導語：設計模式和架構模式對於軟件開發人員來說是很重要的兩個概念。但它們又對很多程序員來說是很模糊的概念。模糊，是因為寫代碼時根據前輩的經驗而使用了某種設計模式或架構模式，卻知其然而不知其所以然。在這裡，拾人牙慧，記錄一些有關於設計模式和架構模式的基礎知識和個人理解。

參考文檔：

php 設計模式全集：

https://learnku.com/docs/php-design-patterns/2018/Builder/1488

軟件設計模式概述

http://c.biancheng.net/view/1317.html

軟件架構模式：

https://colobu.com/2015/04/08/software-architecture-patterns/

常見的軟件架構模式：

https://www.cnblogs.com/IcanFixIt/p/7518146.html

1、定義及區別

模式（Pattern）事物的標準樣式。其實就是解決某一類問題的方法論。把解決某類問題的方法總結歸納到理論高度，那就是模式。模式是一種指導，在一個良好的指導下，有助於你完成任務，有助於你作出一個優良的設計方案，達到事半功倍的效果。而且會得到解決問題的最佳辦法。

1.1、什麼是設計模式

軟件設計模式（Design pattern），又稱設計模式，是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。

設計模式的本質是面向對象設計原則的實際運用，是對類的封裝性、繼承性和多態性以及類的關聯關係和組合關係的充分理解。

從設計模式的定義來看，設計模式並非是必須的。

沒有了設計模式和下文的架構模式，程序也可以正常開發和運行。

例如下文代碼：

http://thumb.liyulinbill.com/upload/attachment/saas_mTiikMvYZq_php_html.rar

detail.php文件代碼：

```

<code>


 

content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">

$data = $_GET;
if(!isset($data['id'])||!$data['id']){
var_dump('404');die;
}
//連接mysql數據庫
$con = mysql_connect('localhost','root','liyulin');
if(!$con){
die('Could not connect: ' . mysql_error($con));
}
//選擇數據庫
mysql_select_db('test',$con);
?>
<title>文章詳情頁面/<title>



$sql = "SELECT * FROM article";
$result = mysql_query($sql);
$detail = mysql_fetch_object($result);
?>

title; ?>


content;?>






我要評論 






確認評論




mysql_close($con);
?>



/<code>

```

detail.php 的代碼是可以正常運行的，代碼中包含了 php、css、html、js、mysql 各種原生寫法，沒有任何的設計模式。對於程序員而言，這段代碼是耦合度很高的，不可重用的，甚至是可讀性很差的（有可能只知道前端知識的開發人員，是不能理解php部分的代碼的）。

假如使用了設計模式和架構模式，對detail.php 代碼進行最簡單的處理：

```

<code> 





include 'db.php';//php數據庫部分
?>
<title>文章詳情頁面/<title>
<link>


include 'controller.php';//php邏輯部分
?>



/<code>

```

把css部分的代碼，寫入到.css 的文件裡，把js部分的代碼寫入到.js文件裡，把php部分的代碼寫入到.php文件裡，數據庫部分的代碼寫入到和數據庫有關的執行文件裡，再找個入口，把這些引用進來，展現出來。對瀏覽器而言，整理後的代碼和detail.php 放在一起的代碼沒什麼區別，但對開發人員而言，代碼分出了層次和結構、易讀且可複用。

在本文detail.php一個文件就是一個程序，在實際開發應用中，複雜的軟件則可能涉及到成千上萬個文件或者功能模塊、組件、應用子系統，而設計模式和架構模式，就是對代碼以及整體系統的”分析整理”。

對於簡單的程序開發，可能寫一個簡單的算法要比引入某種設計模式更加容易。但對大項目的開發或者框架設計，用設計模式來組織代碼顯然更好。

1.2、什麼是架構模式

架構模式，也叫架構風格，一個架構模式描述軟件系統裡的基本的結構組織或綱要。架構模式提供一些呈先定義好的子系統，指定它們的責任，並給出把它們組織在一起的法則和指南。一個架構模式常常可以分解成很多個設計模式的聯合使用。

