-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Blake Sent: Saturday, September 10, 2005 4:17 AM To: The general-purpose Squeak developers list Subject: Re: Miscellaneous questions...
These were some great answers, guys, thanks. I'll have a lot more the more I write.
I would not use any primitive value type object to represent suit or rank. I would use objects, i.e. a Heart object and a King object. Doing so makes it much easier to do reasoning and comparisons between cards.
I am from the old school and used to start out using symbols, numbers, or strings to represent state. I eventually found out that real objects do a much better job. Rather change my code from some value type of representation to a real object after I found out I need it, I think it is better to just start off that way.
I see the logic of this, but I'm not 100% sure I agree.
The point of having a multiple objects versus a single object would be if the cards behaved differently. But not only do they not behave differently, they only meaning in a larger context. You can't ask the Ace if it's higher or lower than the Jack, for example, because the Ace doesn't know. You can't ask the Ace if it's okay to play itself, because it depends on whether it's Poker, Solitaire, Go Fish, or whatever.
True, but I think you would find that your game code would be better composed if the representation was a real object. In the simple case the rank object would have a string used to display itself, i.e. Jack, and maybe a rank number used for comparing cards. Obviously, as you point out, the Ace would have to he handled specially. You could also have different rank objects for different games.
But, you will have to come to this realization yourself. It only took me 14 years of ST programming to figure this out. :-) My problem is that I hate adding complexity and to me using objects instead of values increases complexity, so I resisted. But, I have seen too many situations where initially it seemed that a value was simpler and would suffice, but later it turned out not to be the case.
You could say Rules->Deck->Card, because its the rules that determine the relative value of the cards and the composition of the deck. The deck, really, is always going to behave the same. It's just a holder. Its job is to keep track of the cards, shuffle and deal.
Now, if you were making a Magic: The Gathering-type game, yeah, objects for cards--a real hierarchy to boot. And the Deck object should be able to handle that. The rules, however, would determine base play, while deferring to the rule changes specified by the cards.