Re: Virtual constructor?
DS wrote:
For example, suppose you have a class hierarchy like
Client->WebClient->SpecificWebClient. Perhaps there cannot
concurrently
exist two identical SpecificWebClient (since it's associated with a
TCP
connection which you cannot duplicate).
In this case, I would use a weaker association to the TCP connection,
that allows it to be shareable between the <SpecificWebClient>
instances, making them duplicatable (like having member
boost::shared_ptr<TcpConn> in SpecificWebClient. The base class (or
interface) makes certain promises to its client. One of those promises
is that it gives an exact duplicate (of type as well). Duplicate will
be called via Base interface and the caller is not required to know the
real type, but he expects the duplicated type to behave just like the
original type when the rest of the interface is used - does it (can it)
do this when duplicate returns a type higher in the hierarchy? Also, in
proper designed code I would assume that WebClient is abstract (and
non-duplicatable too as it is not-instantiatable). What are you do
return - throw (my fat) interface_not_implemented?
In this case, the logical thing to do if someone tries to duplicate a
SpecificWebClient is to return a WebClient, giving him a new client of
the same type. Obviously, you cannot give him precisely the same
client.
Well, according to your hierarchy, SpecificWebClient is a WebClient and
not visa versa. Therefore you are not giving the caller a client of the
same type. This certainly does not seem like the logical thing to me.
The logical thing to do will be for the derived class (having an isA
relationship with its base) to provide the implementation iaw. the
interface requirements imposed by its base, or not derive at all, or
use some mechanism of sharing of members that allows for duplication.
It is not unusual to have a hierarchy that includes duplicatable and
non-duplicatable objects. Duplicating a non-duplicatable object should
give you the first object up that is duplicatable.
In my opinion, it is unusual and wrong. If this is the case, I smell
rotten design.
Before anyone says that because a SpecificWebClient is not
duplicatable, you should not be able to duplicate it, remember that a
SpecificWebClient *is* a WebClient, and WebClients *are* duplicatable,
giving you another WebClient that may or may not also be a
SpecificWebClient. SpecificWebClients are not duplicatable in the
sense
that duplicating them cannot produce a SpecificWebClient because the
connection is inherenently incapable of being duplicated.
Not if one has a weak relation with a connection, or if a connection
can be shared amongst objects that were duplicated.
Similar logic applies to any class trees where sufficiently derived
classes cannot be duplicated but higher-up classes can. Consider, for
example:
PublicKey->RSAPublicKey->RSAPublicKeyOnCryptoToken. Some code might
Duplicate an RSAPublicKey to get one to hold onto for awhile, but you
don't want to duplicate the key on the token and you may not want two
objects referring to the same key on the same token. So you either
don't implement 'Duplicate' on 'RSAPublicKeyOnCryptoToken' or make it
return an 'RSAPublicKey'.
....Or you have duplicatable and non-duplicatable keys in your hierarcy,
both types being on the same level. OTOH, a key can be non-duplicatable
by default, as this seems to be the case in your example. A
duplicatable key can be a special case. If you don't want to
re-implement certain functionality, make use of implementation classes
that contain the implementation (and algorithms), and forward call
their member functions to adhere to the interface imposed by the
interface (prefer aggregation or containment to inheritance, prefer
weakest relationship - ring a bell?).
One could even use a template interface to specify whether or not
something is duplicatable.
template <bool Dup>
class Key
{
virtual Key* Dup() const = 0;
//...
};
template <>
class Key<false>
{
//Dup doesn't exists as part of this interface...
};
I suppose better alternatives exist, but you get the idea
Key<duplicatable> <----- Its hierarchy
Key<non-duplicatable> <----- Its hierachy
Now we don't impose requirements on our derived that they can't
enforce.
We deal with many types of objects that are inherently not
duplicatable
and where it does not make sense to duplicate to another object that
refers to the same underlying object.
Then don't derive from a base class that imposes that constraint (to be
duplicatable) on the derived's implementation, or make another plan.
Regards,
Werner
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]