Design pattern to avoid switch-case on types during transformation/translation

Question

I'm trying to implement a preferences system where the programmer can specify preference names, types (boolean, integer, string, etc.), and optionally their default values. What I've been dwelling on for a while and can't come up with is a generic solution for storing to / loading from disk. I want the design to be generic enough to handle multiple formats (i.e. text files, the Windows Registry, or Apple's Property Lists). The simple solution would be to make transformers for each storage format and somewhere along the line when the storage format is already chosen, iterate through preferences and switch-case on their types.

I've been told doing a switch-case on a type isn't a good solution and I understand why: if I add a type, I need to go and modify all those switch-case blocks. So what should I do instead? The usual answer is to have the objects whose types were being checked implement a common interface and know how to perform the actions themselves.

But that seems ridiculous to me, to have an preference value know how to store itself in a text file, in the Windows registery, and in an Apple property List. That just moves the problem. Instead of adding a new type requiring me to go and modify the transformers, if I add a new transformer, I need to go and modify all the types!

I imagine this is a common design problem but I can't find any good solutions out there.

Answer 1

Classic use of the visitor pattern. Though you sometimes see the pattern expressed more generically, here is some psuedo-code of a persistance layer via the Visitor pattern.

Note that the preferences dont need to know how to save themselves, they just need to pass themselves to the storage mechanism:

abstract BasePreference
{
    abstract Persist(PreferenceStorage ps);
}


NumericPreference : BasePreference
{
   string Name;
   int Value;
   int Default

   Persist(PreferenceStorage ps)
   {
      ps.Save(this);
   }

}


StringPreference : BasePreference
{
   string Name;
   string Value;
   string Default

   Persist(PreferenceStorage ps)
   {
      ps.Save(this);
   }   
}


DateRangePreference : BasePreference
{
   string Name;
   DateTime StartOfRange;
   DateTime EndOfRange;
   DateTime DefaultStartOfRange;
   DateTime DefaultEndOfRange;

   Persist(PreferenceStorage ps)
   {
      ps.Save(this);
   }   
}

Next, the PreferenceStorage utilizes method overloading to allow seperate code to be run for each pref subtype. No switch blocks on types:

abstract PreferenceStorage 
{
   abstract void Save(NumericPreference pref);
   abstract void Save(StringPreference pref);
   abstract void Save(DateRangePreference pref);   
}

And finally, the subclasses of PreferenceStorage take care of the mechanics or saving the data:

XmlPreferenceStorage : PreferenceStorage
{
   void Save(NumericPreference pref)
   {
      // save number to xml 
   }

   void Save(StringPreference pref)
   {
      // save string to xml 
   }   

   void Save(DateRangePreference pref)
   {
      // save date range to xml 
   }      
}



RegistryPreferenceStorage : PreferenceStorage
{
   void Save(NumericPreference pref)
   {
      // save number to registry 
   }

   void Save(StringPreference pref)
   {
      // save string to registry 
   }   

   void Save(DateRangePreference pref)
   {
      // save date range to registry 
   }      
}

(Uggg, why is this formtating so terribly? Sorry for the bad indenting, normally great code formatting on SO)