前面说到可以通过数据在执行时控制程序的行为。那么在实践中有什么用处?
一个例子
比如我们在产品版有一个标准的流程 A -> B -> C ->D ->E。
这时候在项目甲中,表示不需要经过流程B 只需要A -> C -> D-> E。
但是在项目乙中,不需要经过流程C 只需要A -> B -> D-> E。
那么一个常见的解决方案就是加配置项。
加配置项的话呢 有两种加法,一种是根据是否需要某个流程来加,一种是根据项目来加。
根据流程加配置项
因为例子中流程的改动比较小,我只需要加两个配置项 IsNeedB IsNeedC 就可以轻松兼容。
那么我的整个流程就变成了 A -> IsNeedB ? B : "" -> IsNeedC ? C: "" -> D ->E。
在不同的项目中根据实际使用情况来配置这两个配置项即可。
但是根据流程加配置项有两个弊端:
假如在项目丙中,需要增加一个特殊的流程F。这时候根据流程加配置项的话呢,就必须把这个特殊的流程F引入到产品的标准流程中。 并且在所有其他项目中都必须添加这个配置项以不经过F流程。(甚至在所有其他毫不相干的项目中,都要执行一次判断是否需要F流程!)
假如在项目丁中,需要的流程顺序变了,需要是A -> C -> B -> D -> E。那么之前的IsNeedX的配置方式不再管用了,我们必须再另外加一种流程的配置项 IsB->C ? B->C : C->B 。
我想写到这里大家应该发现了。根据流程加配置项的复杂度增加的太快了。配置项加在代码中会有互相嵌套。假如我有十个项目,那么起码会有十个不同的配置项,并且我在某个项目中配置时,另外九个是与本项目毫不相干的其他项目的配置项! 但是仍然要全部配置正确才能保证整个流程正确。
这不合理。
根据项目加配置项
根据项目加配置项就简单多了,只需要加一个配置项: ProjectType。
那么代码大致上是这样的:
switch(ProjectType){
case ProjectType.项目甲: A -> C -> D-> E;break;
case ProjectType.项目乙: A -> B -> D-> E;break;
case ProjectType.项目丙: A -> B -> C -> D -> E -> F;break;
case ProjectType.项目丁: A -> C -> B -> D -> E;break;
default :A -> B -> C ->D ->E;
}
好的这样一来配置项也只需要一个,再多的项目配置起来也不会增加配置的复杂度。
但是仍然有一个问题:如果再来新项目,流程有变动时,我必须修改代码,把该项目需要的流程加入switch case中。即使没有新加特殊的流程F。对于项目而言,重新修改代码,编译,打包,往往意味着需要重新经过测试,发布。这样整个流程就非常长了。在不新增特殊流程的情况下,仅仅修改已有的流程不需要修改代码可以吗?
改进
显而易见的我们可以把流程的数据之间加入配置项中。
比如我们用这样的一个配置项 ProjectData。配合之前的接口设计。
在产品中。缺省的Data可能是这样的
var data = ["do", [
["A", [{}]],
["B", [{}]],
["C", [{}]],
["D", [{}]],
["E", [{}]],
]];
而在项目甲中,我们仅仅需要把配置项修改为:
var data = ["do", [
["A", [{}]],
["C", [{}]],
["D", [{}]],
["E", [{}]],
]];
到了项目乙中,同样修改下配置项就行:
var data = ["do", [
["A", [{}]],
["B", [{}]],
["D", [{}]],
["E", [{}]],
]];
仅仅当项目丙中需要新加一个流程F时,才需要修改代码,把F流程的功能实现。测试时也可仅单独测试F流程的功能。
这样一来 ,假如再来一个新的项目 仅仅需要A->E的流程。那么配置起来再方便不过了。
var data = ["do", [
["A", [{}]],
["E", [{}]],
]];
无需再新加任何配置项或者修改代码。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。