依赖倒转原则:
定义:
在大话中最重要的两句话是:抽象不应该依赖与细节,细节应该依赖于抽象。另一句是:针对接口编程,不要对实现编程。
问题:
类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类和添加一个类了。如果我们设计端口,让各种低层模块实现端口,而客户只依赖端口不就行了。在看第二段代码。
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.抽象不应该依赖细节。细节应该依赖抽象。