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