When should interface be owned by client?

Question

In Agile Software Development: Principles, Patterns, and Practices, Uncle Bob talks about client owning the service interface.

My questions are :

1. Should client always own the interface or only when the client changes less often i.e. at higher level of abstraction than classes which implement the interface?

2. Is there any scenario where the client should own the interface although it is at lower level of abstraction than the implementing classes.

Edit: Client owning the interface means, it will specify the interface and not the implementers of the interface. Implementers of the interface own the interface in the case of utility libraries.

Answer 1

First, lets clarify what we mean when we say "interface is owned by client". It means that interface is defined by what client of the interface needs and not by what implementer provides. If we were to create a modules of the trio of client, interface and implementer, then first module would be client and interface and second would be implementer, with second module depending on the first one. This goes nicely along Dependency Inversion principles and Interface segregation principles.

That said, I believe, that "interface is owned by client" is the default position in good design. The question should be "Does it make sense for interface to be defined by implementer". For myself, the question is no. There are multiple reasons for that.

First, lets look at GoF design patterns :

Here, it is quite obvious, that every interface is not defined by the implementer, but by the client. Every pattern allows for arbitrary number and types of implementers. But if client changes, so does the interface. That means the interface and client are more closely conceptually related than interface and implementer.

Second is already mentioned Interface Segregation principle. That says "Client shouldn't depend on interface it doesn't need." This can be paraphrased as "Interface is defined by what client needs." This is quite clear.

Third is the very logic behind interface being defined by implementer. If interface is defined by implementer, it becomes very easy to leak that specific implementer's API. That will make it hard to provide different implementations for the interface. It is quite common sight to see just single implementer for an interface if that interface is defined by that implementer. What is then point in that?

To sum it up : In good, modular and understandable design interfaces (and other abstraction) are first and foremost defined by needs of the clients and are thus part of them. It is a code smell if interface is defined by what implementer provides.