Die Nachrichten unter den angenehm Unerwarteten weckten alle möglichen Erinnerungen, süß und nicht so. Ich habe auch diesen Artikel von ihr bekommen und hatte sofort die Nostalgie satt, und ich wollte in den letzten sieben Jahren eine so gewichtige Ellipse von ihr spielen.
Dephi war eine absolut brillante Lösung. Nun, Sie wissen, wie die Beatles, als grafische Computerschnittstelle mit Maussteuerung, als Verbrennungsmotor. Die geniale Lösung, die in unserem Leben so weit verbreitet ist, dass Sie nicht einmal glauben können, dass sie einmal nicht vorhanden war, und das Zeichnen von Fenstern, Kontrollkästchen und Schaltflächen in Windows kann ein echtes Problem sein.
Der geniale, absolut Teil von Delphi war VCL - derselbe Satz von Kontrollkästchen und Schaltflächen für Windows-Fenster, die plötzlich so einfach und unkompliziert ineinander zu ziehen und schöne und ungewöhnliche Windows-Anwendungen zu erstellen waren.
Und wie bei jeder anständigen Benutzeroberfläche funktionierte dies natürlich entsprechend dem Ereignismodell. OnClick in das Schaltflächenobjekt beschreibt alles, was die Schaltfläche tut. OnChange beim Eingeben eines Textfeldes ist alles wie bei Erwachsenen. Aber danach - weiter gab es leider noch nichts.
Nichts von dem, was wir jetzt wissen, meine ich. MVC zum Beispiel - Delphi, denken Sie, es bestand aus einem V, dann blieb alles dem Entwickler ausgeliefert. Direkt von OnClick, um eine Anfrage in die Datenbank zu ziehen? Ja, bitte. Öffnen Sie in OnChange eine Datei und versuchen Sie, darauf zu schreiben. Wenn sich herausstellt, dass die vorhandene Datei nicht leise mit einer Verletzung des Speicherzugriffs abstürzt - bei jedem Schritt (dies hat jedoch nichts mit Delphi als Plattform zu tun).
Und ich muss sagen, dass es viele Jahre lang für alle vollkommen glücklich war und einige immer noch ziemlich glücklich damit. Die Vorteile einer schlanken und schönen Bibliothek von UI-Komponenten sind sofort sichtbar. Die Vorteile von Controllern und Modellen werden weder im ersten Entwicklungsjahr noch in den ersten hundert Kilobyte Quellcodes deutlich.
Und selbst wenn es so geworden ist - es ist leicht zu vergessen, gibt es hier eine Gedankenfalle, wie jene optischen und akustischen Illusionen, über die im Internet heftig diskutiert wird. Lassen Sie mich versuchen, eine kleine Brücke von Delphi zu einem modernen Verständnis der Benutzeroberfläche zu schlagen, und wir können herausfinden, was passiert.
Die Schlüsselidee: Wir trennen die Präsentation von den Daten, das Widget getrennt, die gesamte Arbeit mit den darin enthaltenen Informationen ist getrennt. Wie getrennt? Angenommen, die Schaltfläche hat noch eine Inschrift und manchmal ein Symbol. Der Benutzer selbst kann diese Inschrift in das Textfeld einfügen, und manchmal enthält das Textfeld eine andere Inschrift, die dem Benutzer erklärt, was genau er fährt. Allgemeine Regel: Das Widget zeigt mindestens (SIC!) Logik an. Die darin möglicherweise vorhandene Logik sollte nur der Anzeige zugeordnet werden und sonst nichts. Wenn die Schaltfläche nicht bereit ist, sich zusammen mit der Beschriftung zu dehnen, sollte die Beschriftung entweder irgendwie abgeschnitten werden (z. B. die Auslassungspunkte und die Vollversion in der QuickInfo anzeigen) oder einen Fehler ausgeben, wenn Sie versuchen, den Wert mehr als passend festzulegen (obwohl dies der Fall ist) Die Idee ist so lala, dass ein solcher Fehler höchstwahrscheinlich bereits während der Ausführung des Programms im ungünstigsten Moment auftritt.
Ein Texteingabefeld kann Wagenübersetzungen aus dem Text löschen, wenn es einzeilig ist. Es ist jedoch nicht erforderlich, beispielsweise nur Zahlen einzugeben - dies ist nicht seine Aufgabe. So wie im Button-Click-Handler keine Überprüfungen erforderlich sind, keine Aufrufe neu gezeichnet werden, muss der Button-Handler den externen Code abrufen, der bereits für die Logik der Benutzeroberfläche und der gesamten Anwendung verantwortlich ist.
Und wenn Sie in einer wunderschönen neuen Jet-Welt leben und auf all diese OOP-Event-Probleme herabblicken, bleibt das Prinzip dasselbe: Durch Drücken einer Taste wird der Status durch Hinzufügen der entsprechenden Aktion geändert, und dann wird ein Code hinzugefügt, der Code nicht Sehen Sie sich diese Aktion an, ziehen Sie die entsprechenden Schlussfolgerungen und ändern Sie den Status, sodass auf der Benutzeroberfläche etwas angezeigt werden kann.
Das heißt, unabhängig von der Umgebung, Plattform und dem Paradigma tragen die visuellen Elemente selbst ein Minimum an Funktionalität und keine Logik in sich. Sie erhalten Informationen in der allgemeinsten Form. Wenn Sie also eine TextBox haben, ist dies auch Eingabe, es ist auch ein Feld für die Eingabe von Text, es nimmt eine Zeichenfolge und gibt eine Zeichenfolge. Und die Aufgabe, eine Zeile in eine Zahl, einen Namen oder etwas Listigeres zu verwandeln, ist nicht mehr für das Widget.
Nun, dann verarbeitet Controller oder Presenter das Ergebnis und erzeugt das Ergebnis. Rufen Sie ihn an, wie Sie es gewohnt sind, und fügen Sie ihm keine visuellen Elemente hinzu.
Was ist der Gewinn? Ich liste in der Reihenfolge vom Offensichtlichsten zum Meiner Meinung nach das Wesentliche auf.
Erstens die Wiederverwendbarkeit. Es kann ziemlich viel Zeit aufgewendet werden, um zu verstehen, dass ein Feld zur Eingabe einer Postanschrift, zur Eingabe eines Nachnamens und zur Eingabe einer Summe tatsächlich dasselbe Feld ist. Ein und dasselbe Widget mit denselben Funktionen, die zum Abrufen eines Texteingabeereignisses oder zum Aktualisieren eines Status erforderlich sind. Und nur die Logik der Arbeit mit dem darin enthaltenen Text kann sich unterscheiden. Ein Beispiel dafür, wie man im Leben nicht vorgeht: Erstellen Sie ein Feld für die Eingabe eines Geldbetrags (bis zu zwei Dezimalstellen) und spielen Sie dann lange herum, um es manchmal zu wiederholen, sodass Sie manchmal eine Menge in dasselbe Feld eingeben können (bis zu 4 Dezimalstellen). . Unterbrechen Sie den Vorgang an allen Stellen, an denen der Betrag in der Anwendung eingegeben wurde, und reparieren Sie sie mitten in der Nacht. Dies trotz der Tatsache, dass sie nach der Logik ihrer Arbeit Unterschiede in der dritten Dezimalstelle hatten. Sie können Gedichte darüber schreiben, wie Felder zur Eingabe von E-Mail-Adressen mithilfe von Vererbung und Gottes Worten zu Feldern für die Eingabe von geografischen Adressen werden.
Zweitens: Testbarkeit. Sie können auch die Benutzeroberfläche testen. Fast jede Benutzeroberfläche. Es wird jedoch teuer sein, was Zeit und Ressourcen angeht, die für die Entwicklung von Tests und das Ausführen von Tests aufgewendet werden, und es ist unwahrscheinlich, dass sie bei jeder Neuerstellung gestartet werden. Wenn die Tests jedoch bei der Veröffentlichung abstürzen, ist dies höhere Gewalt. Aber UI-Komponenten sind in Bezug auf Ausfälle am riskantesten, sie brechen in der Regel am häufigsten, am deutlichsten und am schmerzhaftesten. Aber der Code, der aus den Widgets selbst herausgerissen wurde, wird wirklich durch Unit-Tests abgedeckt. Unit-Tests sind viel billiger - es ist einfacher zu schreiben, und Sie können sie nach Änderungen buchstäblich ausführen und immer sicher sein, dass nichts kaputt gegangen ist.
Und drittens meiner Meinung nach das Wichtigste. Es ist äußerst schwierig, ein Stück Benutzeroberfläche zusammen mit Logik als ein einziges Stück zu zeichnen, um Faulheit zu besiegen und tiefer darüber nachzudenken, wie es funktioniert. Um Szenarien zu erarbeiten, die nicht idealerweise positiv sind, wenn der Benutzer genau das eingegeben hat, was von ihm erwartet wurde, genau das getan hat, was erforderlich war, und genau das erhalten hat, was er wollte. Derselbe heilige Programmierer "alles funktioniert für mich".
Die Trennung des visuellen und des logischen Teils lässt Sie zunächst darüber nachdenken, wie der visuelle Teil funktioniert: Was kommt hinein, was kommt heraus, was passiert, wenn etwas, von dem nicht erwartet wurde, dass es ein- oder ausgeht, nicht funktioniert. Wenn Sie die Logik getrennt von der Steuerung schreiben, müssen Sie sie in Fällen schreiben, dh gemäß möglichen Szenarien für die Verwendung einer bestimmten Anwendung an einem bestimmten Ort, einschließlich der hier auftretenden Verarbeitungsfehler, und dem Benutzer bei den hier auftretenden Schwierigkeiten helfen. Ja, nicht immer oder eher nicht in allem, eine Lösung ist im Allgemeinen besser als eine auf einen bestimmten Fall zugeschnittene Lösung.
Zusammenfassend. Sie können in Delph oder einer Anwendung für iOS schreiben, das lange leidende Web für eine Art von 0 quälen oder ein Mikrocontroller-Spiel in Python nieten, wenn Ihr Code der Formel "Eine Form, eine Abfrage, ein Ergebnis" entwachsen ist - ich sage es Ihnen Ich empfehle dringend, Widgets entscheidend von jeder Logik ihrer Arbeit zu trennen, und dann besteht die Möglichkeit, dass Ihre Schnitzel weniger Fliegen enthalten. Und trotz der anfänglich vollkommenen Nicht-Offensichtlichkeit der Vorteile einer solchen Lösung erscheinen Ihnen umso mehr Vorteile, je weiter Sie damit arbeiten.