物件導向設計原則 - SOLID

日期：

起因：

要開始慢慢遵守物件導向設計原則來撰寫程式。
之前都是為了要快速要案子弄出來頂多就是模組化而已就連測試也不一定有時間寫，所以這篇文章就是紀錄一下設計原則順便複習一下避免忘記，最後就是提昇寫程式碼的到更進接的架構層級。

1. 單一職責原則 Single responsibility principle , SRP

每個物件不管是類別、函數，負責的功能都應該只做一件事。也就是說當一個函數內，同時做了兩件以上的事情，一旦發生錯誤時很難快速找到錯誤的地方。此外也會讓程式碼的可閱讀性降低。

優點：

  1. 可讀性與可維護性提昇。
  2. 可靠性提昇。
    有做好的話通常修改只會對同一個界面或是類別有影響，這對擴展性和維護性有很大的幫助。

潛在問題：

  • 職責該怎麼劃分？因為變化的原因和職責都是無法量化的，如果每個方法都要在一個界面上會導致界面數量爆增反而帶來麻煩。

2. 開放封閉原則 Open-Close principle, OCP

軟體應該是對於擴展是開放的，但是對於修改是封閉的概念。也就是說當有需求異動時藉由繼承、相依性注入等方式去增加新的程式碼實做新的需求。
因為如果為了新需求去修改原本的程式中的函數，可能會造成其他呼叫使用該函數的功能出現非預期的錯誤。

優點：

  1. 降低修改風險。因為是透過繼承、擴展的方式新增程式碼因此不會動到原本舊有的程式碼，理論上出現新的bug機率會比較小。

潛在問題：

  • 需要擴展的情況通常不一定會出現在設計階段，常常到了需求調整才會知道。所以並不一定可以在開發階段可以用到OCP。

3. 里氏替換原則 Liskov substitution principle, LSP

子類別必須要能取代它的父類別，而且不能出現任何錯誤或異常。不過由於很多人在撰寫子類別的時候會去覆蓋父類別的某些方法行為(method)，很容易導致相同的方法(method)有不可預測的錯誤。例如：父類別有個 print()的功能是把數值列印到畫面上，而它的一個子類別覆寫 print() 方法改成輸出到印表機去這種行為所以要建議要遵守原則的要領。

原則要領：

為了避免發生錯誤或是異常，實做可以參考要領如下。
  • 子類別必須完全實做父類別的方法。
  • 子類別可以有屬於自己的屬性和方法。
  • 複寫或實做父類別的方法時，參數要與父類別定義的一樣或是更寬鬆。
  • 複寫或實做父類別的方法時，回傳結果要跟父類別定義的一樣或是縮小。

優點：

增加程式的強健性讓版本升級的時候也能有很好的兼容性。

4. 界面隔離原則 Interface segregation principle, ISP

針對不同需求的用戶，開放其對應需求的界面勝於一個廣泛用途的界面。可以避免用戶用不到的界面異動造成全部用戶一起面對異動可能產生的問題。

優點：

  • 讓系統解耦合，從而容易重構、更改和重新佈署。

5.依賴反轉原則 Dependency inversion principle,DIP

高階模組不應該依賴低階模組，兩著都應該依賴於抽象界面。抽象不要依賴具體實現細節，細節要依賴抽象。

優點：

  • 避免上層模組因為底層模組改變而被迫改變

以上五個原則構成了 SOLID 這個字！但是其實以上五個原則都在談『改變』這件事。
用五種的策略來面對程式碼改變只不過改變的原因不同，所以有五種不同的應對策略。
此外程式不可能沒有耦合，但是我們的目標應該是建立在內部完整(高內聚)，而副程式之間的關聯是小巧、直接、可見、靈活的(鬆耦合)所以把耦合的程度適度的小才是最好的。


REF:

留言

張貼留言