Java, générateur d'interface graphique ou codage manuel? [fermé]

Pour quelques formulaires, je recommande d'utiliser un générateur. Il obtiendra le chemin fait plus rapidement. Cependant, si vous avez beaucoup de formulaires que vous devez maintenir pendant un certain temps, je recommande contre un constructeur. Dans ce cas, le temps que vous passez à lire le code et à la maintenance est beaucoup plus important que le temps de conception initial. Ainsi, alors que le constructeur vous fait gagner du temps à la phase initiale, il rend la lecture et la maintenance du code plus difficiles. De plus, il permet la réutilisation du code, même sous forme de copier-coller à partir d'une forme à une autre, plus difficile.

Je ne sais pas si vous faites référence à des applications Web ou de bureau, mais en général, je n'ai pas trouvé de générateur d'interface graphique Java qui produit une sortie élégante. Netbeans Swing code généré par exemple est un gâchis. Peut-être, si un bon constructeur était disponible, je changerais d'avis. Je n'ai eu aucun problème à utiliser le concepteur de formulaires de Visual Studio - il produit un code agréable que vous pouvez lire et comprendre.

Pour les applications de bureau jetez un oeil à MiGLayout . C'est un gestionnaire de mise en page, pas un constructeur, pour Swing et SWT qui vous facilitera la vie.

En utilisant un bon constructeur, le développement sera beaucoup plus rapide.

L'anxiété que vous avez de ne pas pouvoir modifier le code peut être due au fait que vous avez beaucoup de logique dans la vue où il n'appartient pas. En fait, ce changement peut vous aider à déplacer la logique de la vue, ce qui est bon précisément pour la possibilité de changer les éléments visuels sans casser le code.

Selon le "illisible", vous devriez envisager d'utiliser un meilleur générateur d'interface graphique. J'ai entendu que des choses positives sur l' NetBeans, et j'ai utilisé IntelliJ GUI builder dont le code est assez propre.

Sur les deux le code source est lisible et modifiable, mais seulement pour des ajustements mineurs. Pour les principaux, utilisez bien le générateur d'interface graphique.

Je pense que pour un petit nombre de formulaires, il n'y a pas de problème à procéder à la main, mais puisque vous en avez "beaucoup" comme vous venez de le dire, l'utilisation de ces outils sera des plus bénéfiques.

Voici mon expérience:

Je n'ai jamais aimé le code généré par le générateur d'interface graphique. Au moins, ce n'est pas comme dans le monde VB que tout le monde (enfin, presque) utilisera le mêmeE pour créer des applications. En Java, les gens utilisent plusieursEs, et certains utilisent aussi VIM et Notepad. Et tous lesEs ne génèrent pas le même type de code. Et un autre problème est qu'ils ne comprennent généralement pas le code généré par d'autresEs. Donc, pour répondre à votre 1ère question, je ne recommande pas.

Votre prochain question: Quel constructeur est le meilleur? La dernière fois que j'ai utilisé, Netbeans était meilleur que la plupart d'entre eux que j'ai essayés.

Si vous devez utiliser un générateur d'interface graphique parce que vous devez développer des applications plus rapidement, assurez-vous que tous les membres de votre équipe utilisent le même générateur. Il vaut mieux avoir leur avis à ce sujet, sinon leurs yeux vont être blessés par le code source généré par ID.

Faites-nous savoir votre décision!

J'utilise Java Swing GUI Builder de Netbeans (Matisse) pour tous mes projets depuis 3 1/2 ans. J'ai lu les plaintes de tant de gens sur les constructeurs d'interfaces graphiques et les programmeurs les plus chevronnés réprimandent tous ceux qui font même allusion à l'utilisation d'un, mais voici mon expérience:

