設計模式系列·王小二需求歷險記(二)

0x1 原文再續，書接上回

上回說到，C哥憑藉本身多年的編碼經驗，欲傳授王小二絕世武功。
讓咱們書接上回。

0x2 來源於生活中的實例

看着王小二求知若渴的眼神，C哥開始對小二循循善誘。

「小二啊，咱們假設一個場景：假設你是一名講師，對於上完你課程的人，你要確保接下來，每一個人都知道他們下一節課去哪上。你如何去作呢？」

「嗯...我會在教室門口貼一張課表。課表上標明全部的課程以及課程對應的教室。讓學生們本身根據課表去找就好了。」

「不錯！小二很聰明嘛。可是若是把這個場景轉換爲程序實現，你起初可能就不會這樣設計了」。

「爲何？」小二睜大眼睛問道。

「由於面對需求，你首先想到的是過程化的解決辦法。好比在你設計發送消息的需求的時候，就是典型的過程化的思惟模式。上面那個講師的場景，你轉換成程序可能會這麼作：

1. 得到課堂上每一個人的名單;
2. 對於名單上的每一個人：
   a.查找他的下一節課程;
   b.查找他的下一節課程的地點;
   c.告訴他去哪裏上下一節課。

爲了實現上面的過程，你可能須要：

1. 得到課堂上每一個人名單的方法;
2. 得到每一個人課表的方法;
3. 得到每一個課程對應的教室的方法;
4. 告訴學生去相應教室上課的方法;
5. 一個控制程序爲每一個人作須要的步驟。」

王小二沉思了一會，如有所思的點點頭：「嗯，確實會這麼作」。

0x3 趁熱打鐵·責任的轉移

「小二啊，上面咱們說了兩種解決辦法。你以爲這兩種解決辦法哪一種更好些呢？」C哥問道。

「固然是第一種了，現實生活中我可不會傻到本身挨個去查學生的課表，地點，而後挨個告訴學生，那多累啊。」

「是啊，確定是第一種解決辦法好。其實，你仔細想一想，這兩種解決方式，最大的不一樣點是哪裏？」

「嗯...想不出來。」

「最大的不一樣點，是責任的轉移。你看第一種解決辦法，你只須要把課表張貼出來，學生本身去查詢課程、教室就好了。完成這件事情，既有老師的責任，也有學生的責任。而第二種方法，從頭至尾都須要老師去作，責任都在老師身上。」

「每一個人的責任邊界劃分的很清楚，每一個人都對本身的事情負責，各司其職。這也就是咱們常講的低耦合。這樣的代碼很好維護、擴展，當需求有所改變時，咱們就能很好的去應對。你好好想一想是否是...」

0x4 發送消息的從新設計

C哥提到，一種方式是面向過程，一種方式是面向對象。
兩種方式最大的不一樣就是責任的轉移。

王小二如有所悟，決定從新設計下發送消息的那個需求。

按照小二的想法，發送消息須要以下類(或實體)，才能實現責任的界定、轉移。從而將程序解耦。

小二先把類圖設計了出來。

設計完畢，頓時以爲思路清晰了好多。

用面向對象的方式去實現這個需求，如何實現呢？

1. 開始控制程序;
2. 對相應的vip用戶作初始化;
3. 告訴相應的vip用戶，發送信息;
4. 每一個vip用戶:
   a.肯定本身要發送什麼類型的消息(短信、微信、email...)
   b.發送消息

如此，就實現瞭解耦。真是能量滿滿。

0x5 不再怕需求變了

根據上面的設計，小二又用相應的代碼進行了實現。
「需求愛咋變咋變，此次不怕了，哈哈」，小二竊喜道。

好比，如今需求變化了。

產品經理說:"須要給年Vip用戶發送短信、郵件。其餘Vip用戶不變"。

王小二想到：「哈哈哈哈哈，需求隨便改，我終於再也不須要改那一大坨代碼了，我只須要改年Vip用戶的類就能夠了。」

如圖，須要改一個地方，其餘地方不會有任何影響。

看，通過一番設計以後，就是這麼的靈活、有魅力。

更多精彩，請關注公衆號「聊聊代碼」，讓咱們一塊兒聊聊「左手代碼右手詩」的事兒。