Object-Oriented Programming principles

Disclaimer: the object-oriented programming principles listed below are not my personal summary, but my notes on recent design patterns. Currently, only a few items are listed. You can continue to add them later.

1. Single Responsibility Principle (SRP)

The single responsibility principle is that, for a class, there should be only one reason for its change.

That is to say, a class should only implement a single function. Why? If a class has too many responsibilities, it is equivalent to coupling these responsibilities. A change in responsibilities may weaken or suppress the class's ability to fulfill other responsibilities. This coupling will lead to a fragile design. When a change occurs, the design will be unexpectedly damaged. For example, if we write a form application, we generally generate a class like form1, so we can use a variety of codes, such as some functional algorithms, the SQL statements used for database access are written into such a class. This means that you need to change the form class regardless of your needs. This is actually very bad, it is difficult to maintain, reuse is impossible, and there is a lack of flexibility.

What software design really needs to do is to discover responsibilities and separate them from each other. If you can think of more than one motive to change a class, this class has more than one responsibility, and you should consider the separation of duties of the class.

2. Open-Close Principle

The open-closed principle means that software entities (such as classes, modules, and functions) can be expanded but cannot be modified.

This principle has two features: "Open for extension" and "Closed for modification )". It is actually the so-called "High Cohesion, loose coupling ". In this way, the changes to the program are made by adding new Code, rather than changing the existing code.

The open-closed principle is the core of object-oriented design. Following this principle can bring about the huge benefits that object-oriented technology claims, that is, maintenance, scalability, reusability, and flexibility. Developers should only abstract those parts that present frequent changes in the program. However, it is not a good idea to deliberately Abstract Every part of an application. Rejecting immature abstractions is just as important as abstraction itself.

3. Dependency reversal Principle

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

Why is it reversed? In process-oriented development, to make common code reusable, they are generally written into libraries of many functions. When creating a new project, call these lower-level functions. For example, if we want to access the database most of our projects, we will write the code for accessing the database and call these functions every time we create a new project. This is called a high-level module dependent on a low-level module. The problem with this is that when we want to create a new project, we find that the business logic of the high-level module is the same, but the customer wants to use different databases or storage information methods, in this case, it is troublesome. We hope to use these high-level modules again, but the high-level modules are all associated with the access to the database at the lower level, and there is no way to reuse these high-level modules. However, if both the high-level module and the low-level module depend on abstraction (interface or abstract class), as long as the interface is stable, no other changes will be affected, this makes it easy for both the High-Level module and the low-level module to be reused.

Rishi replacement principle

Child types must be able to replace their parent types.

Ms. Barbara liskov published the principle of Rishi replacement in 1988. The specific mathematical definition is complicated. vernacular translation is a place where the parent class appears and can be replaced by a subclass, it does not affect the program. That is to say, in the software, the parent class is replaced with its subclass, and the behavior of the program will not change.

It is precisely because the child types can replace their parent types that the parent type modules can be extended without modification to implement the Dependency inversion principle, only then can the open-closed principle be realized.

Dependency inversion can be said to be a sign of object-oriented design. It is not important to write a program in which language. If the programming is based on abstract programming rather than detailed programming, that is, all dependencies in the program are terminated from abstract classes or interfaces, that is, object-oriented design, and vice versa, that is, procedural design.

 

Refer: