DCI piqued my interest when I first heard about it. It seemed to solve some problems I was seeing in the typical model structure of MVC apps. In the end while I still agree with the principles behind context (keeping the primary workflow of a code module linear and organized in one place) I found interactions (mixing in behaviour with data) to be largely unnecessary in actual practice.
The problem DCI purports to solve with OOP is in fact largely caused by failing top apply OOP properly (yeah, yeah no true Scotsman...). Issues like overloading objects with too many responsibilities (MVC models do this almost always), relying on inheritance when composition is what is needed, not defining and enforcing module or transactional boundaries and naively applying DRY to everything all lead to high coupling and low cohesion and ultimately cause the problems that DCI attempts to solve. However they can be solved by simple avoiding the above and using simple principled objects with clear dependency trees and boundaries.
Bottom line: Follow the basic principles of OOP and SOLID instead of just paying them lip service and no secret sauce is required.
It seems that they are trying to develop a model where object behavior can be restricted or modified depending on its uses. In fact, it is a quite important problem and there exist many general models and specific techniques which tackle different aspects of this problem, for example:
As I understand it, DCI slims down classes by moving contextual responsibilities in a contextual helper class. DDD shifts this problem by introducing the Bounded Context concept, where you are encouraged to have, for example, a dedicated, specialized "User" class in the "Billing" context and another specialized "User" class in the "Content" context (and having mappers/adapters between these two classes).
In my experience, most devs start with an ORM/data store/framework/pattern and try to shoehorn the solution into it.
I think Domain Driven Design[0] has held up well as an alternative to this - especially the strategic design patterns. The DDD strategic patterns are all about expressing the model in the domain language and finding the boundaries around clusters of interrelated model concepts (DDD calls these "Bounded Contexts").
DDD is often mentioned alongside CQRS[1] these days, but it also works for plain old OOP and functional systems as well.
If you want to play Entity-Component-System. I'd suggest you check out A-Frame, a WebVR framework that uses and promotes Entity-Component-System:
https://aframe.io/
I spent quite a lot of time exploring ECS before building my own ECS library for developing 2D games. I have found that with my (minuscule) ECS library it greatly alleviates just about all of the issues I was facing with normal OOP. Everything scales extremely well, the code is almost crystal clear, and it makes code structure very simple. I'm not sure how you could effectively apply ECS outside of simulation style applications but I'm interested to see what influence it has in other domains such as UI.
Well, of course ECS does that. It's ultimately the same approach to data as a normalized relational schema. It's a bit of upfront work but the flexibility of processing and optimization is awesome.
For UI the issue is one of expressing lightweight dependencies, which may be detached and recombined easily. I am currently exploring an approach that combines "imgui" concepts with hierarchical path data, akin to the hard and symbolic links in Unix. Having the path as data allows assemblages of partial routes to be combined to express a "final" data point. The data itself may not entirely exist in a physical tree structure but instead be a combination of procedural data, stored data, and a parser.
When you further qualify by time/transaction you get EAVT like Datomic and then just do queries (potentially recursive), and can implement semantics like "classes" over it.
It's strange that ECSs only have traction in game development. I agree with all the advantages you mentioned, but additionally, they solve the structure-of-arrays/array-of-structures performance discrepancy; this is something Jon Blow is working on with his Jai language.
> I spent quite a lot of time exploring ECS before building my own ECS library for developing 2D games.
The problem with DCI is that it didn't have native support in any programming language. Coplien, one of the co-founders of DCI is actually working on a programming language called Trygve which implements these ideas.
I only skimmed the article, but it the description sounds a bit like some of the ideas in ContextL, an extension of CLOS (Common Lisp's Object System):
Is that still being developed? Has some recent commits, but parts of the manual are clearly somewhat out-of-date; for instance, in 5.3.1 (Defining Generics) there's a "try doing that in Java!" that's trivially accomplishable with Java generics.
Since when can you create new objects of a generic type T in java using "new"?
class MyGeneric<GenericType>
{
public GenericType stupidJava()
{
return new GenericType();
}
}
You still can't do that with java. In order to create a new instance from a generic type you must use the reflection mechanism. Or alternatively do what Java people did for ages, factory classes.
Trygve allows you to use "new" keyword. So no, the manual is correct.
To be honest, the ideas on the article look that they can be implemented in a straight way using Lisp's CLOS.
EDIT: The post below beat me to it, it was already implemented in CLOS...
"ContextL is a CLOS extension for Context-oriented Programming (COP), and was the first language extension that explicitly supports COP when it was originally introduced in 2005."
I'm not sure I understand the example in https://github.com/amolenaar/roles/blob/master/example.py. Maybe it's just too simple to demonstrate the benefits and so the code seems a little contrived. But why have the `context` thing at all? Why can't TransferMoney just handle the money transfer logic itself, without adding a whole extra layer of indirection with the `context` and then the MoneySource and MoneySink?
DCI despite its claims, simply cannot be easily understood by its target audience. It claims to represent a better mental model, but it mostly succeeds in alienating those looking for a better way to model concepts in the world, abstract and real. The arrogance and condescension shown to newcomers by adherents like Jim Coplien, doesn't help.
The problem DCI purports to solve with OOP is in fact largely caused by failing top apply OOP properly (yeah, yeah no true Scotsman...). Issues like overloading objects with too many responsibilities (MVC models do this almost always), relying on inheritance when composition is what is needed, not defining and enforcing module or transactional boundaries and naively applying DRY to everything all lead to high coupling and low cohesion and ultimately cause the problems that DCI attempts to solve. However they can be solved by simple avoiding the above and using simple principled objects with clear dependency trees and boundaries.
Bottom line: Follow the basic principles of OOP and SOLID instead of just paying them lip service and no secret sauce is required.