Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #28447

Re: @java.lang.DontOverride

From Daniel Pitts <newsgroup.nospam@virtualinfinity.net>
Newsgroups comp.lang.java.programmer
Subject Re: @java.lang.DontOverride
References <override-20140511031054@ram.dialup.fu-berlin.de> <lkmkeg$qko$1@dont-email.me>
Message-ID <1K5cv.7545$s87.2913@fx11.iad> (permalink)
Date 2014-05-12 08:25 -0700

Show all headers | View raw


On 5/10/14 6:40 PM, markspace wrote:
> On 5/10/2014 6:16 PM, Stefan Ram wrote:
>> class Example extends javax.swing.JComponent
>> { public boolean isValid(){ return true; }}
>>
>>    I do not want to override any method of JComponent with my method.
>>    I just want to add a new method. But now or in future versions of
>>    Swing there might be an »isValid« method in JComponent.
>
[snip]
> Moreover, I find your request questionable.  How do you know what
> methods should never ever be overridden in future classes?  How do you
> know someone won't make a new interface for JComponent, some
> ImprovedJComponent, where the "isValid()" method needs to be overridden
> by the new classes?  It's too hard to predict the future like this. Just
> require that your coders learn to read, and especially test, their code
> and problems like this become manageable.
I think his point is that if "isValid" becomes a member of JComponent, 
he wants a compiler error so that he knows his implementation may now 
have different semantics than intended.  This is to say "My code is now 
broken because of an interface change in JComponent."  That is a 
reasonable thing to want to know.
>
> The keyword "final" is there for the correct behavior of the current
> class;  that's something you can reasonable predict.  Leave the correct
> behavior of future classes to future coders.
This is for defining a class that is to be extended, not for defining 
the extending class.


Stefan, I think the real answer is "Don't add non-private methods to 
your JComponent extension."  Instead, create a different class that 
provides a JComponent object (perhaps a getComponent() method). All of 
the "business" logic that affects the component will live in your 
non-component class, or in the appropriate standard methods of your 
component class.



HTH,
Daniel.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: @java.lang.DontOverride markspace <markspace@nospam.nospam> - 2014-05-10 18:40 -0700
  Re: @java.lang.DontOverride Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-05-12 08:25 -0700
    Re: @java.lang.DontOverride markspace <markspace@nospam.nospam> - 2014-05-12 10:11 -0700
    Re: @java.lang.DontOverride Sarah Connor <s.connor@gmail.invalid> - 2014-05-14 17:12 +0000
      Re: @java.lang.DontOverride markspace <markspace@nospam.nospam> - 2014-05-14 10:18 -0700

csiph-web