Let s start by recalling what a list is and considering the implementation we have already.

Transcription

1 Here we look at the other major implementation of a list, the linked list. This is the data structure that underlies java.util.linkedlist. We will look at a simplified implementation, SimpleLinkedList. CSC 143, Spr '06 1

2 Let s start by recalling what a list is and considering the implementation we have already. CSC 143, Spr '06 2

3 There is a single List interface, with two implementations: SimpleArrayList and SimpleLinkedList. Since they share a common interface, the two types are the same from an external point of view. Abstraction happening here. However, as we will see, the two types are radically different from an internal point of view. Notice the structural difference. As we have seen, the array-based list needs the elements of the list to be contiguous. That is, the elements have an interdependence in locality. In this new structure, the connection between the elements is not based on adjacency. Instead, they are more independent with the connection between the elements moderated by links. CSC 143, Spr '06 3

4 In discussing the concept of linked list, we re going to use a number of images in these slides. I cannot stress enough how much pictures are going to help. Drawing this stuff out will help you visualize these concepts, paper and pencil on the back of an envelope rather than making something pretty using graphics software. The goal is understanding. In fact, as you work through implementation issues with these linked structures, draw them. Every step of the process, draw it. This may seem like overkill, but it s not. Also, drawing linked lists and talking about them is a favorite sort of technical interview question. CSC 143, Spr '06 4

5 The drawings could use boxes and arrows. In fact, that s very common. These little jaggedy clouds are too hard to draw to be practical. (I think Hal used the shape as a compromise. Commonly, these napkin drawings use a cloud to represent something that is as of yet undetermined. Drawing cloud shapes in PowerPoint is just painful, but they have these stars are stock images.) Notice that the actual data that is being linked together is separate. It s represented by the goldenrod shapes. The linked list is the backbone of the structure, composed of the cyan links. In fact, in drawing this, the data is often omitted! Very important note: See the title of the slide. We don t have the list yet, just a bunch of connected links. CSC 143, Spr '06 5

6 Here is the simplest version of a linked list. Notice that there are two structural types: List and Link. The data type is separate. This is analogous to the separate ArrayList type that we had in the previous discusson. CSC 143, Spr '06 6

7 Time to make the clouds less cloudy. This is a typical Java implementation. Yes, the spiky things really are supposed to be clouds, representing a tbd object type. CSC 143, Spr '06 7

8 Here s a constructor for Link. Like all good constructors, it explicitly sets the values for the fields. CSC 143, Spr '06 8

9 We re going to be doing a bunch of drawing here. It may seem goofy, but I strongly, strongly encourage you to draw this stuff. It s not going to be great art. In fact, you should make these drawing as quick and easy as possible. You can do this on scratch paper that you re going to throw away. It doesn t need to be in your notes, really. Why? Well, because once you get the hang of the idea, you most probably won t need to refer back to these drawing to understand the concept again, that is, how this works. For this piece, don t worry about the code that would build this set of three links. We ll get back to that later. CSC 143, Spr '06 9

10 Now that you have the drawing yes, if you didn t do it, draw it now. Now that you have the drawing, sketch in how you would insert wolf into the list. When you know what that would look like, write the code to make this happen. Remember, the only variable that we are guaranteed is Link head; If you think of this as a single use method, you can create local variables if you need them. But, we don t have any direct references to the links for lion and tiger and bear oh my! [fodder: source? The actual text would be, Lions and tigers and bears, oh my! ] CSC 143, Spr '06 10

11 More drawing. Once again, the only stable variable is Link head; CSC 143, Spr '06 11

12 Now, let s write some code to modify the structure. Remember, you must start this code from head. CSC 143, Spr '06 12

13 What we have just done is emulate the internal view of SimpleLinkedList. This object maintains a Link to the first element in the list. CSC 143, Spr '06 13

14 And a constructor. The list starts out empty. CSC 143, Spr '06 14

15 Notice: no Links! The Link data type is an internal (implementation) detail, not part of the abstraction (external view). CSC 143, Spr '06 15

16 Draw the picture. Yes, there are problems with this implementation, which is why it s the first try. However, it should work well enough for adding to the end of an existing list. CSC 143, Spr '06 16

