A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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
@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 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/73911 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 self.new(name,colour, parent1, parent2)
Which is ok - is this how it is commonly done ?
Apologies if this is too much of a newbie question
Why not have a Marriage class that represents the marriage? It could have attributes for the date and location of the marriage.
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
Wednesday, December 13, 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
"disallowing an object to participate in both a Marriage contract and a Dating contract"
Sunday, December 17, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz