Single Responsibility Principle - a practical application

Many times during the lifetime of a project I find myself writing something like this:

method A(){
...
var something = B();
...
}

method B(){
...
var somethingElse = C();
...
}

It doesn't take long to realize that this could be written in a different way:

method A(){
...
var somethingElse = C();
var something = B(somethingElse);
...
}

method B(somethingElse){
...
}

The problem is - which way should I prefer? Which way is "better"? I have struggled with this for a while now.

Today I just realized something: SRP (as applied to methods) says each method should only have one reason to change. (I was reading this article when I had this epiphany.) If something changes in C(), that effect will "ripple" to both B and A in the first case. In the second case, it is much more likely that it will only affect A. Which is fine - it is A's responsibility to "join together" the two other methods, so it's ok if it's affected by them. B, however, has other responsibilities and only needs a result from C() - so it should be isolated from it, as it were.

Somewhat abstract so far :) I will try to add a concrete example to this post the next time I hit this issue. Who knows, I might be wrong :P

Comments

Popular posts from this blog

Posting dynamic Master / Detail forms with Knockout

Comparing Excel files, take two

EF Code First: seeding with foreign keys