Private Method不該有複雜的邏輯嗎？

Mar. 01 14:45~16:01

前幾天寫了一篇《要不要幫Private Method寫單元測試?》，有位熱心的鄉民提出一個問題：

為何private method內不該有複雜的邏輯呢？憑什麼《JUnit Recipes》的作者認為只有public method 才有資格擁有複雜的內部邏輯呢？因為作者有這樣的可見性歧視，所以才會有「只有public method應該測試，private method如果需要測試，很可能他本來應該被public才對」這樣的論調。

在討論這個問題之前，先補充說明幾點：

• 《JUnit Recipes》的原意應該不是說private method「不須測試」，而是private method應該透過public method來測試即可，不需要「直接」測試private method。
• 在前述的假設之下，如果private method的邏輯非常複雜，則要透過測試public method來涵蓋到private method的所有可能執行路徑（至少要考慮到主要的執行路徑）很可能讓測試案例變得很難寫或是過於複雜。
• 此時回頭思考一下，為什麼這個private method的邏輯會如此的複雜？有沒有可能是在設計這個類別的時候，責任沒有劃分好，以至於這個類別做了太多事情（擔負太多責任）。這些責任，有一部分剛好是目前的客戶端所關注的，所以被設計成public method。而有些責任，有可能並非客戶端主要關注的焦點，或是設計者還沒有認知到這些責任應該要擺在哪裡。此時設計者有可能就把這些責任當成類別實作的細節，將其放在private method之中。在這種情況之下，private method就很有可能會過於複雜以至於很難透過測試public method來測試到private method。這種設計的結果可視為一種警訊，提醒設計者注意是否有改善設計之處。例如思考這些private method有沒有可能應該要另起爐灶，設計成另外一個類別的public method。但就好像打噴嚏可能是感冒的前兆一樣，但並不是說只要是打噴嚏就一定是感冒。所以private method很複雜只是一種潛在設計問題的症狀，並不是說只要是private method有著複雜的邏輯一律都要抽離出來變成另一個類別的public method。

***

換一個角度來思考。很多年前Teddy當任「物件導向分析與設計」這門課的助教，發現有不少學生的設計，長成下面這個樣子。

 

Teddy：不是有規定要用物件導向的方式來設計系統嗎，你的設計怎麼還是程序導向的思考？

學生：我有用物件導向設計啊。物件導向不是告訴我們要設計類別，並且把資料與行為一起封裝在類別之中嗎？我的系統有設計類別啊，就叫做System，裡面也有很多資料與行為。你看，我設計了20個public method給使用者直接呼叫，另外有100個private method用來隱藏實作細節。

Teddy：你的private method很多都超過1,000行了耶？

學生：對啊，這些都是實作細節，反正這些行為我套用資訊隱藏的做法，將它們設計成private method，所以就算是這些private method再怎麼 混亂 改變，也不會影響外部的使用者。

Teddy：好，很好，你物件導向學得不錯嘛！零分，下一位。

***

物件導向設計強調透過「物件互動」來完成工作，因此物件介面設計的好或不好，成為影響物件導向系統設計品質的主要原因。要一開始就設計出良好的物件互動模式與物件介面，說實話並非易事。了解物件導向設計技術與設計原則是一種方法，學習設計模式（design pattern）是一種方法，從測試的角度來檢視設計也是一種方法（所以TDD是一種設計技巧）。

看完本篇先不必急著開罵或是馬上把你的private method抽離到另一個類別之中。請花一點點時間找一下鄉民們手邊已有的程式，看看那些「過於忙碌（有著複雜邏輯）」的private method，如果把它們抽離到其他類別之中，原本的系統是否會變得更容易理解與測試。

***

友藏內心獨白：物件導向技術還真的不太容易學啊。