六大设计原则详解(4)-接口隔离原则
接口隔离原则(Interface Segregation Principle )，客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
从定义上总结起来，要建立单一的接口，并且接口里的方法越少越好，这里说的接口指的是类接口，也就是Interface关键字定义的接口。
接口隔离原则和单一职责原则的区别：
单一职责原则指的是类、接口和方法的职责是单一的，强调的是职责，也就是说在一个接口里，只要职责是单一的，有10个方法也是可以的。
接口隔离原则指的是在接口中的方法尽量越来越少，接口隔离原则的前提必须先符合单一职责，在单一职责的前提下，接口尽量是单一接口。
下面用实例来说明一下
一.接口臃肿实例
1.首先定义一个接口，声明体育课可以玩的球类
public interface PEclass_Ball { public void PlayBasketball(); public void PlayFootball(); public void PlayVolleyball(); }
2.学生去实现(实现类)
public class Students implements PEclass_Ball { @Override public void PlayBasketball() { System.out.println("可以打篮球"); } @Override public void PlayFootball() { System.out.println("可以踢足球"); } @Override public void PlayVolleyball() { System.out.println("可以打排球"); } @Override public void PlayPlaytabletennis() { System.out.println("可以打乒乓球"); } }
场景中声明了体育课可以玩四种球，现在改变一下，体育课只能打篮球，如果还是按照此接口写的话，其他的三个方法都是空的。代码如下：
public class Students implements PEclass_Ball { @Override public void PlayBasketball() { System.out.println("可以打篮球"); } @Override public void PlayFootball() { } @Override public void PlayVolleyball() { } @Override public void PlayPlaytabletennis() { } }
二.拆分接口实例
给实例1增加一个场景，如果我们体育课，男生只踢足球和打篮球，女生打排球和乒乓球，这种情况我们要拆分接口。
public interface ball_1 { public void PlayBasketball(); public void PlayFootball(); }
public interface ball_2 { public void PlayVolleyball(); public void PlayPlaytabletennis(); }
上面两个实例其实都反应的是一个问题，接口不能太过臃肿，根据接口隔离原则，应该建立单一接口。
总结：
(1). 接口要尽量小。
这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。
根据接口隔离原则拆分接口时，首先必须满足单一职责原则。
(2). 接口要高内聚。
高内聚就是要提高接口、类、模块的处理能力，减少对外的交互。
具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺地越少对系统开发越有利，变更的风险也就越少，同时也有利于降低成本。
(3). 定制服务。
定制服务就是单独为一个个体提供优良的服务。
(4). 接口设计是有限度的。
接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个度只能根据经验和常识判断，没有一个固化或可测量的标准。
最后我想说，一本书，我们看得懂不一定能说出来，能说出来不一定能写出来，多写写一定有收获！
推荐阅读