| Re: [platform-ui-dev] User interface code smell and update of the wiki |
I'd argue that listeners themselves are an antipattern.
- They risk memory leaks if they aren't explicitly removed.
- They don't have inherent flow control, and can introduce performance problems when things change more rapidly than those changes need to be consumed.
- They duplicate business logic between whatever code initializes an observer's initial state and whatever updates that state in the listener.
- The set of things that are listened to need to match the set of dynamic data that is accessed within the listener. If they get out of sync, it introduces stale data bugs. Such bugs are hard to test for and easy to create.
- Most listeners are synchronous, which creates all sorts of special cases when they invoke methods that reach back and access the code that is invoking the listener.
Now that we have several good models for reactive programming ( databinding's SideEffect class and tracked getters or one of the various FRP libraries ), there's no need to use listeners at all anymore except within the implementation of said libraries.
Hi all,
Andrey suggested me to send a message here regarding the discussion we
started there:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=510745
We are researchers in software engineering that currently work on user
interface (UI) bad coding (aka. code smell) practices.
We are studying UI listeners, in particular listeners that manage
several widgets, like the following listener we spotted in
org.eclipse.ui.workbench:
@Override
public void handleEvent(Event event) {
if (event.widget == addResourceTypeButton) {
promptForResourceType();
} else if (event.widget == removeResourceTypeButton) {
removeSelectedResourceType();
} else if (event.widget == addEditorButton) {
promptForEditor();
} else if (event.widget == removeEditorButton) {
removeSelectedEditor();
} else if (event.widget == defaultEditorButton) {
setSelectedEditorAsDefault();
} else if (event.widget == resourceTypeTable) {
fillEditorTable();
}
updateEnabledState();
}
In such listeners, the source widget is identified using if/switch
statements.
Thanks to empirical studies we have indications that such a practice has
a negative impact on the code quality.
We call UI listeners that control three or more widgets, Blob Listeners
(see this PDF document for more details:
https://hal.inria.fr/hal-01308625v2/document).
We submitted patches to removing Blob Listener instances from
org.eclipse.ui.workbench here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=510745
Andrey suggest me the idea of adding another section or page to the
Platform UI wiki (https://wiki.eclipse.org/User_Interface_Guidelines)
and describe the blob listener pattern there.
What do you think?
Also, we have several questions for the Eclipse's developers:
1/ Do you think that coding UI listeners that manage several widgets is
a bad coding practice (cf the exemple at the beginning of the email of
the patches)?
2/ Do you think that the threshold of three or more widgets per listener
relevant for characterising a Blob listener?
3/ Do you consider the refactored code suitable for removing Blob listeners?
4/ Do you have any idea of the reason of the presence of Blob listeners
in the code?
For example, lack of anonymous functions (aka lambdas) in Java 7 (and
previous JDKs)? Multiple developers with various experiences,
backgrounds? etc.
5/ Do you have suggestions about other bad user interface coding
practices? This can concern controllers, commands, GUIs, widgets, data
bindings, GUI testing, etc.
Cheers,
--arno
--
Arnaud Blouin
Associate Professor INSA Rennes, France
Inria DiverSE Team (formerly Triskell)
http://people.irisa.fr/Arnaud.Blouin/
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev