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

·  阅读 196

引言

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

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(蝙蝠 || 鲸鱼){
     哺乳();
}
复制代码

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

面向实体编程.png

面向行为方式

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

if(能飞()){
     飞();
}
if(能游泳()){
     游泳();
}
if(能肺呼吸()){
     肺呼吸();
}
if(能鳃呼吸){
     鳃呼吸();
}
if(能哺乳()){
     哺乳();
}
复制代码

如上代码只保留领域行为,很容易阅读吧。生物行为和物种的关系通过如下的配置表来实现,新加入物种的时候,只要修改配置就可以。配置如下:

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

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

面向行为.png

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改