本筆記除了以文字說明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原則。
本筆記參考: