摘要：面向對象設計模式通常以類別或對象來描述其中的關系和相互作用，但不涉及用來完成應用程序的特定類別或對象。里氏代換原則里氏代換原則是面向對象設計的基本原則之一。

通俗易懂的設計模式

零、使用

1、安裝

2、測試

一、什么是設計模式

二、設計模式的類型

三、設計模式的六大原則

四、UML類圖

1、看懂UML類圖

2、解釋

五、資料

前言：花了一些時間再次熟悉了一遍設計模式，主要是參考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/

摘自wiki：

在軟件工程中，設計模式（design pattern）是對軟件設計中普遍存在（反復出現）的各種問題，所提出的解決方案。這個術語是由埃里希·伽瑪（Erich Gamma）等人在1990年代從建筑設計領域引入到計算機科學的。
設計模式并不直接用來完成代碼的編寫，而是描述在各種不同情況下，要怎么解決問題的一種方案。面向對象設計模式通常以類別)或對象)來描述其中的關系和相互作用，但不涉及用來完成應用程序的特定類別或對象。設計模式能使不穩定依賴于相對穩定、具體依賴于相對抽象，避免會引起麻煩的緊耦合，以增強軟件設計面對并適應變化的能力。
并非所有的軟件模式都是設計模式，設計模式特指軟件“設計”層次上的問題。還有其他非設計模式的模式，如架構模式。同時，算法不能算是一種設計模式，因為算法主要是用來解決計算上的問題，而非設計上的問題。
隨著軟件開發社群對設計模式的興趣日益增長，已經出版了一些相關的專著，定期召開相應的研討會，而且沃德·坎寧安（Ward Cunningham）為此發明了WikiWiki用來交流設計模式的經驗。

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

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

創建型模式（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） 傳送門

開閉原則（Open Close Principle）

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

里氏代換原則（Liskov Substitution Principle）

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

依賴倒轉原則（Dependence Inversion Principle）

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

接口隔離原則（Interface Segregation Principle）

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

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

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

合成復用原則（Composite Reuse Principle）

合成復用原則是指：盡量使用合成/聚合的方式，而不是使用繼承。

一個簡單的栗子

車的類圖結構為abstract，表示車是一個抽象類

它有兩個繼承類：小汽車和自行車，它們之間的關系為實現關系，使用帶空心箭頭的虛線表示

小汽車為與SUV之間也是繼承關系，它們之間的關系為泛化關系，使用帶空心箭頭的實線表示

小汽車與發動機和輪胎之間是組合關系，使用帶實心箭頭的實線表示

學生與班級之間是聚合關系，使用帶空心箭頭的實線表示

學生與身份證之間為關聯關系，使用一根實線表示

學生上學需要用到自行車，與自行車是一種依賴關系，使用帶箭頭的虛線表示

實現關系是繼承自抽象類，泛化關系是繼承自非抽象類

組合關系是強依賴的，比如上圖中的小汽車由發動機和輪胎組成，小汽車不在了，發動機和輪胎也是不存在了

聚合是不是強依賴的，比如上圖中的一個班級由學生構成，班級不在了，學生還在

關聯關系是強關聯的，比如上圖中學生跟身份證關聯了，可以說是身份證可以代表學生，學生也能代表身份證

依賴關系一般是單向的，雙向依賴是非常糟糕的，比如上圖中學生依賴自行車，但是自行車依賴學生是說不通的，同時學生也可以依賴價值百萬的公交車或價值上億的地鐵，只是臨時性的依賴

圖說設計模式

design-patterns-for-humans

DesignPatternsPHP

UML軟件