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...)
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 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)
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"
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.
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.
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?
Some of these highlight certain circumstances where SOLID doesn't apply... and, therefore, deepen our understanding of SOLID.... or other sets of principles/patterns.
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 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.
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 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
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!
Loving the Content! Keep it up! Also looking forward to more Code Roasts! 👍 🙏🙏
Thank you!
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.
Please do an individual video for each principle. That way we get a rock solid idea of the principle. Thanks!
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).
Well done sir. Your videos are ones I like before proceeding to watch.
Thank you!
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...)
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!
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!
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 video as always!
I appreciate that!
Great video as usual! Thanks!
Thank you!
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"
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.
Final today. One of the topics is grasp. Wish me luck.
Good luck!
I love the vehicle video
Invaluable. Thank you.
Thank you - glad you found it valuable!
Great content. Keep it up!
Greet video, tnk foi this
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.
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
Some of these highlight certain circumstances where SOLID doesn't apply... and, therefore, deepen our understanding of SOLID.... or other sets of principles/patterns.
Thanks!
You’re welcome!
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
great videos. really.
Thanks!
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.
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.
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
20:39 - I think CreditCard class should inherit PaymentMethod class just like Cash class did.
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.
It would be better if this was a Playlist of videos
Doesn't the creator principle violate the DI principle of solid? Because in add_line_item function you use class Salelineitem directly.
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.
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 😊
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)
WTF, None the letters in GRASP map to the concept that they describe
Awww.... I wanted stupid puns :)
Side note: Anyone old enough to remember when GRASP meant .GL files?