动机:客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频繁变化,带来了代码维护性、扩展性等弊端。本模式通过将对象组合成树形结构以表示“部分-整体”的层次结构,让组合对象实现自身的复杂结构,使得用户对单个对象和组合对象的使用具有一致性。
应用:ASP.NET子父控件关系。
场景:以树为例,叶子为最低级原子节点,树为容器,可以包括子树和叶子。需要使客户程序对树和叶子的处理一致,保持透明性,而不需要关心处理的是树还是叶子。
适用环境:
你想表示对象的部分-整体层次结构。
你希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
Composite好处:
1.使客户端调用简单,客户端可以一致的使用组合结构或其中单个对象,用户就不必关系自己处理的是单个对象还是整个组合结构,这就简化了客户端代码。
2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。
结构:
[img]http://www.cnblogs.com/images/cnblogs_com/charly/DesignPatternNote/Composite.gif[/img]
代码实现
namespace DesignPattern.Composite
{
public interface ITree
{
void Process();
void Add(ITree tree);
void Remove(ITree tree);
}
public class Leaf : ITree
{
public void Process()
{
}
public void Add(ITree tree)
{
throw new Exception("叶子不支持该方法!");
}
public void Remove(ITree tree)
{
throw new Exception("叶子不支持该方法!");
}
}
public class Tree : ITree
{
IList<ITree> treeCollection = null;
public void Process()
{
foreach (ITree tree in treeCollection)
{
tree.Process();
}
}
public void Add(ITree tree)
{
treeCollection.Add(tree);
}
public void Remove(ITree tree)
{
treeCollection.Remove(tree);
}
}
}
/**//*
* 树工厂
*/
namespace DesignPattern.Composite
{
public class TreeFactory
{
public static ITree GetTree()
{
return (ITree)Assembly.Load("DesignPattern.Composite").CreateInstance("DesignPattern.Composite" + "." + System.Configuration.ConfigurationSettings.AppSettings["TreeName"].ToString());
}
}
}
/**//*
* 客户程序
*/
namespace DesignPattern.Composite
{
public class TreeClient
{
ITree tree;
public TreeClient()
{
tree = TreeFactory.GetTree();
}
public void ProcessTree()
{
// 客户代码依赖抽象接口
tree.Process();
}
}
}
安全性与透明性
组合模式中必须提供对子对象的管理方法,不然无法完成对子对象的添加删除等等操作,也就失去了灵活性和扩展性。但是管理方法是在Component中就声明还是在Composite中声明呢?
一种方式是在Component里面声明所有的用来管理子类对象的方法,以达到Component接口的最大化。目的就是为了使客户看来在接口层次上树叶和分支没有区别——透明性。但树叶是不存在子类的,因此Component声明的一些方法对于树叶来说是不适用的。这样也就带来了一些安全性问题。
另一种方式就是只在Composite里面声明所有的用来管理子类对象的方法。这样就避免了上一种方式的安全性问题,但是由于叶子和分支有不同的接口,所以又失去了透明性。
《设计模式》一书认为:在这一模式中,相对于安全性,我们比较强调透明性。对于第一种方式中叶子节点内不需要的方法可以使用空处理或者异常报告的方式来解决。
要点:
1、本模式采用树形结构来实现普遍存在的对象容器,从而将“一对多” 的关系转化为“一对一”的关系,使得客户代码可以一致地处理单个对象和对象容器,而无需关心处理的是单个对象还是组合的对象容器。
2、将“客户代码与复杂的对象容器结构”解耦是本模式的核心思想,解耦之后,客户代码将与纯粹的抽象接口——而非对象容器的复杂内部实现结构——发生依赖关系,从而能够应对变化。
3、本模式中,将单个对象不具有的操作的(如Add和Remove)定义于接口或抽象类中,还是组合对象中,需要从透明性和安全性两方面平衡考虑。应用此模式,更强调透明性,所以有可能违背面向对象的“单一职责”原则。
4、本模式在具体实现中,可以让父对象中的子对象反向追溯;如果父对象有频繁的遍历需求,可使用缓存来改善性能。
应用:ASP.NET子父控件关系。
场景:以树为例,叶子为最低级原子节点,树为容器,可以包括子树和叶子。需要使客户程序对树和叶子的处理一致,保持透明性,而不需要关心处理的是树还是叶子。
适用环境:
你想表示对象的部分-整体层次结构。
你希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
Composite好处:
1.使客户端调用简单,客户端可以一致的使用组合结构或其中单个对象,用户就不必关系自己处理的是单个对象还是整个组合结构,这就简化了客户端代码。
2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。
结构:
[img]http://www.cnblogs.com/images/cnblogs_com/charly/DesignPatternNote/Composite.gif[/img]
代码实现
namespace DesignPattern.Composite
{
public interface ITree
{
void Process();
void Add(ITree tree);
void Remove(ITree tree);
}
public class Leaf : ITree
{
public void Process()
{
}
public void Add(ITree tree)
{
throw new Exception("叶子不支持该方法!");
}
public void Remove(ITree tree)
{
throw new Exception("叶子不支持该方法!");
}
}
public class Tree : ITree
{
IList<ITree> treeCollection = null;
public void Process()
{
foreach (ITree tree in treeCollection)
{
tree.Process();
}
}
public void Add(ITree tree)
{
treeCollection.Add(tree);
}
public void Remove(ITree tree)
{
treeCollection.Remove(tree);
}
}
}
/**//*
* 树工厂
*/
namespace DesignPattern.Composite
{
public class TreeFactory
{
public static ITree GetTree()
{
return (ITree)Assembly.Load("DesignPattern.Composite").CreateInstance("DesignPattern.Composite" + "." + System.Configuration.ConfigurationSettings.AppSettings["TreeName"].ToString());
}
}
}
/**//*
* 客户程序
*/
namespace DesignPattern.Composite
{
public class TreeClient
{
ITree tree;
public TreeClient()
{
tree = TreeFactory.GetTree();
}
public void ProcessTree()
{
// 客户代码依赖抽象接口
tree.Process();
}
}
}
安全性与透明性
组合模式中必须提供对子对象的管理方法,不然无法完成对子对象的添加删除等等操作,也就失去了灵活性和扩展性。但是管理方法是在Component中就声明还是在Composite中声明呢?
一种方式是在Component里面声明所有的用来管理子类对象的方法,以达到Component接口的最大化。目的就是为了使客户看来在接口层次上树叶和分支没有区别——透明性。但树叶是不存在子类的,因此Component声明的一些方法对于树叶来说是不适用的。这样也就带来了一些安全性问题。
另一种方式就是只在Composite里面声明所有的用来管理子类对象的方法。这样就避免了上一种方式的安全性问题,但是由于叶子和分支有不同的接口,所以又失去了透明性。
《设计模式》一书认为:在这一模式中,相对于安全性,我们比较强调透明性。对于第一种方式中叶子节点内不需要的方法可以使用空处理或者异常报告的方式来解决。
要点:
1、本模式采用树形结构来实现普遍存在的对象容器,从而将“一对多” 的关系转化为“一对一”的关系,使得客户代码可以一致地处理单个对象和对象容器,而无需关心处理的是单个对象还是组合的对象容器。
2、将“客户代码与复杂的对象容器结构”解耦是本模式的核心思想,解耦之后,客户代码将与纯粹的抽象接口——而非对象容器的复杂内部实现结构——发生依赖关系,从而能够应对变化。
3、本模式中,将单个对象不具有的操作的(如Add和Remove)定义于接口或抽象类中,还是组合对象中,需要从透明性和安全性两方面平衡考虑。应用此模式,更强调透明性,所以有可能违背面向对象的“单一职责”原则。
4、本模式在具体实现中,可以让父对象中的子对象反向追溯;如果父对象有频繁的遍历需求,可使用缓存来改善性能。