Okay, so what are you saying I should do to prevent these problems? I know
the compiler will not let me make writeEmploymentHistory() (within
ResumeWriterAscii) a private method because it is public in the abstract
class and the implementation can't have less access than the abstract
version. I know the compiler will only let me make the method public or
protected in the abstract class. I _can_ make writeEmploymentHistory() final
within ResumeWriterAscii; is that what you are suggesting? I don't plan on
subclassing ResumeWriterAscii or its siblings any further so I don't have a
problem with making the writeXXX() implementations final.

With regards to your docType example, I wasn't aware that docType would be
uninitialized in that case. Frankly, it rather surprises me that docType
would be uninitialized in this case, given that docType is a class variable
in the class. Why exactly does Java behave that way? Would I be safe in
assuming that a compiler warning would bring this to my attention?

Am I correct in thinking that you are warning me against setting a class
variable based on a value passed in the parameter of a constructor?

My actual ResumeWriterAscii class, and its siblings, pass only two values to
their constructors: a String containing the name of the file that is to be
written and a ResourceBundle that contains the data used by the class. Both
of these values are not assigned to any class variables, are used only in
the constructor and are not passed explicitly to any other method of the
class. I also have several class variables in ResumeWriterAscii: all but two
of them are constants used throughout the class for formatting. The other
two class variables are:

   private StringUtils stringUtils = null;
   private PrintWriter pw = null;

They get set to useful values in the constructor and are then used
throughout the class. I'm not going to have any problems with any of that,
am I? The compiler is not giving me any errors or warnings anywhere in my
project.

Hmmm, just out of curiousity, I made a class variable called strOutfile
which was defined as a private String and initialized to null. Then, within
my constructor, I added this line:

   this.strOutfile = strOutfile;

I also added this line to writeEmploymentHistory():

   System.out.println("strOutfile: " + this.strOutfile); //$NON-NLS-1$

The compiler flags 'strOutfile' within my constructor signature ['public
ResumeWriterAscii(String strOutfile, ResourceBundle locList)'] and gives me
this warning: "The parameter strOutfile is hiding a field from type
ResumeWriterAscii." That's fair enough since the strOutfile value passed in
via the constructor will inevitably clobber the value of the strOutfile
class variable. But I get no warnings or errors about strOutfile being
uninitialized in writeEmploymentHistory() even though it now parallels the
docType example you gave. I assume that's why you brought that to my
attention: since the compiler gives no warning, I can easily fail to notice
this problem.

You're right; I do think of my ResumeWriter subclasses as Option 2.

Could you elaborate on what you mean by your last sentence? Are you saying
that I am doing the right thing in storing the values obtained by the
getters in local variables and then passing them to  their respective
writers? Do the implementations of the writeXXX methods which appear in my
ResumeWriter subclasses constitute the protected APIs that you are
recommending? Or are you proposing something else?

Rhino

Though I'd argue that (1) is in general inferior to (2).  It depends on cases,
of course, but usually (2) is simpler to use and think about, easier to
implement, and more flexible.  So I'd recommend (2) as the norm, with (1) as an
alternative to use in the (relatively rare) cases where it turns out to be more
appropriate.

   -- chris

The other thing (the more important thing, in fact) that the abstract
superclass is doing is to call methods to write the pieces of the
resume.  A method like "writeResume" would exist in the parent, and it
calls overridden methods to write each section in turn.

Forgive me for taking so long to respond to this suggestion as I have; I've
been trying to understand and use the suggestions of Chris Smith and Chris
Uppal and have only now gotten around to your remarks.

Your main observation makes a lot of sense: "It seems like the only thing
Rhino's abstract super class does is provides a unified way of reading the
data." That is exactly the case: I _am_ using my abstract superclass to get
data from my ResourceBundle via a bunch of getters; the write methods are
all abstract and each one is implemented differently in the classes that
write the Resumes.

Your suggestions for a redesign follow logically from that observation. I
think it makes perfect sense to make the abstract ResumeWriter into a class
called ResumeData that contains only the getters and handle the writing via
a different mechanism, an interface. I looked at your pseudocode and found
myself somewhat unclear over exactly what you meant in some places; at first
glance, it seemed you'd left a fair bit to my imagination and I have an
(over?) active imagination :-)

But I knocked together the code you described and got it to work after a bit
of trial and error. I even think I understand it. So now I'm going to try to
describe it back to you (and anyone else who is still watching this thread)
and make sure that I have written the code as you intended and that I
understand how it works correctly.

Okay, let's start with ResumeData. I simply copied abstract class
ResumeWriter to a new concrete class called ResumeData and deleted all of
the abstract writeXXX methods.

Here is a brief excerpt of the class with the package statement and all Java
and Javadoc comments removed for brevity:

------------------------------------------------------------------------------------------------------------
import java.util.ResourceBundle;

public class ResumeData {

   private ResourceBundle resourceBundle;

   public ResumeData(ResourceBundle resumeResourceBundle) {
       this.resourceBundle = resumeResourceBundle;
   }

   public String getCandidateNameData() {
       String candidateNameData =
this.resourceBundle.getString("CandidateNameData");
       return candidateNameData;
   }

