Design principles of design patterns (II) and design patterns

Design principles of design patterns (II) and design patterns

I haven't written a blog for a long time. Because I have been busy with a website recently and have no time to write it, I am sorry to my friends here. Today is also the Mid-Autumn Festival, wish you a happy holiday! Continue with the previous section.

　　Dependence Inversion Principle (DIP)His core idea is that during business design, the high-level module should not depend on the underlying module. The two should depend on and abstract, abstract, and not specific implementation, the specific implementation should be dependent and abstract, which will make the code more stable, thus greatly improving the program's ability to respond to business changes.

Let's take a look at the next example to better understand the above core ideas:

1 public class Car 2 3 {4 5 public string CarName; 6 7 8 9 public Car (string carname) 10 11 {12 13 this. carName = carname; 14 15} 16 17 public void driving () 18 19 {20 21 Console. writeLine (CarName + ": Driving"); 22 23} 24 25 26 27} 28 29 30 31 public class Person32 33 {34 35 public void drive () 36 37 {38 39 Car bmw = new Car ("BMW"); 40 41 bmw. driving (); 42 43} 44 45}

From the above example, we can see that the Person class depends on the Car class, which has a high Coupling Degree. For example, when the Car class changes, problems may easily occur, for example, what should I do when the Person class doesn't want to drive a Car or when I want to drive a train or plane? We can modify the class above. The Person class does not depend on the specific implementation of the Car. We need to rely on abstraction, dependencies and transportation tools. Let's look at the Code:

1 // vehicle abstraction 2 3 public interface IVehicle 4 5 {6 7 void driving (); 8 9} 10 11 // Car 12 13 public class Car: IVehicle 14 15 {16 17 public string CarName; 18 19 20 21 public Car (string carname) 22 23 {24 25 this. carName = carname; 26 27} 28 29 public void driving () 30 31 {32 33 Console. writeLine (CarName + ": Driving"); 34 35} 36 37 38 39} 40 41 // aircraft 42 43 public class Plane: IVehicle 44 45 {46 47 public string PlaneName; 48 49 50 51 public Plane (string carname) 52 53 {54 55 this. planeName = carname; 56 57} 58 59 public void driving () 60 61 {62 63 Console. writeLine (PlaneName + ": Driving"); 64 65} 66 67 68 69} 70 71 // Train 72 73 public class Train: IVehicle 74 75 {76 77 public string TrainName; 78 79 80 81 public Train (string carname) 82 83 {84 85 this. trainName = carname; 86 87} 88 89 public void driving () 90 91 {92 93 Console. writeLine (TrainName + ": Driving"); 94 95} 96 97 98 99} 100 101 public class Person102 103 {104 105 private IVehicle machine = null; 106 107 public Person (IVehicle _ vehicle) 108 109 {110 111 machine = _ vehicle; 112 113} 114 115 public void drive () 116 117 {118 119 machine. driving (); 120 121} 122 123}

 

 

The class diagram is as follows:

 

Client call code:

1 Person person1 = new Person (new Car ("BMW"); 2 3 person1.drive (); 4 5 Person person2 = new Person (new Plane (" ")); 6 7 person2.drive (); 8 9 Person person3 = new Person (new Train ("Train"); 10 11 person3.drive (); 12 13 Console. readLine ();

The output result is as follows:

From the code above, we can see that the Person-type driving method does not need to rely on specific transportation tools, but only on abstraction. The specific transportation tool is imported from outside. This is actually an abstract encoding. It is also a bit of dependency inversion.

Combination is better than inheritance: His core idea is that combination is more flexible and stable than inheritance.

Why? Let's take a look at their respective advantages and disadvantages:

Advantages:

1) The new implementation is easy, because most of them are inherited.

2) It is easy to modify and extend existing implementations.

Disadvantages of inheritance:

1) The encapsulation is broken, because the base class wants to expose the specific implementation details of the amount of sub-classes.

2) white box reuse, because the internal details of the base class are usually visible to the subclass.

3) when the parent class changes, the Child class also changes accordingly.

4) The implementation inherited by the parent class cannot be modified at runtime.

Combination advantages:

1) The contained objects are accessed by the class containing them.

2) the Black Box is reused because the internal details of the contained object are invisible.

3) Good Encapsulation

4) Every class focuses on a task.

5) by obtaining an object reference of the same type as the contained object, you can dynamically define the combination at runtime.

Disadvantages of combination:

1) The system may contain more objects.

2) to enable the combination of different objects, you must define the interface with caution.

Principles of JAVA Design Patterns

In recent years, everyone has begun to pay attention to the design model. So why should we use the design pattern? Why are so many design patterns designed? To be honest, I have never figured it out before. It's just a look at everyone's "Design pattern", and the heart is a bit weak. So I bought the design model of the "four-person gang". The results showed that I understood it clearly. I forgot it later. It may be because I am relatively "stupid" :)) recently, I have some insights. "Joy is better than joy". I 'd like to share it with you and hope to give you some advice!

Why do we advocate "Design Pattern? The root cause is to reuse code and increase maintainability. So how can we achieve code reuse? OO has several principles of its predecessors: "Open-Closed" principle (Open Closed Principal), Rishi replacement principle, and synthetic Reuse Principle. The design pattern is to achieve these principles, so as to achieve code reuse and increase maintainability.

I. Principle of "open-close"

This principle was proposed by "Bertrand Meyer. Original article: "Software entities shocould be open for extension, but closed for modification ". That is to say, the module should be open for expansion, but closed for modification. The module should be extended without modifying the original (original) code. How can we scale it out? Let's look at the factory model "factory pattern": Suppose Zhongguancun has a hacker who sells pirated disk and wool film. We designed a "CD sales management software" for him ". We should first design a "cd" interface.

　　

The pirated disk and the wool film are its sub-categories. The kid manages these CDs through "DiscFactory. Code:

Public class DiscFactory {

Public static disc getDisc (String name ){

Return (CD) Class. forName (name). getInstance ();

}}

How can someone buy a pirated disk?

Public class kiddies {

Public static void main (String [] args ){

CD d = DiscFactory. getDisc ("pirated disk ");

CD. Sell ();

}}

If one day, this kid finds his conscience and starts selling genuine software. It doesn't matter. We just need to create another sub-category "genuine software" of "cd. You do not need to modify the original structure and code. How is it? For extension development, disable modification. "Open-closed principle"

The factory model is to expand specific products. Some projects may require more scalability. To expand the "Factory", it becomes an "Abstract Factory model ".

Ii. Li's replacement principle

The Li's replacement principle was proposed by "Barbara Liskov. If the parent class is called, the sub-classes can be fully run. For example:

CD d = new pirated disk ();

D. Sell ();

Now I want to change the category of "pirated disk" to "fake disk". No problem, it can be fully run. The Java compiler checks whether the program complies with the Li's replacement principle. Do you still remember a principle inherited by java? The access permission of the subclass overload method cannot be less than the access permission of the method corresponding to the parent class ...... the remaining full text>

Who asked the second question?

No matter how hard I work, the years have accumulated, and I will never go back. If we say that memories can shake the tears of the night's dream into a Happy Melody, I think that the arrival of you, whether it is remembered or tears, should be my happiest rhythm. I once heard people say, the Wanderer must go through a wandering river bridge. This river bridge is not in love with secular fame and fortune, not much prosperous. It is just a lonely journey in the left and right, as long as you walk, that is the end of happiness.