1 Introduction
After work, the code can not only finish, and reuse, maintenance is also very important, before the codes are to write their own functions for the purpose of considering not only the other a class all finished on the line, but that the future will exposed more problems, rather than scrawl, it is better not to write, leaving some time to the idea of the whole process, not went ahead.
Design patterns are exposed to long before the concept, but for not less than with the concept of science, there has been no serious study to go, this time determined to learn it again ,, design patterns and principles of development lay the foundation, increase the height of thinking.
2. Speaking from ducks
If the "machine learning" is the watermelon book, that chapter is the first design patterns book a duck, was an example to more people left a deep impression.
Suppose we have a group of ducks classes that inherit the super class Duck.
Duck
quack()
swim()
display()
//鸭子的其他方法All the ducks are quacking (Quack) will also swim (Swim), so by the superclass implementation code responsible for handling this part.
Since the appearance of each duck is different, so display () method is abstract, each duck subclass is responsible for implementing its own display.
This seems to be a perfect system, they carry out their duties, each doing, but by the same part of the management responsible for the superclass.
3. duck to fly
The new demand, and this time we want to join ducks flying capabilities. Duck wings would have been no problem, join a fly method in the superclass, the subclass inherits all of the good,
Duck
quack()
swim()
display()
fly() //新加入的飞行方法
//鸭子的其他方法Indeed, all the ducks are flying, but the system and some rubber ducks, they can fly, and this is not consistent with common sense! ! !
We overlooked one thing, not all subclasses will fly, some will not fly also inherited this method.
Note: local modifications made to the code, not just the local level impact.
When it comes to "maintenance" in order to "reuse" the purpose of the use of inheritance, the outcome is not perfect.
3.1 The first solution - subclasses covering
We can fly a method of covering rubber duck out
RubberDuck
quack(){//吱吱叫}
display(){//橡皮鸭}
fly(){
//覆盖，什么也不做
}This seems to really solve the problem of rubber ducks, but if we can not fly after each duck to join, so should check again, lost the meaning of the multiplex.
3.2 second solution --- the use of interfaces
We can fly from superclass method to take out and put a Flyable interface, so that only ducks fly only implement this interface.
This approach is not feeling seems to be, absolutely not! This way duplicate code will become much, even if the coverage is bad several methods, then for 48 subclasses of Duck should slightly modify the behavior of the flight, is simply a nightmare.
If there is a way to establish the software, so that we can use a minimal impact on existing ways to modify the software code that be nice. We can spend less time to redo the code, and let the program do more than cool thing.
4. Re-look at the problem
Now we know that the use of inheritance and can not solve the problem, because the duck's behavior is constantly changing in the sub-class, and so that all subclasses have these behaviors are inappropriate. Flyable and Quackable the interface seems a pretty good start to solve the problem (only ducks fly only inherited Flyable), but the interface does not have a Java implementation code, it inherits the interface can not achieve code reuse. This means: Whenever you need to change a behavior, you have to track down and modify it in every definition of this behavior class, accidentally, may cause new mistakes!
Fortunately, there is a design principle, just for this situation.
Design principles: identify applications may require changes in place, put them independent, and do not need to change the code that mix.
In other words, if every time a new demand to, certain areas will make the code changes, then you can determine, this part of the code needs to be drawn to, and other stable code differentiated.
Here is another way to think about this principle: "vary the portion taken out and packaged together, so that you can easily be altered or expanded in this section, without affecting the rest does not require changes."
Such a concept is simple, almost is the spirit behind each design pattern. All models have provided a way for "a part of the system changes will not affect other parts."
Well, this is the behavior of the duck removed from the Duck class time!
5 redesign duck
We extracted two categories, one is fly, is a quack, each set of classes to achieve their action, you can specify a particular type of behavior to duck flying, let them dynamically to change just fine.
Design principles: for interface programming, rather than programming.
We use interface represents each behavior, each implementation action will implement an interface of them.
This approach is quite different from the past, the previous approach is: to achieve specific behavior from Duck superclass, or inherited by subclasses to implement an interface from their own. Both practices are dependent on the "implementation", we implemented tied too tightly, no way to change the behavior (unless write more code). In our new design, the ducks will use the behavior of the subclass Interface (FlyBehavior and QuackBehavior) represented, so the actual "realization" will not die tied to a subclass of ducks. (In other words, in the preparation of certain specific behavior and achieved FlyBehavior QuakcBehavior class).
This design allows flying and croaking actions are multiplexed other objects, because these acts have nothing to do with duck class, and not just for the Duck class and extraction, now has nothing to do with the Duck.
This way, with the succession of "reuse" benefits, but did not inherit the burden brought about.
6. Implement duck behavior
First, the class Duck "Join two instance variables", namely "flyBehavior" and "quack Behavior", is declared as an interface type (class rather than specific implementation type), each duck objects are dynamically set these variables in refer to the correct type of behavior is running (for example: FlyWithWings, Squeak, etc.).
We also need to Duck class with all its sub-class fly () and quack () deleted because these acts have been moved to FlyBehavior and QuackBehavior the class.
We use two methods similar performFly () and performQuack () substituted Duck class Fly () and quack ().
Superclass
Duck
FlyBehavior flyBehavior
QuackBehavior quackBehavior
performQuack(){ quackBehavior.quack(); }
swim()
display()
performFly()A subclass
public class MallardDuck extends Duck {
public MallardDuck() {
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
public void display() {
System.out.println(“I’m a real Mallard duck”);
}
}7. Summary
When you use the combination of two classes, as in the present embodiment a - generally, this is a combination (composition). Such practices and "inheritance" different places that duck behavior is not inherited, but the behavior of objects and appropriate "combination" to the.
As you can see, a combination create a system with great flexibility, not only the family of algorithms may be packaged as such, but also "dynamically change the runtime behavior", as long as the combination of the behavior of the object interface standard can conform to correct.
Design principles: multi-purpose combination, less inheritance.
Strategy Mode
Defines a family of algorithms, are encapsulated, so that they can replace each other, so that a change in this pattern is independent of the algorithm Algorithm customers.