Java设计模式-接口隔离原则

接口隔离原则 【Interface Segregation Principle】

  定义1：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上（Clients should not be forced to depend upon interfaces that they don’t use.）。
  定义2：类间的依赖关系应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。
  问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

  解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

  举例来说明接口隔离原则：

  这个图的意思是：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。程序代码如下：

nterface I {
	public void method1();
	public void method2();
	public void method3();
	public void method4();
	public void method5();
}

class A{
	public void depend1(I i){
		i.method1();
	}
	public void depend2(I i){
		i.method2();
	}
	public void depend3(I i){
		i.method3();
	}
}

class B implements I{
	public void method1() {
		System.out.println("类B实现接口I的方法1");
	}
	public void method2() {
		System.out.println("类B实现接口I的方法2");
	}
	public void method3() {
		System.out.println("类B实现接口I的方法3");
	}
	//对于类B来说，method4和method5不是必需的，但是由于接口A中有这两个方法，
	//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
	public void method4() {}
	public void method5() {}
}

class C{
	public void depend1(I i){
		i.method1();
	}
	public void depend2(I i){
		i.method4();
	}
	public void depend3(I i){
		i.method5();
	}
}

class D implements I{
	public void method1() {
		System.out.println("类D实现接口I的方法1");
	}
	//对于类D来说，method2和method3不是必需的，但是由于接口A中有这两个方法，
	//所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
	public void method2() {}
	public void method3() {}

	public void method4() {
		System.out.println("类D实现接口I的方法4");
	}
	public void method5() {
		System.out.println("类D实现接口I的方法5");
	}
}
public class Test {
    public static void invoker(){
        A a = new A();
        a.depend1(new B());
        a.depend2(new B());
        a.depend3(new B());

        C c = new C();
        c.depend1(new D());
        c.depend2(new D());
        c.depend3(new D());
    }
    public static void main(String[] args) {
        invoker();
    }
}

  可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的设计如图2所示：

程序代码如下：

interface I1 {
	public void method1();
}

interface I2 {
	public void method2();
	public void method3();
}

interface I3 {
	public void method4();
	public void method5();
}

class A{
	public void depend1(I1 i){
		i.method1();
	}
	public void depend2(I2 i){
		i.method2();
	}
	public void depend3(I2 i){
		i.method3();
	}
}

class B implements I1, I2{
	public void method1() {
		System.out.println("类B实现接口I1的方法1");
	}
	public void method2() {
		System.out.println("类B实现接口I2的方法2");
	}
	public void method3() {
		System.out.println("类B实现接口I2的方法3");
	}
}

class C{
	public void depend1(I1 i){
		i.method1();
	}
	public void depend2(I3 i){
		i.method4();
	}
	public void depend3(I3 i){
		i.method5();
	}
}

class D implements I1, I3{
	public void method1() {
		System.out.println("类D实现接口I1的方法1");
	}
	public void method4() {
		System.out.println("类D实现接口I3的方法4");
	}
	public void method5() {
		System.out.println("类D实现接口I3的方法5");
	}
} 

  接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

  说到这里，很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。

  采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口要高内聚。什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互，就比如一个人，你告诉下属“到奥巴马的办公室偷一个XX文件”，然后就听到下属就坚定的口吻回答你“好的，保证完成！”，然后一个月后还真的把XX文件放到你的办公桌了，这种不讲任何条件、立刻完成任务的行为就是高内聚的表现。具体到接口隔离原则就是要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。

• 定制服务。一个系统或系统内的模块之间必然会有耦合，有耦合就要相互访问的接口（并不一定就是Java中定义的Interface，也可能是一个类或者是单纯的数据交换），我们设计时就需要给各个访问者（也就是客户端）定制服务，什么是定制服务？单独为一个个体提供优良优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的定义要采用定制服务，采用定制服务就必然有一个要求就是：只提供访问者需要的方法，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

• 接口尽量小，但是要有限度。接口的设计粒度是越小系统越灵活，这是不争的事实，但是这就带来成接口数量过多，使设计结构的复杂化，开发难度增加，维护性降低，这不是一个项目或产品所期望看到的。所以一定要适度。

  接口隔离原则是对接口的定义也同时是对类的定义，接口和都尽量使用原子接口或原子类来组装，但是这个原子该怎么划分是这个模式也是设计中的一大难题，在实践中应用时可以根据以下几个规则来衡量：
  一个接口只服务于一个子模块或者业务逻辑。

  通过业务逻辑压缩接口中的public方法。接口时常去回顾，尽量做让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法。

  已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。

  了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄，千万别，环境不同的，接口拆分的标准就不同。深入了解的业务逻辑，最好的接口设计就出自的你的手！