公司组织结构在学习和使用组合模式时，Sunny 软件公司开发人员发现树形结构其实随处可见，例如 Sunny 公司的组织结构就是“一棵标准的树”，如图所示： 在 Sunny 软件公司的内部办公系统 Sunny OA 系统中，有一个与公司组织结构对应的树形菜单，行政人员可以给各级单位下发通知，这些单位可以是总公司的一个部门，也可以是一个分公司，还可以是分公司的一个部门。
透明组合模式与安全组合模式通过引入组合模式，Sunny 公司设计的杀毒软件具有良好的可扩展性，在增加新的文件类型时，无须修改现有类库代码，只需增加一个新的文件类作为 AbstractFile 类的子类即可，但是由于在 AbstractFile 中声明了大量用于管理和访问成员构件的方法，例如 add()、remove() 等方法，我们不得不在新增的文件类中实现这些方法，提供对应的错误提示和异常处理…
完整解决方案为了让系统具有更好的灵活性和可扩展性，客户端可以一致地对待文件和文件夹，Sunny 公司开发人员使用组合模式来进行杀毒软件的框架设计，其基本结构如图所示： 在图中， AbstractFile 充当抽象构件类，Folder 充当容器构件类，ImageFile、TextFile 和 VideoFile 充当叶子构件类。完整代码如下所示： import java.util.*;
组合模式概述对于树形结构，当容器对象（如文件夹）的某一个方法被调用时，将遍历整个树形结构，寻找也包含这个方法的成员对象（可以是容器对象，也可以是叶子对象）并调用执行，牵一而动百，其中使用了递归调用的机制来对整个结构进行处理。
树形结构在软件中随处可见，例如操作系统中的目录结构、应用软件中的菜单、办公系统中的公司组织结构等等，如何运用面向对象的方式来处理这种树形结构是组合模式需要解决的问题，组合模式通过一种巧妙的设计方案使得用户可以一致性地处理整个树形结构或者树形结构的一部分，也可以一致性地处理树形结构中的叶子节点（不包含子节点的节点）和容器节点（包含子节点的节点）。
适配器模式与桥接模式的联用在软件开发中，适配器模式通常可以与桥接模式联合使用。适配器模式可以解决两个已有接口间不兼容问题，在这种情况下被适配的类往往是一个黑盒子，有时候我们不想也不能改变这个被适配的类，也不能控制其扩展。适配器模式通常用于现有系统与第三方产品功能的集成，采用增加适配器的方式将第三方类集成到系统中。
完整解决方案为了减少所需生成的子类数目，实现将操作系统和图像文件格式两个维度分离，使它们可以独立改变，Sunny 公司开发人员使用桥接模式来重构跨平台图像浏览系统的设计，其基本结构如图所示： 在图中，Image 充当抽象类，其子类 JPGImage、PNGImage、BMPImage 和 GIFImage 充当扩充抽象类；
桥接模式概述桥接模式是一种很实用的结构型设计模式，如果软件系统中某个类存在两个独立变化的维度，通过该模式可以将这两个维度分离出来，使两者可以独立扩展，让系统更加符合“单一职责原则”。与多层继承方案不同，它将两个独立变化的维度设计为两个独立的继承等级结构，并且在抽象层建立一个抽象关联，该关联关系类似一条连接两个独立继承结构的桥，故名桥接模式。
在正式介绍桥接模式之前，我先跟大家谈谈两种常见文具的区别，它们是毛笔和蜡笔。假如我们需要大中小 3 种型号的画笔，能够绘制 12 种不同的颜色，如果使用蜡笔，需要准备 3×12 = 36 支，但如果使用毛笔的话，只需要提供 3 种型号的毛笔，外加 12 个颜料盒即可，涉及到的对象个数仅为 3 + 12 = 15，远小于36，却能实现与 36 支蜡笔同样的功能。
缺省适配器缺省适配器模式是适配器模式的一种变体，其应用也较为广泛。
类适配器除了对象适配器模式之外，适配器模式还有一种形式，那就是类适配器模式，类适配器模式和对象适配器模式最大的区别在于适配器和适配者之间的关系不同，对象适配器模式中适配器和适配者之间是关联关系，而类适配器模式中适配器和适配者是继承关系，类适配器模式结构如图所示： 根据类适配器模式结构图，适配器类实现了抽象目标类接口 Target，并继承了适配者类，在…
完整解决方案Sunny 软件公司开发人员决定使用适配器模式来重用算法库中的算法，其基本结构如图 9-4 所示： 在图中，ScoreOperation 接口充当抽象目标，QuickSort 和 BinarySearch 类充当适配者，OperationAdapter 充当适配器。完整代码如下所示： //抽象成绩操作类：目标接口interface ScoreOperation { public int[] sort(int array[]);
我的笔记本电脑的工作电压是 20 V，而我国的家庭用电是 220 V，如何让 20 V 的笔记本电脑能够在 220 V 的电压下工作？
软件模式与具体的应用领域无关，也就是说无论你从事的是移动应用开发、桌面应用开发、Web 应用开发还是嵌入式软件的开发，都可以使用软件模式。 在软件模式中，设计模式是研究最为深入的分支，设计模式用于在特定的条件下为一些重复出现的软件设计问题提供合理的、有效的解决方案，它融合了众多专家的设计经验，已经在成千上万的软件中得以应用。
定义一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。问题由来在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。解决方案当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
定义一个对象应该对其他对象保持最少的了解。问题由来类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。解决方案尽量降低类与类之间的耦合。自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。
定义客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。问题由来类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。解决方案将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
定义高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。问题由来类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。定义 1如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
定义不要存在多于一个导致类变更的原因。**通俗的说，即一个类只负责一项职责。问题由来类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；
关注时代Java
