Introduction: Design Patterns-policy patterns

Simple Design Mode

 

Introduction

Gof (Gang of Four, which refers to Erich Gamma, Richard Helm, Ralph Johnson & John vlissides)'s design patterns (published in 1995) this is the first time that we have elevated the design pattern to a theoretical level and standardized it. This book proposes 23 basic design patterns. Since then, a large number of new design patterns have emerged in the development process of reusable object-oriented software.

 

1. A group of ducks

Living in a group of happy ducks in the distant Denmark, they can sing (quack), Dance (swim) will also show themselves (Display ). Let's design these ducks into a class. The UML diagram is as follows:

As we can see, each duck will behave the same way.

 

2. ducks come from afar

One day later, a group of "South African ducks" came from Africa. They sang and danced like the Danish duck, but they showed themselves different from the Danish duck.

Here we will use abstract classes to solve this problem, as shown in (AbstractionIn italics)

In this way, we use an abstract class duck to reuse the quack and swim methods, while display is implemented by the inherited sub-classes separately.

Key 1: Identify potential changes in the application and separate them from those that do not need to be changed.Code.

 

3. Every duck is an angel with wings in his life

It was a day of thunder and lightning. The duck boss told the ducklings the story of their ancient Swan flying in the blue sky. It turns out that they have always been wings of angels ......

As a result, these ducks expand their wings ~~ -|

Here, the ducks need a fly method. Since everyone can fly, add it to the parent duck.

 

However, some ducks (Teddy duck, just duck) won't fly ~~ What should we do? Is there an error in our design?

Hmm ~ We should first overwrite the methods in the parent class to achieve our needs.

OK. We have met the requirements.

Key 2: Using inheritance for the purpose of "reuse" (reuse) does not seem very good

 

Think carefully: 1. Have we solved this problem? 2. What should we do if there is another duck a (it won't be called, it won't work, it won't fly), or duck B (it will scream, it will swim, it won't fly? 3. What are the disadvantages of using inheritance to provide duck? A. the Code repeats B in multiple subclasses. c. we cannot let the duck dance D. it's hard to know the full behavior of all ducks. E. duck doesn't play well that fly at the same time and is also called F. it will lead to changes that other ducks don't want.
 

 

4. Have you thought of the "interface"

Looks good ~

If there are a lot of child ducks, the problem will come out. Isn't it true for every duck? Why can't code be reused?

1. Now we know that using inheritance does not solve the problem well, because the duck behavior is constantly changing in the subclass and it is inappropriate for all subclasses to have these behaviors.

2. flyable and quackable interfaces seem to be good at the beginning and solve the problem (only Flying ducks inherit flyable). However, interfaces do not have implementation code, so inherited interfaces cannot be reused in code.

Key 3: Multi-Purpose Combination and less inheritance

 

5. Redesign duck

I. Separated and unchanged parts

(This figure illustrates the self-in-depth design mode)

 

Ii. Interface Programming (digress)

We use interfaces to represent every behavior, such as iflybehavior and iquackbehaviour. Each implementation of the behavior implements one of the interfaces.

This method is different from the past in that the previous practice is: behavior comes from the specific implementation of the duck parent class, or inherits an interface and is implemented by an interface from a row. Both of these methods depend on "Implementation". We are bound to the implementation and cannot change the behavior (unless we write more code)

 
Example: "programming for implementation" Dog d = new dog (); D. bark (); "for interface/super-type programming" Animal animal = new dog (); animal. bark (); what's better is that the actions of subclass instantiation do not need to be hard-coded in the Code, such as new dog (); instead, "the specific implementation object is specified at runtime" A = getanimal ();. makesound ();
 

 

Iii. Implement duck Behavior

 

Iv. Integrate duck Behavior

Note that the two members of duck in are interface types, that is, the iflybehavior and iquackbehavior interface types we mentioned above.

 

Don't forget that because yellowduck inherits duck, it has flybehavior and quackbehavior instance variables.

 

V. Test code

④Enter and compile the test class

 

 
Public class miniduck () {public static void main (string [] ARGs) {duck mini = new yellowduck (); Mini. javasmfly (); Mini. javasmquack ();}}
 

⑤ Run the code

 

6. Summary

Is the class diagram after the whole re-design

The way we describe things here is rarely changed. The behavior of ducks is no longer described as "a group of actions ". We started to think of behavior as a group.Algorithm".

It is the policy pattern in the gof design pattern.

Policy mode: defines algorithm families, which are encapsulated separately so that they can be replaced with each other. This mode allows algorithm changes to be independent of algorithm customers.