Java Design Patterns-six principles of design patterns

The so-called No recruit wins a recruit, practice a kung fu divides into internal strength and drilling.

Drilling is like the moves, is the so-called 23 kinds of design patterns. But the internal strength, is the heart, that is the 6 kinds of laws. Light will drilling that is huaquanxiutui, the internal strength is the situation.

So many design patterns, learned 2 times. 3 times you'll probably forget just the Singleton and the factory model. But only the principle to remember, in the future design, consciously or unconsciously will use the essence of the design pattern.

Six Principles of design

Single principle of responsibility

do not have more than one cause for class changes. In layman's terms, a class is responsible for only one responsibility. The origin of the problem: class T is responsible for two different duties: responsibility P1, Responsibility P2.

When a change of class T is required because of the P1 of the duty, it is possible to cause a problem with the function P2 the normal duties. a sentence summed up: not for the figure code, the cow champ mouth together to a class plug

The principle of the Richter replacement

1. Subclasses can implement the abstract methods of the parent class, but cannot override the non-abstract methods of the parent class.

2. Subclasses can add their own unique methods.

3. When a method of a subclass overloads a method of the parent class, the method's preconditions (that is, the form of the method) are more lenient than the input parameters of the parent class method.

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

Sum up: Do not rewrite the parent class's already implemented methods, you can use the interface and other methods to bypass

Dependency Inversion principle

High-level modules should not rely on the lower layers, both should rely on their abstraction; abstractions should not depend on detail; detail should be dependent on abstraction.

Here is a Lezilai description:

Import Java.util.linkedlist;import java.util.queue;interface ieat{public void Eat ();//abstract Eat This action}class eatapple Implements ieat{@Overridepublic void Eat () {//Here is eating apple System.out.print ("eat a Apple");} Class Eatwater implements ieat{@Overridepublic void Eat () {//Here is draft System.out.print ("Dringk Water");}} public class Human{public void DoSomething (IEAT IEAT)//I love to eat, what to eat, see what is passed {ieat.eat ();} /*public void dosomething (String food)//I love to eat, what to eat. See what's passed in {if (Food.equals ("Apple")) {//Eat Apple}if (food.equals ("Water")) {//drink}}*/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 some water human.dosomething (new Eatwater ());}}

What we are staring at is the way we often use it. Such a method is not suitable for expansion, because it is assumed to eat bananas, eat watermelon, but also in the dosomething to write a bunch of inferences. It was written, and it was mixed.

So one sentence summed up: The use of abstract interface to describe the same action, reducing the number of people and things to achieve this action between the degree of coupling

Interface Isolation principle

The client should not rely on interfaces that it does not need, and a class-to-class dependency should be based on the smallest interface. The problem is that class A relies on class B through interface I, and Class C relies on class D through interface I, assuming that interface I is not the smallest interface for Class A and Class B. Then Class B and Class D must implement methods that they do not need. A sentence summary:Like fish and people two classes, fish is swimming and gills breathing two movements, people are walking and eating two movements, these actions can not be written in an interface inside. All four of these actions are included. To be split into two interfaces specifically for fish and people.

Dimitri Law

The Dimitri rule is also known as the least known principle, which was first proposed by Ian Holland of the American Northeastern University in 1987. In layman's terms, it is a class that knows as little as possible about the classes it relies on.

That is, for a dependent class, regardless of how complex the logic is, try to encapsulate the logic inside the class as much as possible. Outside of the public method provided. Incorrect external leaks no matter what information.

It's a little hard to remember. Summary is:father1<-child1,father2<-child2,father1 and Father2 is the hand, father1 as far as possible through Father2 to interview Child2, Do not visit child2 directly in the class. How can subordinates go to lead the children of the family, beware of people who say you are trafficked

Opening and closing principle

This is nothing to say: try to make changes by extending the behavior of the software entity rather than changing the existing code.

Transfer from http://blog.csdn.net/cq361106306/article/details/38708967

Java Design Patterns-six principles of design patterns