Using Interfaces for Loosely Coupled Code

Question

Background

I have a project that depends on the usage of a certain type of hardware device, while it doesn't really matter who makes that hardware device as long as it does what I need it to do. With that being said, even two devices that are supposed to do the same thing will have differences when they are not made by the same manufacturer. So I am thinking to use an interface to decouple the application from the particular make/model of device involved, and instead have the interface just cover the highest-level functionality. Here is what I am thinking my architecture will look like:

1. Define an interface in one C# project IDevice.
2. Have a concrete in a library defined in another C# project, that will be used to represent the device.
3. Have the concrete device implement the IDevice interface.
4. The IDevice interface might have methods like GetMeasurement or SetRange.
5. Make the application have knowledge about the concrete, and pass the concrete to the application code that utilizes (not implements) the IDevice device.

I am pretty sure that this is the right way to go about it, because then I will be able to change out what device is being used without affecting the application (which seems to happen sometimes). In other words, it won't matter how the implementations of GetMeasurement or SetRange actually work through the concrete (as may differ among manufacturers of the device).

The only doubt in my mind, is that now both the application, and the device's concrete class both depend on the library that contains the IDevice interface. But, is that a bad thing?

I also don't see how the application won't need to know about the device, unless the device and IDevice are in the same namespace.

Question

Does this seem like the right approach for implementing an interface to decouple the dependency between my application and the device that it uses?

Answer 1

I think you've got a pretty good understanding of how decoupled software works :)

The only doubt in my mind, is that now both the application, and the device's concrete class both depend on the library that contains the IDevice interface. But, is that a bad thing?

It doesn't need to be!

I also don't see how the application won't need to know about the device, unless the device and IDevice are in the same namespace.

You can deal with all these concerns with Project Structure.

The way I typically do it:

• Put all my abstract stuff in a Common project. Something like MyBiz.Project.Common. Other projects are free to reference it, but it may not reference other projects.
• When I create a concrete implementation of a an abstraction I put it in a separate project. Something like MyBiz.Project.Devices.TemperatureSensors. This project will reference the Common project.
• I then have my Client project which is the entrypoint to my application (something like MyBiz.Project.Desktop). At startup, the application goes through a Bootstrapping process where I configure abstraction/concrete-implementation mappings. I can instantiate my concrete IDevices like WaterTemperatureSensor and IRCameraTemperatureSensor here, or I can configure services like Factories or an IoC container to instantiate the right concrete types for me later on.

The key thing here is that only your Client project needs to be aware of both the abstract Common project and all the concrete implementation projects. By confining the abstract->concrete mapping to your Bootstrap code you're making it possible for the rest of your application to be blissfully unaware of the concrete types.

Loosely coupled code ftw :)

Answer 2

Yes, that does seem like the right approach. No, it is not a bad thing for the application and the device library to depend on the interface, especially if you are in control of the implementation.

If you are concerned that the devices might not always implement the interface, for whatever reason, you can utilize the adapter pattern and adapt the concrete implementation of the devices to the interface.

EDIT

In addressing your fifth concern, think of a structure like this (I am assuming you are in control of defining your devices):

You have a core library. In it is an interface called IDevice.

In your devices library, you have a reference to your core library, and you have defined a series of devices which all implement IDevice. You also have a factory which knows how to create different kinds of IDevices.

In your application you include references to the core library and the devices library. Your application now uses the factory to create instances of objects which conform to the IDevice interface.

This is one of many possible ways to address your concerns.

EXAMPLES:

namespace Core
{
    public interface IDevice { }
}


namespace Devices
{
    using Core;

    class DeviceOne : IDevice { }

    class DeviceTwo : IDevice { }

    public class Factory
    {
        public IDevice CreateDeviceOne()
        {
            return new DeviceOne();
        }

        public IDevice CreateDeviceTwo()
        {
            return new DeviceTwo();
        }
    }
}

// do not implement IDevice
namespace ThirdrdPartyDevices
{

    public class ThirdPartyDeviceOne  { }

    public class ThirdPartyDeviceTwo  { }

}

namespace DeviceAdapters
{
    using Core;
    using ThirdPartyDevices;

    class ThirdPartyDeviceAdapterOne : IDevice
    {
        private ThirdPartyDeviceOne _deviceOne;

        // use the third party device to adapt to the interface
    }

    class ThirdPartyDeviceAdapterTwo : IDevice
    {
        private ThirdPartyDeviceTwo _deviceTwo;

        // use the third party device to adapt to the interface
    }

    public class AdapterFactory
    {
        public IDevice CreateThirdPartyDeviceAdapterOne()
        {
            return new ThirdPartyDeviceAdapterOne();
        }

        public IDevice CreateThirdPartyDeviceAdapterTwo()
        {
            return new ThirdPartyDeviceAdapterTwo();
        }
    }
}

namespace Application
{
    using Core;
    using Devices;
    using DeviceAdapters;

    class App
    {
        void RunInHouse()
        {
            var factory = new Factory();
            var devices = new List<IDevice>() { factory.CreateDeviceOne(), factory.CreateDeviceTwo() };
            foreach (var device in devices)
            {
                // call IDevice  methods.
            }
        }

        void RunThirdParty()
        {
            var factory = new AdapterFactory();
            var devices = new List<IDevice>() { factory.CreateThirdPartyDeviceAdapterOne(), factory.CreateThirdPartyDeviceAdapterTwo() };
            foreach (var device in devices)
            {
                // call IDevice  methods.
            }
        }
    }
}

Answer 3

The only doubt in my mind, is that now both the application, and the device's concrete class both depend on the library that contains the IDevice interface. But, is that a bad thing?

You need to think the other way around. If you don't go this way, the application would need to know about all of the different devices / implementations. What you should keep in mind is, that changing that interface could break your application if it is already out in the wild, hence you should design that said interface carefully.

Does this seem like the right approach for implementing an interface to decouple the dependency between my application and the device that it uses?

Simply yes

how the concrete actually gets to the app

The application can load the concrete assembly(dll) at runtime. See: https://stackoverflow.com/questions/465488/can-i-load-a-net-assembly-at-runtime-and-instantiate-a-type-knowing-only-the-na

If you need to dynamically unload/load such a "driver" you need to load the assembly into a separate AppDomain.