Java集合框架官方教程(3)：SortedSet/SortedMap接口

Object Ordering

A

List

l

may be sorted as follows.

Collections.sort(l);

If the

List

consists of

String

elements, it will be sorted into alphabetical order. If it consists of

Date

elements, it will be sorted into chronological order. How does this happen?

String

and

Date

both implement the

Comparable

interface.

Comparable

implementations provide a natural ordering for a class, which allows objects of that class to be sorted automatically.The following table summarizes some of the more important Java platform classes that implement

Comparable

.

Classes ImplementingComparable

Class	Natural Ordering
Byte	Signed numerical
Character	Unsigned numerical
Long	Signed numerical
Integer	Signed numerical
Short	Signed numerical
Double	Signed numerical
Float	Signed numerical
BigInteger	Signed numerical
BigDecimal	Signed numerical
Boolean	Boolean.FALSE < Boolean.TRUE
File	System-dependent lexicographic on path name
String	Lexicographic
Date	Chronological
CollationKey	Locale-specific lexicographic

If you try to sort a list, the elements of which do not implement

Comparable

,

Collections.sort(list)

will throw a

ClassCastException

. Similarly,

Collections.sort(list,comparator)

will throw a

ClassCastException

if you try to sort a list whose elements cannot becompared to one another using the

comparator

. Elements that can becompared to one another are called mutually comparable. Although elements of different types may be mutually comparable, none of the classes listed here permit interclass comparison.

This is all you really need to know about the

Comparable

interface if you just want to sort lists of comparable elements or to create sorted collections of them. The next section will be of interest to you if you want to implement your own

Comparable

type.

Writing Your OwnComparable Types

The

Comparable

interface consists of the following method.

public interfaceComparable<T> {
public intcompareTo(T o);
}

The

compareTo

methodcompares the receiving object with the specified object andreturns a negative integer, 0, or a positive integer depending on whether the receiving object is less than, equal to, or greater than the specified object. If the specified object cannot becompared to the receiving object, the method throws a

ClassCastException

.

The

following class representing a person's name

implements

Comparable

.

import java.util.*;

public className implementsComparable<Name> {
private finalString firstName, lastName;

publicName(String firstName,String lastName) {
if (firstName == null || lastName == null)
throw new NullPointerException();
this.firstName = firstName;
this.lastName = lastName;
}

publicString firstName() {return firstName; }
publicString lastName()  {return lastName;  }

public boolean equals(Object o) {
if (!(o instanceofName))
return false;
Name n = (Name) o;
return n.firstName.equals(firstName) && n.lastName.equals(lastName);
}

public int hashCode() {
return 31*firstName.hashCode() + lastName.hashCode();
}

publicStringtoString() {
return firstName + " " + lastName;
}

public intcompareTo(Name n) {
int lastCmp = lastName.compareTo(n.lastName);
return (lastCmp != 0 ? lastCmp : firstName.compareTo(n.firstName));
}
}

To keep the preceding example short, the class is somewhat limited: It doesn't support middle names, it demands both a first and a last name, and it is not internationalized in any way. Nonetheless, it illustrates the following important points:

Name

objects are immutable. All other things being equal,immutable types are the way to go, especially for objects that will be used as elements in

Set

s or as keys in

Map

s. These collections will break if you modify their elements or keys while they're in the collection.

The constructor checks its arguments for

null

. This ensures that all

Name

objects are well formed so that none of the other methods will ever throw a

NullPointerException

.

The

hashCode

method is redefined. This is essential for any class that redefines the

equals

method. (Equal objects must have equal hash codes.)

The

equals

methodreturns

false

if the specified object is

null

or of an inappropriate type. The

compareTo

method throws a runtime exception under these circumstances. Both of these behaviors are required by the general contracts of the respective methods.

The

toString

method has been redefined so it prints the

Name

in human-readable form. This is always a good idea, especially for objects that are going to get put into collections. The various collection types'

toString

methods depend on the

toString

methods of their elements, keys, and values.

Since this section is about element ordering, let's talk a bit more about

Name

's

compareTo

method. It implements the standard name-ordering algorithm, where last names take precedence over first names. This is exactly what you want in a natural ordering. It would be very confusing indeed if the natural ordering were unnatural!

