Seven Principles of Software Design

Seven Principles of Software Design

The general principles of design patterns are as follows:

1.Open-closed principle ):A software entity should be responsible for extended development and should be closed for modifications. when designing another module, the module should be extended without being modified. in other words, the behavior of this module should be changed without modifying the source code, and the system should be extended on the basis of maintaining a certain degree of system stability. This is the cornerstone of object-oriented design (OOD) and the most important principle.

2.Liskov substitution principle, often abbreviated as. LSP)
(1) proposed by Barbar liskov (Barbara R), it is the cornerstone of inheritance reuse.
(2 ). strict expression: if every T1 object O1 has an O2 object whose type is T2, so that all program P defined by T1 is replaced by O2 for all object O1, the action of program P is not changed, so Type T2 is the child type of Type T1.
In other words, if a software entity uses a base class, it must be applicable to its subclass, and it cannot detect the differences between the base class object and the subclass object. only when the category class can replace the base class can the functions of the software unit be unaffected, and the base class can be reused. The category class can also add new functions based on the base class.
(3). In turn, replacement is not valid.
(4). <Mozi. Xiaoyao>: "White Horse, horse also; riding White Horse, riding horse also. Horse (black horse), horse also; riding horse, riding horse also ."
(5). This famous Western routine is: whether the square is a subclass of a rectangle (the answer is "no "). Similarly, there is a relationship between an ellipse and a circle.
(6 ). we should try to inherit from the abstract class instead of the specific class. Generally, if there are two specific classes A and B that have an inheritance relationship, the simplest solution is to create an abstract class C, and then make class A and B a subclass of the abstract class C. that is, if there is a registration structure formed by an inheritance relationship, all leaf nodes on the hierarchy should be specific classes; all tree branches should be abstract classes or interfaces.
(7). "based on design by constract, or DBC", this technology provides support for the liskov replacement principle. This technology is described in detail by Bertrand MEYER:
When DBC is used, the class creator explicitly specifies the contract for this class. the creator of the Customer Code can use this contract to learn the behavior that can be relied on. A contract is specified by preconditions and postconditions declared by each method. to execute a method, the precondition must be true. after execution, this method must ensure that the post condition is true. that is to say, when you re-declare the routines (routine) in the derived class, you can only use equal or weaker preconditions to replace the original preconditions, only equal or stronger postcondition can be used to replace the original postcondition.

3.Dependence inversion principle ),The client is required to rely on abstract coupling.
(1) Representation: Abstraction should not depend on details, and details should depend on abstraction. (program to an interface, not an implementaction)
(2) expression 2: For interface programming, it means that the interface and abstract class should be used to declare the type of the variable, the type declaration of the parameter, and the return type declaration of the method, and data type conversion. do not implement programming. That is to say, you should not use a specific class to declare the type of a variable, declare the parameter type, declare the return type of the method, and convert the data type.
To ensure this, a specific class should only implement the methods declared in interfaces and abstract classes, rather than providing redundant methods.
As long as a referenced object has an abstract type, the abstract type should be used wherever the object is referenced, including the parameter type declaration and the method return type declaration, attribute variable type declaration.
(3) The difference between an interface and an abstract is that an abstract class can provide partial implementation of some methods, but an interface cannot. This is probably the only advantage of an abstract class. if you add a new method to an abstract class, all the child types will get the new method, and the interface will not be able to do this. if a new method is added to an interface, all classes that implement this interface cannot be compiled because they do not implement the new declaration method. this is obviously a disadvantage of the interface.
(4) the implementation of an abstract class can only be given by the subclass of this abstract class. That is to say, this implementation is in the inherited registration structure defined by the abstract class, generally, a language limits a class to be inherited from at most one superclass. Therefore, the efficiency of using abstraction as a type definition tool is greatly reduced.
If you look at the interface, you will find that any class that implements the methods specified by an interface can have the type of this interface, and a class can implement any number of interfaces.
(5) from the perspective of code refactoring, it is easy to refactor a specific class into an interface. You only need to declare an interface, add the important methods to the interface declaration, and add the reserved words in the specific class definition statement to inherit from the interface.
It is not easy to add an abstract class as an existing concrete class, because this specific class may already have a super class. in this way, the newly defined abstract class has to move up and become the super class of this super class. In this loop, the new abstract class must be at the top of the class hierarchy, in this way, all members in the registration structure will be affected.
(6) An interface is an ideal tool for defining hybrid types. For hybrid types, it is a secondary type other than the primary type of a class. A hybrid type indicates that a class has not only a primary type of behavior, but also other secondary behaviors.
(7) joint use interface and abstract class:
Abstract classes have the advantages of providing default implementations, while interfaces have all other advantages. Therefore, it is a good choice to use both classes together.
First, the declaration type work is still undertaken by the interface, but an abstract class is also provided, providing a default implementation for this interface. other specific classes of the same abstract type can choose to implement this interface, or inherit from this abstract class. if a specific class directly implements this interface, it must implement all its own interfaces. On the contrary, if it inherits from an abstract class, it can save unnecessary methods, because it can automatically obtain the default implementation of these methods from the abstract class; if you need to add a new method to the interface, you only need to add a specific implementation of this method to this abstract class at the same time, because all subclasses inherited from this abstract class will get this specific method from this abstract class. this is actually the default adapter mode (defaule adapter ).
(8) What is a high-level policy? It is the abstraction behind the application and the truth that does not change with the specific details. It is the system ____ metaphor within the system.

4.Interface segregation principle (ISP)
(1) One Class depends on another class on the smallest interface.

(2) It is better to use multiple special interfaces than to use a single total interface. it is encouraged to provide different services for different clients based on the customer's needs. just like "looking at people's dishes", it depends on who the guests are and then provides meals of different grades.
(3) The fat interface may lead to abnormal and harmful coupling between their customer programs. when a customer program requires a change to the fat interface, it will affect all other customer programs. therefore, the customer program should only rely on the methods they actually need to call.

5.Principles of synthesis/aggregation reuse (composite/aggregate Reuse Principle, CARP)
Use existing objects in a new object to make it a part of the new object. New objects reuse existing functions through these delegates to the object. this design principle has another short expression: Use synthesis/aggregation as much as possible, and do not use inheritance as much as possible.

6.Law of Demeter looss is also called the least knowledge principle (LKP ),That is to say, an object should have as little knowledge as possible about other objects.
The DEMETER rule was originally designed as an object-oriented system design style, and was proposed by Ian Holland for a project called Demeter at Northeastern University in the fall of 1987, therefore, it is called the Demeter 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 Jupiter's Europa satellite orbital spacecraft.
There is no other OO design principle as there are so many expressions like the Demeter law:
(1) only communicate with your friends (only talk to your immediate friends)
(2) don't talk to strangers (don't talk to strangers)
(3) Each software unit has only the minimum knowledge of other units, and is limited to software units closely related to this unit.
That is to say, if two classes do not need to communicate with each other directly, they should not interact directly. If one class needs to call a method of another class, this call can be forwarded by a third party.

7.Simple responsibility pinciple SRP)
For a class, there should be only one reason for its change. If you can think of more than one motivation to change a class, then this class has more than one responsibility. more than one criticism should be separated, and some classes should be created to complete each responsibility.

Seven Principles of Software Design