object modeling

Tom Phoenix rootbeer at redcat.com
Sat Sep 29 16:23:16 UTC 2007


On 9/29/07, Jimmie Houchin <j.squeak at cyberhaus.us> wrote:

> Is this a correct way to do this in Squeak or am I off base?

I don't see anything necessarily wrong with your approach. On the
other hand, I don't see that it's an especially helpful way to
approach your task. The best way to find out whether it's "correct" or
not is to try to implement it. To find out whether one way is better
than another, implement both.

In some languages, there's mostly one way to do a given task. But
Squeak (Smalltalk) generally allows you to structure your code and
data in a wide variety of ways, depending upon your needs and skills.
Further, it allows you quickly and easily to refactor your design once
you see enough of it to know what changes are needed.

In particular, factoring out a person's birth info might make
especially good sense if that BirthInfo object might be passed around
without the rest of the Person; I can imagine that for some
applications. But if the Person and the BirthInfo always stick
together, I foresee many methods delegating like this, for little or
no benefit:

  Person>>daysUntilBirthday
    "Answer the number of days (0-365) until this Person has a birthday."
    ^self birthInfo daysUntilBirthday

On the other hand, if you might have place-and-date-and-more about
Birth, and also similarly about Death, Marriage, Adoption, Childbirth,
and so on, an EventInformation object might make sense to unify the
way you handle that data. It's all about the nature of your task, and
how it can best be broken into manageable pieces.

In the end, there's no substitute for experience. Have a good one!

--Tom Phoenix



More information about the Squeak-dev mailing list