All language subtitles for 001 The Observer Pattern_en

So let's talk about one of the most commonly used design patterns with the most commonly talked about,

which is the observer persona, and we're going to start with a motivating example from the game world.

So imagine that in my game I have a rampage mode.

I get some sort of power up and I become invincible and scary to enemies.

So usually enemies will try to attack me.

However, if I get a rampage power up, I become invincible, and as a result, enemies should try to

run away now.

But a few other things happen in the game as well.

Apart from that, that's not the only behavior that people see.

They will also see that their health component should stop registering damage and that the UI should

be tinted red or some other kind of UI update an indicator.

So the situation we've got is a lot of dependencies.

We've got a rampage mode component of some sort, which gets enabled.

When we only pick up that power up, it kind of detects the power up.

Somehow, let's just assume that that bit is sorted out.

We've got the Rampage mode, has to talk to a whole bunch of enemies.

It has to call a method on the enemies to say, Hey, you should be scared of me right now.

So in a naive example, this might do a find objective type, find all the enemy eyes and call a method

on them saying run away something like that.

Now this is obviously creating a dependency between Rampage and the enemy air.

It's made rampage dependent and coupled to the enemy A.I..

And also, if we carry on with this naive train of thought, if we have a rampage UI, it has to go

and say, Hey, get the UI and update it to the UI that we're in rampage mode and draw the red tint

and go to the hell component and say, Hey, enable invulnerability.

So it's got all of these dependencies.

All of a sudden.

It knows a lot about all of these different classes, which is not an ideal situation to be in.

What we want to do is essentially flip this around because this would take it from having one class

with a dependency on lots of classes to a lot of classes having a dependency on one class, which is

a much better place to be in in this case.

And one naive way of doing this is in update.

So the Rampage UI could every update check with their players rampage components and say, Are you rampaging?

And if so, I should draw the Rampage UI.

The same would go with the health component could check its rampage, and it could enable its invulnerability

and the all of the enemies could run that update methods to check that as well.

Now this has an efficiency problem because updates will be run every frame and rampage might be something

an event that happens once or twice in the whole course of the game.

So this is an okay strategy, but not ideal, and it's also not great from the point of view of understanding

the code.

So what could we do instead?

So that's where the observer pattern comes in.

Now I'm going to use this graphic, which is a UML diagram taken from Wikipedia, because I think it's

time that we start to understand these kinds of diagrams where you'll see them all over the place where

ever design or programming patterns are discussed.

So we're going to try and understand what this means.

So the key things in the observer pattern are the observer class, which is this thing over here and

the subject, which is something over here.

The subject is the thing that we are observing.

The observer is the thing doing the observing.

In our example, the subject here would be the rampage component.

The observers would be a number of different classes.

They would be the enemy class, the Rampage UI class and the health class.

So what's going on here?

Basically, the observer has an update method, which basically is saying something has changed.

For example, Rampage has started, Rampage has stopped.

That would be our update method on the observer.

And then you can see what we've got here.

This arrow, this empty white arrow is indicating inheritance.

So we've got a concrete observer, a concrete observer.

B, in our example, this would be an enemy.

This would be a health component and the rampage.

Why each of these implements the update method.

So each of them would have Rampage enabled Rampage disabled on them.

And you can then have a situation where they register themselves for notifications so you can see the

subject here has a register, observer, unregister observer and notify observers.

So what would happen is the health component, which would call register observer on the rampage components.

The enemies would do the same and then when the rampage actually starts the subject, in which case

the rampage component would notify all of the observers it essentially runs through.

As you can see this little snippet of code here notify observers would go and do a fully over all of

the registered observers and call their update method.

So this is obviously not exclusive to rampaging and is a very common pattern to want to use when in

a situation where you have a one to many kind of communication, where you have one class, the subject

that wants to send a message to lots of different observers and doesn't particularly care who those

observers are, we don't want to know.

Who needs to update is the response to this is just a fire and forget kind of situation now there's

a lot of ways for us to do this.

This the kind of classic way is to implement all these methods, but there's a lot of better ways for

us to do this in unity and C-sharp.

So we're going to look at some of those methods in the next lecture.

But for now, let's have a quick little challenge about this pattern and think about the principles

that this pattern is trying to improve.

So take a look back at the commandments from the last section.

And which does this particular pattern implement post video and have a little ponder?

Okay, welcome back.

So what I think this implements is not super clear, necessarily straight off the bat, but this is

about loose coupling.

Primarily, we had a situation in the first naive implementation of Rampage, where Rampage was unnecessarily

coupled to a whole lot of components, which is undesirable because any of those components changing

would cause a change in rampage.

So what you're doing is you're reducing the coupling essentially by changing the direction of those

dependencies, and that's why we like to use things like the observer pattern.

Okay, so that's the observer pattern.

In a nutshell.

In the next decade, we're going to look at how we can actually implement it using various unity methods.