摘要：面向?qū)ο笤O(shè)計模式通常以類別或?qū)ο髞砻枋銎渲械年P(guān)系和相互作用，但不涉及用來完成應(yīng)用程序的特定類別或?qū)ο?。里氏代換原則里氏代換原則是面向?qū)ο笤O(shè)計的基本原則之一。

通俗易懂的設(shè)計模式

零、使用

1、安裝

2、測試

一、什么是設(shè)計模式

二、設(shè)計模式的類型

三、設(shè)計模式的六大原則

四、UML類圖

1、看懂UML類圖

2、解釋

五、資料

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

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

設(shè)計模式（Design pattern）代表了最佳的實踐，通常被有經(jīng)驗的面向?qū)ο蟮能浖_發(fā)人員所采用。設(shè)計模式是軟件開發(fā)人員在軟件開發(fā)過程中面臨的一般問題的解決方案。這些解決方案是眾多軟件開發(fā)人員經(jīng)過相當(dāng)長的一段時間的試驗和錯誤總結(jié)出來的。

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

創(chuàng)建型模式（Creational）：這些設(shè)計模式提供了一種在創(chuàng)建對象的同時隱藏創(chuàng)建邏輯的方式，而不是使用 new 運算符直接實例化對象。這使得程序在判斷針對某個給定實例需要創(chuàng)建哪些對象時更加靈活

簡單工廠模式（Simple Factory Pattern） 傳送門

抽象方法模式（Factory Method Pattern） 傳送門

抽象工廠模式（Abstract Factory Pattern） 傳送門

單例模式（Singleton Pattern） 傳送門

建造者模式（Builder Pattern） 傳送門

原型模式（Prototype Pattern） PHP使用clone即可實現(xiàn)，目的是減少開銷

結(jié)構(gòu)型模式（Structural）：這些設(shè)計模式關(guān)注類和對象的組合。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式

適配器模式（Adapter Pattern） 傳送門

橋接模式（Bridge Pattern） 傳送門

裝飾器模式（Decorator Pattern） 傳送門

外觀模式（Facade Pattern） 傳送門

享元模式（Flyweight Pattern） 傳送門

代理模式（Proxy Pattern） 傳送門

行為型模式（Behavioral）：這些設(shè)計模式特別關(guān)注對象之間的通信

責(zé)任鏈模式（Chain of Responsibility Pattern） 傳送門

命令模式（Command Pattern） 傳送門

迭代器模式（Iterator Pattern） 傳送門

備忘錄模式（Memento Pattern） 傳送門

觀察者模式（Observer Pattern） 傳送門

狀態(tài)模式（State Pattern） 傳送門

策略模式（Strategy Pattern） 傳送門

訪問者模式（Visitor Pattern） 傳送門

模板方法模式（Template Method Pattern） 傳送門

開閉原則（Open Close Principle）

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

里氏代換原則（Liskov Substitution Principle）

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

依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）

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

接口隔離原則（Interface Segregation Principle）

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

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

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

合成復(fù)用原則（Composite Reuse Principle）

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

一個簡單的栗子

車的類圖結(jié)構(gòu)為abstract，表示車是一個抽象類

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

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

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

學(xué)生與班級之間是聚合關(guān)系，使用帶空心箭頭的實線表示

學(xué)生與身份證之間為關(guān)聯(lián)關(guān)系，使用一根實線表示

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

實現(xiàn)關(guān)系是繼承自抽象類，泛化關(guān)系是繼承自非抽象類

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

聚合是不是強依賴的，比如上圖中的一個班級由學(xué)生構(gòu)成，班級不在了，學(xué)生還在

關(guān)聯(lián)關(guān)系是強關(guān)聯(lián)的，比如上圖中學(xué)生跟身份證關(guān)聯(lián)了，可以說是身份證可以代表學(xué)生，學(xué)生也能代表身份證

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

圖說設(shè)計模式

design-patterns-for-humans

DesignPatternsPHP

UML軟件