Hello,
I've worked on an API for quite some time and have (on several occasions)
tried to introduce generics at the core abstract level of business objects
(especially a hierarchical node). The current non-generic implementation is
functional, but not as clean as I would like. Although not sure, I believe
my problems stem from lacking support of co- and contravariance in C# (which
I'm desperately hoping will make it in the next version).
The reason of this post is to ask for your feedback (i.e. if my assumptions
are right or wrong) and hopefully get some directions. Right now it feels
like I'm working against the compiler, but the API design looks clean to me.
However, if I'm trying to do the impossible, it would obviously be an
important lesson and keep working with the non-generic version of the API
(and refactor if or when C# can support the requirements).
// Start of examples
I would like to "say" the following in C#:
1. Define a generic hierarchical type (HierarchyNode<T>) that allows a
descending class (Page) to implement coveriant return types. As seen below,
the class Page defines itself "as a" HierarchyNode<Page>, but can't
implement the abstract members - even though the return type in fact "is a"
HierarchyNode<Page>. It's the same situation with
NodeCollection<HierarchyNode<T>>that wants to be implemented using a
covariant NodeCollection<Pagereturn type.
abstract class Node {}
abstract class HierarchyNode<T: Node where T : Node
{
// if this property is implemented as T instead of HierarchyNode<T>, the
// structure is not hierarchical (i.e. HierarchyNode<T>.Parent.Parent is
not possible
// because T is constrained to CmsNode.
// abstract T Parent { get; }
// abstract NodeCollection<TChildren { get; }
abstract HierarchyNode<TParent { get; }
abstract NodeCollection<HierarchyNode<T>Children { get; }
}
class NodeCollection<Twhere T : Node {}
// a concrete hierarchical business object
class Page : HierarchyNode<Page>
{
override Page Parent
{
get { return new Page(); }
}
override NodeCollection<PageChildren
{
get { return new NodeCollection<Page>(); }
}
}
The following compiler error is raised when compiling the snippet:
Error 1 'Page' does not implement inherited abstract member
'HierarchyNode<Page>.ChildNodes.get' 16 15 Generics.
Please note that I have tried the following signature also:
abstract class HierarchyNode<T: Node where T : HierarchyNode<T>
{
abstract T Parent { get; }
abstract NodeCollection<TChildren { get; }
}
but it makes it impossible to test if a Node "is a" HierarchicalNode<T>
because T is never convertiable to Node.
void ProcessNode<T>(T node) where T : CmsNode
{
// does not compile (which construct should be used here?)
if (node is HierarchyNode<?>)
{
// process node
}
}
2. Cast a type to a generic type definition. Because the HierarchyNode<Tis
generic, it's impossible to actually test whether a Node in fact "is a"
HierarchyNode<Tunless you know the exact type of T and that might not be
available (i.e. requires a generic method). The following snippet is an
example of a common pattern implemented in a method that takes a Node as
argument. I realize there's a potential way around this situation -
providing two different methods; one taking the Node and another with a
generic type (ProcessNode<T>(HierarchyNode<Tnode) where T : Node (but
that's convoluted - and left out of the example).
void ProcessNode(Node node)
{
// process node
if (node is HierarchyNode<Node>)
{
// should process node as a hierarchical structure
// but never happens.
foreach (HierarchyNode<Nodechild in ((HierarchyNode<Node>)
node.ChildNodes)
{
// should process child as a hierarchical structure
// but throws a compiler error.
}
}
}
// just call the worker method with an instance of a Node (should not care
whether it's hierarchical or not)
ProcessNode(new Page());
The following compiler error is raised when compiling the snippet:
Error 1 Cannot convert type 'HierarchyNode<Page>' to 'HierarchyNode<Node>'
75 4 Generics
// End of examples
Over the couse of the past few weeks I've tried many different approaches at
implementing the generic and concrete classes above, so that they allow
casting to and from generic versions etc. but constantly find myself
cornered by a compiler errors (or class design I'd rather not live with).
Am I simply working in a corner of C# where variance is not yet as evolved?
I've thought about seperating the hierarchy completely from the structure,
but it didn't really fit well with the design of the business objects and as
far as I know I would still face some of the problems - namely conversion
problems between generic types.
Right now I've implemented the concrete API using abstract non-generic
classes (also collections) and hiding inherited members in concrete classes
(such as Page and PageCollection). I'd much rather skip the method hiding
and provide a single generic collection of T, but the trouble I'm facing
with generics (and I've really tried my best) simply made me give up.
Perhaps generics was not intended for this scenario - which is sad, because
it would enable a wide range of oppertunities.
Thanks for reading!
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)
