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@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
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 data.
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 incredibly complex.
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.
Jimmie