Arjan, I’ve been watching your videos for a few years now and they’ve been tremendously helpful in making me become a better engineer. You have a great style of teaching and illustration. Thank you for producing very high quality and accessible content on UA-cam for all of us. I’m incredibly grateful for content creators like you that can help the rest of us learn.
The best GRASP-related video on UA-cam! I traversed more than 20 ones in order to watch practical examples rather than clumsy theoretical declarations scraped from Wikipedia, which makes things even more unclear. Your channel is a pure diamond and I'll stick for here later, because there is a lot of PRACTICAL information. Even despite on I'm Java-developer. Keep going! Thank you. Will share it to friends and mates as a good example of how the things should be practically explained.
I am happy when someone talks about GRASP principles. They not only tell what is the ideal design of the code, but also how to achieve that ideal state.
I think you should show the functional way more often (every time it is applicable). it is very useful (and the UA-cam videos about that way to do things are not that many...)
Thank you for this great video ! TBH the liskov substitution talk more about type than class. In OOP we generally only have classes to define new types so it's mainly about inheritance but it's also possible in FP (especially with algebraic data types)
1.4k views but 129 likes still now... Ridiculous sence of gratitude! Respected, sir 🖖 Your content is Rare star in the universe of coding guru's🌠🌟 🎉🎀 Thank you for your continuous 🎁 Love from gratitude from🇮🇳
Thanks, I enjoyed the video. I think it would be better to let the view call the controller, since in your example the controller is basically the whole use case of the application, thus should not be dependent on view (DI). Also then you can add several views calling the controller without ever changing the controller (OCP). Although these suggestions come from a SOLID perspective.
Not sure what I found more useful in that book "Applying UML And Patterns" -- the design advice with examples, the GRASP principles or the quotes at the start of each chapter. Quotes like, "Le mieux est l'ennemi du bien (The best is the enemy of the good). -- Voltaire"
Great video, as always! You talk a lot about how you'd do lots of functional programming rather than object oriented programming... I'd love to see a video where you compare pure functional, pure object oriented, and a mix of both :) possibly doing the same thing?
Food for thought, each line of code should be responsible for one thing. Or blocks of lines. So, each line/block is a step. A singular step that does one thing.
I've read about them a long time ago. Thanks for your work. Maybe you will be so nice as to cover something form Eric Evans' book. There is a lot of interesting and useful information there, but it may be a bit complicated.
Some of these highlight certain circumstances where SOLID doesn't apply... and, therefore, deepen our understanding of SOLID.... or other sets of principles/patterns.
So what if the behavior of your processing is highly dependent on the data structure? I'm really interested to hear your ideas around recursive algorithms. What kind of design principles are best suited to accommodate such data processing?
There’s a principle that Arjan didn’t mention which is to anticipate change. In the case of tree shaped data, the code can evolve by adding more kinds of trees or by adding more procedures that operate on trees. For example if you represent documents with trees the code might evolve to add more kinds of node, e.g., enumerated lists and description lists as well as bullet lists, or it might evolve to add more recursive algorithms on the trees, e.g., convert to PDF and serialize, as well as layout. When you expect the set of kinds of node to expand but the number of algorithms to be essentially fixed, it makes sense to just implement each algorithm with a method that has a separate implementation in each node class, e.g. bullet list has its implementation of layout, and then so does description list and enumerated list. On the other hand, if the set of kinds of nodes is relatively stable, you can just write each recursive algorithm as a single recursive procedure with a switch (or match) statement at the top level. If change is likely along both axes, I don’t know of a magic solution.
I tend to have a lot of problems with principles, but the creator pattern example is particularly problematic. ie Sale(...) knowing how to create SaleLineItems. Why would you store the creation in the class, which you now have to move if: 1. your language class access modifiers make nesting class creation a problem for testability. In most languages, I can't mock the object creation nested in another class. 2. you want to be able to create SaleLineItems later Following the Creator pattern, an author would aschew placing a creator solely in another class as a matter of code quality due to the obvious advantages of DI.
The Creator principle doesn't prohibit or prevent you from creating new objects from classes elsewhere, it merely suggests where it would be best to do it in your program. SaleLineItems aren't nested inside Sale class - they are just created (instantiated) there. You can always create a SaleLineItem outside of Sale if you want to - but you shouldn't need to.
I hate oo patterns, but always nice to hear you explaining stuff. btw: as per ifnotelse and switch blocks which leads to imperative programming, use declarative approach with protocol class as you explained
Please more examples with only functions. I would even refactor your old videos with a light SOLID or now with a functional GRASP video that pays attention to the power of a simpler Python without classes. Please. Thanks.
someone must have redefined what acronyms are, and not told me. Now they don't have to contain any of the first characters of any of the constituent terms!
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
Arjan, I’ve been watching your videos for a few years now and they’ve been tremendously helpful in making me become a better engineer. You have a great style of teaching and illustration.
Thank you for producing very high quality and accessible content on UA-cam for all of us. I’m incredibly grateful for content creators like you that can help the rest of us learn.
Thank you so much!
I feel like I was drinking from the firehose. A whole semester of CS in one video. This one will require many visits. Bravo.
Thank you so much John!
That's true...😅😅
The best GRASP-related video on UA-cam! I traversed more than 20 ones in order to watch practical examples rather than clumsy theoretical declarations scraped from Wikipedia, which makes things even more unclear.
Your channel is a pure diamond and I'll stick for here later, because there is a lot of PRACTICAL information. Even despite on I'm Java-developer. Keep going! Thank you.
Will share it to friends and mates as a good example of how the things should be practically explained.
My first time encountering GRASP. Now all the previous videos makes sense. Thank you for sharing.
You're very welcome!
Great and comprehensive material, again! I feel that with each of your videos the quality of my software development in Python increases :D Thank you!
Glad to hear it helps you!
As always very valuable material. Thanks Arjan :)
Glad you think so!
I am happy when someone talks about GRASP principles.
They not only tell what is the ideal design of the code, but also how to achieve that ideal state.
Loving the Content! Keep it up! Also looking forward to more Code Roasts! 👍 🙏🙏
Thank you!
Please do an individual video for each principle. That way we get a rock solid idea of the principle. Thanks!
Thanks!
You’re welcome!
Well done sir. Your videos are ones I like before proceeding to watch.
Thank you!
I appreciate you use classes. In engineering software we are not using functions (far away more complex code than what is generally shown in youtube).
Great video as usual! Thanks!
Thank you!
I will make all my coworkers watch this, cause OHMYGOD some people just need to. Thank you so much, Arjan, for this.
Thank you so much!
Really good video as usual! You are basically the reason for me staying on top of our Python-related challenges at work :D
Same here!
Thanks so much Robert!
Great video as always!
I appreciate that!
I think you should show the functional way more often (every time it is applicable). it is very useful (and the UA-cam videos about that way to do things are not that many...)
Thank you for this great video ! TBH the liskov substitution talk more about type than class. In OOP we generally only have classes to define new types so it's mainly about inheritance but it's also possible in FP (especially with algebraic data types)
Great content. Keep it up!
1.4k views but 129 likes still now... Ridiculous sence of gratitude!
Respected, sir 🖖
Your content is Rare star in the universe of coding guru's🌠🌟
🎉🎀
Thank you for your continuous 🎁
Love from gratitude from🇮🇳
Thank you so much SP!
Invaluable. Thank you.
Thank you - glad you found it valuable!
I love the vehicle video
Final today. One of the topics is grasp. Wish me luck.
Good luck!
Greet video, tnk foi this
Thanks, I enjoyed the video.
I think it would be better to let the view call the controller, since in your example the controller is basically the whole use case of the application, thus should not be dependent on view (DI). Also then you can add several views calling the controller without ever changing the controller (OCP). Although these suggestions come from a SOLID perspective.
Not sure what I found more useful in that book "Applying UML And Patterns" -- the design advice with examples, the GRASP principles or the quotes at the start of each chapter. Quotes like, "Le mieux est l'ennemi du bien (The best is the enemy of the good). -- Voltaire"
great videos. really.
Thanks!
Great video, as always! You talk a lot about how you'd do lots of functional programming rather than object oriented programming... I'd love to see a video where you compare pure functional, pure object oriented, and a mix of both :) possibly doing the same thing?
Haha, I hadn't quite finished the video yet
Food for thought, each line of code should be responsible for one thing.
Or blocks of lines.
So, each line/block is a step. A singular step that does one thing.
I've read about them a long time ago. Thanks for your work. Maybe you will be so nice as to cover something form Eric Evans' book. There is a lot of interesting and useful information there, but it may be a bit complicated.
I'll check it out! Thanks
Some of these highlight certain circumstances where SOLID doesn't apply... and, therefore, deepen our understanding of SOLID.... or other sets of principles/patterns.
What VS Code extension do you use to auto complete the code. I see that as you type suddenly the code lines appears from nowhere
So what if the behavior of your processing is highly dependent on the data structure?
I'm really interested to hear your ideas around recursive algorithms. What kind of design principles are best suited to accommodate such data processing?
There’s a principle that Arjan didn’t mention which is to anticipate change. In the case of tree shaped data, the code can evolve by adding more kinds of trees or by adding more procedures that operate on trees. For example if you represent documents with trees the code might evolve to add more kinds of node, e.g., enumerated lists and description lists as well as bullet lists, or it might evolve to add more recursive algorithms on the trees, e.g., convert to PDF and serialize, as well as layout. When you expect the set of kinds of node to expand but the number of algorithms to be essentially fixed, it makes sense to just implement each algorithm with a method that has a separate implementation in each node class, e.g. bullet list has its implementation of layout, and then so does description list and enumerated list. On the other hand, if the set of kinds of nodes is relatively stable, you can just write each recursive algorithm as a single recursive procedure with a switch (or match) statement at the top level. If change is likely along both axes, I don’t know of a magic solution.
at 19:42, why does Cash class inherits from PaymentMethod whereas CreditCard doesn't?
He forgot is all. CreditCard was supposed to inherit from PaymentMethod.
20:39 - I think CreditCard class should inherit PaymentMethod class just like Cash class did.
Doesn't the creator principle violate the DI principle of solid? Because in add_line_item function you use class Salelineitem directly.
It would be better if this was a Playlist of videos
I tend to have a lot of problems with principles, but the creator pattern example is particularly problematic. ie Sale(...) knowing how to create SaleLineItems. Why would you store the creation in the class, which you now have to move if:
1. your language class access modifiers make nesting class creation a problem for testability. In most languages, I can't mock the object creation nested in another class.
2. you want to be able to create SaleLineItems later
Following the Creator pattern, an author would aschew placing a creator solely in another class as a matter of code quality due to the obvious advantages of DI.
The Creator principle doesn't prohibit or prevent you from creating new objects from classes elsewhere, it merely suggests where it would be best to do it in your program. SaleLineItems aren't nested inside Sale class - they are just created (instantiated) there. You can always create a SaleLineItem outside of Sale if you want to - but you shouldn't need to.
I hate oo patterns, but always nice to hear you explaining stuff.
btw: as per ifnotelse and switch blocks which leads to imperative programming, use declarative approach with protocol class as you explained
Please more examples with only functions. I would even refactor your old videos with a light SOLID or now with a functional GRASP video that pays attention to the power of a simpler Python without classes. Please. Thanks.
someone must have redefined what acronyms are, and not told me. Now they don't have to contain any of the first characters of any of the constituent terms!
"and I will try not to making any stupid puns".
Yes, because you don't need to "try". They come just come out 😉
I can’t control myself 😊
WTF, None the letters in GRASP map to the concept that they describe
Nine principles of GRASP
1 - Creator
2 - Information Expert
3 - Controller
4 - Protected Variations
5 - Indirection
6 - Low Coupling
7 - High Cohesion
8 - Polymorphism
9 - Pure Fabrication
i love this video (INDIAN ACCENT)
Awww.... I wanted stupid puns :)
Side note: Anyone old enough to remember when GRASP meant .GL files?