Personal Blogs

Today I wanted to stay in, but my wife dragged me out to exercise, "her human right to make-up". We came home cold and penniless. So I did a bit of coding.

I had a problem, which I will explain thus: we have an implementation of a board [which is part of the Model] that we wish to have the View to advertise, and the Controller to know about. Not too difficult you'd think, we use an enum to tell the view what options are available. But then the Controller has to keep up with the changes...

Or does it? And even if it does do we want to hard-code the Controller?

[Board is an Abstract Class, neither the controller nor the Vew should care about what the thing actually is; but as a board maker how do I tell the others that there's a new one? And do they have to alter their code?]

My first-thought was that I could add some methods to an enum, didn't work. But you can wrap a Class around said enum thingees. Throw in some methods and we might be on the right track. 

What I came up with is a class that exposes an enum of what's available and copes with, the inevitable, switch. You send me a switch, I'll send you an instance of what you want if you send me a String.  

public class Boards {

    private enum AvailableBoards {
        ENGLISH,
        FRENCH
    }

    public static Board getBoard(String board) {
        AvailableBoards available = AvailableBoards.valueOf(board);
        Board brd = null;
        switch (available) {
            case ENGLISH:
                brd = new English();
                break;
            case FRENCH:
                brd = new French();
                break;
        }
        return brd;
    }
}

Not finished, indeed I have a burning tree and there are several returns that need to be crafted better.

Still I think that a Class like this [at the top of a package] is a self-documenting boundary for the package. It reminds me of the [rarely-seen] javascript .config.