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

[Matthew Busse]

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

        if (queryProfile.hasExactMactches()){
			queryOrMatch = "match";
			ArrayList<STRProfile> exactMacthes = queryProfile.getExactMatches();
			for (STRProfile matchProfile: exactMacthes){
				this.writeProfileAndMatches(matchesSheet, matchProfile, nextRowCount, queryOrMatch);
				nextRowCount++;
			}
		}

I could also image doing something like

    ArrayList<STRProfile> exactMatches = queryProfile.getExactMactches()
	if (exactMatches != null){
		queryOrMatch = "match";
		for (STRProfile matchProfile: exactMacthes){
			this.writeProfileAndMatches(matchesSheet, matchProfile, nextRowCount, queryOrMatch);
			nextRowCount++;
		}
	}

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

Thanks!

[Joanne Neal]

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]

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]

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

List<String> exactMatches = new ArrayList<String>

instead of

ArrayList<String> exactMatches = new ArrayList<String>

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]

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]

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]

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.