This question already has an answer here:
implement ienumerable with ienumerable<T>
(1 answer)
Closed 3 years ago.
If I just want to use the generic version IEnumerable, I have to implement not only IEnumerator<T> GetEnumerator() but also IEnumerator GetEnumerator(), the latter seems to be redundant
IEnumerable interface was introduced in 1.1 .net framework.
But generic version IEnumerable<T> in 2.0 only (with generics). So, it's backward compatibility. There is legacy code, that accept only IEnumerable:
void Method(IEnumerable list)
{
foreach(var item in list)
{
Console.WriteLine(item);
}
}
So if IEnumerable<T> does not implement IEnumerable, you can not pass List<int> in this method, for example.
Basically, there are two reasons:
compatibility. A lot of legacy code, which can deal with IEnumerable, but can't deal with IEnumerable<T>. Yes, modern APIs are being designed to use generics, but from time to time we need to use legacy APIs.
there are cases, when you want to enumerate, but don't care at design-time about object type or boxing. IEnumerable is OK here. Data binding is the most obvious one.
Related
This question already has answers here:
Can anyone explain IEnumerable and IEnumerator to me? [closed]
(16 answers)
Closed 7 days ago.
I want to know the exact place where we should use IEnumberable<T>
I know how IEnumerable<T> work and returns IEnumerator<T> and all that but the ultimate goal of IEnumerable<T> is to query the data from the collection isn't it? That is what we can already do using foreach() loop ? So when to use IEnumerable<T>? what is the actual practical scenario where the IEnumerable<T> is the only option to query the collection?
but the ultimate goal of IEnumerable<T> is to query the data from the collection isn't it?
No; the goal of IEnumerable<T> is to provide access to a sequence, which may or may not be a collection. The point being to abstract away what the underlying source is. It could be a raw collection, but it could be:
some LINQ (or similar) projection (collection.Where(...).Select(...) etc)
an open query to ADO.NET, redis, a socket, gRPC, a file or some other data provider that isn't readily countable, repeatable, etc - just: "a sequence"
an in-process data generator
some producer/consumer setup
etc
If you know you're always iterating a collection, then sure: feel free to use the concrete type, or ICollection<T>/IList<T> etc; but: not every sequence is a collection.
This question already has answers here:
When to use IList and when to use List
(12 answers)
Closed 9 years ago.
I saw a function like
public FuncA(string param1, IList<SqlParameter> sqlParamsList)
I wonder why the author was using IList instead of List? Which one is better? I know the difference between them is one is interface, the other one is class. So my final question is when to use which?
More than one class can implement the IList interface. If you use IList you accept any class that implements IList.
If you use List, you can only pass List and derived classes.
Using an interface is generally preferable as it makes the API more flexible for the caller. If your method accepts the interface rather than the concrete implementation, the caller can use whatever type they want (List, Array, ImmutableList...), as long as it implements IList.
Using an interface is preferred over a concrete type in order to allow a caller to pass in any object that implements the interface.
Especially in public methods this is good practice.
I would tend towards using the IList interface parameter over the concrete implementation, unless there was some reason you absolutely HAD to have the concrete List parameter.
By using IList instead of List, your method can now accept all collection types that implement IList, which may or may not be a collection that directly inherits from List. List and any of its subclasses implement IList as well, so they would also be included in the set of available types your method could use. Using IList in this case allows you to be more flexible.
Also, in unit testing scenarios, IList may be easier to mock out, depending on what exactly you're trying to test and what your features your mocking framework has.
This question already has answers here:
C#'s equivalent of Java's <? extends Base> in generics
(4 answers)
Closed 9 years ago.
I’m looking for equivalent C# code of following line
private List<? extends HotSpot> hotSpots;
Any help is much appreciated.
Depending on exactly what you need, you're probably either looking for:
public class MyClass
{
private IList<HotSpot> hotSpots;
}
or using where
public class MyClass<T> where T : HotSpot
{
private IList<T> hotSpots;
}
Functionally, I'd say the closest is:
IEnumerable<HotSpot> hotSpots;
If the real type of the the enumerable happens to be an IList, then ElementAt() and such will be O(1).
As of .NET 4.5, you could also use:
IReadOnlyList<HotSpot> hotSpots;
and use List.AsReadOnly() to wrap regular lists.
The .NET approach to variance in generics is letting specific interfaces be either covariant or contravariant, and consequently only allow them to define methods with the generic type parameter as the return value only, or only in the argument list. (As opposed to Java where the compiler does these checks in each expression.) My guess is the rationale is that C# implements generics using reification, and a concrete type like List<out T> can't exist in the type system.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why is there not a ForEach extension method on the IEnumerable interface?
Why ForEach extension method is not available in ObservableCollections class while it is available in List ?
As JJohn says, it's by design. Read this post by Eric Lippert for more information. A standard foreach loop works just as well and is generally more readable.
ForEach is available only in List<T> and not in any other collection. It is just design decision.
Foreach can be used only on those objects which are of classes that implements IEnumerable.
IEnumerable is an interface that defines one method GetEnumerator which returns an IEnumerator interface, this in turn allows readonly access to a collection. A collection that implements IEnumerable can be used with a foreach statement.
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
IList<int> vs List<int>
C# - List<T> or IList<T>
What is the difference between List and IList, which one has better performance and when to use List over IList and vice versa?
In C# List is a concrete implementation of the IList interface. The List is an implementation of the IList Interface. The idea is to program against the interface, not the implementation. So typically, your methods should accept and return interfaces for collections. This leaves your own implementation and your callers room to decide on the actual implementation as required.
Benefit of using an Interface is that you get to implement your functionality or better yet, the only functionality you require. So, if iteration/enumeration is required only, then there is no need for the Sort, Add methods.
List implements IList interface
IList is a interface and doesn't have any implementation, so the performance of IList depending the class it implements
IList is the interface - see this question for more information - List<T> or IList<T>