Object-oriented s.o.l. I. d Principle

Object-oriented s.o.l. I. d Principle

In general, this is the five object-oriented design principles, but I think these principles can be applied to all software development.

Single Responsibility Principle (SRP)-single Responsibility Principle

The core idea of a single responsibility principle is:One class only does one thing and completes it well. There is only one reason for its change.. The single responsibility principle can be seen as the extension of low coupling and high cohesion in the object-oriented principle. The responsibility is defined as the cause of change to improve cohesion to reduce the cause of change. Too many responsibilities may lead to more reasons for its changes. This will lead to dependency between duties and affect each other, greatly damaging their cohesion and coupling. A single responsibility usually means a single function. Therefore, do not implement too many function points for a module to ensure that the entity has only one reason for its change.

• Unix/Linux is the perfect embodiment of this principle. Each program is responsible for a single task independently.
• Windows is a negative example of this principle. Almost all programs are intertwined and coupled.

Open/closed principle (OCP)-principle of open/closed

With regard to the principle of closed development, the core idea is that modules are scalable and cannot be modified. That is to say,It is open to extensions and closed to modifications.

• Open to expansion means that existing code can be expanded to adapt to new situations when there are new requirements or changes.
• Closed modification means that once the class is designed, its work can be completed independently without any modification to the class.

For object-oriented users, You need to rely on abstraction instead of implementation. The "Policy mode" in 23 classic design patterns is the implementation. For non-object-oriented programming, Some APIs require you to input a function that you can extend. For example, our c-language qsort () allows you to provide a "Comparator ", memory Allocation of containers in STL and various locks of multithreading in Ace. For software, browser plug-ins belong to this principle.

Liskov substitution principle (LSP)-Rishi replacement principle

Software Engineering guru Robert C. Martin finally simplified the Li's replacement principle into one sentence: "subtypes must be substitutable for their base types ". That is, subclasses must be able to replace them with their base classes. That is, the subclass should be able to replace any location where the base class can appear, and after replacement, the code will work normally. In addition, conditions such as if/else for determining subclass types should not appear in the code. LSP is an important guarantee for codes to comply with the open and closed principles. It is precisely because the child type can be replaced that the parent type module can be expanded without modification.

In this case, it seems to be a bit systematic. I suggest you take a look at the two most classic cases of this principle-"square is not a rectangle" and "ostrich is not a bird ". Through these two cases, you will understand what Mozi xiaozi says-"Beauty, beauty, love, not beauty .... Thieves and people; evil thieves, not wicked people ." -- Although my sister is a beauty, it does not mean that I like my sister. Thieves are human beings, but they do not hate humans.This principle does not allow you to consider the relationship between semantic objects, but the actual needs of the environment..

In many cases, the relationship between classes is not very clear at the initial stage of design. LSP gives us a benchmark to judge the relationship between the classes and design: do not need to inherit, and how to design inheritance relationships.

Interface segregation principle (ISP)-interface isolation principle

The interface isolation principle refers to implementing functions in interfaces rather than classes. It is better to use multiple specialized interfaces than to use a single total interface.

For example, we use computers in different ways, such as writing, communication, watching movies, playing games, surfing the Internet, programming, computing, and data, if we declare these functions in the computer pumping class, then our netbook, PC, server, and notebook implementation class will implement all these interfaces, this is too complicated. Therefore, we can isolate these functional interfaces, such as work learning interfaces, programming and development interfaces, online entertainment interfaces, and computing and data service interfaces, computers with different functions can selectively inherit these interfaces.

This principle can improve our software development by building blocks. In terms of design, various event listener and adapter in Java have different features for software development. Different versions have different features, which are the application of this principle.

Dependency inversion principle (DIP)-Dependency inversion principle

High-level modules should not rely on the implementation of low-level modules, but on high-level abstraction.

For example, the wall switch should not rely on the lamp switch implementation, but on an abstract standard interface of the switch. In this way, when we expand the program, our switch can also control different lights or even different appliances. That is to say, electric lights and other electrical appliances inherit and implement our standard switch interface, and our switch manufacturer does not need to care about what kind of equipment it wants to control, but only about the Standard switch standard. This is the principle of dependency inversion.

It seems that the browser does not depend on the Web server, but only on the HTTP protocol. This principle is too important. The division of labor and standardization of society are the embodiment of this design principle.

