設計模式學習

設計模式的6大設計原則

• 單一職責原則       

           單一職責原則：Simple Responsibility Principle  簡稱 SRP

                這個原則比較難定義，可是也是比較好理解的。簡單來講就是接口要作到職責分明，什麼該作什麼不應作要分清楚。

                單一職責的好處

                        類的複雜性下降，實現什麼的職責都有清晰明確的定義

                        可讀性提升，複雜性下降

                        可維護性提升，可讀性提供

                        更變引發的風險下降

• 里氏替換原則

           里氏替換原則  (Liskov Substitution Principle , LSP)   

          第一種定義：若是對每一個類型爲S的對象o1,都有類型爲T的對象o2,使得以T定義的全部程序P在全部的對象o1都替換成o2時，程序P的行爲沒有發生變化，那麼S是T的子類型。

          第二種定義：全部引用基類的地方必須能透明地使用其子類的對象。

          官方的說明太官方了。。。簡單來講，只要父類能出現的地方子類就能夠出現，並且替換成子類也不會產生任何的錯誤或者異常。（給我最直接的感受就是里氏替換原則就是爲JAVA裏的繼承定義了一個規範，

          在JAVA裏的繼承，子類能夠強制轉換成父類，父類不能強制轉換成子類）

• 依賴倒置原則

          依賴倒置原則 （Dependence Inversion Principle , DIP） 

          依賴倒置原則原始定義是 ： High level modules should not depend upon low level modules . Both should depend upon abstractions . Abstractions should not depend upon details . Details should depend upon  abstractions.

          很容易理解，高層模塊不該該依賴底層模塊，二者都應該依賴其抽象，抽象不該該依賴細節，細節應該依賴抽象。從JAVA的方向看，模塊間的依賴經過抽象過程，實現類之間不發生直接的依賴關係，其依賴關係   是經過接口和抽象產生的；接口或抽象類不依賴實現類，實現類依賴接口或抽象類。（這不就是面對接口編程的精髓嗎？）

         採用依賴倒置原則的本質就是經過抽象（接口或抽象類）使各個類或模塊的實現彼此獨立，能夠減小類之間的耦合性，提升系統的穩定性，下降並行開發引發的風險，提升代碼的可讀性和可維護性。

 

• 接口隔離原則

          接口隔離原則第一種定義：客戶端不該該依賴它不須要的接口，第二種定義：類間的依賴關係應該創建在最小的接口上。簡單的來講就是創建接口要儘可能細化，同時接口中的方法儘可能少。看起來與單一職責原則很  像，其實兩個原則的審視角度不相同，單一職責要求的是類和接口的職責單一，注重的是職責，是業務邏輯上的劃分，而接口隔離原則要求接口的方法儘量少（拆分接口時必須知足單一職責原則），接口要高內聚，定製服務，接口設計是有限度的（並非越小越好，要根據實情去設計）

• 迪米特法則

         迪米特法則（Law of Demeter , LoD）也稱爲最少知識原則

         定義：一個對象應該對其餘對象有最少的瞭解，通俗地說，一個類應該對本身須要耦合或調用的類知道得最少（被調用的類邏輯多複雜跟你不要緊，你只是調用它提供的方法而已）

         迪米特法則的核心觀念是類間解耦，弱耦合，只有弱耦合了之後，類的複用率才能夠提升

• 開閉原則

         開閉原則定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。（通俗講一個程序應該經過擴展來實現變化，而不是經過修改已存在的代碼來實現變化）