He visto esto subir algunas veces, pero en las publicaciones que he visto, nadie me lo explicó. ¿Por qué no debería extender JFrame (o cualquier componente)? ¿Hay condiciones en las que debería extender un componente, o es esta una regla firme que usted no?¿Por qué no debería extender JFrame y otros componentes?
En términos generales, extender el componente tiende a hacerse estrictamente para utilizar el componente. Esto limita severamente sus opciones de forma innecesaria en términos de diseño, de modo que sus clases no pueden extender diferentes clases, no puede ocultar los métodos de JFrame, lo que hace que sea más difícil de mantener y más fácil de desencadenar errores inesperados al usar la clase .
Normalmente, la intención es utilizar estrictamente la clase para dibujar un marco, y se prefiere la composición sobre la herencia.
Dicho esto, las subclases deberían estar bien cuando pretenda que su subclase agregue funcionalidad específica del proyecto al Marco (como métodos de conveniencia y similares) donde se usaría la subclase en lugar del Marco en sí, pero se usaría como un marco en general, no como una vista de un marco específico en la aplicación.
Si su aplicación REALMENTE es solo un JFrame, prosiga y amplíelo. Sin embargo, es mejor usar composición de objetos en lugar de herencia si simplemente es usando un JFrame.
Si su objeto se extiende a algún otro objeto no tendría otra opción en el asunto, como un ejemplo.
No veo el problema mientras amplíe la clase y pueda conservar los aspectos "is-a" de la herencia.
Cuando extiende un JPanel pero su nuevo objeto no es una verdadera especialización de JPanel, es allí donde tiene problemas. Pero si creas un nuevo SpeciallyFormattedJLabel que se extiende a JLabel, no veo ningún problema con eso.
Prefiere la composición sobre la herencia. Todas las razones usuales. La composición fuerza menos dependencias entre el código.
Swing, y evento AWT, los componentes son horriblemente complicados. No quieres meterme en ese lío. Puede anular los métodos accidentalmente. En los casos en los que es necesario anular los métodos, es difícil ver dónde se hace eso si se trata de un código normal.
isValid es un clásico para anular accidentalmente – willcodejavaforfood
Sé que esta es una publicación anterior, pero me encontré con ella y tengo que decírtelo ... extendiendo mis opciones limitadas de llamar a ciertas acciones del objeto. En realidad estoy reescribiendo algunas partes del código ahora para deshacerme del daño que me ha causado extender. A menos que esté escribiendo un programa de un solo archivo, no voy a usar extended nuevamente.
De acuerdo. Esto es swing, tienes que extender los componentes para obtener el comportamiento de la pintura. – akarnokd
@ kd304 * "para obtener el comportamiento de la pintura." * Podemos hacer 'comportamiento de la pintura' en una 'Imagen Buffered' .. –