软件体系结构

软件体系结构

质量属性：

开发期质量:可扩展性，可复用性，可维护性等；

运行期质量：正确性，健壮性，性能，可靠性，容错性，易用性，安全性，可移植性，兼容性。

 

 

设计原则：

1. 面向接口编程（Program to interfaces, not to implementations）
2. 多用组合，少用继承（Favor composition over inheritance）
3. Principle of Least Knowledge(Law of Demeter)
4. 单一职责原则（Single Responsibility Principle）：就一个类而言，应该仅有一个引发它变化的缘由。
5. 开闭原则（Open-Closed Principle）：软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能。抽象化是开闭原则的关键
6. 里氏代换原则（Liskov Substitution Principle）：在软件系统中，一个能够接受基类对象的地方必然能够接受一个子类对象。里氏代换原则是实现开闭原则的重要方法之一。
7. 依赖倒置原则（Dependency Inversion Principle）：要针对抽象层编程，而不要针对具体类编程。实现开闭原则的关键是抽象化，而且从抽象导出具体化实现，若是说开闭原则是面向对象设计的目标的话，那么依赖倒置原则就是面向对象设计的主要手段。依赖注入：构造注入，设置注入，接口注入
8. 接口隔离原则（Interface Segregation Principle）：使用多个专门的接口来取代一个统一的接口。
9. 分离关注点（Principle of Separation of Concerns）:"Organize software into separate components(pieces) that are as independent as possible."

 

软件风格：

Model-View-Controller(pattern)

MVC模式（Model-view-controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）

MCV模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，而且使程序某一部分的重复利用成为可能。

控制器（Controller）：负责转发请求，对请求进行处理。

试图（View）：界面设计人员进行图形界面设计。

模型（Model）：程序员编写程序应有的功能（实现算法等等）、数据专家进行数据管理和数据库设计（能够实现具体的功能）

将应用程序划分为三种组件，模型-试图-控制器（MVC）设计定义它们之间的相互做用。

模型（Model）：用于封装与应用程序的业务逻辑相关的数据以及数据的处理方法。"Model"有对数据直接访问的权利，例如对数据库的访问。"Model"不依赖"View"和"Controller"，也就是说，Model不关心它会被如何显示或是如何被操做。可是Model中数据的变化通常会经过一种刷新机制被公布。为了实现这种机制，那些敢于监视此Model的View必须事前在此Model上注册，从而，View能够了解在数据Model上发生的改变。

视图（View）可以实现数据有目的的显示（理论上，这不是必需的）。在View中通常没有程序上的逻辑。为了实现View上的刷新功能，View须要访问它监视的数据模型（Model），所以应该事前在被它监视的数据那里注册。

控制器（Controller）起到了额不一样层面间的组织做用，用于控制应用程序的流程。它处理事件并做出响应。"事件"包括用户的行为和数据Model上的改变。

实例Java平台上实现的MVC模型

视图（View）

在J2EE应用程序中，视图（View）可能由Java Server Page（JSP）担任。生成View的代码则多是一个servlet的一部分，特别是在客户端服务端交换的时候。

控制器（Controller）

J2EE应用中，Controller多是一个servlet。除了可直接以J2EE来撰写外，亦可用其余框架来撰写，常见的有Struts2,Spring Framework…等等。

模型（Model）

Model则是由一个实体Bean来实现。

 

 

C/S(Client-Server)

C/S软件是基于资源不对等，且为实现共享而提出来的。C/S体系结构主要有三个主要组成部分：数据库、服务器、客户应用程序和网络。优势：具备强大的数据操做和事务处理能力；对于软件和硬件的变化显示出强大的适应性和灵活性；将大的应用处理任务分到许多经过网络链接的低成本计算机上。缺点：开发成本高；客户端程序设计复杂；软件维护和升级困难。

 

 

管道过滤器风格（Pipe-and-Filter）

每个组件都有一组输入和输出，组件读输入的数据流，通过内部处理，而后产生输出的数据流。过滤器风格的链接件就像是数据流传输的管道，将一个过滤器的输出传到另外一个过滤器的输入。

 

分层系统（Layered/Tiered Architecture）

组织成一个层次结构，每一层都为上一层提供了相应的服务，而且接受下一层的服务。在分层系统的一些层次中构件实现了虚拟机的功能。实例:分层的操做系统

 

端到端（Peer-to-Peer）

 

黑板系统/仓库系统（Blackboard/Repository）

组件：中心数据结构（仓库）和一些独立构件的集合。

