Re: Overloading abstract methods


"Chris Smith" <cdsmith@xxxxxxx> wrote in message
news:MPG.1e28cb6cd1a3b1b2989cf3@xxxxxxxxxxxxxxxxxxx
> Rhino <no.offline.contact.please@xxxxxxxxxx> wrote:
>> I've decided that my project, which writes my resume in a variety of
>> different formats - HTML, ASCII, PDF for starters - would benefit from an
>> abstract class. I'm calling this abstract class ResumeWriter. There will
>> be
>> one class for each each of the resume formats and each of these will
>> extend
>> ResumeWriter so I'm calling them ResumeWriterHtml, ResumeWriterAscii and
>> ResumeWriterPdf.
>
> Okay, you're only the seventeen gazillionth person to do this, but I'm
> picking on you.
>
> Why?!? Would it have killed you to call them HtmlResumeWriter,
> AsciiResumeWriter, and PdfResumeWriter? Have you ever asked a neighbor
> to borrow her mower-lawn?
>
> Anyway, just ignore me. Had to get that off my chest.
>
See my explanation in a followup to Roedy's first reply. It probably won't
persuade you but, then again, maybe it will :-)

>> This suggests to me that I need _two_ abstract methods called
>> writeEmploymentHistory(); one has only two arguments,
>> EmploymentHistoryText
>> and EmploymentHistoryData, while the other version also has the same two
>> arguments plus four additional arguments, FromToText, EmployerText,
>> RoleText, and MainToolsText. Now, I know that this is simply overloading
>> the
>> writeEmploymentHistory() method and that this is perfectly fine in an OO
>> program.
>>
>> The problem for me is that I apparently have to implement _both_ versions
>> of
>> writeEmploymentHistory() in each class that subclasses ResumeWriter, even
>> though only one of the two methods will be used in any given subclass of
>> ResumeWriter.
>
> There's no problem with giving an object more than it needs. What you
> want is, most fundamentally, one method called writeEmploymentHistory,
> which takes as parameters all of the information that might be useful
> for writing an employment history. Which information you choose to make
> use of in each subclass is up to you.
>
Okay, I guess I can buy that as a valid approach. But is it good design? If
I applied that same argument to other classes in the J2SE, then I'd probably
never overload _any_ method: I'd just combine all overloaded methods into a
single big method that had all possible parameters. I'd expect to get
criticized on the grounds that I'm discarding the benefits of overloaded
methods by doing that. Isn't that what you're proposing here? Or is this a
"special case" where that is okay?

>> One other small issue related to the main problem.
>
> Actually, it turns out I think this is more related to the problem than
> you may think.
>
>> In the version of the
>> overloaded method that I am NOT using, it seems to me that the easiest
>> thing
>> to do is just leave the method body empty with a comment that it is not
>> being implemented because it is not appropriate for this subclass.
>
> If you decide on this design against my recommendations, the better
> thing to do would be to throw an exception... an unchecked one, since
> this is a programming error.
>
>> However, if I do that, I get compiler warnings that the parameters for
>> that method are never used. I know I could disable those warnings in
>> the compiler but I'd rather avoid that
>
> Why? Disable that warning. That warning is counterproductive to good
> programming technique. It will cause you to do a worse job than if you
> leave it enabled.
>
> If the warning only warned about unused parameters for an entire
> hierarchy of types in unpublished APIs, then I could see its uses. What
> it's doing, though -- warning you for not using a parameter in one
> method when you ARE using it within that method signature in the type
> hierarchy -- is counterproductive, and encourages poor code... like this
> throw away "trick the compiler" nonsense you're asking for.
>
> I know it sounds like rehashing the same thing, but you're really
> providing a perfect example now of why you should NOT turn on random
> warnings just because some compiler vendor saw fit to give you the
> option (and leave it OFF by default). I imagine I could really make
> your life miserable by patching your copy of Eclipse to add an optional
> warning if you use more than 16 characters in an identifier.
>
>> and just put some sort of do-nothing code in the
>> method body to satisfy the compiler that the parameters are used, even if
>> the use is trivial. What is the most trivial thing I can do with each
>> parameter to satisfy the compiler that the parameter is being used?
>
> Is this Java 1.5? If so, @SuppressWarnings("unused").
>
Yes, it is Java 1.5.

> If it's not Java 1.5, and if you can't be dissuaded from doing this,
> then I guess you could declare a temporary variable of the same type,
> assign the value of the parameter to the parameter to that temporary
> variable, and then assign the temporary variable back to the parameter.
> Like this:
>
> public void myMethod(int unusued)
> {
> int tmp = unused;
> unused = tmp;
> }
>
> (The second bit is to prevent another warning about an unread local
> variable.)
>
> Then again, with any luck Eclipse will soon gain a warning for assigning
> to a parameter (which WOULD be a good one to leave on) and you'll
> trigger that one. Or its control flow will get smarter and you'll have
> to get more complex to trick it. Eventually, someone might get wise
> enough to use escape analysis for that warning, and then you'll be
> really snookered.
>
I'm actually not as determined to write do nothing code as you may think. I
was hoping someone could suggest a way to avoid that, first and foremost.
But I wanted a suggestion for the least offensive way of doing it if I had
to do it.

You make a good case for using the compiler switch to simply ignore unused
variables, at least in this case. I suppose I was looking for some bragging
rights in saying that I am not ignoring any warnings or errors and have an
absolutely warning-free compile. But I agree that this is just going to lead
to poor code in this case. And, as you say, the next version of the compiler
will probably find ways to detect any little tricks that I play on the
current version of the compiler and make me change the code eventually.

> Do you care about the standard output and error streams? I guess you
> could print the values there, and that would sure take care of it... but
> you'd get weird output if you ran the app from the command line.
>
Interesting. That's exactly what I came up with on my own: I just did a
System.out.println() of each parameter. I'm not even worried about the code
executing because the unused method simply isn't called anywhere within its
class. Of course, if I subclassed that class, there'd be the risk that the
subclass could execute it.

Rhino


.

Relevant Pages

  • Re: Overloading abstract methods
    ... I'm calling this abstract class ResumeWriter. ... > However, if I do that, I get compiler warnings that the parameters for ... Disable that warning. ...
    (comp.lang.java.programmer)
  • Re: Why INFINITE loop in a thread occupy so much CPU time??
    ... With the attendant warning about the constant expression. ... This is a common programming technique. ... Good programming practice would consist of using the compiler at ... One can write 'bool' in C++ but not C. ...
    (microsoft.public.vc.mfc)
  • Re: help needed please!
    ... But some compilers like to give you a warning ... Each warning a compiler can give you is important when you not ... but you may use flages to handle flags to handle flags when you ... >> stdout is line bufferd and until one or both of the following cases is ...
    (comp.lang.c)
  • Re: Why does this work?
    ... The compiler is able to tell the difference between the two by the context in which the word "color" is used. ... The point is that the compiler reads the original code as attempting to access a shared member of an instance. ... That's why the compiler is warning the programmer that it's not going to do what was coded. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Portability / compatibility issues
    ... I have posted my test code below, and the results I get on each compiler. ... The crux of the matter is that the 'strstr' function differs wildly in its behaviour on different platforms, and precious few man pages will actually provide a worked example of any function, let alone this one. ... I have had to write the "has_slash" function and use the reserved work SLASH already, to get around the problems that strstrgives me. ...
    (comp.lang.c)