1 定义:
组合模式(Composite)
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.(将对象组合成树形结构以表示“部分-整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性。)
1.1 通用类图:
组合模式中引入了抽象构件类Component,它是所有容器类和叶子类的公共父类,客户端针对Component进行编程。组合模式结构如图11-3所示:
图11-3 组合模式结构图
在组合模式结构图中包含如下几个角色:
● 抽象构件(Component):它可以是接口或抽象类,为叶子构件和容器构件对象声明接口,在该角色中可以包含所有子类共有行为的声明和实现。在抽象构件中定义了访问及管理它的子构件的方法,如增加子构件、删除子构件、获取子构件等。
● 叶子构件(Leaf):它在组合结构中表示叶子节点对象,叶子节点没有子节点,它实现了在抽象构件中定义的行为。对于那些访问及管理子构件的方法,可以通过异常等方式进行处理。
● 容器构件(Composite):它在组合结构中表示容器节点对象,容器节点包含子节点,其子节点可以是叶子节点,也可以是容器节点,它提供一个集合用于存储子节点,实现了在抽象构件中定义的行为,包括那些访问及管理子构件的方法,在其业务方法中可以递归调用其子节点的业务方法。
组合模式的关键是定义了一个抽象构件类,它既可以代表叶子,又可以代表容器,而客户端针对该抽象构件类进行编程,无须知道它到底表示的是叶子还是容器,可以对其进行统一处理。同时容器对象与抽象构件类之间还建立一个聚合关联关系,在容器对象中既可以包含叶子,也可以包含容器,以此实现递归组合,形成一个树形结构。
在使用组合模式中需要注意一点也是组合模式最关键的地方:叶子对象和组合对象实现相同的接口。这就是组合模式能够将叶子节点和对象节点进行一致处理的原因。
如果不使用组合模式,客户端代码将过多地依赖于容器对象复杂的内部实现结构,容器对象内部实现结构的变化将引起客户代码的频繁变化,带来了代码维护复杂、可扩展性差等弊端。组合模式的引入将在一定程度上解决这些问题。
1.2 通用代码:
组合模式(Composite)有两种实现方式:透明方式和安全方式.
透明方式:在Component中声明所有用来管理子对象的方法,如Add()方法,Remove()方法及GetChild()方法,所有实现Component接口的子类都具备这些方法,这使得Component和子类具备一致的行为接口,使得对客户端无需区别树叶和树枝对象。
大家可以回忆一下代理模式(Proxy)中,Proxy,RealSubject类和Subject接口具备一致的行为接口,从而使得被代理者对于客户端是透明的。
正由于我们的Composite和Leaf都具备一致的接口行为,但我们知道Leaf不应该具有Add(),Remove()及GetChild()方法,因为我们叶子节点不能再添加和移除节点了。
安全模式这种做法将树枝与叶子完全分开,在遍历时需要强制类型转换(因而破坏了依赖倒置原则),也需要类型判断。可以避免运行间异常。
2 优点
1、客户端<高层模块>调用简单,客户端可以一致的使用组合结构或其中单个对象。
2、 节点自由增加:容易扩展,符合OCP,对维护有利:
2.1 可以清楚地定义分层次的复杂对象,表示对象的全部或部分层次,使得增加新构件也更容易。
2.2 定义了包含叶子对象和容器对象的类层次结构,叶子对象可以被组合成更复杂的容器对象,而这个容器对象又可以被组合,这样不断递归下去,可以形成复杂的树形结构。
2.3 更容易在组合体内加入对象构件,客户端不必因为加入了新的对象构件而更改原有代码。
3 缺点
使设计变得更加抽象,对象的业务规则如果很复杂,则实现组合模式具有很大挑战性,而且不是所有的方法都与叶子对象子类都有关联。
4 应用场景
4.1 维护和展示部分-整体关系的场景,如树形菜单、文件和文件夹管理;
4.2 从一个整体中能够独立出部分模块或功能的场景;
4.3 家族关系图谱(倒推方可)
5 注意事项
- Composite模式采用树形结构来实现普遍存在的对象容器,从而将“一对多”的关系转化为“一对一”的关系,使得客户代码可以一致的处理对象和对象容器,无需关心处理的是单个对象,还是组合的对象容器。
- 将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思想,解耦之后,客户代码将与纯粹的对象接口——而非对象容器的复杂内部实现结构——发生依赖关系,从而更能“应对变化”。
- Composite模式中,是将“Add和Remove的和对象容器相关的方法”定义在“表示抽象对象的Component类”中,还是将其定义在“表示对象容器的Composite类”中,是一个关乎“透明性”和“安全性”的两难问题,需要仔细权衡结构,这又是必须付出的代价。
- Composite模式在具体实现中,可以让父对象中的字对象反向追溯:如果父对象有频繁的遍历需求,可使用缓存技巧来改善效率
6 扩展
Java SE中的AWT和Swing包的设计就基于组合模式,Java AWT中使用的组合模式就是安全组合模式,在这些界面包中为用户提供了大量的容器构件(如Container)和成员构件(如Checkbox、Button和TextComponent等),其结构如图11-10所示:
图11-10 AWT组合模式结构示意图
在图11-10中,Component类是抽象构件,Checkbox、Button和TextComponent是叶子构件,而Container是容器构件,在AWT中包含的叶子构件还有很多,因为篇幅限制没有在图中一一列出。在一个容器构件中可以包含叶子构件,也可以继续包含容器构件,这些叶子构件和容器构件一起组成了复杂的GUI界面。
除此以外,在XML解析、组织结构树处理、文件系统设计等领域,组合模式都得到了广泛应用。
7 范例
7.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的资料'进行杀毒 ****对文件夹'图像文件'进行杀毒 ----对图像文件'小龙女.jpg'进行杀毒 ----对图像文件'张无忌.gif'进行杀毒 ****对文件夹'文本文件'进行杀毒 ----对文本文件'九阴真经.txt'进行杀毒 ----对文本文件'葵花宝典.doc'进行杀毒 |
Sunny公司开发人员“成功”实现了杀毒软件的框架设计,但通过仔细分析,发现该设计方案存在如下问题:
(1) 文件夹类Folder的设计和实现都非常复杂,需要定义多个集合存储不同类型的成员,而且需要针对不同的成员提供增加、删除和获取等管理和访问成员的方法,存在大量的冗余代码,系统维护较为困难;
(2) 由于系统没有提供抽象层,客户端代码必须有区别地对待充当容器的文件夹Folder和充当叶子的ImageFile和TextFile,无法统一对它们进行处理;
(3) 系统的灵活性和可扩展性差,如果需要增加新的类型的叶子和容器都需要对原有代码进行修改,例如如果需要在系统中增加一种新类型的视频文件VideoFile,则必须修改Folder类的源代码,否则无法在文件夹中添加视频文件。
面对以上问题,Sunny软件公司的开发人员该如何来解决?这就需要用到本章将要介绍的组合模式,组合模式为处理树形结构提供了一种较为完美的解决方案,它描述了如何将容器和叶子进行递归组合,使得用户在使用时无须对它们进行区分,可以一致地对待容器和叶子。
为了让系统具有更好的灵活性和可扩展性,客户端可以一致地对待文件和文件夹,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();
- }
- }
编译并运行程序,输出结果如下:
****对文件夹'Sunny的资料'进行杀毒 ****对文件夹'图像文件'进行杀毒 ----对图像文件'小龙女.jpg'进行杀毒 ----对图像文件'张无忌.gif'进行杀毒 ****对文件夹'文本文件'进行杀毒 ----对文本文件'九阴真经.txt'进行杀毒 ----对文本文件'葵花宝典.doc'进行杀毒 ****对文件夹'视频文件'进行杀毒 ----对视频文件'笑傲江湖.rmvb'进行杀毒 |
由于在本实例中使用了组合模式,在抽象构件类中声明了所有方法,包括用于管理和访问子构件的方法,如add()方法和remove()方法等,因此在ImageFile等叶子构件类中实现这些方法时必须进行相应的异常处理或错误提示。在容器构件类Folder的killVirus()方法中将递归调用其成员对象的killVirus()方法,从而实现对整个树形结构的遍历。
如果需要更换操作节点,例如只需对文件夹“文本文件”进行杀毒,客户端代码只需修改一行即可,将代码:
folder1.killVirus(); |
改为:
folder3.killVirus(); |
输出结果如下:
****对文件夹'文本文件'进行杀毒 ----对文本文件'九阴真经.txt'进行杀毒 ----对文本文件'葵花宝典.doc'进行杀毒 |
在具体实现时,我们可以创建图形化界面让用户选择所需操作的根节点,无须修改源代码,符合“开闭原则”,客户端无须关心节点的层次结构,可以对所选节点进行统一处理,提高系统的灵活性。