2011-09-14 17 views
8

Ho letto il tutorial Overriding and Hiding Methods. E da questo, ho raccolto la seguente:Nascondere i metodi della superclasse

Se una sottoclasse definisce un metodo di classe con la stessa firma come metodo classe nella superclasse, il metodo nella sottoclasse pelli il uno nella superclasse.

Come tale, ho fatto la seguente:

import javax.swing.JTextArea; 

public final class JWrappedLabel extends JTextArea{ 
    private static final long serialVersionUID = -844167470113830283L; 

    public JWrappedLabel(final String text){ 
     super(text); 
     setOpaque(false); 
     setEditable(false); 
     setLineWrap(true); 
     setWrapStyleWord(true); 
    } 

    @Override 
    public void append(final String s){ 
     throw new UnsupportedOperationException(); 
    } 
} 

Quello che non mi piace di questo progetto è che è ancora un append visibile metodo della sottoclasse . Invece di lanciare il UnsupportedOperationException, avrei potuto lasciare il corpo vuoto. Ma entrambi si sentono brutti.

Detto questo, esiste un approccio migliore per nascondere i metodi della superclasse?

+2

solo per dare enfasi (@Simone ha la risposta completa): si ** non ** deve metodi di override di una superclasse senza rispettare il suo contratto. A proposito, la frase che hai citato riguarda i metodi _class_ mentre si esegue l'override di un metodo _instance_ qui. – kleopatra

+0

@kleopatra, ho segnato la risposta che ho fatto perché sentivo che questa domanda non avrebbe più attirato l'attenzione. Continuo a non ritenere che questa domanda abbia avuto una risposta sufficiente. Forse potresti fornirne uno tuo? Sembri essere informato! : D – mrkhrts

+0

so che la domanda è vecchia ma ho appena trovato questo così ... Io normalmente uso il tuo modo di fare questo, una cosa che faccio anche è di sovrascrivere i metodi come finale in modo che la classe non possa essere estesa a abilitare determinate funzionalità come accoda. –

risposta

11

Utilizzare la composizione, se possibile. Questo è raccomandato da Joshua Bloch nel Effective Java, Second Edition.

Articolo 16: composizione favore per l'eredità

Ad esempio:

import javax.swing.JTextArea; 

public final class JWrappedLabel { 
    private static final long serialVersionUID = -844167470113830283L; 

    private final JTextArea textArea; 

    public JWrappedLabel(final String text){ 
     textArea = new JTextArea(text); 
     textArea.setOpaque(false); 
     textArea.setLineWrap(true); 
     textArea.setWrapStyleWord(true); 
    } 

    //add methods which delegate calls to the textArea 
} 
+0

+1, apprezzo il suggerimento, anche se questo non è davvero desiderabile. Ha senso, ma poi non sarò in grado di aggiungere un'istanza 'JWrappedLabel' direttamente ad un contenitore. Invece, dovrò interrogare l'oggetto per la sua area di testo, che davvero non voglio fare. Ma se la composizione è l'unica altra alternativa, preferirei fare eccezioni. Ad ogni modo, sembra che la soluzione finale sarà piuttosto brutta. :/ – mrkhrts

+1

L'unica cosa che aggiungere è implementare un'interfaccia che consente di aggiungere JWrappedLabel a un contenitore. Ciò risolverà il problema che mrkhrts ha notato sopra. –

+0

@James DW, ci penserò, grazie! : D – mrkhrts

3

No, che io sappia.

È un problema/funzionalità OOP. La classe è ancora UN JTextArea, e come tale potrebbe essere usata dal codice inconsapevole della sottoclasse che la tratterà come JTextArea, aspettandosi che tutto il metodo in JTextArea sia presente e funzioni correttamente.

Se è necessario definire una nuova interfaccia, è necessario definire una nuova classe che non estende JTextArea ma invece lo incapsula.

Problemi correlati