GRASP Design Principles: Why They Matter (And How to Use Them)
Vložit
- čas přidán 26. 07. 2024
- In this video, I'll dive into the GRASP design principles and explore why they matter when designing software systems. By understanding these principles, you'll be able to write better code that's easier to maintain and extend.
Example code: github.com/ArjanCodes/2023-grasp.
🚀 Next-Level Python Skillshare Class: skl.sh/3ZQkUEN
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
💻 ArjanCodes Blog: www.arjancodes.com/blog
🎓 Courses:
The Software Designer Mindset: www.arjancodes.com/mindset
The Software Designer Mindset Team Packages: www.arjancodes.com/sas
The Software Architect Mindset: Pre-register now! www.arjancodes.com/architect
Next Level Python: Become a Python Expert: www.arjancodes.com/next-level...
The 30-Day Design Challenge: www.arjancodes.com/30ddc
🛒 GEAR & RECOMMENDED BOOKS: kit.co/arjancodes.
👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!
💬 Discord: discord.arjan.codes
🐦Twitter: / arjancodes
🌍LinkedIn: / arjancodes
🕵Facebook: / arjancodes
📱Instagram: / arjancodes
♪ Tiktok: / arjancodes
👀 Code reviewers:
- Yoriz
- Ryan Laursen
- James Dooley
- Dale Hagglund
🎥 Video edited by Mark Bacskai: / bacskaimark
💻 Code example by Henrique Branco: / henriqueajnb
🔖 Chapters:
0:00 Intro
0:59 Overview
1:23 01 - Creator
4:28 02 - Information expert
7:39 03 - Controller
11:57 04 - Protected variations
14:58 05 - Indirection
17:34 06 - Low coupling
20:43 07 - High cohesion
24:26 08 - Polymorphism
28:43 09 - Pure fabrication
30:07 Retrospective
31:44 Outro
#arjancodes #softwaredesign #python
DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!
👷 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 CZcams! 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!
Please do an individual video for each principle. That way we get a rock solid idea of the principle. Thanks!
As always very valuable material. Thanks Arjan :)
Glad you think so!
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!
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.
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).
Thanks!
Thank you so much!
Great content. Keep it up!
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 CZcams videos about that way to do things are not that many...)
Great video as always!
I appreciate that!
Great video as usual! Thanks!
Thank you!
Greet video, tnk foi this
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!
Invaluable. Thank you.
Thank you - glad you found it valuable!
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!
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!
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)
I love the vehicle video
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!
Final today. One of the topics is grasp. Wish me luck.
Good luck!
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
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
Some of these highlight certain circumstances where SOLID doesn't apply... and, therefore, deepen our understanding of SOLID.... or other sets of principles/patterns.
Awesome as usual!. I didn't receive the email once I enrolled in Code Diagnosis Workshop.
Sometimes issues can occur and in this case the best you can do is to send an email to support@arjancodes.com
Doesn't the creator principle violate the DI principle of solid? Because in add_line_item function you use class Salelineitem directly.
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.
20:39 - I think CreditCard class should inherit PaymentMethod class just like Cash class did.
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.
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!
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.
"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 😊
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
WTF, None the letters in GRASP map to the concept that they describe
i love this video (INDIAN ACCENT)
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.
Awww.... I wanted stupid puns :)
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
Side note: Anyone old enough to remember when GRASP meant .GL files?
Thanks!
You’re welcome!