Uso delle interfacce per codice liberamente accoppiato

Penso che tu abbia una buona conoscenza di come funziona il software disaccoppiato:)

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?

Non è necessario!

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.

Puoi gestire tutti questi problemi con Struttura del progetto .

Il modo in cui lo faccio in genere:

• Metti tutte le mie cose astratte in un progetto Common . Qualcosa come MyBiz.Project.Common . Altri progetti sono liberi di farvi riferimento, ma potrebbero non fare riferimento ad altri progetti.
• Quando creo un'implementazione concreta di un'astrazione, la metto in un progetto separato. Qualcosa come MyBiz.Project.Devices.TemperatureSensors . Questo progetto farà riferimento al progetto Common .
• Ho quindi il mio progetto Client che è il punto di accesso alla mia applicazione (qualcosa come MyBiz.Project.Desktop ). All'avvio, l'applicazione passa attraverso un processo Bootstrapping in cui configuro i mapping di astrazione / implementazione di calcestruzzo. Posso istanziare il mio concreto IDevices come WaterTemperatureSensor e IRCameraTemperatureSensor qui, oppure posso configurare servizi come fabbriche o un contenitore IoC per istanziare i tipi concreti giusti per me più avanti.

La cosa fondamentale qui è che solo il tuo progetto Client deve essere a conoscenza sia del progetto Common astratto sia di tutti i progetti di implementazione concreta. Confinando la mappatura concreta e astratta del tuo codice Bootstrap, puoi rendere il resto della tua applicazione piacevolmente inconsapevole dei tipi concreti.

Codice ftw:)

Sì, sembra l'approccio giusto. No, non è una cosa negativa per l'applicazione e la libreria di dispositivi dipendere dall'interfaccia, specialmente se si ha il controllo dell'implementazione.

Se si teme che i dispositivi possano non implementare sempre l'interfaccia, per qualsiasi motivo, è possibile utilizzare il modello dell'adattatore e adattare l'implementazione concreta dei dispositivi all'interfaccia.

Modifica

Nell'affrontare la tua quinta preoccupazione, pensa a una struttura come questa (presumo che tu abbia il controllo sulla definizione dei tuoi dispositivi):

Hai una libreria principale. In esso c'è un'interfaccia chiamata IDevice.

Nella libreria dei dispositivi, hai un riferimento alla tua libreria principale e hai definito una serie di dispositivi che implementano tutti i dispositivi ID. Hai anche una fabbrica che sa come creare diversi tipi di IDevice.

Nella tua applicazione includi riferimenti alla libreria principale e alla libreria dei dispositivi. L'applicazione ora utilizza la fabbrica per creare istanze di oggetti conformi all'interfaccia IDevice.

Questo è uno dei tanti modi possibili per risolvere i tuoi dubbi.

ESEMPI:

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

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?

Devi pensare il contrario. Se non si va in questo modo, l'applicazione dovrebbe conoscere tutti i diversi dispositivi / implementazioni. Quello che dovresti tenere a mente è che cambiare quell'interfaccia potrebbe rompere la tua applicazione se è già in circolazione, quindi dovresti progettare con cura questa interfaccia.

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

Semplicemente sì

how the concrete actually gets to the app

L'applicazione può caricare l'assembly concreto (dll) in fase di esecuzione. Vedi: link

Se è necessario scaricare / caricare dinamicamente un "driver" di questo tipo, è necessario caricare l'assembly in un AppDomain .