Використання інтерфейсів для слабо пов'язаного коду

Фон

У мене є проект, який залежить від використання певного типу апаратного пристрою, хоча це неважливо, хто робить цей апаратний пристрій до тих пір, поки він робить те, що мені потрібно для цього. Зважаючи на це, навіть два пристрої, які повинні робити те саме, матимуть відмінності, коли вони не будуть виготовлені тим самим виробником. Тому я думаю використовувати інтерфейс, щоб від'єднати додаток від конкретної марки / моделі пристрою, а замість цього інтерфейс просто покриває функціональність найвищого рівня. Ось як я думаю, як виглядатиме моя архітектура:

1. Визначте інтерфейс в одному проекті C # IDevice.
2. Майте конкретику в бібліотеці, визначеній в іншому проекті C #, який буде використовуватися для представлення пристрою.
3. Попросіть конкретний пристрій реалізувати IDeviceінтерфейс.
4. IDeviceІнтерфейс може мати такі методи , як GetMeasurementабо SetRange.
5. Зробіть, щоб у додатку були знання про бетон, і передайте бетон до коду програми, який використовує ( не реалізує ) IDeviceпристрій.

Я майже впевнений, що це правильний шлях для цього, оскільки тоді я зможу змінити, який пристрій використовується, не впливаючи на додаток (що, здається, трапляється іноді). Іншими словами, не має значення, як реалізація GetMeasurementабо SetRangeнасправді працює через бетон (як це може відрізнятися у виробників пристрою).

Єдиний сумнів у моєму розумінні - це те, що зараз і додаток, і конкретний клас пристрою залежать від бібліотеки, яка містить IDeviceінтерфейс. Але хіба це погано?

Я також не бачу, як програмі не потрібно буде знати про пристрій, якщо пристрій IDeviceне знаходиться в одному просторі імен.

Питання

Чи здається це правильним підходом до реалізації інтерфейсу для усунення залежності між моїм додатком та пристроєм, який він використовує?

Я думаю, ви досить добре розумієте, як працює нерозділене програмне забезпечення :)

Єдиний сумнів у моєму розумінні - це те, що тепер і програма, і конкретний клас пристрою залежать від бібліотеки, яка містить інтерфейс IDevice. Але хіба це погано?

Це не потрібно!

Я також не бачу, як програмі не потрібно буде знати про пристрій, якщо пристрій і IDevice не знаходяться в одному просторі імен.

Ви можете вирішити всі ці проблеми зі структурою проекту .

Як я зазвичай це роблю:

• Покладіть усі мої абстрактні речі в Commonпроект. Щось подібне MyBiz.Project.Common. Інші проекти можуть посилатися на нього, але вони можуть не посилатися на інші проекти.
• Коли я створюю конкретну реалізацію абстракції, я розміщую її в окремому проекті. Щось подібне MyBiz.Project.Devices.TemperatureSensors. Цей проект буде посилатися на Commonпроект.
• Потім у мене є мій Clientпроект, який є вхідним пунктом до моєї заявки (щось подібне MyBiz.Project.Desktop). При запуску додаток проходить процес завантаження, де я налаштовую відображення абстракції / конкретного виконання. Я можу інстанціювати свої конкретні, IDevicesяк WaterTemperatureSensorі IRCameraTemperatureSensorтут, або можу налаштувати такі служби, як Фабрики або контейнер IoC, щоб інстанціювати потрібні конкретні типи для мене згодом.

Тут головне - лише те, що ваш Clientпроект повинен бути обізнаний як про абстрактний Commonпроект, так і про всі конкретні проекти з реалізації. Обмеживши абстрактне -> конкретне відображення у вашому Bootstrap-коді, ви даєте можливість решті вашої програми бути безтурботно невідомими конкретних типів.

Слабо пов'язаний код ftw :)

Так, це здається правильним підходом. Ні, для програми та бібліотеки пристроїв непогано залежати від інтерфейсу, особливо якщо ви контролюєте впровадження.

Якщо ви стурбовані тим, що пристрої можуть не завжди реалізовувати інтерфейс, з будь-якої причини ви можете використовувати схему адаптера та адаптувати конкретну реалізацію пристроїв до інтерфейсу.

EDIT

Звертаючись до свого п’ятого занепокоєння, подумайте про таку структуру (я припускаю, що ви контролюєте визначення своїх пристроїв):

У вас є основна бібліотека. У ньому є інтерфейс під назвою 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. Але хіба це погано?

Вам потрібно думати навпаки. Якщо ви не підете цим шляхом, програмі потрібно буде знати про всі різні пристрої / реалізації. Що слід пам’ятати, це те, що зміна цього інтерфейсу може зламати вашу програму, якщо вона вже знаходиться в природі, отже, ви повинні ретельно розробити цей інтерфейс.

Чи здається це правильним підходом до реалізації інтерфейсу для усунення залежності між моїм додатком та пристроєм, який він використовує?

Просто так

як бетон насправді потрапляє в додаток

Додаток може завантажувати бетонну збірку (dll) під час виконання. Дивіться: /programming/465488/can-i-load-a-net-assembly-at-runtime-and-instantiate-a-type-knowing-only-the-na

Якщо вам потрібно динамічно розвантажувати / завантажувати такий "драйвер", вам потрібно завантажити збірку в окремий AppDomain .