views:

77

answers:

3

I have defined an Event class:

Event

and all the following classes inherit from Event:

AEvent BEvent CEvent DEvent

Now, with the info I gather from all these Event classes, I will make a chart. With AEvent and BEvent, I will generate points for that chart, while with CEvent and DEvent I will paint certain regions of the chart.

Now, how should I signal this in my class hierarchy?

  1. Should I make AEvent and BEvent inherit from PointEvent while CEvent and DEvent inherit from RegionEvent, being that both RegionEvent and PointEvent inherit from Event?
  2. Should I add a field with an Enum to Event with 2 values, Point and Region, and each of the child classes set their value to it?
  3. Should I use some kind of pattern here? Which one?

Thanks.

+1  A: 

There isn't enough information to know for sure, but it sounds like your first option is the best.

Since AEvent and BEvent are both, in essense, PointEvent subclasses, it makes sense to have a PointEvent class. Same is true with the RegionEvent.

This will help you consolidate shared code, and avoid repeating code unnecessarily.

Reed Copsey
What is the advantage of that against, for example, adding an Enum to the Event class? Thanks
devoured elysium
@devoured: Putting in an Enum will just make you have to add lots of "switch" code through your classes. This is less flexible (what happens if you need a third type?), and tends to make your methods larger (bad) and less obvious(bad).
Reed Copsey
Ah! I see. Never though of that.
devoured elysium
+1  A: 

It really depends on your exact scenario. AEvent, BEvent, RegionEvent, PointEvent are a little vague. ;-)

Option 1 seems to be ok in most cases. However it also sounds a bit like interfaces á la IDrawsRegion or IDrawsPoint would be good here. Also I feel that a bit of the Strategy pattern shines through here which you might want to take a look at.

herzmeister der welten
So with Strategy Pattern, from what I recall, basically I would let everything as it is, and then I'd let my chart generator decide what to do with each one of the classes?
devoured elysium
Yes, that's one possibility I guess. You'd instantiate one of your XEvent classes and inject a `IDrawStrategy` object into it.
herzmeister der welten
How would I "inject" a IDrawStrategy object into it? Should I pass it as a constructor argument? Or what do you mean with it? Should I have in all my event an IDrawStrategy variable, or should I create new event classes that impleent IDrawStrategy? The later option would allow me to separate what an Event is from what you can do with an Event.Thanks
devoured elysium
Yes you can use a constructor argument. I was using jargon of the _Dependency Injection_ pattern, which you might want too look at to help you further decouple your stuff, but this might be overkill for this example for now. And yes, in your `EventX` classes you should then have a property of type `IDrawStrategy` rather than of a concrete type that implements this interface.
herzmeister der welten
+1  A: 

I wouldn't think that an Event would have anything to do with drawing. So I would tend to create something like an EventPainter with subclasses PointEventPainter and RegionEventPainter. Some other entity would be responsible for getting the appropriate EventPainter for a given Event.

Carl Manaster
Yes, I share your concern. Maybe I could have a method that given AEvent,BEvent,CEvent and DEvent would return either a PaintRegion or PaintPoint class?
devoured elysium