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 带来的可读性：
- 跨业务功能的上下文切换比较少，而且更接近心智模型（基于角色），而不是程序员模型（基于领域）；
- 包含多态（inclusion polymorphism）几乎完全消失了。调用 Foo 就得到 Foo：而不是子类型化层次中派生出的众多 Foo 里的一个。
- 我可以找到有业务价值的测试点：也就是说，我可以做到真正的 BDD（行为驱动开发）。这更易于开发测试用例，以支持调试。
- 不太需要进行运行时调试，因为代码在编译时就更加易读。
Trygve Reenskaug 强调说，要理解 DCI，需要“减少对类抽象的关注，勇于接受更适用于以上对象结构的额外抽象”，还需要“增加一种既能扩充类，又仍然保持对象身份的对象抽象”，即角色。
查看英文原文： Data, Context and Interaction : A New Architectural Approach by James O. Coplien and Trygve Reenskau
评论