Ist es eine gute Idee, eine Architektur zu entwerfen, die denkt, dass die Benutzerschnittstellenklassen durch eine Befehlszeilenschnittstelle ersetzt werden können?

In Code Complete, Seite 25, heißt es, dass es eine gute Idee ist, die regulären Benutzerschnittstellenklassen einfach durch eine Befehlszeilenklasse zu ersetzen.

Was ist mit den Problemen, die das Testen mit sich bringen kann?

Lohnt sich diese zusätzliche Arbeit wirklich für Web- und Mobilprojekte? Was ist mit kleinen und mittleren Projekten? gelten die gleichen regeln? Was ist, wenn Ihr Design dadurch komplexer wird?

Die Möglichkeit, Funktionen unter verschiedenen Schnittstellen (z. B. GUI vs CLI vs REST) wiederzuverwenden, ist nicht immer erforderlich, aber es ist schön, ein System zufällig wiederverwenden zu können, da andere Benutzer neue Möglichkeiten finden, mit ihm zu interagieren.

Dies hat einige Nachteile, die gewichtet werden müssen:

1. Es werden zusätzliche Abstraktionsebenen benötigt (manchmal sogar Ebenen). Obwohl diese Schichten eine gute technische Praxis sind, verursachen sie zusätzliche Kosten bei der Entwicklung, was möglicherweise nicht zu einer Verringerung des Aufwands in anderen Bereichen (z. B. Wartung, Wiederverwendung, Tests) führt. Es lohnt sich also, ein wenig darüber nachzudenken.
2. Strömung, die für ein Medium optimal ist, kann für andere schrecklich sein. Wenn die Funktionalität zur Unterstützung einer GUI entwickelt wurde, ist sie möglicherweise zu gesprächig für das Web . Nicht jede Funktionalität lohnt sich in jedem Medium.
3. Es ist eine Falle, einen generischen Konverter zwischen Diensten und Benutzeroberfläche zu definieren, sodass man den Servicevertrag definieren und automatisch (oder so weit wie möglich) die Benutzeroberfläche für alle Medien ableiten kann. Viele Projekte haben zu viel Mühe damit verschwendet, solche Frameworks zu erstellen und jede mögliche Anpassung vorzunehmen, wenn sich die Anforderungen ändern.

Nach meiner Erfahrung hat sich die Implementierung solcher Schichten jedoch immer gelohnt. In einigen Fällen gelang es mir, Systeme rechtzeitig bereitzustellen, da wir einige Wochen vor dem Fälligkeitsdatum die Medien (z. B. von der Integration von Webservices zur Benutzeroberfläche) austauschen mussten.

Abgesehen vom Testen besteht der offensichtliche Vorteil dieses Ansatzes darin, dass Ihr Projekt automatisierbar und skriptfähig ist . Wenn ich in der Lage bin, Befehlszeilenbefehle an ein Programm zu senden, kann ich ein Skript schreiben, um komplizierte Aufgaben viel einfacher (und zuverlässiger!) Auszuführen, als ich ein Makro erstellen könnte, um dasselbe auf einer GUI zu automatisieren.

Ob sich das wirklich lohnt oder nicht, hängt natürlich ganz davon ab, ob Sie viele Benutzer haben, die Ihr Programm automatisieren möchten oder nicht.

Es ist keine zusätzliche Arbeit, nur eine andere Arbeit. Wenn Sie es richtig machen, wird es nicht nur nicht komplexer, sondern auch einfacher, da Sie gezwungen sind, Ihr Design zu entkoppeln. Unabhängig davon, ob Sie die CLI tatsächlich implementieren oder nicht, ist Ihr Entwurf besser geeignet, um dies zu ermöglichen.

Ein wichtiger Vorteil, der nicht erwähnt worden zu sein scheint, ist, dass dies eine strikte Entkopplung der Benutzeroberfläche vom zugrunde liegenden Code erzwingt . Ein wesentlicher Vorteil dabei ist , dass es bedeutet , dass , wenn Sie brauchen , um signifikant die GUI zu ändern (sagen iOS Standards OSX Standards oder eine grafische Maschine zu einem anderen), das ist alles Sie ändern müssen, da der zugrundeliegende Code ist nicht abhängig von das Layout der Benutzeroberfläche. Es kann nicht sein, denn wenn es so wäre, würden die Kommandozeilen-Tools nicht funktionieren.

Darüber hinaus ist die Automatisierung von Tests ein entscheidender Vorteil.

Ja, das ist fast immer eine gute Idee.

Wenn Sie diesem Ansatz folgen, haben Sie wahrscheinlich keine Geschäftslogik oder keinen Datenzugriff in demselben Thread wie die GUI und hinter einigen GUI-Handlern. Allein in diesen Grund lohnt es sich zu investieren.

Ich denke, es ist eine gute Idee. Die Möglichkeit, ein zweites Befehlszeilen-Front-End zu schreiben, beweist letztendlich, dass die Geschäftslogik vollständig von einer bestimmten Anwendungsserver-Architektur entkoppelt ist.

Die einzige Gefahr, die ich dabei sehe, ist, dass der Benutzer normalerweise andere Teile der Benutzeroberfläche durchqueren muss, um zu einem bestimmten Teil der Benutzeroberfläche zu gelangen.

Wobei der Entwickler einfach die Benutzeroberfläche direkt ausführen kann. Ich habe Situationen erlebt, in denen ein Entwickler ein Benutzerproblem nicht reproduzieren konnte, bis er das Produkt tatsächlich verwendet hat.

Berücksichtigen Sie dies also auch beim Erstellen von Tests.

Schreckliche Ratschläge.

Es ist ein bisschen yagni (du wirst es nicht brauchen).

Das Anzeigen einer Befehlszeilenschnittstelle ist nicht dasselbe wie das Strukturieren Ihrer App in einer Weise, die Unit-Tests unterstützt oder mit einem Teil von SOLID oder einer von mir empfohlenen Programmierpraxis übereinstimmt.

Es funktioniert nicht für eine Benutzeroberfläche, die einfach nicht für eine Befehlszeilenschnittstelle geeignet ist. MS Paint ist eine wirklich einfache Anwendung, aber wie würden Sie in jeder Situation einen Vorteil darin sehen, sie über eine Befehlszeile steuern zu können?

Es würde Ihnen nicht helfen, Skripte zu implementieren. Es würde tatsächlich jeden Fortschritt in diese Richtung behindern.

Das einzig Positive ist, dass es auf Seite 25 auftaucht, sodass Sie zumindest gewarnt werden, dass der Rest des Buches vielleicht ... stinkt. Ich habe es vor langer Zeit gelesen und mochte es nicht, also bin ich voreingenommen.

Aufbauend auf dem, was Mason Wheeler gesagt hat, macht es die Interaktion mit einer Anwendung über eine Befehlszeile sehr einfach, Aufgaben zu automatisieren.

Dies ist besonders nützlich beim Testen.

Um ein praktisches Beispiel zu geben: Wenn ich automatisierte Tests für eine Anwendung ausführen möchte, möchte ich die Anwendung möglicherweise automatisch installieren. Dazu übergebe ich möglicherweise die folgenden Parameter "myApplication.exe / silentinstall".

Ich kann es so programmieren, dass bei Angabe dieser Befehlszeilenoption eine Installation im Hintergrund ohne das GUI-Installationsprogramm ausgeführt wird. Alle Eingaben in das Installationsprogramm (z. B. das Installationsverzeichnis) können möglicherweise aus einer XML-Datei entnommen werden.

Nehmen Sie ein anderes Beispiel. Die GUI von Microsoft Test Manager (im Lieferumfang von Visual Studio enthalten) ermöglicht Benutzern das Starten von Testläufen über die GUI-Oberfläche, bietet jedoch auch eine Befehlszeilenschnittstelle, über die dasselbe getan werden kann (mithilfe einer Kombination aus Befehlszeilenschaltern und Eingaben). Dies bedeutet, dass ich ein PowerShell- oder DOS-Skript zusammenstellen kann, um das Starten von Tests zu automatisieren, und dann eine geplante Aufgabe erstellen kann, damit die Skripts möglicherweise jede Nacht ausgeführt werden.

Einige Anwendungen verfügen über Befehlszeilenoptionen, die festlegen, dass eine Anwendung mit bestimmten Optionen geöffnet werden soll (z. B. kann die Anwendung mit "/ maximize" in einem maximierten Fenster geöffnet werden).

Es gibt viele Szenarien, in denen eine Befehlszeilenschnittstelle zum Einsatz kommen könnte. Dies sind nur einige Beispiele.