仓库和在系统中很重要的外部组件之间的相互做用

实例：须要使用一些复杂表征的信号处理系统

 

基于事件的隐式调用（Event-Based Architecture(PubSub)）

组件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其余组件中的过程在一个或多个事件中祖册，当一个事件被触发，系统自动调动这个事件中注册的全部过程。这种风格的组件是一个模块，这些模块能够是一些过程，又能够是一些事件的集合。不变量：事件的触发者并不知道哪些组件会被这些事件影响（观察者模式-Observer）

实例：数据库管理系统，用户界面。

 

 

SOA(Service-Oriented Architecture)

面向服务的体系结构是一个组件模型，它将应用的不一样功能单元（称为服务）经过这些服务之间定义良好的接口和契约联系起来。阿里的dubbox是国内如今应用最多的用来实现SOA的框架。它将服务注册到企业服务总线上，当某个系统须要调用其余系统中数据的时候直接从企业服务总线上获取，而不是端到端的获取，从而减小了系统的复杂度。

 

RESTF(representational state transfer)表述性状态转移

Rest是web服务的一种架构风格；使用HTTP,URI,XML,JSON,HTML等普遍流行的标准和协议；轻量级，跨平台，跨语言的架构设计。它是一种设计风格，不是一种标准，是一种思想。

Rest架构的主要原则：

1. 网络上的全部事情都被抽象为资源
2. 每一个资源都有一个惟一的资源标识符
3. 同一个资源具备多种表现形式（xml，json等）
4. 对资源的各类操做不会改变资源标识符
5. 全部的操做都是无状态的
6. 符合REST原则的框架方式便可成为RESTful

什么是Restful：

对应的中文是rest式的；Restful web service是一种常见的rest的应用，是遵照了rest风格的web服务；rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构)

为何会出现Restful

在Restful以前的操做：
http://127.0.0.1/user/query/1 GET  根据用户id查询用户数据
http://127.0.0.1/user/save POST 新增用户
http://127.0.0.1/user/update POST 修改用户信息
http://127.0.0.1/user/delete GET/POST 删除用户信息

RESTful用法：
http://127.0.0.1/user/1 GET  根据用户id查询用户数据
http://127.0.0.1/user  POST 新增用户
http://127.0.0.1/user  PUT 修改用户信息
http://127.0.0.1/user  DELETE 删除用户信息

以前的操做是没有问题的，大神认为是有问题的，有什么问题呢?你每次请求的接口或者地址，都在作描述，例如查询的时候用了query,新增的时候用了save，其实彻底没有这个必要，我使用了get请求，就是查询，使用post请求，就是新增的请求，个人意图很明显，彻底没有必要作描述，这就是为何有了restful

如何使用

总结：restful就是旧技术，新风格。

 

 

大泥球风格（big ball of mud）：大泥球风格就是没有任何清楚的结构，杂乱无章、错综复杂，邋遢不堪、随意拼贴的大堆代码。

 

控制反转与依赖注入

什么是控制？以下图所示，咱们看到了软件系统中对象的高耦合现象。全体齿轮的转动由一个对象来控制，如类B

什么是控制反转？是用来对对象进行解耦。借助第三方实现具备依赖关系的对象之间的解耦。这个第三方就是ioc容器。引入了ioc容器后，对象A、B、C、D之间没有了依赖关系，全体齿轮转动的控制权交给容器。这时候齿轮转动控制权不属于任何对象，而属于ioc容器，因此控制权反转了，从某个对象转到了ioc容器。

什么是依赖注入？

什么是依赖？依赖是指一种关系，若是在类A中建立了类B的实例，咱们说类A依赖类B。下面有一个例子：

出现的问题（problems）：

问题1：若是如今要改变类B生成方式，如须要new B(string name)初始化 B，须要修改类A中的源代码；

问题2：若是想测试不一样B对象对A的影响很困难，由于B的初始化被写死在了A的构造函数中；

问题3：若是要对类B的实例进行调试时，就必须在类A中对类B的实例进行测试，增长了测试的难度和复杂度；由于当出现问题时，不知道是类A的问题仍是类B的问题。

解决方法：

依赖注入定义：将B对象实例做为类A的构造器参数进行传入，在调用类A构造器以前，类B实例已经别初始化好了。像这种非本身主动初始化依赖，而经过外部传入依赖对象的方式，咱们就称为依赖注入。

依赖反转

