I have a class which uses a singleton to output progress messages for
logging or display. It's typically used deep within a hierarchy of
aggregations, inheritances and containers. The singleton keeps things
nice and simple: the classes further up the hierarchy don't need to know
about the mechanism used for handling progress messages.
I now want this class to be more generic, and perhaps put it into a
library. The users of the class may not want to provide a singleton for
outputting progress messages. In a recent thread here, some interesting
ideas for handling notification and other callbacks were suggested.
Neither of the most useful methods seem applicable to this particular
case:
1/ Use boost::bind and boost::function. In a deeply nested hierarchy of
classes, this would mean adding methods to all the higher level classes.
2/ Give the class some virtual functions to do the notification. The
users of the class provide a descendant which does the actual
notification. Unfortunately a container can't be a descendant of the
class it contains, so this starts to get messy quite quickly.
The way I normally deal with this situation is to have a 'notify object'
with loads of virtual functions. The users of the class create a class
which inherits from the 'notify object', instantiate it, and pass a
pointer down to the class which is going to do the notification. In this
case this suffers from the same problem as using boost::bind and
boost::function: umpteen intermediate layers will need to have a method
to pass a pointer to the 'notify object' downwards.
Are there any other design patterns here which would allow me to achieve
my goals without these disadvantages?
--
Simon Elliott
http://www.ctsn.co.uk/
