Re: calling own methods from constructor
On 4/6/2011 6:06 PM, Tom Anderson wrote:
On Wed, 6 Apr 2011, Andreas Leitgeb wrote:
Is there any *good* use of having the constructor call a method that
actually *can* be overridden in a subclass? I mean, are there
(non-anti)patterns of explicitly allowing subclasses to hook into
base-class's construction?
public abstract class Library {
private List<Document> documents;
protected Library() {
documents = new ArrayList<Document>();
Collection<String> titles = listDocuments();
for (String title: titles) {
Document doc = loadDocument(title);
// do other preparatory stuff with the document
documents.add(doc);
}
}
protected abstract Collection<String> listDocuments();
protected abstract Document loadDocument(String title);
}
public class FilesystemLibrary extends Library {
// ...
}
public class WebDavLibrary extends Library {
// ...
}
public class JCRLibrary extends Library {
// ...
}
What are the alternatives?
Safer ones, I hope. This code presupposes that the subclass
instance can do useful work before its constructor finishes -- to
put it another way, it assumes that the subclass constructor does
absolutely nothing except call the superclass constructor (and even
that much requires some leaps of faith).
How might Java ensure such an assumption? I can't imagine how
it could be done at compile time, when the suite of subclasses may
not even exist to be inspected. At run time, I guess it could be
done with two additional bits per instance: One that says "The
constructor has not yet returned" and another that says "A virtual
method has been called while the constructor is active." Each
virtual method would copy the first bit to the second, and if the
constructor found the second bit set while doing anything other
than a "return," it could throw an exception.
The obvious one is for the subclass constructor to prepare all the
objects and pass them upward; i think that is likely to lead to a lot of
duplication of effort.
The almost as obvious one is to push the abstract methods out into a
separate interface - DocumentStore, say - and have the subclass
constructor pass up an instance of that.
You could also push the repeated logic out into some sort of factory or
helper, and have the subclasses call that, rather than relying on code
in the supeclass, but that is repetitive, and does nothing to establish
invariants in the superclass.
It seems to me the constructor is doing too much of the heavy
lifting. A Library(Collection<Document>) constructor, with the
Documents already loaded or maybe with "load on first use" flags,
seems a more tenable approach. In particular, it allows the
subclass constructors to choose their own sets of exceptions to
throw, instead of requiring that they all extend exceptions thrown
by the superclass' abstract method declarations.
--
Eric Sosman
esosman@ieee-dot-org.invalid