An overview,

  • There are seven principles of design patterns
    • Single responsibility principle
    • Interface Isolation Principle
    • Rely on the inversion principle
    • Richter’s substitution principle
    • The open closed principle
    • Demeter’s rule
    • Principle of composite reuse

Single Responsibility Principle

  • That is, a class has only one responsibility. If class A is responsible for two responsibilities, the granularity of class A needs to be decomposed into A1 and A2 to avoid interaction

Iii. Interface Segregation Principle

  • A client should not rely on interfaces it does not need, that is, the dependency of one class on another should be based on the minimal interface. If class A implements interface B and must implement methods it doesn’t need, then this interface represents the smallest interface of class A and interface B should be split.

Iv. Dependence Inversion Principle

  • High-level modules should not depend on low-level modules; both should depend on each other’s abstractions
  • Abstractions should not depend on details, details should depend on abstractions
  • The central idea of dependency inversion is interface oriented programming
  • The dependency inversion principle is based on the design idea that something abstract is much more stable than the polygon of detail. An architecture based on abstraction is much more stable than one based on detail. (Abstract refers to an interface or abstract class; details are concrete implementation classes.)
  • The purpose of using interfaces or abstract classes is to create specifications that do not involve any concrete actions, leaving the task of presenting the details to their implementation classes.
  • Variables are declared as abstract classes or interfaces as possible, so that there is a buffer layer between our variable references and the actual object, which facilitates program expansion and optimization.

5. Liskov Substitution Principle

  • When using inheritance, follow the Richter’s substitution principle and try not to override methods of the parent class in subclasses
  • Inheritance actually makes the two classes more coupled and, where appropriate, can be resolved through aggregation, composition, and dependency

Vi. Open Closed Principle

  • A software entity, such as a class, module, or function, should be open to extension (by providers), closed to modification (by users), framed with abstraction, and extended with implementation details
  • When software needs to change, try to achieve change by extending the behavior of software entities, rather than by modifying existing code to achieve change
  • The purpose of following other principles in programming and using design patterns is to follow the open closed principle

Vii. Demeter Principle

  • One object should have minimal knowledge of other objects
  • The closer the relationship between classes, the greater the coupling degree
  • Also known as the least know principle, a class knows as little as possible about the classes it depends on. That is, for the dependent class, no matter how complex, try to encapsulate the logic inside the class. In addition to what is providedpublicWithout disclosing any information to the public.
  • Friend relationship: Two objects are said to be friends as long as there is a coupling relationship between them
  • Direct friends: Classes that appear in member variables (attributes), method parameters, and method return values are direct friends. Classes in local variables are not direct friends.
  • Demeter’s simpler definition: Correspond only with direct friends. That is, unfamiliar classes should not appear inside the class as local variables.

Reuse Principle

  • Try to use composition/aggregation rather than inheritance

Core ideas of design principles

  • Identify changes that may need to be made in your application and isolate them from code that doesn’t need to be changed
  • Program for interfaces, not implementations
  • Strive for loose coupling design between interacting objects