Otaku, Cedric's weblog

Java Component Object Model

In a previous entry, I discussed how using mix-ins lets you compose your code to a finer level and allows you to create smaller bundles of functionalities that you can import and use on demand.

Of course, it is quite possible to take this practice too far and end up with code that is not only broken down too much but also spends most of its time exchanging messages between its various components using more complex communication ways than it should.  Sometimes, it just makes sense to group certain methods and fields in the same class.

Formalizing the communication between units of code is a subject that has received very little exposure until recently, and when you are trying to pass information between different classes (A to B) or different packages, you typically use one of the following techniques:

• Have A create an instance of B with the right parameters and invoke a method on it.
• Have A create an empty instance of B, call a few setters then invoke a method on it.
• A receives an instance of B that has been created somewhere else and invokes a method on it.

The hard coupling of A and B is a topic that has already been covered many times and can be improved by either using interfaces or dependency injection.  However, there is a third way to accomplish this that I am hoping will be used more and more:  use a plug-in architecture.

I have written quite a few Eclipse plug-ins these past years (and more recently, RCP applications) and I started noticing two very interesting trends in the code that this environment made me produce:

1. Resuming development on a plug-in I hadn't worked on for a while was very easy, because the various parts of the plug-ins were so clearly isolated from each other that I only needed to brush up on a very small portion of my code to be able to modify it.
    
2. Adding features to an existing plug-in didn't require understanding the existing code base:  all you need to do is read some documentation about the area that your plug-in will depend on and focus on that part only.

 In case you were wondering about the reasons behind the explosion of Eclipse plug-ins, look no further:  the reasons are outlined above, and the bottom line is that the learning curve to add to existing code with the Eclipse model is extremely small (and can actually go down over time).  When new developers join your project, they don't need to learn a new architecture because that architecture has been formalized by Eclipse and everybody now agrees on how the plug-ins are declared and how they interact with each other.  The rest is, literally, implementation details.

The net result of this new paradigm is that all Eclipse plug-ins and RCP applications are nothing more than a set of isolated modules that gravitate around the Eclipse core. 

Another interesting thing about this architecture is that even the communication between these plug-ins is formalized.  Not only does the plug-in model offer all the benefits of dependency injection, it also formalizes how you can receive notifications from other plug-ins, how you can emit notifications yourself and more importantly, hides all the details pertaining to upgrades, classloading, and, of course, provides an impressive set of functionalities that cover everything you will ever need for a client-side application, including integration with the host operating system (Windows, MacOS and GTK/Gnome).

Thanks to Eclipse and the RCP, Java is finally on its way toward having a true component model.  Still not as powerful as COM (only in-process mode is supported), but definitely one step closer.

 

Posted by cedric at August 23, 2005 06:00 AM