更重要的是,代码的可验证性还是遵守OOP原则?

前端之家收集整理的这篇文章主要介绍了更重要的是,代码的可验证性还是遵守OOP原则?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的团队演进的TDD包括什么似乎偏离了传统的oop。

>远离自给自足的课程
我们仍然在适当的时候封装数据。但是为了模拟任何帮助类,我们通常通过构造函数或mutator创建一些外部设置它们的方式。
>我们不会使用私有的方法
为了利用我们的嘲笑框架(RhinoMocks),方法不能是私有的。这是“卖给我们的传统开发商”中最大的一个。在某种程度上,我看到他们的观点。我只是测试更多。

你怎么看?

OOP只是许多可能的范例。它本身不是一个目标,而是一种手段。你不必编程面向对象,而不是如果其他范例更适合你。

而无数聪明的人才表示,单位测试在面向对象语言方面往往比面向对象的语言容易得多,只是因为测试的自然单位是一个功能。它不是一个类(可能有私有方法和各种怪异的状态),而是一个函数

另一方面,可测性本身就有价值。如果你的代码是不可测试的,你不能测试(显然),如果你不能测试它,你怎么能告诉它是有效的?
所以如果你必须选择一个极端或另一个,我一定会选择可测试性。

但是一个明显的问题是,您是否真的需要测试每个私有方法?这些不是一个类的公共合同的一部分,也可能不是孤立的有意义的。公共方法对于具体具体目的进行测试是很重要的,他们必须履行这个非常具体的合同,并使对象保持一致的状态等等。
它们本质上是可测试的,以私人方法可能不是。 (谁在乎私人方式呢?这不属于阶级契约)

也许一个更好的解决方案是将一些否则私有的东西重构为单独的类。也许需要测试私人方法并不像你一直在想的那么大。

在另一个注意事项上,其他嘲笑的框架也允许你模拟私人的东西。

编辑:
在想了一下之后,我想强调,只要让私人会员公开,可能是一个可怕的想法。
我们私人会员的原因是这样的:
必须始终保持类不变量。外部代码必须不可能使您的类进入无效状态。这不只是OOP,这也是常识。私有方法简单地允许在类内部内部提供更精细的粒度,通过多种方法等将一​​些任务分解,但是它们通常不保留类不变量。他们做了一半的工作,然后依靠一些其他的私人方法被称为后来做另一半。这是安全的,因为它们通常不可访问。只有其他类的方法可以称之为它们,所以只要它们保持不变量,一切都很好。

所以虽然是的,您可以通过将私有方法公开化来进行测试,但您也可以引入一些错误来源,这些bug不能通过单元测试轻松抓住。您可以使用类“错误”。一个精心设计的类始终保持其不变量,无论外部代码如何使用。一旦你公开,那就不可能了。外部代码可以调用可能不在该上下文中使用的内部帮助函数,哪些会将类置于无效状态。

单元测试不能真正保证这不会发生。所以我会说你冒险引入一个比你想象的更大的错误来源。

当然,鉴于上述私有成员(不保留类不变量)的定义,可能会将许多其他方法公开转换,因为它们保留不变量,因此不需要隐藏他们从外部代码。所以这可能会减少你的问题,通过给你更少的私有方法,但不允许外部代码打破你的课程,如果一切都是公开的可能。

原文链接:https://www.f2er.com/javaschema/282196.html

猜你在找的设计模式相关文章