 <p>The design of an interface contract is a balancing; a good interface should satisfy consumers' needs, but prevent implementations from using the most efficient data structures and algorithms that would meet consumers' <em>actual</em> needs. If consumers would <em>substantially</em> benefit from knowing certain things about an interface's implementation, then it may be worth including such details in the interface contract, but only if the benefit to consumers would outweigh any cost to implementers. Further, it's important when designing an interface to have some idea of how it might be implemented. One need not flesh out all the details of an implementation, but an understanding of potential implementations and what features are likely to be cheap or expensive may allow an interface to satisfy clients better than would otherwise be possible.</p> <p>Consider, for example, the .NET <code>IList&lt;T&gt;</code> interface, which goes back to the very beginning of .NET generics. Even though typical implementations will be backed by one or more arrays, and it's possible to copy a range of elements from one array to another very efficiently, the only general way to copy a range of elements from one <code>IList&lt;T&gt;</code> to another is to enumerate them individually--an approach which is many times slower than an array copy would be. If there existed a system-defined non-inheritable(*) <code>ReadonlyArraySegment</code> type which--like <code>ArraySegment</code>--encapsulated an array reference and a range of elements but--unlike <code>ArraySegment</code>--did not allow outside code access to the array itself, then an <code>IList&lt;T&gt;</code> could have offered a method which would return part of the list as an <code>IEnumerable&lt;ReadonlyArraySegment&lt;T&gt;&gt;</code>, along with a method which--given an <code>IEnumerable&lt;ReadonlyArraySegment&lt;T&gt;&gt;</code> could use <code>Array.Copy</code> to copy ranges of data into its own backing stores. If two implementations of <code>IList&lt;T&gt;</code> each happened to use a single array as a backing store, items could be copied very efficiently. If they use multiple arrays as backing stores, copying would be more complicated but could still be many times faster than processing elements individually. If the source list uses something that isn't based on arrays (such as a tree), an <code>IEnumerable&lt;ReadonlyArraySegment&lt;T&gt;&gt;</code> would end up having to copy each list item to a single-element array [depending upon how the contract is written, it may be able to continuously recycle the same single-element array].</p> <p>(*) If the system type were non-inheritable, and its contract provided that it would not be possible for code to modify the encapsulated array or get a reference to it, and the only thing that would be done with the array would be to read or copy elements out of it, then other data types with backing arrays could safely make their contents available to outside code via <code>ReadonlyArraySegment</code>, especially if there were a means by which the code which created a <code>ReadonlyArraySegment</code> could later invalidate it. </p> <p>Having <code>IList&lt;T&gt;</code> include a function which would return the list as an <code>IEnumerable&lt;ReadonlyArraySegment&gt;&gt;</code> would in a sense expose a common implementation detail (that lists often use backing arrays), but it could also offer a significant benefit to clients (the ability to copy data quickly from one <code>IList&lt;T&gt;</code> to another). As to whether Microsoft considered such features and decided they weren't worth the cost, or they simply wanted to get an interface that could do the most important things out the door, or somewhere in-between, I have no idea. My point is that sometimes it may be useful for an interface contract to expose details of probable implementation; such exposure should generally be done in such a way that clients which implement things other ways could still satisfy the contract (though perhaps less efficiently than those which implement things in the expected fashion), and is generally only appropriate when clients would actually benefit from it.</p>