Шаблон проектирования для горелки EEPROM

Question

Я построил основную горелку EEPROM с помощью Teensy ++ 2.0 для моего моста с ПК, и он отлично работает, но, поскольку я стараюсь расширить его совместимость, мой код становится довольно взломанным. Я ищу несколько советов для правильной разработки для расширения этого кода. Я взял класс в шаблонах проектирования программного обеспечения, но прошло некоторое время, и сейчас я рисую пробел. В принципе, вот прецедент:

У меня есть несколько методов, таких как ReadByte(), WriteByte(), ProgramByte() (для FlashROM, для которых требуется многобайтовая последовательность записи для программирования), EraseChip(), и т. д., так что в основном у меня есть чистый виртуальный базовый класс EEPROM, который реализуется конкретными классами для каждого типа микросхемы, который я хочу поддерживать. Сложная часть - это определение того, какой объект типа чипа должен генерировать. В настоящее время я использую псевдотерминальный интерфейс на последовательном входе Teensy ++, базовый интерфейс типа командной строки с параметрами, для отправки таких параметров, как тип чипа, в Teensy ++. Вопрос в том, есть ли шаблон дизайна (в C/C++), что-то вроде Factory Pattern, который будет вводить строковый ввод типа чипа (потому что это то, что я получаю от пользователя) и вернуть объект EEPROM от правильного производного типа, без необходимости вручную создавать какой-либо большой оператор switch или что-то уродливое, как если бы я должен был добавить новый чип в список в любое время, когда создаю новый класс, основанный на чипе? Так что-то вроде:

общественного Const EEPROM & GetEEPROM (Const станд :: строка & идентификатор)

и если я передать ему строку «am29f032b» он возвращает ссылку на объект AM29F032B, или если я передать его строка «sst39sf040» возвращает ссылку на объект SST39SF040, который я мог бы затем вызвать ранее упомянутые функции, и он будет работать для указанного чипа.

Этот код будет запущен на микроконтроллере AVR, поэтому я не могу ничего иметь с огромными служебными данными OOP, но у конкретного микроконтроллера, который я использую, есть относительно большой объем программной вспышки и рабочей RAM, поэтому не так, как я пытаюсь работать в 2kb, но мне нужно иметь в виду ограниченные ресурсы.

Answer 1

У вас может быть диспетчер фабрики singleton, который хранит карту объекта string-> factory. Тогда каждый заводский класс будет иметь глобальный экземпляр, который регистрируется с менеджером при запуске.

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

Answer 2

Что вы ищете, это Вставной завод. Здесь есть good description. Это объясняется Джоном Влиссидесом (1 из Gang of Four) и занимает шаблон фабрики в виде рисунка на несколько шагов дальше. Этот шаблон также является архитектурной основой COM.

Обычный способ реализации на C++ состоит в том, чтобы поддерживать статический реестр абстрактных фабрик. При разумном использовании нескольких шаблонов и статических инициализаторов вы можете обернуть всю партию несколькими строками котельной плиты, которые вы включаете в каждый конкретный продукт (например, тип чипа).

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