Diagramme de classes Swing et UML avec plusieurs écrans avec des composants identiques

Question

Je suis bloqué pendant des heures. Je devrais faire un diagramme de classes UML pour l'application Swing dans un projet de collège. J'ai imaginé un écran principal à partir duquel je peux ouvrir l'un des différents écrans en fonction de l'option choisie. Tous ces écrans ont plusieurs composants identiques (comme le logo de l'application, le bouton de déconnexion, etc.). Maintenant, j'ai lu qu'il n'est pas recommandé d'hériter de JFrame, donc j'ai évité de les placer dans une classe qui hérite de JFrame qui est encore héritée par ces autres classes mais qui ne semble pas non plus avoir d'héritage ces composants en tant qu'attributs dans chaque classe.

Alors, quelle est la bonne façon de le faire?

Answer 1

Tout écran différent est généralement considéré comme une classe. L'écran contenant des données concrètes est une instance de la classe.

Toute sorte de sous-élément de l'écran est évidemment une autre classe. Encore une fois, son exemple avec date est une instance.

Une classe d'écran a des sous-éléments de différentes classes. Ce sont vraiment des attributs, et changer la logique naturelle serait une idée très malheureuse.

Si les écrans ont les mêmes éléments et ne diffèrent que par leur contenu, et ce fait est conceptuel, s'ils DOIVENT être les mêmes, ces écrans appartiennent à la même classe. Si elles sont si semblables seulement accidentellement, et le développement ultérieur peut le changer, elles devraient appartenir à différentes classes.

L'héritage pourrait également être utilisé. Si vous avez des boutons jaunes et des boutons jaunes avec des points, ces derniers pourraient être les descendants des premiers. Ici, le principe de Liskov ne sera pas brisé. Ne pas oublier, les principes de base sont définis dans SOLID, il n'y a pas de principe tel que ne pas utiliser l'héritage, et vous n'avez pas besoin d'utiliser la composition de pure façon.