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?

92

Dans Code Complete, à la page 25, il est indiqué qu'il est judicieux de pouvoir remplacer facilement les classes d'interface utilisateur standard par une classe de ligne de commande.

Connaissant ses avantages pour les tests, qu'en est-il des problèmes que cela peut engendrer?

Ce travail supplémentaire rapportera-t-il vraiment 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 design plus complexe?

— Julio Rodrigues
source

2

En Perl, c’est à cela que servent des outils tels que MooseX :: Getopt et Plack :: Handler :: CLI .

— Ether

4

Si vous construisez d'abord votre programme avec une interface de ligne de commande, l'interface utilisateur peut être superposée, offrant ainsi beaucoup plus de flexibilité qu'une interface utilisateur profondément intégrée au programme. C'est à peu près la même chose pour les services Web.

— zzzzBov

28

Est toujours un mot fort.

— Mark Canlas

8

Veuillez prendre note de la citation initiale, qui est la suivante: "L’architecture doit être modularisée de manière à pouvoir remplacer une nouvelle interface utilisateur sans affecter les règles commerciales et les parties de sortie du programme. Par exemple, l’architecture doit permettre de retirer assez facilement une groupe de classes d'interface interactives et connectez un groupe de classes de ligne de commande. " Donc, CC ne dit pas que vous devez vous préparer à remplacer une interface graphique par une ligne de commande, il indique simplement que l'architecture doit s'adapter à la modification de l'interface utilisateur. La chose en ligne de commande GUI-> est juste un exemple.

— Sleske

2

@Vandell J'ai la deuxième édition de Code Complete et ceci n'est pas mentionné à la page 25. De quelle édition parlez-vous?

— JW01

43

Pouvoir réutiliser des fonctionnalités sous différentes interfaces (par exemple, interface graphique vs CLI contre REST) n'est pas toujours nécessaire, mais il est agréable d'avoir et de permettre une réutilisation fortuite pour un système, car d'autres personnes trouvent de nouveaux moyens d'interagir avec celui-ci.

Cela a 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 ces couches constituent une bonne pratique d'ingénierie, elles impliquent des coûts supplémentaires en développement, compréhension qui ne conduit pas nécessairement à une réduction des efforts dans d'autres domaines (maintenance, réutilisation, tests, etc.), il est donc utile de réfléchir un peu à ce sujet.
Un flux optimal pour un support peut être terrible pour les autres. Si la fonctionnalité a été conçue pour prendre en charge une interface graphique, il est peut-être trop bavard pour le Web . Toutes les fonctionnalités ne sont pas valables dans tous les médias.
Il y a un piège à essayer de définir un convertisseur générique entre services et interface utilisateur. Vous pouvez donc définir le contrat de service et dériver automatiquement (ou autant que possible) l'interface utilisateur de tous les supports. De nombreux projets ont trop coûté en efforts pour créer de tels cadres et y apporter toutes les personnalisations possibles en fonction de l'évolution des besoins.

Cela dit, selon mon expérience, la mise en œuvre de telles couches finissait toujours par payer l'effort. Dans quelques cas, j'ai réussi à déployer des systèmes à temps car nous avons dû échanger des médias (par exemple de l'intégration des services Web à l'interface utilisateur) quelques semaines avant la date d'échéance.

— Daniel Yokomizo
source

2

Comme d'autres commentaires l'ont noté, cela devrait augmenter la cohésion du code et réduire le couplage. Les deux devraient rendre votre code plus simple et plus facile à tester. Flow est plus un concept d'interface graphique et ne devrait généralement pas être présent dans d'autres fonctionnalités.

— BillThor

Je ne peux pas croire que cela n’a pas encore été mentionné, mais c’est l’essence même de l’architecture Model-View-Controller. Le but est de pouvoir échanger à volonté les vues et les contrôleurs, afin de réduire le couplage, comme le dit @BillThor. C'est le meilleur cas d'utilisation pour MVC.

— Rudolf Olah

110

Complètement à part les tests, l’avantage évident de cette approche est qu’elle rendra votre projet automatisable et scriptable . Si je suis capable d'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.

Bien sûr, que cela en vaille la peine ou non, dépend entièrement de savoir si de nombreux utilisateurs souhaitent automatiser votre programme.

