Dependency Inversion Principle (DIP)

  • High-level modules (stable) should not depend on lower-level modules (transformations), both should depend on abstractions (stable)
  • The abstraction (stability) should not depend on the implementation details (change). The implementation details should depend on the abstraction (stability).

The open closed principle

  • Open for extension, closed for change
  • Class modules should be extensible, but not modifiable

Single Responsibility Principle

  • A class should have only one reason for its change
  • The direction of change implies responsibility for the class

Liskov Substitution Principle (LSP)

  • Subclasses must be able to replace their base class (IS-A)
  • Inheritance expresses type abstraction

Interface Isolation Principle (ISP)

  • Clients should not be forced to rely on methods they do not use
  • The interface should be small and complete

Use object composition in preference to class inheritance

  • Class inheritance is usually “white box multiplexing” and object composition is usually “black box multiplexing”
  • Inheritance breaks encapsulation to some extent, and the coupling degree of subclass and superclass is high
  • Object composition, on the other hand, only requires that the object to be composed have a well-defined interface with low coupling

Package change point

  • Using encapsulation to create hierarchies between objects allows designers to make changes on one side of the decomposition point without adversely affecting the other, resulting in coupling

Program to interfaces, not implementations

  • The variable type is not declared as a particular concrete class, but as an interface
  • The client does not need to know the specific type of the object, just the interface that the object has
  • Reduce the dependence of each part of the system, so as to achieve “high cohesion, loose coupling” type design scheme

Key techniques for refactoring

  • Static -> dynamic
  • Early binding -> late binding
  • Inherit-> combination
  • Compile-time dependencies -> run time dependencies
  • Tight coupling -> loose coupling