设计模式之接口隔离原则

　　What

　　Interface Segregation Principle(ISP)：客户端不应该依赖它不需要的接口；类间的依赖关系应该建立在最小的接口上

　　Why

　　“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

　　How

　　现在有一个接口，作用是编写一个网站，其中有两个方法

    interface IWriteWebsite
    {
        //实现UI
        void WriteWebsiteUI();
        //实现逻辑代码
        void WriteWebsiteLogic();
    }

　　经验丰富的程序员类，可以单独完成开发网站的任务

  //经验丰富的程序员
    class ExperiencedProgrammer : IWriteWebsite
    {
        public void WriteWebsiteUI()
        {
            Console.WriteLine("实现界面");
        }

        public void WriteWebsiteLogic()
        {
            Console.WriteLine("实现后台逻辑");
        }
    }

　　但是我们会发现，有一些经验不是那么丰富的程序员只能完成一个方向的工作，可能是界面方向也可能是后台方向，那么我们如果实现原有的编写网站的接口，那部分他不会的技能就不能实现，那么这样一来就违反了单一职责原则以及里氏替换原则，所以我们可以将编写网站的接口拆分成IWriteWebsiteUI及IWriteWebsiteLogic两个接口，这样的话，经验丰富的程序员实现这两个接口，而对应方向的程序员实现各自的接口就可以了。这样在接口的复用上，也达到了想要的效果。

　　编写网站逻辑接口

  interface IWriteWebsiteLogic
    {
        void WriteLogic();
    }

　　编写网站界面接口

   interface IWriteWebsiteUI
    {
        void WriteUI();
    }

　　编写逻辑的程序员类

   class LogicProgrammer : IWriteWebsiteLogic
    {
        public void WriteLogic()
        {
            Console.WriteLine("实现后台逻辑");
        }
    }

　　编写界面的程序员类

    class UIProgrammer : IWriteWebsiteUI
    {
        public void WriteUI()
        {
            Console.WriteLine("实现界面");
        }
    }

　　经验丰富的程序员类

    class ExperiencedProgrammer : IWriteWebsiteLogic, IWriteWebsiteUI
    {
        public void WriteLogic()
        {
            Console.WriteLine("实现后台逻辑");
        }

        public void WriteUI()
        {
            Console.WriteLine("实现界面");
        }
    }

　　当然上面只是一个简单的示例，其中有很多的东西都没有加入，比如抽象的程序员类，而这个类应该具有可演示的工作结果等等。这里是为了演示一下相关的臃肿接口拆开之后带来的好处。当细粒度减小之后，复用性就提高了；类也不需要实现不合适的接口而造成承担不需要承担的行为，也不存在违反LSP或者SRP。

 

　　单一职责原则同接口隔离原则的异同：相似之处都是起到了瘦身的作用，减少耦合性；不同的地方当然是职责是一种能力，可能可以处理某一样事物需要很多个接口。接口跟职能还是有差别的。