通俗易懂的設計模式

• 通俗易懂的設計模式
  • 零、使用
    • 一、安裝
    • 二、測試
  • 1、什麼是設計模式
  • 2、設計模式的類型
  • 3、設計模式的六大原則
  • 4、UML類圖
    • 一、看懂UML類圖
    • 二、解釋
  • 5、資料

前言：花了一些時間再次熟悉了一遍設計模式，主要是參考design-patterns-for-humans，也有了一些感悟，本人能力有限，如遇到什麼不對的地方還望指出修正，謝謝

有收穫的話請加顆小星星，沒有收穫的話能夠 反對 沒有幫助 舉報三連

• 倉庫地址
• 博客原文

零、使用

一、安裝

composer create-project -s dev omgzui/design-pattern
複製代碼

or

git clone https://github.com/OMGZui/DesignPattern
composer install
複製代碼

二、測試

vendor/bin/phpunit tests/
複製代碼

1、什麼是設計模式

摘自wiki：

在軟件工程中，設計模式（design pattern）是對軟件設計中廣泛存在（反覆出現）的各類問題，所提出的解決方案。這個術語是由埃裏希·伽瑪（Erich Gamma）等人在1990年代從建築設計領域引入到計算機科學的。

設計模式並不直接用來完成代碼的編寫，而是描述在各類不一樣狀況下，要怎麼解決問題的一種方案。面向對象設計模式一般以類別或對象來描述其中的關係和相互做用，但不涉及用來完成應用程序的特定類別或對象。設計模式能使不穩定依賴於相對穩定、具體依賴於相對抽象，避免會引發麻煩的緊耦合，以加強軟件設計面對並適應變化的能力。

並不是全部的軟件模式都是設計模式，設計模式特指軟件「設計」層次上的問題。還有其餘非設計模式的模式，如架構模式。同時，算法不能算是一種設計模式，由於算法主要是用來解決計算上的問題，而非設計上的問題。

隨着軟件開發社羣對設計模式的興趣日益增加，已經出版了一些相關的專著，按期召開相應的研討會，並且沃德·坎寧安（Ward Cunningham）爲此發明了WikiWiki用來交流設計模式的經驗。

設計模式（Design pattern）表明了最佳的實踐，一般被有經驗的面向對象的軟件開發人員所採用。設計模式是軟件開發人員在軟件開發過程當中面臨的通常問題的解決方案。這些解決方案是衆多軟件開發人員通過至關長的一段時間的試驗和錯誤總結出來的。

簡而言之設計模式就是一套解決方案，目的是爲了重用代碼，同時也能保證代碼的可靠性

2、設計模式的類型

• 建立型模式（Creational）：這些設計模式提供了一種在建立對象的同時隱藏建立邏輯的方式，而不是使用 new 運算符直接實例化對象。這使得程序在判斷針對某個給定實例須要建立哪些對象時更加靈活
  • 簡單工廠模式（Simple Factory Pattern） 傳送門
  • 抽象方法模式（Factory Method Pattern） 傳送門
  • 抽象工廠模式（Abstract Factory Pattern） 傳送門
  • 單例模式（Singleton Pattern） 傳送門
  • 建造者模式（Builder Pattern） 傳送門
  • 原型模式（Prototype Pattern） PHP使用clone便可實現，目的是減小開銷
• 結構型模式（Structural）：這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象得到新功能的方式
  • 適配器模式（Adapter Pattern） 傳送門
  • 橋接模式（Bridge Pattern） 傳送門
  • 裝飾器模式（Decorator Pattern） 傳送門
  • 外觀模式（Facade Pattern） 傳送門
  • 享元模式（Flyweight Pattern） 傳送門
  • 代理模式（Proxy Pattern） 傳送門
• 行爲型模式（Behavioral）：這些設計模式特別關注對象之間的通訊
  • 責任鏈模式（Chain of Responsibility Pattern） 傳送門
  • 命令模式（Command Pattern） 傳送門
  • 迭代器模式（Iterator Pattern） 傳送門
  • 備忘錄模式（Memento Pattern） 傳送門
  • 觀察者模式（Observer Pattern） 傳送門
  • 狀態模式（State Pattern） 傳送門
  • 策略模式（Strategy Pattern） 傳送門
  • 訪問者模式（Visitor Pattern） 傳送門
  • 模板方法模式（Template Method Pattern） 傳送門

3、設計模式的六大原則

• 開閉原則（Open Close Principle）

開閉原則的意思是：對擴展開放，對修改關閉。在程序須要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。簡言之，是爲了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，咱們須要使用接口和抽象類，後面的具體設計中咱們會提到這點。

• 里氏代換原則（Liskov Substitution Principle）

里氏代換原則是面向對象設計的基本原則之一。 里氏代換原則中說，任何基類能夠出現的地方，子類必定能夠出現。LSP 是繼承複用的基石，只有當派生類能夠替換掉基類，且軟件單位的功能不受到影響時，基類才能真正被複用，而派生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對開閉原則的補充。實現開閉原則的關鍵步驟就是抽象化，而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。

• 依賴倒轉原則（Dependence Inversion Principle）

這個原則是開閉原則的基礎，具體內容：針對接口編程，依賴於抽象而不依賴於具體。

• 接口隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。它還有另一個意思是：下降類之間的耦合度。因而可知，其實設計模式就是從大型軟件架構出發、便於升級和維護的軟件設計思想，它強調下降依賴，下降耦合。

• 迪米特法則，又稱最少知道原則（Demeter Principle）

最少知道原則是指：一個實體應當儘可能少地與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。

• 合成複用原則（Composite Reuse Principle）

合成複用原則是指：儘可能使用合成/聚合的方式，而不是使用繼承。

4、UML類圖

一、看懂UML類圖

一個簡單的栗子

• 車的類圖結構爲abstract，表示車是一個抽象類
• 它有兩個繼承類：小汽車和自行車，它們之間的關係爲實現關係，使用帶空心箭頭的虛線表示
• 小汽車爲與SUV之間也是繼承關係，它們之間的關係爲泛化關係，使用帶空心箭頭的實線表示
• 小汽車與發動機和輪胎之間是組合關係，使用帶實心箭頭的實線表示
• 學生與班級之間是聚合關係，使用帶空心箭頭的實線表示
• 學生與身份證之間爲關聯關係，使用一根實線表示
• 學生上學須要用到自行車，與自行車是一種依賴關係，使用帶箭頭的虛線表示

二、解釋

• 實現關係是繼承自抽象類，泛化關係是繼承自非抽象類
• 組合關係是強依賴的，好比上圖中的小汽車由發動機和輪胎組成，小汽車不在了，發動機和輪胎也是不存在了
• 聚合是否是強依賴的，好比上圖中的一個班級由學生構成，班級不在了，學生還在
• 關聯關係是強關聯的，好比上圖中學生跟身份證關聯了，能夠說是身份證能夠表明學生，學生也能表明身份證
• 依賴關係通常是單向的，雙向依賴是很是糟糕的，好比上圖中學生依賴自行車，可是自行車依賴學生是說不通的，同時學生也能夠依賴價值百萬的公交車或價值上億的地鐵，只是臨時性的依賴

5、資料

• 圖說設計模式
• design-patterns-for-humans
• DesignPatternsPHP
• UML軟件