老生常谈:组合模式 02 安全性, 开发者, 接口

samwalton

安全性:
只在Composite里面声明所有的用来管理子类对象的方法。这样就避免了安全性问题，但是由于Leaf和Composite有不同的接口，所以又失去了透明性。下面是类图:



这两种实现方式各有所长，开发者可以根据自己的实际情况来取舍，本人推荐透明性，因为它对客户端来说是最简单的,它的安全性问题完全可以用些空处理等方式来避免.

我在这里用一个增送礼物的需求来说明一下组合模式的应用.
说明：此例子不太符合实际，只是为了说明组合模式的应用生搬的一个例子。在实际中并不会出现这样的情况：
把第一名得到的五个奖品分五次发送。
需求:网站需要推行一个有奖活动,中奖的用户可以根据名次来得到相应的奖品.例如,奖项分为五个:
第五名:一个奖品.
第四名:两个奖品
第三名:三个奖品
第二名:四个奖品
第一名:五个奖品
程序要实现的就是根据名次来发送相应的礼品包,同时记录些相关信息,例如礼品包中的礼物信息以后中奖人信息等等.
一个奖品的发送是最简单的,因为信息单一,一个奖品一个用户,录入数据库就OK了,名次越前程序要记录的东西就越多,当在处理第一名时，要判断是单个奖品还是多个奖品（因为单个奖品和礼品包在业务处理上会有不同）.这样在客户端调用的时候往往会产生大量的代码.而且最可怕的是这种代码依赖于奖品发送的具体业务处理类。能不能让客户调用的时候不去费心的判断奖品的类型，而是直接调用一个统一的方法，例如sendGift(),这时就要用到组合模式了。

例子的类结构图




礼物与中奖人信息我用一个实体类来记录 giftAndUserInfo,它包含礼物名称及中奖人用户名.
Code
抽象类sendGiftComponent,它定义了发送礼物的方法以及管理子类的方法Add,Romove.
Code
发送单个礼物的Leaf,这个类实现单个礼物的发送
Code
发送礼物包的Composite,它负责把多个礼物打包成一个整体,然后一个一个发送出去.
Code
客户端调用代码:
本例只为说明问题,只是将要发送的礼品包里面的全部礼品名称以及中奖人信息输出.例子是调用的是发送一个第二名礼品包.
Code
输出结果:

优点:
1:以上的代码中,客户端不关心要处理的是单个礼物还是礼品包,统一对待,使客户端调用简单化.

2:如果礼品包中要增加或者是删除一个礼物,都无需更改代码结构,这符合"开闭原则".

总结：

无论模式如何强大，用与不用取决于开发人员，如果你有足够的理由不采用那么你可以不屑此模式。