Lab Assignment 1 is due next Wednesday, April 16. Your section leader will be discussing this lab assignment in detail in this week's section. Although attending your section is optional, I highly recommend showing up this week. The hour you spend in section will save you more than an hour later in the week.
In a previous lecture we used an interface to allow ourselves to define a variable declared to be a reference to a GeomShape. In fact, GeomShape was an interface, and the way we implemented the program, the variable was actually a reference to either a Circle or a Rectangle object. We can accomplish the same thing via inheritance and avoid duplicating code in the process.
Consider geometric shapes: circles, rectangles, segments, squares, diamonds, etc. What do they have in common? We might want all of them to have a color, to know how to draw themselves, to know how to move themselves, and to know how to compute their area. The class GeomShape.java defines a class with these properties. Note that all shapes will have a color, and so myColor is an instance variable that is initialized in a constructor. There are methods to set and get the color. The draw method doesn't know how to draw the object, but we will look later at how it can allow the shape to be drawn in the correct color without permanently changing the color of the Graphics object.
The methods areaOf and move depend on specific information about the shape. Therefore they are given as abstract methods. The header ends in a semicolon and the word abstract is included in the header. The entire class is also declared as abstract. No object of an abstract class can ever be created. Hence, no GeomShape object can be created. Abstract classes exist only to serve as superclasses for other classes.
If a class declares one or more abstract methods, then the class itself must be declared abstract. However, you can still declare a class to be abstract even if it declares no abstract methods. As before, declaring a class to be abstract means that no object of the class can be created (even if the class contains no abstract methods).
A second abstract class, PointRelativeShape.java, is a subclass of GeomShape. This class is for shapes that have some "center" or reference point, where the shape is defined relative to that reference point.
PointRelativeShape takes care of defining the instance variables myX and myY, providing methods to return these values, and providing the move method. It extends GeomShape. Even though it declares no methods as abstract, it fails to implement areaOf, and so it must be abstract as well.
Finally, Circle.java and Rectangle.java inherit from PointRelativeShape. Note the use of super in the constructors. The drawShape methods (we'll see these methods soon) call getX and getY to figure out where the object is. They do not have to supply a move method, because they inherit it.
We can also have classes that inherit directly from GeomShape. Segment.java does so, and it implements everything itself.
Here's a picture of our class hierarchy:
Now, let's look at the driver GeomShapeDriver.java, which demonstrates all of these classes, showing that everything works. Again, we see polymorphism in action. The variable shape is declared as a reference to GeomShape, but in reality it will refer to a Circle, Rectangle, or Segment object. The calls at the bottom of the loop body show dynamic binding in action. The first time through the loop, we call methods in the Circle class; the second time through, we call methods in the Rectangle class; and the third time through, we call methods in the Segment class.
So far, when we went to draw a shape, we set the color of the Graphics object and drew our shape. Therefore, the next time we draw something, it will be in the color of the last shape drawn. If we next call drawString, then the rendered text will be in that color. Suppose we wanted the text to remain whatever the original foreground color was?
The Graphics class has a getter method that returns the current color for drawing: getColor. Thus, we can solve the problem by making the draw methods in the subclasses save the current color by calling getColor, changing the Graphics object's color to the color of the object being drawn, drawing the object, and finally restoring the saved color. For the Circle class, we could write the draw method as follows:
public void draw(Graphics page) {
// Save the current color.
Color savedColor = page.getColor();
// Set the color.
super.draw(page);
// Draw the circle.
page.drawOval(getX() - myRadius, getY() - myRadius, 2*myRadius, 2*myRadius);
// Restore the color we had on the way in.
page.setColor(savedColor);
}Unfortunately, that's a lot of work that we'd have to repeat for each instantiable subclass of GeomShape. There's a better way to accomplish this goal, with less code. We move all of the code except the actual drawing of the shape up to the GeomShape class in GeomShape.java in its draw method, and we add the following abstract method:
protected abstract void drawShape(Graphics page);Note that this is an example of the strategy pattern. The draw method does all of the color saving, changing, and restoring and leaves the detail of how to draw the shape to an abstract method.
Each instantiable class will have to define the drawShape method, and it would consist of the code that is specialized to that shape. For example, here's the drawShape method in the Rectangle class, within Rectangle.java:
protected void drawShape(Graphics page) {
page.drawRect(getX(), getY(), myWidth, myHeight);
}You can see also how we wrote the drawShape methods in Circle.java and Segment.java.
Now we can understand the draw method in GeomShape.java. It saves the current color, sets the current color to the shape's actual color, does the drawing specialized to the shape, and finally restores the original color:
public void draw(Graphics page) {
Color savedColor = page.getColor(); // save the current color
page.setColor(myColor); // set the color
drawShape(page); // draw the shape in the shape's color
page.setColor(savedColor); // restore the color we had on the way in
}Once again, dynamic binding helps us. When the draw method calls drawShape, which class has its drawShape method called? As usual, it's the class of the object that draw was called on.
Why did I make drawShape protected? I intend drawShape to be called only by the draw method in GeomShape. By making it protected, it cannot be called by methods outside of GeomShape or its subclasses. (Well, except for the detail that any other class in the same package can call it, also!)
Because drawShape is protected in GeomShape, I had to make drawShape protected in the subclasses Circle, Rectangle, and Segment—even though I don't intend for there to be any subclasses of Circle, Rectangle, and Segment. That's because when we declare a method as abstract in a superclass, the method has to have at least the same degree of "visibility" in the subclasses. Why? When we say that a superclass allows a method to be called, that method has to be callable in all subclasses. So the method must be at least as visible in the subclasses as it is in the superclass. Indeed, I could have declared drawShape as public in Circle, Rectangle, and Segment, so that it would be even more visible than in GeomShape, but there's no point in doing so.
We have talked about public and private access. Those are the kinds of access that we will usually use. However, you should know that there are four access levels:
We have seen that public access means that any method of any class can access the variable or method. Private access is limited to the given class and its inner classes.
Protected access is new for us. With protected access, the variable or method should be accessible to only the class and any subclass that extends the class (or extends a class that extends the class, etc.). Protected access seems to be a good compromise between public and private, and it is certainly an improvement on public.
There is a problem with protected access, however. Because anyone can extend a class, there is no real control over who can access protected instance variables. Again, there is no abstraction barrier between the superclass and its subclasses. A better way to restrict access is to make all instance variables (except constants) private and then to make the methods that can access those instance variables protected. That should prevent classes other than subclasses from accessing the instance variables, while still keeping encapsulation.
The default access, package access, is what you get if you don't put anything before the instance variable or method. In other words, it's what you'd get for the instance variable x in the following class:
public class Bozo {
int x; // package access
...
}I consider it a design flaw of the language that there is no package visibility level specifier, as there is for public, private, and protected. It is too easy to forget to declare an instance variable (or method) private. I would have preferred that leaving off the visibility level specifier would be a syntax error. That way the programmer would always have to make an explicit choice.
Package access makes the variable or method visible to everything in the same package. As we mentioned when we talked about import statements, package is a way of grouping methods together that are intended to work together as a group, such as java.util or java.awt. To put a file into a package, you start the file with a package statement:
package package_name;where you replace package_name by the name of the package.
If there is not a package statement, then all classes in the file go into the default package.
You seldom want package access. Anyone can add a class to a package, so you have very little control of who has access to things that have package access. It sometimes makes sense to give package access for methods that you want as utility routines within a package, but it seldom makes sense to have package access for instance variables.
You might have noticed that when I described what protected means, I said it "should" only be available to the class and its descendents (subclasses or subclasses of those subclasses, etc.). That is what protected means in C++. Unfortunately, that is not what it means in Java. As we have described it, public is the least restrictive, private the most, and protected and package are both somewhere in between, but you can't say that one is more restrictive than the other. They control access in very different ways.
The designers of Java decided that not having a linear heirarchy of protection levels was a bad idea. Therefore they somewhat arbitrarily decided that protected access should include package access, so that package access is more restrictive than protected. So in Java protected really means visible in descendents and to classes in the same package. If you are using the default package, that means it is not much different than public! However, I will still declare things protected to indicate who should have access.
When we created listeners, we had to implement an interface. For the MouseListener interface, there were five methods that had to be implemented, and we usually used only one or two. We had to create empty-bodied implementations for the others. Having to do so was a minor irritant.
This situation comes up often enough that Java has provided an alternate approach. For each Listener interface, there is a corresponding Adapter class that supplies empty-body implementations for each of the methods in the interface. We then can extend these classes, overriding just the methods that we want to actually do something. We no longer have to supply the empty-body implementations, because the Adapter class has already done that, and we inherit them.
For example, consider DragAMac3.java. It has two inner classes that implement the MouseListener and the MouseMotionListener interfaces. But instead of saying that we will implement these interfaces, we instead extend the MouseAdapter and MouseMotionAdapter classes. The empty-body implementations that we had to supply before are now gone.
Note that if we use the applet itself as the listener (using this as the parameter to the appropriate addListener method calls), we cannot use this approach. That is because in creating the class DragAMac3, we have already extended Applet, and Java does not allow multiple inheritance. In other words, Java does not allow a class to extend more than one other class. DragAMac3 has to extend Applet, and we can either implement the two interfaces directly or extend the Adapter classes in inner classes as we have done here. In fact, we had to use two different inner classes, since a single inner class cannot extend both Adapter classes.
We saw one other interface that we use to handle events: the ActionListener interface. Unlike MouseListener and MouseMotionListener, ActionListener has no corresponding adapter class. There's a pretty good reason for that. What do you think it is?
The above point is worth repeating.
In Java, a subclass can extend just one superclass.
(Extending more than one superclass would be multiple inheritance.) For example, the following class declaration would not be legal:
class Bozo extends Clown, TVStar {
...
}On the other hand, a class is allowed to implement any number of interfaces. Thus, the following class declaration would be legal:
class Bozo implements Clown, TVStar {
...
}Why doesn't Java allow multiple inheritance? Because it can cause problems that are difficult to resolve. What if more than one superclass defines the same instance variable that is visible to the subclass (i.e., either public or protected)? What if more than one superclass defines a method with the same name and signature? What if you have a "diamond" shaped inheritance structure, where A is the superclass, B and C both inherit from A, and D inherits from both B and C. D should have access to all instance variables that B and C have. But each has a copy of A's instance variables! Should D have two copies of each?
C++ allows multiple inheritance, and it pays the price in its complexity. The designers of Java decided to keep things simple, and so Java does not provide for multiple inheritance. Interfaces provide a way to get most of the benefits of multiple inheritance without most of the problems. The downside of interfaces, of course, is that they don't allow you to define instance variables in them, nor do they allow you to provide method bodies that are inherited.
Let's revisit linked lists. I say "revisit" because you've seen linked lists before in either CS 1, ENGS 20, or your AP course. But you haven't seen them like you're going to see them here.
Some reminders about linked lists. A linked list is in some ways like an array. In particular, it defines a linear ordering of elements. Unlike an array, we can insert an element into any position in the linear order in constant time, and we can also delete an element from any position in the linear order in constant time, with all other elements maintaining their relative positions for both insertion and deletion. With an array, we have to shift elements when inserting or deleting if we want them to maintain their positions relative to each other, and so it can take a while to insert or delete into an array (or an ArrayList).
Another advantage of linked lists is that they grow and shrink dynamically. That is, the space occupied by an n-element linked list, in which each element occupies n bytes, is about bn. Although you could implement an ArrayList to grow and shrink dynamically, you cannot do so while maintaining constant-time per insertion or deletion from the middle of the ArrayList.
So what's the downside of linked lists? They're a little more complicated to work with than arrays. They also take a bit more space than arrays (need space for the links). Like an ArrayList, a linked list can store only objects, not primitive types. But the biggest disadvantage is that we cannot index into them in constant time. In other words, we can find the ith element of an array or an ArrayList in constant time, but finding the ith element of a linked list takes time proportional to i. For applications where we need to index quickly, linked lists are not a great choice.
In a linked list, the elements are arranged in a linear order that is determined by following a chain of links. For example, here is a conceptual picture of a linked list with three elements, each of which contains a reference to the name of a state:
As you can see, we think of the list as having a head and a tail element, and we can think of references head and tail to these elements.
The link part of each element tells us the next or previous element on the list. These will be implemented as references to entire elements.
We will see a couple of ways to implement linked lists. Both ways will support a basic set of operations. When we have a set of operations to be supported but without a specific implementation for them, we make an interface. We will use the CS10LinkedList interface in CS10LinkedList.java. Like an ArrayList, this interface uses a generic type T.
The specifications of the methods of the CS10LinkedList interface assume that the linked list maintains a notion of a "current" element of the list. The interface has the following methods:
add inserts a new element after the current element, making the current element be this new element. If there is no current element, it inserts at the front of the list.remove removes the current element, designating the successor of the removed element as the new current element. It is an error to call remove if there is no current element.contains determines whether an object is in the linked list. It returns a boolean that says whether the object was found. If the object was found, then the current element is set to be this object. (You can then insert after it, set it, or remove it.) The contains method uses the equals method to determine whether an object is in the linked list. As always, the default version of equals determines whether two objects are the same object, i.e., whether two references are to the same address, but a class can override the default version of equals.isEmpty returns a boolean indicating whether the linked list has no elements.hasCurrent returns a boolean indicating whether the linked list has a current element.hasNext returns true if there is a current element and it has an element that follows it.getFirst sets the current element to be the first one in the linked list and returns it. If the list is empty, getFirst returns null.getLast sets the current element to be the last one in the linked list and returns it. If the list is empty, getLast returns null.addFirst inserts an element at the head of the linked list and makes it the current element.addLast inserts an element at the tail of the linked list and makes it the current element.clear removes all elements from the list.next advances the notion of the current element to the next element following the current element and returns it. If there is no element following the current element, then next returns null.get returns the data of the current element, or null if there is no current element.set sets the data field of the current element, It is an error to call set if there is no current element.You can traverse a linked list to get a reference to each element of the list, as ListTraverse.java shows. Here, each element is an Integer object, just to keep things simple. (We rely on unboxing in the loop body, where we add i, which is really a reference to an Integer object, into sum.) Notice the header of the for-loop to traverse the list:
for (Integer i = myList.getFirst(); i != null; i = myList.next()) {
System.out.println("List element with value " + i);
sum += i;
}This style of for-loop header might seem strange to you, becuase it doesn't use the increment or decrement operators of Java to go through the linked list, as you would for an array or ArrayList. Since we don't index into a linked list, there's no need to maintain an index and hence no need to increment.
Let's dissect the first for-loop header. The initialization sets i to be the value of the first element in the list and sets current to reference the first list element. It's the equivalent of getting the 0th element in an array. The test checks whether we've hit the end of the linked list, the equivalent of the index into an array reaching the size of the array. The update part advances current by one position in the linked list, setting i to the value of the next element in the list.
We don't have to rely on getFirst and next returning null when they hit the end of the list. The second for-loop calls the hasCurrent method to determine when that happens, but it has to explicitly call the get method within the body of the loop to get the value of the current element:
for (myList.getFirst(); myList.hasCurrent(); myList.next()) {
Integer i = myList.get();
System.out.println("List element with value " + i);
sum += i;
}If you took CS 1, then you know that the simplest, cleanest way to implement a linked list is with a circular, doubly linked list with a sentinel. The implementation is in SentinelDLL.java. The class is generic for a type T, declared with the line
public class SentinelDLL<T> implements CS10LinkedList<T>To start, each list element is an object of the class Element and has three instance variables:
data is a reference to the object being stored in that list element. This object must be of the type T. For the above example with state names, when we create a SentinelDLL object, T will be a String, so that data is a reference to a String.next is a reference to the Element after this one in the list.previous is a reference to the Element before this one in the list.The Element class is a private inner class. It has the following methods:
T. It stores this reference in the instance variable data.toString returns the String representation of this element's data object.Because each Element stores a reference to an object, strange things can happen if we store a reference to an object and then the object is changed. Therefore, we require that once a reference to an object is stored in an Element, the object itself should not change.
The class SentinelDLL implements the linked list. In fact, it implements the CS10LinkedList interface. The methods of SentinelDLL will need to access the data, next, and previous instance variables of each Element object. Because Element is a private inner class, the methods of SentinelDLL can access its instance variables, even though they are declared as private. No methods outside of SentinelDLL can access the instance variables of Element, and so no methods outside of SentinelDLL can refer to data, next, or previous.
Next we examine the declaration for the class SentinelDLL. It contains several methods, but first let's look at the instance variables.
current references the "current" list element, which we will need for several of the linked-list operations.sentinel references a special list element, which we call the sentinel.The scheme is that a linked list has exactly one sentinel, along with zero or more "real" elements. For example, the list above, with the names of three states, would contain four Element objects: the sentinel, and objects for Maine, Idaho, and Utah. The picture looks like the following, where a slash indicates a null reference:
Here, I omitted showing which Element object is pointed to by current. Despite how I had to draw the figure, each of these references points not to individual instance data, but rather to an entire Element object. The sentinel's data is a null reference.
Notice how the list is circular, in that you can start at the sentinel and follow either forward (next) or backward (previous) references and eventually get back to the sentinel.
In this scheme, every linked list, even an empty one, has a sentinel. In an empty list, both references in the sentinel point to the only Element available, namely the sentinel:
It may seem strange to have an "empty" list actually have an Element object in it, but it turns out to really simplify some of the code. You may appreciate this simplicity later on when we examine other ways to implement linked lists.
Having seen how we intend circular, doubly linked lists with a sentinel to be represented, now we examine the methods of the Element and SentinelDLL classes in SentinelDLL.java. The methods for Element are straightforward, so we won't go over them here.
The SentinelDLL constructor makes an empty list with only the sentinel, as the diagram above shows. It also sets the instance variable current to point to the only Element in town, namely the sentinel. Setting the next and previous fields of the sentinel and setting current are done by a call to clear, which makes any list empty (leaving any contents for garbage collection).
StringThe toString method for a SentinelDLL is fairly straightforward. It uses a common style of traversing a linked list by a clever for-loop header:
String result = "";
for (Element<T> x = sentinel.next; x != sentinel; x = x.next)
result += x.toString() + "\n";
return result;The for-loop iterates through the list, starting from the first non-sentinel on the list (sentinel.next), following next references, and stopping when it gets back to the sentinel. It concatenates the string representation of each element in the list onto a String named result, returning result at the end. Of course, this style of traversing the linked list works only within methods of the SentinelDLL class, since the instance variables sentinel and next are private to their respective classes.
The add method for a list takes an object reference obj, and it inserts it after the Element object referenced by the instance variable current. Notice that we restrict obj to be of type T. The code manipulates references to "splice in" the new element. For example, if we start from an empty list, where current = sentinel, and insert an element with the string Maine, we have the following situation:
The add method makes current reference the new Element object.
The splicing works the same when inserting into any position of the list. For example, starting from the 3-element list from before, we insert Ohio after Idaho as follows:
Let's take a careful look at how add works. First, it makes a new Element that references the given object, and x references this new Element. It is this new Element that we will add to the list. We need to do four things:
x's next reference the element following the one that current references. The assignment x.next = current.next does so.x's previous reference current. The assignment x.previous = current does so.current will have a new predecessor, namely the element that x references, so we need to set the previous instance variable of this element to reference x's element. The assignment current.next.previous = x does so. The expression current.next.previous can be a bit confusing, so let's examine it carefully. current references the current element. current.next references the element following the one that current references. This element has an instance variable previous that references its predecessor (which is current at the time that the add method is called, but it's about to be updated). Since we want to assign to the previous instance variable of the Element object referenced by current.next, we put current.next.previous on the left-hand side of the assignment statement.current will have a new successor, namely the element that x references, so we set the next instance variable of current's element to reference x's element. The assignment current.next = x does so.As you can easily see from the add code, it takes constant time to insert an element into a circular, doubly linked list with a sentinel. You can also see, by the absence of if-statements, that there are no special cases.
The remove method for a list removes the Element object that current references. You never ever remove the sentinel, so the first thing we do is check whether current references the sentinel by calling the hasCurrent method. If current references the sentinel (indicated by hasCurrent returning false), then we print an error message to System.err, rather than to System.out. On some systems, you can suppress regular output printed to System.out, but you have to go to extra lengths to suppress error messages printed to System.err. In Eclipse, when you print to System.err, the message appears in red in the console. We want to make error messages likely to be seen.
Normally, the remove method is not trying to remove the sentinel. We splice the current element out of the list and make current reference its successor in the list.
For example, to remove Idaho from the previous list:
and to remove the only element from a list:
The time to remove an element is constant. As we will see when we examine "simpler" lists, this running time is quite good; with linked lists whose representation appears simpler than that of a circular, doubly linked list with a sentinel, the time to remove an element at the ith position in the list is proportional to i.
The contains method for a SentinelDLL takes a reference obj to an object of the generic type T and looks for an element that equals obj, according to the equals method on the data field of each Element. We traverse the list, calling equals on each element's data, until a match is found. If the contains method finds such an element, it sets current to reference it, so that we can next either add a new element after it or remove it.
We could check to make sure that we haven't returned to the sentinel, along with checking whether we have a match, but we use a clever way to avoid having to check that we haven't returned to the sentinel in each iteration of the loop. We put the value we're looking for in the sentinel. That way, we're guaranteed of finding it. If where we found it was the sentinel, it wasn't there in the first place. If where we found it was not the sentinel, then it really was there. We set sentinel.data to be the same reference as obj before traversing the list, and we make sure to put a null back into sentinel.next after the traversal is done, no matter where in the list the traversal stopped.
When we use the sentinel trick, the for-loop needs no body:
for (x = sentinel.next; !x.data.equals(obj); x = x.next)
;This process is really linear search. The time to perform it depends on the time to compare two elements. If we denote this comparison time by t, and we say that the list has nelements, then the time to find a list element is proportional to tn in the worst case (when the element is not in the list). If t is a constant that can be ignored, then the worst-case time is proportional to n.
The remaining list functions are really easy. Note that the later functions use the isEmpty, hasCurrent, and hasNext predicates rather than just doing the tests directly. Accessing the linked list through these methods makes changing the representation easier.
isEmpty returns true if and only if the only list element is the sentinel. That is the case precisely when the sentinel references itself.hasCurrent returns true if and only if there is a current element. That is the case precisely when current does not reference the sentinel.hasNext returns true if there are both a current element and another element after the current element.getFirst sets the current reference to the first element in the list and returns the data in the first element. If the list is empty, then current must reference the sentinel, and its data must be null, and so getFirst returns null when the list is empty.getLast is like getFirst except that it sets current to reference the last element in the list and return its data.addFirst adds a new element at the head of the list and makes it the current element.addLast adds a new element at the tail of the list and makes it the current element.next moves current to current.next and returns the data in that next element. It returns null if there is no next element.get returns the data in the current element, or null if there is no current element.set assigns to the current element, printing an error message to System.err if there is no current element.All of the above methods are in the CS10LinkedList interface. In addition, the SentinelDLL class contains one method (other than the constructor) that is not in the CS10LinkedList interface:
previous moves current to current.previous and returns the data in that previous element. It returns null if there is no previous element.SentinelDLL classWe can use the ListTest.java program to test the SentinelDLL class. You can use the debugger to examine the linked list if you like.
Notice that to declare and create the linked list, we specify the type that will be stored in the list. Here, it's a String:
CS10LinkedList<String> theList = new SentinelDLL<String>();Because theList is declared as a reference to the interface CS10LinkedList, we cannot call the previous or hasPrevious methods in this driver.
Although doubly linked circular linked lists with sentinels are the easiest linked lists to implement, they can take a lot of space. There are two references (next and previous) in each element, plus the sentinel node. Some applications create a huge numbers of very short linked lists. (One is hashing, which we'll see later in this course.) In such situations, the extra reference in each node and the extra node for the sentinel can take substantial space.
The code for singly linked lists has more special cases than the code for circular, doubly linked lists with a sentinel, and the time to remove an element in a singly linked list is proportional to the length of the list in the worst case rather than the constant time it takes in a circular, doubly linked list with a sentinel.
The SLL class in SLL.java implements the CS10LinkedList interface with a generic type T, just as the SentinelDLL class does. A singly linked list, as implemented in the SLL class, has two structural differences from a circular, doubly linked list with a sentinel:
Each Element object in a singly linked list has no backward (previous) reference; the only navigational aid is a forward (next) reference.
There is no sentinel, nor does the list have a circular structure. Instead, the SLL class maintains references head to the first element on the list and tail to the last element on the list.
A singly linked list with Maine, Idaho, and Utah would look like
A singly linked list with only one element would look like
And an empty singly linked list looks like
The file SLL.java contains the class definitions for Element and SLL for a singly linked list. These declarations are similar to those for circular, doubly linked lists with a sentinel. As before, Element class is a private inner class, and all method declarations are the same. The only difference is in the instance data. We can use the same ListTest.java driver to test the singly linked list class, as long as we change the line creating the list to read
CSLinkedList<String> theList = new SLL<String>();Let's examine the List methods in SLL.java for singly linked lists. We will highlight those that differ from those for circular, doubly linked lists with a sentinel.
The clear method, which is called by the SLL constructor as well as being publicly available, makes an empty list by setting all instance variables (head, tail, and current) to null.
As before, the add method places a new Element object after the one that current references. Without a special case, however, there would be no way to add an element as the new head of the list, since there is no sentinel to put a new element after. Therefore, if current is null, then we add the new element as the new list head.
The code, therefore, has two cases, depending on whether current is null. If it is, we have to make the new element reference what head was referencing and then make head reference the new element. Otherwise, we make the new element reference what the current element is referencing and then make current reference the new element. If the new element is added after the last element on the list, we also have to update tail to reference the new element.
Compare this code to the add code for a circular, doubly linked list with a sentinel. Although there is only one directional link to maintain for a singly linked list, the code has more cases and is more complex. For either implementation, however, adding an element takes constant time.
As mentioned, removing an element from a singly linked list takes time proportional to the length of the list in the worst case—in other words, time that is linear in the length of the list— which is worse than the constant time required for a circular, doubly linked list with a sentinel. Why does it take linear time, rather than constant time? The reason is that the previous reference in a doubly linked list really helps. In order to splice out the current element, we need to know its predecessor in the list, because we have to set the next instance variable of the predecessor to the value of current.next. With the previous reference, we can easily find the predecessor in constant time. With only next references available, the only way we have to determine an element's predecessor is to traverse the list from the beginning until we find an element whose next value references the element we want to splice out. And that traversal takes linear time in the worst case, which is when the element to be removed is at or near the end of the list.
The remove method first checks that current, which references the Element object to be removed, is non-null. If current is null, we print an error message and return. Normally, current is non-null, and the remove method finds the predecessor pred of the element that current references. Even this search for the predecessor has two cases, depending on whether the element to be removed is the first one in the list. If we are removing the first element, then we set pred to null and update head. Otherwise, we have to perform a linear search, stopping when pred.next references the same element as current; once this happens, we know that pred is indeed the predecessor of the current element. (There is also some "defensive coding," just in case we simply do not find an element pred such that pred.next references the same element as current. We do not expect this to ever happen, but if it does, we have found a grave error and so we print an error message and return.) Assuming that we find a correct predecessor, we splice out the current element. We also have to update tail if we are removing the last element of the list.
The bottom line is that, compared with the remove code for a circular, doubly linked list with a sentinel, the remove code for a singly linked list is more complex, has more possibilities for error, and can take longer.
toString for a listThe toString for a singly linked list is similar to how we print a circular, doubly linked list with a sentinel, except that now we start from head rather than sentinel.next and that the termination condition is not whether we come back to the sentinel but rather whether the reference we have is null. The for-loop header, therefore, is
for (x = head; x != null; x = x.next)The contains method for a singly linked list is perhaps a little shorter than for a circular, doubly linked list with a sentinel, because now we do not replace the object reference in the sentinel. The for-loop header, therefore, becomes a little more complicated. We have to check whether we have run off the end of the list (which we did not have to do when we stored a reference to the object being searched for in the sentinel) and then, once we know we have not run off the end, whether the element we are looking at equals the object we want. The bodyless for-loop is
for (x = head; x != null && !x.data.equals(obj); x = x.next)
;Although the code surrounding the for-loop simplifies with a singly linked list, the loop itself is cleaner for the circular, doubly linked list with a sentinel. Either way, it takes linear time in the worst case.
isEmpty is easy, but slightly different from the version for a circular, doubly linked list with a sentinel. We simply return a boolean that indicates whether head is null.hasCurrent returns true if and only if the there is a current element. We simply return a boolean indicating whether current is not null.hasNext checks to see whether there is a current element and whether the next field of the current element is null rather than seeing if it is the sentinel.getFirst is different, as it sets current to head.getLast changes, too, setting current to tail.addFirst and addLast are similar to a circular, doubly linked list with a sentinel. However, addLast has to deal with an empty list separately.get is unchanged.next is identical to the version in the doubly linked list. (This is an advantage of calling hasNext rather than doing the test directly in this method.)previous and hasPrevious methods. We are not required to, because they're not in the CS10LinkedList interface.It is also possible to have a dummy list head, even if the list is not circular. If we do so, we can eliminate some special cases, because adding at the head becomes more similar to adding anywhere else. (Instead of changing the head you update a next field.) It is also possible to have current reference the element before the element that it actually indicates, so that removal can be done in constant time. It takes a while to get used to having current reference the element before the one that is actually "current."
It is also possible to have a circular singly linked list, either with or without a sentinel.