1.3、設計模式和架構模式的區別

設計模式 < 架構模式

a、從複用角度講，設計模式是代碼級複用、架構是系統級複用

b、從解決問題角度講，設計模式針對特定的場景特定的問題提出的解決方案，架構模式則是闡述各個組件之間的通信、層次劃分的體系結構設計。簡言之，設計模式的範圍較小，架構模式的範圍較大。

2、常用的設計模式

前人總結，模式可以分為三個大類。

a、創建型

在軟件工程中，創建型設計模式是處理對象創建機制的設計模式，試圖以適當的方式來創建對象。對象創建的基本形式可能會帶來設計問題，亦或增加了設計的複雜度。創建型設計模式通過控制這個對象的創建方式來解決此問題。

b、結構型

在軟件工程中，結構型設計模式是通過識別實體之間關係來簡化設計的設計模式。

c、行為型

在軟件工程中，行為設計模式是識別對象之間的通用通信模式並實現這些模式的設計模式。 通過這樣做，這些模式增加了執行此通信的靈活性。

2.1、創建型

建造者模式（Builder）

多例模式（Multiton）

單例模式（Singleton）

對象池模式（Pool）

原型模式（Prototype）

簡單工廠模式（Simple Factory）

靜態工廠模式（Static Factory）

抽象工廠模式（Abstract Factory）

工廠方法模式（Factory Method）

2.2、結構型

適配器模式（Adapter）

橋樑模式（Bridge）

組合模式（Composite）

數據映射模式（Data Mapper）

裝飾模式（Decorator）

依賴注入模式（Dependency Injection）

門面模式（Facade）

流接口模式（Fluent Interface）

享元模式（Flyweight）

代理模式（Proxy）

註冊模式（Registry）

2.3、行為型

責任鏈模式（Chain of Responsibilities）

命令行模式（Command）

迭代器模式（Iterator）

中介者模式（Mediator）

備忘錄模式（Memento）

空對象模式（Null Object）

觀察者模式（Observer）

狀態模式（State）

策略模式（Strategy）

模板方法模式（Template Method）

訪問者模式（Visitor）

能把這些模式都試一遍，瞭解一遍的同學，基本上都是對敲代碼真愛的了。以上詳解：

，一般是天才或者都使用過這些模式的人。

2.4、軟件開發原則

a、開閉原則（Open Closed Principle，OCP）

軟件實體應當對擴展開放，對修改關閉。

b、里氏替換原則（Liskov Substitution Principle，LSP）

繼承必須確保超類所擁有的性質在子類中仍然成立。通俗來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。

c、依賴倒置原則（Dependence Inversion Principle，DIP）

高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象。核心思想：要面向接口編程，不要面向實現編程。

d、單一職責原則（Single Responsibility Principle，SRP）

一個類應該有且僅有一個引起它變化的原因，否則類應該被拆分。大致意思是：對象不應該承擔太多職責。

e、接口隔離原則（Interface Segregation Principle，ISP）

客戶端不應該被迫依賴於它不使用的方法。一個類對另一個類的依賴應該建立在最小的接口上。其含義是：要為各個類建立它們需要的專用接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。

f、迪米特法則（Law of Demeter，LoD）

只與你的直接朋友交談，不跟“陌生人”說話。其含義是：如果兩個軟件實體無須直接通信，那麼就不應當發生直接的相互調用，可以通過第三方轉發該調用。其目的是降低類之間的耦合度，提高模塊的相對獨立性。

g、合成複用原則（Composite Reuse Principle，CRP）

在軟件複用時，要儘量先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現。

總結：這 7 種設計原則是軟件設計模式必須儘量遵循的原則，各種原則要求的側重點不同。其中，開閉原則是總綱，它告訴我們要對擴展開放，對修改關閉；里氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口編程；單一職責原則告訴我們實現類要職責單一；接口隔離原則告訴我們在設計接口的時候要精簡單一；迪米特法則告訴我們要降低耦合度；合成複用原則告訴我們要優先使用組合或者聚合關係複用，少用繼承關係複用。

