面向对象设计之接口隔离原则

面向对象设计原则

接口隔离原则：面向对象设计之接口隔离原则-CSDN博客

设计模式

工厂模式 ： 设计模式之工厂模式-CSDN博客

迭代器模式：设计模式之迭代器模式-CSDN博客

适配器模式：设计模式之适配器模式-CSDN博客

过滤器模式：设计模式之过滤器模式-CSDN博客

单例模式：设计模式之单例模式-CSDN博客

观察者模式：设计模式之观察者模式-CSDN博客

空对象模式：设计模式之空对象模式-CSDN博客

目录

1.引言    

2.接口隔离

3.对接口的污染

---

1.引言    

        面向对象的6大设计原则有：单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则 、迪米特法则、开闭原则，每个原则对我们程序的设计都有很大的指导意义，遵循这些原则，设计出来的程序具有很好的扩展性、复用性和可维护性等。

        下面就接口隔离原则进行详细的探讨。

2.接口隔离

接口隔离原则（Interface Segregation Principle, ISP）表明客户端不应该被强迫实现一些他们不需要的接口，应该把胖接口中的方法分组，然后用多个接口替代它，每个接口服务于一个子模块。简单地说，就是使用多个专门的接口比使用单个接口要好很多。

ISP 的主要观点如下：

1）类之间的依赖关系应当是建立在最小的接口上的。

        ISP 可以达到不强迫客户（接口的使用方法）依赖于他们不用的方法，接口的实现类应该只呈现为单一职责的角色（遵循 SRP 原则） ISP 还可以降低客户之间的相互影响---当某个客户要求提供新的职责（需要变化）而迫使接口发生改变时，影响到其他客户程序的可能性最小。

2）客户端程序不应该依赖它不需要的接口方法（功能）。

        客户端程序就不应该依赖于它不需要的接口方法（功能），那依赖于什么？依赖它所需要的接口。客户端需要什么接口就是提供什么接口，把不需要的接口剔除，这就要求对接口进行细化，保证其纯洁性。

        比如在继承时，由于子类将继承父类中的所有可用方法；而父类中的某些方法，在子类中可能并不需要。例如，普通员工和经理都继承自雇员这个接口，员工需要每天写工作日志，而经理不需要。因此不能用工作日志来卡经理，也就是经理不应该依赖于提交工作日志这个方法。

        可以看出，ISP和SRP在概念上是有一定交叉的。事实上，很多设计模式在概念上都有交叉，甚至你很难判断一段代码属于哪一种设计模式。

        ISP强调的是接口对客户端的承诺越少越好，并且要做到专一。当某个客户程序的要求发生变化，而迫使接口发生改变时，影响到其他客户程序的可能性小。这实际上就是接口污染的问题。

3.对接口的污染

        过于臃肿的接口设计是对接口的污染。所谓的接口污染就是为接口添加不必要的职责，如果开发人员在接口中增加一个新功能的目的只是减少接口实现类的数目，则此设计将导致接口被不断地“污染”并“变胖”。

        “接口隔离”其实就是定制化服务设计的原则。使用接口的多重继承实现对不同的接口的组合，从而对外提供组合功能---达到“按需提供服务”。 接口即要拆，但也不能拆得太细，这就得有个标准，这就是高内聚。接口应该具备一些基本的功能，能独一完成一个基本的任务。

        在实际应用中，会遇到如下问题：比如，我需要一个能适配多种类型数据库的 DAO 实现，那么首先应实现一个数据库操作的接口，其中规定一些数据库操作的基本方法，比如连接数据库、增删改查、关闭数据库等。这是一个最少功能的接口。对于一些 MySQL 中特有的而其他数据库里并不存在的或性质不同的方法，如 PHP 里可能用到的 MySQL 的 pconnect 方法，其他数据库里并不存在和这个方法相同的概念，这个方法也就不应该出现在这个基本的接口里，那这个基本的接口应该有哪些基本的方法呢？PDO已经告诉你了。

        PDO 是一个抽象的数据库接口层，它告诉我们一个基本的数据库操作接口应该实现哪些基本的方法。接口是一个高层次的抽象，所以接口里的方法都应该是通用的、基本的、不易变化的。

        还有一个问题，那些特有的方法应该怎么实现？根据ISP原则，这些方法可以在别一个接口中存在，让这个“异类”同时实现这两个接口。

对于接口的污染，可以考虑这两条处理方式：

• 利用委托分离接口，即has-a关系
• 利用多继承分离接口, 即is-a关系

委托模式中，有两个对象参与处理同一个请求，接受请求的对象将请求委托给另一个对象来处理，如策略模式、代理模式等中都应用到了委托的概念。