Re: design problem with inheritance
On Aug 23, 3:09 pm, alessio211734 <alessio211...@yahoo.it> wrote:
I am reading a design pattern book.
the example is a class duck that a method fly
class duck
{
virtual void fly(){......}
void display();
}
class FakeDuck: public duck()
{
void fly(){ override to nothing...}
}
if I have a FakeDuck class it's need to override the fly method to
nothing because a FakeDuck can't fly.
And so on for every subclass of duck that have no fly feature.
If there are many such subclasses, then perhaps fly shouldn't be
a function of the base interface. If there are many such
subclasses, however, Duck probably isn't a very good name for
the base class. It's very, very exceptional that ducks can't
fly.
More generally, however, the problem might occur for Animal;
some animals can fly, but most can't. The solution in such
cases is generally to extend the interface:
class Animal
{
// No function fly.
};
class FlyingAnimal : public virtual Animal
{
virtual void fly() = 0;
};
Animals which can fly implement FlyingAnimal; animals which
can't implement Animal. Client code which needs to make the
animal fly will first dynamic_cast the Animal* to FlyingAnimal*,
and take whatever actions are appropriate if the dynamic_cast
fails.
(Note too that the inheritance is virtual. This should almost
always be the case when extending an interface: one can easily
imagine a SwimmingAnimal, a WalkingAnimal, etc., and concrete
animals which implement more than one of these.)
book propose the pattern strategy and to extern the fly
behavior as a
class FlyBehavior
{
virtual void fly()=0;
}
I think you're misunderstanding the book. The strategy pattern
is about implementation, not interface.
class NoFly: public FlyBehavior
{
virtual void fly(){ printf("can't fly")};
and the class duck became
class duck
{
FlyBehavior * bhv;
void performFly(){ bhv->fly(); }
}
I have doubts about the design proposed because book says
encapsulating the algorithms in a class hierarchy and make them
interchangeable.
But ok if I need the private data about duck class to implement the
fly method of NoFly class how can do it??
Then perhaps the strategy pattern is not the best solution. The
big advantage of the strategy pattern is that it allows changing
the strategy dynamically. If you don't need this, you can use
the template method pattern, or mixins---a certain type of wing
supports flying, and an animal which has this type of wing and
can fly inherits (privately, since this is implementation) from
this type of wing; the "member data" to which the function needs
access is a class which implements the actual function.
But it depends. In such cases, it's not rare that in certain
cases, the concrete strategy is a member (usually private) of
the concrete class. In this case, the concrete strategy has
can have access to the member data.
--
James Kanze