写在前面
Composite组合模式属于设计模式中比较热门的一个，相信大家对它一定不像对访问者模式那么陌生，毕竟谁又没有遇到过树形结构呢。不过所谓温故而知新，我们还是从一个例子出发，起底一下这个模式吧。
一个简单例子
设想我们要建立一个公司的人事架构，在一个公司里，我们可以简单地分为两种员工，一种是经理（包括老板），另一种是基层员工，经理可以有下属，而普通员工不行，我们写出这样的代码。
基层员工类
这种员工是最基层的员工，没有下属
代码语言：javascript复制class BasicLevelEmployee //基层员工
{
public string ID { get; set; }
public void ShowStatus(int indent)
{
string str = ID;
str = str.PadLeft(ID.Length indent, '-');
Console.WriteLine(str);
}
}经理类
经理可以有下属，下属可能是基层员工，也可能是其他经理（考虑老板这种情况，无疑其他经理也是老板的下属），因为比基层员工多了下属，所以也多了一些方法维护下属属性
代码语言：javascript复制class Manager //经理
{
public string ID { get; set; }
public void ShowStatus(int indent)
{
string str = ID;
str = str.PadLeft(ID.Length indent, '-');
Console.WriteLine(str);
indent = 4;
Subordinate.ForEach(s => s.ShowStatus(indent));
SubordinateManagers.ForEach(m => m.ShowStatus(indent));
}
public List<BasicLevelEmployee> Subordinate = new List<BasicLevelEmployee>();
public List<Manager> SubordinateManagers = new List<Manager>();
//下面是经理所属的方法
public void AddSubordinate(BasicLevelEmployee e) { Subordinate.Add(e); }
public void AddSubordinate(Manager e) { SubordinateManagers.Add(e); }
public void RemoveSubordinate(BasicLevelEmployee e) { Subordinate.Remove(e); }
public void RemoveSubordinate(Manager e) { SubordinateManagers.Remove(e); }
}公司架构类
公司架构类非常简单，只需要掌握最大的BOSS，整个公司人事架构都可以顺藤摸瓜的展示出来
代码语言：javascript复制class CompanyHierachy
{
public Manager BOSS { get; set; }
public void ShowStatus()
{
BOSS.ShowStatus(0);
}
}客户端代码
假设这个公司的结构很单纯，除了老板就是开发部门和财务部门，各个部门分设经理是，所以我们写出代码如下
代码语言：javascript复制class Program
{
static void Main(string[] args)
{
//老板
Manager boss = new Manager() { ID = "BOSS" };
//开发部门经理
Manager devManager = new Manager() { ID = "Dev Manager" };
//财务部门经理
Manager financeManager = new Manager() { ID = "Finance Manager" };
//开发组长
Manager devLead = new Manager() { ID = "Dev Lead" };
//测试组长
Manager qcLead = new Manager() { ID = "QC Lead" };
boss.AddSubordinate(devManager);
boss.AddSubordinate(financeManager);
financeManager.AddSubordinate(new BasicLevelEmployee() { ID = "Purchase" });
devManager.AddSubordinate(devLead);
devManager.AddSubordinate(qcLead);
devLead.AddSubordinate(new BasicLevelEmployee() { ID = "Developer1" });
devLead.AddSubordinate(new BasicLevelEmployee() { ID = "Developer2" });
qcLead.AddSubordinate(new BasicLevelEmployee() { ID = "QuanityControl1" });
qcLead.AddSubordinate(new BasicLevelEmployee() { ID = "QuanityControl2" });
CompanyHierachy company = new CompanyHierachy() { CEO = boss };
company.ShowStatus();
}
}代码非常简单，不需要更多解释了，运行后得到结果
一切正常，代码是工作的，公司架构建立成功了。
再想一下
但是想想，这样的代码真的好吗？感觉起码有两个地方我们可以改进。
- 1. 基层员工和经理其实有太多的共性（属性和方法），可以利用抽象思维，让他们继承自同一种东西吗？
- 2. 在经理类中我们维护了多个下属列表，如果以后再加一个实习生，是不是我们又得创建更多的列表？如果我们使用了继承，这个问题还会存在吗？
基于此，利用抽象思维让经理和员工继承自同一个类（雇员）势在必行。在抽象之后，经理类会继承自雇员并且也内含雇员列表，可能第一次见到这种包含自身父类列表的设计方式会让人感觉不习惯，但不用担心，这其实是一种比较常见的设计方式。这种既有继承也有合成的结构，就是组合模式的精髓。
使用组合模式进行重构
组合模式属于结构型设计模式，它利用类型层级和聚合层级构造更大的复合结构
说的更加直白一点，当对象的局部结构和对象自身相同的情况下，我们可以使用继承加上聚合的方式来组合代码，比如刚刚提到的例子中
观察一下，对于Boss来说，它的局部结构，即DevManager和FinanceManager与它自己的结构有何区别？都是树结构，无非就是根节点不一样而已，所以于情于理这一块可以用继承加聚合来重构。
那么心细的朋友肯定发现了，有些操作是经理类独有的，这些操作我们是应该抽象到和基层员工共同的父类雇员类吗？对于这个问题，一般有两种解决方案。
透明型
在此设计中，子类方法的并集被提炼到了共有父类，哪怕这些方法对于某些子类根本不需要，这样的好处是客户端在使用的时候根本不需要知道对象纠结是哪个子类，对客户端透明，所以得名。当前设计多采用这种。
安全型
安全型设计非常保守，只会提炼子类交集的方法到父类，这样的好处是绝对安全，客户端绝对不可能在BasicLevelEmployee对象上面调用AddSubordinate或者RemoveSubordinate。但有时候会面临向下转型的情况。
重构后的代码（透明型）
抽象出共同父类雇员类，使用透明型，所有的子类方法都提炼到这个类
代码语言：javascript复制abstract class Employee
{
public string ID { get; set; }
public abstract void ShowStatus(int indent);
//因为是透明型，所以基层员工用不上的方法也会被抽象到父类
public abstract void AddSubordinate(Employee e);
public abstract void RemoveSubordinate(Employee e);
}对于基层员工，如果客户端无意间调用了不该使用的方法，这基本是一个明确的、表明客户端代码出现了逻辑问题的信号，这种情况直接抛出异常，能更快地暴露出问题
代码语言：javascript复制class BasicLevelEmployee : Employee
{
public override void ShowStatus(int indent)
{
string str = ID;
str = str.PadLeft(ID.Length indent, '-');
Console.WriteLine(str);
}
public override void AddSubordinate(Employee e)
{
throw new NotImplementedException();
}
public override void RemoveSubordinate(Employee e)
{
throw new NotImplementedException();
}
}在经理类中，得益于共有父类Employee，我们可以用一个列表装下所有的下属，不论下属是基层员工，还是经理，抑或是未来可能添加的实习生。毕竟他们都是雇员嘛
代码语言：javascript复制class Manager : Employee
{
public override void ShowStatus(int indent)
{
string str = ID;
str = str.PadLeft(ID.Length indent, '-');
Console.WriteLine(str);
indent = 4;
Subordinate.ForEach(s => s.ShowStatus(indent));
}
public List<Employee> Subordinate = new List<Employee>();
//下面是经理所属的方法
public override void AddSubordinate(Employee e) { Subordinate.Add(e); }
public override void RemoveSubordinate(Employee e) { Subordinate.Remove(e); }
}公司架构类和客户端代码调用保持不变，运行结果一致，重构成功。
可以看到，在使用了组合模式之后，现在的代码不但消除了冗余（不用再去维护多个下属列表），也更具有抵御未来变化的能力，这样的结构比起原来，当然是更加合理的。这就是结构型设计模式的用武之地，让对象的结构更加的合理，更加的易于扩展。
这就是关于Composite组合模式的介绍，鉴于笔者能力有限，如果大家对于这篇文章中所讲有其他看法，欢迎留言讨论。
> 作者：老胡写代码
> 原文：https://www.cnblogs.com/deatharthas/p/16390116.html
