csdn_manong1的博客

职责链设计模式（Chain Of Responsibility Design Pattern）的定义是，将请求的发送和接收解耦，让多个接收对象都有机会处理这个请求。同时，将这些接收对象串成一条链，并沿着这条链传递这个对象，直至链上的某个接收对象能够处理这个请求为止。职责链可以是一条直线、一个环或一个树形结构，最常见的职责链是直线型，即沿着一条单向的链来传递请求。将发送者和接收者解耦，客户端无需知道请求被哪一个对象处理。

备忘录设计模式（Memento Design Pattern）也叫作快照（Snapshot）模式，主要用于实现防丢失、撤销、恢复等功能。其定义是，在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象先前的状态。给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态实现了内部状态的封装，使得用户不需要关心状态的保存细节。

在模板方法设计模式（Template Method Design Pattern）中比较重要的两个概念是基本方法和模板方法。实现具体逻辑步骤的方法可以称之为基本方法，而把基本方法汇总起来形成一个总算法或总行为的方法称之为模板方法。具体方法：在抽象类中声明，由具体子类实现抽象方法：在抽象类中已经实现，在具体子类中可以继承或重写钩子方法：在抽象类中已经实现，包括用于判断的逻辑方法和需要子类重写的空方法两种封装了不变部分，扩展了可变部分在父类中提取了公共的部分代码，便于代码复用。

状态模式（State Design Pattern）的定义是，允许一个对象在内部状态改变时改变它的行为，对象看起来似乎修改了它的类。在状态模式中，通常有两种方式实现状态转换：统一由环境类来负责状态之间的转换；由具体状态类来负责状态之间的转换。状态模式统一封装了状态的转换规则，对状态转换代码进行集中管理将不同的状态引入独立的对象中使得状态转换变得更加明确，且减少对象间的相互依赖状态的职责分明，通过定义新的子类可以很容易地增加新的状态和转换。

命令设计模式（Command Design Pattern）可以将请求发送者和接收者完全解耦。发送者和接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。其定义是，将请求（命令）封装成一个对象，从而可用不同的请求对客户进行参数化（将不同请求依赖注入到其他对象），并且能够支持请求（命令）的排队执行、记录日志、撤销等（附加控制）功能。降低请求者和接收者的耦合度新的命令可以很方便地加入到系统中可以比较容易地设计一个命令队列或者宏命令（组合命令）

策略设计模式（Strategy Design Pattern）实际上起到一个解耦的作用，解耦了策略的定义、创建、使用三部分。其概念是，定义一系列算法类，将每一个算法封装起来，并让它们可以互相替换。从代码的层面上理解就是，将面向过程编程中的分支（如 if-else 或 switch 分支）代码，转换成面向对象的算法类，通过构建这些类的关系以实现不同分支的选择，实现运行时选择策略。使用策略模式可以避免使用多重条件语句，如 if-else 或 switch 语句。

观察者设计模式（Observer Design Pattern）的别名有很多，如发布 - 订阅（Publish/Subscribe）模式、模型 - 视图（Model/View）模式、源 - 监听（Source/Listener）模式或从属者（Dependents）模式。无论是何种名称，其意图都是在对象之间定义一个一对多的依赖，当一个对象状态改变的时候，所有依赖的对象都会自动收到通知。其主要解决了一个对象状态改变之后给其他对象通知的问题，而且考虑到易用性和低耦合，保证高度的协作性。

迭代器设计模式（Iterator Design Pattern），也叫作游标设计模式（Cursor Design Pattern）。迭代器模式将集合对象的遍历操作从集合类中拆分出来，放到迭代器类中，让两者的职责更加单一。其定义是，提供一种方法来访问聚合对象，而不暴露这个对象的内部实现。封装性良好，访问一个聚合对象的内容而无需暴露它的内部实现将遍历操作交给迭代器，简化了复杂聚合类的设计支持以不同的方式遍历聚合对象，在同一个聚合对象上可以定义多种遍历方式。

古代的活字印刷术就有点像享元模式，活字印刷就是将每个字模做出来，再印刷时再选取需要的字模到印刷板上，这样就构成了一页书的印刷板。这样的活字印刷大大提升了效率，减少了印刷板的空间。在享元模式中，存储共享实例对象的地方称为享元池（Flyweight Pool）。类比到上述的活字印刷术中，放置字模的地方就是享元池。内部状态：存储在享元对象内部且不跟随环境变化而改变的状态，内部状态可以在对象之间共享外部状态：通常由客户端保存，当需要时再传入享元对象中的状态，会跟随环境变化而改变，不可以在对象之间共享。

