使用面向行为编程解除项目耦合
引言
实际项目中,我们经常使用面向实体编程。程序中我们会书写这样的逻辑:如果是某个业务实体,就执行某个逻辑。伴随着新需求的不断涌现,系统代码不断出现了耦合了各种需求的语句。这些判断语句代码会散列在不同的模块中,代码逐渐演变为人无法看懂的程度。
本文以一个实际的例子来说明这个问题的形成原因,并给出解决方案。
项目实例
项目背景是我们要编写一个世界系统(类似黑客帝国里的世界)。想象一下,我们负责生物模块的编写。需求 A:如果是燕子就会飞;如果是鲤鱼,就会游泳…。很自然的,我们写下下面的代码。
伴随着新物种需求的出现,鸽子,蝙蝠…,我们的程序演进为下面的样子。
这种写法我称为面向实体的编程,很符合人的自然想法。什么实体能做什么。一开始好像很简单,燕子和鸽子都是鸟类,能飞。伴随跨界生物的出现,比如鲸鱼虽然很多行为是鱼类的行为,确实用肺呼吸。比如蝙蝠虽然有很多鸟类的行为,却会哺乳。系统已经很难读懂,并且很难维护。如果不断加入新的物种,代码基本就不能看了。(我们真实的业务系统并不会比这里的例子更合理,真实系统很多可能都是类似蝙蝠和鲸鱼的这种怪物)。
通过变化和不变分离的想法进行思考。会发现不变的是生物的行为,变化的是物种和行为的映射。通过对变化(物种和行为映射)进行抽象化处理,代码变为如下样子。IF 判断只依赖于领域行为。
如上代码只保留领域行为,行为和执行实体的关系通过如下的配置表来实现
![](https://static001.geekbang.org/infoq/75/7527b3c0c7f2ebf9ae81ceff49137238.png)
这种写法我称之为面向行为编程,程序代码依赖于是否具有某个行为,而不是依赖某个实体。实体和行为的关系是配置化的。
当然也可以简单的把这个过程理解为配置化,程序真正面对的是去分析领域模型的内在真实行为,可以参考 DDD。
本文相对比较初级,其实只是说明代码中不该把逻辑与执行实体的关系散列各处,你可以从各个视角去观察本例,可以有多种解读。
版权声明: 本文为 InfoQ 作者【sdutyq】的原创文章。
原文链接:【http://xie.infoq.cn/article/b4669a570159496aa1dc78ef1】。文章转载请联系作者。
评论