上一篇：《把設計模式用起來（3）——用不好的原因 之 實踐不足》https://blog.csdn.net/nanyu/article/details/141939342

本篇繼續(xù)講設計模式用不好的常見原因，這是第二個：使用設計模式的時機不對。

二、時機不對

這里說的時機并不是單純指軟件研發(fā)周期中的時間階段，而是指條件；更具體一點，指程序員應該滿足什么條件，才是使用設計模式的好時機。

第一個條件前面說過了，得有問題。第二個條件，程序員需具備分析問題的能力。畢竟，只有通過分析才能從問題得到模式，如圖：

圖：? 從問題到模式

這張圖中最重要的是分析，最不重要的是模式。你甚至可以認為，一個沒學過模式的程序員面對某個具體問題，只要分析得當，往往也能應用正確的模式，只是他自己不知道自己組織代碼方式，被稱作某某模式。

那么，我們要如何獲得更強的分析能力呢？其一，對問題所屬的業(yè)務邏輯越熟悉，對問題就越了解；其二，既然模式是此過程的結果，那么，熟悉模式也有利于我們強化分析問題的能力。由此，我們可以畫一張更復雜一點的圖：

圖：? 問題-分析-模式

盡管熟悉模式倒過來有助于理解問題，但程序員的更多努力仍需用在正向路徑：熟悉業(yè)務→理解問題→分析問題→找到并應用正確的設計模式。

在理解問題的基礎上，思考是否需要以及如何使用設計模式，這個結論聽起來是如此的自然而然，幾乎稱得上是一條“公理”，但確實有很多程序員，特別是正在學習設計模式或自詡擅長設計模式的程序員，容易違背，犯“先有模式，然后到處找問題”的錯誤。

有同學說，“老師，雖然我心里確實裝滿設計模式，快溢出來的那種，但我并不會犯拿模式硬套問題的低級錯誤；相反，我總是在看到某個問題和某個模式匹配度很高的情況后，才會放心地套用設計模式?！?/p>

“只是放心嗎？難道沒有開心？”

“當然也開心啊！每當用對一次設計模式，我的內(nèi)心充滿成就感?！?/p>

這正是罪之所在：對設計模式的使用，有迫切的期待。這是貪欲，這是心魔，是引發(fā)更多軟件研發(fā)問題的萬惡之源。這種心態(tài)很容易讓我們提倡的“工作逼迫你使用設計模式”，變成“你逼迫工作使用設計模式”。

說這么多，是在表達一個觀點：使用設計模式應寧缺勿濫，因為，一段用錯設計模式的代碼往往比未使用模式的代碼，更令后來人頭痛。

每一個設計模式，都是在表達特定意圖（Intent）的一種組織代碼的方式。一段代碼用上一個設計模式，意味著這段代碼至少多出了兩個明顯的屬性：一是它的意圖，二是它的代碼結構。一段什么設計模式都沒用上代碼，它就是一段代碼；而一段代碼用上了設計模式，代碼中的設計模式就像人群有個顯眼包，它會一直叫嚷：“看我，看我！我的設計意圖是……我的實現(xiàn)結構是……”

那么，閱讀者接收到這兩個信息，是好事還是壞事？這就得看設計模式用對與否。幸福的代碼都是相似的，不幸的代碼卻各有各的不幸，見表：

功能滿足 (業(yè)務)	模式選擇 (意圖)	模式實現(xiàn) (結構)	不幸的效果
?	?	?	表達了錯誤的意圖且該意圖未正確實現(xiàn)，程序不對勁
?	?	√	表達并實現(xiàn)了一個錯誤的意圖，程序不對勁
?	√	?	意圖正確，但該意圖實現(xiàn)有錯，程序不對勁
√	?	?	表達了錯誤的意圖，且意圖實現(xiàn)有誤，但程序能跑對
√	?	√	用一個錯誤的模式實現(xiàn)了程序所需的功能

無論模式選對選錯，也無論功能滿足與否，表中幾種應用情況中的設計模式，都會給代碼閱讀者帶來更多干擾甚至誤導，畢竟它們會說話。

