在使用设计模式时，我猜想有三种类型的商店。那些不知道是否会在脸上碰到图案的人通常会选择Ctrl-C / Ctrl-V方式进行代码重用。那些每天花几个小时搜索其遗留代码以希望实现一种更好的模式的人，通常比重构一百年的维护花费更多的时间来重构简单程序的代码。最后，那些在有意义的情况下使用模式走在中间道路上的人，然后对任何内容进行编码，以最小化公开代码。

我想知道是否有人锁定了一种在软件开发生命周期中平衡使用模式的好方法。另外，网络上关于模式，动机因素及其正确使用的最佳资源是什么？

谢谢。

解决方案

我认为我必须建议"重构：改进现有代码的设计"。

重构：改进现有代码的设计http://2020ok.com/img/1/41191.jpg

关于如何实现对模式的合理使用的大量示例。

我认为最好的Web资源包含有关模式和重构的信息http://sourcemaking.com

在设计模式中，定义和原始答案是概念的起源。本书从理论上讲这个概念，而不是渗透到该地区的管理层的话。他们认为设计模式只是常见习语的名称。他们列举了一些并证明了自己的立场。

他们避免使用"我应该使用哪种设计模式"类型的问题，而将问题处理为"我自然地步入了一个知名领域吗？如果是这样，其他人可以帮助我吗？"。对我而言，设计模式不像我们将预制组件粘合在一起以提供解决方案。它们只是当我们遇到一种类似情况已被反击时的指导资料库，并提供了一些名称，以使人们可以在交谈中参考一般情况。

http://www.dofactory.com/Patterns/Patterns.aspx

那里有很多不同的"模式"系列，但以问题为最广义的术语...

我建议：

• 吉姆·科普林(Jim Coplien)的组织模式
• 山坡小组Wiki
• Kevlin Henney的网站上有很多出色的链接和论文

离线(我的最爱)：

• 福勒的企业架构模式
• Feather与旧版代码有效合作

离线(受欢迎)：

• GoF设计模式
• 福勒的重构：改进现有代码的设计

模式的正确使用取决于知识和经验；没有公式。要做的一件好事是让有经验的人明智地应用模式，以定期检查团队中其他所有人的代码，以确保他们不会过度使用或者使用不足设计模式。它们不是预先烘焙的食谱，它们需要有效地应用才能有效的技巧，而这需要学习。

我对设计模式的第一个也是最好的接触是波特兰模式存储库。

每个人都一直在使用模式。他们可能不知道。甚至"在列表上迭代"之类的简单事物也是一种模式。

我认为将模式整合到工作周期中的最佳方法就是使用它们，并在讨论它们和注释代码时按名称引用它们。希望这将导致知识的传播。

因此，举例来说，我们发现工作非常适合Observer。我们对同事说："嘿，如果我们将此对象设为观察者，并将该对象作为主题，这将非常容易做到。"

或者同事马上就能理解-这就是节省我们时间的模式-或者我们就可以对其进行教育，而下次我们提到"观察者"时，他们马上就会理解。

同时，我们正在传播知识，他们将发现使用从我们那里学到的新模式的机会。当然这是双向的。下次可能是他们教我们新的模式。

所有这一切的确取决于同事不是那种点头并假装理解某些东西的人。我们确实需要他们说"嘿，我们提到的观察员，我想我不知道那是什么。"

设计模式很有趣，因为我们仅在完全了解适用的模式后才知道在哪里使用模式。稍作练习后，就可以使用诸如Strategy，Observer，Iterator之类的东西而无需费力思考。如果我们在C中，则始终使用Iterator(IEnumerable ...)，而不会将其视为一种模式。

我认为，这些简单的模式是最好的模式。我们已经有工作要做，而当问题不太适合时，尝试将一个问题一个接一个地拖到另一个模式中，将浪费时间，并导致代码错误。

我的建议是查看模式的uml图，如果它很简单，请尝试并充分学习它，以便我们以后再调用它。合同更简单的模式可能更有用。

我是该系列的忠实拥护者，并且已经阅读了许多书籍，因此我建议我们采用Head First Design Patterns。我们可以通过O'Reilly的Safari书架在线阅读它，但印刷版也随附精美的图案海报。

我自己去买《四人帮的设计模式》

我同意这些参考资料，但没有新手友好。为了快速开始学习设计模式的简单方法：

首先，设计模式

然后，一旦我们了解了更高级的书籍，就可以检查更高级的书籍(很多实际示例；-)

"模式"的使用在很大程度上取决于

• 使用的语言
• 要达到的目标。

可以使用C ++，Java等语言将设计模式命名为高估。他们掩盖了各种打字问题所带来的僵化。以下是使用较少限制语言的"生存"模式的链接：
http://norvig.com/design-patterns/

另一个示例是面向方面的编程，其中需要用某种"未设计"的语言"介绍"事物。

二手工具背后的理念也产生了很大的影响。只需比较一下，例如Smalltalk，Common Lisp，Haskell等中的平均PHP或者Visual Basic程序和解决方案。

语法元素也有很大的影响。在C，C ++(迭代器)中，我们会看到大量类似的循环，但是如果我们研究支持高阶函数的languag，我们只会发现几个循环。

然后，我们必须查看人们访问编程的方式，自下而上或者自上而下，零散增长或者构建金字塔，或者任何其他个人喜好

我建议阅读提到的链接，然后检查"不同"语言的实现...。

问候
弗里德里希

我完全同意以上评论。我使用设计模式，但我可以但始终依靠团队的其他成员来真正理解特定模式的好处。否则，我们将得到丑陋的代码和轻巧的包装器，该包装器有点类似于该模式。

顺便说一句，http：//www.developer.com每月有几篇有关设计模式及其应用的文章。祝你好运！