ET++ case study (new patterns)

Event handling

Last time we talked about how ET++ uses a Chain of Responsibility to find the handler of an input event. What happens when the handler runs? One might have the handler directly implement the operation associated with the event. Some frameworks, like MFC, work this way, but not ET++.

Event handlers in ET++ immediately return a Command object, which encapsulates the real work to be done. The Command is queued up for a Command Processor object which will execute the Command by calling its DoIt() method. The Command Processor will also save the Command in a history list so that it can be later undone. Commands are undone by calling their UndoIt() method, and redone by calling their RedoIt() method.

This design is an instance of the Command pattern. It ensures that no matter which part of the interface initiates a request, the request is always handled in the same way and is always undoable.

Object copying, persistence, and communication

Copying an arbitrary object is not as simple as it seems. The object may contain other objects, which must also be copied. However, the same object may be contained twice, or there may be a containment cycle. Simply copying the object's fields one-by-one will not work in this case, and may even loop forever.

ET++ solves this problem by using the Atomizer pattern. The same solution also allows storing and transmitting arbitrary object structures.

Thomas Minka

Last modified: Wed Jan 29 22:21:13 EST 1997