I once had to write a version that worked for multiple games. Holdem, Omaha, Omaha 8 or better, Ace to Five, Deuce to Seven, and Badugi. I did it using inheritance, having high and low hand classes. The low ball games just reverse ordinary logic, but Omaha 8 needed both and the 8 or better restrictions. The Badugi class rewrote everything entirely.
When I finally finished I was asked to add Stud, Badeucy and Badacey. That’s when I quit.
I wouldn’t do it in Objective C again, that’s for sure.
But no, I think the class structure worked well for this. Just too many esoteric rules in these games. And it’s getting worse from what I hear of the high stakes games. Archey was just getting popular when I quit and now there is like a half dozen new games they play. It’s a constant arms race to see who can master a new set of rules to skin the fish with.
As crazy as it sounds, this is why I'd try to keep it simple and just keep each implementation separate. Sure I'd save some keystrokes having a base abstraction and whatnot, but I feel like Poker is one of those "i'll make an interface" traps that is much more complex than it originally seems
The abstraction is pretty simple, and close to that. IIRC I had base Hand object that defines a comparison routine that takes a Hand object.
The Hand object has a method that returns Card objects by index with a high to low order so subclasses can do their comparisons in either 4 or 5 card games.
The you need like a best hand method, so games like Holdem that make best 5 card hands out of 7 cards work. Then a bunch of utility functions.
It’s also useful to have your Card objects have their comparison functions.
When I finally finished I was asked to add Stud, Badeucy and Badacey. That’s when I quit.