The problem is that Java supports neither inferred structural types or intersection types, which is why attempting to do things the "right way" ends up becoming extremely unwieldy in the case of collections. In a perfect world, interfaces would not have optional operations, and fine grained interfaces would instead be used. However, such an implementation would violate the contract as the documentation for Collection.size() does not say that this is permitted.Īside: The approach used by Java's Collections API is somewhat controversial (probably less now than when it was first introduced, however). For example, you could throw it from an implementation of Collection.size(). Note that because UnsupportedOperationException is a RuntimeException you can throw it from any method implementation, as far as the compiler is concerned. Rather, it means that a valid implementation choice (one that still conforms to the contract) is to throw an UnsupportedOperationException. When methods in the Collections API are documented as being "optional operations", it does not mean that you can just leave the method implementation out in the implementation, nor does it mean you can use an empty method body (for one thing, many of them need to return a result). Of core interfaces that can throw a runtime exception. When all was said and done, we felt that it was a sound engineeringĬompromise to sidestep the whole issue by providing a very small set For example, theĬollection-views returned by Map are natural delete-only collections.Īlso, there are collections that will reject certain elements on theīasis of their value, so we still haven't done away with runtime That don't fit cleanly into any of the interfaces. Now we're up to twenty or so interfaces and five iterators, and it'sĪlmost certain that there are still collections arising in practice Important distinction of all, because it allows multiple threads toĪccess a collection concurrently without the need for synchronization.Īdding this support to the type hierarchy requires four more (i.e., Collections that cannot be changed by the client AND will neverĬhange for any other reason). They require a new core interface, and a new iterator.Īnd what about immutable Collections, as opposed to unmodifiable ones? That support all of the List operations except for remove and set Twelve interfaces, plus two new Iterator interfaces, instead of ourĬonsider logs (such as error logs, audit logs and journals for Operations, to go along with unmodifiable List. Variety of ListIterator that doesn't support the add and remove Identical to ModifiableCollection and ModifiableSet, but you mightĬhoose to add them anyway for consistency's sake. VariableSizeCollection and VariableSizeSet, because they'd be This notion in the hierarchy, you have to add two new interfaces: They implement most of the List operations, but not Now can you do away with UnsupportedOperationException? UnfortunatelyĬonsider arrays. Unmodifiable Collections, that does not contain the remove operation. Also, you need a new Iterator interface for use with What was previously a simple hierarchy is now a messy Interfaces: ModifiableCollection, ModifiableSet, ModifiableList, and Notion of modifiability to the Hierarchy. To illustrate the problem in gory detail, suppose you want to add the From the Java Collections API Design FAQ: This was to avoid the combinatorial explosion that would result from fine-grained interfaces. When designing the Collections API Joshua Bloch decided that instead of having very fine-grained interfaces to distinguish between different variants of collections (eg: readable, writable, random-access, etc.) he'd only have very coarse set of interfaces, primarilyĬollection, List, Set and Map, and then document certain operations as "optional". If you don't do what the contract says then you'll have an implementation of the interface as far as the compiler is concerned, but it will be a defective/invalid implementation. You need to read the docs, and do what they say. Well written interfaces will include documentation explaining exactly what is expected from implementations. That is, does the implementation do what the documentation in the interface says it should? This pretty much just boils down to: is there some implementation for each of the methods?Īctually fulfilling the contract. It's important to realize that there are sort of two levels of conforming to an interface: To say "Collections are an exception" suggests a very fuzzy understanding of what's really going on here. The Java language requires that every method in an interface is implemented by every implementation of that interface. There seems to be an awful lot of confusion in the answers here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |