All language subtitles for 003 Delegates, Actions and Events_en

Hello and welcome in this lecture, we're are going to be looking at how we could replace the unity

specific unity event with a more C-sharp generic event action.

And we'll see the pros and cons of using that approach.

Let's dive in and see it now.

So we've seen how we can implement the observer pattern using agency events.

However, that does require us to go in and set this up in the ED. And that means that if we use a health

component and forget to set it up, this behavior is not going to exist.

That might be fine for you and you might not want it to always exist.

But if you want a certain behavior to always exist and be configured in code, then you can still use

the unity event.

There is a way to subscribe to a unity event in code.

That's one thing that we could do, but there is a built in mechanism in C Sharp that we could use as

well.

So let's, first of all, have a look at how we might do this in code.

So taking the serialised field and turning into public will expose our own level up.

I have accidentally just gone ahead and closed that file, so let's go open it again.

So we've now got on level up exposed.

So in health, we should be able to register here.

So we're going to do this and start because we need to get hold of another component and we should only

get hold of and communicate with other components in start.

But do it get component level?

And then we are going to look for the on level public variable unity event.

And from then we can go and see what options we've got and we've got an add listener.

You can think of a listener as being a bit like an observer lazy listener.

You can substitute observer if you like, so we can add a listener.

And then what you need to pass in here is a function for it to call so we could pass a reset health.

And it's important here that you leave off the set of parentheses because what we're doing here is we're

saying cool this method when on level up is invoked.

If we put parentheses after here, we would be calling the method right now in stop.

But that's not what we want to happen.

We want that method to be called on level up.

So we need to leave off the parentheses.

So that's the way that we can do it with a unity event, and that's OK.

But there are a few things that are not so great about this.

The first is that this on level up variable has a lot of other methods that are completely unprotected.

For example, I can do on level up dots invoke so I could call the owner level up event.

Now, obviously, I wouldn't try and do this, but you can see that it's not very well protected.

It's not very well encapsulated.

I could also remove all listeners.

That's not very good for the health component to be able to do so.

All these things are fixed by a C-sharp mechanism called an event, and an event automatically protects

you.

It allows you to publicly expose subscribing to an event and subscribing yourself.

But you can't remove anybody else's listeners.

You cannot invoke the method that can only be done from the place that declares it.

So that sounds like exactly the sort of thing we want to be able to do.

So let's go ahead and put our unity event back to being a sterilize field like soap, and let's create

another on level up event here, which we're going to have as our own level up action.

You'll see why in just a second.

The way we declare this is and I'm going to put this after all of our state, we have a public variable

that we call put the event key word in front of.

And then we're just going to use the type action for now, and we'll get to that in a second.

Now you do need to be using system in order to use action or you can use system action.

So we've got a public event action and then we can have on level up action.

I'm going to call it just to differentiate from the other one.

Now what we can do with on level up action is we can actually just call it like a method.

So if we go down, it's gain experience where we are invoking own level up.

We can also do on level up action and we can just put parentheses on the end of it and call it like

this.

So we don't have to do a dot invoke.

You can just call it like this because it's built into the C-sharp language.

It has some niceties around it, so you can do like this.

It does.

However, this would give an error.

If there is nothing listening to this event, then it's going to give an error when we call this.

So typically what you do is you will wrap this and if statement.

So you say if on level up action and you notice that's quite cool, there is a little lightning bolt

in auto complete and visual studio code, which basically signifies that it's an action.

You may have seen these in other built in unity things, so you can put this inside of these statements

and then you can call on level up, call the method from here.

And I was wrong that you can't put it directly if you need say is.

Not equal to no.

So we're saying that if on a level up action is not equal to now, you can go ahead and call it like

so.

Now the flip side to this would be registering for that event.

So actually being able to go ahead and listen to it.

We can do this over in health now.

We've not got on level up exposed anymore, so we need to stay on level up action.

You can see it now says on level up action, it gives us that little thunderbolts, which tells us right

off the bat that this is an action.

We can subscribe to it.

And then what you do is you use this interesting syntax to do plus equals and then you have the name

of the method you wanted to call, such as reset health.

So this does exactly the same thing as when we did add listener, except the syntax is slightly different

and in my opinion, quite nice.

So what this is doing is it's saying on start, go ahead and add this reset health listener and this

will be called whenever the level up event happens.

So you don't need to do this anymore.

Over in years, he don't need to configure this so we can go ahead and remove the reset health call

from the inspector.

And that's great.

We are now getting the same sort of functionality.

However, let's just check, is there any way that we could abuse this that's going to unlevel up to

action dots?

Well, should we can't do any dots here?

There's no kind of dots to be done.

What we can do is we can remove a listener, we could remove the listener for reset health.

And that's something that we might well actually want to do because the standard way of doing this in

