Design Pattern Problem

The Top Level Design:

The class Base is a factory class with a twist. It uses the Assembly/Type
classes to extract all types that inherit from it and add them to the list
of types that inherit from it. During run time, using a static method, the
class creates an instance of the derived class using the Activator class and
returns it. This design pattern is very similar to the design pattern
applied by the Assembly class.

The twist is that all inheritors of Base must specify a small amount of
metadata. The metadata will be hard-coded into the derived classes and a
lack of the said metadata must be discovered at compile time.



Design Constraints:

a.. Base is not a component.
b.. Derived classes may be inherited as well.
c.. All derived classes must have unique metadata.

There are several ways to approach this problem:



Design Approach #1:

Base will expose an abstract property that will, when called, return the
value. This, in turn, will require a derived class to override the property
and thus exposing the metadata.

When the factory would be filled, Base would approach all classes that
derive from it and are not abstract and extract the metadata by calling the
property.

Advantages:

There will be compiler intervention in case of failure to override.

Problem #1:

If Base is derived by the non-abstract class A (A is Base) and A is derived
by the non-abstract class B (B is A, B is Base), there is a high probability
for the third constraint to be violated, since there is no compiler error
when not overriding the property in class B (since it has already been
overridden in class A).

Problem #2:

Calling this method from the Base class will require creation of an instance
of the derived class, which is both costly and redundant.



Design Approach #2:

Any implementation of a derivative of Base will require programmers to write
a static property that will return the metadata.

When the factory would be filled, Base would approach each derived class and
extract the metadata by calling the static property.

Advantages:

A static property will not require the construction of an instance of the
derived class.

Problem:

Programmers may and will forget to implement the said property, since there
is no compiler error when it is written and there is no mechanism in the
language that requires a derived class to implement a static
property/method.



Design Approach #3:

Any implementation of a derivative of Base will require programmers to have
a custom attribute set on their derived class and that attribute will be
read at run time.

When the factory would be filled, Base would approach each derived class and
extract the metadata by getting the custom attribute.

Advantages:

This design approach seems the most logical, since attributes are a language
element that was created to describe metadata for classes.

Problem:

Programmers may and will forget to implement said property, since there is
not compiler error when it is written and there is no mechanism in the
framework that requires an attribute to be placed on a class.



Design Approach #4:

When the factory would be filled, Base would explicitly call the static
constructors using the RunTimeHelpers.RunClassConstructor of all derived
classes that, in turn, would register themselves with the base class.

Advantages:

This design pattern works with current compiler / language abilities.

Problem #1:

Programmers may and will forget to implement an explicit type initializer,
since there is no compiler error when it is written and there is no
mechanism in the language that requires a derived class to implement an
explicit type initializer.

Problem #2:

This method places the responsibility of registration in the hands of the
programmer of the derived class.

Problem #3:

This is too much of a Hack-ish approach to be a design approach.



My Conclusion:

With the current tools in the hands of the programmer today, there is no
ability to implement this kind of special factory design pattern.



Does anyone have an idea as to how to approach this situation?

re: Design Pattern Problem

Omer van Kloeten <gv.admin@spaz.ice.org> wrote:

<snip>
[color=blue]
> My Conclusion:
>
> With the current tools in the hands of the programmer today, there is no
> ability to implement this kind of special factory design pattern.
>
> Does anyone have an idea as to how to approach this situation?[/color]

I would suggest the second approach, combined with a tool which can
very easily be run in the "post build" phase which checks that all
classes which should have the appropriate attribute do indeed have it.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

re: Design Pattern Problem

Jon,
I believe you mean the third approach.
I have thought of using an external tool, but just like I don't "trust"
people to write the attribute themselves, I don't "trust" them to use that
external tool in their post-build events, as I will have no control over the
customers once the product will ship.
And besides, having to create an external tool reduces the strength and
wholeness of this design pattern.

Omer

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.19f5ce5277079d46989877@msnews.microsoft.c om...[color=blue]
> Omer van Kloeten <gv.admin@spaz.ice.org> wrote:
>
> <snip>
>[color=green]
> > My Conclusion:
> >
> > With the current tools in the hands of the programmer today, there is no
> > ability to implement this kind of special factory design pattern.
> >
> > Does anyone have an idea as to how to approach this situation?[/color]
>
> I would suggest the second approach, combined with a tool which can
> very easily be run in the "post build" phase which checks that all
> classes which should have the appropriate attribute do indeed have it.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

re: Design Pattern Problem

Omer van Kloeten <gv.admin@spaz.ice.org> wrote:[color=blue]
> I believe you mean the third approach.[/color]

Yes, sorry.
[color=blue]
> I have thought of using an external tool, but just like I don't "trust"
> people to write the attribute themselves, I don't "trust" them to use that
> external tool in their post-build events, as I will have no control over the
> customers once the product will ship.[/color]

Yup, that's fair.
[color=blue]
> And besides, having to create an external tool reduces the strength and
> wholeness of this design pattern.[/color]

Absolutely - it's just an unfortunate fact of life at the moment :(
Certainly it's not ideal - it would be nice if there could be some way
of writing attributes that affect compilation in a custom way, although
I don't know what the API to such a facility would look like.

I don't know exactly what your situation is, but you could also do the
verification when the assembly is loaded, and write out warnings if the
relevant information isn't present. I would at least hope that your
customers would test their plug-in implementations once before trying
to use them in a production environment! It's not a *great* solution,
but it may well be the best you can do at the moment.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too