java中接口中的方法,Java接口中的可选方法

To illustrate the problem in gory detail, suppose you want to add the

notion of modifiability to the Hierarchy. You need four new

interfaces: ModifiableCollection, ModifiableSet, ModifiableList, and

ModifiableMap. What was previously a simple hierarchy is now a messy

heterarchy. Also, you need a new Iterator interface for use with

unmodifiable Collections, that does not contain the remove operation.

Now can you do away with UnsupportedOperationException? Unfortunately

not.

Consider arrays. They implement most of the List operations, but not

remove and add. They are “fixed-size” Lists. If you want to capture

this notion in the hierarchy, you have to add two new interfaces:

VariableSizeList and VariableSizeMap. You don’t have to add

VariableSizeCollection and VariableSizeSet, because they’d be

identical to ModifiableCollection and ModifiableSet, but you might

choose to add them anyway for consistency’s sake. Also, you need a new

variety of ListIterator that doesn’t support the add and remove

operations, to go along with unmodifiable List. Now we’re up to ten or

twelve interfaces, plus two new Iterator interfaces, instead of our

original four. Are we done? No.

Consider logs (such as error logs, audit logs and journals for

recoverable data objects). They are natural append-only sequences,

that support all of the List operations except for remove and set

(replace). They require a new core interface, and a new iterator.

And what about immutable Collections, as opposed to unmodifiable ones?

(i.e., Collections that cannot be changed by the client AND will never

change for any other reason). Many argue that this is the most

important distinction of all, because it allows multiple threads to

access a collection concurrently without the need for synchronization.

Adding this support to the type hierarchy requires four more

interfaces.

Now we’re up to twenty or so interfaces and five iterators, and it’s

almost certain that there are still collections arising in practice

that don’t fit cleanly into any of the interfaces. For example, the

collection-views returned by Map are natural delete-only collections.

Also, there are collections that will reject certain elements on the

basis of their value, so we still haven’t done away with runtime

exceptions.

When all was said and done, we felt that it was a sound engineering

compromise to sidestep the whole issue by providing a very small set

of core interfaces that can throw a runtime exception.