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

public class foolist {     public boolean add(foo item) {         int index = indexof(item.getkey());         if (index == -1) {             list.add(item);         }         return index == -1;     } } 

since adds item and returns success value, violate single-responsibility principle? if so, matter?

an alternative throw 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 this, too, violate single-responsiblity principle? seems method has 2 tasks: if item doesn't exist, add it; else, throw exception.

---

bonus question: methods can return null violate single-responsibility principle? here's example:

public class foolist {     public foo getfoo(string key) {         int index = indexof(key);         return (index == -1) ? null : list.get(index);     } } 

is returning either foo or null, depending on situation, "doing 2 things"?

how this:

public class myvector{     private int[] data;     private int count;      public void add(int value){         data[count]=value;         ++count;     } } 

add 2 things - updates data , increments count. according single responsibility rule should have split 2 functions:

public void myvector{     private int[] data;     private int count;      public void add(int value){         data[count]=value;     }     public void inc(){         ++count;     } } 

which - - breaks foundation of oop. want data , count change - that's kind of whole point of bundling them in class!

you won't far if apply rule of single responsibility this. if every method can 1 thing, entire program can 1 thing, , when definition of one thing 1 used in above example you're program can't interesting.

the thing - that's not how single responsibility rule works:

• you shouldn't strive write methods can't defined in way specifies more 1 thing. instead, should write method can meaningfully , sufficiently defined in way specifies 1 thing do.

• you shouldn't define one thing based on implementation - should define based on abstraction of class hosts method.

• this bit controversial: should more strict regarding side-effects , less strict regarding return values. reasoning it's easier user of methods ignore return values ignore side-effects.

• exceptions should never counted "the method doing thing". not part of description of method - exception that, happens if goes wrong. that's whole point of exceptions.

now, let's take @ method. implementation 3 things: checking existence, adding item, , returning success result. if @ abstraction, can define adding item if doesn't exists - , that's 1 thing!

yes, returns something, return values can ignored wouldn't count "another thing". users of method use adding items, can ignore return values if don't need it. if other way around, , using method check existence of items, wouldn't able ignore side-effect of adding item , bad. bad. since "additional thing" return value(or exception) , not side-effect - there's no problem method.

the important design rule not blindly follow design rules.