有人說“TDD（測試驅(qū)動開發(fā)）可以帶來優(yōu)秀的設(shè)計”，也有人說“TDD會對設(shè)計有負(fù)面影響”。如果有個具體例子的話，討論起來會實際得多，所以下面我們來看一下私有方法以及它與優(yōu)秀設(shè)計、可測試性的關(guān)系——這種對立觀點的一個實例。
Szczepan Faber在博客中寫道，私有方法是一種反模式：
自從TDD誕生之日起，私有方法似乎就有了壞味道。被測試浸染的開發(fā)者總想尋找測試私有方法的辦法。嗯……這顯然是很困難的，所以問題就從“如何”變成了“為何”：為何要測試私有方法？大多數(shù)TDDers都會立刻回答說：別這么干。于是TDD又改變了我們構(gòu)建軟件的方式，對私有方法進行了重新評估
Jay Fields在博客上描述了在ruby中測試私有方法的一種通用方式：
……我很少測試私有方法。我更傾向于通過public API來進行測試。不過偶爾也有這種時候，如果你可以給一兩個私有方法寫點測試用例的話，日子就可以過的容易一些。
Michael Feathers在去年的The Deep Synergy Between Testability and Good Design一文中指出，TDD可以帶來優(yōu)秀的設(shè)計，而反過來想，那些不可測試的代碼應(yīng)該引起我們的深思：
在我編寫測試時，如果覺得有強烈的沖動促使我去測試一個私有方法，我就會把它看作一種暗示。它告訴我，我的類已經(jīng)被封裝得趨近于封閉了，測試代碼無法再通過公共接口來“理解”這個類的行為。我順從了這個暗示的召喚，重新構(gòu)建了代碼。通常我都會把這個私有方法（可能還有一些相關(guān)的方法）挪到一個新的類里面，在那里它不再是私有，可以讓測試代碼訪問。
以上種種想法，都傾向于不鼓勵使用私有方法，在天平的可測試性一端加入更多砝碼。但它們并不是唯一的聲音。實際上在我們所能看到的有關(guān)面向?qū)ο箝_發(fā)的觀點中，很多都是支持少用一些類，極盡所能使用封裝。在public API中只暴露最小的API集合，就會將耦合降低到最小。David West在Object Thinking一書中，引用了Lorenz和Kidd在Object Oriented Software Metrics書中的論述：
一個應(yīng)用程序應(yīng)該最多包括40個故事，100個類。
應(yīng)用程序所屬的整個業(yè)務(wù)領(lǐng)域不應(yīng)該需要超過1000個類來完成。
每一次迭代后都該扔掉25-30%的代碼。
每個類的職責(zé)：平均是7個。
每個類的方法數(shù)：平均是12個。
每個方法的代碼行數(shù)：平均是15個。
需要進行注釋的代碼行數(shù)百分比：60。
case語句的數(shù)量：平均為0。
如果私有方法確實是壞味道，需要把它們挪到自己所應(yīng)歸屬的類中，這不就是“為了讓測試變得簡單，而增加類的數(shù)量”么？它勢必會造成類的數(shù)量急劇膨脹。
那么該拿私有方法怎么辦呢？測試它們太折磨人了。我們可否修改一下，把它們暴露給測試代碼？或者不去測試私有方法，讓設(shè)計與可測試性永不相干？或者，私有方法是一種壞味道，它表明一個類做了太多事情？
|
