Rant: Who Designs These UI Frameworks Anyway?

Their interface is big, complex and there is only one reasonable implementation.

Why? Adding new components, and building on them, is a key part of using and extending a UI library.  If to make those new components you have to inherit from something like JComponent, then you are automatically limiting new widgets.

The latter is true even if you would compose their interface from many smaller subinterfaces

The point of the smaller subinterfaces is to limit what the underlying framework needs to know about the component.  So, if it just wants (IFocusable, IAccessible) you don't have to provide a monolith to it.

I'd like to add that none of the solutions is really worthwhile: abstract classes are too limited, interfaces create as correctly pointed out too much redundancy. The only proper OO-solution to this scenario is (mixin) multiple inheritance, which allows a more flexible composition.

But as pointed out, "modern" languages force us to choose one of two evils: Either code redundancy with interfaces (evil) or limited design flexibility with abstract classes. Why again was multiple inheritance removed? To create better code?

Inheritance is fine and good when you have source-level control of the base class, this is not the case of a public API, end users has no control of the code of the base class they are inheriting and almost nobody changes the source code of the tool being used.

Another downside of classes being public is for toolkit developers, when you expose a class you have a problem in the future to evolve this class because you are exposing TOO much. For instance end users are going to create objects with new sentences providing the necessary context information in constructor, if you need more context information in a future you have a problem because construction is also a public API.

For instance I remember when the developers of a famous UI toolkit proposed to end users to systematically change constructors adding a new context parameter. This context parameter (for instance the parent component to be inserted, the object representing the "web page" going to contain this component or similar) would be very useful to set up the component on construction phase, and end users said NO (some like "is your problem"). If the class is not exposed you don't have this problem you don't need to ask to end users or break end user's code. 

Another downside is the benefit of inheritance for the benefit of the toolkit, for instance, if the class of a component is not exposed you can create the appropriated internal implementation based on the parameters provided in some kind of factory method, if your class is public you are forced to provide several types of behaviour coupled in the same class plagued of "ifs" instead of some kind of inheritance used internally,  more elegant solution.

In the case of ItsNat, the interface ItsNatComponent for new components is an interface because provided methods are very simple to implement, furthermore, most of them could do nothing (or throw an exception) because most of them are not called by the framework.

Regarding to adding new APIs, I agree that in public classes you can add a new public method (to be called by the framework) and provided a default implementation (for instance "do nothing"), this is not possible in interfaces, if you add a new method you break the user code when he/she recompiles. But there is another option: put these new methods in a new "conceptual" interface related with the new feature, if the user component needs this new feature the developer can implement this new interface and the framework can ask the user componet with a simple instanceof before calling the new methods. The benefit of this kid of approach is it can help to divide the API by "features", if you look at the API of JComponent you see tons of methods that could be better classified by using interfaces.

I must recognize that web environment is usually a simpler place than desktop (for instance Swing), I agree with Greg Brown (desktop guy) and Jonathan Locke (desktop guy and web guy) desktop is pixel based and more complex and Component base classes do many things. However I think that composition can also work , you can extend the "configurable" behavior of a component with extensions the same like Swing allows pluggable renderers to replace the default behavior, you are not going to see classes derived from Swing's  JTable because JTable provides as pluggable extensions all your need, the same could be done for JComponent like an interface, you could create a prototype object (the default implementation) calling a factory method and extend it with "plug-ins". 

Anyway I must recognize that when I have complete control of source code of classes I prefer inheritance instead of composition (plugins explained before), of course when inheritance is the best option (when the question "I am X" is yes, inheritance is the path, different to "is part of me" a.k.a. composition), but this is not the case (in my opinion) in public APIs.

Ah, finally, coupling is not ever bad, when you inherit is because there is a strong "conceptual" coupling between classes. Like in marriage coupling is "sometimes" needed :)

That would simply mean the class that you design may have more than one responsibilities (ie. view and business logic).

Views of Widgets in a rich UI toolkit necessarily have far more than 1 responsibility, which is why they get so large.  They will typically handle graphical rendering, tabbing, accessibility, containment of other widgets, being contained by containers, focus handling, keyboard mapping & shortcuts, event management and many other concerns.

And this is before any business logic in the app at all.  This logic typically all sits in event listeners.

Essentially this entire discussion has been about how to manage these complex capabilities in a sensible way, whilst supporting the creation of new widgets and evolution of the underlying toolkit itself.

Using an interface as a base for a UI component hierarchy is a ridiculuous idea

That's simply not true; a number of frameworks do this to very good effect.  I do it in my commercial product.  Is it more difficult than using abstract classes with different pros and cons?  Yes, clearly.  It also tends to push infrastructure away from the widgets themselves.  This can be a good thing as it minimizes the work needed to implement a new component and makes the responsibilities clear.  The disadvantage of interfaces is that abstract classes support better framework evolution, as default implementations of methods can be added.  However, each approach has its strengths.

 UI frameworks are not designed to accomodate your test environment.

We are talking about testing the widgets and supporting infrastructure, and allowing alternative implementations that don't carry the default implementation baggage.

A huge thank you to all those who participated in this lively discussion! It has been very useful to me. I have tried to summarise the key themes of the discussion over on my blog:

http://kennardconsulting.blogspot.com/2010/12/rant-who-designs-these-ui-frameworks.html

First, I would like to apologise to any who were offended by the somewhat incendiary tone of my article. It was pitched as a 'rant' in order to encourage responses, but in no way am I suggesting the UI frameworks I listed are anything but successful - or that their creators are anything but intelligent, brilliant people.

But anyway, the themes:

• Some UI frameworks (albeit a minority) *are* interface-based. Examples include ItsNat, Vaadin
• Other frameworks have considered being interface-based (Swing), but on balance decided to use abstract classes. Neither is optimal: "when I was working on the Swing team at Sun Microsystems back in the early days of Java. Some people on the team were of the opinion that Component should be an interface and others that it was best as an abstract class. But really, neither sounded like a good choice
• Abstract base classes limit future use cases. This is dangerous because "anything of strategic importance will be used in ways that the original designer cannot anticipate"
• The problem with a 'monolithic' interface is that it is cumbersome to evolve: "You will soon have IComponent, IComponent_v2, IComponent_v3"
• The problem with 'granular' interfaces is that you often have to pass around many of them together: "I found it to get problematic as I'd pass around something like (Sizable, Locatable) and then deep in the heart of the framework I realised I needed Focusable also, and I then had to go back up the stack chain and add it to all parameters"
• Java does not have a good way to bundle several 'fine-grained' interfaces together, but other languages may (Scala traits): "It's not yet possible to write Component the way I really want to write it. To do that, you'd have to change Java."

Thanks again!

Richard.

Can't agree more Ronald.

Neither interfacing nor composition is always good choice or bad one.

It is needed that engineer think how that peace of code she writing will be used and to do it proper way.

Dangerous it is just to follow some advice which is good for only 90% of the time, like those above about interface over class and composition over inheritance.

Milos