List T or IList T

Question

Can anyone explain to me why I would want to use IList over List in C    Related question  Why is it considered bad to expose List lt T gt

User · Answer

A principle of TDD and OOP generally is programming to an interface not an implementation.

In this specific case since you're essentially talking about a language construct, not a custom one it generally won't matter, but say for example that you found List didn't support something you needed. If you had used IList in the rest of the app you could extend List with your own custom class and still be able to pass that around without refactoring.

The cost to do this is minimal, why not save yourself the headache later? It's what the interface principle is all about.

User · Answer

If you are exposing your class through a library that others will use  you generally want to expose it via interfaces rather than concrete implementations   This will help if you decide to change the implementation of your class later to use a different concrete class   In that case the users of your library won t need to update their code since the interface doesn t change   If you are just using it internally  you may not care so much  and using List lt T gt  may be ok

User · Answer

IList lt   is almost always preferable as per the other poster s advice  however note there is a bug in  NET 3 5 sp 1 when running an IList lt   through more than one cycle of serialization   deserialization with the WCF DataContractSerializer   There is now a SP to fix this bug   KB 971030

User · Answer

Some people say  always use IList lt T gt  instead of List lt T gt    They want you to change your method signatures from void Foo List lt T gt  input  to void Foo IList lt T gt  input    These people are wrong   It s more nuanced than that   If you are returning an IList lt T gt  as part of the public interface to your library  you leave yourself interesting options to perhaps make a custom list in the future   You may not ever need that option  but it s an argument   I think it s the entire argument for returning the interface instead of the concrete type   It s worth mentioning  but in this case it has a serious flaw   As a minor counterargument  you may find every single caller needs a List lt T gt  anyway  and the calling code is littered with  ToList    But far more importantly  if you are accepting an IList as a parameter you d better be careful  because IList lt T gt  and List lt T gt  do not behave the same way   Despite the similarity in name  and despite sharing an interface they do not expose the same contract   Suppose you have this method   public Foo List lt int gt  a        a Add someNumber       A helpful colleague  refactors  the method to accept IList lt int gt    Your code is now broken  because int   implements IList lt int gt   but is of fixed size   The contract for ICollection lt T gt   the base of IList lt T gt   requires the code that uses it to check the IsReadOnly flag before attempting to add or remove items from the collection   The contract for List lt T gt  does not   The Liskov Substitution Principle  simplified  states that a derived type should be able to be used in place of a base type  with no additional preconditions or postconditions   This feels like it breaks the Liskov substitution principle    int   array   new    1  2  3    IList lt int gt  ilist   array    ilist Add 4      throws System NotSupportedException  ilist Insert 0  0      throws System NotSupportedException  ilist Remove 3      throws System NotSupportedException  ilist RemoveAt 0      throws System NotSupportedException   But it doesn t   The answer to this is that the example used IList lt T gt  ICollection lt T gt  wrong   If you use an ICollection lt T gt  you need to check the IsReadOnly flag     if   ilist IsReadOnly       ilist Add 4      ilist Insert 0  0       ilist Remove 3      ilist RemoveAt 0     else         what were you planning to do if you were given a read only list anyway      If someone passes you an Array or a List  your code will work fine if you check the flag every time and have a fallback    But really  who does that   Don t you know in advance if your method needs a list that can take additional members  don t you specify that in the method signature   What exactly were you going to do if you were passed a read only list like int     You can substitute a List lt T gt  into code that uses IList lt T gt  ICollection lt T gt  correctly   You cannot guarantee that you can substitute an IList lt T gt  ICollection lt T gt  into code that uses List lt T gt    There s an appeal to the Single Responsibility Principle   Interface Segregation Principle in a lot of the arguments to use abstractions instead of concrete types - depend on the narrowest possible interface  In most cases  if you are using a List lt T gt  and you think you could use a narrower interface instead - why not IEnumerable lt T gt    This is often a better fit if you don t need to add items   If you need to add to the collection  use the concrete type  List lt T gt    For me IList lt T gt   and ICollection lt T gt   is the worst part of the  NET framework   IsReadOnly violates the principle of least surprise   A class  such as Array  which never allows adding  inserting or removing items should not implement an interface with Add  Insert and Remove methods   see also https   softwareengineering stackexchange com questions 306105 implementing-an-interface-when-you-dont-need-one-of-the-properties   Is IList lt T gt  a good fit for your organisation   If a colleague asks you to change a method signature to use IList lt T gt  instead of List lt T gt   ask them how they d add an element to an IList lt T gt    If they don t know about IsReadOnly  and most people don t   then don t use IList lt T gt    Ever     Note that the IsReadOnly flag comes from ICollection lt T gt   and indicates whether items can be added or removed from the collection  but just to really confuse things  it does not indicate whether they can be replaced  which in the case of Arrays  which return IsReadOnlys    true  can be   For more on IsReadOnly  see msdn definition of ICollection lt T gt  IsReadOnly

