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