Java Swing + MVC pattern in a modular way

Question

I'm developing a Java Swing application and I'm following the MVC approach. I've a controller and then I've my model and my view.

Model and View only communicate via the Controller. The Controller was communicating with the Model and View by interfaces which lead to quite a lot of nested code.

After my boss review over the code he complained that it wasn't modular. He wanted a more modular approach. Where he could put in a new module or remove one without much hassle. With modules he meant like a toolbar, a table, menu bar... all regarding my View model. He also didn't like all the interfaces and nested code he saw.

What suggestions do you have for me to change my approach without messing up all the code I already have (it is really a lot of code, really a lot!).

I did google for "java mvc modular" and I didn't find much information about this.

The approach I think that can solve my problem is using an EventBus. The module would just need to send an event using the bus and the controller would handle it. At least no more nested code with all those interfaces.

With the bus I would just do something like (on the module):

bus.post(new MyEvent());

And on the controller:

@Subscribe 
public void onEventMyEvent(MyEvent event) {
     // handle the event
}

--------------- EDIT -------------

After reading the link provided by the user trashgod (in the comments section) and conclude that what I'm doing right now is using the MVP (Model View Presenter) represented by this image: (Credits for the image to udalmik and found here: enter link description here )

Answer 1

The Model, View, Controller pattern allows us to separate business logic, screen rendering and handling asynchronous events into discrete classes. The benefit of this is that it effectively decouples all the fundamental responsibilities of a GUI-driven application into dedicated classes. This means that the functionality of each class is isolated, which better accommodates application-specific customization and maintainability.

So, with this fundamental approach, the application's overall architecture for your application is good so far, however what your boss is looking for is slightly different. He's asking for the implementation of some architecture which will allow you to rapidly and simply modify the UI. So, immediately, you can tell what he's asking for is with respect to the View element of the MVC.

Below I use pseudo-code to provide a generic example of how you could create these modular graphical elements.

public final class View {

private GUIElement mModularElement;

public final void setModularElement(final GUIElement pModularElement) {
    this.mModularElement = pModularElement;
}

public final GUIElement getModularElement() {
    return this.mModularElement;
}

public final void onRender(final GUIVariable pGUIVariable) {
    this.getModularElement().draw(pGUIVariable);
}

}

In this code, we've defined the View of the application access to an instance of something called ModularElement, of type GUIElement. By using public getter/setter methods, the Controller can get the View to render any type of Object that inherits from GUIElement. So, if you ever wanted to change the GUI, you could specify a new kind of GUIElement without making changes to the surrounding architecture.

This is a basic example, because other kinds of responsibilities, not just rendering, would need to be handled by the GUIElement to maximize flexibility. These would include defining the screen layout, encapsulation of further graphical elements, how they handle MotionEvents, all lie within extending the functionality of GUIElement. You could even draw an array of GUIElements. Importantly, mModularElement would exist within your Model to adhere to the MVC pattern; the implementation above avoids this in the interest of simplicity.

Hope this helps.