Re: dynamic_cast is ugly!
In article <47ddb07d$0$8168$4f793bc4@news.tdc.fi>, nospam@thanks.invalid
says...
Jerry Coffin wrote:
struct UML_object {
int x_, y_;
virtual void draw(surface_t &) = 0;
};
class UML_interface : public UML_object {
static color_t color;
public:
static void highlight(bool state=true) {
static color_t colors[] = {
RGB(0,0,0),
RGB(255, 0,0)
};
color = colors[state];
// code to force re-draw goes here.
}
square(int x, int y) : x_(x), y_(y) {}
virtual void draw(surface_t &s) {
// draw "interface" on specified surface
}
};
class UML_class : public UML_object {
public:
UML_class(int x, int y) : x_(x), y_(y) {}
virtual void draw(surface_t &s) {
// draw "class" on specified surface
}
};
I don't really understand what you are doing there. It's not even
valid C++.
Sorry -- I tested the code with the classes named 'circle' and 'square',
and when I edited them for posting, I missed changing the 'square' ctor
to 'UML_interface'. My apologies for that.
Here's the code, edited in my normal code editor, with no further
editing after compiling, to ensure against my fat-fingering (which means
it stil includes working drawing code and such, though that's neither
portable nor really topical):
struct UML_object {
virtual void draw(CDC *) = 0;
// Note that this does NOT include highlight().
};
class UML_interface : public UML_object {
int x_, y_, cx_, cy_;
static DWORD color;
public:
// This implements highlight() ONLY for UML_interface
static void highlight(bool state=true) {
static DWORD colors[] = {
RGB(0,0,0),
RGB(255, 0,0)
};
color = colors[state];
}
UML_interface(int x, int y, int cx, int cy) :
x_(x), y_(y), cx_(cx), cy_(cy)
{}
virtual void draw(CDC *pDC) {
CPen pen;
pen.CreatePen(0, 0, color);
pDC->SelectObject(&pen);
pDC->Rectangle(x_, y_, x_+cx_, y_+cy_);
}
};
class UML_class : public UML_object {
int x_, y_, r_;
DWORD color;
public:
// UML_class doesn't include highlight() either.
//
UML_class(int x, int y, int r) : x_(x), y_(y), r_(r),
color(RGB(0,0,0))
{}
virtual void draw(CDC *pDC) {
CPen pen(0, 0, color);
pDC->SelectObject(pen);
pDC->Ellipse(x_-r_, y_-r_, x_+r_, y_+r_);
}
};
(And public member variables?)
Public member variables have a lot worse reputation than they deserve --
though in many cases, they should be of types that ensure against
misuse. As you can see above, they were originally private, but this
increases the amount of code, without contributing anything relevant to
the question at hand.
This way we don't need separate containers OR a dynamic_cast to
highlight all your UML_interface objects
Maybe one of us is missing the point here?
Yes, you are -- or at least you were. Knowing how Usenet (or the human
psyche) works, you probably figured out that highlight() was specific to
UML_interface about 10 seconds _after_ your post hit the server. Been
there, done that!
The problem is not how to implement a feature which is common to all
the objects. The problem is how to implement a feature which is not.
Of course if a feature is common to all the objects (such as your
highlighting above), you simply make that feature part of the base
class. The problem is that not all features are common to all objects
and cannot be logically placed in the base class.
What you've probably already realized is that highlight() really IS
specific to UML_interface, not common to all the objects.
Of course, you may instead have decided I'm such an idiot that you've
plonked me, so you won't see this either... :-)
--
Later,
Jerry.
The universe is a figment of its own imagination.