From: Marnen Laibow-Koser Date: 2010-02-18T08:08:02+09:00 Subject: 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 marnen@marnen.org http://www.marnen.org -- Posted via http://www.ruby-forum.com/.