你使用设计模式吗？

Question

现实世界中设计模式的渗透是什么？您是否在日常工作中使用它们 - 讨论如何以及在何处将它们应用于您的同事 - 或者它们是否更像是学术概念？

他们真的为您的工作提供实际价值吗？或者他们只是人们谈论听起来聪明的东西？

注意：出于此问题的目的，请忽略“简单”设计模式，例如 Singleton 。我正在谈论设计代码，以便您可以利用模型视图控制器等。

Answer 1

任何写得很好的大型程序都会使用设计模式，即使它们没有被命名或识别。这就是设计模式，重复设计和自然的设计。如果您与丑陋的API接口，您可能会发现自己正在实施Facade来清理它。如果您需要在需要解耦的组件之间进行消息传递，您可能会发现自己正在使用Observer。如果您有多个可互换的算法，最终可能会使用Strategy。

值得了解设计模式，因为您更有可能识别它们，然后更快地收敛于清洁解决方案。但是，即使你根本不了解它们，你最终也会最终创建它们（如果你是一个不错的程序员）。

当然，如果您使用的是现代语言，您可能会被迫将它们用于某些事情，因为它们已经融入标准库中。

Answer 2

在我看来，问题是：“你使用设计模式吗？”，单独存在一点缺陷，因为答案普遍是肯定的。

让我解释一下，我们，程序员和设计师都使用设计模式......我们并不总是意识到这一点。我知道这听起来很陈词滥调，但你不去模式，模式来找你。你设计的东西，它可能看起来像一个现有的模式，你这样命名，所以每个人都明白你在说什么，你的设计决策背后的理由更强，知道之前已经讨论过 ad nauseum

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

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

然而，反模式是完全不同的类。您实际上希望 主动避免反模式。这就是反模式这个名称如此具有争议性的原因。

回到原来的问题：
“我使用设计模式吗？”，是的！ “我是否积极倾向于设计模式？”，不，

Answer 3

是。如果使用得当，设计模式可以很精彩。正如您所提到的，我现在正在为我的所有Web项目使用模型 - 视图 - 控制器（MVC）。它是Web空间中非常常见的模式，它使服务器端代码更加清晰和组织良好。

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

• MVVM（Model-View-ViewModel）：与MVC类似的模式;用于WPF和Silverlight应用程序。

• 组成：非常适合需要使用对象层次结构的时候。

• Singleton：比使用globals存储真正需要单个实例的项目更优雅。正如您所提到的，一个简单的模式，但确实有它的用途。

值得注意的是，设计模式还可以突出显示语言缺乏语言特征和/或缺陷。例如，迭代器现在作为较新语言的一部分构建。

一般来说，设计模式非常有用，但你不应该在任何地方使用它们;只是它们非常适合您的需求。

Answer 4

我试着，是的。它们确实有助于代码的可维护性和可读性。但是，有些人通常会（通过我所见）滥用它们，将系统强制转换为不存在的模式。

Answer 5

如果适用，我会尝试使用模式。我认为看到开发人员为了它而在代码中实现设计模式有点令人遗憾。但是，对于正确的任务，设计模式可能非常有用和强大。

Answer 6

除了“真实世界”中使用的简单之外，还有许多设计模式。好示例Stackoverflow使用模型视图控制器模式。我已经在我的雇主的项目中多次使用类工厂，我已经看到许多已经编写的项目也使用它们。

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

Answer 7

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

我们还使用未记录但从设计中出现的模式。

请注意，我们不会经常使用它们。

Answer 8

是的，工厂，责任链，命令，代理，访问者和观察者等都在我每天使用的代码库中使用。就MVC而言，这个网站似乎很好地使用它，并且开发人员在latest podcast中无法说出足够好的东西。

Answer 9

是的，我使用了许多众所周知的设计模式，但我最终还是构建了一些软件，我后来发现这些软件使用的是“命名”设计模式。大多数优雅，可重复使用的设计可称为“模式”。这很像舞蹈动作。我们都知道华尔兹和两步，但不是每个人都有“撞击和滑行”的名称，尽管我们大多数人都这样做。

Answer 10

MVC非常有名，所以我们使用的设计模式非常多。现在，如果您询问“四人帮”模式，我会使用几个，因为其他维护人员将了解设计以及我们在代码中正在努力的方向。有几个虽然对我们的工作仍然相当模糊，所以如果我使用一个我没有得到使用模式的全部好处。

它们是否重要，是的，因为它为您提供了一种以快速有效且普遍接受的方式讨论软件设计的方法。你能做更好的自定义解决方案吗，是的（sorta）？

原始的GoF模式是从生产代码中提取的，因此他们编制了已经在野外使用的内容。它们不是纯粹的，甚至不是学术性的东西。

Answer 11

我发现MVC模式对于隔离模型逻辑非常有用，它可以重复使用或工作而不会有太多麻烦。它还有助于解耦类，使单元测试更容易。我写了recently（是的，这里无耻插件......）

另外，我最近使用基类的工厂模式使用LINQ生成并返回我需要的正确DataContext类。

在尝试将两种不同技术（例如Mac上的Cocoa and Ruby）粘合在一起时尝试使用网桥。

但是，我发现每当我实现一个模式时，都是因为我事先就知道了。一些额外的想法通常会进入它，因为我发现我必须稍微修改原始模式以满足我的需要。

你只需要小心不要成为architecture astronaut！

Answer 12

是的，设计模式主要用于现实世界 - 我和许多人一起每天使用。

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

例如，不是将新类描述为“基于输入条件的某种组合创建其他几个类之一的实用程序”，而是简单地说它是“抽象工厂”和每个人立刻明白你在说什么。

Answer 13

是的，设计模式或抽象图案是我生活的一部分，在我看来，我开始看到它们。因此，我被他们包围了。但是，正如你所知，小知识是一件危险的事情。因此，我强烈建议您阅读GoF书籍。

关于设计模式的一个主要问题，大多数开发人员只是没有理解，或者不相信它们。大多数时候，他们争论变量，循环或开关。但是，我坚信如果你不说模式语言，你的软件就不会走得太远，你会发现自己处于维护噩梦中。

如您所知，反模式也是危险的事情，当您对设计模式缺乏专业知识时就会发生这种情况。重构反模式要困难得多。作为有关此问题的推荐书，请阅读“AntiPatterns：重构软件，架构和危机中的项目”。

Answer 14

是

我们甚至在目前的工作中使用它们：使用COBOL和PL / I进行大型机编码。

到目前为止，我已经看到了Adapter，Visitor，Facade，Module，Observer以及与Composite和Iterator非常接近的东西。由于语言的性质，它主要使用的是strutural模式。此外，我并不总是确定使用它们的人这样做是如此有意义：D

Answer 15

我绝对使用设计模式。在这一点上，我认为MVC是一种设计模式。我使用它们的主要原因是我很谦虚地知道我可能不是第一个遇到特定问题的人。我很少知道我将要使用哪种模式的代码;我不断观察代码，看它是否自然地发展成现有的模式。

我也非常喜欢Martin Fowler's Patterns of Enterprise Application Architecture。当一个问题或任务出现时，我转到相关部分（它主要是参考书）并阅读一些模式的概述。一旦我对一般问题和现有解决方案有了更好的了解，我就会开始看到我的代码可能通过其他人的经验获得的长期路径。我最终做出了更好的决定。

设计模式无疑在我的所有“未来”想法中发挥了重要作用。