Take a look at how

compareTo

is implemented, because it's quite typical.First, youcompare the most significant part of the object(in this case, the last name). Often, you can just use the natural ordering of the part's type. In this case, the part is a

String

and the natural (lexicographic) ordering is exactly what's called for. If the comparison results in anything other than zero, which represents equality, you're done: You justreturn the result. If the most significant parts are equal, you go on tocompare the next most-significant parts. In this case, there are only two parts — first name and last name. If there were more parts, you'd proceed in the obvious fashion, comparing parts until you found two that weren't equal or you were comparing the least-significant parts, at which point you'dreturn the result of the comparison.

Just to show that it all works, here's

a program that builds a list of names and sorts them

.

import java.util.*;

public classNameSort {
public static void main(String[] args) {
Name nameArray[] = {
newName("John", "Smith"),
newName("Karl", "Ng"),
newName("Jeff", "Smith"),
newName("Tom", "Rich")
};

List<Name> names = Arrays.asList(nameArray);
Collections.sort(names);
System.out.println(names);
}
}

If you run this program, here's what it prints.

[Karl Ng, Tom Rich, Jeff Smith, John Smith]

There are four restrictions on the behavior of the

compareTo

method, which we won't go into now because they're fairly technical and boring and are better left in the API documentation. It's really important that all classes that implement

Comparable

obey these restrictions, so read the documentation for

Comparable

if you're writing a class that implements it. Attempting to sort a list of objects that violate the restrictions has undefined behavior. Technically speaking, these restrictions ensure that the natural ordering is atotal order on the objects of a class that implements it; this is necessary to ensure that sorting is well defined.

Comparators

What if you want to sort some objects in an order other than their natural ordering? Or what if you want to sort some objects that don't implement

Comparable

? To do either of these things, you'll need to provide a

Comparator

— an object that encapsulates an ordering. Like the

Comparable

interface, the

Comparator

interface consists of a single method.

public interfaceComparator<T> {
intcompare(T o1, T o2);
}

The

compare

methodcompares its two arguments,returning a negative integer, 0, or a positive integer depending on whether the first argument is less than, equal to, or greater than the second. If either of the arguments has an inappropriate type for the

Comparator

, the

compare

method throws a

ClassCastException

.

Much of what was said about

Comparable

applies to

Comparator

as well.Writing a

compare

method is nearly identical to writing a

compareTo

method, except that the former gets both objects passed in as arguments. The

compare

method has to obey the same four technical restrictions as

Comparable

's

compareTo

method for the same reason — a

Comparator

must induce a total order on the objects itcompares.

Suppose you have a class called

Employee

, as follows.

public class Employee implementsComparable<Employee> {
publicName name()     { ... }
public int number()    { ... }
publicDate hireDate() { ... }
...
}

Let's assume that the natural ordering of

Employee

instances is

Name

ordering (as defined in the previous example) on employee name. Unfortunately, the boss has asked for a list of employees in order of seniority. This means we have to do some work, but not much. The following program will produce the required list.

import java.util.*;
public class EmpSort {
static finalComparator<Employee> SENIORITY_ORDER =
newComparator<Employee>() {
public intcompare(Employee e1, Employee e2) {
return e2.hireDate().compareTo(e1.hireDate());
}
};

// Employee database
static final Collection<Employee> employees = ... ;

public static void main(String[] args) {
List<Employee> e = new ArrayList<Employee>(employees);
Collections.sort(e, SENIORITY_ORDER);
System.out.println(e);
}
}

The

Comparator

in the program is reasonably straightforward. It relies on the natural ordering of

Date

applied to the valuesreturned by the

hireDate

accessor method. Note that the

Comparator

passes the hire date of its second argument to its first rather than vice versa.
The reason is that the employee who was hired most recently is the least senior; sorting in the order of hire date would put the list in reverse seniority order. Another technique people sometimes use to achieve this effect is to maintain the argument order but to negate the result of the comparison.

// Don't do this!!
return -r1.hireDate().compareTo(r2.hireDate());

You should always use the former technique in favor of the latter because the latter is not guaranteed to work. The reason for this is that the

compareTo

method canreturn any negative

