Dependency Inversion principle
What is the Dependency Inversion principle of it?
For example the first, with making child car Example:
If the first step is to build cars: inventing the wheel
The second step is: the size of the wheel bottom repairer
The third step is: making the vehicle body according to the size of the bottom
The last step is to: create the car according to the size of the body.
So dependencies this process are: dependent on the automobile body design, body depends on the underbody design, vehicle design depends on the wheel.
Cursory look, this design logic is no problem, all part of the "parts" are dependent on each other, and finally be able to successfully assemble cars, however, there is a big problem this design logic, what is it?
- maintainability
If, now, and you build a car factory customer docking, I now ask for the production of car tires capable of big size, it will have a very serious problem is to re-design of the underbody, body, car, which can He said to be "indeed affect the whole body."
So this time, if we change a way of thinking, to build cars, recycling body, followed by the repairer end, finally inventing the wheel. This way, then, if making cars dependence on reversed, and becomes: wheel depends on the bottom of the vehicle design, vehicle design depends on the body, the body depends on the car's design.
If this time is not change, then the wheels do not need to change a car? ... ah yes, this is a rough look at the past, however, there are still problems ah, if I want to change cars directly? It should not still have all the changes ? Yes, yes, all have to change.
I cite the example above what use is it ah, oh have far-reaching effects; online Baidu a wave, it's Dependency Inversion principle concept is?:
1: layer module should not be dependent on the underlying module, both should depend on its abstract.
2: Abstract should not rely on the specific implementation, the specific implementation should depend abstraction (see the relationship between the interface and implementation class).
The first concept says both dependent on its abstract, the above-made car, whether it is from the beginning of the wheels (bottom) or car (top) start out from the concrete implementation to start, so the above example instead of relying on the principle of reverse .
Its dependence inverted core idea is: oriented programming interface
The next example I build cars in programming said:
First of all, to create four interfaces, namely, wheels, vehicle, car body, car. These four interfaces in their agreed methods, such as wheel interface, the write method with a wheel size argument. Then such as making cars, making the wheels of a car, then write an implementation of this interface implementation class, the class name is a car wheel. If now suddenly there are new demands, we want to build a truck wheel, realized that to write a class to implement the interface to the wheel, in fact, here uses one other principle (the principle of opening and closing: closed for modification, open to extension) the method of interface it is a good agreement before something can not be modified, do not allow here is not really allowed to refer to, but contrary to the principle of opening and closing design principles, a simple and easy to remember way is this: there is the main purpose of the interface is to facilitate the expansion, and maintenance.
In short, the Dependency Inversion principle for interface modules and high-level modules are dependent on the underlying abstract (interface).