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

  依赖倒置原则：

 定义：

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

 问题：

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

 

版权声明：本文博主原创文章。博客，未经同意不得转载。