以流程设计为向导的现实代码(引以为戒!)

我在上一篇blog中写了 以流程为向导和以数据为向导的设计,有点抽象。今天在检查客户提出的一个性能问题时,发现这个问题的根源其实就是以流程为向导的设计导致的。出于保密的考虑,我下面用伪代码的形势把那个设计表现出来。

在客户的框架中,提供了一个接口方法:
public Customers[] SearchCustomers(string ids);
这个方法的调用会消耗较多的时间。客户在他们的跟踪器中发现在一个查询操作中,这个方法被调用了两次。显然如果改进设计,让它只被调用一次,会对系统的性能有很大的提升。

如果从流程的角度来考虑,这种设计是合理的。
private void LoadObjects()
{
.........................

CommonUtility.CheckClientInfo(clientIDs);//这是一个静态方法,用于检查customer信息

CheckClientOnView(res);//这是一个成员方法,用于检查 customer在当前实例中的状态。

............................
}

上面两个方法中,都调用了SearchCustomers方法。
为什么说上面这段代码是以流程为向导,因为customer数据本身并没有方法来维护其状态,customer状态的判断是以流程的要求来设计的。即业务流到哪里,对customer数据状态的判断就到哪里。这样,获取两份customer数据来判断是完全合理的。

但实际上,这种设计代码来很多的问题,上面就是其中的一种。

关于这个问题,我很希望能够和更多的朋友讨论。我是一个很认真的程序员,我很希望把这个问题搞清楚
联系QQ:64528619;MSN:czy@vip.163.com
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

明天好,会的

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值