A single principle of responsibility: the granularity of the cause of change

Question

When applying the principle of Single Responsibility and studying the causes of a class to change, how do you determine if this reason is too important, too big or not enough granular?

Answer 1

I do not know that there is a good answer to this question, other than "apply your opinion based on your experience." If this does not work, get help, which I think you are doing here;)

Seriously, however, if you find yourself creating gazillion classes to do what seems like a simple job, then you are probably too granular. If your classes seem short, then you are probably too rude. Please forgive me if this expression is obvious.

I think this is one of those fuzzy, non-hard rules that show us why human programmers are needed. Just try something, look for balance and refactoring if you find that you go too far in one direction. And remember: if it's worth it, it's worth doing badly .

Answer 2

• I would not worry too much about detailing initially. First, I just share the concerns at a wider level. The main point is that we should avoid over-engineering here. But enough. I agree with Lucas here that this first step will improve with experience.
• As requirements change, as I begin to get “smells,” as my understanding of the problem improves, I would reorganize the design, diverting individual problems as they arise. In principle, the division of attention will also be evolutionary, as with general design.