Do you use design patterns?设计模式在现实世界中的渗透力是什么？ 您是否在日常工作中使用它们-与同事讨论如何以及在何处应用它们-还是它们仍然具有更多的学术概念？ 它们确实为您的工作提供了实际价值吗？ 还是只是人们谈论的听起来很聪明的东西？ 注意：出于这个问题的目的，请忽略"简单"设计模式，例如Singleton。 我说的是设计代码，以便可以利用Model View Controller等。
编写良好的任何大型程序都将使用设计模式，即使它们没有这样命名或识别。这就是设计模式，即反复自然发生的设计。如果您使用的是丑陋的API，则可能会发现自己实现了 值得了解设计模式，因为您更有可能识别出它们，然后更快地收敛于干净的解决方案。但是，即使您根本不了解它们，您最终也会最终创建它们(如果您是一个体面的程序员)。 当然，如果您使用的是现代语言，您可能会被迫将它们用于某些方面，因为它们已被烘焙到标准库中。 在我看来，"您是否使用设计模式？"这个问题本身就有一点缺陷，因为答案通常是肯定的。 让我解释一下，我们，程序员和设计师都使用设计模式...我们并不总是意识到这一点。我知道这听起来有些陈词滥调，但是您不会去了解模式，而是会遇到模式。在设计东西时，它看起来可能像一个现有的模式，用这种方式命名，这样每个人都可以理解您在说什么，并且知道以前已经被讨论过，因此设计决策的依据更强了。 我个人将模式用作沟通工具。而已。它们不是设计解决方案，不是最佳实践，也不是工具箱中的工具。 别误会，如果您是初学者，有关模式的书籍将向您展示如何最好地"使用"其模式而不是另一个有缺陷的设计来解决方案。您可能会从练习中学到东西。但是，您必须意识到，这并不意味着每种情况都需要相应的模式来解决。每种情况到处都有一个怪癖，这将要求您考虑替代方案，并在没有完美答案的情况下做出困难的决定。那是设计。 但是，反模式的类别完全不同。您实际上想积极地避免使用反模式。这就是为什么反模式的名称引起争议的原因。
回到您最初的问题： 是。如果正确使用设计模式，可能会很棒。如您所提到的，我现在对我的所有Web项目都使用Model-View-Controller(MVC)。这是Web空间中的一种非常常见的模式，它使服务器端代码更加简洁和井井有条。 除此之外，还有一些其他有用的模式：
值得注意的是，设计模式也可以突出语言的缺乏和/或语言的不足。例如，迭代器现在作为新语言的一部分内置。 通常，设计模式很有用，但您不应在任何地方都使用它们。正是它们非常适合您的需求。 如果适用，我会尝试使用模式。我认为看到开发人员仅出于此目的而在代码中实现设计模式实在令人遗憾。对于正确的任务，设计模式可能非常有用且功能强大。 我尝试，是的。它们确实确实有助于代码的可维护性和可读性。但是，有些人确实在滥用它们，通常(根据我的观察)是通过将系统强制为不存在的模式。 是的，我每天使用的代码库中正在使用工厂，责任链，命令，代理，访问者和观察者等。就MVC而言，该站点似乎使用得很好，并且开发人员无法在最新的播客中说出足够多的好话。 是的，我们会这样做，通常是在我们开始设计某些东西时发生的，然后有人注意到它类似于现有的模式。然后，我们看一下它，看看它如何帮助我们实现目标。 我们还使用未记录的模式，但是这些模式是从大量设计中得出的。 提醒您，我们不会经常使用它们。 除了在"现实世界"中使用的简单之外，还有许多设计模式。一个很好的例子，Stackoverflow使用了模型视图控制器模式。我曾为雇主在项目中多次使用Class Factories，而且我也看到许多已经使用它们的书面项目。 我并不是说正在使用每种设计模式，但有很多正在使用。 是。 我们甚至在我目前的工作中使用它们：使用COBOL和PL / I进行大型机编码。 到目前为止，我已经看到了Adaptor，Visitor，Facade，Module，Observer以及与Composite和Iterator非常接近的东西。由于语言的性质，大多使用结构化模式。另外，我并不总是确保使用它们的人会自觉地：D 是的，设计模式或抽象模式是我生活的一部分，在我所看到的地方，我开始看到它们。因此，我被他们包围了。但是，正如您所知，很少的知识是危险的事情。因此，强烈建议您阅读GoF书。 有关设计模式的主要问题之一，大多数开发人员只是不了解或不相信它们。而且大多数时候，他们都在争论变量，循环或开关。但是，我坚信，如果您不讲模式语言，则您的软件不会走得太远，您将陷入维护噩梦。 如您所知，反模式也是很危险的事情，当您对设计模式缺乏专门知识时，它就会发生。重构反模式要困难得多。作为有关此问题的推荐书，请阅读" AntiPatterns：危机中的重构软件，体系结构和项目"。 是的，设计模式在现实世界中被广泛使用-与我一起工作的许多人每天都在使用这种模式。 我认为设计模式提供的最大价值是，它们为您提供了一种通用的高级语言，可以将软件设计传达给其他程序员。 例如，您不必将新类描述为"根据输入条件的某种组合来创建其他几个类之一的实用程序"，而可以简单地说这是"抽象工厂"，并且每个人都立即理解您在说什么。 我发现MVC模式对于隔离模型逻辑非常有用，可以很容易地重用或使用它。它还有助于取消类的耦合，并使单元测试更加容易。我是最近写的(是的，这里是无耻的插件...) 另外，我最近使用了基类的工厂模式来生成并返回我使用LINQ即时所需的DataContext类。 尝试将两种不同的技术(例如Mac上的Cocoa和Ruby)粘合在一起时，会使用网桥 但是，我发现，每当实现一个模式时，这是因为我事先知道它。我发现通常必须略微修改原始模式以适应我的需求，因此通常需要一些额外的考虑。 您只需要注意不要成为建筑宇航员！ MVC是众所周知的，所以是的，我们经常使用设计模式。现在，如果您询问"四人组合"模式，那么我会使用几种模式，因为其他维护人员会知道设计以及代码中的工作方向。尽管有一些内容对于我们所做的工作仍然相当模糊，所以如果我使用一种方法，我将无法获得使用模式的全部好处。 它们重要吗，是的，因为它为您提供了一种快速有效且普遍接受的方式来讨论软件设计的方法。您能做更好的定制解决方案吗，是的(sorta)？ 最初的GoF模式是从生产代码中提取出来的，因此它们将已经在野外使用的目录归类。它们不是纯粹的，甚至绝不是学术性的。 是的，我使用了许多众所周知的设计模式，但最终我还构建了一些软件，后来发现它们使用的是"命名"设计模式。最优雅，可重复使用的设计可以称为"样式"。这很像舞蹈动作。我们都知道华尔兹和两步法，但并不是每个人都为"起伏和踏板车"起了个名字，尽管我们大多数人都这么做。 我绝对使用设计模式。在这一点上，我认为MVC是理所当然的设计模式。使用它们的主要理由是我很谦虚，以至于我很可能不是第一个遇到特定问题的人。我很少编写一段代码就知道我要使用哪种模式。我一直在看代码，看它是否自然地发展成现有的模式。 我也非常喜欢Martin Fowler的企业应用程序体系结构模式。当出现问题或任务时，我会转到相关部分(主要是参考书)并阅读一些模式概述。一旦我对一般问题和现有解决方案有了更好的了解，我就会开始看到我的代码将通过他人的经验而走的长途之路。我最终做出了更好的决定。 设计模式无疑在我所有的"面向未来"思想中都扮演着重要角色。 |
