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?
