Re: "Code must be Chunkable"

Marnen Laibow-Koser wrote:
> James Coplien wrote:
> [...]

> I cannot imagine *not* representing a bank account as an object in a 
> bank software system.  The balance is part of such an object's state.

No. In every example I've seen, financial records are kept as audit 
trails that track deposits, withdrawals, interest accruals, etc. There 
is no "balance" sitting on a disk nor sitting in memory. The balance is 
computed as the sum of accruals, less the sum of decreases, against some 
baseline. All these data are in a database — but no balance.

Let me reiterate my question, which yet goes unanswered here: Can you 
name me one, real, concrete system in real use, in a real financial 
institution, where the account is an object, and its field is a balance, 
within a system that manages the account itself?


> Not necessarily agreed.  In the example below, you're talking about 
> accounts as objects while claiming you're not doing so.

I start talking about them as objects as a way to introduce the concept. 
Then I move to the real design to introduce how Contexts can replace 
objects in some contexts.



> I believe that you're getting trapped by ambiguous language here.  A 
> "source account" is not an object, to be sure, but that doesn't mean an 
> *account* isn't an object.  "Source account" and "destination account" 
> are roles, but only accounts (or objects that behave like accounts) can 
> play those roles, it seems to me.


I agree that this is an issue of misunderstanding. Your code example has 
nothing to do with the point I'm making. Think of the point I'm making 
as having to do with the psychology of perception (which is what Dahl 
and Nygård viewed OO as being all about in the end). In your example, 
peter is a name for an identifier which contains a reference (an 
address, another kind of name) of something called an account. That it 
can be an object in Ruby doesn't mean that it properly reflects the 
proper mental model. For example, I can also do this in Ruby:

   def account (account_id, amount)
       . . . .
   end

So what? And I have the same "so what" reaction to your code.

I agree with your above analysis that accounts, or objects that behave 
like accounts, can play these roles. Can my phone bill play the role of 
an acccount? If it does, is it an account in the banking sense? Of 
course not. But I can transfer money to it — because it can play the 
role of a source account. So it *can* be a data object. My point is that 
it doesn't have to be, and that in fact, very few accounts are. They 
rather are Contexts than Data objects.

This facet of the underpinnings of DCI is not about language expression, 
but of about how we think. That's the paradigm shift part.
-- 
Posted via http://www.ruby-forum.com/.