前言

以小說的筆法寫的設計模式系列文章，你絕對看得懂！[首發于公眾號:"聊聊代碼"]

設計模式系列·王小二需求歷險記(一)
設計模式系列·王小二需求歷險記(二)
設計模式系列·封裝、繼承、多態
設計模式系列·初探設計模式之王小二的疑問
設計模式系列·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哥說到：“嗯。從一大坨代碼到模塊化，程序變得更好理解和維護了，不錯不錯?！?/p>

聽到C哥的贊賞，小二高興極了，瞬間從之前低落的心情變得彩虹滿天飛。

“不過，你這個還不夠靈活?！?/p>

“還不夠靈活？”

“是啊。比如發送消息模塊，我現在需要發送微信。但是短信、郵件的內容是字符串，微信的內容是數組。那這個send_message()函數是不是就不能用了？"

”你這么一說還真是“

”很明顯，模塊化可以幫你寫出更加容易理解和維護的代碼，但是，模塊化并不能幫助你寫出能應付所有變化的代碼?！?/p>

”嗯...是的“

”并且，函數還有一個問題。如果有很多地方對你的函數有依賴，在使用你的函數(你或許不知道別人在使用你的函數)。那么，你對這個函數一更改，也會間接的對其他地方產生bug。這就是強耦合帶來的弊端?！?/p>

”對，對！C哥說的太對了！那么，如何去解決呢？“

欲知后事如何，請關注公眾號“聊聊代碼”，讓我們一起聊聊“左手代碼右手詩”的事兒。

總結

以上是生活随笔為你收集整理的设计模式系列·王小二需求历险记(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。