Шаблон проектирования для реализации (IoT) -Device API - PullRequest
0 голосов
/ 11 декабря 2018

Я ищу несколько шаблонов проектирования для гибкой реализации IoT-Device-Interface.

Сценарий таков: у нас есть группа устройств (скажем, разные датчики температуры), которые имеют некоторыеобщие функции ...

StartMeasurement - чтобы начать считывание температуры.

Типы устройств отличаются в зависимости от специализации.Второе устройство типа addiotinaly реализует метод для настройки температурного разрешения.

Легко написать это устройство в виде Interface-Classes:

interface BasicTempSensor
{
      StartMeasurement()
}

interface ConfigureableSensor : public BasicTempSensor
{
   ConfigureResolution(config)
}

Теперь эти устройства должны быть подключены как IoT-устройство.Мы хотим использовать Microsoft IoT Device SDK.По сути, он предоставляет способ регистрации методов (по имени) для устройства и регистрации соответствующих обратных вызовов.-> В целом, это коммуникационный уровень, который предоставляет функции для отправки и получения команд и сообщений.

Вопрос в следующем: Я ищу способ сделать хорошую и гибкую абстракцию для коммуникационного уровня на верхних уровнях.Также должна учитываться общая структура интерфейса.Существует ли шаблон проектирования для создания такой абстракции?

Мой первый подход заключается в реализации показанной структуры интерфейса на стороне устройства и приложения.Реализация интерфейса отображается на команды, которые могут быть отправлены через уровень связи.(шаблон адаптера?)

Я также взглянул на структуру http://johnny -five.io / .На стороне приложения функциональность устройства создается из небольших базовых классов.Не знаю, как это происходит на стороне устройства.Может быть, некоторая информация в этом направлении также полезна.

Вкратце: я ищу шаблоны для реализации описания API типобезопасного устройства, которое также полиморфно охватывает общие части устройств.

Спасибо.Tobu

1 Ответ

0 голосов
/ 17 декабря 2018

Полагаю, шаблонный метод - это ответ.

Это означает, что вы определяете базовый класс, предоставляя абстрактный метод для каждой и любой необходимой операции - что означает, что достаточно для описания поведения самого конкретного и сложного датчика .Чем вы подкласс этого базового класса - один раз для каждого датчика;Ваш дорогой друг - компилятор - заставляет вас реализовывать все абстрактные методы - даже те, которые не имеют ничего общего с этим конкретным типом датчика.Поэтому немногие из них, как правило, ничего не делают - либо пустые void методы, либо возвращающие элементы типа вроде BaseClass Calibrate(BaseClass baseClass) { return baseClass; }.

Излишне говорить, что вы сохраняете эти методы protected - чтобы не подвергать внутренние органы наружу.Внешний мир имеет дело и знает только вашу BaseClass - за исключением, конечно, фабрик или чего-либо еще, участвующего в создании соответствующей реализации BaseClass.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...