1

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

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

一些伪代码：

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

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

1 回答 1

4

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

希望这可以帮助。

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

于 2011-08-05T09:53:26.160 回答