This is not how I had interpreted the GoF's description of the
State pattern. In my mind, DerivedClass1 _is_ the Context Class,
i.e. the class that the rest of the system sees and uses. I
don't see what benefit is provided by the FSMContext1 class
above.

It may not make sense in terms of an IS-A relationship, but what I'm
really after is a mechanism for reusing the implementation of a
class that is implemented as an FSMs.

What I have come up with so far is to define a vector
of pointers to the FSM's concrete states in the Context class, so
that the concrete states do not refer to specific concrete state
instances. This allows polymorphism in the concrete states and would
allow me to to reuse the bulk of the concrete state classes and
modify the ones I need to modify.

Each derived Context class' constructor would populate the list
of states with pointers to the appropriate state instances for
that derivative's FSM.

By using the Template pattern on the Context class for the methods
implementing the FSM actions, the actions of the base FSM can be
overriden in derived FSM's when necessary.

I haven't yet figured out how the concrete states would refer
to this list of next state pointers to set the next state.

Only thing is, this is anything but elegant, or easily comprehensible.

MV

Martin Vuille      | Real-time and | Software & Firmware Contracting
JPMV Realtime Inc. |   embedded    | Turnkey Controls Development
Tel.:(613)823-0777 |   control     | System Integration
Fax.:(613)823-3034 |  specialist   | Product Development Consulting