|
|
固定条件
一般来说，固定条件就是一种在给定的上下文中始终为 true 的条件。 在应用于面向对象的软件时，固定条件指示一种针对类的各个实例始终为 true 的条件。 固定条件是一种强大的工具，每当给定类的任何实例的状态失效时，它都会及时通知您。 换言之，固定条件协定正式定义据以推测类的实例处于良好状态的条件。 虽然听起来很重要，但这只是在通过类对业务域建模时要先了解后实施的第一个概念。 域驱动设计 (DDD) 是目前用于为复杂业务方案建模的成熟方法，而且可在设计时为固定条件逻辑分配一个重要位置。 实际上，DDD 极力建议您永远都不要处理处于无效状态的类的实例。 同样，DDD 还建议您编写返回有效状态的对象的类的工厂，并且您的对象在每次操作后都以有效状态返回。
DDD 是一种方法，协定的实际实施应该由您来完成。 在 .NET Framework 4 中，代码协定可最大限度地减少您的工作量，有效帮助您成功地进行实施。 我们来更详细地了解一下 .NET Framework 4 中的固定条件。
固定条件逻辑在哪里？
固定条件是否在某种程度上与优秀的对象建模和软件设计有关？ 深入了解域至关重要。 深入了解域自然会指导您找到您的固定条件。 有些类根本不需要固定条件。 从根本上说，缺乏固定条件并不是一种警告信号。 对应该包含什么内容以及应该执行什么操作没有限制的类就没有固定条件。 如果这是您的分析得出的结果，那么再好不过了。
假定有一个类代表要发布的新闻。 该类可能有标题、摘要和发布日期。 此处的固定条件在哪里？ 这取决于业务域。 发布日期是必需的吗？ 如果是，则您应该确保新闻始终有有效日期，而“有效日期”的定义也来源于上下文。 如果日期是可选的，则您可以保存一个固定条件，并确保先验证属性的内容，然后再将该属性应用于要在其中使用它的上下文中。 标题和摘要也可以以同样的方式处理。 既没有标题也没有内容的新闻是否有意义？ 如果这在您正在考虑的业务方案中有意义，则您有一个无固定条件的类。 如果没有意义，则要准备好添加几项检查，以防标题和内容为空。
更常见的情况是，无任何行为且充当松散关系数据的容器的类可能缺乏固定条件。 如有疑问，我建议您对该类的每个属性都问问“我是否可以在这里存储值？”，而不需要考虑属性是公用的、受保护的还是私用的（只要是通过方法设定的）。 这样做应该有助于具体了解您是否会遗漏模型的要点。
与设计的许多其他方面一样，如果在设计过程的早期查找固定条件，则会更富有成效。 在开发过程的晚期添加固定条件始终都是可行的，但这样做会增加您在重构方面的成本。 如果要这样做，则必须小心，当心回归。
代码协定中的固定条件
在 .NET Framework 4 中，类的固定条件协定是对该类的任何实例始终应为 true 的条件的集合。 向类中添加协定时，前置条件用于在该类的调用程序中查找错误，而后置条件和固定条件则用于在类及其子类中查找错误。
您需要通过一个或多个专用的方法来定义固定条件协定。 这类方法是实例方法，它们是私有的，返回 void 且有特殊属性（ContractInvariantMethod 属性）加以修饰。 此外，固定条件方法不得包含定义固定条件所需的调用之外的代码。 例如，您不能在固定条件方法中添加任何类型的逻辑，无论逻辑是否纯净都不行。 您甚至不能添加只是用于记录类的状态的逻辑。 下面介绍如何为类定义固定条件协定：
public String Title {get; set;}
public String Body {get; set;}
[ContractInvariantMethod]
privatevoid ObjectInvariant()
{
Contract.Invariant(!String.IsNullOrEmpty(Title));
Contract.Invariant(!String.IsNullOrEmpty(Body));
}
}
NET技术：代码协定中的固定条件和继承，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
