j.squeak at cyberhaus.us
Sun Sep 30 17:44:00 UTC 2007
I want to thank all who have given advise and wisdom in answer to my
question. I am very glad I asked. :)
It seems that the advise was:
1. Don't get too wound up about it. :)
Smalltalk is easy to refactor as true objects/classes
become apparent in the code.
2. Its about behavior and not data structures.
3. Potential independence of the object outside of its owner/possessor.
Tom Phoenix wrote:
> 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:
> "Answer the number of days (0-365) until this Person has a birthday."
> ^self birthInfo daysUntilBirthday
When modeling this I hadn't thought about the BirthInfo being passed
around per se, it was really more of a data structure providing a
variety accessor methods to the data.
> 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.
The website I am developing is a church website for the Worship Team. So
that definitely affects how I model the person. I am trying to offer a
whole lot of functionality that the current website (that I didn't
design) that I am migrating from has. So when I look at the data I have
to migrate, some of the birthdays in the database are in error. Some
people don't reveal a year of birth, or intentionally give an incorrect
year. So I have to deal with people who want year of birth to be private
As a Funeral Director of 20 years, I have somewhat modeled a person
object in the database I wrote to generate the regular paperwork I have
to do when serving my families. For this case, the person object is
Fortunately for me this person object will be far simpler. :)
> In the end, there's no substitute for experience. Have a good one!
Yes, absolutely! But I am happy to avail myself to the experience,
wisdom and knowledge of those who have traveled down the road before me,
as I acquire my own experience.
Thanks. And again, thanks to all who helped.
More information about the Squeak-dev