Kevin and Others,

I was looking at our Form Classes trying to figure out how to simplfy the design for maintenance... what I had was something like:

cBizObj
   |
aBaseForm  (Abstract base class for all form classes)
   |   |
   |   aPersonForm (Added code and paramaters about a person)
   |
aMultiRecordForm (Added page frame and grid to page one)
            |
          aPersonMultiForm  

So, now I have a quandry... I have code in aPersonForm that handles some info about the form holding person info. But, now I needed aPersonMultiForm - basically I needed to add a pageframe and grid to the first page, but still have the Person method and parameters.

So, I could either subclass aPersonForm and add the multirecord stuff again, or subclass aMultiRecordForm and add the person stuff again.

Either way I am duplicating code. So, what I came up with, I think, follows the bridge pattern. I removed the person Method/Properties implementation from the form and put it into a custom class called aPersonAddIn. (Still not sure I like addin... don't like hook either, cause it is not really a hook.)

Now, I use the above hierarchy but put the aPersonAddIn on the person forms... This way ALL forms come from aBaseForm, and all multi's come from aMultiRecordForm.

********
Now the question... I wonder if I should even seperate the interface from the form also. Create the UI that I want in a container and save it as a class. Then, only have ONE form class...

The one form class at run time would be passed a Parameter that would define a record in a file. This file would contain:

1. The Form PlugIn class
2. The Business Object class
3. The UI class...

This would allow for my users to subclass my UI class, or BizObj class, and change the table with the class names on it. This seems like a combination of a Form using an Abstract Factory to bridge to implementation classes to present a functional form.

What do you all think. Would performance suffer doing this, other than just building the whole form at design time?

Thanks,
BOb