Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: calling own methods from constructor Date: Wed, 06 Apr 2011 20:46:04 -0400 Organization: A noiseless patient Spider Lines: 79 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 7 Apr 2011 00:49:19 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="KiwfXDyOjqGhZBXcfNnZBg"; logging-data="24514"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198T90CFyFzs+mHFDg5tLfV" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: Cancel-Lock: sha1:38ZtmehX5wqailqJwE9eqG3jUhM= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2908 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 documents; > > protected Library() { > documents = new ArrayList(); > Collection titles = listDocuments(); > for (String title: titles) { > Document doc = loadDocument(title); > // do other preparatory stuff with the document > documents.add(doc); > } > } > > protected abstract Collection 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) 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