Single responsiblity principle: granularity of the reason to change

Question

When applying the Single Responsibility Principle and looking at a class's reason to change, how do you determine whether that reason too change is too granular, or not granular enough?

Answer 1

Added for reference:http://en.wikipedia.org/wiki/Single_responsibility_principle

Answer 2

I don't know that there's a good answer to this one other than "apply your judgement, based on your experience." Failing that, get help, which I guess is what you're doing here ;)

Seriously, though, if you find that you're creating a gazillion classes to do what seems like a simple job, then you're probably being too granular. If your classes all seem collossal, then you're probably being too coarse. Please pardon me if that's a statement of the obvious.

I think this is one of those fuzzy, no-hard-and-fast-rules cases that show us why we need human programmers. Just try something, seeking balance, and refactor if you find you're going too far in one direction or the other. And remember: if it's worth doing, it's worth doing badly.

Answer 3

See also Robert Martin's excellent article.

Answer 4

1. I wouldn't be too worried about granularity initially. I will just go with separation of concern at a broader level initially. Basic point is that we should avoid over-engineering here. But just enough. I agree with Lucas here, that this first step will improve with experience.
2. As the requirements change, as I am starting to get the 'smells', as my understanding of the problem improves I would refactor the design by factoring out the separate concerns as they become obvious. Basically separation of concern shall also be evolutionary as with overall design.