1. Le code non modifiable n'est jamais nécessaire à modifier. Vraiment, le générateur d'interface graphique fournit un squelette pour votre interface graphique. Vous faites glisser, déposer, redimensionner et contraindre vos composants à l'aide de l'éditeur, mais contenu de la table, la liste de la zone de liste déroulante, etc., tous doivent être gérés sur le backend. Le générateur d'interface graphique vous permet de vous concentrer sur cela pendant qu'il prend soin de rendre les choses jolies et de rester en place.
2. WYSIWYG est toujours plus productif. Les traitements de texte en sont le témoignage. Les gens vous diront: "Vous n'éditez pas beaucoup de code GRAPHIQUE, donc si cela vous fait gagner du temps, ce n'est pas beaucoup de temps."Mais cette déclaration est extrêmement relative. Lorsque vous travaillez dans un environnement logiciel avec un modèle de processus qui nécessite des mises à jour constantes en raison de changements de modèle commercial, cette déclaration est fausse. De plus, vous passez la majorité de votre temps sur lecontenu de votre essai en anglais, n'est-ce pas? Donc, cet argument dirait que les traitements de texte WYSIWYG ne vous font pas gagner beaucoup de temps, et une telle déclaration tomberait dans l'oreille d'un sourd parce que personne ne voudrait coder à la main le look-and-feel de leur essai.
3. Il n'y a rien qu'un constructeur d'interface graphique ne puisse pas faire de code manuscrit, alors que J'ai passé des heures à essayer de résoudre de petits défis avec du code graphique manuscrit qui m'a pris 1 minute dans un générateur d'interface graphique.

Le constructeur d'interface graphique de Netbeans, en particulier, s'est tellement amélioré au fil des ans qu'une grande partie du flak qu'il a reçu (semblable à beaucoup de flak que Java a reçu) a été vraiment annulée. C'est un excellent programme et c'est un excellent moyen de créer de belles interfaces riches en fonctionnalités de manière efficace dans le temps. Je recommande fortement un bon constructeur d'interface graphique, en particulier Netbeans.

Là, je l'ai dit.

Non, je ne travaille pas pour eux.

Je resterais à l'écart des constructeurs d'interfaces graphiques. Dans mon expérience(matisse) vous finissez par passer autant de temps à écrire des interfaces graphiques avec le constructeur par contre, si pas plus. En raison d'essayer de lire le code généré et de le nettoyer lors des modifications. Aussi, si vous écrivez l'interface graphique à la main, vous devrez comprendre le code afin d'écrire l'interface graphique, et cela aidera les heures supplémentaires à devenir plus compétent, et vous obtiendrez plus rapide à écrire des interfaces graphiques, et vous serez plus rapide et les écrire à la main. Au fil du temps vous pouvez également développer une bibliothèque de composants pour les fonctionnalités gui que vous vous retrouvez à écrire plusieurs fois. Je resterais loin des constructeurs. Un bon développeur battra un développeur moyen avec un constructeur à tout moment.

Si vous n'avez pas de formulaires trop complexes à construire, alors vous pouvez jeter un oeil à DesignGridLayout, c'est Swing LayoutManager avec une API fluide qui le rend très facile à écrire du code pour votre formulaire et facile à lire ce code (et à maintenir, je veux dire modifier si nécessaire) et visualiser le formulaire

Avec DesignGridLayout, une ligne de composants dans votre formulaire est une ligne de code. Pas de XML, sécurité complète à la compilation. Pas de valeurs d'espacement codées en dur, alignement... DesignGridLayout s'occupe de tout pour vous.

Courbe d'apprentissage courte et aussi rapide à mettre en page un formulaire qu'un concepteur d'interface graphique!

Depuis que je l'ai découvert il y a environ 2 ans, je l'ai utilisé exclusivement (j'ai toujours été allergique aux concepteurs d'interfaces graphiques à cause du code généré terrible). C'est la raison pour laquelle j'ai repris le projet il y a 8 mois, parce que je voulais lui donner tout son potentiel.

