[翻譯]清除靜態方法三板斧之二——我是否應該保留助手類

原文連結：Should I Leave That Helper Class

宣告：本文與右側相關圖書《深入理解C#（第2版）》二者之間沒有直接關係，之所以選中此書作為相關圖書，是因為二者有個共同特點【Depth】，即對事物的深入探查（再說右邊空一塊兒也不美觀，呵呵）。

書接上回

在上一回《清除靜態方法三板斧之一——靜態方法將使你大吃一驚 》中，我們仔細分析了靜態方法的利弊，現在是做出決斷的時候了。

---

我手頭的這個專案已被“助手”類（helper class）搞得千瘡百孔。助手類到底是什麼呢？

好問題。 我真的不知道。 也未處理過助手類。

當你向助手類問起，你在做些什麼時……他（助手類）似笑非笑地低頭瞧著他那雙大腳，並答覆一些毫無意義的“廢話”。

如何識別助手類

我們可以通過一些可察覺的常見屬性來辨析我們是否正在處理助手類，以下排序不分先後：

• 沒有任何明確的職責。
• 不包含任何與其自身有關的狀態資料。
• 其中大多數或所有都是靜態方法。
• 類名以helper結尾。（這是個很好的提示！）
• 若在某處新建了助手類，隨後則需要把所有相關引數傳遞給它。
• 位於名為“utilities”（實用工具）的包或名稱空間之下。

助手類是一個含有適用於其他類的輔助方法的類，但實際上就其本身而言算不上事物。助手類是物件導向程式設計的反面。之前我曾寫過有關靜態方法的危害，而助手類通常是靜態方法激增和滋生的結果。

我們將略過任何有關為什麼靜態方法是有害的進一步討論（譯註：相關討論參見上一回），而直接進入到最緊迫的問題……當你在你的程式碼庫中發現一個助手類時……

你應該只是把它留在那裡麼？

（上面的這幅圖片意味著“不”）

當你在高速公路上看到一起尚無人報告的車禍時，你應該只是驅車行駛而不撥打911報警麼？

當你在街上看到一位老婦正在遭人毆打時，你應該僅僅從旁走過麼？

當你開啟你家冰箱，然後開啟蔬菜抽屜並看到袋子裡腐爛的黃瓜糊糊時，你能只是忘記你曾見過它麼？

我不建議你開始就一頭扎進你的遺留程式碼庫中，並立刻著手移除所有的助手類方法。而我要說的是，如果你正在一個助手類方法內工作進而更改某些功能，並且你認為僅僅新增一個附加方法就行了，而且還在使用某些類似“這是約定”的牽強借口，那麼我想拿一支大船槳（譯註：莫非他要動粗？）並教你一些單一職責。不要成為問題的一部分。要成為解決方案的一部分。

這裡有些用於保留助手類並傳播它們的牽強借口。

• 我只是在對程式碼做一個小改動。
• 我不想破壞這個已經可執行的程式。
• 我只是在遵循架構的約定。
• 我不明白它是如何工作的。
• 此功能沒有所屬的類。
• 我是個懶蟲，我也不關心讓世界變得更美好。
• 不管怎樣，世界在2012年即將毀滅（譯註：兩天以後就是2012年，阿彌陀佛\~\~）。

如果你正在使用這些牽強借口的其中之一……別這樣！3000行程式碼的助手類不是一夜之間誕生的。有些呆瓜首先建立了此類，然後更多的呆瓜向其中新增了方法。不要再成為另一個呆瓜。我懇求你。呆瓜已經夠多了。

約翰，我想做正確的事……幫幫我。

什麼？你要這麼做？我將假設你是真誠的……即使我有所保留。

先來發個誓。把你的手放在《計算機程式設計藝術》（The Art of Computer Programming）上並重復我的話。

我，<你的名字>，鄭重宣誓不會傳播邪魔外道或純粹的邪惡，以及被稱為助手類的往往很蒼白的程式碼。

我承諾維護單一職責、資料抽象、以及開放-關閉原則的價值觀。

我將擊敗那些助手類、以及助手類方法，並將它們適當地放入所屬的關聯類中，若有悖誓言將遭受不輕於用黃油小刀割去雙臂和雙腿的懲罰（譯註：真狠呀！）。

歡迎新人，在下一帖中我將告訴你一些我用於消除助手類的技巧。

預知後事如何，請看下回《清除靜態方法三板斧之三——如何重構助手類？ 》。