Gfrktyl

The code in its full glory, complete with unit tests is here: https://github.com/edemo/PDEngine/pull/277/files
(And also some discussion of the issue)

I am struggling with how the principle of separating data structures and behaviour applies here.

This would be the data structure, only with public fields:

package org.rulez.demokracia.pdengine;



import java.util.HashMap;

import java.util.Map;



import javax.persistence.ElementCollection;



public class BeatTableEntity {



    @ElementCollection

    public Map<Choice, HashMap<Choice, Integer>> table;



    public BeatTableEntity() {

        super();

    }



}

And this would be the behaviour, no data fields:

package org.rulez.demokracia.pdengine;



import java.util.HashMap;



import org.rulez.demokracia.pdengine.exception.IsNullException;



public class BeatTable extends BeatTableEntity {

    public enum Direction {

        DIRECTION_FORWARD, DIRECTION_BACKWARD

    }



    public BeatTable() {

        table = new HashMap<>();

    }



    public int beatInformation(Choice choice1, Choice choice2, Direction direction) throws IsNullException {

        if(direction == null)

            throw new IllegalArgumentException("Null direction");



        int result = 0;



        if(direction.equals(Direction.DIRECTION_FORWARD))

            result = getBeatValue(choice1, choice2);

        else

            result = getBeatValue(choice2, choice1);



        return result;

    }



    private HashMap<Choice, Integer> getBeatRow(Choice choice) {

        if (table.get(choice) == null)

            throw new IllegalArgumentException("Not existing row key");

        return table.get(choice);

    }



    private int getBeatValue(Choice choiceF, Choice choiceS) throws IsNullException {

        if (choiceF == null || choiceS == null)

            throw new IsNullException("Choice");

        HashMap<Choice, Integer> row = getBeatRow(choiceF);

        if (row.get(choiceS) == null)

            throw new IllegalArgumentException("Not existing column key");

        return row.get(choiceS);

    }



}

This is obviously badly encapsulated; an example is the test which changes a whole row to an empty one, and calls beatInformation() to throw an exception.
That test fiddles around with the internals of the data representation (which should have no internals in the first place), and results in an error which is not exactly making sense in the business logic level.

My question is: what would be the right data structure to back this behaviour.

We came up with two possible solutions, none of them could really convince me:

1. have table as a simple map , where key is effectively the (Choice choice1, Choice choice2) tuple (e.g. choice1.id + choice2.id, as those are strings). This way the data structure have no internals to hide, but it is slow for a non-sparse matrix, and I do believe that good design is not slow.


2. come up with a Matrix class which we think of as a "primitive type". Matrix would itself use an internal data structure fully encapsulated, and implement its own serialization. The reasoning of this would be that this complexity of data cannot work without internals, and as the compiler can hide the internals of e.g. a HashMap, we just do the same, and thus we can use Matrix as a building block in properly separated code.


3. ???

What are the points to consider here, and what would be the Right Solution(tm) ?