On Tue, Jun 22, 2010 at 8:57 AM, Greg Brown <[email protected]> wrote > > in my experience WeakReferences > > are better since the lifecycle of the listener is generally (90%+) > > equivalent to the lifecycle of the component that defines the listener. > > I mentioned this in my previous email, and I think it is actually a much > stronger argument for strong references: In this case, you don't need to > worry about unregistering the listener anyways, so weak references add > almost no value. > > This is dead wrong. If component A adds a subscriber and component A goes away, the subscriber must be removed.
Take out pub/sub and it's still wrong: If component A adds a listener to component B and component A goes away, the listener must be removed. THE SUBSCRIBER HAS THE SAME LIFECYCLE AS THE COMPONENT. > Anonymous inner classes are not a questionable design pattern. They have a > valid use case in event handling, also described in my previous email. Once > you get used to the syntax (which I'll admit seemed a bit strange at first), > they become quite useful. To me, they are somewhat akin to closures, which > also seemed strange at first but are the cornerstone of many currently > popular languages. Huh? Just because you don't question them doesn't mean they are not questionable. Lots of other people question them. Google it if you are interested in what other people think. Personally, I've written hundreds of them so I'm "used to the syntax." They aren't closures and a main motivation for getting Closures in Java is because anonymous inner classes are a suboptimal at best. > > when annotations are available users generally use that > > more terse route rather than using an anonymous class. > > I am not familiar with techniques for using annotations to replace > anonymous inner classes. Can you provide some examples? > There are a number of detailed examples in the article and demo I wrote on Pivot and the EventBus and sent to you a few months ago. Did you read it yet? > > > I think the encapsulation argument is extremely weak. Firstly, most UI > > developers don't care too much about building extensible classes > > It's not a question of extensibility - it is about method visibility. When > your class implements an interface, all listener methods by necessity become > public. Any other class can now invoke the listener method, effectively > spoofing the event. This is a poor design that inner classes allow you to > avoid. > This is a good design since it allows the component to be tested in isolation. Spoofing events is sometimes a nice way to get things done in normal (non-test) development too. Encapsulation in UI development is way overrated. There's already so much exposed just by extending a base class. Besides, if you use annotations, you don't need to implement an interface. > > Also, if your class needs to respond to multiple events, it must now > implement multiple interfaces. This further bloats its public API and > exposes it to additional misuse. > Most components already implement a ton of interfaces and adding more to describe all the responsibilities of a class is better than trying to hide a bloated class with a lot of hidden features. Besides, if you use annotations, you don't need to implement an interface. > > > Lastly, if you don't like that idea, you can easily create private fields > that are listeners. > > I'm not sure how you could do this without inner classes. > > They would be inner classes, but since they are fields, they are not anonymous and thus are lifecycle'd with the component.
