In our current implementation, the builder class (arrangement/gridded/etc) would take a board instance as a member variable. At the same time, it also inherits from the board class. So it actually does not make full use of the member variables (e.g., pieces) of the board class.
In the original design, it seems that we want to save a solution board plus another generated board (e.g., by an explosion function) in the builder instance. I do not think it is necessary to do that. The explosion function will always output a new board instance but does not need to save it in the builder. In addition to that, if we want to check the progress of puzzle-solving, we can create a specific board called solution. Then have a comparison between an estimated board and that.
So I would suggest we remove the board instance as a member variable of the builder class. Instead, we just consider a builder instance as an enhanced board, which will enable its ability to manipulate the saved pieces. We can even combine the board class and the arrangement class together. Then we will have the following class relationship: board(arrangement) -> adjacent -> interlocking -> gridded. The child class will just be a special case of the parent class.
With this change, I think it is more clear to the users what the function of the builder class is about and it can also make full use of the saved variables.
In our current implementation, the builder class (arrangement/gridded/etc) would take a board instance as a member variable. At the same time, it also inherits from the board class. So it actually does not make full use of the member variables (e.g., pieces) of the board class.
In the original design, it seems that we want to save a solution board plus another generated board (e.g., by an explosion function) in the builder instance. I do not think it is necessary to do that. The explosion function will always output a new board instance but does not need to save it in the builder. In addition to that, if we want to check the progress of puzzle-solving, we can create a specific board called solution. Then have a comparison between an estimated board and that.
So I would suggest we remove the board instance as a member variable of the builder class. Instead, we just consider a builder instance as an enhanced board, which will enable its ability to manipulate the saved pieces. We can even combine the board class and the arrangement class together. Then we will have the following class relationship: board(arrangement) -> adjacent -> interlocking -> gridded. The child class will just be a special case of the parent class.
With this change, I think it is more clear to the users what the function of the builder class is about and it can also make full use of the saved variables.