User · Answer

public void Foo IList lt Bar gt  list            Do Something with the list here      In this case you could pass in any class which implements the IList lt Bar  interface  If you used List lt Bar  instead  only a List lt Bar  instance could be passed in   The IList lt Bar  way is more loosely coupled than the List lt Bar  way

User · Answer

List lt T gt  is a specific implementation of IList lt T gt   which is a container that can be addressed the same way as a linear array T   using an integer index  When you specify IList lt T gt  as the type of the method s argument  you only specify that you need certain capabilities of the container    For example  the interface specification does not enforce a specific data structure to be used  The implementation of List lt T gt  happens to the same performance for accessing  deleting and adding elements as a linear array  However  you could imagine an implementation that is backed by a linked list instead  for which adding elements to the end is cheaper  constant-time  but random-access much more expensive   Note that the  NET LinkedList lt T gt  does not implement IList lt T gt     This example also tells you that there may be situations when you need to specify the implementation  not the interface  in the argument list  In this example  whenever you require a particular access performance characteristic  This is usually guaranteed for a specific implementation of a container  List lt T gt  documentation   It implements the IList lt T gt  generic interface using an array whose size is dynamically increased as required      Additionally  you might want to consider exposing the least functionality you need  For example  if you don t need to change the content of the list  you should probably consider using IEnumerable lt T gt   which IList lt T gt  extends

User · Answer

If you are exposing your class through a library that others will use  you generally want to expose it via interfaces rather than concrete implementations   This will help if you decide to change the implementation of your class later to use a different concrete class   In that case the users of your library won t need to update their code since the interface doesn t change   If you are just using it internally  you may not care so much  and using List lt T gt  may be ok

User · Answer

If you are exposing your class through a library that others will use  you generally want to expose it via interfaces rather than concrete implementations   This will help if you decide to change the implementation of your class later to use a different concrete class   In that case the users of your library won t need to update their code since the interface doesn t change   If you are just using it internally  you may not care so much  and using List lt T gt  may be ok

User · Answer

Typically  a good approach is to use IList in your public facing API  when appropriate  and list semantics are needed   and then List internally to implement the API    This allows you to change to a different implementation of IList without breaking code that uses your class   The class name List may be changed in next  net framework but the interface is never going to change as interface is contract   Note that  if your API is only going to be used in foreach loops  etc  then you might want to consider just exposing IEnumerable instead

User · Answer

You can look at this argument from several angles including the one of a purely OO approach which says to program against an Interface not an implementation   With this thought  using IList follows the same principal as passing around and using Interfaces that you define from scratch  I also believe in the scalability and flexibility factors provided by an Interface in general  If a class implmenting IList lt T gt  needs to be extended or changed  the consuming code does not have to change  it knows what the IList Interface contract adheres to   However using a concrete implementation and List lt T gt  on a class that changes  could cause the calling code to need to be changed as well  This is because a class adhering to IList lt T gt  guarantees a certain behavior that is not guaranteed by a concrete type using List lt T gt      Also having the power to do something like modify the default implementation of List lt T gt  on a class Implementing IList lt T gt  for say the  Add   Remove or any other IList method gives the developer a lot of flexibility and power  otherwise predefined by List lt T gt

