设计模式依靠大话反向原则

依赖倒置原则：

定义：

在大话中最重要的两句话是：抽象不应该依赖与细节，细节应该依赖于抽象。还有一句是：针对接口编程。不要对实现编程。

问题：

类A直接依赖类B，假如要将类A改为依赖C。则必须通过须要改动类A的代码来达成，但假设，类A是高级模块，负责业务逻辑；类B和类C是低层模块，负责主要的源自操作，这样改变A会给程序带来不必要的风险。

解决方式：

将类A改动为依赖接口I，类B和类C各自实现接口I，类A通过接口I来与类B和C发生纤细，则会大大减少改动A的几率。

基本思想：

用抽象构建框架，用事先扩展细节，相对于细节的多边性，抽象的东西要稳定的多。

详细的样例：

场景：客户去商场买东西，要买水果。买的东西是低层模块，客户是高层模块。它决定了要买什么。

class FoodA //低层的实现
{
public string Take()
{
return "水果";
}
}
class Client
{
public void client(FoodA a)
{
Console.WriteLine("我想要");
Console.WriteLine(a.Take());
}
}
class Program
{
static void Main(string[] args)
{
Client client = new Client();
client.client(new FoodA());
}
}

上述这样做是没有问题的，可是假设客户想要买其他的东西呢？这时候。我们可能就会想要在建一个类。让客户依赖它。这时候，就要改动Client类和加入一个类了。

假设我们设计port，让各种低层模块实现port，而客户仅仅依赖port不即可了。

在看第二段代码。

interface IFood//体现抽象
{
string take();
}
class FoodA : IFood //让低层的模块实现接口
{
public string take()
{
return "水果";
}
}
class FoodB : IFood
{
public string take()
{
return "蔬菜";
}
}

class Client
{
public void client(IFood ifood)//高级模块依赖接口
{
Console.WriteLine("我想要");
Console.WriteLine(ifood.take());
}
}
class program
{
static void Main(string[] args)
{
Client client = new Client();
client.client(new FoodA());//实现接口
client.client(new FoodB());
}
}

这样是不是科扩展性就非常棒了。当然这是横向扩展。纵向是。我们能够加入另外一个类：销售员，让销售员类依赖接口即可了。

依赖倒转原则中心思想：

A.高层模块不应该依赖低层模块，两个都应该依赖抽象。

B.抽象不应该依赖细节。细节应该依赖抽象。