Duck Ear Strategy Diagram - First Head Design Example

Question

I want to ask something about the duck example in this book, which has confused me, and I feel contradictions.

• Problem

• conclusions

He said: " When Joe added new behavior to the duck superclass, he also added behavior that was not suitable for suum Duck subclasses. "

BUT in conclusion, he added performFly() and performQuack(); that is different because i think it is the same with he was also adding behavior that was not appropiate for sume Duck subclasses ?

** image taken from the book. Chapter one design model ** this question does not say that this book is not very good, this book is really good, in my opinion. it's just me who asks what I have not received from the book.

Answer 1

In conclusion, he adds two new classes that have a fly() function. However, the function does not always make the duck fly. Rubber ducks cannot fly, so they use an instance of the FlyNoWay class. Other ducks that can fly use an instance of the FlyWithWings class. The flyBehavior field in the Duck class is likely to be set in the constructor.

The performFly() function will call the fly() function for any class.

As kainaw pointed out in the comments, this is a rather complicated solution. However, it can still be used. Say you are creating a duck design program. If the user chooses whether the duck can fly, it cannot be hardcoded. You can create a boolean, but you may have to handle more complex situations, such as behavior. You may need the WildDuckBehavior and DomesticDuckBehavior WildDuckBehavior , each with their own information on how to proceed. Basically, the example in the book is a simplified version of how this will be used.

Answer 2

A strategy template works when you prefer composition rather than inheritance http://en.wikipedia.org/wiki/Composition_over_inheritance

. This is good practice because you can change the behavior of a class without having to change any code. And you do not need a huge class tree. You can also dynamically change class behavior.

In this example, it defines "behavior" in the parent class. In the parent class, you determine that a duck can have flying and quacking behavior. But this does not mean that in children's classes you need to quack or fly.

You may have a flightless duck, and when you call a "fly", it does nothing, because we will have a "flightless" behavior.

Instead of hard-coded programming duck actions in the class, you can change the behavior of this duck whenever you want.

Answer 3

I am not a guru of design patterns, but while I was reading this book, the first sensation I had in this particular chapter was that the interface was built and then implemented, violated one of the well-known programming principles: Network separation principle (ISP) Basically, this principle states that

No client should depend on methods that it does not use

Because some Ducks that don’t fly implement the fly () method, even they don’t need it. Nevertheless, I think that in this particular case it is inevitable to implement all the interface methods, since on the client side we use polymorphic behavior, and we must be sure that we have all the available methods, even if they are not used.

Answer 4

You're right. The solution proposed in the book suffers from one huge problem: FlyNoWay is not a subcategory of FlyBehaviour. To make any difference, FlyBehaviour must require flying skills. Classes that inherit it will determine behavior (fly using wings, etc.). A subclass cannot contain less than the class from which it inherits.

If you look closely, FlyNoWay is just a pseudo-class that was introduced to solve the polymorphism problem inappropriately.

The correct method is to use interfaces.

 class Duck { swim(); } class MallardDuck : IFlyable { fly(); } class RedheadDuck : IFlyable, IQuackable { fly(); quack(); } 

What about reusing code? You must make the interface as strict as possible, ensuring that most changes to the interface will result in the program not compiling.