User · Answer

All concepts are basically stated in most of the answers above regarding why use interface over concrete implementations   IList lt T gt  defines those methods  not including extension methods    IList lt T gt  MSDN link   Add Clear Contains CopyTo GetEnumerator IndexOf Insert Remove RemoveAt   List lt T gt  implements those nine methods  not including extension methods   on top of that it has about 41 public methods  which weighs in your consideration of which one to use in your application   List lt T gt  MSDN link

User · Answer

The most important case for using interfaces over implementations is in the parameters to your API  If your API takes a List parameter  then anyone who uses it has to use List  If the parameter type is IList  then the caller has much more freedom  and can use classes you never heard about  which may not even have existed when your code was written

User · Answer

I would turn the question around a bit  instead of justifying why you should use the interface over the concrete implementation  try to justify why you would use the concrete implementation rather than the interface  If you can t justify it  use the interface

User · Answer

IList lt   is almost always preferable as per the other poster s advice  however note there is a bug in  NET 3 5 sp 1 when running an IList lt   through more than one cycle of serialization   deserialization with the WCF DataContractSerializer   There is now a SP to fix this bug   KB 971030

User · Answer

The less popular answer is programmers like to pretend their software is going to be re-used the world over  when infact the majority of projects will be maintained by a small amount of people and however nice interface-related soundbites are  you re deluding yourself   Architecture Astronauts  The chances you will ever write your own IList that adds anything to the ones already in the  NET framework are so remote that it s theoretical jelly tots reserved for  best practices      Obviously if you are being asked which you use in an interview  you say IList  smile  and both look pleased at yourselves for being so clever  Or for a public facing API  IList  Hopefully you get my point

User · Answer

What if  NET 5 0 replaces System Collections Generic List lt T gt  to System Collection Generics LinearList lt T gt    NET always owns the name List lt T gt  but they guarantee that IList lt T gt  is a contract  So IMHO we  atleast I  are not supposed to use someone s name  though it is  NET in this case  and get into trouble later   In case of using IList lt T gt   the caller is always guareented things to work  and the implementer is free to change the underlying collection to any alternative concrete implementation of IList

User · Answer

The interface ensures that you at least get the methods you are expecting  being aware of the definition of the interface ie  all abstract methods that are there to be implemented by any class inheriting the interface  so if some one makes a huge class of his own with several methods besides the ones he inherited from the interface for some addition functionality  and those are of no use to you  its better to use a reference to a subclass  in this case the interface  and assign the concrete class object to it   additional advantage is that your code is safe from any changes to concrete class as you are subscribing to only few of the methods of concrete class and those are the ones that are going to be there as long as the concrete class inherits from the interface you are using  so its safety for you and freedom to the coder who is writing concrete implementation to change or add more functionality to his concrete class

User · Answer

IList lt T gt  is an interface so you can inherit another class and still implement IList lt T gt  while inheriting List lt T gt  prevents you to do so   For example if there is a class A and your class B inherits it then you can t use List lt T gt   class A   B  IList lt T gt

User · Answer

I would turn the question around a bit  instead of justifying why you should use the interface over the concrete implementation  try to justify why you would use the concrete implementation rather than the interface  If you can t justify it  use the interface

User · Answer

IList lt T gt  is an interface so you can inherit another class and still implement IList lt T gt  while inheriting List lt T gt  prevents you to do so   For example if there is a class A and your class B inherits it then you can t use List lt T gt   class A   B  IList lt T gt

User · Answer

Typically  a good approach is to use IList in your public facing API  when appropriate  and list semantics are needed   and then List internally to implement the API    This allows you to change to a different implementation of IList without breaking code that uses your class   The class name List may be changed in next  net framework but the interface is never going to change as interface is contract   Note that  if your API is only going to be used in foreach loops  etc  then you might want to consider just exposing IEnumerable instead

User · Answer