這里特別講講表中最后一類不幸：“用一個錯誤的模式實現(xiàn)了程序所需功能”。這里最常見的“錯誤”，就是用了一個并不需要的模式。比如，使用策略模式，但直至系統(tǒng)下線也沒用上第二個策略。再如，實現(xiàn)了一個無比強大的解釋器，卻只用它順序執(zhí)行指令。

丁小明嚴肅地從座位站起來：“老師，您應知道‘防御性編程’？程序員總是預設程序存在問題且將持續(xù)需要修改。所以，盡管在剛開始做設計時我們無法預測是否有第二個策略，但我們應該預設它有。至于解釋器的例子，確實有點過度設計之嫌，但原則上，假定未來會有復雜的流程腳本需要執(zhí)行，不對嗎？”

這是很多同學都會有的疑惑：防御性編程是對的，可是切忌過度設計也是對的，日常編程做設計，能不能有一個簡單明了且有效的方法，能迅速將我們從“加上！”和“不要！”，甚至是“砍掉！”的糾結中拉出來？

具體到何時使用設計模式這個問題，新的疑惑是：假設我還沒有完全掌握業(yè)務需求就被迫寫代碼，那這些代碼未來一定會變，那么，我現(xiàn)在是不是應該預防性地多加使用設計模式？畢竟，設計模式生來就是為了應對變化。讓我們畫張圖來更清楚的表達：

因為會有變化，所以就馬上用模式？

這種想法是錯的，它把工作理想化了，并且弄錯了工作首要目標。編程工作首先需保證正確實現(xiàn)當下的功能，然后才去考慮如何更好地就應對未來的變化。

為什么是這樣先后次序？有兩個理由，第一個略顯功利：先快點做對，再慢慢做好，這樣比較不會挨訓，也可以反過來說，你上來就花大力氣讓代碼能應對未來的65536種變化，大概率也得不到領導夸獎。第二個理由很客觀：后者依賴前者，即，通常，正是在從不對，到不那么對，到最終做對的過程中，才能對眼下的功能、未來的變化、應有的設計這三者都產(chǎn)生深刻的理解。

丁小明再次發(fā)問：“有些功能未來會發(fā)生的變化，在程序員一行代碼未寫時，就可以猜出十之八群，這種情況下，程序員直接用上設計模式，也不合理嗎？”這種理想狀態(tài)當然存在。諸如：

• 項目前期工作非常棒，需求清晰，設計詳細，詳細到此處該用什么模式都寫出來了；
• 你對此類問題有深刻理解，或有可靠的經(jīng)驗，此類功能后續(xù)的變化路徑，你看得清楚、也看得長遠；
• 針對眼前這類問題，業(yè)界有教科書般的解決方法。

更多的時候，程序員處在水深火熱中：

• 甲方對現(xiàn)有的功能都說不清楚，遑論未來的變化；
• 甲方基于防御性心理，羅列了各種各樣的，未來可能的變化；
• 甲方?jīng)]怎么提，我方（領導、產(chǎn)品經(jīng)理、程序員自己）設想了一大堆；
• 甲方?jīng)]怎么提，我方也沒怎么想，但因為業(yè)務領域問題，我方并未正確理解甲方的真實需求；
• 甲方提了一些，我方想了一些，并且我方正確地理解了甲方，只是不管甲方說還是我方想的，都有不對的地方；
• ……

如果某一塊的功能需求還比較模糊，作為乙方，千萬不要自信可以通過一個“強大的設計”以做到“以不變應萬變”，從而“立于不敗之地”。此時的正確做法，應是直接的、快速地把當前所理解的功能做出來，并借助它盡快確定相關需求。

對問題的理解是一切設計的基礎，不過，實現(xiàn)設計的過程，能極大幫助程序員全面地，深入地理解問題。多數(shù)時候，甲方能告訴你需求，但不能幫你做需求分析，而程序員因為跨領域的原因，所做的需求分析仍然有不少模糊與曖昧。比如，功能F1客觀上需要的輸入是I1、I2、I3，但程序員有可能在開始時認為是I1、I3和I4。有很多方法有助發(fā)現(xiàn)并糾正這個錯誤認知，其中一種非常高效的方法，就是編寫代碼嘗試實現(xiàn)，在實現(xiàn)的過程，即可驗證、強化、糾偏、補充程序員對業(yè)務系統(tǒng)的理解，包括厘清對象職責和理清對象關系，這二者是面向?qū)ο蠛陀脤υO計模式的重要基礎。

