 Welcome to this first pattern now in the design patterns part of this module And the pattern we talk about here is the so-called observer pattern. The idea is that you might have a subject You have some part That you want to display in a certain way And you want to decouple the subject itself from For example the display or the behavior so common cases where you have this is for example a data object that you Want to display and if the data changes you want to update display or For example listeners that you have in many programming languages. You have a button and The behavior when you press the button is a different part So these are common things that so that you can evolve them separately and you can dynamically add For example multiple displays for the same data or multiple behaviors multiple listeners for the same button If you're not familiar with it or if you have forgotten it I would really recommend you to take another look at the class diagram syntax because we'll use that a lot here in Particular the object or at the design patterns that we're going through all make heavy use of inheritance and things like polymorphism that depending on if you call the concrete object the inherited Subtype then depending on the language you actually call the update function down here instead of the original one in the higher class in the parent class So this is a behavioral pattern in the the observer pattern. I'll just walk you through what this means we have a subject That supports Attaching and detaching Observers so you can at runtime call this method and say I am an observer I would like to attach myself to this subject and Then the observer itself has an update method So this is how you tell the observer something has changed now imagine a subject changes For example the data changes you do something in the database What happens then is that you call the notify method of the subject and the notify method of the subject goes through a list of all the observers and For each of these observers it basically calls the update method so by calling notify all of these update methods are called and If you call detach again, the the subject simply removes the observer from the list of existing observers now That's sort of the higher level here. Then you have the concrete Observer and the concrete subject and they actually need to know each other So for example, if you implement a button then you have a button listener that knows exactly what kind of state The the concrete class has if you implement some kind of data structure then this information is here How does the data structure look like and the observer needs to know that? Because if you want to for example, let's say you display a bar chart or a pie chart of that data for that You need to know how the data looks like so that's why we have this line in between here The concrete classes know each other So what happens if I call notify? The update method here is called and the concrete implementation of the observer Then calls the concrete get state functions So basically we tell the observer something has changed and the concrete one says, okay I know what kind of subject I'm dealing with I'll call the get state method and I get back the current state So imagine now this is for example, election data Our concrete class is some kind of implementation of this data structure states parties votes and We have an observer that this place this as a bar chart as you often have Once we call the notify the update one here is called of our bar chart The bar chart knows exactly how the data looks like so it calls to get state method and they get state method Turns the state which is the concrete data structure With the polling information and then the observer updates the display As I said, this is common for example for button listeners So for any kind of listeners actually event listeners and programs so for example here you would have a generic class button and You would have a generic class listener and Down here you would have a concrete implementation of the button and a concrete Implementation of the button listener listener, which is for example the case in Java where you can do these kind of things So that's one common implementation of the observer pattern in practice that you might come across In terms of the solid principles what we see here is on the one hand the the open closed principle So these two parent classes are not made to be modified. They're kind of fixed So they're closed for modification, but they're open for extension. So the idea is that you add Things on top of them. That's the open close principle in practice basically and the other thing we have here is Liskoff substitution so The Abstract type subject and observer we cannot any time replace with concrete Implementations and the behavior should remain the same. So that's Liskoff substitution Okay, let's look into another one. This was the first behavior pattern