int

if its argument is less than the object on which it is invoked. There is one negative

int

that remains negative when negated, strange as it may seem.

-Integer.MIN_VALUE == Integer.MIN_VALUE

The

Comparator

in the preceding program works fine for sorting a

List

, but it does have one deficiency: It cannot be used to order a sorted collection, such as

TreeSet

, because it generates an ordering that isnot compatible with equals. This means that this

Comparator

equates objects that the

equals

method does not. In particular, any two employees who were hired on the same date willcompare as equal. When you're sorting a

List

, this doesn't matter; but when you're using the

Comparator

to order a sorted collection, it's fatal. If you use this

Comparator

to insert multiple employees hired on the same date into a

TreeSet

, only the first one will be added to the set; the second will be seen as a duplicate element and will be ignored.

To fix this problem, simply tweak the

Comparator

so that it produces an ordering thatis compatible with

equals

. In other words, tweak it so that the only elements seen as equal when using

compare

are those that are also seen as equal whencompared using

equals

. The way to do this is to perform a two-part comparison (as for

Name

), where the first part is the one we're interested in — in this case, the hire date — and the second part is an attribute that uniquely identifies the object. Here the employee number is the obvious attribute. This is the

Comparator

that results.

static finalComparator<Employee> SENIORITY_ORDER =
newComparator<Employee>() {
public intcompare(Employee e1, Employee e2) {
int dateCmp = e2.hireDate().compareTo(e1.hireDate());
if (dateCmp != 0)
return dateCmp;

return (e1.number() < e2.number() ? -1 :
(e1.number() == e2.number() ? 0 : 1));
}
};

One last note: You might be tempted to replace the final

return

statement in the

Comparator

with the simpler:

return e1.number() - e2.number();

Don't do it unless you're
absolutely sure no one will ever have a negative employee number!
This trick does not work in general because the signed integer type is not big enough to represent the difference of two arbitrary signed integers. If

i

is a large positive integer and

j

is a large negative integer,

i - j

will overflow and willreturn a negative integer. The resulting

comparator

violates one of the four technical restrictions we keep talking about (transitivity) and produces horrible, subtle bugs. This is not a purely theoretical concern; people get burned by it.

The SortedSet Interface

A

SortedSet

is a

Set

that maintains its elements in ascending order, sorted according to the elements' natural ordering or according to a

Comparator

provided at

SortedSet

creation time. In addition to the normal

Set

operations, the

SortedSet

interface provides operations for the following:

Range view

— allows arbitrary range operations on the sorted set

Endpoints

—returns the first or last element in the sorted set

Comparator access

—returns the

Comparator

, if any, used to sort the set

The code for the

SortedSet

interface follows.

public interface SortedSet<E> extends Set<E> {
// Range-view
SortedSet<E>subSet(E fromElement, E toElement);
SortedSet<E> headSet(E toElement);
SortedSet<E> tailSet(E fromElement);

// Endpoints
E first();
E last();

//Comparator access
Comparator<? super E>comparator();
}

Set Operations

The operations that

SortedSet

inherits from

Set

behave identically on sorted sets and normal sets with two exceptions:

The

Iterator

returned by the

iterator

operation traverses the sorted set in order.

The arrayreturned by

toArray

contains the sorted set's elements in order.

Although the interface doesn't guarantee it, the

toString

method of the Java platform's

SortedSet

implementationsreturns a string containing all the elements of the sorted set, in order.

Standard Constructors

By convention, all general-purpose

Collection

implementations provide a standard conversion constructor that takes a

Collection

;

SortedSet

implementations are no exception. In

TreeSet

, this constructor creates an instance that sorts its elements according to their natural ordering. This was probably a mistake. It would have been better to check dynamically to see whether the specified collection was a

SortedSet

instance and, if so, to sort the new

TreeSet

according to the same criterion (comparator or natural ordering).Because

TreeSet

took the approach that it did, it also provides a constructor that takes a

SortedSet

andreturns a new

TreeSet

containing the same elements sorted according to the same criterion. Note that it is the compile-time type of the argument, not its runtime type, that determines which of these two constructors is invoked (and whether the sorting criterion is preserved).

SortedSet

