Foreword:
For daily development projects, if it is just a simple first-phase development and you are not responsible for anything later, then you can develop it by yourself (if no one asks);
However, if you want to continuously develop the first phase, maintain development in the later period, or develop in a large team, you must basically understand some principles of development objects. In order to expand development and understand, low coupling, scalability, and reusability For sexual development, knowing some principles will lead to more effective code.
These principles are obtained through practice, and after understanding, you will get conventional development ideas and design code logic.
One: Single Responsibility Principle
A class is only responsible for the corresponding code development in a functional module.
For example, a conventional interface development: control layer cotroller plus service interface layer development, and db database interaction and other modules, each class has its own responsibility module,
Do not merge code development, which is not conducive to later maintenance, code browsing, and review functions.
Secondly: A class has too many functions, which is equivalent to coupling these functions together. When one of the functions changes, it may affect the module development, so these functions should be separated.
For example: If the service interface layer and db database interaction are placed in the first phase, if you want to change the database interaction technical framework, will you have to consider a lot of codes, changes, and inspections?
Two: the principle of opening and closing
Software entities should be open for extension and closed for modification,
That is, software entities should try to expand without modifying the original code.
This is how to think about it. It is more convenient for later maintenance and development. When new requirements change, try not to change the original code.
1. Maintain and develop in a polymorphic way
2. New interface method for development
3. The overall framework is optimized. For example, in a previous project, all interface logic subjects are in one class.
In this class, there are mainly three abstract interfaces, business rule verification, parameter inspection, database interaction,
For each interface or transaction, customize an implementation layer, inherit the base class, implement three APIs, and later develop new interfaces, just add an interface class and implement three APIs
Three: Liskov substitution principle
All places that refer to the base class object can transparently use its subclass object; if
a base class object is replaced by its subclass object in the software, the program will not produce any errors and exceptions, and vice versa, if a If the software entity uses a subclass object, it may not be able to use the base class object;
The Liskov substitution principle is one of the important ways to realize the opening and closing principle. Since the subclass object can be used wherever the base class object is used, the base class type should be used to define the object as much as possible in the program, and the object can be defined again at runtime. Determine its subclass type, and replace the parent class object with the subclass object.
A simple understanding is:
When using inheritance, parent class A, child class B,
All the codes can be replaced by B when referring to the location of the parent class A, just to try not to rewrite the method of the parent class for the subclass, otherwise, different people have different opinions, and it is not conducive to rewriting too much Later maintenance, expansion, replacement.
Four: Dependency Inversion Principle
Abstractions should not depend on details, details should depend on abstractions;
Simple, business implementation layer approach, using interfaces for development.
The principle of dependency inversion requires us to refer to high-level abstract layer classes as much as possible when passing parameters in program code or in association relationships, that is, using interfaces and abstract classes for variable type declarations, parameter type declarations, method return type declarations, and data types conversions, etc., instead of using concrete classes to do these things
After introducing the abstraction layer, the system will have good flexibility. Try to use the abstraction layer for programming in the program, and write the concrete class in the configuration file. In this way, if the system behavior changes, only the abstraction layer needs to be updated. Expand and modify configuration files without modifying the source code of the original system, and expand the system's functions without modification, meeting the requirements of the open-close principle.
Five: Interface Segregation Principle
Use multiple dedicated interfaces instead of a single general interface;
that is, the client should not rely on those interfaces it does not need, and each interface should assume a relatively independent role, and do not do what it should not do;
This is similar to the advantages of single responsibility. When designing interface classes, don't mix them up. Use functional modules for division, etc. for differentiated division.
If the interface assumes too many responsibilities, on the one hand, the implementation class of the interface will be very large, and all the methods defined in the interface will have to be implemented in different implementation classes, which is less flexible. If there are a large number of empty methods, it will lead to A large number of useless codes are generated in the system, which affects the code quality; on the other hand, because the client is programming for a large interface, the encapsulation of the program will be destroyed in a certain program. The client sees methods that should not be seen, and there is no customization for the client. interface.
Six: Principles of Synthesis and Reuse
Try to use object composition instead of inheritance to achieve the purpose of reuse.
When reusing, use composition/aggregation relationship (association relationship) as much as possible, and use less inheritance.
The main problem with reuse through inheritance is that inheritance reuse will destroy the encapsulation of the system, because inheritance will expose the implementation details of the base class to subclasses, because the internal details of the base class are usually visible to subclasses , So this kind of reuse is also called "white box" reuse. If the base class changes, the implementation of the subclass must also change; the implementation inherited from the base class is static and cannot be changed at runtime. , there is not enough flexibility; and inheritance can only be used in limited environments (such as classes that are not declared as not being inherited);
For example:
public class Base{
...wait api
}
public class BaseA{
//By referring to the base object, use the upper method
private Base base;
... and so on baseA specific api;
}
Seven: Demeter's Law
A software entity should interact with other entities as little as possible.
When one of the modules is modified, it will affect other modules as little as possible, and expansion will be relatively easy. This is the limitation of communication between software entities. Dimi Special laws require limiting the breadth and depth of communication between software entities. Dimit's law can reduce the coupling degree of the system and keep the loose coupling relationship between classes.
Extract the public class, each business module interacts with the public class module, this public class module cannot involve too much business level code, only to complete a single function,
When it comes to key points, try not to directly access the business modules directly, call APIs with each other, and facilitate subsequent expansion