从书本的角度来看，你可能会说x设计模式适用于y场景，但我想在这里深入挖掘一下。所以这是我的疑问：
修改
我想补充一点，我通过“头部设计模式”阅读DP，虽然它是理解模式的最佳书籍之一。我认为我无法将Pizza示例转换为真实场景。
我认为这是关于DP的最有影响力的书之一，但我们仍然可以有一本书可以列举各种流行的商业场景，这些场景需要特定的模式以及该模式。我认为这种知识在很大程度上仍然隐含着。这样一本书将是一个非常好的快速参考你不认为：））
答案 0 :(得分：9)
使用设计模式处理如何和时（不）使用设计模式的两本好书：
答案 1 :(得分：9)
这取决于您编写代码的方式。如果这是我在编码之前决定的一个大项目，那么在我开始编写代码之后，如果我注意到应该使用设计模式的地方，我会重构代码。
是的，如前所述。
在99.99％的案例中：Factory Pattern，Singleton（就像我在很多地方使用它的人一样，因为它很容易实现，而且在实践中我倾向于在重构时删除它码）。 然后：Object Pool（如果我有资源我想重用 - 我的一些项目是游戏，我需要一个良好的资源管理），战略和模板方法（因为它们非常适合解耦并且很好地服务于使代码易于扩展）。然后，当你有一个你想要使用的库时，可以使用适配器，而不依赖它（解耦）。
如上所述，如果我还没有使用它们。它也以相反的方式起作用。如果我没有找到使用设计模式的原因，我会在编写代码时将其删除或跳过它（它一直发生在单例和工厂不时。有时我使用的工厂也是单例为我提供那些应该是单身人物的东西;不确定这是否是明智之举，但它对我有用。）
唯一的代码提示我可能会认为你对一个类的引用数量。您还可以使用PMD，jDepend和Architecture Rules来查看类包含太多依赖项的位置。我不确定这是一个编码提示。在设计阶段，不仅在您决定使用设计模式时，只需考虑其优点。我发现软件Design Principles对于帮助您了解何时以及为何（不）使用设计模式非常重要，但许多正在使用design patterns的程序员都不知道它们。
我不确定Micro DP是什么意思。我只是在找到使用它们的理由时才尝试使用DP，而且好处似乎比问题更大。我避免过度使用，因为它会导致您失去实施和维护工厂模式的时间而不是真正的软件。
答案 2 :(得分：6)
我认为，至少对于那些新学习设计模式的人来说，有一种倾向，即过度应用模式;当你有一把锤子时，一切都开始像钉子一样。更好的方法是考虑API的替代方案及其各自的优势和权衡，然后选择合适的方法。设计模式更多的是术语帮助，允许开发人员有效地传达他们正在做的事情，而不是提供如何编写代码的指南。也就是说，有些东西在代码中重复出现，并且更容易告诉你的同事你使用工厂而不是解释你有一些你传递的对象创造了其他对象......但仅仅因为工厂的概念确实存在并不意味着你应该尝试将你看到的所有东西都变成工厂。有意义吗？
答案 3 :(得分：3)
设计模式描述了在给定上下文中针对周期性问题的一般可重用解决方案。当您识别模式可以解决的设计问题时，可以应用模式。这可能发生在初始设计，编码期间，维护期间等。没有绝对的配方，IMO。
答案 4 :(得分：3)
1＆amp; 2
我认为这是错误的方法，只是盲目地决定一个喜欢的模式，或者第一个代码，然后重构一个已知的模式。当您发现问题时，您必须认识到与使用已知模式可能解决的其他问题的相似性。
模式不是成功的食谱;这是一个经验法则。阅读关于模式的书中的案例可以帮助您识别问题，从而避免您从一两个错误中解决。
3：主要的模式在很大程度上取决于域名。在进行与其他系统进行大量通信的应用程序时，状态模式，代理和外观非常常见。 GUI应用程序有不同的要求等。
在我的行业（银行业）：我看到了很多以下的GOF模式：工厂方法，单例，适配器和外观。行为模式或多或少地被10年前模式化的java-ee 14层反模式所杀死。
4：重构时 - 如果模式对你有所帮助，请使用它。在重构时，没有一类模式更适合。
5：我认为特定模式的主要指标与问题更相关，与特定模式解决的其他问题相似。是的，如果代码闻起来，这表明它可能需要重写，并且应该再次分析问题。虽然有些问题很复杂，而且无法减少，但大多数问题和模式可能有助于整理问题。
然而。由于观察到复杂的问题需要复杂的解决方案，厚厚的人倾向于编写复杂的代码;那是为了什么。例如。状态模式（我喜欢它）如果过度使用，可能会使事情变得难以想象。
6：我的同事似乎喜欢我，所以我可能不会做任何事。我对自己过度使用工厂和工厂方法的代价感到非常恼火，这些代码不太可能同时改变或存在于不同的实现中 - 如果它最终会被改变，那么无论如何都需要重写。这只是浪费时间，并使代码复杂化并延迟错误搜寻。答案 5 :(得分：1)
根据我的经验，它取决于何时应用模式的前期设计的方法和水平。通常在敏捷过程中，我会看到一个模式很快就会出现，因为代码的意图会发展，然后相应地重构。
冒险说明明显的单元测试可以减轻很多风险，但是越早越好。我从来没有做过一个主要的代码重构来支持实现一个新的模式，因为所涉及的努力很少显示出显着的好处。除非项目即将进入新的发展阶段。
一个或两个方法中包含的小型重构在项目的整个生命周期中都相当普遍，但这些都是假设没有“代码完成”这样的东西：）
答案 6 :(得分：0)
IMO，没有任何规则或常见情况。设计模式在适当的时候使用，有时你在设计时就知道了，有时在编码时，有时在重构时。
大多数时候我不会“一对一地应用设计模式”。他们需要适应。设计模式就像一个经验目录。您只需了解一些常见或典型的模式，并将其更改为您需要的解决方案。 （注意：它们是模式，而不是解决方案。）
答案 7 :(得分：0)
不要忘记这本书Design Patters，它可能涵盖C ++，但它并不重要，它是所有模式。除了这本书非常好。
你没有学习实现它们的模式，这是错误的方式，你学习了所以你可以与其他程序员讨论代码。它更像是对您的正常语言的扩展，而不是其他任何东西。在需要时在代码中使用它，但之前不能： - ）
答案 8 :(得分：0)
我会采取不同的方法，不提书或单独解决所有这些问题。
就我而言，我从呼吸中获得了最好的影响SOLID。 Imho你可以联系很多场景＆amp;这些原则的模式，并遵循不断发展的代码基础思维模式，通常会为您揭示所有其他模式的需求。
至于提示，长方法=＆gt;重构。即使它只是转向同一类中的方法，因为通常中间步骤会显示下一步。