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

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

来源

2010-04-05 Gabriel Ščerbák

从原来的纸，也有在斯卡拉性状和公开课在Ruby中。我的Stete设计模式建议是错误的，因为如果我正确理解DCI，应该将数据从所知道的所有上下文中分离出来。 – 2010-04-23 13:33:47

你的理解是正确的它的DCI的主要关切作出什么系统是独立的系统是什么 – 2012-03-05 11:10:06

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

来源

2010-04-28 23:01:38

DCI是很难在Java中，但使用Qi4J得到是你非常接近（数据）之一。 Java中不同实现产生的主要问题是身份问题。 DCI是关于对象而不是类。装饰者模式是基于类的。在DCI中，（已经实例化的）对象的行为通过角色方法进行扩展。这些方法是内部的而不是其他类或其他对象。换句话说，你不能用装饰模式来做DCI – 2012-04-04 13:38:10

做纯粹的DCI是在最艰难的语言，你通常遇到的两个问题之一。像Java这样的静态类型语言通常以某种封装解决方案结束，这会产生一个self schizofrenia问题。允许您在运行时随意附加新实例方法的动态语言经常会遇到范围问题。当对象不再扮演角色时，RoleMethods仍然可用。

我知道

最适合不同语言

马文：对DCI，因此设计有完整的支持
红宝石使用栗色。如果您使用的是maroon gem（或类似的），那么Ruby中的DCI将得到全面支持。
Java：Qi4J
C＃扩展方法（范围问题和过载问题）可能与动态一起使用。我有一个基于Clay的实现，但会产生身份问题
原生Ruby：方法注入当对象不再扮演角色时可用方法的范围界定问题
C++：模板。范围界定问题方法的寿命是一样的对象生命周期

，如果你看一看fullOO你会发现在几种语言的例子。在我自己的项目中包括Marvin，这是一种专门为支持DCI而设计的语言。目前，Marvin的大多数与C＃相同，所以你可以说它是C＃的扩展，而不仅仅是它自己的权利。

来源

2012-03-14 12:17:17

你应该把Ruby的例子改成Maroon。 :) – ciscoheat 2013-06-01 03:18:01

@ciscoheat thatnks指针 – 2013-06-01 08:55:53

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

回答

相关问题