refactoring - 什么时候调用四人组？ [什么时候使用设计模式？]

Question

在 The Guerilla Guide to Interviewing Joel 说那些想要完成任务但不聪明的人会做一些愚蠢的事情，比如使用访问者设计模式，其中一个简单的数组就足够了。

我发现很难检测，如果 Gang of Four 建议的设计模式应该应用。

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

什么时候简单的方法(固定大小的数组)就足够了？

证明使用 GoF 模式合理的软件的最小尺寸是多少？

什么时候从头脑简单重构到GoF？这可以以明智的方式完成吗？

Answer 1

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

什么时候是一个简单的方法
充足的？它总是足够的
用最简单的方法得到
下一个要通过的测试。但知道
何时/如何重构才是真正的艺术
形式。

a的最小尺寸是多少
可以证明其合理性的软件
使用 GoF 模式？一个规则
我曾经读过的拇指是当你
编码一次，很好，当你
在某处复制该代码
第二次，做笔记并移动
在。当您发现需要
第三次使用相同的代码，是时候
重构以消除重复和
简化，通常涉及
转向设计模式。

何时
从头脑简单重构到GoF？
我喜欢@anopres 所说的 - 它是
当你感到痛苦的时候
设计模式到位。
疼痛(或代码“气味”)可能
表现在几个方面。
代码重复是最多的
明显的。重构类书籍
福勒Refactoring或者
克里耶夫斯基的 Refactoring toPatterns列出许多这样的痛苦
点/代码恶臭。

这个可以吗
[重构] 以合理的方式进行
道路？重构的诀窍是
有一套单元测试
你有信心，和
然后重构而不造成任何
那些测试失败。
根据定义，重构不会
改变你的功能
代码。因此，如果您的测试
继续通过，你可以有一个
很好的感觉，你没有
打破任何东西。虽然这可能很困难，但我实际上很喜欢 TDD 的这一部分，它几乎就像一个在不破坏任何测试的情况下进行更改的游戏。

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