Why should I specify in Method() ? And how can it be used?

Question

Taking into account the application code below, having 3 overloaded extension methods doing the same as well as having the same input and output:

• What is the benefit (or difference) in using and in parameters of calling and defining a method?
• Why to use them (if the same method 3 without them will be called and do the same)?
• And or how can they (such information) be manually/explicitly used inside a method?

Code:

namespace LINQ_CreatingYourFirstExtensionMethod   
{
  internal class Program  
  {
    private static void Main(string[] args)  
    {
      string[] aBunchOfWords = {"One", "Two", "Hello", "World", "Four", "Five"};  
      var iEnuResult =  from s in aBunchOfWords   
                        where s.Length == 5  
                        select s;
      iEnuResult.Write();  
      iEnuResult.Write<string>();
      iEnuResult.Write<object>();//same effect as above line
      Console.ReadKey();
    }  
  }  
} 

The overloaded extension methods Write():

namespace LINQ_CreatingYourFirstExtensionMethod  
{  
   public static class Utils  
   {
     public static void Write(this IEnumerable<object> source) //****1 
     //public static void Write(this IEnumerable<string> source)//same effects as above line  
     {
       foreach (var item in source)  
       {
         Console.WriteLine(item);
       }
     }

    public static void Write<T>(this IEnumerable<T> source)//****2
    {
      foreach (var item in source)
      {
        Console.WriteLine(item);
      }
    }

    public static void Write(this IEnumerable source)//******3
    {
      foreach (var item in source)
      {
        Console.WriteLine(item);
      }
    }
  }
}

Update:
Can you give me any simplest illustration why would I need

1. call a method using <Type>
2. define a method using <Type>

if I can do all the same without it?

Update2:
I did not write it at once since I thought it was obvious from context of question.

In current code:

• the iEnuResult.Write(); call
  enters the 1st method:
  public static void Write(this IEnumerable source) //**1
• iEnuResult.Write(); (or iEnuResult.Write();) call
  enters the 2nd meth: public static void Write1(this IEnumerable source)//**2

If to comment out

public static void Write1<T>(this IEnumerable<T> source)//*****2

then

iEnuResult.Write1<object>(); 

cannot be made (only iEnuResult.Write(); )

And if to comment both 1st and 2nd methods, the 3d one is called by

iEnuResult.Write();

So, it is possible to call "the same" method both with and without a <Type> in the call (invocation) as well as to have a method definition with and without a <Type>.

There are multiple combinations (I'd say dozens) to do seemingly the same things and I do not see much rationale for this.
So, I'd like to understand what is the purpose of such differences existence, if any

Answer 1

To focus on your two questions:

1. Why call a method using <Type>
2. Why define a method using <Type>

The second question first. Let me rephrase it: when do I define a generic method?

You would define a generic method when the method targets many types, but one type at a time. There are two great advantages:

• It ensures (compile time) type safety: IEnumerable<string> will really only contain strings, not the odd integer or whatever.

• It is a way to use types without boxing and unboxing (i.e. converting value types to and from object, respectively). As said here:

  Boxing and unboxing incurs a significant performance penalty in their own right, but it also increases the pressure on the managed heap, resulting in more garbage collections, which is not great for performance.

If you only have the untyped method (3) each string is boxed when the untyped IEnumerable is enumerated (IEnumerator.Current returns Object) and unboxed again to call the type-specific ToString() method. And the source list can contain anything (which would not matter here, but it often does).

The generic method (2) skips boxing and unboxing and is type safe.

The first method forces any input parameter to be converted (explicitly or implicitly) to IEnumerable<object>. Again, boxing and unboxing will occur. But another nasty thing is that there will not always be an implicit conversion available, which forces the consumer of the method to do the conversion explicitly before calling it. The effect of this can be illustrated by changing select s into select s.Length. If only method 1 is available you'll get

Instance argument: cannot convert from 'System.Collections.Generic.IEnumerable<int>' to 'System.Collections.Generic.IEnumerable<object>'

I think a general rule of the thumb is to avoid method parameters of type object (or IEnumerable<object> etc.), unless there is no other option.

So in short: your second method is the best option here because it executes a task for any type, but avoids boxing and unboxing.

Now your first question. When do you need to specify the generic type parameter in method calls? I can think of three reasons (there may be more):

1. When there is no method parameter of type T by which the compiler can infer the generic type. Factory methods typically are in this category. A method like T Create<T>() must be called by e.g. Create<Customer>(). Constructors are another example: generic constructors can't even be called without a specified type.
2. When you want to enforce that a specific method overload be used. This may happen when there are inherited types with a mixture of generic and non generic methods overloads. (Not a mark of good design by the way).
3. Indirectly when the type is not know at compile time but only at execution time. See Generics in C#, using type of a variable as parameter.