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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Somewhere I have read this question. How can we handle situation like this:
I have an interface, In that I have four methods: Add, Subtract, Multiply, Divide.
I have two classes A and B.
I want A and B to implement this Interface. But I want situation like this:
A can access only Add, Subtract.
B can access only Multiply, Divide.
Please tell me how is this possible in C#?
Or by some trick if this is possible please let me know.
The point of an interface is to define a contract between two objects. If you are saying that your object only wants to implement some of the contract, then that breaks the meaning of the interface.
Why don't you use multiple interfaces, one for Add/Subtract and another for Multiply/Divide. Your class can implement any or both of these interfaces.
A class that implements an interface must implement all of its methods. The documentation says:
A class or struct that implements the interface must implement the members of the interface that are specified in the interface definition.
It seems to me that what you need is two interfaces:
IAdditiveOperators which implements addition and subtraction.
IMultiplicativeOperators which implements multiplication and division.
Implementing classes can then implement one or other or both.
Split the interface to two interfaces: one with Add and Substract and name IAddSubstract and another one with Multiply and Divide with name IMultiplyDivide. Then you can add another interface (IOperation) which implements IAddSubstract and IMultiplyDivide
You have two ways to go about it:
Either split up your methods between two separate interfaces and implement one interface containing Add and Subtract in class A and the other one containing Multiply and Divide in class B. That of course means you have two interfaces instead of one, so decide if this is a problem.
OR
If you insist on having only one interface, you can declare A and B as abstract (which of course means you cannot instantiate them)
If going the abstract route, you need to mark interface methods you don't want to implement as abstract as well.
You can't avoid implementing all methods of the interface. If you inherit the interface you have to fulfil it.
In some situations some methods of an interface can't have a useful implementation for a specific class. After you have come to the conclusion that you should implement the interface despite this, there are some things that you can do:
You can implement a method as doing nothing. If the class already does what's expected without it, you can just accept the method call and silently do nothing.
You can throw a NotSupportedException, if some result is expected by calling the method, that the class can't fulfil. Naturally this should only be done if the method is not crucial for how the interface is supposed to be used.
Also, you have the choise of implementing interface members implicitly or explicilty. Implicitly is the normal way, where the member is visible both when the type of the reference is the interface and when it's the class.
To implement a member explicitly makes it only visible when the type of the reference is the interface, not when it's the class.
If the Multiply method is implemented explicitly in the class A (and the interface is named ICanCalc):
A obja = new A();
ICanCalc infa = new A();
infa.Multiply(); // works fine
obja.Multiply(); // gives a compiler error
However, the method is only hidden, you can still use it by simply casting the reference:
(ICanCalc)obja.Multiply(); // works fine
This question already has answers here:
List<T> or IList<T> [closed]
(18 answers)
Closed 8 years ago.
Why here interface Ilist is used to create an object of List type
IList<BankAccountView> bankAccountViews = new List<BankAccountView>();
when it can be done like this
List<BankAccountView> bankAccountViews = new List<BankAccountView>();
A List is a concrete type, while an IList is a contract for which you can use any implemtation that an IList has.
An IList has a set of methods as defined on MSDN: http://msdn.microsoft.com/en-us/library/system.collections.ilist.aspx
Here's a very good blogpost explaining it in detail: http://www.claudiobernasconi.ch/2013/07/22/when-to-use-ienumerable-icollection-ilist-and-list/
So when writing a function or method that takes a collection, write it not to take a List, but an IList, an ICollection, or IEnumerable. The generic interfaces will still work even for heterogenous lists because System.Object can be a T too. Doing this will save you headache if you decide to use a Stack or some other data structure further down the road. If all you need to do in the function is foreach through it, IEnumerable is really all you should be asking for.
On the other hand, when returning an object out of a function, you want to give the user the richest possible set of operations without them having to cast around. So in that case, if it's a List internally, return a copy as a List.
Read link: When to use IList and when to use List
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Do interfaces derive from System.Object? C# spec says yes, Eric says no, reality says no
It is said all objects in .net inherit from System.Object.
Is that true?
I try to find what object the Ilist interface inherited from on the MSDN, but there's no mention about its inheritance.
Can anyone tell me something?
Interfaces themselves aren't objects in a class hierarchy. They are "types" in the sense that they represent an object. But they aren't concrete classes in and of themselves.
For example, you can't instantiate an IList<int>. This wouldn't compile:
var list = new IList<int>();
However, you can create a List<int>, which does inherit from System.Object:
var list = new List<int>();
This instance of list can be viewed as lots of different interfaces. For example:
var listVariantA = list as IList<int>();
var listVariantB = list as IEnumerable<int>();
And so on. This is because its concrete type, List<int>, implements multiple interfaces. It doesn't inherit from them, as they themselves are not concrete types.
It seems like where you're getting lost is in the different between inheritance and interfaces. Some might say that interfaces are ".NET's answer to multiple inheritance" which can be a fair statement. But there's a fundamental difference between the two concepts. Think of inheritance as a hierarchy of what an object is:
Vehicle
Car
Honda Accord
Toyota Camry
Truck
Ford F150
And so on. Interfaces don't fit into this hierarchy. Think of an interface, instead, as a contract which an object meets. For example, all Vehicle object might implement the IDrivable interface. Some of them might implement the IFlyable interface. Some still might implement both (flying cars).
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Reference unit tests for common data structures?
I'm trying to implement the IList interface. I've finished my implementation, but I'm not sure if my implementation semantically fits for this interface. Are there tests for prooving that? Tests for the ICollection interface would be appreciate too.
You know what you're supposed to implement so just unit test your class.
There are no 'standard' tests for collections in BCL, as every collection is different. Yours must be doing something special since you're not using List<T>.
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>