# 六角鼠年鐵人賽 Week 38 - Design Pattern - Interface Segregation Principle

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai==

## 義彥 (勇者義彥)
:::info
我是肩負拯救世界的勇者 義彥
:::

## 前引
上篇介紹了 **Single Responsibility Principle**，主要在於當功能複雜性超出其原先對於該類別的預期時，則應將可區分的功能再切割出去的動作。

若說 **Single Responsibility Principle** 重視的是功能的處理，則今天要介紹的 **Interface Segregation Principle** 就是重視接口的處理。

開發人員應該會常遇到一個狀況是，原先完成的 Interface 和 實現類別，在後續進行擴充的時候，為了因應新的方法加入，必須要在 Interface 中增加新方法的宣告。

當新宣告的方法完全適用每一個實現類別的時候，相信都沒什麼問題。
但當有部分的實現類別完全不需要這個新方法的時候呢?

或者原先的分類處理都很完善，但因為業務需求，不得不在原先的 Interface 中增添特殊案例的方法時?

是不是要重新針對 Interface 做一個劃分? 重新做符合 **Single Responsibility Principle** 的處理法?

其實在這種類似的狀況下，你需要做的是符合 **Interface Segregation Principle** 的處理。

## 主題
**Interface Segregation Principle**

中文常見名稱 **介面隔離原則**

由 ***Robert C. Martin*** 在 2002 年提出，原文提到: **Clients should not be forced to depend on methods they do not use.**
以及 **The dependency of one class to another one should depend on the smallest possible interface.**

意即子端(實現類) 不應去處理不需要的接口方法實現，並且類與類的的依賴應建立在最小的接口上。

精準的處理每一個透過接口取得的類中使用的方法，避免寫出類與類的依賴範圍過大而難以使用的程式架構。

## 幫助
Interface Segregation Principle 實現後對於架構上的幫助有以下：
- 降低擴充後的肥大問題
- 降低系統耦合問題
- 減少不必要的實現
- 提高接口靈活性
- 提高程式內聚性
- 提高系統可維護性

> 當心! Interface Segregation Principle 並不是要求將接口方法砍到極限的細緻，而是追求一個適中的發展狀況。
> 若追求到極致反而容易造成接口類過多，功能程式過於分散等問題!

## 實例
Kai 這邊拿體育競賽當做一個例子，今天要設計一個體育報名的網站，需要刊登各項賽事的規則和提供報名。

為求方便，在一開始 Kai 把所有的規則處理都寫進了同一個 Interface 中。

結果發現，游泳項目後續多了一條特殊規定須要補上，因此就直接補在了 Interface 中。

結果如下圖:

很明顯的，子類必須實現絕對不會被使用到的方法，且功能方法並沒有被正確切分開來。

Kai 試著透過拆分更多的接口方式改成下列架構:

我們可以看到個體育競賽的接口保持著最適當限度的接口，並且在耦合的處理上不會再發生錯誤項目的錯誤方法被使用的問題。

:::danger
又過了一週，又學習到一個新的 Principle，希望大家都能與 Kai 一起慢慢把基本功紮實起來吧!
:::

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Design Pattern`,`w3HexSchool`