本筆記除了以文字說明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: ABC
Role Name: CEO
Interface Segregation Principle (ISP) 介面隔離原則
- 將龐大的介面拆分為更小且具體的介面，讓客戶只需實作他們需要的方法，不應有用不到的功能可以呼叫。
沿用上述code，修改成如下:
假設讀取報表(readReport)是祕書才會做的事，審核假單(verifyBreakLog)是主管才會做的事，對於主管(Director)來說，不需要readReport()這個方法，但卻被迫實作且可以呼叫不會使用的方法，這就違反了ISP原則。
為了符合ISP原則，將code改成如下，將AdminUsage拆的更小:
如此一來，秘書可以讀取報表，不需要去實作用不到的審核假單。
主管可以審核假單，不需要去實作用不到的讀取報表，也就符合了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/