根据依赖注入的定义：被依赖者对象并非依赖本身主动初始化，而是经过外部传入被依赖者的方式，那么背依赖者对象类型能够是其自己，也可使其实现类或继承子类；

因此，通过分析，被依赖者的对象类型，并非依赖者自身能够决定的，（固然传统的程序设计方式是依赖者决定的），而是由外部建立者决定的，因此被依赖者类型的决定权反转了。对于spring来讲，就是由spring容器决定的；

依赖反转定义：被依赖者的对象类型并非由依赖者自身能够决定的，而是由外部建立者决定的，外部传入什么类型的对象就是什么类型的对象，依赖者对其一无所知；

框架与库

有一个基本的特征是框架通常指的是会调用你的代码，控制权从你写的程序手中转移到框架中，而库通常是用来被你调用。

库和框架都是一种有别于软件、面向程序开发者的产品形式。正由于如此，也有不少人误认为库就是框架，或者认为指定语言的库就是框架。

库的英文单词为Library(简称为Lib)，框架的英文为Framework。

库是将代码集合成一个产品，供程序员调用。面向对象的代码组织形式而成的库也叫类库。面向过程的代码组织形式而成的库也叫函数库。在函数库中的能够直接使用的函数叫库函数。开发者在使用库的使用，只须要使用库的一部分类或函数，而后继续实现本身的功能。

框架则是为解决一个（一类）问题而开发的产品，框架用户通常只须要使用框架提供的类或函数，便可实现所有功能。能够说，框架是库的升级版。

开发者在使用框架的时候，必须使用这个框架的所有代码。

框架和库的比较能够想象为：

假如咱们要买一台电脑。框架为咱们提供了已经装好的电脑，咱们只要买回来就能用，但你必须把整个电脑买回来。这样用户天然轻松许多，但会致使不少人用同样的电脑，或你想自定义某个部件将须要修改这个框架。而库就如本身组装的电脑。库为咱们提供了不少部件，咱们须要本身组装，若是某个部件未提供，咱们也能够本身作。库的使用很是灵活，但没有框架方便。

体系结构中的模型

To help reason and communicate about the design of complex software as a whole.

（为了帮助理解与沟通复杂软件做为一个总体的设计）

Canonical Model Structure（规范化模型结构）

Domain Model（领域模型）: The facts about the world（真实世界的事实）

Design Model（设计模型）: The design decisions made about the software.（软件开发中的设计决策）

Code Model（代码模型）: The source code implementation of a system.（实现系统的源代码）

领域模型：领域模型表达了与系统相关的现实世界的不变事实。就Yinzer系统而言，这些相关事实包括如广告(Ads)和联系方式（Contacts）等重要类型的定义、类型之间的关系，以及描述类型与关系如何因时而变的行为。一般，没法控制领域模型，例如，没法决定一周只能拥有6天，或者要求每周举行生日宴会。

设计模型：相反，设计模型主要是在设计者控制下。须要构建的系统不只会显示在领域模型中，还会在设计模型中出现。设计模型是设计承若的一部分。这就是说，能够推迟实现那些不曾决策而又事关设计的某些细节（一般出于更低层次），直到得到代码模型。设计模型由递归嵌套的边界模型和内部模型组成。边界模型与内部模型描述了相同的内容（就像组件或模块），但边界模型只涉及公共的可见接口，而内部模型还介绍了内部设计。

代码模型：代码模型既是系统的源代码实现，又至关于一个模型。它能够是实际的Java代码，或经过运行工具将代码转换为UML的结果。关键还在于它包含了完整的对设计的承若。

    设计模型每每会忽略对低风险部分的描述，只要开发者理解了整个设计和架构，设计就是充分的。然而，设计模型对设计的承如果不完整的，代码模型则否则，至少它对设计的承若完整到足以在机器上运行。

4+1视图模型

逻辑视图：分析，设计（结构）

实现视图：编程（软件开发）

过程视图：系统集成（性能，吞吐量，可扩展性）

部署视图：系统工程（系统拓扑，分发与安装，通讯）

用例视图：用来描述功能

软件体系结构

软件体系结构包组件（Component）、链接件（Connector）和约束（Constraint）三大要素。

组件：能够是一组代码，如程序的模块；也能够是一个独立的程序，如数据库服务器。链接件能够是过程调用，管道，远程调用等，用于表示组件之间的相互做用。一个软件体系结构还包括某些约束，约束通常对象链接时的规则或指明链接的势态和条件。软件体系结构是设计过程的一个层次，它处理那些超越算法和数据结构的设计，研究总体设计和描述方法。

