设计模式依赖与物理功能依赖的区分---依赖倒转原则DIP

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。高层模块不直接依赖低层的实现，而是依赖于底层模块的抽象。但是抽象接口不是通过底层模块的来实现吗，应该是抽象接口依赖于底层模块呀！这是怎么回事呢？

区分设计模块上的依赖与物理功能上的依赖的语义不同

现实中抽象模块功能是通过低层模块实现的（继承实现），但从依赖关系上讲是低层模块依赖于抽象模块，因为父类或接口类是上层建筑，是低层模块的“父辈依赖”，要区分继承和实现与依赖语义的不同。通俗讲，子类继承父类，当然是子类依赖父类，虽然实际上父类的抽象接口或方法“依赖”于子类来实现，但此处“依赖”实际是“依靠，通过”xx功能来实现之意，设计模式的依赖语义是类层次上的，不是物理世界的“利用，通过”功能的含义，要避免混淆。

举个例子，（使用无刷电机的）研磨机功能依赖电机控制接口来实现，但具体无刷电机驱动是依赖于电机控制接口的，电机控制接口的功能在这个程序中是依靠无刷电机驱动来实现的。未来如果我们更换成串激电机，则只需要更换成串激电机驱动来实现电机控制接口就可以了。而研磨功能（客户）层与电机接口层是无需变更的，这就实现了“高层模块不应该直接依赖于底层模块的具体实现”（注意不要想成“高层模块不依赖底层模块实现他的功能”，物理世界本来就只能是研磨机功能通过电机驱动来实现，这是无法变更的，但利用设计模块我们能实现是软件设计上将这种直接关系解耦）