
The DCI Architecture: A New Vision of Object-Oriented Programming (2009) - dmux
http://www.artima.com/articles/dci_vision.html
======
lucisferre
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.

~~~
cshenton
Do you think most devs spend enough time thinking through a good way to model
what they're building?

~~~
pbourke
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.

[0] [https://en.m.wikipedia.org/wiki/Domain-
driven_design](https://en.m.wikipedia.org/wiki/Domain-driven_design)

[1]
[https://martinfowler.com/bliki/CQRS.html](https://martinfowler.com/bliki/CQRS.html)

------
RubenSandwich
Another vision of Object-Oriented Programming that has gotten quite a bit of
traction. (Especially in the game development community.) Is the Entity-
Component-System model:
[https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80...](https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system)

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/](https://aframe.io/)

~~~
joeyjojo
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.

~~~
fuwafuwa
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.

~~~
nikki93
The extreme version of an ECS is an EAV:
[https://en.m.wikipedia.org/wiki/Entity–attribute–value_model](https://en.m.wikipedia.org/wiki/Entity–attribute–value_model)

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.

------
tbrownaw
The most interesting part is that as good as this sounds I haven't heard of it
again since that article first came out.

~~~
mempko
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.

[https://github.com/jcoplien/trygve](https://github.com/jcoplien/trygve)

~~~
al2o3cr
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.

~~~
mempko
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.

------
aryehof
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.

