Overload or not overload

[Martin Lira]

According to Bruce Eckel's Thinking in Java, Java programming guidelines
No 21: Watch for overloading. A method should not conditionally execute code based on the value of an argument. In this case, you should create two or more overloaded methods instead.
My problem:
I have a method in a Java Bean that uses PreparedStatement to executeQuery(sql). The sql depends on one of the arguments to the method. Do I need to overload the method just because my sql is little different. It will be unnecessary repetition. But then what about Bruce's advice on this........

[Robert Konigsberg]

How is your SQL different? Overloading is best with parameter types, as opposed to functionality differences. If you've got different functionality, consider a different method name, or a parameter that indicates what type of functionality (either a boolean flag, or better yet, an integral flag.)

[Stefan Wagner]

You may extract the common parts from both methods, and call them without duplicating your code.

But I wouldn't take the advice too dogmatic. If differences are minor, I would perhaps ignore it.
Shall we avoid using 'if'-statements for parameters???
I don't think so.

[Ilja Preuss]

Originally posted by Stefan Wagner:
Shall we avoid using 'if'-statements for parameters???

It depends. I'd had to see the code to be able to decide.

[Martin Lira]

The only difference is in the where clause depending on the method argument.
Ex.
public myMethod(int arg){
String sql = "select * from table ";
if(arg ==1)
sql += "where name = ?";
if(arg ==2)
sql += "where name = ? and city = 'DALLAS'";
if(arg ==3)
sql += "where name = ? and state = 'TEXAS'";
}

Thanks!
ML

[Stan James]

You won't be able to apply overloading to that one. You'd have to distinguish two method signatures by different parameter types, not just their values. If you find yourself testing "instanceof" ask yourself if their isn't a polymorphic solution. Or ask us.

[Robert Konigsberg]

No wait, I see what you're thinking. Good idea. You're hoping that you can do this:

doQuery(String name);                            // #1
doQuery(String name, String city);               // #2
doQuery(String name, String state);              // #3
doQuery(String name, String city, String state); // #4

The problem is that city and state are strings. Your theory is OK except you can't tell the difference between #2 and #3. One of the ways you can handle this is:

doQuery(String name);
doQuery(String name, City city);
doQuery(String name, State state);
doQuery(String name, City city, State state);

Now the trouble here, is how do you define City and State? Here's a possible definition for State:

public final class State
{
    setState(String state) { ... }
    public static boolean isValidState(String state) {...}
    public static final String[] STATES = {"AR", "AZ", "CO", "CT" ...}
}

NOTE: Now is a REALLY GOOD TIME to take a peek at Java 1.5 Enumerated types, which would handle just this sort of problem: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Now you get:

doQuery(String name);
doQuery(String name, String city);
doQuery(String name, State state);
doQuery(String name, String city, State state);

... which would work! Would you encapsulate City into a String? Naw, I don't think that's such a great idea. A City class wouldn't provide any additional knowledge, it's just a way to encapsulate. You're going down a slippery slope here. What if you want to add Zip Code? What about Zip Code, First Name, Last Name, Middle Name, Zip Code Extension, Suffix ("Jr.", "Sr."), Title("Mr.", "Ms.", "Mrs.", "Dr.") and so forth?

Naw, if you want to handle that type of genericity, I'd suggest you do this:

public String getSql(Map parameters)
{
 ...
}

I'll leave it to you to write getSql... but I'll give you a hint by showing how I would use it:

Map params = new HashMap();
params.put("name", "Smith");
params.put("title", "Dr.");
params.put("state", "TX");
String sql = getSql(params);

[Martin Lira]

Thanks everybody...will be looking forward for the 1.5 version of enums.

//ML

[Robert Konigsberg]

Martin, I was a little unclear. Enums in 1.5 only makes creating (in my example) the State class much simpler. But it doesn't solve your particular problem. But yes, 1.5 is going to really make some waves. I know many folks that are still using 1.3 and I feel bad for them still!