• Post Reply Bookmark Topic Watch Topic
  • New Topic

Better to write a "has" method or check for null result  RSS feed

 
Matthew Busse
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Java Ranchers,

I have stylistic/design patterns question.

If class A needs to get an object from class B, and class B may or may not have that object, is it better to write a separate method that first checks if class B has that object, then gets it, or is it better to write one get method, and first check if the get result is null?

For example, in this case, I have a separate "has" method


I could also image doing something like


The second option only calls one method on the queryProfile object, is that going to be more efficient?

Thanks!
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd go for option 3 - make your getExactMatches() method return an empty List if there are no matches. Your for loop will then loop zero times.
 
Paul Clapham
Sheriff
Posts: 22813
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your third option is to just return an empty List when there are no exact matches. That's what I would be likely to do in this case; the caller of the message can easily look at the List to see whether it's empty or not. I wouldn't return null to signify the fact that the list would have been empty, that just gives the caller more work to do. And it's also wrong in the sense the null is not the same as zero.

I also wouldn't declare my getExactMatches method to return an ArrayList, as you appear to have done. I would declare it to return a List. The method could return an ArrayList if it liked, or some other kind of list too, if I did that. That would allow my getExactMatches method to return Collections.emptyList() if I wanted it to work that way.

As a general rule you should declare your variables at the highest level of the inheritance hierarchy which makes sense. Obviously declaring the "exactMatches" variable as an Object is too far up in the inheritance hierarchy -- you do want to treat it as a list of STRProfile objects -- but ArrayList is too far down. List is about right. The other way to say this general rule is "Program to the interface, not to the implementation".
 
Matthew Busse
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
As a general rule you should declare your variables at the highest level of the inheritance hierarchy which makes sense. Obviously declaring the "exactMatches" variable as an Object is too far up in the inheritance hierarchy -- you do want to treat it as a list of STRProfile objects -- but ArrayList is too far down. List is about right. The other way to say this general rule is "Program to the interface, not to the implementation".


Thank you very much for the responses. Would you mind explaining this point a little more? I see this in code quite frequently, and I've never fully understood while it's better to do
instead of


I don't understand why it's better to declare variables at the highest level of the inheritance hierarchy...

Any explanation would be greatly appreciated!

Thanks!
 
Paul Clapham
Sheriff
Posts: 22813
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's like I already said. You might want your matches to be stored in some other kind of list in some circumstances. For example you might want to use whatever Collections.emptyList() returns -- I don't know what exactly that is, but I know it's a List, and that's all I need to know. There's no reason to lock yourself into having to use an ArrayList for everyhing.
 
Brian Burress
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By declaring and coding to the interface such as List, you will be able to swap the implementation to something else without having to change any other code (ex: change ArrayList to LinkedList). By declaring the variable as 'List' you will only be able to access methods declared by the List interface and as such not use something that may be unique to ArrayList such as the reference I made to clone on your other post. As was pointed out, clone is not declared in List so if you called clone, you'd have to refactor the code in order to swap to another implementation of List.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
I also wouldn't declare my getExactMatches method to return an ArrayList, as you appear to have done. I would declare it to return a List. The method could return an ArrayList if it liked, or some other kind of list too, if I did that. That would allow my getExactMatches method to return Collections.emptyList() if I wanted it to work that way.

As a general rule you should declare your variables at the highest level of the inheritance hierarchy which makes sense. Obviously declaring the "exactMatches" variable as an Object is too far up in the inheritance hierarchy -- you do want to treat it as a list of STRProfile objects -- but ArrayList is too far down. List is about right. The other way to say this general rule is "Program to the interface, not to the implementation".


And if you don't need to make any promises to your callers about ordering or whether or not duplicates are allowed, you could declare it to return Collection. Not saying that is or is not appropriate here. Just another option on the "how specific should I be?" spectrum.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!