I have multiple objects that inherit from a base class and am trying to decide how the user should edit them. There are many common fields and a few fields that only apply to each sub class. Is there a design pattern to address this?
I was thinking I could have one web page for each one or I could have a single web page and show/hide the fields for the subclass. I can think of pros and cons for each one. It'd be nice to know if there's a standard way of handling it.
I've had pretty good luck with dynamic tabs. The idea being that all of the common fields go on a Main tab. Anything that depends on the particular class goes on a tab with a similar name.
At runtime I decide what object it is and show the appropriate tab(s).
You could use parallel class hierarchies (which isn't a design pattern in itself). Using this idea, you'd create a base code-behind class to cater for your base class's properties and then create classes derived from this to support the necessary UI to handle the additional properties of your derived classes.
Parallel class libraries can lead to problems e.g. if you create a new derived class then you also have to create a new derived UI class etc, however if your derived UI classes are simple then this might not become too much of a problem.
Edit:
If this is the route you go down, you would want to create a hierarchy of user controls rather than pages, then add the appropriate user control to your page at runtime.
The opposite approach to the class hierarchy is the compositional school. A compositional approach to this problem would have you create a basic display control for the base data of your class (which would normally in a compositional scheme be held in a core object) and a specialized control for the specialized data (which would be held in its own separate object).
This has some advantages and some disadvantages. The most important advantages are that you have an infinitely extensible system for displaying common data set types all the way up the class tree, and you get the normal compositional style strengths - changing the definition of the class tends to break down into smaller edits on smaller, more self-contained units. The most important disadvantage is probably that you end up having to fracture the work into a lot of subunits rather than having a single "elegant" (elegance is often an illusion when it comes to class trees) abstraction for the class and its visual representation/serialization.