oop - 更重要的是代码的可测试性还是遵守 OOP 原则？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。




10年前关闭。




我的团队对 TDD 的演变包括似乎与传统 oop 的不同之处。

远离自给自足的类(class)
我们仍然在适当的地方封装数据。但是为了模拟任何辅助类，我们通常创建一些方法来通过构造函数或修改器从外部设置它们。

我们从不使用私有(private)方法。
为了利用我们的模拟框架(RhinoMocks)，方法不能是私有(private)的。这是向我们的传统开发者“出售”的最大的一个。在某种程度上，我明白他们的观点。我只是更重视测试。

你怎么认为？

Answer 1

OOP 只是众多可能的范例之一。它本身不是一个目标，它是达到目的的一种手段。如果其他范例更适合您，您不必编写面向对象的程序。

在你之前无数聪明的人已经说过单元测试在面向函数的语言中往往比面向对象的语言容易得多，因为测试的自然单元是一个函数。它不是一个类(可能有私有(private)方法和各种奇怪的状态)，而是一个函数。

另一方面，可测试性本身确实具有值(value)。如果你的代码不可测试，你就不能测试它(很明显)，如果你不能测试它，你怎么能说它有效呢？
因此，如果您必须选择一个极端或另一个，我当然会选择可测试性。

但一个明显的问题是，你真的需要测试每一个私有(private)方法吗？这些不是一个类的公共(public)契约的一部分，孤立起来可能没有意义。公共(public)方法对于测试很重要，因为它们有特定的目的，它们必须履行这个非常特定的契约，并使对象保持一致的状态等等。
它们本质上是可测试的，而私有(private)方法可能不是。 (谁在乎私有(private)方法的作用？它不是类契约的一部分)

也许更好的解决方案是将一些原本私有(private)的东西重构到单独的类中。也许测试私有(private)方法的需求并不像您想象的那么大。

另一方面，其他模拟框架也允许你模拟私有(private)的东西。

编辑:
在进一步考虑之后，我想强调一下，仅仅公开私有(private)成员可能是一个可怕的想法。
首先我们有私有(private)成员的原因是:
类不变量必须始终保持。外部代码一定不可能使您的类进入无效状态。这不仅仅是 OOP，它也是常识。私有(private)方法只是为了让您在类内部有更精细的粒度，将一些任务分解为多个方法等，但它们通常不保持类不变。他们完成了一半的工作，然后依靠之后调用的其他私有(private)方法来完成另一半。这是安全的，因为它们通常无法访问。只有其他类方法可以调用它们，所以只要它们保持不变量，一切都很好。

因此，虽然是的，您通过将私有(private)方法公开来使它们可测试，但您也引入了单元测试无法轻易捕获的错误来源。您可以使用“错误”类。一个设计良好的类总是保持它的不变性，不管它如何被外部代码使用。一旦你把所有东西都公开了，那就不可能了。外部代码可以调用可能不会在该上下文中使用的内部辅助函数，这将使类进入无效状态。

并且单元测试并不能真正保证这不会发生。因此，我会说您可能会引入比您预期的更大的错误来源。

当然，鉴于上述私有(private)成员的定义(那些不保留类不变量的成员)，可能可以安全地将许多其他方法公开，因为它们确实保留了不变量，因此无需隐藏它们来自外部代码。
因此，通过为您提供更少的私有(private)方法，但不允许外部代码破坏您的类，这可能会减轻您的问题，如果一切都是公共(public)的，这将是可能的。