Software Design principles

General principles of design pattern adherence:

1. Open-Close principle (open-closed Principle, OCP): a software entity should be developed for expansion and closed for modifications. The point is that when designing a module, the module should be extended without being modified. In other words, It should be possible to change the behavior of the module without having to modify the source code, and to extend the system on the basis of maintaining a certain stability of the system. This is the cornerstone of object-oriented design (OOD) and the most important principle.

2. the principle of substitution on the Richter scale (Liskov Substitution Principle, often abbreviated as. LSP)
(1) by Barbar Liskov (Barbara Richter), is the cornerstone of succession reuse.
(2). Strict expression: If each type is T1 object O1, there is a type of T2 object O2, so that all program P defined by T1 when all object O1 is substituted O2, the behavior of the program P does not change, then type T2 is a subtype of type T1.
In other words, if a software entity is using a base class, then it must apply to its subclasses, And it is not aware of the difference between a base class object and a subclass object. Only the derived class can replace the base class, the functionality of the Software Unit is unaffected, the base class is truly reused, and the derived class can add new functionality on top of the base class.
(3). The reverse substitution is not tenable
(4) .< Mozi. Small take > said: "White horse, horse also; By the White Horse, and by the horse, and also by the horse.
(5). This type of Western famous example is whether the square is a subclass of rectangles (the answer is "no"). There is a similar relationship between Ellipse and circle.
(6). Should inherit from the abstract class as far as possible, not from the specific class inheritance, in general, if there are two concrete classes, a and inheritance relationship, then one of the simplest modification is to create an abstract class C, and then let classes A and B become the subclass of abstract class C. That is, if there is a registration structure formed by an inheritance Then all the leaf nodes should be concrete classes on the tree tree of the hierarchical structure, and all the node nodes should be abstract classes or interfaces.
(7). " Based on the design by Constract, the "DBC" technology provides support for the Liskov substitution principle. This technology Bertrand Meyer Bertrand has been described in detail:
With DBC, the writer of the class explicitly prescribes a contract for that class. The author of the client code can learn the behavior that can be relied upon by the contract. The contract is a precondition (preconditions) and a post condition (postconditions) declared by each method To specify. In order for a method to execute, the precondition must be true. After execution, the method guarantees that the post condition is true. That is, when you re-declare a routine (routine) in a derived class, you can only replace the original precondition with an equal or weaker precondition. You can only replace the original post condition with an equal or stronger post condition.

