面向行为编程

引言

实际项目中，经常面临伴随着新需求的不断叠加，系统代码不断出现了耦合了各种需求的语句，逐渐发展出了如下代码，当然这些代码可能出现在不同的模块中，很难读懂到底ABCDEF的需求实现是否正确了。

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(蝙蝠 || 鲸鱼){
     哺乳（）;
}

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

通过变化分离的想法进行思考，会发现不变的是生物的行为，变化的是物种和行为的映射，通过对变化（物种和行为映射）进行抽象化处理，代码变为如下样子：if中的判断进行了抽象化

if(能飞()){
     飞();
}
if(能游泳()){
     游泳（）;
}
if(能肺呼吸()){
     肺呼吸（）;
}
if(能鳃呼吸){
     鳃呼吸();
}
if(能哺乳()){
     哺乳（）;
}

抽象化的映射关系通过配置化实现，新加入业务的时候，只要修改配置就可以。配置如下：

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

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