17 Math purists are permitted to shudder. The English majors as well. ( vertexes??? Shouldn t that be vertices!?!) Can you see what the problems are? (Note use of plural.) CSC 143, Spr '06 17

18 How many of you found the problems? This is why you need to draw these things and then be as rigid as the computer will be in following your instructions. Also, notice that this is a prime example of an error occurring at a boundary. CSC 143, Spr '06 18

19 CSC 143, Spr '06 19

20 Let s address the first issue, the one about how inefficient the naïve add is by adding another field to SimpleLinkedList. We ll see how this can speed up processing. CSC 143, Spr '06 20

21 Do some examples of how lists get created and updated. CSC 143, Spr '06 21

22 Now, here it is in code. Notice that adding the second field removed the need to cycle through the list to find the end. At the same time, adding more fields increased the housekeeping overhead of SimpleLinkedList. This is a common trade-off. Needless to say, every operation that changes the state of the list needs to be concerned about maintaining these two fields. (Therein lies the housekeeping overhead.) CSC 143, Spr '06 22

23 Given the current implementation of SimpleLinkedList, how would this method be implemented? Very slow! CSC 143, Spr '06 23

24 Problem: Every list operation that adds or removes elements must remember to update the size field. Easy to forget. An invariant can be used here. In fact, this would be a common place to use the assert statement. Once again, the more fields we have describing the list, the more housekeeping we need to do to keep everything in sync. CSC 143, Spr '06 24

25 Nice it s simple. But, even as simple as it is, it still needs to update all three fields, since it changes the state of the object. CSC 143, Spr '06 25

26 Compare this to the get method in SimpleArrayList. The precondition checking is analogous. In fact, it would be the same if the field was named numelems rather than numlinks. Why? This precondition is based on fundamental list-iness. It could (should) be included in a description of this method at the interface level. SimpleArrayList.get was a very quick operation. Just jump into the middle of the array and nab the value. Here in SimpleLinkedList.get, we need to navigate through the links to arrive at the appropriate location. Clearly, we don't use LinkedLists if this happens a lot. More about this later. You might be wondering if we couldn t keep track of known places in the list you know, more fields in SimpleLinkedList, say for every thousandth element. We could, but that would be more overhead. Way more overhead. CSC 143, Spr '06 26

27 Besides how will we know how many of these intermediate points will be needed well, we could keep track of them in a list yes, we just fell down the rabbit hole with Alice. CSC 143, Spr '06 26

28 Now, here is where the linked list shines. Adding and removing at a location in the middle of the list. The update piece is trivial, once we are at the correct location. CSC 143, Spr '06 27

29 What s happening here? Refactoring. Common functionality is pulled out of separate methods and implemented once. Notice the question at the bottom of the slide. This is an important question. <spoiler space> <spoiler space> <spoiler space> CSC 143, Spr '06 28

30 The get method of List returns the data type, probably the generic formal type E. This method messes around with the internal structure of the linked list and returns the package private type Link. CSC 143, Spr '06 28

31 A few things to note: There is a good deal of special case code written for the boundaries. To remove a Link, we need to have the previous Link. The next field of that Link object (the previous one) needs to be updated. This is the root of some of the boundary special processing. CSC 143, Spr '06 29

32 Once again, we need to have access to the previous link. This might prompt you to suggest updating the Link data type to include another field, Link previous; This is actually a great idea. It creates a related data structure called a doublylinked list. But, yes, it involves more housekeeping. But once you get the code working, it s relatively little overhead to maintain twice as many Link references. They only need to be updated when the contents of the list changes, and then only at the location of the change. CSC 143, Spr '06 30

33 Yes, we can do much better. The SimpleListIterator class maintains the current pos for the Iterator object. This is used in calls to the get method. As we have seen, this is not very efficient for our SimpleLinkedList. However, we could create another inner class for LinkedList that maintains the current Link for the Iterator. What would the implementation of hasnext and next be? Notice how using ListIterator would make add at a location much faster, if this occurred using a ListIterator, rather than the List method. Fortunately, Links and their next field are package private, so we don't have to worry about inner classes etc. to implement this. Now the remove method for Iterator might be a bit trickier unless we had implemented a doubly-linked list. CSC 143, Spr '06 31

34 CSC 143, Spr '06 32