With our new design, the Duck subclasses will use a behavior represented by an interface (FlyBehavior and QuackBehavior), so that the actual implementation of the behavior (in other words, the specific concrete behavior coded in the class that implements the FlyBehavior or QuackBehavior) won’t be locked into the Duck subclass. We were locked into using that specific implementation and there was no room for changing the behavior (other than writing more code). In both cases we were relying on an implementation. This is in contrast to the way we were doing things before, where a behavior came either from a concrete implementation in the superclass Duck, or by providing a specialized implementation in the subclass itself. Instead, we’ll make a set of classes whose entire reason for living is to represent a behavior (for example, “squeaking”), and it’s the behavior class, rather than the Duck class, that will implement the behavior interface. So this time it won’t be the Duck classes that will implement the flying and quacking interfaces. We’ll use an interface to represent each behavior-for instance, FlyBehavior and QuackBehavior-and each implementation of a behavior will implement one of those interfaces.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |