1-1-4、结构型设计模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象
由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性
结构型模式分为以下七种，除了适配器模式分为类结构型模式和对象结构型模式两种，其他的全部属于对象结构型模式：

• 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性
• 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作
• 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度
• 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能
• 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问
• 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用
• 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性
  

代理模式

使用背景

在有些情况下，一个客户不能或者不想直接访问另一个对象，这时需要找一个中介帮忙完成某项任务，这个中介就是代理对象。例如，购买火车票不一定要去火车站买，可以通过 12306 网站或者去火车票代售点买。又如找女朋友、找保姆、找工作等都可以通过找中介完成
在软件设计中，使用代理模式的例子也很多，例如，要访问的远程对象比较大（如视频或大图像等），其下载要花很多时间。还有因为安全原因需要屏蔽客户端直接访问真实对象，如某单位的内部数据库等

定义

由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介

特点

代理模式的主要优点有：

• 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用
• 代理对象可以扩展目标对象的功能
• 代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度

其主要缺点是：

• 在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢
• 增加了系统的复杂度
  

结构

代理模式的结构比较简单，主要是通过定义一个继承抽象主题的代理来包含真实主题，从而实现对真实主题的访问
代理模式的主要角色如下：

• 抽象主题（Subject）类：通过接口或抽象类声明真实主题和代理对象实现的业务方法。
• 真实主题（Real Subject）类：实现了抽象主题中的具体业务，是代理对象所代表的真实对象，是最终要引用的对象。
• 代理（Proxy）类：提供了与真实主题相同的接口，其内部含有对真实主题的引用，它可以访问、控制或扩展真实主题的功能
  

实现

• 原生代理模式（静态代理）：继承目标对象的同一个接口，引入目标对象，重写方法

public class ProxyTest{
	public static void main(String[] args){
		Proxy proxy=new Proxy();
		proxy.Request();
	}
}
//抽象主题
public interface Subject{
	void Request();
}
//真实主题
public class RealSubject implements Subject{
	public void Request(){
		System.out.println("访问真实主题方法...");
	}
}
//代理
public class Proxy implements Subject{
	private RealSubject realSubject;
	public void Request(){
		if (realSubject==null){
			realSubject=new RealSubject();
		}
		preRequest();
		realSubject.Request();
		postRequest();
	}
	public void preRequest(){
		System.out.println("访问真实主题之前的预处理。");
	}
	public void postRequest(){
		System.out.println("访问真实主题之后的后续处理。");
	}
}

运行结果：

访问真实主题之前的预处理
访问真实主题方法…
访问真实主题之后的后续处理

• jdk动态代理：用JDK原有的API传入目标对象的类加载器和接口，再重写代理方法，返回一个代理对象，缺点就是需要传入接口

/**
* 创建动态代理对象
* 动态代理不需要实现接口,但是需要指定接口类型
*/
public class ProxyFactory{
	//维护一个目标对象
	private Object target;
	public ProxyFactory(Object target){
		this.target=target;
	}
	//给目标对象生成代理对象
	public Object getProxyInstance(){
		return Proxy.newProxyInstance(
			target.getClass().getClassLoader(),
			target.getClass().getInterfaces(),
			new InvocationHandler() {
				@Override
				public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
					System.out.println("开始事务2");
					//执行目标对象方法
					Object returnValue = method.invoke(target, args);
					System.out.println("提交事务2");
					return returnValue;
				}
			}
		);
	}
}

• CGlib实现动态代理：需要先导入相应的jar包，目标对象的方法如果为final/static，那么就不会被拦截，即不会执行目标对象额外的业务方法

/**
* Cglib子类代理工厂
* 对UserDao在内存中动态构建一个子类对象
*/
public class ProxyFactory implements MethodInterceptor{
	//维护目标对象
	private Object target;

	public ProxyFactory(Object target) {
		this.target = target;
	}

	//给目标对象创建一个代理对象
	public Object getProxyInstance(){
		//1.工具类
		Enhancer en = new Enhancer();
		//2.设置父类
		en.setSuperclass(target.getClass());
		//3.设置回调函数
		en.setCallback(this);
		//4.创建子类(代理对象)
		return en.create();
	}

	@Override
	public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
		System.out.println("开始事务...");
		//执行目标对象的方法
		Object returnValue = method.invoke(target, args);
		System.out.println("提交事务...");
		return returnValue;
	}
}

扩展

静态代理模式会有以下缺点，使用动态代理可以解决以上问题：

• 真实主题与代理主题一一对应，增加真实主题也要增加代理
• 设计代理以前真实主题必须事先存在，不太灵活

动态代理的对比：

• CGlib底层是动态的在内存中生成了目标对象的子类的字节码，并生成相应的对象
• JDK动态代理实现则是使用的反射机制
• CGlib实现动态代理能满足没有接口的目标对象的代理对象实现

注：在Spring中，实现AOP的AspectJ框架底层，会对无接口的目标对象采用CGlib，有接口的目标对象则采用JDK动态代理

使用场景

• 远程代理，这种方式通常是为了隐藏目标对象存在于不同地址空间的事实，方便客户端访问。例如，用户申请某些网盘空间时，会在用户的文件系统中建立一个虚拟的硬盘，用户访问虚拟硬盘时实际访问的是网盘空间
• 虚拟代理，这种方式通常用于要创建的目标对象开销很大时。例如，下载一幅很大的图像需要很长时间，因某种计算比较复杂而短时间无法完成，这时可以先用小比例的虚拟代理替换真实的对象，消除用户对服务器慢的感觉
• 安全代理，这种方式通常用于控制不同种类客户对真实对象的访问权限
• 智能指引，主要用于调用目标对象时，代理附加一些额外的处理功能。例如，增加计算真实对象的引用次数的功能，这样当该对象没有被引用时，就可以自动释放它
• 延迟加载，指为了提高系统的性能，延迟对目标的加载。例如，Hibernate中就存在属性的延迟加载和关联表的延时加载
  

适配器模式

使用背景

在现实生活中，经常出现两个对象因接口不兼容而不能在一起工作的实例，这时需要第三者进行适配。例如，讲中文的人同讲英文的人对话时需要一个翻译，用直流电的笔记本电脑接交流电源时需要一个电源适配器，用计算机访问照相机的 SD 内存卡时需要一个读卡器等
在软件设计中也可能出现：需要开发的具有某种业务功能的组件在现有的组件库中已经存在，但它们与当前系统的接口规范不兼容，如果重新开发这些组件成本又很高，这时用适配器模式能很好地解决这些问题

定义

将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作
适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些

特点

该模式的主要优点如下：

• 客户端通过适配器可以透明地调用目标接口
• 复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类
• 将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题

其缺点是：对类适配器来说，更换适配器的实现过程比较复杂

结构

适配器模式（Adapter）包含以下主要角色：

• 目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口
• 适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口
• 适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者
  

实现

• 类适配器

//目标接口
public interface Target{
	public void request();
}
//适配者类
public class Adaptee{
	public void specificRequest(){       
		System.out.println("适配者中的业务代码被调用！");
	}
}
//类适配器类
public class ClassAdapter extends Adaptee implements Target{
	public void request(){
		specificRequest();
	}
}
//客户端代码
public class ClassAdapterTest{
	public static void main(String[] args){
		System.out.println("类适配器模式测试：");
		Target target = new ClassAdapter();
		target.request();
	}
}

运行结果：

类适配器模式测试：
适配者中的业务代码被调用！

• 对象适配器

//对象适配器类
public class ObjectAdapter implements Target{
	private Adaptee adaptee;
	public ObjectAdapter(Adaptee adaptee){
		this.adaptee=adaptee;
	}
	public void request(){
		adaptee.specificRequest();
	}
}
//客户端代码
public class ObjectAdapterTest{
	public static void main(String[] args){
		System.out.println("对象适配器模式测试：");
		Adaptee adaptee = new Adaptee();
		Target target = new ObjectAdapter(adaptee);
		target.request();
	}
}

说明：对象适配器模式中的“目标接口”和“适配者类”的代码同类适配器模式一样，只要修改适配器类和客户端的代码即可
运行结果：

对象适配器模式测试：
适配者中的业务代码被调用！

扩展

适配器模式（Adapter）可扩展为双向适配器模式，双向适配器类既可以把适配者接口转换成目标接口，也可以把目标接口转换成适配者接口
示例：

//目标接口
public interface TwoWayTarget{
	public void request();
}
//适配者接口
public interface TwoWayAdaptee{
	public void specificRequest();
}
//目标实现
public class TargetRealize implements TwoWayTarget{
	public void request(){       
		System.out.println("目标代码被调用！");
	}
}
//适配者实现
public class AdapteeRealize implements TwoWayAdaptee{
	public void specificRequest(){       
		System.out.println("适配者代码被调用！");
	}
}
//双向适配器
public class TwoWayAdapter  implements TwoWayTarget,TwoWayAdaptee{
	private TwoWayTarget target;
	private TwoWayAdaptee adaptee;
	public TwoWayAdapter(TwoWayTarget target){
		this.target=target;
	}
	public TwoWayAdapter(TwoWayAdaptee adaptee){
		this.adaptee=adaptee;
	}
	public void request(){
		adaptee.specificRequest();
	}
	public void specificRequest(){       
		target.request();
	}
}
//客户端代码
public class TwoWayAdapterTest{
	public static void main(String[] args){
		System.out.println("目标通过双向适配器访问适配者：");
		TwoWayAdaptee adaptee=new AdapteeRealize();
		TwoWayTarget target=new TwoWayAdapter(adaptee);
		target.request();
		System.out.println("-------------------");
		System.out.println("适配者通过双向适配器访问目标：");
		target=new TargetRealize();
		adaptee=new TwoWayAdapter(target);
		adaptee.specificRequest();
	}
}

运行结果：

目标通过双向适配器访问适配者：
适配者代码被调用！

适配者通过双向适配器访问目标：
目标代码被调用！

使用场景

• 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
• 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。
  

桥接模式

使用背景

在现实生活中，某些类具有两个或多个维度的变化，如图形既可按形状分，又可按颜色分。如何设计类似于 Photoshop 这样的软件，能画不同形状和不同颜色的图形呢？如果用继承方式，m 种形状和 n 种颜色的图形就有 m×n 种，不但对应的子类很多，而且扩展困难
当然，这样的例子还有很多，如不同颜色和字体的文字、不同品牌和功率的汽车、不同性别和职业的男女、支持不同平台和不同文件格式的媒体播放器等。如果用桥接模式就能很好地解决这些问题

定义

将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度

特点

桥接（Bridge）模式的优点是：

• 由于抽象与实现分离，所以扩展能力强
• 其实现细节对客户透明

缺点是：由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度

结构

可以将抽象化部分与实现化部分分开，取消二者的继承关系，改用组合关系
桥接（Bridge）模式包含以下主要角色：

• 抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用
• 扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法
• 实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用
• 具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现

public class BridgeTest{
	public static void main(String[] args){
		Implementor imple=new ConcreteImplementorA();
		Abstraction abs=new RefinedAbstraction(imple);
		abs.Operation();
	}
}
//实现化角色
public interface Implementor{
	public void OperationImpl();
}
//具体实现化角色
public class ConcreteImplementorA implements Implementor{
	public void OperationImpl(){
		System.out.println("具体实现化(Concrete Implementor)角色被访问" );
	}
}
//抽象化角色
public abstract class Abstraction{
	protected Implementor imple;
	protected Abstraction(Implementor imple){
		this.imple=imple;
	}
	public abstract void Operation();   
}
//扩展抽象化角色
public class RefinedAbstraction extends Abstraction{
	protected RefinedAbstraction(Implementor imple){
		super(imple);
	}
	public void Operation(){
		System.out.println("扩展抽象化(Refined Abstraction)角色被访问" );
		imple.OperationImpl();
	}
}

运行结果：

扩展抽象化(Refined Abstraction)角色被访问
具体实现化(Concrete Implementor)角色被访问

扩展

在软件开发中，有时桥接（Bridge）模式可与适配器模式联合使用。当桥接（Bridge）模式的实现化角色的接口与现有类的接口不一致时，可以在二者中间定义一个适配器将二者连接起来，其结构图如下：

使用场景

• 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时
• 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时
• 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时
  

装饰模式

使用背景

在现实生活中，常常需要对现有产品增加新的功能或美化其外观，如房子装修、相片加相框等。在软件开发过程中，有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下，可以动态地扩展其功能。所有这些都可以釆用装饰模式来实现

定义

指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式

特点

主要优点有：

• 采用装饰模式扩展对象的功能比采用继承方式更加灵活
• 可以设计出多个不同的具体装饰类，创造出多个不同行为的组合

其主要缺点是：装饰模式增加了许多子类，如果过度使用会使程序变得很复杂

结构

通常情况下，扩展一个类的功能会使用继承方式来实现。但继承具有静态特征，耦合度高，并且随着扩展功能的增多，子类会很膨胀。如果使用组合关系来创建一个包装对象（即装饰对象）来包裹真实对象，并在保持真实对象的类结构不变的前提下，为其提供额外的功能，这就是装饰模式的目标。下面来分析其基本结构和实现方法
装饰模式主要包含以下角色：

• 抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象
• 具体构件（Concrete Component）角色：实现抽象构件，通过装饰角色为其添加一些职责
• 抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能
• 具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任
  

实现

public class DecoratorPattern{
	public static void main(String[] args){
		Component p=new ConcreteComponent();
		p.operation();
		System.out.println("---------------------------------");
		Component d=new ConcreteDecorator(p);
		d.operation();
	}
}
//抽象构件角色
public interface  Component{
	public void operation();
}
//具体构件角色
public class ConcreteComponent implements Component{
	public ConcreteComponent(){
		System.out.println("创建具体构件角色");       
	}   
	public void operation(){
		System.out.println("调用具体构件角色的方法operation()");           
	}
}
//抽象装饰角色
class Decorator implements Component{
	private Component component;   
	public Decorator(Component component){
		this.component=component;
	}   
	public void operation(){
		component.operation();
	}
}
//具体装饰角色
class ConcreteDecorator extends Decorator{
	public ConcreteDecorator(Component component){
		super(component);
	}   
	public void operation()    {
		super.operation();
		addedFunction();
	}
	public void addedFunction()    {
		System.out.println("为具体构件角色增加额外的功能addedFunction()");           
	}
}

运行结果：

创建具体构件角色
调用具体构件角色的方法operation()

调用具体构件角色的方法operation()
为具体构件角色增加额外的功能addedFunction()

扩展

装饰模式所包含的 4 个角色不是任何时候都要存在的，在有些应用环境下模式是可以简化的，如以下两种情况**：**

• 如果只有一个具体构件而没有抽象构件时，可以让抽象装饰继承具体构件，其结构图如下：
  

• 如果只有一个具体装饰时，可以将抽象装饰和具体装饰合并，其结构图如下：
  

使用场景

装饰模式通常在以下几种情况使用：

• 当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类
• 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰模式却很好实现
• 当对象的功能要求可以动态地添加，也可以再动态地撤销时
  

外观模式

使用背景

在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了
软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了“开闭原则”，也违背了“迪米特法则”，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标

定义

是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性

特点

外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点：

• 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类
• 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易
• 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象

主要缺点如下：

• 不能很好地限制客户使用子系统类
• 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”
  

结构

外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。
包含以下主要角色：

• 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
• 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
• 客户（Client）角色：通过一个外观角色访问各个子系统的功能
  

实现

public class FacadePattern{
	public static void main(String[] args){
		Facade f=new Facade();
		f.method();
	}
}
//外观角色
public class Facade{
	private SubSystem01 obj1=new SubSystem01();
	private SubSystem02 obj2=new SubSystem02();
	private SubSystem03 obj3=new SubSystem03();
	public void method(){
		obj1.method1();
		obj2.method2();
		obj3.method3();
	}
}
//子系统角色
public class SubSystem01{
	public  void method1(){
		System.out.println("子系统01的method1()被调用！");
	}   
}
//子系统角色
public class SubSystem02{
	public  void method2(){
		System.out.println("子系统02的method2()被调用！");
	}   
}
//子系统角色
public class SubSystem03{
	public  void method3(){
		System.out.println("子系统03的method3()被调用！");
	}   
}

运行结果：

子系统01的method1()被调用！
子系统02的method2()被调用！
子系统03的method3()被调用！

扩展

在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题，其结构图如下：

使用场景

通常在以下情况下可以考虑使用外观模式：

• 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系
• 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问
• 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性
  

享元模式

使用背景

在面向对象程序设计过程中，有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源，它是系统性能提高的一个瓶颈。例如，围棋和五子棋中的黑白棋子，图像中的坐标点或颜色，局域网中的路由器、交换机和集线器，教室里的桌子和凳子等。这些对象有很多相似的地方，如果能把它们相同的部分提取出来共享，则能节省大量的系统资源

定义

运用共享技术来有効地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率

特点

主要优点是：相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力
主要缺点是：

• 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性
• 读取享元模式的外部状态会使得运行时间稍微变长
  

结构

享元模式中存在以下两种状态：

• 内部状态，即不会随着环境的改变而改变的可共享部分；
• 外部状态，指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化

主要角色有如下：

• 抽象享元角色（Flyweight）:是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入
• 具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口
• 非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中
• 享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象
  

实现

import java.util.HashMap;
public class FlyweightPattern{
	public static void main(String[] args){
		FlyweightFactory factory=new FlyweightFactory();
		Flyweight f01=factory.getFlyweight("a");
		Flyweight f02=factory.getFlyweight("a");
		Flyweight f03=factory.getFlyweight("a");
		Flyweight f11=factory.getFlyweight("b");
		Flyweight f12=factory.getFlyweight("b");       
		f01.operation(new UnsharedConcreteFlyweight("第1次调用a。"));       
		f02.operation(new UnsharedConcreteFlyweight("第2次调用a。"));       
		f03.operation(new UnsharedConcreteFlyweight("第3次调用a。"));       
		f11.operation(new UnsharedConcreteFlyweight("第1次调用b。"));       
		f12.operation(new UnsharedConcreteFlyweight("第2次调用b。"));
	}
}
//非享元角色
public class UnsharedConcreteFlyweight{
	private String info;
	public UnsharedConcreteFlyweight(String info){
		this.info=info;
	}
	public String getInfo(){
		return info;
	}
	public void setInfo(String info){
		this.info=info;
	}
}
//抽象享元角色
public interface Flyweight{
	public void operation(UnsharedConcreteFlyweight state);
}
//具体享元角色
public class ConcreteFlyweight implements Flyweight{
	private String key;
	public ConcreteFlyweight(String key){
		this.key=key;
		System.out.println("具体享元"+key+"被创建！");
	}
	public void operation(UnsharedConcreteFlyweight outState){
		System.out.print("具体享元"+key+"被调用，");
		System.out.println("非享元信息是:"+outState.getInfo());
	}
}
//享元工厂角色
public class FlyweightFactory{
	private HashMap<String, Flyweight> flyweights=new HashMap<String, Flyweight>();
	public Flyweight getFlyweight(String key){
		Flyweight flyweight=(Flyweight)flyweights.get(key);
		if(flyweight!=null){
			System.out.println("具体享元"+key+"已经存在，被成功获取！");
		} else {
			flyweight=new ConcreteFlyweight(key);
			flyweights.put(key, flyweight);
		}
		return flyweight;
	}
}

运行结果：

具体享元a被创建！
具体享元a已经存在，被成功获取！
具体享元a已经存在，被成功获取！
具体享元b被创建！
具体享元b已经存在，被成功获取！
具体享元a被调用，非享元信息是:第1次调用a。
具体享元a被调用，非享元信息是:第2次调用a。
具体享元a被调用，非享元信息是:第3次调用a。
具体享元b被调用，非享元信息是:第1次调用b。
具体享元b被调用，非享元信息是:第2次调用b。

扩展

在前面介绍的享元模式中，其结构图通常包含可以共享的部分和不可以共享的部分。在实际使用过程中，有时候会稍加改变，即存在两种特殊的享元模式：

• 单纯享元模式：这种享元模式中的所有的具体享元类都是可以共享的，不存在非共享的具体享元类，其结构图如下：
  

• 复合享元模式：这种享元模式中的有些享元对象是由一些单纯享元对象组合而成的，它们就是复合享元对象。虽然复合享元对象本身不能共享，但它们可以分解成单纯享元对象再被共享，其结构图如下：
  

使用场景

享元模式是通过减少内存中对象的数量来节省内存空间的，所以以下几种情形适合采用享元模式：

• 系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源
• 大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态
• 由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式
  

组合模式

使用背景

在现实生活中，存在很多“部分-整体”的关系，例如，大学中的部门与学院、总公司中的部门与分公司、学习用品中的书与书包、生活用品中的衣服与衣柜以及厨房中的锅碗瓢盆等。在软件开发中也是这样，例如，文件系统中的文件与文件夹、窗体程序中的简单控件与容器控件等。对这些简单对象与复合对象的处理，如果用组合模式来实现会很方便

