Coffee mug reflections part 2 – Method objects

I’d like to spend a few words about Method object for many reasons. First, they’re cool. Second, if you come from the C/C++ world, you might have had the feeling that something was missing: function pointers.

In C/C++ function pointers are extremely handy tools to do lots of nasty stuff, and I must admit, before this was available in Java, I felt like something was missing.
Method objects are slightly different from function pointers and what I can say is… they’re way cooler. But before we have a look at how to use it, let’s proceed my way.

***Add on 2009/03/12 – thanks to Walter Milner***
What exactly is a Method object?
When you write a method, you rarely stop thinking about what exactly is the act of writing one. You’re writing a procedure that can freely interact with the object it’s enclosed in. In the method body you (and the compiler) make some some assuptions like:
when you write a=10; the compiler assumes that a is accessible from the method and that it’s a int. That’s obvious to you, but you shouldn’t ignore the importance of this fact. If a is private, nothing but the class methods are able to access its value. So your method is privileged.
A method object is an object that can trigger a method, knowing the class in which it’s defined, its name, and its parameters (in other words, its signature). The method can be static -and in this case it has no reference class- or not, and in this case you have to tell the method what class it’ll be reflecting on. If the method object changes the value of the class field a, you must let it know which object you want to alter.
Example:

class Stuff{
  private Integer a;
  public void setA(Integer val){
      a=val;
   }
}
//[...]
//...main...
Stuff first = new Stuff();
Stuff second = new Stuff();
//here's my reference
Method m = Stuff.class.getMethod("setA",Integer.class);
//I apply it to second
m.invoke(second,10);
//guess what's the value of a in second object...

***

Why the heck would I ever need them?
I can agree with you in some ways. There are very few things you can’t do in Java without them. One of them is the example we’ve seen in the previous chapter of this series. In that occasion we’ve used methods we didn’t even know they were there.
Another interesting setup is: method objects gives us a very fluent way to run methods or sequences of methods we choose runtime. Want an example of this? Say, image processing. A BufferedImage and a stack of things to do to it, build by a configuration file? You can do it traditionally? Alright, imagine now that everyone can produce a filter class ( extends ?) with only two rules: (1) each filterng method gets at least a BufferedImage and returns a BufferedImage (transformed); (2) every extra parameter is a java.lang type. This is getting a little tricky. Now, I agree with you this example is way too extreme, but see how the boundries of things you can do, change dramatically with this technique in your hands?