Beachten Sie den Satz noch einmal: "[Es ist eine gute Idee, die regulären Benutzerschnittstellenklassen einfach durch eine Befehlszeile zu ersetzen". Es bedeutet nicht, dass Sie eine CLI schreiben müssen, nur, dass Sie es einfach tun können.

Es heißt also, dass Ihre Benutzeroberfläche vom Rest des Codes entkoppelt sein sollte.

Es kommt darauf an, und wenn ich sage, dass es darauf ankommt, geht es nicht nur darum, ein paar Randfälle zu haben, sondern es ist sehr abhängig von der Anwendung und der Zielgruppe. Angenommen, wir entfernen Spiele aus der Gleichung, dann gibt es immer noch eine Vielzahl von Anwendungen, die Sie möglicherweise schreiben, wenn ein Befehl wie dieser unwahrscheinlich ist oder niemals implementiert wird. Aus der Vogelperspektive fällt wahrscheinlich jede Anwendung, die auf eine mobile Umgebung (z. B. iOS, Android usw.) abzielt, unter diese Überschrift.

In Anbetracht dessen ist es unwahrscheinlich, dass im allgemeinen Softwarebereich für Anwendungen, die stark von der Visualisierung abhängig sind (z. B. PowerPoint, Maya usw.), jemals eine Befehlszeilenersetzung implementiert wird. Tatsächlich ist es im Fall von Grafiksoftware wie Maya eine gute mentale Übung, festzustellen, wie eine vollständige und ordnungsgemäße Befehlszeilenversion funktionieren würde, und dies ist möglicherweise vom Standpunkt des Benutzers aus nicht möglich. Somit ist klar, dass es definitiv übliche Anwendungen gibt, bei denen es unwahrscheinlich ist, dass eine befehlsähnliche Schnittstelle jemals gesehen wird oder wünschenswert ist, selbst wenn Skripten für die Anwendung wünschenswert sein könnten.

Wenn wir uns als Nächstes die vorgeschlagene Form vom Standpunkt der allgemeinen Softwarearchitektur ansehen, kann ich sehen, wo es sinnvoll wäre, sich regelmäßig die Frage zu stellen: "Wie kann ich ohne die Benutzeroberfläche auf diese Funktion zugreifen?" Wenn dies nicht möglich ist und keine direkte Interaktion mit dem Benutzer stattfindet (z. B. Gesteneingabe), besteht im Allgemeinen die Gefahr, dass die Gesamtarchitektur verbessert werden muss. Um das Testen zu vereinfachen, sollten Sie in der Lage sein, direkt auf Befehle zuzugreifen, ohne die Benutzeroberfläche zu durchlaufen, auch wenn sie möglicherweise nicht über eine Befehlszeile aufgerufen werden. Dies bedeutet im Allgemeinen, dass eine solide API vorhanden sein muss und theoretisch eine gute API den Zugriff über die Befehlszeile oder die Benutzeroberfläche ermöglichen sollte. Darüber hinaus auf lange Sicht,

Letztendlich denke ich, dass das, worauf der Vorschlag abzielt, Sinn macht (dh, Sie sollten eine gute API haben und Ihre Benutzeroberfläche darauf aufbauen), aber die Wortauswahl war möglicherweise etwas besser, um den Punkt zu verdeutlichen .

Es hängt davon ab, ob.

Oft partitionieren wir unsere Programme als model / view / controller oder model / view / view / model. Es scheint, dass das Modell den Zugriff über die Befehlszeile zulassen sollte, aber ich bin mir über den Controller nicht so sicher. Natürlich wird die Ansicht ersetzt.

Ein gewisser Unterschied kann aufgrund der Werkzeugkette bestehen. Code Complete ist ein Microsoft Press-Buch. Verwenden Sie also möglicherweise Microsoft-Technologien für diese GUI? In diesem Fall gibt es möglicherweise ein Kontrollkästchen, wenn Sie die App zum Anzeigen von Schnittstellen über COM oder DCOM erstellen. Bei einigen Microsoft-Technologien sind die Ressourcentabellen und die Nachrichtenübermittlung meiner Meinung nach ziemlich eng mit allem verknüpft, was die Assistenten für einen schnellen Prototyping-Prozess bieten. Ich denke, es wird besser, aber wenn Sie MFC oder Formulare beibehalten, kann es ein bisschen weh tun.

