How to approach constructing an instance of an unknown class?

[K Viltersten]

I have a class that reads an XML and
according to its contents, it creates a
List<Letter>, where Letter is an abstract
class that is implemented in Alpha and
Beta classes.

I use a foreach statement consisting of a
switch upon which i create an instance of
e.g. Alpha an add it to the list.

The only limitation is that if i ever
invent a new implementation, say Gamma,
i'll be forced to rewrite, recompile and
reinstall the executable.

I'm looking for a suggestion on how to
approach the problem so that a new type
will be handled appropriately (provided
that i distribute SOME definition of the
appropriate actions to be taken).

--
Regards
Konrad Viltersten
----------------------------------------
May all spammers die an agonizing death;
have no burial places; their souls be
chased by demons in Gehenna from one room
to another for all eternity and beyond.

[Peter Morris]

You could have an app.config file

<classes>
<add key="Alpha" value="MyNameSp ace.MyClass, MyAssemblyName"/>
<add key="Beta" value="MyNameSp ace.MyClass2, MyAssemblyName"/>
<add key="Gamma" value="MyNameSp ace.MyClass3, NameOfMyNewAsse mbly"/>
</classes>

You can read these in and add them to a Dictionary<stri ng, Type>, then you
can easily create instances based on the name. This way you can drop a new
DLL into the folder + update the app.config and you are all done.

Pete

[Pavel Minaev]

"K Viltersten" <tm**@vilterste n.comwrote in message
news:6i******** ****@mid.indivi dual.net...

>I have a class that reads an XML and
according to its contents, it creates a
List<Letter>, where Letter is an abstract
class that is implemented in Alpha and
Beta classes.

I use a foreach statement consisting of a
switch upon which i create an instance of
e.g. Alpha an add it to the list.

The only limitation is that if i ever
invent a new implementation, say Gamma,
i'll be forced to rewrite, recompile and
reinstall the executable.

I'm looking for a suggestion on how to
approach the problem so that a new type
will be handled appropriately (provided
that i distribute SOME definition of the
appropriate actions to be taken).

Sounds like a classic case for the abstract factory pattern. For instance,
let's say that you decide on the class to use depending on the name of the
XML element that you encounter. Then, you abstract away the logic of
creating a letter of specific type from an XML node as a delegate (or an
interface), and introduce a registry (could be one, could be several) for
known implementations of that interface/delegate.

delegate Letter LetterFactory(X Element element);
Dictionary<XNam e, LetterFactoryFa ctories;

List<LetterPars eLetters(XDocum ent document)
{
XElement current;
...
var factory = Factories[current.Name];
var letter = factory(current );
...
}

...

Alpha AlphaLetterFact ory(XElement element)
{
Alpha result = ...; // create and fill from XML
return result;
}

Factories.Add(" alpha", AlphaLetterFact ory);

...

Beta BetaLetterFacto ry(XElement element)
{
Beta result = ...; // create and fill from XML
return result;
}

Factories.Add(" beta", BetaLetterFacto ry);

...

XDocument doc = ...;
ParseLetters(do c);

[K Viltersten]

>>I have a class that reads an XML and

>according to its contents, it creates a
List<Letter> , where Letter is an abstract
class that is implemented in Alpha and
Beta classes.

I use a foreach statement consisting of a
switch upon which i create an instance of
e.g. Alpha an add it to the list.

The only limitation is that if i ever
invent a new implementation, say Gamma,
i'll be forced to rewrite, recompile and
reinstall the executable.

I'm looking for a suggestion on how to
approach the problem so that a new type
will be handled appropriately (provided
that i distribute SOME definition of the
appropriate actions to be taken).

Sounds like a classic case for the abstract factory pattern. For instance,
let's say that you decide on the class to use depending on the name of the
XML element that you encounter. Then, you abstract away the logic of
creating a letter of specific type from an XML node as a delegate (or an
interface), and introduce a registry (could be one, could be several) for
known implementations of that interface/delegate.

delegate Letter LetterFactory(X Element element);
Dictionary<XNam e, LetterFactoryFa ctories;

List<LetterPars eLetters(XDocum ent document)
{
XElement current;
...
var factory = Factories[current.Name];
var letter = factory(current );
...
}

...

Alpha AlphaLetterFact ory(XElement element)
{
Alpha result = ...; // create and fill from XML
return result;
}

Factories.Add(" alpha", AlphaLetterFact ory);

...

Beta BetaLetterFacto ry(XElement element)
{
Beta result = ...; // create and fill from XML
return result;
}

Factories.Add(" beta", BetaLetterFacto ry);

...

XDocument doc = ...;
ParseLetters(do c);

Oh, i think i see the approach. Only one
question, regarding the var keyword. Is
it allowed even in DotNet 2.0? I fear
that it's a newer thing, like 3.0 or 3.5
and such great utilities i can't use. :(

--
Regards
Konrad Viltersten
----------------------------------------
May all spammers die an agonizing death;
have no burial places; their souls be
chased by demons in Gehenna from one room
to another for all eternity and beyond.

[Marc Gravell]

Only one

question, regarding the var keyword. Is
it allowed even in DotNet 2.0?

Yes, but it needs C# 3.0 (the language and the .NET library version are
separate). In this case it probably just saves a little typing. The only
*essential* use of var is with anonymous types, which are a C# 3.0 feature.

Marc

[Jon Skeet [C# MVP]]

K Viltersten <tm**@vilterste n.comwrote:

<snip>

Oh, i think i see the approach. Only one
question, regarding the var keyword. Is
it allowed even in DotNet 2.0? I fear
that it's a newer thing, like 3.0 or 3.5
and such great utilities i can't use. :(

"var" is part of C# 3.0, but you can still use it when targeting .NET
2.0 from VS2008. However, it's unnecessary anyway - unless you're using
anonymous types (another part of C# 3.0) you can always just use the
real name instead of "var". It's just the compiler inferring the type
for you.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Peter Morris]

This approach wont solve the problem you described, in particular

========
The only limitation is that if i ever
invent a new implementation, say Gamma,
i'll be forced to rewrite, recompile and
reinstall the executable.
========