設計模式真的有多重要？設計模式真的有多重要？
我覺得上一代的程序員沒有使用設計模式那麼多（人誰在80年代和90年代前中期畢業）。最近的畢業生是否知道這個問題並且使用更多？
如果你有興趣，我也做了一個調查，你可以在這裏查看：
http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d
更新：這裏有初步調查結果：
http://img192.imageshack.us/img192/7107/surveyresults.png
我們在80年代使用過設計模式，我們只是不知道它們是設計模式。
在我看來，設計模式的最大好處就是它爲開發人員提供了一個談論軟件解決方案的通用詞彙。
如果我說「我們應該使用單例模式來實現這個」，我們有一個共同的參考點來開始討論這是否是一個好主意，而不必先實際實施解決方案，這樣您就知道了什麼我的意思是。
添加可讀性和隨之而來對共同問題的解決熟悉的可維護性，而不是每個開發人員嘗試過的一次又一次解決自己的方式的問題。
非常重要的。軟件可以在沒有它們的情況下製作，但它肯定要困難得多。
他們不是絕對必要的，但良好的絕對遠遠多於壞的。
好：
壞：
重要的是我不會使用這個詞。我會用「有幫助」一詞。爲開發人員提供通用語言來描述頻繁出現的問題/解決方案非常有用 - 在協作環境中更是如此。
偉大的問題！我一個星期前就問自己這個問題。我儘可能使用它們，但是我沒有找到很多機會來使用它們。我個人認爲設計模式的想法很棒。機械工程師和電子工程師不是從頭開始設計，而是運用良好的理解模式，讓新手站在他們前輩所掌握的知識的肩膀上。設計模式是朝着正確方向邁出的一步，但需要更多步驟。
我想你錯過了什麼是設計模式。
在軟件工程中，設計模式是軟件設計中常見問題的通用可重用解決方案。
所以設計模式只是一個正式的語言來定義共同的方式來解決軟件工程問題。我想大多數人都在使用設計模式而不知道它們是。所以這些軟件問題的常見解決方案可以追溯到很長的一段時間，他們還沒有提出一種正式的語言來描述他們在做什麼。
我認爲設計模式很重要，因爲它們教會你如何解決設計模式適用的問題。
設計模式在CS的設計課程中教授。他們不是必不可少的，但是如果你能找到類似的情況來得到一個已經被認真思考的解決方案，這真的很有幫助。
它還允許程序員更容易地進行通信。您也可以根據模式與您的同事交談。如果你在這裏說我有我的觀察者，那麼它很好理解什麼是發生。人們自然會想出適合自己的設計模式的解決方案，但設計模式有助於定義可能有用的術語和標準想法。
這些模式沒有什麼超級顯着，最好的是他們是想法，這些想法是經過反覆使用的經典和定義。
我要說非常
設計模式的訣竅是學習何時何地使用它們。然後，可以做各種各樣的事情你喜歡：
但有時他們可以再次做一些有益處完全相反它知道如何以及何時...
你有沒有試過用框架錘子拉出一條條子？你可能會愛你誣陷錘，但如果你試圖用這種方式造成各種各樣的問題......
我認爲，當你重構你的代碼時，它有時會演變成一種特定的模式，或者你可能有一直在使用模式而沒有意識到它。
就我個人而言，我認爲他們大大超額支付和邊際價值。這個想法聽起來不錯，但是當你認真對待它時，實際上只有少數人能夠值得記住（並且可能記住）。
我想說他們的淨效應是負面的，這是由於新近癡迷於這個概念的人所犯下的醜陋的過度工程，並試圖將盡可能多的模式塞進他們的代碼中。也許更糟糕的是Maslow's hammer效應導致糟糕的設計，因爲開發人員沒有找到最佳的設計，而是記住了一個適合（很糟糕）的設計模式。
無論您是否知道您正在使用它們，軟件模式都很重要......根據定義。
設計模式只是一個廣義的，可重複使用的解決方案，以解決常見問題。
你可以破解，直到你重新發明你遇到的每一個問題的解決方案，或者你可以學習那些程序員已經使用了幾代人的「模式」。如果您對最常見的命名模式的知識進行形式化，那麼您將擁有一個共同詞彙來討論和應用解決方案。
享受，
羅伯特C. Cartaino
我找到邊際價值的設計模式。任何組織良好，設計完善的軟件框架都有數以百計的設計模式，其中很少被描述在正式的「模式文獻」中。
在設計模式出現之前，設計良好的軟件有很多模式可以在很多情況下重用。例如，Kernighan和Ritchie關於C的書包含了一個使用yacc和lex以及堆棧，符號表，函數指針傳遞（即基本上動態綁定）實現的計算器示例，並且包含大量用於圖書大小的模式。
您可能通過研究如何學習數百種更有用的設計模式。微軟的.NET框架，Java類庫等，而不是閱讀有關設計模式的書籍。
真的，好的軟件有一個設計。如果設計很好，它可能會被重新使用。瞧 - 一種設計模式。
我見過太多「小男孩有模式」綜合徵的例子。在一個人第一次閱讀GoF書的時候，通常會遇到最困難的情況，並且立即跑出去看看他們中有多少人可以適應他們正在進行的項目。 （將所有23個項目加入到一個項目中的額外要點）。它們最終會建立一個系統，在其生命的一英寸內進行設計，並且無法理解或修改。
最終發燒停了下來，他們安頓下來，足以適當地使用它們。但是傷害可能很大。
警告的故事是「核心Java EE模式」一書。它列出了一系列針對EJB 1.0和2.0的「最佳實踐」，現在被認爲是反模式。 EJB 3.0規範取消了很多。春天正在殺死其他人。
模式已經在陽光下的一天，像UML。但是太陽都在下降。我不認爲任何一個人拯救了世界或者宣傳了這個世界。
雖然有時會談論設計模式會很有用，但我傾向於認同那些在許多情況下認爲它們有害的人。
我想說的主要觀點是，他們經常會阻止人們針對特定問題提出適當的解決方案。與其思考如何解決特定問題，人們嘗試應用一種設計模式。
他們也傾向於隱瞞語言缺陷。它們中的很多都是足夠表達語言的小事。一個主要的例子就是戰略模式，它基本上是以複雜的方式重新編寫函數式編程。通常人們會更好地理解真正的編程原則，而不是僅僅談論模式語言。
話雖如此：我寧願與某人談論模式，也不願意有共同的語言。如果沒有更好的選擇，那麼它們就很重要。如果我能以更正式的方式解釋自己（例如代數），那麼我就不再關心模式語言。當然有人會聲稱我只是發明了我自己的模式語言;-)
我會說他們肯定很重要。
在典型的原因（共享詞彙，不重新發明車輪）中，它們是學習良好軟件設計的墊腳石。大部分的設計模式都是由程序員開始的，他們對面向對象的原則有着很好的理解，並運用他們所知道的解決問題的方法，並注意到其他人正在提出相同的解決方案。如果你將設計模式看作是一本食譜來解決你所困擾的當前問題，那麼它們並不是很有用，而這正是你看到「設計模式錘子」出現並使設計複雜化的地方。
如果不是將其視爲一個良好的面向對象設計的窗口，那麼您就會開始看到它們是多麼有價值，即根據設計模式背後的原則而不是特定設計模式本身來思考。
從考慮模式之前的原則開始，因爲它是通知和激勵模式出現的總體設計原則。
對於您的特殊問題，您最好遵循以下原則：首先。如果你到達了一個着名的模式，那麼恭喜你，你重新發現了一個模式，對你有好處。問題在於它可能需要很長時間，所以這取決於您是否想要冒險在發展過程中發明一些反模式，或者您是否想要一個已經發布的東西的快捷方式。考慮一下，因爲你會比閱讀他人對自己作品的描述學得更多。
下面的（這裏很多非常好的答案已經指出）是，你可能會試圖將一個已發佈的模式應用於不合適或不合理的情況下。
一個良好的開端與設計原理是通過看Uncle Bob Martin's SOLID principles，關於他們的好處，他們一旦下沉，就是你覺得你已經知道他們（它讓你覺得自己聰明）和
Bob大叔的書Clean Code也涵蓋了相同的原則很多的一些有用的例子，只是沒有那麼明確列舉的原則爲原創文章，集中更多的一般組織和整理你的函數，類等
評論設計模式如果你正在努力爲開源項目貢獻力量，那麼這很有用！
您可以發佈您的調查結果嗎？我對結果感興趣 – 2009-06-10 23:05:57
考慮到標籤「設計模式」已用於近1000個關於SO的問題中，我認爲單獨可以回答你的問題......或者至少有一個問題有答案。 – gnovice 2009-06-10 23:08:01
@Kwang肯定我會發布一些結果。有沒有辦法打開結果呢？如果可能，我想打開它。 – 2009-06-11 02:58:19