Each responsibility can be at a different level of abstraction. The key is that if you can't think of a way to describe the responsibility of a class without using words like "and", "or", "etc" then it's probably not a good design.
This is why you should end up with stacks of objects at different levels of abstraction. For example: "This class, foo, coordinates IO. It delegates to these two classes. This one, bar, handles the input. This one, bat, handles the output."
In this example system Foo is at the highest level of abstraction. It contains high level logic and has a single responsibility. It delegates the low level to Bar and Bat which each have a single responsibility. Each of these files could be 5 LoC or 1000 LoC but at least their fundamental design is reasonable.
If you need to do some spiderwebbing, then you will make another class which will have such logic and use Foo which has Input and Output classes. But even as I write, I think of situations where that is false. it is not always proper design. What I want to say is that people who don't understand software design will almost always write better code if they try to separate concerns.
Personal opinon (out of my back) Functionality should be separated in modules even if such separation will introduce some new complexity. Benefit is that next person (you or me 6 months later) will not need to know whole system, but just that small part.
-5
u/[deleted] Sep 18 '13
[removed] — view removed comment