Re: DCI Wikipedia article

[Risto Välimäki]

Hi again,

I got some feedback and critique of DCI as response of the Wikipedia article (http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction). I had already thanked Cope for his rather complete rewrite on that article (maybe spam-eater ate my email?). Anyway, here are some feedback from Drozembe:

> Here are several comments to what you are writing - the DCI article. First, if you state that this the pattern language you need to show the patterns it uses. This is missing in this article as well as in the major publication referenced. I have serious concerns that it can be even called the pattern language. 

Is it pattern language or architectural pattern? Or both? Anyways, Wikipedia page for "Pattern Language (software development)" is missing, if someone has too much spare time...

> Second, the statement that DCI complements MVC seems incorrect. You cannot complement the whole with the part.

I think MVC (as a pattern) is separating logic from presentation and DCI is separating business logic from domain logic (or model). In other hand, MVC-U is closely related to DCI as a vision or philosophy.

> Besides, in essence DCI is nothing, but renaming some of the portions of MVC so that it will look easier from the implementation standpoint. 

I think this is just a misconception.

> In reality, it does not simplify, but complicates both the design and the implementation of the application because it requires to create much more classes or objects. It is something that will never be really used. As the analogy, recall that the relational databases have four normalization levels defined, but nobody really goes that far with real database design. There are always the compromises between the complexity and the responsiveness of the database. The same thing here. The real problem is who is teaching OOD and how far those who teach are from the practices of software engineering.

> Third, I am not sure what the actual contrubution of Jim Coplien into DCI besides multiple speeches and attempts to popularize this concept. 

>Fourth, DCI will result and already resulted in unnecessary statements that it replaces MVC which comes from the way the major article from artima.com was written. Drozenbe (talk) 12:50, 25 December 2009 (UTC)

Talk page with my longer response can be seen here:

http://en.wikipedia.org/wiki/User_talk:Rvalimaki

I also add here my response:

>>Thanks for your input. I had written: "DCI is an architectural pattern", but Jim Coplien changed it to "DCI is a pattern language". I think Cope knew what he did, but I'm still not sure what exactly is a pattern language (in software development) and how it differs from "architectural pattern".

DCI is not part of MVC and it really complements MVC. You should use MVC to separate business/domain logic from presentation even if you use DCI. DCI is separating domain logic from business logic and not doing MVC's job. Therefore DCI is complementing MVC, not replacing it. Both are also made by Reenskaug and both are about users and their mental models and not about "observer"-pattern.

About contribution of Jim Coplien, he is co-author of "new vision" article: http://www.artima.com/articles/dci_vision.html. Also you can read google group "object composition", where Cope is quite active. Coplien has also contributed to multi paradigm programming and Reenskaug to role modeling, and both can (maybe) be seen as steps towards DCI (as well as other similar concepts by other CS people). All in all, Coplien had read through the article and quite heavily modified it before you did read it.

I think DCI is still lacking complete real world implementation as framework (as DCI&MVC -framework of course). DCI could be maybe seen as a new programming paradigm and therefore it's not so easy to just read couple of DCI articles and then say this or that about how DCI is going to complicate things or not. Reenskaug published MVC on 70's, and now, 20-30 years later MVC is heavily used. (Usually maybe not as MVC-U (as intented), but at least as a architectural pattern / programming trick). Nobody knows if DCI ever breaks through or if it takes another 20 years to do so. That said, I think that DCI is really great concept that brings Use Cases (or algorithms) back to the programming and stops the madness of splitting all the business logic to tiny parts all over the code.

Actually I'm quite pleased to use current generation of web-MVC-frameworks, mainly CakePHP which is a ruby-on-rails clone for PHP, and I don't actually see the benefits of roles in this concept (However, I can see it with more complex desktop apps). Web apps are generally about displaying and manipulating the data that is usually stored on SQL-databases. HTTP is also stateless protocol and you don't have to care that much about the life cycle of objects: Controller gets users input, reads/writes database through Model and brings up View. After that, all is gone, almost nothing to care about. In web apps, there are quite many atomic actions and "direct manipulation of object" thus fitting ordinary OO & MVC -ways very well. Still there are some Use Cases here and there and they are now a bit too much split up.

As soon as I manage to have some time for "research", I'm going to add "C" or Context part from DCI to CakePHP's MVC without adding "I" (Interaction) == roles. I personally dislike fat models anyway (while I'm not writing for example a computer board game or something other as trivial), so my "M" in "MVC" already resembles "D" in "DCI". This way, putting Context (C in DCI, use cases) part into custom Controllers (C in MVC) and doing some simple redirect-magic, I can hopefully turn CakePHP MVC-framework easily into a "MVCC" or "DCCV"(where M is equivalent to D) or "DCV" in short. Rvalimaki (talk) 12:32, 30 December 2009 (UTC)

[James O. Coplien]

Hi, Risto,

First, I find it interesting that someone would critique a Wikipedia article instead of fixing it.

Second, I can justify DCI as a pattern language on several grounds. It is a collection of semi-group compositions that can be applied piecemeal according to a grammar that guides the compositions, based on archetypical forms. I have started writing the pattern language; it is not yet published, but is a work in progress. It's called "Improv Theatre" and is obviously based on a theatre metaphor.

Why can you not complement the whole with the part? And his statement that this is just a renaming reflects a gross misunderstanding of DCI. Maybe this is an issue of the immaturity of the state of the Wikipedia article at this point.

As for ownership of ideas, I'm pretty ambivalent about who contributed what. Trygve gets credit for the invention and the concept. I'll let Trygve relate what he feels my contributions were so I don't look self-serving.

I simply do not understand the concern about DCI replacing MVC and how the artima article relates to that. I think the artima article is pretty authoritative, and I'd certainly like to know about any problems in it.

Anyhow, Risto, thanks for your continued efforts. Your reply looks fine. I'll try to get back to the Wiki page and add clarifications. Of course, present company is invited to do so as well.

--

You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[Cesario Ramos]

Hi James,

Great that there is a patterlanguage coming out! Any change of sharing the unpublished version for feedback?

The theatre metaphor works great to get the message accross. I used it in several talks and with succes :)

Cheers,

Cesario

Sent from my iPhone

[James O. Coplien]

Hi, Cesario!

For clarification, it might be better to talk about DCI in public as a paradigm. That's how Trygve has been presenting it, and he reminded me that we had agreed to posture it that way.The nitpickers will grill us about the pattern nature of the parts but, hey, no one will challenge a paradigm :-)

A pattern language is in fact a formalization of an architectural style. Talking about the difference between a paradigm and an architectural style starts to split hairs, so we're in the right neighborhood. And the pattern language *will* eventually make it out... For now, it's called Improv Theatre. The current version has little more than a few pattern titles and some "reminder" text to me. The current patterns are:

Cast of Characters (the role design)

Scenes of Action (basically, use cases)

Domain Actors (the objects)

Actor Character Traits (separating role methods from class methods)

Traits Contract (automatic generation of traits interfaces from use cases)

Script per Scene (for each scene define a role-to-actor mapping: the Context)

Improv Script (allows individual players to enact)

Directed Improvisation (the director assigns actors to roles)

Audience Engagement