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