It's time to explore the interface segregation principle or ISP.
And that's the eye in solid.
So the interface segregation principle, in short, tells us that we have to split up interfaces if
one interface gets too big so that there are some classes which are not using all of the interface methods.
Um, this again, I will explain it in detail with an example, but just keep in mind, let's say we
have an interface that implements two methods, and we have a class that only needs one method, but
also has to implement the second method because of the interface contract.
Then we have an ISP violation, right.
So in that case we would have to split up the interface.
So here we have two types of workers.
We have a human worker and we have a robot worker.
Now every worker needs to eat so that he can work right.
Well maybe for humans.
But robots do not have to eat.
So in that case, if we take a look here at our AI worker interface, everyone who implements the AI
worker interface has to provide a method for eating and a method for working.
And the problem with that, or the ISP violation, is that the robot who has or who doesn't have to
eat right to get the work done still has to implement the method right.
He is implementing the AI worker interface so that he can work, but he also has the contract to implement
the Eat method.
But he's a robot and does not have to eat.
So the best practice here or to follow along with the ISP, we would now create a second interface so
that we split up working and eating.
Therefore let's create a public interface AI eatable.
And also we will rename this one here public interface to AI workable.
He can work.
He can eat.
Take the void eat.
Let's put it into the second interface.
So now we have two interfaces instead of one.
And the first one is for everyone who can work.
And in addition, if a worker also needs to eat, he will implement the AI interface.
And our human worker, which we simply call worker can work so AI workable and he can also eat.
So add a comma and implement the second interface AI eatable.
Scroll down.
Our robot can only work AI workable, but does not have to eat or cannot eat.
So we can remove the public void.
Eat here.
Great.
So with the previous single interface, we weren't able to remove the EE method because we had the interface
contract, so that would have thrown an exception or an error.
We wouldn't even be able to compile the application.
Great.
So now we have two interfaces.
We have two kind of worker class which are implementing the interfaces at least the worker.
The human worker who needs to eat the robot is only implementing the AI workable interface.
Now let's scroll to the top.
You can for sure see that this is no longer working here, right?
Because we have no AI worker interface anymore.
So let's remove the try catch block here.
Let's say we have an AI workable robot.
New robot.
Okay, he can work, right?
But he cannot eat.
We have no access to any kind of method that's called eat.
That's fine, because the robot does not have to eat.
And for our human worker, we will say that this is also using AI workable human, new worker.
And then human can work.
But human can still not eat.
Because here we're using the AI workable interface for creating the instance.
Right.
So let's go ahead and let's add a cast here say AI eatable.
Let's wrap it around with parentheses.
Now we can call eat because we're casting to AI eatable.
And since our worker here is implementing AI eatable, we will be able to call the eat method.
So that's the interface segregation principle ISP again if our interface is too blasted, if it's too
full, if there are methods and other things inside that some classes have to use, even though they
don't need it, right?
So they have to implement it because of the interface contract, but they don't make use of it.
Then we have to split up our interfaces into multiple smaller interfaces to follow along with the interface
segregation principle that keeps our code clean, maintainable, and also encapsulated.
And as I finished this lesson, I noticed something.
And for sure, instead of using interfaces here, you can also use the classes, right?
So I just wanted to explain it with our, um, with our interfaces.
But for.
Sure, you can simply take human work and human eat and robot work, but you cannot call robots.
Right?
Okay.
So in that way you are using your classes, the work and robot to create the instances.
That's an easier way to actually show it since your classes are implementing the interfaces.
Still, it results in exactly the same output, right?
You will get access to a class here which can do both, and here the robot which can only work.