In today's video, we're gonna be talking about integration, segregation with Java script, which is the fourth Saleh design principle and one of the easiest in my opinion toe.

Understand?

So let's get started now.

But before we get started, I want to talk about how you can get an entire year of hosting for free with a powerful server.

And that's by using atlantic dot net, which is the video sponsor for today's video.

And if you use the code, Kyle, when you check out on top of that entire year of free hosting, you get an additional $50 of credit that you can use to customize your hosting however you want.

And the best part is is this isn't some small, weak server.

This is a powerful server.

This is actually a server that's about two times as powerful as other platforms starting level server, and they don't even give those out for free.

You get this for free for an entire year.

That is amazing.

The server also has incredible redundancy and incredible security, so you don't have to worry about problems with your data going missing.

It's always going to be there for you.

So make sure you use the code, Kyle, when you sign up and use the link in the description down below, welcome back to Webb.

Have simplified.

My name is Kyle, and my job is to simplify the web for you.

So that sounds interesting.

Make sure you subscribe for more videos just like this.

Now, in JavaScript, there's no such thing as an interface and the entire idea of the interface segregation principle is about segregating your interfaces and making them smaller.

So I'm gonna show you an example of what this would look like without javascript.

And then I'm gonna show you how you can use the interface segregation principle in JavaScript because it's actually applicable even without interfaces.

So in a normal language with interfaces, you'll define an interface and every single thing such as all the properties and all the different methods of that interface.

And then every single class that implements that interface needs to define all of the methods in that interface.

But the problem is, is that when you have large interfaces like this which do lots of different things, for example, this has a name.

It handles attacking things.

It handles moving.

It handles taking damage and health, for example, in a video game.

And you may have a character here which implements all of those it needs to be able to move.

Attack.

It has health.

It takes damage, has a name, everything makes sense, but a tear it, for example, it can't actually move.

So having this move functionality on it really doesn't make sense.

And with the interface segregation principle, it's saying that whenever you have an interface, you need everything that implements that interface to use every single portion of the interface.

And right now a turret which is implementing this interface doesn't use movement, so we don't actually use all of the different parts of this interface.

So we're breaking the interface segregation principle.

And now, in JavaScript, a very similar way of doing this is using classes and inheritance instead of using interfaces.

So if we just remove this code and come down here, I have almost the exact same example as you can see.

Here we have an entity, but instead, now it's a class instead of an interface, and it has all those same properties name, attack, damage, health.

And it has these functions, move, attack and take damage.

And these air just printing out to the council so we can see that everything works.

Then we have our character class, which is just extending entity, and it's not doing anything else, is just doing the stuff in the entity class.

We then have a wall which can't move and it can't attack.

So it has zero for attacked image and were just returning Nohl from moving attack and then a tear.

It can't move or take damage.

So we're returning know for those and then down here, we're just initializing our turret character and wall.

And if we save this, you can see our turret is able to attack our character or characters and will lose health.

It's able to move and the characters able to attack the wall because the wall has health and this looks like it works.

I mean, obviously the code works, but the problem is, is we have this base class, this entity which has all these different functionalities in all these different properties but for example of all doesn't use all of them, and our Terran doesn't use all of them.

And this is the same problem with interface segregation where we noticed we had a big interface that had a lot of properties, a lot of method and not everything was able to use all of them.

This is the same exact problem and we need to implement the same style of solution which is to break apart our interface.

But in our case, this is a class.

We want to break this class into individual components for movement, for attacking, for taking damage.

I actually have an entire video on composition versus inheritance which I'm gonna link in the cards and the description for you.

But I'm gonna show you how to do it in this instant, how we can break apart this big entity class into much smaller components that we can add to individual classes as we need.

So here we have the actual final example of what we would do if we moved to components which are essential, like smaller interfaces.

We just broke apart our class.

As you can see, our entity class is now really small.

All it is is a constructor that takes in a single name and then below that we have our different components thes of our smaller interfaces in that interface segregation model.

As you can see, our mover component, all it can do is move and dysfunction.

This concert logged the stock name.

This is the exact same as our move function here we just move that over into the move function in this mover component.

We also did the exact same thing with the attacker.

We just put the attack functionality in there and this handles attack damage the name, all that information and the same thing for has health.

This allows our unit to take damage and it also modifies the health variable as needed.

And then, as you can see down here and our character class, we're extending our entity, which, as we know, just has that name portion of it.

So we're pushing the name up to that entity.

But we're also taking in the extra parameters of damage and health and setting those inside of our character.

And now, in order to make our character actually worked with these components, what we do is we take the prototype of our character, which is essentially the definition of our class, and we're adding in the functionality of mover by saying object.

Gotta sign the prototype and we're adding in the mover to it.

We're also adding attacker in and we're adding the has health into this similar thing for the wall here, except for the wall can't attack or a move.

So we're only adding that has health portion and the same thing with the turret.

It can't move and it can't be destroyed.

A has no health, so we're only adding the attacker portion to it.

And if we save, you can see Over here we get the exact same output with the same exact code down here.

Our actual code that we're using to create these objects and actually interact with them is exactly the same between this example on our previous example as you can see here.

But the difference is is that in this example, for example, our turret dot move doesn't actually work.

You see, we're getting air.

There is no move function on our turn.

But if we were to switch over and use our previous example So if I change this to be our previous example, we're now running our code here, and I called turret dot Move.

You could see that it's not actually doing anything, and that's because it's entering inside here.

I could just say, for example, air.

And as you can see, we're getting air printed out because Turin can't actually move.

But we can still call the move function, which is why you want to break out your interfaces or large classes into smaller components or smaller interfaces.

So you don't have this problem where the turret is extending all of this information from moving, even though there's no way that the turret can actually move.

Instead, you want to use these small components, as you can see here, where we just assign these components to our different classes so that now our turret can't actually move.

We can try to make it move all we want, but every single time we're just going to get an air.

If we switch over to that script, as you can see here, we're getting an error because the turret cannot move.

Same thing.

If we tried to get the wall to move, we're gonna get the exact same error.

This makes it so that each more objects and each more classes on Lee ever implements the information that it can actually use, and it doesn't implement anything else that it cannot use that is really crucial and the main point to the interface segregation principle.

And that's all there is to the interface segregation principle.

If you're interested in checking out other solid design principles, I have them all make over here for you to check out.

And if you enjoy this video, make sure to subscribe to the channel for more videos just like this one.

Thank you very much for watching and have a good day.