在The Guerilla Guide to Interviewing Joel 中说，想要完成任务但不聪明的人会做一些愚蠢的事情，比如使用访问者设计模式，而简单的数组就足够了。
如果应该应用Gang of Four 建议的设计模式，我发现很难检测。
因此，我想从你的工作经历中获得一些例子
【问题讨论】：
标签： refactoring software-design design-patterns
设计模式是结果，而不是目标。你不认为今天我会使用策略模式，你就去做吧。在完成第三个几乎相同的课程的中途，您停下来使用纸质笔记本找出一般情况并敲出一个描述共享上下文的基类。您将前两个类重构为后代，这使您可以进行现实检查，并对基类进行很多更改。然后接下来的三十个是在公园里散步。
只有在第二天的团队会议上，您才可以通过说“我使用策略模式。它们都工作相同，所以只有一个测试程序，它需要参数来更改测试用例”，从而为大家节省了 30 分钟的无聊时间。
对模式的深入了解使您能够在情况需要时反射性地使用它们。当人们将模式的使用本身视为一个目标时，你会得到生硬、丑陋的代码，它谈论的是机制而不是目的；如何而不是为什么。
大多数模式都解决了反复出现的基本问题，例如降低复杂性和需要提供可扩展点。在明确不需要它们的情况下提供可扩展点会使您的代码无意义地复杂化并创建更多故障点和测试用例。除非您正在构建一个发布到野外的框架，否则只解决您实际面临的问题。
【讨论】：
GoF 原书的一大优点是讨论了该模式最能解决问题的场景。查看这些讨论可以帮助您确定“是时候”了。
另一个好的起点是Head First Design Patterns。说明使用不同设计模式的练习非常详尽，足以提供良好的学习体验。此外，这些练习还以现实世界的场景为基础，因此可以毫不费力地确定何时应用设计模式的适当时机。
【讨论】：
模式只是工具和词汇。您编写的代码尽可能简单、易于理解和可维护。通过了解模式，您可以使用更多替代方案，并且您有一种语言可以在实施之前讨论该方法的优缺点。
在任何一种情况下，您都不只是“切换”到“使用模式”。你只是继续做你一直在做的事情，用你知道的最好的方式编写代码。
【讨论】：
当您遇到某个模式可以解决的问题时。 GoF 书的每一章都有一节解释每种模式适用于哪些类型的场景。你应该不分析你遇到的每个问题，然后去查找要使用的模式。您应该熟悉这些模式，以便学会识别需要它们的情况。
【讨论】：
随着问题的复杂性增加，从简单的方法切换到正式的设计模式对我来说通常是很自然的事情。关键是要足够熟悉模式，以便您可以识别临界点并从简单的方法切换到设计模式，因为它会为当前和未来的开发带来最大的好处。
对于一个更大、更复杂的项目，临界点应该在相当早的时候；在许多情况下，甚至在您开始编码之前。对于较小的项目，您可以在决定实施模式之前等待。
您可以做的最好的事情之一是提高您识别何时应该使用模式的能力，即在完成项目后花一些时间来检查您的“简单”方法变得多么复杂。如果实现一个模式会花费您更少的时间和精力，或者如果该模式能够阐明您想要做什么，那么您可以将这些知识归档以备下次遇到类似问题时使用。
【讨论】：
我经常发现，在遇到这些问题时，使用测试驱动开发有助于指导我。
总而言之，我想说的是，TDD 帮助指导我编写当时足够的代码，也许更重要的是帮助我在以后不可避免的需求变化、需要更多功能等时进行更改。
【讨论】：
这类似于任何其他设计决策。最终，这取决于。您应该学习那些对您的语言有用的模式（例如，Lisp 或 Smalltalk 中不需要许多 GoF 模式），了解它们的优缺点，了解系统的限制，并做出最适合您需求的选择.
我能给出的最好建议是学习、学习、再学习。
【讨论】：