模块(module)

模块（module）是实现制品的集合，例如，源代码（类、函数、过程、规则等）、配置文件、数据库模式定义。

模块能够把相关的代码进行分组，只暴露接口而隐藏实现。在这一点上，模块和类类似，因为模块经常包含不少类和其余的制品，其规模比类要大。模块的接口和内部的那些接口是不一样的。模块能够依赖（depend）于另外一个模块。一个模块能够被包含在另外一个模块内，这个关系称为嵌套（nesting）,也能够称为包含。

端口（Ports）

    全部进出组件的通讯都是经过组件上的端口（ports）来完成的。一个组件支持的全部公开可用的方法，以及要响应的全部公开事件，都会在组件端口中进行规定。若是一个组件要给另外一个组件发送消息，要写数据库，要获取互联网上的信息，就必须经过端口。端口经过操做来透露行为。客户端经常必须以一种特定的次序或者协议来调用操做。端口能够是有状态的，这尤为便于跟踪协议的状态。

 

适应变化（Adapting to Change）

1. 应该能够很容易地定位到哪个地方须要变化。It should be easy to locate the place where a change is needed
2. 若是要改变单一制品的话，应当只在一处地方进行修改。A change to a single artifact in a program should be made in just one place
3. 改变单一制品的话，不该当在其余地方进行改变。A change to an artifact should require no (or minimal) changes to the rest of the program
4. 错误应当只出如今被改变的地方。An error introduced by the change should only affect the thing being changed

 

 

 

 

 

 

 

 

 

 

 

 

 

设计模式

To help reason about complex software's code

Strategy(behavioral)

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use if.

策略模式（Strategy Pattern）

定义：

定义一系列算法，将每个算法封装起来，并让它们能够相互替换。策略模式让算法独立于使用它的客户而变化，也称为政策模式(Policy)。策略模式是一种对象行为型模式。

Strategy Pattern:Define a family of algorithms,encapsulate each one,and make them interchangeable.Strategy lets the algorithm vary independently from clients that use it.

优缺点：

策略模式主要有点在于对"开闭原则"的完美支持，在不修改原有系统的基础上能够更换算法或者增长新的算法，它很好地管理算法族，提升了代码的复用性，是一种替换继承、避免多重条件转移语句的实现方式；其缺点在于客户端必须知道全部的策略类，并理解其区别，同时在必定程度上增长了系统中类的个数，可能会存在不少策略类。

适合的场景：

在一个系统里面有许多类，他们之间的区别仅在于它们的行为，使用策略模式能够动态地让一个对象在许多行为中选择一种行为；一个系统须要动态地在几种算法中选择一种；避免使用难以维护的多重条件选择语句；但愿在具体策略类中封装算法和与相关的数据结构。

 

类图：

 

 

Decorator(structural)

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

装饰模式（Decorator Pattern）

定义：动态地给一个对象增长一些额外的职责（Responsibility）,就增长对象功能来讲，装饰模式比生成子类实现更为灵活。其别名有能够成为包装器（Wrapper），与适配器模式的别名相同，但它们适用于不一样的场合。根据翻译的不一样，装饰模型也有人称之为"油漆工模式"，它是一种对象结构型模式。

适用环境：在不影响其余对象的状况下，以动态、透明的方式给的单个对象添加职责。须要动态地给一个对象增长功能，这些功能也能够动态地被撤销。当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。

 

 

Composite(structural)

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

组合模式（Composite Pattern）

定义：组合多个对象造成树型结构以表示"总体-部分"的结构层次。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具备一致性。

Composite Pattern:Compose objects into tress structures to represent part-whole hierarchies.Composite lets clients treat individual objects and compositions of objects uniformly.

优缺点：

组合模式的主要优势在于能够方便地对层次结构进行控制，客户端调用简单，客户端能够一致的使用组合结构或其中单个对象，用户就没必要关心本身处理的是单个对象仍是整个组合结构，简化了客户端代码；其缺点在于使设计变得更加抽象，且增长新构件时可能会产生一些问题，并且很难对容器中的构件类型进行限制。

适用场景：

须要表示一个对象总体或部分层次；让客户可以忽略不一样对象层次的变化，客户端能够针对抽象构件编程，无需关心对象层次结构的细节；对象的结构是动态的而且复杂程度不同，但客户须要一致地处理它们。

类图：

 

Simple Factory(idiom)

Lets a separate class (or method) decide what object to instantiate.

简单工厂模式(Simple Factory Pattern)

