Deliberate Abstraction

Summary

I recently wrote code to simulate a card game. The details are irrelevant, but it was a great opportunity to put inside-out design into practise, because when I started programming, I didn’t actually know the rules of the game, nor what all the card types were. Thus, I started from a very general core that I did know with certainty: Card - name : string - valid_play : Card -> bool A card has a name and it gets to decide on its own whether it’s legal to play this card on top of another card. Naturally, we also have Player - name : string - hand : List Card - add : Card -> () - remove : Card -> Maybe () A player has a name and a few cards on their hand. If we give the player a card, we get a new player with more cards. If we try to remove a card from a player, we either get nothing (if the player didn’t have that card) or a new player with one fewer cards. Simple, but extremely general. Then we have Table - pile : List Card - previous : Card - draw : Player -> Maybe () - play : Player -> Card -> Maybe () In other words, the table has a pile of cards that are not yet in play, and there’s the previously played card. The table lets a player draw a card from the pile, or play a card from the player’s hand. Again, these do minimal validation.13 The draw method ensures there are still cards in the pile, and the play method obviously fails if the player does not have the card that they are attempting to play. Then to start to impose some structure on this, we can create Ply - table : Table - player : Player - draw : () -> Maybe () - play : Card -> Maybe () - end_ply : () -> Maybe () A ply is game-speak for the portion of a turn in which one player is allowed to act. In some games, the player may perform multiple actions during their ply, which is why it is a separate action to end_ply. This may only be permitted under certain circumstances, e.g. there may be a requirement to play a card before ending one’s ply. This abstraction also starts to control the sequences of actions...