   public String[] getCandidateAddressData() {
       String[] candidateAddressData = (String[])
this.resourceBundle.getObject("CandidateAddressData");
       return candidateAddressData;
   }
}
------------------------------------------------------------------------------------------------------------

Now, I'm afraid that the only interfaces I've written for myself contain
only constants; I've never written any methods in my interfaces before. But
I dug into some reference material to find out the rules for methods in
interfaces and found that they are always public and abstract, just like the
writeXXX methods had been in the abstract ResumeWriter class. Now, to
prevent any confusion with other parts of this thread, I decided to name the
interface that you call ResumeWriter in your pseudocode
"ResumeWriterInterface"; that should make it crystal clear that I'm _not_
referring to the abstract ResumeWriter class.

So, here's the code for that interface, again with the package statement and
all comments removed:

------------------------------------------------------------------------------------------------------------
public interface ResumeWriterInterface {

   public void write(ResumeData resumeData);
}
------------------------------------------------------------------------------------------------------------

Okay, so now I only need to implement ResumeWriterInterface in each class
that writes a resume. That class will be free to write whatever data it
wants, as long as it comes from ResumeData, in whatever format it likes. It
will be able to choose any subset of that data and therefore write as much
or as little of the information as it wants.

I created a new version of ResumeWriterAscii called ResumeWriterAscii2 to
write the resume this new way.

Here is an excerpt of the code, again omitting the package statement,
comments, for brevity. I've also omitted most of the writeXXX methods since
the ones I've shown are enough to demonstrate what I'm doing so that you can
tell me if I'm doing the right things:
------------------------------------------------------------------------------------------------------------

import java.io.PrintWriter;
import java.util.ResourceBundle;

public class ResumeWriterAscii2 implements ResumeWriterInterface {

   private PrintWriter printWriter = null;

   public ResumeWriterAscii2(String outfile, ResourceBundle resourceBundle)
{

       ResumeUtilities.deleteFile(outfile);
       this.printWriter = ResumeUtilities.openOutputFile(outfile);
       ResumeData resumeData = new ResumeData(resourceBundle);
       write(resumeData);
       ResumeUtilities.closeOutputFile(this.printWriter);
   }

   public final void write(ResumeData resumeData) {

       writeCandidateAndTarget(resumeData.getCandidateNameData(),
               resumeData.getCandidateAddressData(),
               resumeData.getJobTargetText(),
resumeData.getJobTargetData());
       writeEmploymentHistory(
               resumeData.getEmploymentHistoryText(),
resumeData.getEmploymentHistoryData());
       writeEducationAndEmployability(
               resumeData.getFormalEducationText(),
resumeData.getFormalEducationData(),
               resumeData.getRecentEducationText(),
resumeData.getRecentEducationData(),
               resumeData.getEmployabilityText(),
resumeData.getEmployabilityData());
       writeSoftwareSkills(resumeData.getAddendumText(),
               resumeData.getOsText(), resumeData.getOsData(),
               resumeData.getComputerLanguagesText(),
resumeData.getComputerLanguagesData(),
               resumeData.getDatabasesText(),
resumeData.getDatabasesData(),
               resumeData.getWordProcText(), resumeData.getWordProcData(),
               resumeData.getEditorsText(), resumeData.getEditorsData(),
               resumeData.getOtherToolsText(),
resumeData.getOtherToolsData());
       writeOtherExperience(resumeData.getExperienceText(),
resumeData.getExperienceData());
       writeImportantNote(resumeData.getNoteData());
   }

   public final void writeCandidateAndTarget(String candidateNameData,
String[] candidateAddressData, String jobTargetText, String jobTargetData) {

       this.printWriter.println(this.stringUtils.wrap(candidateNameData.toUpperCase(),
ResumeWriterAscii2.DELIMS, ResumeWriterAscii2.LINE_WIDTH,
ResumeWriterAscii2.INDENT1, ResumeWriterAscii2.INDENT2_NORMAL,
ResumeWriterAscii2.BLANK_LINES_BEFORE_0,
ResumeWriterAscii2.BLANK_LINES_AFTER_1));
       for (String candidateAddressLine : candidateAddressData) {
           this.printWriter.println(candidateAddressLine);
       }
       this.printWriter.println(this.stringUtils.wrap(jobTargetText + ": "
+ jobTargetData, ResumeWriterAscii2.DELIMS, ResumeWriterAscii2.LINE_WIDTH,
ResumeWriterAscii2.INDENT1, ResumeWriterAscii2.INDENT2_NORMAL,
ResumeWriterAscii2.BLANK_LINES_BEFORE_1,
ResumeWriterAscii2.BLANK_LINES_AFTER_2));
   }

}

------------------------------------------------------------------------------------------------------------

ResumeWriterAscii2 implements ResumeWriterInterface but doesn't extend
anything. It gets an instance of ResumeData in its constructor, then passes
it to the implemenation of the write() method which was defined in the
interface. The write() method implementation uses the getters in the
ResumeData class to obtain the information that is being written to the
resume. The writeXXX methods in ResumeWriterAscii2 simply write the desired
information to the file in the desired format, ASCII in this case.

