6

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.

Community
  • 1
q126y
  • 1,713
  • 3
  • 14
  • 24
  • 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. https://en.wikipedia.org/wiki/Dependency_inversion_principle#/media/File:DIPLayersPattern.png – q126y Dec 16 '15 at 16:06
  • 1
    How many [different](http://nerdanswer.com/answer.php?q=1205338) [places](http://www.howto-stack.com/news/90306/when-should-interface-be-owned-by-client) did you post this question? In any case, it is unclear what you are asking. I doubt your question will get an answer anywhere on the Internet in its present form. – Robert Harvey Dec 16 '15 at 16:53
  • 3
    @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
  • @DavidPacker See, for example, http://www.objectmentor.com/resources/articles/dip.pdf , specifically the section "The Dependency Inversion Principle". The dependency inversion principle isn't just about coding to contract, it's also that the high level code is the one specifying the contract, and the low level code is the one forced to adhere to that contract. That's why it's called "*inversion*" - instead of high level depending on low level, it's inverted to be low level depending on high. – Ben Aaronson Dec 18 '15 at 13:15
  • @BenAaronson What? Low level depending on high level? I don't think that is right, Ben. Why would you want to do that? Low level modules are supposed to know **NOTHING** about the upper layers and how they are used, so they can be reused. Low level modules should only provide implementations and satisfy contrats of interface they implement, so you can use them without unwanted stuff. If your low level module uses something from the upper layer, it is not low level anymore and should be moved. – Andy Dec 18 '15 at 14:24
  • @DavidPacker I don't think I can explain it better than the article I linked to. – Ben Aaronson Dec 18 '15 at 17:10

1 Answers1

11

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.

Euphoric
  • 36,735
  • 6
  • 78
  • 110