面向对象的设计原则三.doc

面向对象的设计原则三 - 接口隔离原则 动机 当我们设计应用程序的时候，如果一个模块包含多个子模块，那么我们应该小心对该模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接 口。但是当我们想要添加一个新的模块扩展程序时，如果要添加的模块只包含原系统中的一些子模块，那么就会强迫我们实现接口中的所有方法，并且还要编写一些 哑方法。这样的接口被称为胖接口或者叫被污染的接口，使用这样的接口将会给系统引入一些不正确的行为。 ? 接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口，应该把胖接口中的方法分组，然后用多个接口代替它，每个接口服务于一个子模块。 ? 接口隔离原则? 不应该强迫客户端依赖于他们不会使用的接口。 ? 实例 下面是一个违反了接口隔离原则的例子。我们使用Manager类代表一个管理工人的管理者。有两种类型的工人：普通的和高效的，这两种工人都需要吃 午饭。现在来了一批机器人，它们同样为公司工作，但是他们不需要吃午饭。一方面Robot类需要实现IWoker接口，因为他们要工作，另一方面，它们又 不需要实现IWorker接口，因为它们不需要吃饭。 ? 在这种情况下IWorker就被认为是一个被污染了的接口。 ? 如果我们保持现在的设计，那么Robot类将被迫实现eat()方法，我们可以写一个哑类它什么也不做（比如说它只用一秒钟的时间吃午饭），但是这 会对程序造成不可预料的结果（例如管理者看到的报表中显示被带走的午餐多于实际的人数）。 ? 根据接口隔离原则，一个灵活的设计不应该包含被污染的接口。对于我们的例子来说，我们应该把IWorker分离成2个接口。 Java代码 //?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();??? ????}?? }?? // 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() { worke