aspose file tools*
The moose likes Java in General and the fly likes Overload or not overload Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Overload or not overload" Watch "Overload or not overload" New topic
Author

Overload or not overload

Martin Lira
Ranch Hand

Joined: May 26, 2004
Posts: 97
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
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
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.)


SCJP 1.4 (91%)<br />SCJD 1.4 (376/400, 94%)
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

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.


http://home.arcor.de/hirnstrom/bewerbung
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Martin Lira
Ranch Hand

Joined: May 26, 2004
Posts: 97
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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Robert Konigsberg
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
No wait, I see what you're thinking. Good idea. You're hoping that you can do this:



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:



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



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:



... 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:


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

Joined: May 26, 2004
Posts: 97
Thanks everybody...will be looking forward for the 1.5 version of enums.

//ML
Robert Konigsberg
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
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!
 
 
subject: Overload or not overload