状态模式：
概念：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

定义一个状态的父类，限定了可以执行的操作，并实例化用于存储现在状态。子类通过继承关系，实现不同状态下，进行各种操作的逻辑。这样可以保证对修改封闭，对添加开放。 当加入一个新的状态的时候，只需要继承父类并实现相应操作，并修改主线程逻辑即可。

同策略模式大同小异，但是实现的意图不一样。 策略模式是为了类的多样化，操作的多样化；状态模式是为了状态转换的易于实现和添加。

状态模式

代理模式：
概念：为另一个对象提供一个替身或占位符以访问这个对象

现在看来，应该就是类似于webservice或者是云服务吧。为客户提供一个接口，告诉他可以实现的功能，然后客户就可以使用这个接口完成想要进行的操作。实际上，这个接口只是调用了一个远程的服务，将数据传递过去并将结果传递回来。

现在的很多像soap和hessian都可以很好的完成，另外还有python和ruby等脚本语言应该也比较方便的实现。

代理模式

复合模式：

概念：复合模式结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。

问题的引出：

一大堆Quackable —– 策略模式，继承

有一只鹅出现了，它希望自己像一个Quackable —– 适配器模式

然后，呱呱叫学家决定要计算呱呱叫声的次数 —– 工厂模式生成

但是呱呱叫学家担心他们忘了加上QuackCounter装饰者 —– 装饰者模式

又是鸭子，又是鹅，又是Quackable的……我们有管理上的困扰 —– 组合模式和迭代器模式

当任何呱呱声响起时，呱呱叫学家都希望能被告知 —– 观察者模式

实际上，就MVC框架就是很好的一个复合模式

其他的一些模式

桥接模式：不只改变你的实现，也改变你的抽象。

生成器模式：封装一个产品的构造过程，并允许步骤构造。

责任链模式：让一个以上的对象有机会能够处理某个请求。（处理流程）

蝇量模式：让某个类的一个实例能用来提供许多“虚拟实例”。（类似不同大小不同内容的注释文字）

解释器模式：为语言创建解释器。（编译原理的词法分析，语法分析）

中介者模式：集中相关对象之间复杂的沟通和控制方式。（卖房中介，可以应对不同房源，不同买房主，卖房主，有自己的营销策略）

备忘录模式：可以让对象返回之前的状态。（动态规划里面的备忘录方法）

原型模式：创建给定类的实例的过程很昂贵或很复杂时使用。

访问者模式：可以为一个对象的组合增加新的能力，且封装并不重要时使用。

适配器模式：
概念：将一个类的接口，转换成客户期望的另一个接口。适配器让原本不兼容的类可以合作无间。
比如我们要将一个火鸡封装成一个鸭子，因为我们现在只有处理鸭子的机器方法。那么我们使用一个将火鸡转换成鸭子的适配器类，类中包含一个火鸡对象，当需要它鸣叫时，调用火鸡的鸣叫方法，需要飞时，调用火鸡的飞行方法。通俗理解就像插头转换器一样，所以叫适配器模式。

与装饰者模式（不改变接口，但加入方法）不同的是，适配器模式是直接将一个接口转成另一个接口。

适配器模式

外观模式：

概念：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

就是说把一些相关的类的操作集合在了一起，创建了一个流程的感觉。类似于功能的集合，比如按遥控器的家庭影院按钮，会关灯，开音响，下降幕布等一系列操作。

外观模式

模板方法模式：

概念：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

算法的骨架使用final定义，不可改变。可以延迟的步骤使用抽象方法abstract。比如可以定义制造咖啡，牛奶和茶的方法步骤，只是冲泡的内容不一样，添加的调料不一样，都需要烧开水和装杯（可能杯子也不一样）。

模板方法模式

迭代器模式：

概念：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。

比较好理解，就是比如有几种集合元素，数组，ArrayList，Hashmap，使用Iterator迭代获得全部元素。需要注意的是可以自己写一些Iterator方法，和compareTo方法，来完成比较。

迭代器模式

组合模式：

概念：允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

就是借鉴的树的概念，一个结点，可以是父节点，也可以是子结点，迭代器会相同对待。他们共同继承自Component，可以将对象的集合以及个别的对象一视同仁。。复杂的是在迭代的过程中，要考虑到遍历的顺序，可以参考深搜和广搜。

组合模式

这是一本好书
上班第17天，今天发工资，哇咔咔
============================================
策略模式：
概念：定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
通俗来讲，就是有一个父类型，他有一些方法，子类型可以继承这些方法，但是这些方法在子类中的表现又不尽相同。
所以将父类型中的一些方法，也变成接口和类来处理，这样可以在构造子类的时候，选择对应的父类不同的方法来构造。

策略模式

观察者模式：
概念：定义了对象之间的一对多依赖，这样依赖，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
例子是天气预报，接收到新数据后对三个指示器进行更新。指示器继承自object并都有update方法。主题对象将不同的object加入到array，在获取数据后对全部object进行自动更新。

观察者模式

装饰者模式：
概念：动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
比如星巴兹咖啡的解决方案：先定义一个基类，有描述和花费两个方法，一般的咖啡直接继承该父类即可。如果需要加调料，使用继承自基类的装饰者类，用原始的对象构造新的对象，并添加额外的花费即可。

装饰者模式

工厂方法模式：
概念：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
在制作pizza的时候，使用pizza工厂类，来根据不同的type选择实例化不同的pizza style。这样可以保证在对之后的处理独立。
也就是把一串的if else移到专门的工厂类里面去，保证代码的稳定性。
包括：一般工厂模式，抽象工厂模式（可以有很多不同的工厂实现自同一个抽象工厂，比如pizza的原料也可以不同）

工厂模式

单件模式：
概念：确保一个类只有一个实例，并提供一个全局访问点
Singleton模式的实现基于两个要点：
　　1）不直接用类的构造函数，而另外提供一个Public的静态方法来构造类的实例。通常这个方法取名为Instance。Public保证了它的全局可见性，静态方法保证了不会创建出多余的实例。
　　2）将类的构造函数设为Private，即将构造函数”隐藏”起来，任何企图使用构造函数创建实例的方法都将报错。这样就阻止了开发人员绕过上面的Instance方法直接创建类的实例。
　　通过以上两点就可以完全控制类的创建：无论有多少地方需要用到这个类，它们访问的都是类的唯一生成的那个实例。

命令模式：
概念：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
定义一个命令接口，具有execute方法，其他命令已此为基础。使用命令的对象包含一个command，通过set方法指定不同的命令并调用execute方法即可实现命令操作。

命令模式