有趣而有益的「管道模式」——電商支付用例

我想分享一個我最喜歡的、屢試不爽的設計模式——「管道模式」。所謂的「管道模式」，能夠將其想象成一個「傳輸帶」，或者「生產線」，它們傳遞一個東西，每一步進行相應操做，而後再傳給下一環。在編程裏，就是拿起一個實例對象，進行必要操做或修改，而後再傳給下一個類，如此傳下去。

能夠想象這麼一個訂單處理的電商邏輯：

1. 用戶下單了
2. 支付邏輯處理了支付
3. 訂單記錄，或者發貨單生成了，併發送給了用戶
4. 訂單發送到了你的ERP系統中了,交付生產了
5. 訂單物品打包後發貨了
6. 用戶收到了一封感謝信

雖然藉助於某些狀態機（state-machine，可大體理解成管理狀態的機器系統），這整個流程會更好處理些，可是這期間，很顯然展現出了一個「管道」、「流程」或「步驟」概念。

在這些全部的步驟或管道中，有一個基本的常量——這個訂單，它被傳遞到了這個過程的每一步，直到最後處理完。

若是你以前搞過相似的邏輯，那麼十有八九你會在你的好比說Order.php裏，搞相似的這麼一堆亂糟糟的代碼：

if ($order->getStatus() === 'success') {
    $this->getErpAdapter()->sendOrder($order);
}
// 此處省略了一百個if判斷
複製代碼

這樣的代碼，要理解它，你就得一行行的緊盯着看，又亂又費時間，讓人沒心情看完。

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

任何一個傻子，均可以寫出能讓計算機執行的代碼；可是隻有好的程序員，才能寫出讓人看得懂的代碼。

——Martin Fowler

這是我喜歡的一個引用。那麼如今，看看下面的代碼：

$pipeline = (new Pipeline)
    ->pipe(new createOrder)
    ->pipe(new processPayment)
    ->pipe(new sendInvoice)
    ->pipe(new exportOrder);
$pipeline->process($order);
複製代碼

如今還會有人抱怨「可讀性」嗎？不會了吧。

這樣來寫，一樣也讓你在「可測試性」上，以及單一職責原則上，得到巨大勝利——由於你如今每一塊代碼只作一件事兒，或者相關的兩件也行，而後就傳給下一個類了，職責很是簡單清晰。這樣整個流程的每一步都是可測試的，均可以輕易mock，甚至整個的管道流程也是可測試的。

好了，因爲本文較長，剩下的請移步咱們原文發佈處閱讀，如下是剩下的目錄結構

原文連接： www.pilishen.com/posts/the-p…