使用接口进行松耦合代码

背景

我有一个项目，该项目取决于某种类型的硬件设备的使用情况，但是只要该硬件设备执行我需要的操作，则由谁来制造该硬件设备并不重要。话虽这么说，即使两个本来应该做同样事情的设备，如果不是由同一家制造商生产的，它们也会有差异。因此，我正在考虑使用一个接口将应用程序与所涉及设备的特定制造商/型号分离开，而使该接口仅涵盖最高级别的功能。这就是我在想我的体系结构的外观：

1. 在一个C＃项目中定义一个接口IDevice。
2. 在另一个C＃项目中定义的库中有一个具体的东西，它将用来表示设备。
3. 有具体的设备实现IDevice接口。
4. 该IDevice接口可能具有类似GetMeasurement或的方法SetRange。
5. 使应用程序了解具体的知识，并将具体的知识传递给利用（而非实现）IDevice设备的应用程序代码。

我非常确定这是正确的做法，因为这样我就可以在不影响应用程序的情况下更改正在使用的设备（这似乎有时会发生）。换句话说，具体的实现方式GetMeasurement或SetRange实际操作方式并不重要（设备制造商之间可能会有所不同）。

我唯一的疑问是，现在应用程序和设备的具体类都依赖于包含IDevice接口的库。但是，这是一件坏事吗？

我也看不到应用程序不需要知道设备的方式，除非设备与设备IDevice位于相同的名称空间中。

题

这似乎是实现接口以解耦应用程序与所使用设备之间的依赖关系的正确方法吗？

我认为您已经对解耦软件的工作方式有了很好的了解：)

我唯一的疑问是，现在应用程序和设备的具体类都依赖于包含IDevice接口的库。但是，这是一件坏事吗？

不必是！

我也看不到应用程序不需要知道设备的方式，除非设备和IDevice位于同一名称空间中。

您可以使用Project Structure处理所有这些问题。

我通常的做法是：

• 将我所有的抽象内容放入一个Common项目中。有点像MyBiz.Project.Common。其他项目可以自由引用它，但它可能不引用其他项目。
• 创建抽象的具体实现时，我将其放在单独的项目中。有点像MyBiz.Project.Devices.TemperatureSensors。该项目将引用该Common项目。
• 然后，有了我的Client项目，这是我的应用程序的入口点（类似MyBiz.Project.Desktop）。在启动时，该应用程序将经历引导过程，在此过程中，我将配置抽象/具体实现映射。我可以实例具体我IDevices喜欢WaterTemperatureSensor和IRCameraTemperatureSensor这里，我也可以配置诸如工厂或IoC容器服务以后实例权的具体类型适合我。

这里的关键是，只有您的Client项目才需要了解抽象Common项目和所有具体的实现项目。通过将abstract-> concrete映射限制在您的Bootstrap代码中，您可以使其余应用程序幸福地意识到具体类型。

松耦合代码ftw :)

是的，这似乎是正确的方法。不，依靠接口对应用程序和设备库来说不是一件坏事，尤其是在您控制实现的情况下。

如果您出于某种原因担心设备可能不总是实现接口，则可以利用适配器模式并使设备的具体实现适应接口。

编辑

解决您的第五个问题时，请考虑以下结构（我假设您可以控制设备的定义）：

您有一个核心库。其中有一个称为IDevice的接口。

在设备库中，您有对核心库的引用，并且定义了一系列均实现IDevice的设备。您还拥有一个工厂，该工厂知道如何创建不同类型的IDevice。

在您的应用程序中，您包括对核心库和设备库的引用。您的应用程序现在使用工厂来创建符合IDevice接口的对象的实例。

这是解决您的问题的多种可能方法之一。

例子：

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

我唯一的疑问是，现在应用程序和设备的具体类都依赖于包含IDevice接口的库。但是，这是一件坏事吗？

您需要反过来思考。如果您不这样做，那么应用程序将需要了解所有不同的设备/实现。您应该牢记的是，如果该接口已经被淘汰，那么更改该接口可能会破坏您的应用程序，因此您应该仔细设计该接口。

这似乎是实现接口以解耦应用程序与所使用设备之间的依赖关系的正确方法吗？

简直是

具体实际如何到达应用程序

应用程序可以在运行时加载具体的Assembly（dll）。参见：https : //stackoverflow.com/questions/465488/can-i-load-a-net-assembly-at-runtime-and-instantiate-a-type-knowing-only-the-na

如果需要动态卸载/加载此类“驱动程序”，则需要将程序集加载到单独的AppDomain中。