Pattern for annotation based null analysis and GUI programming [message #1749750] |
Sat, 10 December 2016 23:15 |
Frank Benoit Messages: 179 Registered: July 2009 |
Senior Member |
|
|
Hi
in GUI, the initialization is often done over a sequence of called overridden methods.
E.g. if you implement a org.eclipse.jface.dialogs.TitleAreaDialog
Then the buttons and all the widgets created not in the ctor of the class, instead it needed to do it in createDialogArea() and friends.
This means, all those widgets, that need to be accessed later, must be fields with @Nullable.
What i try to achieve, is to have the object's fields as @NonNull, intialized in the ctor.
I create an inner class "Gui" that is instantiated in the createDialogArea, passes the args to Gui, and Gui has all those widgets as fields. Now initialized in its ctor.
All other overrides in my dialog class, need once to check the Gui instance to be non-null and then delegate to it.
This will not work, if there are 2 or more overrides that are used to create widgets. Not sure if i will encounter this. But before i start to work on my code base....
Are there better patterns?
|
|
|
|
|
|
Re: Pattern for annotation based null analysis and GUI programming [message #1749765 is a reply to message #1749763] |
Sun, 11 December 2016 22:24 |
Frank Benoit Messages: 179 Registered: July 2009 |
Senior Member |
|
|
Hello Stephan,
thanks for this link.
An inner (non static?) class derived from the outer. I would have never thought about this.
I was not even sure if this is legal, i had to try it to be convinced.
Does that mean you have all fields doubled, once for the outer and inner instance?
Probably best done with a static inner class.
In that link, they are making use of an own language to support this state types feature.
Using this in Java with a GUI library, i have doubts.
1. you need to copy all exising fields from the previous state class (the not-fully-initialized one).
If I understand correctly, i cannot do this e.g. with TitleAreaDialog, i cannot expect to find a copy constructor or such. This would mean, to cancel the TitleAreaDialog build up procedure in the middle (when i am called in createDialogArea()) and to continue in my newly created state instance. Challenging, hehe
2. The user of the class must know, to exchange his references with an newly returned one?
So the user needs now somehow to handle state transition actively. If the reference to that class is hold in multiple places this gets ugly.
Or do I miss the point and it can be done in Java in a good way?
About the annotation order, the SonarLint rule is this:
https://dev.eclipse.org/sonar/rules/show/squid:ModifiersOrderCheck
Are the places technically equivalent?
private @Nullable Listener getListener();
@Nullable private Listener getListener();
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03457 seconds