設計模式之禅之六大設計原則-接口隔離原則

接口隔離原則

一：什麼是接口？

● 執行個體接口(Object Interface)

        ---->Person zhangSan=new Person()産生了一個執行個體,這個執行個體要遵從的标準就是Person這個類,Person類就是zhangSan的接口

● 類接口(Class Interface)

        ---->Java中經常使用的interface關鍵字定義的接口。

二：那什麼是隔離呢?它有兩種定義:

      ---->事物的定義一般都比較難了解,晦澀難懂是正常的。我們把這兩個定義剖析一下

         ---->第一種定義：用戶端不應該依賴它不需要的接口”,那依賴什麼?依賴它需要的接口,用戶端需要什麼接口就提供什麼接口,把不需要的接口剔除掉,那就需要對接口進行細化,保證其純潔性.

         ---->第二種定義：類間的依賴關系應該建立在最小的接口上”,它要求是最小的接口,也是要求接口細化,接口純潔,與第一個定義如出一轍,隻是一個事物的兩種不同描述。

         ---->總結：建立單一接口,不要建立臃腫龐大的接口。再通俗一點講:接口盡量細化,同時接口中的方法盡量少

         ---->疑惑點：看到這裡大家有可能要疑惑了,這與單一職責原則不是相同的嗎?錯,接口隔離原則與單一職責的審視角度是不相同的,單一職責要求的是類和接口職責單一,注重的是職責,這是業務邏輯上的劃分,而接口隔離原則要求接口的方法盡量少。例如一個接口的職責可能包含10個方法,這10個方法都放在一個接口中,并且提供給多個子產品通路,各個子產品按照規定的權限來通路,在系統外通過文檔限制“不使用的方法不要通路”,按照單一職責原則是允許的,按照接口隔離原則是不允許的,因為它要求“盡量使用多個專門的口”。專門的接口指什麼?就是指提供給每個子產品的都應該是單一接口,提供給幾個子產品就應該有幾個接口,而不是建立一個龐大的臃腫的接口,容納所有的用戶端通路。

        例子：

        美女分為臉蛋氣質美女和身材美女

        一個臉蛋氣質的接口

        一個身材美女的接口

        一個抽象類擁有兩個接口的依賴

一個臉蛋氣質的接口

package com.yeepay.sxf.sjms1;

/**

 * 五官氣質美女接口

 * @author sxf

 *

 */

public interface IGoodBodyGirl {

        /**

         * 好看的五官外貌

         */

        public void goodLooking();

         * 有氣質

        public void greatTemperament();

}

  一個身材美女的接口

 * 身材美女

public interface IGreatTemperamentGirl{

         * 好身材

        public void niceFigure();

  一個抽象類擁有兩個接口的依賴

 * 星探的抽象類

public abstract class AbstractSearcher2 {

         * 臉蛋氣質美女

        protected IGoodBodyGirl iGoodBodyGirl;

         * 臉蛋氣質身材美女

        protected IGreatTemperamentGirl iGreatTemperamentGirl;

         * @param pettyGirl

        public AbstractSearcher2(IGoodBodyGirl iGoodBodyGirl){

                this.iGoodBodyGirl=iGoodBodyGirl;

        }

         * @param iGreatTemperamentGirl

        public AbstractSearcher2(IGreatTemperamentGirl iGreatTemperamentGirl){

                this.iGreatTemperamentGirl=iGreatTemperamentGirl;

         * 搜尋美女

        public abstract void show();

三：如何保證接口的純潔性

● 接口要盡量小

        --->這是接口隔離原則的核心定義,不出現臃腫的接口(Fat Interface),但是“小”是有限度的,首先就是不能違反單一職責原則

        --->根據接口隔離原則拆分接口時,首先必須滿足單一職責原則

● 接口要高内聚

        --->什麼是高内聚?高内聚就是提高接口、類、子產品的處理能力,減少對外的互動。比如你告訴下屬“到奧巴馬的辦公室偷一個×××檔案”,然後聽到下屬用堅定的口吻回答你:“是,保證完成任務!”一個月後,你的下屬還真的把×××檔案放到你的辦公桌上了,這種不講任何條件、立刻完成任務的行為就是高内聚的表現。具體到接口隔離原則就是,要求在接口中盡量少公布public方法,接口是對外的承諾,承諾越少對系統的開發越有利,變更的風險也就越少,同時也有利于降低成本。

● 定制服務

        --->一個系統或系統内的子產品之間必然會有耦合,有耦合就要有互相通路的接口(并不一定就是Java中定義的Interface,也可能是一個類或單純的資料交換),我們設計時就需要為各個通路者(即用戶端)定制服務,什麼是定制服務?定制服務就是單獨為一個個體提供優良的服務。我們在做系統設計時也需要考慮對系統之間或子產品之間的接口采用定制服務。采用定制服務就必然有一個要求:隻提供通路者需要的方法

● 接口設計是有限度的

        --->接口的設計粒度越小,系統越靈活,這是不争的事實。但是,靈活的同時也帶來了結構的複雜化,開發難度增加,可維護性降低,這不是一個項目或産品所期望看到的,是以接口設計一定要注意适度

四：最佳實踐

        接口隔離原則是對接口的定義,同時也是對類的定義,接口和類盡量使用原子接口或原子類來組裝。但是,這個原子該怎麼劃分是設計模式中的一大難題,在實踐中可以根據以下幾個規則來衡量:

        ● 一個接口隻服務于一個子子產品或業務邏輯;

        ● 通過業務邏輯壓縮接口中的public方法,接口時常去回顧,盡量讓接口達到“滿身筋骨肉”,而不是“肥嘟嘟”的一大堆方法;

        ● 已經被污染了的接口,盡量去修改,若變更的風險較大,則采用擴充卡模式進行轉化處理;

        ● 了解環境,拒絕盲從。每個項目或産品都有特定的環境因素,别看到大師是這樣做的你就照抄。千萬别,環境不同,接口拆分的标準就不同。深入了解業務邏輯,最好的接口設計就出自你的手中!