— Maçon Wheeler
source

12

De nombreuses applications utilisent un modèle de plug-in pour la génération de scripts. Généralement, le modèle objet est exposé et un langage tel que python est utilisé pour écrire les scripts. Je ne pense pas que les paramètres de ligne de commande fonctionnent pour une application non triviale.

— Softveda

Un autre avantage peut être la découvrabilité. La fonction Ctrl-Maj-P de Sublime Text en est un exemple fantastique. S'il y a des fonctionnalités obscures que je veux, plutôt que d'avoir à chercher dans les menus, je tape simplement le nom qui, à mon avis, serait appelé, je peux voir la commande (et le raccourci) et pouvoir l'exécuter immédiatement.

— Adam Iley

OpenDJ, un serveur LDAP basé sur Java et open source, en est un excellent exemple: la ligne de commande pour chaque modification apportée dans l'interface graphique est disponible dans la boîte de dialogue de confirmation.

— Franck

1

@ Marnixv.R .: les gestes ne sont qu'un moyen pratique d'effectuer une action pouvant être spécifiée par une commande, par exemple "Zoom avant sur 35.73N 118.23W". Un dessin pourrait être saisi en tant que commande, bien que cela ne soit pas pratique. Néanmoins, je pense qu’il est très utile de disposer d’une interface facilement scriptable et que très peu de travail soit nécessaire pour en créer une.

— kevin cline

7

+1: Un autre avantage clé est qu'il est facile de consigner les actions de l'utilisateur, ce qui simplifie la reproduction des problèmes de production.

— kevin cline

81

Ce n'est pas un travail supplémentaire, mais un travail différent . Si vous le faites correctement, non seulement cela ne le rendra pas plus complexe, mais il le simplifiera davantage car il vous obligera à découpler votre conception. Que vous mettiez ou non réellement en œuvre la CLI, votre conception serait mieux à même de vous permettre de le faire.

— Karl Bielefeldt
source

4

-1 pour plusieurs déclarations complètement incorrectes. Bien sûr, cela le rendra plus complexe. Après tout, il s’agit d’une exigence / fonctionnalité supplémentaire.

— Boris Yankov

@BorisYankov Je pense qu'il voulait dire "compliqué" au lieu de "complexe" - ils ont un son similaire et ont une signification commune, ils sont donc faciles à confondre à l'occasion

— Izkata

43

Un avantage clé qui ne semble pas avoir été mentionné est que le fait de pouvoir le faire impose le découplage strict de l'interface utilisateur du code sous-jacent. L’un des principaux avantages est que cela signifie que si vous devez modifier considérablement l’interface graphique (par exemple, les normes iOS en normes OSX, ou un moteur graphique en un autre), c’est tout ce que vous devez changer, car le code sous-jacent ne dépend pas de la mise en page de l'interface utilisateur. Cela ne peut pas être, car si c'était le cas, les outils en ligne de commande ne fonctionneraient pas.

En dehors de cela, l'automatisation des tests est un avantage clé.

— mots
source

Corrigez-moi si je me trompe, mais passer d'une interface graphique à une autre nécessiterait encore un travail important en termes de validation de formulaire / affichage des messages d'erreur, de paramétrage des gestionnaires d'événement, etc.

— Cliquez sur Vote à la hausse

5

Oui, mais toute cette validation fait partie d’une bonne interface utilisateur, que j’ai dit que vous deviez changer. Le code backend qui stocke (par exemple) l’état actuel du compte de l’utilisateur, l’algorithme de recherche d’articles, les règles spécifiques du jeu, etc. L’essentiel ici est que si je dois passer de l’interface utilisateur souris / clavier à interface utilisateur à écran tactile pour un jeu, je devrais toujours être en mesure d'utiliser le même moteur de gestion pour gérer les calculs de combat et les scores, afin de pouvoir me concentrer sur l'écriture de nouveaux gestionnaires d'événements utilisant le même système sous-jacent.

— deworde

2

