Violating the Interface Segregation Principle?

Question

I currently have an interface named InternalEntityIdTransformer, which has a getInternalId method, that given an external id returns the corresponding internal one.

Now I am working on functionality that will need to do the opposite transformation, and go from internal id to external id. Is adding an getExternalId method to this InternalEntityIdTransformer a bad violation of the ISP? (All places that currently are using this interface only need the getInternalId and are not going to care about getExternalId at any point.)

And if it is, then is is particularly harmful? Should I rather have two dedicated interfaces here?

The language used is Java, PHP or C#.

Answer 1

ISP basically says that it's not good to require from a class to implement unrelated things, and/or make a client require unrelated things. Methods in an interface are related — a client may need all of them to complete some reasonable task.

I think getInternalID and getExternalID belong to separate interfaces, since clients wanting one of these don't need the other, per your words.

The class that currently implements InternalEntityIdTransformer could happily implement one more interface, say, ExternalEntityIdTransformer, if sharing of implementation details saves you some work. If at some moment you would need to split the implementations (e.g. external to internal is trivial, but the reverse requires heavy lifting), it will be painless, as it should be.

Answer 2

ISP is an interesting principle because the benefits (or rather the costs of ignoring it) are generally small, but the cost of implementation is also small.

The kind of problem that might occur is if, at some point, you want multiple strategies for getting an internal interface, but only one for getting an external interface (or vice versa).

And you're immediately going to think "no, that's not going to happen," but I'll warn you that I did exactly that very recently and got bitten by it.

I was getting two pieces of data from a web service and thought "well if they change the service, I'm going to have to change both clients. So why worry? An obvious truism, you might imagine.

And then they gave me a CSV file for one half of the data, which was faster and contained more data. I wanted, for a time, to be able to switch between the two, while we made sure the CSV file filled all our needs. But I still wanted to get the other half of the data from the same place.

So, now I really want to break that down into three classes, but to do that was a pain because I only had one interface. The solution is simple enough, but it caused me pain in my unit tests.

I wished I'd followed ISP in that case, even though the cost was fairly low, and kicked myself cause you have to ask ... why didn't I? There is zero cost to having two interfaces to one service class for two different client classes.