DCI，'context'概念问题以及内部角色相互了解的问题

Question

我可能在这里漏掉了一个关键概念。我理解"愚蠢的"数据对象。我还理解，角色是在哑对象扮演该角色时应用于该对象的方法的无状态集合。我也理解上下文集合了将在正在实现的算法中发生的参与者。但我不知道这些角色彼此了解多少，以及它们是必须在上下文中定义，还是必须在上下文中定义。

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

一些psudocode:

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. 上下文在第一个参与用例的对象上调用Role方法。
2. 从此，角色调用彼此的方法来执行用例。

Answer 1

在DCI中，角色通常知道上下文，并且上下文可以充当所有相关角色的存储库。例如，在第二种情况下，角色可以访问上下文，并向上下文请求扮演其他角色所需的对象。这是实现细节。将需要的对象传递到角色方法中也可以工作。重要的部分是角色通过角色方法相互交互(也就是说，不是通过角色参与者方法，因为那样会造成不幸的耦合)。一般来说，角色不应该成为跨上下文重用的候选对象。上下文大致对应于用例，角色实现用例的行为。一般来说，逻辑不能跨用例重用。

希望对你有帮助。

您可能还想查看artima文章介绍DCI和对象组合google组。