0

Possible Duplicate:
What does the single responsibility principle mean for validation

Case A: Validate object -> Send to Method -> Method assumes valid object -> Method executes
Case B: Send to Method -> Method checks object validity -> Method executes ONLY IF valid

In case A, I can have the method be responsible for 1 task (execute). However, I may accidentally pass an invalid object. (Of course I can prevent this with careful coding, but this is the heart of my question...)

In case B, the method will never execute on an invalid object, but it must be responsible for not only executing its code but also object validation. Isn't this sort of violating "single responsibility" ?

THANK YOU!

Community
  • 1
  • 1
blitzcrag
  • 21
  • 2
  • 1
    If validation is not obvious (more than 2/3 lines of codes) than I personally prefer to mover it to another method. If validation is shared between different classes methods, then I'd move it to another class. I'd launch application excpetion to signal validation issues. Single Responsibility principle is about classes not methods. – Tony Rad Nov 10 '12 at 04:36
  • In fairness, I prefer to use the SRP to methods also, the code is much more maintainable this way. A method which get stuff from db, updates stats etc does too much. Small methods imply SRP and you want many, clearly defined methods instead of 2-3 behemots. – MikeSW Nov 10 '12 at 09:10

1 Answers1

1

The best coding practice would be

Case C : Objects are valid by construction meaning it is impossible to construct an instance that is not valid, and all methods transition to a valid state when called in a valid state.

In this case, the object itself is responsible for its validity, and any additional checks are just there to fail-fast in case the object is not living up to its guarantees.


For example, with a linked list, you could have passers and receivers checking that the list is well-formed, but there are potentially many of each and so you would necessarily be duplicating work.

If the linked-list is itself responsible for its own validity, so its create/add/remove/concatenate/copy operations all preserve validity, then only one class is involved and that has an easier job since it has privileged access to privates.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • To extract a 'rule' from what Mike said: Objects MUST be ALWAYS in a valid state. Then the methods need only to check for null. For cases when you need to pass primitives (string, integer etc) which have rules, it's best to make them a value object. This will simplify things and will give them a semantic meaning. String can mean everything, but 'Email' says what you need to know about that value – MikeSW Nov 10 '12 at 09:08
  • @MikeSW, and "ALWAYS" means whenever it can be accessed, so in a multi-threaded environment, mutators and accessors for the state being mutated only operate under mutual exclusion, and in a single-threaded environment between calls from instances of other classes. – Mike Samuel Nov 10 '12 at 17:24