Using Generics vs Passing System.Type as argument?

16 Mar 2007 7:08 PM

Kenneth Baltrinic

I have am currently working on a set of c# utility methods that all require
a System.Type object as an input argument, either soley or along with other
arguments. In call cases the calling methods are not working with variables
of System.Type, they just know the type at compile time that they need to
pass in and pass it by invoking typeof on the type. It has occurred to me
that I could implement all these methods as generic and thus the calling
code would not have to be invoking typeof all the time, it could be invoked
within the utility methods just once per method. As in the examples below,
are there any disadvantages to example B or example A? I see an obvious
advantage of being able to do compile time type checking by using a where
statement assert constraints, but currently that is not needed.

Example A:

//Client code:
Utils.MethodA( typeof(ClassA), arg2, arg3);
Utils.MethodA( typeof(ClassB), arg2, arg3);

//Utility class
public static class Utils
{
    public static void MethodA( Type type , object arg2, object arg3)
    {
        ...
    }
}

Example B:

//Client code:
Utils.MethodA<ClassA>( arg2, arg3);
Utils.MethodA<ClassB>( arg2, arg3);

//Utility class
public static class Utils
{
    public static void MethodA<theType>( object arg2, object arg3)
    {
        Type type = typeof(theType);
        ...
    }
}

17 Mar 2007 2:45 PM

VJ

The key for you should be to avoid unnecessary boxing/un-boxing. So what
ever is going to minimize that you can use that method..

VJ

Show quote

"Kenneth Baltrinic" <no.direct.repl***@nowhere.xyz> wrote in message
news:%23NymN6$ZHHA.4832@TK2MSFTNGP02.phx.gbl...
>I have am currently working on a set of c# utility methods that all require
>a System.Type object as an input argument, either soley or along with
>other arguments. In call cases the calling methods are not working with
>variables of System.Type, they just know the type at compile time that they
>need to pass in and pass it by invoking typeof on the type. It has
>occurred to me that I could implement all these methods as generic and thus
>the calling code would not have to be invoking typeof all the time, it
>could be invoked within the utility methods just once per method. As in
>the examples below, are there any disadvantages to example B or example A?
>I see an obvious advantage of being able to do compile time type checking
>by using a where statement assert constraints, but currently that is not
>needed.
>
> Example A:
>
> //Client code:
> Utils.MethodA( typeof(ClassA), arg2, arg3);
> Utils.MethodA( typeof(ClassB), arg2, arg3);
>
> //Utility class
> public static class Utils
> {
>    public static void MethodA( Type type , object arg2, object arg3)
>    {
>        ...
>    }
> }
>
> Example B:
>
> //Client code:
> Utils.MethodA<ClassA>( arg2, arg3);
> Utils.MethodA<ClassB>( arg2, arg3);
>
> //Utility class
> public static class Utils
> {
>    public static void MethodA<theType>( object arg2, object arg3)
>    {
>        Type type = typeof(theType);
>        ...
>    }
> }
>

17 Mar 2007 7:22 PM

Jon Skeet [C# MVP]

VJ <nonewsaddr***@yahoo.com> wrote:

> The key for you should be to avoid unnecessary boxing/un-boxing. So
> what ever is going to minimize that you can use that method..

That depends on the context. If it's not performance critical (as most
methods aren't) I'd go for whichever ended up being more readable.
Making code clean and maintainable is usually more important (at a
micro level) than making it perform absolutely as fast as it can.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

17 Mar 2007 9:07 PM

VJ

Very true Jon. Also the more hirearchy you introduce, the more tough it
becomes to maintain code. Which is also a problem.

VJ

Show quote

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.2066505643f22a7698d9c3@msnews.microsoft.com...
> VJ <nonewsaddr***@yahoo.com> wrote:
>> The key for you should be to avoid unnecessary boxing/un-boxing. So
>> what ever is going to minimize that you can use that method..
>
> That depends on the context. If it's not performance critical (as most
> methods aren't) I'd go for whichever ended up being more readable.
> Making code clean and maintainable is usually more important (at a
> micro level) than making it perform absolutely as fast as it can.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too