Differences

This shows you the differences between two versions of the page.

Link to this comparison view

it:ad:patterns:solid_srp [2019/03/24 12:02] (current)
Line 1: Line 1:
 +# IT:​AD:​Patterns:​SOLID/​SRP #
  
 +
 +
 +<callout type="​Navigation"​ class="​small">​
 +* [[../​|(UP)]]
 +{{indexmenu>​.#​2|nsort tsort}}
 +
 +
 +</​callout>​
 +
 +
 +<panel title="​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/.
 +
 +
 +</​panel>​
 +
 +
 +## 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.