implementations also provide, by convention, a constructor that takes a

Comparator

andreturns an empty set sorted according to the specified

Comparator

. If

null

is passed to this constructor, itreturns a set that sorts its elements according to their natural ordering.

Range-view Operations

The

range-view

operations are somewhat analogous to those provided by the

List

interface, but there is one big difference. Range views of a sorted set remain valid even if the backing sorted set is modified directly. This is feasible because the endpoints of a range view of a sorted set are absolute points in the element space rather than specific elements in the backing collection, as is the case for lists. A

range-view

of a sorted set is really just a window onto whatever portion of the set lies in the designated part of the element space. Changes to the

range-view

write back to the backing sorted set and vice versa. Thus, it's okay to use

range-view

s on sorted sets for long periods of time, unlike

range-view

s on lists.

Sorted sets provide three

range-view

operations. The first,

subSet

, takes two endpoints, like

subList

. Rather than indices, the endpoints are objects and must be comparable to the elements in the sorted set, using the

Set

's

Comparator

or the natural ordering of its elements, whichever the

Set

uses to order itself. Like

subList

, the range is half open, including its low endpoint but excluding the high one.

Thus, the following line of code tells you how many words between

"doorbell"

and

"pickle"

, including

"doorbell"

but excluding

"pickle"

, are contained in a

SortedSet

of strings called

dictionary

:

int count = dictionary.subSet("doorbell", "pickle").size();

In like manner, the following one-liner removes all the elements beginning with the letter

f

.

dictionary.subSet("f", "g").clear();

A similar trick can be used to print a table telling you how many words begin with each letter.

for (char ch = 'a'; ch <= 'z'; ) {
String from =String.valueOf(ch++);
String to =String.valueOf(ch);
System.out.println(from + ": " + dictionary.subSet(from, to).size());
}

Suppose you want to view a closed interval, which contains both of its endpoints, instead of an open interval. If the element type allows for the calculation of the successor of a given value in the element space, merely request the

subSet

from

lowEndpoint

to

successor(highEndpoint)

. Although it isn't entirely obvious, the successor of a string

s

in

String

's natural ordering is

s + "\0"

— that is,

s

with a

null

character appended.

Thus, the following one-liner tells you how many words between

"doorbell"

and

"pickle"

, including doorbell and pickle, are contained in the dictionary.

count = dictionary.subSet("doorbell", "pickle\0").size();

A similar technique can be used to view an
open interval, which contains neither endpoint. The open-interval view from

lowEndpoint

to

highEndpoint

is the half-open interval from

successor(lowEndpoint)

to

highEndpoint

. Use the following to calculate the number of words between

"doorbell"

and

"pickle"

, excluding both.

count = dictionary.subSet("doorbell\0", "pickle").size();

The

SortedSet

interface contains two more

range-view

operations —

headSet

and

tailSet

, both of which take a single

Object

argument. The formerreturns a view of the initial portion of the backing

SortedSet

, up to but not including the specified object. The latterreturns a view of the final portion of the backing

SortedSet

, beginning with the specified object and continuing to the end of the backing

SortedSet

. Thus, the following code allows you to view the dictionary as two disjoint

volumes

(

a-m

and

n-z

).

SortedSet<String> volume1 = dictionary.headSet("n");
SortedSet<String> volume2 = dictionary.tailSet("n");

Endpoint Operations

The

SortedSet

interface contains operations toreturn the first and last elements in the sorted set, not surprisingly called

first

and

last

. In addition to their obvious uses,

last

allows a workaround for a deficiency in the

SortedSet

interface. One thing you'd like to do with a

SortedSet

is to go into the interior of the

Set

and iterate forward or backward. It's easy enough to go forward from the interior: Just get a

tailSet

and iterate over it. Unfortunately, there's no easy way to go backward.

The following idiom obtains the first element that is less than a specified object

o

in the element space.

Object predecessor = ss.headSet(o).last();

This is a fine way to go one element backward from a point in the interior of a sorted set. It could be applied repeatedly to iterate backward, but this is very inefficient, requiring a lookup for each elementreturned.

Comparator Accessor

The

SortedSet

interface contains an accessor method called

comparator

thatreturns the

Comparator

