• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Overload or not overload

 
Martin Lira
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everybody...will be looking forward for the 1.5 version of enums.

//ML
 
Robert Konigsberg
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic