Well not really, because SOLID can get bloody complex, but it does maintain some level of sanity.
One of the principles of SOLID is the Single Responsibility Principle
SRP, and recently I ran into exactly why this one can help a lot.
Basically I had a mega function, now for all intents and purposes this function is not going to become any less mega given the single task it needed to perform just inherently consisted of many subtasks.
So I will ignore that, because there is no simplifying it without introducing too much complexity.
What I did do though at first was move quite procedural down and 300 lines later decided that sure I like it but it only works for one implementation.
Now to use it for a similar but slightly different implementation I would need to duplicate and frankly change a fraction of the code to accommodate this different version.
Or I just move core bits into their own methods and obviously just call what I need based on whatever criteria or just have the different methods handle their own control flow and return what I expect without me having to handle the control flow beforehand.
Just pass what it wants and get a result.
This works well enough but the problem and where I realised I am doing too much aka not keeping to "Single Responsibility" in a way that caused me a lot of headache was when I need to catch errors, handle exceptions etc.
Then I think it really clicked for me, and I am no code principles or algorithm fundi so I will likely more ways where I can implement these concepts with a purpose.
It is not always apparent that my code is becoming a problem because in many cases I have quite simple flows, user requests data, I process, I return. Sure there is a lot happening in the back but a lot of the times this is also linear, I don't need recovery and can exit and rerun or throw error.
Simple.
That is why this specific feature forced me to reconsider what has become a bit of a creep in my code, since even though I was creating new methods in the spirit of having a single method deal with a single problem, they were also too complex when it came to handling errors in a very specific fashion.
So just because my method looked lean and mean and I offloaded a lot of the functionality it did not mean my code was not a mess.
Frankly if anything failed it made it hard to hunt down specifically what and where because I was bubbling errors up in an attempt to keep things cleaner, instead of if I caught an error in the function handling it within said function or sending it to a handler dedicated for that class.
Bubbling them up only made me know what error may have occurred but reduced my handling ability purely because the parent does not have access to the same "state" if you will.
Anyway, I am sure this makes no sense aside from to myself , not because it is technical, just because it is not technical in the least, so as always this is but a note to myself.