Some people say  always use IList lt T gt  instead of List lt T gt    They want you to change your method signatures from void Foo List lt T gt  input  to void Foo IList lt T gt  input    These people are wrong   It s more nuanced than that   If you are returning an IList lt T gt  as part of the public interface to your library  you leave yourself interesting options to perhaps make a custom list in the future   You may not ever need that option  but it s an argument   I think it s the entire argument for returning the interface instead of the concrete type   It s worth mentioning  but in this case it has a serious flaw   As a minor counterargument  you may find every single caller needs a List lt T gt  anyway  and the calling code is littered with  ToList    But far more importantly  if you are accepting an IList as a parameter you d better be careful  because IList lt T gt  and List lt T gt  do not behave the same way   Despite the similarity in name  and despite sharing an interface they do not expose the same contract   Suppose you have this method   public Foo List lt int gt  a        a Add someNumber       A helpful colleague  refactors  the method to accept IList lt int gt    Your code is now broken  because int   implements IList lt int gt   but is of fixed size   The contract for ICollection lt T gt   the base of IList lt T gt   requires the code that uses it to check the IsReadOnly flag before attempting to add or remove items from the collection   The contract for List lt T gt  does not   The Liskov Substitution Principle  simplified  states that a derived type should be able to be used in place of a base type  with no additional preconditions or postconditions   This feels like it breaks the Liskov substitution principle    int   array   new    1  2  3    IList lt int gt  ilist   array    ilist Add 4      throws System NotSupportedException  ilist Insert 0  0      throws System NotSupportedException  ilist Remove 3      throws System NotSupportedException  ilist RemoveAt 0      throws System NotSupportedException   But it doesn t   The answer to this is that the example used IList lt T gt  ICollection lt T gt  wrong   If you use an ICollection lt T gt  you need to check the IsReadOnly flag     if   ilist IsReadOnly       ilist Add 4      ilist Insert 0  0       ilist Remove 3      ilist RemoveAt 0     else         what were you planning to do if you were given a read only list anyway      If someone passes you an Array or a List  your code will work fine if you check the flag every time and have a fallback    But really  who does that   Don t you know in advance if your method needs a list that can take additional members  don t you specify that in the method signature   What exactly were you going to do if you were passed a read only list like int     You can substitute a List lt T gt  into code that uses IList lt T gt  ICollection lt T gt  correctly   You cannot guarantee that you can substitute an IList lt T gt  ICollection lt T gt  into code that uses List lt T gt    There s an appeal to the Single Responsibility Principle   Interface Segregation Principle in a lot of the arguments to use abstractions instead of concrete types - depend on the narrowest possible interface  In most cases  if you are using a List lt T gt  and you think you could use a narrower interface instead - why not IEnumerable lt T gt    This is often a better fit if you don t need to add items   If you need to add to the collection  use the concrete type  List lt T gt    For me IList lt T gt   and ICollection lt T gt   is the worst part of the  NET framework   IsReadOnly violates the principle of least surprise   A class  such as Array  which never allows adding  inserting or removing items should not implement an interface with Add  Insert and Remove methods   see also https   softwareengineering stackexchange com questions 306105 implementing-an-interface-when-you-dont-need-one-of-the-properties   Is IList lt T gt  a good fit for your organisation   If a colleague asks you to change a method signature to use IList lt T gt  instead of List lt T gt   ask them how they d add an element to an IList lt T gt    If they don t know about IsReadOnly  and most people don t   then don t use IList lt T gt    Ever     Note that the IsReadOnly flag comes from ICollection lt T gt   and indicates whether items can be added or removed from the collection  but just to really confuse things  it does not indicate whether they can be replaced  which in the case of Arrays  which return IsReadOnlys    true  can be   For more on IsReadOnly  see msdn definition of ICollection lt T gt  IsReadOnly

User · Answer

The most important case for using interfaces over implementations is in the parameters to your API  If your API takes a List parameter  then anyone who uses it has to use List  If the parameter type is IList  then the caller has much more freedom  and can use classes you never heard about  which may not even have existed when your code was written