ce n'est pas facile du tout, je déteste écrire des gestionnaires d'événements et du code de validation de formulaire bien plus que du code commercial. (Bien que je sois d'accord avec vous, ils devraient être

— dissociés

2

@ClickUpvote Dans une certaine mesure, cela dépend de la manière dont vous implémentez votre interface graphique. Une interface graphique vraiment mince qui envoie simplement des messages ValueChanged à une classe de support et reçoit des messages ValueValid / ValueInvalid en réponse sera beaucoup plus facile à échanger celle qui effectue toute la validation dans les événements OnTextboxChanged.

— Dan Neely

@ClickUpvote Je suis assez d'accord, c'est pourquoi je veux pouvoir me concentrer sur ce que j'aime sans être corrompu ou donner ce que je déteste sous mon attention afin que je puisse en finir avec le plus tôt possible.

— deworde

17

Oui c'est presque toujours une bonne idée.

Si vous suivez cette approche, vous ne disposerez probablement pas d'une logique métier ou d'un accès aux données dans le même thread que l'interface graphique et derrière un gestionnaire d'interface graphique. Cette seule raison vaut la peine d'investir dans.

— Codeur
source

2

Quel serait l’avantage de cela si vous écrivez par exemple un éditeur de texte?

— Nikie

5

@nikie Parce que, par exemple, vous pouvez remplacer votre affichage d'éditeur de texte WYSIWIG par un système frontal au format texte simple ou à balises, et tant qu'il transmet les mêmes informations au modèle sous-jacent, votre infrastructure existante continue de fonctionner.

— deworde

5

Je pense que c'est une bonne idée. De plus, la possibilité d'écrire un deuxième serveur frontal en ligne de commande prouve que la logique métier est totalement découplée de toute architecture de serveur d'applications particulière.

— Tulains Córdova
source

5

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 traverser d'autres parties de l'interface utilisateur.

Où en tant que développeur peut simplement exécuter l'interface utilisateur directement. J'ai vu des situations dans lesquelles un développeur ne pouvait pas reproduire un problème d'utilisateurs avant d'avoir réellement utilisé le produit.

Il faut donc en tenir compte lors de la création de tests.

— Simon O'Doherty
source

3

Terrible conseil.

C'est un peu yagni (vous n'en aurez pas besoin).

Exposer une interface de ligne de commande n’est pas la même chose que de structurer votre application de manière à prendre en charge le test unitaire ou à se conformer à n’importe quelle partie de SOLID ou à toute pratique de programmation que je recommanderais.

Cela ne fonctionne pour aucune interface utilisateur qui ne conviendrait pas pour une interface en ligne de commande. MS Paint est une application très simple, mais comment, dans n'importe quelle situation, verriez-vous un avantage à pouvoir le contrôler à partir d'une ligne de commande?

Cela ne vous aiderait pas à implémenter les scripts. Cela entraverait tout progrès dans cette direction.

La seule chose positive est que cela est apparu à la page 25, donc au moins, vous recevez un avertissement vous indiquant que le reste du livre pourrait être… malodorant. Je l'ai lu il y a longtemps et je ne l'aimais pas, alors je suis partial.

— Ian
source

1

Approuvé +100000000

4

Scriptable MSPaint semble vraiment utile.

— RoundTower

OMI la meilleure réponse. Depuis que je suis le mantra "ne pas appliquer" YAGNI "", j'ai beaucoup plus de temps à me concentrer sur le vrai travail et il me reste même assez de temps pour expérimenter beaucoup. Essayer d'être intelligent à l'avance m'a montré que la plupart du temps, le client souhaitait une extension différente de celle mentionnée précédemment, de sorte que vous ne perdiez pas de temps pour une tâche inutile.

— topskip

Interface de ligne de commande PSPaint + = AutoCAD

— Vorac

-1 (si je pouvais) Notez qu'il ne dit pas "implémenter une CLI aussi bien qu'une interface graphique"; il dit "prendre en charge la mise en œuvre d'une interface utilisateur alternative, comme une interface de ligne de commande".

— Mark Hurd

2

S'appuyant sur les propos de Mason Wheeler, le fait de pouvoir interagir avec une application via une ligne de commande facilite l'automatisation des tâches.

Ceci est particulièrement utile lors des tests.

Pour donner un exemple concret, si je souhaite exécuter des tests automatisés sur une application, je souhaite éventuellement l’installer automatiquement. Pour ce faire, je pourrais transmettre les paramètres suivants, "myApplication.exe / silentinstall".

