接口隔离原则（The Interface Segregation Principle,ISP）​

概念

• 在针对接口的编程中，接口的设计质量将直接影响系统的设计质量。要设计出内聚的、职责单一的接口也是必须遵循的原则。接口隔离原则即描述了这项设计要求：​“使用多个专门的接口比使用单一的总接口要好。​”
• 更具体来说，就是一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口相当于剧本中的一个角色，而此角色由哪个演员来扮演相当于接口的实现。因此，一个接口应当简单地代表一个角色，而不是多个角色。如果系统涉及多个角色，那么每一个角色都应该由一个特定的接口代表。
• 一个接口代表一个角色，不应当将不同的角色都交给一个接口。
• 一个设计师往往想节省接口的数目，而将看上去类似的接口合并，实际上这是一种错误的做法，这将提供给客户多余的操作，使接口变得臃肿，造成接口污染。而这种接口污染将迫使客户依赖那些他不会使用的操作，从而导致客户程序之间的耦合
• ISP使得接口的职责明确，有利于系统的维护。向客户端提供public接口是一种承诺，应尽量减少这种承诺；而将接口隔离出来，这有利于降低设计成本。

应用分析

考虑某电子商务系统中有关“订单”的设计方案，有3种使用订单的场合：外部用户可以通过门户网站添加订单；公司员工可以通过前台系统查询订单；而管理员则可以通过管理后台进行订单的增、删、改、查等所有维护工作。按照传统的设计方案，首先设计订单访问接口IOrder，该接口提供了订单类对外公布的所有操作，包括查询订单（getOrder）​、添加订单（insertOrder）​、修改订单（modifyOrder）和删除订单（deleteOrder）​，然后定义订单类（Order）来实现这些接口。

由于只为订单类提供了一个“肥”接口IOrder，因此，门户网站、前台系统和管理后台3个外围系统都通过该接口来使用订单类。该设计方案明显违背了ISP，因为门户网站只需要insertOrder，而前台系统也只需要getOrder，但IOrder接口提供了全部行为。客户依赖了他所不需要的接口。

遵循ISP，需要将这单一的总接口分解成多个专门的接口。结合业务需求，为前台系统、门户网站建立专门的接口，从而把getOrder和insertOrder分离出去，形成单独的接口。

该方案为前台系统建立了专门的IOrderForGet接口，为门户网站建立了专门的IOrderForInsert接口。而管理后台需要的管理接口IOrderForAdmin首先继承已有的接口，并添加其他相关的行为。当然，订单类需要同时实现这3个接口。很明显，该方案保证了客户程序只依赖于自己所需的接口，避免了接口污染问题。