Question

What’s the difference between these two, and what is the “correct” one?

public interface IMessage
{
    /// <summary>
    /// Array used to hold all bytes that will be written.
    /// </summary>
    IList Buffer { get; set; }
}

and

public interface IMessage<T> where T : IList
{
    /// <summary>
    /// Array used to hold all bytes that will be written.
    /// </summary>
    T Buffer { get; set; }
}

---

Edit 1: Fixed – can’t have fields on interfaces. (Thanks BoltClock)
Edit 2: Fixed – can’t have encapsulation on interfaces. (Thanks KeithS)

Answer 1

In the first case, your buffer is defined to be of type IList. It can, at runtime, be assigned any implementation of IList, and any creator of implementations of this interface does not have to know exactly what implementation will be used. However, code cannot know, at runtime, which exact concrete implementation is used, and so at design-time when referring to this property as a member of the interface, you will never have access to any methods not exposed explicitly by the IList interface.

In the second case, you are defining a generic. Wherever this generic definition remains “open” (T is not defined), you are still restricted to using the methods of IList. However, something must close this generic, either an implementation of the interface or the definition of a particular instance of an implementation that keeps the generic open. Once the generic is closed, the exact, concrete type of buffer is known, and methods can be called on it that are not necessarily defined by IList. But, once the generic is closed, an instance or class that defines a particular generic type can’t be given a different implementation of IList to use as the buffer.

So, some examples (assuming that the protected field, which you can’t specify on an interface, is actually a mutable public property):

//this class implements the non-generic interface, so buffer is an IList.
class MyMessage1: IMessage
{
   public IList buffer {get;set;}

   public MyMessage1()
   {
      buffer = new List<string>();

      //even though you "know" what you just assigned, 
      //you cannot refer to buffer as a List<string>, even here.
      buffer.Sort(); //error
   }
}

...

//The exact type of buffer cannot be known statically, 
//so only non-generic IList methods are allowed
var myMessage = new MyMessage1();
myMessage.buffer.Add("my message"); //valid; string literals are Objects
var firstLen = myMessage.buffer[0].Length; //error: indexer returns Objects.
myMessage.Sort(); //error: IList does not have a Sort() method.
firstLen = GetFirstLength(myMessage); //error: not an IMessage<List<string>>
//but, an IList is an IList no matter what, so this works.
myMessage.buffer = new List<int>(); 

...

//this class keeps the generic open so T can be any IList, determined at instantiation.
class MyMessage2<T>:IMessage<T> where T:IList
{
    public T buffer {get;set;}

    //buffer's exact type is still not known here,
    //so inside this class you are still restricted to IList members only
    public int BufferCount{get{return buffer.Count;}}

    public void SortBuffer()
    {
       buffer.Sort(); //error; no such method
    }    
}

...

//but, once you define an instance, you know exactly what buffer is
var myMessage = new MyMessage2<List<string>>();
myMessage.buffer.Add("my message");
var firstLen = myMessage.buffer[0].Length; //now we know the indexer produces strings.
myMessage.buffer.Sort(); //buffer is known to be a List<T> which has Sort()
firstLen = GetFirstLength(myMessage);

...

//and when you pass it as a parameter, you can close the generic of the interface
public string GetFirstLength(IMessage<List<string>> message) 
{
   //...so you still know what you're dealing with
   return message.buffer[0].Length;
}

...

//however, buffer is now "strongly typed" and the implementation can't change
myMessage.buffer = new List<int>(); //error; buffer is of type List<string>

...

//this class closes the generic within the declaration.
class MyMessage3:IMessage<IList<string>>
{
   //now we're closing the generic in the implementation itself,
   //so internally we know exactly what we're dealing with
   public List<string> buffer {get;set;}

   //...so this call is valid
   public void SortBuffer() { buffer.Sort(); }
}

//...and consuming code doesn't have to (get to?) specify the implementation of T
var myMessage = new MyMessage3();
//... but still knows exactly what that implementation is
myMessage.buffer.Add("my message");
var firstLen = myMessage.buffer[0].Length;
myMessage.buffer.Sort();

//and btw, MyMessage3 is still an IMessage<List<string>>
firstLen = GetFirstLength(myMessage);

//... and buffer's still a strongly-typed List<string>
myMessage.buffer = new List<int>(); //error