sikrob / slick-game-of-life Goto Github PK

On key releases, gardens can be updating. This seems like bad practice. We should be setting up our state to update but not resolving until the update step – in this case, I'm thinking we should just have a flag that the garden can update and then just call garden.update() in the update loop step.

Or am I over thinking this?

At any rate, if we go this route, we may want to break out the auto funcitonality into a function that can get called immediately prior to actually updating the garden and have that function also just trip the "garden should update" flag. Then just update when we see that flag.

I'm thinking that this would technically be a good place to use an "updatable" interface or something to ensure readability in terms of what has or update flags and what gets updated in Update loop step.

Updatable would have, as a minimum, the "willUpdate" flag (or similar) and the update() method. Then called by update loop step with if (x.willUpdate) { x.update() } for all items.

This description also again highlights: Why bother if we aren't planning to add any more updatables?

It's better to build these gardens separately as walled and wrapped because, while much behavior is shared, they run different neighbor search methods based on a constant, "WALLED". It makes more sense to have separate possible instances of Garden that either Wall or Wrap the specimens so that the gardens aren't themselves carrying unreachable code. This will also aid readability.

From a higher level POV, since we can think of the different kinds of gardens as completely separate items, it makes sense to do so. Not sure if that is always going to be a good test, but it feels like a good indicator at least.