對一般訂單產生過程的抽象過程的思考
一般的電子商務網站,都會有產生訂單這個業務,最近自己也正好負責的是這塊業務,所以自己也好好理了理這塊的業務。
其實不管是訂單部分的業務代碼,還是其它部分的業務代碼。一個不小心就會寫成流程式的代碼。寫成流程式的代碼,我個人覺得主要有一下幾點:
- 代碼裡面充滿了很多注釋,注釋按照步驟寫下來.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設定了啟動