介面隔離原則
定義
Clients should not be forced to depend upon interfaces that they don't use.
The dependency of one class to another one should depend on the smallest possible interface
說明
兩句話想說明的其實很單純，意思就是，依賴的介面方法應該盡量得少，只要依賴用到的到就好。
可能有人會覺得這跟單一職責原則的概念是否相符，我覺得可以適當地從這個概念去理解，但實際上還是有所不同。
單一職責著重的是職責，但是介面隔離比較像是透過細分的介面來控制每個模組只能用那些功能，不必要針對所有的功能都開放。
以職責來看，也許這 10 個方法都是同一個類別應該去處理的，但是從介面隔離的角度來看，也許這個模組只需要用到這個類別的兩個方法就好了。
實作建議
- 一個介面只用於一個模組或是業務邏輯。
- 常常要去回顧介面中定義的的方法，讓介面不要越來越肥大。
- 從 Domain Knowhow 的角度出發，根據情境或是產品本身，拆分出好的介面設計。
實例
需求
// ...
設計
// ...
效益 & 注意事項
效益
- 當我們使用介面隔離原則，我們能夠讓程式碼只依賴需要的介面，不再需要困惑說，到底我們應該使用這個介面的哪個方法。
- 根據這項原則，我們可以再更細分出介面的結構，可以讓個模組只依賴適合的介面，進一步做到了高內聚低耦合，更有利於系統開發。
介面是對外部的承諾，當我們提供的內容越少，表示未來異動的機會越小，有利於降低後續的維護成本。
注意事項
- 介面隔離跟其他的設計原則一樣，需要根據經驗和實際的場景，需要適當的去使用。
- 過於龐大的介面會讓靈活度降低，難以維護；過於碎片的介面 (一個方法一個介面!?) 會讓介面的數量非常多，開發人員光是要找到是哪一個介面大概就快累死了。