J'ai vu ça arriver quelques fois, mais dans les publications que j'ai vues, personne ne l'a expliqué. Pourquoi ne devrais-je pas étendre JFrame (ou un composant)? Y a-t-il des conditions dans lesquelles je devrais prolonger un composant, ou est-ce une règle ferme que vous n'avez pas?Pourquoi ne pas étendre JFrame et d'autres composants?
D'une manière générale, l'extension du composant a tendance à être effectuée strictement pour utiliser le composant. Cela limite considérablement vos options en termes de conception, de sorte que vos classes ne peuvent pas étendre des classes différentes, vous ne pouvez pas masquer les méthodes de JFrame, ce qui rend la maintenance plus difficile et plus facile de déclencher des bogues inattendus lors de l'utilisation de la classe .
Généralement, l'intention est strictement d'utiliser la classe pour dessiner une image, et la composition est préférée à l'héritage. Cela étant dit, le sous-classement devrait être bon lorsque vous avez l'intention votre sous-classe d'ajouter des fonctionnalités spécifiques au cadre (telles que les méthodes de commodité et autres) où la sous-classe serait utilisée à la place du cadre, mais utilisé comme une image en général, pas comme une vue d'une image spécifique dans l'application.
Si votre application est vraiment juste un JFrame, allez-y et l'étendre. Cependant, il est préférable d'utiliser la composition d'objet plutôt que l'héritage si vous êtes simplement en utilisant un JFrame.
Si votre objet étend un autre objet, vous n'auriez pas le choix, à titre d'exemple.
Je ne vois pas le problème tant que vous étendez la classe et que vous pouvez conserver les aspects «est-a» de l'héritage.
Lorsque vous étendez un JPanel mais que votre nouvel objet n'est pas une véritable spécialisation de JPanel, c'est là que vous avez des problèmes. Mais si vous créez un nouveau SpeciallyFormattedJLabel qui s'étend JLabel, je ne vois aucun problème avec cela.
Préférer la composition à l'héritage. Toutes les raisons habituelles. La composition force moins de dépendances entre le code.
Les composants Swing et Event AWT sont extrêmement compliqués. Vous ne voulez pas entrer dans ce pétrin. Vous pouvez facilement remplacer les méthodes accidentellement. Dans les cas où vous avez besoin de surcharger les méthodes, il est difficile de voir où cela est fait si c'est dans le code normal.
isValid est un classique pour l'annulation accidentelle – willcodejavaforfood
Je sais que c'est un vieux message, mais je viens de le rencontrer et je dois vous dire ... étendre mes possibilités d'appeler certaines actions de l'objet. Je suis en train de réécrire certaines parties du code pour me débarrasser des dégâts que cela a causés. À moins que j'écrive un programme d'un fichier, je ne vais pas utiliser à nouveau étendu.
D'accord. Ceci est swing, vous devez étendre les composants pour obtenir un comportement de peinture. – akarnokd
@ kd304 * "pour obtenir un comportement de peinture." * Nous pouvons faire un 'comportement de peinture' dans un 'BufferedImage'. –