這是本小節(jié)的結論：除非你對問題理解到位透徹，否則不要一開始寫代碼就想著使用設計模式，在功能寫對之前，更不要為了該功能“未來可能的變化”去套用設計模式。

這個結論只說了不要，那什么時候可以要呢？兩點：

1. 如果你對問題和業(yè)務所在領域非常有經(jīng)驗，那么，可以直接上設計模式以應對未來的變化；
2. 否則，請在變化發(fā)生一次、兩次、甚至三次的時候，再開始考慮使用設計模式重構代碼。

臺下有同學一臉落莫，問：“老師，我贊同第二點，但我們的領導不愿意給我重構所需的資源，比如時間，怎么辦？”。這是回到上一小節(jié)“實踐不足”中的情況B了。你可以屈服，從此不去想設計模式的好；也可以造反，說服領導，或想辦法讓自己當上領導；還也可以跳槽。無論如何，我都不建議一個程序員在這種惡劣的工作環(huán)境下，一邊要抓緊完成業(yè)務功能，一邊要努力用對設計模式。注意，當我說這話時，我站邊技術主管。本來，主管只需檢查你功能做對做錯，現(xiàn)在，他需要同時檢查功能和模式，其中后者還有需區(qū)分選擇和實現(xiàn)上的錯誤，諸如：(a) 功能做錯，模式選錯，模式寫錯；(b) 功能做錯，模式選對，模式寫錯； (c) 功能做對，模式選錯，模式寫對……（參見表2）。

猜，技術主管在這種場景下，最喜歡說的是哪一句話？答：“你這是要把錯誤雕成一朵花嗎？”

來聽一個源于真實案例改編的故事吧。主人公本應是丁小明，為節(jié)省篇幅，我們用“你”來代替。

假設問題為Q，正確答案是A；而因為理解有誤，你以為需要實現(xiàn)的業(yè)務邏輯是B，并且你迅速想到B未來有可能發(fā)展成B1、B2、B3。想到這里，你一邊啜吸奶茶發(fā)出嗞嗞嗞的聲音；一邊在腦海中構建原始思路C。為了更好地表達思路，也為了更好地應對B1、B2、B3，你果斷選用設計模式D，D的意圖是I。不過，由于你還是設計模式新人，所以你真實想表達的意圖其實是J，而你寫的模式很像D但又不是D，稱作“D' ”。測試一把，確實能實現(xiàn)B，你充滿成就感地提交了代碼E。

技術主管開始審查E，他迅速嗅到D的味道；會心一笑，品一口咖啡，感覺自己像羽扇綸巾的諸葛亮，準備欣賞一場漂亮的戰(zhàn)役，看看自己的員工如何通過設計模式優(yōu)雅地干掉Q。10分鐘過去，20分鐘過去，30分鐘過去……經(jīng)驗老到的主管，終于發(fā)現(xiàn)D` 和 D 只是長得像而已。

主管放下代碼，翻出上次設計模式內(nèi)訓的文檔，發(fā)現(xiàn)當時你寫的答案那叫一個似是而非。他嘆一口氣，陷入自責。

1個小時過去，主管猛然領悟，你的真實意圖是J。

2個小時過去，主管醍醐灌頂：“這家伙想要實現(xiàn)的業(yè)務邏輯是B，不是A！”，不過，縱使如此，也不應該用D啊？看一眼時間是夜里11點30分，還早；他撥通了你的電話。

夜深人靜，主管的身邊人呼吸均勻，偶爾吐一兩句夢話。主管輕悄悄地換個姿式，繼續(xù)聽話里的你興奮地談著：“B1、B2、B3變化，可能還是保守了，我有一種預感，三個月以后，隨著用戶量的劇增，B99，B100，B101也是有可能發(fā)生的……”

這樣的破事來個三四次，故事中主人公的工作類型就會發(fā)生變化，參見上一小節(jié)“實踐不足”的情況D、情況C、情況A。