|# Looking to reduces rows of board game data to|
|# primitives (for eventual JSON output).|
|# each cell can be either unoccupied, or occupied by N|
|# armies of a given color. What data format do you prefer,|
|# and why?|
|# 1) nil indicates empty territory|
|[[:white, 2], nil, [:black, 3]]|
|# 2) :empty indicates empty territory|
|[[:white, 2], :empty, [:black, 3]]|
|# 3) somewhat homogenous. nil indicates count being non-applicable|
|[[:white, 2], [:empty, nil], [:black, 3]]|
|# 4) fully homogenous. 0 indicates no units of either color present|
|[[:white, 2], [:empty, 0], [:black, 3]]|
|# your own representation (leave a note in the comments)|
@ljsc: Hmm... that seems fundamentally different than any of the examples I've shown. While I can see breaking homogeneity to introduce
I think semantically the fact that you have
It's probably just my propensity to add mathematical properties to type domains (probably YAGNI in this case): I can see why others would favor consistency of #4, however.
Out of the listed strategies, I'd say
The most obvious thing to me while sticking with the general format outlined would be:
Then for the implementation, something like:
Why render the board as an array though? Why not a hash?
Disclaimer: I am very sick right now. I apologize if this is incomprehensible.
@phiggins: Interesting ideas, thanks for sharing. The board is an NxN grid, so an array of arrays makes sense for this game.
The context is important, but it's okay to assume it's a generic board in which cells can be empty, or have n cells of a given color (either white or black)
Maybe you should look at using a class for each cell. At that point it would be easier to extend and add other information or maybe some behavior to a cell. You could also make it more clear with intention reviling method name. I have often wanted to add unary operators to game cells.
Not to go all "appeal to authority" on you, but I just read this last night, and thought it worth mentioning:
The more code we write, the more we're convinced that we should define types to represent value concepts in the domain, even if they don't do much. It helps to create a consistent domain model that is more self-explanatory. If we create, for example, an Item type in a system, instead of just using String, we can find all the code that's relevant for a change without having to chase through the method calls. Specific types also reduce the risk of confusion -- as the Mars Climate Orbiter disaster showed, feet and metres may both be represented as numbers but they're different things. Finally, once we have a type to represent a concept, it usually turns out to be a good place to hang behavior, guiding us towards using a more object-oriented approach instead of scattering related behavior across the code.
-- Growing Object Oriented Software, Guided by Tests
I go for #4, after all the advantages already said, I'd add the self-documented style.
As you said is a serialization structure what we are defining here, so would be possible to think it is gonna be drunk up by external systems, better then that the info has an implicit way to be understood.