使用面向行为编程解除项目耦合

引言

实际项目中，我们经常使用面向实体编程。程序中我们会书写这样的逻辑：如果是某个业务实体，就执行某个逻辑。伴随着新需求的不断涌现，系统代码不断出现了耦合了各种需求的语句。这些判断语句代码会散列在不同的模块中，代码逐渐演变为人无法看懂的程度。 if(需求A || 需求B){ doSometing1(); } if(需求B){ doSometing2(); } if(需求C || 需求F){ doSometing3(); } if(需求A || 需求E){ doSometing4(); } if(需求A || 需求M){ doSometing5(); } 本文以一个实际的例子来说明这个问题的形成原因，并给出解决方案。

项目实例

项目背景是我们要编写一个世界系统(类似黑客帝国里的世界)。想象一下，我们负责生物模块的编写。需求A：如果是燕子就会飞；如果是鲤鱼，就会游泳…。很自然的，我们写下下面的代码。

if(燕子){ 飞(); } if(鲤鱼){ 游泳(); } if(燕子){ 肺呼吸(); } if(鲤鱼){ 鳃呼吸(); } 伴随着新物种需求的出现，又来了新需求，鸽子，蝙蝠…，如果是鲸鱼，会游泳，用肺呼吸，有哺乳行为。如果是蝙蝠，会飞，有哺乳行为等等。我们的程序演进为下面的样子。 if(燕子 || 鸽子 || 蝙蝠){ 飞(); } if(鲤鱼 || 鲸鱼){ 游泳(); } if(鸽子 || 蝙蝠 || 鲸鱼){ 肺呼吸(); } if(鲤鱼){ 鳃呼吸(); } if(蝙蝠 || 鲸鱼){ 哺乳(); } 这种写法我称为面向实体的编程，很符合人的自然想法。什么实体能做什么。一开始好像很简单，燕子和鸽子都是鸟类，能飞。伴随跨界生物的出现，比如鲸鱼虽然很多行为是鱼类的行为，确实用肺呼吸。比如蝙蝠虽然有很多鸟类的行为，却会哺乳。系统已经很难读懂，并且很难维护。如果不断加入新的物种，代码基本就不能看了。(我们真实的业务系统并不会比这里的例子更合理，真实系统很多可能都是类似蝙蝠和鲸鱼的这种怪物)。下图表示面向实体的变成过程：

面向行为方式

通过变化和不变分离的想法进行思考。会发现不变的是生物的行为，变化的是物种和行为的映射。通过对变化(物种和行为映射)进行抽象化处理，代码变为如下样子。IF判断只依赖于领域行为。

if(能飞()){ 飞(); } if(能游泳()){ 游泳(); } if(能肺呼吸()){ 肺呼吸(); } if(能鳃呼吸){ 鳃呼吸(); } if(能哺乳()){ 哺乳(); } 如上代码只保留领域行为，很容易阅读吧。生物行为和物种的关系通过如下的配置表来实现，新加入物种的时候，只要修改配置就可以。配置如下：

| | 能飞 | 能游泳 | 能肺呼吸 | 能鳃呼吸 | 能哺乳 | | ---- | ---- | ------ | -------- | -------- | ------ | | 燕子 | 能 | 不能 | 能 | 不能 | 不能 | | 鸽子 | 能 | 不能 | 能 | 不能 | 不能 | | 蝙蝠 | 能 | 不能 | 能 | 不能 | 能 | | 鲤鱼 | 不能 | 能 | 不能 | 能 | 不能 | | 鲸鱼 | 不能 | 能 | 能 | 不能 | 能 |

这种写法我称之为面向行为编程，程序代码依赖于是否具有某个行为，而不是依赖某个实体或具体需求。实体和行为的关系是配置化的。