This morning I read a post about the .NET design guidelines and I am upset about the last line of this guideline. We are now going to have people choosing generics over polymorphism to solve a problem.  If I expect an ISession for the paramter of my method, class etc, why would that become a generic?  Maybe I am completely missing something here.  So I turn my chair around and start ranting to Peter and Brian to unleash my angry coder feelings.  It took a while for me to understand that generics are not templates and now I understand the need for typesafe containers so I can get T back from a method of class Foo<T>.  I just don't understand the need to put the responsibility of limiting T on the class.  If I want a generic sort algorithm, that should be outside of the container ala STL. Of course I also keep thinking when we get iterators in C# that we are getting C++ iterators and again, sadly, I am disappointed, so I understand the need, I just don't agree with the solution.

I understand that generics are not templates, but why not?  I think Stan Lippman's post hits in on the head.

So to get back to the real point of this post, using descriptive names for template paramters seems to support something that should be purged from the system, which are large classes, methods etc.  I belive in naming variables for what they are, but if you have a template and you can't see the name of the template parameter anymore, you probably have a method that is too long, or need unusually large fonts for accesiblity reasons. Objects are cheap and the methods in them should be short.  I am in favor of a bunch of small classes with specific responsiblities and small methods.

Don't get me wrong, I like C# and the direction it is heading, yet as a wise man Brian Button says "All languages tend toward C++".  And I tend to agree with him. I think the guys on the C++ 2.0 team are going to get it right and make some big waves in the world.  If you are interested in these types of things read here.

All that being said, this is my personal opinion and in no way implies the opinion of Microsoft.

Comments (4)

  1. I’m looking at that, and I think it is just a really bad example… It appears to add no value beyond clarifying just the naming convention. After all, why would you have multiple versions of ISessionChannel created for a specific type that supports ISession? I just don’t get it, and I’m sure that is the root of your anger. So I side with you, and agree that certain things just aren’t right in the world.

    To note, if you have a struct that you are stringing the interface from, then there is a storage bonus by storing that structure in unboxed form on whatever class supports ISessionChannel. I don’t know if it is worth the extra constraints and adding generics… Damn you! Now I have to go find this stupid API and figure out what in the hell it does just to clarify in my own mind why in the hell they used it as an example 😉

  2. Red flags were definitely raised when I first saw the type constraint "feature" of generics. I guess the use case is where you need to constrain a type and do operations on that type polymorphically within your class, but want to avoid casting of the specific type when implementing that class. However, I’m not convinced that this is a valid approach.

  3. Tony Chow says:

    Polymorphism is the ability of an object to assume a more abstract form. Generics do not provide quite this capability. For instance:

    LionPen can be cast to AnimalPen…

    …but Pen<Lion> cannot be cast to Pen<Animal>.

    In the latter case, if you wanted a *type-safe* way of referring to Pen<Lion>, Pen<Elephant>, or Pen<Penguin> using the same variable, you’d have to declare an abstract Pen type, and have Pen<Animal> derive from it:

    public abstract class Pen


    public abstract Animal Animal {get;}


    public class Pen<Animal>: Pen

    where Animal: Animal



    In other words, you’d have to fall back to polymorphism, even if you limit the type parameter.

    Generics solve a different set of problems than polymorphism does. It addresses the performance defects of using value types with collections, and it dramatically reduces the amount of code required to create classes that are on the *same level of abstraction*.

    Polymorphism targets a different problem–that of facilitating the interaction of classes on different levels of abstraction.

    They complement each other.

  4. Kirk Marple says:

    The parameter typing can be a big benefit because it gives you a lowest-common denominator when accessing objects of that type. You can then call methods/access properties on that generic parameter w/o casting.

    I have a common base class used by several generic classes, and i’m able to assume that the parameters of type ‘T’ support this common denominator of methods/properties.

Skip to main content