Re: "Code must be Chunkable"

> Then at the end, it says that an account isn't really an object at all - 
> but all the previous code has shown it as a concrete object (e.g. 
> Account.find(id)). So an example of what an account role *should* look 
> like in code would be good.

Such code has been posted in the past on object-composition, to which 
you are subscribed, Brian. You're welcome to re-post it here.

Indeed, an Account is not an object, any more than a predecessor is an 
object in the front loader example. It is a role. Remember, the D in DCI 
stands for data. In architecture, we are trying to separate many things 
from the data. MVC separates the data (the representation of 
information) from user interaction. DCI separates use case logic from 
domain logic.

The general approach to DCI is that objects should be pretty dumb. They 
are just-barely-smart data, and are usually primitive. Over the years we 
have been taught that objects should be smart and that their APIs should 
reflect what goes on in the use cases. That creates several problems. 
One problem is that rapidly changing use-case level logic is mixed in 
the same interface with slowly-changing domain interfaces. Another is 
that classes don't provide natural boundaries for the delineation of 
mental models of algorithms (as DCI used to call them when it was DCA) 
or interactions.

An account is a collection of use cases. It is in the "I" part of DCI, 
not in the "D" part. If you look at real banking software, the real 
objects are transaction logs and audit trails. They become re-configured 
in interactions on every use case, where the use cases are at the level 
of a Context object called an account. Except for its housekeeping 
references that set up the current role / instance binding at the audit 
trail and transaction level, the account is stateless. Your bank account 
is not a number sitting in memory or sitting on a disk somewhere, 
anymore than your money is sitting in a bag on a shelf in a bank 
somewhere. It is a computation: a use case. In DCI, we encapsulate those 
in Contexts.

In my talk, I catered to the usual kind of example used by consultants 
and university professors in talking about object-oriented programming, 
where they apply the little white lie of an account being an object. 
Later in the talk I introduce the concept of an account as a context. 
This is a recent and rather advanced concept in DCI.


I can see from the thread below that it was too much for the posters in 
this thread, and that the posters were unable to correlate that example 
with the description in the Artima article. The reason this is a bit 
advanced is that it comes from the design thinking that Trygve and I 
have put into DCI, rather than the nerd-level stuff. It doesn't cater to 
UML-shaped heads, or even to the way that most people characterize 
object-oriented programming. It is one of the more difficult ideas in 
DCI, and it is the one that most people trip on. Most people have so 
much trouble fitting into their mental model that they just say that it 
is wrong, or stupid. It's O.K. if you feel that way: new paradigms are 
hard, and it will take a while to unlearn old ways and to learn new.

The best way is to keep in dialog and to keep trying things out. Try to 
get above the code level and think about this from a design perspective 
(but still with the code in the back of your mind, by all means). You'll 
hopefully get to a turning point where you see programming in a totally 
different way. If you haven't gotten to that point yet, you probably 
have internalized only the nerd part of DCI. That's a good start. But as 
one poster here said: it's not about traits, it's not about injection, 
and it's not about aspects, but about something higher level. It's about 
thinking in objects while being able to separate the algorithm into 
something manageable and understandable.
-- 
Posted via http://www.ruby-forum.com/.