Re: "Code must be Chunkable"

Thanks for replying!  I've probably injected myself into a debate that's 
a bit over my head, but that's how learning happens.

James Coplien wrote:
> 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.

That's implementation.  It is irrelevant to interface, no?

> 
> 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?

First, your question probably goes unanswered because the only people 
who could answer it are people who've worked on the proprietary systems 
in question.  I have the impression that not much financial software is 
open source.

Second, it's irrelevant whether balance is a field or a calculation, at 
least if the uniform access principle is still to hold.  As a 
hypothetical user of class Account, I want to be able to call 
Account#balance and get a balance.  I don't care in the least what has 
to go on to get me that balance.

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

OK.

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

So far so good.

> That it 
> can be an object in Ruby doesn't mean that it properly reflects the 
> proper mental model. 

I think of an account as being an object. Doesn't that make it the 
proper mental model for me?

> For example, I can also do this in Ruby:
> 
>    def account (account_id, amount)
>        . . . .
>    end
> 
> So what? 

I don't get your point here at all.  Please elaborate.

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

Why?

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

Uh, what?  You can't transfer money to your phone bill.  You can 
transfer money to your account at the phone company -- and you can do so 
precisely because it is (or behaves like) an account.

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

And I really don't see where you come to that conclusion.

> 
> This facet of the underpinnings of DCI is not about language expression, 
> but of about how we think. That's the paradigm shift part.

Yes, but I so far do not agree with your premises here, which means I 
can't agree with the paradigm that develops from them.  I'm certainly 
willing to be convinced, though.

Best,
--
Marnen Laibow-Koser
[e-mail]
http://www.marnen.org
-- 
Posted via http://www.ruby-forum.com/.