Java Anonymous Class as Utility Functions ? To design Arguments that are actually used, or one Argument (the bigger obj)

Question

The Situation is that I have to use Function pointers for so many functions in Java (so I did it this way) and saved each anonymous class to a static variable of the Interface, so that I could use them directly.

 /** The Constant HARDLIM. */
    public static final TransferePatternable HARDLIM =
    new TransferePatternable() {
        public DoubleMatrix transfere(DoubleMatrix netSum, double theta) {
        return netSum.gt(theta);
        }
        public String getFuncName() {
        return "HARDLIM";
        }
    };

But the problem is that sometimes I don't need to provide the Theta so if I remove it the polymorphism won't work, (2 Functions out of 10 don't need theta) so I had to put it (Function declaration conventions now ugly) so I thought of passing the whole Object which actually contains both netsum and theta.

But I'm starting to worry, cause it's also going to ruin what this function really is for. So at last I suggested I put these function separately (non anonymous) and then make anonymous functions use them but the argument would be the object. Like the following:

 /** The Constant HARDLIM. */
    public static final TransferePatternable HARDLIM =
    new TransferePatternable() {
        public DoubleMatrix transfere(MyObject obj) {
        return MyObjectUtilFun.hardlim(obj.getNetsum,obj.getTheta);
        }
        public String getFuncName() {
        return "HARDLIM";
        }
    };

So Am I taking the right steps ? or I'm messing around, Please guide me!

Answer 1

Do you really need the instance to be public static final? If you can instantiate the instance wherever you have a reference to theta, then your anonymous class can use that theta reference. For example:

final double theta = 123d;
class TransferePatternable {
    public String transfere(String whatever) {
        return whatever + theta;
    }
}
TransferePatternable myInstance = new TransferePatternable();
myInstance.transfere("arg");

Alternatively you can specify the input as a generic type such that your MyObject need not be a superset of all possible inputs, but rather can differ by TransferePatternable type. Obviously the drawback here is that you need to know what type you're calling in order to provide the right input, but you sort of need to know this anyway if you don't want to provide theta in some situations.

Finally, another common solution to this problem is to replace ALL method parameters with just one Map. Then, you can pass in whatever you want! This has lots of obvious drawbacks, but lots of APIs do exactly this, and generally you'll see them refer to the map as the "context". Here are a few examples:

• javax.servlet .ServletRequests store parameters in a Map
• AOP has the javax.interceptor.InvocationContext class
• Spring's IoC container basically is a big Map of named javabeans
• The JSP Expression Language allows you to refer to Implicit Objects that basically are stored in several Maps

I myself have used this Map solution when implementing an Excel-like formula language in java years ago. Such a formula can be parsed into functions and variables, and when executing the function we provided a Map containing the variables keyed by variable name. Obviously you still need to know something about what you're invoking, and in fact we always did know enough about the formula that providing the right inputs in a Map was easy. But again I have to caution you: this sort of code is fairly hard to implement and maintain. Unless you anticipate growing a large set of functions over time, don't go down this route. It's not OO-friendly, and it should be a last resort.

Answer 2

If MyObject is a generally used interface or class and TransferePatternable is not expected to work with anything else, your second idea is best. It opens up the possibilities of a TransferePatternable being able to work with more than just netSum and theta and gets rid of the unneeded theta. My guess is that this is what you want to do, even if it means expanding the capabilities and scope and importance of the MyObject class/interface.

But you are restricting a TransferePatternable to working with a MyObject instance. The unused theta is a problem, but it's a small price to pay for the power of polymorphism (and its a lot simpler and neater than most other solutions). If the MyObject solution doesn't look perfect to you, stick with the unused theta. My guess is a good idea will come along sooner or later, with no harm done if it doesn't.

Answer 3

Is there any reason you can't have an overloaded "transfere" function in the HARDLIM?

/** The Constant HARDLIM. */
public static final TransferePatternable HARDLIM =
new TransferePatternable() {
    public DoubleMatrix transfere(DoubleMatrix netSum, double theta) {
    return netSum.gt(theta);
    }
    public DoubleMatrix transfere(DoubleMatrix netSum) {
    return netSum.whateverYouNeedToDoWithoutTheta();
    }
    public String getFuncName() {
    return "HARDLIM";
    }
};

Answer 4

At the end I used The second choice but with some notes in mind:

1. To always have functions (i.e Hardlim) defined independently in utility classes.
2. To state in Javadocs what this variable really is and the utility function being used.

3. I also found the price of confusing users with unnecessary arguments to be high cause the application is already complex no need to be more complicated.

   public static final TransferePatternable HARDLIM =
   new TransferePatternable() {
       public DoubleMatrix transfere(MyObject obj) {
       return MyObjectUtilFun.hardlim(obj.getNetsum,obj.getTheta);
       }
       public String getFuncName() {
       return "HARDLIM";
       }
   };