和許多人一樣，第一次接觸設(shè)計模式也是從《設(shè)計模式》開始的，在拜讀完這本巨著后，在感到深深的震憾之余，還有一種將這本書推薦給公司里每個家伙閱讀的強烈沖動?？墒菐讉€頗有面向?qū)ο缶幊棠芰Φ募一飬s告訴我，這本書太深奧、太抽象了，看得叫人感到頭昏眼花、云里霧里。
那時，我除了郁悶還有納悶，郁悶的是這么偉大的書，這些家伙卻一致反映很難看懂，看不懂，還如何從中吸取豐富的營養(yǎng)，迅速提高軟件設(shè)計水平，從而提高產(chǎn)品質(zhì)量？納悶的是為什么這些家伙會一致反映看不懂，而我自己卻沒有這樣的感覺呢？后來通過和這群家伙交流我才知道，他們不像我那樣擁有豐富的程序設(shè)計經(jīng)驗，經(jīng)歷過的東西太多(我先自吹自擂一番)，因此在閱讀這本書時，從自己過去眾多的設(shè)計中挑選出相似的案例來進行對比，而他們卻很難有這么多的案例去擬合每個設(shè)計模式，沒有“實物”做參照物，閱讀、理解自然是一個痛苦而漫長的過程。如果我想幫助這群家伙的話，只有“翻譯”這本書，如何“翻譯”？用常見的實例，用程序員的“語言”來解釋設(shè)計模式，而不再使用原著中抽象的。
從那里開始呢？首先從回答兩個問題說起吧。
第一個是學習設(shè)計模式從那個設(shè)計模式開始？
第二個是我最喜歡那個設(shè)計模式？
我認為回答第一個問題可以反映出回答者的“心態(tài)”，而回答第二個問題則反映出回答者的“心境．我的答案是，學習設(shè)計模式從“適配器”開始，我最喜歡的設(shè)計模式是“策略”。先說反映心態(tài)的“適配器”，程序員在成長過程中都有這樣的極其相似經(jīng)歷：在別人寫的代碼基礎(chǔ)上繼續(xù)，比如完善或者維護別人寫的程序。通常你我做的其實大同小異，先會去閱讀已經(jīng)寫好的代碼，感覺差不多了，下步動作是什么？60%的人不是開始“繼續(xù)的”工作，而是開始改寫、甚至是重寫代碼，還有40%的人是在“繼續(xù)工作”，完成新東西的設(shè)計后，回頭再來改寫、甚至是重寫代碼。我敢打賭，只有不到10%的人會在別人的基礎(chǔ)上“繼續(xù)”工作。改寫、重寫的理由是什么，無非是別人寫的太土、太臭，不改寫、重寫，心里不舒服，更“好”的理由是，和我“繼續(xù)”的思路不同，比如接口不兼容，我寫不下去，因此只有改寫，改的太多，我又比較能干，因此干脆重寫！
其實……其實……下一個在你工作基礎(chǔ)上繼續(xù)工作的家伙，和你的想法一樣，你一樣土，一樣臭，他一樣比你高明，一樣會改寫、重寫你引以為自豪的代碼。唉，就因為是軟件，你我可以拿到源代碼，因此你我手才會癢，才會有改寫、重寫的奇怪念頭，想想硬件，自己沒那個本事，也沒有那個條件去重新設(shè)計、制造另一個主板，來實現(xiàn)一個滿足自己需要的接口。每次開發(fā)一個接口卡的時候，你我還不是老老實實按“規(guī)范”去設(shè)計接口，再按自己的需要做個“適配”處理？！同樣你有改寫API的沖動嗎，老實說我經(jīng)常有，我特別討厭win32API的許多接口，羅嗦不說，還無法提供我想要的全部功能，麻煩死了。但我改不了，因為沒有本事改，也無法改。老實說，那些宣稱喜歡linux的家伙，肯定有一堆想“改進”linux內(nèi)核的自負家伙，我就遇到好多好多。那么改寫、重寫的效果如何呢，老實說，我自己有很深的體會，步入管理崗位后體會更深，客氣點“條條道路通羅馬”吧，心情不佳的時候“50步笑100步”吧，還不說時間(你總不至于聰明到1秒鐘內(nèi)修改完成吧)、成本(你改寫、重寫、測試的那段時間，你不會給老板說你不要工資吧)了。如果你心平氣和去對比，你會發(fā)現(xiàn)我說的絕對一點不夸張、過分。
說了這么一大堆，就是想說，如果你想提高自己的工作效率，你想做更有意義的事情，你不想重復去造一個別人已經(jīng)造好的輪子的話，下次遇到在別人工作基礎(chǔ)上“繼續(xù)”這樣的“美差”的時候，首先要想到“適配器”設(shè)計模式，適配器設(shè)計模式太簡單了，簡單到我認為不需要說什么了，其實你能否有機會使用適配器模式，主要是看你的心態(tài)，我相信你一定能掌握他，不就是匹配個接口嘛。
那時，我除了郁悶還有納悶，郁悶的是這么偉大的書，這些家伙卻一致反映很難看懂，看不懂，還如何從中吸取豐富的營養(yǎng)，迅速提高軟件設(shè)計水平，從而提高產(chǎn)品質(zhì)量？納悶的是為什么這些家伙會一致反映看不懂，而我自己卻沒有這樣的感覺呢？后來通過和這群家伙交流我才知道，他們不像我那樣擁有豐富的程序設(shè)計經(jīng)驗，經(jīng)歷過的東西太多(我先自吹自擂一番)，因此在閱讀這本書時，從自己過去眾多的設(shè)計中挑選出相似的案例來進行對比，而他們卻很難有這么多的案例去擬合每個設(shè)計模式，沒有“實物”做參照物，閱讀、理解自然是一個痛苦而漫長的過程。如果我想幫助這群家伙的話，只有“翻譯”這本書，如何“翻譯”？用常見的實例，用程序員的“語言”來解釋設(shè)計模式，而不再使用原著中抽象的。
從那里開始呢？首先從回答兩個問題說起吧。
第一個是學習設(shè)計模式從那個設(shè)計模式開始？
第二個是我最喜歡那個設(shè)計模式？
我認為回答第一個問題可以反映出回答者的“心態(tài)”，而回答第二個問題則反映出回答者的“心境．我的答案是，學習設(shè)計模式從“適配器”開始，我最喜歡的設(shè)計模式是“策略”。先說反映心態(tài)的“適配器”，程序員在成長過程中都有這樣的極其相似經(jīng)歷：在別人寫的代碼基礎(chǔ)上繼續(xù)，比如完善或者維護別人寫的程序。通常你我做的其實大同小異，先會去閱讀已經(jīng)寫好的代碼，感覺差不多了，下步動作是什么？60%的人不是開始“繼續(xù)的”工作，而是開始改寫、甚至是重寫代碼，還有40%的人是在“繼續(xù)工作”，完成新東西的設(shè)計后，回頭再來改寫、甚至是重寫代碼。我敢打賭，只有不到10%的人會在別人的基礎(chǔ)上“繼續(xù)”工作。改寫、重寫的理由是什么，無非是別人寫的太土、太臭，不改寫、重寫，心里不舒服，更“好”的理由是，和我“繼續(xù)”的思路不同，比如接口不兼容，我寫不下去，因此只有改寫，改的太多，我又比較能干，因此干脆重寫！
其實……其實……下一個在你工作基礎(chǔ)上繼續(xù)工作的家伙，和你的想法一樣，你一樣土，一樣臭，他一樣比你高明，一樣會改寫、重寫你引以為自豪的代碼。唉，就因為是軟件，你我可以拿到源代碼，因此你我手才會癢，才會有改寫、重寫的奇怪念頭，想想硬件，自己沒那個本事，也沒有那個條件去重新設(shè)計、制造另一個主板，來實現(xiàn)一個滿足自己需要的接口。每次開發(fā)一個接口卡的時候，你我還不是老老實實按“規(guī)范”去設(shè)計接口，再按自己的需要做個“適配”處理？！同樣你有改寫API的沖動嗎，老實說我經(jīng)常有，我特別討厭win32API的許多接口，羅嗦不說，還無法提供我想要的全部功能，麻煩死了。但我改不了，因為沒有本事改，也無法改。老實說，那些宣稱喜歡linux的家伙，肯定有一堆想“改進”linux內(nèi)核的自負家伙，我就遇到好多好多。那么改寫、重寫的效果如何呢，老實說，我自己有很深的體會，步入管理崗位后體會更深，客氣點“條條道路通羅馬”吧，心情不佳的時候“50步笑100步”吧，還不說時間(你總不至于聰明到1秒鐘內(nèi)修改完成吧)、成本(你改寫、重寫、測試的那段時間，你不會給老板說你不要工資吧)了。如果你心平氣和去對比，你會發(fā)現(xiàn)我說的絕對一點不夸張、過分。
說了這么一大堆，就是想說，如果你想提高自己的工作效率，你想做更有意義的事情，你不想重復去造一個別人已經(jīng)造好的輪子的話，下次遇到在別人工作基礎(chǔ)上“繼續(xù)”這樣的“美差”的時候，首先要想到“適配器”設(shè)計模式，適配器設(shè)計模式太簡單了，簡單到我認為不需要說什么了，其實你能否有機會使用適配器模式，主要是看你的心態(tài)，我相信你一定能掌握他，不就是匹配個接口嘛。