 Okay, the second pattern we are covering of the behavioral pattern is the so-called strategy pattern. And this is a pattern that is useful in cases where you want to have something like an algorithm, some kind of routine, some filters that are exchangeable, that you might want to choose at runtime or that you envision might change over time as your program evolves and you simply don't want to have a single implementation but you want to be able to choose. So imagine for example a case where you have a navigation system, navigation application like you have in Google Maps or in many cars that tells you where to go. And you of course have different algorithms, different routing algorithms and instead of implementing a single algorithm in the system and you don't have to replace it manually you can implement this as a strategy pattern and simply say I want to have a method with which I can set the routing application, the routing algorithm at runtime. And then the algorithm itself is a different class or an interface that is implemented and you could basically just add another implementation and then change at runtime. So the way this works is you have the context, so that's our application for instance. This application has a strategy, some kind of algorithm, some filter and it has methods to set this strategy. So it has a method, a set method where you provide a strategy and then there is some kind of method that does something and the assumption here is simply that this method is what is actually executing. So you have something like strategy.execute somewhere in there we are executing our algorithm. So this is just where the actual functionality is happening. This context then has a strategy and this strategy has an execute function, execute and it takes some kind of data that depends on your application. If it's the routing application for instance you probably have some kind of source and target or origin and target destination where do you want to go and then the algorithm gives you a way. This is an interface so it's just that we define that we have this method and then a concrete realization of that interface would be a concrete algorithm that implements this method. So for example, well the easiest navigation is just to say go straight. We don't care if there are any houses in between, we assume go straight. Then you can have more sophisticated ones that kind of try to optimize this. First of all have an algorithm that actually routes you in a way that is possible. You have algorithms that might adapt to traffic information and so on. So very different implementations possible and this is indicated here that you can actually have many of them and then you choose at runtime or at compile time or you configure it. This of course is also useful where you might have multiple cases that depend on the situation. So you might have a routing algorithm that's more efficient during rush hour and you might have a routing algorithm that's more efficient in other situations for instance. So it's not only about replacing it over time it might also be applicable in cases where you want to choose depending on the context. So that's the strategy pattern. Context has a strategy and the strategy is executed in a method here. What kind of solid principles do we have? We have again the open-closed idea. So the context here is close to modifications. We're not modifying the algorithm anyhow. The interface itself is close to modification but then we can extend by having concrete realizations and we can basically enrich the behavior of this context by dynamically setting the strategy at runtime, at configuration or at compile time. The other thing we have here is a classic case of dependency inversion and that's because the context does not have a concrete strategy set. It doesn't have a dependency like this to a concrete case. Instead it has a method that allows you to set the strategy at runtime so we basically invert the dependency here. So we decide which concrete strategy we want. The context does not define that. Okay that's it for the behavioral patterns. There are of course more on the slides. There's also the iterator pattern which many of you probably know already from for example Python where it's built in but we'll now go into the next group of object-oriented design patterns.