2011-09-14 15 views
8

He leído el tutorial Overriding and Hiding Methods. Y a partir de eso, se reunieron los siguientes:Ocultando los métodos de la superclase

Si una subclase define un método de la clase con la misma firma como método clase en la superclase, el método en la subclase cueros la una en la superclase.

Como tal, hice lo siguiente:

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(); 
    } 
} 

Lo que no me gusta de este diseño es que append es todavía visible método de la subclase . En lugar de arrojar el UnsupportedOperationException, podría haber dejado el cuerpo vacío. Pero ambos se sienten feos.

Dicho esto, ¿hay un mejor enfoque para ocultar los métodos de la superclase?

+2

simplemente para dar énfasis (@Simone tiene la respuesta completa): usted ** ** no deben métodos de anulación de una superclase sin cumplir su contrato. Por cierto, la oración que citó trata sobre los métodos de _clase_ mientras reemplaza un método _instance_ aquí. – kleopatra

+0

@kleopatra, marqué la respuesta que hice porque sentí que esta pregunta no iba a atraer más atención. Todavía no creo que esta pregunta haya sido suficientemente respondida. ¿Tal vez podría proporcionar uno propio? ¡Pareces estar bien informado! : D – mrkhrts

+0

, sé que la pregunta es vieja, pero acabo de encontrar esto, así que ... Normalmente utilizo tu forma de hacer esto, una cosa que también hago es anular los métodos como finales para que la clase no se pueda extender a habilitar ciertas funciones como agregar. –

Respuesta

11

Usar composición, si es posible. Esto es recomendado por Joshua Bloch en Effective Java, Second Edition.

Artículo 16: Composición favor sobre la herencia

Por ejemplo:

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, agradezco la sugerencia, aunque esto no es realmente deseable. Tiene sentido, pero luego no podré agregar una instancia 'JWrappedLabel' directamente a un contenedor. En cambio, tendré que consultar el objeto por su área de texto, lo cual realmente no quiero hacer. Pero si la composición es la única alternativa, preferiría lanzar excepciones. De cualquier manera, parece que la solución final será bastante fea. :/ – mrkhrts

+1

Lo único que agregaría es implementar una interfaz que le permita agregar JWrappedLabel a un contenedor. Eso resolverá el problema que mrkhrts ha señalado anteriormente. –

+0

@James DW, lo investigaré, gracias! :RE – mrkhrts

3

No, que yo sepa.

Es un problema/función OOP. Tu clase todavía ES una JTextArea, y como tal podría ser utilizada por un código que desconoce tu subclase, que la trataría como una JTextArea, esperando que todo el método en JTextArea esté allí y funcione correctamente.

Si necesita definir una nueva interfaz, debe definir una nueva clase que no extienda JTextArea sino que la encapsule.

Cuestiones relacionadas