c++ - Design Pattern for an EEPROM burner -

i've built myself basic eeprom burner using teensy++ 2.0 pc bridge, , it's working great, expand compatibility, code getting rather hacky. i'm looking advice proper design making code expandable. i've taken class in software design patterns, awhile ago, , i'm drawing blank. basically, here's use case:

i have several methods, such readbyte(), writebyte(), programbyte() (for flashroms require multi-byte write sequence in order program), erasechip(), etc. have eeprom pure virtual base class gets implemented concrete classes each chip type want support. tricky part determining chip type object generate. i'm using pseudo-terminal front-end on teensy++ serial input, basic command-line type interface parameters, send options chip type teensy++. question is, there design pattern (in c/c++), factory pattern, take string input of chip type (because that's i'm getting user), , return eeprom object of correct derived type, without having manually create big switch statement or ugly i'd have add new chip list time create new chip derived class? like:

public const eeprom & geteeprom(const std::string & id)

and if pass string "am29f032b" returns reference am29f032b object, or if pass string "sst39sf040" returns reference sst39sf040 object, call mentioned functions on, , work specified chip.

this code run on avr microcontroller, can't have huge oop overhead, particular microcontroller i'm using have relatively large amount of program flash , work ram, it's not i'm trying operate in 2kb, have keep in mind limited resources.

what you're looking pluggable factory. there's good description here. it's attributed john vlissides (1 of gang of four) , takes abstract factory pattern few steps further. pattern happens architectural foundation of com.

the usual way of implementing 1 in c++ maintain static registry of abstract factories. judicious use of few templates , static initialisers, can wrap whole lot few lines of boiler-plate include in each concrete product (e.g. chip type).

the use of static initialisers allows complete decoupling of concrete products both registry , code wanting create products, , has possibility of implementing each plug-in.