Swing
From APIDesign
Swing is standard GUI for Java (in spite of many seeing the future in JavaFX; while everyone should be looking at DukeScript!). What do you think, is Swing following the MVC paradigm or not? Recently Swing and JavaFX interoperability has been greatly improved.
Example of Bad APIDesign
Few readers of TheAPIBook complained that it is too UI oriented as some of the examples are about Swing. True, but it is hard to find better examples of bad API Design. Swing is designed in a way SmallTalk people think about design and re-use. All methods are virtual, one can override almost each of them. There are duplicated helper methods which can be overwritten as well.
This all has one big problem. It is a braid of virtual methods calling each other. An object oriented spaghetti code. One needs Swing sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of cluelessness (yet I have to admit it is possible to do some trivial stuff in clueless mode).
This also has implications for the maintainers of the Swing framework. They have to assume everyone can override anything - almost like in the case of APILessAPI where one can literally change anything. Sometimes people do crazy things and then weird code paths get executed. That means a maintainer of Swing has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the Arithmetica class). Not every engineer working on Swing has such attitude and there used to be a lot of incompatible changes in the past (when Swing was still in active development).
Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice: design APIs where less is more!
Follow
