DCI 架构有哪些可能的设计？答案

【问题标题】：What are possible designs for the DCI architecture?DCI 架构有哪些可能的设计？
【发布时间】：2011-02-04 10:21:41
【问题描述】：

在不同的 OOP 语言中实现 DCI（数据、上下文、交互）架构的可能设计是什么？我想到了 C++ 的基于策略的设计 (Andrei Alexandrescu)，Java 的 DI 和 AOP。但是，我也考虑过使用状态设计模式来表示角色，并使用某种模板方法来进行交互......还有哪些其他可能性？

【问题讨论】：

从原始论文来看，Scala 中也有特征，Ruby 中也有开放类。我的 Stete 设计模式建议是错误的，因为如果我正确理解 DCI，则数据应该与了解它可能存在的所有上下文隔离开来。
您的理解是正确的，DCI 的主要关注点之一是使系统是什么（数据）独立于系统是什么

【解决方案1】：

在大多数语言中执行纯 DCI 非常困难，您通常会遇到两个问题之一。静态类型语言（如 Java）通常以某种包装解决方案结束，这会产生self schizofrenia 问题。允许您在运行时随意附加新实例方法的动态语言通常会遇到范围问题。当对象不再扮演角色时，RoleMethods 仍然可用。

我所知道的不同语言的最佳匹配

如果您查看fullOO，您会发现几种语言的示例。包括在我自己的项目 Marvin 中，这是一种专门为支持 DCI 而设计的语言。目前，Marvin 的大部分内容与 C# 相同，因此您可以说它是 C# 的扩展，而不是它自己的语言。

【讨论】：

【解决方案2】：

在 Java 中，没有字节码生成，我会使用装饰器模式作为上下文，但是我会代替类来装饰接口，这将更加灵活。数据将通过实现接口的类来表示。交互将使用手动依赖注入到模板方法中来完成。

【讨论】：

DCI 在 Java 中很难，但使用 Qi4J 可以让您非常接近。 Java 中不同实现产生的主要问题是身份问题。 DCI 是关于对象而不是类。装饰器模式是基于类的。在 DCI 中，（已经实例化的）对象的行为通过角色方法进行扩展。这些方法是上下文内部的，而不是其他类或其他对象。换句话说，你不能用装饰器模式做 DCI