23.11.2014 Views

Data Structures and Algorithms in Java[1].pdf - Fulvio Frisone

Data Structures and Algorithms in Java[1].pdf - Fulvio Frisone

Data Structures and Algorithms in Java[1].pdf - Fulvio Frisone

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

package <strong>in</strong>cludes a similar Entry <strong>in</strong>terface, by the way). Other k<strong>in</strong>ds of<br />

compositions <strong>in</strong>clude triples, which store three objects, quadruples, which store<br />

four objects, <strong>and</strong> so on.<br />

Code Fragment 8.1: <strong>Java</strong> <strong>in</strong>terface for an entry<br />

stor<strong>in</strong>g key-value pairs <strong>in</strong> a priority queue.<br />

Comparators<br />

Another important issue <strong>in</strong> the priority queue ADT that we need to def<strong>in</strong>e is how<br />

to specify the total order relation for compar<strong>in</strong>g keys. We have a number of<br />

design choices concern<strong>in</strong>g how to compare keys that we can make at this po<strong>in</strong>t.<br />

One possibility, <strong>and</strong> the one that is the most concrete, is to implement a different<br />

priority queue for each key type we want to use <strong>and</strong> each possible way of<br />

compar<strong>in</strong>g keys of such types. The problem with this approach is that it is not<br />

very general <strong>and</strong> it requires that we create a lot of similar code.<br />

An alternative strategy is to require that keys be able to compare themselves to<br />

one another. This solution allows us to write a general priority queue class that<br />

can store <strong>in</strong>stances of a key class that implements some k<strong>in</strong>d of Comparable<br />

<strong>in</strong>terface <strong>and</strong> encapsulates all the usual comparison methods. This solution is an<br />

improvement over the specialized approach, for it allows us to write a s<strong>in</strong>gle<br />

priority queue class that can h<strong>and</strong>le lots of different types of keys. But there are<br />

contexts <strong>in</strong> which this solution is ask<strong>in</strong>g too much of the keys, as keys often do<br />

not "know" how they ought to be compared. Two examples follow.<br />

Example 8.2: Given keys 4 <strong>and</strong> 11 we have that 4 ≤ 11 if the keys are <strong>in</strong>teger<br />

objects (to be compared <strong>in</strong> the usual manner), but 11 ≤ 4 if the keys are str<strong>in</strong>g<br />

objects (to be compared lexicographically).<br />

Example 8.3: A geometric algorithm may compare po<strong>in</strong>ts p <strong>and</strong> q <strong>in</strong> the<br />

plane, by their x-coord<strong>in</strong>ate (that is, p ≤q ifx(p) ≤ x(q)), to sort them from left to<br />

right, while another algorithm may compare them by their y-coord<strong>in</strong>ate (that is, p<br />

≤ q ify(p) ≤ y(q)), to sort them from bottom to top. In pr<strong>in</strong>ciple, there is noth<strong>in</strong>g<br />

perta<strong>in</strong><strong>in</strong>g to the concept of a po<strong>in</strong>t that says whether po<strong>in</strong>ts should be compared<br />

453

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!