Re: "Code must be Chunkable"

James Coplien wrote:
[...]
>> For instance, to say that an account is not a not object... going all
>> the way back to the bad old days of COBOL, an account has always been
>> treated as as object, even if not coded in OOP form.
> 
> I don't think so. Have you ever worked in finance or banking? I think 
> your statement holds true only in lectures by college professors or by 
> people outside of finance. In the latter case, the object isn't the 
> account, but the name of the account (sometimes called its account 
> number). Can you give me a single example in the software of a real 
> financial institution where the balance is actually stored as a data 
> member of an object in memory?

I have yet to watch your presentation (though I am very much looking 
forward to doing so), and I know that you and Trygve generally know what 
you're talking about.  So I may be a fool rushing in where angels fear 
to tread.  But...

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.

> 
> After you answer that, we can discuss the difference between 
> object-oriented programming and class-oriented programming. One of the 
> major features of DCI is that it supports object-oriented programming. 
> Very few languages support object-oriented programming directly: they 
> support class-oriented programming instead.

Often quite true.

> 
> 
>> That's because
>> banks treat accounts as objects --people have them, they have ID
>> numbers, etc.
> 
> You are perhaps suffering from being trapped in the old paradigm, where 
> everything must be an object. Stick with me here for a few paragraphs as 
> I explore this. You would have been an excellent student of Kant. In 
> fact, if you look at people's mental models of their worlds, they think 
> of much more than objects. An ID number is not an object: it is a handle 
> to an object.

Agreed.

> An account is not an object: it is a role that several 
> objects together can play.

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

> 
> Do the following experiment. Go to someone who has recently done a money 
> transfer in their bank. Ask them to give you a general user story for 
> it. Inevitably, I find people saying, "I decide on an amount, and then I 
> witdraw that money from one account and put it into another account." If 
> they speak more precisely they will use terms like "source account" and 
> "destination account." A "source account" is not an object. It is a role 
> that something can play (like a savings account).

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.

In Ruby:

def transfer(source, destination, amount)
  ...
end

peter = Account.find(:peter)
paul = Account.find(:paul)

Now we have handles to Peter's account and Paul's account.  Of course we 
don't have the accounts themselves, but we have object representations 
of them.

Now we can do
transfer(peter, paul, 100)
in which case peter plays the role of source account
or we can do
transfer(paul, peter, 100) in which case paul plays the role of source 
account.  Where's the problem here?


> 
> For the time being we can pretend that savings account is a class whose 
> objects can play the role of "source account." That fits the simple 
> Kantian model of the world, where most things must be objects. But if we 
> go more deeply, to the level of that domain (in the sense of DDD) we 
> find that it is not an object — certainly not in the "D" sense of "Data" 
> in DCI. It is a collection of use cases, of behaviors. 

The point of a "traditional" object, it seems to me, is that it unifies 
data and behavior in one package.  DCI may be a valid form of analysis, 
orthogonal to "traditional" object analysis, but that doesn't mean that 
objects revealed by traditional object analysis (such as the Account 
instances in your example) aren't objects.

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