原文链接:Should I Leave That Helper Class

声明:本文与右侧相关图书《深入理解C#(第2版)》二者之间没有直接关系,之所以选中此书作为相关图书,是因为二者有个共同特点【Depth】,即对事物的深入探查(再说右边空一块儿也不美观,呵呵)。

书接上回

在上一回《清除静态方法三板斧之一——静态方法将使你大吃一惊 》中,我们仔细分析了静态方法的利弊,现在是做出决断的时候了。


我手头的这个项目已被“助手”类(helper class)搞得千疮百孔。助手类到底是什么呢?

好问题。 我真的不知道。 也未处理过助手类。

当你向助手类问起,你在做些什么时……他(助手类)似笑非笑地低头瞧着他那双大脚,并答复一些毫无意义的“废话”。

helper class

如何识别助手类

我们可以通过一些可察觉的常见属性来辨析我们是否正在处理助手类,以下排序不分先后:

  • 没有任何明确的职责。
  • 不包含任何与其自身有关的状态数据。
  • 其中大多数或所有都是静态方法。
  • 类名以helper结尾。(这是个很好的提示!)
  • 若在某处新建了助手类,随后则需要把所有相关参数传递给它。
  • 位于名为“utilities”(实用工具)的包或命名空间之下。

助手类是一个含有适用于其他类的辅助方法的类,但实际上就其本身而言算不上事物。助手类是面向对象程序设计的反面之前我曾写过有关静态方法的危害,而助手类通常是静态方法激增和滋生的结果。

我们将略过任何有关为什么静态方法是有害的进一步讨论(译注:相关讨论参见上一回),而直接进入到最紧迫的问题……当你在你的代码库中发现一个助手类时……

你应该只是把它留在那里么?

just say no

(上面的这幅图片意味着“不”)

当你在高速公路上看到一起尚无人报告的车祸时,你应该只是驱车行驶而不拨打911报警么?

当你在街上看到一位老妇正在遭人殴打时,你应该仅仅从旁走过么?

当你打开你家冰箱,然后打开蔬菜抽屉并看到袋子里腐烂的黄瓜糊糊时,你能只是忘记你曾见过它么?

cucumber in your fridge

我不建议你开始就一头扎进你的遗留代码库中,并立刻着手移除所有的助手类方法。而我要说的是,如果你正在一个助手类方法内工作进而更改某些功能,并且你认为仅仅添加一个附加方法就行了,而且还在使用某些类似“这是约定”的牵强借口,那么我想拿一支大船桨(译注:莫非他要动粗?)并教你一些单一职责。不要成为问题的一部分。要成为解决方案的一部分。

这里有些用于保留助手类并传播它们的牵强借口。

  • 我只是在对代码做一个小改动。
  • 我不想破坏这个已经可运行的程序。
  • 我只是在遵循架构的约定。
  • 我不明白它是如何工作的。
  • 此功能没有所属的类。
  • 我是个懒虫,我也不关心让世界变得更美好。
  • 不管怎样,世界在2012年即将毁灭(译注:两天以后就是2012年,阿弥陀佛\~\~)。

如果你正在使用这些牵强借口的其中之一……别这样!3000行代码的助手类不是一夜之间诞生的。有些呆瓜首先创建了此类,然后更多的呆瓜向其中添加了方法。不要再成为另一个呆瓜。我恳求你。呆瓜已经够多了。

约翰,我想做正确的事……帮帮我。

什么?你要这么做?我将假设你是真诚的……即使我有所保留。

先来发个誓。把你的手放在《计算机程序设计艺术》(The Art of Computer Programming)上并重复我的话。

我,<你的名字>,郑重宣誓不会传播邪魔外道或纯粹的邪恶,以及被称为助手类的往往很苍白的代码。

我承诺维护单一职责数据抽象、以及开放-关闭原则的价值观。

我将击败那些助手类、以及助手类方法,并将它们适当地放入所属的关联类中,若有悖誓言将遭受不轻于用黄油小刀割去双臂和双腿的惩罚(译注:真狠呀!)。

欢迎新人,在下一帖中我将告诉你一些我用于消除助手类的技巧。

预知后事如何,请看下回《清除静态方法三板斧之三——如何重构助手类? 》