S
Simon Elliott
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?
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?