Mutability and objects; how to properly manage data?

Question

Objects tend to confuse me some. In understand the concept and use, certainly, but I feel like the functional paradigm is somewhat restricting my use of them.

At the moment, I'm creating a simple code for a game of cards. Each player might have a simple object, like this:

object player {
    name = "Steve";
    score = 0;
    hand = [/*...contains seven cards...*/];
}

and a object for a deck:

object deck {
    cards = [/*...contains the other 45 cards...*/]
}

So for dealing new cards, the simplest way would just be to mutate the this.hand and the this.cards. But... mutation.

I can think of other ways to do it, but the purely functional ways I can think of feel messy.

At what point do you draw the line between mutable and immutable data, or what am I missing?

Answer 1

It is quite simple: if you want to go the "pure functional road", you need purely functional data structures, which means immutable data structures, which in OO languages means immutable objects.

For representing card decks, a very efficient, immutable structure is a stack, implemented as a single linked list (and not as an array!), maybe combined with a size counter. Then the typical stack operations like adding a card to the top, removing one from the top can be implemented as immutable operations in O(1). Forward iterating over all elements can be implemented in O(N). Random access to a certain card will become an O(N) operation (instead of O(1) when using an array implementation), but most meaningful card operations can be implemented without the latter, or it does not have a serious impact on the running time for most practical cases.

the purely functional ways I can think of feel messy

I don't feel so - using a stack abstraction is not necessarily more or less "messy" than using an array abstraction. The only obstacle I see is that the standard libraries of main stream OO languages like C++, C#, or Java do not provide standard implementations for something like an immutable stack "out of the box". Most functional languages probably do so today. Just google for immutable stack <your favourite language>, or immutable object tutorial <language> and you will find probably what you need.

However, if you are more used to classic OO modeling with mutable state, you can model and implement your card game using mutable classes (but then it won't very functional any more).

Answer 2

In FP mutation of an entity is modelled as a creation of its next state. First, the entity has one state represented by an arbitrary complex object, next moment it can have another. These states include states for all properties of entity, for example, player state may include state of his hand, world's state includes players state and deck's state.

A simple mutation, involving only one aspect of the state, is achieved by shallow copy of the previous state, replacing one of its property values.

Functional languages (should) have a designated syntax or libraries for such transformation.

Simple mutation without using designated libraries and in Javascript syntax:

function score (world) {
   return {
     deck: world.deck,
     player: {
        name: world.player.name,
        score: world.player.score + 1,
        hand: world.player.hand
    }
}

With syntax enhancements:

function score (world) {  world { player.score = world.player.score + 1 }; }

Hypothetical example with non-trivial logic, better representing real state transitions:

function win (world) {
  return {
     deck: world.deck.merge (world.player.hand),
     player: {name: world.player.name, score: world.player.score + 1, hand:[] }
}

Answer 3

OO and functional programming are orthogonal concepts. So if you mix them improperly you won't get the best of both but the worst of both.

Mutating structures with functions is the worst you can do. You have side effects AND you don't know who is the responsible for consistency of the structure.

Either you encapsulate mutation into an object and let the object preserve consistency OR use immutable data structures and represent any new state with a new data structure. If you follow this then you can mix the paradigms without drawbacks.