M
Medi Montaseri
Hi,
Given a collection of similar but not exact entities (or products)
Toyota, Ford, Buick, etc; I am contemplating using the Abstraction pattern
to provide a common interface to these products. So I shall have an
Abstract Base called 'Car' implemented by Toyota, Ford, and Buick.
Further I'd like to enable to client to say
Car *factory;
Car *mycar = factory->make ( "Ford" );
However note how 'mycar' is of type 'Car' and although make() will
return (new Ford ), an up-cast will take place and what client now has
is an instance of Car (abstract) and not Ford (concrete).
True that with Virtual Methods, the appropriate method will be called,
but I now have a data-member problem as the newly created and returned
object will only have access to Base data members. Again I don't want the
client to be aware of what type of 'Car' he/she will be using, ie I don't want
(if possible) to force the client to say
Ford *mycar = factory->make ( "Ford" )
Because client is now becomming aware of 'Car' vs 'Ford'.
One answer would be to have the Base have all the data members (superset)
of any Car-type. But now Ford has to know what is needed for it and have code
that guard against under usage or over usage. ie Ford would say, I don't need this
data member, why is it here...
Another answer would be, sorry can't do. Your client has to provide the
correct lval type during the object creation to reach the exact object.
If the client is to be aware, then I'm loosing part of Abstraction , ie who cares
wether its a Toyota or Ford, to my client its just a Car.
By the way I know my people who actually think that way about cars....
Given a collection of similar but not exact entities (or products)
Toyota, Ford, Buick, etc; I am contemplating using the Abstraction pattern
to provide a common interface to these products. So I shall have an
Abstract Base called 'Car' implemented by Toyota, Ford, and Buick.
Further I'd like to enable to client to say
Car *factory;
Car *mycar = factory->make ( "Ford" );
However note how 'mycar' is of type 'Car' and although make() will
return (new Ford ), an up-cast will take place and what client now has
is an instance of Car (abstract) and not Ford (concrete).
True that with Virtual Methods, the appropriate method will be called,
but I now have a data-member problem as the newly created and returned
object will only have access to Base data members. Again I don't want the
client to be aware of what type of 'Car' he/she will be using, ie I don't want
(if possible) to force the client to say
Ford *mycar = factory->make ( "Ford" )
Because client is now becomming aware of 'Car' vs 'Ford'.
One answer would be to have the Base have all the data members (superset)
of any Car-type. But now Ford has to know what is needed for it and have code
that guard against under usage or over usage. ie Ford would say, I don't need this
data member, why is it here...
Another answer would be, sorry can't do. Your client has to provide the
correct lval type during the object creation to reach the exact object.
If the client is to be aware, then I'm loosing part of Abstraction , ie who cares
wether its a Toyota or Ford, to my client its just a Car.
By the way I know my people who actually think that way about cars....