面向对象的六大原则之 接口隔离原则——ISP

ISP = Interface Segregation Principle

 

ISP的定义以下：

一、客户端不该该依赖他不须要的接口

二、一个类对另一个类的依赖性应该是创建在最小的接口上

三、不该当将不一样的接口合并在一块儿，造成一个臃肿的大接口，这是对接口的污染

四、使用多个专门的接口要比使用单一的总接口要好

 

 

ISP的几个使用原则

一、根据接口隔离原则拆分接口时，首先必须知足单一职责原则： 没有哪一个设计能够十全十美的考虑到全部的设计原则，有些设计原则之间就可能出现冲突，就如同单一职责原则和接口隔离原则，一个考虑的是接口的职责的单一性，一个考虑的是方法设计的专业性(尽量的少)，必然是会出现冲突。在出现冲突时，尽可能以单一职责为主，固然这也要考虑具体的状况。

二、提升高内聚： 提升接口，类，模块的处理能力，减小对外的交互。好比你给杀手提交了一个订单，要求他在一周以内杀一我的，一周后杀手完成了任务，这种不讲条件完成任务的表现就是高内聚。具体来讲就是：要求在接口中尽可能少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变动的风险就越小，也有利于下降成本。

三、定制服务： 单独为一个个体提供优良服务(只提供访问者须要的方法)。

四、接口设计要有限度： 根据经验判断

 

 

接口隔离原则和单一职责原则就是一个硬币的两面，他们说的实际上是一回事。

只是接口隔离原则是站在服务调用者角度看问题，单一职责原则是站在服务提供者的角度看。

 

 

===========================================================================================

契约是怎么回事呢？

契约就是在说两件事，甲方在契约里说我不会多要，乙方会在契约里说我不会少给。

乙方的不会少给是比较容易作到的，由于当一个类实现一个接口的时候，他必需要实现接口里的全部方法。若是你不想实现全部的方法，你留下了抽象方法，那你这个类就是抽象类，不能被实例化，即你不是一个完整的服务提供者。因此说乙方不会少给，是强制性的。

甲方不会多要是软性的规定，他是个设计上的东西，须要咱们用一些设计原则去约束和控制你们写代码。由于编译器是能检测出乙方是否是少给，无法检查出来甲方是否是多要了。

 

那么我怎么知道甲方有没有多要呢？很简单，就看传递给调用者接口类型里，有没有一直没有被调用到的函数成员，若是有，就说明传递进来的接口类型太大了（太胖了），换句话说 胖接口就是这个接口是由两个或两个以上本质不一样的小一点接口合并起来的，把大接口传递进来，只能一部分接口被调用到，另外一部分就多余出来了。

根据胖接口的产生缘由不一样，违反接口隔离原则可能带来的很差的后果基本上有两个：

一、第一种状况，设计的时候有问题，把太多的功能接口包含进来，那其中必然有一部分功能永远用不到，也就天然违反了接口隔离原则。

  咱们看一下实例：

   场景介绍： 一对小情侣，一天女生给男生打电话，告诉他车被追尾了，哭的梨花带雨。小男生情商高，哄小女生说 没关系，明天给你买辆坦克，就不怕追尾了。（前提是小女生不能开炮，只能开~~~~）

 

 

   初版的实现=》小女生只会开汽车，不会开别的

  

#region 车辆接口和实现

    interface IVehicle
    {
        void Run();
    }

    class Car : IVehicle
    {
        public void Run()
        {
            Console.WriteLine("Car is Running");
        }
    }
    class Truck : IVehicle
    {
        public void Run()
        {
            Console.WriteLine("Truck is Running");
        }
    }

    #endregion

  驾驶员类：

class Driver
    {
        private IVehicle _vehicle;
        public Driver(IVehicle vehicle)
        {
            _vehicle = vehicle;
        }
        public void Drive()
        {
            _vehicle.Run();
        }
    }

服务调用方：

   var driver = new Driver(new Car());//开汽车
            driver = new Driver(new Truck());//开卡车
            driver.Drive();

            //这时候你会发现，若是小女生想要开坦克的话，目前是知足不了的
            //由于Driver构造参数传递的是IVehicle接口，不是ITank接口
            //若是想要知足小女生开坦克上街的愿望，就必须改造Driver，传递ITank接口，请看下一个例子

            Console.ReadKey();

  第二版的实现=》小女生能开坦克，可是却不能开汽车了

      

 class Driver
    {
        private ITank _tank;
        public Driver(ITank tank)
        {
            _tank = tank;
        }
        public void Drive()
        {
            _tank.Run();
        }
    }

   var driver = new Driver(new HeavyTank());//开坦克
            driver.Drive();

            // 这时候你会发现， 小女生能开坦克上街了，可是你又会发现，小女生如今只会开坦克了，不会开车了
            // 问题出如今哪里呢？
            // 咱们把一个胖接口(ITank)传递进来,这个胖接口中有一个咱们永远用不到的功能，就是fire。
            // 因此如今这个设计是违反了接口隔离原则
            // 具体改造请看下一个例子

            Console.ReadKey();

 

   第三版的实现=》符合接口隔离原则，小女生能开坦克，也能开汽车了。

#region 车辆接口和实现

    interface IVehicle
    {
        void Run();
    }

    class Car : IVehicle
    {
        public void Run()
        {
            Console.WriteLine("Car is Running");
        }
    }
    class Truck : IVehicle
    {
        public void Run()
        {
            Console.WriteLine("Truck is Running");
        }
    }

    #endregion

interface IWeapon
    {
        void Fire();
    }

  interface ITank:IVehicle,IWeapon
    {
    }
    class LightTank : ITank
    {
        public void Fire()
        {
            Console.WriteLine("Boom!");
        }

        public void Run()
        {
            Console.WriteLine("Ka Ka Ka!");
        }
    }

    class HeavyTank : ITank
    {
        public void Fire()
        {
            Console.WriteLine("Boom!!!!!!!!");
        }

        public void Run()
        {
            Console.WriteLine("Ka!!! Ka!!!! Ka!!!!!!");
        }
    }

驾驶员类：

  class Driver
    {
        private IVehicle _vehicle;
        public Driver(IVehicle vehicle)
        {
            _vehicle = vehicle;
        }
        public void Drive()
        {
            _vehicle.Run();
        }
    }

服务调用方：

      //接口隔离的原则是 服务的调用方不会都要
            //本例子中服务的调用方的需求很简单，这是要求会run,不要求fire
            //所以原先的ITank接口中本身包含的fire和run就符合胖接口的规则，他提供了多余的接口给调用方
            //所以把ITank接口隔离开是对的
            var driver = new Driver(new HeavyTank());//开坦克
            driver.Drive();
            driver = new Driver(new Car());//开汽车
            driver.Drive();


            Console.ReadKey();

 

 第二种状况明天继续，哇哈哈~~~~~~~~~~