All language subtitles for 005 Sources Of Spaghetti Code_en

So let's discuss a few of the sources of spaghetti code.

But before we do that, let's ask ourselves why is it called spaghetti code in the first place?

It might not be obvious to all of you.

So if you've heard this term before, what it's getting at is the idea that when you've got a bowl of

spaghetti like this and you pull it one strand, you're not sure which bits of the bowl are going to

move.

Where is the end of that spaghetti?

Where is it?

It's in a tangle.

You can't quite see spaghetti code.

Just like this.

You change one bit of code and you are not sure what the repercussions are going to be.

It could be wide reaching and chain have a bug in a piece of completely unrelated code.

Or at least you thought it was unrelated.

So that's my spaghetti code is bad because you go and make a change in one place and it has repercussions

all over the place.

What we want is you make a change in one class and it's mostly self-contained to that class with a little

bit of changes elsewhere.

Now, the static and global state are some commonly identified issues with code.

Any use of static and global state is a bad thing.

So what do you mean by static or global state?

Well, it's these cases where you have a static public variable, even not necessarily public, but

a static variable that's shared across the whole of your program.

And you can edit it if it's constant that doesn't use a bug that way.

But if it's something that can be modified by your program, then there is an issue.

Here is why bugs that's the first thing is quite easy for that variable to change when you're not expecting

it to, because somewhere else in the code it gets updated.

You forgot that because your mind can't be everywhere in a large code base.

And so bugs happen.

Poor unit test ability.

So this is not always a problem in games because we don't always unit test games for whatever reason.

That might be a bad thing, but we don't often unit test games.

But if you've got global state, that makes it virtually impossible or very hard.

It's a unit.

Test things properly because you can't set things up in isolation in a little test case code comprehension

because global state variables are often declared far away or used far away from where you're currently

reading the code, and their impact can be far away.

They can be really hard to understand.

When is that variable going to change?

What should that variable be at this point in time?

So someone coming into your code fresh or you coming in a few months time, you won't be able to know

what to expect from that variable multithreading.

Not so much an issue again with you.

Secret tend to write single threaded code.

But if you do have multi-threaded stuff, then this whole level of bugs just gets so much worse because

threads can stomp all over each other.

There can be performance issues around having multiple threads trying to access the same information

and communication between threads.

Its global state is absolutely a no go.

When you've got multithreading involved and the last final argument is and then you need to.

So you thought with that global state that only ever be one audio manager, you thought they'd only

ever be one character in the game?

Oh, suddenly we've decided we're going to have a team of player characters in the game.

And now you thought that it was alright to have just one global mana variable.

Well, now we need to manage variables one further player, one on one for player two.

Wouldn't it have been better if we hadn't use global variables in the first place?

So these are some of the common reasons we don't use global state.

It creates a spaghetti code where we don't know what is involved with what.

Here's an example Suppose we had a mana variable like I was saying, and we decided it'd be a good idea

if this was a public only static global variable.

So in our character, we might decide that we're updating the Mana every frame to recharge.

And when you use an ability that cost gets subtracted from the Mana, obviously we'd put in some code

here to make sure the bond doesn't get below zero and stuff like that.

But for simplicity sake, we're just leaving it like this.

Now, suppose you have another class somewhere else a magic potion that will restore your mana now for

simplicity, because it can just get access to the Mana.

It just does.

It goes and restores that mana.

Everything is working fine at the moment.

What if I went in and added some code that tried to cap the Mana?

Well, I would go and write it here where the money's being updated, right?

Yes, except I'd introduce a bug because I could overcharge the mana by using a mana potion because

I'm accessing this global state and I didn't realize it.

It was coming out of left field for me.

I didn't know it was there.

Another source of spaghetti ification is communication.

Asian between classes and this is where those two points of high cohesion and loose coupling come into

the equation.

So what is loose coupling and high cohesion?

While I think this diagram kind of sums it up the best, imagine that these boxes are classes and inside

them, the dots are variables and functions, and the lines between them are when a function axis is

a variable or another function and so on.

So what's going on here is the good example.

At the top is one which has high cohesion and loose coupling.

What do we mean by that?

High cohesion means that the elements within the classes, the functions and variables refer a lot to

one another.

The functions use multiple variables, they use each other and so on.

Loose coupling means the opposite is true between classes.

One class will not try to access lots and lots of variables of another class.

That's what happens when you have the bad example down here at the bottom, which is one that has low

cohesion, meaning that the elements within the class don't really refer to each other very much.

And tight coupling, which is when they actually refer a lot more to elements from other classes.

You can see these two classes have a lot of functions and variables that reference each other across

the class boundary, which means that these two classes are very tightly coupled.

And this is usually a sign that your structure of classes isn't very good, and you should consider

rejigging the classes and their responsibilities so that they can be higher.

Have higher cohesion and more loose coupling.

So here comes an example of this and a challenge for you.

Why are these two classes here?

Bad?

Because the video and have a go and see if you could also rewrite it to be better.

OK, so this if you haven't figured it out, it was low cohesion and tight coupling was what was wrong

with these classes.

So here's our low cohesion character class, which you can see what's location about it?

Well, this knock back method only uses one variable the animator.

The Shout method only uses the audio source and and the shout and take damage only uses the health.

So you can see that essentially, we've almost got three separate classes here.

We've got one that deals with the animation portion, which is this knockback method one class that

deals with the audio portion and one class that deals with the health portion.

So it's not very cohesive.

We could split it up and there wouldn't be much communication between those classes, and we'd end up

with more pie cohesion.

Now, how about the tightly coupled enemy was the other problem, because this enemy knew an awful lot

of information about the character, for instance, ET knew all of these methods.

It used three of its methods here when it only has three, so that's pretty tightly coupled.

And then we also knew how to access and how to find this character.

So in start, it's actually finding the character.

That's another thing that needs to know about that class.

And if we change where the character is located, if we changed any of these methods that are all reasons

why we would have to come and also change the enemy.

So spaghetti code is when you make one change in one file and you have to change 15 other files.

Good code, you should make a change in one file, maybe two.

But that should be it.

If it's good code, it's resilient to changing and doesn't need a scattershot surgery across the whole

code base.

So how could we improve this and a high cohesion character?

We might say, Well, let's take more responsibility for taking a hit, and that's going to be all rolled

up into one method which accesses the animator, the audio and the health components of this character.

This is now a high cohesion class because the function axis is multiple of those variables and it's

much more tightly integrated.

The loosely coupled enemy, on the other hand, might just and this is why they go hand in hand, high

cohesion and loose coupling.

Because now that we have a high cohesion character, the coupling to the enemy has improved because

we now just call take hit.

Well, I've also improved here is we've used an interface.

If you're not seen interfaces before, they're just a way of saying, I want this, it's a contract.

Basically, I want this method to be implemented on whatever object is passed in.

So now what we've got is that instead of relying directly on the high cohesion character class, we

could even swap that out.

Instead of having a character, we could have an NPC object as long as it implemented.

I attachable, we would be able to call Typekit on it.

So now we don't even have the we're not even coupled to the way of finding that class in enemy.

We just get past that target and that's how we do the damage to it.

Now, obviously, this is quite a toy example, but you can see from this example how cohesion and coupling

it goes hand in hand.

Now, in the next lecture, we are going to look at composition and inheritance and why you should prefer

the former over the latter.

I'll see you then.