We Keep Coding

Doubly Linked List with generic node type

I need a doubly linked list that can work on different node implementations. Note that I do not want nodes that contain generic data, like DoublyLinkedNode<T>, but something like DoublyLinkedList<N extends DoublyLinkedNode<T>>.
To be precise, I use the list in the general case with standard nodes, but in other parts of my program I need nodes with additional fields. So I implemented the general node as
public class DoublyLinkedNode<T> {
DoublyLinkedNode<T> before, after;
T value;
}
and the special type as
public class DoublyLinkedSpecialNode<T, S> extends DoublyLinkedNode<T> {
S specialValue;
}
Now in my DoublyLinkedList implementation I want to be able to handle both cases at one, because all the code basically fiddles around with the pointers that are obviously common to both implementations.
This gives a few requirements:
1) When I use the special node, I want to be able to return it as the DoublyLinkedSpecialNode type to be able to access the additional fields.
2) The list must use a DoublyLinkedNode type to access the pointers of the nodes.
3) The list is assigning the pointed-to nodes to other nodes, e.g. head = node.after;, so the type of the pointers in the special node must be the same as the type in the list.
Extending the list makes no sense because then I could not change the return type of the methods. Therefore I tried two ideas without success:
The already mentioned solution: Generic node type that extends from DLN
The list would look like this:
public class DoublyLinkedList<T, N extends DoublyLinkedNode<T>> {
N head, tail;
N tail() {
return tail; // OK
}
void remove(N node) {
if (head == node) {
head = node.after; // Type error
}
...
This solution conflicts with requirement 3), because in the list the type is an N that extends from DLN, but in the node implementation N the pointer is of the type of the base class/interface DLN (the pointer type could theoretically be more general than N).
Base DLN instead of generics
In this case the list works on the base class node and accepts the subclasses because of polymorphism:
public class DoublyLinkedList<T> {
DoublyLinkedNode<T> head, tail;
DoublyLinkedNode<T> tail() {
return tail;
}
void remove(DoublyLinkedNode<T> node) {
if (head == node) {
head = node.after; // OK
}
...
But tail() can only return nodes as the general type, conflicting with 1). I would prefer not to use casting, because I assume it's bad practice (?) but also because the implementation is performance critical. There surely is a better way?

I found another solution that is okay-ish, not very performant but more elegant than the last solution.
The idea ist to use only one type of nodes, and wrap the varying content in a generic container. The DLN code looks like this:
public class DoublyLinkedNode<C> {
DoublyLinkedNode<C> before, after;
C content;
public static class ValueContent<T> {
T value;
}
public static class ValueSpecialContent<T, S> extends ValueContent<T> {
S specialValue;
}
}
The list implementation then looks something like this:
public class DoublyLinkedList<C> {
DoublyLinkedNode<C> head, tail;
public DoublyLinkedNode<C> head() {
return head;
}
void remove(DoublyLinkedNode<C> node) {
if (head == node) {
head = node.after;
...
And I can access the special field from the calling class like this:
DoublyLinkedList<SpecialContent<SpecialType>> list;
SpecialType s = list.head().content.specialValue;
There is some overhead because each node has to instantiate that container class, but I think it's still better than casting. I have to check the performance impact.

Java - interface passing itself as a parameter [duplicate]

I had an interview days ago and was thrown a question like this.
Q: Reverse a linked list. Following code is given:
public class ReverseList {
interface NodeList {
int getItem();
NodeList nextNode();
}
void reverse(NodeList node) {
}
public static void main(String[] args) {
}
}
I was confused because I did not know an interface object could be used as a method parameter. The interviewer explained a little bit but I am still not sure about this. Could somebody enlighten me?

This is in fact one of the most common and useful ways to use an interface. The interface defines a contract, and your code can work with any class that implements the interface, without having to know the concrete class - it can even work with classes that didn't exist yet when the code was written.
There are many examples in the Java standard API, especially in the collections framework. For example, Collections.sort() can sort anything that implements the List interface (not just ArrayList or LinkedList, though implementing your own List is uncommon) and whose contents implement the Comparable interface (not just String or the numerical wrapper classes - and having your own class implement Comparable for that purpose is quite common).

It's not the interface "object" being passed to the method, still just a regular object. It's just a way of saying "this parameter will accept any object that supports this interface". It's equivalent to accepting some object of a base class type, even if you're passing in a subclass.

This is called programming to interfaces. You don't code to a specific implementation class of node lists but to the interface implemented by all those implementations.
That way your code will still work if someone writes a new and much better implementation of NodeList after you wrote your reverse method and you don't have to adapt your code for each new implementation of NodeList.

The argument needs an object, which class implements an interface (the parameter).
In pseudo Java the code:
void reverse(NodeList node) {
// your code
}
is equal to:
reverse(x) {
if(x == null || x instanceof NodeList) {
// your code
}else throw new RuntimeException("Some sort of error.");
}
Note; read more on Interfaces here: http://java.sun.com/docs/books/tutorial/java/IandI/interfaceAsType.html

This is one possible implementation:
public class ReverseList {
interface NodeList {
int getItem();
NodeList nextNode();
}
static class Node implements NodeList {
private int item;
private Node next;
#Override
public int getItem() {
return item;
}
public void setItem(int si) {
item = si;
}
#Override
public NodeList nextNode() {
return this.next;
}
public void setNext(Node n) {this.next=n;}
}
Node reverse(NodeList head) {
Node node = (Node) head;
Node previous = null;
while(node.nextNode() !=null) {
Node tempNext = (Node) node.nextNode();
node.setNext(previous);
previous = node;
node = tempNext;
}
node.setNext(previous);
return node;
}
public static void main(String[] args) {
//Initialization block
ReverseList rl = new ReverseList();
Node n1= new Node(); n1.setItem(1);
Node n2=new Node(); n2.setItem(2);
Node n3 =new Node(); n3.setItem(3);
n1.setNext(n2); n2.setNext(n3); n3.setNext(null);
//Reversing the list
System.out.println("Before reversal");
System.out.println(n1.getItem() +"->"
+ n1.nextNode().getItem() + "->"
+ n1.nextNode().nextNode().getItem() + "->"
+n1.nextNode().nextNode().nextNode());
rl.reverse(n1);
System.out.println("\nAfter reversal");
System.out.println(n3.getItem() +"->"
+ n3.nextNode().getItem() + "->"
+ n3.nextNode().nextNode().getItem() + "->"
+n3.nextNode().nextNode().nextNode());
}
}
Program output:
Before reversal
1->2->3->null
After reversal
3->2->1->null
I am very curious to know if this problem can be solved by using an anonymous class. Any ideas?

Had this same confusion while learning lambda stuff.
This video didnt explain the concept, but it's a clear way for you to see how it works in terms of passing an interface as a parameter.
https://www.youtube.com/watch?v=mk3erzL70yM

The major benefit of using interfaces, IMHO, is being able to test easily. Suppose you have an interface called, PatientManager.
You can write specific unit tests for imaginable things like "CachingPatientManager" or "LDAPPatientManager", the use case could be myriad.
The benefit is because the programming to interface becomes highly reusable and testable.

You cannot create an instance (/object ) of an Interface.
Yes, you can pass Interface as a parameter in the function. But the question seems incomplete. Interface isn't implemented by any class. Something is missing. If you try to run this, compiler will not show any error.
But, in the reverse() method you need to create an instance of class that implements NodeList interface. I hope this makes sense.

JAVA Why do I get a type error when assigning these variables (T extends Comparable<T>)

So, let's say we have these two classes.
public class Main<T extends Comparable<T>> {
public List<T> toList(T t){
Node n = new Node();
n.value = t; //This assignment1 gives no issues.
List<T> list = new List<T>();
list.add(n.value); //This assignment2 gives a type error.
return list;
}
}
class Node <T extends Comparable<T>> {
T value = null;
}
So, why does assignment1 go through without a type error, while assignment2 gives me the following error:
add (T) in List cannot be applied to (java.lang.Comparable)
It disappears when I do:
list.add((T)n.value);
But I would like to understand the reason first to figure out if above solution is the correct one.
EDIT: For now, I should specify that the code that uses these classes are Integer objects. So, I as the developer can assume that the T types are the same. But I am not sure if the code has some underlying routine that can change the values during casting.

Node n = new Node();
should be
Node<T> n = new Node<T>();
If you ever refer to Node without <something> after it, you are telling the compiler to ignore all type checking on Node. This will give you warnings, as it should.

Generics and compareTo() method

I am trying to make a SkipList and I have a method that takes a generic data type:
public void add(E key, Integer value)
{
Node<E> p;
p = find(key);
}
Which takes you here:
public Node<E> find(E key)
{
//Start at head
Node<E> p = head;
while (true)
{
while ( (p.getRight().getKey() != Node.posInf) && (p.getRight().getKey().compareTo(key) <= 0 ))
{
p.setRight(p.getRight());
}
//More stuff down here
}
}
The problem is on the compareTo() method. It says the compareTo() method is undefined for type E. In Eclipse it wants me to add two typecasts like this:
((String) p.getRight().getKey().compareTo((String) key) <= 0 )
Why does it want String? The data type could be anything. I tried doing typecast of E instead but Eclipse wants to change it back to String. Any help would be appreciated.

You haven't shown how E is defined, but the error message indicates that you didn't place an upper bound of Comparable<E> on the declaration of E.
You can accomplish that with something like this on your class:
public class SkipList<E extends Comparable<E>>
This will allow you to call compareTo on your key variable of type E.
As to why Eclipse is suggesting casting to a String, it looks like Eclipse is guessing as to what would be the best change to make to make it compile. It may have guessed String because it's Comparable<String>. In this case, it's wrong, because E isn't necessarily a String. The solution here is different, as I stated above: restrict E to be Comparable<E>.

The method compareTo is defined in the interface java.lang.Comparable. There is nothing in your code that tells the compiler that the type parameter E is Comparable. You can do this in the generic type declaration:
class Node<E extends Comparable<E>> {
...
}
By default if you don't declare extends Comparable, you can only access methods defined in the java.lang.Object class.

How to write Iterator for a list?

I have a class implementing List interface and storing data in an array of Objects. Now I need to write Iterator method for my class. How to get started ? I thought about writing a subclass implementing Iterator interface. Object of the class will have parameters of current index and last index. At each call to next/hasNext those parameters will be modified. Is this approach correct ? But then there is a problem with remove() method, since it should allow to delete object of class calling my iterator. How to solve this ? Also what should happen in iterator() method of my main class ?
My pseudocode:
class MyCollection<T> implements List<T>{
T[] tab;
MyCollection(int len) {
tab = (T[])new Object[len];
}
public Iterator iterator(){
}
}
class MyIterator<T> implements Iterator {
private int current;
private int last;
public void remove(){
}
public T next(){
}
public boolean hasNext(){
}
}

I have a class implementing List interface and storing data in an array of Objects.
It looks like you are reimplementing ArrayList. Is there a good reason for doing this?
Object of the class will have parameters of current index and last index. At each call to next/hasNext those parameters will be modified. Is this approach correct ?
You should only need one index, I think. But the basic idea is correct.
But then there is a problem with remove() method, since it should allow to delete object of class calling my iterator. How to solve this ?
There are two approaches:
Remove the element from the array and somehow arrange that the "hole" is filled. Either a) copy all elements to a new array of size tab.length - 1, b) use System.arraycopy or equivalent to move the elements after the deleted element, or c) assign null to the slot and change the classes to skip over null elements. (The last is probably a really bad idea ...)
Have MyIterator.remove() throw an UnsupportedOperationException. The remove method is an optional method according to the Iterator API spec.
Also what should happen in iterator() method of my main class ?
It should create and return an instance of the MyIterator class.

Take a look at java.util.ArrayList.

class MyCollection<T> implements List<T>{
T[] tab;
MyCollection(int len) {
tab = (T[])new Object[len];
}
public Iterator iterator(){
return new MyIterator(tab);
}
}
class MyIterator<T> implements Iterator {
private int current = 0;
private int last ;
private T[] tab;
public MyIterator(T[] tab){
this.tab = tab;
}
public void remove(){
throw UnsupportedException();
}
public T next(){
current ++ ;
return tab[current];
}
public boolean hasNext(){
current == tab.length - 1;
}
}

How about extending java.util.AbstractList? After all that's what all sun List implementations in java.util (but not in java.util.concurrent) do.
That way you only need to implement
get(int) and
add(E) (if you want to make the list mutable)
and some Constructors
You get all other methods (including iterator()) for free.