AI 助理
备案控制台
开发者社区 人工智能 文章 正文

.NET设计模式（11）：组合模式（Composite Pattern）

2017-11-16 1116
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：

组合模式（Composite Pattern）

——.NET设计模式系列之十一
Terrylee ， 2006 年 3 月
概述
组合模式有时候又叫做部分 - 整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。
意图
将对象组合成树形结构以表示“部分 - 整体”的层次结构。 Composite 模式使得用户对单个对象和组合对象的使用具有一致性。 [GOF  《设计模式》 ]
结构图
图 1 Composite 模式结构图
生活中的例子
组合模式将对象组合成树形结构以表示 " 部分 - 整体 " 的层次结构。让用户一致地使用单个对象和组合对象。虽然例子抽象一些，但是算术表达式确实是组合的例子。算术表达式包括操作数、操作符和另一个操作数。操作数可以是数字，也可以是另一个表达式。这样， 2+3 和（ 2+3 ） + （ 4*6 ）都是合法的表达式。
图 2  使用算术表达式例子的 Composite 模式对象图
组合模式解说
这里我们用绘图这个例子来说明 Composite 模式，通过一些基本图像元素（直线、圆等）以及一些复合图像元素（由基本图像元素组合而成）构建复杂的图形树。在设计中我们对每一个对象都配备一个 Draw() 方法，在调用时，会显示相关的图形。可以看到，这里复合图像元素它在充当对象的同时，又是那些基本图像元素的一个容器。先看一下基本的类结构图：
图 3
图中橙色的区域表示的是复合图像元素。示意性代码：
public   abstract   class  Graphics
 {
    protected string _name;

    public Graphics(string name)
    {
        this._name = name;
    }
    public abstract void Draw();
}

public   class  Picture : Graphics
 {
    public Picture(string name)
        : base(name)
    { }
    public override void Draw()
    {
        //
    }

    public ArrayList GetChilds()
    { 
        //返回所有的子对象
    }
}
而其他作为树枝构件，实现代码如下：
public   class  Line:Graphics
 {
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public   class  Circle : Graphics
 {
    public Circle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public   class  Rectangle : Graphics
 {
    public Rectangle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}
现在我们要对该图像元素进行处理：在客户端程序中，需要判断返回对象的具体类型到底是基本图像元素，还是复合图像元素。如果是复合图像元素，我们将要用递归去处理，然而这种处理的结果却增加了客户端程序与复杂图像元素内部结构之间的依赖，那么我们如何去解耦这种关系呢？我们希望的是客户程序可以像处理基本图像元素一样来处理复合图像元素，这就要引入 Composite 模式了，需要把对于子对象的管理工作交给复合图像元素，为了进行子对象的管理，它必须提供必要的 Add() ， Remove() 等方法，类结构图如下：
图4
示意性代码：
public   abstract   class  Graphics
 {
    protected string _name;

    public Graphics(string name)
    {
        this._name = name;
    }
    public abstract void Draw();
    public abstract void Add();
    public abstract void Remove();
}

public   class  Picture : Graphics
 {
    protected ArrayList picList = new ArrayList();

    public Picture(string name)
        : base(name)
    { }
    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());

        foreach (Graphics g in picList)
        {
            g.Draw();
        }
    }

    public override void Add(Graphics g)
    {
        picList.Add(g);
    }
    public override void Remove(Graphics g)
    {
        picList.Remove(g);
    }
}

public   class  Line : Graphics
 {
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { }
    public override void Remove(Graphics g)
    { }
}

public   class  Circle : Graphics
 {
    public Circle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { }
    public override void Remove(Graphics g)
    { }
}

