Now that I’ve had a chance to work with both Java and .NET generics, I must admit I like the runtime presence of generics in .NET. Java generics exist only to enhance compiler time checks and type erasure removes these from the binary class file — in all but metadata form for IDE code completion. In .NET, on the other hand, the generated MSIL retains the generic types, which become runtime metadata.
This, unfortunately, opens the door to coding abuse. When passing Type-typed arguments to methods parameters, one can now shove the parameter in as a generic parameter. Like this: myEmployeeCollection.First<Employee>(). This is borderline terrible; if First hadn’t been an extension method, the generic type would have been known to the method. But investigate this next example:
myContainer.RegisterType<IMyService, CustomerService>();
IMyService myServiceInstance = myContainer.Resolve<IMyService>();
This is perversion. For just the small gain of not having to use the typeof operator, we lose readability. One can’t even use this consistently as a new form of parameter passing, because there will always be non-Type parameters around. Either way, this opens the door to inconsistency.
In fact, generics are supposed to specialize, or focus the scope of code. Historically, generics described template — generic — bundles of behavior. This use scope is engrained in the coding standards of a few generations. Code reuse was the primary goal, but the presence of generic behavior has always been a crucial aspect of generic. There was also a fortunate side effect; the reader had an indication of the specific use case of the generic type. If a code preprocessor (C++), the compiler (Java) or even the runtime (C#) benefited from this arrangement, so much the better. But the primary purpose was pretty specific.
We see nowadays an abuse of the generics feature at method level, where Type parameters that from a semantic stand point clearly deserve the title of method parameters, are passed instead as generic type parameters, for the sole reason of their ability to be used as such. This programming pattern hinders consistency, and makes other use cases difficult. If the generic type parameter is unknown at compile time, reflective methods must be employed to produce results with generic and non-generic methods.
The problem is exacerbated by the use of this anti-pattern in Microsoft code. The above snippet is part of the documentation of the Unity dependency injection framework. In fact we sometimes have to moderate our sprints towards novel and embrace the good that we’ve achieved so far.
