zhimokf的专栏

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。①文法：即语法规则。在解释器模式中每一个语法都将对应一个解释器对象，用来处理相应的语法规则。它对于扩展、改变文法以及增加新的文法规则都很方便。②解释器模式描述了如何为简单的语言定义一个文法，如何在该语言中表示一个句子，以及如何解释这些句子。③在解释器模式中可以通过一种称之为抽象语法树(Abstract Syntax Tree, AST)的图形方式来直观地表示语言的构成，每一棵抽象语法树对应一个语言实例。

迭代器模式是一种行为设计模式， 它可以有效管理数据流动的同时，让用户能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。迭代器通常会提供一个获取集合元素的基本方法。客户端可不断调用该方法直至它不返回任何内容， 这意味着迭代器已经遍历了所有元素。

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前拐下定义作用于这些元素的新操作。

对于责任链模式，其作为一种行为设计模式， 允许你将请求沿着处理者链进行发送。收到请求后， 每个处理者均可对请求进行处理， 或将其传递给链上的下个处理者。这种处理方法类似包与包之间的调用的思路，只是其可以不在主程序中累赘的去申明一堆if else变量使得程序更加臃肿。相比于创建设计模式的对整体架构进行的设计，和结构设计模式对对象的化繁为简的操作，作为行为设计模式，其需要我们对数据流能够充分的把握，来避免检查代码的混乱不堪。而每次新增功能都会使其更加臃肿。修改某个检查步骤有时会影响其他的检查步骤。

对于责任链模式，其作为一种行为设计模式， 允许你将请求沿着处理者链进行发送。收到请求后， 每个处理者均可对请求进行处理， 或将其传递给链上的下个处理者。这种处理方法类似包与包之间的调用的思路，只是其可以不在主程序中累赘的去申明一堆if else变量使得程序更加臃肿。相比于创建设计模式的对整体架构进行的设计，和结构设计模式对对象的化繁为简的操作，作为行为设计模式，其需要我们对数据流能够充分的把握，来避免检查代码的混乱不堪。而每次新增功能都会使其更加臃肿。修改某个检查步骤有时会影响其他的检查步骤。

我们在遇到类似GUI中多种Button点击功能的操作时，我们应该将请求的所有细节 （例如调用的对象、 方法名称和参数列表） 抽取出来组成命令类， 该类中仅包含一个用于触发请求的方法。命令模式就是这样一种行为设计模式， 它可将请求转换为一个包含与请求相关的所有信息的独立对象。并能根据不同的请求将方法参数化、 延迟请求执行或将其放入队列中， 且能实现可撤销操作。

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前拐下定义作用于这些元素的新操作。

中介者模式和命令模式类似，都有着一层中间层来作为沟通的渠道，只是中介者模式使用了Mediator来实现实现更新函数changed。而在命令模式中使用Invoke作为最上层，用于管理具体类的操作，从而对接收者增删。简而言之，命令模式在发送者和请求者之间建立单向连接，使请求者可以调用发送者的不同方法。中介者清除了发送者和请求者之间的直接连接， 强制它们通过一个中介对象进行间接沟通。

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。备忘录模式核心在于保存一个对象某个时刻部分或者全部状态，以便客户返回时可以取消撤回那个时刻的状态。也就是说，核心思想是保存一个对象状态，当状态改变后用保存的对象赋值给当前对象即可。其实现跟原型模式不同，原型模式主要是对整个对象的克隆，无法做到部分克隆以及接口对所有客户开放，破坏开闭原则。

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。相当于邮箱当中的订阅功能。抽象主题（Subject）：把所有观察者对象的引用保存在列表里，提供注册和删除观察者对象的接口。抽象观察者（Observer）：为那些在目标发生改变时须获得通知的对象定义一个更新接口。具体主题（Concrete Subject）：将有关状态存入具体的观察者对象，当他的状态发生改变时，向他的各个观察者发出通知。具体观察者（Concrete Observer）

State模式也叫状态模式，是行为设计模式的一种。State模式允许通过改变对象的内部状态而改变对象的行为，这个对象表现得就好像修改了它的类一样。状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转译到表现不同状态的一系列类当中，可以把复杂的判断逻辑简化。

策略模式是指定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。也就是说这些算法所完成的功能一样，对外的接口一样，只是各自实现上存在差异。策略模式把对象本身和运算规则区分开来，其功能非常强大，因为这个设计模式本身的核心思想就是面向对象编程的多形性的思想。1）策略模式是一个比较容易理解和使用的设计模式，策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。

有许多模式都和模板模式非常相似，用的都是相同的手法。

代理模式是一种结构型设计模式，其主要目的是为其他对象提供一种代理，以控制对这些对象的访问。代理对象可以充当原始对象的包装器，将请求转发到原始对象，并且可以在转发请求之前或之后执行一些额外的操作。远程代理：用于在不同地址空间中的两个对象之间通信，将请求发送到远程对象。虚拟代理：用于延迟加载，即在需要时加载资源。保护代理：用于控制对对象的访问权限，例如，只有特定用户才能访问某个对象。缓存代理：用于缓存对象的访问结果，以避免重复执行计算密集型操作。实现代理模式可以使用抽象类和接口来定义代理和原始对象之间的。

隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。属于结构型模式。这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

享元模式（Flyweight Pattern）是一种结构型设计模式，它主要解决的问题是创建大量相似对象时的内存开销问题。该模式通过共享具有相同状态的对象来减少内存使用量。享元模式的思想是：当需要创建一个新对象时，首先检查是否已经存在具有相同状态的对象。如果存在，则返回已经存在的对象，否则创建一个新的对象。因此，如果要创建多个具有相同状态的对象，可以重复使用相同的对象，从而减少内存开销。通过运用共享技术来有效地支持大量细粒度对象的复用。

