Swing
From APIDesign
(→Example of Bad APIDesign) |
(→Example of Bad APIDesign) |
||
| (7 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | [[wikipedia::Swing_(Java)|Swing]] is standard [[GUI]] for [[Java]] (in spite of many seeing the future in [[JavaFX]]; while everyone should be | + | [[wikipedia::Swing_(Java)|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 [[JavaFX|improved]]. |
| Line 6: | Line 6: | ||
=== Example of Bad [[APIDesign]] === | === 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. | + | 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 [[OOP | + | 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 - almost like in 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 attitude and there used to be a lot of incompatible changes in the past (when [[Swing]] was still in active development). | + | 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 | + | Maybe the wide openness of the framework is the reason why it has such a bad reputation!? My advice: design [[API]]s where [[Do_Not_Expose_More_Than_You_Want|less is more]]! |
Current revision
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
