Event systems are a good example of a design that results in code with low coupling and strong cohesion. This video delves into coupling and cohesion in more detail: ua-cam.com/video/eiDyK_ofPPM/v-deo.html.
Absolutely. I think events are particularly useful in backend systems, where you need to perform different tasks depending on what happens. There's an example in the video about performing tasks such as sending a welcome email after a user has registered. Event systems are very useful for that, since it allows you to group/batch operations. I didn't mention specific backend platforms, but for example Django has something called Signals, which is a variation of an event system, see: docs.djangoproject.com/en/3.1/topics/signals/
@@ArjanCodes Hah! Just used that a couple days ago to keep data in sync between my main database and a search database. In slightly different words I think events make sense particularly when the actual events you are firing don't inherently seem like they belong together (Sending a slack message doesn't seem like it inherently "belongs" with sending an email for example). So when you're effectively just working through "ToDo" lists for a given action. Observer patterns allow you very neatly to create and store such todo lists in the observing object, in this case the subscriber dictionary. Would you agree with that assessment so far?
@@qizhang5749 Especially in backend services, you'll often use asynchronous event management systems like Celery, RabbitMQ, Kafka, ... . Typical use case is that you have a web application where some tasks need to be triggered that could take a while and maybe even shouldn't be part of the web application, just as they need completely different dependencies or hardware requirements. E.g. because the do heavy computations, some machine learning stuff, or just have to make external requests on their own with a high latency, or you'll trigger a batch job and are only interested to get the results, once the job is done. Then one option would be to build up this as microservices, call them asynchronously, fetch the results and deliver from the web application. Works, but it is highly coupled and not very robust if either the web application or the microservices crash or get updated inbetween. Or, you build some stand alone workers doing these jobs, but let them communicate via events. Those jobs will have to communicate back via a job_done kind of event, but in the end, you have a very decoupled, easy scalable (just add more workers if you need more) way to get your jobs done and if the messaging system is persistent and ensures messages get delivered, everything will work even on crashes or system updates. In addition, from a practical point of view, you also get a nice automatic logging of what happens when in your system. Feed the messages into a log aggregation and a dashboard and you can built up dashboards, alerting and ad hoc introspection to your running system, even though it might work distributed or even in different programming languages. The latter, in principle, works also with logging, but this is something you have to do by hand when programming, while an event driven system automatically can keep track of all (important) events, what is really useful in practice. It's definitely better than having to reverse engineer foreigners code in case of problems. This also is very useful for smaller projects. I've been using celery + django admin panel multiple times to easily have all of this from above for close to no extra project costs or exploding tech stack (assuming django already included). You can even fire with django admin panel actions such events or autoschedule some or configure to ignore specific messages and so on.
I love the sense of humour all over the place. Your tutorials are the first ones that actually managed to get me interested in design patterns. Please never stop making videos!
These kinds of tutorials are incredibly refreshing! Thanks, Arjan! Most programming tutorials are about either learning a language, a framework or building some kind of bogus app. These topics are usefull of course, but at a point they will either be too basic or too specific. Your video's are both advanced/expert level AND generic enough to be interesting/educational for a lot of programmers. Kudo's, vriend!
Hi Willem, thank you very much - glad you like the videos! You're absolutely right: I try to create content that is interesting for intermediate/advanced developers but at the same time is not a very specific recipe for something, but a bit more generic.
Clear and useful explanation! Using an observer can be extended to abstract over the event transport. Then you can do things like retry failures or even plug in a distributed pub/sub system. Constructive feedback: I would like if you spent a little time to also cover limitations/drawbacks of the pattern you're discussing in each video, and the circumstances when it would be inappropriate or overkill. Design patterns are tools for architecting software, and it's important to know when each tool is the best for the job, and also when one should look for a different tool.
Arjan if you keep up these videos, this channel is going to explode. As an amateur python user who has gone through some Kaggle courses, freeCodeCamp courses, and primarily written code as a hobby and as a necessity when needs have arisen, these videos are phenomenal and engaging content. I took the time to like and comment, and am subscribing and look forward to future content!
These videos provide so much help for me! As you said, there are a lot of tutorials out there on design pattern recepies but no one really explains when it might be a good idea to use them and their advantages when it comes to get a better cohesion and decoupling your code. This channel is a real treasure trove! Cheers from Sweden
This is my favorite pattern. Event-based programming works amazingly well with micro services and allows you to super easily scale asymmetrically i.e. the ML portion of your architecture vs the I/O portion.
Something to mention is that, especially when used internally, events can obscure the flow of code. In the first code, it was pretty clear, what happens. Using events, since the `subscribe` calls can be anywhere (and anytime), it is not immediately clear which functions actually get called. This is even more difficult with `unsubscribe` in the mix.
@@TheProtein83 write Goodreadable code first and then the documentation. (What if the doc isn`t uptodate? what if you have somebody who reads the Docs only briefly...) the code itself should be readable
Arjan !!! This is like million dollar wealth for me and programmers like me who want to develop their skill from just coding to designing their codes. I must thank you ...for such great contents. Keep the good work and keep showering knowledge to rest of the world.
Great overview! There are tons of use-cases for this, I'm glad to have now seen a concrete example of how to use it. And fun fact, this would have helped me in an interview with Amazon about a year ago!
I love that you showed the UML and explained the concept really well before hand. Event handlers are used in so many places but it is not always clear what is going on when you look at existing usages.
Just wow. Such good practical example of refactor using observer pattern. It really helps because as you said there are lot of examples out there but they are ridiculously simple or not very much useful to fully grasp the advantages of this approach. Definitely your channel deserves subscription so one could become rightful observer :D
I would not have decoupled logging in that way. That feels integral to what the function is supposed to do. And I like logs to be very obviously and simply related to code that's doing the logging. But yes, this pattern is powerful and useful, and the example you chose was (aside from the logging bit) compelling.
This video and the series in general is absolute dynamite! I cannot thank you enough. This is exactly the kind of content I have spent a fortune searching for in books and Udemy courses - and not been able to find. In fact I was beginning to think there was something seriously wrong with what I am doing because no-one seemed to be seeking answers to the problems you are tackling head on. No one seemed to be passionate about smarter ways to compose code to get the job done 'beautifully'. I now tend to think that I know enough to be useful about the language itself, what I was screaming out for is 'technique' , or maybe more formally, the design patterns. You not only describe the design pattern but you are providing the real world context that makes the learning content land squarely and penetrate this stupid old worn out brain of mine. You are addressing problems and challenges that speak precisely to where I am. I have written variations on your starting code scores of times - always realising deep inside that there had to be better ways to achieve beauty. Your content is lighting up those dark places. When you shook your head and said there was a better way - I literally got shivers. How can we support these? Do you have a Patreon? Have you written any books? Have you considered making a video based training course? How can I consume more of what you have to offer? Thank you most sincerely.
I’m happy the videos are helpful to you, and thanks so much for your BMAC support! I’m working on a full blown online course on software design that will come out before Christmas. If you sign up for my email list via my website, you’ll be the first to know when it’s out!
This video really helped! The example using which you have demonstrated the pattern is not just like how to implement observer pattern, but how we can make use of this pattern in a real world scenario. Thank you so much :-)
Another fantastic video Arjan! I've had this exact problem building a machine learning system: someone uploads new data, then I want to train a model when X amount of new data is added. The observer pattern looks perfect. PS congratulations on 100k!
Good overview. I tend to use Enums with specific single byte values rather than strings for the sake of smaller packed messages, either when storing or when transmitting over a network.
Really like this pub/sub variation of Observer. It it seems to achieve much lower coupling via cleaner separation of concerns for most practical implementations. This has inspired me to consider the Observer pattern more often.
I have been learning Python for 10 years. Lately I got a bit frustrated because I wanted to increase my Python Level from medium to more Profesional but most of the courses and posts are focussed on entry to mid level programming. I love you videos, you tackle more advanced topics but still in a very accesable way. I am keeping an eye on this channel.
I swear, I saw his subscriber count this morning it was 100K, approximately 18hrs later it's 101K. Nice one, I really love these videos they make me feel like senior developer.
Another cool application of events is that it's straightforward to add debugging instrumentation, say, write a func that lists all events that are registered to, and another one allowing to set breakpoints programmatically when a given event is posted.
That's a great pattern and is also compatible with queues or API calls... the only thing I do differently is that each "listener" will also be responsible of subscribing instead if having a centralised file.
OMG, this is a life saver, as a self-taught developer, this was something that I always encountered throughout my coding journey. This must be something that I can help make my life easier, thank you so much.
Very good explanation of the observer pattern and how to apply it also in the backend. The explanation of the solution, how it works and how to write it and structure it, was flawless in my opinion. Only suggestion I had would be to maybe to explain the pattern of the problem better, to give the viewer an easier time spotting where applying the solution could be useful.
A very good explanation! I have been trying to learn design patterns for awhile and this is one of the most understandable examples I have ever seen. Thank you!
This is such a useful pattern that can be applied in so many of the automations I work on day to day. Thank you for the wonderful content you create on this channel!
Never seen anything from this channel before, but have seen tons of videos on patterns (and used many of them for ages in my work). My reaction to this video was WOW - this is probably the best pedagogical approach I’ve ever seen, ever! I am now a subscriber and will definitely check out the rest of your demonstrations. Very well executed!
Years ago I had to work on legacy code that had been modified by newbies and experienced developers for more than 10 years. Making any changes to the code would break other code. To add new features or fix some bugs I came up with something similar to the observer pattern but for data, a DataSubscription class. If a procedure was called from another procedure high up in the call stack and I needed to send or receive data between procedures I would use that class instead of using global variables. Passing the data as args was not possible because there was so many paths it could take and it may have been called by another procedure high up in the stack that does not need to send or receive the data. I also used it as a flag to change the behavior of a procedure depending on if a subscription exists or not. I got really good at adding new features and fixing bugs without adding new bugs. The down side was since I was so successful with legacy code I was not put on new projects that used more modern programming languages like C#.
Great video. I wish you would mention common problems with event systems as well. Like call back hell & unreadable error messages (tracebacks). It would be easy to introduce change to such system. But the cost of search for a specific place where this change need to be made - would be a huge headache.
This was perfect! I've been using C# for about 20 years and always used a pub/sub event aggregator and was hoping there was something similar in Python.. and this was a great example of it.. will be using this right away.. The native event handling in .NET was always confusing and hard to follow.
I agree with the closing comments. Just following a tutorial is insufficient. I want to hear / discuss / dialog more about the whys. This video is terrific synaptic sugar.
I already do patterns OOP, etc in other languages. But my Python has always been for very short scripts only... trying to "up my Python game", these little tutorials are really useful. :) Your screens are very readable too... which certainly isn't the case with many tutorials on UA-cam... And you delivery the voiceover with a sane, calm style too... all in all, very good... keep up The Great Work. This is the first programming tutorial series where I haven't thought "Who is this annoying (random insulting term)? I can't bear to watch this!"... look I've even subscribed.
One thing i would add to this is instead of using string event names you could use enums and group them by type. That way it will be easy to see which events are available. Great content!
Great explanation of the pattern. I think It would be also good to mention a few of the most popular technologies that are used in event driven systems f.eg: Apache Kafka. I'm not sure what is the common solution for use with python based microservices outside of platforms like AWS.
Great video. In my view, this is an abstraction. Event abstracts the messaging services into two functions: register and post. It hides the detailed implementation internally.
Although this has made the code easier to change, it has also made it harder to read - since figuring out which side-effects occur when a new user is registered requires looking in multiple files. I guess there is always a tradeoff being made when using these kinds of patterns.
I had to scroll a lot to find this comment. You are absolutely right. Code like this is much less obvious. I would in the past, but these days I would never reach for a pattern like this, unless I was building a modular system - something that gets deployed with many different configurations. The original code was more readable, easier to understand, and already factored so you could comment-out each function call with a line of code. In a large system, there is maybe an argument to be made about testing too - but that was never even mentioned here.
@@RasmusSchultz The decoupling does sometimes help. He did mention that it makes it easier to disable Slack: comment out the single line that registers Slack handlers, instead of having to comment out the Slack call in each event implementation. Essentially we're restructuring the code and slicing it in a different dimension, which makes some things easier but other things harder. Still I would have liked him to discuss the drawbacks and when using the pattern is inappropriate or overkill.
@@fat_pigeon You could replace the implementation of the Slack call with a no-op. That's pretty much the equivalent effort. Granted, it _does_ mean completely removing the Slack calls is more effort if you decide to do it later.
@@fat_pigeon Well, sure, but I assumed we were talking about removing it temporarily for whatever reason (e.g. debugging, in-house experimental testing, etc.), in which case, broken unit tests are a non-issue. But if we're talking about it being a more common thing, we should be making it configurable, for which there are multiple good approaches.
I'm a largely self-taught developer and felt a lack of competent feedback when coding. So even after years of coding practice, your videos give me some food for thought. Thanks for your videos!
Great video thanks so much! I am new to programming and python but I have recently finished some of my first projects. I see that I have a lot of things I could do to go back and improve. My first script was one giant for loop with no functions and like 1000 lines, then my next project was built with classes and functions but my main function is still 400 lines. Going to see if I can go back some time and really cut that down, add in unit testing, and then think about the design better. I hadn't considered these events or abstract classes and I could see that being very useful as these programs grow.
I really liked your presentation; you struck a great balance between practical real world example and a toy example. The pacing wasn't too fast, the code was easy to read with the dark theme, and your English is excellent (which is important for monoglots like me). Could you help explain how the listener/observer model is not the same thing as the MVC pattern? They seem very similar
Thank you very much! An MVC video is in the works actually as a part of this series, but in short: MVC is more of a software architecture pattern in that it defines the main roles in an application (model = data, view = what the user sees, controller = business logic). Event systems/observer/listener is a specific design solution for decoupling a piece of an application that updates something (e.g. register a new user) and another part that needs to do things following that (e.g. send a welcome email).
Thank you for this playlist. It is very coherent and at a good pace. I have sent then around my local python group. Looking forward to more in the series. :-)
This pattern can be made even more powerful if it works asynchronously. Especially if it's being used in UI. You don't want your UI to freeze while costly functions are running, but you want some progress indication.
Absolutely! I’m also using async events in our backend to start processes like sending emails and then the request handling code doesn’t have to wait for it.
Hi, I really liked the way you have shown the pattern applied in a real-world scenario. I was stuck in implementing this design pattern. Thank you. Please If you can make a playlist of all the Design patterns and implementation of that using python for a real-world scenario.
Event systems are a good example of a design that results in code with low coupling and strong cohesion. This video delves into coupling and cohesion in more detail: ua-cam.com/video/eiDyK_ofPPM/v-deo.html.
Any real world use cases in python systems?
Absolutely. I think events are particularly useful in backend systems, where you need to perform different tasks depending on what happens. There's an example in the video about performing tasks such as sending a welcome email after a user has registered. Event systems are very useful for that, since it allows you to group/batch operations. I didn't mention specific backend platforms, but for example Django has something called Signals, which is a variation of an event system, see: docs.djangoproject.com/en/3.1/topics/signals/
@@ArjanCodes Hah! Just used that a couple days ago to keep data in sync between my main database and a search database.
In slightly different words I think events make sense particularly when the actual events you are firing don't inherently seem like they belong together (Sending a slack message doesn't seem like it inherently "belongs" with sending an email for example). So when you're effectively just working through "ToDo" lists for a given action. Observer patterns allow you very neatly to create and store such todo lists in the observing object, in this case the subscriber dictionary. Would you agree with that assessment so far?
@@qizhang5749 Especially in backend services, you'll often use asynchronous event management systems like Celery, RabbitMQ, Kafka, ... . Typical use case is that you have a web application where some tasks need to be triggered that could take a while and maybe even shouldn't be part of the web application, just as they need completely different dependencies or hardware requirements. E.g. because the do heavy computations, some machine learning stuff, or just have to make external requests on their own with a high latency, or you'll trigger a batch job and are only interested to get the results, once the job is done. Then one option would be to build up this as microservices, call them asynchronously, fetch the results and deliver from the web application. Works, but it is highly coupled and not very robust if either the web application or the microservices crash or get updated inbetween. Or, you build some stand alone workers doing these jobs, but let them communicate via events. Those jobs will have to communicate back via a job_done kind of event, but in the end, you have a very decoupled, easy scalable (just add more workers if you need more) way to get your jobs done and if the messaging system is persistent and ensures messages get delivered, everything will work even on crashes or system updates. In addition, from a practical point of view, you also get a nice automatic logging of what happens when in your system. Feed the messages into a log aggregation and a dashboard and you can built up dashboards, alerting and ad hoc introspection to your running system, even though it might work distributed or even in different programming languages. The latter, in principle, works also with logging, but this is something you have to do by hand when programming, while an event driven system automatically can keep track of all (important) events, what is really useful in practice. It's definitely better than having to reverse engineer foreigners code in case of problems.
This also is very useful for smaller projects. I've been using celery + django admin panel multiple times to easily have all of this from above for close to no extra project costs or exploding tech stack (assuming django already included). You can even fire with django admin panel actions such events or autoschedule some or configure to ignore specific messages and so on.
I love the sense of humour all over the place. Your tutorials are the first ones that actually managed to get me interested in design patterns. Please never stop making videos!
Thank you Matheus, I’m not planning to stop, no worries ;).
Arjan: "I'm going to show you how to use the Observer pattern…"
Me:
These kinds of tutorials are incredibly refreshing! Thanks, Arjan!
Most programming tutorials are about either learning a language, a framework or building some kind of bogus app. These topics are usefull of course, but at a point they will either be too basic or too specific. Your video's are both advanced/expert level AND generic enough to be interesting/educational for a lot of programmers. Kudo's, vriend!
Hi Willem, thank you very much - glad you like the videos! You're absolutely right: I try to create content that is interesting for intermediate/advanced developers but at the same time is not a very specific recipe for something, but a bit more generic.
Clear and useful explanation! Using an observer can be extended to abstract over the event transport. Then you can do things like retry failures or even plug in a distributed pub/sub system.
Constructive feedback: I would like if you spent a little time to also cover limitations/drawbacks of the pattern you're discussing in each video, and the circumstances when it would be inappropriate or overkill. Design patterns are tools for architecting software, and it's important to know when each tool is the best for the job, and also when one should look for a different tool.
Arjan if you keep up these videos, this channel is going to explode. As an amateur python user who has gone through some Kaggle courses, freeCodeCamp courses, and primarily written code as a hobby and as a necessity when needs have arisen, these videos are phenomenal and engaging content. I took the time to like and comment, and am subscribing and look forward to future content!
Thanks so much - that's really kind. I'm glad you're enjoying the videos!
Never commented on a Programming video before, the way u presented the whole idea made me to comment on. Kudos, and keep up the good work.
Thank you Rishan, that’s so kind and happy you are enjoying it.
Great video! Keep up the great work. Looking forward to watching more.
Thank you so much! :)
Your attention to details, all the way down to the volume of the background music, is immaculate.
This is insane quality content, keep it up !
Thank you so much!
Just want to complement the production quality of this tutorial, both the editing and content are great!
That’s very kind - thank you!
These videos provide so much help for me! As you said, there are a lot of tutorials out there on design pattern recepies but no one really explains when it might be a good idea to use them and their advantages when it comes to get a better cohesion and decoupling your code.
This channel is a real treasure trove!
Cheers from Sweden
Glad you like the videos Mikael!
This is my favorite pattern. Event-based programming works amazingly well with micro services and allows you to super easily scale asymmetrically i.e. the ML portion of your architecture vs the I/O portion.
Couldn't agree more!
Something to mention is that, especially when used internally, events can obscure the flow of code. In the first code, it was pretty clear, what happens. Using events, since the `subscribe` calls can be anywhere (and anytime), it is not immediately clear which functions actually get called. This is even more difficult with `unsubscribe` in the mix.
Correct, the event model can sometimes get confusing. It becomes problematic when multiple events fire off for the same action.
Usually this is solved writing good documentation
@@TheProtein83 write Goodreadable code first and then the documentation. (What if the doc isn`t uptodate? what if you have somebody who reads the Docs only briefly...) the code itself should be readable
Arjan !!! This is like million dollar wealth for me and programmers like me who want to develop their skill from just coding to designing their codes. I must thank you ...for such great contents. Keep the good work and keep showering knowledge to rest of the world.
Hi Manu, thank you - I’m glad to hear you like the content!
Great overview! There are tons of use-cases for this, I'm glad to have now seen a concrete example of how to use it. And fun fact, this would have helped me in an interview with Amazon about a year ago!
Thank you Mark, and that’s an interesting story. So did you get the job? :)
I love that you showed the UML and explained the concept really well before hand. Event handlers are used in so many places but it is not always clear what is going on when you look at existing usages.
Happy you are enjoying the video, Richard!
Is it a coincidence that I started reading the same book about Design Patterns and I suddenly come across your channel? Brilliant.
Just wow. Such good practical example of refactor using observer pattern. It really helps because as you said there are lot of examples out there but they are ridiculously simple or not very much useful to fully grasp the advantages of this approach. Definitely your channel deserves subscription so one could become rightful observer :D
I would not have decoupled logging in that way. That feels integral to what the function is supposed to do. And I like logs to be very obviously and simply related to code that's doing the logging.
But yes, this pattern is powerful and useful, and the example you chose was (aside from the logging bit) compelling.
This video and the series in general is absolute dynamite! I cannot thank you enough. This is exactly the kind of content I have spent a fortune searching for in books and Udemy courses - and not been able to find. In fact I was beginning to think there was something seriously wrong with what I am doing because no-one seemed to be seeking answers to the problems you are tackling head on. No one seemed to be passionate about smarter ways to compose code to get the job done 'beautifully'.
I now tend to think that I know enough to be useful about the language itself, what I was screaming out for is 'technique' , or maybe more formally, the design patterns. You not only describe the design pattern but you are providing the real world context that makes the learning content land squarely and penetrate this stupid old worn out brain of mine.
You are addressing problems and challenges that speak precisely to where I am. I have written variations on your starting code scores of times - always realising deep inside that there had to be better ways to achieve beauty. Your content is lighting up those dark places. When you shook your head and said there was a better way - I literally got shivers.
How can we support these? Do you have a Patreon? Have you written any books? Have you considered making a video based training course? How can I consume more of what you have to offer?
Thank you most sincerely.
I’m happy the videos are helpful to you, and thanks so much for your BMAC support! I’m working on a full blown online course on software design that will come out before Christmas. If you sign up for my email list via my website, you’ll be the first to know when it’s out!
I really appreciate that you built the event system to show its internal workings instead of using an existing library, thanks!
This video really helped! The example using which you have demonstrated the pattern is not just like how to implement observer pattern, but how we can make use of this pattern in a real world scenario. Thank you so much :-)
You're welcome - glad you enjoyed the video!
Another fantastic video Arjan! I've had this exact problem building a machine learning system: someone uploads new data, then I want to train a model when X amount of new data is added. The observer pattern looks perfect.
PS congratulations on 100k!
Thank you. I'm looking forward to the rest of the series. This type of content is rare, much needed and much appreciated!
Thank you and glad that you’re enjoying the videos!
This channel became my favorite python channel. Thanks for your work, I'm learning a lot!!!!
Great to hear!
I don't even code in python professionally yet I've subscribed. You're genuine and well-rounded lecturer
Thank you for these kind words! Welcome aboard, Ivan.
Good overview. I tend to use Enums with specific single byte values rather than strings for the sake of smaller packed messages, either when storing or when transmitting over a network.
I feel honored to have found your channel when you are still so new. You are amazing at explaining these things so thank you!
Thanks!
Really like this pub/sub variation of Observer. It it seems to achieve much lower coupling via cleaner separation of concerns for most practical implementations. This has inspired me to consider the Observer pattern more often.
Happy to hear you enjoyed it!
I have been learning Python for 10 years. Lately I got a bit frustrated because I wanted to increase my Python Level from medium to more Profesional but most of the courses and posts are focussed on entry to mid level programming. I love you videos, you tackle more advanced topics but still in a very accesable way. I am keeping an eye on this channel.
Thank you so much, glad you like the videos!
I swear, I saw his subscriber count this morning it was 100K, approximately 18hrs later it's 101K. Nice one, I really love these videos they make me feel like senior developer.
Another cool application of events is that it's straightforward to add debugging instrumentation, say, write a func that lists all events that are registered to, and another one allowing to set breakpoints programmatically when a given event is posted.
That's a great pattern and is also compatible with queues or API calls... the only thing I do differently is that each "listener" will also be responsible of subscribing instead if having a centralised file.
OMG, this is a life saver, as a self-taught developer, this was something that I always encountered throughout my coding journey.
This must be something that I can help make my life easier, thank you so much.
15 minutes well spent! Thank you!
Very good explanation of the observer pattern and how to apply it also in the backend.
The explanation of the solution, how it works and how to write it and structure it, was flawless in my opinion.
Only suggestion I had would be to maybe to explain the pattern of the problem better, to give the viewer an easier time spotting where applying the solution could be useful.
A very good explanation! I have been trying to learn design patterns for awhile and this is one of the most understandable examples I have ever seen. Thank you!
You’re very welcome Bryan, I happy you enjoyed the video.
Great content, you're not recycling material that other people do. this is a good original video, subscribed
Thanks for the sub, Pedro. Glad you like the content.
This is such a useful pattern that can be applied in so many of the automations I work on day to day. Thank you for the wonderful content you create on this channel!
Never seen anything from this channel before, but have seen tons of videos on patterns (and used many of them for ages in my work).
My reaction to this video was WOW - this is probably the best pedagogical approach I’ve ever seen, ever! I am now a subscriber and will definitely check out the rest of your demonstrations.
Very well executed!
Thank you Mikael, glad you like it!
Arjan really great work my man! I'm enjoying your series here
Loved your way of explaining the complex concepts in easier way. Thank you ♥
Years ago I had to work on legacy code that had been modified by newbies and experienced developers for more than 10 years. Making any changes to the code would break other code.
To add new features or fix some bugs I came up with something similar to the observer pattern but for data, a DataSubscription class. If a procedure was called from another procedure high up in the call stack and I needed to send or receive data between procedures I would use that class instead of using global variables. Passing the data as args was not possible because there was so many paths it could take and it may have been called by another procedure high up in the stack that does not need to send or receive the data. I also used it as a flag to change the behavior of a procedure depending on if a subscription exists or not.
I got really good at adding new features and fixing bugs without adding new bugs. The down side was since I was so successful with legacy code I was not put on new projects that used more modern programming languages like C#.
Great video. I wish you would mention common problems with event systems as well. Like call back hell & unreadable error messages (tracebacks). It would be easy to introduce change to such system. But the cost of search for a specific place where this change need to be made - would be a huge headache.
Thanks! And that’s a good suggestion to cover in a followup video.
This was perfect! I've been using C# for about 20 years and always used a pub/sub event aggregator and was hoping there was something similar in Python.. and this was a great example of it.. will be using this right away.. The native event handling in .NET was always confusing and hard to follow.
I agree with the closing comments. Just following a tutorial is insufficient. I want to hear / discuss / dialog more about the whys. This video is terrific synaptic sugar.
Thank you Brian, happy you liked the video.
Fantastic Video! I searched for practical design pattern uses in python, I found YOURS!
For me your video was really helpful
Thank you Mehrnoosh, I’m happy that my video helped you.
I already do patterns OOP, etc in other languages. But my Python has always been for very short scripts only... trying to "up my Python game", these little tutorials are really useful. :)
Your screens are very readable too... which certainly isn't the case with many tutorials on UA-cam... And you delivery the voiceover with a sane, calm style too... all in all, very good... keep up The Great Work.
This is the first programming tutorial series where I haven't thought "Who is this annoying (random insulting term)? I can't bear to watch this!"... look I've even subscribed.
Wow, a really nice tutorial: short, to the point and with simple examples.
Great job, thanks! 👍
Thank you, glad you enjoyed it!
best series for learning design patterns!
Thank you!
Yes. You made me think differently about events and the observer pattern. Thank you.
You're very welcome! :)
former web dev coming back to coding later in my career, and these videos are pure gold. 🥇
7:12 you should really use a "defaultdict(list)" instead of those two if conditions
Sweet thinking!
Thank you, and that’s a great tip - I didn’t know about defaultdict, and I’ll definitely start using that more often.
@@sieyk There's no need for imports with dict.setdefault(key, default)
@@levblit3721 you can't set default to an array
@@sieyk you are correct, didn't think of that
The background music is exactly what I listen to when working. It has had me in Pulsemixer trying to work out what is going on several times.
Thanks so much Nick, glad you liked it!
You are a simply amazing teacher. Keep up the good work.
Thank you Vishal, happy you are enjoying the content!
This channel has such an amazing content. Pls continue doing this👍👍👍
This pattern is the mother of decoupling! My favorite GoF pattern!
Thanks, Kevin, Glad that you liked it.
One thing i would add to this is instead of using string event names you could use enums and group them by type. That way it will be easy to see which events are available. Great content!
Good point! I've been using Enums for these kinds of things already in my more recent videos.
@@ArjanCodes I just found your channel, will look through some more of your newer videos aswell. thanks!
Hello Arjan. Could you point me to the actual videos where you enhance this with Enums? Thanks for a great tutorial!
Great explanation of the pattern. I think It would be also good to mention a few of the most popular technologies that are used in event driven systems f.eg: Apache Kafka. I'm not sure what is the common solution for use with python based microservices outside of platforms like AWS.
I hope your channel grows! Also, I recently downloaded your software design guide and I'm already using it for some projects at work!
Happy to hear that!
Thanks!
Thanks so much Brian!
Your content is top notch man. Good job
Thanks so much!
What could be better than illustrative examples! Thank you!
This channel has great value. Thank you
Thank you, glad you like the content!
This is such a great way to write code for this type of use case
Thank you Tim, glad you liked it.
great video, underrated channel
Thanks for your compliments, Drew!
Just found your channel. I like your approach, understanding the why you would apply a certain coding pattern is very helpful, subscribed!
Awesome, thank you and welcome!
These videos have been really helpful -- a bridge between concepts and code. Thank you.
Hi Mike, glad they've been helpful to you.
Great video. In my view, this is an abstraction. Event abstracts the messaging services into two functions: register and post. It hides the detailed implementation internally.
Although this has made the code easier to change, it has also made it harder to read - since figuring out which side-effects occur when a new user is registered requires looking in multiple files.
I guess there is always a tradeoff being made when using these kinds of patterns.
I had to scroll a lot to find this comment. You are absolutely right. Code like this is much less obvious. I would in the past, but these days I would never reach for a pattern like this, unless I was building a modular system - something that gets deployed with many different configurations. The original code was more readable, easier to understand, and already factored so you could comment-out each function call with a line of code. In a large system, there is maybe an argument to be made about testing too - but that was never even mentioned here.
@@RasmusSchultz The decoupling does sometimes help. He did mention that it makes it easier to disable Slack: comment out the single line that registers Slack handlers, instead of having to comment out the Slack call in each event implementation. Essentially we're restructuring the code and slicing it in a different dimension, which makes some things easier but other things harder. Still I would have liked him to discuss the drawbacks and when using the pattern is inappropriate or overkill.
@@fat_pigeon You could replace the implementation of the Slack call with a no-op. That's pretty much the equivalent effort. Granted, it _does_ mean completely removing the Slack calls is more effort if you decide to do it later.
@@bloodgain Except that would break all the unit tests for the Slack implementation, so you'd have to remove those as well.
@@fat_pigeon Well, sure, but I assumed we were talking about removing it temporarily for whatever reason (e.g. debugging, in-house experimental testing, etc.), in which case, broken unit tests are a non-issue. But if we're talking about it being a more common thing, we should be making it configurable, for which there are multiple good approaches.
I'm a largely self-taught developer and felt a lack of competent feedback when coding. So even after years of coding practice, your videos give me some food for thought. Thanks for your videos!
Thanks for sharing!
Great video thanks so much! I am new to programming and python but I have recently finished some of my first projects. I see that I have a lot of things I could do to go back and improve. My first script was one giant for loop with no functions and like 1000 lines, then my next project was built with classes and functions but my main function is still 400 lines. Going to see if I can go back some time and really cut that down, add in unit testing, and then think about the design better. I hadn't considered these events or abstract classes and I could see that being very useful as these programs grow.
This is genuinely high quality stuff. Keep it up!
6:00 this is a really nice use case for a defaultdict. It will automatically create a new list if the key is new.
I really liked your presentation; you struck a great balance between practical real world example and a toy example. The pacing wasn't too fast, the code was easy to read with the dark theme, and your English is excellent (which is important for monoglots like me).
Could you help explain how the listener/observer model is not the same thing as the MVC pattern? They seem very similar
Thank you very much! An MVC video is in the works actually as a part of this series, but in short: MVC is more of a software architecture pattern in that it defines the main roles in an application (model = data, view = what the user sees, controller = business logic). Event systems/observer/listener is a specific design solution for decoupling a piece of an application that updates something (e.g. register a new user) and another part that needs to do things following that (e.g. send a welcome email).
I'm so glad I found you, thank you!!!
Thank you, this really helped me out! I am working on code which handles several APIs, websockets and logging.
Glad it helped!
it's very popular pattern in Python. good job Arjan👍
You are great Arjan. Much love 🤟
Thank you for this playlist. It is very coherent and at a good pace. I have sent then around my local python group. Looking forward to more in the series. :-)
Thank you, Tim, I'm happy you're enjoying it. More will come in the near future ;).
Awesome. Please keep creating content like this. No1 unfortunately teaches them
Thank you - that's the plan! :)
Díky!
Thank you so much!
Great video -- I like the practical application. Look forward to seeing more
Thanks James, happy you liked it!
This example is really practical! Thank Yout for this!
Glad you like it!
very useful to simplify my project, have to come back and reference to this again and again
Thank you - happy the content is useful to you!
one question actually, is subscrber dict object only generated once? I see it is imported a few times.
Awesome video, really nice example to show how to implement this design pattern... Thanks a lot... Keep it up...
Thank you! And will do!
Good pythonic introduction, much better than some authors where it is clear that they would really rather be programming in SmallTalk or Java (spits).
Thank you Scott, glad you enjoyed it!
This pattern can be made even more powerful if it works asynchronously. Especially if it's being used in UI. You don't want your UI to freeze while costly functions are running, but you want some progress indication.
Absolutely! I’m also using async events in our backend to start processes like sending emails and then the request handling code doesn’t have to wait for it.
@@ArjanCodes if you ever update this video, a python async version would be awesome!
Thanks for sharing. It was easy to follow and see the difference in the end result.
Thank you Brian, happy you liked it.
Great tutorial! Thanks for sharing your knowledge with us. It was easy to follow and it's very informative. Keep the good work if you can!
6:10 Consider using dictionaries' .setdefault() method, it replaces lines 4-6 with a clean oneliner
That was an awesome and concise example of the observer pattern. thanks!
Thanks, glad you're enjoying it :).
Great video, I'd love to see more on exception handling using this event system.
Thank you, and great suggestion!
Thanks. Dabbled a bit in JS and I really like the subscriber pattern
Thanks so much, glad you liked it!
Subbed. You have a great way with explaining things! Quality content!
You are great instructor! Bless you and bless internet! Also, you might consider going to pluralsight or people skills
Thanks for sharing that suggestion, and glad to hear you like the videos!
Hi, I really liked the way you have shown the pattern applied in a real-world scenario. I was stuck in implementing this design pattern. Thank you. Please If you can make a playlist of all the Design patterns and implementation of that using python for a real-world scenario.
Thank you! I will definitely cover more design patterns on the channel in the future!
Thank you, Prof. Arjan!
Cool! I should try event-oriented programming in my next project!
Any recommended librairies/frameworks in Python?