Dynamic object costuming

[Derek]

I have an advanced question that I hope there is a possible answer
for...

Say that I have a list of base objects and I wish to allow them to be
passed to various routines which may wish to temporarily give them
extra functionality akin to an actor putting on a costume and taking on
a role. The base class would need to provide storage for the costume,
and the derived classes would have specific costume methods.

While I imagine this could be done with virtual member functions for
controlling the "costume" in the derived classes, operating upon a
"void *" placeholder in the base "actor" class, I'm not sure if that is
the best or most desirable method.

[Ben Pope]

Derek wrote:

I have an advanced question that I hope there is a possible answer
for...
Ask away.
Say that I have a list of base objects and I wish to allow them to be
This already sounds bad. "base" implies polymorphic behaviour. List of
base implies slicing.
passed to various routines which may wish to temporarily give them
extra functionality akin to an actor putting on a costume and taking on
a role. The base class would need to provide storage for the costume,
and the derived classes would have specific costume methods.
I think I follow. The base stores data and the derived operate on it?
Thats not a good design choice.
While I imagine this could be done with virtual member functions for
controlling the "costume" in the derived classes, operating upon a
Only if your list is of pointers to base.
"void *" placeholder in the base "actor" class, I'm not sure if that is
the best or most desirable method.

void* is rarely a good idea.

I see no question.

What are you actually trying to achieve?

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Derek]

Yes, the list would be a list of pointers to base objects.

I guess it would have been better to frame the question from a "user"
point of view than an "actor" point of view, but it's all the same.

You have a system where you have a variable number of "user" objects in
a list.

These users can access various aspects of the system... they could be
anything... email, chat, file management, etc.

When a User object accesses the email module, it would be nice if that
user could then become an EmailUser (a derived class of User), and have
extra functionality, but keep a pointer to any email specific data
pointed to by a generic data pointer (void * or maybe a base data
object) within the User class, but when acting as an EmailUser, the
EmailUser specific methods would reference the EmailData object.

I imagine this is a somewhat common requirement, but I'm not sure about
the best way to go about doing this in C++.

I'm currently doing this with a lot of ugly typecasting, but I am
certain there is a better way.

[Luke Meyers]

Derek wrote:

Yes, the list would be a list of pointers to base objects.

I guess it would have been better to frame the question from a "user"
point of view than an "actor" point of view, but it's all the same.

You have a system where you have a variable number of "user" objects in
a list.

These users can access various aspects of the system... they could be
anything... email, chat, file management, etc.

When a User object accesses the email module, it would be nice if that
user could then become an EmailUser (a derived class of User), and have
extra functionality, but keep a pointer to any email specific data
pointed to by a generic data pointer (void * or maybe a base data
object) within the User class, but when acting as an EmailUser, the
EmailUser specific methods would reference the EmailData object.

I imagine this is a somewhat common requirement, but I'm not sure about
the best way to go about doing this in C++.

I'm currently doing this with a lot of ugly typecasting, but I am
certain there is a better way.

At first inspection, I'd say you're making the (very common) mistake of
trying to shoehorn inheritance into a situation where it doesn't
belong. Does the logic for email rely on the User class's protected
interface? If so, why? That's excessive coupling. As a rule, prefer
composition to inheritance.

The core problem is you're trying to break a fundamental assumption of
C++ -- that is, strong typing. What that means is, for the duration of
an object's existence, it is of the same type. It does not "become"
another type, or a derived type, or anything.

There are so many ways to solve the problem you describe without
inheritance. Ask yourself why you want to use inheritance. If you
can't find a good answer, maybe there isn't one. As soon as you stop
using that hammer for everything, you'll find that not every problem
looks like a nail, and you'll learn about the rest of the toolbox.

Luke

[Martin Eisenberg]

Derek wrote:

I have an advanced question that I hope there is a possible
answer for...

Seems like this is what you want to do:
http://c2.com/cgi/wiki?RoleObjectPattern
Martin

--
Quidquid latine scriptum sit, altum viditur.

[Ben Pope]

Derek wrote:

Yes, the list would be a list of pointers to base objects.

I guess it would have been better to frame the question from a "user"
point of view than an "actor" point of view, but it's all the same.
In UML, "actors" are "users", actors don't have to be a person, they
could be a another class.
You have a system where you have a variable number of "user" objects in
a list.

These users can access various aspects of the system... they could be
anything... email, chat, file management, etc.

When a User object accesses the email module, it would be nice if that
user could then become an EmailUser (a derived class of User), and have
You can't do derivation at run time. It would be better if say, the
service (email, chat, file management) would hold a reference (think
boost::shared_ptr) to the user.
extra functionality, but keep a pointer to any email specific data
pointed to by a generic data pointer (void * or maybe a base data
object) within the User class, but when acting as an EmailUser, the
Email specific data should be it's own class, that both the user and the
emailService understand.
EmailUser specific methods would reference the EmailData object.

I imagine this is a somewhat common requirement, but I'm not sure about
the best way to go about doing this in C++.

I'm currently doing this with a lot of ugly typecasting, but I am
certain there is a better way.

Indeed. Ugly typecasting is bad.

It looks to me like you have services (email, chat) and users. The
services could inherit from an abstract base, that manage the user
connections/disconnections.

It does depend on your design though; which persists longer, the
instances of the users or the instances of the services?

Does it make sense for each service instance to have multiple users? Or
would a user each have their own instance?

From your description, I would say a System has services, and a list of
users. The services are somewhat fixed, and the users come and go.
Each service can be accessed by 0 or more users.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...