Hello,
Just wanting some general wisdom on object modeling.
I am creating a person object for a website I am building.
Inside this person there is much data desired/required. Some of it very simple but I could easily see an explosion of instance variables.
My naive instinct is to create/model other objects even if very small to satisfy the needs.
example:
instead of instance variables: dateOfBirth placeOfBirthCity placeOfBirthState yearOfBirthPublic ...
I would create a class/object for BirthInformation with those variables and in my person object have a birthInfo variable.
Is this a correct way to do this in Squeak or am I off base? I have lots of such types of data.
Any wisdom greatly appreciated.
Thanks.
Jimmie
Personally, I would just throw the inst vars in there and start doing stuff. As you continue building you will probably notice certain synergies and places where you realize some of those instVars actually look more like a separate class.
For me, building in Smalltalk is about very quickly making stuff the first way I think of and refactoring as I go until I have something that I like, and does everything it needs to.
On 9/29/07, Jimmie Houchin j.squeak@cyberhaus.us wrote:
Hello,
Just wanting some general wisdom on object modeling.
I am creating a person object for a website I am building.
Inside this person there is much data desired/required. Some of it very simple but I could easily see an explosion of instance variables.
My naive instinct is to create/model other objects even if very small to satisfy the needs.
example:
instead of instance variables: dateOfBirth placeOfBirthCity placeOfBirthState yearOfBirthPublic ...
I would create a class/object for BirthInformation with those variables and in my person object have a birthInfo variable.
Is this a correct way to do this in Squeak or am I off base? I have lots of such types of data.
Any wisdom greatly appreciated.
Thanks.
Jimmie
Just wanting some general wisdom on object modeling.
I am creating a person object for a website I am building.
Inside this person there is much data desired/required. Some of it very simple but I could easily see an explosion of instance
variables.
My naive instinct is to create/model other objects even if
very small
to satisfy the needs.
example:
instead of instance variables: dateOfBirth placeOfBirthCity placeOfBirthState yearOfBirthPublic ...
I would create a class/object for BirthInformation with those variables and in my person object have a birthInfo variable.
Is this a correct way to do this in Squeak or am I off base? I have lots of such types of data.
Any wisdom greatly appreciated.
Thanks.
Jimmie
Personally, I would just throw the inst vars in there and start doing stuff. As you continue building you will probably notice certain synergies and places where you realize some of those instVars actually look more like a separate class.
For me, building in Smalltalk is about very quickly making stuff the first way I think of and refactoring as I go until I have something that I like, and does everything it needs to.
I agree. Jimmie, don't be afraid of making objects, but be sure you're making them for behavioral reasons and not simply to make clean looking data structures.
Think less about the data and more about the behavior such an object would display. What would a BirthInfo do? If the answer is belong to a Person, then you don't yet have any reason to make such an object. Hopefully you already have an idea of what a person will do.
Ramon Leon http://onsmalltalk.com
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
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
On 9/29/07, Tom Phoenix rootbeer@redcat.com wrote:
On 9/29/07, Jimmie Houchin j.squeak@cyberhaus.us wrote:
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.
Yes. Personally, I come from more a C++ background, and I can say that in C++ the compile times become so painful that you really want to take the time to try and design everything perfect from the start.
Smalltalk is on the exact other side of the universe. So if you come from a similar background it may take some time to get used to a new way of thinking, but this is what Smalltalk brings to the table. If you want to make the most out of a new programming language the best thing to do IMO is to find out it's strengths and try to play to those.
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
squeak-dev@lists.squeakfoundation.org
-
Jason Johnson -
Jimmie Houchin -
Ramon Leon -
Tom Phoenix