If you are a junior dev or self-taught programmer who watches this video and thinks "but... the original code was much tighter and easier to understand" I hope that you please understand that this is a totally natural thought to have. All of these design principles (as well as software architecture decisions) really shine when you are doing more than writing a quick 1-off script. Many times you will come back later to some code (either yours or someone elses) and need to make changes, or dramatically expand it's capability, and in those moments you will start to wish very much that the original code was written in this way (high cohesion, low coupling, dependency inversion, etc.) because then adding your new feature is not only relatively simple (e.g. a new processor subclass) but YOU CAN ADD IT WITHOUT BEING SCARED THAT YOU ARE BREAKING TONS OF STUFF. I cannot stress how important that last part is. I cannot tell you how many times I have looked at someones high-ly procedural code and tried to add a quick feature to it and though "oh god i hope this doesn't break something!" When you break code up this way, you make it so that adding a new feature capability is significantly de-risked.
@@luck3949 Yes, working in a team is definitively something where these principles shine. I would also add testing to that list. If your code can't be tested, it very probably doesn't follow SOLID. I am a a fan of writing code the KISS way (Keep it simple, stupid!), but now that I have more experience in larger and more complicated projects with more people involved and ever changing requirements, I always say that SOLID trumps KISS. Of course you should still keep it as simple as possible, but not if that means violating SOLID. It probably means that you have to think more in the beginning and have to create more classes (and especially interfaces), but I can almost guarantee you that this makes testing, refactoring and extending the code a lot easier and especially safer. I've had too many projects which started as something small and easy which grew over time and are an unstable and unmaintainable mess. A lot of those I've built myself. Well, at least for me this has been a lesson learned :)
Defining the SOLID principles in layman's terms (based on this video alone): 1. Single Responsibility Make things (classes, functions, etc.) responsible for fulfilling one type of role. e.g. Refactor code responsibilities into separate classes. 2. Open/Closed Be able to add new functionality to existing code easily without modifying existing code. e.g. Use abstract classes. These can define what subclasses will require and strengthen Principle 1. by separating code duties. 3. Liskov Substitution When a class inherits from another class, the program shouldn't break and you shouldn't need to hack anything to use the subclass. e.g. Define constructor arguments to keep inheritance flexible. 4. Interface Segregation Make interfaces (parent abstract classes) more specific, rather than generic. e.g. Create more interfaces (classes) if needed and/or provide objects to constructors. 5. Dependency Inversion Make classes depend on abstract classes rather than non-abstract classes. e.g. Make classes inherit from abstract classes.
You built a simple and practical example that progressively incorporates in a natural manner the SOLID principles "in the right order". That's not easy ! Really inspiring pedagogical work
Absolutely great work! It's such a rare occasion to find a good channel, dealing with intermediary stuff and up. Also, really like 'real life' examples in videos so far - makes it so much easier to memorize.
This Software Design series fills a gap that almost nobody else seems to be addressing. The real world examples + refactoring process make these videos truly amazing!
Dude you are the absolute best!!!! I am a computer science student in university, and they would never dream of teaching good design like this. This is the first time I've been able to actually understand the usefulness of Inheritance/Polymorphism in OOP.
I keep coming back to this video from time to time, it is so well-explained. The order of examples is so good that I was not only able to understand SOLID but make some small refactors in my day-to-day as well to make it adhere to the principles. Amazing work!
Thanks, glad to hear you like it. It was indeed quite a challenge to have the example make sense for each of the five principles and also be explainable in that order 😁.
uncle un·cle a) the brother of one's father or mother b) the husband of one's aunt or uncle c) annoying, pipe-smoking computer scientist. PS. don't forget to check out the gag reel at the end! ;)
the way you walk through examples is brilliant! the way code is structured has always fascinated me to no limit, and seeing a live rework done this well is a gem to watch! i have started to use composition over inheritance for vast majority of cases for a while now due to it being more flexible. and you can apply inheritance to composition as well, so its the best of both worlds in a lot of cases
Thank you very much! I’m happy you’re enjoying the content. I fully agree regarding inheritance vs composition. I went through that same process a while ago.
17:15 It looks like the code in this example violates the Liskov Substitution Principle. We have a base class named Authorizer which is basically an interface. In our client-code we depend on it, waiting that its subclass won't force us to change anything because of a different implementation (verify_code, not_a_robot). You should've specified an abstract method in the base "Authorizer" class and implement it in subclasses. Correct me if I'm mistaken.
Good quality set, good camera, good clear concise speaker, good audio, good editing, good music, good examples, good explanations, good pacing. Good video. Probably one of the best SOLID vids out there
@@ArjanCodes No worries. Really dude, you seem to be the only one doing intermediate level stuff in python. All other intermediate stuff is in C, C++ C#/Java etc... but there are so many people learning to code with python (Go and Rust are looking exciting as well, oh and JavaScript) and need to learn how to write clean code. You are making the world a better place with this channel. So thank you. Please also setup a Bitcoin Lightning wallet (Wallet of Satoshi mobile app is good) and show the code in a video so we can donate to you for no fees (everyone charges too much fees when we try to tip guys like yourself.)
I have watched many SOLID priciples videos on You Tube and this is by far the best one. Thanks for all the efforts you put in these videos to share your deep knowledge with the world !
Well written, good presentation, high production value. This is easily the best programming advice channel on RUclips. Everybody should subscribe to this.
Thank you Vladimir, I do pay a lot of attention to creating the right examples - At the moment I think it's about 2/3 of the work that goes into producing a video.
Some thoughts about Liskov substitution example. Turns out, that if we move a specific parameter (security code or email) to the initializer, then we have to create a new instance of the class for each payment? Doesn't sound like a good approach
Your Code example is chosen perfectly and your explanations are on the point. No waffleing, just the pure information in an easy to understand language. Great stuff.
Just a small side note if anyone reads this, what he shows as the variation of interface segregation is actually not composition, it is segregation. If each of the payment processors CREATED the smsAuth inside of the class, it had been composition, there is some kind of important detail here! :) Anyways, awesome video! :D
This was a great video, thank you. The composition step, after Interface Segregation and Dependency Inversion, looks a lot like Dependency Inversion. I had expected you to use a mixin on the subclass, but instead you added authorizer argument to the initializer. When I think of composition, I usually think of mixins. Can you touch on the pros/cons of mixins, versus adding functionality through the initializer, in the context of composition?
Hi Connor, thanks! I don’t use mixins very often, for a few reasons. First, they don’t adhere to what a parent-child class relation means in traditional OO programming (the ‘is a’ relationship). Second, I don’t like how mixins potentially create strange coupling issues, for example mixin A might define a method X, mixin B uses that method X, and finally, a class C then inherits from both A and B to combine the two. But at the same time, both mixins A and B can’t be used independently in a meaningful way. I much prefer composition/association (a ‘has a’ relationship), which models the dependencies explicitly and doesn’t break OO philosophy.
@@ArjanCodes Thank you, that sounds like a pretty good reason to avoid mixins, then. Come to think of it, I recall running into unexpected behavior when I used multiple mixins in one class. In Python, the order in which you include mixins affects how the child class works. Thank you for taking the time to address my question.
perfect explanation for this problem. To the point, with practical examples. Others are using 1000 words to beat around the bush. Love your explanation style
Hi Arjan. I just wanted to thank you. There is material in SOLID to talk about for hours, but you have done a great job of distilling the fundamentals in a less than 20 min video with a very clear and didactic python example. Kudos and Thank you very much! 😊
Loving all the best-practice examples and patterns! They're really helping me get off the ground with my latest personal project of building a chess enginer B) Thanks for all the good content!
The most understandable video on SOLID I have ever seen, thanks a lot! And every time I am amazed how much simpler and more readable Python code is than JavaScript :}, there is no nested curly braces hell...
New(ish) to python. Have been struggling to wrap my head around (and use) SOLID principles for years. This video made BOTH much clearer. Thanks Unkl Arjan!
I start learning design principles and design patterns and I have discovered your YT channel, I think, nothing better could me happen. Nice code, nice explanations and very good inspiration to studying. Thanks for alls.
I have a question regarding the second part, let's say the pay() for all the subclasses have a few similar lines of codes, what do you think is the best option here, to repeat these lines, group them into a separate functions and call them or use .super() the mother class then add the rest of code (which is different in each subclass)
I will begin a new job next week and really need to refresh my programming skill. Have to agree with all the comments here. Exactly what I have been looking for. A+ for your great work!
You've done one of the best SOLID explains I ever saw. Your code and explanation is really understandable. Wish I could have such teammate as your. Thank you!
Big Like!! I'm Senior JS developer, recently moving to AI career after PhD in the field. My problem was that I don't know enough Python (especially clean code). I found your channel very helpful as a starting point so I don't have to waste my time learn Python programming from scratch as it's the first time I program. 😅
Great Job. Not easy to find a example small and compact yet enough to show how the idea works out. I was ready to procrastinate but the pace was so good it kept me on the seat!
one of the best programming/ software design explanation channel. Keep this up. You vids really clear explain and easy to understand example. Really appreciate the afford.
I am really glad to find this channel by the beginning of the 2022. Thank you very much for the wonderful content. You deserve 100+ Millions subscribers.
If I'm not mistaken the pattern you choose to use instead of creating a new interface for the SMS Processor (favoring composition over inheritance) is the Strategy Pattern, this pattern defines a family of algorthms across different concrete classes and can be interchanged at runtime by the class that requires them.
Great explanations and examples @ArjanCodes, as always :) however I noticed something I had always been told was not very highly-advised: at 12:37 you set a class attribute `authorized`, which you then modify at instance-level in the method `verify_code`. I thought setting class attributes like this was risky because you could in theory directly modify the class attribute, which could globally overwrite the attribute in instances of this class. Instead I guess it should go in the init method for the class, making it instance-level... But quite likely I'm missing something crucial here. Any thoughts on this?
You are right, thats a mistake. I assume that @ArjanCodes actually intended to use a DataClass here in which case it would be an instance variable otherwise he should have placed it in __init__ . But I guess the topic and point of the video (i.e. principles of software architecture ) is looking at the bigger picture and assumes that the target audience already understands basic concepts like cls vs instance variables... Then again, the man is clearly a masterful programmer who is more knowledgable that 99.99% of us in the comments section so let me not be so bold as to say its him who is mistaken and not me who is missing something :D
For the interface segregation principle, in Python, wouldn't you rather split up the PaymentProcessor into 2 abstract classes and use multiple inheritance to require both functions? As a mixin?
Lekker bezig Arjan! I admire your discipline and consistency of doing a video every Friday. That's the way to grow. It's great to see you covering higher level topics like design principles / architecture / clean code in the context of Python, which is not common here on yt. I just happen to be reading Bob's 'clean architecture' book right now after finishing 'clean architectures in python' and `architecture patterns in python` (all great) because I've started designing a complex piece of software for my startup and want to keep it clean & maintainable. Uncle B writes there's a bit of misunderstanding about the SR principle. People tend to think a module/class should "do only one thing". That is a good principle too, but SR originally means a module/class should only be responsible to one "user" or "stakeholder". I guess that's the group of humans (or robots) that ends up using the business logic described by the code, not sure if I understand it 100% myself. But it's ok if a class does a bunch of different things, as long as it's being done serving a common goal. This way the class only has one "reason to change" and that's useful. Curious to see what else you have in the pipeline. If you need suggestions, going deeper into Clean Architectures, TDD, Event Driven, if you resonate with those, would be amazing 👌
Dankjewel Richard! You make a good point that having a single responsibility doesn’t mean doing only a single thing. In the example, the order class also has multiple methods doing different things. In my experience, how responsibilities are divided over classes is for a large part decided by the structure of the data. For example, moving the total price method outside of the order would introduce a lot of coupling, because it needs to know a lot of details about the order data, which is not the case for payment processing. Thank you very much for those suggestions, keep them coming! I’ll add those to my list of video ideas (which is getting quite large).
Besides my comment on Single Responsibility -->> you actually do great intro presentation of SOLID - your simplifications make good sense. THX! I have taught pro developers code quality (including SOLID and its package principle siblings) for decades. I appreciate when you manage to introduce potentially complex topics to developers that are new to the topic. I know how difficult this can be based on own successes and failures. You earned yourself a new subscriber!
Thanks, Arjan, for a brilliant, clear exposition of SOLID with simple, tangible examples. Like with your excellent 'smelly code' videos it's a good lesson in how one should brutally and with malice aforethought refactor, refactor and refactor until your code is concise, readable and makes you giggle out loud because its soooo pretty and smells beautiful! Your team will will use & love your code and you may well be surprised how reusable and extensible it is in the future. It may take a bit more time up front than just going with the first hack that runs and spits out a (probably) correct answer (i.e., as is most 'engineering' analyst Python, Matlab, Perl, R, etc etc etc), but your future self will thank you for it. cheers!
I got a real understanding of the SOLID principles the first time I watched this video (well... I had to rewatch it a couple of times 😂), and I've been applying them in my code ever since with really noticeable improvements; moreover, today I gave a talk at my job on this topic based mostly on the things I learned from this video and it all went super good. Thanks for the fantastic content and keep up the great work Arjan!
Hi Arjan, I really like your video. I learned 5 principles in less than 20 mins with good examples. However, could you elaborate a little bit more about what will happen if we DO NOT follow those principles? This will make the impact of those principles more visible. Thank you.
Thanks Arjan for explaining the advanced concept in programming with code.. this channel really help to take leap from intermediate level to expert level..
Single Responsibility Principle is often misunderstood and I think it happened again here in the common way which is to conflate it with separation of concern. SRP is a people-focused problem whereas SoC is a modular cohesion problem. The examples given in Uncle Bob's book explains it pretty well. In short, it addresses an issue where you have multiple different stakeholders giving you requirements for the same package/service/etc -- in DDD you would see this as an invalid overlap of subdomains. For example, when payroll and Human Resources have cause a conflict in the same "employee" table as they have a different definition of "salary" and how its calculated (or if it's calculated at all; it might static). SME/VP 1 says you have to do it one way whereas SME/VP 2 says you have to do it another way which could take the entire department down because of that conflict. Or where Sales and Marketing have two different definitions of "Customer" with different journeys. The entity has more than one reason to change in that you are getting conflicting requirements from what is essentially two opposing forces. So the problem is similar in that the class is conflicted, but with SRP, the conflict is caused by people, and with SoC the problem is caused by low cohesion (actually doing too many unrelated or loosely related things).
Thanks, I read simple architecture, it skimps over the solid principles and only demonstrates the principles on a design level and I really needed some implementation examples!
I thought I was decent in oop, but after watching this video, I am not really that good at applying good design to my code, that helped alot bro, thank you alot, and btw, I love the way you code and the sound of the keyboard and all that stuff. further more, I would like to point out something hat I w I like about your python videos, it seems like you bring alot of use cases and real world applications for the language which something I always have wanted to do in youtube since no one does it, but now since I found that channel, I can enjoy seeing such great practical content that really does what I always wanted people to do (but probably I will make some videos if I get a new laptop soon). anyways thanks, I will subscribe with my 4 youtube accounts lol.
This video is worth its weight in gold and this series is amazing! Thanks a lot Arjan! Please do a separate series on the GoF design patterns with Python examples. :D
Just came across this channel and it is very informative. I was following along with this video and with each iteration I was thinking "well, that makes sense" until we got to the 4th. I then found myself wondering how we changed the code so many times and became lost. 🤣 Clearly I need to watch this video a few more times to be able to get my little head around it. The video is time stamped and each section I feel is concise. So it should be easy enough. Thank you for sharing your wisdom!
Great video! I love all your content, it has been so very helpful! It is so insightful to hear you talk about design concepts *while* you are implementing them with a simple example. In my experience, this is a rather rare feature of programming related educational videos -- most of the time they're focused on outcomes and not principles (and if they are focused on principles, they're seldom integrated into a single example that is refined -- with explanations -- over the course of a video). You have such a great style and approach to these videos! This is video is a gem that I will return to several times in the future just to check myself on future projects. I initially discovered your channel while looking for some info about the observer design pattern and I just kept watching more because it was really well done. I would love to see some discussions/examples of frameworks like MVC vs other architectures, perhaps as a series where you roll out a small full-stack app. Love your content! THANK YOU for the work that you do!
You manage to put this topic, which is far from easy to explain, into less than 20 minutes and sill keep it in a good pace while implementing good and easy to follow examples. You have my respect for that. The only other course I found so far that is on an equal level is a paid one that is almost an hour in length. "SOLID Principles in PHP" by Jeffrey Way on Laracast. I've put a link to your video in our intranet and I will trey to make it mandatory for all our devs that they have to watch it at least once :)
Great work!! Your videos are the best I've seen and what's helped me the most to understand core OO principles for better code design and easy solutions. You're the best at teaching this stuff!
EXCELLENT work! Love your videos, so helpful with the examples and explanation. The pace of the video and explanations and sound and video quality are spot on as well!
S - classes must have a single responsibility for a single actor, other actors shouldn't need to modify it for their needs O - to make changes to a class, extensions must be possible and easy and modifications must be avoided:- use ABC to allow extensions) L - super-class must be substitutable with subclass (especially method args and outputs):- use dependency injection in the constructor I - Use finer and not broader interfaces that can be optionally inherited from:- use composition with implementations based on finer interfaces D - Instead of concrete dependencies, use an abstract depdendency (using an ABC, like an abstract strategy instead of a concrete strategy)
Hii Arjan, Your content is brilliant. I have a doubt, In L(liskov principle) you added initializers in each payment class. so it does not voilates the Liskov's principle but does it voilates Open/close principle as we modified it by addding __init__ method? correct me if I am wrong. Thanks!!
2 года назад
High cohesion doesn't refer to "do one thing", it's more "don't split too much, keep related things close". Regarding OCP - it doesn't have to be implemented using inheritance. In fact, a simple interface IPayment and PaymentProcessor processing payments would work better. Open for extension simple means "don't hardcode" (variables, dependencies). Composition is the more common approach of implementing OCP. Some design patterns target it as well - Proxy, Deocrator, Chain of Responsibility. The rest looks good. My summary of SOLID is: Split Don't hardcode Don't fake
Seems like one of those senior devs who you could ask for help and he would gladly explain, I appreciate that vibe
100%
If you are a junior dev or self-taught programmer who watches this video and thinks "but... the original code was much tighter and easier to understand" I hope that you please understand that this is a totally natural thought to have. All of these design principles (as well as software architecture decisions) really shine when you are doing more than writing a quick 1-off script. Many times you will come back later to some code (either yours or someone elses) and need to make changes, or dramatically expand it's capability, and in those moments you will start to wish very much that the original code was written in this way (high cohesion, low coupling, dependency inversion, etc.) because then adding your new feature is not only relatively simple (e.g. a new processor subclass) but YOU CAN ADD IT WITHOUT BEING SCARED THAT YOU ARE BREAKING TONS OF STUFF. I cannot stress how important that last part is. I cannot tell you how many times I have looked at someones high-ly procedural code and tried to add a quick feature to it and though "oh god i hope this doesn't break something!" When you break code up this way, you make it so that adding a new feature capability is significantly de-risked.
Yes. They also help to prevent merge conflicts - a thing I didn't know existed before I started working in a team.
@@luck3949 Yes, working in a team is definitively something where these principles shine. I would also add testing to that list.
If your code can't be tested, it very probably doesn't follow SOLID. I am a a fan of writing code the KISS way (Keep it simple, stupid!), but now that I have more experience in larger and more complicated projects with more people involved and ever changing requirements, I always say that SOLID trumps KISS. Of course you should still keep it as simple as possible, but not if that means violating SOLID. It probably means that you have to think more in the beginning and have to create more classes (and especially interfaces), but I can almost guarantee you that this makes testing, refactoring and extending the code a lot easier and especially safer.
I've had too many projects which started as something small and easy which grew over time and are an unstable and unmaintainable mess. A lot of those I've built myself.
Well, at least for me this has been a lesson learned :)
ah ok thanks
Exactly, and to add to that, it also becomes naturally much more testable, which also feeds into the risk aversion
Their gut instinct is correct. OOP is a stain in programmings history and will be eclipsed by procedural and data oriented design.
Defining the SOLID principles in layman's terms (based on this video alone):
1. Single Responsibility
Make things (classes, functions, etc.) responsible for fulfilling one type of role.
e.g. Refactor code responsibilities into separate classes.
2. Open/Closed
Be able to add new functionality to existing code easily without modifying existing code.
e.g. Use abstract classes. These can define what subclasses will require and strengthen Principle 1. by separating code duties.
3. Liskov Substitution
When a class inherits from another class, the program shouldn't break and you shouldn't need to hack anything to use the subclass.
e.g. Define constructor arguments to keep inheritance flexible.
4. Interface Segregation
Make interfaces (parent abstract classes) more specific, rather than generic.
e.g. Create more interfaces (classes) if needed and/or provide objects to constructors.
5. Dependency Inversion
Make classes depend on abstract classes rather than non-abstract classes.
e.g. Make classes inherit from abstract classes.
Excellent summary!
Can I share this?
@@onlyoneuche yes, of course
thank you!!!
thx
You built a simple and practical example that progressively incorporates in a natural manner the SOLID principles "in the right order". That's not easy ! Really inspiring pedagogical work
Thanks so much! Yeah, it definitely took me a while to figure this out, thanks for noticing :).
Absolutely great work! It's such a rare occasion to find a good channel, dealing with intermediary stuff and up. Also, really like 'real life' examples in videos so far - makes it so much easier to memorize.
Thank you so much, that’s really kind! I agree having real-life examples helps a lot to put it into a useful context.
Indeed Arjan earned my sub.
This Software Design series fills a gap that almost nobody else seems to be addressing. The real world examples + refactoring process make these videos truly amazing!
Dude you are the absolute best!!!! I am a computer science student in university, and they would never dream of teaching good design like this. This is the first time I've been able to actually understand the usefulness of Inheritance/Polymorphism in OOP.
Glad to hear the videos are helpful to you!
I keep coming back to this video from time to time, it is so well-explained. The order of examples is so good that I was not only able to understand SOLID but make some small refactors in my day-to-day as well to make it adhere to the principles. Amazing work!
Thanks, glad to hear you like it. It was indeed quite a challenge to have the example make sense for each of the five principles and also be explainable in that order 😁.
uncle un·cle a) the brother of one's father or mother b) the husband of one's aunt or uncle c) annoying, pipe-smoking computer scientist.
PS. don't forget to check out the gag reel at the end! ;)
the way you walk through examples is brilliant!
the way code is structured has always fascinated me to no limit, and seeing a live rework done this well is a gem to watch!
i have started to use composition over inheritance for vast majority of cases for a while now due to it being more flexible.
and you can apply inheritance to composition as well, so its the best of both worlds in a lot of cases
Thank you very much! I’m happy you’re enjoying the content. I fully agree regarding inheritance vs composition. I went through that same process a while ago.
17:15
It looks like the code in this example violates the Liskov Substitution Principle.
We have a base class named Authorizer which is basically an interface. In our client-code we depend on it, waiting that its subclass won't force us to change anything because of a different implementation (verify_code, not_a_robot). You should've specified an abstract method in the base "Authorizer" class and implement it in subclasses. Correct me if I'm mistaken.
Good quality set, good camera, good clear concise speaker, good audio, good editing, good music, good examples, good explanations, good pacing. Good video. Probably one of the best SOLID vids out there
This is the first video I've seen clearly explaining LSP, how and why it's used, and its violations. Great job.
Glad it was helpful!
Someone in Python who is discussing SOLID! All I can say is "Solid man!"
Thanks! :)
@@ArjanCodes No worries. Really dude, you seem to be the only one doing intermediate level stuff in python. All other intermediate stuff is in C, C++ C#/Java etc... but there are so many people learning to code with python (Go and Rust are looking exciting as well, oh and JavaScript) and need to learn how to write clean code. You are making the world a better place with this channel. So thank you.
Please also setup a Bitcoin Lightning wallet (Wallet of Satoshi mobile app is good) and show the code in a video so we can donate to you for no fees (everyone charges too much fees when we try to tip guys like yourself.)
@@adjbutler watch the Clean Code series by Uncle Bob, "Coding a better world together".
You have an incredible talent to explain things clearly and in a very pedagogical way. Your channel is a gem.
I have watched many SOLID priciples videos on You Tube and this is by far the best one. Thanks for all the efforts you put in these videos to share your deep knowledge with the world !
Thank you so much, glad you liked it!
This channel is super helpful and quite frankly deserves much more appreciation and attention.
I'm happy the channel is helpful to you - please spread the word! ;)
Finally, Solid Content about the SOLID principles in Python 👏👏👏
Nice to finally see a solid video without using the employee pay calculatkr example
Well written, good presentation, high production value.
This is easily the best programming advice channel on RUclips.
Everybody should subscribe to this.
Suddenly discovered this channel and now addicted to this. Please continue the good work.
I like your examples. They so precisely chosen to illustrare the problem at hand. They are neither too complex nor too simplistic. Kudos!
Thank you Vladimir, I do pay a lot of attention to creating the right examples - At the moment I think it's about 2/3 of the work that goes into producing a video.
Some thoughts about Liskov substitution example. Turns out, that if we move a specific parameter (security code or email) to the initializer, then we have to create a new instance of the class for each payment? Doesn't sound like a good approach
Best channel on RUclips for software design and architecture, Man you just saved us from those weird and complicated tutorials.
Glad to help!
Your Code example is chosen perfectly and your explanations are on the point. No waffleing, just the pure information in an easy to understand language. Great stuff.
Just a small side note if anyone reads this, what he shows as the variation of interface segregation is actually not composition, it is segregation. If each of the payment processors CREATED the smsAuth inside of the class, it had been composition, there is some kind of important detail here! :) Anyways, awesome video! :D
This is exactly what I have looking for in understanding OOP concepts in full picture in many years.
Thanks, glad you found it helpful!
this is exactly the channel I was looking for for a year, thanks for this great solid content!!
This was a great video, thank you. The composition step, after Interface Segregation and Dependency Inversion, looks a lot like Dependency Inversion. I had expected you to use a mixin on the subclass, but instead you added authorizer argument to the initializer. When I think of composition, I usually think of mixins. Can you touch on the pros/cons of mixins, versus adding functionality through the initializer, in the context of composition?
Hi Connor, thanks! I don’t use mixins very often, for a few reasons. First, they don’t adhere to what a parent-child class relation means in traditional OO programming (the ‘is a’ relationship). Second, I don’t like how mixins potentially create strange coupling issues, for example mixin A might define a method X, mixin B uses that method X, and finally, a class C then inherits from both A and B to combine the two. But at the same time, both mixins A and B can’t be used independently in a meaningful way. I much prefer composition/association (a ‘has a’ relationship), which models the dependencies explicitly and doesn’t break OO philosophy.
@@ArjanCodes Thank you, that sounds like a pretty good reason to avoid mixins, then. Come to think of it, I recall running into unexpected behavior when I used multiple mixins in one class. In Python, the order in which you include mixins affects how the child class works. Thank you for taking the time to address my question.
This is amazing stuff. I've been having hard time finding python tutorials that covers more than just the basics. Thanks a lot Arjan!
You're most welcome - glad you like it!
perfect explanation for this problem. To the point, with practical examples. Others are using 1000 words to beat around the bush. Love your explanation style
Hi Arjan. I just wanted to thank you. There is material in SOLID to talk about for hours, but you have done a great job of distilling the fundamentals in a less than 20 min video with a very clear and didactic python example. Kudos and Thank you very much! 😊
You are most welcome
You have a gift of making this stuff understandable using real examples . I enjoyed your course as well. Great stuff
Thanks you so much Dave. Glad that you like the video.
Loving all the best-practice examples and patterns! They're really helping me get off the ground with my latest personal project of building a chess enginer B) Thanks for all the good content!
Great to hear, Tyler! Good luck with your personal project, sounds like a nice topic to dive into!
I really didn't want to subscribe to yet another tech channel but this content is truly high quality. Congratulations and thank you.
Thanks! And glad you're here!
The most understandable video on SOLID I have ever seen,
thanks a lot!
And every time I am amazed how much simpler and more readable Python code is than JavaScript :},
there is no nested curly braces hell...
New(ish) to python. Have been struggling to wrap my head around (and use) SOLID principles for years. This video made BOTH much clearer. Thanks Unkl Arjan!
Thanks so much Tim, glad it was helpful!
The only video I understood on SOLID. Keep up the solid work!
Glad it helped!
Best explanation & example of SOLID principle I ever found on RUclips.
Thank you so much for making this video
I start learning design principles and design patterns and I have discovered your YT channel, I think, nothing better could me happen. Nice code, nice explanations and very good inspiration to studying. Thanks for alls.
That is wonderful to hear, Peter! I'm glad the content has been helpful :)
I have a question regarding the second part, let's say the pay() for all the subclasses have a few similar lines of codes, what do you think is the best option here, to repeat these lines, group them into a separate functions and call them or use .super() the mother class then add the rest of code (which is different in each subclass)
Being a self taught dev, this channel has been very helpful in my growth
Thanks so much Ebuka, glad it was helpful!
I will begin a new job next week and really need to refresh my programming skill. Have to agree with all the comments here. Exactly what I have been looking for.
A+ for your great work!
Glad the video was helpful in your learning journey! :)
This is the best demonstration of SOLID principles.
You've done one of the best SOLID explains I ever saw. Your code and explanation is really understandable. Wish I could have such teammate as your. Thank you!
Thank you so much!
Big Like!! I'm Senior JS developer, recently moving to AI career after PhD in the field. My problem was that I don't know enough Python (especially clean code). I found your channel very helpful as a starting point so I don't have to waste my time learn Python programming from scratch as it's the first time I program. 😅
I've seen this video and followed it's examples several times. Thank you so much for this!
Great Job. Not easy to find a example small and compact yet enough to show how the idea works out. I was ready to procrastinate but the pace was so good it kept me on the seat!
Probably one of the best channels on Software Engineering/Development out there! Great job Arjan!
For me this was one of the best videos that I found to explain SOLID principles! Kudos to you!
OMG, I truly think this is the best SOLID video!!!!
one of the best programming/ software design explanation channel. Keep this up. You vids really clear explain and easy to understand example. Really appreciate the afford.
I am really glad to find this channel by the beginning of the 2022. Thank you very much for the wonderful content. You deserve 100+ Millions subscribers.
You're so kind - I'm happy you like the videos!
If I'm not mistaken the pattern you choose to use instead of creating a new interface for the SMS Processor (favoring composition over inheritance) is the Strategy Pattern, this pattern defines a family of algorthms across different concrete classes and can be interchanged at runtime by the class that requires them.
Great explanations and examples @ArjanCodes, as always :) however I noticed something I had always been told was not very highly-advised:
at 12:37 you set a class attribute `authorized`, which you then modify at instance-level in the method `verify_code`. I thought setting class attributes like this was risky because you could in theory directly modify the class attribute, which could globally overwrite the attribute in instances of this class. Instead I guess it should go in the init method for the class, making it instance-level... But quite likely I'm missing something crucial here. Any thoughts on this?
You are right, thats a mistake.
I assume that @ArjanCodes actually intended to use a DataClass here in which case it would be an instance variable otherwise he should have placed it in __init__ .
But I guess the topic and point of the video (i.e. principles of software architecture ) is looking at the bigger picture and assumes that the target audience already understands basic concepts like cls vs instance variables...
Then again, the man is clearly a masterful programmer who is more knowledgable that 99.99% of us in the comments section so let me not be so bold as to say its him who is mistaken and not me who is missing something :D
Arjan, thank you so much for your content. I've been learning so much form you over the past month!
Thank you - glad you like the content!
For the interface segregation principle, in Python, wouldn't you rather split up the PaymentProcessor into 2 abstract classes and use multiple inheritance to require both functions? As a mixin?
Absolutely love your explanation. I bought a Design Patterns book and your pedagogy was an amazing overview of what I can dive deeper into.
Love it! Posse of One! Uncle Bob was one of OG agile manifesto signatories.
One of the best videos out there on design patterns in Python! Instantly subscribed!
Awesome, thank you!
It is amazing, this videos are been so helpful for my first job in a US company (From South America). Thanks a LOT!!
Very happy to hear that the videos have been helpful to you!
Lekker bezig Arjan!
I admire your discipline and consistency of doing a video every Friday. That's the way to grow. It's great to see you covering higher level topics like design principles / architecture / clean code in the context of Python, which is not common here on yt.
I just happen to be reading Bob's 'clean architecture' book right now after finishing 'clean architectures in python' and `architecture patterns in python` (all great) because I've started designing a complex piece of software for my startup and want to keep it clean & maintainable.
Uncle B writes there's a bit of misunderstanding about the SR principle. People tend to think a module/class should "do only one thing". That is a good principle too, but SR originally means a module/class should only be responsible to one "user" or "stakeholder". I guess that's the group of humans (or robots) that ends up using the business logic described by the code, not sure if I understand it 100% myself. But it's ok if a class does a bunch of different things, as long as it's being done serving a common goal. This way the class only has one "reason to change" and that's useful.
Curious to see what else you have in the pipeline. If you need suggestions, going deeper into Clean Architectures, TDD, Event Driven, if you resonate with those, would be amazing 👌
Dankjewel Richard!
You make a good point that having a single responsibility doesn’t mean doing only a single thing. In the example, the order class also has multiple methods doing different things. In my experience, how responsibilities are divided over classes is for a large part decided by the structure of the data. For example, moving the total price method outside of the order would introduce a lot of coupling, because it needs to know a lot of details about the order data, which is not the case for payment processing.
Thank you very much for those suggestions, keep them coming! I’ll add those to my list of video ideas (which is getting quite large).
Besides my comment on Single Responsibility -->> you actually do great intro presentation of SOLID - your simplifications make good sense. THX!
I have taught pro developers code quality (including SOLID and its package principle siblings) for decades. I appreciate when you manage to introduce potentially complex topics to developers that are new to the topic. I know how difficult this can be based on own successes and failures. You earned yourself a new subscriber!
Thank you so much! I remember when I prepared this video, getting the example to make sense was a real challenge.
@ArjanCodes , I will watch your back catalog, albeit takes a while being busy myself.
Looking forward and ready to share tips/tricks/experience
Great video, I like to come back here every once and a while to refresh
Thanks Tom, glad you like it!
thnx alot now i fully understood the Dependency inversion principle, it finally clicked
Glad it helped!
Man, you made the best video about SOLID, thanks!
Glad you liked it!
Best SOLID explanation video! I came from JS/TS, but I could totally relate how I can implement those principles into my code.
Glad you enjoyed it!
You're my favourite python youtuber! Always great examples and beautiful code
Thank you so much 😊
Thanks, Arjan, for a brilliant, clear exposition of SOLID with simple, tangible examples. Like with your excellent 'smelly code' videos it's a good lesson in how one should brutally and with malice aforethought refactor, refactor and refactor until your code is concise, readable and makes you giggle out loud because its soooo pretty and smells beautiful! Your team will will use & love your code and you may well be surprised how reusable and extensible it is in the future. It may take a bit more time up front than just going with the first hack that runs and spits out a (probably) correct answer (i.e., as is most 'engineering' analyst Python, Matlab, Perl, R, etc etc etc), but your future self will thank you for it. cheers!
I got a real understanding of the SOLID principles the first time I watched this video (well... I had to rewatch it a couple of times 😂), and I've been applying them in my code ever since with really noticeable improvements; moreover, today I gave a talk at my job on this topic based mostly on the things I learned from this video and it all went super good. Thanks for the fantastic content and keep up the great work Arjan!
Thank you kind sir. Clear, Calm and Humane. Just what I’m looking for right now.
Hi Arjan, I really like your video. I learned 5 principles in less than 20 mins with good examples. However, could you elaborate a little bit more about what will happen if we DO NOT follow those principles? This will make the impact of those principles more visible. Thank you.
Thanks Arjan for explaining the advanced concept in programming with code.. this channel really help to take leap from intermediate level to expert level..
Single Responsibility Principle is often misunderstood and I think it happened again here in the common way which is to conflate it with separation of concern. SRP is a people-focused problem whereas SoC is a modular cohesion problem. The examples given in Uncle Bob's book explains it pretty well. In short, it addresses an issue where you have multiple different stakeholders giving you requirements for the same package/service/etc -- in DDD you would see this as an invalid overlap of subdomains. For example, when payroll and Human Resources have cause a conflict in the same "employee" table as they have a different definition of "salary" and how its calculated (or if it's calculated at all; it might static). SME/VP 1 says you have to do it one way whereas SME/VP 2 says you have to do it another way which could take the entire department down because of that conflict. Or where Sales and Marketing have two different definitions of "Customer" with different journeys. The entity has more than one reason to change in that you are getting conflicting requirements from what is essentially two opposing forces. So the problem is similar in that the class is conflicted, but with SRP, the conflict is caused by people, and with SoC the problem is caused by low cohesion (actually doing too many unrelated or loosely related things).
Thanks, I read simple architecture, it skimps over the solid principles and only demonstrates the principles on a design level and I really needed some implementation examples!
I thought I was decent in oop, but after watching this video, I am not really that good at applying good design to my code, that helped alot bro, thank you alot, and btw, I love the way you code and the sound of the keyboard and all that stuff.
further more, I would like to point out something hat I w I like about your python videos, it seems like you bring alot of use cases and real world applications for the language which something I always have wanted to do in youtube since no one does it, but now since I found that channel, I can enjoy seeing such great practical content that really does what I always wanted people to do (but probably I will make some videos if I get a new laptop soon).
anyways thanks, I will subscribe with my 4 youtube accounts lol.
This video is worth its weight in gold and this series is amazing! Thanks a lot Arjan! Please do a separate series on the GoF design patterns with Python examples. :D
Glad you liked it Ajay! And thank you for your suggestion. There's definitely more design patterns related content upcoming.
Just came across this channel and it is very informative.
I was following along with this video and with each iteration I was thinking "well, that makes sense" until we got to the 4th.
I then found myself wondering how we changed the code so many times and became lost. 🤣
Clearly I need to watch this video a few more times to be able to get my little head around it.
The video is time stamped and each section I feel is concise. So it should be easy enough.
Thank you for sharing your wisdom!
Thanks for this video, you have a great knack for teaching!
I appreciate that!
Great video! I love all your content, it has been so very helpful! It is so insightful to hear you talk about design concepts *while* you are implementing them with a simple example. In my experience, this is a rather rare feature of programming related educational videos -- most of the time they're focused on outcomes and not principles (and if they are focused on principles, they're seldom integrated into a single example that is refined -- with explanations -- over the course of a video). You have such a great style and approach to these videos!
This is video is a gem that I will return to several times in the future just to check myself on future projects. I initially discovered your channel while looking for some info about the observer design pattern and I just kept watching more because it was really well done. I would love to see some discussions/examples of frameworks like MVC vs other architectures, perhaps as a series where you roll out a small full-stack app. Love your content! THANK YOU for the work that you do!
Thank you @foobar for your suggestions, and I’m very happy that my videos are helping you!
Thanks for making videos this clear. These concepts are quite difficult as a beginner and you make them seem easy.
You're very welcome!
Very clear explanation makes it sound as smth easy to understand.
Thank you, mate.
Good job.
Very good explanation. I found best SOLID explanation till date. God Bless You. Please make some videos on setuptools and other design patterns.
this is the best explanation I have seen so far, I still don't understand it, but i feel I kinda get it better
the best way of solid describing for last 10 prog-year i saw )
You manage to put this topic, which is far from easy to explain, into less than 20 minutes and sill keep it in a good pace while implementing good and easy to follow examples.
You have my respect for that.
The only other course I found so far that is on an equal level is a paid one that is almost an hour in length. "SOLID Principles in PHP" by Jeffrey Way on Laracast.
I've put a link to your video in our intranet and I will trey to make it mandatory for all our devs that they have to watch it at least once :)
Great video, I was looking for a channel that talks beyond the basics of programming for a while, there's a lot to learn here!
Thanks, glad you liked it!
This is so good that my brain synapses rewire for SOLID topic in Software Design
Small suggestion: total price can be: sum(price * quantity for price, quantity in zip(self.prices, self.quantities))
Keep up the good work!
Thanks! Indeed, that’s a nice, short way to do it.
Great work!! Your videos are the best I've seen and what's helped me the most to understand core OO principles for better code design and easy solutions. You're the best at teaching this stuff!
Thank you - glad to hear you like the videos!
really enjoyed this video and how you broke it down! Definitely up there in terms of simplification and seeing a example similar to the real world!
Glad you enjoyed the video!
thank you Bob for this great series. You explain the concepts very clear and concise. looking forward to more episodes.
Perfect explanation. Thanks for your great effort to teach this complicated subject to who wants to know about OOP principles.
Thank you Mehmet, glad to hear you liked it!
EXCELLENT work! Love your videos, so helpful with the examples and explanation. The pace of the video and explanations and sound and video quality are spot on as well!
S - classes must have a single responsibility for a single actor, other actors shouldn't need to modify it for their needs
O - to make changes to a class, extensions must be possible and easy and modifications must be avoided:- use ABC to allow extensions)
L - super-class must be substitutable with subclass (especially method args and outputs):- use dependency injection in the constructor
I - Use finer and not broader interfaces that can be optionally inherited from:- use composition with implementations based on finer interfaces
D - Instead of concrete dependencies, use an abstract depdendency (using an ABC, like an abstract strategy instead of a concrete strategy)
🙃 Really great and brief illustration. Will be watching this way more than once!
Hii Arjan, Your content is brilliant.
I have a doubt, In L(liskov principle) you added initializers in each payment class. so it does not voilates the Liskov's principle but does it voilates Open/close principle as we modified it by addding __init__ method? correct me if I am wrong.
Thanks!!
High cohesion doesn't refer to "do one thing", it's more "don't split too much, keep related things close".
Regarding OCP - it doesn't have to be implemented using inheritance. In fact, a simple interface IPayment and PaymentProcessor processing payments would work better. Open for extension simple means "don't hardcode" (variables, dependencies). Composition is the more common approach of implementing OCP. Some design patterns target it as well - Proxy, Deocrator, Chain of Responsibility.
The rest looks good.
My summary of SOLID is:
Split
Don't hardcode
Don't fake
Very detailed explanation! Thank you so much for making me understand Liskov Substitution principle. This was that tough part fo me.
Wow! I learned so much in just under 20 minutes! Great example too.