3.Dependency Inversion principle (dependence inversion Principle),Requires the client to rely on abstract coupling.
(1) Expression: The abstraction should not depend on the detail, the detail should depend on the abstraction. (Program to a interface, not an implementaction)
(2) Expression two: For the interface programming means that the use of interfaces and abstract classes should be used for variable type declaration, parameter type declaration, method of return type declaration, and data type conversion and so on. Do not program for the implementation of the meaning that the specific class should not be used for variable type declaration, parameter type declaration, The return type declaration of the method, the conversion of the data type, and so on.
To ensure that this is done, a specific class should only implement methods that are declared in the interface and abstract classes, and should not be given redundant methods.
As long as an abstract type exists for a referenced object, the abstract type should be used wherever the object is referenced, including the type declaration of the parameter, the declaration of the method return type, the type declaration of the property variable, and so on.
(3) The difference between an interface and an abstraction is that an abstract class can provide partial implementations of some methods, and interfaces are not, which is probably the only advantage of an abstract class. If you add a new concrete method to an abstract class, all of the subtypes will get the new concrete method all at once, The interface does not do this. If a new method is added to an interface, all classes that implement the interface cannot be compiled because none of them implements the new declaration. This is obviously a disadvantage of the interface.
(4) An implementation of an abstract class can only be given by subclasses of this abstract class, that is, the implementation is in an inherited registration structure defined by an abstract class, and because the general language restricts a class to inherit from at most one superclass, it compromises the effectiveness of the abstraction as a type definition tool.
Conversely, looking at an interface, you will find that any class that implements the method specified by an interface can have the type of this interface, and a class can implement any number of interfaces.
(5) From the point of view of code refactoring, it is easy to refactor a single concrete class into an interface, just declare an interface and add the important method to the interface declaration, and then put the reserved word in the concrete class definition statement to inherit from the interface.
Adding an abstract class as an existing concrete class is not as easy as an abstract type, as it is possible that the concrete class already has a superclass. Thus, the new definition of the abstract class has to continue to move upward, into this superclass super class, so loop, Finally, the new abstract class must be at the top of the hierarchy of the entire type so that all members of the enlisted structure are affected.
(6) An interface is an ideal tool for defining mixed types, which is a secondary type that is outside the main type of a class. A mixed type indicates that a class does not only have the behavior of one of the main types, but also has other minor behaviors.
(7) Joint use of interfaces and abstract classes:
Because an abstract class has the advantage of providing a default implementation, and the interface has all the other advantages, it is a good choice to use both together.
First, the work of declaring the type still assumes the interface, but at the same time gives an abstract class that gives the interface a default implementation. Other specific classes that belong to this abstract type can choose to implement this interface, or they can choose to inherit from this abstract class. If a specific class implements this interface directly, It has to implement all the interfaces on its own, and conversely, if it inherits from the abstract class, it can omit unnecessary methods because it can automatically get the default implementations of these methods from the abstract class, and if you need to add a new method to the interface, It is possible to add a concrete implementation of this method to this abstract class at the same time, because all subclasses inheriting from this abstract class will get this concrete method from this abstract class. This is the default adapter mode (Defaule Adapter).
(8) What is a high-level strategy? It is the abstraction behind the application, the truth that does not change with the specifics. It is the system within the system ____ metaphor.

4. interface Isolation principle (Interface segregation Principle, ISP)
(1) The dependency of a class on another class is based on the smallest interface.

(2) using more than one dedicated interface is better than using a single total interface. Depending on the needs of the customer, providing different services to different clients is a way to be encouraged. Like "due dish", it depends on who the guest is, and offers different grades of food.
(3) Fat interfaces can cause unhealthy and harmful coupling relationships between their client programs. When a client program asks for a change to the fat interface, it affects all other client programs. Therefore, the client program should rely solely on the methods that they actually need to invoke.

5. synthesis/polymerization multiplexing principle (composite/aggregate reuse Principle,carp)
Use some existing objects in a new object to make them part of the new object; The new object is used to reuse the existing functionality through the delegation of these objects. This design principle has another brief statement: To use composition/aggregation as much as possible, and not to use inheritance.

6. The Dimitri rule (Law of Demeter LoD) is also called the least-knowledge principle (Least knowledge principle,lkp), which means that an object should have as little understanding of other objects as possible.
The Dimitri Law was originally used as a rule for object-oriented system design, and was proposed by Ian Holland at Northeastern University in the autumn of 1987 for a project called Dimitri (Demeter), so called the Dimitri Law [lieb89][lieb86]. This rule is actually a guiding design principle for many well-known systems, such as the Mars Landing software system, and the software system of the Jupiter-Europa satellite orbital spacecraft.
There is no other OO design principle like the Dimitri law so there are so many ways to express it as follows:
(1) Communicate with your direct friends only (your immediate friends)
(2) Do not speak to "strangers" (Don ' t talk to strangers)
(3) Each software unit has only the least knowledge of the other units, and is limited to the software units which are closely related to the unit.
That is, if two classes do not have to communicate directly with each other, then these two classes should not have a direct interaction, if one of the classes needs to invoke a method of another class, you can forward the call through a third party.

7. Single Responsibility principle (simple responsibility pinciple SRP)
In the case of a class, there should be only one cause for it to change, and if you can think of more than one motive to change a class, then this class has more than one responsibility. You should separate more accusations and create classes to accomplish each responsibility.

In addition: Often said the five principles of OO refers to: 1, the single principle of responsibility, 2, the principle of open closure, 3, the Richter replacement principle, 4, the dependency inversion principle, 5, the interface isolation principle.

original link: Software design principles ( for learning use only)

Software Design principles