Best practice for custom control that can switch between objects derived from the same base class

Question

User457814038 posted

I currently work for a company that has a WebUI for our product. At some point a class was made to draw differant kinds of graphs. This class had an ENUM that switched between the differant types(Bar, line, pie, etc). To me it seems like it would be better to make an Abstract base class and a differant class for each of the types rather then using a switch, however, this would require us to change ALL of the pages to hide and show differant controls based on the selected bar type.

 What is typically the best practice for this kind of a situation, I had the idea of creating a proxy control to dish out the differant chart objects on the older site, while any new site could implement the better way but this has been met with resistance. Anyone have any ideas?

Answer 1

User1092940952 posted

I don't know if it's best practice or not but I prefer the method of having a base class.  It allows to perform dependency injection. 

Answer 2

User1119078696 posted

What your doing can be simplified in the long term if you pay the price now.  I have done just what you are talking about with the Dundas Chart tools.

We created a server control that enabled a page to set properties of that control.  That control handled building the chart based on the settings.  So now all of your pages contain reference to this one type of control.  This will save you changing pages in the future.  This control  (or class) holds all of the smarts for determining which chart should be built.

Next make a base (abstract) class that all charts will inherit.  This can hold methods that can set title, bind to data etc.  Anything that is common to all charts.

Make a class for each type of chart to be created.  This class will set properties specific to that type of chart.  You'll find that only a couple of properties are different between the different types of charts.

I created a builder class for our charts.  This class uses reflection to determine what type of chart (class) to create.  We store the name of the class in an xml definition file.  We can add new chart types by simply creating a new concrete chart class.  We don't need to change the base class or the builder. 

The method you are thinking of is right on.  It is a more OO (object oriented) design.  When ever you see a lot of switch or if statements executing.  You need to think more OO.  Your idea is right.  Do it right.  Think containers.