开发者

What are possible designs for the DCI architecture?

开发者 https://www.devze.com 2022-12-25 12:11 出处:网络
What are possibles designs for implementation of the DCI (data, contexts, interactions) architecture in different OOP languages? I thought of Policy based design (Andrei Alexandrescu) for C++, DI and

What are possibles designs for implementation of the DCI (data, contexts, interactions) architecture in different OOP languages? I thought of Policy based design (Andrei Alexandrescu) for C++, DI and AOP for Java. However, I also thought ab开发者_如何学Pythonout using State design pattern for representing roles and some sort of Template method for the interactions... What are the other possibilities?


Doing pure DCI is tough in most language you usually run into one of two problems. Statically typed languages such as Java usually ends up with some kind of wrapper solution which creates a self schizofrenia problem. Dynamic languages that let you attach new instance methods at will at run time often suffers from a scoping issue. The RoleMethods are still available when the object is no longer playing the role.

Best fits I know of for different languages

  • Marvin: Design for DCI and as such has full support
  • Ruby using Maroon. If you are using the maroon gem (or similar) then there's full support for DCI in Ruby.
  • Java: Qi4J
  • C# Extension methods (Scoping issue and overload issue) possibly together with dynamic. I've had an implementation based on Clay but that creates an identity problem
  • Native Ruby: Method injection Scoping issue with methods being available when the object no longer plays the role
  • C++: Templates. Scoping issue method life span is the same as the object life span

if you take a look at fullOO you will find examples in a few languages. Including in my own project Marvin which is a language specifically designed to support DCI. At present most of Marvin is identical to C# so you could say it's an extension to C# more than a language of it's own right.


In Java, without byte-code generation, I would use Decorator pattern for contexts, however I will instead of classes decorate interfaces, which will be more flexible. Data than will be represented through classes implementing the interfaces. The interactions will be done using manual dependency injection into Template methods.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号