Je pourrais le programmer pour que, lorsque je spécifie ce commutateur de ligne de commande, une installation se fasse en arrière-plan, en mode silencieux, sans le programme d'installation de l'interface graphique. Toute entrée dans le programme d’installation (telle que le répertoire d’installation) pourrait éventuellement être extraite 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 permettant de faire la même chose (à l'aide d'une combinaison de commutateurs et d'entrées de ligne de commande). Cela signifie que je peux combiner un script PowerShell ou DOS pour automatiser le lancement des tests, puis créer une tâche planifiée pour que les scripts soient exécutés toutes les nuits, par exemple.

Certaines applications disposent de commutateurs de ligne de commande qui spécifient qu’une application doit s’ouvrir avec certaines options (par exemple, je pourrais utiliser «/ maxim» pour ouvrir l’application dans une fenêtre agrandie).

Il existe de nombreux scénarios dans lesquels une interface de ligne de commande pourrait être utilisée. Ce ne sont que quelques exemples.

— CiaranG
source

1

Remarquez à nouveau la phrase: "C'est une bonne idée de pouvoir remplacer facilement les classes d'interface utilisateur habituelles par une ligne de commande". Cela ne signifie pas que vous devez écrire une CLI, mais simplement que vous pouvez le faire facilement.

Donc, ce qui est écrit, c'est que votre interface utilisateur doit être découplée du reste du code.

— José Dinuncio
source

2

Je pense que vous aviez l'intention de faire un commentaire, non?

— Julio Rodrigues

1

Cela dépend et quand je dis que cela dépend, il ne s'agit pas seulement de quelques cas marginaux, mais cela dépend beaucoup de l'application et du public cible. En supposant que nous éliminions les jeux de l'équation, il existe encore un large éventail d'applications que vous écrivez peut-être lorsqu'une commande du genre est peu probable ou ne sera jamais mise en œuvre. De mémoire, toute application ciblant un environnement mobile (par exemple, iOS, Android, etc.) tombera probablement sous cette rubrique.

En gardant cela à l'esprit, dans l'espace logiciel général, il est peu probable qu'une application fortement dépendante de la visualisation (par exemple, PowerPoint, Maya , etc.) puisse voir un remplacement de ligne de commande implémenté. En fait, dans le cas de logiciels graphiques tels que Maya, il peut être considéré comme un bon exercice mental de déterminer comment une version complète et appropriée en 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 est tout à fait possible de rencontrer des applications courantes dans lesquelles une commande telle que l’interface est improbable, voire souhaitables, même si la création de scripts de l’application peut être souhaitable.

Ensuite, si nous examinons la forme suggérée du point de vue de l’architecture logicielle générale, je peux voir où il serait logique de se 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 si cela n'interagit pas directement avec l'utilisateur (par exemple, la saisie de gestes), il est probable que l'architecture globale doit être améliorée. Pour 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 devrait permettre l'accès via une ligne de commande ou une interface utilisateur. En outre, à long terme,

À 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 des mots aurait peut-être été un peu meilleure pour faire passer le message. .

— rjzii
source

1

Je ne suis pas en désaccord en général, mais l'un des grands atouts de Maya est le fait qu'il dispose d'une API de script très puissante (à l'origine, MELScript, maintenant Python).

— Jwd

@jwd - Maya est un exemple que j'ai choisi parce que je l'ai utilisé il y a quelques années, si vous en avez un meilleur dans le même ordre d'idée, faites-le-moi savoir. Peut-être que Bryce, bien que ce ne soit pas aussi connu?

— rjzii

0

Ç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, la vue est ce qui est remplacé.

Certaines différences peuvent exister en fonction de la chaîne d'outils. Code Complete est un livre Microsoft Press. Vous utilisez peut-être les technologies Microsoft pour cette interface graphique? Si tel est le cas, une case à cocher pourrait exister lorsque vous créez l'application pour exposer les interfaces via COM ou DCOM. Pour certaines technologies Microsoft, je pense que les tables de ressources et la transmission de messages sont étroitement associées à tout ce que les assistants vous aident à créer rapidement un prototype. Je pense que la situation s'améliore, mais si vous maintenez MFC ou Forms, cela pourrait vous faire mal.

