Uso de interfaces para código acoplado libremente

Antecedentes

Tengo un proyecto que depende del uso de cierto tipo de dispositivo de hardware, mientras que en realidad no importa quién haga ese dispositivo de hardware siempre que haga lo que necesito que haga. Dicho esto, incluso dos dispositivos que se supone que deben hacer lo mismo tendrán diferencias cuando no sean fabricados por el mismo fabricante. Por lo tanto, estoy pensando en usar una interfaz para desacoplar la aplicación de la marca / modelo particular del dispositivo involucrado y, en cambio, hacer que la interfaz cubra la funcionalidad de más alto nivel. Así es como creo que se verá mi arquitectura:

1. Defina una interfaz en un proyecto de C # IDevice.
2. Tenga un concreto en una biblioteca definida en otro proyecto de C #, que se usará para representar el dispositivo.
3. Haga que el dispositivo concreto implemente la IDeviceinterfaz.
4. La IDeviceinterfaz puede tener métodos como GetMeasuremento SetRange.
5. Haga que la aplicación tenga conocimiento sobre el concreto y pase el concreto al código de la aplicación que utiliza ( no implementa ) el IDevicedispositivo.

Estoy bastante seguro de que esta es la forma correcta de hacerlo, porque así podré cambiar qué dispositivo se está utilizando sin afectar la aplicación (lo que parece suceder a veces). En otras palabras, no importará cómo las implementaciones GetMeasuremento SetRangerealmente funcionan a través del concreto (ya que pueden diferir entre los fabricantes del dispositivo).

La única duda en mi mente es que ahora tanto la aplicación como la clase concreta del dispositivo dependen de la biblioteca que contiene la IDeviceinterfaz. Pero, ¿es eso algo malo?

Tampoco veo cómo la aplicación no necesitará saber sobre el dispositivo, a menos que el dispositivo IDeviceesté en el mismo espacio de nombres.

Pregunta

¿Parece este el enfoque correcto para implementar una interfaz para desacoplar la dependencia entre mi aplicación y el dispositivo que utiliza?

Creo que tienes una buena comprensión de cómo funciona el software desacoplado :)

La única duda en mi mente es que ahora tanto la aplicación como la clase concreta del dispositivo dependen de la biblioteca que contiene la interfaz IDevice. Pero, ¿es eso algo malo?

¡No necesita ser!

Tampoco veo cómo la aplicación no necesitará saber sobre el dispositivo, a menos que el dispositivo y el IDevice estén en el mismo espacio de nombres.

Puede abordar todas estas inquietudes con la Estructura del proyecto .

La forma en que normalmente lo hago:

• Pon todas mis cosas abstractas en un Commonproyecto. Algo así como MyBiz.Project.Common. Otros proyectos son libres de referenciarlo, pero es posible que no haga referencia a otros proyectos.
• Cuando creo una implementación concreta de una abstracción, la pongo en un proyecto separado. Algo así como MyBiz.Project.Devices.TemperatureSensors. Este proyecto hará referencia al Commonproyecto.
• Luego tengo mi Clientproyecto, que es el punto de entrada a mi aplicación (algo así como MyBiz.Project.Desktop). Al inicio, la aplicación pasa por un proceso de Bootstrapping donde configuro asignaciones de abstracción / implementación concreta. Puedo crear instancias de mi concreto IDevicescomo WaterTemperatureSensory IRCameraTemperatureSensoraquí, o puedo configurar servicios como Fábricas o un contenedor IoC para instanciar los tipos de concreto adecuados para mí más adelante.

La clave aquí es que solo su Clientproyecto necesita conocer tanto el Commonproyecto abstracto como todos los proyectos de implementación concretos. Al limitar el mapeo abstracto-> concreto a su código Bootstrap, está haciendo posible que el resto de su aplicación desconozca completamente los tipos concretos.

Código vagamente acoplado ftw :)

Sí, ese parece ser el enfoque correcto. No, no es malo que la aplicación y la biblioteca de dispositivos dependan de la interfaz, especialmente si usted tiene el control de la implementación.

Si le preocupa que los dispositivos no siempre implementen la interfaz, por cualquier razón, puede utilizar el patrón del adaptador y adaptar la implementación concreta de los dispositivos a la interfaz.

EDITAR

Al abordar su quinta preocupación, piense en una estructura como esta (supongo que tiene el control de definir sus dispositivos):

Tienes una biblioteca central. En ella hay una interfaz llamada IDevice.

En su biblioteca de dispositivos, tiene una referencia a su biblioteca principal, y ha definido una serie de dispositivos que implementan IDevice. También tiene una fábrica que sabe cómo crear diferentes tipos de IDevices.

En su aplicación, usted incluye referencias a la biblioteca central y la biblioteca de dispositivos. Su aplicación ahora usa la fábrica para crear instancias de objetos que se ajustan a la interfaz IDevice.

Esta es una de las muchas formas posibles de abordar sus inquietudes.

EJEMPLOS

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

La única duda en mi mente es que ahora tanto la aplicación como la clase concreta del dispositivo dependen de la biblioteca que contiene la interfaz IDevice. Pero, ¿es eso algo malo?

Tienes que pensar al revés. Si no va por este camino, la aplicación necesitaría conocer todos los diferentes dispositivos / implementaciones. Lo que debe tener en cuenta es que cambiar esa interfaz podría romper su aplicación si ya está en estado salvaje, por lo tanto, debe diseñar esa interfaz con cuidado.

¿Parece este el enfoque correcto para implementar una interfaz para desacoplar la dependencia entre mi aplicación y el dispositivo que utiliza?

Simplemente si

cómo el concreto llega realmente a la aplicación

La aplicación puede cargar el conjunto de hormigón (dll) en tiempo de ejecución. Ver: /programming/465488/can-i-load-a-net-assembly-at-runtime-and-instantiate-a-type-knowing-only-the-na

Si necesita descargar / cargar dinámicamente dicho "controlador", debe cargar el ensamblado en un dominio de aplicación separado .