Наверняка вам, как и мне, все уши прожужжали шаблонами проектирования.  Вот и решил я привести свои мозги в соответствие с веяниями моды и прочитать классическую книжку “банды четырех”.

Книжка хоть и интересная, но читается довольно туго – иногда перевод сильно хромает. В начале книжки есть пример архитектуры WYSIWYG-редактора, на которой показывается реальное применение шаблонов проектирования. Я читал этот раздел только после того, как прочитал справочник шаблонов.

Я пытался не просто читать книжку, но и писать текущие программы с использованием шаблонов. Были как положительные, так и отрицательные стороны. Я убедился, что шаблоны – не панацея.

Самым адским опытом стало применение шаблона State для простенькой машины состояний. Код раздулся так, что я там чуть не потерялся. Получилось очень некрасиво. С другой стороны, та-же машина состояний, вынесенная в отдельный поток уместилась в одну страницу.

В любом случае, шаблоны учат правильно разбивать системы на объекты. Что касается применения шаблонов во встраиваемых системах, то оно весьма ограничено тем, что у нас часто нет освобождаемой динамической памяти.

Итак, пройдемся по шаблонам и я опишу, какое применение их я вижу в эмбедде:

Порождающие паттерны

1. Abstract Factory – тут вроде все понятно, в зависимости от состояния ножки при загрузке система может выполнять несколько разных функций, определяемых некими классами. Эти классы создаются только при запуске.
2. Builder – применение не ограничено, билдер может быть и статическим. Можно строить пакеты, собирать систему из заранее созданных кусочков, итп.
3. Factory Method – к сожалению, не особо полезен – нужна динамическая память.
4. Prototype – можно приводить один статический объект в соответствие другому. Хотя, для этого можно просто использовать memcpy
5. Singleton – применение неограниченно, хотя народ считает синглтоны дурным тоном. К примеру, модуль управления блоком питания может быть синглтоном.

Структурные паттерны

1. Adapter – тут вроде как все понятно – адаптируем что-то одно к интерфейсу чего-то другого. Необходимости в нем у меня пока не возникало.
2. Bridge – может использоваться в драйверах. К примеру, абстракциями могут быть Uart и UartWithHandshaking, а реализациями – LpcUartImpl, Stm32UartImpl. Хотя, если у вас прямо аж такие требования к переносимости, нужно задуматься.
3. Composite – не очень применимый шаблон из-за ограниченности памяти. Для него придется использовать пулы объектов. Я использовал его для конструирования меню.
4. Decorator – вполне себе применимый шаблон. Я использовал его, чтобы передавать данные, предназначенные для RS232 по RS485 сети.
5. Facade – пока у меня небыло таких “огромных подсистем”, для которых необходим был бы фасад.
6. Flyweight – лично я часто его использую, хотя мне это и не нравится. По-моему, Flyweight очень сильно нарушают инкапсуляцию, сохраняя свое состояние во внешнем объекте.

   Я использую Flyweight как-раз тогда, когда нужно обойти отсутствие динамической памяти.

   Пример из практики – класс, считывающий информацию с устройства, которому передаются данные о том, откуда и куда ее считывать.

7. Proxy – Пример: по приему каждого байта в пакет нужно обнулить таймаут.

Паттерны поведения

1. Chain of Responsibility – у меня используется для приёма нескольких разных пакетов. Если байт не подошел одному пакету, то передается другому.
2. Command – используется для обработки команд, присланных с компьютера.
3. Interpreter – требует динамической памяти, даже и не знаю, где его применить. По-моему он чересчур жирный даже для ПК.
4. Iterator – применяется для перечисления приборов, находящихся на связи, Списка переменных, полученный от приборов да и много еще где. Очень полезный паттерн.
5. Mediator – у меня применяется для передачи данных между устройствами. Сами интерфейсы устройств не знают друг про друге.
6. Memento – если показываем пользователю меню, где он может выбрать Ok или Cancel, то состояние до редактирования можно запомнить в Memento.
7. Observer – я использую обзервер для слежки за ножками с прерываниями. Несколько частей программы могут подписаться на события типа “возрастающий фронт”  или “спадающий фронт” такой-то ножки. Может показаться, что это жирно, но у меня во многих местах не требуется прямо такая уж мгновенная реакция, микросекунда задержки вполне допустима.
8. State – я уже рассказал о своём негативном опыте. Хотя, паттерн и красивый, но я его нигде не использую. Принципиальных ограничений нет, все состояния можно создать статически, но код получается слишком уж жирным.
9. Strategy – очень полезный шаблон. С помощью него я делаю абстракцию от аппаратуры, да и многое другое.
10. Template Method – мой прибор может считывать данные с нескольких типов устройств. Алгоритм считывания задается шаблонным методом, а сам доступ к данным – подклассами типов устройств.
11. Visitor – его я нигде не использую, просто не было необходимости. Принципиальных ограничений нет.

Стоит ли читать эту книгу эмбеддеру? Думаю, да, особенно, если вы считаете, что ООП есть место в эмбедде и если вы не совсем новичок.

Если есть минутка, опишите, как вы применяли шаблоны проектирования в эмбедде!