Thread: Pros and Cons of Listeners vs Method invocation through Reflection

Hi there.

First of all, this is a very theoretic question, there is a little wall of text ahead, I am sorry to take away so much of your precious time with this, but I would very much appreciate some opinions of more experienced programmers on this topic.

I know that the majority of standard java classes uses listeners when they are supposed to interact with application logic; for example AWT and Swing GUI components have listeners as a way to interact with the end user.
I personally have never really liked the listener approach in java because it forces you to write huge amounts of code for simple problems. At least thats my opinion.

If I have a GUI with a button, and, for example, and I want to invoke some method when the button is pressed I would have something like this in my initialization code:

    public void init() {
        Button btn = new Button("some button");
        btn.addActionListener(new ActionListener() {
            public void onAction() {
                doStuff();
            }
        });
    }

Thats five lines of code, even when trying to make it somewhat small. I mean, I could always sprinkle in some white-lines to make it more friendly to the eyes, but I would not like to make it any smaller then this to keep it easily readable.

Now, through the use of reflection we could do things like this:

    public void init() {
        Button btn = new Button("some button");
        btn.setAction(this, "doStuff");
    }

This would be much shorter with just a single line of code. It is also much more straight forward and easier to understand. (In my opinion)


The button class would use Reflection to get an object of class Method which points to the Method doStuff within our Applications GUI initialization class.

    public void setAction(Object source, String methodName) {
        this.source = source;
        this.method = source.getClass().getMethod(methodName, null);
    }

(For simplicity, lets ignore exceptions for now)

When the button is pressed the internal logic would do something like this:

    public void onPress() {
        this.method.invoke(source, null);
    }

Now both alternatives would obviously work. But I would like to know what the pros and cons would be, or what you would think they would be.
For example, would there be any major performance difference between both methods? Does one need significantly more ram? Might there be any compatibility issues that could come up in the future?
Just tell me anything you could think about.

Thank you all very much, I really appreciate any kind of input on this topic.

Originally Posted by copeg

[...] This allows a programmer to write code such that it can respond in more ways than one to an action (or change), the responses can be reused in other contexts, and these responses can be added or removed at any time. The reflection approach you outlined suggests a one-to-one relationship, and if one wants a program to respond in multiple ways to a button action, one must jump through hoops (or write their own library) to do so.

I dont see why this should be impossible with the Reflection approach. Sure, the example Code that I have shown is not the most fitting, but when designing an API you could easily work around that.
One could create a little Wrapper class which remembers the source and the method to be invoked and have them in a list.

Originally Posted by copeg

Another con of the reflection approach is that it can result in runtime errors (rather than compile time errors) that can deleteriously affect functionality.

Originally Posted by aussiemcgr

[...] Reflection can lead to seemingly random and inconsistent runtime errors, which we all know is the most annoying things ever to debug. Notice the word "seemingly", because the exceptions thrown by Reflection are usually not immediately obvious that they are caused by code which uses Reflection.

There is only 2 Exceptions which can be thrown by the Reflection methods used in this code; the NoSuchMethodException which is a fairly obvious one, and the SecurityException which is unlikely to happen unless the method is not public.
The API says:

SecurityException - If a security manager, s, is present and any of the following conditions is met:

• invocation of s.checkMemberAccess(this, Member.PUBLIC) denies access to the method
• the caller's class loader is not the same as or an ancestor of the class loader for the current class and invocation of s.checkPackageAccess() denies access to the package of this class

Furthermore these are checked exceptions and their appearance is not at all random; if they will be thrown at all they will be thrown right at the initialization of the GUI.
Maybe I am overlooking something, but from what I see I can not immediately agree with you there.

You asked for pros and cons and got just that from 2 who apparently have relevant experience. They shared their thoughts, but I doubt they intend to argue with you.

Originally Posted by Cornix

I dont see why this should be impossible with the Reflection approach.

It's not impossible, just a very bad idea. The most glaring problem is that you are substituting a trivial syntax error for run time exceptions. You are deliberately circumventing the compile time checks to save a few lines of code (which my IDE auto-generates anyway).

The more subtle issue is the nature of reflection. It's a very powerful tool but also a very specific one. It's slow, unpredictable and difficult to test. It breaks encapsulation and doesn't fit in well with the OO paradigm.

Don't get me wrong, Reflection can be awesome in the right places; error logging, serialization, plugins. It's just that I have attempted (and failed) to use it too many times to agree with you on any level. Learn to love Listeners.