7 design principles = SOLID + Lod + CRP

Like Newton’s three laws in classical mechanics, the open and closed principle is the cornerstone of Object Oriented Design or OOD. Other design principles (Richter’s substitution principle, dependency inversion principle, single responsibility principle, interface isolation principle, Demeter’s rule, composite reuse principle) are the means and tools to implement the open closed principle.

The open closed principle

The Open Closed Principle (OCP) was developed by Bertrand Meyer, In his 1988 book Object Oriented Software Construction, he proposed: Software entities should be open for extension, but closed for modification. This is the classic definition of the open closed principle.

Details: c.biancheng.net/view/1322.h…

Code directory: Principle/OCP

Windows desktop theme design.

Analysis: A Windows theme is a combination of elements such as desktop background images, window colors and sounds. Users can change their own desktop theme according to their favorite, or download a new theme from the Internet. These topics have common characteristics, and you can define an Abstract Subject for them, with each Specific Subject as a subclass. The user form can select or add new themes as needed without modifying the original code, so it meets the open and closed principle, as shown in the following class diagram.

Richter’s substitution principle

Liskov Substitution Principle, LSP) in an article called Data Abstraction and Hierarchy by Ms. Liskov of the Computer Science Laboratory at MIT, published at OOPSLA in 1987 She proposed: Inheritance should ensure that any property proved about supertype objects also holds for subtypes Objects).

Details: c.biancheng.net/view/1324.h…

Code directory principle/ LSP

Penguins, ostriches and kiwis are biologically classified as birds; However, from the perspective of class inheritance, they cannot be defined as a subclass of “Asuka” because they cannot inherit the function of “Asuka” flying. They need to be redefined as their common parent to birds, because they both run, and they can be defined as “animals,” as shown here.

Dependency inversion principle

Dependence Inversion Principle (DIP) is an article by Robert c. Martin, president of Object Mentor, published in C++ Report in 1996.

The dependency inversion principle was originally defined as: a high-level module should not depend on a low-level module, but both should depend on its abstraction; Abstraction should not depend on details, Details should depend upon abstractions (High level modules shouldnot depend upon low level modules. Both should depend upon abstractions. Abstractions Should not depend upon details. Details should depend upon Abstractions). The core idea is: program to the interface, not to the implementation.

Details: c.biancheng.net/view/1326.h…

Code directory principle/dip

Application of dependency inversion principle in “customer shopping program”. Analysis: This program reflects the relationship between “customer class” and “store class”. The store class has the sell() method, through which the customer class purchases goods:

Class Customer {public void shopping(BookShop shop) {// shop.out.println (shop.sell()); }} However, there is a drawback to this design. If the customer wants to shop from another store (such as FoodShop), the customer's code needs to be changed to the following: Class Customer {public void shopping(FoodShop shop) {// shopping system.out.println (shop.sell()); }}Copy the code

Customers change the code every time they change stores, which is a clear violation of the open and close principle. The reason for the above shortcomings is that the customer class is bound to the specific store class when it is designed, which violates the dependency inversion principle. The solution is to define the common interface Shop for “BookShop” and “FoodShop”, to which the customer class is programmed, as shown in the following class diagram.

Single responsibility principle

Single Responsibility Principle (SRP), also known as Single function Principle, was formulated by Robert C. Robert C. Martin in Agile Software Development: Principles, Patterns, and Practices. The single responsibility principle states that There should never be more than one reason for a class to change.

Single responsibility applies to methods as well. A method should do one thing as well as possible. If a method does too many things, its granularity becomes too coarse for reuse.

Details: c.biancheng.net/view/1327.h…

Code directory Principle/SRP

Procedures for the management of university student work.

Analysis: the university student work mainly includes two aspects of student life guidance and students’ academic guidance work, including counselling mainly includes the construction of class committee, attendance statistics, psychological counseling, cost reminder, class management, academic instruction mainly includes professional guidance, counselling, scientific guidance, learning summary, etc. It is obviously unreasonable to assign these tasks to a teacher. The correct way to do this is to give life guidance to the counselor and academic guidance to the academic tutor, as shown in the following diagram.

Interface Isolation Principle

Interface Segregation Principle (ISP).

In 2002, Robert C. Martin defined the “interface isolation principle” as: Clients should not be forced to depend on methods they do not use. There is another definition of this principle: The dependency of one class to another one should depend on The smallest possible interface.

The interface isolation principle and the single responsibility principle are both intended to improve the cohesion of classes and reduce the coupling between them, reflecting the idea of encapsulation, but they are different: the single responsibility principle focuses on responsibilities, while the interface isolation principle focuses on the isolation of interface dependencies. The single responsibility principle is mainly a constraint class, which is targeted at the implementation and details in the program; The interface isolation principle mainly constrains interfaces and is aimed at abstraction and the construction of the overall framework of the program.

Details: c.biancheng.net/view/1330.h…

Code directory Principle/ISP

The student achievement management program.

Analysis: Student grade management procedures generally include insert, delete, modify the results, calculate the total score, divide calculation, printing performance information, query results, and other functions, if all these features into an interface obviously is not very reasonable, right, it is respectively in the input module, statistics module and print module three modules, the class diagram below.

Demeter’s rule

The Law of Demeter (LoD) is also known as the Least Knowledge Principle (LKP), Born in 1987 as a Northeastern University research project called Demeter, proposed by Ian Holland and popularized by Booch, one of the founders of UML, He later became known as The Pragmatic Programmer in his classic book.

Demeter’s Law is defined as: Talk only to your immediate friends and not to strangers. The implication is that if two software entities do not communicate directly, then direct calls to each other should not occur and can be forwarded by a third party. Its purpose is to reduce the degree of coupling between classes and improve the relative independence of modules.

The “friend” in Demeter’s law refers to the current object itself, its member object, the object created by the current object, the method parameters of the current object, etc. These objects are associated, aggregated or combined with the current object, and can directly access the methods of these objects.

Details: c.biancheng.net/view/1331.h…

Code directory Principle /Lod

An example of the relationship between a star and his agent.

Analysis: Celebrities devote themselves to their art, so many daily affairs are handled by their agents, such as meeting with fans and negotiating with media companies. Here agents are friends of the stars, and fans and media companies are strangers, so it’s appropriate to apply Demeter’s rule, as shown in the following diagram.

Principle of composite reuse

Composite Reuse Principle (CRP) is also called Composition/Aggregate Reuse Principle (CARP). It requires that in software reuse, we should first use association relation such as combination or aggregation, and then consider using inheritance relation.

If inheritance is to be used, the Richter substitution principle must be strictly followed. The principle of composite reuse and the Principle of Richter’s substitution complement each other.

Details: c.biancheng.net/view/1333.h…

Code directory Principle/CRP

The automobile classification management program.

Analysis: according to the “power source” can be divided into gasoline vehicles, electric vehicles, etc. According to the “color” can be divided into white cars, black cars and red cars. If you consider both categories, the combinations are numerous. Using inheritance to implement many subclasses, and adding new “power sources” or adding new “colors” requires modifying the source code, which violates the open closed principle and is obviously not desirable. However, the above problems can be well solved by using combinatorial relations, as shown in the following class diagram.

Source github.com/buloo/Desig…