我已经阅读了所有这些方法：按合同设计，面向方面编程，测试驱动开发和单元测试。在实践中，我只使用了单元测试和AOP（AspectJ）。我知道这是不同的事情，但似乎我对他们的目的有一些妄想。
问题\请求： 您能否对DBC，AOP，TDD和单元测试的目的之间的差异进行简要调查？你能回顾一下我对它的结论并指出我错在哪里吗？
我的结论：
答案 0 :(得分：2)
IMMO DBC，TDD和AOP不能直接比较，是非常不同的目的，我尝试解释这些技术在我个人看来是什么：
DBC的目的是定义语义（以前置条件，后置条件和不变量的形式），以确保一段代码的正确性。根据DBC的实现，这个契约可以在运行时声明，也可以尝试在编译时强制执行。老实说，我不得不说，我从来没有使用过，我从未看到过使用DBC构建真正的系统，DBC没有很好的工具支持，而且使用DBC的实用建议很少。
TDD关于通过使用示例（也称为测试）确保正确性，TDD也是使用快速反馈循环红绿重构的设计技术。像DBC一样，它是一种构建软件的技术，没有任何缺陷，但采用了一种截然不同的方法。我在很多项目中使用TDD超过六年（或者更多我不记得了）并取得了良好的效果，对我而言，它现在是开发软件的“自然”方式，当然这是个人选择而不是一般建议，自己尝试。
AOP是另一个非常不同的东西，它是一种处理交叉问题的方法，你可以用它来验证合同的执行吗？可能是的，但这不过是无限的用途之一AOP。只有我的观点，我不是AOP的忠实粉丝，我必须维护具有大量AOP内容的遗留代码库，而IMMO AOP是一种隐藏系统重要功能的非常复杂的方法。
答案 1 :(得分：1)
我会抓住这个......
DBC - 与防御性编程相比，这种编程方法更容易理解。
按合同设计是指完全指定谁（功能客户或功能提供商）负责什么（合同）。功能提供者承诺：如果你满足我的前提条件（例如输入值是非负的），然后我保证我的后置条件（例如，我将返回平方根的价值）。一个同样有效的合同是：如果你给我任何数字（没有先决条件），那么如果它是否定的话我会返回-1，否则我将返回数字的平方根。 / p>
使用此方法，功能客户端显然负责在调用功能之前检查是否满足前提条件。功能提供者可以自由地假设满足前提条件，但必须确保它满足后置条件。
将此与防御性编程进行对比，其中功能客户端和功能提供者都将验证数据以防万一另一个不会。
DBC尝试通过降低其复杂性（更强的规格和更少的重复代码）来帮助开发人员创建正确的代码。
如何实现DBC是各种实现细节。您可以在没有任何工具支持的情况下完成DBC，只需在纸上完全定义API然后实现它，以便客户端检查（指定的）前提条件并且提供程序满足其后置条件（对于所有有效的前提条件）。当然，工具支持有帮助....
单元测试只是确保代码按预期运行的方式（多种方法之一）。您可以在DBC代码或非DBC代码上使用单元测试。单元测试和DBC在某种程度上是互补的，因为它易于为明确定义的API规范编写单元测试;另一方面，如果您使用工具来支持DBC，它们甚至可以看到重复，因为合同可能最终在单元测试和DBC工具中被描述/验证。
TDD是另一种从不同角度降低开发代码复杂性的方法。从一个特性的规范开始，为它编写测试（它应该失败），编写使测试通过的生产代码（而不是更多）。 TDD代码仍然可以使用DBC（或不使用）。
AOP更像是一种技术 - 它是一种让代码在你想要的地方运行的替代方法。它可以用来支持很多东西，但我不会说“AOP是包含DBC的更广泛的概念”，而不是说一支笔是一个比一个简短故事更广泛的概念。
< / LI>