為什麼我們需要可測試的物件導向開發（翻譯 ）

原文：Why you should think about TOOP- Testable Object Oriented Programming 作者:Typemock首席架構師Roy OSherove ---The Art of Unit Testing: With Examples in .Net的作者

我覺得物件導向設計\編程（ Object Oriented Design\Programming）是時候要做些改變了。

品質和對可測試性、持續整合的追求在業界已經開始萌芽。

我們需要思考一個簡單的事實：在很多情況下，純OOD和可測試設計在概念上有些許衝突。我曾經寫過一篇文章，FXCop為了追求純粹的物件導向，移除了一些利於可測試性的特性(當然，作者鄙視了FXCop的團隊)。

以下是一些關於OOD/OOP要求“隱藏”，而可測試性（Testable Design）設計建議“公開”的例子。

OOD：不要公開那些不需要其他開發人員使用的私人成員或者方法。

Testable：通過介面，依賴注入，開放setters方法等方式 公開或者替換 那些對象裡私人的成員。

OOD：除非你需要讓別人擴充，否則把類給密閉（seal）了。

Testable:預設不允許密閉（除非安全方面考慮）以便使用者可以重用你的方法並按照他們的測試需要override。

OOD：只在你需要使用者override你的方法時才讓你的方法virtual。—-因為java預設是virtual，所以作者在這點上喜歡java。

Testable：只要可能，預設讓你的方法virtual，這樣那些需要寫測試的人可以繼承和override你的方法來解除一些依賴。

OOD：使用單例方法來確保只使用一個執行個體，不允許任何人觸及私人對象。

Testable：允許為了測試中解除依賴去替換單例對象。

OOD：除非需要，否則類型預設為private或者interna。

Testable：開放API裡那些你認為有助於測試專案的類型。

OOD：不要添加那些非必須的APIs。

Testable：添加特定的API（方法，介面，尤其類型）方便測試，這些對測試來說是必須的。

如果我們把”可測試性“添加到OOD詞彙中會怎樣呢？

“Testable Object Oriented Design: TOOD“（可測試的物件導向設計）

“Testable Object Oriented Programming: TOOP“（可測試的物件導向編程）

讓兩個詞彙貫徹在開發設計中，更加重視可測試性的需求。很多情況下，如果不遵從一些物件導向的最佳實務（多態這個特性對於可測試的設計就是非常重要的），

TOOD和TOOP可以讓你的設計更加SOLID

（參考Bob Martin的SOLID設計原則。這一系列原則經久不衰，它包括單一職責原則(Single Responsibility Principle)，開閉原則(Open Closed Principle)，裡氏替換原則(Liskov Substitution Principle)，介面分離原則(Interface Segregation Principle)，依賴反轉原則(Dependency Inversion Principle)。）