BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

DCI:James O. Coplien和Trygve Reenskau提出的新架构方法

| 作者 Sadek Drobi 关注 1 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2009年5月15日. 估计阅读时间: 7 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

James O. Coplien和Trygve Reenskaug最近发表了系列文章的第一篇,该系列文章介绍一种面向对象编程的新架构方法,该方法基于DCI(数据、上下文和交互)模式

作者在第一篇文章里主张,即便面向对象编程有助于描述结构,但它并不能充分表明用户的心智模式,因为它不能表示“最终用户的行为需求”。为了说明“行为”到底指什么,他们举了一个储蓄账户对象的例子,该对象可以减少余额,也能提款。按照Coplien和Reenskaug的意思,“这两种行为完全不同”:“减少余额只是数据的特征:它是什么。提款则反映了数据的目的:它做了什么。”事实上,能减少余额在任何情况下都是以数据为特征的——这一点是不变的。相反,提款则涉及“与ATM或审计跟踪之间的交互”——这是动态的,不再关乎“是什么”,而关乎“做什么”。

虽然用户模型很自然地结合了是什么和做什么这两个部分,但“在面向对象里很少有内容会帮助开发人员在代码中描述做什么,在MVC里则根本就没有。”“面向对象将这两部分混在一起”,很难把“简单、不变的数据模型和动态的行为模型区分开来”,但从架构和维护的角度来说,把两者分清楚可是很必要的。另外,纯粹的面向对象要求对大型算法进行分割,将各细分部分(也就是方法)分布到对象中,对象与给定的方法有着紧密的联系。即使有些算法能存在于单个对象中,“有意思的业务功能往往还是会跨多个对象。”

James和Trygve提倡用DCI模型描述这些动态的行为模型,DCI模型基于以下三个概念:

——数据,描述领域对象,表示不变的部分;

——交互,以角色的语言去描述,角色是“对象能进行的行为的集合”;

——上下文,可看成是“一个表格,将角色的一个功能(表格的一行)映射到一个对象方法上(表格的列是对象)。表格根据Context对象中程序员提供的业务智能进行填充,对给定的用例来说,Context知道什么对象应该扮演什么角色。”

作者用转账用例给读者做了具体的说明。转账会涉及储蓄账户和投资账户,但用户在讨论这个用例的时候更喜欢用“源账户”和“目的账户”。这全都是角色,而转账的交互可以用角色的算法描述。上下文不同,角色可以由不同的对象去扮演:在这个具体的例子中,源账户角色将关联到储蓄账户对象上。

代码中能表示角色的一般设计概念是Trait,但Trait的实现依赖于特定编程语言中存在的结构:Scala中的Traits、Squeak Smalltalk中的Squeak Traits、C++中的模板等……DCI方法的最大好处是,作者提供的示例代码“几乎就是用例描述文字的自然展开”:

比起让逻辑主观任意地跨越许多类的边界,DCI将更容易理解——因为更符合最终用户的心智模型中逻辑的自然组织。

这篇文章引发了很多评论和批评,让James和Trygve提供更多精确的DCI概念

Michael Feather和很多其他评论者认为,把转账的任务指派给源账户太随意了,这实际上并不符合用户的心智模型,在用户看来,转账并不是由哪个账户来完成的,而是由银行或交易对象完成,“交易对象映射到交互的用户概念”。比如说,John Zabroski建议用分析类TransferSlip。另一些人则认为,DCI所涉及的正是人们早已知道的内容:某些语言中的“Traits”,“函数编程的一般思想(算法比较紧要、应该能表达清楚)”,等等……

James O. Coplien回应道,DCI“试图结合二十世纪八十年代面向对象里很多很好的领域建模概念,重现过程语言(比如Fortran)过去用算法表达给我们带来的方便性”。像Scala这些语言中的Traits是一种实现方法,但在其它语言里可以用不同的结构去完成DCI架构。实际上,重要的并不是文中建议的工具或使用的例子,而是区分以下内容的架构方法:1)任何情况下都专属于领域对象的行为;2)特定于上下文的行为,这种行为属于业务逻辑,往往跨越多个对象。正如Bill Venners所说,“如果应用的十个用例都涉及账户概念,结果可能每个用例都有一些行为进入了Account类”,这对设计者来说也是个很大的挑战。所以,运用DCI让“对象在每个上下文中有一个不同的类”是“改善OO程序可理解性的一种尝试”:

[……]这篇文章指出,有时候你可能在对象中放置了太多的行为,因为在不同上下文中要用到这些行为的不同子集。作者建议用Traits对额外的内容进行建模,Traits可以映射到用户心智模型的任务上去。然后在某个特定的上下文或用例中,再往基本的领域对象中添加上下文需要的Traits。

Coplien指出了DCI使代码更易于阅读和调试的四个理由,以强调DCI带来的可读性:

  1. 跨业务功能的上下文切换比较少,而且更接近心智模型(基于角色),而不是程序员模型(基于领域);
  2. 包含多态(inclusion polymorphism)几乎完全消失了。调用Foo就得到Foo:而不是子类型化层次中派生出的众多Foo里的一个。
  3. 我可以找到有业务价值的测试点:也就是说,我可以做到真正的BDD(行为驱动开发)。这更易于开发测试用例,以支持调试。
  4. 不太需要进行运行时调试,因为代码在编译时就更加易读。

Trygve Reenskaug强调说,要理解DCI,需要“减少对类抽象的关注,勇于接受更适用于以上对象结构的额外抽象”,还需要“增加一种既能扩充类,又仍然保持对象身份的对象抽象”,即角色

查看英文原文:Data, Context and Interaction : A New Architectural Approach by James O. Coplien and Trygve Reenskau

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

很好.... by Yu Peter

这个跟我这年来在WEB开发中提出的 DMCV模式不谋而合
我一直设想并在一些项目中将DMVC进一步解释为 数据业务 业务模型 业务实现机制 和交互视图
所持有的观点是: 业务模型不常变 但业务流程常变.引申即可举例为:大楼不常变但出入规则常变,机场跑道不常变但起飞降落规则常变. 将业务的模型单独抽取出来,把一个业务内的流程控制放在另一层.甚至于对数据本身的处理机制单独处理.更有利于软件开发维护.

Re: 很好.... by 王 虎

精辟~~

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT