Standard interfaces. RRS feed

  • General discussion

  • What is the actual use of standard interfaces like Ienumarable,Icomparer etc and Why are they Used with Lists?Are there any places more we use them? I want to Know about the whole story of the Standard Interfaces.Please Help.Thanks :)
    Monday, September 26, 2016 11:09 AM

All replies

  • Hi,

    the core idea with interfaces is to keep the implementation used separated from the classes that are using the data.

    So there are multiple classes available that a developer could use to manage the data. So a developer could use System.Collections.ObjectModel.Collection<T> or System.Collections.Generic.List<T> just to take 2 classes.

    Both implement different interfaces e.g. IList<T>, IEnumerable<T> and ICollection<T>.

    Now you could write code, that works with Collection<T>. That would mean, that you cannot use that code with List<T>. So your code is not as reusable as it could be. Your could simply depends fully on that class Collection<T>.

    If your code just needs the possibilities of IEnumerable<T>, then you could use an IEnumerable<T> in your code. The result is, that you could use this code with any instance of a class that implements IEnumerable<T>. So the result is, that the code has less dependencies and is much easier to reuse.

    I hope this helped a little bit to understand why these standard interfaces are useful.

    With kind regards,


    Monday, September 26, 2016 12:27 PM
  • I think first you need to understand what interfaces actually are, as it doesn't sound like you're quite getting it.

    They provide a way to separate out behaviour from specific implementations. You define an interface to declare some properties/methods/events that define an "interface" to some other class, although the interface declaration code itself contains no code.

    Then, you can define classes that implements that interface. The class provides the actual code implementation for the properties/methods/events declares on the interface.

    The point of this is that you can create several disparate classes that all implement the same interfaces. And this allows you to interact with those classes 'through' that interface without needing to know about the specific implementation.

    Check out some links (or just search for "C# interfaces"):

    Now understand that what you are calling "standard" interfaces are not special in any way - they are just interfaces, like any "normal" interface that you might declare yourself. The only difference is that - by following the practice described above, i.e. separating out behaviour from implementation - the .Net framework happens to define a whole bunch of interfaces that are used by other classes in the .Net framework. Which is obviously a good thing!

    To take one example you mention, IEnumerable. This interface provides a way to get an 'enumerator' allowing calling code to step through a collection. The are lots and lots of possible collections, many provided by the .Net framework such as Queue, List, Array etc.

    They all 'implement' IEnumerable.

    All this means is if you have some calling code that just needs to step through the collection (i.e. to enumerate it), that it only needs to know about IEnumerable. It does not need to know any specifics of the class itself. So you can write code such as:

    public void OutputCollection(IEnumerable collection)
      foreach (var item in collection)

    Now you can call this from different places and pass in different classes. As long as that class implements IEnumerable, it will work:

    string[] myarray = {"hello", "world"};
    List<int> mylist = new List<int>() {1, 2};

    To repeat, "standard" interfaces are just interfaces. Its just that they happen to have been created for you by the .Net framework and are implemented by classes in the .Net framework (so its good to know about them, so you don't end up reinventing the wheel and so you can make best use of the existing .Net classes, but you treat them like any other interface).

    • Edited by RJP1973 Monday, September 26, 2016 1:50 PM
    Monday, September 26, 2016 1:48 PM
  • Hello Konard,

    •  So Standard Interfaces are from the system.collections.objectmodel.collections<T> or system.Collections.Generic.List<T>
    • List<T> and Collection<T> can we use both at a time? or the Program Crashes due to the load of using them both?
    • Usage of IList<T> ,IEnumarable<T> etc  depends on the type of data and the output of data what we actually deal with.So if we are Dealing with Enumarated Data type and we have a large set of data in IEnumrabale<T> and we are Excepting the Enumarable return type.Then it's best to use IEnumarable<T> rather Using List<T> or Collection<T>.am I right?
    • Now As we Use Standard Interfaces in Classes,Is it Possible to Declare Normal Interface in a class and Implement it? I mean Can we Use a code with Instance of a class that implements a normal Interface inside the Class? for example:-(Class Program { interface Itransform<>....)

    Please Tell me Whether my Assumptions are True or false.Thank you Again :)

    Monday, September 26, 2016 1:49 PM
  • Hi Lalith,

    Please see my response above. You really need to get a better idea of the actual purposes of interfaces first.

    As I said above, what are you are calling "standard" interfaces are just interfaces. The ones you have mentioned (IEnumerable, IList, etc) provide behaviours for talking with different kinds of collection classes, but there are lots of different interfaces for all sorts of things.

    The .Net framework has dozens if not hundreds of interfaces pre-defined in the .Net framework. They are not special in any way - they are just interfaces, but they are utilised by other classes in the .Net framework (e.g. List<T> implements the IList<T> interface).

    With this in mind:

    • Lots of the namespaces in the .Net framework define interfaces. They are not limited to the collections classes you have mentioned.
    • Not sure what you are asking here. You can use any kind of collection classes you like in a program: arrays, lists, queues. It depends on what you are actually trying to do and you will want to use different collection classes for different purposes as appropriate (what do you mean by "use both at a time"??)
    • Again, not entirely sure what you are asking. The IList<T> and IEnumerable<T> interfaces don't depend on the type of data - they are generic interfaces. The data they deal with depends on how you define T when you declare the class you are using. e.g. List<string> mylist. You use whatever interface contains the methods appropriate to what you are trying to do; if all you need to do is step through (enumerate) a collection of items then you use the IEnumerable interface.
    • You can define your own interfaces and use them in your own classes as you see fit. Your own classes can also implement any of the existing .net Interfaces such as IEnumerable if you require.

    It may help if you provide a specific example of what you are trying to achieve.

    Monday, September 26, 2016 2:17 PM
  • Hi RJP1973

    Thanks a lot sir,Now I totally understand what an Interface is. So It's not Mandatory to learn Ienumarable etc when You can Define your Own Interface and work on it.

    • So What I Actually mean to say is-Let us consider an Example where we have a list of Football Players and The number of Goals they have done.After Implementing this,Now I also want to store Which player belongs to which Club.So what Should I do now? Use a Separate List or collection type to assign them to Their Respective Club or edit the above list where we have players and the number of goals they have done.
    Monday, September 26, 2016 2:27 PM
  • Hi,

    I agree to rjp1973 that it is quite likely that you didn't understand the concept of an interface so far.

    So the first thing is the term "standard interfaces" - C# just knows Interfaces. Standard Interfaces could mean Interfaces that are defined inside the framework and that are some kind of standard. (Non Standard Interfaces would be Interfaces that are introduced by a developer so other developers are normaly not aware of these.)

    And classes implement interfaces. So an interface is simply something stand alone. Classes might use (implement) them. Then developers like to say stuff like List<T> implements IList<T>. 

    You can use all Classes that are available. It does not matter and of course does not cause any trouble.

    Maybe it will help to give you an example that might help you a little bit to understand Interfaces a little better.

    Imagine, that all vendors of cars would do, whatever they want to do. Then you could either drive a BMW or an Audi. But the behaviour and how to use the car would be different. So you have to learn each car on your own. Would be quite bad.
    But they commited to standard interfaces. We could think of "ManualGearboxCar" and "AutomaticGearboxCar". All car vendors make sure, to "implement" these interfaces where possible.
    So if you can drive a "ManualGearboxCar", then you can take any car of any vendor who build the car according to that "interface".
    And people simply know how to drive these types of cars: ManualGearboxCar and AutomaticGearboxCar.
    The vendor is now no longer important.
    But of course: There is a backdraft on this: A vendor might have something really cool and new. Lets imagine, that a vendor got a Flux Compensator (Back to future - heya :) ). With just the knowledge of the two interfaces, you cannot use it.

    So when you decide to use interfaces, then you can only use parts, that are defined in an interface. But the exact implementation is no longer of interest. So it doesn't matter if you get a Audi, VW, Mercedes, ... implementation.

    So you see: The interface is only important to have something universal.

    Now a C# example:
    Imagine, that you want to write a method that simply prints all Elements of a collection. You could have a parameter of Type List, but then it always must be a List that you get. A Collection will not work. Or the other way round: You could take a Collection but then a List will not be accepted as parameter.
    But as soon as you take an Interface that both classes implement (and that offers all that you need!), then you could use that as parameter (e.g. IEnumerable). Then it no longer matters if you get a List, Collection or any other instance as long as the Interface IEnumerable is implemented.

    Did this help a little bit? But best you also follow the links given by RJP1973 to get a better understanding.

    With kind regards,


    Monday, September 26, 2016 2:30 PM
  • Hello Konard,

                      Yeah I Understand it.Now I Get it When to use Ienumarable and when to use a user-Defined Interface.Thank you sir :)

    Monday, September 26, 2016 2:37 PM
  • Hi,

    you should look at the different classes an learn how they behave. When you want to store some data, then you have to decide on a concrete class to use for it.

    So in the end you need to get an instance of some class which you will use. This could be a List<Player> which is inside a Club to store all Player of the club.

    The Interfaces are only important when you want to define some interactions. So you could have a method inside your club which is
    public void Add(IEnmuerable<Player> players)
    Which goes through the players given as parameters and add them to the field that stores all player.

    The main idea behind all this is simply the so called encapsulation. The exact implementation is hidden which is great, because that allows you to change the exact implementation whenever you find it useful.

    So when you create the class Club, you have to decide how to store the Player. But when I am using your class later, then this detail will be hidden and I should not even be interested in how you did it.

    With kind regards,


    Monday, September 26, 2016 2:38 PM
  • Hello,

    Alright Now I get it,The Actual Use of Interfaces is Encapsulation.Very well Explained.Thanks a lot sir :)

    Monday, September 26, 2016 2:45 PM