Check the class of objects
janderson
askme at me.com
Sat Jun 7 02:14:16 PDT 2008
mael wrote:
> Actually, this wouldn't be the right solution,
> because the doSomething action is specific to a particular algorithm, and there will be tens of such algorithms, and I don't want to clutter the main class with parts of algorithms adapted to each class...
>
http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism
http://c2.com/cgi/wiki?SwitchStatementsSmell
The following is an excerpt from Scott Meyers’ new book,
Effective C++, Third Edition: 55 Specific Ways to Improve
Your Programs and Designs.
"Effective C++, Third Edition Item 27 7
One thing you definitely want to avoid is designs that involve cascading
dynamic_casts, i.e., anything that looks like this:
class Window { ... };
... // derived classes are defined here
typedef std::vector<std::tr1::shared_ptr<Window> > VPW;
VPW winPtrs;
...
for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter)
{
if (SpecialWindow1 *psw1 =
dynamic_cast<SpecialWindow1*>(iter->get())) { ... }
else if (SpecialWindow2 *psw2 =
dynamic_cast<SpecialWindow2*>(iter->get())) { ... }
else if (SpecialWindow3 *psw3 =
dynamic_cast<SpecialWindow3*>(iter->get())) { ... }
...
}
Such C++ generates code that’s big and slow, plus it’s brittle, because
every time the Window class hierarchy changes, all such code has to
be examined to see if it needs to be updated. (For example, if a new
derived class gets added, a new conditional branch probably needs to
be added to the above cascade.) Code that looks like this should
almost always be replaced with"
I think that only becomes appropriate if you use a template or operator
overloads to generate this so its generic, less brittle and without evil
down casting.
-Joel
More information about the Digitalmars-d-learn
mailing list