什么时候打电话给四人帮？[何时使用设计模式？]

Question

在The Guerilla采访指南 Joel说,想要完成任务但不聪明的人会做一些愚蠢的事情,例如使用访问者设计模式,其中一个简单的数组就足够了.

如果应该使用Gang of Four建议的设计模式,我发现很难检测到.

因此,我想从您的工作经验中得到一些例子

Answer 1

我经常发现,在面对这些问题时,使用测试驱动开发有助于指导我.

什么时候一个简单的方法足够？ 使用最简单的方法来完成下一个测试总是足够的.但知道何时/如何重构是真正的艺术形式.
一个软件的最小尺寸是多少,证明使用GoF模式是正确的？ 我曾经读过的一条经验法则是,当你对某些东西进行一次编码时,很好,当你再次在某处复制该代码时,做一个笔记并继续前进.当您第三次发现需要相同的代码时,是时候重构以消除重复和简化,并且通常涉及转移到设计模式.
什么时候从简单的重构到GoF？ 我喜欢@anopres所说的 - 现在是时候感受到没有设计模式的痛苦了.疼痛(或代码"气味")可能以多种方式表现出来.代码重复是最明显的.像Fowler的Refactoring或Kerievsky的Refactoring to Patterns这样的重构书列出了很多这样的痛点/代码.
这种[重构]能否以合理的方式完成？ 重构的技巧是让你有信心的一套单元测试,然后重构而不会导致任何这些测试失败.根据定义,重构不会改变代码的功能.因此,如果您的测试继续通过,您可以非常好地感觉到您没有破坏任何东西.虽然这可能很难,但实际上我喜欢这部分TDD,它几乎就像一个游戏,在不破坏任何测试的情况下进行更改.

总之,我会说TDD有助于指导我编写当时足够的代码,也许更重要的是帮助我在以后不可避免地需求变更,需要更多功能等时进行更改.

Answer 2

设计模式是一种结果,而不是目标.你今天不认为我会使用策略模式,你就是这样做的.在完成第三个几乎相同的类的中途,你停下来并使用纸质笔记本来弄清楚一般情况并敲掉描述共享上下文的基类.你重构前两个类是后代,这给你一个现实检查和你的基类的一些变化.然后接下来的三十个人在公园散步.

只是在团队会议的第二天,你通过说"我使用了策略模式来节省每个人三十分钟的无聊.它们都工作相同所以只有一个测试程序,它需要参数来改变测试用例."

对模式的熟悉使您可以在情况需要时反复使用模式.当人们将模式的使用本身视为一个目标时,你就会得到一种愚蠢的,丑陋的代码,它们讲的是机制而不是目的; 怎么而不是为什么.

大多数模式解决了复杂的缓解和提供可扩展性点的需要等重复出现的基本问题.提供可扩展性点时,无需明确它们就会使代码变得复杂,并创建更多的故障点和测试用例.除非您构建一个框架以便释放到野外,否则只解决您实际遇到的问题.

Answer 3

模式只是工具和词汇.您可以将代码编写为您知道的简单,易懂和可维护的代码.通过了解模式,您可以使用更多的替代品,并且在实施之前,您可以使用一种语言来讨论该方法的优缺点.

无论哪种情况,你都不要只是"切换"到"使用模式".你只是继续做你总是做的事情,以你知道的最佳方式编写代码.

Answer 4

这与任何其他设计决策类似.最终,这取决于.您应该学习那些对您的语言有用的模式(例如,Lisp或Smalltalk中不需要许多GoF模式),了解它们的优点和缺点,了解系统的约束条件,并做出最符合您需求的选择.

我能给出的最好的建议是学习,学习和学习.