Est-ce une bonne idée de concevoir une architecture en pensant que les classes d'interface utilisateur peuvent être remplacées par une interface de ligne de commande?
Dans Code Complete page 25, il est dit que c'est une bonne idée de pouvoir facilement remplacer les classes d'interface utilisateur normales par une classe en ligne de commande.
Connaissant ses avantages pour les tests, qu'en est-il des problèmes que cela peut entraîner?
Ce travail supplémentaire sera-t-il vraiment rentable pour les projets Web et mobiles? Qu'en est-il des petits et moyens projets; les mêmes règles s'appliquent-elles? Et si cela rend votre conception plus complexe?
Être en mesure de réutiliser des fonctionnalités sous différentes interfaces (par exemple, GUI vs CLI vs REST) n'est pas toujours nécessaire mais agréable d'avoir et d'activer réutilisation fortuite pour un système, car d'autres personnes trouvent de nouvelles façons d'interagir avec lui.
Cela présente quelques inconvénients qui doivent être pondérés:
- Cela nécessitera des couches d'abstraction supplémentaires (parfois même des niveaux). Bien que le fait d'avoir ces couches soit une bonne pratique d'ingénierie, elles ont un coût de développement supplémentaire, une compréhension qui ne peut pas conduire à réduire les efforts dans d'autres domaines (par exemple la maintenance, la réutilisation, les tests), donc cela vaut la peine d'y réfléchir un peu.
- Un débit optimal pour un médium peut être affreux pour les autres. Si la fonctionnalité a été conçue pour prendre en charge une interface graphique, elle peut être trop bavarde pour le Web . Toutes les fonctionnalités ne valent pas la peine sur tous les supports.
- Il y a un piège à essayer de définir un convertisseur générique entre les services et l'interface utilisateur, de sorte que l'on peut définir le contrat de service et dériver automatiquement (ou autant que possible) l'interface utilisateur pour tous les supports. De nombreux projets ont gaspillé trop d'efforts à essayer de construire de tels cadres et à y ajouter toutes les personnalisations possibles à mesure que les exigences changeaient.
Cela dit, d'après mon expérience, la mise en œuvre de telles couches a toujours fini par payer l'effort. Dans quelques cas, j'ai réussi à déployer des systèmes à temps car nous avons dû échanger des supports (par exemple, de l'intégration des services Web à l'interface utilisateur) quelques semaines avant la date d'échéance.
Outre les tests, l'avantage évident de cette approche est qu'elle rendra votre projet automatisable et scriptable. Si je peux envoyer des commandes de ligne de commande à un programme, je peux écrire un script pour effectuer des tâches compliquées beaucoup plus facilement (et de manière plus fiable!) Que je ne pourrais créer une macro pour automatiser la même chose sur une interface graphique.
Le fait que cela vaille la peine, bien sûr, dépend entièrement du fait que vous ayez ou non beaucoup d'utilisateurs qui voudraient automatiser votre programme.
Ce n'est pas du travail supplémentaire, juste différent travail. Si vous le faites correctement, non seulement cela ne le rendra pas plus complexe, il le rendra plus simple car il vous forcera à découpler votre conception. Que vous mettiez ou non réellement en œuvre la CLI, votre conception sera mieux placée pour permettre de le faire.
Un avantage clé qui ne semble pas avoir été mentionné est que pouvoir faire cela à peu près impose un découplage strict de l'interface utilisateur du code sous-jacent. Un avantage clé de cela est que cela signifie que si vous devez modifier considérablement l'interface graphique (par exemple, les normes iOS aux normes OSX, ou un moteur graphique à un autre), c'est tout vous devez changer, car le code sous-jacent ne dépend pas de la disposition de l'interface utilisateur. Cela ne peut pas l'être, car s'il l'était, les outils de ligne de commande ne fonctionneraient pas.
En dehors de cela, la possibilité d'automatiser les tests est un avantage clé.
Oui, c'est presque toujours une bonne idée.
Si vous suivez cette approche, vous n'aurez probablement pas de logique métier ou d'accès aux données dans un même thread que l'interface graphique et derrière un gestionnaire d'interface graphique. Cette raison à elle seule mérite d'être investie.
Je pense que c'est une bonne idée. De plus, la possibilité d'écrire un deuxième front-end en ligne de commande prouve finalement que la logique métier est totalement découplée à toute architecture de serveur d'applications particulière.
Le seul danger que je vois en faisant cela est que pour accéder à une certaine partie de l'interface utilisateur, l'utilisateur doit normalement parcourir d'autres parties de l'interface utilisateur.
Où le développeur peut simplement exécuter l'interface utilisateur directement. J'ai vu des situations où un développeur ne pouvait pas reproduire le problème d'un utilisateur tant qu'il n'avait pas réellement utilisé le produit.
Il faut donc en tenir compte lors de la création des tests.
Non. Un conseil horrible.
C'est un peu yagni (vous n'en aurez pas besoin).
L'exposition d'une interface de ligne de commande n'est pas la même chose que la structuration de votre application d'une manière qui prend en charge les tests unitaires, ou est conforme à n'importe quelle partie de SOLID, ou à toute pratique de programmation que je recommanderais.
Cela ne fonctionne pas pour toute interface utilisateur qui ne conviendrait tout simplement pas à une interface de ligne de commande. MS Paint est une application vraiment simple, mais comment, dans n'importe quelle situation, verriez-vous un avantage à pouvoir la contrôler à partir d'une ligne de commande?
Cela ne vous aiderait pas à implémenter les scripts. Cela entraverait en fait tout progrès dans cette direction.
La seule chose positive est qu'il est apparu à la page 25, donc au moins vous recevez un avertissement que le reste du livre pourrait être ... malodorant. Je l'ai lu il y a longtemps et je ne l'aimais pas, donc je suis partial.
S'appuyant sur ce qu'a dit Mason Wheeler, être capable d'interagir avec une application via une ligne de commande facilite l'automatisation des tâches.
Ceci est particulièrement utile pour les tests.
Pour donner un exemple pratique, si je veux exécuter des tests automatisés sur une application, je peux vouloir installer l'application automatiquement. Pour ce faire, je peux transmettre les paramètres suivants, "myApplication.exe/silentinstall".
Je pourrais le programmer de sorte que lorsque je spécifie ce commutateur de ligne de commande, une installation soit effectuée silencieusement en arrière-plan, sans le programme d'installation de l'interface graphique. Toute entrée dans le programme d'installation (comme le répertoire d'installation) pourrait peut-être être récupérée à partir d'un fichier XML.
Prenons un autre exemple. L'interface graphique de Microsoft Test Manager (fournie avec Visual Studio) permet aux utilisateurs de lancer des tests à partir de son interface graphique, mais fournit également une interface de ligne de commande pour faire la même chose (en utilisant une combinaison de commutateurs et d'entrées de ligne de commande). Cela signifie que je peux créer un script PowerShell ou DOS pour automatiser le lancement des tests, et je pourrais ensuite créer une tâche planifiée pour que les scripts soient exécutés tous les soirs, peut-être.
Certaines applications ont des commutateurs de ligne de commande qui spécifient pour une application à ouvrir avec certaines options (par exemple, je pourrais utiliser '/ maximiser' pour ouvrir l'application dans une fenêtre maximisée).
Il existe de nombreux scénarios dans lesquels une interface de ligne de commande pourrait être utilisée. Ce ne sont là que quelques exemples.
Remarquez à nouveau la phrase: "[C'est] une bonne idée de pouvoir remplacer facilement les classes d'interface utilisateur standard par une ligne de commande". Cela ne signifie pas que vous devez écrire une CLI, juste que vous pouvez le faire facilement.
Donc, ce qu'il dit, c'est que votre interface utilisateur doit être découplée du reste du code.
Cela dépend et quand je dis que cela dépend, ce n'est pas seulement une question d'avoir quelques cas Edge, mais cela dépend beaucoup de l'application et de la cible public. En supposant que nous éliminons les jeux de l'équation, il existe encore un large éventail d'applications que vous pouvez écrire là où une commande comme celle-ci est peu probable ou ne sera jamais implémentée. Du haut de ma tête, toute application ciblant un environnement mobile (par exemple, iOS, Android, etc.) tombera probablement sous cette rubrique.
Dans cet esprit, dans l'espace logiciel général, toute application qui dépend fortement de la visualisation (par exemple PowerPoint, Maya , etc.) est peu susceptible de voir un remplacement de ligne de commande implémenté. En fait, dans le cas d'un logiciel graphique tel que Maya, on peut soutenir un bon exercice mental pour déterminer comment une version complète et appropriée de la ligne de commande fonctionnerait et il pourrait ne pas être possible de le faire du point de vue de l'utilisateur. Ainsi, il est clair qu'il existe des applications définitivement communes qui peuvent être rencontrées là où une interface de type commande ne sera probablement jamais vue, ou souhaitable même si le scriptage de l'application peut être souhaitable.
Ensuite, si nous regardons la forme suggérée du point de vue de l'architecture logicielle générale, je peux voir où il serait logique de vous demander périodiquement "Comment puis-je accéder à cette fonctionnalité sans l'interface utilisateur?" En général, s'il n'y a aucun moyen de le faire et qu'il n'interagit pas directement avec l'utilisateur (par exemple, la saisie gestuelle), vous avez probablement une situation où l'architecture globale doit être améliorée. Afin de faciliter les tests, vous souhaiterez pouvoir accéder directement aux commandes sans passer par l'interface utilisateur, même si elles ne peuvent pas être appelées via une ligne de commande. Cela signifie généralement qu'une API solide doit être en place et, théoriquement, une bonne API doit permettre l'accès via la ligne de commande ou l'interface utilisateur. De plus, à long terme, vous gagnerez du temps si vous avez besoin d'ajouter une nouvelle interface utilisateur à l'application.
À la fin de la journée, je pense que ce que la suggestion essaie de faire est logique (c'est-à-dire avoir une bonne API et construire votre interface utilisateur à partir de cela) mais la sélection de Word aurait peut-être été un peu meilleure pour faire passer le message .
Ça dépend.
Souvent, nous partitionnons nos programmes en tant que modèle/vue/contrôleurs ou modèle/vue/vue/modèle. Il semble que le modèle devrait permettre l'accès en ligne de commande, mais je ne suis pas aussi sûr du contrôleur. Naturellement, c'est la vue qui est remplacée.
Certaines différences peuvent exister en fonction de la chaîne d'outils. Code Complete est un livre Microsoft Press, alors peut-être utilisez-vous les technologies Microsoft pour cette interface graphique? Si c'est le cas, je pense qu'il peut y avoir une case à cocher lorsque vous créez l'application pour exposer les interfaces via COM ou DCOM. Pour certaines technologies Microsoft, je pense que les tableaux de ressources et la transmission des messages sont couplés de manière assez intensive avec tout ce que les assistants vous aident à créer rapidement. Je pense que ça s'améliore, mais si vous maintenez MFC ou Forms, cela pourrait faire un peu mal.
Dans certains cas, votre programme basé sur une interface graphique peut être un wrapper autour d'une interface de gestion ou peut avoir si peu de logique propre, qu'il n'y a pas grand-chose à contrôler par l'interface de ligne de commande. La création d'une application console distincte peut être plus rapide et vous permettre de créer des scripts, de tester ou d'utiliser ce qui est important.
Le point clé, je suppose, est que la suggestion n'est pas une règle. Si vous le suivez, vous devriez obtenir des tests unitaires et d'acceptation plus faciles ou une interface de secours lorsque vous ou un client préférez taper au lieu de cliquer. S'il est rentable, faites-le. Bonne chance.
De nos jours (au moins pour Java), il semble que tôt ou tard tous les programmes ajoutent tôt ou tard un service Web (SOAP ou Ajax ou les deux). Donc, en général, oui, pensez de cette façon, mais un frontal de service Web est plus probable qu'une ligne de commande si vous voulez une meilleure métaphore mentale ... et plus probable.
Cela dépend de l'utilité du programme de ligne de commande. Certaines choses, comme tracer un itinéraire sur une carte ou jouer à un jeu en 3D, ne se prêtent tout simplement pas à une interface en ligne de commande. Mais d'autres choses, comme les outils système, sont bien meilleures depuis la ligne de commande que depuis une interface graphique, pour la simple raison qu'elles peuvent être scriptées.
Le Dr Richard Hipp a dit un jour que son système d'exploitation GUI idéal était un bureau vide avec une icône pour ouvrir des fenêtres de commande et une autre icône pour ouvrir un navigateur Web. Je ressens presque la même chose. S'il serait utile en tant que programme en ligne de commande, et pas trop difficile à construire de cette façon, je le ferais. L'interface graphique pourrait être un programme complètement séparé, peut-être construit par quelqu'un d'autre!
C'est généralement une bonne idée, oui.
Par métaphore, les gens peuvent penser à cela comme une forme de conception RESTful. ... ce n'est pas, en soi, car une interface utilisateur (G) typique pourrait impliquer des transactions complexes en plusieurs étapes comme la création de compte.
Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.
Une fois, j'ai programmé une métaphore de l'interface utilisateur drag'n'drop dans le navigateur. Règles d'interaction très complexes sur le back-end pour rendre l'expérience utilisateur naturelle. J'ai résolu ce problème en faisant du site une API et l'interface graphique était une application complète qui générait des événements lors de l'action. Un module a détecté ces événements et, sur une minuterie, les a regroupés en "appels API" (pour l'efficacité du réseau).
Le résultat a été un système central complètement RESTful. Le deuxième résultat était que j'avais une interface pour des tiers, que je pouvais exposer en utilisant des profils d'affiliation selon le modèle commercial.
Il y a une façon différente de voir les choses. Plutôt que de supposer qu'une ligne de commande est la seule solution, pourquoi ne pas supposer que le contrôle vocal pourrait être utilisé à la place? Un paradigme entièrement différent est alors nécessaire.
Avant que Jobs ne prenne le contrôle d'Apple, des mécanismes de commande vocale très sophistiqués étaient à l'étude. Apple a étouffé cela en faveur de choses comme Siri.
Soupir.
Populaire et évident n'est pas toujours "le meilleur".