结构型模式

适配器模式（在NBA我需要翻译）：将一个类的接口转换成客户希望的另外一个接口。使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。也就是说需要的东西就在面前，但是却不能使用，而短时间又无法改造它，于是就想办法适配它。就像电工学里，有些国家用110V电压，而我们国家用的是220V，而我们的笔记本电脑是不能什么电压都可以的，这就用到了电源适配器，把电源变成需要的电压，适配器使得一个东西适应另外一个东西。再如姚明打篮球，我们都知道篮球比赛要靠一个团队协作取胜的，那么姚明就要和教练还有球员交流作战计划了，问题来了，姚明不会外语，这个问题在短时间内又是无法解决的，所以就用到了翻译这个适配器，他使得姚明和团队能够更好的交流协作沟通无障碍。

何时使用适配器：系统的数据和行为都正确，但接口不符时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。就是在软件维护因不同的开发人员，不同的产品，不同的厂家而造成功能类似而接口不同的情况，此时就是适配器大展拳脚的时候了。

桥接模式 （手机软件何时统一）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。 符合合成/聚合复用原则

有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。

继承在这里不好的地方就在于，子类的实现与父类实现有密切的依赖关系，当继承下来的实现不适合解决新的问题，则父类就要重写或被更适合的类替换，一维的变化，导致多种手机软件下又都有多种品牌，形成了一个特别臃肿的体系。手机品牌和手机软件分离，二维变化，使得各自的扩展都互不影响，然后再将想要哪种品牌哪种软件的手机这两个维度组合起来。

组合模式（分公司=一部门）：将对象组合成树形结构以表示‘部分—整体’的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。符合里氏代换原则

总部，分部，职能部门形成树状结构，总部相当于一颗大树的根部的话，下属分公司就相当于树的分枝，职能部门就是树的叶子。总公司的组织结构可以复用于分公司，分部又相当于一个小的总部的结构。让我想起了一个挺符合组合模式的例子，小时候的夏天，家里常种的一种花叫做“死不了”，整棵小小的植物上长着叶子还有它的分枝，分枝上还可以再长分枝，随便掐下一个枝来栽到地上就又成了一株植物了。

何时使用组合模式 ：当发现需求中是体现部分与整体层次的结构时，以及希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式。

好处：基本对象可以被组合成更复杂的组合对象，组合对象又可以被组合，依次递归下去，任何用到基本对象的地方都可以使用组合对象了；让客户可以一致地使用组合结构和单个对象，不用单独判断是否是组合对象。

装饰模式（穿什么有那么重要？）：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。

内部组装完毕再显示出来。

建造者模式要求建造的过程必须是稳定的，装饰模式的建造过程不稳定。 装饰顺序很重要。

利用SetComponent来对对象进行包装的，每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中。

装饰模式是为已有功能动态地添加更多功能的一种方式。当系统需要新功能的时候，是向旧的类中添加新的代码，来装饰原有类的核心职责或主要行为。

装饰模式把每个要装饰的功能放在单独的类中并让这个类包装它所要修饰的对象，根据需要有选择地、按顺序地使用装饰功能包装对象。把类中的装饰功能从类中搬移去除，简化原有的类，这样的好处是有效地把类的核心职责和装饰功能区分开了，去除相关类中重复的装饰逻辑。

外观模式（牛市股票还会亏钱？）：为了系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。为复杂的子系统提供一个简单的接口，降低耦合。

收邮件这件事情就可以看做是一个外观模式，把所有我们该做的事情都汇聚到收邮件这一个接口，通过收邮件，来完成我们当天要做的各种事情，这样每一件事都不会漏掉。

何时使用：设计初期阶段，有意识的将不同的两个层分离，层与层之间建立外观。

开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观可以提供一个简单的接口，减少它们之间的依赖。

在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，为新系统开发一个外观类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，，让新系统与外观对象交互外观对象与遗留代码交互所有复杂的工作。

 

享元模式（项目多也别傻做）：运用共享技术有效地支持大量细粒度的对象。

共享对象来降低内存的损耗，

享元模式可以避免大量非常相似类的开销，在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的，有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数目。

实例化大量类似的东西时，要把相同部分抽象出来，把不同的部分作为参数传递，就能通过共享大量减少实例化的数目。

享元模式是一个类别的对个对象共享这个类别的一个对象，而不是各自再实例化各自的对象。这样达到了节省内存的目的。

 

代理模式（为别人做嫁衣）：为其他对象提供一种代理以控制对这个对象的访问。

代理和真实实体都实现同样的接口，因为代理必须要有追求者所要的方法。代理保存了一个引用使得代理可以访问实体，这样看似是代理做的事情，实则是真实实体做的。

区别

代理和外观

代理对象代表一个单一对象而外观对象代表一个子系统；

代理的客户对象无法直接访问目标对象，而由代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。

代理和适配器

代理是一种原来对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。

而适配器则不需要虚构出一个代表者，只需要为应付特定使用目的，将原来的类进行一些组合。