组合模式就是组合多个对象形成树形结构以表示具有“部分 - 整体”关系的层次结构。组合模式对单个对象（叶子对象）和组合对象（容器对象）的使用具有一致性。组合模式的关键是定义一个抽象构件类，它既可以代表叶子，也可以代表容器。客户端针对该抽象构件进行编程，无需知道它到底表示的是叶子还是容器，可以对其进行统一处理。组合模式为树形结构的面向对象实现提供了一种灵活的解决方案在组合模式中增加新的叶子构件和容器构件都很方便，符合开闭原则客户端可以一致地使用一个组合结构或其中单个对象，简化了客户端代码。

外观设计模式（Facade Design Pattern）又被叫作门面模式，其描述是，通过为多个复杂的子系统提供统一的接口，使得子系统更容易被使用。在现实生活中，常常存在办事复杂的情况，如办理房产证或者注册公司，有时需要跑几个部门才能办成，如果这些部门都在一个地方，或者是成立一个综合部门就方便很多。对于上述例子，成立综合部分就相当于使用外观模式，为客户端提供统一的接口，从而降低的系统的耦合度、降低客户端的使用难度。降低了子系统与客户端的耦合度，使得子系统的变化不会影响调用它的客户端。

将目标类和适配者类解耦增加了类的透明性和复用性灵活性和扩展性都非常好一个对象适配器可以把多个不同的适配器适配到同一个目标可以适配一个适配者的子类。

装饰器模式主要解决的问题是，如果使用子类继承的方式扩展一个类，随着扩展功能的增多，子类会非常膨胀，包括子类的数量或子类的方法数。装饰器类和原始类继承同样的父类，这样就可以对原始类“嵌套”多个装饰器类装饰器类是对功能的加强，这也是装饰器模式应用场景的一个重要特点对于扩展一个对象的功能，装饰器模式比继承更加灵活，不会导致类的个数急剧增加可以通过一种动态的方式来扩展一个对象的功能可以对一个对象进行多次装饰。

桥接设计模式（Bridge Design Pattern）也叫作桥梁模式，其描述是将实现和抽象放在两个不同的类层次中，使两个层次可以独立地变化。桥接模式采用抽象关联取代了传统的多层继承，将类之间的静态继承关系转化为动态的对象组合关系，使系统更加灵活，并易于扩展，同时有效控制了系统中类的个数。抽象化：将对象共同的性质抽取出去而形成类的过程实现化：和抽象化是一个互逆的过程，实现化是对抽象化事物的进一步具体化脱耦：将抽象化和实现化之间强关联改换成弱关联，将两个角色之间的继承关系改为关联关系。

举个简单的例说明代理模式就是：假如现在需要买一辆二手车，可以自己去找车源、做质量检测等一系列车辆过户的流程，但是这实在太浪费时间和精力了，其实可以通过找中介的方式，同样会找车源、做质量检测等一系列车辆过户的流程，但是这样自己就只需要选车、付钱即可。协调调用者和被调用者，在一定程度上降低了系统的耦合，满足迪米特原则客户端可以针对抽象主题角色进行编程，增加和更换代理类无需修改源代码，符合开闭原则。

对于大部分系统来说，创建对象包括申请内存、给成员变量赋值等过程，这些操作耗费的时间基本可以忽略不计。如果对象中的数据需要经过复杂的计算才能得到（比如排序、计算哈希值），或者需要从 RPC、网络、数据库、文件系统等非常慢速的 IO 中读取，这其中耗费的时间有时是无法容忍的。如果对象的创建成本比较大，而同一个类的不同对象之间差别不大（如大部分字段都相同），在这种情况下，可以利用对已有对象（原型）进行复制的方式来创建新对象，以达到节省创建时间的目的。

建造者设计模式（Builder Design Pattern）又叫作生成器模式，是一种对象构建模式，其核心在于将产品和产品建造过程解耦。建设者模式允许用户只通过指定复杂对象的类型和内容就可以一步一步地构建出一个复杂的对象，在这个过程当中，用户不需要知道内部的具体构建细节。因此，建造者模式特别适合用于构建具有复杂内部结构的对象，或者是需要生成内部本身相互依赖的对象。使用建造者模式可以使客户端不必知道产品内部组成的细节具体的建造者类之间是相互独立的，这有利于系统的扩展。

工厂设计模式（Factory Design Pattern）是一种创建型的设计模式，它提供了一种创建对象的最佳方式，是一种代替new操作符的一种模式。在工厂模式中，创建对象不会对客户端暴露创建逻辑，而是通过使用一个共同的接口来指向新创建的对象。工厂模式还可以细分为三种的类型：简单工厂模式、工厂方法模式和抽象工厂模式。封装变化：创建逻辑有可能变化，封装成工厂类之后，创建逻辑的变更对调用者透明代码复用：创建代码抽离到独立的工厂类之后可以复用隔离复杂性：封装复杂的创建逻辑，调用者无需了解如何创建对象。

一个类只允许创建一个对象（或实例），那么这个类就是一个单例类，这种设计模式称作单例设计模式（Singleton Design Pattern），简称单例模式。单例模式保证系统内存中只存在一个对象，非常节省系统资源，对于一些需要频繁销毁的对象，使用单例模式可以提高系统性能。将单例类的构造方法定义为私有方法，禁止外部直接调用构造方法来实例化单例类的对象；在类的内部创建并保存类的唯一实例，并设置成私有变量，禁止外部直接调用这个实例变量；创建一个公开的静态方法，对外暴露类的唯一实例。

可以这么理解：第一次写代码时，如果当下没有复用的需求，而未来的复用需求也不是很明确，并且开发可复用代码的成本比较高，那就不需要考虑代码的复用性；当基类发生了改变，继承基类的子类也会不可避免地发生改变，从基类继承而来的实现是静态的，不可能在运行时发生变化，没有足够的灵活性。并且，有些本身就复杂的问题，用复杂的方法解决，并不能算是违背 KISS 原则。通过组合或聚合关系可以将已有的对象纳入新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样关系不会将已有对象的实现细节暴露给新对象。

两者的区别在于，前者是被动的接收对象，在类 A 的实例创建过程中即创建了依赖的 B 对象，通过类型或名称来判断将不同的对象注入到不同的属性中，而后者是主动索取相应类型的对象，获得依赖对象的时间也可以在代码中自由控制。从代码实现上看，面向对象的多态和里式替换原则有点类似，但是它们的关注点不一样：里式替换原则是用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。控制反转并不是一种具体的设计技巧，而是一种笼统的设计思想，一般用来指导框架层面的设计。

而且，抽象类中的抽象方法只是起到一个限制的作用，并没有提供实际的方法体，这也要求子类去实现自己的方法体。从更深层次的角度上看，抽象类是不能被实例化的类，只能被子类继承，继承关系表示的是一种 is-A 的关系，接口表示的是一种 has-A 关系。抽象类和接口是配合而不是替代，它们经常一起使用，接口声明能力，抽象类提供默认实现，实现全部或部分方法，一个接口经常有一个对应的抽象类。从上述对抽象类和接口的简单分析看，抽象类和接口的概念非常相似，从明面上看，其最大的区别就是，抽象类是用来继承的，接口是用来实现的。

比如说，对于一个钱包类，里面有余额、币种这两个属性，通常是不允许外部直接更新余额或者直接更新币种，而是仿照现实交易的找补零钱的方式，对外提供一个找补零钱的方法，在这个方法中根据提供的参数来更新余额和币种，这样可以保证数据的一致性。多态可以通过继承的方式实现，子类继承父类之后，并重写了父类的方法，在初始化子类的对象时，可以将对象定义为父类的数据类型，这时的对象调用的会是重写后的子类方法。所谓的鸭子类型，指的是只关心事物的外部行为而非内部结构，即不关心对象是什么类型，只关心该对象是否拥有指定方法。

在日常开发中，通常是无法客观地去评价代码的质量高低，对于同一段代码，高级开发工程师可能觉得可读性非常好，而初级开发工程师就会觉得难以阅读，他们的评价标准肯定是不一样的。耦合指的是两个模块之间的关联程度。对编码质量的常见评价标准非常多，而它们又存在着包含、重叠、相互影响的关系，如一段代码的可读性、可扩展性非常好，也意味着这段代码的可维护性非常好。行为型设计模式：解释器模式、模板方法模式、职责链模式、命令模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、访问者模式。