.
public void add ( E data )
{
Node node = new Node () ;
node.setData ( data ) ;
}
assuming you defined LinkedList as public class LinkedList<E> and the Node class as;
public class Node<E>
{
private E data ;
public void setData ( E data )
{
this.data = data ;
}
public E getData ()
{
return data ;
}
}
With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.
node.setData ( data ) ;
Dont Nodes need to be of a particular type or cast down?
Can you tell me what this means or whats wrong with it
node = new Node<E>(Object);
For the instance field private Node <E> head = null;
the initilazation needs a cast to make sure that when a new Node is created that it is of the same type as the LinkList right?
Or also or just for the innerclass private class ListIter implements ListIterator <E>
I am implementing LinkList with most of the delegation being done in ListIter don't I need some casting in the constructor here.
You should remove the <E> dependency from Node I guess. It should just be like private Node head = null ; Let the <E> stuff be at the LinkedList level.
If you're declaring Node as a generic private inner class with a type parameter representing the data it is holding (which is going to be the same type as the linked list), it actually MUST use a different identifier for the type parameter than what your linked list class is using. If you use the same identifier, one will hide the other (much like variables or method parameters can hide a class's fields if the names match).
public class IterableLinkedList<E> implements ListIterator<E> {
private Node<E> head;
// Declaring the class as "Node<E>" here will hide the type E from IterableLinkedList
private class Node<F> {
private F data;
private Node<F> next;
...
}
...
}
However, if they're using different identifiers, how do we know that the Nodes will be bound to the same type that the IterableLinked is bound to? The part which ensures that is the declaration of the head field, where we say Node<E>. This way, when you bind a type to E in the IterableLinkedList, the same type is also bound to that head Node<E>. All methods you write for IterableLinkedList will use the types E and Node<E>, and all the methods you write for Node will use F and Node<F>. (If Node were defined outside of the IterableLinkedList class, we could use E in both places, but it would still be the same concept... just without the added confusion of hidden types.)
Your class would end up looking like this:
public class LinkedListIterator<E> implements ListIterator<E> {
private Node<E> head = null;
private class Node<F> {
private F data;
private Node<F> next;
public Node() {
this(null);
}
public Node(F data) {
this(data, null);
}
public Node(F data, Node<F> next) {
setData(data);
setNext(next);
}
public F getData() {
return data;
}
public void setData(F newData) {
this.data = newData;
}
public Node<F> getNext() {
return next;
}
public void setNext(Node<F> newNext) {
this.next = newNext;
}
}
// implementations of methods from List and Iterator interfaces...
// for example, this adds to the head of the list
public void add(E element) {
// head = new Node<E>(element, head);
Node<E> toBeAdded = new Node<E>(element);
toBeAdded.setNext(head);
head = toBeAdded;
}
// and so on...
}