In 91

前言
前面介紹了單一職責原則、開放封閉原則、最少知識原則，今天要介紹的是Interface Segregation Principle, ISP (介面隔離原則)。

介面隔離原則，與單一職責原則和最少知識原則有一點關係，而SOLID原則的總綱是開放封閉原則，所以如果對這些觀念還不夠熟悉的朋友們，可以參考一下前面幾篇文章：

1. [ASP.NET]91之ASP.NET由淺入深 不負責講座 Day17 – 單一職責原則
2. [ASP.NET]91之ASP.NET由淺入深 不負責講座 Day18 – 開放封閉原則
3. [ASP.NET]91之ASP.NET由淺入深 不負責講座 Day19 – LoD/LKP 最少知識原則

Issues

1. 定義
   1. Clients should not be forced to depend upon interfaces that they don't use.
      也就是Client不應該依賴它不需要的介面。
      
   2. The dependency of one class to another one should depend on the smallest possible interface.
      也就是Class之間的依賴關係應該建立在最小的interface上。
      
      
2. 簡單的說
   Class與外部的關係，應只依賴它需要的最小介面，所以介面不能太肥，應該要細化，不然會強迫中獎。每一個interface的方法數目應該盡可能地降到最低。
   
   
3. 與單一職責原則的矛盾
   1. 單一職責是指屬於同一個職責的方法應該放在一起，且一個class/interface只負責一個職責。
      可能產生一種情況，實作interface的class，用不到該interface的所有方法。
      
   2. 相對於介面隔離原則，則是每一個class實作了某個介面，就應該代表會用到該介面所有的方法，如果不會用到所有方法，代表該interface可以再繼續細化。
      
      
4. 目的
   對interface的scope進行約束。
   
   
5. 基本原則
   1. interface盡量小
      • 粒度越小代表系統可以越靈活，但也代表結構越複雜，開發難度提升
      • 最小的情況就是一個interface只有一個method，但違反單一職責原則
      • 細分interface的前提，就是不能違反單一職責原則
        
        
   2. interface應高內聚
      • 粒度應該符合環境與未來需求中，細分到最細
      • interface就是contract的觀念，對外承諾的function越少，變動風險越低，就越穩定
        
        
   3. 訂製服務
      • interface只提供訪問者需要的方法
        
        
   4. 粒度大小的細分標準
      • 因地因時制宜，取捨需求、開發與結構的平衡點
        
        
6. 結論
   殺雞焉用牛刀，但書：
   • 如果是為了殺雞，就不需要用到牛刀
   • 如果是為了用牛刀，那就還是得用牛刀
     
     
7. 舉例
   我們用下面這張class diagram(點圖可放大)來看，可以看到以工作上所需的技能來分，一個ExcellentWorker，應同時具備HardSkill與SoftSkill。
   然而，不是每一樣工作，都需要excellent的worker才能做事。一個健康的團隊，應該有將有兵，分工合作，各司其職，互助互補。
   
   如果今天工作需要的是協助測試，那可以找QA，也可以找Joey。最好是先找QA，因為如果找Joey，他的對外方法不只測試的介面，還有許多其他的功用，就很有可能被其他任務插單。
   
   相對的，以介面來說，一個QA可能只需要具備測試的介面，而不需具備Leadership或是Integrity。
   
   我自己的原則是，寧可多實作幾個interface，保留彈性，也要避免未來因為繼承或extend造成強耦合而無法修改的風險。
   但interface的本身，還是要盡量符合單一職責的原則。
   
   

 

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/