Creating Dynamic Swing Views with Reflection by Extending MVC

by Vlad Kofman

Deploy a large GUI program quickly and effectively by implementing the Model–View–Controller (MVC) architecture. Several developer groups can work on business logic or model layer, data representation or views, and controller independently; combining the pieces at the end.

Often large GUI projects need to be deployed quickly and adhere to strict guidelines; therefore design and implementation process is assigned to multiple developer groups doing the work simultaneously. With the arrival of Model–View–Controller (MVC) architecture, several developer groups can work on business logic or model layer, data representation or views, and Controller independently; combining the pieces at the end. MVC has been used extensively in GUI and Web–Based applications; in this article I’ll show how to extend MVC architectural pattern to build a Swing GUI program by using Reflection to dynamically generate Views. The Controller will read a property file, generate Views, and corresponding Models, and execute simple business logic. Developers working on Views and following this design will only need to update properties file and their new class instances will automatically be added to the main project, without the need to modify Controller or any other part of the project. Reflection will be used to instantiate new objects and call required methods.

On a historical note, model–view–controller architectural pattern was conceived in the mid–1980's by developers of the Smalltalk-80 GUI library. It has since then been extensively used in most object oriented user interfaces, it has also been extensively covered in numerous books and publications. According to the MVC pattern, the model should be separated from the actual implementation of its view. The reason being, that there could be many representations of the same data and closely coupling views with the model would complicate project’s development, modifications and create maintenance nightmares.

In other words, you do not want to change your business logic every time you change your view.

When working on a large Swing GUI project, one way to represent views is to use Tabs or JTabbedPane as an underling class. Development of different modules should be assigned to different programmer groups and at the end and each Tab (view) has to be added to the main application. And before any coding is done, project architects usually come up with object relationship diagrams, use-case diagrams, object flow diagrams and hand out coding responsibilities. At the same time, GUI programmers or designers create appropriate screen prototypes for all sections.

Sample Project

In order to show how to extent MVC to create and coordinate views, I have created a simple GUI project that shows an application containing several tabs and several buttons with attached actions; this project has all the components of a template for a large–scale projects, and with small modifications can easily be reused in other GUI applications. The project contains – a controller that, as any MVC controller, deals with all data flow and coordinates object relationships, but on top of that it also literally creates all views. A model layer – represented by interface ModelInterface and several concrete classes extending it, and a view layer – represented by abstract class AbstractView (that by itself extends generic JPanel component) and several concrete tab classes extending AbstractView class. The model layer is actually a set of beans that perform some rudimentary business logic operations. The beans are not EJBs, but simply objects that manipulate data. The project also has one main property file.

In an enterprise level application properties are usually read as java.util.Properties and include data-store locations, connection pool information, environment variables, debug levels and other global information. For our purposes only views info in a text file will suffice. Additional services managed by controller like persistence, distribution or security, are also beyond the scope of this article.

Main Controller

The Controller is the brain of the project, its responsibility is to capture user events and to determine which actions each of these events imply, and in my case to instantiate new View objects and corresponding Model objects and coordinate actions between them. I called the controlled class “MainController”, it has three methods: init – where all the initialization and views instantiation takes place, execute – where an action from a View invokes some operation from a corresponding Model, and loadProperties method that reads a text file with names of the concrete Views to add. The text properties file is called smvc.property and has just three lines – the actual names of concrete views or tabs:


MainController also has three fields: a main JTabbedPane to add new Views too, an array of Tabs and a HashMap of to store Model objects.

In the init method I call the loadProperties("smvc.properties") to fill the array with tab names from the property file. As each view’s class name is read from the properties file, I use Java Reflection API to instantiate actual objects and add them to the main JTabbedPane. See listing 1 at the end of this article.

Class newClass = Class.forName((String) tabs.get(i));
//try to make an object – extending AbstractView
AbstractView anyTab = (AbstractView) newClass.newInstance();
//add our new view tab here, and set its name
mainPane.addTab(anyTab.getName(), anyTab);

// I also set a reference back to the Controller
// let each tab know who is its controller

As soon as I add all dynamic Tabs, we can see them:

Swing Views

As I said, each Tab (view) in the project is a subclass of AbstractView abstract class. The AbstractView itself has methods to set the Tab name, set parent component (reference to the controller object), and init method that automatically uses Class name as Tab name (you can change that of cause); very useful since concrete Views will inherent them all.

