Re：鸭型检查？ [英] Re: duck-type-checking?

问题描述

2008年11月12日下午2:42，Tim Rowe写道：

On Nov 12, 2008, at 2:42 PM, Tim Rowe wrote:

然后原始类定义发生变化 - 新成员添加 -

但工厂级的那些不会改变，因此不再符合工厂级的b $ b（不支持新工厂级） />
" form_pun_relating_to_avoiding_a_high_hazard（）"方法）。

And then the original class definition changes -- new members added --
but the ones from the factory class don''t change, and so are no longer
compliant with the the factory class (which doesn''t support the new
"form_pun_relating_to_avoiding_a_high_hazard() " method) .

是的，这肯定是一种风险。但是我宁愿冒险在开发过程中以明显的方式破坏代码的风险，而不是风险

以某种微妙的方式打破它的东西，更有可能是最终用户发现的
。

Yes, that''s certainly a risk. But I''d rather risk something that
breaks the code in an obvious way during development, than risk
something that breaks it in a subtle way and is more likely to be
discovered by the end-user.

罚款。如果你检查了你的代码

使用的班级的所有成员，它会使

没有区别。 ABCs为您提供了一种方法，但在他们缺席的情况下，这是一长串支票。

Fine. If you checked for all the members of the class that your code
uses, it makes
no difference. ABCs give you a way of doing this, but in their absence
it''s a long list of checks.

True。我喜欢ABC方法;现在我只需要弄清楚是否

我喜欢它足以让我们整个公司超过2.6（尽管2.5'

很大的优势，它是预先的 - 默认情况下安装在每台Mac上），或者

相反，我会想出一些与ABC兼容的临时

解决方案我可以用来直到我们切换。

True. I love the ABC approach; now I just have to figure out whether
I love it enough to move our entire company over to 2.6 (despite 2.5''s
great advantage that it''s pre-installed on every Mac by default), or
whether instead I''ll come up with some sort of ABC-compatible interim
solution I can use to hobble along until we do switch.

如果您/可以/使用继承，那么它可以节省必须进行的检查。

If you /can/ use inheritance then it saves having to do those checks.

嗯，当然。任何合理的检查系统都会首先检查

isinstance和issubclass，然后在声明的界面（或ABC）中痛苦地检查每个

方法和属性，以便
至少
性能原因。

但重点是要有一个能够轻松高效地处理常见案例的系统，而仍然能够处理不常见的

。


最好，

- 乔

Well, sure. And any sensible checking system would first check
isinstance and issubclass before painfully checking each of the
methods and properties in the declared interface (or ABC), for
performance reasons at the very least.

But the point is to have a system that will easily and efficiently
handle the common cases, while still being able to handle the uncommon
ones.

Best,
- Joe

推荐答案

Joe Strout写道：

Joe Strout wrote:

我宁愿冒一些风险

在开发过程中以明显的方式破坏了代码而不是风险

以微妙的方式打破它并且更有可能是最终用户发现的
。

I''d rather risk something that
breaks the code in an obvious way during development, than risk
something that breaks it in a subtle way and is more likely to be
discovered by the end-user.

在我看来，投入这些断言并不会让b $ b对错误的比例产生很大影响b / b
通过测试。


您的测试套件仍然必须足够全面，以便
触发错误对象的分配。如果它不是b $ b，你的断言就不会有任何结果。如果是，那么

你会在测试期间发现任何情况。

没有
$ b可能更难解决问题$ b断言，但你仍然会抓住它。


-

格雷格

Seems to me that putting in these kinds of assertions isn''t
going to make much difference to the proportion of bugs that
slip through testing.

Your test suite still has to be comprehensive enough to
trigger the assignment of the erroneous object. If it''s
not, your assertions won''t catch anything. If it is, then
you would have found out during testing in any case.
It might be more difficult to *fix* the problem without
the assertions, but you will still catch it.

--
Greg

这篇关于Re：鸭型检查？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！