讀「SOLID」的設計原則記錄

閱讀連接：https://xueyuanjun.com/post/9719

單一職責原則（Single Responsibility Principle）

        一個類只作某一件事。

        例：操做訂單時咱們須要查詢數據進行驗證 若是在訂單類中直接查詢MySql數據庫就意味着 數據存儲方式發生改變這裏也須要改代碼 這時咱們能夠另起一個訂單資料類進行調用保存數據 這樣咱們的代碼就 更清晰、更容易維護、更加解耦、更容易測試

 

開放封閉原則（Open Closed Principle）

        對擴展是開放的，對修改是封閉的。

        例：咱們須要驗證訂單，訂單驗證又隨着業務規則改變，隨着業務的增加就須要增長一大推新規則，代碼必須隨着每次業務規則的改變而改變 這樣是對修改開放的就違反了開放封閉原則。咱們能夠：定義訂單驗證接口 --> 封裝訂單處理器 --> 每個訂單驗證接口的實例注入到訂單處理器中 --> 訂單操做時調用訂單處理器

 

里氏替換原則（Liskov Substitution Principle）

        對象能夠被其子類的實例所替換，而且不會影響到程序的正確性。

        例：原來的訂單數據存儲到了 CSV 格式的文件系統中（CsvOrderRepository ），如今須要更換存儲方式，存到關係數據庫中（DatabaseOrderRepository ）。原來的CSV文件系統不須要帳戶密碼而關係數據庫須要，若是在OrderProcessor處驗證是否調用了關係型數據並傳帳號密碼，就違反了里氏替換原則。DatabaseOrderRepository須要本身接管數據庫帳號密碼以及鏈接，這樣咱們就能夠在 CsvOrderRepository 和 DatabaseOrderRepository 實現之間進行切換了，不用對 OrderProcessor 作任何修改

若是不遵照里氏替換原則，那麼可能會影響到咱們以前已經討論過的其餘原則。不遵照里氏替換原則，那麼開放封閉原則必定也會被打破。由於，若是調用者必須檢查實例屬於哪一個子類，則一旦有了新的子類，調用者就得作出改變。

 

接口隔離原則（Interface Segregation Principle）

        不該該強制接口的實現依賴於它不使用的方法。在實際操做中，這個原則要求接口必須粒度很細，且專一於一個領域。調用方只須要依賴它就能夠了，而沒必要去依賴包含多個領域的接口。

 

依賴反轉原則（Dependency Inversion Principle）

        高層次的代碼不該該依賴低層級的代碼，高層次的代碼應該依賴抽象接口。低層次代碼用於實現一些底層的基本操做，好比從磁盤讀文件、操做數據庫等。高層次代碼用於封裝複雜的業務邏輯而且依靠低層次代碼來實現功能，但不能直接和低層次代碼耦合在一塊兒。

       反轉的思想：使用這一原則會反轉不少開發者設計應用的方式。再也不將高層次代碼直接和低層次代碼以「自上而下」的方式耦合在一塊兒，這個原則規定不論高層級仍是低層次代碼都要依賴於一個高層次的抽象，從而使得低層次代碼依賴於高層次代碼的需求抽象。

 

 

全部五個「SOLID」原則都是相關的，也就是說違背了其中一個原則，一般意味着也違背了其餘的原則。當你違背了接口隔離原則，確定也違背了單一職責原則。