> This is dead wrong. If component A adds a subscriber and component A goes > away, the subscriber must be removed.
That's only true if something else maintains a reference to the listener, which is generally not the case when using anonymous inner classes as listeners. >> Anonymous inner classes are not a questionable design pattern...To me, >> they are somewhat akin to closures, which >> also seemed strange at first but are the cornerstone of many currently >> popular languages. > > They aren't closures and a main motivation > for getting Closures in Java is because anonymous inner classes are a > suboptimal at best. I didn't say they were closures - I said they were akin to closures. Also, at least one of the proposals for implementing closures in Java is effectively syntactic sugar around anonymous inner classes (though I'm not sure if that is the one that is actually being implemented for Java 7). >> 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 read it. I did not memorize it. >>> 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. > > This is a good design since it allows the component to be tested in > isolation. It is not good design. It breaks encapsulation, and thus violates a basic OO principle. You should not be making a list selection change listener part of your public API, for example. It allows an arbitrary caller to simulate a change event, which may leave your class in an inconsistent state. If you want to test something in isolation, you can make the methods package private and create a JUnit test that lives in the same package. > Besides, if you use annotations, you don't need to implement an interface. And thus lose the compile-time benefits of using an interface.
