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

Je voudrais toujours coder à la main la conception de l'interface graphique lorsqu'il n'y a pas de norme (ou de facto langage de balisage GUI (comme pour le langage Java ). La raison en est que j'ai constaté que l'utilisation d'un outil de conception d'interface graphique vous lie à l'utilisation d'un IDE particulier. Avec le temps, le meilleur IDE pour la conception d'une interface graphique et/ou l'écriture de code changera et chaque développeur devrait être libre de choisir l'IDE avec lequel il se sent le plus à l'aise .

Là où je travaille actuellement, nous avons beaucoup d'interfaces graphiques héritées qui ont été écrites en utilisant Netbeans Matisse GUI builder (contre mon avis à l'époque :-). Ils sont maintenant presque impossibles à maintenir parce que tous les développeurs préfèrent soit IntelliJ IDEA o Eclipse comme leur IDE. Il n'est pas réaliste ou réalisable de demander aux développeurs de lancer Netbeans juste pour modifier la présentation de l'interface graphique (les gens ne gardent pas les définitions de projet Netbeans synchronisées, etc.)

Un autre point est que le temps total consacré à l'écriture du code de présentation de l'interface graphique ne représente probablement que 5 % de l'effort de développement total d'un projet donné. Même s'il vous faut deux fois plus de temps pour écrire le code vous-même, cela ne représente pas un surcoût important dans l'ensemble du projet. Et c'est un petit prix à payer pour la maintenabilité à long terme.

Tant que vous séparez clairement la logique de présentation de l'interface graphique de la logique commerciale, je ne pense pas que cela ait des conséquences négatives. Plus personne ici n'utilise de concepteurs d'interfaces graphiques !

Answer 2

Je le fais à la main, c'est beaucoup plus facile de mélanger les choses et de réutiliser les panneaux à l'intérieur de l'application (certains panneaux peuvent apparaître à plusieurs endroits).

L'utilisation d'un designer fonctionne lorsque vous êtes dans une équipe où les artistes sont censés réaliser l'interface graphique.

Il peut être difficile de trouver le bon élément dans un grand panneau.

? ? Je n'ai jamais vu cela.

Answer 3

Il est amusant de constater que c'est l'inverse qui s'est produit pour moi. Du point de vue de Winforms, le code généré par le concepteur est assez bruyant, avec peut-être un quart ou la moitié de tous les paramètres de propriété réellement nécessaires. La création de contrôles assez volumineux est également plus tentante lorsque l'on travaille avec un concepteur. Modifier une hiérarchie de contrôles dans le concepteur Winforms est un véritable cauchemar à mes yeux.

Dans mon dernier projet, j'ai créé des API supplémentaires pour mettre en place des séparateurs dans les formulaires, dockmanagers, menus, barres d'outils, etc. de manière déclarative. Ces API sont telles qu'elles renforceront la séparation des préoccupations.

J'essaie également de m'appuyer beaucoup plus sur les fonctionnalités de mise en page automatique qui, il est vrai, sont beaucoup plus agréables dans WPF, mais qui peuvent également être utiles dans Windows Forms.

Answer 4

Je suis convaincu qu'il est préférable d'utiliser un constructeur d'interface plutôt que de coder manuellement une interface graphique. Comme dans la question mentionnée, la séparation est beaucoup plus nette et une fois que quelque chose doit être modifié, c'est beaucoup plus facile.

Le Qt Designer dispose de cette fonctionnalité qui permet de créer une classe à partir d'un fichier .ui fichier ₁₎ Mais je pense que la meilleure solution est de ne pas utiliser cette fonctionnalité, car elle crée un code supplémentaire qui ne devrait pas exister du tout. Le problème de la vitesse de création de la fenêtre à partir d'un .ui -est négligeable car la fenêtre ne doit être chargée qu'une seule fois.

Il s'agit de PyQt, mais quelque chose de similaire est possible en C++ :

class SelectDateDialog(QDialog):
    def __init__(self):
        QDialog.__init__(self)
        uic.loadUi("resources/SelectDate.ui", self)

Essentiellement, cela a le même effet que d'inclure tout le code de l'interface utilisateur dans le fichier __init__() mais l'interface utilisateur est presque complètement séparée du code.

1) .ui sont des fichiers XML qui décrivent une interface utilisateur

Answer 5

Je vous conseille vivement d'utiliser Interface Builder sur OS X. Le faire à la main est une bonne chose si vous voulez apprendre, mais vous vous épargnerez beaucoup de maux de tête en l'utilisant sur des projets réels. Il est vraiment très puissant.

Quant à Java et C++, cela dépend de ce que vous faites et des plates-formes utilisées. Pour les applications simples, il est possible de ne jamais voir le code de l'interface utilisateur. Cependant, pour les applications complexes et les clients riches, vous devez généralement effectuer une partie du code à la main.