Design Patterns discussion

[Andy Dent <dent AT oofile.com.au>]

At 13:42 -0700 11/12/2003, Chris Finlayson wrote:

> Make-believe you have a stand alone windows application that you want to
> allow people to extend via an API...
> 1. The parameters required by the customized plugin may be of varying types...
> 3. Each custom plugin may have varying numbers of parameters
> 4. Plugins may evolve over time, causing its parameter requirements to
> change
> 5. Appropriate parameters should be "rememberred" and passed through other
> plugins where appropriate,

I've solved similar problems.

I'm too busy to comment much and I don't know off-hand of any one 
pattern which claims to address these issues.

the typical overall pattern I've seen and used is:
- objects support a serialisation interface (eg: MFC's approach, 
Python pickling) which allows varying types of parameters to be 
converted to a common format (J2EE relies on all types being 
converted to string, for example).

- instantation of objects is via a signature in the serialised data 
being used to create the appropriate Abstract Factory

- objects created by the factory are able to then populate themselves 
from the serialised data.

The J2EE API's used in JBuilder (sorry, I can't remember if these are 
J2EE general API's or JBuilder-specific frameworks) use this approach 
a lot to save objects between pages.

After spending some time programming in Python, I find myself writing 
more c++ code that uses dictionaries to lookup objects or factories, 
providing this kind of uncoupling even within a GUI (eg: checking 
items on menus in OnUpdateCommand handlers based on retrieving the 
matching Setting object and querying its state).
--

Andy Dent BSc  MACS  AACM   http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability