Six Design Principles of Design Patterns

Six Design Principles of Design Patterns

• Single Responsibility Principle (Single Responsibility Principle - SRP)
  There is one and only one reason for class changes. That is, a class is only responsible for one responsibility.
  • class complexity reduction
  • Improved readability
  • Improved maintainability
  • Risk reduction due to change
• Liskov Substitution Principle (LSP)
  Subclass can extend the function of the parent class, but cannot change the original function of the parent class.
  • Subclasses can implement abstract methods of superclass, but cannot override non-abstract methods of superclass
  • Subclasses can add their own unique methods
  • When the method of the subclass overrides the method of the superclass, the preconditions of the method (that is, the formal parameters of the method) are more relaxed than the input parameters of the superclass method
  • When the method of the subclass implements the abstract method of the superclass, the post-condition of the method (that is, the return value of the method) is stricter than the classification
• Dependence Inversion Principle:
  High-level modules should not depend on low-level modules, both should depend on their abstractions; abstractions should not depend on details; details should depend on abstractions. The core is interface-oriented programming.
  • Low-level modules should have abstract classes or interfaces as much as possible, or both
  • The declared type of the variable should be an abstract class or interface as much as possible
  • Follow the Liskov Substitution Principle when using inheritance
• Interface Segregation Principle (Interface Segregation Principle)
  A client should not depend on interfaces it does not need; dependencies of one class on another should be built on the smallest interface.
  • The interface should be as small as possible. When splitting an interface according to the interface segregation principle, the single responsibility principle must first be satisfied.
  • Interfaces should be highly cohesive. Improve the processing capabilities of interfaces, classes, and modules, and reduce external interactions.
  • Customized service. Only the methods it needs are exposed to the calling class, and the methods it doesn't need are hidden. Minimal dependencies can only be established by focusing on providing custom services for one module.
  • Interface design is limited. The smaller the design granularity of the interface, the more flexible the system is. This is an indisputable fact, but this will lead to the complexity of the structure, the increase of development difficulty, and the reduction of maintenance, so it must be moderate. Interfaces and classes are assembled using atomic interfaces or atomic classes as much as possible.
    • Atomic partition rules:
      • An interface only serves one submodule or business logic
      • Compress public methods in interfaces by business logic
      • If the interface has been polluted, try to modify it as much as possible. If the risk of change is high, use the adapter mode for conversion processing.
      • Understand the environment and refuse to follow blindly. Different environments have different standards for interface splitting. Only by deeply understanding business logic can better design atoms
• Law of Demeter (Low Of Demeter)
  An object should keep the least knowledge about other objects. The Law of Demeter is also called the Least Knowledge Principle (LKP). The less a class knows about the classes it depends on, the better. In fact, it is to achieve high cohesion and low coupling of classes.
  • Only communicate with direct friends. Classes appearing in member variables, method parameters, and method return values ​​are direct friends.
  • There is also a distance between friends. Dimit's legal system requires classes to be "stingy", try not to publish too many public methods and non-static public variables, try to be restrained, and use more access rights such as private, package-private, and protected.
• Open Close Principle
  Classes, modules and functions should be open for extension and closed for modification. Build frameworks with abstractions and extend details with implementations.
• Summarize
  • Single Responsibility Principle: Implementing classes should have a single responsibility
  • The Liskov Substitution Principle: Don't Break the Inheritance System
  • Dependency Inversion Principle: Interface-Oriented Programming
  • Interface isolation principle: design interfaces to be streamlined and single
  • Demeter Law: To reduce coupling
  • Open-closed principle: open for extension, closed for modification