上回說到，c哥憑藉自己多年的編碼經驗，欲傳授王小二絕世武功。
讓我們書接上回。
看著王小二求知若渴的眼神，c哥開始對小二循循善誘。
「嗯...我會在教室門口貼一張課表。課表上標明所有的課程以及課程對應的教室。讓學生們自己根據課表去找就行了。」
「不錯！小二很聰明嘛。但是如果把這個場景轉換為程式實現，你起初可能就不會這樣設計了」。
「為什麼？」小二睜大眼睛問道。
「因為面對需求，你首先想到的是過程化的解決辦法。比如在你設計傳送訊息的需求的時候，就是典型的過程化的思維模式。上面那個講師的場景，你轉換成程式可能會這麼做：
獲得課堂上每個人的名單;
為了實現上面的過程，你可能需要：
獲得課堂上每個人名單的方法;
獲得每個人課表的方法;
獲得每個課程對應的教室的方法;
告訴學生去相應教室上課的方法;
乙個控制程式為每個人做需要的步驟。」
王小二沉思了一會，若有所思的點點頭：「嗯，確實會這麼做」。
「小二啊，上面我們說了兩種解決辦法。你覺得這兩種解決辦法哪種更好些呢？」c哥問道。
「當然是第一種了，現實生活中我可不會傻到自己挨個去查學生的課表，地點，然後挨個告訴學生，那多累啊。」
「是啊，肯定是第一種解決辦法好。其實，你仔細想想，這兩種解決方式，最大的不同點是**？」
「嗯...想不出來。」
「最大的不同點，是責任的轉移。你看第一種解決辦法，你只需要把課表張貼出來，學生自己去查詢課程、教室就行了。完成這件事情，既有老師的責任，也有學生的責任。而第二種方法，從頭到尾都需要老師去做，責任都在老師身上。」
「每個人的責任邊界劃分的很清楚，每個人都對自己的事情負責，各司其職。這也就是我們常講的低耦合。這樣的**很好維護、擴充套件，當需求有所改變時，我們就能很好的去應對。你好好想想是不是...」
c哥提到，一種方式是面向過程，一種方式是物件導向。
兩種方式最大的不同就是責任的轉移。
王小二若有所悟，決定重新設計下傳送訊息的那個需求。
按照小二的想法，傳送訊息需要如下類(或實體)，才能實現責任的界定、轉移。從而將程式解耦。
小二先把類圖設計了出來。
設計完畢，頓時覺得思路清晰了好多。
用物件導向的方式去實現這個需求，如何實現呢？
開始控制程式;
對相應的vip使用者做初始化;
告訴相應的vip使用者，傳送資訊;
如此，就實現了解耦。真是能量滿滿。
根據上面的設計，小二又用相應的**進行了實現。
「需求愛咋變咋變，這次不怕了，哈哈」，小二竊喜道。
比如，現在需求變化了。
產品經理說:"需要給年vip使用者傳送簡訊、郵件。其他vip使用者不變"。
王小二想到：「哈哈哈哈哈，需求隨便改，我終於不再需要改那一大坨**了，我只需要改年vip使用者的類就可以了。」
如圖，需要改乙個地方，其他地方不會有任何影響。
看，經過一番設計之後，就是這麼的靈活、有魅力。
設計模式系列 王小二需求歷險記 一
需求總是在變化的 在無數次與產品經理的 需求大戰 中，小二對這句話深有體會。這不，前些天，小二就經歷了一件欲哭無淚的事情.產品經理走到小二面前 小二，我們需要給年會員傳送簡訊，你多長時間能搞定？小二沉思了一會，拍拍胸脯 沒問題，不就是傳送簡訊嘛。一周內搞定 拿到需求後，小二就快速的對需求拆分了步驟 ...
Git歷險記（二） Git的安裝和配置
各位同學，上回git歷險記 一 講了乙個 hello git 的小故事。有的同學可能是玩過了其它分布式版本控制系統 dvcs 看完之後就觸類旁通對git就了然於胸了 也有的同學可能還如我當初入手git一樣，對它還是摸不著頭腦。從這一篇開始，我就將比較 囉嗦 的和大家一起從零開始經歷git使用的每一步...
設計模式系列二 設計模式總覽
設計模式七大原則 開閉原則 黎克特制替換原則 依賴反轉原則 介面隔離原則 迪公尺特法則 合成復用原則 單一職責原則 設計模式根據特點可以分為三大類 1 建立型模式 5 這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式，而不是使用 new 運算子直接例項化物件。這使得程式在判斷針對某個給定例項...