Heim  >  Artikel  >  Backend-Entwicklung  >  对一般订单生成过程的抽象过程的思考

对一般订单生成过程的抽象过程的思考

WBOY
WBOYOriginal
2016-06-06 20:35:141389Durchsuche

对一般订单生成过程的抽象过程的思考

一般的电子商务网站,都会有生成订单这个业务,最近自己也正好负责的是这块业务,所以自己也好好理了理这块的业务。
其实不管是订单部分的业务代码,还是其它部分的业务代码。一个不小心就会写成流程式的代码。写成流程式的代码,我个人觉得主要有一下几点:

  1. 代码里面充满了很多注释,注释按照步骤写下来.1,2,3,4,5,6.
  2. 代码没有层次性,具体的层次性可以参照关于业务分层。还有一个就要设计的就是抽象一致性
  3. 代码没有模块性,具体的体现就是一件事,会在很多地方穿插进行。举个例子,订单里面会涉及到邮费,计算邮费的值会遍布在整个订单流程。这样的坏处就是,出了问题以后,一下子定位不到问题出现在哪里。

订单的流程,按照普通的过程来说。会有生成一下几步

  1. 计算优惠(包括活动,红包等)
  2. 计算邮费
  3. 生成支付信息
  4. 生成订单
  5. ......

先来分析下订单的整个流程,发现它其实是一个黑盒。页面传了一批参数过来以后,我们封装了一下,然后丢进这个黑盒,出黑盒里面出来的是最后生成的订单实体。
我们首先对整个过程建立一个最高层的抽象。即:

<code>    public interface Builder{
        public void do(Context context);
    }
</code>

这样子,每一部分都在做自己的事情,如果涉及到和其他模块进行通信的话,可以借助这个上下文Context。这样子就可以在很大程度上实现模块化。至于里面更小的抽象,我们还可以根据不同的层次抽象出更多的Builder来让我们的代码可以模块化。
至于怎么讲这些Builder串联起来。一开始,我觉得这个过程可以看做是一个订单实体的构建过程,所以一开始我用的是建造者模式,但是发现把这些东西都放在一个类中,在维护上是在是太费力气,所以后来我就用了责任链模式的变形(类似struts里面的拦截器)。

经过这样子的抽象以后,你会发现。每个类都在做自己的事情,而且不用写大量的注释来注释整个流程。关于流程的扩展的话,因为整个架子在那里,所以如果是扩展流程的话,那么在已有的链上加一个节点就OK了,如果是业务内部的扩展的话,只需要在相应的类里面扩展,不会涉及到其他的类。

这里写到了关于建造在模式责任链模式,我准备下一个提问中说说关于设计模式的一些事。
希望大家可以指点。

回复内容:

对一般订单生成过程的抽象过程的思考

一般的电子商务网站,都会有生成订单这个业务,最近自己也正好负责的是这块业务,所以自己也好好理了理这块的业务。
其实不管是订单部分的业务代码,还是其它部分的业务代码。一个不小心就会写成流程式的代码。写成流程式的代码,我个人觉得主要有一下几点:

  1. 代码里面充满了很多注释,注释按照步骤写下来.1,2,3,4,5,6.
  2. 代码没有层次性,具体的层次性可以参照关于业务分层。还有一个就要设计的就是抽象一致性
  3. 代码没有模块性,具体的体现就是一件事,会在很多地方穿插进行。举个例子,订单里面会涉及到邮费,计算邮费的值会遍布在整个订单流程。这样的坏处就是,出了问题以后,一下子定位不到问题出现在哪里。

订单的流程,按照普通的过程来说。会有生成一下几步

  1. 计算优惠(包括活动,红包等)
  2. 计算邮费
  3. 生成支付信息
  4. 生成订单
  5. ......

先来分析下订单的整个流程,发现它其实是一个黑盒。页面传了一批参数过来以后,我们封装了一下,然后丢进这个黑盒,出黑盒里面出来的是最后生成的订单实体。
我们首先对整个过程建立一个最高层的抽象。即:

<code>    public interface Builder{
        public void do(Context context);
    }
</code>

这样子,每一部分都在做自己的事情,如果涉及到和其他模块进行通信的话,可以借助这个上下文Context。这样子就可以在很大程度上实现模块化。至于里面更小的抽象,我们还可以根据不同的层次抽象出更多的Builder来让我们的代码可以模块化。
至于怎么讲这些Builder串联起来。一开始,我觉得这个过程可以看做是一个订单实体的构建过程,所以一开始我用的是建造者模式,但是发现把这些东西都放在一个类中,在维护上是在是太费力气,所以后来我就用了责任链模式的变形(类似struts里面的拦截器)。

经过这样子的抽象以后,你会发现。每个类都在做自己的事情,而且不用写大量的注释来注释整个流程。关于流程的扩展的话,因为整个架子在那里,所以如果是扩展流程的话,那么在已有的链上加一个节点就OK了,如果是业务内部的扩展的话,只需要在相应的类里面扩展,不会涉及到其他的类。

这里写到了关于建造在模式责任链模式,我准备下一个提问中说说关于设计模式的一些事。
希望大家可以指点。

通过apple-touch-startup-image设置了启动

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn