How to avoid a big switch statement to create a type/subtype

[Angel Of Death]

[Reposted as I made a mistake]

I have a method. It takes some XML as a parameter. Depending on the
content of the XML it should create a specific object and call a KNOWN
method.

So: public void PersistXml(string XmlData){}

Inside this method I determine what object I should call the Persist
method on using a switch statement (not very OO).

switch (otype)
{
case "type1"
switch (osubtype)
{
case "subtype1"
//create type
foo x = new foo(XmlData);
x.Persist();
break;
case "subtype2"
foo2 x = new foo2(XmlData);
x.Persist()
break;
}
case "..."
foo3 x = new foo3()
x.Persist(XmlData);
break;
}

I can see from here that I really just have one method (Persist) and
that all I'm really doing is creating the right object at run-time and
then calling a known method on it.

I was thinking that perhaps I could create the objects at runtime and
use an interface for the known method to then call it:

object o = Activator.CreateInstance(type);
IPersist persist = o as IPersist; //IPersist is same sig as PersistXml
if (persist != null)
{
persist.Persist(XmlData);
}

But being a novice I'm not really sure if there is a better way (or if
there are even issues with implementing it this way). It seems to me
that I shouldn't be worried with what object should be created, and that
I should be able to have the correct Persist method called for me using
Polymorphic code, yet if I have to create the subtype then I surely need
to know its type? I could use virtual methods and overrides but this
doesn't help me with the object creation and if I need to know the
subtype to create it, then I dont need polymorphic behaviour since I can
just call the method on it directly since I will have a reference to the
specific object.

What's the cleanest way to implement this. Either way the switch
statement has to go!

 

[PS]

[Reposted as I made a mistake]

I have a method. It takes some XML as a parameter. Depending on the
content of the XML it should create a specific object and call a KNOWN
method.

So: public void PersistXml(string XmlData){}

Inside this method I determine what object I should call the Persist
method on using a switch statement (not very OO).

switch (otype)
{
case "type1"
switch (osubtype)
{
case "subtype1"
//create type
foo x = new foo(XmlData);
x.Persist();
break;
case "subtype2"
foo2 x = new foo2(XmlData);
x.Persist()
break;
}
case "..."
foo3 x = new foo3()
x.Persist(XmlData);
break;
}

I can see from here that I really just have one method (Persist) and
that all I'm really doing is creating the right object at run-time and
then calling a known method on it.

I was thinking that perhaps I could create the objects at runtime and
use an interface for the known method to then call it:

object o = Activator.CreateInstance(type);
IPersist persist = o as IPersist; //IPersist is same sig as PersistXml
if (persist != null)
{
persist.Persist(XmlData);
}

But being a novice I'm not really sure if there is a better way (or if
there are even issues with implementing it this way). It seems to me
that I shouldn't be worried with what object should be created, and that
I should be able to have the correct Persist method called for me using
Polymorphic code, yet if I have to create the subtype then I surely need
to know its type? I could use virtual methods and overrides but this
doesn't help me with the object creation and if I need to know the
subtype to create it, then I dont need polymorphic behaviour since I can
just call the method on it directly since I will have a reference to the
specific object.

What's the cleanest way to implement this. Either way the switch
statement has to go!

Somewhere you need to maintain a link between a key and either a class name
or a method that creates the class. Relection is commonly used in the
Abstract Factory pattern. An alternative is to link a key to a method which
would be done by creating a delegate that returns IPersist. Then you can
store the key and the delegate in a Dictionary and Invoke the method by key.

PS