本节书摘来自异步社区《重构与模式（修订版）》一书中的第1章1.2节模式万灵丹，作者【美】Joshua Kerievsky，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.2　模式万灵丹

然而，随着时间的推移，模式的强大使我开始对更简单的代码编写方式视而不见。只要遇到某个可以使用两三种不同方法进行的计算，我就会很快想到实现Strategy模式，而事实上，使用简单的条件表达式编程更加容易，也更加快捷，完全足够。

有一次，我对模式的走火入魔可以说是暴露无遗。在结对编程中，我和搭档编写了一个类，它实现了Java的TreeModel接口，在树型窗口部件（widget）中显示Spec对象的图形。代码能够工作，但是树型窗口部件通过调用Spec对象的toString()方法来显示它们，而该方法并不返回需要的Spec对象信息。我们不能修改Spec的toString()方法，因为系统的其他部分还要用到这个方法。我们只好慎重思考如何继续。和往常一样，我开始考虑哪个模式能够助我们一臂之力。脑子里浮现出Decorator模式。我建议，按照这个模式用一个对象封装Spec对象，再重写（override）这个对象的toString()方法。搭档对这条建议的反应使我大吃一惊：“在这里用Decorator模式？那不等于大炮打蚊子吗？”他的解决方案是，创建一个名为NodeDisplay的很小的类，将Spec对象作为其构造函数的参数，它的一个公共方法toString()包含了Spec对象的正确显示信息。NodeDisplay类编写起来几乎花不了多少时间，因为它的代码不超过10行。而我使用Decorator模式的解决方案至少需要50行代码，需要多次反复委托调用Spec对象。

这样的经验使我意识到，再也不能过多地考虑模式了，应该重新把精力放在短小、简单和直截了当的代码上。我走到了一个十字路口：我努力学习模式，想成为更优秀的软件设计师，然而，现在为了真正更上一层楼，我需要放弃对它们的依赖。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。