前言
以小說的筆法寫的設計模式系列文章，你絕對看得懂！[首發於公眾號:"聊聊程式碼"]
設計模式系列·王小二需求歷險記(一)
設計模式系列·王小二需求歷險記(二)
設計模式系列·封裝、繼承、多型
設計模式系列·初探設計模式之王小二的疑問
設計模式系列·Facade模式之MVC的煩惱
設計模式系列·Adapter 模式之如何優雅的使用別人的輪子
設計模式系列·類爆炸之Bridge模式
設計模式系列·工廠方法模式之 Code Review
設計模式系列·抽象工廠模式
------華麗的分割線------
0x1 不斷變化的需求
“需求總是在變化的”，在無數次與產品經理的”需求大戰“中，小二對這句話深有體會。
這不，前些天，小二就經歷了一件欲哭無淚的事情...
0x2 產品經理的需求
產品經理走到小二面前：“小二，我們需要給年會員傳送簡訊，你多長時間能搞定？”
小二沉思了一會，拍拍胸脯：“沒問題，不就是傳送簡訊嘛。一週內搞定”。
0x3 程式導向的開發
拿到需求後，小二就快速的對需求拆分了步驟：
- 在資料庫中獲取所有的會員；
- 獲取所有的年會員的資訊；
- 按照註冊時間排序；
- 依次給這些會員傳送簡訊。
好了，需求的實現，拆分的如此簡單明瞭，下一步就擼起袖子開始幹唄！
經過一週的努力，明天終於要上線了，小二內心中滿滿的都是成就感。
“等等，小二，傳送簡訊的事，需求要變一下...”
"啥？明天就上線了，你告訴我要變需求？有沒有搞錯？"
“小二，這個需求確實緊急，沒有辦法。我們除了給年會員傳送簡訊外，還需要傳送微信。你諒解下，幫幫忙，我也是確實沒有辦法...”
"唉，好吧，就這一次，下不為例！"
剛剛寫好的812行程式碼，又要重新修改...
經過一個晚上10小時的加班，小二終於搞定了，程式碼從之前的812行變為了1300行...
專案如期上線，小二也鬆了口氣，但最近整晚的加班確實吃不消了。
小二回過頭來想想：“這產品經理每一次的需求變化，我都得更改我的整個指令碼或整個函式。這樣太容易出錯了，有沒有好點的辦法，不讓我這麼痛苦？...”
0x4 模組化
小二忽然靈光一閃：“與其寫成一個龐大的函式，為什麼不把程式模組化呢？下次變化的時候，那我只需要更改我這個模組就可以了。這不是更好理解與維護嗎？”
小二內心竊喜，就這麼幹！
於是，小二將整個傳送訊息的過程拆分成了不同的函式，不同的模組。
//1、獲取年會員的資訊[包括mobile、email、微訊號...]
function get_year_vip(){}
//2、按照註冊時間排序
function sort_year_vip(){}
//3、傳送訊息($user_info為使用者資訊,$content為訊息內容)
function send_message($user_info,$content){}複製程式碼那麼，當我需要從傳送簡訊變為傳送簡訊和郵件的時候，我只需要更改send_message()這個函式就可以了。good job!
0x5還不夠靈活
在牛人云集的公司，小二想去請教下C哥，看看有沒有更好的解決辦法。
聽完小二的描述，C哥說到：“嗯。從一大坨程式碼到模組化，程式變得更好理解和維護了，不錯不錯。”
聽到C哥的讚賞，小二高興極了，瞬間從之前低落的心情變得彩虹滿天飛。
“不過，你這個還不夠靈活。”
“還不夠靈活？”
“是啊。比如傳送訊息模組，我現在需要傳送微信。但是簡訊、郵件的內容是字串，微信的內容是陣列。那這個send_message()函式是不是就不能用了？"
”你這麼一說還真是“
”很明顯，模組化可以幫你寫出更加容易理解和維護的程式碼，但是，模組化並不能幫助你寫出能應付所有變化的程式碼。“
”嗯...是的“
”並且，函式還有一個問題。如果有很多地方對你的函式有依賴，在使用你的函式(你或許不知道別人在使用你的函式)。那麼，你對這個函式一更改，也會間接的對其他地方產生bug。這就是強耦合帶來的弊端。“
”對，對！C哥說的太對了！那麼，如何去解決呢？“
欲知後事如何，請關注公眾號“聊聊程式碼”，讓我們一起聊聊“左手程式碼右手詩”的事兒。
