Interface Driven Design

In a sense, I feel vindicated thanks to this article, as its how I've approached my projects and components from the very beginning. It doesn't matter if I'm designing an overall user interface, a single Swing-based component, a web page, or a piece of back-end library code. I always try to make it easier for the end user to use.

One consideration when it comes to the "well, nobody else but me is going to see this" argument : you may have to come back to that code in 4 months time after dealing with something completely different. Will it make sense to you then?

The way to handle that situation and all others is to remember that "the best" interface isn't always correct, or for that matter even possible. What you strive for is "the best fit". Make the interface something that the end-user of that level will be used to, or that fits into the rest of the design.

When making overall GUIs, this means that one has to consider standard Microsoft Windows layouts, even if one hates them: only change from that if your customer says "no, we can go with something different". When the GUI is uncomfortable, the project has a hard sell, no matter how much the customers need the capabilities.

If writing a Swing component, use MVC, with its requisite model Interface, JavaBean events, Abstract model implementation, Default model implementation (derived from the abstract model to test the base code), and have Component use standard JavaBean properties.

If writing a library, consider separation of the interface hierarchy from the default implementation, with factory classes that instantiate a driver class to create the rest of the implementation as you need it. This is how JDBC and JAXP work, and its what programmers are used to. It may not be the best, but its something a programmer can immediately recognize and say "ok, I can get past the basic instantiation problem, now lets get to the real work".

When writing general services, use JavaBean events (I have a code generator for automagically making the event listeners, classes, and templates for the triggers to insert into the beans). Layer the events appropriately; at no point in a high-level component should someone have to write an "ActionListener".