Analysis of solid object-oriented model

2. Single responsibility principle (SRP)

   The single Responsibility Principle

   A classic illustration of a foreigner's reference:

   The single principle of responsibility requires that "a class can have only one duty", and the only reason for this kind of change is that responsibility. When a class has multiple responsibilities, it should separate the other responsibilities and create classes to complete.

   For example:

   The class modem realizes the function of modem, but it realizes two functions (you can say four responsibilities, this is divided according to the application scenario), connection establishment and terminal, data transmission and receiving. So the problem is, if you want to modify the data transfer method, you need to modify the modem class, then all the elements dependent on the modem need to be modified. The solution is to reconstruct the modem, extract two interfaces from it, connection is responsible for the connection, Datachannel responsible for data transmission. Finally, there are modemimplementation implementations of the two interfaces.

3. Opening and closing principle. (OCP)

   The Open Closed Principle

   When you wear your coat, you don't need a thoracotomy.

   "Modules should be open to extensions, close to changes" 1. "Open to expansion", when demand changes, we can expand the module to have new behavior that satisfies those changes, making the software adaptable and flexible. 2. "Turn off changes", when we need to extend the new functionality, we should write new code, should not modify the original code.

   For the OCP principle, abstraction is the key. For example, if more than one client relies on a specific server, when the server needs to extend the new functionality, it will cause all client changes to be possible. The solution is to abstract a server, so that the client relies on this abstract server, only to describe what is not easy to change a set of services, so that its subclasses to provide specific implementation and extension, so that the implementation of specific and extended changes will not affect the client.

   An additional understanding of the OCP is the "package variability Principle" (EVP). The core idea is to "find the mutable elements in the system and encapsulate them." EVP has two key points:

   1. Variability should not be scattered around the code, but should be encapsulated in a class.

   2. One type of variability should not be mixed with another variability.

   What you allow to change, but not let the change lead to redesign. The OCP is the core of object-oriented design, but the actual misuse of the OCP is also wrong, and the correct approach is to abstract and encapsulate only the parts of the program that show frequent changes .

4. The Richter replacement principle. (LSP)

   The Liskov Substitution Principle
   

   Real ducks and toy ducks are abstract ducks, but toy ducks need batteries, which is a false abstraction.

   Thought: Inheritance must ensure that the properties owned by the parent class are still true in the subclass, and that when an instance of a subclass can replace any instance of its parent class, there is a is-a-kind-of-a relationship between them. Only when a subclass (derived class) replaces its parent class (the base class) and the software functionality is not affected, A base class can be reused, and derived classes can add new behavior based on the base class.

   Its essence is that the objects in the same inheritance system should have common behavioral characteristics.

   For example: Penguins do not belong to birds, because penguins do not fly, so penguins can not inherit birds.

5. Interface separation principle (ISP).

   The Interface segregation Principle
   

   Provide a single interface as "small" as possible, instead of providing a large interface.

   Idea: multiple interfaces with the customer are better than a common interface. If a class has several consumers, instead of letting the class use all of the methods that it requires, create a specific interface for each consumer and have the class implement the interfaces separately. do not allow redundant methods in the interface that are not related to the functionality of the interface.

   As shown, Class A relies on interface I method 1\ method 2\ Method 3, Class B is an implementation of Class A dependency, Class C relies on the method method in interface I 1\ method 4\ method 5, Class D is the implementation of Class C dependency. There are methods that are not available for Class B and Class D, but because of the implementation of interface I, So it's necessary to implement these unused methods. It can be found that the interface is too bloated, as long as the interface appears in the method, regardless of the class that depends on it is not useful, the implementation class must implement these methods, such as in class B method 4 and Method 5, Class D in Method 2 and Method 3, it is clear that such a design does not apply:

   The principle of interface isolation is to try to refine the interface as little as possible, creating a dedicated interface for each class, rather than trying to build a huge and bloated interface to provide all of the classes that depend on him to invoke.

   Speaking of which, many people will feel that the interface isolation principle is similar to the previous single principle of responsibility, it is not.

   One is that the single responsibility principle focuses on responsibility, while the interface isolation principle focuses on the isolation of interface dependencies.

   Second, the principle of single responsibility is mainly constrained class, followed by the interface and method, it is the implementation and details of the program, and the interface isolation principle mainly constrains the interface, mainly for the abstract, for the construction of the overall framework of the program.

6. Dependency inversion principle. (DIP)

   The Dependency inversion Principle

   Thought: High-level modules should not rely on low-layer modules, both should be dependent on abstraction.

   1. High-level modules should only contain important business models and policy choices

   2. Low-level module is the implementation of different business and strategy

   3. High-level abstraction does not rely on the implementation of high-level and underlying modules, up to the lower levels of abstraction

   4. Low-level abstraction and implementation are also dependent on high levels of abstraction

   For example:

   Now the driver eastmount not only to drive a Mercedes-Benz, but also to drive a BMW, and how to achieve it? Custom BMW, but not open, because Eastmount does not open the BMW method, the problem is:

   between the driver class and the Mercedes-Benz class is a tight coupling relationship, which led to a greatly reduced maintainability of the system, the addition of new vehicles such as BMW BWM car will need to modify the driver class drive () method, this is not stability but variable. The change of the dependent person should allow the dependent to bear the cost of the change, Span style= "FONT-SIZE:14PX; line-height:27.2px; Text-indent:1em; " > So it can be implemented by the dependency inversion principle.

   As shown, through the establishment of two interfaces Idriver and ICAR, respectively defined the driver's function is driving the car, through the drive () method, the function of the car is to run, through the run () method to achieve.

   We discussed 5 design principles, the most important is the OCP, the other four are attached to the open and closed principle, contrary to the other four principles are directly or indirectly contrary to the OCP.

Analysis of solid object-oriented model