一般地，我们通过调用类的方法来实现某个功能。假设现在要执行一系列的方法实现复杂的完整功能，当需要取消这个完整功能时，Command模式就派上了用场。 Command模式要求每一个方法都定义成一个类，他们实现一个统一的接口。接口提供Execute和Unexecute方法来表示执行或者取消执行。然后会有一个Invoker通过Add方法将这些Command添加到一个列表（或者栈，或者队列都可以）...

Proxy有很多应用场景，比如： 虚拟代理（如果实例初始化很复杂很耗时，通过代理延迟到真正使用的时候再创建） 访问代理（在处理真正的请求时进行一定的验证） 远程代理（客户端像访问本地的资源一样，透明地访问远程资源，而无需关心到底资源在哪里） 所有这些，相同点都是：当实例不方便直接处理时，通过proxy包裹真正的对象，做适当的处理，再调用真正的对象。 通过一个Http代理...

Observer模式其实就是Publish-Subscribe模式，用于对于消息的响应。这里Observer的词语不是很恰当，因为Observer是要求订阅者主动去查询，而subscribe模式则是subject主动推送消息过来。两者恰恰是相反的。 了解到它的本质就是订阅模式，接下来就比较好设计了。对于消息的推送，是基于subject的某个状态变化的。这里假设有个手机商店，卖iphone和...

State模式非常适合那种用优先状态机来表达的工作流应用。比如有个文档的发布系统，创建文档的人要经历编辑、审核、批准到最后发布的几个状态。在某个状态上切换到其他状态，可能需要满足一定的条件。比如在批准阶段，就不允许再编辑了。在发布阶段，就不允许编辑、审核和批准。这样的工作流的状态切换最直观的解决方式是使用 if-else或者swtich-case来判断。但是有一个很大的问题是，一旦需要添加一...

Facade模式，每个人都在不知不觉地使用这个模式，它没有什么复杂的概念和技巧，其实类似一站式服务中心，或者像房产中介，它把后面的所有流程细节对调用者全部隐藏了。调用者无须知道复杂的细节，所有的事情交给一站式服务中心处理即可。 调用者有两种方式和一站式服务中心打交道： 知道具体功能的对象，把对象告诉服务中心 不知道有哪些对象，全权让服务中心处理 ...

Decorator模式从名字上来看就是有一点装修房子的感觉。比如在毛坯房的基础上，可以层层装修、丰富完善一个房子。它的使用场景针对一个已经存在的功能，想要在此基础上添加一些新的功能。但是这些新添加的功能不一定是确定的，可以根据需要添加一批功能，也可能想添加另外一组功能。 举例： 有一些紧急的通知，平时都是通过发送邮件的方式通知人员。后来有新的需求，想要同时发送邮件和短信。再然后，想同时发送...

Composite模式，就是组合模式，是一个比较有意思的思维，它没有什么设计技巧，完全就是一种思想，就是怎么看待一组关联、或者有包容关系的事物。 一棵树，树干上有树叶，树干上有树枝，然后树枝上也有树叶，他们之间存在一定的包容关系。树干是树枝和树叶的容器，树枝是树叶的容器。 文件夹和文件的概念，也有包容和嵌套包容的关系。在Windows中我们用Folder（或者Directory）和Fil...

Strategy模式的定义，就是委托者想要实现某种功能时，把具体的算法丢给被委托者去做，在一定时候，委托者还可以选择其他的被委托者实现不一样的效果。也就是说，每一个被委托者，实现特定的算法。至于这个算法是如何实现的，委托者不关心，它只负责交代任务给被委托者。 这种转嫁任务并可以选择不同被委托者的模式，就是策略模式。 可以自由选择不同的被委托者，从这句话的概念里肯定知道，委托者对象内部，一定...

Flyweight英文是轻量级的意思，表示把笨重的对象轻量化。这个怎么做到呢，其实做不到的。这里的设计的意图是：假设有大量的比较笨重的对象（创建时间长或者消耗内存大），每次实例化都需要消耗大量的资源，而这些对象如果恰恰是一样的，或者可以抽取出部分可以重用的那部分，如果将他们事先保存为一份，等到下次需要实例化的时候直接从内存里拿出来用，而不再重新创建。说最直接一点，就是最大化地共享可以重复使用...

桥接模式用于最开始的设计阶段，需要对一个对象进行不同维度的分析，并把不同维度独立出来，也就是把功能和实现进行分离 比如对于饮料这个对象而言，从大小的角度看有大杯、中杯和小杯三种功能，从口味的角度看有加冰可乐，鲜榨柠檬橘子汁等两种实现。反过来，也可以把口味定义为功能，把大小当成实现。 具体哪个维度作为功能，哪个维度作为实现，可以选择相对单一简单的那个维度为功能，复杂的维度作为实现。 所以...