3、常見的軟件架構模式

a、分層模式

這種模式也稱為多層體系架構模式。它可以用來構造可以分解為子任務組的程序，每個子任務都處於一個特定的抽象級別。每個層都為下一個提供更高層次服務。

b、客戶端-服務器模式

這種模式由兩部分組成：一個服務器和多個客戶端。服務器組件將為多個客戶端組件提供服務。客戶端從服務器請求服務，服務器為這些客戶端提供相關服務。此外，服務器持續偵聽客戶機請求。

c、主從設備模式

這種模式由兩方組成;主設備和從設備。主設備組件在相同的從設備組件中分配工作，並計算最終結果，這些結果是由從設備返回的結果。

d、管道-過濾器模式

此模式可用於構造生成和處理數據流的系統。每個處理步驟都封裝在一個過濾器組件內。要處理的數據是通過管道傳遞的。這些管道可以用於緩衝或用於同步。

e、代理模式

此模式用於構造具有解耦組件的分佈式系統。這些組件可以通過遠程服務調用彼此交互。代理組件負責組件之間的通信協調。

服務器將其功能(服務和特徵)發佈給代理。客戶端從代理請求服務，然後代理將客戶端重定向到其註冊中心的適當服務。

f、點對點模式

在這種模式中，單個組件被稱為對等點。對等點可以作為客戶端，從其他對等點請求服務，作為服務器，為其他對等點提供服務。對等點可以充當客戶端或服務器或兩者的角色，並且可以隨時間動態地更改其角色。

g、事件總線模式

這種模式主要是處理事件，包括4個主要組件：事件源、事件監聽器、通道和事件總線。消息源將消息發佈到事件總線上的特定通道上。偵聽器訂閱特定的通道。偵聽器會被通知消息，這些消息被髮布到它們之前訂閱的一個通道上。

h、模型-視圖-控制器模式

也被稱為MVC模式，把一個交互式應用程序劃分為3個部分：

1、模型：包含核心功能和數據

2、視圖：將信息顯示給用戶(可以定義多個視圖)

3、控制器：處理用戶輸入的信息

這樣做是為了將信息的內部表示與信息的呈現方式分離開來，並接受用戶的請求。它分離了組件，並允許有效的代碼重用。用戶操作->View（負責接收用戶的輸入操作）->Controller（業務邏輯處理）->Model（數據持久化）->View（將結果反饋給View）。

還有與之相提並論的MVP和MVVM模式：

MVP是把MVC中的Controller換成了Presenter（呈現），目的就是為了完全切斷View跟Model之間的聯繫，由Presenter充當橋樑，做到View-Model之間通信的完全隔離

MVVM模式，它是將“數據模型數據雙向綁定”的思想作為核心，因此在View和Model之間沒有聯繫，通過ViewModel進行交互，而且Model和ViewModel之間的交互是雙向的，因此視圖的數據的變化會同時修改數據源，而數據源數據的變化也會立即反應到View上。

i、黑板模式

這種模式對於沒有確定解決方案策略的問題是有用的。黑板模式由3個主要組成部分組成：

1、黑板——包含來自解決方案空間的對象的結構化全局內存

2、知識源——專門的模塊和它們自己的表示

3、控制組件——選擇、配置和執行模塊

所有的組件都可以訪問黑板。組件可以生成添加到黑板上的新數據對象。組件在黑板上查找特定類型的數據，並通過與現有知識源的模式匹配來查找這些數據。

j、解釋器模式

用於設計一個解釋用專用語言編寫的程序的組件。它主要指定如何評估程序的行數，即以特定的語言編寫的句子或表達式。其基本思想是為每種語言的符號都有一個分類。

閱讀更多 渝木木 的文章

關鍵字: 軟件設計 設計 設計模式