https://baike.baidu.com/item/依赖倒置原则
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();
}
}
}
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();
}
}
}
https://zh.wikipedia.org/wiki/依赖反转原则
应用依赖反转原则同样被认为是应用了适配器模式，例如：高层的类定义了它自己的适配器接口（高层类所依赖的抽象接口）。被适配的对象同样依赖于适配器接口的抽象（这是当然的，因为它实现了这个接口），同时它的实现则可以使用它自身所在低层模块的代码。通过这种方式，高层组件则不依赖于低层组件，因为它（高层组件）仅间接的通过调用适配器接口多态方法使用了低层组件，而这些多态方法则是由被适配对象以及它的低层模块所实现的。
Dependency inversion principle - Wikipedia https://en.wikipedia.org/wiki/Dependency_inversion_principle
In object-oriented design, the dependency inversion principle is a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:[1]
- High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
- Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.[2]
The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface.
In many cases, thinking about the interaction in itself as an abstract concept allows the coupling of the components to be reduced without introducing additional coding patterns, allowing only a lighter and less implementation-dependent interaction schema.
When the discovered abstract interaction schema(s) between two modules is/are generic and generalization makes sense, this design principle also leads to the following dependency inversion coding pattern.
Generalization restrictions[edit]
The presence of interfaces to accomplish the Dependency Inversion Pattern (DIP) has other design implications in an object-oriented program:
- All member variables in a class must be interfaces or abstracts.
- All concrete class packages must connect only through interface or abstract class packages.
- No class should derive from a concrete class.
- No method should override an implemented method.[1]
- All variable instantiation requires the implementation of a creational pattern such as the factory method or the factory pattern, or the use of a dependency-injection framework.