依赖倒置原则的结构图 依赖倒置原则的代码实现

图二
看图 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.抽象不应该依赖于具体，具体应该依赖于抽象。

JAVA中什么是依赖倒置原则~

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。

public class HondaCar{ public void Run(){ Console.WriteLine(本田开始启动了); } public void Turn(){ Console.WriteLine(本田开始转弯了); } public void Stop(){ Console.WriteLine(本田开始停车了); }}public class FordCar{ publicvoidRun(){ Console.WriteLine(福特开始启动了); } publicvoidTurn(){ Console.WriteLine(福特开始转弯了); } publicvoidStop(){ Console.WriteLine(福特开始停车了); }}public class AutoSystem{ public enum CarType{ Ford,Honda }; private HondaCar hcar=new HondaCar(); private FordCar fcar=new FordCar(); private CarType type; public AutoSystem(CarType type){ this.type=type; } private void RunCar(){ if(type==CarType.Ford){ fcar.Run(); } else { hcar.Run(); } } private void TurnCar(){ if(type==CarType.Ford){ fcar.Turn(); } else { hcar.Turn(); } } private void StopCar(){ if(type==CarType.Ford){ fcar.Stop(); } else { hcar.Stop(); } }}代码分析：上面的程序确实能够实现针对Ford和Honda车的无人驾驶，但是软件是在不断变化的，软件的需求也在不断的变化。背景2：公司的业务做大了，同时成为了通用、三菱、大众的金牌合作伙伴，于是公司要求该自动驾驶系统也能够安装在这3种公司生产的汽车上。于是我们不得不变动AutoSystem： public class AutoSystem{public enum CarType{Ford,Honda,Bmw};HondaCar hcar=new HondaCar();FordCarf car=new FordCar();BmwCar bcar=new BmwCar();private CarType type;public AutoSystem(CarTypetype){this.type=type;}private void RunCar(){if(type==CarType.Ford){fcar.Run();}else if(type==CarType.Honda){hcar.Run();}else if(type==CarType.Bmw){bcar.Run();}}private void TurnCar(){if(type==CarType.Ford){fcar.Turn();}else if(type==CarType.Honda){hcar.Turn();}else if(type==CarType.Bmw){bcar.Turn();}}private void StopCar(){if(type==CarType.Ford){fcar.Stop();}else if(type==CarType.Honda){hcar.Stop();}else if(type==CarType.Bmw){bcar.Stop();}}}分析：这会给系统增加新的相互依赖。随着时间的推移，越来越多的车种必须加入到AutoSystem中，这个“AutoSystem”模块将会被if/else语句弄得很乱，而且依赖于很多的低层模块，只要低层模块发生变动，AutoSystem就必须跟着变动，它最终将变得僵化、脆弱。导致上面所述问题的一个原因是，含有高层策略的模块，如AutoSystem模块，依赖于它所控制的低层的具体细节的模块（如HondaCar()和FordCar()）。如果我们能够找到一种方法使AutoSystem模块独立于它所控制的具体细节，那么我们就可以自由地复用它了。我们就可以用这个模块来生成其它的程序，使得系统能够用在需要的汽车上。OOD给我们提供了一种机制来实现这种“依赖倒置”。

依赖倒置原则的结构图
答：图二看图 2中这个简单的类图。这儿有一个“AutoSystem”类，它包含一个“ICar”接口。这个“AutoSystem”类根本不依赖于“FordCar”和“HondaCar”。所以，依赖关系被“倒置”了：“AutoSystem”模块依赖于抽象，那些具体的汽车操作也依赖于相同的抽象。于是可以添加ICar public interface ICar{void Run(...

依赖倒置原则的意图
答：面向过程思想的结构图：图一背景1：公司是福特和本田公司的金牌合作伙伴，现要求开发一套自动驾驶系统，只要汽车上安装该系统就可以实现无人驾驶，该系统可以在福特和本田车上使用，只要这两个品牌的汽车使用该系统就能实现自动驾驶。于是有人做出了分析如图一。对于图一分析：我们定义了一个AutoSystem类，...

依赖于抽象,不要依赖于具体是什么原则
答：依赖于抽象,不要依赖于具体是依赖倒置原则。 依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口,不要依赖于具体实现。 依赖倒置原则是程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。 依赖倒置原则 定义: 高...

一文图解23种设计模式和编程规范
答：2. 开放封闭原则: 保持软件的扩展性，但保持内部结构不变。设计时要预见未来的变化，引入抽象以适应可能的演变。3. 里氏替换原则: 子类可以无缝替换父类，保持模块的可扩展性，避免向下耦合。4. 依赖倒置原则: 高层模块依赖抽象，而非具体实现，这样编程时就更专注于接口而非细节。5. 迪米特原则: 降...

依赖倒置原则
答：依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。意图 面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低...

软件工程题目:为了具有良好的程序设计风格,应注意哪些方面的问题?
答：2、里氏替换原则：派生类(子类)对象能够替换其基类(父类)对象被调用。即在程序中，任何调用基类对象实现的功能，都可以调用派生类对象来替换。3、依赖倒置原则：程序设计应该依赖抽象接口，而不应该依赖具体实现。即接口编程思想，接口是稳定的，实现是不稳定的，一旦接口确定，就不应该再进行修改了。根据...

面向对象设计的三个原则
答：面向对象设计的原则是单一职责原则、开放-封闭原则、Liskov替换原则、依赖倒置原则、接口隔离原则。1、单一职责原则。2、开放-封闭原则（对扩展开放；对修改关闭）。3、Liskov替换原则（子类型必须能够完全替换其父类型（继承）；关注行为的替换（多态））。4、依赖倒置原则（依赖抽象；面向接口编程等）。5...

面向对象七大设计原则
答：面向对象设计原则有7个，这7大设计原则包括开闭原则、里氏替换原则、依赖倒转原则、单一职责原则、接口隔离原则、组合/聚合复用原则、迪米特法则。DIP依赖倒置原则抽象不依赖于细节，细节应该依赖抽象。（面向抽象编程，C#为面向接口编程）。ISP接口隔离原则接口属于用户类。特征见下面：抽象就是忽略一个主题中...

什么是依赖倒置原则,和开闭原则有何联系
答：依赖倒置原则要求：高层不应依赖于低层；抽象不应依赖于细节。 开闭原则讲的是：一个软件设计应当对扩展是开放的（Open for extension），但对于修改是封闭的（Closed for modification）。 都是类的设计原则 

设计模式六大原则
答：设计模式六大原则为：单一职责原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则。1、单一职责原则：不要存在多余一个导致类变更的原因，即一个类只负责一个职责。2、开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。3、里氏替换原则：所有引用基类的地方必须能...