Codage manuel de l'interface graphique ou utilisation d'un outil de conception d'interface graphique

Question

J'aimerais connaître l'avis de certains sur le codage manuel de vos interfaces graphiques, comme on le fait généralement lorsqu'on utilise Java ou Qt avec C++, par rapport à l'utilisation d'un outil de conception d'interfaces graphiques. Des exemples d'outils de conception d'interfaces graphiques seraient MFC GUI-designer, Qt designer, Interface Builder (Apple).

J'étais un adepte du codage manuel, mais l'expérience récente m'a fait changer d'avis. Le problème que j'ai constaté avec le codage manuel est qu'il est assez rapide et flexible d'écrire les interfaces graphiques, mais une fois que vous avez besoin d'apporter un changement à une interface graphique écrite il y a longtemps, cela peut s'avérer très difficile. Trouver le bon élément dans un grand panneau peut s'avérer difficile.

Le deuxième problème est qu'il est beaucoup trop facile d'ajouter beaucoup de logique dans le code de création et de présentation de l'interface graphique. J'ai souvent dû prendre en charge la maintenance du code de l'interface graphique qui est vraiment difficile à réutiliser parce que son comportement est mélangé à son apparence et que le fait de mélanger la présentation et le comportement rend souvent la classe très volumineuse et difficile à comprendre.

L'utilisation d'un outil de conception d'interface graphique impose, à mon avis, une séparation beaucoup plus nette entre l'apparence et la logique.

Answer 1

Si vous concevez une application commerciale avec de nombreux formulaires de saisie et des données tabulaires, écrire du code pour votre interface utilisateur est à la fois plus rapide et plus facile à maintenir que d'utiliser un concepteur d'interface utilisateur. Dans ce type d'applications, il n'est presque jamais nécessaire de placer précisément un élément à un endroit prédéfini de l'écran, alors que d'un autre côté, il y a beaucoup de répétitions et de conventions de conception qui peuvent simplement être extraites dans des méthodes séparées.

Prenons l'exemple d'une boîte de dialogue de préférences d'Eclipse ou d'OpenOffice. Il existe un grand nombre de catégories et d'options différentes à définir pour chacune d'entre elles. Si vous devez faire quelque chose de cette taille, concevoir chaque écran à la main est une tâche banale. Une bien meilleure approche consiste à écrire un code qui générera des éléments d'interface utilisateur à la volée, à partir de données de domaine fournies, conformément à certaines conventions et valeurs par défaut.

Je ne vois pas en quoi l'utilisation d'un designer facilite une meilleure séparation, ni en quoi cette séparation perçue aiderait quoi que ce soit, étant donné que vous gardez déjà votre logique d'entreprise en dehors de l'interface utilisateur.

Enfin, si vous utilisez Java, n'oubliez pas de consulter le site suivant MigLayout . Il fonctionne avec Swing et SWT, sa syntaxe est très concise et claire, et il dispose d'un mode de débogage incroyablement utile.

Answer 2

Cela dépend de la situation. Je pense que les deux ont leur place, et j'utilise généralement une approche hybride.

Il y a toujours des choses que le constructeur d'interface graphique ne peut pas faire (par exemple, définir la couleur à une constante UIColor dans le constructeur d'interface). D'un autre côté, la plupart des tâches liées à l'interface graphique sont assez banales (par exemple, l'ajout d'étiquettes statiques).

Je préfère faire les choses banales dans le constructeur de l'interface graphique, et les choses plus intéressantes dans le code.

De plus, il m'arrive de modifier à la main le XML produit par le constructeur d'interface graphique (Interface Builder et glade dans mon cas).

Answer 3

J'ai tendance à penser que la bonne réponse dépend de la culture de la plateforme cible. Sur OS X, Interface Builder fait tellement partie intégrante de la chaîne d'outils qu'il est difficile de l'éviter.

En Java (awt ou swing), c'est l'inverse qui est vrai. Il n'y a pas de support de chaîne d'outils pour cela.

En réalité, c'est la façon dont les outils produisent leurs résultats qui permet de s'en rendre compte. Interface Builder produit des fichiers au format .nib qui sont spécifiques à la manière dont Cocoa affiche les contrôles à l'écran. Il comprend ce qui est essentiellement un format de balisage d'interface. Java n'a pas de concept similaire. Tout est une classe compilée et il est donc beaucoup plus difficile d'obtenir des résultats pratiques.

GTK+, combiné à glade, semble trouver un équilibre raisonnable entre les deux.

Answer 4

Rien n'empêche de mélanger les deux approches. Il m'arrive souvent de faire la présentation principale d'un formulaire dans un concepteur d'interface graphique (parce que c'est rapide et qu'on voit ce qu'on fait), et d'y placer un ou plusieurs panneaux qui sont ensuite remplis avec du code. C'est particulièrement utile lorsque l'interface graphique doit s'adapter à des situations spécifiques - par exemple, si l'interface graphique doit changer en fonction du matériel connecté.

Quoi qu'il en soit, le plus important est de séparer l'interface graphique de la logique de l'application.

Answer 5

M 1. Le code GUI codé à la main est beaucoup plus réutilisable 2. Les problèmes de mise en page sont plus simples avec les concepteurs