It will therefore behave the same way regardless of the CommaSeparate() method's return type.Īs someone else pointed out, the FXCop rule warns against using List, not IList the question you linked to is asking why FXCop doesn't recommend using IList in place of List, which is another matter. Regardless of the runtime type of the object returned, consider the behavior when the static reference is IList or ICollection: When you call GetEnumerator() (perhaps implicitly in a foreach loop), you're going to call the same method and get the same object regardless of the static type of the reference. If you need the method to return, by contract, a type whose contract requires a certain order, then you should express that in the method's signature by returning the more specific type. For example, if you return the Values collection of a SortedDictionary, the objects will be in the the order defined by the dictionary's comparer. The objects will be in the order specified by the object returned. The ICollection interface doesn't specify anything about an order. In the case of an API contract, to indicate order, which of the following is correct: IEnumerable Grob(string s) It is critical that the order of items be maintained.Ĭonceptually, i require a contract that indicates an "ordered" set of string tuples. This begs the wider question: Does an ICollection even have an order?Ĭonceptually, imagine i want to parse a command line string. Is there a ways to access items of a collection in order?
Unfortunately, my internal implementation constructs an array which i can be cast to return IList or ICollection, but not as a Collection.
ICOLLECTIONS LITE VS COLLECTIONS CODE
Following the rules that a public APIs should never return a list, i'm blinding converting all code that returned lists, to return ICollection instead: public IList CommaSeparate(String value)
0 kommentar(er)
