DCI Talk by James Copelien
James Coplien(@jcoplien), thankfully, gave us a talk titled "DCI and Ruby — the current DCI language of choice". Which was arranged by @kakutani to, I guess, let us, Japanese Rubyists, know about true DCI concept given by its main advocator. Thanks guys for the great opportunity.
Here, I'll wrap up what I got from today's talk. It probablly includes many misunderstanding, though. It doesn't precisely represent what @jcoplien said. You're be warned.
At the first, he said that almost all of us didn't understand truely what OOP was. What we thought of ourselves understanding was "Class-Oriented Programming", not "Object-Oriented Programming". It can be said that only JavaScript guys are actually practicing it now.
"Object" originally represents our mental model and it has no relation to class, polymorphism, or other such so-called "OOP" terms. It's for personal relation to computers as when we recognize "object" on a computer screen and touch it with mouse. When Alan Kay, the inventor of Dynabook, refers to "object", he's talking just about "object", not class or other things at all.
Historically, limiting factor of our programming has been changing as below:
- CPU-centered
- Storage-centered
- Communication-centered
I don't have to explain about 1 and 2, but, for 3, some addition is needed; "Communication" can be done through "bus" such as "hardware bus" connecting CPU, storage, or other hardwares, and "information bus" that represents interactions by objects. What matters here is interactions and reflective dynamics of such forms. There, class diagrams fail. Object diagram just can do.
Such grasp on programming, that is, what matters is objects and their interaction fits way of Agile thinking, "Individuals and interactions over processes and tools". Business values come from objects. Program's values come from its use cases. It's never from class or something like it.
Classes prevent us from knowing about it. We can't reason about objects interaction if we think about only classes. The form of the interaction is just "program". This form lives in neither single object nor classes. It dwells in "runtime" interactions.
What we should think about is not class hierarchy but use case. Use case is "Context", like a stage director, which knows what "Role" objects should assume and teaches them how to play. In DCI, classes are just dumb. Algorithm represents "Role" and "Context" allocates the "Role" to object. "Context" is like a stage. "Data" play their "Roles" and "interact" with each other on the stage.
From around then, I was really fatigued to hear English discussion, so my notes almost ended here. I was very impressed by what he said, "Going to OOP from class-oriented programming is a paradigm shift." I saw that I didn't understand what OOP is actually. I'll read his and others' books on OOP, patterns, and architecture designs, and dig more into better thinking on it.
