Skip to main content
deleted 69 characters in body
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization (which, as your surely know, D. Knuth called "the root of all evil").

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> (or Map<Direction, LinkedList<Cell>>) by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more. It is to some dgeree a matter of tastemay be debatable if thisit should really be a method of the piece, or a method of the board. IfHowever, if you put this method into the board instead of the piece, pieces will not have to know anything about the board, so this avoids a cyclic dependency between boards and pieces.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck (which I doubt), you can still cache its results using memoization. That would lead to a solution where a Map<Direction, LinkedList<Cell>> per piece is required, but without the necessity of actively observing other board changes.

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization (which, as your surely know, D. Knuth called "the root of all evil").

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> (or Map<Direction, LinkedList<Cell>>) by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more. It is to some dgeree a matter of taste if this should be a method of the piece, or a method of the board. If you put this method into the board instead of the piece, pieces will not have to know anything about the board, so this avoids a cyclic dependency between boards and pieces.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck (which I doubt), you can still cache its results using memoization. That would lead to a solution where a Map<Direction, LinkedList<Cell>> per piece is required, but without the necessity of actively observing other board changes.

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization.

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> (or Map<Direction, LinkedList<Cell>>) by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more. It may be debatable if it should really be a method of the piece, or a method of the board. However, if you put this method into the board instead of the piece, pieces will not have to know anything about the board, so this avoids a cyclic dependency between boards and pieces.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck (which I doubt), you can still cache its results using memoization. That would lead to a solution where a Map<Direction, LinkedList<Cell>> per piece is required, but without the necessity of actively observing other board changes.

added 211 characters in body
Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization (which, as your surely know, D. Knuth called "the root of all evil").

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> (or Map<Direction, LinkedList<Cell>>) by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more. It is to some dgeree a matter of taste if this should be a method of the piece, or a method of the board. If you put this method into the board instead of the piece, pieces will not have to know anything about the board, so this avoids a cyclic dependency between boards and pieces.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck (which I doubt), you can still cache its result and invalidate the cache for all pieces wheneverresults using memoization. That would lead to a solution where a Map<Direction, LinkedList<Cell>> per piece is required, but without the necessity of actively observing other board is changedchanges.

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization (which, as your surely know, D. Knuth called "the root of all evil").

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck, you can still cache its result and invalidate the cache for all pieces whenever the board is changed.

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization (which, as your surely know, D. Knuth called "the root of all evil").

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> (or Map<Direction, LinkedList<Cell>>) by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more. It is to some dgeree a matter of taste if this should be a method of the piece, or a method of the board. If you put this method into the board instead of the piece, pieces will not have to know anything about the board, so this avoids a cyclic dependency between boards and pieces.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck (which I doubt), you can still cache its results using memoization. That would lead to a solution where a Map<Direction, LinkedList<Cell>> per piece is required, but without the necessity of actively observing other board changes.

Source Link
Doc Brown
  • 220.5k
  • 35
  • 410
  • 625

Having a "Map object that keeps track of all the cells to which it can travel" looks to me like an example of premature optimization (which, as your surely know, D. Knuth called "the root of all evil").

Instead of remembering all those cells for each piece "just in case it could become slow", why not give a piece a method with the board as parameter, which returns the related List<Cell> by calculating it when the method is called? This way, no notifications or observer pattern or "32 listeners" are needed any more.

If it turns out later that this method is called quite often for the same, unchanged board so it becomes a performance bottleneck, you can still cache its result and invalidate the cache for all pieces whenever the board is changed.