面向对象的设计原则三 - 接口隔离原则

动机

当我们设计应用程序的时候，如果一个模块包含多个子模块，那么我们应该小心对该模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接口。但是当我们想要添加一个新的模块扩展程序时，如果要添加的模块只包含原系统中的一些子模块，那么就会强迫我们实现接口中的所有方法，并且还要编写一些哑方法。这样的接口被称为胖接口或者叫被污染的接口，使用这样的接口将会给系统引入一些不正确的行为。

 

接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口，应该把胖接口中的方法分组，然后用多个接口代替它，每个接口服务于一个子模块。

 

接口隔离原则 

不应该强迫客户端依赖于他们不会使用的接口。

 

实例

下面是一个违反了接口隔离原则的例子。我们使用Manager类代表一个管理工人的管理者。有两种类型的工人：普通的和高效的，这两种工人都需要吃午饭。现在来了一批机器人，它们同样为公司工作，但是他们不需要吃午饭。一方面Robot类需要实现IWoker接口，因为他们要工作，另一方面，它们又不需要实现IWorker接口，因为它们不需要吃饭。

 

在这种情况下IWorker就被认为是一个被污染了的接口。

 

如果我们保持现在的设计，那么Robot类将被迫实现eat()方法，我们可以写一个哑类它什么也不做（比如说它只用一秒钟的时间吃午饭），但是这会对程序造成不可预料的结果（例如管理者看到的报表中显示被带走的午餐多于实际的人数）。

 

根据接口隔离原则，一个灵活的设计不应该包含被污染的接口。对于我们的例子来说，我们应该把IWorker分离成2个接口。

// interface segregation principle - bad example interface IWorker { public void work(); public void eat(); } class Worker implements IWorker { public void work() { // ....working } public void eat() { // ...... eating in launch break } } class SuperWorker implements IWorker{ public void work() { //.... working much more } public void eat() { //.... eating in launch break } } class Manager { IWorker worker; public void setWorker(IWorker w) { worker=w; } public void manage() { worker.work(); } }

 

下面是遵循接口隔离原则的代码。通过把IWorker分离成两个接口，Robot类不需要再被强迫实现eat()方法。如果我们需要为Robot类添加其他的功能，例如重新充电，我们可以创建一个新的IRechargeable接口，其中包含一个重新充电的方法recharge。

//interface segregation principle - good example interface IWorkable { public void work(); } interface IFeedable{ public void eat(); } class Worker implements IWorkable, IFeedable { public void work() { // ....working } public void eat() { //.... eating in launch break } } class SuperWorker implements IWorkable, IFeedable{ public void work() { //.... working much more } public void eat() { //.... eating in launch break } } class Robot implements IWorkable{ public void work() { // ....working } } class Manager { IWorkable worker; public void setWorker(IWorkable w) { worker = w; } public void manage() { worker.work(); } }

 

总结

如果已经设计成了胖接口，可以使用适配器模式隔离它。

像其他设计原则一样，接口隔离原则需要额外的时间和努力，并且会增加代码的复杂性，但是可以产生更灵活的设计。如果我们过度的使用它将会产生大量的包含单一方法的接口，所以需要根据经验并且识别出那些将来需要扩展的代码来使用它。