Solid Principles Misconceptions

i was watching a lot of content about software architecture recently and if i'm being honest i came away a bit more confused than when i started i think a lot of the discussion around this topic is fundamentally misunderstanding the kind of point the central themes of software architecture so instead of another confusing example let's take a look at something practical and step through it here is the sample script that we're going to use now the specifics of this code don't matter try not to focus on the literal changes i'm making and focus on the philosophy behind why i'm making them this is very important so i'll say it again don't focus on the lines of

code focus on the decision making behind it right so first let's look at what this script does performs a raycast and if it hits something and i click the mouse it'll spawn a tree nothing too crazy let's have a deeper look at the code so what's wrong with this code well nothing it works perfectly fine and that's our first point software architecture is not concerned with making your code work your code should already work if it's not for making your code work though then what is it for well imagine you're working for someone else and you make them this script and they come back with some feedback something like this hey bro thanks for the

script it works wonderfully i did notice it spams the console with log messages that's great for debugging but i'd love a way to turn them off and on thank you jason my boy pretty simple request pretty representative of the kind of thing that would happen in a normal project a change request now this is the single most important word here change from this point on i want you to look at this code with that word in mind change so our task is to be able to toggle the messages now being expert programmers that we are we know it's just a simple boolean flag and an if statement you know what the request is and we

know how to write it with all that in mind how much do we have to change this script no sorry i don't have any change add that feature well it looks to me like five places one for each debug block and five isn't that bad but again we're not looking at the lines of code we're looking at the philosophy of the code what this is really saying is that in order to make this change i don't have any change the amount of work it will take to fix it is directly proportional to the number of log messages in the class so it's three this time but it could have been 300.

now let's go back in time and make an alternate version of that script now it's pretty similar the only real difference is we have this log method down at the bottom so let's revisit our request how many changes do we have to make to this script to add that feature i just gave you a change one right and it doesn't matter if there's one log 10 logs or 10 000 logs so a seemingly small design decision in advance took a future change down from an unknown amount of time affecting a large and unknown amount of code to a predictable single location and a single change that is the point of software architecture to support change

let's say everybody loves that boolean change so much that you've added it to every single other script that's going fine until you get another change request okay i love the fact that we can now individually change the scripts uh that is great but we have a lot of scripts in the project and um toggling them off individually one at a time is kind of cumbersome so i was just thinking is there a way that we could maybe add a group toggling feature that would be pretty useful thanks so we now need a way to not only show log messages from one class but to toggle on and off messages from certain classes so how much

change is that going to be well it seems to me that it's going to affect every single class we've written it's directly proportional to how many scripts we have in our project well why is that every single script is making its own decisions about logging so at a minimum it's doing two things what it normally does and then it decides what to do with login so let's go and rewind time again and start from a different starting point even before the original boolean checkbox this time around we've got something called a logger and we're handing it to our item painter and that is doing the logging for us everything else is exactly the same so

let's redo our original request there we go one change now how about our much bigger new change across our entire application how many changes do we have to make to allow us to control which logs get turned on and off and who logs them well what if i did this instead and created a bunch of separate loggers now i can just hand a different logger to a different object and toggle on or off the groups so no changes we've gone from having to possibly edit every single script in our application to writing no code at all and that is the point of software architecture so as a final note on this subject i read a

lot of articles that talk about how the solid principles are not relevant anymore well now that we've broken down the point of software architecture and we now understand the conversation more let's revisit them the single responsibility principle a class should have only one reason to change well did you notice that the reason we potentially had so much work ahead of us with the second request was because the item painter was responsible for two things painting and logging now it seems to me like pretty good advice to say that if a class was not responsible for logging like in our later example we wouldn't have had this problem in the first place so this is what

the single responsibility principle is really saying it's not about 50 tiny interfaces or other complex nonsense it's simply saying that the reason logging will change are different than the reason the painter will change so changing locking over here should not affect painting over here they're unrelated responsibilities okay so what about this one the open closed principle software should be open for extension but closed for modification what does that even really mean well in our first example we had a change to make and in order to change that we had to rewrite parts of the code we had to modify its contents in our second example in order to change the behavior of the item painter

we actually didn't have to open the item painter at all we could just change the logger so it was open for extension for changing the behavior but it was closed for rewriting we couldn't change the code the advice here is that your life will be easier if you design your code such that you can add new behavior without modifying the contents seems like good advice to me and if you want another example here i am adding a prefix label to all of the logs in our item painter and i don't have to even touch the item painter class because it's closed for modification but i'm still able to extend its behavior because i'm changing which

logger and how the logger is working right i think we'll call it there i think you get the point if you hear people talking about the death of the solid principles or anything like that ask yourself if they have discussed change at all have they really talked about what the principles are really about problems they are trying to solve i hope you found that helpful if you did please feel free to drop a like and a comment you can also support me over on kofi and if you do you'll get access to the private discord so catch you on the next one