导语：设计模式和 架构模式 对于软件开发人员来说是很重要的两个概念。但它们又对很多程序员来说是很模糊的概念。模糊，是因为写代码时根据前辈的经验而使用了某种设计模式或架构模式，却知其然而不知其所以然。在这里，拾人牙慧，记录一些有关于设计模式和架构模式的基础知识和个人理解。
参考文档：
百度百科
php 设计模式全集：
软件设计模式概述
软件架构模式：
常见的软件架构模式：
1、定义及区别
模式（Pattern）事物的标准样式。其实就是解决某一类问题的方法论。把解决某类问题的方法总结归纳到理论高度，那就是模式。模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。
1.1、什么是设计模式
软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。
从设计模式的定义来看，设计模式并非是必须的。
没有了设计模式和下文的架构模式，程序也可以正常开发和运行。
例如下文代码：
detail.php文件代码：
“`
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<?php
$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>
<style>
/*css代码*/
input[name='comment']{padding: 5px;height: 35px;line-height: 35px;font-size: 16px;border-radius: 8px;}
.comment-btn{background-color: red;color: #fff;border: none;cursor: pointer;width: 80px;padding: 12px;text-align: center;border-radius: 5px;}
</style>
</head>
<body>
<?php
$sql = "SELECT * FROM article";
$result = mysql_query($sql);
$detail = mysql_fetch_object($result);
?>
<h1>
<?php echo $detail->title; ?>
</h1>
<div class="content">
<?php echo $detail->content;?>
</div>
<div class="back">
<a href="/index.php?page=1">返回列表页面</a>
</div>
<div class="comment">
<h4>我要评论</h4>
<p>
<!-- <form action="api.php" method="post">-->
<!-- </form>-->
<input type="text" placeholder="请输入要评论的内容" name="comment" id="comment">
<input type="hidden" value="<?php echo $data['id']?>" name="id" id="article_id">
<div onclick="comment()" class="comment-btn">确认评论</div>
</p>
</div>
<?php
mysql_close($con);
?>
</body>
<script>
function comment(){
var xmlHttp = new XMLHttpRequest();
xmlHttp.open('POST','/api.php',true);
xmlHttp.onreadystatechange = function () {
if(this.readyState==4 && this.status == 200){
alert('评论成功！');
}
};
var c = document.getElementById('comment').value;
var id = document.getElementById('article_id').value;
//请求头部
xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
var sendStr = "id="+id+"&comment="+c;
console.log(sendStr);
xmlHttp.send(sendStr);
}
</script>
</ html >
“`
detail.php 的代码是可以正常运行的，代码中包含了 php、css、html、js、mysql 各种原生写法，没有任何的设计模式。对于程序员而言，这段代码是耦合度很高的，不可重用的，甚至是可读性很差的（有可能只知道前端知识的开发人员，是不能理解php部分的代码的）。
假如使用了设计模式和架构模式，对detail.php 代码进行最简单的处理：
“`
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<?php
include 'db.php'; //php数据库部分
?>
<title>文章详情页面</title>
<link rel="stylesheet" href="css代码部分.css">
</head>
<body>
<?php
include 'controller.php'; //php逻辑部分
?>
</body>
<script src="js代码部分.js"></script>
</html>
“`
把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、解释器模式
用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。
