設計模式在實際開發中用的多嗎？

01-27

寫了這麼多年代碼，一直沒用過，不知你們是不是也一樣

相信大家都看過武俠小說，聽過獨孤求敗這個人！獨孤求敗的劍術分為五個級別：利劍級、軟劍級、重劍級、木劍級和無劍級。

獨孤九劍屬於利劍級，包括破氣式，破箭式，破掌式，破索式，破鞭式，破槍式，破刀式，破劍式，總訣式。簡而言之，就是針對特定的招式用特定的方法破解！

《設計模式》就是軟體開發中的孤獨九劍！設計模式中包涵創建型模式，結構型模式，行為模式。同樣是針對特定的問題給出特定的解決辦法！

「凌厲剛猛，無堅不摧，弱冠前以之與河朔群雄爭鋒。」在功力還沒大成之前，獨孤求敗靠著獨孤九劍在二十歲前就馳騁江湖！

軟體開發新手，只要熟加練習，靠著設計模式，完成基本的開發任務是可以的！

二十歲到三十歲之前，獨孤求敗進入了第二個階段，軟劍級！這個時候，他意識到，天下武功唯快不破！招式一樣，那麼快者勝！這段時間，獨孤求敗用的是紫薇軟劍！現實中，快已經是大部分的公司屢試不爽的招數，即使是加班加點，也要快！然而太快便難以收放自如！「紫薇軟劍，三十歲前所用，誤傷義士不祥，乃棄之深谷。」歷史總是相似的，有些公司走火入魔，出現過勞死的現象！

三十到四十歲，獨孤求敗用的是玄鐵重劍，玄鐵劍法以簡單的刺、挑、砸、掃等幾個簡單的招式，用深厚的內力推動，威力無窮！「重劍無鋒，大巧不工。四十歲前恃之橫行天下。」

在實際的開發工作中，堅持職責單一，介面簡潔的原則，再怎麼做都不會爛到哪裡去！但，同樣的，需要深厚的基礎！操作系統，網路協議，演算法與數據結構等，都要熟練掌握！

「四十歲後，不滯於物，草木竹石皆可為劍。」此乃木劍級。而「自此精修，漸進於無劍勝有劍之境。」則是無劍級！

其實說白了，就是不用太在意設計模式！多寫代碼多思考才是最終之道！

程序員分三種：框架，類庫，邏輯

寫邏輯的時候滿腦子設計模式，估計會把自己搞瘋掉

當用則用，不合適，或者感覺把握不了千萬不要強上

如果產品設計上明確了這塊會有擴展，需要預留。

或者這塊就天然適合設計模式。那麼就用吧……

雖然這樣講不太好，但開發的實際情況就是，對不同類型的代碼，質量要求是不一樣的。這個包括，時間，資源，需求易變程度，復用程度和穩定性，人員素質，決策層的關注度等。很多時候是不能強求的……既不能向髒亂差隨便妥協，也不能把自己項目搞成分析癱瘓

我曾經給一個組員講過幾個設計模式，結果他就記住了一個單例模式。然後安排他寫UI的時候，就到處用單例，可想而知那後果（不過之前他都是用static，沒法子小項目的基礎）……然後，我就對在公司推行設計模式這種事非常慎重了……

如果大家想了解關於設計決策是如何取捨的，在公司開發中如何提高質量（尤其是在中國軟體企業），有一本書叫做《走出軟體作坊》，我很推薦：）

有用

是一種工作語言

和同事間一個簡單的「用策略模式吧」「加個面板吧」

很方便

設計模式最後一開始只在重構中用，用多了就知道什麼場合該用，再往後就可以上來就用了。

我個人覺得，

在50萬行以下的項目中，

設計模式沒有用。

說模式沒用的要麼兩種，一種是還沒做過多人協作的大的軟體項目，一種就是過了某個過程，模式自在心中的高手

本來設計模式就是起源於建築學，你蓋個茅房造個廁所，開發個簡單的靜態網頁，做個三消，跑酷，簡單卡牌類的手機遊戲的，隨便寫也沒關係了，反正也不需要再擴展維護，賣一筆扔掉好了。

但凡建設高屋建瓴，高樓大廈，複雜的軟體系統，頭條京東這樣的高負載軟體產品，《農藥》《吃雞》等中大型的手游項目，生命周期維護期很長的手游項目（做一票一直賣代碼一直賣支持或者滾服洗用戶的軟體或遊戲開發者勿擾）。

技術人員應該還是會經歷一個，邏輯開發

- 》擴展性維護性思考

-》各種經驗模式的學習

-》恍然大悟

-》運用經驗，運用方法論，運用模式

- 》模式自在心中的過程，融匯模式，忘記模式

的過程。

設計模式很實用啊，造輪子不用設計模式怎麼行？寫個PHP也可以像Java一樣玩得風生水起：
PHP設計模式簡介
可以看看我小站中的介紹。

多。

單例，解決全局變數問題。別說好的設計沒有全局變數，有時候全局變數可以大大簡化設計。單例類就是解決全局變數的副作用。

工廠，這個模式在com裡面用爛了。

adapter，新舊系統的介面兼容，可能你不知道這個叫adapter，但是就是好用。

代理模式，c++的防火牆技術就是代理模式。太多了，多看看好的源碼，就能看出套路。

不可能沒有用到的，所有主流的語言本身都大量地使用了設計模式，比如JAVA、PHP、C#。關鍵是可能你用的時候並不自知，不知道自己所調用的東西裡面有使用了設計模式。

而且其實我覺得樓主的問題不是「有沒有用到」，而是有沒有「在自己的代碼裡面使用設計模式，而不是調用」。

總之就是大道至簡，要言不繁！

感覺沒啥用，就是面試的時候問的多，如果不用現成的架構，編寫基礎架構的時候用的比較頻繁，

但如果想成為一個編程大師，設計模式是必須要了解的

有幸參與過一個瑞典醫療設備改進項目的開發和本地化，是超導磁共振的軟體平台，原來的開發者設計了一個模塊專門實現該項目用到的設計模式，其他模塊調用或者以其為父類多重派生，我只能說北歐的軟體開發技術真心牛逼。

哎？學了半年unity，用了單例模式，觀察者模式，工廠模式。感覺有些地方不用就尷尬了。菜鳥如是說道。

喵喵喵喵喵？

單例模式算咩？哈哈哈。。。

不過觀察者倒是用。

寫了6年代碼，也就用過工廠，單例，委託，慚愧啊

沒用過不過自從這貨出來之後我寫的類名都是factory啊strategy啊啥的可以嚇唬嚇唬同事

設計模式可以起到便於溝通的作用，交流成本有時是很高的，尤其在程序員之間。

我自己做項目的時候沒有刻意去寫成什麼模式，順著框架來唄，框架怎麼寫我怎麼寫。

倒是在面試的時候，頻繁被問到，以至於我手機里抄了一些工廠模式之類的小抄，每次上陣抱一下佛腳。