选择正确的设计模式

我一直都认识到利用设计模式的重要性。我对其他开发人员如何选择最合适的开发人员感到好奇。您是否使用一系列特征（例如流程图）来帮助您做出决定？

例如：

如果对象是相关的，但是我们不想指定具体的类，请考虑Abstract

将实例化留给派生类时，请考虑使用Factory

需要顺序访问聚合对象的元素，请尝试使用Iterator

或类似的东西？

在当今的编码世界中，一个关键的误解是模式是构建块。您在AbstractFactory这里和Flyweight那里，甚至可能Singleton在那儿，然后将它们与XML和presto连接在一起，您就有了一个可以正常工作的应用程序。

他们不是。

嗯，还不够大。

模式不是构件

这样更好

模式是在发现问题时使用的东西-您需要该模式提供的灵活性，或者在配置文件中使用少量语言时偶然发现并且说“等待”请稍等，这是我正在编写的自己的解释器-这是一个已知且已解决的问题，请使用Interpreter模式。”

但请注意，这是您在代码中发现的东西，而不是您一开始就发现的东西。Java的创作者并没有说“哦，我们会把在整数飞锤”在一开始，而是意识到这可能是一个性能问题解决由轻量级。

因此，没有可用于查找正确模式的“流程图”。模式是针对一再遇到的特定类型问题的解决方案，并将其关键部分精炼成模式。

从模式开始就像有一个解决方案并寻找问题。这是一件坏事：它导致过度的工程设计，最终导致设计上的灵活性。

在编写代码时，当您意识到自己正在编写工厂时，可以说“啊哈！这就是我要编写的工厂”，并利用您了解工厂模式的知识快速编写下一篇文章。代码，而无需尝试重​​新发现Factory模式。但是您不会以“我在这里有一个班级，我将为其编写一个工厂以便它可以变得灵活”开始，因为它不会。

这是来自Erich Gamma（来自Gamma，Helm，Johnson和Vissides的访谈）的摘录：如何使用设计模式：

尝试使用所有模式都是一件坏事，因为您最终将获得综合设计，即具有没有人需要的灵活性的推测性设计。这些天软件太复杂了。我们无法推测它还应该做什么。我们需要真正专注于它的需求。这就是为什么我喜欢重构模式。人们应该了解到，当他们遇到一种特殊的问题或代码异味时，正如如今人们所说的那样，他们可以转到模式工具箱中找到解决方案。

“何时使用什么内容”的最佳帮助可能是软件设计模式的Wikipedia页面-“分类和列表”部分描述了每种模式所处的类别及其作用。没有流程图；可能会有最好的描述，作为“何时使用什么”的简短摘要。

请注意，您会在不同的编程领域中找到不同的模式。Web设计具有其自己的模式集，而JEE（而非Web设计）具有另一组模式。金融编程的模式与独立应用程序UI设计的模式完全不同。

因此，将它们全部列出的任何尝试本质上都是不完整的。您找到一个，弄清楚如何使用它，然后它最终成为第二天性，而您无需考虑如何或何时再次使用它（直到有人要求您解释它）。

我问我自己：

1. 我想解决什么问题？
2. 哪种软件设计模式（如果有）最能解决相同的问题，或者提供解决我的问题的逻辑途径？
3. 我是否需要该模式提供的其他抽象（和复杂性），还是为我的特定问题过度设计？没有这种模式，能否以更简单，更有效的方式解决问题？

选择软件模式的过程与选择数据结构的过程没有什么不同，除了选择数据结构时，您将评估问题的性能和内存特征，然后选择最适合这些特征的数据结构。