Прочитал “классическую” книжку GoF’ов

Опубликовано в рубрике "Статьи", 30 августа, 2011.

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

 

image

 

Книжка хоть и интересная, но читается довольно туго – иногда перевод сильно хромает. В начале книжки есть пример архитектуры 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 – его я нигде не использую, просто не было необходимости. Принципиальных ограничений нет.

 

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

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




Комментарии
  1. scratchboom написал(а) 30 августа, 2011 в 18:31

    Читал эту книжицу некоторе примеры довольно искуственны. Имхо паттерны не должны быть самоцелью, а должны появляться в процессе рефакторинга.

    P.S.
    Не думал, что паттерны можно в эмбединге применить)))

    BSVi Reply:

    Насчет примеров — согласен. А эмбеддинг нынче мало чем отличается от обычного программирования.

  2. juray написал(а) 31 августа, 2011 в 1:54

    » шаблоны – не панацея»

    Серебряной пули не существует… ( http://en.wikipedia.org/wiki/No_Silver_Bullet )

  3. MrYuran написал(а) 1 сентября, 2011 в 7:19

    Шаблоны и динамическая память — совершенно параллельные вещи.
    Шаблоны — это своеобразное средство расширения возможностей препроцессора и автоматизации проектирования. В эмбеде совершенно спокойно применяется, даже на 8-битниках с килом ОЗУ. Чтобы проникнуться, почитайте Александреску.

    BSVi Reply:

    Для многих шаблонов просто необходима динамическая память (к примеру, Factory Method тело которого фактически состоит из создания экземпляра объекта).

  4. andy5000 написал(а) 2 ноября, 2011 в 6:09

    тоже читал эту книгу оказалась слишком нудной
    советую эмбеддеру читать вначале
    Гради Буч: Объектно-ориентированный анализ и проектирование
    http://www.proklondike.com/books/oop/buch_ooad.html
    Более интересно написана
    темболее с новыми тенденциями ШП встраивается в семантику языка (C#)

    BSVi Reply:

    У меня сейчас Фаулер, потом книжка по UML, и только потом будет Буч.

  5. bea написал(а) 22 февраля, 2013 в 7:10

    Скажите, а как при помощи Стратегии Вы умудряетесь сделать абстракцию от аппаратуры???? (я только начинаю примерять паттерны, новичок)
    Спасибо!

  6. Darksky написал(а) 16 марта, 2015 в 17:57

    Вот еще собственно неплохая и достаточно простая книга:
    А. Шевчук «Design Patterns via C#» (http://itvdn.com/ru/patterns)

Создать новую ветку комментариев


Вы должны войти или зарегистрироваться чтобы оставить комментарий.