All language subtitles for 007 The Law Of Demeter_en

So what is this law of Demeter or as I'm choosing to call it, it's the guideline, it's a meat because

I don't think it's something that we want to adhere to, necessarily to strictly.

It needs a little bit of caution when applying it now.

Typically, it's referred to as the Dot's rule or the multiple Dot's rule or the two dots rule.

And the idea is that if you see a line like this, you're almost certainly in violation of the law.

And let's have a look at this.

Why is this a bad thing?

Because we've got a class.

We're in some class that has an enemy variable.

Maybe that was something passed in as an argument to a function.

So we have a dependency on enemy in this class.

That's fine.

We know about the interface of enemy.

So doing against current target on enemy should be fine.

That's a publicly exposed variable where a depending upon its public interface that is OK, however,

was not okay.

Is it?

Then this target is of some other type.

Maybe it's a player, for example.

Maybe it's a character and we are now calling a function on that.

So now we depending upon that class as well.

And then what's more, we've done another bad thing.

This would have been bad enough.

We're going one step further and we're saying, well, apart from depending upon the enemy, the enemy's

target class and the health now with depending on the health component as well to do damage to it.

Basically, this line is bad because it means that we're depending on every link of this chain.

If anything in this chain changes, then we have got ourselves a problem now.

This wouldn't be so much of a problem if everything in this chain was the same.

Sometimes in some languages, like Ruby, you'll do this a lot with strings.

You'll have chains of string commands, a chain of array commands that each chain member of the changes

returns another array or another string, so you're not actually increasing the number of classes you're

depending upon.

But this isn't the case here.

Here we are, depending on more and more classes.

And that's basically the reason that we have the law of diameter because we don't want to or the law

of Demeter, as some people pronounce it differently.

That's how I pronounce it, and it might be wrong.

Anyway, the reason we don't want to do this is we don't want to add more class dependencies, and this

is an easy way of accidentally adding more class dependencies and not realizing it.

It's not the best thing, and often what we want to do is make the class we're talking to have the responsibility

for doing more of this.

So exposing something higher level from the enemy might be a solution, such as doing damage to the

current target.

So that means that the enemy will have to have more code written into it.

Maybe the current target and the health component also will need to have more code written into them

to avoid these multiple steps.

But that does not mean that if we made some sort of wholesale change to the way that the target works,

you're not going to have to go and change a whole bunch of other files that are doing lookups crazy

look ups like this?

So here's a challenge for you to see if you can identify what is wrong with the code on this slide.

So what's the situation here?

We've got ourselves a play set up.

A has got a gun.

The gun has got ammo and the ammo class has got a number of rounds.

And for simplicity's sake, I've made these variables public, although you could imagine that they

were private with getters and so on and so forth.

But for simplicity's sake, everything's public in this hierarchy.

Then over on the left, we've got some UI to represent the player and represent the gun and the ammo,

and this works fairly straightforwardly.

We've got a player UI which has some gun UI in it.

And when we redraw the player UI, we get some information about the play.

You can see we're getting reference to the player we are printing its health in lieu of actually updating

some UI.

We are printing the health and then we are calling redraw on the gun UI and the Gun UI similarly gets

some information from the player and prints the rounds left.

What looks wrong in this slide pulseaudio and see if you can figure it out and if you can figure out

what's wrong, a bonus is to try and fix it.

OK, welcome back.

So if you've had a go at this, then you will be saying, well, this line here looks a bit fishy.

That seems to violate the law of Dempster because our gun UI has to have a dependency on player, has

to have a dependency on gun, has to have a dependency on ammo and it has to have a dependency on rounds

left.

It doesn't seem ideal.

So what could we do to improve this situation?

Well, it's not always as straightforward as saying, Well, let's just have the player have a get round

left method.

Maybe that's the wrong level of abstraction for the player.

I think here the first place we're going wrong is by having the Gun UI get hold of the player for itself.

The Gun UI doesn't really have to be linked to a player at all.

It could just be passed a gun or given a gun from somewhere else.

So let's see if we can't do a better job of this.

So the first thing I said was over in the Gun UI.

I think we want to not worry about getting hold of the player here in the gun UI.

In fact, I don't even think we should know about the player at all.

It's a gun UI.

It's not a player gun UI.

So let's try and reduce the number of dependencies here by passing in the actual gun type here that

we want to redraw that we want to render.

So now what we can do is we've simplified matters a little bit.

We've got none of this dealing with the player or figuring out how to get hold of the player.

And instead, we are just getting hold of the gun or ammo that rounds left.

This is still not great, but we'll come back to that in a second.

The player UI now would be the one responsible for when it calls can UI and does a you end up redraw

UI.

It would pass in the player dart gun.

And that's fine because it has a dependency on player, has an unfortunate dependency that I don't quite

like, but we can probably not get around at this level, which is that it knows how to find player

as well.

That's not ideal, but it's probably OK, and it can use obviously the public interface for player.

It can get its health, it can get its gun and redraw the gun using the gun UI, which it's aware of.

So this is no longer so bad.

It's not violating the law as badly, but there is still a gun.

Ammo dealt rounds left.

So we've got an issue here that the Gun UI knows a little bit about the internals of the gun and how

it storing the rounds left of ammo.

And if we were to change how that works, it's going to affect the gun UI.

So this is where we do the kind of simple change of just adding another in here in the gun where we

might do something like public, which returns float an inch, which would be something like get rounds

left on here and we could just go ahead and from here, return the ammo dot rounds left.

And now you can see the gun had already a dependency on ammo, so it's fine for it to be getting the

rounds left from ammo.

It's using its public interface of its direct dependencies, not dependencies of dependencies.

And that's the point of the law that matter.

So now we can fix that up over in the Gun UI.

So instead of the Gun UI, knowing about the ammo class, it just as a gun darts get rounds left, and

that means that the Gun UI only has a dependency on gun.

The Play UI only has a dependency on player and not any of its descendant dependencies, and the gun

only has a dependency on its ammo and so on.

So we've really reduced those dependencies down to the direct dependencies that are absolutely necessary

by using the law of diameter.

So hopefully now you'll be more confident in understanding if you ever come across a lot of damage or

demetre and don't know what it meant in the past.

Now you've got an idea and can see how it can help you to write better, more maintainable code with

fewer dependencies.

So this brings us to the close of our introductory section.

Let's review our coding components before we dive in to design patterns.

Number one, the code shall read like English number two, thou shalt take time to name things.

Well, we've seen how important and hard that is.

Thy classes shall do one thing also known as the single responsibility principle, and this is about

consistent levels of abstraction.

Thou shalt use as little state as possible.

State causes bugs.

Let's not include as much as we can.

Thou shalt not refactor before the third repetition.

Premature refactoring leads to complication, not simplification.

Thou shalt not use a static and global state state is bad static and global state.

So my classes shall be highly cohesive and they classes shall be loosely coupled, meaning that they

communicate a lot within themselves and less outside of the.

Sells Nashat use composition over inheritance because it's more flexible and generally more reusable.

And thou shalt follow the Law of Death Matter to not include dependencies that we don't need.

I look forward to seeing you in the next section where we'll get cracking with design patterns.