До сих пор осталась нерешенной одна очень важная проблема: как (а также где) создавать объекты? Здесь возможны варианты.

Один из вариантов — создание локальной переменной в стеке. Он привлекателен в первую очередь тем, что в этом случае принципиально невозможна утечка памяти — при выходе из функции, в которой был создан объект, область ее стека полностью освобождается. К сожалению, нам это не подходит, ведь в нашей модели клиент не знает ничего о внутреннем строении объекта, поэтому не может выделить достаточную область стека для его хранения. Конечно, можно было бы запрашивать у класса его размер через специальный метод, затем выделять область заданного размера в стеке и создавать там объект, но такое решение слишком усложнено.

Другой вариант, который часто применяется в «больших программах», — создание объекта в «куче» посредством оператора new. Это мощное и гибкое решение, поскольку позволяет создавать динамические структуры, размер которых неизвестен заранее при компиляции программы. Впрочем, мощные инструменты, как правило, опасны в обращении. Данный случай — не исключение. Во-первых, динамическое создание объектов в среде, не оснащенной «сборщиком мусора», требует весьма кропотливой работы по своевременному уничтожению ненужных объектов, в противном случае неизбежна утечка памяти: «осиротевшие» объекты, забытые создателями, продолжают занимать место в драгоценной оперативной памяти. При интенсивном создании объектов запросто можно превысить лимит доступной памяти, после чего практически неминуем крах приложения. Об актуальности этой проблемы говорит тот пример, что изрядная часть учебников программирования на C++ начинается изобретением велосипеда в виде «умного указателя», который ведет подсчет ссылок на объекты и при обнулении их числа удаляет объект (на самом деле эта полумера, как и все прочие полумеры, не в состоянии решить проблему полностью; впрочем, эта тема лежит за рамками статьи).

Во-вторых, управление «кучей» — нетривиальная задача, требующая немалых накладных расходов. После нескольких циклов выделения/освобождения памяти «куча» фрагментируется, а с ростом фрагментации снижается эффективность использования «кучи». Даже в культовой для многих системе Unix эта задача решалась с переменным успехом, как упоминается в статье «Оптимизация: ваш злейший враг». Реализовать полноценную систему управления памятью на микроконтроллере с объемом оперативной памяти в несколько байт — совершенно нереальная задача, поскольку управлять будет попросту нечем: свободной памяти не останется. Получается замкнутый круг: чем меньше доступной памяти, тем выше потребность в качественной системе управления ей, и одновременно тем меньше шансов такую систему реализовать. Очевидно, создание объектов в «куче» также плохо подходит для встроенных систем.

Чтобы избежать сложностей работы с «кучей», во встроенных приложениях обычно применяется статическое управление памятью: все необходимые объекты создаются заранее, на этапе компиляции. При этом вероятность неприятных сюрпризов во время выполнения минимальна: если мы выйдем за допустимые пределы, то получим предупреждение еще во время компиляции. Такой подход представляется мне наиболее целесообразным с учетом нашей специфики, и я намерен его придерживаться. Модуль, отвечающий за работу с объектами, будет содержать пул готовых экземпляров. Например, в нашем проекте достаточно иметь два экземпляра интервальных таймеров, по одному для красного и зеленого каналов. Поэтому модуль интервального таймера будет содержать два таймера. Клиент, которому необходим таймер, сможет запросить его у модуля через вызов специального метода (этот метод является своеобразной разновидностью паттерна проектирования «фабричный метод»). Метод вернет клиенту указатель на выделенный ему экземпляр объекта, которым клиент может пользоваться для своих нужд.

Такая простая стратегия не слишком гибка: мы не можем уничтожить ненужный нам более объект и использовать выделенную ему память для других целей. С другой стороны, встроенные приложения, как правило, используются циклически, производя одни и те же действия, и созданные объекты используются постоянно. Поэтому это ограничение не будет для нас критическим.

Теперь у нас есть все необходимое для создания семейств сходных объектов.