Question

I’m modeling a Poker game and I have a little design doubt:

I’ve a PokerHand, which is composed by 5 PokerCards. Should Straight, ThreeOfAKind, Poker, etc be subclasses of PokerHand? Or should they be symbols returned by a PokerHand method that computes what kind of hand it is?

My rationale for subclassing PokerHand is that it would make checking winner hands much easier and faster, but I’m not sure this is good engineering…

Is there any design pattern that would fit here?

Thanks!

Answer 1

Last semester, I had to design such a system in Java as a homework. While it was required we checked the hands using the chain of responsibility pattern, I’m fairly sure it was a bad approach to the problem and mostly just a way to plug the pattern into a homework.

If I had to redo it without the chain of responsibility pattern, and using a saner, more cohesive list of strategies, I would use a design like the following.

There would be a Card class, with a ‘color’ (spades, clubs, diamonds, hearts) and a number (both being enums); a Hand class, that holds 5 cards (or just n cards if you’re into that); an abstract HandRank class that implements the Comparable<HandRank> interface, and subclasses for each kinds of hands (two of a kind, three of a kind, straight, etc) that are each comparable to another (such that StraightFlush is better than TwoOfAKind); and a base class AbstractHandAnalyzer. This AbstractHandAnalyzer would have a Analyze(Hand) method that would return a HandRank object.

Now, you make one subclass of AbstractHandAnalyzer per HandRank subclass. Those subclasses check a given hand and return a HandRank instance if the hand matches (for instance, if TwoOfAKindAnalyzer finds that you have two kings, it returns a TwoOfAKindRank that tells it found two kings, and saves the kicker in case it needs it during a comparison later).

All you have to do to analyze a hand, then, is to have a list of hand analyzers in descendant order (so you start with the straight flush), and run each analyzer on the hand until one matches by not returning null.

The important part here is to decouple the poker hands from the ranks themselves. With most languages (it might not be the case with Smalltalk though), if you construct a Hand object, you cannot magically morph it into another class, so subclassing Hand to qualify the ranks can be hard depending on your object instantiation scheme, and can be made next-to-impossible if the hand is mutable (some poker variants allow to swap cards). This approach lets you reuse Hand and easily implement various analyzers for hands.