Five principles of design patterns

1. Single Responsibility Principle

Whether in design, interface, or method, a single responsibility is everywhere. A single responsibility is defined as the cause of system changes. When defining classes, interfaces, and methods. After the definition is complete, think about it again. There is no more motivation to change this class, interface, and method. If the answer is yes, the defined class, interface, and method are more than one responsibility. Therefore, if a single responsibility is violated, you should subdivide the responsibilities until there are no classes or interface methods with multiple responsibilities (discover responsibilities and separate those responsibilities ). One of the five simplest principles is a single responsibility. It is embodied everywhere in the software design process. Everywhere.

 

2. principles of openness and Closure

The open/closed principle means that classes, modules, and methods can be expanded, but cannot be modified. It is open to expansion, and closed to modification. The application of the open/closed principle is embodied in the fact that developers should only abstract the frequent changes in the Program (encapsulate the changes ). Encapsulation of the change point is to disable the change modification. Uncertainty of changes can be expanded at any time. That is, the use of inheritance. The use of abstract classes.

 

3. Lee's replacement principle

The principle of lining replacement is to always ensure that the base class of a subclass can be replaced.

The implementation of the Lee replacement principle. For a group of classes with similar attributes, methods, and variables. We can extract public attributes, methods, and variables as a base class (abstract class or class), so that this group of classes inherits the base class and override the virtual method. Currently, the relationships between these inherited classes and the base classes comply with is-. If the base class is a bird, the inheritance class can be a sparrow or swallow. We can say that sparrow is-a bird, swallow is-a bird.

All child classes in the project can be replaced by the parent class, but the method is called to present Object-Oriented Programming polymorphism. That is, the Lee replacement principle, a very important principle, is also a relatively difficult principle.

 

4. Dependency inversion principle

A. High-level modules should not depend on low-level modules. Both of them should depend on abstract B, and abstraction should not rely on details. Details should depend on abstraction.

During analysis and design in a process-oriented development language, some high-level modules are always created to call the low-level modules, and the policies depend on the detailed software structure. In fact, the purpose of this method is to define the subprogram hierarchy, which describes how the high-level module calls the lower-level module. The well-designed object-oriented program is just an inversion of this dependency. High-level modules no longer rely on low-level modules, so that the modifications to the low-level modules will not affect the High-Level modules, and the high-level modules can be easily reused, both high-level and low-level modules depend on abstraction. This is also very compatible with the programming idea of strong cohesion and loose coupling. Therefore, this principle is also the core principle of framework design.

Using the dependency structure created by the traditional procedural program design, the strategy depends on the details. This is bad, because it will affect the policy by changing the details, object-Oriented Programming reverses the dependency structure. Full details and policies depend on abstraction, and often the customer program has service interfaces.

In fact, the inversion of this dependency is exactly the sign of a good object-oriented design. It doesn't matter which language is used to write programs. If the program dependency is inverted, it is an object-oriented design. If the program dependency is not inverted, it is a procedural design.

The dependency inversion principle is a basic low-layer mechanism that implements the benefits declared by many object-oriented technologies. Its correct application is required for creating reusable frameworks. At the same time, it is also very important for building flexible code in the face of changes. Because abstraction and details are isolated from each other, the Code is also very easy to maintain.

 

5. Interface isolation principles

It should be said that this principle is to deal with the shortcomings of the existing "fat" interface. If the class interface is not cohesive, it indicates that the class has a "fat" interface. In other words, the "fat" interface can be divided into multiple groups of methods. Each method serves a different set of customer programs. In this way, the customer program can use a group member function, while other customer programs can use a group member function.

There are two methods for interface isolation (the sharing client is the splitting Interface ):

1. Use the delegate (This delegate is not a. Net delegate [Delegate]) to separate the interface

By using delegation, you can create a delegate class and use this class to implement methods in other interfaces after separation.

2. Use the multi-inheritance isolation interface,

This method divides the existing "fat" interface into two or more interfaces that can be called by different customer programs. The customer program that needs to implement multiple interfaces is implemented using multiple inheritance.

These two methods are all the methods for implementing interface isolation. The second method is common and simple. The first method is relatively complicated to use, and the re-object will be generated during the use of the Delegate, which takes up the running time and memory overhead. Sometimes the second method is required, and the first method cannot be used. For example, the conversion made by using the delegate object is required, or different conversions are required in different cases.

Transferred from: http://www.cnblogs.com/yuqilin/archive/2011/09/04/2162961.html Li Guoqing blog Park

Five principles of design patterns