public   class  Rectangle : Graphics
 {
    public Rectangle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { }
    public override void Remove(Graphics g)
    { }
}
这样引入 Composite 模式后，客户端程序不再依赖于复合图像元素的内部实现了。然而，我们程序中仍然存在着问题，因为 Line ， Rectangle ， Circle 已经没有了子对象，它是一个基本图像元素，因此 Add() ， Remove() 的方法对于它来说没有任何意义，而且把这种错误不会在编译的时候报错，把错误放在了运行期，我们希望能够捕获到这类错误，并加以处理，稍微改进一下我们的程序：
public   class  Line : Graphics
 {
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { 
        //抛出一个我们自定义的异常
    }
    public override void Remove(Graphics g)
    {
        //抛出一个我们自定义的异常
    }
}
这样改进以后，我们可以捕获可能出现的错误，做进一步的处理。上面的这种实现方法属于透明式的 Composite 模式，如果我们想要更安全的一种做法，就需要把管理子对象的方法声明在树枝构件 Picture 类里面，这样如果叶子节点 Line ， Rectangle ， Circle 使用这些方法时，在编译期就会出错，看一下类结构图：
图5
示意性代码：
public   abstract   class  Graphics
 {
    protected string _name;

    public Graphics(string name)
    {
        this._name = name;
    }
    public abstract void Draw();
}

public   class  Picture : Graphics
 {
    protected ArrayList picList = new ArrayList();

    public Picture(string name)
        : base(name)
    { }
    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());

        foreach (Graphics g in picList)
        {
            g.Draw();
        }
    }

    public void Add(Graphics g)
    {
        picList.Add(g);
    }
    public void Remove(Graphics g)
    {
        picList.Remove(g);
    }
}

