wolfenste
commented
6 years ago Initially I had Map with 9 nice marks. No objects or squares, nothing like that. But, because the logic for keeping the track of rows and columns and diagonals required x and y (and moreover, because the player works with x and y (x, y)) it seemed a good ideea to keep consistency in the project, and a square object was created. Anyway, that old code in the inspiration is abandoned and now I am open to make another logic for finding the winner. That old code is based on my 'discovery' that when a player makes a move actually updates a row, a column, and maybe one or two diagonals. And, if (x + y) == 4 then the square is on the second diagonal and if x == y then the square is on the first diagonal. Finally, when a row, a column or a diagonal reaches 'level 3' (by incrementing) we have a win situation. Following this logic no loops for finding the winner are needed. And no loops means better performance. But at the and too many abstractions were introduced and I was not satisfied because I like to favor simplicity as possible.
With Square, you're essentially introducing a way to sparsely represent the state of a Map.
In principle a great idea.
But is this really needed? You do sparse representation when we're talking about millions or billions of entries, to optimize memory usage.
In this case, we know the upper bound, which is extremly low: 9.
So why not have the board encoded as an array of 9 Mark instances? Or a mix of 9 Mark instances or null?
Looking over the code, I see so much complexity, just because of this sparse representation. It looks over-engineered and difficult to extend, just because of this.
Keep simple things simple.
Mark for instance justifies its existence - if you do what I already told you a couple of times: because it's a value object, it protects your business (Map, Game and Player) from corrupt data.
Square on the other hand just creates self-inflicted problems, instead of solving real problems.
Remove Square.