所有的例子均来源与实际开发项目
本节介绍组合模式的使用–商品结果排序评分系统
首先还是重复一下：设计模式是思路，而不是一味套用，如果业务场景和功能需求恰好吻合，那最好不过；如果有偏差，一定要具体情况具体分析，更具实际场景选择合适的模式类型（注意，是类型，并不特定指某种模式，有的时候一个场景多种模式都可以做）
本节所举得例子为商品结果排序评分系统，也就是很多项目中，在比较重要任何事物查询完毕后，会有一个排序过程，比如在淘宝上搜索完商品后那个商品列表的排序过程。而且其复杂度当然远远超过数据中SQL语句可以完成的程度（当然不排除有公司把逻辑直接写入到存储过程中，但是这种情况不做探讨），所以需要一个完整的评分系统来对结果进行排序，高分排前，低分置后。
Ⅰ 【分析阶段】———————————
a.首先分析业务功能（功能需求）：类似于上面所述的，就是对结果进行排序，高分前，低分后。再深入到实现代码层面，就是多层次的权重分数计算了，这个类似大家学校里，最终期末总评分，30%平时分，70%考试分一个道理；
b.然后分析扩展性（非功能需求）：主要变化会在哪？当然毫无疑问就是：
好了，结合上面两点，你会发现，这有点一个“树”的意思了，不是么？请看下面这个图
左边一个一般的树图，类似资源管理器的列表单，这个摘自《研磨设计模式》P392页的组合模式章节配图
右边是我刚刚所说的业务功能的分析图，一个商品的综合总评分分为“商品评分”与发布该商品的“店铺评分”，分别占总评分的80%与20%，然后其下面又分别有子评分标准，以此类推，图片应该不难理解
这个时候，当然需要你对组合模式还是有了了解，至少要有印象，知道有这么一个模式可以作为备选，然后一比较，发现确实也凑巧，这个例子非常符合组合模式，而且看起来至少目前不需要做太大改动，已经可以满足需求了。那就开始设计吧！
Ⅱ【设计阶段】——————————————————-
类图设计如下，以下图片中上半部分摘自《研磨设计模式》P396 图15.1 ，下面为我基于他的图进行的部分修改，即为我的组合模式的设计
是不是发现还是变化了不少，这就是我之前在第一篇文章设计模式–概述【请看清本质】中所提到的观点，不用在乎一些改变，而要关注设计模式的核心目标是否达到
好了，继续对上面的设计做一些说明：
身份对应：
具体实现，我结合代码示例进行说明：
/**
* 评分计算基类
* 这里我略掉了一些什么addChild,removeChild等方法的说明，这个大家需要自行加入
*/
public abstract class ScoreCalculator {
// list用于存放子类
// 至于我这里为什么还封装到了一个Entry里，只是完全出于业务考虑，因为既要放规则计算类，又要放入配置文件导入的权重参数
// 像这个就需要大家根据自己业务灵活处理
protected List scoreEntryList;
public int calculateScore(){
int totalScore = 0;
//先进行子节点的分数计算，对叶子节点来说，由于没有子节点，这个代码段就自然不会执行了
if(this.scoreEntryList!=null){
int[] scoreArray = new int[scoreEntryList.size()];
ScoreEntry entry = null;
for (int i =0; i < scoreEntryList.size(); i++) {
entry = scoreEntryList.get(i);
//这里调用子节点的calculateScore(),递归！，也就是组合模式的核心思想之一
scoreArray[i] = (int)(Math.round(entry.cal.calculateScore() * entry.weight));
totalScore += scoreArray[i];
}
}
//注意，这里就用了模板方法的思想，上面所做的一切都是不变的，就是计算子节点的分数然后汇总
//那统计完子节点的了，自己还要进一步做处理吧？毕竟有些简单的加减乘除就解决了，有些可还有复杂的逻辑
totalScore = moreCalculate(totalScore);
return totalScore;
}
//抽象方法，让子类自己去实现
protected abstract int moreCalculate(int currentTotalScore);
}
public class ScoreEntry {
//规则计算类
public ScoreCalculator cal;
//本规则在上一级规则中所占的比重(0~1)
public float weight;
//本规则在计算后的结果,整型(0~10000)
public int score;
}
/*
* 店铺分数计算规则，其还带有子类规则A1,A2
* 至于商品分数计算规则的思路就差不多了，这里就只举此一个
*/
public class ShopCalculator extends ScoreCalculator {
//..构造方法等等略
@Override
protected int moreCalculate(int currentTotalScore) {
//进行具体的操作，比如这些分数还要进一步结合店铺的某种其他信息做检查处理
//然后做相应的增减，最后返回数据至上一层，向上一层统计分数节点“呈递”自己的最终结果
currentTotalScore = doSth();
return currentTotalScore;
}
}不知道大家是否能够顺利理解，毕竟这个例子是实际项目，逻辑相对复杂，篇幅问题我也只能选择核心代码给出，所以难免会看着有点困难，没关系，重点看我有注释的那几行便可，若有问题可以回帖发问~
好了，继续还有一点收尾，那既然这棵树“种好了”，那怎么来使用呢？设计模式不仅仅要便于扩展，也要便于使用，那我们就来看看如何搭建起这个树结构，也就是上面画图中，那个Client怎么调用了
//首先提醒一句，大家在看上面第二幅图时，《研磨设计模式》书中图里有addChild方法，怎么样？想到了怎么建立树了吗？ //对吧，其实很简单，new出节点，然后通过addChild建立起双方的父子关系便可了 //总分统计 ScoreCalculator totalCal = new TotalCalculator(); //商品统计，数字是在上级中的所占权重 ScoreCalculator goodsCal = new GoodsCalculator(0.8); //店铺统计 ScoreCalculator shopCal = new ShopCalculator(0.2); //A1统计 ScoreCalculator a1Cal = new A1Calculator(0.3); //A2统计 ScoreCalculator a2Cal = new A2Calculator(0.7); ...（略） //好了，把相互的关系整理起来！ goodsCal.addChild(a1Cal); goodsCal.addChild(a2Cal); ... totalCal.addChild(goodsCal); totalCal.addChild(shopCal); //最后，执行计算就OK了！无穷的递归就在这一刻开始 int finalScore = totalCal.calculateScore();
Ⅲ【核查阶段】———————————————————–
好了，到这里为止，这个样例算是分析完了，只是还查了一点，什么呢？检查！
就是检查这个最终的开发结果是不是达到的之前的设计目的：
可见，目的都算是达到了，这个模式的使用就算是合格了！
在这里，大家发现我其中用上了模板模式，其实在这个以组合模式为核心的模块里里外外还包围着很多其他模式来进行辅助，这里我为了避免影响都没有写出来了，有点像变形金刚合体一样。这依旧说明了一点：
模式为思想，方法不固定，灵活变通使用才是硬道理！
欢迎访问我的主页，最新的文章我会首先发布在个人主页上：
原文地址：http://blog.csdn.net/yangxy81118/article/details/38710779