Nous le faisons à la main, mais avec une bibliothèque nous aidant avec la mise en page ( JGoodies Forms) et ainsi de suite. De plus, nous utilisons un ensemble de composants prédéfinis que nous branchons dans notre interface utilisateur (Jide). Fonctionne très bien pour nous.

J'ai utilisé de nombreux concepteurs d'interfaces graphiques au fil des ans (pour différents langages): Delphi, Visual Studio, JBuilder, Netbeans.

La qualité du code qu'ils produisent et le volume est important. Delphi était fantastique, il produisait de petites quantités de code par rapport à la taille du formulaire et le code était facilement compréhensible et les outils bidirectionnels vous permettaient de modifier le code généré en toute confiance. Cela a été aidé par une bibliothèque GUI simplement comprise. VS produit des rames de code et vous avez peur de la changer.

Java est en partie déçu par le langage, pas de délégués ou de fermetures et donc le code basé sur les événements peut rapidement devenir un étalement.

Je ferais des trucs simples avec Netbeans Matisse et - une fois confiant - les coder à la main. Les choses complexes méritent d'être planifiées et codées à la main afin que votre modèle soit bien défini.

Cela aide si vous créez une bibliothèque de vos propres composants GUI que vous pouvez réutiliser. Ceci est pertinent pour toutes les langues avec des bibliothèques GUI.

Pour les systèmes avec un lot de formulaires simples, j'ai eu tendance à suivre la route XML -

• définir des fichiers XML pour les informations et tout flux de travail pour chaque formulaire
• créer XSLT pour générer Java / XHTML / n'importe quel code pour exécuter les formulaires sur PC de bureau/mobile/web
• créez également XSLT pour générer des objets de données de code source, etc.

Vous pouvez utiliser XForms et ses implémentations, mais j'ai généralement travaillé dans des endroits où l'achat de solutions prend plus de temps que construire votre propre XSLT simple. Il faut généralement une semaine pour tout mettre en œuvre s'il n'y a pas trop de widgets spécialisés dans les formulaires. Si vous créez vos propres générateurs de code, vous avez le contrôle total. Si vous trouvez que vous voulez changer tous vos formulaires de défilement vers le haut/bas pour être présentés dans des colonnes, alors il n'y a qu'un seul endroit que vous devez changer, plutôt que de changer l'implémentation de chaque formulaire. (bien que vous puissiez créer un cadre pour abstraire les informations de formulaire de la présentation en Java, ce n'est pas bien adapté à une telle programmation déclarative)

Personnellement, je suis un fan de séparer la disposition de l'interface graphique du code (sinon vous vous retrouvez avec les problèmes que vous venez de mentionner). Cela semble également être la tendance: Microsoft a son XAML, vous continuez à entendre parler de différents moteurs de vue pour MVC, etc.

Pourquoi ne pas aller avec la conception graphique basée sur XML? Vous pouvez essayer quelque chose comme JFormDesigner qui peut gérer à la fois les mises en page XML et générées par code.

J'ai fait les deux récemment - j'utilise Netbeans, et j'ai d'abord été frustré par le manque de contrôle du code généré. J'ai ensuite découvert que vous pouvez ajouter du code personnalisé à partir du générateur d'interface graphique, qui a surmonté la plupart des problèmes. Cependant, je suis devenu plus frustré par le gestionnaire de mise en page dans NetBeans, et j'ai trouvé que cela nuisait plus que tout à ma productivité. Je suis passé à l'utilisation de MiGLayout et à faire la plupart du codage à la main maintenant. Cela dit, NetBeans dans l'ensemble est assez bien, et peut-être que j'aurais dû passer plus de temps à apprendre le GroupLayout.

Si vous faites du développement d'équipe, assurez-vous que vous utilisez tous le même outil si vous vous fiez à un générateur d'interface graphique.

J'ai utilisé Netbeans dans le passé pour construire du code GUI et utilisé Eclipse pour écrire la logique du programme. Incluez simplement le code GUI en tant que dossier source lié séparé.

