[
https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349245#comment-16349245
]
Roger Whitcomb commented on PIVOT-1011:
---------------------------------------
One last tidying up:
Sending wtk\src\org\apache\pivot\wtk\ExpanderListener.java
Transmitting file data .done
Committing transaction...
Committed revision 1822906.
> Move ListenerList implementations of interfaces into the interface itself
> -------------------------------------------------------------------------
>
> Key: PIVOT-1011
> URL: https://issues.apache.org/jira/browse/PIVOT-1011
> Project: Pivot
> Issue Type: Improvement
> Components: core-collections, core-util, web, wtk, wtk-terra
> Environment: All
> Reporter: Roger Whitcomb
> Assignee: Roger Whitcomb
> Priority: Minor
> Attachments: 1011.diffs
>
>
> A universal paradigm in Pivot is to have a "listener" interface for a class
> or data structure that is used to notify listeners of changes in the
> class/data. There is then an "Adapter" static class in the interface file
> that implements the interface with default implementations. Then there is a
> very separate enclosed static class that implements the "ListenerList"
> interface of that listener interface. And usually (or always) this "listener
> list" class is defined/used only in the class that needs to notify the
> listeners. However, this class must be very parallel to not only the
> interface itself, but also the "Adapter" class, and yet it is in a different
> place.
> So, it seems somewhat reasonable to move all these "listener list" classes
> into the interfaces themselves, so all three related things are located in
> the same file. A preliminary POC of this concept was done with "Query.java",
> and "QueryListener.java" and it looks good.
> This doesn't seem to require changes to client code, because the accessor
> methods only refer to "ListenerList<....>" and not to the listener list class
> itself (in order to be more general, of course), but which helps us to hide
> the implementing class away inside the interface.
> I will attach the diff of the POC, to hopefully make this more clear. It may
> seem a somewhat nebulous concept, but the idea is to keep "like things"
> together for clarity.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
