算法设计应该依赖抽象而不是业务
2007-04-22 10:54
162 查看
很多时候,算法的设计是归属于详细设计阶段的。一些公司甚至都没有设计而直接编码。这些往往导致很多算法的实现都混杂在业务模块中。典型的特点是,这些算法会依赖于业务实体的某些属性的实现。
举一个简单的例子,我曾经做过一个项目中,遇到一个排序功能:分部整理。这个排序比我们以往所学的排序不一样,所以很多人都不将它作为算法来看待,而是直接做为业务逻辑功能进行实现。
排序的基础数据是清单(一个业务实体)的编码
排序的依据是清单编码在检索库中的顺序
如果你细心的话,就会发现,其实上面的两条,和我们的一般排序方法实现起来是一样的!
比较对象:字符串、整数、浮点数等等
比较方法:比较大小、大小写敏感等等
根据上面的分析,设计这个算法的过程中,应该将清单编码列表作为一个参数传入。注意,这里是是编码列表,而不是实体对象列表。最好的情况是,重新声明一个数组。这样就能将算法和业务实体隔离开。另外,清点编码的检索作为一个排序的比较回调函数。这样,比较的业务也可以和算法分开。最后,算法其实也不需要实现了,因为这是通用的。
大家一定注意到了,上面的设计过程中,一直在强调接口编程。我们的算法如果不依赖于业务,就必须提取出来一个独立的接口。说到接口,我想多说几句,因为很多人在这里有一个误区。
我们在业务代码中,有很多接口。这些接口一般都是业务接口。是因为业务而不得不存在的接口。但是写得多了,很多人可能会将这些和我们所提倡的独立的接口想混淆。让他依赖接口编程,他就直接将业务对象实现的接口引入进来。这种方法的直接后果就是,这部分代码,别的地方不可能再用了!
依赖于业务抽象的算法实现,是有很多好处的:
算法简洁、易于阅读
层次清楚、易于扩充
抽象独立、易于复用
对于服用,不光是可以给别人服用,很多时候,就是因为抽象的好,因而可以使用到一些基础算法。复用代码的好处,就是不需要额外的维护啊。
算法设计,是应该高于业务设计的。这样才能体现算法的优势。否则石头一旦沉入大海,我们再也不能看清楚他们了。
举一个简单的例子,我曾经做过一个项目中,遇到一个排序功能:分部整理。这个排序比我们以往所学的排序不一样,所以很多人都不将它作为算法来看待,而是直接做为业务逻辑功能进行实现。
排序的基础数据是清单(一个业务实体)的编码
排序的依据是清单编码在检索库中的顺序
如果你细心的话,就会发现,其实上面的两条,和我们的一般排序方法实现起来是一样的!
比较对象:字符串、整数、浮点数等等
比较方法:比较大小、大小写敏感等等
根据上面的分析,设计这个算法的过程中,应该将清单编码列表作为一个参数传入。注意,这里是是编码列表,而不是实体对象列表。最好的情况是,重新声明一个数组。这样就能将算法和业务实体隔离开。另外,清点编码的检索作为一个排序的比较回调函数。这样,比较的业务也可以和算法分开。最后,算法其实也不需要实现了,因为这是通用的。
大家一定注意到了,上面的设计过程中,一直在强调接口编程。我们的算法如果不依赖于业务,就必须提取出来一个独立的接口。说到接口,我想多说几句,因为很多人在这里有一个误区。
我们在业务代码中,有很多接口。这些接口一般都是业务接口。是因为业务而不得不存在的接口。但是写得多了,很多人可能会将这些和我们所提倡的独立的接口想混淆。让他依赖接口编程,他就直接将业务对象实现的接口引入进来。这种方法的直接后果就是,这部分代码,别的地方不可能再用了!
依赖于业务抽象的算法实现,是有很多好处的:
算法简洁、易于阅读
层次清楚、易于扩充
抽象独立、易于复用
对于服用,不光是可以给别人服用,很多时候,就是因为抽象的好,因而可以使用到一些基础算法。复用代码的好处,就是不需要额外的维护啊。
算法设计,是应该高于业务设计的。这样才能体现算法的优势。否则石头一旦沉入大海,我们再也不能看清楚他们了。
相关文章推荐
- 算法设计应该依赖抽象而不是业务
- 算法设计应该依赖抽象而不是业务
- 算法设计应该依赖抽象而不是业务
- 算法设计应该依赖抽象而不是业务
- API不是从业务抽象出来的(2)_举例说明
- 开发一个业务逻辑复杂的系统,应该怎么样设计才能使项目的扩展性更好
- 算法设计课思考题;矩阵着色;回溯算法;抽象成图;
- 数据结构:有人设计以下算法用于删除整数顺序表L中所有值在[x,y]范围内的元素,该算法显然不是高效的,请设计一个同样功能的高效算法。
- 4程序员小飞原计划三天完成某个任务,现在是第三天的下午,他马上就可以做完。但是在实现功能的过程中,他越来越意识到自己原来设计中的弱点,他应该采取另一个办法,才能避免后面集成阶段的额外工作。但是他如果现在就改弦更张,那势必要影响自己原来估计的准确性,并且会花费额外的时间,这样他的老板、同事也许会因此看不起他。如果他按部就班地按既定设计完成,还要花更多时间在后续集成上,但那就不是他个人的问题了,怎么办
- [项目设计]考虑抽象出业务逻辑
- 建议149:依赖抽象而不是实现
- c++基础知识,有现成的函数不用,非的自己设计算法,这不是坑爹吗?
- 策略设计模式:把可变的行为抽象出来形成一个算法簇
- 设计接口时应该如何设计业务异常?
- 【翻译】eXpressAppFramework QuickStart 业务模型设计(九)——实现依赖引用属性
- 折半查找实现算法二(递归办法)PS:编译后有一个warning,但不影响结果,代码设计上应该还有些问题
- c++基础知识,有现成的函数不用,非的自己设计算法,这不是坑爹吗?
- 设计接口时应该如何设计业务异常?
- 设计模式之 抽象工厂 封装业务逻辑层和Dao层
- API不是从业务抽象出来的(1):设计思维