Dependency Inversion principle

The basic architecture of a program should be an abstraction layer with stable dependencies.

The concrete implementation of the program relies on a stable abstraction layer.

This will ensure the stability and scalability of the program.

http://blog.csdn.net/coolingcoding/article/details/8043265

Dependent on abstraction: the recommendation does not depend on a specific class, that is, all dependencies in a program should terminate in an abstract class or interface.

Hierarchical: All well-structured object-oriented architectures have a clear hierarchical definition, with each level providing a cohesive set of services to the outside through a well-defined, controlled interface.

Full name : "Dependence inversion Principle"

Pros : Using the dependencies created by traditional procedural programming, the policy relies on detail, which is bad because the strategy is affected by the change in detail. The dependency inversion principle makes the detail and strategy dependent on the abstraction, and the stability of the system determines the stability.

How to do dependency inversion?

Coupling in an abstract way is the key to relying on the reversal principle. Abstract coupling relationships always involve concrete classes inheriting from abstract classes, and it is necessary to ensure that any reference to the base class can be converted to its subclasses, so the Richter substitution principle is based on the principle of reversal.

Although coupling at the level of abstraction is flexible, it also brings additional complexity, and if the likelihood of a specific class change is very small, then the benefits of an abstract coupling can be very limited, which can be better with concrete coupling.

Hierarchical: All well-structured object-oriented architectures have a clear hierarchical definition, with each level providing a cohesive set of services to the outside through a well-defined, controlled interface.

Dependent on abstraction: the recommendation does not depend on a specific class, that is, all dependencies in a program should terminate in an abstract class or interface. Try to do the following:

1. Any variable should not hold a pointer or reference to a specific class.

Http://www.cnblogs.com/shaosks/archive/2012/02/07/2341639.html

Dependency Inversion principle

The so-called dependency inversion principle (dependence inversion Principle) is to rely on abstraction and not rely on specifics. The simple thing is to program the abstraction, not to program the implementation, thus reducing the coupling between the customer and the implementation module.

Process-oriented development, the upper layer calls the lower layer, the upper layer depends on the lower layer, when the lower level of drastic changes, the upper layer must follow the change, which will lead to the module reusability and greatly improve the cost of development.

Object-oriented development is a good solution to this problem, the general situation of the abstract change probability is very small, so that the user program depends on the abstraction, the implementation of the details also rely on abstraction. Even if the implementation details change, the client program does not need to change as long as the abstraction is constant. This greatly reduces the degree of coupling of the client program domain implementation details.

Dependency Inversion principle