Shulou(Shulou.com)06/03 Report--

Strategy mode

Description of the problem:

Requirements: develop a duck game, can swim, have the appearance, the implementation class diagram is as follows:

Increased demand:

1. Add flight function

two。 Add the quack function. Wait, the temporary solution is as follows:

After launch, there were some problems:

1. Can all ducks bark? Where's the wooden duck?

two。 Can all ducks fly? Where's the wooden duck? Where's the rubber duck?

To sum up, the disadvantages of using inheritance:

The code is repeated in multiple subclasses

Runtime behavior is not easy to change

It's hard to know the whole behavior of ducks.

Change will trigger the whole body, causing changes that other ducks don't want.

. . .

All right, let's introduce the interface for further modification, and the class diagram is as follows:

The problem has been solved, but there are more than 40 kinds of ducks. If we modify the fly method, can we modify 40 samples? The maintenance pit in the future is a little big!

To sum up, the disadvantages of this approach are:

The code is repeated in multiple subclasses

Increased maintenance costs (there are 40 ducks, it takes 40 times to modify the fly method? )

. . .

Problems continue, we use the set pattern to solve this problem, first look at the definition: policy pattern: define the algorithm family, respectively encapsulated, they can replace each other, this pattern makes the change of the algorithm independent of the customer who uses the algorithm.

OK, let's modify it. The class diagram is as follows:

We used this model to solve the problem:

1. There are all kinds of duck behavior (there is no direct relationship between subclass behavior and superclass behavior, adding and deleting behavior does not affect the inheritance system)

two。 Code reuse, maintenance problems (it is especially troublesome to modify behavior when there are too many subclasses, and the code is repeated, just modify the algorithm group)

3. Dynamically modify behavior (Setter and Getter methods to flexibly configure behavior)

4. .

The design principles we have learned in this chapter:

Design principle 1: encapsulate changes (find out where changes may be needed in the application, separate them, and don't mix them with code that doesn't need changes).

Design principle 2: program against interfaces, not implementation classes

Design principle 3: use more combinations and less inheritance

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.