So what are situations where you could use such a pattern? Whenever you are faced with a design that requires a "sort of" observer pattern, but where the observer and observable satisfy the above listener-generator description, you need the event-handling pattern instead. An abstract example: a program that can read text commands from a socket could use events to send the data to whoever may be interested in the command. A concrete example:
A stock market program has several components that "live" while the program is running, e.g. a StockMarket object, several Broker objects, several Investor objects, a CentralComputer object, etc. The program runs a loop in which each object is updated every time through the loop to model the stock market according to investor actions. These actions are received on a socket port as an integer id and text string. The id tells the program what type of text command is the string (see below). Additionally, the StockMarket, Broker, and CentralComputer objects can be configured at run time to print out extra debugging info, to take several actions independent of the investor actions, for instance shutdown, crash, etc, or to change operation mode, such as novice vs expert mode. The program reads the text string from a socket port, and depending on the type id of the string (debug type, investor instruction, command, and user level) an event of the appropriate type is created, with the text string in it, and sent. All objects in the system that have registered as listeners of that type of event will hear the event, and take action depending on the text command in it.
include
subdirectory over to a directory of your choice (or leave them where they are and add that subdirectory to your header search path during compilation). There is no library to build as all files are templates.
tests
subdirectory contains a test file that tests the event handling framework (and may give you an example of how to use it, though the instructions below are probably clearer).make
to build it then ./testListening
to run it;
Listener<
YourEvent> listenForEvents()
methodEventSender<
YourEvent >::send(
yourEventInstance )
Refer to the class documentation for more details on the following:
Download the library from SourceForge
This library is based on one developed by the author at the National Research Council (NRC) Canada. It is made available open source, with NRC's permission, in the form of CEHTL. This is a completely new design and implementation of the functionality found in the original source for a large, real-time simulator developed at the Integrated Manufacturing Technologies Institute, one of the many branches of NRC.
Should the lib be in its own namespace? It's barely large enough to justify it.
This project's CVS repository, located on SourceForge, can be checked out online, or through anonymous (pserver) CVS with the following CVS commands (replace cvshost with cvs.cehtl.sourceforge.net, and when prompted for a password for anonymous, simply press the Enter key):
cvs -d:pserver:anonymous@cvshost:/cvsroot/cehtl login
cvs -z3 -d:pserver:anonymous@cvshost:/cvsroot/cehtl co cehtl
Updates from within the module's directory do not need the -d parameter.
Copyright:
Copyright (C) 2002, 2003 Oliver Schoenborn
This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.
You can redistribute it and/or modify it under the terms found in the LICENSE file that is included in the library distribution.