Visualisation of derived classes in C#

Question

I have a base class (representing a real world container filled with small spheres) and some derived classes. This works just fine.
My problem is how to do their visualisation. I have a UserControl visualising the base class. Is the best solution to have a derived UserControl for each of the derived classes? Or is it better to have just one working for all of them?
Edit:
Apparently I was not specific enough. There is always the same basic appearance: rectangle with a lot of circles inside. The difference between the classes is how the container is filled. One type puts a seed in the middle and creates other spheres in a tree like structure - in this case the connecting lines between parents and their children should be drawn.
Generally there should be consistent look of the classes' visualisations with a few specialities for each derived type.

Answer 1

I suspect only you can answer that question definitively. A UI for a given subclass is likely what you want, but if the subclasses differ only slighltly, you could find it easier to add some conditional logic in fewer user controls. I don't think there is One Right Answer to this one.

Answer 2

It hard to say from just the vague description. We'd really need to know, at the least, what are the differences among the derived classes.

Generally, with limited knowledge, I'd go with one derived UserControl per derived class

Answer 3

If the derived classes visualization does not differ from each other, then, by all means, use one UserControl. The main point here is DRY.

Answer 4

This really depends a great deal on how similar the displays will be. If the displays of the derived classes are very similar to the base class then you only need the one UserControl to do the visiualization. OTOH, if each derived class needs to display unique things then you will be better off having a separate UserControl to visualize each derived class. I really can't be any more specific without more specific info on your classes.

EDIT: From your additional info I would say that you should have a base display class that draws the commom rectangular container then have derived UserControls that handle drawing the contents of each specific type.

Answer 5

One approach to the problem would be decomposing it following the MVVC perspective:

You will need one UserControl as a View.

One base Painter, which handles the painting of your "box with circles in it" as a ViewModel. Derived Painters implement different positioning logic of objects and their interconnections.

If the look of your objects can vary then they themselves should be given to the painter as ViewModel possibly through the Adapter pattern.

And finally your circles, rectangles and items associated with them are the Model.

Generally speaking:

View (UserControl) -> ViewModel (Painter + derived Painters + object ViewModels) -> Model (circle, rectangle, etc)

Answer 6

I don't fully understand your problem domain but i think you need to break this up some more. decompose your model into parts and write views for each part then you can just wire them back up.

I would write a View for your Spheres, a view for lines between your spheres and a view for the rectangle holding everything then each of your models will be responsible for arranging these and creating the corresponding SphereModels and LineModels (and whatever else you need)then your main view just needs to be responsible for laying these out in the box.

Remember always prefer composition to inheritence! Focus on breaking up your problem into smaller pieces.

good luck

Answer 7

I think I would go with a base Visualizer class that had some protected methods for drawing the circles and lines, and maybe some property for the drawing surface (Canvas?) so each implementation can compute measurement-based positions, etc.

The base class implements all the necessary interface methods/props to make it a visualizer.

Use the strategy pattern in the method called by IDE when your visualizer is supposed to draw itself... that method implementation could clear the canvas, set up brushes, and other things that are to be common to every implementation - then call an abstract method of the base class that actually places the circles/boxes/lines/etc on the canvas.

This way, each specific implementation then only has to worry about the logic to correctly position stuff according to its set of rules - all the "drawing stuff on the canvas" is kept in the base class.

HTH

EDIT: Corrected typo that may have caused confusion, where I used the word "control" when I meant "visualizer."

Answer 8

This sounds like a situation with multiple solutions.

One way to do it would be to set up the UserControl to call a virtual method in the base class, and then override it in the derived classes. In the derived classes, you could just call the base implementation to set up the frame initially.

You could also set it up to render in layers (a container layer, sphere layer, line layer, etc.), and have the child class render any unique layers, and determine order. This can be expensive, but it could smooth the visuals if most of the image stays the same.

Another is to use delegates as opposed to inheritance, but this tends to get messy. This is generally not a good idea due to performance penalties. However, it does have the advantage of runtime flexibility. Depending on the rest of your code, you might be able to switch styles of growth mid-way through with this model. If you don't see yourself taking advantage of this flexibility, I would recommend you use a different model, though.

No matter what method you use, I would recommend that the base class provide the common drawing routines to ensure consistency. The routines in the base class should be used by most child classes, but not necessarily all. This usually results in more manageable code (unless you end up with a 10000 line file), fewer bugs, and less effort.

Answer 9

That sound for me like the decorator pattern:

http://en.wikipedia.org/wiki/Decorator_pattern