polymorphism advice,

[vsgdp]

I have a set of brush classes that inherit from Brush. They override a pure
virtual paint method. When the user selects a new brush, I just have a
Brush pointer point to an instance of the particular selected type of brush.

The problem is that some brush settings don't apply to every kind of brush.
So it is difficult to set the particular brush property with the abstract
brush pointer. I see two ways to handle this:

Add a virtual "set" function that takes an AllBrushProperties structure
(some properties will be unused depending on the brush) so that each brush
can update itself correctly.

Use runtime type checking and downcast to the type to call the appropriate
set method.

I don't really like either as it sort of ruins my otherwise clean
polymorphic system.

[Puppet_Sock]

vsgdp wrote:
[snip]

The problem is that some brush settings don't apply to every kind of brush.
So it is difficult to set the particular brush property with the abstract
brush pointer. I see two ways to handle this:

Old problem, new form. It arises because your design has not kept
subsitution in mind. when a derived class is designed, it must be
able to fill in the hole left for a base class. Here's an example:

All birds fly.
Ostrich is a bird.
Ostrich does not fly.

You must give up one (or more) of these to make it work.

- Maybe not all birds fly. The "make bird fly" interface could define
what happens when the bird fails to fly. Or there could be
exceptions.
- Maybe Ostrich is not a bird. Could be you have two categories
that derive from proto-bird. Proto-bird does not define flight.
Flighted-bird is a proto-bird that flies. Non-flying-bird is a
proto-bird
that does not fly, and Ostrich fits under that.
- Ostrich might fly. (Call the airlines.)
Socks

[mlimber]

vsgdp wrote:

I have a set of brush classes that inherit from Brush. They override a pure
virtual paint method. When the user selects a new brush, I just have a
Brush pointer point to an instance of the particular selected type of brush.

The problem is that some brush settings don't apply to every kind of brush.
So it is difficult to set the particular brush property with the abstract
brush pointer. I see two ways to handle this:

Add a virtual "set" function that takes an AllBrushProperties structure
(some properties will be unused depending on the brush) so that each brush
can update itself correctly.

Use runtime type checking and downcast to the type to call the appropriate
set method.

I don't really like either as it sort of ruins my otherwise clean
polymorphic system.

This is not really a C++-specific question so much as an OO question.
You might try in comp.object or similar.

Cheers! --M

[Victor Bazarov]

"vsgdp" <he***@null.comwrote...

>I have a set of brush classes that inherit from Brush. They override a
pure virtual paint method. When the user selects a new brush, I just have
a Brush pointer point to an instance of the particular selected type of
brush.

The problem is that some brush settings don't apply to every kind of
brush.

Like which? And if the brushes are not truly *extending* the base Brush,
why are they deriving from it?

So it is difficult to set the particular brush property with the abstract
brush pointer.

What do you mean by "to set the particular brush"?

I see two ways to handle this:

Add a virtual "set" function that takes an AllBrushProperties structure
(some properties will be unused depending on the brush) so that each brush
can update itself correctly.

Use runtime type checking and downcast to the type to call the appropriate
set method.

I don't really like either as it sort of ruins my otherwise clean
polymorphic system.

"Clean"? Are you sure? You know, there's much to be said about deriving
a PhoneNumber class from a String class, for example. In my book public
inheritance is not the right thing for those. A phone number, although can
be represented by a string, is not a true *extension* of it. It seems that
you are looking at your polymorphic system through rosy glasses.

Another possibility is to have a *polymorphic* BrushPropertySetter class
and have every Brush descendant present a pointer to its own "Setter". I
don't know (yet) what properties you have that are not common, but each
of the brush-specific setters can present its own interface to the user,
and the user then sets certain properties that will be used to update the
correct brush (or something like that anyway).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Daniel T.]

In article <fW7yg.7277$5K2.1890@fed1read03>, "vsgdp" <he***@null.com>
wrote:

I have a set of brush classes that inherit from Brush. They override a pure
virtual paint method. When the user selects a new brush, I just have a
Brush pointer point to an instance of the particular selected type of brush.

The problem is that some brush settings don't apply to every kind of brush.
So it is difficult to set the particular brush property with the abstract
brush pointer. I see two ways to handle this:

Add a virtual "set" function that takes an AllBrushProperties structure
(some properties will be unused depending on the brush) so that each brush
can update itself correctly.

Use runtime type checking and downcast to the type to call the appropriate
set method.

I don't really like either as it sort of ruins my otherwise clean
polymorphic system.

Ask about this on comp.object

[vsgdp]

>>I have a set of brush classes that inherit from Brush. They override a

