Rant: Who Designs These UI Frameworks Anyway?
Join the DZone community and get the full member experience.Join For Free
I've been working with a few different UI frameworks lately as part of building Metawidget, and I've noticed something...
First let me state some things I hope we can all agree on:
- Rule 18 of Effective Java: Prefer interfaces to abstract classes
- Rule 16 of Effective Java: Favor composition over inheritance
- The industry trend toward POJO-based development is a positive one
If you accept all these, then I have a shock for you: most UI frameworks ignore them. Oh sure, UI frameworks love defining interfaces for you the developer to have to pass them (MouseListener, SystemEventListener etc) but when it comes to adhering to these rules themselves, internally? Not so much.
Swing of Doom
Here's the challenge: how come hardly any UI frameworks define their widgets in terms of interfaces, as opposed to abstract base classes? Why isn't, say, Swing's JComponent an interface? By all means have a JComponentImpl as a convenience class, but don't force me to extend from it. Many programming languages use single-shot inheritance, so if you constrain my single-shot I'm screwed if I want to develop, say, some cross-platform UI functionality or a composite component without putting everything inside a JPanel.
It's Not Just Me, They're All Doing It!
Sure you could argue this is a corner-case, and that Swing predates much of the modern wisdom, but just look at this list:
Where are the lightweight, POJO-based, interface-based (or even, gasp, annotation-based) UI frameworks?
A Shining Example To Us All
A twist to the tale: I did manage to find one UI framework that implements its base widget using an interface. What is this enlightened, cutting-edge, modern framework you ask? Why plain ol' Java Server Pages of course! Its base Tag is an interface, with convenience class TagSupport. JSP, eh? Before its time or what :)
Opinions expressed by DZone contributors are their own.