3 ms·
This sounds like the same discussion I always see about the SRP. I think the root of it is that whether you're following the SRP can always be true, depending o
by bvirb 5y ago
This sounds like the same discussion I always see about the SRP. I think the root of it is that whether you're following the SRP can always be true, depending on how you're looking at your code. If the one thing your code is supposed to do is "run the whole application" then putting everything into one file called "Application" sounds just fine. If the one thing your code is supposed to do is "add 2+2" then abstracting a module that only adds 2+2 seems just fine.
I always found the SRP too vague to be useful for actual decision making, it seems to just lead to arguments where everybody (and nobody) is correct. "Unix philosophy" sounds like it is just about as vague, or am I just really missing something that everyone else gets?
- splittingTimes 5y agoI really liked Dan's reasoning around SRP "SRP mandates that you separate the rendering and business logic of the component. As a developer, having these living in different places leads to an administrative chore of chaining identical fields together. The greater risk is that this may be a premature optimisation preventing a more natural separation of concerns emerging as the codebase grows, and as components emerge that “do one thing well” and that are better suited to the domain model of the problem space."