From: James Coplien Date: 2010-02-17T01:41:17+09:00 Subject: 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/.