The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Simple Ruby/OO qns - Modelling neopets marriage/ children

  I've been trying to get my 9 yr old daughter interested in programming, and I started using Ruby as the language and Neopets (think Tamagotchi/Pokemon/ any small cute animal etc.) as the domain.
<My background is more C++, VB, C# - all a bit rusty, I've been doing a little ruby/rails recently>

We started simply (JPet class with name, colour etc.), but then I hit two problems which I couldn't explain 'clean' solutions to

1) She wanted to 'marry' two JPets. I started doing this by creating a 'marry' JPet class function. But then both JPets need a 'married' state, and a link to the pet married to and it soon felt wrong
(e.g. I started writing code like
 def marry(spouse)
  @married = true
  @marriedTo = spouse
  spouse.marry(self) # stop here - marriage is 2 way relationship - how to stop recursion - this is ugly

What is a cleaner way to do this - should I have a separate MarriageRegister class, and then get it to marry the JPets ? If so how should a JPet know if it is married (can it keep local state or should it always check via the MarriageRegister)

2) She wanted two JPets to have a child. I wrote a second initialize class initialize(spouse1, spouse2) but found out Ruby only likes one initialize class. Now I can write a variable argument initalize and call this but this seems kludgy - or I can do what this guy recommends and write

def JPet.initialize(name,colour = "grey", parent1=0,parent2=0)

def JPet.fromparents(parent1, parent2)
  name = ... # calculate name from parents
  colour = ... # calculate colour from parents
  return,colour, parent1, parent2)

Which is ok - is this how it is commonly done ?

Apologies if this is too much of a newbie question
Jim D Send private email
Wednesday, December 13, 2006
Why not have a Marriage class that represents the marriage? It could have attributes for the date and location of the marriage.
John Topley Send private email
Wednesday, December 13, 2006
Heh, Jim, damn those kids eh...  always coming up with the hard programming questions.

John has the right solution to the marriage problem.  Have both pets have a reference to the same Marriage object.

As for the having children part, this could be done with a factory method.  A static method that takes both parents as parameters and constructs a new child pet with the parent properties set appropriately.
Almost H. Anonymous Send private email
Wednesday, December 13, 2006
Guys, thanks for the answers, this is a real help, really appreciate it.
Glad my wife isn't a coder so she can't take me to task for not thinking of Marriage as a proper class.
Thanks again
Jim D Send private email
Wednesday, December 13, 2006
Will there be a Divorce class too? :)
Thursday, December 14, 2006
A system I worked on a while back modelled a more general version of this problem by having Contracts that existed among several domain objects.  Each domain object then maintained a list of Contracts to which it was bound and which constrained its behavior.  In that system the contracts came in different flavors, so you could have things like Marriage, Partnership, Client, and so on.  The interesting thing was the logic to resolve conflicts between contracts - for example, disallowing an object to participate in both a Marriage contract and a Dating contract
ralphie Send private email
Friday, December 15, 2006
"disallowing an object to participate in both a Marriage contract and a Dating contract"

Why? ;)
Berislav Lopac Send private email
Sunday, December 17, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz