在侦听器的handle方法中是否有最佳方法来调用控制器类的方法？

Question

I am developing a small game and was wondering about a best practice for handle methods in (anonymous) listeners. Although I am developing with libGDX in particular, my question is about java programming standards in general.

Suppose I have a controller controlling screen classes containing a stage each. These stages build up the gui including buttons and so on. I'm adding click listeners as anonymous classes for the buttons in the stage. As I want to call methods of the screen or even the controller class in the handle method I am passing down a reference to them from controller to screen to stage to listener. This passing down the reference appears to me as not being good practice.

Alternatively I could get the buttons in screen class and add the listeners there. I would need to add get-methods for each button then though.

Could you think about any other cleaner way of implementing this?

Answer 1

I think towards the end of your question you are on the right path, but let's use some general (not even Java-specific) programming principles to understand why that's the right approach. Here are our principles:

1. Separation of Concerns (SoC): Make sure your code does one thing and that one thing very well.
2. Don't Repeat Yourself (DRY): Code everything once; minimize boilerplate code.
3. Keep it Simple (KISS): It'll be easier to read, easier to maintain, and easier to test.

When I create a game screen in libGDX, I typically use the following structure:

Screen
|- Stage
|- ControllerReference
\- ModelReference

The screen has a private stage which only it uses to create the layout for that particular screen. I then inject a controller (used primarily for changing screens) and a model (dynamic game data) into the screen as demonstrated in the sample code below:

StageScreen.java

abstract class StageScreen implements Screen {
    protected Stage stage;
    protected Game controller;

    public StageScreen(Game controller) {
        this.controller = controller;
    }

    @Override
    public void render(float v) {
        stage.act(v);
        stage.draw();
    }

    @Override
    public void dispose() {
        stage.dispose();
    }
    // Snipped other methods like "hide" and "resize" which aren't relevant
}

MenuScreen.java

class MenuScreen extends StageScreen {
    private Array<Demo> demos;

    public MenuScreen(Game controller, Array<Demo> demos) {
        super(controller);
        this.demos = demos;
    }

    @Override
    public void show() {
        stage = new Stage(new ScreenViewport());
        Gdx.input.setInputProcessor(stage);

        VisTable table = new VisTable();
        table.setFillParent(true);

        for(final Demo demo : demos) {
            table.add(new VisTextButton(demo.getName(), new ChangeListener() {
                @Override
                public void changed(ChangeEvent changeEvent, Actor actor) {
                    controller.setScreen(demo);
                }
            }));
            table.row();
        }

        stage.addActor(table);
    }
}

So let's throw some rocks at the example:

1. Does it separate concerns? Yes . All the screen does is render a button for each demo, and tell the controller the user's intent. All it knows is that Demos have names and that they count as screens. We could make our controller more abstract by passing it an event (ie "UserSelectsDemoX") instead of the screen we want to transition to, but I would argue that this would violate the KISS principle.
2. Does it make us repeat ourselves? No. The code that is common to all screens (management of the Stage, keeping a reference to the folder) is in our abstract class, and our child class only contains code needed to make that Screen do something other screens don't.
3. Is it simple? Yes. Notice that if you are familiar with basic libGDX classes ( Game , Stage , Screen ), you don't need any comments to understand what this code snippet does. We could make things more general (ie make a controller interface and a model interface that only reveal what our screen needs), but adding additional abstraction would just make the code harder to understand.

Hopefully this helps answer your question around the best way to link your listeners to your controller, as well as give you a way of thinking that you can apply to other parts of your codebase.