1

Background

I have an interface defined for a circular-buffer called ICircularBuffer in a separate project. This ICircularBuffer is something that we use all over the place, so it resides in the CommonInterfaces project.

Well, we have another interface IEquipmentController that controls some very distinct piece of equipment. This piece of equipment produces some data. I would like to pass my buffer to the IEquipmentController so that I can read the buffer asynchronously by reference from the thread that passed it.

The problem is, that the IEquipmentController and ICircularBuffer are defined in two separate projects. So this leads me into my question...

Question

Because of how the CommonInterfaces is used all over the place, is it okay for my IEquipmentController's project to take a dependency on the CommonInterfaces project?

Alternatively

Maybe I can have the concrete EquipmentController take the dependency on the CommonInterfaces... and then just have the IEquipmentController define a method that accesses the buffer? Thus remaining ignorant to the implementation details (and avoid passing by reference altogether)? I guess this way the two interfaces (IEquipmentController and ICircularBuffer) wouldn't get tied together.

What is my best option here? And in general, are there ever situations where it is a good idea for an interface to take a dependency on another project just to access another interface?

Improve this question
2
  • "IEquipmentController and ICircularBuffer are defined in two separate interfaces." Do you mean defined in two seperate projects?
    – Winston Ewert
    Jun 9, 2016 at 19:10
  • Yes @WinstonEwert feel free to edit.
    – Snoop
    Jun 9, 2016 at 20:04

2 Answers 2

Reset to default
1

There are two options for this type of dependency.

Interface dependency

You can define a method on the controller interface which accepts a buffer. This increases coupling between the modules, and may have a ripple effect in terms of dependencies and code changes. Existing implementations will need to be updated, and they might not care about the buffer.

Do all subclasses have a use for the buffer? Is "using the buffer" part of what the controller does? If so, this may make sense.

Constructor dependency

Leave the interfaces alone, and pass the buffer into the implementation's constructor. This avoids coupling the modules as well as updating existing classes.

If only certain implementations deal with the buffer or if you need to limit changes across modules this is a stronger solution.

Improve this answer
1
  • Yeah I kind of like the second solution. And, I do pass a concrete version of Common to the concrete controller at runtime anyway, so the concrete controller is already depending on CommonInterfaces.
    – Snoop
    Jun 9, 2016 at 20:07
3

Because of how the CommonInterfaces is used all over the place, is it okay for my IEquipmentController's project to take a dependency on the CommonInterfaces project?

Of course it is. That's the whole point of a project like CommonInterfaces. You want to be able to freely reuse those interfaces in a variety of projects.

However, you may want to consider returning a more generic interface. Not because you want to avoid a project dependency, but because you want to avoid leaking implementation details. Does the user of IEquipmentController really need to know that its using a ICircularBuffer? ICircularBuffer probably implements (or should implement) IList. Perhaps it makes sense to return the buffer as a list instead.

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.