接口隔离原则(ＩＳＰ）

ISP用来处理fat接口的缺点.

1. 如果类的接口不是内聚的,那么该类就具有fat接口.
2. fat接口可以分解为多个组.每个组服务于不同的客户.
3. ISP承认不需要内聚接口的对象.但是建议客户不应该看到它作为单一的类而存在.
4. 客户程序看到的应该是多个具有内聚接口的抽象基类.

• 接口污染.
  1. 
• 分离客户就是分离接口.
  1. 客户对接口施加的反作用力.
  2. 考虑引起变化的作用力时,通常考虑的是接口的变化会怎么影响它的使用者.
  3. 但有时候,迫使接口改变的,正是它的使用者.
• ISP:不应该强迫客户依赖于它们不使用的方法.
  • 这样会导致所有客户程序间的耦合.
  • 一个客户依赖于一个它不使用的方法的类.但是其他客户却要使用该方法.
  • 此时,当其它客户要求这个类改变时,会影响到第一个客户.这样加剧了更改的附加风险.
• 类接口与对象接口．
  • 一个对象的客户不是必须通过该对象的接口去访问它，也可以通过委托或者该对象的基类来访问它．
  • 
• 

• 多参数与单参数形式．
  • void g(DepositUI,TransferUI);/void g(UI);
  • 首先,因为两个参数引用的是同一个对象,加上多参数的调用形式为g(ui,ui).直觉上可能倾向于单参数.
  • 但是,单参数迫使g函数依赖于UI实现的所有的接口.譬如当与g函数无关的withdrawUI接口变化时,g函数和其所有客户都需要联动更新.
• 对客户进行分组
  • 可以根据客户所调用的服务方法来对客户进行分组,这样可以为每组而不是每个客户创建分离的接口.
  • 这样,减少了服务需要实现的接口数量;也避免了让服务依赖于每个客户类型.
  • 有时,不同客户组调用的方法会有重叠,如果重叠较少,那么组的接口应该保持分离.公共方法应该在所有重叠的接口中声明,同时服务者类继承了所有的公共方法,但是只会实现它们一次.
• 改变接口
• 维护时,会改变现有的类和组件的接口.造成了系统的大部分需要重新编译和部署.
• 可以通过为现有的对象增加新的接口来缓解,而不是去改变现有的接口.
• 原有接口的客户访问新接口的方法时,可以通过is来查询该新接口.
• 不能过度使用,当一个类实现了过多的接口.而这些接口的分类方式还不同(根据版本,根据客户程序).此类是难以维护的.

总结. fat类导致它的客户程序之间参数了有害的耦合关系.

当一个客户要求胖类改动时,会影响到其他的客户.

客户应该仅仅依赖它们实际需要调用的方法.

通过将胖类的接口分解为多个特定于客户的接口来解决.