组合模式 - 设计模式学习

  组合模式(Composite),将对象组合成属性结构以表示‘部分-整体‘的层次结构,组合模式使得用户对单个对象和组合对象的使用具有一致性。

  下面给出组合模式的UML图:

    

  来看组合模式的基本代码结构:

namespace ConsoleApplication1
{
    //Component为组合中的对象声明接口
    abstract class Component
    {
        protected string name;

        public Component(string name)
        {
            this.name = name;
        }

        public abstract void Add(Component c);
        public abstract void Remove(Component c);
        public abstract void Display(int depth);
    }

    //Leaf在组合中表示叶节点对象
    class Leaf : Component
    {
        public Leaf(string name) : base(name)
        { }

        public override void Add(Component c)       //由于叶子没有再增加分支和树叶,所以Add方法和Remove方法对它没有意义,
            //但这样做可以消除叶节点和枝节点对象在抽象层次的区别,他们具备完全一直的接口
        {
            Console.WriteLine("叶子节点不允许再添加树枝和树叶");
        }

        public override void Remove(Component c)
        {
            Console.WriteLine("叶子节点根本没有子节点,移除方法也没有意义");
        }

        public override void Display(int depth)
        {
            Console.WriteLine(new String(‘-‘, depth) + name);
        }
    }

    //枝节点
    class Composite : Component
    {
        private List<Component> children = new List<Component>();

        public Composite(string name)
            : base(name)
        { }

        public override void Add(Component c)
        {
            children.Add(c);
        }

        public override void Remove(Component c)
        {
            children.Remove(c);
        }

        public override void Display(int depth)
        {
            Console.WriteLine(new String(‘-‘, depth) + name);
            foreach (Component component in children)
            {
                component.Display(depth + 2);
            }
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Composite root = new Composite("root");
            root.Add(new Leaf("Leaf A"));
            root.Add(new Leaf("Leaf B"));

            Composite comp = new Composite("Composite X");
            comp.Add(new Leaf("Leaf XA"));
            comp.Add(new Leaf("Leaf XB"));

            root.Add(comp);

            Composite comp2 = new Composite("Composite XY");
            comp2.Add(new Leaf("Leaf XYA"));
            comp2.Add(new Leaf("Leaf XYB"));

            comp.Add(comp2);

            root.Add(new Leaf("Leaf C"));
            Leaf leaf = new Leaf("Leaf D");
            root.Add(leaf);
            root.Remove(leaf);

            root.Display(1);

            Console.ReadKey();
        }
    }
}

  结果如下图所示:

    

  至于在Component接口中的所有子类都具备了Add和Remove。这样做的好处就是叶节点和枝节点对于外界没有区别,他们具备完全一致的行为接口。但问题也很明显,因为Leaf类本身不具备Add()、Remove()方法的功能,所以事先它是没有意义的。不过,如果是不一致的话,那么客户端在调用的时候,就要先判断这个节点是不是叶子节点才能用Add和Remove方法了。

  什么地方适合使用组合模式呢?

  当你发现需求中是体现部分与整体层次的结构时,以及你希望用户可以忽略组合对象与单个对象的不同,统一地使用组合结构中的所有对象时,就应该考虑用组合模式了。

  下面回到《大话设计模式》中的公司管理系统的例子:

namespace ConsoleApplication1
{
    //公司类,抽象类
    abstract class Company
    {
        protected string name;

        public Company(string name)
        {
            this.name = name;
        }

        public abstract void Add(Company c);    //增加
        public abstract void Remove(Company c); //移除
        public abstract void Display(int depth);    //显示
        public abstract void LineOfDuty();   //履行职责
    }

    //具体公司类
    class ConcreteCompany : Company
    {
        private List<Company> children = new List<Company>();
        public ConcreteCompany(string name)
            : base(name)
        { }

        public override void Add(Company c)
        {
            children.Add(c);
        }

        public override void Remove(Company c)
        {
            children.Remove(c);
        }

        public override void Display(int depth)
        {
            Console.WriteLine(new String(‘-‘,depth) + name);
            foreach (Company component in children)
            {
                component.Display(depth + 2);
            }
        }

        //履行职责
        public override void LineOfDuty()
        {
            foreach (Company component in children)
            {
                component.LineOfDuty();
            }
        }
    }

    //人力资源部
    class HRDepartment : Company
    {
        public HRDepartment(string name)
            : base(name)
        { }

        public override void Add(Company c)
        {

        }

        public override void Remove(Company c)
        {

        }

        public override void Display(int depth)
        {
            Console.WriteLine(new String(‘-‘, depth) + name);
        }

        public override void LineOfDuty()
        {
            Console.WriteLine("{0}员工招聘培训管理", name);
        }
    }

    //财务部
    class FinanceDepartment : Company
    {
        public FinanceDepartment(string name)
            : base(name)
        { }

        public override void Add(Company c)
        {

        }

        public override void Remove(Company c)
        {

        }

        public override void Display(int depth)
        {
            Console.WriteLine(new String(‘-‘, depth) + name);
        }

