設計模式 ----- 開篇

時間 2019-12-14

原文原文鏈接

設計模式並不是類庫

爲了方便地編寫java程序，咱們會使用類庫，但設計模式不是類庫。

與類型庫相比，設計模式是一個更爲廣泛的概念。類庫是由程序組合而成的組件，而設計模式則是來表現內

部組件是如何被組裝的，以及每個組件是如何經過相互關聯構成一個龐大的系統。

                                                 -- 引用自《圖解設計模式》 結城浩 著

起源

最先提出"設計模式"概念。是在1970年，由建築設計大師亞力山大Alexander<<建築的永恆之道>>描述：
     
模式是一條由三部分組成的經過規則：它表示了一個特定環境、一類問題和一個解決方案之間的關係。每個 模

式描述了一個不斷重複發生的問題，以及該問題解決方案的核心設計。在他的另外一本書<<建築者模式語言>>中提

到了如今已經定義的253種模式。

儘管Alexander的著做是針對建築領域的，但他的觀點適用於因此的工程設計領域，其中也包含軟件設 計

領域。"軟件設計模式"，這個術語是由1990年代由Erich Gamma等2 從建築設計領域引入到計算機科學中來的。

目前主要有23種。固然，設計模式不只僅中有23種。

這裏引用費馬理論：光線傳播的路徑是需時最少的路徑。而設計模式，在軟件開發中，可讓咱們少走不少

彎路，他是一套被反覆使用的、多數人知曉的、通過分類編目的、代碼設計經驗的總結。

軟件需求千變萬化，計劃沒有變化快，可是咱們仍是要尋找出不變的東西，並將它和變化的東西分離開來，

這須要很是的智慧和經驗。設計模式是在這方面開始探索的一塊里程碑。

爲了代碼可重用性、讓代碼更容易被他人理解、保證代碼可靠性。 設計模式使代碼編寫真正工程化；設計模

式是軟件工程的基石脈絡，如同大廈的結構同樣

設計原則

#1 單一職責原則( Single Responsibility Principle )

"一個類僅有一個職責"或者"引發類變化的只有一個緣由",這就是單一職責原理

就一個類而言，應該僅有僅有一個引發它變化的緣由。簡單來講，這個類應該是一組相關性很高的函數，數
     
據的封裝。單一職責的劃分界限並非總那麼清晰，不少的時候都是須要靠我的經驗去界定。

類只因一個類的緣由去變化，面對對象編程時，試圖把一個事物對象成一個類，事務這個類具有的功能都是

這個類的操做。好比。1塊錢，它既能夠買辣條，它也能夠去買小浣熊便利面等。而在單一職責原理下，錢的功能就

是引發這個類變化的兩個緣由，就應該寫成兩個類。

若是混在一塊兒寫，在修改的一個職責的時候，就會影響到另外一個職責。當另外一個類只使用其中一個職責的時
     
候，另外一不會用到的職責會消耗更多的資源。

#2 開閉原則( Open Close Principle )

"對於擴展是開放的，對於修改是關閉的",這就是開閉原則原理

開閉原則明確的告訴咱們：軟件實現應該對擴展開放，對修改關閉，其含義就是說：一個軟件應該經過

擴展來實現變化，而不是修改已有的代碼來實現變化的。
     
     打個比方：1塊錢，它既能夠買2包辣條。可是因爲物價上漲，如今只能買一塊。那麼根據開閉原則，你

並不能在原來的代碼中去修改已有的代碼。換句話說，如今是對已有代碼的一種修改，可是，若是他如今還能

界定他還能買一根香腸。那麼如今是對已經代碼的一種擴展。

若是直接修改代碼，那麼若是他要換回去怎麼辦，又去改回來？因此，開閉原則能夠提升程序的複用性、

維護性。

#3 里氏代換原則( Liskov Substitution Principle )

"任何基類能夠出現的地方，子類必定能夠出現。 里氏代換原則是繼承複用的基石，只有當衍生類能夠

替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新

的行爲"。

全部引用基類的地方必須透明的使用其子類的對象。

上兩點就是里氏代換原則。

打個比方：若是對每個類型爲"駝鳥"的對象a,都有類型爲"鳥"的對象b,使得以"鳥"定義的全部程序C在
    
全部的對象a都代換爲b,程序行爲沒有發生變化，那麼類型"駝鳥"是"鳥"的子類型。只要有"鳥"能出現的地方

"駝鳥"也能夠出現，並且替換爲子類不會產生任何的Error或Exception，可是，"駝鳥"出現的地 方，"鳥"未

必就能適應。

#4 依賴倒轉原則( Dependence Inversion Principle )