User · Answer

A principle of TDD and OOP generally is programming to an interface not an implementation.

In this specific case since you're essentially talking about a language construct, not a custom one it generally won't matter, but say for example that you found List didn't support something you needed. If you had used IList in the rest of the app you could extend List with your own custom class and still be able to pass that around without refactoring.

The cost to do this is minimal, why not save yourself the headache later? It's what the interface principle is all about.

User · Answer

Supprising that none of these List vs IList questions  or answers  mentions the signature difference    Which is why I searched for this question on SO    So here s the methods contained by List that are not found in IList  at least as of  NET 4 5  circa 2015    AddRange AsReadOnly BinarySearch Capacity ConvertAll Exists Find FindAll FindIndex FindLast FindLastIndex ForEach GetRange InsertRange LastIndexOf RemoveAll RemoveRange Reverse Sort ToArray TrimExcess TrueForAll

User · Answer

The most important case for using interfaces over implementations is in the parameters to your API  If your API takes a List parameter  then anyone who uses it has to use List  If the parameter type is IList  then the caller has much more freedom  and can use classes you never heard about  which may not even have existed when your code was written

User · Answer

Interface is a promise  or a contract    As it is always with the promises - smaller the better

User · Answer

public void Foo IList lt Bar gt  list            Do Something with the list here      In this case you could pass in any class which implements the IList lt Bar  interface  If you used List lt Bar  instead  only a List lt Bar  instance could be passed in   The IList lt Bar  way is more loosely coupled than the List lt Bar  way

User · Answer

A principle of TDD and OOP generally is programming to an interface not an implementation.

In this specific case since you're essentially talking about a language construct, not a custom one it generally won't matter, but say for example that you found List didn't support something you needed. If you had used IList in the rest of the app you could extend List with your own custom class and still be able to pass that around without refactoring.

The cost to do this is minimal, why not save yourself the headache later? It's what the interface principle is all about.

User · Answer

You would because defining an IList or an ICollection would open up for other implementations of your interfaces   You might want to have an IOrderRepository that defines a collection of orders in either a IList or ICollection  You could then have different kinds of implementations to provide a list of orders as long as they conform to  rules  defined by your IList or ICollection

User · Answer

The most important case for using interfaces over implementations is in the parameters to your API  If your API takes a List parameter  then anyone who uses it has to use List  If the parameter type is IList  then the caller has much more freedom  and can use classes you never heard about  which may not even have existed when your code was written

User · Answer

List lt T gt  is a specific implementation of IList lt T gt   which is a container that can be addressed the same way as a linear array T   using an integer index  When you specify IList lt T gt  as the type of the method s argument  you only specify that you need certain capabilities of the container    For example  the interface specification does not enforce a specific data structure to be used  The implementation of List lt T gt  happens to the same performance for accessing  deleting and adding elements as a linear array  However  you could imagine an implementation that is backed by a linked list instead  for which adding elements to the end is cheaper  constant-time  but random-access much more expensive   Note that the  NET LinkedList lt T gt  does not implement IList lt T gt     This example also tells you that there may be situations when you need to specify the implementation  not the interface  in the argument list  In this example  whenever you require a particular access performance characteristic  This is usually guaranteed for a specific implementation of a container  List lt T gt  documentation   It implements the IList lt T gt  generic interface using an array whose size is dynamically increased as required      Additionally  you might want to consider exposing the least functionality you need  For example  if you don t need to change the content of the list  you should probably consider using IEnumerable lt T gt   which IList lt T gt  extends

User · Answer

IList lt T gt  is an interface so you can inherit another class and still implement IList lt T gt  while inheriting List lt T gt  prevents you to do so   For example if there is a class A and your class B inherits it then you can t use List lt T gt   class A   B  IList lt T gt

User · Answer

You would because defining an IList or an ICollection would open up for other implementations of your interfaces   You might want to have an IOrderRepository that defines a collection of orders in either a IList or ICollection  You could then have different kinds of implementations to provide a list of orders as long as they conform to  rules  defined by your IList or ICollection