定义：又称为静态工厂方法(Static Factory Method)模式，它属于建立型模式。在简单工厂模式中，能够根据参数的不一样返回不一样类的实例。简单工厂模式专门定义一个类来负责建立其余类的实例，被建立的实例一般都具备相同的父类。

优缺点：

优势：

简单工厂模式最大的优势在于实现对象的建立和对象的使用分离，将对象的建立交给专门的工厂类负责，可是其最大的缺点在于工厂类不够灵活，增长新的具体产品须要修改工厂类的判断逻辑代码，并且产品较多时，工厂方法代码将会很是复杂。

适用场景：

工厂类负责建立的对象比较少

客户端只知道传入工厂类的参数，对于如何建立对象不关心。

 

类图

 

Factory Method(creational)

Define an interface for creating an object, but let subclasses decide which class to instantiate. Lets a class defer instantiation to subclass.

工厂方法模式(Factory Method Pattern)

定义:工厂方法模式(Factory Method Pattern)又称为工厂模板，也叫虚拟构造器(Virtual Constructor)模式或多态工厂(Polymorphic Factory)模式，它属于建立类型模式。在工厂方法模式中，工厂父类负责定义建立产品对象的公共接口，而工厂子类负责生成具体的产品对象，这样作的目的是将产品类的实例化操做延迟到工厂子类中完成，即经过工厂子类来肯定究竟应该实例化哪个具体产品类。

Factory Method Pattern: Define an interface for creating an object,but let subclasses decide which class to instantiate.Factory Method lets a class defer instantiation to subclasses.

优缺点：

工厂方法模式主要优势是增长新的产品类时无需修改现有系统，并封装了产品对象的建立细节，系统具备良好的灵活性和可扩展性；其缺点在于增长新产品的同时须要增长新的工厂，致使系统类的个数成对增长，在必定程度上增长了系统的复杂度。

使用场景：一个类不知道它所须要的对象的类；一个类经过其子类来指定建立哪一个对象；将建立对象的任务委托给多个工厂子类中的某一个，客户端在使用时能够无须关心是哪个工厂子建立产品子类，须要时再动态指定。

类图：

 

 

 

 

 

Abstract Factory(creational)

Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

抽象工厂模式(Abstract Factory Pattern)

定义：提供一个建立一系列相关或相互依赖对象接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象建立型模式。

Abstract Factory Pattern:Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

优缺点：

抽象工厂模式的主要有点是隔离了具体类的生成，使得客户并不须要知道什么被建立，并且每次能够经过具体工厂类建立一个产品族中的多个对象，增长或者替换产品族比较方便，增长新的具体工厂和产品族很方便；主要缺点在于增长新的产品等级结构很复杂，须要修改抽象工厂和全部的具体工厂类，对"开闭原则"的支持呈现倾斜性。
适用场景：

一个系统不该当依赖于产品类实例如何被建立、组合和表达的细节；系统中有多于一个的产品族，而每次只使用其中某一产品族；属于同一个产品族的产品将在一块儿使用；系统提供一个产品类的库，全部的产品以一样的接口出现，从而使客户端不依赖与具体实现。

 

类图：

 

 

 

State(behavioral)

A monolithic object's behavor is a function of its state, and it must change its behavior at run-time depending on that state.

状态模式（state Pattern）

定义：容许一个对象在其内部状态改变时改变它的行为，对象看起来彷佛修改了它的类。其别名为状态对象（Objects for States）,状态模式是一种对象行为型模式。

适用场景：对象的行为依赖于它的状态（属性）而且能够根据它的状态改变而改变它的相关行为。代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会致使代码的可维护性和灵活性变差，不能方便地增长和删除状态，使客户类与类库之间的耦合加强。在这些条件语句包含了对象的行为，并且这些条件对应于对象的各类状态。

例子：

 

Observer(behavioral)

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

观察者模式(Observer Pattern)

定义：

定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆获得通知并被自动更新。观察者模式又叫作发布-订阅模式(Publish/Subscribe)，模式-视图模式(Modle/View)，源-监听器(Source/Listener)模式或从属者(Dependents)模式。观察者模式是一种对象行为型模式

Observer Pattern:Define a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically.

优缺点：

观察者模式的主要优势在于能够实现表示层和数据逻辑层的分离，并在观察目标和观察者之间创建一个抽象的耦合，支持广播通讯；其主要缺点在于若是一个观察目标对象有不少直接和间接的观察者的话，将全部的观察者都通知到回花费不少时间，并且若是在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之进行循环调用，可能致使系统崩溃。