高層模塊不該該依賴低層模塊，二者都應該依賴其抽象

抽象不依賴實現

實現依賴抽象

以上三點就是依賴倒轉的原則，什麼意思呢？指的是模塊與模塊之間的信賴是經過抽象發生的，實現類之間
   
相互獨立，之間不發生直接的信賴關係，其依賴關係是經過接口或者抽象類產生的，接口或者抽象類不依賴實現，

實現依賴接口或者抽象類。更加精簡的意思叫作「面向接口編程」 。

採用依賴倒置原則能夠減小類間的耦合性，提升系統的穩定性，減小並行開發引發的風險，提升代碼的可讀性

和可維護性。

這裏打個比方：人，和一包笑笑牌辣條。建立一我的類A，裏面有一個吃辣條的動做a1方法，再來一個笑笑

牌辣條類B，裏面有一個打印辣條本身被吃的方法b1方法，再來一個終端，經過A.a1調用B.b1，這裏咱們能夠發

現，這我的吃辣條這個場景，人類A和笑笑牌辣條類B之間是一個緊耦合的關係，假如咱們這裏還有一個只吃花生

的人，怎麼辦?若是這裏把這個動做抽象化，定義一個接口C，接口C中有一個吃的方法，而後建立一個花生類，

裏面有一個本身被吃的打印方法c1。之後若是還有別的功能，那麼實現接口。就能夠了。同理，若是這裏人分爲

大人和小人，那麼就能夠定義一個抽象類（人），而後再定義一個兩個類大人和小孩，繼承這個類。這樣一來，

咱們這個場景就能夠減小類間的耦合性，提升系統穩定性，減小並行開發引發的風險，提升代碼的可讀性和可維

護性覺得可擴展性。

#5 接口隔離原則( InterfaceSegregation Principles )

客戶端不該該依賴它不須要的接口

一個類對另外一個類的依賴應該創建在最小的接口上

這裏的意思是創建單一的接口，接口儘可能細化，若是有不須要的接口，客戶端須要什麼接口，就給什麼接 

口，把不須要的接口剔除了。---

接口隔離原則與單一職責原則有什麼區別

接口隔離原則與單一職現原則其實也沒有，主要是角度不同，單一職責原則要求類和接口只應該響應一

個變化，接口隔離原則要求接口的方法儘量少，儘量的去細化

總之呢：接口要儘可能小，接口要高內聚，接口設計是有限度的。一個接口只服務一地一個子模塊或者業務。

這個要劃分開了，不要糅合在一塊兒。接口要不斷的精簡，使之更加完善。若是接口是壞的，改之。若是背鍋的

可能性大。就採用適配器去處理。儘可能不要去背鍋，這個會很難受。

#6 迪米特原則 ( Law of Demeter )

這個也叫最少知識原則(Low knowledge Principle)。最先是在1987年由美國Northeastern 

University的Ian Holland提出。類與類之間的關係越好(緊密)，耦合度越高（大），當一個類發生改變時，

對另外一個類的影響也越大。因而就提出了迪米特法則。通俗的來說，就是一個類對本身依賴的類知道的越少越

好。也就是說，對於被依賴的類來講，不管邏輯多麼複雜，都儘可能地的將邏輯封裝在類的內部，對外除了提供

的public方法，不對外泄漏任何信息。

打個比方，有一個辣條類，老闆叫員工去清算辣條的包數。這裏咱們建立一個辣條類A,建立一個員工類B,

裏面有一個接收辣條列表參數功能爲清算辣條數量的方法b1。而後咱們一個老闆類C，裏面有一個功能爲命令

員工清算辣條的方法c1。裏面初始化了辣條的數量。咱們經過調用這個命令來達到清算辣條的數量。這裏是我

們常常作的，沒有不同，可是咱們能夠發現，這裏老闆竟然去初始化辣條。這裏就有違反了迪米特原則。它

破壞了老闆類的健壯性。咱們只須要在老闆類中寫一個命令的方法就能夠了，只調用員工清算的方法就能夠了

，讓main方法（客戶端）去建立辣條。這樣就保證了類與類之間的健壯性。

總之核心觀念就是類間解耦，弱耦合，只有弱耦合後，類的複用率才能夠提升。其結果就是產生了大量的

中轉或跳轉類，致使系統複雜，爲維護帶來了難度。因此，咱們在實踐時要反覆權衡，即要讓結構清晰，又作

到高內聚低耦合。

設計模式就是實現了這些原則，從而達到了代碼複用、增長可維護性的目的

設計模式是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了
  
  可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性

參考

幾種常見的設計模式html

若是有侵權，立刻刪除java

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。