[置顶] 大话设计模式之依赖倒转原则

  依赖倒转原则：

 定义：

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

 问题：

 类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.抽象不应该依赖细节。细节应该依赖抽象。