name this pattern game

[Charles McAllister]

I've come across this situation before many times, but don't know the name
for this pattern.
Suppose there is a hierarchy like so...

Vehicle --> Car --> SportsCar

Then suppose that Vehicle has a method, named Repair, that has a default
implementation in Vehicle, but may be overridden if necessary.

Next things get complicated <g>
It becomes necessary to form sub-hierarchys like so...

Vehicle --> Car --> SportsCar
| | |
GermanVehicle GermanCar GermanSportsCar

Now since GermanVehicle may need to override Repair such that its
implementation should be the same for all German vehicles, what is the
appropriate thing to do w/out copying the Repair implementation to other
German vehicle types?

What i tend to do in that case is to make an aggregate VehicleImplementor
(at least this is what i call an 'implementor' but would like to know if
there is some standard name for the pattern). VehicleImplementor is owned
by Vehicle, but its class type is determined by any of the vehicle
descendants via a virtual method, GetVehicleImplementorClass. Vehicle uses
VehicleImplementor to 'implement' the Repair method (among other methods).

So then there can be a GermanVehicleImplementor that is used by all german
vehicles etc. (the only disadvantage being that each german vehicle type
will have to override GetVehicleImplementorClass and supply the correct
implementor class).

Question: What would you call the 'implementor' would it be a 'Strategy'?
or some other pattern?

[Marc Rohloff [TeamB]]

On Thu, 21 Oct 2004 20:38:09 -0600, Charles McAllister wrote:

> I've come across this situation before many times, but don't know the name
> for this pattern.

This is basically the strategy pattern.

--
Marc Rohloff [TeamB]
marc rohloff at myrealbox dot com

[Kyle Cordes]

"Charles McAllister" <cha...@avimark.net> wrote in message
news:4178647b$1...@newsgroups.borland.com...

> Question: What would you call the 'implementor' would it be a 'Strategy'?
> or some other pattern?

Yes, it seems most familiar as Strategy.

It's a fairly common thing to start with with an inheritance hierarchy
directly, then realize you need more than one "axis", and switch to using
the Strategy pattern, once for each "axis". Each axis of strategies can
then use its own inheritance hierarchy as needed.

--
[ Kyle Cordes * ky...@kylecordes.com * http://kylecordes.com ]
[ Better processes, better design, better software. Java, ]
[ Delphi, BDE Alternatives Guide, Enterprise apps, and more ]

[Charles McAllister]

"Kyle Cordes" <ky...@kylecordes.com> wrote in message
news:417877df$1...@newsgroups.borland.com...

> Yes, it seems most familiar as Strategy.
>
> It's a fairly common thing to start with with an inheritance hierarchy
> directly, then realize you need more than one "axis", and switch to using
> the Strategy pattern, once for each "axis". Each axis of strategies can
> then use its own inheritance hierarchy as needed.
>

Thanks Kyle, i'll start naming these classes right then. and P.S. Go
Cards! <g>