[设计模式之禅读书笔记]004_设计模式六大原则（四）：接口隔离原则

序言

   不得不说，我又看到一个比较坑爹的原则，因为它又是一个把一个类变两个，两个变四个的原则。在单一职责原则里，我们为了把不同的职责分开，把一个类抽象出了n个接口，本文的接口隔离原则又是一个抽象多接口的原则，我只能对天长叹：我不就是写个类嘛!你打算拆出多少接口出来啊？

   那到底接口隔离原则抽象出来的接口跟单一职责抽象出来的接口有什么关系呢？接口隔离到底是一个什么概念呢？

正文

一、接口隔离的概念

   要理解这个概念，首先，我们理解一下什么是接口。学过java的人，肯定很自然的说出来：interface定义的就是接口。是的，这是其中一种接口，我们叫做类接口。它是对类的抽象。

   那么除了类接口还有其他接口吗？有的，所谓接口就是抽象，interface是对类的抽象，那类又是对谁的抽象呢？对，是对实例的抽象。也即是说，类也是接口，我们叫做实例接口。比如我有一个中国人的类，它是对中国人的抽象，它有吃皮鞋、喝毒奶的成员函数，而且有定义体，中国人这个类就是实例接口。如果你非跟我抬杠，说中国人这个类是对安徽人这个类的抽象，我表示比较无语，哈哈！现在有一个代表人类的类，它是对地球上所有人类的抽象，也是对中国人这个类的抽象，它有吃饭这个成员函数。这就是一个类接口。

   然后，我们再理解一下什么是隔离。隔离的核心比较扯淡——成员方法尽可能的少。这是个什么意思呢？单一职责原则要求我们从职责的角度，即业务的角度来抽象我们的接口，细分我们的接口。本次的接口隔离原则则是从代码角度来细分接口的。我们从单一职责细分的接口虽然具有单一职责了，但是有时我们会发现，即使应用了单一职责原则了，接口里面还有很多很多的方法，这时候就需要我们的接口隔离原则出场了。

二、 接口隔离原则和单一职责原则的联系

   单一职责原则是从业务角度上来对类进行接口的抽象和细分，而接口隔离原则是从代码角度来对接口进行细分。因为单一职责原则得到的接口可能比较庞大，这就需要我们进行接口隔离原则的实施了。

三、接口隔离原则的规范约束的四层含义

   接口隔离原则是对接口进行规范约束的，它有以下四层含义。

   1. 接口要尽量小

       接口要尽量小，这一点很显然的，如果接口有100个方法，那我每次继承这个接口的时候，我就要实现这100个方法，那不累死啊，况且这100个方法我肯定不可能全用到的。臃肿的接口是我们一定要避免的。但是在细化的时候，我们不能太小，你说我把100个方法放到100个接口里面，老板不抽死你，继承你接口的人也会拿着鼠标砸你头的。

   2. 接口要高内聚

       这一点也是对上一点的要求了，就是细化接口的时候，要做到高内聚，什么叫高内聚呢？这个概念可能很多人都听过，但是没有仔细去想这个高内聚到底是什么含义。我个人也没有一个好的定义，不过能意会，咱就不言传了。

   3. 定制服务

       这个概念看起来比较高深，不知道是不是作者故作高深的，所谓的定制服务就是为调用者提供且只提供他需要的方法。怎样做到只提供呢？也很简单，拆呗！

   4. 接口设计是有限度的

       这个就是废话，浪费笔墨。接口设计当然是要有限度的，不过作者估计是想提醒我们吧！接口设计是需要经验的，就好比煮饭，到底放多少水，只有煮过饭的人才知道，放离米2cm就可以之类的。

总结

   接口隔离原则还是挺简单的，注意它与单一职责原则的区分即可。即前者是代码层面，后者是业务层面。

   不知道理解有没有偏驳的地方，还请指摘。