Dans certains cas, votre programme basé sur une interface graphique peut être un wrapper autour d’une interface de gestion ou peut-être avoir si peu de logique à lui seul qu’il n’ya pas grand chose à contrôler par l’interface de ligne de commande. Il peut être plus rapide de créer une application de console distincte tout en vous permettant de créer un script, de tester ou d’utiliser ce qui est important.

L’essentiel, je suppose, c’est que la suggestion n’est pas une règle. Si vous le suivez, vous devriez obtenir des tests d'acceptation et d'unité plus faciles, ou une interface de secours, lorsque vous ou un client préférez taper au lieu de cliquer. Si c'est rentable, faites-le. Bonne chance.

— DeveloperDon
source

4

-1: Code Complete est un livre indépendant du langage sur la programmation.

— deworde

1

Il n'a jamais dit le contraire.

— Cliquez vote positif

Et sa question était spécifique au développement de l'interface utilisateur ... Votre point de vue, Monsieur deworde?

— Ian

0

Cela dépend de l'utilité du programme en 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 de ligne de commande. Mais d'autres éléments, tels que les outils système, sont bien meilleurs en ligne de commande qu'en interface graphique, pour la simple raison qu'ils peuvent être scriptés.

Le Dr. Richard Hipp a dit un jour que son système d'exploitation graphique idéal était un bureau vierge avec une icône pour ouvrir les fenêtres de commande et une autre icône pour ouvrir un navigateur Web. Je ressens presque la même chose. Si ce serait utile comme 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!

— GlenPeterson
source

Pourquoi tracer un itinéraire sur une carte ne se prête pas à l'automatisation CLI? Quelque chose PlotRoute(startPoint, endPoint)est assez simple.

— Mason Wheeler

@MasonWheeler - Je pense que ce serait plus commePlotRoute(startPoint, endPoint, chart)

— Fabricio Araujo

0

De nos jours (du moins pour Java), il semble que tôt ou tard tous les programmes ajoutent un service Web (SOAP ou Ajax ou les deux) tôt ou tard. Donc, en général, oui, pensez-y, mais un serveur Web frontal est plus probable qu'une ligne de commande si vous voulez une meilleure métaphore mentale ... et plus probable.

— ArtB
source

0

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 de la parole pourrait être utilisé? Un paradigme totalement différent est alors requis.

Avant que Jobs ne reprenne Apple, des mécanismes de contrôle de la voix très sophistiqués étaient en cours d’exploration. Apple a écarté cela en faveur de choses comme Siri.

Soupir.

Populaire et évident ne sont pas toujours "meilleurs".

— Siajanai
source

L'une des principales raisons de la ligne de commande est principalement de pouvoir tester et écrire les fonctionnalités du logiciel. Il peut devenir un peu gênant (ou au moins disque-lourd) d’enregistrer des clips audio de nos voix juste pour tester le logiciel à l’unité ou exécuter un script batch.

0

C'est généralement une bonne idée, oui.

Par métaphore, les gens peuvent y voir une forme de conception RESTful. .... ce n’est pas, en soi, qu’une interface utilisateur typique (G) peut impliquer des transactions complexes en plusieurs étapes telles que 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 UI drag'n'drop dans le navigateur. Des règles d’interaction très complexes sur le back-end pour rendre l’UX plus 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 d'une action. Un module a capturé ces événements et les a intégrés dans des "appels API" (pour l'efficacité du réseau).

Le résultat est un système central complètement RESTful. Le deuxième résultat est que j’avais une interface pour des tiers, que je pouvais exposer à l’aide de profils d’affiliation conformes au modèle commercial.

— NouveauAlexandria
source

-1

L'un des avantages est que vous serez obligé de penser au flux de l'interface utilisateur du point de vue de l'utilisateur. (Qu'est-ce que j'essaie d'atteindre? Quel contexte dois-je créer? Dans ce contexte, comment atteindre l'objectif?)

Il existe une grande différence entre "créer un compte bancaire" et "écrire un document ms word". Même si vous ne construisez pas de CLI, cela peut ajouter de la valeur simplement de considérer le "contexte de CLI" nécessaire. Les modèles ne vivent pas uniquement dans le modèle d'objet métier!

— Aswidi
source