title: If you aren't supposed to return collections to callers, how should you return a collection of data to a caller?
body: <p>I am writing a method that's intended to return a dictionary filled with configuration keys and values. The method that's building up this dictionary is doing so dynamically, so I need to return this set of keys and values as a collection (probably <code>IDictionary&lt;string, string&gt;</code>). In my various readings (sources escape me at the moment), the general consensus on returning collection types from method calls is <strong>not to</strong>.</p>
  
  <p>I understand the reasons for this policy, and I tend to agree, but in cases like this I see no other alternative. This is my question: is there a way I can return this data to the caller, while following this principle?</p>
  
  <p><strong>Edit</strong>: The reasons I've heard for not allowing this behavior is that a collection or dictionary type that is meant to be consumed (but not modified) by the client exposes too much behavior, giving the illusion that the caller can modify the type. Dictionary for example has Add and Remove methods, as well as a mutable indexer. If the values in the dictionary are meant to be read-only, these methods are superfluous at best. Further damage can be done if the internal collection is exposed, and the 'owner' of the collection is not anticipating changes to the collection from outside sources.</p>
  
  <p>There are other reasons I've heard, but I can't recall them off-hand - these are the most pertinent in my situation.</p>
  
  <p><strong>Edit</strong>: More clarification: The problem I'm having is that I'm building an API, so I have no control over the client calling this function. Cloning the dictionary isn't a problem, but I'm trying to keep my API as clean as possible. Returning a dictionary with methods such as Add and Remove implies that the collection can or should be modified, which isn't the case. Modifications here are meaningless, and so I don't want to expose the promise of that functionality through the returned type's interface.</p>
  
  <hr />
  
  <p><strong>Resolution</strong>: To come to terms with my desire for a clean API, I'm going to write a custom Dictionary class that does not expose the mutating methods Add and Remove, or the set indexer. This type will not implement <code>IDictionary</code>, but I will write a method <code>ToDictionary</code> that will return the data within an <code>IDictionary</code>. It will implement <code>IEnumerable&lt;KeyValuePair&lt;TKey, TValue&gt;&gt;</code> in order to have access to the standard LINQ operations over enumerables. Now all I need is a name for my custom dictionary type... =) Thanks everyone.</p>