DCI，“上下文”概念的问题以及相互了解的角色

Posted 2023-02-24

【中文标题】DCI，“上下文”概念的问题以及相互了解的角色

【英文标题】：DCI, trouble with concept of 'context' and what roles within know of each-other

【发布时间】：2011-10-19 16:07:31

【问题描述】：

我可能只是在这里遗漏了一个关键概念。我了解“愚蠢”的数据对象。我也明白，角色是当一个哑对象担任该角色时应用到该对象的方法的无状态集合。我也明白，上下文集合了将在正在实现的算法中发生的参与者。但是角色对彼此的了解以及天气必须在上下文中定义，或者在上下文之外对我来说是未知的。

假设一个上下文有两个角色，开始和结束。我们的用例是字符串连接，因此我们将为每个角色分配一个字符串。

一些伪代码：

context concat 
    role start 
        method concat() ...
        method get_value self->as_string
    
    role end 
        method get_value self->as_string
    

    // According to the docs I have read, the context simply kicks off a method in
    // a role, the role handles the rest.
    start.concat(?)    

现在对于 concat()（方法）和 start.concat(?)（调用）可能需要的 3 种不同组合：

角色知道同一上下文中的其他角色（强制角色在其他上下文中不可重用，这对我来说似乎是错误的。）

concat self.get_value + end.get_value 
start.concat() // Not passing 'end' as an argument, 
               // it is already aware of end because
               // it is defined in the same context

角色不知道上下文中的其他角色，因此需要将它们作为参数传入（这似乎很痛苦，因为上下文可以有任意数量的角色，如果上下文从启动我们可能需要的方法开始将 30 个“角色”作为参数传递给一个方法调用，然后将它们一直链接起来！） （注意：在这一个中，角色定义可能会移到上下文之外，并在多个上下文中重复使用）

concat( end x )  self.get_value + x.get_value )
start.concat(x)

对我来说，最明显的选择似乎是不强制上下文启动方法，仅此而已。然后将交互逻辑放入上下文中，将非交互部分放入角色中。 （注意：在这一个中，角色定义可能会移到上下文之外，并在几个上下文中重复使用）

concat() UNDEFINED
start.get_value + x.get_value

这似乎与此相矛盾： http://en.wikipedia.org/wiki/Data,_Context_and_Interaction#Execution_Model

Context 在第一个对象上调用 Role 方法以参与用例。 从那时起，角色调用彼此的方法来执行用例。

【参考方案1】：

在 DCI 中，角色通常知道上下文，并且上下文可以充当所有相关角色的存储库。 IE。第二种情况，角色可以访问上下文，并要求它提供扮演它需要的其他角色的对象。 这是实现细节。将所需的对象传递给角色方法也可以工作。重要的部分是角色通过角色方法相互交互（也就是说，不是通过角色扮演者方法，因为这会产生不幸的耦合）。 角色 - 一般而言 - 预计不会成为跨上下文重用的候选者。一个上下文大致对应一个用例，角色实现用例的行为。通常，该逻辑不能跨用例重用。

希望这会有所帮助。

您可能还想查看介绍 DCI 的 artima 文章，以及 object-composition google group。

【讨论】：

谢谢，我已经阅读了artima的文章。昨天在思考这个问题时，我意识到我已经被细节挂断了，并且没有抓住重点。确切的细节并不重要，重要的是您将“功能”（也称为一组交互）的所有代码放在一个地方（尽管不一定是一个功能），以便在您尝试时拥有所有部分想办法。这个地方是一个上下文，角色是表示该功能/上下文的组件（交互）的一种方式。