        public override void LineOfDuty()
        {
            Console.WriteLine("{0}公司财务收支管理", name);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            ConcreteCompany root = new ConcreteCompany("北京总公司");
            root.Add(new HRDepartment("总公司人力资源部"));     //注意 此处是root.Add    说明这个节点是总公司下的
            root.Add(new FinanceDepartment("总公司财务部"));

            ConcreteCompany comp = new ConcreteCompany("上海华东分公司");
            comp.Add(new HRDepartment("华东分公司人力资源部"));   //此处是comp.Add   说明这个节点是分公司下的
            comp.Add(new FinanceDepartment("华东分公司财务部"));
            root.Add(comp);     //分公司属于总公司直接管理

            ConcreteCompany comp1 = new ConcreteCompany("南京办事处");
            comp1.Add(new HRDepartment("南京办事处人力资源部"));
            comp1.Add(new FinanceDepartment("南京办事处财务部"));
            root.Add(comp1);     //分公司属于总公司直接管理

            ConcreteCompany comp2 = new ConcreteCompany("杭州办事处");
            comp2.Add(new HRDepartment("杭州办事处人力资源部"));
            comp2.Add(new FinanceDepartment("杭州办事处财务部"));
            root.Add(comp2);     //分公司属于总公司直接管理

            Console.WriteLine("\n结构图:");
            root.Display(1);

            Console.WriteLine("\n职责:");
            root.LineOfDuty();

            Console.ReadKey();
        }
    }
}

  结果如下所示:

    

  这样写的好处呢?组合模式这样就定义了包含人力资源部和财务部这些基本对象和分公司、办事处等组合对象的类层次结构。基本对象可以被组合成更复杂的对象,而这个组合对象又何以被组合,这样不断地递归下去,客户代码中,任何用到基本对象的地方都可以使用组合对象了。同时客户端是不用关心到底是处理一个叶节点还是处理一个组合组件,也就用不着为定义组合而写一些选择判断语句了。简单说来,组合模式让客户可以一直地使用组合结构和单个对象。

时间: 2024-10-08 07:18:18

组合模式 - 设计模式学习的相关文章

简单工厂模式、工厂方法模式和抽象工厂模式-设计模式学习

1.简单工厂模式 简单工厂模式是属于创建型模式,又叫做静态工厂方法(StaticFactory Method)模式,但不属于23种GOF设计模式之一.简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例.简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现. 工厂(Creator)角色 简单工厂模式的核心,它负责实现创建所有实例的内部逻辑.工厂类的创建产品类的方法可以被外界直接调用,创建所需的产品对象. 抽象产品(Product)角色 简单工厂模式所创建的所有

备忘录模式 - 设计模式学习

备忘录模式(Memento):在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态.这样以后就可将该对象恢复到原先保存的状态. 以下给出备忘录模式的UML图: Originator(发起人):负责创建一个备忘录Memento,用以记录当前时刻它的内部状态,并可使用备忘录恢复内部状态.Originator可根据需要决定Memento存储Originator的哪些内部状态. Memento(备忘录):负责存储Originnator对象的内部状态,并可防止Originator以外

桥接模式 - 设计模式学习

合成/聚合复用原则(CARP),尽量使用合成/聚合,尽量不要使用类继承. 合成和聚合都是关联的特殊种类.聚合表示一种弱的“拥有关系”,体现的是A对象可以包含B对象,但B对象不一定是A对象的一部分:合成则是一种枪的‘拥有’关系,体现了严格的部分和整体的关系,部分和整体的声明周期一样.比方说,大雁有两个翅膀,翅膀与大雁是部分和整体的关系,并且它们的声明周期是相同的,于是大雁和翅膀就是合成关系.而大雁是群居动物,所以每只大雁都是属于一个雁群,一个雁群可以有多只大雁,所以大雁和雁群是聚合关系. 合成/聚

职责链模式 - 设计模式学习

职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它位置. 下面给出职责链模式的结构图: 下面给出职责链模式的基本代码结构: namespace ConsoleApplication1 { //Handler类,定义一个处理请示的接口 abstract class Handler { protected Handler successor; publ

命令模式 - 设计模式学习

命令模式(Command),将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化:对请求排队或记录请求日志,以及支持可撤销操作. 下面给出命令模式的结构图: 下面是命令模式的基本结构代码: namespace ConsoleApplication1 { abstract class Command { protected Receiver receiver; public Command(Receiver receiver) { this.receiver = receiver; }

抽象工厂模式 - 设计模式学习

抽象工厂模式(Abstract Factory),提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类. 以下给出抽象工厂方法模式的UML图: 回到<大话设计模式>里面的双数据库访问的例子: namespace ConsoleApplication1 { class User { private int _id; public int ID { get { return _id; } set { _id = value; } } private string _name; pub

享元模式 - 设计模式学习

享元模式(Flyweight),运用共享技术有效地支持大量细粒度的对象. 下面给出享元模式的结构图: 下面给出享元模式的基本代码结构: namespace ConsoleApplication1 { //Flyweight类,它是所有具体享元类的超类或接口,通过这个接口,Flyweight可以接受并作用于外部状态 abstract class Flyweight { public abstract void Operation(int extrinsicstate); } //ConcreteF

解释器模式 - 设计模式学习

解释器模式(interpreter),给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. 解释器模式需要解决的是,如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题. 下面给出解释器模式的结构图: 下面给出解释器模式的基本代码结构: namespace ConsoleApplication1 { //AbstractExpresstion(抽

访问者模式 - 设计模式学习

访问者模式(Visitor),表示一个作用于某对象结构中的各元素的操作.它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作. 下面给出访问者模式的结构图: 从类图可以看出,访问者模式那是相当复杂啊! 下面给出访问者模式的基本代码结构: namespace ConsoleApplication1 { //Visitor类,为该对象结构中ConcreteElement的每一个类声明一个Visit操作. abstract class Visitor { public abstract vo