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

引言

实际项目中，我们经常使用面向实体编程。程序中我们会书写这样的逻辑：如果是某个业务实体，就执行某个逻辑。伴随着新需求的不断涌现，系统代码不断出现了耦合了各种需求的语句。这些判断语句代码会散列在不同的模块中，代码逐渐演变为人无法看懂的程度。

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(能鳃呼吸){     鳃呼吸();}if(能哺乳()){     哺乳();}

如上代码只保留领域行为，行为和执行实体的关系通过如下的配置表来实现

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

当然也可以简单的把这个过程理解为配置化，程序真正面对的是去分析领域模型的内在真实行为，可以参考 DDD。

本文相对比较初级，其实只是说明代码中不该把逻辑与执行实体的关系散列各处，你可以从各个视角去观察本例，可以有多种解读。