Design by Contract (DBC) 契约式设计

09-05-21 banq
                   

DBC最早是有Bertrand Meyer 的 Eiffel programming language提出。DBC在Evans DDD的柔性设计中也谈到了。所以,DDD是集OO设计大成,正因为它是一个总结,你就不能把它和其他思想并列在一起,这有上下层次之分,我在这里强调DDD了,就是排斥其他思想,这是很多初学者外行看热闹的误解。

Contract契约是对Object对象行为的描述表达,也就是说:一个对象的行为方法做到什么样为合适?这是有数据库背景的人转到OO上一个鸿沟,而通过契约来约定是一种主要的设计方法。

http://en.wikipedia.org/wiki/Design_by_contract

DBC分三种:

1.Post-conditions 后置条件postcondition 表示调用一个方法一定会得到的结果。类似断言Assertion,如果语言不支持断言,那么我们就必须自己写断言,也就是测试驱动了。

2.Pre-conditions 前置条件precondition ,预先保证后置条件必须满足前置条件。

前置条件必须满足,后置条件必须实现,通过契约的前置和后置条件的结合,就不会出现有隐藏的功能obligations,这样,事情清清楚楚地被摆出来。这样设计才能落实为代码,保证正常的对象调用。

3.类不变量class invariant 表示对象状态的断言,执行完任何操作后都都应该被满足,不变量还是对聚合体进行完整性严格定义。

不变性意义非常重要,不变性意思是对象的所有属性必须由其方法来保证一致性。DDD推广到根对象要通过方法保证其聚合体内所有对象的属性保持一致性。比如ForumThread的addMessage就保证加入新的Message以后,其聚合体内相关属性一致修改,保持不变性是一个排他性过程,或者说需要由锁或事务来完成,这又和伸缩性scalable设计有关。

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=36063&message=23122565#23122565

[该贴被banq于2009-05-21 15:00修改过]

[该贴被admin于2012-10-17 09:34修改过]

                   

3
xmuzyu
2009-05-21 19:44

现在觉得面向对象的设计是一种艺术的活动,有些职责分配给任何对象,其实都可以完成功能,但是只有我们把职责分配给合适的对象,这样才更加容易理解,维护和扩展。还有那个后验条件非常重要,这个条件也可以看成是职责的后验条件,也许一个职责有很多个方法来完成,而这些方法完成后,这个职责的后验条件一定要满足,一个粒度粗点,一个粒度细点。

最近再好好看看<<UML和模式应用>>,这本书我觉得对面向对象编程很有用。

banq
2009-05-22 10:38

DBC的Contract 契约主要是谈对象之间的行为关系,就好象我们通常说的行为关系学。

而DDD主要从聚合体这个集合来说明,聚合体也就是一个集合,容易给人一种静态关系的错误感觉,但是适合有关系数据库背景的人学习提升。

Contract和聚合体应该是讲的同一个东西,侧重点不一样,聚合比较有高度,Contract比较更有行动力,侧重聚合体内对象之间行为关系。

Directory Enabled Network–new generation (DEN-ng) 则拓展了DBC,将DBC的前后条件具化为:权力benefit和义务obligation。

义务行为意思是一个对象必须尽的义务行为,比如维护自己属性的一致性等,这些是它应该做的行为,也就是前置条件;权力是对象能力行为,有多种选择,是对象执行某种行为后,进入一个新的层次,那么无疑拥有新层次状态的新的权力行为,也就是后置条件。

世界电联推出的NGOSS又拓展了DEN-ng,形成契约模板,划分为五个部分:generic, functional, non-functional, management, 和 model

对契约进行了细化规定:

1.一个契约负责管理多个实体之间的交互

2.一个契约包含权力(可以做什么)和义务(必须做什么)

3.一个契约会辨识到在一个场景下实体之间交互的结果状态

4.一个契约能够将内容从一个视图变幻到另外一个视图,这里视图是指可以用UML表达,或者BPEL 或者工作流等。

5.一个契约包含策略 委托和约束

我认为契约的好处就是突出了状态,这个在DDD中好像有意无意被忽视,状态是实体还是值对象呢?没有正面回答,而DBC已经从这个方面给予状态足够重视,因为状态是行为的结果。

NGOSS这种实现DBC模板细化方式虽然有很强的针对性指导,但是在实战中容易范实际和模板对号难以入座,对错了的情况,把Product当成服务,而这时依照Evans DDD对实体和服务的定义,能够很容易找到感觉,两者诞生时间都是2004年左右,可以说是人类OO思维达到的一个同样的高度吧。

NGOSS是什么?

http://www.jdon.com/jivejdon/thread/36319.html

[该贴被banq于2009-05-23 10:45修改过]


tobekong
2009-05-22 16:43

一直很崇拜集理论探索与实际应用于一体的大师,至今难忘手把手带我的毕老师和从网络上结识的刘老师,很荣幸现在能够从彭老师的众多资源中继续受益,在以后的路上我会继续踏实努力,请多多指教,谢谢!