Refactoring Graph Data Structures and Loading Board Layout from Files

TLDR

Rafactoring graph data structures and helper methods. Reading board layout details from resource files rather than hardcoding. Adding Hexagons into larger graph structure so we can more easily find adjacent Hexagons for a Settlement.

Reading board layout from a file.

// read in the json file has a map of graphNodeIndex to list of neighboring graphNodeIndices
// would throw during initialization, so fine to ignore
@SneakyThrows
private static Map<GraphNodeIndex, List<GraphNodeIndex>> readAdjacentsFromFile(String fileName) {
  String filePath = Objects.requireNonNull(
      ResourceLoader.class.getClassLoader().getResource(fileName)).getFile();
  return new ObjectMapper()
      .readValue(new File(filePath), Adjacents.class)
      .adjacents()
      .stream()
      .collect(
          Collectors
              .toMap(
                  adjacency -> rawIndexToGraphNodeIndex(adjacency.node()),
                  adjacency -> adjacency.neighbors()
                      .stream()
                      .map(CatanGraph::rawIndexToGraphNodeIndex)
                      .toList()
              )
      );
}

Main work

• Updating graph HashMap to use the entire GraphNode objects, rather than String keys.
• Removing unneeded fields in GraphNodes, adding composition / field for IGraphNodePiece.
• Updating helper functions to use the new GraphNode structure.

Challenges

• Java is verbose, even reading a file into a particular data structure involves a lot of Stream API use.
• Thinking about inheritence / composition / design changes as the final application structure becomes more apparent.

Learnings

• Records in Java have default hash implementations that are useful, but can silently be wrong based on referenced objects.
  • For example, if a Record references a List<T>, even if T also has a useful hash, the List<T> reference is what gets hashed.
  • E.g., Two equivalent List<T> would not result in identical Record hashes.