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.

6.2 Node Lists<br />

Us<strong>in</strong>g an <strong>in</strong>dex is not the only means of referr<strong>in</strong>g to the place where an element<br />

appears <strong>in</strong> a sequence. If we have a sequence S implemented with a (s<strong>in</strong>gly or doubly)<br />

l<strong>in</strong>ked list, then it could possibly be more natural <strong>and</strong> efficient to use a node <strong>in</strong>stead<br />

of an <strong>in</strong>dex as a means of identify<strong>in</strong>g where to access <strong>and</strong> update S. In this section, we<br />

def<strong>in</strong>e the node list ADT, which abstracts the concrete l<strong>in</strong>ked list data structure<br />

(Sections 3.2 <strong>and</strong> 3.3) us<strong>in</strong>g a related position ADT that abstracts the notion of<br />

"place" <strong>in</strong> a node list.<br />

6.2.1 Node-Based Operations<br />

Let S be a (s<strong>in</strong>gly or doubly) l<strong>in</strong>ked list. We would like to def<strong>in</strong>e methods for S that<br />

take nodes as parameters <strong>and</strong> provide nodes as return types. Such methods could<br />

provide significant speedups over <strong>in</strong>dex-based methods, because f<strong>in</strong>d<strong>in</strong>g the <strong>in</strong>dex<br />

of an element <strong>in</strong> a l<strong>in</strong>ked list requires search<strong>in</strong>g through the list <strong>in</strong>crementally from<br />

its beg<strong>in</strong>n<strong>in</strong>g or end, count<strong>in</strong>g elements as we go.<br />

For <strong>in</strong>stance, we could def<strong>in</strong>e a hypothetical method remove(v) that removes the<br />

element of S stored at node v of the list. Us<strong>in</strong>g a node as a parameter allows us to<br />

remove an element <strong>in</strong> O(1) time by simply go<strong>in</strong>g directly to the place where that<br />

node is stored <strong>and</strong> then "l<strong>in</strong>k<strong>in</strong>g out" this node through an update of the next <strong>and</strong><br />

prev l<strong>in</strong>ks of its neighbors. Similarly, we could <strong>in</strong>sert, <strong>in</strong> O(1) time, a new element e<br />

<strong>in</strong>to S with an operation such as addAfter(v, e), which specifies the node v<br />

after which the node of the new element should be <strong>in</strong>serted. In this case, we simply<br />

"l<strong>in</strong>k <strong>in</strong>" the new node.<br />

Def<strong>in</strong><strong>in</strong>g methods of a list ADT by add<strong>in</strong>g such node-based operations raises the<br />

issue of how much <strong>in</strong>formation we should be expos<strong>in</strong>g about the implementation of<br />

our list. Certa<strong>in</strong>ly, it is desirable for us to be able to use either a s<strong>in</strong>gly or doubly<br />

326

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

Saved successfully!

Ooh no, something went wrong!