unity is not to do this in start.

Reason being, you might start with a component disabled and you probably don't want that component

to have functions called on it if it's disabled.

So what we typically do is instead of using start we use on Enable, which does get called in start

if your component is enabled at the beginning of play.

So then on an able means that we enable the health component or we get started and we then subscribe

to having our callback called.

So I'd like you to experiment with removing that callback on disabled so added on disabled events if

you don't know how to do that.

It's exactly the same as the on enable event I just did, but with the words on disabled instead and

then use the minus equal operator to remove that reset health listener and check the behavior in game.

If you go in play the game and disabled a health component while you're playing.

What happens?

Does that callback get called any more?

Does their health stop being reset?

Have a go.

Find out.

Pause VIDEO And a half ago.

OK, let's go back in and give this a stab.

I'm going to do it on disable.

We're going to do basically the exact same code, so it's going to be a get component level dot on level

up action minus Eq., the reset health.

This time now, actually, because we're not calling Reset Health from outside anymore.

And it's probably not the sort of thing we want just anybody to be able to call.

I'm going to go ahead and make that private.

And you can do that now, so the level doesn't need it to be public because nobody is using that public

interface.

The only public interface here is the fact level exposes an on level up action.

And this is the right way, in my opinion, for the dependencies to be going from health to level,

not the other way round, even though the direction of execution is the other way.

Round level is calling to us, but it doesn't have to know anything about it.

That's a great thing about the observer pattern.

Is it because it flips those dependencies around when you want them to?

So this should now work.

Let's go over into unity, and we're going to make sure that the game isn't going to maximize on load

and go into our console.

Clear it out and we're going to go ahead and hit play.

So when we go ahead and hit play, it's got to maximize it.

For some reason, I don't know why.

And you can see we're getting our log messages out here.

And what I want to do is just go ahead and disable the health component for a time, and we're going

to see that the health component carries on running because the code routine is running that, don't

worry, that's a bug with my implementation there, but you can quite clearly see that the health is

not being replenished.

So we have successfully removed ourselves as a subscriber to the level up event.

However, if I go ahead and re-enable it and we level up, you can see the event is being called once

again and that's entirely being configured now in code using events and actions.

Now, I did promise that we would go back to reviewing this action type here.

So if I go to level and have a look, we've got this action type now.

Basically, this is a easy way of describing a delegate type.

And so this is going to get a little bit technical now.

If you if you're not interested, action is all you need.

However, if you are interested, essentially what action is doing here is is writing the following

we can write delegate void and let's just call it call back type here puts some parentheses like that

and a semicolon so you can see this looks very much like a method declaration, except has this delegate

key word in front.

Now what this is doing is it's telling us the type of method that you can have as a listener to an event

of this type.

So if I replaced action with callback type, the effect is exactly the same because action essentially

is doing that same thing over there.

The only thing you have to watch out for is that the level of accessibility of that type.

The callback type has to be the same as the level accessibility of the event.

So we need to make it a public delegate void, callback type.

And what this is now saying is that anything that has this kind of format, it returns void and it takes

no arguments that can be used as a listener for the on level up action.

Now, if you wanted to, you could have a delegate which has got parameters in here, so it could have

a float, which I don't know could be the level, for example, that we've leveled up to.

And now you can see over in health it would be giving us an error because it's saying, Hey, reset

health doesn't match the delegate, it doesn't take a parameter.

So we'd have to take a parameter like float level for it to stop giving us warnings here.

But obviously we don't want to do that and it was fine just as it was.

So we're going to go back to removing that parameter from our callback type.

You could also have delegates can be used as just parameters into regular functions if you wanted to

pass in a callback for to be called when a function finishes or anything like that.

Delegates are much more widely applicable in the observer pattern, and you don't have to worry about

that if you just want to implement the observed pattern.

I would recommend using action because it avoids you having to invent a name for something that has

already been invented.

If you are a C-sharp developer, you will have come across action.

So this is something that keeps our code clean.

It already has a meaning.

We don't need to reinvent the wheel here.

If you do want to pass an argument, you still don't need to make a new delegate type because action

has a generic format where you put these angle brackets and you could put an action float.

And this basically does exactly the same as that delegate.

I just described it.

Now means that on level up action expects to take a float.

So both the reset health would have to have a float in it, but also where we are calling, it's down

here on line 32 and gain experience that would also have to give you the level that would have to give

you a float in there.

So we'd have to do something like get level to satisfy the compiler here.

So that's a little brief foray into actions.

Obviously, I've brushed over them really, really quickly.

I'm just going to take away that generic argument for float so that we're going back to having an action

that simply signals that something has happened and this is the most used form of action.

So if you see around the place event action, this is a common way of implementing the observer pattern

in C-sharp.