[摘自DbC原则与实践]Design by Contract的六大原则和六大准则

简介:

1. Design by Contract
的六大原则 :
原则1 区分命令和查询。查询返回一个结果,但不改变对象的可见性质。命令改变对象的状态,但不返回结果。
原则2 将基本查询同派生查询区分开。派生查询可以用基本查询来定义。
原则3 针对每个派生查询,设定一个后验条件,使用一个或多个基本查询的结果来定义它。这样一来,只要我们知道基本查询的值,也就能知道派生查询的值。
原则4 对于每个命令都撰写一个后验条件,以规定每个基本查询的值。结合“用基本查询定义派生查询”的原则(原则3),我们现在已经能够知道每个命令的全部可视效果。
原则5 对于没个查询和命令,采用一个合适的先验条件。先验条件限定了客户调用查询和命令的时机。
原则6 撰写不变式来定义对象的恒定特性。类是某种抽象的体现,应当将注意力集中在最重要的属性上,以建立关于类抽象的正确概念模型。
 
2. Design by Contract 的六大准则 :
准则1 在适当的地方添加物理限制。尤其是那些需要限制变量不应该为void的地方。
准则2 先验条件中尽可能使用高效的查询。如果有必要,可以增加高效的派生查询,并在其后验条件中确保其与较低效的基本查询之间的等价关系。
准则3 用不变式限定属性。如果一个派生查询被实现为一个属性,则应通过类中不变式的断言保证它与其他查询保持一致。在一个类的开发过程中,通常应该先把断言检测的级别设为最高级,使先验条件、后验条件和不变式都得到检测;一旦通过了检测和测试,一般就可以降低断言检测的级别,只检测先验条件,以提过代码的运行效率。
准则4 为了支持特性的重定义,用相应的先验条件确保每个后验条件。这样就允许在子类开发过程中进行各种不可预见的重定义。
准则5 将预期发生的变化和框定规则这两种不同的限制分别放置在不同的类中。这使开发者在扩展已有类时享有更多的自由。
准则6 若有保密性要求,则违背保密性的查询只能被设为私有熟悉在契约中使用。这里的“设为私有”,是对“在契约中使用了该查询的类”之下的层次而言,至于类之上的层次,这个查询当然是可以使用的。

 

本文转自Silent Void博客园博客,原文链接:http://www.cnblogs.com/happyhippy/archive/2006/12/18/601303.html,如需转载请自行联系原作者

相关文章
|
Java
六大设计原则-里式替换原则【Liskov Substitution Principle】
六大设计原则-里式替换原则【Liskov Substitution Principle】
49 0
|
9月前
|
数据处理
软件工程概论---内聚性和耦合性
软件工程概论---内聚性和耦合性
172 0
六大设计原则-迪米特原则【Low Of Demeter】
六大设计原则-迪米特原则【Low Of Demeter】
70 0
|
前端开发 测试技术 定位技术
DDD实战之八:冲刺 1 战术之聚合设计(上)
DDD实战之八:冲刺 1 战术之聚合设计(上)
DDD实战之八:冲刺 1 战术之聚合设计(上)
|
前端开发 小程序 Java
DDD实战之八:冲刺 1 战术之聚合设计(下)
DDD实战之八:冲刺 1 战术之聚合设计(下)
DDD实战之八:冲刺 1 战术之聚合设计(下)
软件架构设计原则--迪米特原则
本专栏内容参考自:咕泡学院Tom老师的《Spring5核心原理与30个类手写实战》,仅作个人学习记录使用,如有侵权,联系速删
软件架构设计原则--迪米特原则
|
设计模式 程序员 uml
设计模式---七大原则
设计模式---七大原则
160 0
设计模式---七大原则
|
uml 程序员 设计模式
|
测试技术 程序员
也谈TDD,以及三层架构、设计模式、ORM……:没有免费的午餐
想在园子里写点东西已经很久了,但一直没有落笔,忙着做 一起帮 的开发直播,还有些软文做推广,还要做奶爸带孩子,还要……好吧,我承认,真正的原因是: 太特么的难写了!   但再难写也要写啊,要等到“能写好了再写”,怕是黄花菜都凉了——尤其是技术类文章,时效性非常强的。
1400 0