In einigen Fällen handelt es sich bei Ihrem GUI-basierten Programm möglicherweise um einen Wrapper um eine Verwaltungsschnittstelle oder es verfügt über so wenig eigene Logik, dass über die Befehlszeilenschnittstelle nicht viel gesteuert werden kann. Das Erstellen einer separaten Konsolen-App ist möglicherweise schneller und lässt Sie dennoch das Wesentliche skripten, testen oder verwenden.

Der entscheidende Punkt, denke ich, ist, dass der Vorschlag keine Regel ist. Wenn Sie dem folgen, sollten Sie einfachere Tests für Einheiten und Abnahmen oder eine Fallback-Oberfläche erhalten, wenn Sie oder ein Kunde es vielleicht vorziehen, zu tippen, anstatt zu klicken. Wenn es sich auszahlt, tun Sie es. Viel Glück.

Es hängt davon ab, wie nützlich das Kommandozeilenprogramm wäre. Einige Dinge, wie das Zeichnen einer Route auf einer Karte oder das Spielen eines 3D-Spiels, eignen sich einfach nicht für eine Befehlszeilenschnittstelle. Aber andere Dinge, wie System-Tools, sind von der Kommandozeile aus viel besser als von einer GUI aus, und zwar aus dem einfachen Grund, dass sie per Skript erstellt werden können.

Dr. Richard Hipp sagte einmal, sein ideales GUI-Betriebssystem sei ein leerer Desktop mit einem Symbol zum Öffnen von Befehlsfenstern und einem weiteren Symbol zum Öffnen eines Webbrowsers. Mir geht es fast genauso. Wenn es als Befehlszeilenprogramm nützlich und nicht zu schwierig wäre, es so zu erstellen, würde ich es tun. Die GUI könnte ein völlig separates Programm sein, das möglicherweise von jemand anderem erstellt wurde!

Heutzutage (zumindest für Java) scheinen früher oder später alle Programme früher oder später einen Webdienst (SOAP oder Ajax oder beides) hinzuzufügen. Also im Allgemeinen denke ich ja so, aber ein Web-Service-Front-End ist wahrscheinlicher als eine Befehlszeile, wenn Sie eine bessere mentale Metapher wollen ... und eine wahrscheinlicher.

Es gibt eine andere Sichtweise. Anstatt davon auszugehen, dass eine Befehlszeile der einzige Weg ist, warum nicht davon ausgehen, dass stattdessen die Sprachsteuerung verwendet wird? Ein völlig anderes Paradigma ist dann erforderlich.

Bevor Jobs Apple übernahm, wurden sehr ausgefeilte Sprachsteuerungsmechanismen untersucht. Apple hat dies zugunsten von Dingen wie Siri unterdrückt.

Seufzer.

Populär und offensichtlich sind sie nicht immer die Besten.

Das ist im Allgemeinen eine gute Idee, ja.

By-Metapher, Menschen können dies als eine Form von RESTful Design denken. ... es ist per se nicht so, dass eine typische (G) Benutzeroberfläche komplexe mehrstufige Transaktionen wie die Kontoerstellung beinhalten könnte.

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

Ich habe einmal eine Drag'n'Drop-UI-Metapher im Browser programmiert. Sehr komplexe Interaktionsregeln im Back-End , damit sich das UX natürlich anfühlt. Ich habe das gelöst, indem ich die Site zu einer API gemacht habe und die GUI eine vollständige App war, die Ereignisse nach einer Aktion generierte. Ein Modul hat diese Ereignisse abgefangen und sie in einem Timer zu API-Aufrufen gebündelt (aus Gründen der Netzwerkeffizienz).

Das Ergebnis war ein vollständig RESTful-Kernsystem. Das zweite Ergebnis war, dass ich eine Schnittstelle für Dritte hatte, die ich mit Hilfe von Zugehörigkeitsprofilen gemäß dem Geschäftsmodell offenlegen konnte.

Ein Vorteil ist, dass Sie gezwungen sind, über den Fluss der Benutzeroberfläche aus der Benutzerperspektive nachzudenken. (Was versuche ich zu erreichen? Welchen Kontext muss ich einrichten? In diesem Kontext, wie erreiche ich das Ziel?)

Es gibt einen großen Unterschied zwischen "Bankkonto erstellen" und "ms-Word-Dokument schreiben". Auch wenn Sie keine CLI erstellen, kann dies nur unter Berücksichtigung des erforderlichen "CLI-Kontexts" einen Mehrwert schaffen. Modelle leben nicht nur im Geschäftsobjektmodell!