The other file writer classes, ResumeWriterPdf2 and ResumeWriterHtml2, would
have identical constructors to ResumeWriterAscii2. Their write() methods
might vary somewhat; for example, ResumeWriterHtml2 will obtain a little bit
more information from ResumeData, namely the "From/To", "Employer", "Role",
and "Main Tools" strings. The writeXXX methods would take whatever data was
obtained in the write() method and write it to the file in whatever format
was desired.

So, have I understood you correctly? Is that basically what you intended?

Assuming it is, I have one followup question.

As I was writing ResumeWriterAscii2, it occurred to me that it could be
defined a little differently and still work just fine; in fact, the code
would actually get just a little more concise. The problem is that I'm not
sure if this alternate approach would be better or worse from a design point
of view. The alternate method is quite simple: make ResumeWriterAscii2
extend ResumeData _and_ implement ResumeWriterInterface.

------------------------------------------------------------------------------------------------------------

import java.io.PrintWriter;
import java.util.ResourceBundle;

public class ResumeWriterAscii2 extends implements ResumeWriterInterface {

   private PrintWriter printWriter = null;

   public ResumeWriterAscii2(String outfile, ResourceBundle resourceBundle)
{

       super(resourceBundle); //new line
       ResumeUtilities.deleteFile(outfile);
       this.printWriter = ResumeUtilities.openOutputFile(outfile);
//      ResumeData resumeData = new ResumeData(resourceBundle); //no longer
needed
//      write(resumeData); //replace with following line
      write(); //new version of the previous line
       ResumeUtilities.closeOutputFile(this.printWriter);
   }

//    public final void write(ResumeData resumeData) { //replace with the
following line
     public final void write() { //new version of the previous line

/* no longer need 'resumeData.' in front of each getter */

       writeCandidateAndTarget(getCandidateNameData(),
               getCandidateAddressData(),
               getJobTargetText(), getJobTargetData());
       writeEmploymentHistory(
               getEmploymentHistoryText(), getEmploymentHistoryData());
       writeEducationAndEmployability(
               getFormalEducationText(), getFormalEducationData(),
               getRecentEducationText(), getRecentEducationData(),
               getEmployabilityText(), getEmployabilityData());
       writeSoftwareSkills(getAddendumText(),
               getOsText(), getOsData(),
               getComputerLanguagesText(), getComputerLanguagesData(),
               getDatabasesText(), getDatabasesData(),
               getWordProcText(), getWordProcData(),
               getEditorsText(), getEditorsData(),
               getOtherToolsText(), getOtherToolsData());
       writeOtherExperience(getExperienceText(), getExperienceData());
       writeImportantNote(getNoteData());
   }

   public final void writeCandidateAndTarget(String candidateNameData,
String[] candidateAddressData, String jobTargetText, String jobTargetData) {

       this.printWriter.println(this.stringUtils.wrap(candidateNameData.toUpperCase(),
ResumeWriterAscii2.DELIMS, ResumeWriterAscii2.LINE_WIDTH,
ResumeWriterAscii2.INDENT1, ResumeWriterAscii2.INDENT2_NORMAL,
ResumeWriterAscii2.BLANK_LINES_BEFORE_0,
ResumeWriterAscii2.BLANK_LINES_AFTER_1));
       for (String candidateAddressLine : candidateAddressData) {
           this.printWriter.println(candidateAddressLine);
       }
       this.printWriter.println(this.stringUtils.wrap(jobTargetText + ": "
+ jobTargetData, ResumeWriterAscii2.DELIMS, ResumeWriterAscii2.LINE_WIDTH,
ResumeWriterAscii2.INDENT1, ResumeWriterAscii2.INDENT2_NORMAL,
ResumeWriterAscii2.BLANK_LINES_BEFORE_1,
ResumeWriterAscii2.BLANK_LINES_AFTER_2));
   }

}

------------------------------------------------------------------------------------------------------------

Naturally, you also need to change the definition of the write() method in
the ResumeWriterInterface() so that it doesn't expect any parameters.

So, is that variation any better or worse than what you originally proposed?
If so why?

By the way, the approach you have suggested inadvertently solves another
problem that I've been struggling with for the last while! I also have an
applet that displays my resume but I was having a heck of a time trying to
figure out how it could take advantage of the original abstract ResumeWriter
class. That's because it doesn't write to a file: it creates GUI components
and displays them in an applet; therefore the writerXXX methods don't apply
to the applet. Since an applet has to subclass JApplet, I was at a loss in
how to use ResumeWriter with the applet. Now that I have a concrete
ResumeData class, I can simply use it to gather the data that I need, then
use the existing methods within the applet to turn that data into GUI
components without having to access the ResourceBundle directly in the
ResumeApplet class.

Therefore, you've killed two birds with one stone, which is pretty good
considering you didn't even know that the second bird even existed :-)

P.S. I'm copying you via email, Oliver, in case you've wandered away from
this thread. I just want to make sure you get my thanks for pointing out an
even better solution to my problem!

Rhino