设计模式在现实世界中的渗透力是什么？我们是否在日常工作中使用它们，与同事讨论如何以及在何处应用它们，或者它们仍然具有更多的学术概念？

它们确实为工作提供了实际价值吗？还是仅仅是人们谈论的听起来很聪明的事情？

注意：出于此问题的目的，请忽略"简单"设计模式，例如Singleton。我说的是设计代码，以便可以利用Model View Controller等。

解决方案

回答

我尝试，是的。它们确实确实有助于代码的可维护性和可读性。但是，有些人确实在滥用它们，通常(从我所看到的情况)是通过将系统强制为不存在的模式来进行的。

回答

除了在"现实世界"中使用的简单之外，还有许多设计模式。一个很好的例子，Stackoverflow使用了模型视图控制器模式。我曾为雇主在项目中多次使用Class Factories，而且我也看到许多已经使用它们的书面项目。

我并不是说正在使用每种设计模式，但有很多正在使用。

回答

是的，我们会这样做，通常是在我们开始设计某些东西时发生的，然后有人注意到它类似于现有的模式。然后，我们看一下它，看看它如何帮助我们实现目标。

我们还使用未记录的模式，但是这些模式是从大量设计中得出的。

提醒我们，我们不会经常使用它们。

回答

是的，我每天使用的代码库中正在使用工厂，责任链，命令，代理，访问者和观察者等。就MVC而言，该站点似乎使用得很好，并且开发人员无法在最新的播客中说出足够多的好话。

回答

如果适用，我会尝试使用模式。我认为看到开发人员仅出于此目的而在代码中实现设计模式实在令人遗憾。对于正确的任务，设计模式可能非常有用且功能强大。

回答

是的，我使用了许多众所周知的设计模式，但最终我还构建了一些软件，后来发现它们使用的是"命名"设计模式。最优雅，可重复使用的设计可以称为"样式"。这很像舞步。我们都知道华尔兹和两步法，但并不是每个人都为"起伏和踏板车"起了个名字，尽管我们大多数人都这么做。

回答

MVC是众所周知的，所以是的，我们经常使用设计模式。现在，如果我们询问"四人组"模式，那么我会使用几种模式，因为其他维护人员会知道设计以及代码中的工作方向。尽管有许多内容对于我们的工作仍然相当晦涩，所以如果我使用一种方法，我将无法获得使用模式的全部好处。

它们是否重要，是的，因为它为我们提供了一种快速有效且普遍接受的方式来讨论软件设计的方法。我们能做更好的定制解决方案吗，是的(sorta)？

原始的GoF模式是从生产代码中提取的，因此它们将野外已经使用的目录归类。它们不是纯粹的，甚至绝不是学术性的。

回答

我发现MVC模式对于隔离模型逻辑非常有用，因此可以重用或者使用它而不会造成太多麻烦。它还有助于取消类的耦合，并使单元测试更加容易。我最近写了有关它(是的，这里是无耻的插件...)

另外，我最近使用了基类的工厂模式来生成并返回我使用LINQ即时所需的DataContext类。

在尝试将两种不同的技术(例如Mac上的Cocoa和Ruby)粘合在一起时，会使用网桥

但是，我发现，每当实现一个模式时，这是因为我事先知道它。我发现通常必须略微修改原始模式以适应我的需求，因此通常需要一些额外的考虑。

我们只需要注意不要成为建筑宇航员！

回答

编写良好的任何大型程序都将使用设计模式，即使它们没有这样命名或者识别。这就是设计模式，即反复自然发生的设计。如果我们使用的是丑陋的API，那么我们可能会发现自己实现了一个"门面"来清理它。如果在需要解耦的组件之间有消息传递，则可能会发现自己使用了"观察者"。如果我们有几种可互换的算法，则可能最终会使用"策略"。

值得一提的是了解设计模式，因为我们更有可能识别出它们，然后更快地收敛于干净的解决方案。但是，即使我们根本不了解它们，我们最终也会最终创建它们(如果我们是一个体面的程序员)。

当然，如果我们使用的是现代语言，我们可能会被迫将其用于某些方面，因为它们已被烘焙到标准库中。

