Struggeling with a design flaw

When I was creating my engine I had to decide where to place the transposition tables. I decided to make them part of the board class as I wanted the verify its correct implementation first with the move generator. Let the perft calculation use the transposition table and if not the same number of moves is generated as before you know there is an error with it (the table itself, the hash key generation or make/unmake move). So the transposition table became a property of the board class in order to be available for the perft method.

I then developed my engine and my GUI further and it seemed to work very nicely this way. But when I finally sized the transposition table to a serious size of a couple of million entries I realized that the memory consumption of the GUI went also up very much. The reason is that the code for the board class is used by both the GUI and the engine. The GUI uses board properties like which square holds which piece and the move generation methods to verify the user input but by using the same code it also allocates the size of the transposition table.

So my GUI was suddenly consuming several hundreds of MB RAM.

I first tried to work around that by conditional compiling the GUI and engine

#IFDEF ENGINE
  TTSIZE = 2097152
#ELSE
  TTSIZE = 100
#ENDIF

It worked somehow (not really good because I had to explicitly save the unit with the constants to force a recompile of it). But I was not really happy with that work around anyway. I rather fix problems at the root.

So I decided to remove the transposition table from the board class and put it in the engine class although this requires a lot of code to be changed. I will spend some unpleasant hours on fixing my design. I hope the engine will not run slower after that and I do not introduce many new bugs.

Lessons learnt: Don't mess up your code with something that seems easier at first sight if it involves implementing something in a place where it does not belong to.