}
// 调用数据访问层
$dbTask = new LWordDBTask();
$dbTask->append($newLWord);
// 给用户加分
$score = getUserScore($userName);
$score = $score + 5;
saveUserScore($userName, $score);
// 给用户升级
if (($score % 1000) == 0) {
$level = getUserLevel($userName);
$level = $level + 1;
saveUserLevel($userName, $level);
}
}
};
随着需求的增多，我们需要不断的修改中间服务层代码。但是你应该不难发现，需求越多中间服务层代码也就越多越庞大！最后会导致即便我们使用三层结构的开发模式，也还是没有有效的降低工程难度！另外就是应需求的变化而修改中间服务代码以后，需要重新测试所有代码，而不是有效的测试新增代码……
其实让我们仔细分析一下这个留言板代码，我先要提出一个主业务逻辑和次业务逻辑的概念。无论怎样，把留言内容存入到数据库，这是业务逻辑的主干！这个就是主业务逻辑！这部分没有随着需求的增加而修改。至于在存入数据库之前要进行权限校验，要进行内容检查，存入数据库之后要给用户加分，然后给用户升级，这些都是前序工作和扫尾工作，都是次业务逻辑！主业务逻辑几乎是一成不变的，次业务逻辑变化却非常频繁。为了提高代码的可读性和可维护性，我们可以考虑把这些次业务逻辑放到别的地方，尽量不要让它们干扰主业务逻辑。主业务逻辑专心干自己该干的事情好了，至于别的任何事情，主业务逻辑一概都不闻不问！那么我们的代码就可以写成这样，如代码6所示：
// 代码 6, 将主业务逻辑和次业务逻辑分开
// 中间服务层
class LWordServiceCore implements ILWordService {
// 添加留言
public function append($newLWord) {
// 添加留言前
beforeAppend($newLWord);
// 调用数据访问层
$dbTask = new LWordDBTask();
$dbTask->append($newLWord);
// 添加留言后
behindAppend($newLWord);
}
};
我们可以把权限判断代码和留言内容文本过滤代码统统塞进beforeAppend函数，把用户积分代码塞进behindAppend函数，这样就把次业务逻辑从主业务逻辑代码中清理掉了。主业务逻辑知道有个“序曲”函数beforeAppend，有个“尾声”函数behindAppend，但是在序曲和尾声函数中具体都做了什么事情，主业务逻辑并不知道，也不需要知道！当然实际编码工作并不那么简单，我们还要兼顾产品部和市场部更多的需求变化，所以最好能实现一种插件方式来应对这种变化，但是仅仅依靠两个函数beforeAppend和behindAppend是达不到这个目的～
想要实现插件方式，可以建立接口！使用接口的好处是可以将定义和实现隔离，另外就是实现多态。我们建立一个留言扩展接口ILWordExtension，该接口有两个函数beforeAppend和behindAppend。权限校验、内容检查、加分这些功能可以看作是实现ILWordExtension接口的三个实现类，主业务逻辑就依次遍历这三个实现类，来完成次业务逻辑。如图1所示：
