2

I'm slightly confused over the following:

ProjectA 
-------- GetUsers (Implements IDBConnector)
-------- IGetUsers
-------- UserModel

ProjectB 
-------- Main

I have two projects one main project (project B) and another which gets data from a database (project A). Project A has an interface which the main class makes use of. The GetUsers class is then injected within the main class of type IGetUsers.

This means there is a dependency of Project A for Project B as Project B needs to know how the interface is defined and the class definition itself. I am fine with this from a code standpoint but I can't help thinking that the interface should be kept somewhere else as it is essentially a contract and I am trying to follow the open/closed principle i.e. I shouldn't have to touch the main class to change how the database interaction is dealt with. In my example however if I remove Project A I lose the interface definition and I would have to modify the Main class.

I would have thought that Project B would be a good place to keep the interface but this would result in a circular reference as Project A would need to reference Project A for the interface declaration and vice versa for the class implementation.

The other option is to have a separate project for interfaces which I have seen mentioned in this question:

Sharing classes or interfaces between different projects

But to me this seems a little silly to have this example interface in a whole separate project while there is only one interface at current.

Community
  • 1
Simon Nicholls
  • 255
  • 5
  • 10

1 Answers1

5

You almost have you answer here:

I would have thought that Project B would be a good place to keep the interface but this would result in a circular reference ...

Following the Dependency Inversion Principle, interfaces should be defined by user, not the implementer. As you said in your question, the interface is essentially a contract; in order to invert the dependency, the user has to define the contract, so that the implementer depends on it. This contrasts with the normal flow of dependency, where the user depends on the contract that is forced on it by the implementation.

So, back to organizing the separate projects: If B is the user of the IGetUsers interface, then it must be the one to define it. If A provides an implementation of that interface, then it must depend on B. And now, not only to avoid circular references, but also to free B from any future dependencies that the may come, you can define a third project, C, which has the sole responsibility of composing the system out of the small modular pieces.

This concept is known as composition root, and is ideally the place where all dependency injection should live, leaving A and B outside the bounds of a dependency injection framework, if one were to use it.

MichelHenrich
  • 6,225
  • 1
  • 27
  • 29
  • Thank you so much this is along the lines of what I was thinking although I have just been told the complete opposite - that the interface must be defined in project A. I don't think this is a concept that is widely covered really! When defining the third project - I'm using Spring MVC - would it just contain common interfaces for all the projects. My only worry was that this seemed a bit much to create a whole new project just to contain one interface definition? – Simon Nicholls Dec 09 '14 at 23:03
  • When I mentioned the "third project", I really meant it as only the composition root. It should not define interfaces since nobody should depend on it - it depends on everybody else. Since you mentioned Spring MVC: The composite root is usually the main method - so in your case, the third project is already the one where Spring MVC is used, since it will provide you the main method. Just be sure to decouple your application from it. Here's a good talk on how to do that: https://www.youtube.com/watch?v=HhNIttd87xs – MichelHenrich Dec 10 '14 at 00:34
  • Ah well here lies my issue. My project B is my spring mvc app (I just tried to simplify it for this purpose). The issue is that I believe I know what the composite root is - where my implementation of the interface is injected into a class. The issue is therefore that my controller is using the interface (injected class) and the class is being injected but these are happening in the same project so I'm not sure whether there is really a way round this. That video looks really good though thank you I'll try to find some time to watch it. – Simon Nicholls Dec 10 '14 at 09:53