Do "return success" methods violate the single responsibility principle? - oop

Question

public class FooList {
public boolean add(Foo item) {
int index = indexOf(item.getKey());
if (index == -1) {
list.add(item);
}
return index == -1;
}
}
Since this adds an item and returns a success value, does it violate the single-responsibility principle? If so, does it matter?
An alternative would be to throw an exception:
public class FooList {
public boolean add(Foo item) throws FooAlreadyExistsException {
int index = indexOf(item.getKey());
if (index == -1) {
list.add(item);
} else {
throw new FooAlreadyExistsException();
}
}
}
But would this, too, violate the single-responsiblity principle? It seems that the method has two tasks: if the item doesn't exist, add it; else, throw an exception.
Bonus question: Do methods that can return null violate the single-responsibility principle? Here's an example:
public class FooList {
public Foo getFoo(String key) {
int index = indexOf(key);
return (index == -1) ? null : list.get(index);
}
}
Is returning either a Foo or null, depending on the situation, "doing two things"?

Answer 1

How about this:
public class MyVector{
private int[] data;
private int count;
public void add(int value){
data[count]=value;
++count;
}
}
add does two things - it updates data and increments count. According to the single responsibility rule I should have split it into two functions:
public void MyVector{
private int[] data;
private int count;
public void add(int value){
data[count]=value;
}
public void inc(){
++count;
}
}
which - obviously - breaks the very foundation of OOP. I want data and count to change together - that's kind of the whole point of bundling them together in a class!
You won't get very far if you apply the rule of single responsibility like this. If every method can only do one thing, then the entire program can only do one thing, and when the definition of one thing is like the one used in the above example you're program can't do anything interesting.
The thing is - that's not how the single responsibility rule works:
You shouldn't strive to write methods that can't be defined in a way that specifies more than one thing. Instead, you should write method that can be meaningfully and sufficiently defined in a way that specifies one only thing that they do.
You shouldn't define one thing based on implementation - you should define it based on the abstraction of the class that hosts the method.
This will be a bit controversial: You should be more strict regarding side-effects and less strict regarding return values. The reasoning is that it's easier for the user of your methods to ignore return values than to ignore side-effects.
Exceptions should never be counted as "the method is doing another thing". They are not part of the description of what the method does - they are exception to that, that only happens if something goes wrong. That's the whole point of exceptions.
Now, let's take a look at your method. The implementation is three things: checking for existence, adding the item, and returning the success result. But if you look at the abstraction, you can define it as adding an item if it doesn't exists - and that's one thing!
Yes, it also returns something, but return values can easily be ignored so I wouldn't count it as "another thing". Users of the method will use it for adding items, so they can ignore the return values if they don't need it. If it was the other way around, and they were using your method to check for existence of items, they wouldn't be able to ignore the side-effect of adding the item and that would be bad. Very bad. But since the "additional thing" is the return value(or exception) and not the side-effect - there's no problem with your method.
The most important design rule is to not blindly follow design rules.