定义

有时又叫作部分-整体模式，它是一种将对象组合成树状的层次结构的模式，用来表示“部分-整体”的关系，使用户对单个对象和组合对象具有一致的访问性

特点

主要优点有：

• 组合模式使得客户端代码可以一致地处理单个对象和组合对象，无须关心自己处理的是单个对象，还是组合对象，这简化了客户端代码
• 更容易在组合体内加入新的对象，客户端不会因为加入了新的对象而更改源代码，满足“开闭原则”

其主要缺点是：

• 设计较复杂，客户端需要花更多时间理清类之间的层次关系
• 不容易限制容器中的构件
• 不容易用继承的方法来增加构件的新功能
  

结构

组合模式包含以下主要角色：

• 抽象构件（Component）角色：它的主要作用是为树叶构件和树枝构件声明公共接口，并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口；在安全式的组合模式中不声明访问和管理子类的接口，管理工作由树枝构件完成。
• 树叶构件（Leaf）角色：是组合中的叶节点对象，它没有子节点，用于实现抽象构件角色中 声明的公共接口。
• 树枝构件（Composite）角色：是组合中的分支节点对象，它有子节点。它实现了抽象构件角色中声明的接口，它的主要作用是存储和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法

组合模式分为透明式的组合模式和安全式的组合模式：

• 透明方式：在该方式中，由于抽象构件声明了所有子类中的全部方法，所以客户端无须区别树叶对象和树枝对象，对客户端来说是透明的。但其缺点是：树叶构件本来没有 Add()、Remove() 及 GetChild() 方法，却要实现它们（空实现或抛异常），这样会带来一些安全性问题。其结构图如下：
  

• 安全方式：在该方式中，将管理子构件的方法移到树枝构件中，抽象构件和树叶构件没有对子对象的管理方法，这样就避免了上一种方式的安全性问题，但由于叶子和分支有不同的接口，客户端在调用时要知道树叶对象和树枝对象的存在，所以失去了透明性。其结构图如下：
  

实现

假如要访问集合 c0={leaf1,{leaf2,leaf3}} 中的元素，其对应的树状图如下：



下面给出透明式的组合模式的实现代码，与安全式的组合模式的实现代码类似，只要对其做简单修改即可

import java.util.ArrayList;
public class CompositePattern{
	public static void main(String[] args){
		Component c0=new Composite(); 
		Component c1=new Composite(); 
		Component leaf1=new Leaf("1"); 
		Component leaf2=new Leaf("2"); 
		Component leaf3=new Leaf("3");          
		c0.add(leaf1); 
		c0.add(c1);
		c1.add(leaf2); 
		c1.add(leaf3);          
		c0.operation(); 
	}
}
//抽象构件
public interface Component{
	public void add(Component c);
	public void remove(Component c);
	public Component getChild(int i);
	public void operation();
}
//树叶构件
public class Leaf implements Component{
	private String name;
	public Leaf(String name){
		this.name=name;
	}
	public void add(Component c){ }           
	public void remove(Component c){ }   
	public Component getChild(int i){
		return null;
	}   
	public void operation(){
		System.out.println("树叶"+name+"：被访问！"); 
	}
}
//树枝构件
public class Composite implements Component{
	private ArrayList<Component> children=new ArrayList<Component>();   
	public void add(Component c){
		children.add(c);
	}   
	public void remove(Component c){
		children.remove(c);
	}   
	public Component getChild(int i){
		return children.get(i);
	}   
	public void operation(){
		for(Object obj:children){
			((Component)obj).operation();
		}
	}    
}

运行结果：

树叶1：被访问！
树叶2：被访问！
树叶3：被访问！

扩展

如果对组合模式中的树叶节点和树枝节点进行抽象，也就是说树叶节点和树枝节点还有子节点，这时组合模式就扩展成复杂的组合模式了，如 Java AWT/Swing 中的简单组件 JTextComponent 有子类 JTextField、JTextArea，容器组件 Container 也有子类 Window、Panel。复杂的组合模式的结构图如下：

使用场景

• 在需要表示一个对象整体与部分的层次结构的场合
• 要求对用户隐藏组合对象与单个对象的不同，用户可以用统一的接口使用组合结构中的所有对象的场合