大话重构连载：遗留系统——软件工业时代的痛

你回头去看看什么叫复用原则。

100个开发票的方法，显然应该100个开发票的类来执行。

具体里面相同的功能，可以调用util类来执行。

否则，1个类里面有100个方法，甚至设计成为 pay(methodName, params)

一个实现了100个开发票的方法的巨型方法。你就高兴了？

软件复用有3个基本原则，

一是必须有可以复用的对象；

二是所复用的对象必须是有用的，

三是复用者需要知道如何去使用被复用的对象。



都说了是100个开发票的方法了，从业务上来说，就应该是相对独立的。不可以说业务人员要加101个方法，就要求qa从头开始测其他100种方法。

对吧。这就是低耦合的要求。  如果你不明白，可以提出你的看法。

@SangoRewrite

看了你的表述，我明白了，其实你在做的时候做法是ok的。但是你的理解确实相反了。

你所认为的“独立”——“100个开发票的类来执行，具体里面相同的功能，可以调用util类来执行”，才是真正的复用。将相同的逻辑抽出来不就是复用么。

而我一直说的复用，居然让你理解为“一个类里100个方法”……确实没有想到有人会这么理解，感觉很奇葩啊

当然，虽然说你调用util的方式是可行的，但是做法还是太low。这种流程长的业务，当然是要依靠继承或组合的形式，将主线抽离出来，然后创建不同的实现类以继承父类或者实现接口的形式去编写各个不同的逻辑。这才是规范的复用，才是规范的解耦和。当然，你的util类也是可以，但这是没有编程追求的人做的。

另外，你的QA的例子，我前面就想吐槽，但觉得不重要所以没管。既然你又谈了，我就告诉你，你这里的语言逻辑反了…… 反的特别低级……  呵呵怎么说呢，你说用util类来实现相同的逻辑，所以如果新场景若是需要你适当修改util方法，那么QA不全部测一遍，怎么能知道对其他方法没影响呢？
事实上，这里只能说明了你对QA工作的不了解，QA在测试的时候哪会一个一个case去独立的run啊，都是按照case suit批量run的好不好，这样才能输出report展示当前软件版本的bug率啊。。。。

最后再说一遍了，你在实践中的做法是对的，只是理解不小心反了

嗯，因此说，代码才是最好的文档。文档特别容易叫人误会。