public   class  Line : Graphics
 {
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public   class  Circle : Graphics
 {
    public Circle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public   class  Rectangle : Graphics
 {
    public Rectangle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}
这种方式属于安全式的 Composite 模式，在这种方式下，虽然避免了前面所讨论的错误，但是它也使得叶子节点和树枝构件具有不一样的接口。这种方式和透明式的 Composite 各有优劣，具体使用哪一个，需要根据问题的实际情况而定。通过 Composite 模式，客户程序在调用 Draw() 的时候不用再去判断复杂图像元素中的子对象到底是基本图像元素，还是复杂图像元素，看一下简单的客户端调用：
public   class  App
 {
    public static void Main()
    {
        Picture root = new Picture("Root");

        root.Add(new Line("Line"));
        root.Add(new Circle("Circle"));

        Rectangle r = new Rectangle("Rectangle");
        root.Add(r);

        root.Draw();
    }
}
.NET 中的组合模式
如果有人用过 Enterprise Library2.0 ，一定在源程序中看到了一个叫做 ObjectBuilder 的程序集，顾名思义，它是用来负责对象的创建工作的，而在 ObjectBuilder 中，有一个被称为定位器的东西，通过定位器，可以很容易的找到对象， 它的结构采用链表结构，每一个节点是一个键值对，用来标识对象的唯一性，使得对象不会被重复创建。定位器的链表结构采用可枚举的接口类来实现，这样我们可以通过一个迭代器来遍历这个链表。同时多个定位器也被串成一个链表。具体地说就是多个定位器组成一个链表，表中的每一个节点是一个定位器，定位器本身又是一个链表，表中保存着多个由键值对组成的对象的节点。所以这是一个典型的Composite模式的例子，来看它的结构图：

图6
正如我们在图中所看到的， IReadableLocator 定义了最上层的定位器接口方法，它基本上具备了定位器的大部分功能。
部分代码：
public   interface  IReadableLocator : IEnumerable < KeyValuePair < object ,  object >>
{
    //返回定位器中节点的数量
    int Count { get; }

    //一个指向父节点的引用
    IReadableLocator ParentLocator { get; }

    //表示定位器是否只读
    bool ReadOnly { get; }

    //查询定位器中是否已经存在指定键值的对象
    bool Contains(object key);

    //查询定位器中是否已经存在指定键值的对象，根据给出的搜索选项，表示是否要向上回溯继续寻找。
    bool Contains(object key, SearchMode options);

    //使用谓词操作来查找包含给定对象的定位器
    IReadableLocator FindBy(Predicate<KeyValuePair<object, object>> predicate);

    //根据是否回溯的选项，使用谓词操作来查找包含对象的定位器
    IReadableLocator FindBy(SearchMode options, Predicate<KeyValuePair<object, object>> predicate);

    //从定位器中获取一个指定类型的对象
    TItem Get<TItem>();

    //从定位其中获取一个指定键值的对象
    TItem Get<TItem>(object key);

    //根据选项条件，从定位其中获取一个指定类型的对象
    TItem Get<TItem>(object key, SearchMode options);

    //给定对象键值获取对象的非泛型重载方法
    object Get(object key);

    //给定对象键值带搜索条件的非泛型重载方法
object Get(object key, SearchMode options);
}
一个抽象基类 ReadableLocator 用来实现这个接口的公共方法。两个主要的方法实现代码如下：
public   abstract   class  ReadableLocator : IReadableLocator
 {
    /// <summary>
    /// 查找定位器，最后返回一个只读定位器的实例
    /// </summary>
    public IReadableLocator FindBy(SearchMode options, Predicate<KeyValuePair<object, object>> predicate)
    {
        if (predicate == null)
            throw new ArgumentNullException("predicate");
        if (!Enum.IsDefined(typeof(SearchMode), options))
            throw new ArgumentException(Properties.Resources.InvalidEnumerationValue, "options");

        Locator results = new Locator();
        IReadableLocator currentLocator = this;

        while (currentLocator != null)
        {
            FindInLocator(predicate, results, currentLocator);
            currentLocator = options == SearchMode.Local ? null : currentLocator.ParentLocator;
        }

        return new ReadOnlyLocator(results);
    }

    /// <summary>
    /// 遍历定位器
    /// </summary>
    private void FindInLocator(Predicate<KeyValuePair<object, object>> predicate, Locator results,
                                        IReadableLocator currentLocator)
    {
        foreach (KeyValuePair<object, object> kvp in currentLocator)
        {
            if (!results.Contains(kvp.Key) && predicate(kvp))
            {
                results.Add(kvp.Key, kvp.Value);
            }
        }
    }
}
可以看到，在FindBy方法里面，循环调用了 FindInLocator 方法， 如果查询选项是只查找当前定位器，那么循环终止，否则沿着定位器的父定位器继续向上查找。FindInLocator方法就是遍历定位器，然后把找到的对象存入一个临时的定位器。最后返回一个只读定位器的新的实例。
从这个抽象基类中派生出一个具体类和一个抽象类，一个具体类是只读定位器（ ReadOnlyLocator ），只读定位器实现抽象基类没有实现的方法，它封装了一个实现了 IReadableLocator 接口的定位器，然后屏蔽内部定位器的写入接口方法。另一个继承的是读写定位器抽象类ReadWriteLocator，为了实现对定位器的写入和删除，这里定义了一个对 IReadableLocator 接口扩展的接口叫做 IReadWriteLocator ，在这个接口里面提供了实现定位器的操作：

图7
实现代码如下：
public   interface  IReadWriteLocator : IReadableLocator
 {
    //保存对象到定位器
    void Add(object key, object value);

    //从定位器中删除一个对象，如果成功返回真，否则返回假
    bool Remove(object key); 
}
从 ReadWirteLocator派生的具体类是 Locator类， Locator类必须实现一个定位器的全部功能，现在我们所看到的 Locator它已经具有了管理定位器的功能，同时他还应该具有存储的结构，这个结构是通过一个 WeakRefDictionary类来实现的，这里就不介绍了。 [关于定位器的介绍参考了 niwalker的 Blog]
效果及实现要点
1 ． Composite 模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化“一对一”的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
2 ．将“客户代码与复杂的对象容器结构”解耦是 Composite 模式的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的复内部实现结构——发生依赖关系，从而更能“应对变化”。
3 ． Composite 模式中，是将“ Add 和 Remove 等和对象容器相关的方法”定义在“表示抽象对象的 Component 类”中，还是将其定义在“表示对象容器的 Composite 类”中，是一个关乎“透明性”和“安全性”的两难问题，需要仔细权衡。这里有可能违背面向对象的“单一职责原则”，但是对于这种特殊结构，这又是必须付出的代价。 ASP.NET 控件的实现在这方面为我们提供了一个很好的示范。
4 ． Composite 模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。
适用性
以下情况下适用 Composite 模式：
1 ．你想表示对象的部分 - 整体层次结构
2 ．你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
总结
组合模式解耦了客户程序与复杂元素内部结构，从而使客户程序可以向处理简单元素一样来处理复杂元素。
参考资料
阎宏，《 Java 与模式》，电子工业出版社
James W. Cooper ，《 C# 设计模式》，电子工业出版社
Alan Shalloway James R. Trott ，《 Design Patterns Explained 》，中国电力出版社
MSDN WebCast  《 C# 面向对象设计模式纵横谈 (9) ： Composite 组合模式 ( 结构型模式 ) 》

















本文转自lihuijun51CTO博客，原文链接： http://blog.51cto.com/terrylee/67759  ，如需转载请自行联系原作者

文章标签：
容器
图形学
关键词：
设计模式组合模式composite
设计模式composite
设计模式组合模式
设计模式pattern
设计模式组合模式composite pattern
技术小甜
目录
相关文章
flzjkl
|
4月前
|
设计模式 Java 定位技术
【设计模式】【结构型模式】组合模式（Composite）
一、入门 什么是组合模式 组合模式（Composite Pattern）是一种结构型设计模式，它允许你将对象组合成树形结构来表示“部分-整体”的层次关系。组合模式使得客户端可以统一处理单个对象和组合对
flzjkl
131 10
游客mh6m5bdpmxyz2
|
6月前
|
设计模式 Java 数据安全/隐私保护
Java 设计模式：装饰者模式（Decorator Pattern）
装饰者模式属于结构型设计模式，允许通过动态包装对象的方式为对象添加新功能，提供比继承更灵活的扩展方式。该模式通过组合替代继承，遵循开闭原则（对扩展开放，对修改关闭）。
游客mh6m5bdpmxyz2
95 1
SlackClimb
|
7月前
|
设计模式 存储 安全
「全网最细 + 实战源码案例」设计模式——组合模式
组合模式（Composite Pattern）是一种结构型设计模式，用于将对象组合成树形结构以表示“部分-整体”的层次结构。它允许客户端以一致的方式对待单个对象和对象集合，简化了复杂结构的处理。组合模式包含三个主要组件：抽象组件（Component）、叶子节点（Leaf）和组合节点（Composite）。通过这种模式，客户端可以统一处理简单元素和复杂元素，而无需关心其内部结构。适用于需要实现树状对象结构或希望以相同方式处理简单和复杂元素的场景。优点包括支持树形结构、透明性和遵循开闭原则；缺点是可能引入不必要的复杂性和过度抽象。
SlackClimb
180 22
朝阳39
|
设计模式 JavaScript 前端开发
js设计模式【详解】—— 组合模式
js设计模式【详解】—— 组合模式
朝阳39
150 7
杀死一只知更鸟debug
|
12月前
|
设计模式
设计模式-工厂模式 Factory Pattern（简单工厂、工厂方法、抽象工厂）
这篇文章详细解释了工厂模式，包括简单工厂、工厂方法和抽象工厂三种类型。每种模式都通过代码示例展示了其应用场景和实现方法，并比较了它们之间的差异。简单工厂模式通过一个工厂类来创建各种产品；工厂方法模式通过定义一个创建对象的接口，由子类决定实例化哪个类；抽象工厂模式提供一个创建相关或依赖对象家族的接口，而不需要明确指定具体类。
杀死一只知更鸟debug
661 0
设计模式-工厂模式 Factory Pattern（简单工厂、工厂方法、抽象工厂）
大数据文摘
|
12月前
|
设计模式 Java
Java设计模式：组合模式的介绍及代码演示
组合模式是一种结构型设计模式，用于将多个对象组织成树形结构，并统一处理所有对象。例如，统计公司总人数时，可先统计各部门人数再求和。该模式包括一个通用接口、表示节点的类及其实现类。通过树形结构和节点的通用方法，组合模式使程序更易扩展和维护。
大数据文摘
152 2
Java设计模式：组合模式的介绍及代码演示
艾利克斯冰
|
12月前
|
设计模式 存储 安全
Java设计模式-组合模式（13）
Java设计模式-组合模式（13）
艾利克斯冰
141 2
杀死一只知更鸟debug
|
12月前
|
设计模式 Java
设计模式--适配器模式 Adapter Pattern
这篇文章介绍了适配器模式，包括其基本介绍、工作原理以及类适配器模式、对象适配器模式和接口适配器模式三种实现方式。
杀死一只知更鸟debug
395 0
weixin_836869520
|
设计模式
设计模式-05建造者模式(Builder Pattern)
设计模式-05建造者模式(Builder Pattern)
weixin_836869520
199 0
公众号:码到三十五
|
设计模式 存储 安全
Java设计模式：组合模式之透明与安全的两种实现（七）
Java设计模式：组合模式之透明与安全的两种实现（七）
公众号:码到三十五
124 0