OCP (Open-Closed Princi) opening and closing principle
Its core meaning is that a good design should be able to accommodate the increase in new features, but the increased mode is not done by adding an existing module (class), but is done by adding new modules (classes).
We want to program multiple interfaces. Open to the modification and open it.
SRP (Single Responsibility Princi)
Single job principle
The core meaning of this principle is that a class should have only one responsibility. With regard to the meaning of the responsibility, there is a famous definition for object-oriented master Robert.c Martin: the so-called class responsibility is the reason for this class, if a class has more than one responsibility, then there is a number of different reasons The variation of this class is actually coupled to multiple mutually disconnected responsibilities, which reduces the cohesiveness of this class.
In fact, I feel that
Guiding principles emphasized in Domain Driven Design:
Conceptual DepENDENCY has a communication. The description given in Conceptual DepENDENCY, the object of the service responsibility layer needs to be fully integrated through the next object, and the opposite side object can be independent of the upper object. Such natural lower objects are more stable for the upper object. And in the process of future evolution, the same way to improve the system, rather than changing the object.
DIP (Dependency Injection Principle) Dependent Injection Principle
The core meaning of this principle is that the high-level module should not depend directly on the underlying module, and all modules must depend on abstraction. That is to say, things that are easy to change must depend on things that are not easy to change, because abstract things are not easier to change, and the specific things are easy to change, so they should depend on abstraction.
The existing open source frameworks such as SpringFramework and PicoContainer have implemented IOC (Inversion of Control), Margin Flower more likes to call DIP.
. . . . . .