>>pure virtual paint method. When the user selects a new brush, I just have
a Brush pointer point to an instance of the particular selected type of
brush.

The problem is that some brush settings don't apply to every kind of
brush.

Like which? And if the brushes are not truly *extending* the base Brush,
why are they deriving from it?

Basically my brushes paint different kinds of shapes/patterns. So it seemed
to make sense to have them derive from Brush and implement the paint method.
To give you an example, some brushes require a frequency member because they
paint sinusoidal patterns. For some brushes, the strength of the brush
weakens over distance, but not for all.

>So it is difficult to set the particular brush property with the abstract
brush pointer.

What do you mean by "to set the particular brush"?

I mean, if I need to set the frequency of a brush (only certain brushes have
frequency) this is difficult to do with a pointer to the base class.

In retrospect, I think I found a solution. I store an instance of each
brush type in the program, and only the "currently selected" brush is a
pointer to the base class. Therefore, when the user changes the property of
a brush, I can just apply it to the concrete instance with no problem.

[Victor Bazarov]

"vsgdp" <he***@null.comwrote...

>>>I have a set of brush classes that inherit from Brush. They override a
pure virtual paint method. When the user selects a new brush, I just
have a Brush pointer point to an instance of the particular selected type
of brush.

The problem is that some brush settings don't apply to every kind of
brush.

Like which? And if the brushes are not truly *extending* the base Brush,
why are they deriving from it?

Basically my brushes paint different kinds of shapes/patterns. So it
seemed to make sense to have them derive from Brush and implement the
paint method. To give you an example, some brushes require a frequency
member because they paint sinusoidal patterns. For some brushes, the
strength of the brush weakens over distance, but not for all.

But that's exactly what makes deriving from a common base class pointless.
You can't expect to have such different interfaces in those derived classes
and still derive them from only one base class.

>>So it is difficult to set the particular brush property with the
abstract brush pointer.

What do you mean by "to set the particular brush"?

I mean, if I need to set the frequency of a brush (only certain brushes
have frequency) this is difficult to do with a pointer to the base class.

Of course! That's what makes them break the design (and if the design can
be so easily broken, it's just bad design).

In retrospect, I think I found a solution. I store an instance of each
brush type in the program, and only the "currently selected" brush is a
pointer to the base class. Therefore, when the user changes the property
of a brush, I can just apply it to the concrete instance with no problem.

Sounds good to me.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Philipp]

Victor Bazarov wrote:

"vsgdp" <he***@null.comwrote...

>>Basically my brushes paint different kinds of shapes/patterns. So it
seemed to make sense to have them derive from Brush and implement the
paint method. To give you an example, some brushes require a frequency
member because they paint sinusoidal patterns. For some brushes, the
strength of the brush weakens over distance, but not for all.

But that's exactly what makes deriving from a common base class pointless.
You can't expect to have such different interfaces in those derived classes
and still derive them from only one base class.

Are you saying that every derived class should have the same interface?
Imagine a class Fruit with derived classes Strawberry and Orange

The Oranges class has a method peel();

Is this bad design because Strawberry has not a peel() method?

Or does it become bad design only if you want to use a Fruit pointer and
in some cases only apply the peel() method?

Phil

[Victor Bazarov]

Philipp wrote:

Victor Bazarov wrote:

>"vsgdp" <he***@null.comwrote...

>>Basically my brushes paint different kinds of shapes/patterns. So
it seemed to make sense to have them derive from Brush and
implement the paint method. To give you an example, some brushes
require a frequency member because they paint sinusoidal patterns. For
some brushes, the strength of the brush weakens over distance,
but not for all.

But that's exactly what makes deriving from a common base class
pointless. You can't expect to have such different interfaces in
those derived classes and still derive them from only one base class.

Are you saying that every derived class should have the same
interface? Imagine a class Fruit with derived classes Strawberry and
Orange
The Oranges class has a method peel();

Is this bad design because Strawberry has not a peel() method?

It is bad design if your Fruit class doesn't have the "cleanme" member
implemented differently in Orange, Strawberry, Cherry, etc., but instead
tries to use "peel" for Orange and "skin" for Peach and "pit" for Cherry.
The system should rely on proper _implemenatation_ and _polymorphic_
behaviour, instead of trying to adapt to whatever derived classes provide.

We're not talking about the situation when your system is designed to deal
with Oranges and it knows how to "peel" them. We're talking of a system
that is supposedly geared towards generic interaction with its pieces.

Or does it become bad design only if you want to use a Fruit pointer
and in some cases only apply the peel() method?

Exactly.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Frederick Gotham]

Victor Bazarov posted:

>Are you saying that every derived class should have the same
interface? Imagine a class Fruit with derived classes Strawberry and
Orange
The Oranges class has a method peel();

Is this bad design because Strawberry has not a peel() method?

It is bad design if your Fruit class doesn't have the "cleanme" member
implemented differently in Orange, Strawberry, Cherry, etc., but instead
tries to use "peel" for Orange and "skin" for Peach and "pit" for Cherry.
The system should rely on proper _implemenatation_ and _polymorphic_
behaviour, instead of trying to adapt to whatever derived classes

provide.
Indeed, perhaps something like:

#define override virtual

class Fruit {
public:

virtual PrepareForConsumption() {}
};

class Orange : public Fruit {
public:
override PrepareForConsumption()
{
/* Peel */
}
};

class Cherry : public Fruit {
public:
override PrepareForConsumption()
{
/* Pit */
}
};

--

Frederick Gotham

[Victor Bazarov]

Frederick Gotham wrote:

Victor Bazarov posted:

>>Are you saying that every derived class should have the same
interface? Imagine a class Fruit with derived classes Strawberry and
Orange
The Oranges class has a method peel();

Is this bad design because Strawberry has not a peel() method?

It is bad design if your Fruit class doesn't have the "cleanme"
member implemented differently in Orange, Strawberry, Cherry, etc.,
but instead tries to use "peel" for Orange and "skin" for Peach and
"pit" for Cherry. The system should rely on proper _implemenatation_
and _polymorphic_ behaviour, instead of trying to adapt to whatever
derived classes provide.

Indeed, perhaps something like:

#define override virtual

class Fruit {
public:

virtual PrepareForConsumption() {}

RVT is missing..

virtual bool PrepareForConsumption() = 0;

I'd keep it pure.

};

class Orange : public Fruit {
public:
override PrepareForConsumption()

override bool PrepareForConsumption()

{
/* Peel */
}
};

class Cherry : public Fruit {
public:
override PrepareForConsumption()

override bool PrepareForConsumption()

{
/* Pit */
}
};

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[shadowman615]

Victor Bazarov wrote:

Frederick Gotham wrote:

Victor Bazarov posted:

>Are you saying that every derived class should have the same
interface? Imagine a class Fruit with derived classes Strawberry and
Orange
The Oranges class has a method peel();

Is this bad design because Strawberry has not a peel() method?

It is bad design if your Fruit class doesn't have the "cleanme"
member implemented differently in Orange, Strawberry, Cherry, etc.,
but instead tries to use "peel" for Orange and "skin" for Peach and
"pit" for Cherry. The system should rely on proper _implemenatation_
and _polymorphic_ behaviour, instead of trying to adapt to whatever
derived classes provide.

Indeed, perhaps something like:

#define override virtual

class Fruit {
public:

virtual PrepareForConsumption() {}

RVT is missing..

virtual bool PrepareForConsumption() = 0;

I'd keep it pure.

};

class Orange : public Fruit {
public:
override PrepareForConsumption()

override bool PrepareForConsumption()

{
/* Peel */
}
};

class Cherry : public Fruit {
public:
override PrepareForConsumption()

override bool PrepareForConsumption()

{
/* Pit */
}
};

Suppose you had:
Class PeelableFruit : public Fruit

Class Pitable Fruit : public Fruit

Then derive lemon, orange, and banana from PeelableFruit, no? This
could be a way to have several (but not all) subclasses of Fruit that
need peeling, and several others than need pitting.

[shadowman615]

[e-mail] wrote:

Suppose you had:
Class PeelableFruit : public Fruit

Class PitableFruit : public Fruit

sorry should be:

class PeelableFruit : public Fruit
class PitableFruit : public Fruit

[Victor Bazarov]

sh**********@comcast.net wrote:

[..]
Suppose you had:
Class PeelableFruit : public Fruit

Class Pitable Fruit : public Fruit

Then derive lemon, orange, and banana from PeelableFruit, no? This
could be a way to have several (but not all) subclasses of Fruit that
need peeling, and several others than need pitting.

That is a good solution if your system is able to recognize those two
additional abstractions.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Frederick Gotham]

Victor Bazarov posted:

virtual bool PrepareForConsumption() = 0;

I'd keep it pure.

The reason I opted to provide an empty function (as opposed making it
"pure") is so that it would be very simple to implement a fruit which
required no preparation for consumption, such as a strawberry:

class Fruit {
public:

virtual void PrepareForConsumption() {}
};

class Strawberry : public Fruit {};

int main()
{
Strawberry obj;
}
Let's not drag out this example to far... people tend to lose interest when
the example isn't realisitic.

--

Frederick Gotham