Did you enjoy the SOLID C++ video? Would you like to get a more hands-on exposure on the various principles and concepts? 👉 I've got you covered with a course on Udemy that is still concise but with more details, a critical view of things and interactive labs for you to train your SOLID skills on. 🖥 Check it out at: plat.is/solid
Awesome presentation. To summarize SOLID principle: 1. keep it simple, own only one responsibility. 2. without having to touch base class, extensions are done in child class, meaning base class should be generic/abstract enough. 3. Liskov substitution principle: child behaviors are honored, while adding new behaviors. 4. Interfaces should be minimum and sufficient, nothing more, nothing less, otherwise confusing and code bloating, also interfaces should be simple enough, and should do one job. 5. decoupling, nothing is tightly coupled, high business logics are not tightly coupled, concrete rules are not tightly coupled, basically in all things consider how to reduce tight coupling. Bottom line: easy to understand code , easy to use and change, easy to extend. Thanks.
Thanks for the awesome video. I've been programming C++ for 25 years but non professionally. I used to think all the abstract programming design theories were just "corporate bloat". I had the mentality of "shut up and code!". But as you can imagine, projects became increasingly complex as project size grew. This forced many projects to go unfinished. I was CONSTANTLY having to rewrite code. Not to mention near full-rewrites... Stuff was near impossible to maintain or extend... the list goes on. Finally, I've been making a concerted effort to write maintainable code so I don't have to keep rewriting everything from scratch all the time! I definitely agree with your beginning of the video. I tried looking through some SOLID videos before but they were based on other languages. The implementations were quite different and definitely made the examples harder to relate to. Thanks again! I've subscribed and will definitely be checking out your other videos.
Honestly, I watched another video that used python as an example, and I wasn't really getting it. This really helped me truly understand this set of principles.
Good explanation of SOLID. Just want to point out something about the LSP. The only way this principle is not violated is when both the pre- and post- conditions of the interface are not violated. This principle is basically derived from the old concept of "contract programming", which implies the definition of the specifications through interfaces, both with signatures AND documentation. So both pre and post conditions for the interface should be stated by specifying the range of valid values accepted and returned by the methods in their documentation. This does not prevent bugs by code, but it's up to a good programmer making sure they read the specifications and stick to it. Enforcing this by code essentially introduces another dependency, so I don't like that solution either.
Thank you for the Video. I enjoyed your examples and explanations. They really helped me understand the principles better. I hope they become more natural to me with more practice.
Φίλε μου, πραγματικά φανταστικός. Έχω παρακολουθήσει τουλάχιστον 2-3 courses και μπορώ ειλικρινά να πω, κανένα δεν με βοήθησε να καταλάβω τα solid principles. Αν και σε συντομία, τα εξήγησες πάρα πολύ απλά και παραστατικά και, βεβαίως, τα παραδείγματα στην cpp βοήθησαν και αυτά.
Αν τυχόν δεν είσαι ήδη μέλος, υπάρχει και το grcpp στο meetup και στο Facebook όπου διοργανωνονται εκδηλώσεις τακτικά πάνω σε θέματα σχετικά με C++ στα ελληνικά: facebook.com/grcpp www.meetup.com/grcpp-athens/
Never saw it so well explained, still to make sure, the D means the methods shouldn't depend on the details no? They should be universal across different children and parents no? Great work!
I think you have understood it correctly, yes. One aspect of the dependency inversion is that an interface shouldn't leak or impose an implementation. It shouldn't be semantically coupled to a specific child. This happens very often by the way because, when creating interfaces, we sometimes can't help being biased. Bias in favor of "the current" implementation details makes us create our interfaces dependent on them. We will eventually discover this when we want to reuse our code on a different product and realize that our interface wasn't abstract but rather specific to certain details. 😅 I'm preparing a new video where this is shown.
Thank you, But I found it very hard to read at your blog because of gray font color on white backgrounf. Could you please change it to black for better reading.
DIP can be overused though. For sockets it makes no sense for instance and also for code that is highly dependant on operating specific routines that differ from each other that much that you need to implement them anyway as intended. For generic software architecture design its benefitial though, thumbrule the lower the level you operate on an os in your software the less sense it makes.
Sure, if you have a unit and all it's doing is using an external library or making calls to an operating system then it makes less sense to try and make it reusable. That being said, I'd argue that the particular part of the code should remain as limited as possible and for it to be made available via a generic interface to higher level modules of the system.
There isn't a "working" project with these examples, but you can find all related code in this blog post: platis.solutions/blog/2020/06/22/how-to-write-solid-cpp/
Really good fundamental principles for projects, but they represent something ideal. In real case scenarios these will be bent and sometimes violated. So for anyone who is new, follow them as a guideline and in real cases you'll need to pivot a lot and do lots of violations of these principles :))
And again they are in pretty serious question at the moment. Liskov is of course requried but especially the first 2 are generating too much spaghetti OO code and dep Injection is questionable as it is giving false security when you test against mocks and not real implementation (thats what DI was designed for - testing). But beginners in programming should know about SOLID.
Testing with mocks and to what extent DI was "designed for testing" is a very long discussion. My overall stance is "be pragmatic and not dogmatic". :) Regarding SOLID principles being in question, I've made a Udemy course course on SOLID C++, which includes various interactive labs along with a more critical view on the various principles. In case you're interested, here's a coupon for it: www.udemy.com/course/how-to-write-solid-cpp/?couponCode=84093CD6FDF76650D36D Have a nice day!
@@platisd Of course all is a long discussion because there is no way to measure programmer efficency. And no, sorry after 40 years of programming i don't need any general blabla course about engineering, but one about the modern C++ template hell or other hard technical topics would be good.
@@llothar68 I wouldn't call it a "hard technical topic", I'm preparing something on C++20 concepts which related to reducing the complexity of templates.🙃 I guess there's always SFINAE though: th-cam.com/video/-Z7EOWVkb3M/w-d-xo.html
@@platisd It is hard. We have the CppCon 2024 videos coming soon and i'm sure i won't understand at least half of them. If you think you are good, try to a Udemy course where you explain what they mean in more detail with extended background/starter informationn. Because after spending a few hundert euros on udemy i 'm so careful picking another course. So many bad people who just don't understand anything out there. Having a authoritive reference to work against like a CppCon talk would do it for me. Just my 2 Cent for your business
Really good video, and good solutions to the problems showcased. I just want to ask How would you go about the project file structure? I don't like to put many structs into one file, because I wouldn't have an appropriate name for the file. Splitting them into their separate files would clutter the project directory. Frankly my declarations and usage looks strange.
Thanks for your kind comments Berkster. Now, as to the project structure, if it's big enough and unless there already is some convention I like to split the code in three top layers/directories: 1. Commodity layer: Components that do not add any value to the product but "have to be there". It's components that you should not add features to but if you make changes to them, it should be for bug fixing and decreasing their maintenance cost. 2. Differentiation layer: Components that differentiate the product from others, code for different variants or customers etc. You make changes to those layers so to differentiate more from the competition and create "revenue". 3. Experimentation layer: Components that *may* bring value in the future. You need to be able to create them fast and verify the business case. You create quick prototypes in this layer and if the business makes sense you move those to the differentiation layer. Higher level layers may depend on lower level ones but not vice versa. This architecture I described is based on the "3LPM". You can read bit more here: janbosch.com/blog/index.php/2017/01/28/9-out-of-10-in-rd-work-on-commodity/ If you need, I can provide some more reading material on it. Anyway, for each layer, I usually group different components or classes that belong to the same functional area. Each folder often contains an `include` and a `src` directory. Last but not least, there's a test directory in the root of the project too.
Just imagine/assume there's a member variable of type SensorModel. The goal of this presentation isn't to demonstrate fully working or high performant code but illustrate a point related to the SOLID principles.
That's a good idea. Any of them you're after in particular? Here's my main source on them: sourcemaking.com/design_patterns They have C++ examples as well, however not so modern C++ unfortunately.
@@cristianinujazznight3044 I'm new to making such videos so I'd like some feedback. What would you prefer more: a) A single longer video with many design patterns or b) multiple shorter videos with one design pattern at the time?
@@platisd I agree with Crhizt! Shorter Videos with one Design pattern at a Time! However, this video is great just as it is! really enjoying it :) Very clear and concise! Perhaps adding Time stamps in the description would be enough to help people sort through it if they don't need to watch all of it.
With getOrientation example you did not provide a good solution, what was the point of giving just a bad example ? Sometimes it's really hard to follow SOLID principles because there are no principles in real life.
Either the example was bad AND "there are no principles in real life" or you failed to understand the example as well as the principles. Which case do you think is the most probable?
@@TheRealBigYang aha I see. `struct` is used in the examples to skip one line of code for the `public` access modifier needed in the case of classes. Other than that, it's a matter of convention. The only difference, after all, between classes and structs in C++ is their default visibility.
If I wanted to know about SOLID there are plenty of resources. You were supposed to be detailed on SOLID C++ which is not about writing SOLID examples in C++, that's just rewriting.
@@theRECONN is this a _detailed_ piece on SOLID C++? Yes, or at least most people seem to think so. It explains how to apply the SOLID principles using C++ and particularly using many examples inspired from the embedded systems domain. Now, time for the apparently-not-so-obvious questions: - Should the _focus_ be on the C++ language semantics or how the SOLID principles are applied? - Should we have multi-page examples to ensure conformance with all C++ best practices? E.g. Should we abide by the rule-of-5 when defining a public virtual constructor in interfaces or can we skip that in favor of having all related code in a single page/slide? - Is it important to pass a std::string argument by const reference or std::string_view in an example that illustrates the Single Responsibility Principle? I could go on for a while but I hope you got the point with all these are rhetorical questions. If what made you miss the point of the video was the lack of a disclaimer in the beginning clarifying that the code snippets are simplified, I'll add one next time. I like this one by Vishal Chovatiya (www.vishalchovatiya.com): > The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss virtual destructor, constructor, copy constructor, prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons.
@@dimitriosplatis7496 If I know SOLID and know C++ - what do I learn? Remove my comment if it triggers you so much. I did not mean you have a typo or use a string instead of a string_view. I expected C++-tailored SOLID principles, simple examples but sophisticated concepts. Did I get CRTP, EBO information in interface segragation or pimpl idiom as a different approach of dependency inversion? Those are rethorical questions as well.
@@theRECONN you started off by noting "the code quality is questionable" and that "the snippets do not compile sometimes". Now, I guess my rhetorical questions may have somewhat worked and you mention instead you were expecting sophisticated concepts explained with simple examples. If SOLID is the "sophisticated concepts" and you mention mention PImpl and CRTP as the "simple examples", as alternatives to DI, then we have a very different idea on what is a simple example explaining a sophisticated concept. 🤯 If, on the other hand, SOLID with those "alternatives to DI" is the sophisticated concept, then this deserves a video of its own as a follow up of this.
Did you enjoy the SOLID C++ video?
Would you like to get a more hands-on exposure on the various principles and concepts?
👉 I've got you covered with a course on Udemy that is still concise but with more details, a critical view of things and interactive labs for you to train your SOLID skills on.
🖥 Check it out at: plat.is/solid
One of the best videos I have ever seen on OO embedded design. Thank you.
Awesome presentation. To summarize SOLID principle: 1. keep it simple, own only one responsibility. 2. without having to touch base class, extensions are done in child class, meaning base class should be generic/abstract enough. 3. Liskov substitution principle: child behaviors are honored, while adding new behaviors. 4. Interfaces should be minimum and sufficient, nothing more, nothing less, otherwise confusing and code bloating, also interfaces should be simple enough, and should do one job. 5. decoupling, nothing is tightly coupled, high business logics are not tightly coupled, concrete rules are not tightly coupled, basically in all things consider how to reduce tight coupling. Bottom line: easy to understand code , easy to use and change, easy to extend. Thanks.
Sounds about right! 👍
Thanks for the awesome video. I've been programming C++ for 25 years but non professionally. I used to think all the abstract programming design theories were just "corporate bloat". I had the mentality of "shut up and code!". But as you can imagine, projects became increasingly complex as project size grew. This forced many projects to go unfinished. I was CONSTANTLY having to rewrite code. Not to mention near full-rewrites... Stuff was near impossible to maintain or extend... the list goes on.
Finally, I've been making a concerted effort to write maintainable code so I don't have to keep rewriting everything from scratch all the time! I definitely agree with your beginning of the video. I tried looking through some SOLID videos before but they were based on other languages. The implementations were quite different and definitely made the examples harder to relate to.
Thanks again! I've subscribed and will definitely be checking out your other videos.
I use C and still learnt quite a lot from this. I absolutely suck at OOP and designing OOP so C is what I prefer to use in my free time.
Honestly, I watched another video that used python as an example, and I wasn't really getting it. This really helped me truly understand this set of principles.
I'm very happy to hear this! ⭐👍👍
thank you, the aws file upload example is perfect
Good explanation of SOLID. Just want to point out something about the LSP. The only way this principle is not violated is when both the pre- and post- conditions of the interface are not violated. This principle is basically derived from the old concept of "contract programming", which implies the definition of the specifications through interfaces, both with signatures AND documentation. So both pre and post conditions for the interface should be stated by specifying the range of valid values accepted and returned by the methods in their documentation. This does not prevent bugs by code, but it's up to a good programmer making sure they read the specifications and stick to it. Enforcing this by code essentially introduces another dependency, so I don't like that solution either.
Thank you. This is exactly what I need. Subscribed =)
Very well explained. One of the best videos on this topic.
Excellent content and the principle briefly explained with success. Amazing!
Thank u so much for the great explanation.
Real-world examples are awesome.
A concise and practical guide. Thank you so much!
This is very very clear explanation of SOLID principles.
you really did a wonderful work here...thanks a ton :) ...very well explained here...best in the market as of now ...cheers..
Thank you for the Video. I enjoyed your examples and explanations. They really helped me understand the principles better. I hope they become more natural to me with more practice.
Great content. Thanks for sharing. A small bug that I noticed in the example code. In about 26:07, the struct AwsCloud should derive from Cloud.
Ooops! Good catch. I fixed it on the written versions of this tutorial.
@@platisd It's not a big deal. What matters is the explanation and getting your point across. Which you did! Congratulations!
This video was awesome! Subscribed!
Good video bro. I already knew about solid, but it was in java. This video really came in handy for me.
Thanks, that was exactly the reason this video was made 😊
Loved your content for using cpp, thanks.
One of the best video available on solid principal, great effort man :)
Awesome explanation with code walk through
Excelent video, thank you!
Awesome explanation. Thanks!
Fantastic explanation !
your blogs are worth reading...well done...
Thank you! :)
I watched your other video on SFINAE. I personally like the way you present. Please keep it.
Thanks for the kind words of encouragement! 🧡
Amazing video, thank you so much.
Φίλε μου, πραγματικά φανταστικός. Έχω παρακολουθήσει τουλάχιστον 2-3 courses και μπορώ ειλικρινά να πω, κανένα δεν με βοήθησε να καταλάβω τα solid principles. Αν και σε συντομία, τα εξήγησες πάρα πολύ απλά και παραστατικά και, βεβαίως, τα παραδείγματα στην cpp βοήθησαν και αυτά.
Ευχαριστώ πολύ Ηλία!
Αν τυχόν δεν είσαι ήδη μέλος, υπάρχει και το grcpp στο meetup και στο Facebook όπου διοργανωνονται εκδηλώσεις τακτικά πάνω σε θέματα σχετικά με C++ στα ελληνικά:
facebook.com/grcpp
www.meetup.com/grcpp-athens/
@@platisd Όχι δεν το είχα ακουστά, οπότε θα γραφτώ. Σε ευχαριστώ πολύ Δημήτρη.
what a great video!
Never saw it so well explained, still to make sure, the D means the methods shouldn't depend on the details no? They should be universal across different children and parents no?
Great work!
I think you have understood it correctly, yes. One aspect of the dependency inversion is that an interface shouldn't leak or impose an implementation. It shouldn't be semantically coupled to a specific child. This happens very often by the way because, when creating interfaces, we sometimes can't help being biased. Bias in favor of "the current" implementation details makes us create our interfaces dependent on them. We will eventually discover this when we want to reuse our code on a different product and realize that our interface wasn't abstract but rather specific to certain details. 😅
I'm preparing a new video where this is shown.
@@platisd do you do online classes on c++ over zoom. if so can you let me know
@@MrGaurabpaul I used to in my previous job. Best way to get notified about this is to subscribe to my channel! :)
Thank you, But I found it very hard to read at your blog because of gray font color on white backgrounf.
Could you please change it to black for better reading.
I'll see what I can do 👍
DIP can be overused though. For sockets it makes no sense for instance and also for code that is highly dependant on operating specific routines that differ from each other that much that you need to implement them anyway as intended. For generic software architecture design its benefitial though, thumbrule the lower the level you operate on an os in your software the less sense it makes.
Sure, if you have a unit and all it's doing is using an external library or making calls to an operating system then it makes less sense to try and make it reusable.
That being said, I'd argue that the particular part of the code should remain as limited as possible and for it to be made available via a generic interface to higher level modules of the system.
loved it totally....Do you have the complete source code for these ?
There isn't a "working" project with these examples, but you can find all related code in this blog post: platis.solutions/blog/2020/06/22/how-to-write-solid-cpp/
Really good fundamental principles for projects, but they represent something ideal. In real case scenarios these will be bent and sometimes violated. So for anyone who is new, follow them as a guideline and in real cases you'll need to pivot a lot and do lots of violations of these principles :))
some one distrub him with 9999 cups coffees so he makes a great video imagine getting these
And again they are in pretty serious question at the moment. Liskov is of course requried but especially the first 2 are generating too much spaghetti OO code and dep Injection is questionable as it is giving false security when you test against mocks and not real implementation (thats what DI was designed for - testing). But beginners in programming should know about SOLID.
Testing with mocks and to what extent DI was "designed for testing" is a very long discussion.
My overall stance is "be pragmatic and not dogmatic". :)
Regarding SOLID principles being in question, I've made a Udemy course course on SOLID C++, which includes various interactive labs along with a more critical view on the various principles. In case you're interested, here's a coupon for it: www.udemy.com/course/how-to-write-solid-cpp/?couponCode=84093CD6FDF76650D36D
Have a nice day!
@@platisd Of course all is a long discussion because there is no way to measure programmer efficency. And no, sorry after 40 years of programming i don't need any general blabla course about engineering, but one about the modern C++ template hell or other hard technical topics would be good.
@@llothar68 I wouldn't call it a "hard technical topic", I'm preparing something on C++20 concepts which related to reducing the complexity of templates.🙃
I guess there's always SFINAE though: th-cam.com/video/-Z7EOWVkb3M/w-d-xo.html
@@platisd It is hard. We have the CppCon 2024 videos coming soon and i'm sure i won't understand at least half of them.
If you think you are good, try to a Udemy course where you explain what they mean in more detail with extended background/starter informationn.
Because after spending a few hundert euros on udemy i 'm so careful picking another course. So many bad people who just don't understand anything out there. Having a authoritive reference to work against like a CppCon talk would do it for me.
Just my 2 Cent for your business
@@llothar68not a bad concept!
Not sure it'd work for a Udemy course, but certainly would for a TH-cam video. 👍
Perfect !
Really good video, and good solutions to the problems showcased. I just want to ask How would you go about the project file structure? I don't like to put many structs into one file, because I wouldn't have an appropriate name for the file. Splitting them into their separate files would clutter the project directory. Frankly my declarations and usage looks strange.
Thanks for your kind comments Berkster. Now, as to the project structure, if it's big enough and unless there already is some convention I like to split the code in three top layers/directories:
1. Commodity layer: Components that do not add any value to the product but "have to be there".
It's components that you should not add features to but if you make changes to them, it should be for bug fixing and decreasing their maintenance cost.
2. Differentiation layer: Components that differentiate the product from others, code for different variants or customers etc.
You make changes to those layers so to differentiate more from the competition and create "revenue".
3. Experimentation layer: Components that *may* bring value in the future. You need to be able to create them fast and verify the business case.
You create quick prototypes in this layer and if the business makes sense you move those to the differentiation layer.
Higher level layers may depend on lower level ones but not vice versa. This architecture I described is based on the "3LPM". You can read bit more here: janbosch.com/blog/index.php/2017/01/28/9-out-of-10-in-rd-work-on-commodity/
If you need, I can provide some more reading material on it.
Anyway, for each layer, I usually group different components or classes that belong to the same functional area. Each folder often contains an `include` and a `src` directory. Last but not least, there's a test directory in the root of the project too.
@@platisd Thank you, kind sir, your reply is much appreciated. Keep at it, and you shall abound. This channel will get bigger soon. : )
In 9:29 I didn't understand how did you initialize" mModle" in the class "DistanceSensor" without declared it ?
Just imagine/assume there's a member variable of type SensorModel. The goal of this presentation isn't to demonstrate fully working or high performant code but illustrate a point related to the SOLID principles.
Thanks
Thank you. Could you explain Design patterns in C++ or Rust?
That's a good idea. Any of them you're after in particular?
Here's my main source on them: sourcemaking.com/design_patterns
They have C++ examples as well, however not so modern C++ unfortunately.
@@platisd Thats the case. I will like it in C++20. If you like the factory :D
@@cristianinujazznight3044 I'm new to making such videos so I'd like some feedback. What would you prefer more: a) A single longer video with many design patterns or b) multiple shorter videos with one design pattern at the time?
@@platisd Mmm... I would prefer shorter b).
@@platisd I agree with Crhizt! Shorter Videos with one Design pattern at a Time! However, this video is great just as it is! really enjoying it :) Very clear and concise! Perhaps adding Time stamps in the description would be enough to help people sort through it if they don't need to watch all of it.
With getOrientation example you did not provide a good solution, what was the point of giving just a bad example ? Sometimes it's really hard to follow SOLID principles because there are no principles in real life.
Either the example was bad AND "there are no principles in real life" or you failed to understand the example as well as the principles.
Which case do you think is the most probable?
Ty
the struct interfaces feel so wrong....... especially at 7:35
Because they are `struct` or some other reason?
@@platisd coming from java and just learning c++ more in depth, it feels wrong in general, but mainly because it's a struct and not a class
@@TheRealBigYang aha I see. `struct` is used in the examples to skip one line of code for the `public` access modifier needed in the case of classes.
Other than that, it's a matter of convention. The only difference, after all, between classes and structs in C++ is their default visibility.
@@platisd That's something new I just learnt. Thank you!
Maybe information and intentions were good but your code quality is questionable, not to say it doesn't compile sometimes.
Can't see the forrest for the trees perhaps?
If I wanted to know about SOLID there are plenty of resources. You were supposed to be detailed on SOLID C++ which is not about writing SOLID examples in C++, that's just rewriting.
@@theRECONN is this a _detailed_ piece on SOLID C++? Yes, or at least most people seem to think so.
It explains how to apply the SOLID principles using C++ and particularly using many examples inspired from the embedded systems domain.
Now, time for the apparently-not-so-obvious questions:
- Should the _focus_ be on the C++ language semantics or how the SOLID principles are applied?
- Should we have multi-page examples to ensure conformance with all C++ best practices? E.g. Should we abide by the rule-of-5 when defining a public virtual constructor in interfaces or can we skip that in favor of having all related code in a single page/slide?
- Is it important to pass a std::string argument by const reference or std::string_view in an example that illustrates the Single Responsibility Principle?
I could go on for a while but I hope you got the point with all these are rhetorical questions.
If what made you miss the point of the video was the lack of a disclaimer in the beginning clarifying that the code snippets are simplified, I'll add one next time. I like this one by Vishal Chovatiya (www.vishalchovatiya.com):
> The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing “public:” sometimes and also miss virtual destructor, constructor, copy constructor, prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons.
@@dimitriosplatis7496 If I know SOLID and know C++ - what do I learn? Remove my comment if it triggers you so much. I did not mean you have a typo or use a string instead of a string_view. I expected C++-tailored SOLID principles, simple examples but sophisticated concepts. Did I get CRTP, EBO information in interface segragation or pimpl idiom as a different approach of dependency inversion? Those are rethorical questions as well.
@@theRECONN you started off by noting "the code quality is questionable" and that "the snippets do not compile sometimes".
Now, I guess my rhetorical questions may have somewhat worked and you mention instead you were expecting sophisticated concepts explained with simple examples.
If SOLID is the "sophisticated concepts" and you mention mention PImpl and CRTP as the "simple examples", as alternatives to DI, then we have a very different idea on what is a simple example explaining a sophisticated concept. 🤯
If, on the other hand, SOLID with those "alternatives to DI" is the sophisticated concept, then this deserves a video of its own as a follow up of this.
I'm allergic to this amount of 'virtual' and dynamic polymorphism, this is not Java.
this is not C either, grandpa