使用场景：

一个抽象模型有两个方面，其中一个方面依赖于另外一个方面；一个对象的改变将致使其余一个或多个对象也发生改变，而不知道具体有多少对象将发生改变；一个对象必须通知其余对象，而并不知道这些对象是谁；须要在系统中建立一个触发链。

 

类图：

 

 

Singleton(Creational; anti-pattern)

Ensures a class has only instance, and provides a global point of access to it.

单例模式(Singleton Pattern)

定义:

单例模式确保某一个类只有一个实例，并且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。

Singleton Pattern:Ensure a class has only one instance and provide a global point of access to it.

优缺点:

单例模式的主要优势在于提供了对惟一实例的受控访问并能够节约系统资源；其主要的缺点在于由于缺乏抽象层而难以扩展，且单例类职责太重。

适用场景：

系统只须要一个实例对象；客户调用类的单个实例只容许使用一个公共访问点。

类图：

 

 

 

 

Adapter(structural)

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

适配器模式(Adapter Pattern)

定义：

将一个接口转换成客户但愿的另外一个接口，适配器模式使接口不兼容的那些类能够一块儿工做，其别名为包装器(Wrapper)。适配器模式既能够做为类结构型模式，也能够做为对象结构型模式。

Adapter Pattern:convert the interface of a class into another interface clients expect.Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

优缺点：

适配器模式的主要优势是将目标类和适配者类解耦，增长了类的透明性和复用性，同时系统的灵活性和扩展性都很是方便，符合"开闭原则"；类适配器模式的缺点是适配器在不少编程语言中不能同时适配多个适配者类，对象适配器模式的缺点是很难置换适配者类的方法。

适用场景：

系统须要使用现有的类，而这写类的接口不符合系统道德须要；想要建议一个能够重复使用的类，用于与一些彼此之间没有太大关联的一些类一块儿工做。

 

 

 

 

类图

类适配器

 

对象适配器

 

 

 

Façade(structural)

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

外观模式(Façade Pattern)

外部与一个子系统的通讯必须经过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。

Façade Pattern:Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.

优缺点：

外观模式主要优势在于对客户屏蔽子系统组件，减小了客户处理的对象数目并使得子系统使用起来更加容易，它实现了子系统与客户之间的松耦合关系，并下降了大型软件系统中的编译依赖性，简化了系统在不一样平台之间的移植过程；其缺点在于不能很好地限制客户使用子系统类，并且在不引入抽象外观类的状况下，增长新的子系统可能须要修改外观类或客户端的源代码，违背了"开闭原则"。

适用场景：要为一个复杂子系统提供一个简单接口；客户程序与多个子系统之间存在很大的依赖性；在层次化结构中，须要定义系统中每一层的入口，使得层与层之间不直接产生联系。

 

类图：

 

 

 

Proxy(structural)

Provide a surrogate or placeholder for another object to control access to it.

代理模式(Proxy Pattern)

给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式的英文叫作Proxy或Surrogate，它是一种对象结构型模式。

Proxy Pattern:Provide a surrogate or placeholder for another object to control access to it.

优缺点：

代理模式的优势在于可以协调调用者和被调用者，在必定程度上下降了系统的耦合度；其缺点在于因为在客户端和真实主题之间增长了代理对象，所以有些类型的代理模式可能会形成请求的处理速度变慢，而且实现代理模式须要额外的工做，有些代理模式的实现很是复杂。

适用场景：

远程代理为一个位于不一样的地址空间的对象提供一个本地的表明对象，它使得客户端能够访问在远程机器上的对象，远程机器可能具备更好的计算性能与处理速度，能够快速响应并处理客户端请求。

若是须要建立一个资源消耗较大的对象，先建立一个消耗相对较小的对象来表示，真实对象只在须要时才会被真正建立，这个小对象称为虚拟代理。虚拟代理经过使用一个小对象来表明一个大对象，能够减小系统资源的消耗，对系统进行优化并提升运行速度。

保护代理能够控制对一个对象的访问，能够给不一样的用户提供不一样级别的使用权限。

 

类图

 

 

 

 

 

 

大部分的设计模型都有以下的通用规则。（Most design patterns work by following the same general process）:

1. （识别程序中变化的部分）Identify the part of the program that changes(algorithm, state, method, constructor, etc)
2. （将变化的部分封装成一个类）Encapsulate that functionality into a class
3. （经过其余的类进行实例化）Make instances of the new class components(instance variables) of other classes.