How small a concern should be?

[wli3]

I am not sure this is the right place, should I move it to email?

I realized a problem when I am writing a comment at #4

For data flow alone we can chop it down to much smaller pieces
Write 1. Validation 2. Concurrency
Read 3. get data into correct data structure 4. format to human readable 5. performance of read caching

However, given the subject code is about 20 lines in total, we can end up with 5 class and each of them has 4 lines.

So the problem is -- how small is too small?

[ericgu]

A general note here...

When you start talking about validation, concurrency, and performance, you are adding things to the exercise that aren't there. I believe strongly in YAGNI, and many of the code abominations come from building things that you don't really need.
WRT your particular question, it's a matter of taste. If you do database design, you typically start with something that looks like a spreadsheet and start normalizing it. There is a such a thing as a fully-normalized design, but everybody hates it because it has too many entities and is too complex.
The same is true with class design.
I don't have a general rule I can talk about, but I do see many examples of concerns that are too big (ie missing abstractions), and a few examples of excessively small concerns. The latter are less common but represent more technical debt because they are more impactful and harder to change.
So, you raised a great question, and let's keep it in mind when we discuss the individual issues.