为什么我们需要可测试的面向对象开发（翻译 ）

原文：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)。）