Anyone got an elegant solution?

[Clarice Doe]

We are building a small testing tool to test an external interface. The external interface exposes some methods. The user has an option to select which method he wants to test (say through a drop down in a web page) and provide the input for the method (say XML) in a text field. When he submits the form, we need to call the selected method with the input value.

Now, I'm not able to get the abstraction right. I don't want to put a big conditional (if-else / switch) block to decide which method has to be called based on the option selected by the user.

Is there any elegant solution for such problems?

[Henry Lowell]

Reflection.

[Frank Carver]

Or a Map and polymorphism

interface Action { ... }

class Thing implements Action { ... }
class Thing2 implements Action { ... }

Map actions = new HashMap();

actions.put("red", new Thing());
actions.put("blue", new Thing2());

String command = //whatever
Action action = actions.get(command);

[Mr. C Lamont Gilbert]

I'll side with Frank on this one. Strategy Pattern is what its called.

[saravanan paramasivan]

I think,Reflection is the best way to do it.

java.lanf.reflect.Class has invoke method,where you can pass the method (Method) as object.If the method is not found in the class,it will throw the MethodFoundException.

[Rahul Mahindrakar]

Hi

Reflection is a good way to do it though I think performance should be checked out.

I am however thinking of Frank's way is a better way as long as the interface is consistent and takes only the xml content as parameter.
[ July 10, 2006: Message edited by: Rahul Mahindrakar ]

[Mr. C Lamont Gilbert]

Reflection is the wrong tool for this job based on the stated requirements. When its required to execute an arbitrary method on an interface not defined before compile time, then you can choose reflection.

[kri shan]

Is it API Testing ? Reflection is the best bet.

[Ilja Preuss]

If the exact set of choices is known at compile time, and doesn't have to change often, I'd probably go for Strategy. Otherwise, reflection probably is the way to go.

But if in doubt, simply try both versions and see which one you like more.

[Pradeep bhatt]

So in Frank's solution there will be one implementation class for each method of the interface.

[Frank Carver]

Commonly there will be, but there's nothing to prevent grouping similar behaviour together - just pass the action name into the instance when it is called, and let it do what's necessary.

Or take a look at the Chain of Responsibility pattern

I used this approach in one system. A single general class handled + - * /, all of which required parsing of two numeric arguments and some basic math. Other, more complex and application specific behaviours got their own classes.

Do whatever makes the code simplest.

[Mr. C Lamont Gilbert]

Originally posted by Pradip Bhat:
So in Frank's solution there will be one implementation class for each method of the interface.

Yes. You can use an if-else chain if there are not many methods. Or even a 'case statement' with some identifier for each method. If it gets long then I would switch to the strategy pattern which would make call time similar for each method.

[kri shan]

Is it API Test Harness Framework ?