(See source listing for complete AbstractView code).

// get the name of the class - for tab name
String name = this.getClass().getName();
// get rig of all package info just leave class name
setViewName(name.substring(name.lastIndexOf('.') + 1));

I created several concrete view classes; each concrete View class calls an init method of its super class to set its name and adds a button to invoke a simple action from a corresponding Model, via MainConntoller object. Usually a view layer implements a rendering of the model, but in our case I will only call an action. The view is responsible for getting and showing information from the corresponding model that is appropriate based the model state. The view also gathers information to pass on to the model via controller. If I wanted too, I could’ve added some fields in the each Model and got their data when a matching action was requested from my Tab.
When the button on concrete View 1 is pressed, it will call MainController execute method (via its reference to parent we set earlier) and pass a String key or Model name to let the Controller know to which model it should delegate the request. Code below demonstrated this.

//inside anonymous class for action listener attached to a button
public void actionPerformed(java.awt.event.ActionEvent e) {
   ((MainController) ConcreteView1.this.parent).execute(ConcreteView1.this,"Model1");

I’m passing a reference to the View itself [ConcreteView1.this] as an optional parameter, but if I wanted too I could’ve used it to retrieve user data from the View and done something with it. MainController will instantiate any Model, if it has not done it yet, by using Reflection, add it to the HashMap, and call its action method. (See MainController execute method source.) I add each new Model objects to the HashMap right after instantiation, for the obvious reason not to instantiate a new object every time there is a request from the View. Therefore, if a new request comes, I first check if object already exists and only then complete action. See listing 2.

Model object is created once and is reused afterwards.

Please note that the model does not have any dependence on views or Controller. Generally speaking model layer encapsulates application domain’s concepts, both behavior and state. It responds to requests for information about its state and responds to instructions to change its state. In a well–designed project each concrete Model class will be based on some business logic need and may involve extensive operations on the data or a RDBMS access.

Models should also have clear and simple public interfaces so that if a view is completely changed, for instance from my Swing JTabbPane to a web JSPs, same methods wound be called and requests made.

Model Layer

I created a public ModelInterface interface class, and inherited it by all concrete Model classes. The only public method is doAction and it simply prints out which Model it belongs to. When Controller delegated the request from the View it calls this method.

ModelInterface model = (ModelInterface) models.get(model_key);
if (model == null) {
      Class newClass = Class.forName((String) model_key);
      //try to make an object
      ModelInterface anyModel = (ModelInterface)
      //try to add our new view tab here.
      models.put(model_key, anyModel);
      model = anyModel;

(See Controller source for more into)

The model beans don’t really do anything fancy, but you could effortlessly add more methods to the ModelInterface and their implementing in the concrete classes and then call them based in the key passed on through the controller.

As you can see, this project now has all the elements that can be used to expand View layer with more view. If I want to add another View, all I have to do is create a new class that extends AbstractView, add a new line in the property file for instance “NewTab”, call super.init() in View’s constructor and I’m done! The controller will create it, add it to the main application and show it. It’s that easy! See listing 3.

The incorporation of Model–View–Controller design architecture allowed for decoupling of presentation layer and logic it represents, and extension of MVC allowed for dynamic View generation. Naturally, once the controller is done and coding guidelines have been established, such as properties file format and inheritance structure, work on any project following this design can be concentrated on business logic and presentation by multiple developer groups, simultaneously. Reflection played a big part in automatic view generation, but if class encapsulation were preserved, developers working on the Views or Models would not need to know how their classes are instantiated, added to the main components, referenced and displayed.

Listing 1

Listing 2

Listing 3

Download source code jar here

About the Author

Vlad Kofman is a System Architect currently working on projects under government defense contracts. He has also been involved with enterprise level projects for major wall-street firms and US government. His main interests are object oriented programming methodologies and design patterns.


Sun Reflection API by Dale Green

WebSphere Studio Application Developer Version 5 Programming Guide
By Ueli Wahli, Ian Brown, Fabio Ferraz, Maik Schumacher, and Henrik Sjostrand
IBM Redbook SG24-6957-00, May 9, 2003

Core Java 2, Volume II: Advanced Features (5th Edition)
by Cay Horstmann, Gary Cornell
Publisher: Prentice Hall; 5th edition (December 10, 2001)

This article was originally published on Monday Sep 29th 2003
Mobile Site | Full Site