Notes - Design Pattern 中的 SOLID
這邊簡單整理一下設計模式上的"五大原則"，以用來達成「高內聚，低耦合」的目標。
單一職責原則 SRP
一個類別(模組)只專注做一件事情。例如關於使用者帳號的 UserService (使用者模組)以及 PayService (繳款模組) 兩者所做的事情、行為不同，不應該放在同一個模組當中。
開放-封閉原則 OCP
類別(模組)對外開放擴充，對內封閉不修改。例如同樣都是更新 User 的資料(透過 UserService)，但原本使用者角色只有 Student (學生)，而現在必須增加 Employee (教職員工)且須寫到不同的欄位及資料庫，此時不應該直接修改 UserService 當中的功能，而是建立新的類別(模組)來處理。(面對這種案例，我會將 UserService 寫成 Interface — IUserService 並針對 Student 以及 Employee 分別繼承 Interface 並實作)
里氏替換原則 LSP
子類別(模組)可以擴充父類別(模組)，但不能修改父類別原有的功能。例如教師跟職員都是 Employee，但是教師需要教學而職員不用。此時若 Employee類別有一個 Teaching 的方法，就必須覆寫 Teaching 方法，這樣就違反了 LSP，最好將教師跟職員分別拆開為新類別。
介面隔離原則 ISP
類別不應該去依賴他不需要的方法。例如成績系統模組，可以對成績查詢、更新及刪除，但是顯然學生不應該去更新及刪除成績，所以必須透過 Interface 方式將學生與教師、職員隔離。
依賴反轉原則DIP
高階模組不依賴低階模組，兩者皆依賴抽象介面；抽象介面不依賴具體實作，而具體實作應依賴抽象介面。
低階 vs. 高階
低階模組實作的都是不可分割的原子邏輯(最小單位)，如 Model。而高階多由低階模組組合而成(如 controller 、 service)。
例如常見的 Database 連線，由於每個 DB 都有不同的 driver ，如果今天將 database 直接依賴實作，意味著我更換 DB 的時候必須直接修改每個使用到 database 這個類別的地方，這樣耦合度非常高。
這一篇先寫到這邊，未來我也會更新一些看過的設計模式喔！
