+972 52-548-6969
Ayende's Design Guidelines: Rule #1
When creating a generic method, strongly prefer to supply an overload that is not generic, can accept the types manually, and is externally visible.
Reasoning: The generic version often looks significantly better than the non generic version, but it comes with a cost. It assumes that you know, up front, what the types are. When you are writing any type of generic code, this is almost always not the case and your generic method is useless in that scenario.
Example: myContainer.RegisterComponent<IService, ServiceImpl>(); is a good syntax to have, but the problem with that is that it cannot be used with this code:
foreach(Type type in GetComponentTypes())
{
myContainer.RegisterComponent<type.GetInterfaces()[0], type>();
}
Since we cannot use the generic overload, we need to resort to trickery such as MakeGenericMethod and friends. This is costly at runtime, obscure and generally make life harder all around.
Comments
I completely agree - this is something I've run into a few times and providing an API without non-generic alternatives just generates friction for the consumer.
I guess the context here is when you are publishing an API?
In a project where I control and consume the code base, it's YAGNI.
Yes, this is for published API.
If you control the code, it doesn't really matter, since you can always change that.
Nevertheless, you need to carefully consider what you believe a published API is
Exactly. http://api.castleproject.org/html/M_Castle_MicroKernel_DefaultKernel_ResolveServices__1.htm immediatelly comes to mind.
Exactly. http://api.castleproject.org/html/M_Castle_MicroKernel_DefaultKernel_ResolveServices__1.htm immediatelly comes to mind.
That's why I wished there was a way to promote a type object into a generic scope:
foreach(Type type in GetComponentTypes())
{
}
Comment preview