Caio: What is the Interface Segregation Principle?
Mike: The ISP states that components...
Shouldn't be forced to depend on behaviors that they don't use.
Caio: So methods or types or anything that they don't use.
Let's say if you're a client of a protocol that has two methods...
But you only use one of those methods...
Ideally you should only know about the method you depend on. 
Mike: But that's not the case most of the time.
Why it's not the case?
Caio: Convenience!
Mike: Convenience, exactly!
It's like in the Single Responsibility Principle where you want to add a new method.
And Xcode is already open on a specific class.
You say "well that seems the correct place to put the method."
The same happens with protocols.
You may say for example "this seems like something my UI will use."
And you add the method in an existing DataSource protocol.
Because the protocol is already used in the UI for a completely unrelated reason.
Caio: Yes. And now this component knows about the UI.
Because you added this method just to satisfy the UI.
It's the same if you have a Cache protocol and you have multiple implementations of it.
Let's say you have one method to retrieve an access token.
So your caching access tokens.
And you have a protocol that hides the implementation of that.
Maybe it's a Core Data, a Keychain or an in-memory implementation of the Cache.
Fantastic. But now you need a new feature.
You need to decode the access token and get a user ID from it.
Now if you go the Cache protocol and add a new method...
Like "retrieve user ID."
Now this protocol has two methods: "retrieve access token," "retrieve user ID."
When you should probably have broken it into two protocols.
Because if you have multiple implementations of the protocol...
All the implementations will have to implement the decoding of the user token.
So this violates a bunch of principles.
It violates the Single Responsibility Principle.
It violates probably the Liskov Substitution Principle.
So breaking down interfaces will help you to conform to all the SOLID principles.
The Interface Segregation Principle, I'm not going to say it's the most important one.
Because all of them are important!
But it's key to break down interfaces and only depend...
On methods you really need.
Mike: This is about mindfulness and observing your behavior.
Think of it in terms of "making a fallacy."
If you're saying something always will have a behavior.
Or all of the sub-types of the protocol will have a behavior.
Then you're committing a fallacy because most probably that's not true.
Caio: Always, never...
Mike: Exactly, you want to protect your system against these fallacies.
Against these things that at the time seem logical but...
In time, you just don't know what's going to happen.
Caio: You can't predict the future thus...
You follow the principles that will help you create flexible systems.
If a new requirement comes you're ready for it.
You're not just thinking in the future too much and wasting a lot of time doing it.
We're talking about 5-10 seconds here creating a protocol.
You can even automate it if you want with a tool that creates protocols for you.
I don't think you need it bit if you want to save 2 seconds you can do it.
Mike: You need to think about.
If you find yourself adding more than one method in a protocol...
Especially if the protocol is old...
You're probably violating the Interface Segregation Principle.
Caio: Yes, because you're probably will break modules that depend on the protocol as well.
Mike: Done! Is there anything else to say?
Caio: Even if they don't need the new functionality.
They are happy with just the old method in there.
Now you add something else you need to recompile, redeploy all the modules...
That depend on the client.
Instead of just creating a new protocol.
So again discipline!
Because by creating isolated interfaces you can test things easily in isolation.
You can compose them in different ways.
You can decorate that interface and add more behavior without any changing existing code.
You can conform to the Open/Closed, the Single Responsibility...
And all the other SOLID principles.
So just be mindful and understand the benefits and downsides of not following it.
And in my experience the upsides just win against the downsides easily.
Mike: Exactly!
Caio: What are the downsides?
More interfaces.
What is it more typing? How much typing?
Not a lot! It's an interface.
Mike: More typing, yes. It's not like we are programmers and that's what we do.
Just maybe you're adding a new protocol, closure, a generic parameter...
Just separate it rather than changing existing code.
Recompiling modules. Breaking interfaces.
Violating the Liskov Substitution Principle.
Because the more method you add to your interface the harder it is to implement it.
So what is an example of the Interface Segregation Principle in practice?
As we just said a Cache protocol that stores access tokens.
And we have this new feature where we want to decode the access tokens.
You shouldn't add a method to the Cache protocol.
You should create another interface for decoding the access token.
Segregate those two interfaces...
Implement them in different components or maybe the same one will implement both.
But it doesn't matter. From the client point of view...
You should only depend on the methods you use.
Mike: That's correct!
Maybe the same component will implement both interfaces.
There is absolutely no problem with that.
Caio: So what are some violations of the Interface Segregation Principle?
Messy protocols with loads of methods, especially, unrelated methods.
One is for retrieving the access token the other is for validating it.
Those are two responsibilities.
So separate your interfaces.
It's going to help you conform to all the other SOLID principles.
So other violations of the ISP?
Protocols that are hard to implement. They have too many methods.
They have methods you don't want to implement.
Mike: If you find a protocol with more than one method, I'm just kidding.
Caio: Ideally you should have one method per protocol.
But of course that's not feasible. So follow the Single Responsibility Principle.
You look at the protocol, the abstract interface you have...
And say "is this responsible for more than one thing?"
If yes, you separate the methods into as many interfaces you need.
So you have single-purpose abstractions.
They can be composed differently, tested in isolation, etc.
Mike: Exactly, yes!
Caio: Alright, so when you feel like you want to add more methods to a protocol...
Stop and think.
Most probably you need a new protocol instead.
