Seven principles of design patterns
Overview of design patterns
Design patterns are solutions to common problems in the software design process. It can solve some common problems well.
The ultimate goal of the design pattern is: high cohesion and low coupling
- Code reusability: code with the same function does not need to be written multiple times
- Code readability: standard programming, easy for other programmers to read
- Code scalability: when a new function is added, it has no effect on the original function
Seven Principles
1. Single responsibility principle
As the name implies, the class we designed is responsible for a function as much as possible, so that it is not easy to cause code confusion and avoid some bugs.
Counterexample:
Single class:
public class single{
public static void main(String[] args){
People people = new People;
people.run("老师");
people.run("学生");
people.run("校长");
}
}
People class:
public class People{
void run(String type){
System.out.println(type+"给学生上课");
}
}
This will cause this method to be called by teachers, students, and principals, because People is not only responsible for one function, so there is a problem with the design.
Improve
For the above example, we use the single responsibility principle to rewrite, and divide People into three categories, namely students, teachers, and principals. Let them be responsible for their respective functions so that they do not affect each other. If you want to restrict students, you only need to modify the student class.
optimization
Or you can divide the above People into three methods, each method corresponds to a different person, and the single responsibility falls on the method level instead of the class level
Pros and cons
advantage:
- Reduce the complexity of the class, a class is only responsible for one responsibility
- Improve the readability of the code, the logic is clear
- Reduce the risk, only modify one class, without affecting the functions of other classes
Disadvantages:
- Increased code (single responsibility can be optimized at the method level)
Second, the principle of interface isolation
The class should not rely on unneeded interfaces. The interface should be divided into as small particles as possible. If multiple methods are merged into one interface and then provided to other systems, all methods of the interface must be implemented. Those methods are not needed at all. , Causing confusion for users
Three, rely on the principle of inversion
- High-level modules should not depend on low-level modules, both should depend on interfaces or abstract classes
- Interface-oriented programming
- The principle of dependency inversion is mainly based on the following design concepts: Compared with the variability of details, abstract things are much more stable, and the framework based on abstraction is more stable.
- Abstract refers to the interface or abstract class, and the details refer to the specific implementation class
Counterexample:
- design diagram
[External link image transfer failed. The origin site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-QaVgzavi-1593420283358)(https://raw.githubusercontent.com/iszhonghu/Picture-bed/master/img /20200629150212.png)]
Potato
public class Potato{
public void run(){
System.out.println("买了土豆");
}
}
People class
public class People{
public void bug(Potato potato){
potato.run();
}
}
Test class
public class Test{
public staticvoid main(String[] args){
People people = People();
people.bug(new Potato());
}
}
Improve
In the above counter example, if you don't want to buy potatoes, but want to buy other vegetables, it will be more troublesome and you need to change the People method. This is because the coupling between the modules in the code is too high.
- Improved design drawing
[External link image transfer failed. The origin site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-QuXNMN0h-1593420283360)(https://raw.githubusercontent.com/iszhonghu/Picture-bed/master/img /20200629150342.png)]
In this way, we abstract an interface class from the bottom class, which directly interacts with the high-level, while some low-level classes do not participate, which can reduce coupling and improve stability.
- Vegetables
public interface Vegetables{
public void run();
}
-
Potato
public class Potato implements Vegetables{ public void run(){ System.out.println("买了土豆"); } } -
Tomato type
public class Tomato implements Vegetables{
public void run(){
System.out.println("买了番茄");
}
}
- People class
public class People{
public void bug(Vegetables vegetable){
vegetable.run();
}
}
- Test class
public class Test{
public static void main(String[] args){
People people = new People();
people.bug(new Potato());
people.bug(new Tomato());
}
}
to sum up
The point of this principle is to "reverse", think from the bottom up, and abstract abstract classes and interfaces as much as possible. This example explains very well that "the upper model cannot depend on the underlying module, it should all depend on abstraction".
Fourth, the principle of Richter substitution
Mainly expounds some views on inheritance extend
Advantages of inheritance:
- Improve the reusability of the code, the subclass also has the properties and methods of the parent class
- Improve the scalability of the code, subclasses have their own unique methods
Disadvantages of inheritance:
- When the parent class changes, consider the modification of the subclass
The Richter substitution principle is the basis of inheritance. Only when the subclass replaces the parent class, the software function is still not affected, it means that the parent class is really reused.
Principle 1:
The subclass must implement the abstract method of the parent class, but must not override (override) the non-abstract method of the parent class
Principle 2:
You can add your own unique methods to subclasses.
Principle three;
When a subclass overrides or implements a method of a parent class, the preconditions of the method (that is, the formal parameters of the method) are more relaxed than the input parameters of the parent method.
Five, the principle of opening and closing
The first four principles are to pave the way for the opening and closing principles, which are the most basic and important design principles. The core is the development of extensions, the modification and closure, and in simple terms, the behavior of the extension software is used to achieve changes, not Realized through modification.
Sixth, the Dimit principle
Introduction:
- One object should keep a minimum of knowledge of other objects.
- The closer the relationship between class and class, the greater the degree of coupling
- The less a class knows about the classes it depends on, the better. In other words, no matter how complicated the dependent class is, try to encapsulate the logic inside the class. Except for the public methods provided, no information is disclosed
- There is a simpler definition of Dimit’s Law: only communicate with direct (familiar) friends
Direct (familiar) friends: Every object will have a coupling relationship with other objects. As long as there is a coupling relationship between two objects, we say that the two objects are friends. There are many ways of coupling, such as dependence, association, combination, and aggregation.
Among them, we call the classes that appear in member variables, method parameters, and method return values as direct friends, while classes that appear in local variables are not direct friends. In other words, unfamiliar classes are best not to appear inside the class in the form of local variables.
Seven, the principle of composite reuse
- Try to use composition/collection instead of inheritance
- If you use inheritance, it will strengthen the coupling, try to be the input parameter of the method or the member variable of the class, so as to avoid coupling
At last
- If you feel that you are rewarded after reading, I hope to give me a thumbs up. This will be my biggest motivation for updating. Thank you for your support.
- Welcome everyone to pay attention to my official account [Java Fox], focus on the basic knowledge of java and computer, and ensure that you will gain something after reading it. If you don't believe it, hit my
friend. In other words, unfamiliar classes are best not to appear inside the class in the form of local variables.
Seven, the principle of composite reuse
- Try to use composition/collection instead of inheritance
- If you use inheritance, it will strengthen the coupling, try to be the input parameter of the method or the member variable of the class, so as to avoid coupling
At last
- If you feel that you are rewarded after reading, I hope to give me a thumbs up. This will be my biggest motivation for updating. Thank you for your support.
- Welcome everyone to pay attention to my official account [java Toka Fox], focus on the basic knowledge of java and computer, and ensure that you will get something after reading it. If you don’t believe me, hit me
- If you have different opinions or suggestions after reading, welcome to comment and share. Thank you for your support and love.