我对 .NET 4 中引入的代码契约着迷（尽管是在 DevLabs 的帮助下）。但一张精美的印刷品让我冷静下来。它是这样说的：
- 当在线程安全方法中的锁之外调用后置条件时，除了不使用它们之外，当前没有解决该问题的方法。
- .NET 依赖于二进制重写器，因此使构建速度变慢。
- 使用代码契约也可能会导致运行时性能下降。
- 不能用于安全敏感检查，因为可以在运行时通过处理 ContractFailed 事件来规避它们。
对我来说最大的是第一个。我不知道是否有人再编写单线程应用程序。因此，如果代码契约不能支持多线程，我认为它们没有多大用处。或者也许我不应该对此过分强调，因为后置条件用于断言方法本身的内部结构，可以进行单元测试。
顺便说一句，我没有找到任何东西，也没有尝试反汇编我的代码来查看先决条件被注入的位置。我想在一个简单的方法中，当 lock() 首先执行时，在它之后注入检查很简单，但在一个相当复杂的方法中，当锁定发生在中间的某个地方时，这可能是一个问题。或者如果使用了除lock()之外的其他机制。
您似乎将“编写多线程应用程序”与“使每个类都线程安全”混淆了。撇开定义术语“线程安全”的棘手问题 http://blogs.msdn.com/b/ericlippert/archive/2009/10/19/what-is-this-thing-you-call-thread-safe.aspx我建议您的课程中很少有人应该在大多数应用程序中使用锁定。
一般来说，我编写了很多类，它们不尝试显式线程安全，但同样不具有任何线程依赖性。他们假设，如果您要从多个线程使用它们，则一次只能从一个线程执行此操作，并使用适当的内存屏障来确保一个线程中所做的更改在下一个使用它们的任何线程中都可见。
那么有相对的few执行必要协调的类。
现在，代码契约的问题可能会使这几个类变得足够弱，从而使整个想法崩溃......但我不认为一开始就这样。
我对代码合约将面临的问题有些警惕，因为 C# 编译器会做越来越多的工作来重写你的代码...我不知道合约团队是否已经解决了迭代器块的问题，但即使他们已经解决了当 C# 5 推出异步方法时，将不得不再次这样做......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
