设计模式何时成为问题而非解决方案？

设计模式被定义为以下内容（来自维基百科，但我也在一些书中看到了相同的内容）

在软件工程中，设计模式是解决软件设计中常见问题的通用可重用方案。设计模式不是可以直接转换为代码的完成设计。它是描述或模板，用于解决可以在许多不同情况下使用的问题。

如果你从一开始就应用设计模式而没有深入了解问题域，可能会导致问题。将设计模式用作指南或提示来解决问题。强制应用设计模式肯定不能提供足够抽象的解决方案。通常在企业软件中使用几种设计模式的变体或组合..有点像杂交。如果你说你从未使用过设计模式，那么你会很高兴知道像 foreach 循环实际上是一个迭代器模式，并且你可以在你身边寻找更明显的实现！

简而言之，设计模式只是各种语言中解决常见任务的正式方式。因此，在有人创造术语之前就已经存在“设计模式”。对于每种语言，都有“最佳实践”，而设计模式实际上就是解决定期出现的问题的一组最佳实践。
标记模式的主要好处之一是共享术语允许我们谈论抽象概念。
显然，设计模式可以在任何给定情况下被误用或过度使用，但我真的看不出作为一个概念的设计模式会成为问题。

当我使用LISP编程时，我根本没有使用GoF设计模式，因为它并不适用于我所编写的程序。现在我正在使用C#进行编程，并且经常遇到一些情况，其中设计模式实际上可以简化正在编写的程序。

万物皆有时，万事皆有处。我见过代码中使用了太多的模式，这会支持你的观点，但也有可能出现模式不足的情况，使得代码难以维护，在进行更改时容易出错。

像这样概括性地说是有逻辑缺陷的，但如果你将问题重新表述为“在代码中是否存在过多的模式，这表明了一个更大的问题，即缺乏足够的抽象层次”，那么答案就是肯定的。但并不总是这种情况。

有很多我们使用的格言（在SO上很常见），如果你追溯它们的源头，最初都是带着保留的断言，比如“…当你使用…”。这就是其中之一。设计模式适用于面向对象编程。当你处于另一种范式时，可能会有所不同。
“重构”是另一个类似的情况。
当我写SQL时，我的“模式”大脑部分关闭了。
注意你引用中的内容：“我手动生成我需要编写的某些宏的扩展。” 所以他识别出模式并将其抽象成宏 - 他不会用另一种方式重新编码它。只是好老的DRY原则。问题不在于模式，而在于没有正确地处理我们发现的模式。我会说他的评论可以放到任何扩展DRY优点及如何掌握它们的维基条目中。GoF完全赞同 - 认识设计模式，然后利用你对它们的了解来适当地实现（或重构）它们。

在我的程序设计阶段，我经常首先分解问题，一旦我将其分解开来，就可以轻松地开始识别设计中固有的模式。此时，我可以开始应用众所周知的设计模式，以便在通信或实现设计时，我有一个可以用于通信的共同语言，并且希望我可以重复使用之前在实现类似模式时实现的一些通用对象。
通常情况下，当设计模式被错误地应用时，是因为该过程发生了反转。程序员Joe（对于那些名为Joe的人，我道歉）读了一本关于设计模式的书，然后说：“好的，我理解了设计模式X，现在该如何将它应用到我的应用程序中？”这是错误的。 设计模式可以是一种强大的武器，但像任何其他东西一样，它们应该得到适当的使用，程序员也应该随时准备将一些原创思想融入到他的设计中。

我认为有时候当你学习一种模式时，你不仅仅是学习这个模式。而是获得了一个在问题领域中之前可能没有的新视角。也许这正是你想要的。

如果没有“问题”的背景，我们无法确定设计模式是否是解决方案。

没有必要使用设计模式——你总是可以编写忽略到目前为止所学习的所有编码知识的代码——它甚至可能会工作。但是设计模式可以使事情变得更加容易，为你提供了一个共享的语言来讨论设计。

设计模式并不代表过于少的抽象——它们试图增加抽象级别。你可以说“这一部分是访问者”，而不是“这里是一些递归遍历对象树，在其上执行某个操作的代码。”

如果模式不是解决方案，那么它们就是问题。我指的是：如果引入模式只是为了模式而不是为了解决应用程序中真实存在的设计问题，那么它很可能会导致问题而不是解决或预防问题。
我一直告诉同事们，在工作中《设计模式：可复用面向对象软件的基础》这本四人组的书是参考书，而不是好设计的手册。

是的，pg就在那里。如果你在整个应用程序中看到类似的代码，那么这意味着你缺少对该代码的抽象。更少的代码更好。

这里有另一篇关于这个主题的文章：http://blog.plover.com/prog/design-patterns.html