Problems with generics

[Guest]

I have come across a problem using generics. I want to create a Factory type
that will build classes for me. Code snippet below...

static public class Product<T> where T : new()
{
static public T New()
{
return new T();
}
}

public class Factory<T> : List<Product<T>>
{
public Factory()
{
}

public List<T> BuildAll()
{
List<T> result = new List<T>();

foreach (T item in this)
{
result.Add(Product<T>.New());
}

return result;
}
}

The problem lies in that the Factory's type <T> requires the new constraint
(like Factory), but that will conflict with the base class descriptor.

I know that I can imbed the List<> (ala Decorator pattern), but I would hope
there is another way to solve it.

 

[Robert Jordan]

I have come across a problem using generics. I want to create a Factory type
that will build classes for me. Code snippet below...

static public class Product<T> where T : new()

What means "static class" for C# 2.0? Probably you cannot instantiate
that class because it's static.

bye
Rob

 

[Guest]

You can't instantiate a static class, and I am not doing that. I am
instantiating the type that is passed to the class (the class is there for
the New method).

The problem is that I am passing the type to the Builder class, and I need
that type to be "newable" where you add a constraint ": new()", but since the
Builder class is also decended from the List class, there is no syntax to
also define the incoming meta type as a newable class.

 

[Mickey Williams [C# MVP]]

This doesn't look correct to me - a Factory is not a kind of List. Your
underlying problem from a design point of view is that you're trying to turn
a List into something that it's not. Is there some reason that Factory can't
just aggregate an instance of List as a field?

 

[Guest]

My question suggested that I could:

....I know that I can imbed the List<> (ala Decorator pattern), but I would
hope there is another way to solve it...

I might have referenced the wrong pattern (I sometimes get them confused),
but you get the point.

What I was concerned about was that the syntax for declaring a constraint on
a generic type could only be used if the class that the generic type was
defined on, did not have an ancestor class.

Along those lines, you are not able to define a constraint on a method:

public void MyMethod<t : new()>() // wrong
public void MyMethod<t>:new()() // wrong

The only way to define the constraint at this point is to define it on the
encapsulting class... which leads me back to my question.

Oh, BTW, Why can't a factory be a kind of a list? You could fill it up with
all of the types you want to create, and mass produce them in one call. Or
you could specify the specific types that you want to create, and raise an
error if you are trying to create a type not in the Factory's list.

But generally, I agree that you would probably create multiple instances of
the factory, one for each type of Product.

Thanks,

 

[Mickey Williams [C# MVP]]

Oh, BTW, Why can't a factory be a kind of a list? You could fill it up
with
all of the types you want to create, and mass produce them in one call.

Then you should pass those parameters to the create method. The factory just
isn't a container for other objects supporting sequential iteration.

 

[Mickey Williams [C# MVP]]

...I know that I can imbed the List<> (ala Decorator pattern), but I would
hope there is another way to solve it...

Sorry, missed that. My bad.

What I was concerned about was that the syntax for declaring a constraint
on
a generic type could only be used if the class that the generic type was
defined on, did not have an ancestor class.

That's correct.

Along those lines, you are not able to define a constraint on a method:

Right - the constraint is a type thing.

 

[Guest]

Thanks for your response,

My example may not be the sterling example of the limitation of generics,
but I believe the point to be valid.

Concerning Factory lists... I think it is just a matter of style.

Consider a class (not Factory), that encompasses a list. The arguments for
making that class a decendant, vs making the list internal, are the same as
could be argued for a Factory class. AFAIK, there is nothing special about a
Factory (as in design pattern), that indicates it should not be a list.

If your point is that by superclassing the List, it basically merges the
functionality of a List, and a Factory, making the class more complex to
understand. I have no disagreement with this.

BTW, the solution of passing things in the constructor works only at
instatiation, but doesn't allow the consumer of the object to modify the list
subsiquently, unless the list is exposed publicly. You can assume that I did
not mean for the list to be static or unreachable (by the consumer), since I
explictly designed it not to be.

P.S. This structure was presented to describe a point, not really to argue
"best practice". It was the first thing that I thought of where the class
name could help document the problem... I wanted a Factory that could (new)
build generic Products, and that Factory had to be descended from *something*
that was itself generic.

 

[Kevin Yu [MSFT]]

Hi Leicester,

If I understand your problem correctly, you're going to use Generics to
write a Factory class to build products. This is beyond the scope of the
newgroup, since this group is mainly discussing about the released .net
frameworks. It would be best handle by the Microsoft Visual Studio 2005
Newsgroups group. For a quicker response you may want to try reposting the
question in the following link:

http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slcid=us

Unfortunately the Visual Studio 2005 Newsgroups are not part of the managed
newsgroup list that we guarantee a 2 business day response, so the response
from the community could take a little bit longer. For a list MSDN Managed
newsgroups please visit the following link;

http://msdn.microsoft.com/newsgroups/managed/

Thanks!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Guest]

Sorry I haven't responded sooner... It seems that email responses are not
sent, unless you click on the link EVERY time.

Thanks for your response.

I didn't know that there was a different group for Whidbey (VS2005), I will
repost my question where you suggest.