回答

在我看来，"我们是否使用设计模式？"这个问题本身就有一点缺陷，因为答案通常是肯定的。

让我解释一下，我们，程序员和设计师都使用设计模式...我们并不总是意识到这一点。我知道这听起来很陈词滥调，但是我们不会去学习模式，而是会遇到模式。设计东西时，它看起来可能像一个现有模式，以这种方式命名，这样每个人都可以理解我们在说什么，并且知道以前曾被人们讨论过，因此设计决策的依据更强了。

我个人使用模式作为沟通工具。而已。它们不是设计解决方案，不是最佳实践，也不是工具箱中的工具。

不要误会我的意思，如果我们是初学者，那么有关模式的书籍将向我们展示如何最好地"使用"其模式而不是另一个有缺陷的设计来解决方案。我们可能会从练习中学到东西。但是，我们必须意识到，这并不意味着每种情况都需要相应的模式来解决。每种情况在这里和那里都有一个怪癖，这将要求我们考虑替代方案，并在没有完美答案的情况下做出困难的决定。那是设计。

但是，反模式的类别完全不同。我们实际上想积极地避免使用反模式。这就是为什么反模式这个名字引起争议的原因。

回到我们最初的问题：
"我使用设计模式吗？"，是的！
"我是否积极倾向于设计模式？"，否。

回答

我绝对使用设计模式。在这一点上，我认为MVC是理所当然的设计模式。使用它们的主要理由是我很谦虚，以至于我很可能不是第一个遇到特定问题的人。我很少开始编写一段代码，不知道我要使用哪种模式。我一直在看代码，看它是否自然地发展成现有的模式。

我也非常喜欢Martin Fowler的企业应用程序体系结构模式。当出现问题或者任务时，我会转到相关部分(主要是参考书)并阅读一些模式概述。一旦我对一般问题和现有解决方案有了更好的了解，我便开始看到我的代码将通过他人的经验而走的长途之路。我最终做出了更好的决定。

设计模式无疑在我所有的"面向未来"思想中都扮演着重要角色。

回答

是的，与我一起工作的许多人在现实世界和日常工作中都广泛使用设计模式。

在我看来，设计模式所提供的最大价值是，它们为我们提供了一种通用的高级语言，可以将软件设计传达给其他程序员。

例如，我们不必简单地将新类描述为"根据输入条件的某种组合来创建其他几个类之一的实用程序"，而可以简单地说这是"抽象工厂"，并且每个人都立即理解我们在说什么。

回答

是的。如果正确使用设计模式，可能会很棒。如我们所提到的，我现在对我的所有Web项目都使用Model-View-Controller(MVC)。这是Web空间中的一种非常常见的模式，它使服务器端代码更加简洁和井井有条。

除此之外，还有一些其他有用的模式：

• MVVM(Model-View-ViewModel)：与MVC类似的模式；用于WPF和Silverlight应用程序。
• 组合：非常适合当我们需要使用对象层次结构时使用。
• Singleton：比使用全局变量存储确实需要单个实例的项目要优雅。如我们所述，这是一个简单的模式，但确实有其用途。

值得注意的是，设计模式也可以突出语言的缺乏和/或者语言的不足。例如，迭代器现在作为新语言的一部分内置。

通常，设计模式很有用，但我们不应在任何地方都使用它们。正是它们非常适合需求。

回答

是的，设计模式或者抽象模式是我生活的一部分，在我所看到的地方，我开始看到它们。因此，我被他们包围了。但是，正如我们所知，很少的知识是危险的事情。因此，强烈建议我们阅读GoF书。

关于设计模式的主要问题之一，大多数开发人员只是不了解或者不相信它们。而且大多数时候，他们都在争论变量，循环或者开关。但是，我坚信，如果我们不讲模式语言，软件就不会走得太远，我们将陷入维护噩梦。

如我们所知，反模式也是很危险的事情，当我们对设计模式缺乏专门知识时，它就会发生。重构反模式要困难得多。作为有关此问题的推荐书，请阅读" AntiPatterns：危机中的重构软件，体系结构和项目"。