对一般订单生成过程的抽象过程的思考
对一般订单生成过程的抽象过程的思考
一般的电子商务网站,都会有生成订单这个业务,最近自己也正好负责的是这块业务,所以自己也好好理了理这块的业务。
其实不管是订单部分的业务代码,还是其它部分的业务代码。一个不小心就会写成流程式的代码。写成流程式的代码,我个人觉得主要有一下几点:
- 代码里面充满了很多注释,注释按照步骤写下来.1,2,3,4,5,6.
- 代码没有层次性,具体的层次性可以参照关于业务分层。还有一个就要设计的就是抽象一致性
- 代码没有模块性,具体的体现就是一件事,会在很多地方穿插进行。举个例子,订单里面会涉及到邮费,计算邮费的值会遍布在整个订单流程。这样的坏处就是,出了问题以后,一下子定位不到问题出现在哪里。
订单的流程,按照普通的过程来说。会有生成一下几步
- 计算优惠(包括活动,红包等)
- 计算邮费
- 生成支付信息
- 生成订单
- ......
先来分析下订单的整个流程,发现它其实是一个黑盒。页面传了一批参数过来以后,我们封装了一下,然后丢进这个黑盒,出黑盒里面出来的是最后生成的订单实体。
我们首先对整个过程建立一个最高层的抽象。即:
public interface Builder{
public void do(Context context);
}
这样子，每一部分都在做自己的事情,如果涉及到和其他模块进行通信的话,可以借助这个上下文Context。这样子就可以在很大程度上实现模块化。至于里面更小的抽象,我们还可以根据不同的层次抽象出更多的Builder来让我们的代码可以模块化。
至于怎么讲这些Builder串联起来。一开始,我觉得这个过程可以看做是一个订单实体的构建过程,所以一开始我用的是建造者模式,但是发现把这些东西都放在一个类中,在维护上是在是太费力气，所以后来我就用了责任链模式的变形(类似struts里面的拦截器)。
经过这样子的抽象以后,你会发现。每个类都在做自己的事情,而且不用写大量的注释来注释整个流程。关于流程的扩展的话,因为整个架子在那里,所以如果是扩展流程的话,那么在已有的链上加一个节点就OK了,如果是业务内部的扩展的话,只需要在相应的类里面扩展,不会涉及到其他的类。
这里写到了关于建造在模式和责任链模式,我准备下一个提问中说说关于设计模式的一些事。
希望大家可以指点。
回复内容：
对一般订单生成过程的抽象过程的思考
一般的电子商务网站,都会有生成订单这个业务,最近自己也正好负责的是这块业务,所以自己也好好理了理这块的业务。
其实不管是订单部分的业务代码,还是其它部分的业务代码。一个不小心就会写成流程式的代码。写成流程式的代码,我个人觉得主要有一下几点:
- 代码里面充满了很多注释,注释按照步骤写下来.1,2,3,4,5,6.
- 代码没有层次性,具体的层次性可以参照关于业务分层。还有一个就要设计的就是抽象一致性
- 代码没有模块性,具体的体现就是一件事,会在很多地方穿插进行。举个例子,订单里面会涉及到邮费,计算邮费的值会遍布在整个订单流程。这样的坏处就是,出了问题以后,一下子定位不到问题出现在哪里。
订单的流程,按照普通的过程来说。会有生成一下几步
- 计算优惠(包括活动,红包等)
- 计算邮费
- 生成支付信息
- 生成订单
- ......
先来分析下订单的整个流程,发现它其实是一个黑盒。页面传了一批参数过来以后,我们封装了一下,然后丢进这个黑盒,出黑盒里面出来的是最后生成的订单实体。
我们首先对整个过程建立一个最高层的抽象。即:
public interface Builder{
public void do(Context context);
}
这样子，每一部分都在做自己的事情,如果涉及到和其他模块进行通信的话,可以借助这个上下文Context。这样子就可以在很大程度上实现模块化。至于里面更小的抽象,我们还可以根据不同的层次抽象出更多的Builder来让我们的代码可以模块化。
至于怎么讲这些Builder串联起来。一开始,我觉得这个过程可以看做是一个订单实体的构建过程,所以一开始我用的是建造者模式,但是发现把这些东西都放在一个类中,在维护上是在是太费力气，所以后来我就用了责任链模式的变形(类似struts里面的拦截器)。
经过这样子的抽象以后,你会发现。每个类都在做自己的事情,而且不用写大量的注释来注释整个流程。关于流程的扩展的话,因为整个架子在那里,所以如果是扩展流程的话,那么在已有的链上加一个节点就OK了,如果是业务内部的扩展的话,只需要在相应的类里面扩展,不会涉及到其他的类。
这里写到了关于建造在模式和责任链模式,我准备下一个提问中说说关于设计模式的一些事。
希望大家可以指点。
通过apple-touch-startup-image设置了启动