Six principles of design pattern: How the boss relieves the burden--dependence inversion principle

Many startups have declared "flat management", what is "flat management"? Take a look at this architecture diagram below:

Because fewer people, the boss directly manage the procurement, sales, manpower and IT personnel, although tired point, but the Department of less, not many people are also OK.

But with the development of the company, every time the new staff to join the boss to know, communication, problems have to go out to drink a tea, the boss found their time wasted in these trifles, easy to delay things not to say, but also play no greater value.

At this time he decided to recruit some managers for their own management of the various departments, as long as they manage the managers are good.

So the new architecture diagram is this:

Boss This is much more worry, there are problems directly to find the department manager just fine. As to which department has the new person, or the employee does not have the good job dismissal, he does not have to worry about.

In traditional software development, class A directly depends on class B, if you want to change Class A to dependency Class C, you must modify the code of Class A to achieve. In this scenario, Class A is typically a high-level module that is responsible for complex business logic, and Class B and Class C are low-layer modules that are responsible for basic atomic operations, and if Class A is modified, it poses unnecessary risks to the program. Reference from here This corresponds to the beginning of the start of the company's "flat", the boss is a high-level class A, high-level once the specific dependence on the lower layer in the future when the high-level changes need to be modified, which is very class, but also prone to error.

And the boss can relieve the burden, it is Dependency Inversion principle's role.

High-level modules should not rely on specific underlying modules, two should be dependent on the interface. In short, it is interface-oriented programming, not a concrete implementation.
Any variable should not hold a pointer or reference to a specific class.

In actual programming, we generally need to do the following 3 points:

1. The low-level module should have an abstract class or interface as much as possible, or both.
2. The declaration type of a variable is as abstract a class or interface as possible.
3. Follow the Richter substitution principle when using inheritance.

There are three ways to implement dependency inversion

1. Passing a dependent object through a constructor function;
   For example, the arguments that need to be passed in the constructor are implemented in the form of an abstract class or interface.
2. Passing dependent objects through setter method;
   That is, the arguments in the Setxxx method we set are abstract classes or interfaces that implement transitive dependent objects.
3. The interface declaration implements the dependent object, also called the interface injection;
   That is, in the function declaration, the argument is an abstract class or interface, which implements the transitive dependent object, thus achieving the purpose of directly using the dependent object.

The core of the dependency inversion principle is that we can interface-oriented programming, understand the interface-oriented programming, and understand the dependency inversion. Thank

"Big Talk design mode"
http://blog.csdn.net/imyfriend/article/details/7465596
http://blog.csdn.net/zhengzhb/article/details/7289269

Six principles of design pattern: How the boss relieves the burden--dependence inversion principle