代码合同检查线程亲和力 - 好主意？

我正在尝试学习代码合约，并了解它们有用的内容。代码合同检查线程亲和力 - 好主意？

我有一个WPF应用程序，所以很多代码必须专门在UI线程上运行。不少实用程序类只希望从UI线程中调用。

这是通过我的代码撒这些好主意吗？为什么是/不是？

Contract.Requires(Thread.CurrentThread == Application.Current.Dispatcher.Thread);

静态检查器是否能够可靠地检查这些？

感谢您的任何意见！

来源

2011-04-03 Matěj Zábský

我认为你是正确的想做出这些亲和力检查。它们是早期发现细微错误的好方法，但不是可以使用代码合同静态检查的东西，如Henk和decyclone。

我有一个名为Ensure的静态类，其方法Ensure.OnUiThread()包含与您所提及的完全相同的检查。我用[Conditional("DEBUG")]来标记这一点，以免减慢/膨胀生产代码。对我来说很好。

来源

2011-04-03 10:41:10 chillitom

可以对此进行一些静态检查。对于公共方法来说，它不能完成，但可以确定何时被标记为限制为一类线程的某个标记被限制为不兼容的线程类。例如，如果我构成一个属性并且具有'[ThreadRestriction（“UI”）] void UiThing（）{// bad} [ThreadRestriction（“Background”）] void BackgroundThing（）{UiThing（）; }，静态检查器可以检测到BackgroundThing不应该调用ForegroundThing。微软的合同似乎没有提供这个。 – mdonoughe 2012-06-19 17:32:06

您的合同应该与您的代码有关。 Dispatcher和Thread类不是你的，他们不受自己的合同守护。

因此，不，静态检查器将无法检查这一点。

运行时检查可能会工作，但它们对已经内置到库中的调试检查几乎没有影响。

来源

2011-04-03 10:02:06

方法的契约是“对于特定的有效输入，给定的方法将产生有效的输出”。

在你的情况下，你没有验证你的方法的输入。这就是为什么我不会推荐使用这种方法。

换句话说，这不会是一个合同，而只是某种验证/断言。

来源

2011-04-03 10:10:39 decyclone

代码合同检查线程亲和力 - 好主意？

回答

相关问题