IT:AD:Patterns:SOLID/SRP
Summary
For software to be inexpensively a) maintable, b) enhanceable, it has to be simple enough to be understood by everyone on the team (not only the person who wrote it…) as well as modifyable in a riskless way (changes to one section of the code doesn't cause the app to break somewhere).
The secret to writing non-brittle code, is to not make it complex.
Easier said than done.
But one pattern that has worked over and over again through the years is to write code that is highly cohesive…which is just a fancy term for /keep it simple: do one thing only/.
Benefits
* Small classes, versus God Classes.
- * Small classes mean more understandable, manageable, code.
* Then again, even if more manageable, usually not needed to go back and tinker, because another a side effect of working on one ploblem at a time is that once working, there is no need to go back to the problem unless the definition of the problem changes.
Process
Learning how to break code up into small units of work involves knowing how to define problem boundaries. One trick is to stop asking what the class /is/ (it's a invoice webpage), and instead start asking what it /does/.
And What?!?!
If the answer uses the word and, (it authenticates the user, and then authorizes the person, and then renders the invoices due)then it's doing 2 or more things and needs to be broken down.
In many ways, untangling the page leads to the page becoming thinner, moving code into smaller external stateless services, and ends up just being an orchestrator or other services.