Object-oriented s.o.l. I. d Principle

In general, this is the five object-oriented design principles, but I think these principles can be applied to all software development.

Single Responsibility Principle (SRP)-single Responsibility Principle

The core idea of a single responsibility principle is:One class only does one thing and completes it well. There is only one reason for its change.. The single responsibility principle can be seen as the extension of low coupling and high cohesion in the object-oriented principle. The responsibility is defined as the cause of change to improve cohesion to reduce the cause of change. Too many responsibilities may lead to more reasons for its changes. This will lead to dependency between duties and affect each other, greatly damaging their cohesion and coupling. A single responsibility usually means a single function. Therefore, do not implement too many function points for a module to ensure that the entity has only one reason for its change.

• Unix/Linux is the perfect embodiment of this principle. Each program is responsible for a single task independently.
• Windows is a negative example of this principle. Almost all programs are intertwined and coupled.

Open/closed principle (OCP)-principle of open/closed

With regard to the principle of closed development, the core idea is that modules are scalable and cannot be modified. That is to say,It is open to extensions and closed to modifications.

• Open to expansion means that existing code can be expanded to adapt to new situations when there are new requirements or changes.
• Closed modification means that once the class is designed, its work can be completed independently without any modification to the class.

For object-oriented users, You need to rely on abstraction instead of implementation. The "Policy mode" in 23 classic design patterns is the implementation. For non-object-oriented programming, Some APIs require you to input a function that you can extend. For example, our c-language qsort () allows you to provide a "Comparator ", memory Allocation of containers in STL and various locks of multithreading in Ace. For software, browser plug-ins belong to this principle.

Liskov substitution principle (LSP)-Rishi replacement principle

Software Engineering guru Robert C. Martin finally simplified the Li's replacement principle into one sentence: "subtypes must be substitutable for their base types ". That is, subclasses must be able to replace them with their base classes. That is, the subclass should be able to replace any location where the base class can appear, and after replacement, the code will work normally. In addition, conditions such as if/else for determining subclass types should not appear in the code. LSP is an important guarantee for codes to comply with the open and closed principles. It is precisely because the child type can be replaced that the parent type module can be expanded without modification.

In this case, it seems to be a bit systematic. I suggest you take a look at the two most classic cases of this principle-"square is not a rectangle" and "ostrich is not a bird ". Through these two cases, you will understand what Mozi xiaozi says-"Beauty, beauty, love, not beauty .... Thieves and people; evil thieves, not wicked people ." -- Although my sister is a beauty, it does not mean that I like my sister. Thieves are human beings, but they do not hate humans.This principle does not allow you to consider the relationship between semantic objects, but the actual needs of the environment..

In many cases, the relationship between classes is not very clear at the initial stage of design. LSP gives us a benchmark to judge the relationship between the classes and design: do not need to inherit, and how to design inheritance relationships.

Interface segregation principle (ISP)-interface isolation principle

The interface isolation principle refers to implementing functions in interfaces rather than classes. It is better to use multiple specialized interfaces than to use a single total interface.

For example, we use computers in different ways, such as writing, communication, watching movies, playing games, surfing the Internet, programming, computing, and data, if we declare these functions in the computer pumping class, then our netbook, PC, server, and notebook implementation class will implement all these interfaces, this is too complicated. Therefore, we can isolate these functional interfaces, such as work learning interfaces, programming and development interfaces, online entertainment interfaces, and computing and data service interfaces, computers with different functions can selectively inherit these interfaces.

This principle can improve our software development by building blocks. In terms of design, various event listener and adapter in Java have different features for software development. Different versions have different features, which are the application of this principle.

Dependency inversion principle (DIP)-Dependency inversion principle

High-level modules should not rely on the implementation of low-level modules, but on high-level abstraction.

For example, the wall switch should not rely on the lamp switch implementation, but on an abstract standard interface of the switch. In this way, when we expand the program, our switch can also control different lights or even different appliances. That is to say, electric lights and other electrical appliances inherit and implement our standard switch interface, and our switch manufacturer does not need to care about what kind of equipment it wants to control, but only about the Standard switch standard. This is the principle of dependency inversion.

It seems that the browser does not depend on the Web server, but only on the HTTP protocol. This principle is too important. The division of labor and standardization of society are the embodiment of this design principle.