goran.hultgren at bluefish.se wrote:
> Jimmie Houchin <jhouchin at texoma.net> wrote: 
>>goran.hultgren at bluefish.se wrote:
[SNIP]
>>In the code I was playing with, I initialize the JHPersonName object 
>>when JHPerson is created. Yes, the JHPerson object must always have a 
> 
> Hmmm, well it looked like you simply created an "empty" JHPersonName
> instance in the #name method. Right? Anyway, I think you understand what
> I mean.

Yes, that is correct. In my head I have understandings of how I'll 
populate the data. But that is why I seek wisdom from those who have 
gone before me. My understandings can easily be brought to nought.
[snip]

>>Isn't that one of the purposes of decomposing a large object into 
>>smaller objects of common data and behaviour?
> 
> 
> Yes, decomposition is good. I was just opposing of the line:
> 
> p name first: 'John'.
> 
> Here you ask p (the JHPerson object) for it's name object and then you
> send a message to the name object directly. I agree - this is bordering
> on nitpicking but you are essentially hardcoding a dependency here - the
> code depends on the fact that JHPerson has a JHPersonName instance kept
> internally. My version removed that dependency:
> 
> p firstName: 'John'

Ahh!!! and the light goes on. :)
I don't necessarily think its nitpicking, but rather helping me to get 
it right. If I didn't want that I shouldn't ask. :)

> ...this line has no idea what the JHPerson object will do with the
> String sent in. No dependency on any internal representation. But again
> - nitpicking. I have seen much worse cases of this kind of "ripping your
> guts out-code". When I taught OO I used to tell the analogy of trying to
> find out if John ate a sausage for dinner - two approaches, first the
> datacentric newbie approach:
> 
> 	john intestines stomach contents includes: #sausage
> 
> ...and my slightly more polite message based OO approach :-) :
> 
> 	john didYouEat: #sausage

The light shines on.

> The first solution breaks encapsulation three levels deep, it hardcodes
> the fact that John has intestines and that those intestines include a
> stomach and that the stomach has something called contents that
> understands the message #includes:. A long hariy daisychain of
> dependencies making changes to that object structure immediately
> breaking this line of code.
> 
> The second version just relies on the fact that if we are polite to John
> and asks him if he ate a sausage it is up to him to come up with the
> answer. :-)

Bueno, mi amigo.

[snip]
>>If I put all of that data into JHPerson doesn't that reduce/eliminate 
>>the need for JHPersonName?
> 
> Again, I wasn't implying that you should flatten anything out - I just
> reacted to the "gut cutting". :-)

Me don't like "gut cutting", me do like sausage. :)

I've read much theory, but have never applied any. I knew that when I 
got there, that is where the real learning would happen.

I was just concerned I might be doing bad OO if my Person object had 
dozens or 100+ instance variables. So what I should do is decompose into 
smaller objects which properly encapsulate their data/behaviour and 
aggregate those objects into the Person object but create many, many 
instance methods in the Person object which handle the interface to all 
of its sub-objects.

Am I gaining any understanding here, am I making progress. :)
Or do I still miss something?

And again much thanks for educating this newbie.

Jimmie Houchin