I think the problem is with SOLID that it assumes that perfect software can be created from scratch using these few vary simple and basic principles. Which is of course not the case, actually far from it! In reality, optimizing code and some of its qualities is a highly iterative process, and the optimization principles lies in the way that these iterations are done, the main point being what to optimize and when. You do not start writing code by optimizing, and you do not write optimized code from scratch. What needs to be de-coupling is actually the coding from the optimization. First you code to create solution, than if your solution survives and lives in a longer term than you start optimistic, and you only optimize what is practical as it is a very time consuming and resource hungry process. Good experienced developer knows that it is never a good idea to mix coding with optimization and when it comes to coding the outcome that matters is working code, not optimized code, so it does not matter if it is extensible or re-usable until this point. I think there is a more important rule that says "early optimization is the root of evil" and SOLID goes again this very old and essential rule, as it tries to suggest early optimization that is often not needed and even outright harmful. From these examples here you can also see how these optimizations result in much more code lines than it needed for a simple solution. So SOLID result in more verbose, therefore more complex code even if it is not necessarily needed. Creating and optimizing code needs much more than written down in these few principles and that knowledge only comes with experience in building lot of software. This is another mistake in SOLID that it tries to suggest that you can create optimal software without lot of experience just by following these few simple rules which is a huge error. Do not misunderstand me these are good principles but what is more important to understand the process to create good software which is a iterative process, and it depends on the life cycle of the code what optimization is needed. So in some stage - for example in a very early one - it is not even a good idea to follow these principles as it would result in unneeded early optimization creating over-complicated verbose code for a simple task. So all-in-all whoever put these principles down lacked the real experience to understand that the problem he is dealing with more complex than he thought. Creating optimal code is not a one step process sing some simple principles, it is all about what to do in what stage of the software and it is much more complex than these few simple principles. Lot of the time there is absolutely no problem at all with a simple and not over-optimized code even if it goes against SOLID, as in different life cycle of the code there are different priorities. E.g. simplicity in an early stage, starting solution is much more important than extensibility Related to single responsibility, sometimes it is better to have one function / class that does everything - especially if it is a lot - than splitting it up into to countless classes making your code longer, more complex and understand. also some rules that not in SOLID: only create re-usable code if you are sure you are going to re-use it, otherwise it is a waste of time. Only create extensible class if you are sure it is needed, and you are going to extend it, otherwise it is a waste of time, resources and also make your code longer and more complex than it is needed. Only beginners think that only by using SOLID principles you need to create optimal code from scratch in one huge step regardless if you need that or not. Only beginners think that you need to make your code following all these principles in the first step even if it is just a few simple function, making it re-usable and extensible just in case... Even without being sure that it will be ever re-used and / or extended. So in itself these simple examples that you can see everywhere related to SOLID principles are wrong, as these principles most of the time only come in to sight when you are dealing with huge software with a need of refactoring so the examples should reflect this fact. Illustrating SOLID principles with these simple examples suggest to beginners that they have to over optimize every software even with only 10 lines of code from day one, and unfortunately you can even see this happening everywhere in the industry by beginners in reality everywhere, and they think this how you create "good" code which is ridiculous. Solid principles must only come in the picture in relation of refacturing bigger code bas, but in that case there are much more to follow than these few simple rules, and to know the rest only comes with experience and you need to familiarize yourself with much bigger amount of terminologies from more serious authors. I think the main error in SOLID and the way it is represented that it actually tries to suggest that you need to mix coding with optimization even from the start, suggesting that optimization is as much, if not more, important than working code in the phase of coding when creating a working solution comes first. code optimization in terms of code quality must be a seaprate process from coding phase! These two should not be mixed and should represent different phase of the development cycle. Lot of companies misunderstand and do not know these basic principles and enforce developers to create high quality optimized working code from scratch, which is actually not even possible, not even using these few simple SOLID principles of course. When companies do this, then this is all about saving money and nothing else, and actually this is one of SOLID great error not to be clear on that point so that their principles can not be misrepresented by this way. I am not even sure that whoever created SOLID principles did not only created it to convince beginner developers to mix coding and optimization phasing into one single phase, which is wrong and all about just saving money for software companies by spending less time and money on development and actually creating worst software by using un-needed early optimization "just in case". It is like saying to the develpper: "I am paying so do everything at once for my money..." Unfortunately in practice I can see SOLID interpreted this way actually enforcing really bad practices on developers. The other thing is that only using SOLID principles does not make your code that much better as you need to know much more than these simple basic principles to create real good quality code. So this is another very bad aspect of SOLID as it tries to make it beleive that these few simple principles that you need to know and that is it, voila you have the optimal code. :-(
Tech, Product, Money, Books, Life. Box Piper to serve you faster, easier and superior knowledge.
Support my work and buy me a coffee. It'll mean the world to me. https://ko-fi.com/boxpiper
Thanks for your amazing analysis. It really blew apart lot of things.
Indeed you are correct, agreeable to lot of points, and thanks for taking time out to explain it so beautifully.
I did mention elephant in the room by saying:
SOLID is a guideline and not a rule. It is important to understand the crux of it and incorporate it with a crisp judgement. There can be a case when only few principles out of all is required.
What frustrates the most in SOLID principles that it instills a sense of inferiority in seasoned developers. It suggest that it is very little that you need to master to be able to write good software. It is the opposite, you need to know much much more that only comes with a lot of years of experience and you need to learn from sources really different from people who wrote SOLID. Also if I think about these SOLID principles more, I can come up with a tons of examples that contradict every one of them! So whoever writes principles like these should make sure that at least they are much more SOLID than SOLID! For example if I have 100 things to do then I just have to create 100 different functions, just to make sure every single function does only 1 single thing??? WRONG! Truth is you have to split your 100 things into categories and implement as many functions as categories. This is called separation of concerns. To do this right you need a lot of experience and maybe the right education. How many functions you need is a trade off between so many things. Efficiency, performance, productivity, simplicity, maintainability, extensibility etc.. It is far from an easy task and you hardly ever end up with 100 functions doing 1 single thing each. So there is no such thing as "single responsibility principle", most functions in a real world application have multiple responsibility. In SOLID they oversimplify things, and instead of saying that you need to separate concerns and decide between trade offs that takes a lot of experience, they say just create as many functions as things you do, and voila you do not need experience, you need no proper education in the field and just knowing these 5 single "principle" you end up with the optimal software. So who needs experienced, educated developers anymore? This can't be further from the truth. It is actually just plain stupidity.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the problem is with SOLID that it assumes that perfect software can be created from scratch using these few vary simple and basic principles. Which is of course not the case, actually far from it! In reality, optimizing code and some of its qualities is a highly iterative process, and the optimization principles lies in the way that these iterations are done, the main point being what to optimize and when. You do not start writing code by optimizing, and you do not write optimized code from scratch. What needs to be de-coupling is actually the coding from the optimization. First you code to create solution, than if your solution survives and lives in a longer term than you start optimistic, and you only optimize what is practical as it is a very time consuming and resource hungry process. Good experienced developer knows that it is never a good idea to mix coding with optimization and when it comes to coding the outcome that matters is working code, not optimized code, so it does not matter if it is extensible or re-usable until this point. I think there is a more important rule that says "early optimization is the root of evil" and SOLID goes again this very old and essential rule, as it tries to suggest early optimization that is often not needed and even outright harmful. From these examples here you can also see how these optimizations result in much more code lines than it needed for a simple solution. So SOLID result in more verbose, therefore more complex code even if it is not necessarily needed. Creating and optimizing code needs much more than written down in these few principles and that knowledge only comes with experience in building lot of software. This is another mistake in SOLID that it tries to suggest that you can create optimal software without lot of experience just by following these few simple rules which is a huge error. Do not misunderstand me these are good principles but what is more important to understand the process to create good software which is a iterative process, and it depends on the life cycle of the code what optimization is needed. So in some stage - for example in a very early one - it is not even a good idea to follow these principles as it would result in unneeded early optimization creating over-complicated verbose code for a simple task. So all-in-all whoever put these principles down lacked the real experience to understand that the problem he is dealing with more complex than he thought. Creating optimal code is not a one step process sing some simple principles, it is all about what to do in what stage of the software and it is much more complex than these few simple principles. Lot of the time there is absolutely no problem at all with a simple and not over-optimized code even if it goes against SOLID, as in different life cycle of the code there are different priorities. E.g. simplicity in an early stage, starting solution is much more important than extensibility Related to single responsibility, sometimes it is better to have one function / class that does everything - especially if it is a lot - than splitting it up into to countless classes making your code longer, more complex and understand. also some rules that not in SOLID: only create re-usable code if you are sure you are going to re-use it, otherwise it is a waste of time. Only create extensible class if you are sure it is needed, and you are going to extend it, otherwise it is a waste of time, resources and also make your code longer and more complex than it is needed. Only beginners think that only by using SOLID principles you need to create optimal code from scratch in one huge step regardless if you need that or not. Only beginners think that you need to make your code following all these principles in the first step even if it is just a few simple function, making it re-usable and extensible just in case... Even without being sure that it will be ever re-used and / or extended. So in itself these simple examples that you can see everywhere related to SOLID principles are wrong, as these principles most of the time only come in to sight when you are dealing with huge software with a need of refactoring so the examples should reflect this fact. Illustrating SOLID principles with these simple examples suggest to beginners that they have to over optimize every software even with only 10 lines of code from day one, and unfortunately you can even see this happening everywhere in the industry by beginners in reality everywhere, and they think this how you create "good" code which is ridiculous. Solid principles must only come in the picture in relation of refacturing bigger code bas, but in that case there are much more to follow than these few simple rules, and to know the rest only comes with experience and you need to familiarize yourself with much bigger amount of terminologies from more serious authors. I think the main error in SOLID and the way it is represented that it actually tries to suggest that you need to mix coding with optimization even from the start, suggesting that optimization is as much, if not more, important than working code in the phase of coding when creating a working solution comes first. code optimization in terms of code quality must be a seaprate process from coding phase! These two should not be mixed and should represent different phase of the development cycle. Lot of companies misunderstand and do not know these basic principles and enforce developers to create high quality optimized working code from scratch, which is actually not even possible, not even using these few simple SOLID principles of course. When companies do this, then this is all about saving money and nothing else, and actually this is one of SOLID great error not to be clear on that point so that their principles can not be misrepresented by this way. I am not even sure that whoever created SOLID principles did not only created it to convince beginner developers to mix coding and optimization phasing into one single phase, which is wrong and all about just saving money for software companies by spending less time and money on development and actually creating worst software by using un-needed early optimization "just in case". It is like saying to the develpper: "I am paying so do everything at once for my money..." Unfortunately in practice I can see SOLID interpreted this way actually enforcing really bad practices on developers. The other thing is that only using SOLID principles does not make your code that much better as you need to know much more than these simple basic principles to create real good quality code. So this is another very bad aspect of SOLID as it tries to make it beleive that these few simple principles that you need to know and that is it, voila you have the optimal code. :-(
Thanks for your amazing analysis. It really blew apart lot of things.
Indeed you are correct, agreeable to lot of points, and thanks for taking time out to explain it so beautifully.
I did mention elephant in the room by saying:
SOLID is a guideline and not a rule. It is important to understand the crux of it and incorporate it with a crisp judgement. There can be a case when only few principles out of all is required.
Nevertheless thanks again
What frustrates the most in SOLID principles that it instills a sense of inferiority in seasoned developers. It suggest that it is very little that you need to master to be able to write good software. It is the opposite, you need to know much much more that only comes with a lot of years of experience and you need to learn from sources really different from people who wrote SOLID. Also if I think about these SOLID principles more, I can come up with a tons of examples that contradict every one of them! So whoever writes principles like these should make sure that at least they are much more SOLID than SOLID! For example if I have 100 things to do then I just have to create 100 different functions, just to make sure every single function does only 1 single thing??? WRONG! Truth is you have to split your 100 things into categories and implement as many functions as categories. This is called separation of concerns. To do this right you need a lot of experience and maybe the right education. How many functions you need is a trade off between so many things. Efficiency, performance, productivity, simplicity, maintainability, extensibility etc.. It is far from an easy task and you hardly ever end up with 100 functions doing 1 single thing each. So there is no such thing as "single responsibility principle", most functions in a real world application have multiple responsibility. In SOLID they oversimplify things, and instead of saying that you need to separate concerns and decide between trade offs that takes a lot of experience, they say just create as many functions as things you do, and voila you do not need experience, you need no proper education in the field and just knowing these 5 single "principle" you end up with the optimal software. So who needs experienced, educated developers anymore? This can't be further from the truth. It is actually just plain stupidity.