物件導向設計原則 - SOLID
閱讀時間約 7 分鐘
本筆記除了以文字說明SOLID設計原則以外，並以Java code實際舉例。
Single Responsibility Principle (SRP) 單一職責原則
- 每個人負責屬於自己的職責，不該承擔太多職責，大家各自做自己應該做的事情，且不會互相干擾。
以下舉例說明，假設有個Employee類別，calculatePay()用來計算薪資，是屬於會計部的需求，genHoursReport()用來產生工時報表，是屬於人資部的需求。
calculateWorkingHours() 用來計算工時，calculatePay()與genHoursReport() 方法都依賴這個方法，也就是無論是計算薪資或是產生工時報表，都需要先計算出工時。
假設會計部門要求要更改計算薪資的方式，需要動到計算工時的邏輯calculateWorkingHours()，由於產生工時報表的方法也會呼叫這個method來計算工時，因此這個修改有可能會導致工時報表錯誤的問題，也就是為了會計部門的需求更動，會影響到人資部門的需求功能。
因此問題就浮現了，Employee class做太多事情了，把其他人的職責也囊括進來這邊，會計部門的需求改變會影響到人資部門的功能，這就不符合SRP了。
因此，需要把不同的職責拆分到不同的類別，以免互相影響:
如此將會計的計算薪資與人資的工時報表拆開為獨自的類別(將不同的責任方法拆分到不同的類別)，內部有各自的計算工時邏輯，互不影響。會計部門的計算工時邏輯更動，不會影響人資部門的功能了。
Open/Closed Principle (OCP) 開放封閉原則
- 「對擴充開放，對修改封閉」: 需求變動時，可以對既有的程式碼進行擴展，而不須修改原有的程式碼。
續上程式碼，修改如下:
要根據不同角色計算薪資，這樣的程式碼，每當有一個新的role就要去改switch的code，增加一個case與對應的method，來計算對應的薪資，如此就違反OCP原則了，要擴展不應該要去改原本的程式碼。
因此為了符合OCP原則，我們修改一下code:
如此修改，日後若要擴充新的Role，只需新增一個XXXRole class，並且定義calcSalary()方法，將薪資計算邏輯寫在這，就完成了。擴充功能完全不需要動到原本的code，即符合OCP原則。
Liskov Substitution Principle (LSP) 里氏替換原則
- 當子類別替換掉父類別時，其功能不受影響。
- 子類別繼承父類別可以擴充新的功能，不應覆寫原本父類定義的功能，若要覆寫就必須符合原來預期的行為。
這邊修改一下剛剛的role extends的code，CEORole繼承了Role且覆寫了setName() 方法，將原本父類別setName的行為改掉了，導致發生預期之外的錯誤，這就是違反LSP原則。
從輸出的結果來看，子類的行為改變(覆寫)了父類原本的行為，造成子類無法替代父類，即違反LSP原則。
Output:
Role Name: ABCRole Name: CEO
Interface Segregation Principle (ISP) 介面隔離原則
- 將龐大的介面拆分為更小且具體的介面，讓客戶只需實作他們需要的方法，不應有用不到的功能可以呼叫。
沿用上述code，修改成如下:
假設讀取報表(readReport)是祕書才會做的事，審核假單(verifyBreakLog)是主管才會做的事，對於主管(Director)來說，不需要readReport()這個方法，但卻被迫實作且可以呼叫不會使用的方法，這就違反了ISP原則。
為了符合ISP原則，將code改成如下，將AdminUsage拆的更小:
如此一來，秘書可以讀取報表，不需要去實作用不到的審核假單。
主管可以審核假單，不需要去實作用不到的讀取報表，也就符合了ISP原則。
主管可以審核假單，不需要去實作用不到的讀取報表，也就符合了ISP原則。
Dependency Inversion Principle(DIP) 依賴反轉原則
- 高階模組不應該依賴於低階模組，兩者都應該依賴抽象。
例如為了「讀取報表」功能，需要依賴Excel類別的readFile()來讀取檔案，如同下面的程式碼一樣。
這時候問題就來了，假設要改從Word去讀取檔案，而Word類別的方法名稱不是readFile(), 而是readContent()，高階模組readReport()這邊的程式碼，就會因為低階模組的改動，也需要跟著改程式，這就是所謂的高階模組依賴於低階模組:
為了符合DIP原則，修改如下:
現在變成高階模組跟低階模組都依賴IReader interface，假如今天要換成從PPT讀取呢? 這樣的程式碼擴充就很容易，對我來說只需要新增一個PPT class並且implements IReader 實作readContent() method，然後將PPT instance傳入高階模組建構子即可:
有沒有發現，這樣設計後高階模組的code完全不用改，也變相的統一了method name，都叫做readContent()，對於新的低階模組class而言只需把readContent()的邏輯寫好，高階模組會去call readContent()，完全不須改code。
也就是說，想要符合DIP原則，可以朝這樣的方向去思考: 「為了達成這個目的，我需要依賴什麼功能?」將這個功能設計成interface即可。
以這個例子而已，為了達成讀取報表的目的，我需要依賴讀取資料的功能，因此把讀取資料功能拉出來設計成介面，讓高低階模組皆依賴於這個介面，即可符合DIP原則。
本筆記參考:
1. https://matthung0807.blogspot.com/2021/01/java-solid-liskov-substitution-principle.html
2. https://www.cnblogs.com/windpoplar/p/12724391.html
3. https://easonchang0115.github.io/blogs/other/2021/20210427_1.html#d-dependency-inversion-principle
4. https://ianjustin39.github.io/ianlife/design-pattern/liskov-substitution-principle/
5. https://medium.com/%E7%A8%8B%E5%BC%8F%E6%84%9B%E5%A5%BD%E8%80%85/%E4%BD%BF%E4%BA%BA%E7%98%8B%E7%8B%82%E7%9A%84-solid-%E5%8E%9F%E5%89%87-%E4%BB%8B%E9%9D%A2%E9%9A%94%E9%9B%A2%E5%8E%9F%E5%89%87-interface-segregation-principle-50f54473c79e
6. https://ithelp.ithome.com.tw/articles/10192464
7. https://notfalse.net/1/dip
8. https://www.jyt0532.com/2020/03/24/dip/
9. https://igouist.github.io/post/2020/12/oo-14-dependency-inversion-principle/
2. https://www.cnblogs.com/windpoplar/p/12724391.html
3. https://easonchang0115.github.io/blogs/other/2021/20210427_1.html#d-dependency-inversion-principle
4. https://ianjustin39.github.io/ianlife/design-pattern/liskov-substitution-principle/
5. https://medium.com/%E7%A8%8B%E5%BC%8F%E6%84%9B%E5%A5%BD%E8%80%85/%E4%BD%BF%E4%BA%BA%E7%98%8B%E7%8B%82%E7%9A%84-solid-%E5%8E%9F%E5%89%87-%E4%BB%8B%E9%9D%A2%E9%9A%94%E9%9B%A2%E5%8E%9F%E5%89%87-interface-segregation-principle-50f54473c79e
6. https://ithelp.ithome.com.tw/articles/10192464
7. https://notfalse.net/1/dip
8. https://www.jyt0532.com/2020/03/24/dip/
9. https://igouist.github.io/post/2020/12/oo-14-dependency-inversion-principle/
為什麼會看到廣告
21會員
161內容數
留言0
查看全部
你可能也想看
Google News 追蹤
在寫程式的過程中，你是否遇過一個類別或模組負責了太多事情，結果導致程式變得難以維護？這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時，改動可能會牽一髮動全身影響其他部分，這時候「單一職責原則 (SRP)」便派上用場。
單一職責原則是什麼？
簡單來說，單一
最初階的工作者專注於個人利益，對組織成就無感，而成熟工作者則能從組織及公司利益出發，人的初始設定就是自利，我們要如何擴大自己的格局，成為一位成熟的工作者，則是職場的重要課題。
進入組織工作後，我們可能會發現SOP的仰賴是一種奢望，每次辦理的情形可能都不一樣。在面對問題時，需要自己思考Plan A&Plan B，清楚描述問題，跟解決計畫。
假設不幸有上過我的課，又剛好那堂課有說道管理、薪資，那我一定會告訴你各位：「單一薪俸制是最爛的薪酬制度」。拆解工資的目的是「管理」而非「成本」，將工資拆解後應設定明確、可執行的發給要件，當勞工滿足要件後即依約發給，常見的有：全勤獎金、業績獎金。若勞工未滿足特定標準，雇主即可不發給相應獎金。
※ 設計模式的五大精神介紹（S.O.L.I.D）：
※ 第一大精神 — S：單一職責原則（Single responsibility principle, SRP）
※ 定義：
每個物件，不管是類別或函數，都應該只負責一項功能。
當需求改變時，僅需改相關的區域，而不需要更動其他不相關的部分
責任制其實是勞基法第84-1條的俗稱，而適用勞基法第84-1條並代表可以非無法無天，適用84-1條的工作者雖然可以在「一定範圍內」，對於工作時間、例假...等工時條件「另行約定」，但依然有相應的規範予以制衡，勞工依然有工時上限、加班費與例假的規範，而非坊間誤解的「沒有加班費」、「做完為止」。
其實沒有任何一個計劃是誰應該一手包
也沒有人可以一手包
關鍵在於誰寫計畫而已
計畫是靠分工合作做起來的
是誰要當主導者而已
探討業務同仁「領多少薪水，做多少事」思維，文章指出這種觀念可能忽略工作的內在價值，僅以薪水衡量。薪水是否等同於工作價值，以及這種思維對未來的影響成為討論焦點。提倡超越薪水思維，挑戰傳統觀念，注重工作的滿足感和成就。勇敢探索個人工作價值，使工作不僅是換取薪水的交易，而成為實現夢想和發揮所長的平台。
在工作執行中，部門一定會遇到同仁請假或是人員異動，代理人機制設計可以降低同仁請假或是離職所產生的風險，也就是營運上作業風險。本文將會說明如何進行「代理人機制設計」。
在寫程式的過程中，你是否遇過一個類別或模組負責了太多事情，結果導致程式變得難以維護？這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時，改動可能會牽一髮動全身影響其他部分，這時候「單一職責原則 (SRP)」便派上用場。
單一職責原則是什麼？
簡單來說，單一
最初階的工作者專注於個人利益，對組織成就無感，而成熟工作者則能從組織及公司利益出發，人的初始設定就是自利，我們要如何擴大自己的格局，成為一位成熟的工作者，則是職場的重要課題。
進入組織工作後，我們可能會發現SOP的仰賴是一種奢望，每次辦理的情形可能都不一樣。在面對問題時，需要自己思考Plan A&Plan B，清楚描述問題，跟解決計畫。
假設不幸有上過我的課，又剛好那堂課有說道管理、薪資，那我一定會告訴你各位：「單一薪俸制是最爛的薪酬制度」。拆解工資的目的是「管理」而非「成本」，將工資拆解後應設定明確、可執行的發給要件，當勞工滿足要件後即依約發給，常見的有：全勤獎金、業績獎金。若勞工未滿足特定標準，雇主即可不發給相應獎金。
※ 設計模式的五大精神介紹（S.O.L.I.D）：
※ 第一大精神 — S：單一職責原則（Single responsibility principle, SRP）
※ 定義：
每個物件，不管是類別或函數，都應該只負責一項功能。
當需求改變時，僅需改相關的區域，而不需要更動其他不相關的部分
責任制其實是勞基法第84-1條的俗稱，而適用勞基法第84-1條並代表可以非無法無天，適用84-1條的工作者雖然可以在「一定範圍內」，對於工作時間、例假...等工時條件「另行約定」，但依然有相應的規範予以制衡，勞工依然有工時上限、加班費與例假的規範，而非坊間誤解的「沒有加班費」、「做完為止」。
其實沒有任何一個計劃是誰應該一手包
也沒有人可以一手包
關鍵在於誰寫計畫而已
計畫是靠分工合作做起來的
是誰要當主導者而已
探討業務同仁「領多少薪水，做多少事」思維，文章指出這種觀念可能忽略工作的內在價值，僅以薪水衡量。薪水是否等同於工作價值，以及這種思維對未來的影響成為討論焦點。提倡超越薪水思維，挑戰傳統觀念，注重工作的滿足感和成就。勇敢探索個人工作價值，使工作不僅是換取薪水的交易，而成為實現夢想和發揮所長的平台。
在工作執行中，部門一定會遇到同仁請假或是人員異動，代理人機制設計可以降低同仁請假或是離職所產生的風險，也就是營運上作業風險。本文將會說明如何進行「代理人機制設計」。