FWIW, I agree with Serge on this one. Returning a List implies that the contents are ordered. (Which order is not specified, of course.) Returning a Collection does not imply that.

Returning a SortedSet would imply that the contents are both ordered *and* that there are no duplicates. The choice between these two interfaces obviously comes down to whether or not we require uniqueness.

If your contention is that we should not preclude ourselves from switching from List to SortedSet in future, then I believe that simply indicates a lack of understanding of the requirements.

If the requirement is not known at this point, then deferring the decision is a good choice, so the Collection should stay. If the requirement is known, then we should choose the interface that most closely matches the requirement.

If the requirement is that we be able to support either possibility, then what we really need is an OrderedCollection interface, from which both SortedSet and List derive. I do not believe that this is really the case.

The fact that List provides no additional methods that we wish to use is neither here nor there. The salient fact is that a /contract/ accompanies the List interface. This contract is critical to our application and does _not_ accompany the Collection interface. Sure, the current implementation does honour the required contract. It does that only because the implementation class happens to be of a type that does have that contract.

Returning a Collection implies that any Collection could be substituted. This is not true. Returning a List implies that any List would do the job. This *is* true!

The more of our contract that is designed into place, as opposed to just documented into place, the better.

At the end of the day, returning a list provides a degree of compile-time checking for adherence to our required contract, returning a Collection does not. Sure, it would be better still to have checking for the ordering criteria too, but the cost/benefit ratio of providing this does not stack up.

Cheers

ADK


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to