User · Answer

Interface is a promise  or a contract    As it is always with the promises - smaller the better

User · Answer

List lt T gt  is a specific implementation of IList lt T gt   which is a container that can be addressed the same way as a linear array T   using an integer index  When you specify IList lt T gt  as the type of the method s argument  you only specify that you need certain capabilities of the container    For example  the interface specification does not enforce a specific data structure to be used  The implementation of List lt T gt  happens to the same performance for accessing  deleting and adding elements as a linear array  However  you could imagine an implementation that is backed by a linked list instead  for which adding elements to the end is cheaper  constant-time  but random-access much more expensive   Note that the  NET LinkedList lt T gt  does not implement IList lt T gt     This example also tells you that there may be situations when you need to specify the implementation  not the interface  in the argument list  In this example  whenever you require a particular access performance characteristic  This is usually guaranteed for a specific implementation of a container  List lt T gt  documentation   It implements the IList lt T gt  generic interface using an array whose size is dynamically increased as required      Additionally  you might want to consider exposing the least functionality you need  For example  if you don t need to change the content of the list  you should probably consider using IEnumerable lt T gt   which IList lt T gt  extends

User · Answer

Interface is a promise  or a contract    As it is always with the promises - smaller the better

User · Answer

You can look at this argument from several angles including the one of a purely OO approach which says to program against an Interface not an implementation   With this thought  using IList follows the same principal as passing around and using Interfaces that you define from scratch  I also believe in the scalability and flexibility factors provided by an Interface in general  If a class implmenting IList lt T gt  needs to be extended or changed  the consuming code does not have to change  it knows what the IList Interface contract adheres to   However using a concrete implementation and List lt T gt  on a class that changes  could cause the calling code to need to be changed as well  This is because a class adhering to IList lt T gt  guarantees a certain behavior that is not guaranteed by a concrete type using List lt T gt      Also having the power to do something like modify the default implementation of List lt T gt  on a class Implementing IList lt T gt  for say the  Add   Remove or any other IList method gives the developer a lot of flexibility and power  otherwise predefined by List lt T gt

User · Answer

Interface is a promise  or a contract    As it is always with the promises - smaller the better

User · Answer

You would because defining an IList or an ICollection would open up for other implementations of your interfaces   You might want to have an IOrderRepository that defines a collection of orders in either a IList or ICollection  You could then have different kinds of implementations to provide a list of orders as long as they conform to  rules  defined by your IList or ICollection

User · Answer

IList lt T gt  is an interface so you can inherit another class and still implement IList lt T gt  while inheriting List lt T gt  prevents you to do so   For example if there is a class A and your class B inherits it then you can t use List lt T gt   class A   B  IList lt T gt

User · Answer

What if  NET 5 0 replaces System Collections Generic List lt T gt  to System Collection Generics LinearList lt T gt    NET always owns the name List lt T gt  but they guarantee that IList lt T gt  is a contract  So IMHO we  atleast I  are not supposed to use someone s name  though it is  NET in this case  and get into trouble later   In case of using IList lt T gt   the caller is always guareented things to work  and the implementer is free to change the underlying collection to any alternative concrete implementation of IList

User · Answer

All concepts are basically stated in most of the answers above regarding why use interface over concrete implementations   IList lt T gt  defines those methods  not including extension methods    IList lt T gt  MSDN link   Add Clear Contains CopyTo GetEnumerator IndexOf Insert Remove RemoveAt   List lt T gt  implements those nine methods  not including extension methods   on top of that it has about 41 public methods  which weighs in your consideration of which one to use in your application   List lt T gt  MSDN link

User · Answer

Supprising that none of these List vs IList questions  or answers  mentions the signature difference    Which is why I searched for this question on SO    So here s the methods contained by List that are not found in IList  at least as of  NET 4 5  circa 2015    AddRange AsReadOnly BinarySearch Capacity ConvertAll Exists Find FindAll FindIndex FindLast FindLastIndex ForEach GetRange InsertRange LastIndexOf RemoveAll RemoveRange Reverse Sort ToArray TrimExcess TrueForAll

