J'ai fait une application swing qui est plutôt simple dans la fonctionnalité. Cependant, le code qu'il consiste à devenir assez grand et très désordonné à mon avis. Tous les composants et actions de swing sont dans un seul fichier. Donc, par exemple, si je devais faire une application encore plus importante avec plus de fonctionnalités, le code sera plutôt difficile à traverser.
Ma question est de savoir comment faire une bonne structure du code. Ou s'il y a une bonne page Web, je peux lire à ce sujet, et si possible certains exemples de code. J'ai vérifié le tutoriel de Soleil sur Swing, mais ces exemples plutôt simplistes qu'ils ont montré.
Mise à jour: J'ai réfléchi à un moment et vérifiez certains exemples. Je ne sais pas si j'ai eu le modèle MVC correct. Quoi qu'il en soit, mon idée est de séparer chaque jframe à leur propre fichier de classe. Ensuite, j'ai un mainframe qui est la fenêtre principale de l'application. De ce jframe, je crée une instance de chaque jframe que j'ai. Et appelez ces images du mainframe avec des actions. Je ne sais pas si c'est une bonne idée. Cependant, il rend le code significatif plus facile à lire quand même. Voici un exemple de la façon dont je voulais dire
4 Réponses :
Utilisez Modèle de conception du contrôleur de mode modèle. il traite de la séparation code d'interface utilisateur de la logique commerciale.
EDIT:
OP est à la recherche d'un code organisé plutôt que de conception flexible, j'ai supprimé la partie des concepteurs de l'interface utilisateur NetBeans de ma réponse.
J'ai utilisé des addons visuels d'interface utilisateur pour Eclipse, mais mon expérience est-elle ajoutera beaucoup de code de dépérissement. Est-ce le même cas pour Netbeans?
Cependant, s'il y a une ressource à lire, j'aime apprendre à coder manuellement
Organiser le code d'interface utilisateur de toute taille significative est un problème avec étonnamment peu écrit à ce sujet, considérant que chaque application a le même problème. Il existe certaines techniques qui peuvent aider:
Les techniques de conception de base sont autour depuis un certain temps et sont bien comprises, mais l'application des techniques à plus grande échelle est quelque chose qui semble être conçu individuellement pour chaque application.
Une approche que j'ai vue appliquée efficacement est de séparer les événements, les auditeurs, les actions, etc. dans leurs propres classes et les organiser en paquets par type ou utiliser une convention de dénomination constante sur des packages de sorte qu'un composant et sa Les classes associées sont facilement identifiables (xdialog, xdialogmouselistener, xdialogcancelaction, etc.).
Une autre approche serait de regarder quelques grandes applications open source (Eclipse, Firefox, ...) et voir comment ils organisent leur code d'interface graphique.
Comment séparer le code? Depuis que j'ai des points de vue. Ce qui dépend des actions, je ne peux donc pas le séparer.
Si vous divisez une action d'une vue et qu'il ne compile plus, vous pouvez introduire des méthodes supplémentaires pour permettre aux classes distinctes de l'accès à la fonctionnalité manquante. Les méthodes supplémentaires doivent être organisées en interfaces. L'interface peut être déclarée avec l'accès au niveau du package si les méthodes ne doivent pas être accessibles au public.
Dans les vues MVC ne dépendra pas normalement des actions, bien que dans la mesure de la vue et du contrôleur puissent être plus étroitement couplés. L'introduction des interfaces vous permet d'utiliser le principe d'inversion de dépendance pour inverser la direction des dépendances qui vont mal.
J'ai tendance à tirer autant de fonctionnalités non liées à l'interface graphique des composants de la balançoire que possible. Cela signifie que vous avez une indirection supplémentaire. Cependant:
Je ne parle pas nécessairement d'un modèle MVC complet (bien que ce n'est pas une mauvaise chose). C'est plus d'une question d'organisation de classe / forfait.
+1 pour le pragmatisme, je fais la même chose. En particulier avec un graphique, comme JformDesigner, ce qui facilite l'ajout d'actions et de gestionnaires d'action pour les boutons, etc. Il est logique de disposer de tout cela dans une seule classe, qui appelle des classes d'assistance. Par exemple, mon action d'impression n'est qu'une enveloppe qui appelle une nouvelle estachée d'impression (). Imprimer (MyJob). PrintTask est une classe distincte (non intérieure), qui n'a rien à voir avec l'interface graphique.
La chose à garder au devant de votre esprit est que la programmation d'interface utilisateur est comme d'autres types de programmation. Ne pensez pas que c'est spécial et que vous pouvez ignorer les pratiques raisonnables. Malheureusement, la plupart des codes de tutoriels sont très mauvais et le code dans la production a probablement tendance à être bien pire.
Points clés:
jPanel s).
- Préfère la composition à l'héritage. Il y a très peu de points de sous-classement des goûts de
jframe et jPanel , alors ne le faites pas.
- garder l'interface utilisateur mince. Par exemple, les rendriers devraient avoir très peu de logique. Pour une chose, cela facilite beaucoup les tests (les tests automatisés, les tests à grande échelle à la main sont contre-productifs).
Grande question! Je réfléchis à cela pendant un moment.