Quelles sont les principales différences lors du passage d'une programmation sur console à une programmation basée sur une interface graphique?

J'ai commencé, comme beaucoup d'autres, avec une programmation sur console (comme dans le terminal, pas sur la Playstation). Mais tôt ou tard, il faut aborder la programmation basée sur une interface graphique, que vous le vouliez ou non. Cette transition contient de nombreux changements dans la façon dont vous devez penser au frontend (et peut-être aussi au backend).

Alors, quelles sont les principales différences lors du passage d'une programmation basée sur console à une programmation basée sur une interface graphique?

La plus grande différence est la conception de l'interface utilisateur. Une bonne interface graphique peut faire ou défaire une application. Les fans de Mac attireraient l'attention sur les interfaces graphiques magnifiquement conçues de l'application Mac OS X moyenne et ils ont raison, mais ce n'est pas un problème de technologie - c'est un problème de conception / d'ethos / d'utilisation.

Quant aux problèmes techniques, sans ordre particulier:

1. L'utilisateur peut faire tout ce qu'il veut dans n'importe quel ordre à tout moment, contrairement au programme de la console dans lequel vous demandez soit une entrée, soit vous lui dites la sortie. Vous ne pouvez pas supposer qu'ils suivront l'ordre que vous espérez, sauf si vous appliquez le style Assistant de flux de travail.

2. Comme déjà mentionné, les événements jouent un rôle important dans cela, et vous pouvez obtenir plusieurs événements pendant que vous entretenez le dernier, de sorte que vous ne pouvez pas vraiment construire votre état en fonction de `` l'événement en cours ''. Utilisez des fermetures ou un mécanisme similaire pour maintenir le contexte sur différents événements. Dans une application console, votre FSM est généralement autonome autour de la boucle `` get input, process input, update output ''. Il n'y a pas le même type de structure dans la programmation GUI - le `` principal '' est une chose pilotée par les événements rentrants, souvent une instruction switch () ginormous.

3. Vous devez considérer différentes tailles / résolutions d'écran et permettre à l'interface graphique de redimensionner de 800x600 jusqu'au maximum du moniteur des utilisateurs.

4. Vous devez considérer différentes stratégies de saisie - souris, clavier, tactile, etc. Certaines technologies sont gratuites (défilement avec la molette de la souris), d'autres nécessitent un travail d'intégration (encre).

5. Accessibilité - une interface graphique est beaucoup plus adaptée aux utilisateurs moins capables qui ont une vision, une audition, une motricité ou des capacités cognitives restreintes. Un bruit «ding» est agréable et évident par rapport à un message d'erreur cryptique sur la console.

6. Internationalisation - je suppose que votre application console est uniquement US / ANSI, mais lorsque vous entrez dans l'interface graphique, vous pouvez avoir des packages de langue / ressource qui peuvent cibler d'autres langues et régions sans changer le codage, si vous vous y êtes préparé à partir du début. Par exemple, aucune chaîne de langue codée en dur dans le code - tout comme des recherches de ressources.

7. Vous avez beaucoup plus d'options pour la technologie de mise en œuvre - basée sur le Web, divers kits d'interface graphique, Flash / WPF, etc.

8. Utilisation de la couleur et de l'animation. Les programmes de console sont généralement monochromes et n'animent pas beaucoup. De nombreux frameworks GUI modernes fournissent des widgets thématiques et ont des effets d'animation déplacer / taille / afficher / masquer, souvent gratuitement.

9. Graphique. Les applications de console utilisent parfois de l'art ASCII pour les diagrammes, mais une application GUI vous offre une capacité graphique complète. Un bel art peut aussi faire une grande différence.

Pour moi, ce serait de s'habituer à la programmation événementielle. Il peut toujours s'appliquer aux logiciels sur console, mais je trouve que c'est principalement utilisé avec l'interface graphique. Une fois que vous le saisissez, c'est un outil très puissant.

Je dirais le multi-threading et son implication avec l'interface utilisateur (si vous voulez faire des interfaces utilisateur non bloquantes)

La prise en compte du flux de contrôle sur l'interface utilisateur et la validation des entrées utilisateur deviennent très importantes.

Un programme console a tendance à être affiné au fil du temps tandis qu'un programme GUI a tendance à être vissé.

Habituellement, je considère le programme basé sur la console comme le modèle, tandis que le programme basé sur l'interface graphique est le View / Controller qui incorpore le modèle.

Pour moi, la conception d'une bonne interface graphique a toujours été beaucoup plus difficile que les détails techniques de sa mise en œuvre.

Il est facile de dire "rendez-le simple et clair, comme un Mac". C'est incroyablement difficile de le rendre tel; il y a toujours tellement de détails qui devraient être disponibles, mais en même temps, ils devraient être cachés.

simplicité http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png

Dans certaines (nombreuses?) Langues, la principale différence pour moi est que vous devez maintenant choisir une bibliothèque. La programmation «console» de la dorsale (et bien plus encore, avec un peu de chance) de votre application utilise les ressources standard de votre langue. En ajoutant une interface graphique, vous pouvez (espérons-le) avoir toujours votre «modèle» en idiomes standard, mais maintenant une grande partie, la «vue» dépendra d'une bibliothèque externe (et, malheureusement, vous vous en tiendrez «pour toujours»). Le choix de cette bibliothèque est une énorme responsabilité pour un débutant tout comme votre (mon) cas (sans parler de la courbe d'apprentissage supplémentaire).