我正在閱讀，Erich Gamma和其他人寫的"Design Patterns:Elements of Reusable Object-Oriented Software"。我決定做一些小型項目，以查看將設計模式應用於我編寫的軟件的實際結果。應該嚴格設計模式的實現嗎？
我應該如何嚴格執行它們？我在互聯網上看到了一些實現interpreter pattern的例子，它們只是跳過實現中的整個類/接口/方法。是否應該允許做同樣的事情，還是嚴格執行以避免未來的問題，例如預支持功能？或者，設計模式不能被看作是對所有事物的答案，並且它們是否應該適用於當前情況，即特定於代碼？
沒有銀子彈。設計模式是一個指導原則，是過去可以爲其他人解決常見問題的可重用設計的公式。但是，如果有這種模式的某些部分會不必要地使您的軟件複雜化，那麼使用它並不是完全必要的。
設計模式的目標是簡化和簡化您的設計。如果不這樣做，這是不值得使用的。
其他人可能會有不同的意見。
這就是爲什麼他們被稱爲模式而不是算法或接口。
它們是設計的一般描述，不斷出現在應用程序中。每個實現都將專門用於它所使用的情況，儘管其做事方式的總體模式是相同的。
對於任何你使用設計模式的事情，你應該能夠問自己一個簡單的問題：這是如何使我的軟件更好？具體說一下。如果你不能列出在你的具體情況下實現設計模式的具體優勢，不要打擾;同樣，如果你得到了模式的「主旨」，你很可能會實現對你的情況有用的部分。
設計模式書在這裏特別好 - 他們列出了使用每種模式的具體優點，以及詳細的案例，他們是適當的，爲什麼。
正如曾經指出的那樣，using your brain是編寫優秀軟件的最佳方式。一切都取決於具體情況。
除了Ian Varley的觀點：「這是如何使我的軟件更好？」您可以從該語句中提取以下內容：「這是否會減少我的軟件的複雜性？」在設計軟件和設計模式時，管理複雜性至關重要。
應該支持預支持功能嗎？
這取決於你如何儘快需要這種功能，以及你如何絕對肯定是，你會需要它所有，但往往答案是「不」：谷歌的長期YAGNI
那麼，我的意思是設計模式的目的之一是可重用性，我可以在其他項目中重用代碼。
我的政策和/或YAGNI政策往往是：
這兩個步驟是更快，eaier，如果我沒有在第一時間落實，再不需要以後更改，功能，我甚至不有任何需要還。
幾乎每個讀這本書的人都會淪爲「帶模式的小男孩」綜合徵。您開始尋找將模式注入代碼的方法，無論它們是否合適。最後，你要冷靜下來，認識到這本書與通信詞彙一樣，是關於代碼行的。
這是一本了不起的書，一個經典。如果你看看Java或C＃SDK，你會發現它們充滿了各種例子（例如，Java RMI中的Proxy，java.io中的Decorator，java.sql中的Factory和JDBC等）
但是我發現它們在開發過程中被發現時效果最好，而不是強制提供給代碼庫。
順便說一句，你鏈接到「http://www.interpreter_pattern.com/」，這是你的意思？ :) – Grundlefleck 2009-01-11 22:26:27
哈哈不，現在修復;-) – 2009-01-11 22:38:12