面向對象設計-單一職責原則SRP

 面向對象設計 目標

1 可擴展性 - 新功能易新增

2 靈活性 - 新增過程中, 不因舊功能僵固而進行困難

(不會改功能A 導致功能B無法使用)

3 可插入性 - 容易把一個類別抽出去, 替換相同介面的類進來使用

判斷軟體設計質量的標準

高內聚, 低耦合

*耦合性: 模塊與模塊, 類與類之間相互聯繫的緊密程度->獨立性弱->如果一個類不存在, 另外一個類就無法運作

*內聚性: 模塊內部, 或是 類內部的元素, 程式區塊, 關聯越緊密, 內聚性越高

*高內聚:軟體模塊由相關性很強的程式碼組成, 只負責一項任務, 不可分割

*低耦合:模塊之間, 類與類之間, 盡可能的獨立存在, 以最低程度的關聯進行協作

------------------------------------------------------------------------

單一職責原則 (Singke-Responsibility Principle)

定義: 一個類只負責一個功能領域中的相應職責, 或可以定義為: 就一個類而言, 應該只有一個引起它變化的原因

高內聚

一個類承擔的責任越多, 它可被復用的可能性就越小, 而且一個類承擔的責任過多, 就相當於將這些職責偶合在一起, 當其中一個職責變化時, 可能會影響到其他職責的運作, 因此要將這些職責進行分離,將不同的職責封裝在不同的類中, 即將不同的變化原因封裝在不同的類中, 如果多個職責總是同時發生變化則可將它們封裝在同一個類中

好處:

1 可降低類的複雜度, 一個類只負責一向職責, 其邏輯肯定比負責多項職責簡單的多

2 複雜度低, 可讀性自然提高

3 可維護性高, 風險低, 如果介面的單一職責好, 一個介面修改指對應相應的實現類有影響, 對其它的介面無影響, 這對系統的擴展性, 維護性都有很大的幫助

範例: 原本CustomerChart類別中包含兩個功能

一個是查找數據庫, 另一個是顯示列表

然而我們今天查找數據庫發生變化, 原本使用mysql改成用mogodb

這樣, 這一個類, 它就不存在了, 它需要進行修改

CustomerChart本身關心顯示列表, 並不關心查找數據庫, 我們可以將這功能撥離

產生一個CutomerDao用來查找數據庫

這樣我們未來設計, 如果改變數據庫, 我們只要在這裡new一個CustomerDao

而CustomerChart本身並不需要進行任何改變, 我們就使CusomerChart實現了單一職責原則

就是他只管它該管的事情, 而不管它不該管的事情

參考: 

https://www.youtube.com/watch?v=oKu6q6Nnvdk&list=PLGmd9-PCMLhb16ZxeSy00qUsBazXgJyfM&index=4

https://github.com/iw5420/geroge-design-pattern