設計原則利劍四--接口隔離原則

英文名稱：貌似沒有好的翻譯

中文名稱：接口隔離原則

作      用：仔細分析業務流程，劃分合适的粒度，為系統的靈活性以及可維護性有較大的提高，避免肥嘟嘟的接口類，避免臃腫龐大，一般如

               果接口封裝過頭，就會将一些可變因素封裝進去，這種封裝過度了會導緻今後的維護度大大增加。

真      言：

              1、用戶端不應該依賴于它不需要的接口

              2、類的依賴關系應該建立在最小的接口上

              3、接口要盡量小，在拆分接口時，首先必須要滿足單一職責原則

              4、接口要高内聚，要盡量減少與外面的互動

              5、粒度的劃分要根據實際業務需求，不宜過小，也不宜過大

深刻了解：看了這個接口隔離原則，心中很是難過，原來現在的系統設計接口設計的是多麼的臃腫，是多麼的經受不起未來需求的調整，在

               接口的設計中，一定要遵循一個輕裝上陣，用毛澤東的遊記戰術，化整為0的思想來指導接口的設計與劃分。

理論實踐：

                先用一個星探找美女的案例來說明問題，對于美女的标準可以定義為：身材好，臉蛋漂亮，有氣質，星探則根據這種情況去尋找美女，如是便有了如下的設計，上UML圖如下：

                這種設計的結果就是必須要滿足身材好，臉蛋漂亮，有氣質的才能夠成為美女，但是很多情況下，非常有氣質的大家看來也是美女，身材好，臉蛋漂亮，氣質稍微差點的也算是美女，那麼這個類明顯就不滿足需求了，将衆多的接口資訊放入一起，不僅僅造成的是臃腫，而且還是邏輯上的錯誤，如果再來一個以胖為美的美女，那麼這個類就無法處理了，因為和身材好完全是互相沖突的，這種情況采用接口分離原則，經過分析将接口分成如下圖所示：很明顯，這種方式很容易擴充，無論是氣質型美女，胖嘟嘟類型的美女，星探可以根據各種人的口味來尋找各種類型的美女，兄弟們這下有福氣了，哈哈！,其實我個人欣賞的美女标準為：腿一定要細長，皮膚要白，臉要可愛型，脾氣要溫順點的，我估計星探得氣死，為什麼，因為他根本就不知道怎麼去找，沒有接口啊，如果采用下圖的方式，一點問題沒有，重新加一個IloveBeautyGirl,将腿細長，皮膚嫩白，臉型可愛，脾氣溫順作為标準，一切解決！

                  我不有自主的就聯想到我系統現在的設計模式，我很不好意思将現在系統這種蹩腳的設計模式拿出來獻醜，但是為了加深印象，決定把蹩腳設計拿出來，設計如下：這個子產品主要是負責清單的加載，查詢條件的加載，查詢曆史記錄的加載。知道嗎？我這個可繼承的類肚吞天下，處理了圖像的加載，處理了首頁的加載，處理了複雜多層資料清單以及單層的資料清單，全部用一個類來解決，是以導緻每增加一個類，都必須要增加一個特殊的方法，不可想像，如果我現在要在一個頁面中增加圖形+資料的顯示，我這個類我該如何設計啊，這麼繼續增加下去，我估計我會徹底的崩潰。

                經過到現在為止領悟的四招設計模式：第一招，單一職責原則，第二招，裡氏替換原則，第三招，依賴倒置原則，再加上這招，接口隔離原則，處理完畢，上圖如下，有了這種設計結構，不僅僅減輕了現在的重複代碼，而且還增強了可擴充性，沒有必要實作的方法我就不用再實作了，看起來舒服，寫代碼寫起來也舒服，何樂而不為？