软件设计模式

一、设计模式的分类:

总体来说设计模式分为三大类：

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下：

黑板模式：

　　　　语音识别，不确定性，需要人工智能技术和专家意见的汇总和决策，并且需要支持识别过程中的推理和决策。

解释器模式： 

　　解释器模式属于类的行为模式，描述了如何为语言定义一个文件，如何在该语言中表示一个句子，以及如何解释这些句子，这里的"语言"是使用规定格式和语法的代码。

策略模式：

　　策略模式一种对象的行为型模式。定义一系列算法，并将每个算法封装起来，并将让他们可以互相替换。策略模式让算法独立于使用它的客户而变化，其目的是将行为和环境分隔，当出现新的行为时，只需要实现新的策略类。

中介模式：

　　中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。

意图：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。(QQ游戏平台，聊天室、QQ群、短信平台和房产中介)

主要解决：对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。

何时使用：多个类相互耦合，形成了网状结构。

如何解决：将上述网状结构分离为星型结构。

关键代码：对象 Colleague 之间的通信封装到一个类中单独处理。

应用实例： 1、中国加入 WTO 之前是各个国家相互贸易，结构复杂，现在是各个国家通过 WTO 来互相贸易。 2、机场调度系统。 3、MVC 框架，其中C（控制器）就是 M（模型）和 V（视图）的中介者。

优点： 1、降低了类的复杂度，将一对多转化成了一对一。 2、各个类之间的解耦。 3、符合迪米特原则。

缺点：中介者会庞大，变得复杂难以维护。

使用场景： 1、系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。 2、想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。

注意事项：不应当在职责混乱的时候使用。

迭代器模式：

　　是一种对象的行为模式，提供了一种方法来访问聚合对象，而不用暴露这个对象的内部表示。迭代器模式支持以不同的方式遍历一个聚合对象

　包装器：(Wrapper Facade) :

包装器架构模式解决系统(Linux,Solar.Window )的差异问题，服务端程序应在包装器外观的实例上调用需要的方法，然后请求和请求的参数发送给操作系统API函数，

命令模式（Command Pattern）：

　　命令模式是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。（用户操作图像撤销和重做）

　责任链模式：

顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。

在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。（过滤敏感词语）

软件架构设计的重要性：

• 软件架构设计是降低成本，改进质量，按时和按需交付的关键因素。
• 软件架构设计能够满足系统的性能，安全性，可维护性，
• 软件架构设计能有有效地管理系统的复杂性并降低系统维护费用；
• 软件架构设计针对系统开发具有指导性
• 软件架构设计为系统复用奠定基础
• 软件架构设计能够支持冲突分析
• 软件架构设计与系统需求是直交的，没有必然的联系

软件架构设计与生命周期的关系

　　从本质上看，需求和软件架构设计面临的是不同的对象，：一个是问题空间。另一个是解空间。保持两者的可追踪行和转换，一直是软件工程领域追求的目标

从软件需求模型向SA模型转换主要关注两个问题：① 如何根据需求模型构建软件架构模型；②如何保证米修内功转换的可追踪性；

"4+1"视图理解： 

"4+1"视图是对逻辑架构进行描述，后由RUP采纳。

1. 逻辑视图（Logical View）设计的对象模型（使用面向对象的设计方式时）
2. 过程视图（Process View）捕捉设计的并发与同步特征
3. 物理视图（Physical View）,描述了软件到硬件的映射，反映了分布式特性
4. 开发视图（Development View）描述了在开发环境中软件的静态组织结构
5. 架构描述，所做的各种决定，可以围绕这四个视图来组织，然后由一些用例（User Cases）或澄江（Scenarios）来说明，从而形成第五视图、
   1. 当采用面向对象设计方法描述对象模型时。通常使用类图来表达内部属性和行为。以及即合之间的交互关系，采用状态图定义对象的内部行为　　

构建组装过程知识

　　在架构模型的指导下，可用构建可以通过组装的方式在较高层次上实现系统，并能够提高系统实现的效率。

在构件组装过程中需要检测并解决架构失配问题，其中构件失配主要包括：由于系统构建基础设施、控制模型和数据模型的假设存在冲突引起的失配。

连接子失配包括由于系统构件交互协议、构件连接时数据格式的假设存在冲突引起的失配。

DNS负载均衡：

DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

基于反向代理负载均衡：

反向代理的实现：

1）需要有一个负载均衡设备来分发用户请求，将用户请求分发到空闲的服务器上

2）服务器返回自己的服务到负载均衡设备

3）负载均衡将服务器的服务返回用户

​ 以上的潜台词是：用户和负载均衡设备直接通信，也意味着用户做服务器域名解析时，解析得到的IP其实是负载均衡的IP，而不是服务器的IP，这样有一个好处是，当新加入/移走服务器时，仅仅需要修改负载均衡的服务器列表，而不会影响现有的服务

【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。