468,537 Members | 1,919 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,537 developers. It's quick & easy.

Making a class more generic [part 1]

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

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

Jul 19 '05 #1
0 1137

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by beliavsky | last post: by
2 posts views Thread by Simon Elliott | last post: by
3 posts views Thread by SimonH | last post: by
34 posts views Thread by Asfand Yar Qazi | last post: by
3 posts views Thread by markww | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.