图二
看图 2中这个简单的类图。这儿有一个“AutoSystem”类，它包含一个“ICar”接口。这个“AutoSystem”类根本不依赖于“FordCar”和“HondaCar”。所以，依赖关系被“倒置”了：“AutoSystem”模块依赖于抽象，那些具体的汽车操作也依赖于相同的抽象。
于是可以添加ICar public interface ICar{void Run();void Turn();void Stop();}public class BmwCar:ICar{public void Run(){Console.WriteLine(宝马开始启动了);}public void Turn(){Console.WriteLine(宝马开始转弯了);}public void Stop(){Console.WriteLine(宝马开始停车了);}}public class FordCar:ICar{publicvoidRun(){Console.WriteLine(福特开始启动了);}public void Turn(){Console.WriteLine(福特开始转弯了);}public void Stop(){Console.WriteLine(福特开始停车了);}}public class HondaCar:ICar{publicvoidRun(){Console.WriteLine(本田开始启动了);}public void Turn(){Console.WriteLine(本田开始转弯了);}public void Stop(){Console.WriteLine(本田开始停车了);}}public class AutoSystem{private ICar icar;public AutoSystem(ICar icar){this.icar=icar;}private void RunCar(){icar.Run();}private void TurnCar(){icar.Turn();}private void StopCar(){icar.Stop();}}现在AutoSystem系统依赖于ICar 这个抽象，而与具体的实现细节HondaCar、FordCar、BmwCar无关，所以实现细节的变化不会影响AutoSystem。对于实现细节只要实现ICar 即可，即实现细节依赖于ICar 抽象。
综上：
一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高
层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过子程序库的形式，我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。
总结：依赖倒置原则
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体，具体应该依赖于抽象。
