- The game board itself could determine if the line is a replacement or needs deletion. Since the game board is the one displaying the lines and handling the interaction of flows on the screen, this could be handy. On the other hand, the determination of which lines are replacements or not seems a bit out of the game board's responsibly.
- Another method would be to have the Line class itself handle the determination of what is a good line or replacement line. This moves this logic into the class that has to handle it which seems more appropriate. Then the game board can just use the Line's methods to determine which lines stays or goes. This would also handy if I decide to create something other than lines to move colors. Maybe I want a square type operation in the future. Who knows? It would not matter as much to the game board.
The design could work either way, but I suspect that the game board handling everything would eventually start to feel bloated and resistant to future changes. In the words of Martin Fowler, who wrote one of the classic programming books on Refactoring, it would start to 'smell'. That is a nice way of saying you are not happy with how the code is turning out.
The funny thing about design, is that it can only take you so far. First of all, you can't spend too much time on design because invariably the actual coding will expose a problem that you did not conceive of in the design phase. The design/code cycle needs to be iterative to remain flexible to these challenges. Once the code is put into place, you might find that you don't like that design after all.
And something does not smell right...