used to sort the set, or

null

if the set is sorted according to the natural ordering of its elements. This method is provided so that sorted sets can be copied into new sorted sets with the same ordering. It is used by the

SortedSet

constructor described previously.

The SortedMap Interface

A

SortedMap

is a

Map

that maintains its entries in ascending order, sorted according to the keys' natural ordering, or according to a

Comparator

provided at the time of the

SortedMap

creation. Natural ordering and

Comparator

s are discussed in the Object Ordering section. The

SortedMap

interface provides operations for normal

Map

operations and for the following:

Range view

— performs arbitrary range operations on the sorted map

Endpoints

—returns the first or the last key in the sorted map

Comparator access

—returns the

Comparator

, if any, used to sort the map

The following interface is the

Map

analog of

SortedSet

.

public interface SortedMap<K, V> extends Map<K, V>{
Comparator<? super K>comparator();
SortedMap<K, V> subMap(K fromKey, K toKey);
SortedMap<K, V> headMap(K toKey);
SortedMap<K, V> tailMap(K fromKey);
K firstKey();
K lastKey();
}

Map Operations

The operations

SortedMap

inherits from

Map

behave identically on sorted maps and normal maps with two exceptions:

The

Iterator

returned by the

iterator

operation on any of the sorted map's

Collection

views traverse the collections in order.

The arraysreturned by the

Collection

views'

toArray

operations contain the keys, values, or entries in order.

Although it isn't guaranteed by the interface, the

toString

method of the

Collection

views in all the Java platform's

SortedMap

implementationsreturns a string containing all the elements of the view, in order.

Standard Constructors

By convention, all general-purpose

Map

implementations provide a standard conversion constructor that takes a

Map

;

SortedMap

implementations are no exception. In

TreeMap

, this constructor creates an instance that orders its entries according to their keys' natural ordering. This was probably a mistake. It would have been better to check dynamically to see whether the specified

Map

instance was a

SortedMap

and, if so, to sort the new map according to the same criterion (comparator or natural ordering).Because

TreeMap

took the approach it did, it also provides a constructor that takes a

SortedMap

andreturns a new

TreeMap

containing the same mappings as the given

SortedMap

, sorted according to the same criterion. Note that it is the compile-time type of the argument, not its runtime type, that determines whether the

SortedMap

constructor is invoked in preference to the ordinary

map

constructor.

SortedMap

implementations also provide, by convention, a constructor that takes a

Comparator

andreturns an empty map sorted according to the specified

Comparator

. If

null

is passed to this constructor, itreturns a

Map

that sorts its mappings according to their keys' natural ordering.

Comparison to SortedSet

Because this interface is a precise

Map

analog of

SortedSet

, all the idioms and code examples inThe SortedSet Interface section apply to

SortedMap

with only trivial modifications.

Summary of Interfaces

The core collection interfaces are the foundation of the Java Collections Framework.

The Java Collections Framework hierarchy consists of two distinct interface trees:

The first tree starts with the

Collection

interface, which provides for the basic functionality used by all collections, such as

add

and

remove

methods. Its subinterfaces —

Set

,

List

, and

Queue

— provide for more specialized collections.

The

Set

interface does not allow duplicate elements. This can be useful for storing collections such as a deck of cards or student records. The

Set

interface has a subinterface,

SortedSet

, that provides for ordering of elements in the set.

The

List

interface provides for an ordered collection, for situations in which you need precise control over where each element is inserted. You can retrieve elements from a

List

by their exact position.

The

Queue

interface enables additional insertion, extraction, and inspection operations. Elements in a

Queue

are typically ordered in on a FIFO basis.

The

Deque

interface enables insertion, deletion, and inspection operations at both the ends. Elements in a

Deque

can be used in both LIFO and FIFO.

The second tree starts with the

Map

interface, which maps keys and values similar to a

Hashtable

.

Map

's subinterface,

SortedMap

, maintains its key-value pairs in ascending order or in an order specified by a

Comparator

.

These interfaces allow collections to be manipulated independently of the details of their representation.

Answers to Questions and Exercises:

Questions

Question: At the beginning of this lesson, you learned that the core collection interfaces are organized into two distinctinheritance trees. One interface in particular is not considered to bea true

