Well factored Objects
jhouchin at texoma.net
Tue Apr 29 16:20:33 UTC 2003
goran.hultgren at bluefish.se wrote:
> Jimmie Houchin <jhouchin at texoma.net> wrote:
>>goran.hultgren at bluefish.se wrote:
>>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.
>>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.
>>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.
More information about the Squeak-dev