Re: Sibling Polymorphism
Greg D <greg.door@gmail.com> wrote in news:e95149e2-fe99-4471-9855-
85b2771d40cd@l16g2000hsf.googlegroups.com:
I've come across a pattern (I'd call it an antipattern) in the course
of my job, recently, and I was wondering:
A: Who's seen or done this before?
B: Is there even a theoretically good reason for something like this?
In simplified form:
// ---------- begin code
class B;
class A
{
public:
virtual B* getB() = 0;
};
class B
{
public:
virtual A* getA() = 0;
};
class C : public A, public B
{
public:
A* getA() { return (A*)this; }
B* getB() { return (B*)this; }
};
int main()
{
C* c = new C();
A* a = c->getA();
B* b = a->getB();
a = b->getA();
delete c;
return 0;
}
// ---------- end code
I agree with you that this is an anti-pattern. The motivation seems to
be to bounce around between interfaces or composing objects.
In general, I think this pattern fails. Encapsulation is broken because
each parent class knows about the other parent classes and you can't
have one without the others. This means that what you really have is
one class split into multiple pieces for all practical purposes. That
is, A and B might just as well be one class since if C inherits from A,
it must also inherit from B. I think the modeling is suspect since the
interface implies there is a relationship between A and B and yet that
is very indirectly expressed.
Why not use dynamic_cast<>?
int main()
{
C* c = new C();
A* a = dynamic_cast<A*>(c);
B* b = dynamic_cast<B*>(a);
a = dynamic_cast<A*>(b);
delete c;
return 0;
}
Should work just as well and you don't have the parent classes making
assumptions about the derived classes.
HTH,
joe
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]