Swing

From APIDesign

Revision as of 10:30, 23 May 2012 (edit) JaroslavTulach (Talk | contribs) ← Previous diff		Revision as of 10:36, 26 August 2016 (edit) (undo) JaroslavTulach (Talk | contribs) Next diff →
Line 3:		Line 3:
	{{:Blogs:JaroslavTulach:Daily Life:Podcast2}}		{{:Blogs:JaroslavTulach:Daily Life:Podcast2}}
		+
		+	=== 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 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 [[OOP][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. Sometimes people do 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 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.

---

Revision as of 10:36, 26 August 2016

Swing is standard GUI for Java (in spite of many seeing the future in JavaFX). What do you think, is Swing following the MVC paradigm or not? Recently Swing and JavaFX interoperability has been greatly improved.

Listen to podcast #2: to learn about our take on Swing and its poor reentrancy. Find out what it may mean for your own API design and especially Runtime_Aspects_of_APIs that you create. Learn to fight with that problem by maximizing the declarative nature of your API.

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 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 [[OOP][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. Sometimes people do 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 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.