Reading Notes 9: Object-oriented Design Principles

Single Responsibility Principle

For a class, there should be only one reason for its change. This is the reason for the change ".

Open and closed Principle

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified. It is open for expansion and closed for changes. The key is abstraction. The general part of a function and the implementation details are clearly separated.

Lee's replacement principle

Child types must replace their basic types.

Dependency inversion principle

Abstraction should not depend on details. Details should depend on abstraction. All dependencies in the program should end with abstract classes and interfaces. Programming for interfaces rather than implementations. No variable should hold a pointer or reference pointing to a specific class. No class should be derived from a specific class. No method should overwrite the implemented methods in any of its base classes.

Dimit Law

If the two classes do not need to communicate with each other, they should not interact directly. If one class needs to call a method of another class, you can forward the call through a third party. The intention is to pay attention to loose coupling in the design.

Interface isolation principle

Customers should not be forced to rely on methods they do not need. An interface belongs to a customer and does not belong to its class hierarchy. Multiple user-oriented interfaces are better than one common interface.

Reuse release Equivalence Principle

The granularity of reuse is the publishing granularity.

Principle of joint Reuse

All classes in a package should be reused together. If a class in the package is reused, all classes in the package must be reused. Classes that are not closely related to each other should not be in the same package.

Principle of mutual Closure

All classes in the package should be closed for changes to the same class nature. If a change affects a package, it will affect all classes in the package, without affecting other packages.

No dependency Principle

The package dependency does not allow loops. Details should not be depended on.

Stable dependency Principle

Dependency in a stable direction. The software (such as the abstract class) designed for the encapsulation system should be put into a stable package. The unstable package should only contain the software (such as the specific class) that may change ).

Stable abstraction principles

The package abstraction level should be consistent with other stability levels. A stable package should also be abstract, and an unstable package should be abstract.

Default abstract principle

An abstract class is introduced between the interface and the class implementing the interface. This class implements most operations of the interface.

Interface Design Principles

Plan an interface instead of implementing an interface.

Black box principle

Multi-purpose class aggregation, less class inheritance.

Do not construct a specific superclass Principle

Avoid maintaining specific superclasses.