Die Laster des Imperativs zurückhalten

Das objektorientierte Paradigma ist äußerst praktisch für Unternehmen: Es ermöglicht Ihnen, nahezu jede Idee umzusetzen und eine akzeptable Produktleistung zu erzielen. In diesem Fall meinen wir mit Produkt eine iOS-Anwendung, daher werden wir abschließend von der Entwicklung speziell auf dieser Plattform ausgehen.

Wenn man die bekannten Mängel dieses beliebten Paradigmas ignoriert, enthält die Liste seiner Minuspunkte den wichtigsten Vorteil - die Flexibilität der Entwicklung. Warum ist das ein Minus? Es liegt auf der Hand, dass Flexibilität neben der grundlegenden Fähigkeit, geschäftliche Probleme zu lösen, dies auf verschiedene Weise ermöglicht. Es ist wahr, dass es ein Dutzend falsche für einen korrekten Ansatz gibt, obwohl die Geschäftsaufgabe in jedem Fall korrekt gelöst wird, jedoch mit Unterschieden in der Implementierung, deren Erweiterbarkeit und Transparenz bereits von der Richtigkeit des angewandten Ansatzes abhängt.

Unter Berücksichtigung von Murphys Gesetz ist die Schlussfolgerung, dass es ohne die richtigen architektonischen Einschränkungen wahrscheinlicher ist, dem Weg des Chaos zu folgen, dh die Qualität des Codes wird schnell abnehmen, nur weil das Paradigma dies zulässt. In diesem Artikel wird eine der möglichen architektonischen Einschränkungen erörtert, die dazu beitragen, das Gleichgewicht zwischen den Kräften von Gut und Böse zu halten, dh die Dynamik des Entropiewachstums in der Codebasis des Projekts. Es ist wichtig, dass diese Dynamik direkt mit der Anzahl der Personen korreliert, die am Schreiben des Codes beteiligt sind. Daher ist bei großen Projekten die Richtigkeit der ausgewählten Einschränkungen besonders wichtig. Was ist der Punkt?

Der Punkt ist einfach. Lassen Sie uns vom nächsten Axiom abweichen - je mehr Eigenschaften in einem Objekt vorhanden sind, desto „schlechter“ ist es. Diese Aussage kann wie folgt erklärt werden: Mit zunehmender Anzahl interner Zustände nehmen alle positiven Indikatoren des Objekts - Erweiterbarkeit, Modularität, Transparenz, Testbarkeit - ab. Man kann Einwände erheben und sagen, dass die Komplexität des Objekts und seine Funktionalität miteinander verbunden sind und dass ohne das erste das zweite nicht geschieht. Alles ist wahr, aber auf dem "zustandsbehafteten" Weg tritt das Wachstum der Komplexität exponentiell auf, obwohl das Wachstum im Idealfall linear sein sollte oder, einfacher gesagt, ein neues Merkmal vorhandene Merkmale nicht komplizieren sollte.

PS Hier sollte klargestellt werden, dass Features als semantisch verwandte Ebenen der Geschäftslogik verstanden werden. Daher wird häufig die Entscheidung getroffen, eine vorhandene Klasse zu komplizieren, anstatt eine neue zu erstellen. In solchen Fällen ist es schwierig, Widersprüche zum ersten SOLID-Prinzip zu finden.

Ein Beispiel ist ein Standardbildschirm mit einer Liste von Entitäten mit einer Auswahl. Einige der Eigenschaften könnten instabil gemacht werden, aber IB bindet uns an den Standardkonstruktor des Controllers und dies zwingt uns, "Schmutz zu machen". Der Zugriff auf diese Eigenschaften wird implizit von jeder Klassenmethode in derselben Datei erhalten. Und der unangenehmste Moment ist, dass ihre Veränderlichkeit auch von nichts abgedeckt wird, und dies führt irgendwie zu irreversiblen Konsequenzen in Form einer starken Verbindung und folglich zu der Tatsache, dass die Behebung einiger Defekte das Auftreten neuer Defekte verursacht:



Wir können daraus schließen, dass eine lineare Zunahme der Komplexität eines Objekts mit einem gemeinsamen Zustand praktisch nicht erreichbar ist. Die Funktionalität mit diesem Ansatz wird monolithisch und für jede Art von Trennung schwierig. Ein gutes Beispiel ist der Antipattern-Massive-View-Controller, der weit verbreitet ist und das Ergebnis des Fehlens jeglicher Einschränkungen für das Projekt deutlich zeigt.



Am Beispiel von UIKit können Sie genau sehen, wie sich der zwingende Entwicklungsstil auf die Komplexität des Codes auswirkt und an welchen Stellen das Framework das Erstellen von Eigenschaften in Klassen erzwingt.
Der einfachste Fall - das Verarbeiten eines Knopfdrucks - wird normalerweise nur durch Definieren der „schmutzigen Methode“ ausgeführt, dh durch eine Funktion, die nichts Nützliches empfangen kann, sodass Sie für die Eigenschaften nach draußen gehen müssen:



