Solid design pattern principles are:
- Single Responsibility Principle: Single Responsibility Principle
- Open Closed Principle: the principle of opening and closing
- Liskov Substitution Principle: Leeb Substitution Principle
- Interface Segregation Principle: Interface Segregation Principle
- Dependence Inversion Principle: Dependency Inversion Principle
Besides that:
- Law of Demeter: Demeter
- Composite / Aggregate ReusePrinciple: Synthesis of multiplexing principles
Link: https: //www.jianshu.com/p/3268264ae581
A single responsibility principle (SRP)
"Factors like changes never more than one." Or "a class has one and only one responsibility."
Here the "single responsibility" is what we usually call "high cohesion", that a class should be done only completed its duties, can not pass the buck, and do not pass away behalf of the blisters, it can not become like God almighty.
This is a violation of the "single responsibility principle" of class structure.
Here, Rectangle class does the following two things:
- Calculating the area of a rectangle;
- Draw a rectangle on the interface (drawing apparatus);
This violates the SRP (Single Responsibility Principle). Because Rectangle class does two things, in a way in which calculate the area, in another of its method returns a rectangle representing the GUI.
Duties should be broken into two different classes, such as:
- Rectangle: This class should be defined only Area () method;
- RectangleUI: This class should inherit the Rectangle class, and define the Draw () method.
Second, the open closed principle (OCP)
"Software entities (classes, modules, functions, etc.) should be open for extension, modification closed."
Popular terms, it means (the customer or class) you should be able to extend the behavior of this class in a class without modifying the premise. Where we want to change the system that may encapsulate that closed for modification.
Meanwhile, in order to deal with (function) extended the system requirements, you need to abstract! "Design Patterns" in the state model and strategy model is the best embodiment of this principle.
Violation of the principle of a closed class structure diagram open.
The client code directly to a specific server-side implementation program, the lack of flexibility. So if for some reason the server is replaced with other servers, the client calls the server code must be modified accordingly or replaced. In fact, this is the "realization-oriented programming" design smell!
So, how to get the right to modify flexible design?
The answer is: the abstract! For the server code (Type) abstract an abstract base class (the interface defines a set of minimum service complete responsibility).
Here is the correct design:
Three, Liskov's Substitution Principle (LSP)
"Subtype must be able to replace their base type." Or put another way: "Use local reference to the base class must be able to use objects of derived classes without knowing it."
Here, KingFisher (Kingfisher) Bird class extends the base class, and inherited the Fly () method, this is no problem.
But the following class structure diagram there is a design problem:
Ostrich (Ostrich) is a bird, no doubt about that, and Bird inherit from the class, which conceptually there is no problem. But the ostrich can fly? Can not, then this design violates the LSP. Because in place of use can not necessarily be Ostrich Bird instead.
So, even if in reality seems no problem in class design, Ostrich Bird should not inherit from the class, there should be a separate class NoFlyBrid not fly in from Bird, Ostrich should inherit this flightless bird NoFlyBrid.
LSP Why so important?
- If no LSP, class inheritance is messed up; if the child class as a parameter passed to the method, there will be unknown behavior;
- If there is no LSP, suitable for the base class test unit can not be successfully used to test subclasses;
Fourth, the interface separation principles (ISP)
"The client should not be forced to rely on their unused interfaces." Or said:. "Software system module size as small as possible, in order to achieve highly reusable"
Interface contains many methods will reduce its availability, such as a method comprising useless "fat Interface" will increase the coupling between classes. If you want a class that implements this interface, then it need to implement all of the methods, although for some it may be completely useless, so this introduces unnecessary complexity in the system, reducing the maintainability of the code.
If an interface method contains too many, it should be resolved by separating the interface.
This is a violation of the principle of separation of fat interfaces interfaces.
Notice IBird interface contains many acts of birds, including the Fly () behavior. Now if a Bird class (eg Ostrich) implements this interface, then it need to implement unnecessary Fly () behavior (Ostrich can not fly). Thus, this "fat Interface" should be split into two different interfaces, IBird and IFlyingBird, while IFlyingBird inherited from IBird. As shown below:
In this case, the very flexible reuse: if a bird can not fly (e.g. Ostrich), then it IBird implement the interface. If a bird can fly (such as KingFisher), then it implements IFlyingBird.
Fifth, the Dependency Inversion Principle (DIP)
The meaning of this principle is: high-level modules should not depend on the underlying module, both of which should rely on their abstract. In fact, is "programming to interfaces, not oriented programming to achieve" inherent requirement.
Automobile engine is composed of many such wheel, air conditioning, and other and other components: 
where Car is a high-level module; it depends on the abstract interface IToyotaEngine and IEighteenInchWheel.
And specific engine FifteenHundredCCEngine bottom module belongs, it is also dependent on the abstract interface IToyotaEngine;
Specific wheel EighteenInchWheelWithAlloy also belong to the bottom module, also dependent on the abstract interface IEighteenInchWheel.
The above Car class has two attributes (list engine and wheels), which are an abstract type (interface). Engine and the wheels are removable, because the car can accept any object that implements the interface declaration, and Car class does not need to make any changes.
Sixth, the Law of Demeter (LoD / LKP)
Only communicate with your friends, do not speak with "strangers."
Seven, synthetic multiplexing principles (CARP)
Try to use object composition rather than inheritance relationships to achieve the purpose of software reuse.
This principle is usually progressive avoid violating the Richter substitution principle requires.
Original link: https: //blog.csdn.net/e5max/article/details/8872182
