Java design pattern-six principles of design pattern, java Design Pattern

Java design pattern-six principles of design pattern, java Design Pattern

The so-called "no moves, no moves, no tricks, no practical skills" can be divided into internal and external skills. External talents are like tricks. They are the so-called 23 design patterns. The internal strength is the mental law, which is the six rules. It is huafan embroidery leg, the internal skill is the realm. After completing these many design models, you may forget the singleton and factory models three times. But as long as the principle is remembered, In the future design, the essence of the design model will be used intentionally or unintentionally.

Six Design Principles

Single Responsibility Principle

There should be no more than one cause of class change. In general, a class is only responsible for one responsibility. Problem cause: Class T has two different responsibilities: Responsibility P1 and responsibility P2. When the class T needs to be modified because of the change in the responsibility P1 requirement, it may lead to the failure of the originally running responsibility P2 function. To sum up one sentence: We can't add a class together with a bid to reduce the amount of graph code.

Rys replacement principle

1. Subclass can implement abstract methods of the parent class, but cannot overwrite non-abstract methods of the parent class.

2. You can add a method unique to the subclass.

3. When the subclass method reloads the method of the parent class, the preconditions of the method (that is, the form parameter of the method) are looser than the input parameters of the parent class method.

4. When the subclass method implements the abstract method of the parent class, the post-condition (that is, the return value of the method) of the method is stricter than that of the parent class.

To sum up one sentence: Do not overwrite the implemented methods of the parent class. You can use interfaces and other methods to bypass them.

Dependency inversion principle

High-level modules should not depend on low-level modules, both of which should depend on their abstraction; abstraction should not rely on details; details should rely on abstraction.

Here we use a column to describe:

Import java. util. using list; import java. util. queue; interface IEAT {public void eat (); // abstract this action} class EatApple implements IEAT {@ Overridepublic void eat () {// here is the apple System. out. print ("eat a apple") ;}} class EatWater implements IEAT {@ Overridepublic void eat () {// here is the System. out. print ("dringk water") ;}} public class Human {public void dosomething (IEAT ieat) // What do I love to eat? Let's see what I input {ieat. eat ();}/* public void dosomething (String food) // I love to eat, what to eat, and what to input {if (food. equals ("apple") {// eat apple} if (food. equals ("water") {// water} */public static void main (String [] args) {Human human = new Human ();/* human. dosomething ("apple"); human. dosomething ("water"); * // give you an apple human. dosomething (new EatApple (); // give you a drink of human. dosomething (new EatWater ());}}

The comments are commonly used methods. This method is not suitable for expansion, because if you want to eat bananas, watermelon, you have to write a bunch of judgments in dosomething. It's just a mix of words.

Therefore, in one sentence, abstract interfaces are used to describe the same action, reducing the coupling between people and things implementing this action.

Interface isolation principle

The client should not rely on interfaces that it does not need; the dependency of one class on the other class should be built on the smallest interface. Problem cause: Class A relies on Class B through interface I, and class C relies on Class D through interface I. If interface I is not the smallest interface for Class A and Class B, then class B and class D must implement the methods they do not need. To sum up one sentence: Fish and humans are two types of actions: swimming and cheek breathing, and walking and eating. These actions cannot be written in one interface, these four actions are included. It is necessary to split it into two special interfaces for fish and humans.

Dimit Law

It was first proposed by Ian Holland at Northeastern University in 1987. In general, a class knows little about its dependent classes as well. That is to say, for the dependent class, no matter how complicated the logic is, we try to encapsulate the logic inside the class as much as possible. In addition to the public method provided, we do not disclose any information externally.

This is a bit difficult to remember. The conclusion is: father1 <-child1, fat22-child2, father1 and fat22. father1 tries to access child2 through fat22, do not directly access child2. how can a subordinate take care of the children who lead the house?

Principle of opening/closing

This is nothing to say: Try to implement changes by extending the actions of software entities, rather than modifying existing code.