Collection

, and therefore sits at the top of its own tree. What is the nameof this interface?
Answer:

Map

Question: Each interface in the collections framework is declaredwith the

<E>

syntax, which tells you that it isgeneric. When you declare a

Collection

instance, what isthe advantage of specifying the type of objects that it will contain?
Answer: Specifying the type allows the compiler to verify (at compile time) that the type of object you put into the collection is correct, thus reducing errors at runtime.

Question: What interface represents a collection that does not allow duplicate elements?
Answer:

Set

Question: What interface forms the root of the collections hierarchy?
Answer:

Collection

Question: What interface represents an ordered collection that may contain duplicate elements?
Answer:

List

Question: What interface represents a collection that holds elements prior to processing?
Answer:

Queue

Question: What interface represents a type that maps keys to values?
Answer:

Map

Question: What interface represents a double-ended queue?
Answer:

Deque

Question:Name three different ways to iterate over the elements of a

List

.
Answer: You can iterate over a

List

using streams, the enhanced

for

statement, or iterators.

Question: True or False: Aggregate operations are mutative operations that modify the underlying collection.
Answer: False. Aggregate operations do not mutate the underlying collection. In fact, you must be careful to never mutate a collection while invoking its aggregate operations.Doing so could lead to concurrency problems should the stream be changed to a parallel stream at some point in the future.

Exercises

Exercise: Write a program that prints its arguments in random order. Do not make a copy of the argument array. Demonstrate how to print out the elements using both streams and the traditional enhanced for statement.
Answer:

import java.util.*;

public class Ran {

public static void main(String[] args) {

// Get and shuffle the list of arguments
List<String> argList = Arrays.asList(args);
Collections.shuffle(argList);

// Print out the elements using JDK 8 Streams
argList.stream()
.forEach(e->System.out.format("%s ",e));

// Print out the elements using for-each
for (String arg: argList) {
System.out.format("%s ", arg);
}

System.out.println();
}
}

Exercise: Take the

FindDups

example and modify it to use a

SortedSet

instead of a

Set

. Specify a

Comparator

so that case is ignored when sorting and identifying set elements.
Answer:

import java.util.*;

public class FindDups {
public static void main(String[] args) {
Set<String> s = new HashSet<String>();
for (String a : args)
s.add(a);
System.out.println(s.size() + " distinct words: " + s);
}
}

Exercise: Write a method that takes a

List<String>

and applies

String.trim

to each element.
Answer:
The enhanced

for

statement does not allow you to modify the

List

. Using an instance of the

Iterator

class allows you to delete elements, but not replace an existing element or add a new one. That leaves

ListIterator

:

import java.util.*;

public class ListTrim {
static void listTrim(List<String> strings) {
for (ListIterator<String> lit = strings.listIterator(); lit.hasNext(); ) {
lit.set(lit.next().trim());
}
}

public static void main(String[] args) {
List<String> l = Arrays.asList(" red ", " white ", " blue ");
listTrim(l);
for (String s : l) {
System.out.format("\"%s\"%n", s);
}
}
}

Exercise: Consider the four core interfaces,

Set

,

List

,

Queue

, and

Map

.For each of the following four assignments, specify which of the four core interfaces is best-suited, and explain how to use it to implement the assignment.
Answers:

Whimsical Toys Inc (WTI) needs to record the names of all its employees. Every month, an employee will be chosen at random from these records to receive a free toy.
Use a

List

. Choose a random employee by picking a number between

0

and

size()-1

.

WTI has decided that each new product will be named after an employee — but only first names will be used, and each name will be used only once. Prepare a list of unique first names.
Use a

Set

. Collections that implement this interface don't allow the same element to be entered more than once.

WTI decides that it only wants to use the most popular names for its toys. Count up the number of employees who have each first name.
Use a

Map

, where the keys are first names, and each value is a count of the number of employees with that first name.

WTI acquires season tickets for the local lacrosse team, to be shared by employees. Create a waiting list for this popular sport.
Use a

Queue

. Invoke

add()

to add employees to the waiting list, and

remove()

to remove them.

Original:
http://docs.oracle.com/javase/tutorial/collections/interfaces/order.html