# Assignment - Stone Age game - PlayerBoard component - Immutable 

Your task is to redesign PlayerBoard component so that it contains no mutable state (see [O-O design](pts24.pdf)).

# Solution comments

Many solutions just changed class interfaces for methods that mutate objects to instead return a new instance of an object, e.g.
in PlayerResourcesAndFood
`takeResourcesResources(resources: Effect[]): Tuple[bool, PlayerResourcesAndFood]`
(BTW. `takeResourcesResources(resources: Effect[]): PlayerResourcesAndFood` might be also OK).
This of course helps a bit, but is not sufficient at all. 

We have learnt that immutable structures need to be in a tree structure. As time needs to be modeled as a sequence of values (instead of sequence of in-place mutations), we need to keep references consistent during the process. Consider classes `PlayerBoard`, `TribeFedStatus`, and `PlayerResourcesAndFood`.
If `PlayerBoard` calls `PlayerResourcesAndFood` to get a new value, `TribeFedStatus` keeps its old reference. And we need to resolve this problem.

Most straightforward solution is to make a call to `TribeFedStatus` to update the reference, plus we need a getter to get the correct `PlayerResourcesAndFood` from `TribeFedStatus`. This solution works, but it is very error-prone. You could easily forget something and get a value that consists of fragments corresponding to different times, an error which may be awful to debug. It is much better to define a clean ownership three structure. 

In general there are two approaches to do this. In one approach we keep classes. `TribeFedStatus` will not
have a reference to `PlayerResourcesAndFood`, but it will receive it as a method parameter and returns the new value as the result of the method call together with the updated `TribeFedStatus`. Alternatively, one can redesign the interaction so that there is no dependence between `PlayerResourcesAndFood` and `TribeFedStatus`. Other approach is to leave O-O programming entirely and separate data and behaviour. Both approaches have their advantages and drawbacks that revolve mostly around the ability to do information hiding. 

If we keep the classes `TribeFedStatus` will not be able to work with `PlayerResourcesAndFood` using a limited interface as in the end it needs to return the next value which has be OK for every possible usage. Thus we cannot hide the behaviour, the interface needs to be complete. On the other hand, if we separate data we lose the ability to hide the data. Also it may make sense to do several small adasctions to the design.

Note that we have the same issue at the component level as there are more clients of `PlayerBoard` component.
We need to make a common interface and create a mutable adapter storing the immutable value corresponding to the current time (inside or outside of the component - as you wish).