《Android 源碼設計模式解析與實戰》——第1章，第1.5節系統有更高的靈活性——接口隔離原則

本節書摘來自異步社群《android 源碼設計模式解析與實戰》一書中的第1章，第1.5節系統有更高的靈活性——接口隔離原則，作者 何紅輝 , 關愛民，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

1.5 系統有更高的靈活性——接口隔離原則

接口隔離原則英文全稱是interfacesegregation principles，縮寫是isp。isp的定義是：用戶端不應該依賴它不需要的接口。另一種定義是：類間的依賴關系應該建立在最小的接口上。接口隔離原則将非常龐大、臃腫的接口拆分成更小的和更具體的接口，這樣客戶将會隻需要知道他們感興趣的方法。接口隔離原則的目的是系統解開耦合，進而容易重構、更改和重新部署。

接口隔離原則說白了就是，讓用戶端依賴的接口盡可能地小，這樣說可能還是有點抽象，我們還是以一個示例來說明一下。在此之前我們來說一個場景，在java 6以及之前的jdk版本，有一個非常讨厭的問題，那就是在使用了outputstream或者其他可關閉的對象之後，我們必須保證它們最終被關閉了，我們的sd卡緩存類中就有這樣的代碼：

我們看到的這段代碼可讀性非常差，各種try…catch嵌套都是些簡單的代碼，但是會嚴重影響代碼的可讀性，并且多層級的大括号很容易将代碼寫到錯誤的層級中。大家應該對這類代碼也非常反感，那我們看看如何解決這類問題。

我們可能知道java中有一個closeable接口，該接口辨別了一個可關閉的對象，它隻有一個close方法，如圖1-4所示。

我們要講的fileoutputstream類就實作了這個接口。我們從圖1-4中可以看到，還有100多個類實作了closeable這個接口，這意味着，在關閉這100多個類型的對象時，都需要寫出像put方法中finally代碼段那樣的代碼。這還了得！你能忍，反正小民是忍不了的！于是小民打算要發揮他的聰明才智解決這個問題，既然都是實作了closeable接口，那隻要我建一個方法統一來關閉這些對象不就可以了麼？說幹就幹，于是小民寫下來如下的工具類：

我們再看看把這段代碼運用到上述的put方法中的效果如何：

代碼簡潔了很多！而且這個closequietly方法可以運用到各類可關閉的對象中，保證了代碼的重用性。closeutils的closequietly方法的基本原理就是依賴于closeable抽象而不是具體實作（這不是1.4節中的依賴倒置原則麼），并且建立在最小化依賴原則的基礎上，它隻需要知道這個對象是可關閉，其他的一概不關心，也就是這裡的接口隔離原則。

試想一下，如果在隻是需要關閉一個對象時，它卻暴露出了其他的接口函數，如outputstream的write方法，這就使得更多的細節暴露在用戶端代碼面前，不僅沒有很好地隐藏實作，還增加了接口的使用難度。而通過closeable接口将可關閉的對象抽象起來，這樣隻需要用戶端依賴于closeable就可以對用戶端隐藏其他的接口資訊，用戶端代碼隻需要知道這個對象可關閉（隻可調用close方法）即可。小民設計的imageloader中的imagecache就是接口隔離原則的運用，imageloader隻需要知道該緩存對象有存、取緩存圖檔的接口即可，其他的一概不管，這就使得緩存功能的具體實作對imageloader隐藏。這就是用最小化接口隔離了實作類的細節，也促使我們将龐大的接口拆分到更細粒度的接口當中，這使得我們的系統具有更低的耦合性，更高的靈活性。

bob大叔（robert c martin）在21世紀早期将單一職責、開閉原則、裡氏替換、接口隔離以及依賴倒置（也稱為依賴反轉）5個原則定義為solid原則，作為面向對象程式設計的5個基本原則。當這些原則被一起應用時，它們使得一個軟體系統更清晰、簡單，最大程度地擁抱變化。solid被典型地應用在測試驅動開發上，并且是靈活開發以及自适應軟體開發基本原則的重要組成部分。在經過第1.1～1.5節的學習之後，我們發現這幾大原則最終就可以化為這幾個關鍵詞：抽象、單一職責、最小化。那麼，在實際開發過程中如何權衡、實踐這些原則，大家需要在實踐中多思考與領悟，正所謂”學而不思則罔，思而不學則殆”，隻有不斷地學習、實踐、思考，才能夠在積累的過程中有一個質的飛越。