Code

Illustration

class EmptyNode extends ANode {
/**
* The owner becomes non-empty and 
* has dat as its first element.
*/
LRStruct insertFront(Object dat, LRStruct owner) {
    return owner.setHead(new NENode(dat, new LRStruct(this)));
}

class NENode extends ANode {
    private Object _dat;
    private LRStruct _tail;

/**
* Initializes this NENode to contain dat and a given tail list.
* @param dat the data object to be stored in this NENode.
* @param tail the LRStruct tail of this NENode.
*/
NENode(Object dat, LRStruct tail) {
    _dat = dat;
    _tail = tail;
}

/**
* Inserts a data object at the front of the LRStruct owner.
* @param dat the object to be inserted at the front.
* @param owner the LRS referencing this NENode.
*/
LRStruct insertFront(Object dat, LRStruct owner) {
    return owner.setHead(new NENode(dat, new LRStruct(this)));
    /* Details:
    LRStruct coOwner = new LRStruct (this);
    NENode newNode = new NENode (dat, coOwner);
    return owner.setHead (newNode);
    "old" style: owner._head = newNode - cannot be done here.
    */
}


}

Comment 1: Proper initialization of an object is crucial in program correctness.
The package-private constructor LRStruct( ANode n) { _head = n;} serves to initialize an LRStruct to a particular state.
It  is not absolutely necessary to define such a constructor.  

The call
new LRStruct(n);
can be replaced by a call to LRStruct() followed by a call to setHead(ANode n):
new LRStruct().setHead(n);

However, it is a good programming practice to have an object completely initialized when it is defined, and have all initialization code done in one place.
Such a practice eliminates the prospect of  "forgetting" to initialize and/or improperly initializing an object.

Comment 2: We intentionally make the code for insertFront(...) for both EmptyNode and NENode look identical.
This begs the question, "why don't we just factor it up to the abstract ANode class, making its insertFront(...) method concrete, and thus eliminating code duplication in the concrete subclass?".

Doing so would make the abstract class ANode "aware" of a specific concrete variant, NENode, and prevent us from hiding (and perhaps changing) the details of implementation from external client code, and thus violating the principle of information hiding.

As a general OO programming principle, never make a super class aware of any of its subclasses.
Doing so is tantamount to saying that the super class is not an abstraction of the subclasses.

class NENode extends ANode {

Object removeFront(LRStruct owner) {
    owner.setHead(_tail.getHead()); // owner._head = _tail._head
    return _dat;
}

// other methods elided...
}

Non Object-Oriented Thinking (NOOT)

Object-Oriented Thinking (OOT)

The above algorithm seems straightforward and simple enough. It involves imposing an external control structure to traverse an LRStruct and stop at some appropriate point.  As illustrated in a subsequent section, such an algorithm is usually implemented in terms of a loop whose exit condition involves checking an LRStruct for emptiness!

1. which object should be  responsible for determining whether or not the host's first is the last element?
2. which object should be responsible for removing the last element?  

The host's rest knows whether or not itself is empty, and thus can determine whether or not the host's first is actually the last element.  Therefore the responsibility for determining whether or not the host is holding the last element should be delegated to the host's rest.

Though the host's rest knows whether or not the host holds the last element, it cannot remove that element.  The only object capable of removing this element is the host itself.

So knowing when to remove does not necessarily means capable of the task of removal.  In general, knowing when some action must take place does not mean capable of carrying out that action.  These are two distinct responsibilities that need to be distributed to two cooperating objects.

The above OO thought process leads to the idea of decomposing the task of removing the last element into two subtasks.

1. Ask the host's rest for help in determining whether or not the host is holding the last element.  When asking for help, the host will need to pass itself as a parameter to the helper task so that once the last element is discovered, it can then be removed.
2. Help the preceding LRStruct remove its last element.  When helping the preceding (non-empty) LRStruct to remove an element, an empty LStruct simply tells the given LRStruct to remove its first, while a non-empty LRStruct will ask its rest for help to remove its last element passing itself as a parameter.

Note that the above algorithm involves no notion of list traversal at all.  It entails decomposing the original task into smaller subtasks ("divide-and-conquer") and is only expressed in terms of which objects should be doing what and what pieces of information must be passed to each object's method in order to carry out each of the subtasks.

OOP calls for thinking in terms of  problem abstraction, task decomposition, and delegation of responsibilities.  It is a paradigm shift that emphasizes design and promotes a different way of thinking about formulating and solving problems.

Non Object-Oriented Algorithm (NOOA)

Non Object-Oriented Coding (NOOC)

public class IsEmpty implements IAlgo {
  // Singleton
  public Object emptyCase(LRStruct host, Object inp) {
    return Boolean.TRUE;
  }

  public Object nonEmptyCase(LRStruct host, Object inp) {
    return Boolean.FALSE;
  }
}

If the LRStruct is not empty, traverse the LRStruct until the empty LRStruct is reached, at which point ask the preceding LRStruct to remove its first. 

/**
* Static method of some class.
*/
public static void removeLast(LRStruct list) {
  if (((Boolean)list.execute(IsEmpty.Singleton), null)).booleanValue()) {
    throw new java.util.NoSuchElementException("Empty list has no data.");
  }
  LRStruct next = list.getRest();  
  while (!((Boolean)next.execute(IsEmpty.Singleton), null)).booleanValue()) {
    list = next;
    next = list.getRest();
  }
  list.removeFront();
}

Though the high level description of the algorithm seems simple enough, its translation into code is not that simple.

It is not apparent that the code is a faithful (and correct) translation of the algorithm statement because it involves a lot of tedious book-keeping and flow control programming constructs.

Object-Oriented Algorithm (OOA)

Object-Oriented Coding (OOC)

public class RemLast implements IAlgo {
  // Singleton

  public Object emptyCase(LRStruct host, Object inp) {
    throw new java.util.NoSuchElementException("Empty list has no data.");
  }

When the LRStruct host is not empty, ask the host's rest for help in determining whether or not the host is holding the last element, passing the host as a parameter just in case this is true and the last element needs to be removed.

  public Object nonEmptyCase(LRStruct host, Object inp) {
    return host.getRest().execute(RemLastHelp.Singleton, host);
  }
}

public class RemLastHelp implements IAlgo {
  // Singleton

  /**
  * @param inp the LRStruct preceding host.
  */  
  public Object emptyCase(LRStruct host, Object inp) {
    return ((LRStruct)inp).removeFront();
  }

  /**
  * The last element of the (non-empty) host is the
  * last element of inp, the LRStruct preceding host.
  */
  public Object nonEmptyCase(LRStruct host, Object inp) {
    return host.getRest().execute(this, host);
  }
}

The implementation code for the OO algorithm directly maps to the abstract high-level description of the algorithm and can be easily proved to be correct.

It is "declarative" in nature.  It does not involve any conditional to specify when to perform certain task.  It simply states what needs to be done for each state of the host LRStruct.  Polymorphism is put to use to direct all flow control reducing code complexity.