Daher erschwert die "Funktion" der Schaltfläche den Rest der Funktionalität des Objekts tyrannisch, da alle Bewohner der Klasse Zugriff auf diese Daten haben. Tatsächlich funktioniert fast jedes iOS-UI-Steuerelement auf ähnliche Weise. Daher fällt es ein, eine Art Wrapper über UI-Elemente zu implementieren, der beispielsweise als Verarbeitung der „Operation“ eines bestimmten Elements geschlossen wird. Die Schwierigkeit besteht jedoch darin, einen solchen Wrapper präzise und zuverlässig zu gestalten. Schließlich geht es nicht nur um die Eingabe, sondern auch um die Ausgabe von Informationen. Beispielsweise funktioniert die allgegenwärtige Tabelle mit Daten auch "schmutzig" und hat keine Ahnung von den angezeigten Daten, sodass Sie sie in einem Objekt speichern müssen:



Ist es bequem? Praktischerweise hat jeder immer Zugriff auf Daten. Flexibel, schnell, unerlässlich. Aber im Laufe der Zeit verwandelt sich alles in der Regel in einen konkreten Obelisken für tausend Codezeilen und in die Tränen derer, die die Aufgabe hatten, in dieser Klasse zu arbeiten.

Zurück zu den Einschränkungen: Aus dem obigen Code kann das folgende Prinzip gebildet werden: Code ohne Eigenschaften in Klassen ist viel sauberer und mit Unterstützung und Erweiterung rentabler. Idealerweise sollte die Logik des Objekts in seinen „reinen“ Methoden liegen, die alle ihre Abhängigkeiten als Eingabe verwenden und das Ergebnis ihrer Aktivität bei der Ausgabe haben.
Die Idee ist, den privaten Zustand des Objekts um eine Ebene zu senken. Das heißt, wenn private Objekte von außen schließen, besteht unsere Aufgabe darin, noch weiter zu gehen und die Verkapselung auf der Ebene der Methoden selbst zu stärken. Auf den ersten Blick scheint es trotz der Asynchronität der Plattform und der Notwendigkeit des Hauptrahmens, dass diese ganze Idee nicht nur unmöglich ist, sondern sich zumindest unnatürlich umsetzen wird. Und höchstwahrscheinlich wird es so sein, aber dies ist eines dieser Probleme, die durch die Einführung einer zusätzlichen Ebene von Abstraktionen gelöst werden können.

Wenn wir die gesamte Logik von Klassen in ihre Methoden integrieren wollen, ohne auf Eigenschaften zurückzugreifen, müssen wir eng mit Closures zusammenarbeiten. IOS verfügt über Standardtools zum Verwalten asynchroner Vorgänge wie GCD und OperationQueue. Es scheint, dass sie ausreichen würden, aber wenn Sie versuchen, die Idee zum Leben zu erwecken, wird sich herausstellen, dass alles nicht so rosig ist, wie Sie möchten. Abgesehen von der Tatsache, dass es eine große Chance gibt, eine Rückruf-Hölle zu bekommen, wird sich bei diesem Ansatz herausstellen, dass der Code selbst umständlich ist, viele logische Lücken aufweist und stark miteinander verbunden ist. Es ist möglich, dass ein solcher Code noch komplizierter ist als das, was wir so schnell versuchen zu entkommen.

Wenn Sie sich umschauen, können Sie sehen, dass es viel schönere und funktionalere Wege gibt, um dieses Ziel zu erreichen. Reaktive Programmierung wird seit langem in der kommerziellen Softwareentwicklung eingesetzt und ist ideal für die asynchrone Front-End-Welt. In diesem Fall betrachten wir eine (ziemlich erfolgreiche) Implementierung des reaktiven Paradigmas für Swift-Rx.



Es bietet eine einfache Entität namens Observable. Dies ist eine Art Abstraktion über den Ereignisfluss, die abonniert werden kann, und danach erhält der Abonnent diese Ereignisse im Laufe der Zeit:



Der einfachste Weg, sich den Ablauf von Ereignissen vorzustellen, ist die Darstellung einer regulären Schaltfläche. Das Ereignis seiner Operation ist hier ein Stream, so dass jedes Objekt Ereignisse seines Klickens abonnieren und empfangen kann, und vor allem weiß die Schaltfläche nichts über ihre eigenen Abonnenten. Praktischerweise kann fast jede Aktion in eine ähnliche Folge von Werten umgewandelt werden, und dies ist wichtig, da Observable miteinander kombiniert werden kann, da kein Standard-Framework dies ermöglicht.

