0x1 原文再續，書接上回
上回說到，C哥憑藉自己多年的編碼經驗，欲傳授王小二絕世武功。
讓我們書接上回。
0x2 來源於生活中的例項
看著王小二求知若渴的眼神，C哥開始對小二循循善誘。
“小二啊，我們假設一個場景：假設你是一名講師，對於上完你課程的人，你要確保接下來，每個人都知道他們下一節課去哪上。你如何去做呢？”
“嗯...我會在教室門口貼一張課表。課表上標明所有的課程以及課程對應的教室。讓學生們自己根據課表去找就行了。”
“不錯！小二很聰明嘛。但是如果把這個場景轉換為程式實現，你起初可能就不會這樣設計了”。
“為什麼？”小二睜大眼睛問道。
“因為面對需求，你首先想到的是過程化的解決辦法。比如在你設計傳送訊息的需求的時候，就是典型的過程化的思維模式。上面那個講師的場景，你轉換成程式可能會這麼做：
- 獲得課堂上每個人的名單;
- 對於名單上的每個人：
a.查詢他的下一節課程;
b.查詢他的下一節課程的地點;
c.告訴他去哪裡上下一節課。
為了實現上面的過程，你可能需要：
- 獲得課堂上每個人名單的方法;
- 獲得每個人課表的方法;
- 獲得每個課程對應的教室的方法;
- 告訴學生去相應教室上課的方法;
- 一個控制程式為每個人做需要的步驟。”
王小二沉思了一會，若有所思的點點頭：“嗯，確實會這麼做”。
0x3 趁熱打鐵·責任的轉移
“小二啊，上面我們說了兩種解決辦法。你覺得這兩種解決辦法哪種更好些呢？”C哥問道。
“當然是第一種了，現實生活中我可不會傻到自己挨個去查學生的課表，地點，然後挨個告訴學生，那多累啊。”
“是啊，肯定是第一種解決辦法好。其實，你仔細想想，這兩種解決方式，最大的不同點是哪裡？”
“嗯...想不出來。”
“最大的不同點，是責任的轉移。你看第一種解決辦法，你只需要把課表張貼出來，學生自己去查詢課程、教室就行了。完成這件事情，既有老師的責任，也有學生的責任。而第二種方法，從頭到尾都需要老師去做，責任都在老師身上。”
“每個人的責任邊界劃分的很清楚，每個人都對自己的事情負責，各司其職。這也就是我們常講的低耦合。這樣的程式碼很好維護、擴充套件，當需求有所改變時，我們就能很好的去應對。你好好想想是不是...”
0x4 傳送訊息的重新設計
C哥提到，一種方式是程式導向，一種方式是物件導向。
兩種方式最大的不同就是責任的轉移。
王小二若有所悟，決定重新設計下傳送訊息的那個需求。
按照小二的想法，傳送訊息需要如下類(或實體)，才能實現責任的界定、轉移。從而將程式解耦。
小二先把類圖設計了出來。
設計完畢，頓時覺得思路清晰了好多。
用物件導向的方式去實現這個需求，如何實現呢？
- 開始控制程式;
- 對相應的vip使用者做初始化;
- 告訴相應的vip使用者，傳送資訊;
- 每個vip使用者:
a.確定自己要傳送什麼型別的訊息(簡訊、微信、email...)
b.傳送訊息
如此，就實現瞭解耦。真是能量滿滿。
0x5 再也不怕需求變了
根據上面的設計，小二又用相應的程式碼進行了實現。
“需求愛咋變咋變，這次不怕了，哈哈”，小二竊喜道。
比如，現在需求變化了。
產品經理說:"需要給年Vip使用者傳送簡訊、郵件。其他Vip使用者不變"。
王小二想到：“哈哈哈哈哈，需求隨便改，我終於不再需要改那一大坨程式碼了，我只需要改年Vip使用者的類就可以了。”
如圖，需要改一個地方，其他地方不會有任何影響。
看，經過一番設計之後，就是這麼的靈活、有魅力。
更多精彩，請關注公眾號“聊聊程式碼”，讓我們一起聊聊“左手程式碼右手詩”的事兒。
