Design pattern and configuration settings

I'm developing an application that transforms xml documents using xslt.

The application has a settings dialog for setting values like

* input
* output (directory)
* stylesheet
* and so on...

The user can also choose to transform to pdf, xhtml, etc, and the settings above differ slightly for each format. Now, I was wondering if anyone has any good ideas on how to handle these settings from a design perspective. I am sort of using an MVP (model-view-presenter) pattern for the application as a whole, and I have created a model class for these settings. Because they store the settings in different places and different ways (in build files for transformations) I have subclassed the model class for each format type (PdfModel, etc). But besides having different ways of storing (which motivates subclassing), they also have different properties to some extent as I mentioned. For instance, the xhtml format needs a css property, and the pdf format needs a fo formatter property, and so on.

I have tried to work this out, and I get it to work fine in several different ways, so that's no problem. I'm just curious to know if anybody with good design pattern experience could shed some light on if this is really a good way to do it. It feels to me like a lot of it gets too complicated for a relatively simple thing. And yet it's hard to get a really elegant solution to it. For instance, if I do it as described above, I can use an interface to code to and that way I can have several different views (with presenters) showing the settings, not having to know what model will be presented (e.g. I have a property grid showing the current settings in a view besides the view where the user sets the settings). BUT the problem with this is that I then have to have an interface containing several properties that are not used for each format model. So for the pdf model, I will have to set the Css property to not applicable or something like that. And this could conceivably get worse, if I were to add more specific properties.

I also tried another variant where I only have the common properties in the interface, and then I code to the interface, but downcast the object in the receiving class to get to the subclass properties. I'm not sure if this is good or not, but it works. Maybe that's fine, but I would really like some input to find out if I'm overcomplicating things or I could do it more elegantly...

I hope it's possible to understand the problem from开发者_如何学Go my description. Any suggestions will be greatly appreciated!

Regards,

Anders

---

Maybe you should think in your design more about what is the common behaviour, not properties or methods by name. It would be nice, if you could have a method providing all properties and associated constraints and validations. This method would be shared through the interface. Another possibility could be for example some reflection functionality which could determine properties automatically.