一结构型模式

二适配器模式

下面我将用代码模拟键盘usb接口和ps/2的转接器的适配器过程：
首先定义客户需求：

package GOF23;public interface Target {void handleReq();
}

被适配的类：

package GOF23;
/*** 被适配的类（相当于例子中的PS/2键盘)* @author lenovo**/
public class Adaptee {public void request() {System.out.println("可以完成客户需要的功能！");}}

适配器为了实现被适配的类必须对其进行继承：

package GOF23;
/*** 适配器(相当于usb和ps/2的转接器)* @author lenovo**/
public class Adapter extends Adaptee implements Target {@Overridepublic void handleReq() {super.request();}}

另一种适配器：

package GOF23;
/*** 适配器(对象适配器方式, 使用了组合的方式跟被适配的对象整合)* @author lenovo**/
public class Adapter2 extends Adaptee implements Target {private Adaptee adaptee;@Overridepublic void handleReq() {adaptee.request();}public Adapter2(Adaptee adaptee) {super();this.adaptee = adaptee;}}

客户端：

package GOF23;
/*** 客户端(相当于例子中的笔记本,只有USB接口)* @author lenovo**/
public class AdapterClient {public void test1(Target t) {t.handleReq(); //发送打字请求}public static void main(String[] args) {AdapterClient c = new AdapterClient(); //客户Adaptee a = new Adaptee(); //被适配的类
//      Target t = new Adapter(); //需求Target t = new Adapter2(a);c.test1(t);}
}

它们之间的UML关系：

三代理模式

什么是代理模式？

代理模式的定义：代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。通俗的来讲代理模式就是我们生活中常见的中介。

举个例子来说明：假如说我现在想买一辆二手车，虽然我可以自己去找车源，做质量检测等一系列的车辆过户流程，但是这确实太浪费我得时间和精力了。我只是想买一辆车而已为什么我还要额外做这么多事呢？于是我就通过中介公司来买车，他们来给我找车源，帮我办理车辆过户流程，我只是负责选择自己喜欢的车，然后付钱就可以了。用图表示如下：

为什么要用代理模式？

中介隔离作用：在某些情况下，一个客户类不想或者不能直接引用一个委托对象，而代理类对象可以在客户类和委托对象之间起到中介的作用，其特征是代理类和委托类实现相同的接口。
开闭原则，增加功能：代理类除了是客户类和委托类的中介之外，我们还可以通过给代理类增加额外的功能来扩展委托类的功能，这样做我们只需要修改代理类而不需要再修改委托类，符合代码设计的开闭原则。代理类主要负责为委托类预处理消息、过滤消息、把消息转发给委托类，以及事后对返回结果的处理等。代理类本身并不真正实现服务，而是同过调用委托类的相关方法，来提供特定的服务。真正的业务功能还是由委托类来实现，但是可以在业务功能执行的前后加入一些公共的服务。例如我们想给项目加入缓存、日志这些功能，我们就可以使用代理类来完成，而没必要打开已经封装好的委托类。

有哪几种代理模式？

我们有多种不同的方式来实现代理。如果按照代理创建的时期来进行分类的话，可以分为两种：静态代理、动态代理。静态代理是由程序员创建或特定工具自动生成源代码，在对其编译。在程序员运行之前，代理类.class文件就已经被创建了。动态代理是在程序运行时通过反射机制动态创建的。

（1）静态代理：

下面我将举一个明星和经济人之间的关系：
首先我们先定义一个明星所要做的所有事的所有接口：

package GOF23;public interface Star {void confer(); //面谈void signContract(); //签合同void bookTicket(); //定票void sing(); //唱歌void collet(); //收款
}

接着就是定义明星类：

package GOF23;
/*** 静态代理类* @author lenovo**/
public class staticProxy_RealStar implements Star {@Overridepublic void confer() {System.out.println("RealStar.confer()");}@Overridepublic void signContract() {System.out.println("RealStar.signContract()");}@Overridepublic void bookTicket() {System.out.println("RealStar.bookTicket()");}@Overridepublic void sing() {System.out.println("RealStar(周杰伦).sing()");}@Overridepublic void collet() {System.out.println("RealStar().collet()");}}

然后再定义代理类，实现全部业务，唯独sing()不可以，必须调用realstar.sing()来实现：

package GOF23;
/*** 明星代理人* @author lenovo**/
public class staticProxy_ProxyStar implements Star {private Star star;public staticProxy_ProxyStar(Star star) {super();this.star = star;}@Overridepublic void confer() {System.out.println("ProxyStar.confer()");}@Overridepublic void signContract() {System.out.println("ProxyStar.signContract()");}@Overridepublic void bookTicket() {System.out.println("ProxyStar.bookTicket()");}@Overridepublic void sing() {star.sing();}@Overridepublic void collet() {System.out.println("ProxyStar.collet()");}
}

客户端只需要负责和代理人谈就可以让歌手唱歌：

package GOF23;public class ProxyClient {public static void main(String[] args) {Star real = new staticProxy_RealStar(); //明星Star proxy = new staticProxy_ProxyStar(real); //明星代理人proxy.confer();proxy.signContract();proxy.bookTicket();proxy.sing(); //客户找代理人proxy,proxy再找明星调用他的sing()方法proxy.collet();}
}

它们之间的UML关系：

静态代理总结：

优点：可以做到在符合开闭原则的情况下对目标对象进行功能扩展。

缺点：我们得为每一个服务都得创建代理类，工作量太大，不易管理。同时接口一旦发生改变，代理类也得相应修改。

（2）动态代理：

　　在动态代理中我们不再需要再手动的创建代理类，我们只需要编写一个动态处理器就可以了。真正的代理对象由JDK再运行时为我们动态的来创建。

动态代理中明星接口：

package GOF23;public interface dynamicProxyStar {void confer(); //面谈void signContract(); //签合同void bookTicket(); //定票void sing(); //唱歌void collet(); //收款
}

明星类：

package GOF23;
/*** 动态代理类* @author lenovo**/
public class dynamicProxy_RealStar implements dynamicProxyStar {@Overridepublic void confer() {System.out.println("RealStar.confer()");}@Overridepublic void signContract() {System.out.println("RealStar.signContract()");}@Overridepublic void bookTicket() {System.out.println("RealStar.bookTicket()");}@Overridepublic void sing() {System.out.println("RealStar(周杰伦).sing()");}@Overridepublic void collet() {System.out.println("RealStar().collet()");}}

实现动态代理：

package GOF23;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
/*** 实现动态代理* @author lenovo**/
public class StarHandler implements InvocationHandler {dynamicProxyStar realstar;public StarHandler(dynamicProxyStar realstar) {super();this.realstar = realstar;}@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable {Object object = null;System.out.println("真正的方法执行前：");System.out.println("面谈、签合同、预付款");if(method.getName().equals("sing") ) {object = method.invoke(realstar, args); //每当一个方法被调用时，激活此方法}System.out.println("真正的方法执行！");System.out.println("收尾款");return object;}}

客户端：

package GOF23;import java.lang.reflect.Proxy;public class dynamicProxyClient {public static void main(String[] args) {dynamicProxyStar realstar = new dynamicProxy_RealStar();StarHandler handler = new StarHandler(realstar); //创建一个代理对象//创建一个代理器dynamicProxyStar proxy = (dynamicProxyStar) Proxy.newProxyInstance(ClassLoader.getSystemClassLoader(), new Class[] {dynamicProxyStar.class}, handler);proxy.sing();}
}

结果：

当检测到sing()方法时候就激活此方法,动态调用明星的sing().

注意Proxy.newProxyInstance()方法接受三个参数：

ClassLoader loader:指定当前目标对象使用的类加载器,获取加载器的方法是固定的
Class<?>[] interfaces:指定目标对象实现的接口的类型,使用泛型方式确认类型
InvocationHandler:指定动态处理器，执行目标对象的方法时,会触发事件处理器的方法

动态代理总结：虽然相对于静态代理，动态代理大大减少了我们的开发任务，同时减少了对业务接口的依赖，降低了耦合度。但是还是有一点点小小的遗憾之处，那就是它始终无法摆脱仅支持interface代理的桎梏，因为它的设计注定了这个遗憾。回想一下那些动态生成的代理类的继承关系图，它们已经注定有一个共同的父类叫Proxy。Java的继承机制注定了这些动态代理类们无法实现对class的动态代理，原因是多继承在Java中本质上就行不通。有很多条理由，人们可以否定对 class代理的必要性，但是同样有一些理由，相信支持class动态代理会更美好。接口和类的划分，本就不是很明显，只是到了Java中才变得如此的细化。如果只从方法的声明及是否被定义来考量，有一种两者的混合体，它的名字叫抽象类。实现对抽象类的动态代理，相信也有其内在的价值。此外，还有一些历史遗留的类，它们将因为没有实现任何接口而从此与动态代理永世无缘。如此种种，不得不说是一个小小的遗憾。但是，不完美并不等于不伟大，伟大是一种本质，Java动态代理就是佐例。

四桥接模式（一般桥接模式适用于两个变化维度）

上述问题的UML关系模型：

实现代码：

电脑类的接口：

public interface BridgeComputer {void sale();
}

类型电脑类的实现：

class Desktop implements BridgeComputer {@Overridepublic void sale() {System.out.println("销售台式机！");}}
class Laptop implements BridgeComputer {@Overridepublic void sale() {System.out.println("销售笔记本！");}
}
class Pad implements BridgeComputer {@Overridepublic void sale() {System.out.println("销售平板电脑！");}
}

具体品牌电脑类的实现：

class LenovoDesktop extends Desktop {@Overridepublic void sale() {System.out.println("销售联想台式机！");}
}
class LenovoLaptop extends Desktop {@Overridepublic void sale() {System.out.println("销售联想笔记本！");}
}
class LenovoPad extends Desktop {@Overridepublic void sale() {System.out.println("销售联想平板电脑！");}
}class ShenzhouDesktop extends Desktop {@Overridepublic void sale() {System.out.println("销售神州台式机！");}
}
class ShenzhouLaptop extends Desktop {@Overridepublic void sale() {System.out.println("销售神州笔记本！");}
}
class ShenzhouPad extends Desktop {@Overridepublic void sale() {System.out.println("销售神州平板电脑！");}
}class DellDesktop extends Desktop {@Overridepublic void sale() {System.out.println("销售戴尔台式机！");}
}
class DellLaptop extends Desktop {@Overridepublic void sale() {System.out.println("销售戴尔笔记本！");}
}
class DellPad extends Desktop {@Overridepublic void sale() {System.out.println("销售戴尔平板电脑！");}
}

出现的问题：可扩展性差！

那么我们该如何改良呢？

下面我将使用桥接模式：

我们将电脑的类型和品牌分开成两个接口，以便我们后面添加：

电脑类型维度：

package GOF23;/*** 电脑类型维度* * @author lenovo**/
public class Bridge_Computer {protected Bridge_Brand brand;public Bridge_Computer(Bridge_Brand b) {this.brand = b;}public void sale() {brand.sale();}
}class Desktop1 extends Bridge_Computer {public Desktop1(Bridge_Brand b) {super(b);}@Overridepublic void sale() {super.sale();System.out.println("销售台式机！");}
}class Laptop1 extends Bridge_Computer {public Laptop1(Bridge_Brand b) {super(b);}@Overridepublic void sale() {super.sale();System.out.println("销售笔记本！");}
}

电脑品牌维度：

package GOF23;
/*** 电脑品牌维度* @author lenovo**/
public interface Bridge_Brand {void sale();
}class Lenovo implements Bridge_Brand {@Overridepublic void sale() {System.out.println("销售联想电脑！");}}class Dell implements Bridge_Brand {@Overridepublic void sale() {System.out.println("销售戴尔电脑！");}}

客户端我们可以用组合的方式构建一台电脑来代替多层继承：

package GOF23;public class Bridge_Client {public static void main(String[] args) {// 构建联想的笔记本Bridge_Computer c = new Laptop1(new Lenovo());c.sale();}
}

这就将两个维度分开了，我们可以随意添加电脑的品牌和类型！

下面我们来画出桥接模式的UML模型：

桥接模式的要点：

桥接模式总结：

五装饰模式

　装饰器模式是一种用于代替继承的技术，无需通过继承增加子类就能扩展对象的新功能。使用对象的关联关系代替继承关系，更加灵活，同时避免类型体系的快速膨胀。

开发中的使用场景：

　　IO中输入流和输出流的设计

　　Swing包中图形界面构件功能

　　Servlet API中提供了一个request对象的Decorator设计模式的默认实现类HttpServletRequestWrapper，HttpServletRequestWrapper类增强了request对象的功能。

　　Struts2中，request，response，session对象的处理

实现细节：

——Component抽象构件角色：真实对象和装饰对象有相同的接口。这样，客户端对象就能够以与真实对象相同的方式同装饰对象交互。

——ConcreteComponent具体构件角色（真实对象）：io流中的FileInputStream、　　　　FileOutputStream

——Decorator装饰角色：持有一个抽象构件的引用。装饰对象接受所有客户端的请求，并把这些请求转发给真实的对象。这样，就能在真实对象调用前后增加新的功能。

——ConcreteDecorator具体装饰角色：负责给构件对象增加新的责任。

1. 创建一个抽象组件Decorator_ICar接口，并创建具体构建角色以及各个具体装饰角色

package GOF23;/*** 抽象构建设* * @author lenovo**/
public interface Decorator_ICar {void move();
}// ConcreteComponent 具体构建角色(真实对象)
class D_Car implements Decorator_ICar {@Overridepublic void move() {System.out.println("陆地上跑！");}
}// Decorator装饰角色
class SuperCar implements Decorator_ICar {// 装饰器必须要持有装饰器类的一个引用protected Decorator_ICar car; // 当它所继承的子类需要使用此个成员时，需定义为protected,不能用privatepublic SuperCar(Decorator_ICar car) {super();this.car = car;}@Overridepublic void move() {car.move();}
}// ConcreteComponent 具体装饰角色
class FlyCar extends SuperCar {public FlyCar(Decorator_ICar car) {super(car);}public void fly() {System.out.println("天上飞！");}public void move() {super.move();fly();}}// ConcreteComponent 具体装饰角色
class WaterCar extends SuperCar {public WaterCar(Decorator_ICar car) {super(car);}public void swim() {System.out.println("水上游！");}public void move() {super.move();swim();}
}// ConcreteComponent 具体装饰角色
class AICar extends SuperCar {public AICar(Decorator_ICar car) {super(car);}public void autoMove() {System.out.println("自动跑！");}public void move() {super.move();autoMove();}
}

2. 创建测试类Client

package GOF23;public class Decorator_Client {public static void main(String[] args) {D_Car car = new D_Car(); //定义真实的车car.move();System.out.println("给汽车增加飞行的功能！");FlyCar flyCar = new FlyCar(car);flyCar.move();System.out.println("给汽车增加水上游的功能！");WaterCar waterCar = new WaterCar(car);waterCar.move();System.out.println("给汽车同时增加飞行和水上游两个功能！");WaterCar waterCar2  = new WaterCar(new FlyCar(car));waterCar2.move();}
}

3 结果：

4 UML图：

总结：

　　装饰模式（Decorator）也叫包装器模式（Wrapper）

　　装饰模式降低系统的耦合度，可以动态的增加或删除对象的职责，并使得需要装饰的具体构建类和具体装饰类可以独立变化，以便增加新的具体构建类和具体装饰类。

　　优点：

扩展对象功能，比继承灵活，不会导致类个数急剧增加
可以对一个对象进行多次装饰，创造出不同行为的组合，得到功能更加强大的对象
具体构建类和具体装饰类可以独立变化，用户可以根据需要自己增加新的具体构件子类和具体装饰子类

　　缺点：

产生很多小对象。大量小对象占据内存，一定程度上影响性能
装饰模式易于出错，调试排查比较麻烦

装饰模式和桥接模式的区别：

两个模式都是为了解决过多子类对象问题。但他们的诱因不一样。桥接模式是对象自身现有机制沿着多个维度变化，是既有部分不稳定。装饰模式是为了增加新的功能。

六组合模式（注意：并不是我们所说的继承中的组合）

树形结构在软件中随处可见，例如操作系统中的目录结构、应用软件中的菜单、办公系统中的公司组织结构等等，如何运用面向对象的方式来处理这种树形结构是组合模式需要解决的问题，组合模式通过一种巧妙的设计方案使得用户可以一致性地处理整个树形结构或者树形结构的一部分，也可以一致性地处理树形结构中的叶子节点（不包含子节点的节点）和容器节点（包含子节点的节点）。下面将学习这种用于处理树形结构的组合模式。

11.1 设计杀毒软件的框架结构

Sunny软件公司欲开发一个杀毒(AntiVirus)软件，该软件既可以对某个文件夹(Folder)杀毒，也可以对某个指定的文件(File)进行杀毒。该杀毒软件还可以根据各类文件的特点，为不同类型的文件提供不同的杀毒方式，例如图像文件(ImageFile)和文本文件(TextFile)的杀毒方式就有所差异。现需要提供该杀毒软件的整体框架设计方案。

在介绍Sunny公司开发人员提出的初始解决方案之前，我们先来分析一下操作系统中的文件目录结构，例如在Windows操作系统中，存在如图11-1所示目录结构：

图11-1 Windows目录结构

图11-1可以简化为如图11-2所示树形目录结构：

图11-2 树形目录结构示意图

我们可以看出，在图11-2中包含文件（灰色节点）和文件夹（白色节点）两类不同的元素，其中在文件夹中可以包含文件，还可以继续包含子文件夹，但是在文件中不能再包含子文件或者子文件夹。在此，我们可以称文件夹为容器(Container)，而不同类型的各种文件是其成员，也称为叶子(Leaf)，一个文件夹也可以作为另一个更大的文件夹的成员。如果我们现在要对某一个文件夹进行操作，如查找文件，那么需要对指定的文件夹进行遍历，如果存在子文件夹则打开其子文件夹继续遍历，如果是文件则判断之后返回查找结果。

下面我们用代码模拟杀毒软件：

Sunny软件公司的开发人员通过分析，决定使用面向对象的方式来实现对文件和文件夹的操作，定义了如下图像文件类ImageFile、文本文件类TextFile和文件夹类Folder：

//为了突出核心框架代码，我们对杀毒过程的实现进行了大量简化
import java.util.*;  //图像文件类
class ImageFile {  private String name;  public ImageFile(String name) {  this.name = name;  }  public void killVirus() {  //简化代码，模拟杀毒  System.out.println("----对图像文件'" + name + "'进行杀毒");  }
}  //文本文件类
class TextFile {  private String name;  public TextFile(String name) {  this.name = name;  }  public void killVirus() {  //简化代码，模拟杀毒  System.out.println("----对文本文件'" + name + "'进行杀毒");  }
}  //文件夹类
class Folder {  private String name;  //定义集合folderList，用于存储Folder类型的成员  private ArrayList<Folder> folderList = new ArrayList<Folder>();  //定义集合imageList，用于存储ImageFile类型的成员  private ArrayList<ImageFile> imageList = new ArrayList<ImageFile>();  //定义集合textList，用于存储TextFile类型的成员  private ArrayList<TextFile> textList = new ArrayList<TextFile>();  public Folder(String name) {  this.name = name;  }  //增加新的Folder类型的成员  public void addFolder(Folder f) {  folderList.add(f);  }  //增加新的ImageFile类型的成员  public void addImageFile(ImageFile image) {  imageList.add(image);  }  //增加新的TextFile类型的成员  public void addTextFile(TextFile text) {  textList.add(text);  }  //需提供三个不同的方法removeFolder()、removeImageFile()和removeTextFile()来删除成员，代码省略  //需提供三个不同的方法getChildFolder(int i)、getChildImageFile(int i)和getChildTextFile(int i)来获取成员，代码省略  public void killVirus() {  System.out.println("****对文件夹'" + name + "'进行杀毒");  //模拟杀毒  //如果是Folder类型的成员，递归调用Folder的killVirus()方法  for(Object obj : folderList) {  ((Folder)obj).killVirus();  }  //如果是ImageFile类型的成员，调用ImageFile的killVirus()方法  for(Object obj : imageList) {  ((ImageFile)obj).killVirus();  }  //如果是TextFile类型的成员，调用TextFile的killVirus()方法  for(Object obj : textList) {  ((TextFile)obj).killVirus();  }  }
}

编写如下客户端测试代码进行测试：

class Client {  public static void main(String args[]) {  Folder folder1,folder2,folder3;  folder1 = new Folder("Sunny的资料");  folder2 = new Folder("图像文件");  folder3 = new Folder("文本文件");  ImageFile image1,image2;  image1 = new ImageFile("小龙女.jpg");  image2 = new ImageFile("张无忌.gif");  TextFile text1,text2;  text1 = new TextFile("九阴真经.txt");  text2 = new TextFile("葵花宝典.doc");  folder2.addImageFile(image1);  folder2.addImageFile(image2);  folder3.addTextFile(text1);  folder3.addTextFile(text2);  folder1.addFolder(folder2);  folder1.addFolder(folder3);  folder1.killVirus();  }
}

编译并运行程序，输出结果如下：

Sunny公司开发人员“成功”实现了杀毒软件的框架设计，但通过仔细分析，发现该设计方案存在如下问题：

(1) 文件夹类Folder的设计和实现都非常复杂，需要定义多个集合存储不同类型的成员，而且需要针对不同的成员提供增加、删除和获取等管理和访问成员的方法，存在大量的冗余代码，系统维护较为困难；

(2) 由于系统没有提供抽象层，客户端代码必须有区别地对待充当容器的文件夹Folder和充当叶子的ImageFile和TextFile，无法统一对它们进行处理；

(3) 系统的灵活性和可扩展性差，如果需要增加新的类型的叶子和容器都需要对原有代码进行修改，例如如果需要在系统中增加一种新类型的视频文件VideoFile，则必须修改Folder类的源代码，否则无法在文件夹中添加视频文件。

面对以上问题，Sunny软件公司的开发人员该如何来解决？这就需要用到本章将要介绍的组合模式，组合模式为处理树形结构提供了一种较为完美的解决方案，它描述了如何将容器和叶子进行递归组合，使得用户在使用时无须对它们进行区分，可以一致地对待容器和叶子。

11.2 组合模式概述

对于树形结构，当容器对象（如文件夹）的某一个方法被调用时，将遍历整个树形结构，寻找也包含这个方法的成员对象（可以是容器对象，也可以是叶子对象）并调用执行，牵一而动百，其中使用了递归调用的机制来对整个结构进行处理。由于容器对象和叶子对象在功能上的区别，在使用这些对象的代码中必须有区别地对待容器对象和叶子对象，而实际上大多数情况下我们希望一致地处理它们，因为对于这些对象的区别对待将会使得程序非常复杂。组合模式为解决此类问题而诞生，它可以让叶子对象和容器对象的使用具有一致性。

组合模式定义如下：

组合模式(Composite Pattern)：组合多个对象形成树形结构以表示具有“整体—部分”关系的层次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性，组合模式又可以称为“整体—部分”(Part-Whole)模式，它是一种对象结构型模式。

在组合模式中引入了抽象构件类Component，它是所有容器类和叶子类的公共父类，客户端针对Component进行编程。组合模式结构如图11-3所示：

图11-3 组合模式结构图

抽象构件、叶子构件、容器构件：

package GOF23;/*** 抽象组件* * @author lenovo**/
public interface Component {void operation();
}/*** 叶子组件* * @author lenovo**/
interface Leaf extends Component {
}/*** 容器组件* * @author lenovo**/
interface Composite extends Component {void add(Component c);void remove(Component c);Component getChild(int index);
}

在组合模式结构图中包含如下几个角色：

● Component（抽象构件）：它可以是接口或抽象类，为叶子构件和容器构件对象声明接口，在该角色中可以包含所有子类共有行为的声明和实现。在抽象构件中定义了访问及管理它的子构件的方法，如增加子构件、删除子构件、获取子构件等。

● Leaf（叶子构件）：它在组合结构中表示叶子节点对象，叶子节点没有子节点，它实现了在抽象构件中定义的行为。对于那些访问及管理子构件的方法，可以通过异常等方式进行处理。

● Composite（容器构件）：它在组合结构中表示容器节点对象，容器节点包含子节点，其子节点可以是叶子节点，也可以是容器节点，它提供一个集合用于存储子节点，实现了在抽象构件中定义的行为，包括那些访问及管理子构件的方法，在其业务方法中可以递归调用其子节点的业务方法。

组合模式的关键是定义了一个抽象构件类，它既可以代表叶子，又可以代表容器，而客户端针对该抽象构件类进行编程，无须知道它到底表示的是叶子还是容器，可以对其进行统一处理。同时容器对象与抽象构件类之间还建立一个聚合关联关系，在容器对象中既可以包含叶子，也可以包含容器，以此实现递归组合，形成一个树形结构。

如果不使用组合模式，客户端代码将过多地依赖于容器对象复杂的内部实现结构，容器对象内部实现结构的变化将引起客户代码的频繁变化，带来了代码维护复杂、可扩展性差等弊端。组合模式的引入将在一定程度上解决这些问题。

下面通过简单的示例代码来分析组合模式的各个角色的用途和实现。对于组合模式中的抽象构件角色，其典型代码如下所示：

abstract class Component {  public abstract void add(Component c); //增加成员  public abstract void remove(Component c); //删除成员  public abstract Component getChild(int i); //获取成员  public abstract void operation();  //业务方法
}

一般将抽象构件类设计为接口或抽象类，将所有子类共有方法的声明和实现放在抽象构件类中。对于客户端而言，将针对抽象构件编程，而无须关心其具体子类是容器构件还是叶子构件。

如果继承抽象构件的是叶子构件，则其典型代码如下所示：

class Leaf extends Component {  public void add(Component c) {   //异常处理或错误提示   }     public void remove(Component c) {   //异常处理或错误提示   }  public Component getChild(int i) {   //异常处理或错误提示  return null;   }  public void operation() {  //叶子构件具体业务方法的实现  }
}

作为抽象构件类的子类，在叶子构件中需要实现在抽象构件类中声明的所有方法，包括业务方法以及管理和访问子构件的方法，但是叶子构件不能再包含子构件，因此在叶子构件中实现子构件管理和访问方法时需要提供异常处理或错误提示。当然，这无疑会给叶子构件的实现带来麻烦。

如果继承抽象构件的是容器构件，则其典型代码如下所示：

class Composite extends Component {  private ArrayList<Component> list = new ArrayList<Component>();  public void add(Component c) {  list.add(c);  }  public void remove(Component c) {  list.remove(c);  }  public Component getChild(int i) {  return (Component)list.get(i);  }  public void operation() {  //容器构件具体业务方法的实现  //递归调用成员构件的业务方法  for(Object obj:list) {  ((Component)obj).operation();  }  }
}

在容器构件中实现了在抽象构件中声明的所有方法，既包括业务方法，也包括用于访问和管理成员子构件的方法，如add()、remove()和getChild()等方法。需要注意的是在实现具体业务方法时，由于容器构件充当的是容器角色，包含成员构件，因此它将调用其成员构件的业务方法。在组合模式结构中，由于容器构件中仍然可以包含容器构件，因此在对容器构件进行处理时需要使用递归算法，即在容器构件的operation()方法中递归调用其成员构件的operation()方法。

思考

在组合模式结构图中，如果聚合关联关系不是从Composite到Component的，而是从Composite到Leaf的，如图11-4所示，会产生怎样的结果？

图11-4 组合模式思考题结构图

11.3 完整解决方案

为了让系统具有更好的灵活性和可扩展性，客户端可以一致地对待文件和文件夹，Sunny公司开发人员使用组合模式来进行杀毒软件的框架设计，其基本结构如图11-5所示：

图11-5 杀毒软件框架设计结构图

在图11-5中， AbstractFile充当抽象构件类，Folder充当容器构件类，ImageFile、TextFile和VideoFile充当叶子构件类。完整代码如下所示：

import java.util.*;  //抽象文件类：抽象构件
abstract class AbstractFile {  public abstract void add(AbstractFile file);  public abstract void remove(AbstractFile file);  public abstract AbstractFile getChild(int i);  public abstract void killVirus();
}  //图像文件类：叶子构件
class ImageFile extends AbstractFile {  private String name;  public ImageFile(String name) {  this.name = name;  }  public void add(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public void remove(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public AbstractFile getChild(int i) {  System.out.println("对不起，不支持该方法！");  return null;  }  public void killVirus() {  //模拟杀毒  System.out.println("----对图像文件'" + name + "'进行杀毒");  }
}  //文本文件类：叶子构件
class TextFile extends AbstractFile {  private String name;  public TextFile(String name) {  this.name = name;  }  public void add(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public void remove(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public AbstractFile getChild(int i) {  System.out.println("对不起，不支持该方法！");  return null;  }  public void killVirus() {  //模拟杀毒  System.out.println("----对文本文件'" + name + "'进行杀毒");  }
}  //视频文件类：叶子构件
class VideoFile extends AbstractFile {  private String name;  public VideoFile(String name) {  this.name = name;  }  public void add(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public void remove(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public AbstractFile getChild(int i) {  System.out.println("对不起，不支持该方法！");  return null;  }  public void killVirus() {  //模拟杀毒  System.out.println("----对视频文件'" + name + "'进行杀毒");  }
}  //文件夹类：容器构件
class Folder extends AbstractFile {  //定义集合fileList，用于存储AbstractFile类型的成员  private ArrayList<AbstractFile> fileList=new ArrayList<AbstractFile>();  private String name;  public Folder(String name) {  this.name = name;  }  public void add(AbstractFile file) {  fileList.add(file);    }  public void remove(AbstractFile file) {  fileList.remove(file);  }  public AbstractFile getChild(int i) {  return (AbstractFile)fileList.get(i);  }  public void killVirus() {  System.out.println("****对文件夹'" + name + "'进行杀毒");  //模拟杀毒  //递归调用成员构件的killVirus()方法  for(Object obj : fileList) {  ((AbstractFile)obj).killVirus();  }  }
}

编写如下客户端测试代码：

class Client {  public static void main(String args[]) {  //针对抽象构件编程  AbstractFile file1,file2,file3,file4,file5,folder1,folder2,folder3,folder4;  folder1 = new Folder("Sunny的资料");  folder2 = new Folder("图像文件");  folder3 = new Folder("文本文件");  folder4 = new Folder("视频文件");  file1 = new ImageFile("小龙女.jpg");  file2 = new ImageFile("张无忌.gif");  file3 = new TextFile("九阴真经.txt");  file4 = new TextFile("葵花宝典.doc");  file5 = new VideoFile("笑傲江湖.rmvb");  folder2.add(file1);  folder2.add(file2);  folder3.add(file3);  folder3.add(file4);  folder4.add(file5);  folder1.add(folder2);  folder1.add(folder3);  folder1.add(folder4);  //从“Sunny的资料”节点开始进行杀毒操作  folder1.killVirus();  }
}

编译并运行程序，输出结果如下：

由于在本实例中使用了组合模式，在抽象构件类中声明了所有方法，包括用于管理和访问子构件的方法，如add()方法和remove()方法等，因此在ImageFile等叶子构件类中实现这些方法时必须进行相应的异常处理或错误提示。在容器构件类Folder的killVirus()方法中将递归调用其成员对象的killVirus()方法，从而实现对整个树形结构的遍历。

如果需要更换操作节点，例如只需对文件夹“文本文件”进行杀毒，客户端代码只需修改一行即可，将代码：

folder1.killVirus();

改为：

folder3.killVirus();

输出结果如下：

在具体实现时，我们可以创建图形化界面让用户选择所需操作的根节点，无须修改源代码，符合“开闭原则”，客户端无须关心节点的层次结构，可以对所选节点进行统一处理，提高系统的灵活性。

11.4 透明组合模式与安全组合模式

通过引入组合模式，Sunny公司设计的杀毒软件具有良好的可扩展性，在增加新的文件类型时，无须修改现有类库代码，只需增加一个新的文件类作为AbstractFile类的子类即可，但是由于在AbstractFile中声明了大量用于管理和访问成员构件的方法，例如add()、remove()等方法，我们不得不在新增的文件类中实现这些方法，提供对应的错误提示和异常处理。为了简化代码，我们有以下两个解决方案：

解决方案一：将叶子构件的add()、remove()等方法的实现代码移至AbstractFile类中，由AbstractFile提供统一的默认实现，代码如下所示：

//提供默认实现的抽象构件类
abstract class AbstractFile {  public void add(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public void remove(AbstractFile file) {  System.out.println("对不起，不支持该方法！");  }  public AbstractFile getChild(int i) {  System.out.println("对不起，不支持该方法！");  return null;  }  public abstract void killVirus();
}

如果客户端代码针对抽象类AbstractFile编程，在调用文件对象的这些方法时将出现错误提示。如果不希望出现任何错误提示，我们可以在客户端定义文件对象时不使用抽象层，而直接使用具体叶子构件本身，客户端代码片段如下所示：

class Client {  public static void main(String args[]) {  //不能透明处理叶子构件  ImageFile file1,file2;  TextFile file3,file4;  VideoFile file5;  AbstractFile folder1,folder2,folder3,folder4;  //其他代码省略  }
}

这样就产生了一种不透明的使用方式，即在客户端不能全部针对抽象构件类编程，需要使用具体叶子构件类型来定义叶子对象。

解决方案二：除此之外，还有一种解决方法是在抽象构件AbstractFile中不声明任何用于访问和管理成员构件的方法，代码如下所示：

abstract class AbstractFile {  public abstract void killVirus();
}

此时，由于在AbstractFile中没有声明add()、remove()等访问和管理成员的方法，其叶子构件子类无须提供实现；而且无论客户端如何定义叶子构件对象都无法调用到这些方法，不需要做任何错误和异常处理，容器构件再根据需要增加访问和管理成员的方法，但这时候也存在一个问题：客户端不得不使用容器类本身来声明容器构件对象，否则无法访问其中新增的add()、remove()等方法，如果客户端一致性地对待叶子和容器，将会导致容器构件的新增对客户端不可见，客户端代码对于容器构件无法再使用抽象构件来定义，客户端代码片段如下所示：

class Client {  public static void main(String args[]) {  AbstractFile file1,file2,file3,file4,file5;  Folder folder1,folder2,folder3,folder4; //不能透明处理容器构件  //其他代码省略  }
}

在使用组合模式时，根据抽象构件类的定义形式，我们可将组合模式分为透明组合模式和安全组合模式两种形式：

(1) 透明组合模式

透明组合模式中，抽象构件Component中声明了所有用于管理成员对象的方法，包括add()、remove()以及getChild()等方法，这样做的好处是确保所有的构件类都有相同的接口。在客户端看来，叶子对象与容器对象所提供的方法是一致的，客户端可以相同地对待所有的对象。透明组合模式也是组合模式的标准形式，虽然上面的解决方案一在客户端可以有不透明的实现方法，但是由于在抽象构件中包含add()、remove()等方法，因此它还是透明组合模式，透明组合模式的完整结构如图11-6所示：

图11-6 透明组合模式结构图

透明组合模式的缺点是不够安全，因为叶子对象和容器对象在本质上是有区别的。叶子对象不可能有下一个层次的对象，即不可能包含成员对象，因此为其提供add()、remove()以及getChild()等方法是没有意义的，这在编译阶段不会出错，但在运行阶段如果调用这些方法可能会出错（如果没有提供相应的错误处理代码）。

(2) 安全组合模式

安全组合模式中，在抽象构件Component中没有声明任何用于管理成员对象的方法，而是在Composite类中声明并实现这些方法。这种做法是安全的，因为根本不向叶子对象提供这些管理成员对象的方法，对于叶子对象，客户端不可能调用到这些方法，这就是解决方案二所采用的实现方式。安全组合模式的结构如图11-7所示：

图11-7 安全组合模式结构图

安全组合模式的缺点是不够透明，因为叶子构件和容器构件具有不同的方法，且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义，因此客户端不能完全针对抽象编程，必须有区别地对待叶子构件和容器构件。在实际应用中，安全组合模式的使用频率也非常高，在Java AWT中使用的组合模式就是安全组合模式。

11.5 公司组织结构

在学习和使用组合模式时，Sunny软件公司开发人员发现树形结构其实随处可见，例如Sunny公司的组织结构就是“一棵标准的树”，如图11-8所示：

图11-8 Sunny公司组织结构图

在Sunny软件公司的内部办公系统Sunny OA系统中，有一个与公司组织结构对应的树形菜单，行政人员可以给各级单位下发通知，这些单位可以是总公司的一个部门，也可以是一个分公司，还可以是分公司的一个部门。用户只需要选择一个根节点即可实现通知的下发操作，而无须关心具体的实现细节。这不正是组合模式的“特长”吗？于是Sunny公司开发人员绘制了如图11-9所示结构图：

图11-9 Sunny公司组织结构组合模式示意图

在图11-9中，“单位”充当了抽象构件角色，“公司”充当了容器构件角色，“研发部”、“财务部”和“人力资源部”充当了叶子构件角色。

1.6 组合模式总结

组合模式使用面向对象的思想来实现树形结构的构建与处理，描述了如何将容器对象和叶子对象进行递归组合，实现简单，灵活性好。由于在软件开发中存在大量的树形结构，因此组合模式是一种使用频率较高的结构型设计模式，Java SE中的AWT和Swing包的设计就基于组合模式，在这些界面包中为用户提供了大量的容器构件（如Container）和成员构件（如Checkbox、Button和TextComponent等），其结构如图11-10所示：

图11-10 AWT组合模式结构示意图

在图11-10中，Component类是抽象构件，Checkbox、Button和TextComponent是叶子构件，而Container是容器构件，在AWT中包含的叶子构件还有很多，因为篇幅限制没有在图中一一列出。在一个容器构件中可以包含叶子构件，也可以继续包含容器构件，这些叶子构件和容器构件一起组成了复杂的GUI界面。

除此以外，在XML解析、组织结构树处理、文件系统设计等领域，组合模式都得到了广泛应用。

1. 主要优点

组合模式的主要优点如下：

(1) 组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，它让客户端忽略了层次的差异，方便对整个层次结构进行控制。

(2) 客户端可以一致地使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了客户端代码。

(3) 在组合模式中增加新的容器构件和叶子构件都很方便，无须对现有类库进行任何修改，符合“开闭原则”。

(4) 组合模式为树形结构的面向对象实现提供了一种灵活的解决方案，通过叶子对象和容器对象的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。

2. 主要缺点

组合模式的主要缺点如下：

在增加新构件时很难对容器中的构件类型进行限制。有时候我们希望一个容器中只能有某些特定类型的对象，例如在某个文件夹中只能包含文本文件，使用组合模式时，不能依赖类型系统来施加这些约束，因为它们都来自于相同的抽象层，在这种情况下，必须通过在运行时进行类型检查来实现，这个实现过程较为复杂。

3. 适用场景

在以下情况下可以考虑使用组合模式：

(1) 在具有整体和部分的层次结构中，希望通过一种方式忽略整体与部分的差异，客户端可以一致地对待它们。

(2) 在一个使用面向对象语言开发的系统中需要处理一个树形结构。

(3) 在一个系统中能够分离出叶子对象和容器对象，而且它们的类型不固定，需要增加一些新的类型。

七外观模式 (门面模式)

了解外观模式之前我们先来了解一下什么是什么是迪米特法则：

　　迪米特法则(Law of Demeter )又叫做最少知识原则，也就是说，一个对象应当对其他对象尽可能少的了解。不和陌生人说话。英文简写为: LoD。

(1)概念介绍

外观模式（Facade）,他隐藏了系统的复杂性，并向客户端提供了一个可以访问系统的接口。这种类型的设计模式属于结构性模式。为子系统中的一组接口提供了一个统一的访问接口，这个接口使得子系统更容易被访问或者使用。

（2）角色及使用场景

　　简单来说，该模式就是把一些复杂的流程封装成一个接口供给外部用户更简单的使用。这个模式中，设计到3个角色。

　　1）.门面角色：外观模式的核心。它被客户角色调用，它熟悉子系统的功能。内部根据客户角色的需求预定了几种功能的组合。

　　2）.子系统角色:实现了子系统的功能。它对客户角色和Facade时未知的。它内部可以有系统内的相互交互，也可以由供外界调用的接口。

　　3）.客户角色:通过调用Facede来完成要实现的功能。

　　使用场景：

　　1- 为复杂的模块或子系统提供外界访问的模块；

　　2- 子系统相互独立；

　　3- 在层析结构中，可以使用外观模式定义系统的每一层的入口。

（3）实例

　　下面，我们就通过一个简单的例子来实现该模式。

　　每个Computer都有CPU、Memory、Disk。在Computer开启和关闭的时候，相应的部件也会开启和关闭，所以，使用了该外观模式后，会使用户和部件之间解耦。如：

包体的创建：

代码实现

首先是子系统类：

【代码清单--1】

package com.huawei.facadeDesign.children;import org.apache.log4j.Logger;/*** cpu子系统类* @author Administrator**/
public class CPU
{public static final Logger LOGGER = Logger.getLogger(CPU.class);public void start(){LOGGER.info("cpu is start...");}public void shutDown(){LOGGER.info("CPU is shutDown...");}
}

【代码清单--2】

package com.huawei.facadeDesign.children;import org.apache.log4j.Logger;/*** Disk子系统类* @author Administrator**/
public class Disk
{public static final Logger LOGGER = Logger.getLogger(Disk.class);public void start(){LOGGER.info("Disk is start...");}public void shutDown(){LOGGER.info("Disk is shutDown...");}
}

【代码清单--3】

package com.huawei.facadeDesign.children;import org.apache.log4j.Logger;/*** Memory子系统类* @author Administrator**/
public class Memory
{public static final Logger LOGGER = Logger.getLogger(Memory.class);public void start(){LOGGER.info("Memory is start...");}public void shutDown(){LOGGER.info("Memory is shutDown...");}
}

然后是，门面类Facade

【代码清单--4】

package com.huawei.facadeDesign.facade;import org.apache.log4j.Logger;import com.huawei.facadeDesign.children.CPU;
import com.huawei.facadeDesign.children.Disk;
import com.huawei.facadeDesign.children.Memory;/*** 门面类（核心）* @author Administrator**/
public class Computer
{public static final Logger LOGGER = Logger.getLogger(Computer.class);private CPU cpu;private Memory memory;private Disk disk;public Computer(){cpu = new CPU();memory = new Memory();disk = new Disk();}public void start(){LOGGER.info("Computer start begin");cpu.start();disk.start();memory.start();LOGGER.info("Computer start end");}public void shutDown(){LOGGER.info("Computer shutDown begin");cpu.shutDown();disk.shutDown();memory.shutDown();LOGGER.info("Computer shutDown end...");}
}

最后为，客户角色。

【代码清单--5】

package com.huawei.facadeDesign;import org.apache.log4j.Logger;import com.huawei.facadeDesign.facade.Computer;/*** 客户端类* @author Administrator**/
public class Cilent {public static final Logger LOGGER = Logger.getLogger(Cilent.class);public static void main(String[] args) {Computer computer = new Computer();computer.start();LOGGER.info("=================");computer.shutDown();}}

　【代码清单--6】运行结果

　　从上面的实例来看，有了这个Facade类，也就是Computer类，用户就不用亲自去调用子系统中的Disk,Memory、CPU类了，不需要知道系统内部的实现细节，甚至都不用知道系统内部的构成。客户端只需要跟Facade交互就可以了。

（4）优点

　　- 松散耦合

　　使得客户端和子系统之间解耦，让子系统内部的模块功能更容易扩展和维护；

　　- 简单易用

　　客户端根本不需要知道子系统内部的实现，或者根本不需要知道子系统内部的构成，它只需要跟Facade类交互即可。

　　- 更好的划分访问层次

　　有些方法是对系统外的，有些方法是系统内部相互交互的使用的。子系统把那些暴露给外部的功能集中到门面中，这样就可以实现客户端的使用，很好的隐藏了子系统内部的细节。

八享元模式

前言

享元模式是一种软件设计模式，是对象池的一种实现，其目的在于尽可能的减少内存的使用量，内存属于稀缺资源，如果在一个系统中有很多个完全相同或相似的对象，我们就可以使用享元模式，让他们共享一份内存，不必每个都去实例化对象，从而节省内存，其实现共享的关键在于区分内部和外部状态，内部可共享，外部不可共享，从而实现高效重用。

角色扮演

FlyWeight：抽象享元类，可以使一个接口也可以是抽象类，声明方法用于提供内部状态和设置外部状态。
DisparateObject：不可共享的状态类，用于享元对象内差异的部分。
ConcreteFlyWeight：具体享元类，为内部状态提供成员变量的存储。
FlyWeightFactory：享元工厂类，创建并管理享元对象，一般管理Map类似的键值对象。

适用场景

系统中存在大量的相似对象，或者需要缓冲池的场景，亦或是细粒度的对象都具备相似的外部状态，而且内部状态与环境无关的场景；换言之，能够共享数据对象的场景，应该避免多次new对象，而应该考虑复用对象。

下面我将围棋的为例为大家说明享元模式：

FlyWeight：抽象享元类，可以是一个接口也可以是抽象类，声明方法用于提供内部状态和设置外部状态：

/*** FlyWeight： 抽象享元类，可以使一个接口也可以是抽象类，声明方法用于提供内部状态和设置外部状态。* * @author lenovo**/
public interface FlyWeight_Chess {void setColor(String c);String getColor();void display(FlyWeight_Coordinate c);
}

ConcreteFlyWeight：具体享元类，为内部状态提供成员变量的存储：

/*** ConcreteFlyWeight：具体享元类，为内部状态提供成员变量的存储* * @author lenovo**/
class ConcreteChess implements FlyWeight_Chess {private String color; // 内部状态,可共享public ConcreteChess(String color) {super();this.color = color;}@Overridepublic void setColor(String c) {this.color = c;}@Overridepublic String getColor() {return color;}@Overridepublic void display(FlyWeight_Coordinate c) {System.out.println("棋子颜色：" + color);System.out.println("棋子位置：" + c.getX() + "----" + c.getY());}}

DisparateObject：不可共享的状态类，用于享元对象内差异的部分：

package GOF23;/*** 坐标类(外部状态,不可共享)* DisparateObject：不可共享的状态类，用于享元对象内差异的部分。 * * @author lenovo**/
public class FlyWeight_Coordinate {private int x, y;public FlyWeight_Coordinate(int x, int y) {super();this.x = x;this.y = y;}public int getX() {return x;}public void setX(int x) {this.x = x;}public int getY() {return y;}public void setY(int y) {this.y = y;}}

FlyWeightFactory：享元工厂类，创建并管理享元对象，一般管理Map类似的键值对象：

package GOF23;import java.util.HashMap;
import java.util.Map;/*** 享元工厂类* FlyWeightFactory：享元工厂类，创建并管理享元对象，一般管理Map类似的键值对象。* @author lenovo**/
public class FlyWeightFactory {//享元池private static Map<String, FlyWeight_Chess> map = new  HashMap<String, FlyWeight_Chess>();public static FlyWeight_Chess getChess(String color) {if(map.get(color) != null) {return map.get(color);} else {FlyWeight_Chess chess = new ConcreteChess(color);map.put(color, chess);return chess;}}
}

客户端：我们new两个颜色一样的棋子

package GOF23;public class FlyWeight_Client {public static void main(String[] args) {FlyWeight_Chess chess1 = FlyWeightFactory.getChess("黑色");//第二次新建一个对象前会看看享元池里有没有,如果有就直接取出来,和原对象一样！FlyWeight_Chess chess2 = FlyWeightFactory.getChess("黑色");System.out.println(chess1 + "\n" + chess2); //打印输出是同一个对象System.out.println("增加外部状态的处理=========");//两个棋子的颜色实现了共享chess1.display(new FlyWeight_Coordinate(10, 10));chess2.display(new FlyWeight_Coordinate(20, 20));}
}

结果：

我们发现我们new出来棋子的是同一个对象，因为之前的黑色已经存在于享元池里，二次new只需要取出即可。

设计模式GOF23之-------------------结构型模式（适配器模式、代理模式、桥接模式、装饰模式、组合模式、外观模式、享元模式）相关推荐

【韩老师设计模式7】外观和享元模式，MyBatis的Configuration创建 MetaObject。Integer.valueOf
外观模式例子影院管理项目组建一个家庭影院: DVD播放器.投影仪.自动屏幕.环绕立体声.爆米花机,要求完成使用家庭影院的功能,其过程为: • 直接用遥控器:统筹各设备开关 • 开爆米花机 • ...
设计模式(十六)----结构型模式之代理享元模式
1.概述定义: 运用共享技术来有效地支持大量细粒度对象的复用.它通过共享已经存在的对象来大幅度减少需要创建的对象数量.避免大量相似对象的开销,从而提高系统资源的利用率. 2 结构享元(Flywei ...
设计模式之七个结构型模式的相关知识，简单易懂。
七. 适配器模式-Adapter Pattern 1) 不兼容结构的协调--适配器模式(一) 我的笔记本电脑的工作电压是20V,而我国的家庭用电是220V,如何让20V的笔记本电脑能够在220V的电压 ...
设计模式：结构型模式-桥接、外观、组合、享元模式
结构型模式结构型模式描述如何将类或对象按某种布局组成更大的结构.它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者采用组合或聚合来组合对象. 由于组合关系或聚合关系比继承关系耦 ...
Java23种设计模式——11.结构型模式之享元模式
Java中除去有设计原则之外,还有23中设计模式. 这些模式都是前辈们一点一点积累下来,一直在改进,一直在优化的,而这些设计模式可以解决一些特定的问题. 并且在这些模式中,可以说是将语言的使用体现的淋 ...
享元模式 - 结构型模式
模式类型: Flyweight 享元模式 - 结构型模式意图: The intent of this pattern is to use sharing to support a ...
设计模式-04.02-结构型设计模式-门面模式组合模式享元模式
文章目录门面模式(外观模式)[不常用] 门面模式的原理与实现 Demo案例-影院管理传统方案门面模式代码 TheaterLight Stereo Screen Projector Popcorn ...
结构型模式之享元模式
文章目录享元模式的定义与特点享元模式的结构享元模式的实现享元模式的应用场景享元模式的内部状态和外部状态面向对象技术可以很好的解决一些灵活性或可扩展性问题,但是在很多情况下需要在系统中增加类 ...
Go设计模式(17)-享元模式
享元模式主要是为了复用对象,节省内存.使用享元模式需要有两个前提: 享元对象不可变:当享元模式创建出来后,它的变量和属性不会被修改系统中存在大量重复对象:这些重复对象可以使用同一个享元,内存中只存在 ...

设计模式GOF23之-------------------结构型模式（适配器模式、代理模式、桥接模式、装饰模式、组合模式、外观模式、享元模式）

一结构型模式

二适配器模式

三代理模式

什么是代理模式？

为什么要用代理模式？

有哪几种代理模式？

四桥接模式（一般桥接模式适用于两个变化维度）

五装饰模式

六组合模式（注意：并不是我们所说的继承中的组合）

11.1 设计杀毒软件的框架结构

11.2 组合模式概述

11.3 完整解决方案

11.4 透明组合模式与安全组合模式

11.5 公司组织结构

七外观模式 (门面模式)

- 松散耦合

- 简单易用

- 更好的划分访问层次

八享元模式

设计模式GOF23之-------------------结构型模式（适配器模式、代理模式、桥接模式、装饰模式、组合模式、外观模式、享元模式）相关推荐

最新文章

热门文章

设计模式GOF23之-------------------结构型模式（适配器模式、代理模式、桥接模式、装饰模式、组合模式、外观模式、享元模式）

一 结构型模式

二 适配器模式

三 代理模式

什么是代理模式？

为什么要用代理模式？

有哪几种代理模式？

四 桥接模式（一般桥接模式适用于两个变化维度 ）

五 装饰模式

六 组合模式（注意：并不是我们所说的继承中的组合）

11.1 设计杀毒软件的框架结构

11.2 组合模式概述

11.3 完整解决方案

11.4 透明组合模式与安全组合模式

11.5 公司组织结构

七 外观模式 (门面模式)

- 松散耦合

- 简单易用

- 更好的划分访问层次

八 享元模式

设计模式GOF23之-------------------结构型模式（适配器模式、代理模式、桥接模式、装饰模式、组合模式、外观模式、享元模式）相关推荐

最新文章

热门文章

一结构型模式

二适配器模式

三代理模式

四桥接模式（一般桥接模式适用于两个变化维度）

五装饰模式

六组合模式（注意：并不是我们所说的继承中的组合）

七外观模式 (门面模式)

　　- 松散耦合

　　- 简单易用

　　- 更好的划分访问层次

八享元模式