This a question of weighing the benefits to yourself, the library author, and the benefits to others, the application programmers.
Publishing a general type leaves you free to change your mind later without violating the contract, but at the same time, it devalues the contract itself. If you return a generic collection, your user can't do anything with it except enumerate it. If that's all that is needed, fine. But if the user actually needs a well-defined ordering of the returned elements, a Collection
is not sufficient. In a perfect world, every application programmer would recognize this and refrain from depending on the order in which the elements are returned. However (you know where this is going...), in the real world, what will likely happen is that you declare your results as a Collection
, but implement them via some kind of List
, and your users observe a predictable order of elements and come to depend on it. Then when you change the implementation, their programs break and they curse you. If you had committed to generating a List
in the first place, this can't happen.
This is why it's a good idea to commit at least to some level of specific data structure in public interfaces. It is actually quite rare that you change your mind about whether a data structure will allow duplicates, or whether it allows null
, or whether it has to be ordered or not, so decisions such as choosing List
over Set
aren't that hard to make, and they give your users more assurances to work with (rather than falsely assuming things that are true now but might change without notice).