Je dirais que n'utilisez un générateur d'interface graphique que si vous comprenez suffisamment ce que vous essayez de faire pour pouvoir le faire vous-même.

Si vos formulaires sont simples et non dynamiques, un générateur d'interface graphique est parfait. Plus le formulaire est complexe, moins vous obtiendrez d'avantages en utilisant GUI builder.

L'entreprise pour laquelle je travaille fait exactement cela. Des applications plus simples sont développées avec le générateur d'interface graphique et des applications plus complexes sont faites à la main. Une fois qu'il y a suffisamment d'heures à essayer de contourner les limites du constructeur de l'interface graphique, il est généralement abandonné. De plus chaque constructeur d'interface graphique n'est pas créé de la même manière il faudra donc une évaluation de votre part pour déterminez dans quelles situations un générateur d'interface graphique est approprié. (Le constructeur de l'interface graphique NetBeans est assez bon.)

Personnellement, j'aime utiliser les constructeurs d'interfaces graphiques pour créer la disposition globale de l'application/formulaire et jouer avec les différentes mises en page, mais je le convertit ensuite en code plus lisible et je fais le reste à la main.

Que vous construisiez des formulaires GUI à l'aide d'un éditeur GUI ou non, je vous recommande fortement de développer un ensemble de panneaux "bean" standard que vous pouvez placer sur vos formulaires.

Nous avons environ 100 de ces haricots que nous avons utilisés dans plus de 600 formes. Voici une image montrant l'un de ces haricots:

Ce panneau se compose d'une étiquette standard, d'un indicateur obligatoire (astérisque rouge), d'un champ éditeur (une zone combinée dans ce cas) et d'un champ affichage uniquement (la zone grise). Dans ce cas, les champs combo-box et display-only sont mutuellement exclusifs-un seul est visible à la fois, selon le mode dans lequel le formulaire/champ se trouve.

Ces beans contiennent notre fonctionnalité standard (framework), qui comprend des couleurs standard, des polices, etc. Si nous voulons changer la façon dont toutes les occurrences de ces champs fonctionnent, ou à quoi elles ressemblent, nous les changeons dans une classe et cela change sur tous les formulaires qui l'incluent.

Maintenant, comment construisons-nous nos formes? Eh bien, nous faisons tous nos formulaires dans le NetBeans Matisse GUI builder. Nous sommes très heureux avec elle. Bien que vous ne puissiez pas modifier le code qu'il génère, je n'ai jamais eu de cas où cela m'a empêché de faire quelque chose dans l'interface graphique. Les haricots que j'ai mentionnés ci-dessus peuvent être facilement ajoutés à la palette, donc les ajouter aux formulaires est un glisser-déposer.

Il y a certaines techniques, tho, qui rendent les choses plus faciles, à mon avis. Nous utilisons BoxLayout (dans l'axe de la page) sur la plupart de nos formulaires, et combiné avec notre bean standard panneaux, la construction d'un formulaire peut littéralement prendre quelques minutes à faire (le côté graphique, au moins). En outre, FlowLayout est utile si vous avez plusieurs contrôles sur la même "ligne" sur le formulaire (par exemple, plusieurs cases à cocher).

Et c'est aussi facile, ce qui signifie que nous pouvons obtenir certains analystes commerciaux (non programmeurs) qui construisent les formulaires avant qu'un programmeur n'ajoute le code "sous le capot".

J'ai commencé en tant que programmeur VB, puis je suis passé à C#. Je dirais que Netbean GUI builder est encore loin de Microsoft, en particulier avec le gestionnaire de mise en page dans le formulaire. Il devient vraiment flustrated lorsque vous avez essayé de déplacer les boutons et l'étiquette pour être aligné sur ce que vous voulez et ceux que vous ne voulez pas déplacer l'icône ont commencé à se déplacer tout autour de l'endroit.

Le code généré automatiquement ne peut pas non plus être modifié dans la source, ce qui le rend encore plus non convivial