「需求總是在變化的」，在無數次與產品經理的」需求大戰「中，小二對這句話深有體會。
這不，前些天，小二就經歷了一件欲哭無淚的事情...
產品經理走到小二面前：「小二，我們需要給年會員傳送簡訊，你多長時間能搞定？」
小二沉思了一會，拍拍胸脯：「沒問題，不就是傳送簡訊嘛。一周內搞定」。
拿到需求後，小二就快速的對需求拆分了步驟：
在資料庫中獲取所有的會員；
獲取所有的年會員的資訊；
按照註冊時間排序；
依次給這些會員傳送簡訊。
好了，需求的實現，拆分的如此簡單明瞭，下一步就擼起袖子開始幹唄！
經過一周的努力，明天終於要上線了，小二內心中滿滿的都是成就感。
「等等，小二，傳送簡訊的事，需求要變一下...」
"啥？明天就上線了，你告訴我要變需求？有沒有搞錯？"
剛剛寫好的812行**，又要重新修改...
經過乙個晚上10小時的加班，小二終於搞定了，**從之前的812行變為了1300行...
專案如期上線，小二也松了口氣，但最近整晚的加班確實吃不消了。
小二回過頭來想想：「這產品經理每一次的需求變化，我都得更改我的整個指令碼或整個函式。這樣太容易出錯了，有沒有好點的辦法，不讓我這麼痛苦？...」
小二忽然靈光一閃：「與其寫成乙個龐大的函式，為什麼不把程式模組化呢？下次變化的時候，那我只需要更改我這個模組就可以了。這不是更好理解與維護嗎？」
小二內心竊喜，就這麼幹！
於是，小二將整個傳送訊息的過程拆分成了不同的函式，不同的模組。
function get_year_vip(){}
//2、按照註冊時間排序
function sort_year_vip(){}
//3、傳送訊息($user_info為使用者資訊,$content為訊息內容)
function send_message($user_info,$content){}
那麼，當我需要從傳送簡訊變為傳送簡訊和郵件的時候，我只需要更改send_message()這個函式就可以了。good job!
在牛人雲集的公司，小二想去請教下c哥，看看有沒有更好的解決辦法。
聽完小二的描述，c哥說到：「嗯。從一大坨**到模組化，程式變得更好理解和維護了，不錯不錯。」
聽到c哥的讚賞，小二高興極了，瞬間從之前低落的心情變得彩虹滿天飛。
「不過，你這個還不夠靈活。」
「還不夠靈活？」
」你這麼一說還真是「
」很明顯，模組化可以幫你寫出更加容易理解和維護的**，但是，模組化並不能幫助你寫出能應付所有變化的**。「
」嗯...是的「
」並且，函式還有乙個問題。如果有很多地方對你的函式有依賴，在使用你的函式(你或許不知道別人在使用你的函式)。那麼，你對這個函式一更改，也會間接的對其他地方產生bug。這就是強耦合帶來的弊端。「
」對，對！c哥說的太對了！那麼，如何去解決呢？「
欲知後事如何，且看下篇文章：王小二需求歷險記(二)
設計模式系列 王小二需求歷險記 二
上回說到，c哥憑藉自己多年的編碼經驗，欲傳授王小二絕世武功。讓我們書接上回。看著王小二求知若渴的眼神，c哥開始對小二循循善誘。嗯.我會在教室門口貼一張課表。課表上標明所有的課程以及課程對應的教室。讓學生們自己根據課表去找就行了。不錯！小二很聰明嘛。但是如果把這個場景轉換為程式實現，你起初可能就不會這...
設計模式系列二 設計模式總覽
設計模式七大原則 開閉原則 黎克特制替換原則 依賴反轉原則 介面隔離原則 迪公尺特法則 合成復用原則 單一職責原則 設計模式根據特點可以分為三大類 1 建立型模式 5 這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式，而不是使用 new 運算子直接例項化物件。這使得程式在判斷針對某個給定例項...
設計模式系列二 設計模式總覽
設計模式七大原則 開閉原則 黎克特制替換原則 依賴反轉原則 介面隔離原則 迪公尺特法則 合成復用原則 單一職責原則 設計模式根據特點可以分為三大類 1 建立型模式 5 這些設計模式提供了一種在建立物件的同時隱藏建立邏輯的方式，而不是使用 new 運算子直接例項化物件。這使得程式在判斷針對某個給定例項...