[valuearb]

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.

[cheeze]

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

[valuearb]

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.

[AlchemistCamp]

What challenges were from Obj-C, specifically?

[valuearb]

It’s a pointer based language, ie its C. Swift makes it far easier to write correct code and not have to chase down wild pointer problems.

[AlchemistCamp]

Fair enough. My Obj-C experience was all years before Swift existed... mostly pre-ARC, even!