享元模式（Flyweight Pattern）是一种结构型设计模式，它主要解决的问题是创建大量相似对象时的内存开销问题。该模式通过共享具有相同状态的对象来减少内存使用量。享元模式的思想是：当需要创建一个新对象时，首先检查是否已经存在具有相同状态的对象。如果存在，则返回已经存在的对象，否则创建一个新的对象。因此，如果要创建多个具有相同状态的对象，可以重复使用相同的对象，从而减少内存开销。通过运用共享技术来有效地支持大量细粒度对象的复用。

对于树形结构，当容器对象（如文件夹）的某一个方法被调用时，将遍历整个树形结构，寻找也包含这个方法的成员对象（可以是容器对象，也可以是叶子对象，如子文件夹和文件）并调用执行。（递归调用）由于容器对象和叶子对象在功能上的区别，在使用这些对象的客户端代码中必须有区别地对待容器对象和叶子对象，而实际上大多数情况下客户端希望一致地处理它们，因为对于这些对象的区别对待将会使得程序非常复杂。

对于树形结构，当容器对象（如文件夹）的某一个方法被调用时，将遍历整个树形结构，寻找也包含这个方法的成员对象（可以是容器对象，也可以是叶子对象，如子文件夹和文件）并调用执行。（递归调用）由于容器对象和叶子对象在功能上的区别，在使用这些对象的客户端代码中必须有区别地对待容器对象和叶子对象，而实际上大多数情况下客户端希望一致地处理它们，因为对于这些对象的区别对待将会使得程序非常复杂。

假如现在有一块蛋糕，如果只涂上奶油，其他什么都不加，就是奶油蛋糕。如果加上草莓，就是草莓奶油蛋糕。如果再加上一块黑色巧克力板，上面用白色巧克力写上姓名，然后插上代表年龄的蜡烛，就变成了一块生日蛋糕。<br /> 不论是蛋糕、奶油蛋糕、草莓蛋糕还是生日蛋糕，它们的核心都是蛋糕。不过，经过涂上奶油，加上草莓等装饰后，蛋糕的味道变得更加甜美了，目的也变得更加明确了。<br /> 程序中的对象与蛋糕十分相似。首先有一个相当于蛋糕的对象，然后像不断地装饰蛋糕一样地不断地对其增加功能,它就变成了使用目的更加明确的对象。

* 适配器模式**是一种结构型设计模式， 它能将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。根据适配器类与适配者类的关系不同，适配器模式可分为对象适配器和类适配器两种，在对象适配器模式中，适配器与适配者之间是关联关系；在类适配器模式中，适配器与适配者之间是继承（或实现）关系。他和装饰器模式一样可以动态扩展一些遗留或者不好改动的代码。

该类持有一个对实现角色的引用以维护该对象，抽象角色中的方法需要实现角色来实现。抽象角色一般为抽象类(构造函数规定子类要传入一个实现角色)

用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象，简单理解就是“**克隆指定对象**”。

当构建一个复杂对象时，将构建过程与表示分离。使得同样的过程创建不同的对象。生成器与其他创建型模式不同， 生成器不要求产品拥有通用接口。这使得用相同的创建过程生成不同的产品成为可能。生成器方法通常支持方法链 （例如 someBuilder->setValueA(1)->setValueB(2)->create() ），来组成复杂的对象。相比于工厂模式专门用于生产一系列相关对象而言，生成器重点关注如何分步生成复杂对象。这也是我们常用创建模式的最后一节，后续将会带来结构模式的讲解。生成器。

当构建一个复杂对象时，将构建过程与表示分离。使得同样的过程创建不同的对象。生成器与其他创建型模式不同， 生成器不要求产品拥有通用接口。这使得用相同的创建过程生成不同的产品成为可能。生成器方法通常支持方法链 （例如 someBuilder->setValueA(1)->setValueB(2)->create() ），来组成复杂的对象。相比于工厂模式专门用于生产一系列相关对象而言，生成器重点关注如何分步生成复杂对象。这也是我们常用创建模式的最后一节，后续将会带来结构模式的讲解。生成器。

有时候我们在面对通用代码时候，经常会尝试着创建多个示例函数来对一个函数多次赋值，这样会损耗很多的内存空间，这对于代码来说是不利的。而单例模式可以很好的解决这个问题。但是实现一个实用的单例模式来说，这个并不容易。一般采用饿汉式，若对资源十分在意可以采用静态内部类，不建议采用懒汉式及双重检测。

工厂模式不管工厂怎么拆分抽象，都只是针对一类产品，如果需要多种产品，那就需要使用抽象工厂模式。抽象工厂模式通过在AbstarctFactory中增加创建产品的接口，并在具体子工厂中实现新加产品的创建，当然前提是子工厂支持生产该产品。否则继承的这个接口可以什么也不干。<br />!

工厂方法模式抽象出了工厂类，并把具体产品对象的创建放到具体工厂类实现。实现了一个工厂生产一类产品，不需要修改工厂类，只需要增加新的具体工厂类即可。每新增一个产品，就需要增加一个对应的产品的具体工厂类。：工厂模式的核心类，会定义一个用于创建指定的具体实例对象的接口。：核心类，提供创建具体产品的接口，由具体工厂类实现。扩展性非常差，新增产品的时候，需要去修改工厂类。：继承于抽象工厂，实现创建对应具体产品对象的方式。：工厂类所创建的对象就是此具体产品实例。：具体工厂所创建的对象，就是此类。

主函数调用，可动态扩展调用方法。

泛型编程是一种使用模板来编写代码的方法,可以让程序员编写与具体数据类型无关的代码。