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.

  • 2
    I do not own the book, what do you mean by client owning the interface? As in the interface is included in the client's package? – Andy Dec 16 '15 at 15:50
  • 1
    @DavidPacker It means client specifies the interface of the objects it will use. Like this. en.wikipedia.org/wiki/Dependency_inversion_principle#/media/… – q126y Dec 16 '15 at 16:06
  • 2
    @robert I didn't post it at those places. They seem like data farming sites. Picking content from elsewhere for clicks and earning through ads – q126y Dec 16 '15 at 16:58
  • 2
    Oh, lovely.....I reported the sites to SE corporate. – Robert Harvey Dec 16 '15 at 17:06
  • 2
    You are confusing terms. Dependency inversion principle does not mean the client specifies the interface of the objects it will use. DIP means implementation is not known during the compile time and is decided during runtime execution, where desired implementation tied to a contract specified by a common interface is loaded and injected to a service to use, meaning programmers code to interface rather than concrete implementations (classes). – Andy Dec 16 '15 at 17:31

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 : 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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.