Re: Why RTTI is considered as a bad design?
On Wednesday, August 22, 2012 2:38:17 AM UTC-7, =D6=F6 Tiib wrote:
On Tuesday, August 21, 2012 4:57:06 PM UTC+3, Scott Lurndal wrote:
=?ISO-8859-1?Q?=D6=F6_Tiib?= <ootiib@hot.ee> writes:
Usually i see dynamic_cast<>() more used for cross-casting rather than=
down=
-casting. I bring an example. A specific Door passed to SomeDoer::open=
(Door=
*) may have Lockable interface or not. To have all Doors Lockable by d=
efaul=
t would deviate from sane design since most doors can not be locked. S=
ucces=
s of unlocking may depend of availability of Keys or LockPicks or what=
ever =
for this SomeDoer so open() forwards these problems to SomeDoer::unlo=
ck(Lo=
bool SomeDoer::open( Door* door ) const
// we might need to unlock first on some cases
Lockable* lock = dynamic_cast<Lockable*>(door);
if ( lock != NULL && lock->isLocked() && !unlock( lock ) )
Can you tell how such a situation can be resolved as elegantly without=
RTTI=
(or some self-made substitution of RTTI)?
The ->unlock() method becomes a no-op on a non-lockable door. In other=
words,
one may always call unlock, and if the door is lockable, it will be unl=
ocked;
if not, no-op.
Unlocking itself (with no parameters whatsoever)? It can no way made a re=
sponsibility of a door. If there is lock then it is real and unlocking it m=
ay fail without proper keys or pass-codes. A generic door knows (and should=
know) nothing of it.
Only the cross-casting into "Lockable" may be (and often is) made respons=
ibility of a "Door" but bloating its interface with fake complexities of po=
ssibly "Lockable" is bad design.
Actually, it seems to me that composition is better here. A door either ha=
s a lock or doesn't. That lock is either engaged or it isn't. Opening a d=
oor is either successful or it isn't (and being locked isn't the only reaso=
n it might fail--could be a busted knob or something in the way). A door t=
hat does not have a lock could have one added to it later in many different=
ways.
Thus cross casting seems like a bad solution and instead there should be a =
failable function to attempt an open, a function that gets the lock or list=
of locks (could be many), and then the client can look for locks, check th=
eir state, and open the door. No RTTI required. This seems to me to be th=
e most logical solution given the problem domain.