object modeling

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 <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> wrote:
> On 9/29/07, Jimmie Houchin <[hidden email]> 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:
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