Splitting the interface does not necessarily mean that you should split the class. You can think of interfaces as of a roles an object of a class is playing in the context of some client code. An object can play more than one role – e.g. picture two different clients “seeing” two different aspects of the same concept. The aspects themselves could be of a more general nature. E.g., consider IComparable: it allows a sorting algorithm to be written in terms of that interface, without the developer having to worry about anything else; at the same time, a concrete class implementing IComparable may have a more complex nature, and may implement other interfaces.
To deal with SRP, you can try to split the class into two (or more) separate concepts, but you can also extract parts of it into separate classes to delegate responsibilities to (composition). I.e. the source class can stay a single overall concept, but “relinquish” some of its original responsibilities to its constituent objects; it would essentially only orchestrate them, implementing a high-level policy.
Basically, if splitting the class would still require the objects to be very “chatty” and rely on each other’s internals, and there’s no real way around that, then splitting would hurt cohesion, and it’s probably best not to do it. Such classes would still be coupled, and furthermore might couple other code that uses them.
So basically the ISP states we should break big interfaces with members that are not cohesive with each other to smaller and more cohesive interfaces
That’s a partial picture; what’s missing is that this is to be judged with respect to, or from the perspective of, clients (code that uses objects through these interfaces, code written against these interfaces). ISP states that clients shouldn’t depend on stuff they don’t use, even though it may make sense to bundle that stuff together into a single object.
I think it helps to contrast SRP and ISP in the following way. SRP is more focused on what the objects themselves are doing, and is about (1) splitting things that aren’t closely related (and change for different reasons and with different rates), but also about (2) bringing together things that are closely connected, but are scattered throughout the code. ISP is more about controlling coupling by limiting the surface area exposed to client code. Splitting a large interface into more focused, smaller interfaces provides flexibility for the clients. It can even be useful if two interfaces segregated from the same source class appear in the same client, because this lets you plug something else for the particular “role” embodied by each interface. This lets you reuse that client code for some other feature that has a similar “shape”, and it also allows for testing.
That said, there’s always some judgement involved. If everything was taken to the extreme, then everything would be too granular, too separated to be usable, and so thoroughly decoupled that the system wouldn’t be able to do anything. Sometimes you can’t satisfy both principles to your liking for various reasons. And it’s not always worth it; some parts of the codebase will work fine and won’t change much, so expending design effort there would bring limited benefit.