Sie können beispielsweise mehrere Anforderungen senden, indem Sie auf die Schaltfläche klicken (zweimaliges Tippen filtern), auf die Antwort warten, dann die Antwort mit den Angaben des Benutzers auf dem Bildschirm kombinieren, eine weitere Anforderung ausführen und zum nächsten Bildschirm wechseln und das Ergebnis auf diesen übertragen Dieser Rx ermöglicht es, Fehler beim Verlassen des Bildschirms kurz und bündig zu behandeln und diese Kette zu vervollständigen (Anforderungen abzubrechen), und diese gesamte Logik benötigt zwei Dutzend Zeilen eingegebenen Codes:



Es lohnt sich, über die einzige Eigenschaft von disposeBag zu sprechen. Wie aus den Screenshots hervorgeht, wird jedes Abonnement darin abgelegt, und dies ist erforderlich, um ihre Lebensdauer zu steuern. Das heißt, die Abonnements sind gültig, solange die "Tasche" lebt, in der sie platziert wurden, in diesem Fall, während der Controller lebt.

Zusätzlich zur Kompaktheit ist es schwierig, im obigen Code einen Fehler zu machen, da jeder Verschluss etwas zurückgibt und keine Nebenwirkungen enthält. Dies ist die Kraft, nach der wir gesucht haben.

Sie können einen weiteren wichtigen Punkt bemerken: Da die Klasse keine Eigenschaften hat, ist es nicht erforderlich, [schwaches Selbst] zu schreiben, was sich positiv auf die Lesbarkeit des Codes auswirkt. Alle Funktionen können und besser lokal in der Methode definiert werden, in der sie verwendet werden, oder in separaten Klassen ausgeführt werden. Übrigens können in diesem Fall Links zu Abhängigkeiten (ViewModel, Presenter usw.) als Argument an die Controller-Methode übergeben werden. In diesem Fall müssen sie nicht in Eigenschaften gespeichert werden. Das ist richtig.

Nach der Überprüfung ist es an der Zeit, Observable zu verwenden, um die Entwicklung zu vereinfachen. Wie genau? Kehren wir zur Idee der „sauberen“ Methoden zurück und versuchen, die Logik eines kleinen Bildschirms in seiner einzigen Methode zu implementieren. Aus Gründen der Übersichtlichkeit wählen wir die Methode zum Beenden des Ladens der Ansicht (viewDidLoad). Wenn der Bildschirm in IB erstellt wird, müssen wir natürlich Eigenschaften für Outlets erstellen. Dies ist jedoch nicht beängstigend, da die Elemente selbst keine Geschäftslogik darstellen und daher die Komplexität des Bildschirms nicht wesentlich beeinflussen. Wenn der Bildschirm jedoch aus Code besteht, können Sie auf Eigenschaften verzichten (mit Ausnahme des disposeBag), Elemente in unserer Methode erstellen und genau dort verwenden. Was ist mit der Imperativität der zuvor beschriebenen UIKit-Elemente? Rx bietet zusätzlich zum Ansatz selbst reaktive Wrapper für Standard-UI-Komponenten, sodass Sie in den meisten Fällen die erforderliche Abfolge von Ereignissen vor Ort erhalten können. Oder binden Sie umgekehrt das vorhandene Observable beispielsweise an eine Tabelle. Bringen Sie eine Anforderung dazu, damit der Inhalt unmittelbar nach seiner Fertigstellung aktualisiert wird:



Die Bindung an Sammlungen ist recht flexibel, funktioniert jedoch standardmäßig nur über reloadData. Für Punktaktualisierungen gibt es eine wunderbare debuggte Bibliothek desselben Autors - RxDataSources. Damit können Sie Abstürze während BatchUpdates vergessen.

Was wird als nächstes passieren? Eine Einzelbildschirmmethode wächst und in einem ziemlich komplizierten Fall wird es schwierig, sie zu warten. Und wenn dies geschieht, wird plötzlich klar, dass diese Methode von nichts anderem als von sich selbst abhängt, und der reaktive Ansatz hat den Code in logische Blöcke unterteilt, die leicht in separate Objekte eingefügt werden können, indem sie auf ähnliche Weise entworfen werden. Diesmal nehmen die Methoden jedoch bereits einige Abhängigkeiten vom Bildschirm und geben einige Ergebnisse zurück. Der positive Punkt ist, dass die Signatur in diesem Fall so inhaltlich wie möglich erhalten wird. Es ist ersichtlich, dass die Funktion ihre Arbeit erfordert und was ihr Ergebnis ist. Es könnte ungefähr so ​​aussehen:



Separate Strukturen helfen dabei, den Header der Methode lesbar und ordentlich zu halten, da es viele Abhängigkeiten geben kann.

Es ist wichtig zu verstehen, dass die Methode nicht die einzige im gesamten Objekt sein muss, die Essenz ihrer Unabhängigkeit voneinander. Dank Rx können ihre Ein- und Ausgabe asynchron sein und eine oder mehrere Observable darstellen, was eine weitere Dimension für die Datenmanipulation darstellt.

Dieser Ansatz löst Ihre Hände und ermöglicht es Ihnen, Bildschirme nahezu beliebiger Komplexität zu implementieren, während der Code explizit und lose gekoppelt bleibt.