讀懂 SOLID 的「接口隔離」原則

這是理解 SOLID原則，關於 接口隔離原則如何幫助咱們建立簡單的抽象接口，並使客戶端代與接口之間存在的更少的依賴關係。

接口隔離原則是什麼

Clients should not be forced to depend on methods that they do not use.

客戶端代碼不該當被迫依賴於它們不須要的方法。

這個原則自己與單一職責原則關係十分緊密，它意味着當你在定義你的抽象層代碼時，不該當在客戶端代碼在實現抽象邏輯時，暴露一些客戶端代碼不須要使用或者關心的方法。

進一步說明的話，就是當你有意地在抽象層中暴露的方法時，這意味着全部實現這些抽象邏輯的客戶端代碼都必需要實現全部的抽象方法，儘管這些方法並不必定都對客戶端代碼有意義。

將你的接口的保持精簡和小顆粒度，而且不要在它們中間增長無用的抽象方法，當你在對新的抽象接口進行命名時，你就會擁有更好的選擇，由於你已有了若干小顆粒的命名類型。這樣作的意義在於當你在須要提供一個更加大顆粒度的抽象接口時，你能夠擁有足夠的靈活性來將已有的小顆粒度接口進行組合。

如何實踐接口隔離原則

這個例子是關於一個ATM用戶界面的抽象接口，這個接口會處理諸如存款請求、取款請求等邏輯，從這個例子中咱們會了解到，咱們如何對這個接口進行隔離，使其進一步劃分爲多個獨立的、更加具體的若干接口。

首先咱們應當有一個工具函數庫接口，這個接口會描述咱們想要暴露的關於byte操做邏輯的方法，讓咱們建立這樣一個接口，以下

type ByteUtils interface {
    Read(b []byte) (n int, err error) // Read into buffer
    Write(b []byte)(n int, err error) // Write into buffer
    Trim(b []byte, exclusions string)[]byte // Trim buffer by removing bytes from the exclusion chars
}

它能夠正常工做一段時間，可是很快咱們就會發現如下兩個問題：

• 它的命名ByteUtils太過於通用，若是咱們僅經過命名自己，基本沒法獲取任何具體的信息
• 當使用它時，會有一些古怪的感受，由於當你根據不一樣的優化場景來按不一樣邏輯實現trim方法時，你所實現的read和write幾乎沒什麼差異，可是你卻須要重複地實現它們，同時在某些不須要讀或者寫的場景，仍然須要實現它們。

因此它雖然可以正常工做，可是卻不夠好。

咱們能夠經過建立三個更精簡、更具體的接口來替代原先通用的接口：

type Reader interface {
    Read(b []byte) (n int, err error) 
}
type Writer interface {
    Write(b []byte)(n int, err error) 
}
type Trimmer interface {
    Trim(b []byte, exclusions string)[]byte 
}

這種顆粒度比較細的接口也能夠稱爲角色接口，由於它們更易於重構和改變，甚至對於已經定義好的角色和目的也能夠很容易的進行從新部署和定義。

在這三個基礎上，咱們能夠經過組合它們來獲取一個更有關聯性的接口列表，好比：

type ReadWriter interface {
    Reader
    Writer 
}
type TrimReader interface {
    Trimmer
    Reader
}

這意味客戶端代碼擁有了能夠根據它們各自的需求來組合抽象層接口的靈活性，這樣就會避免在實現抽象接口時沒必要要的麻煩（好比必需要實現某些無用的方法），好比上面的TrimReader的實現並未包含多餘的Write方法的聲明。

總結

正如你所看到的，通用的接口每每會無心識的將本身和類的實現耦合在了一塊兒，因此你應當儘可能的避免這種狀況的發生。在設計接口時，你應當時刻提醒本身，我是否須要使用全部在接口中聲明的方法呢？若是不是的話，將接口細分爲更多個更精簡、更具體的接口。

正如甘地曾經說過：

你的行動決定你的習慣，你的習慣決定你的價值，你的價值會決定你的命運。

若是在架構中，你每次都會通過仔細思考，會按照好的模式來進行設計，它將會成爲一種習慣，天然慢慢會轉變爲你的價值或者原則，最終則會成爲你的命運，好比成爲了一個始終給予完善解決方案的軟件架構師。

個人觀點是，始終經過挑戰本身來變的更好，在某些時刻，你可能會遇到問題，可是每每你可能已經擁有了答案。

Happy coding!

譯者注

對於接口隔離原則的理解，我一直覺的它自己實際上是單一職責原則的一個擴展，可是它們之間也有細微的不一樣：

• 單一職責原則每每面向實現層，好比具體的類或者某個方法
• 接口隔離原則每每面向抽象層，好比一些抽象類或者抽象方法

因此將兩個原則結合起來看的話，能夠很容器獲得當時提出這兩個原則的人的意圖，那就是必定要時刻保持簡單。

在實際工做中，我深知保持簡單是一件十分困難的事情，由於工程師自己的使命即是解決問題，而問題每每充滿了未知性，而未知性每每表明着改變，這尚未考慮到在項目實施過程當中，產品經理天馬行空的設計思路，客戶們五花八門的需求等等。在這些外界條件下，咱們的代碼每每會變得複雜無比，充滿了各類反模式和冗餘代碼，最終會使本身陷入無盡的bug修復和維護工做中，怎麼還會有時間進行自我提高呢？

因此，爲了可以按時下班，爲了可以及早回家，爲了可以讓咱們的擁有更多的時間來提高本身和陪伴家人，在軟件設計之初，儘量地針對未來所面臨的改變，在設計層面下降軟件抽象模塊間的耦合程度，在項目實施時，提升每一個具體實現模塊內部的內聚程度，同時使它們保持簡單，這樣即是一個好的開始。

關注公衆號 全棧101，只談技術，不談人生