Study notes on the seven principles of design patterns

• The seven principles are:
  – Single responsibility principle
  – Interface isolation principle
  – Dependency reversal principle
  – Richter substitution principle
  – Open and close principle
  – Dimit’s rule
  – Composite reuse principle
• Single Responsibility Principle: That is, a class is only responsible for one responsibility. If class A is responsible for two responsibilities, in order to avoid mutual influence, the granularity of class A needs to be decomposed into A1, A2
• Interface Segregation Principle (Interface Segregation Principle): The client should not rely on interfaces it does not need, that is, the dependence of one class on another should be based on the smallest interface. If class A implements interface B and must implement methods that it does not need, it means that this interface represents the smallest interface of class A and interface B should be split.
• Dependence Inversion Principle
  -High-level modules should not depend on low-level modules, and both should rely on each other's abstraction
  -Abstraction should not depend on details, and details should depend on abstraction
  -The central idea of ​​dependency inversion is interface
  - oriented programming - Dependence Inversion Principle It is based on the design concept: Compared with the multilateral nature of details, abstract things are much more stable. Architecture based on abstraction is much more stable than architecture based on details. (Abstraction refers to the interface or abstract class, and the details are the specific implementation class)
  -The purpose of using the interface or abstract class is to formulate a good specification without involving any specific operations, and delegate the task of showing the details to their implementation class to complete .
  – The declaration type of the variable should be an abstract class or interface as much as possible, so that there is a buffer layer between our variable reference and the actual object, which is conducive to program expansion and optimization.
• Liskov Substitution Principle
  -When using inheritance, follow the Liskov Substitution Principle , and try not to override the method of the parent class in the subclass
  -Inheritance actually enhances the coupling of the two classes, where appropriate Next, problems can be solved through aggregation, combination, and dependency
• Open Closed Principle
  -A software entity, such as classes, modules, and functions, should be open for extension (by the provider), closed for modification (by the user), use abstraction to build the framework, and use implementation to extend the details
  – When the software needs to change, try to achieve the change by expanding the behavior of the software entity, rather than by modifying the existing code to achieve change.
  – Follow other principles in programming, and the purpose of using design patterns is to follow the principle of opening and closing
• Demeter Principle
  -An object should have the least knowledge of other objects-
  the closer the relationship between the class and the class, the greater the coupling
  -also called the Least Knowing Principle, that is, the less a class knows about the classes it depends on The better. That is, no matter how complicated the dependent class is, try to encapsulate the logic inside the class. Except for the publicmethods provided, no external information will be disclosed.
  – Friendship: As long as there is a coupling relationship between two objects, we will say that the two objects are a friend relationship
  – Direct friend: The class that appears in member variables (that is, attributes), method parameters, and method return values ​​is direct Friends, and classes in local variables are not direct friends.
  – Dimit's simpler definition: only communicate with direct friends. That is, unfamiliar classes are best not to appear inside the class in the form of local variables.
• Composite Reuse Principle: Try to use composite/aggregation instead of inheritance
• The core idea of ​​the design principle
  -find out where changes may be needed in the application, separate them, and don't mix them with the code that does not need to change
  -for interface programming, not for implementation programming
  -for loose coupling design between interactive objects And work hard