In the design code, we have many design patterns that we can follow, allowing me to make the logical structure of the whole project clear and easy to maintain. Of course, there are more than just patterns in design patterns, there are many design principles, and while they are not templates for code architecture, they are always a reminder to improve code quality and prevent future trouble. This time I will explain the single responsibility principle, the open-closed principle and the dependency reversal principle.
One, single responsibility principle
Professional interpretation: The single responsibility principle (SRP), for a class, should have only one cause for its change. If a class takes on too many responsibilities, those responsibilities are coupled together, and changes to one responsibility may impair the class’s ability to perform other responsibilities. This coupling can lead to fragile designs that can be unexpectedly broken when changes occur.
Actually is easy to understand, for example, like the need to write a visual interface program can be applied to Windows, a lot of people will write business logic code and interface mixed together, that it really can be task to complete, but it will be a problem, when I need a can also run on IOS visual interface of the program, At this point I need to refactor the entire program. If I had separated the business logic code from the interface code at the very beginning, when the interface code needed to change, there would have been little impact on the business logic code, thus enabling reuse.
Of course, this is easier said than done, and what software design is really about is finding responsibilities and separating those responsibilities, and it’s really not that hard to determine if there’s separation, which is that if you can find more than one motivation to change the class, then the class has more than one responsibility.
Ii. The principle of open-closure
The open-closed principle states that software entities (classes, modules, functions, etc.) should be extensible, but not modifiable. It is open for extension and closed for modification.
The open-closed principle teaches us how to design a system that is relatively stable in the face of changing requirements, so that new versions of the system can be introduced after the first one. This principle is similar to the single responsibility principle in that it makes the program as modular as possible and reduces coupling, but the development-closed principle also emphasizes preparation for future expansion. As we mentioned in the previous example, write a calculator program, the first demand, only addition, subtraction, multiplication, and division but later may increase demand, such as the square root of based on this, we need to consider to open closed principle, using some methods to achieve changes in demand, reduce our workload, so we thought about the use of simple factory pattern.
Absolute closed for modification is not possible, no matter how much module is “closed”, there are some can’t closed change, since can’t completely closed, the designer should design the module of to him should be closed to what kind of change to make a choice, he must first guess is most likely to change, and then construct abstract to isolate those changes.
Of course, it is impossible to predict all changes at the beginning of a program’s design, so we initially write code assuming that changes will not occur, and when they do occur, we construct abstractions to isolate similar changes that will occur later.
The open-closed principle is at the heart of object-oriented design. Following this principle can bring the great benefits of object-oriented technology, that is, maintainable, extensible, reusable, and flexible. Developers should abstract the parts of the program that change frequently. Deliberately abstracting every part of your application is not a good idea; rejecting immature abstractions is as important as abstraction itself.
3. Reliance inversion principle
High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details, details should depend on abstractions. Dependency inversion can be said to be a sign of object-oriented design, to write programs in that language is not important, if writing to consider is how to abstract programming rather than the details for programming, the program ending all dependencies in the shit in the abstract class or interface, that is object-oriented design, on the other hand is the procedural design.
In order to repair the computer for example, replacing CPU, memory card, etc., in fact, there are several object-oriented design principles. As we talked about before single responsibility principle, the computer memory is broken, should not be an excuse for replacement of the CPU, between their respective responsibilities clear, open and closed – principle, memory as long as the slot can add enough, hard enough can use mobile hard disk, PC interface is limited, but as long as the software system design of good, but it can be unlimited extension. In the dependency inversion principle, abstractions should not depend upon details. Details should depend upon abstractions, namely for interface programming, to realize the programming, regardless of the motherboard, CPU, hard disk interface design are presented in the, if in reality to design, so when designing CPU mainboard, etc, you need to know the different brands of different interface.