User · Answer

A principle of TDD and OOP generally is programming to an interface not an implementation.

In this specific case since you're essentially talking about a language construct, not a custom one it generally won't matter, but say for example that you found List didn't support something you needed. If you had used IList in the rest of the app you could extend List with your own custom class and still be able to pass that around without refactoring.

The cost to do this is minimal, why not save yourself the headache later? It's what the interface principle is all about.

User · Answer

You would because defining an IList or an ICollection would open up for other implementations of your interfaces   You might want to have an IOrderRepository that defines a collection of orders in either a IList or ICollection  You could then have different kinds of implementations to provide a list of orders as long as they conform to  rules  defined by your IList or ICollection

User · Answer

List lt T gt  is a specific implementation of IList lt T gt   which is a container that can be addressed the same way as a linear array T   using an integer index  When you specify IList lt T gt  as the type of the method s argument  you only specify that you need certain capabilities of the container    For example  the interface specification does not enforce a specific data structure to be used  The implementation of List lt T gt  happens to the same performance for accessing  deleting and adding elements as a linear array  However  you could imagine an implementation that is backed by a linked list instead  for which adding elements to the end is cheaper  constant-time  but random-access much more expensive   Note that the  NET LinkedList lt T gt  does not implement IList lt T gt     This example also tells you that there may be situations when you need to specify the implementation  not the interface  in the argument list  In this example  whenever you require a particular access performance characteristic  This is usually guaranteed for a specific implementation of a container  List lt T gt  documentation   It implements the IList lt T gt  generic interface using an array whose size is dynamically increased as required      Additionally  you might want to consider exposing the least functionality you need  For example  if you don t need to change the content of the list  you should probably consider using IEnumerable lt T gt   which IList lt T gt  extends

User · Answer

The less popular answer is programmers like to pretend their software is going to be re-used the world over  when infact the majority of projects will be maintained by a small amount of people and however nice interface-related soundbites are  you re deluding yourself   Architecture Astronauts  The chances you will ever write your own IList that adds anything to the ones already in the  NET framework are so remote that it s theoretical jelly tots reserved for  best practices      Obviously if you are being asked which you use in an interview  you say IList  smile  and both look pleased at yourselves for being so clever  Or for a public facing API  IList  Hopefully you get my point

User · Answer

public void Foo IList lt Bar gt  list            Do Something with the list here      In this case you could pass in any class which implements the IList lt Bar  interface  If you used List lt Bar  instead  only a List lt Bar  instance could be passed in   The IList lt Bar  way is more loosely coupled than the List lt Bar  way

User · Answer

If you are exposing your class through a library that others will use  you generally want to expose it via interfaces rather than concrete implementations   This will help if you decide to change the implementation of your class later to use a different concrete class   In that case the users of your library won t need to update their code since the interface doesn t change   If you are just using it internally  you may not care so much  and using List lt T gt  may be ok

User · Answer

The interface ensures that you at least get the methods you are expecting  being aware of the definition of the interface ie  all abstract methods that are there to be implemented by any class inheriting the interface  so if some one makes a huge class of his own with several methods besides the ones he inherited from the interface for some addition functionality  and those are of no use to you  its better to use a reference to a subclass  in this case the interface  and assign the concrete class object to it   additional advantage is that your code is safe from any changes to concrete class as you are subscribing to only few of the methods of concrete class and those are the ones that are going to be there as long as the concrete class inherits from the interface you are using  so its safety for you and freedom to the coder who is writing concrete implementation to change or add more functionality to his concrete class

User · Answer

public void Foo IList lt Bar gt  list            Do Something with the list here      In this case you could pass in any class which implements the IList lt Bar  interface  If you used List lt Bar  instead  only a List lt Bar  instance could be passed in   The IList lt Bar  way is more loosely coupled than the List lt Bar  way

[c#] List<T> or IList<T>

Examples related to c#

Examples related to list

Examples related to generics