接口隔離原則（The Interface Segregation Interface）

?

????????這個原則用來處理“胖（fat）”接口（類的接口不是內(nèi)聚的）所具有的缺點。“胖”接口可以分解成多組方法。

考慮一個安全系統(tǒng)，有一些Door對象，可以被加鎖和解鎖，并且Door對象知道自己開關狀態(tài)。

public interface Door {public void lock();public void unlock();public boolean isOpen(); }

考慮一個這樣的實現(xiàn)，TimedDoor 如果門開著的時間過長，它就會發(fā)出警報聲。為了做到這一點，TimedDoor 對象需要和另一個名為Timer 的對象交互。

public interface Timer {// 注冊超時服務public void register(int timeout, TimerClient client); }public interface TimerClient {// 超時后執(zhí)行public void timeout(); }

如果一個對象希望得到超時通知，它可以調(diào)用Timer 的register 函數(shù)。我們怎樣將TimeClient 類
和TimedDoor 類聯(lián)系起來，才能在超時時通知到TimedDoor 中相應的處理代碼呢？如下是一個容易想到的解決方案。

?這個方案最主要的問題：現(xiàn)在Door 類依賴TimeClient 了。可是并不是所有種類的Door 都需要定時功能。

分離客戶就是分離接口

? ? ? ? Door 接口和TimerClient 接口是被完全不同的客戶程序使用的。Timer 使用TimerClient，而操作門的類使用Door。既然客戶程序是分離的，所以接口也應該保持分離。

客戶對接口施加的反作用力

? ? ? ? 例如，有些Timer 的使用者會注冊多個超時通知請求。比如對于TimedDoor 來說。當它檢測到門被打開時，會向Timer 發(fā)送一個register() 消息，請求一個超時通知。可是，在超時到達前，門關上了，關閉一會兒后又被再次打開。這就導致在原先的超時到達前又注冊了一個新的超時請求。最后，最初的超時到達，TimedDoor 的 timeout() 方法被調(diào)用。Door 錯誤地發(fā)出了警報。

? ? ? ? 修復，在每次超時注冊中都包含一個唯一的 timeoutID 碼，并在調(diào)用TimerClient 的timeout() 方法時，再次使用該標識碼。

public interface Timer {// 注冊超時服務public void register(int timeout, int timeoutID, TimerClient client); }public interface TimerClient {// 超時后執(zhí)行public void timeout(int timeoutID); }

????????顯然，這個改變會影響到TimerClient 的所有使用者。還會影響到Door 以及Door 的所有客戶程序。這是僵化性和粘滯性的臭味。

接口隔離原則（ISP）

? ? ? ? 不應該強迫客戶依賴于它們不用的方法。

1、使用委托分離接口

?

public TimedDoor implements Door {public void doorTimeout(int timeoutID);// 其他接口方法實現(xiàn)... }public class DoorTimeAdapter implements TimerClient {private TimedDoor itsTimeDoor;public DoorTimeAdapter(TimedDoor theDoor) {this.itsTimeDoor = theDoor;}public void timeout(int timeoutID) {itsTimeDoor.doorTimeout(timeoutID);} }

2、使用多重繼承分離接口（推薦）

?

總結(jié)

以上是生活随笔為你收集整理的接口隔离原则（ISP）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。