1. 程式人生 > >面向對象原則之一 接口隔離原則

面向對象原則之一 接口隔離原則

分離 其他 ges images mage width display 可維護 很好

原文:面向對象原則之一 接口隔離原則

前言

面向對象有人分為五大原則,分別為單一職責原則、開放封閉原則、依賴倒置原則、接口隔離原則、裏氏替換原則。

也有人分為六大原則,分別為單一職責原則、開放封閉原則、依賴倒置原則、接口隔離原則、裏氏替換原則、迪米特法則。

現在我們來介紹接口隔離原則

接口隔離原則

1)概念

客戶端不應該依賴它不需要的接口。一個類對另一個類的依賴應該建立在最小的接口上。

怎麽理解呢?通俗一點就是說接口盡量細分,把不需要的方法盡量寫在2個不同的接口上。

假如我有一個接口Interface1,有5個方法。其中Class1想實現第1-3個方法,Class2想實現第3-5個方法。

那麽我只有一個Interface1,如果達到上面的要求,Class1與Class2只能實現Interface1的5個方法,如下:

技術分享圖片

那麽就變得很臃腫了。有什麽解決辦法呢?接口分離原則很好地解決了以上方法。

我們把Interface1分離3個接口,然後Class1與Class2分別繼承對應的接口,如下:

技術分享圖片

這樣,很好的消除了冗余。

2)深入了解

接口隔離原則的含義是:建立單一接口,不要建立龐大臃腫的接口,盡量細化接口,接口中的方法盡量少。也就是說,我們要為各個類建立專用的接口,而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。本文例子中,將一個龐大的接口變更為3個專用的接口所采用的就是接口隔離原則。在程序設計中,依賴幾個專用的接口要比依賴一個綜合的接口更靈活。接口是設計時對外部設定的“契約”,通過分散定義多個接口,可以預防外來變更的擴散,提高系統的靈活性和可維護性。

說到這裏,很多人會覺的接口隔離原則跟之前的單一職責原則很相似,其實不然。其一,單一職責原則原註重的是職責;而接口隔離原則註重對接口依賴的隔離。其二,單一職責原則主要是約束類,其次才是接口和方法,它針對的是程序中的實現和細節;而接口隔離原則主要約束接口接口,主要針對抽象,針對程序整體框架的構建。

采用接口隔離原則對接口進行約束時,要註意以下幾點:

  • 接口盡量小,但是要有限度。對接口進行細化可以提高程序設計靈活性是不掙的事實,但是如果過小,則會造成接口數量過多,使設計復雜化。所以一定要適度。
  • 為依賴接口的類定制服務,只暴露給調用的類它需要的方法,它不需要的方法則隱藏起來。只有專註地為一個模塊提供定制服務,才能建立最小的依賴關系。
  • 提高內聚,減少對外交互。使接口用最少的方法去完成最多的事情。

運用接口隔離原則,一定要適度,接口設計的過大或過小都不好。設計接口的時候,只有多花些時間去思考和籌劃,才能準確地實踐這一原則。

3)生活中例子

比如,我們身邊的手機,有打電話、支付、攝影、聊天、玩遊戲功能。

我們可以定義一個接口IPhoneOperation來說明這些功能。這樣臃不臃腫,要看業務邏輯。

我們現在定一個業務邏輯,把手機功能分成業余娛樂、生活支付、工作電話。可以拆分接口分別為:

技術分享圖片

拆分各種接口後,在業務層面我們更加容易地了解各自的業務功能實現;在代碼層面我們更加的高內聚,低耦合。

其他鏈接:

開放封閉原則(開閉原則)

單一職責原則

依賴倒置原則

接口隔離原則

裏氏替換原則

迪米特法則

面向對象原則之一 接口隔離原則