0

I know that you could break down implementations of LinkedList into two categories. In one, the actuall LinkedList is a reference to the first of some linked Nodes, like this

public class LinkedList1<E>{

    class Node{
        E data;
        Node next;
    }

    Node head;

}

That version is probably better, but alternatively, there's a more 'direct' version, that makes things like deleting the head (head meaning the first element from the client's perspective) a bit trickier but still possible from within the instance of LinkedList2:

public class LinkedList2<E>{

    E data;
    LinkedList2 next;

}

I'm curious if there's any way to create LinkedList2Child extends LinkedList2 such that the next field is of type LinkedList2Child, perhaps involving reflection?

EDIT: this isn't preventing me from accomplishing anything since version 1 is available--I'm just curious about the problem in general, and this is an example.

I know that you can 'hide' fields in subclasses by declaring a field with the same name as the parent's field, but this won't work if you want to use parent methods that operate on that field.

user3391564
  • 576
  • 1
  • 5
  • 16
  • Why do you not want to use the first version? All you've done is eliminated the linked list and now you have just nodes, relegating the management of the list itself to the client code. This makes no sense. I think this is an XY problem... please explain the actual problem you're trying to solve that can't be solved with the Collection classes. – Jim Garrison Aug 27 '14 at 20:34
  • You don't have to relegate management to the client code. You could still implement add, delete, whatever from within the class. And it's not that I don't want to use the first version. It's probably better. I just want to know if extending the latter in the way I described is possible. – user3391564 Aug 27 '14 at 20:36

2 Answers2

1

Generics:

public class LinkedList2<E, T extends LinkedList2>{

    E data;
    T next;

}

public class LinkedSubclass extends LinkedList2<LinkedSubclass> {

}

It's subject to the usual restrictions on what you can do with generics (e.g. constructing new "next" values in the base class would require taking in the child type's class, or a factory), but would cover what you want.

Sbodd
  • 11,279
  • 6
  • 41
  • 42
0

This is called co-variance (or co-variant return types):

public static abstract class A
{
    public A get() { ... }
}

public static abstract class B extends A
{
    @Override
    public B get() { ... }
}

Method B#get() overrides A#get(). This is orthogonal (i.e. is conceptually unrelated) to generics.

Jim Garrison
  • 85,615
  • 20
  • 155
  • 190
  • I didn't think it was related to generics. I'm not sure I see how this allows for effectively having an instance of a subclass inside the subclass instead of an instance of the parent class. What if I had a binary tree and create a self-balancing binary tree subclass that overrides insert with an insert that performs balancing operations. When insert is recursively called in a subtree of a self-balancing tree, that subtree also needs to perform balancing operations, and therefore needs to be an instance of the self-balancing subclass. – user3391564 Aug 27 '14 at 21:10