Ich benutze RxJava seit ungefähr einem Jahr in meinem Projekt. Mit der Zeit habe ich es sehr geliebt - jetzt denke ich vielleicht zu viel ...
Die meisten Methoden, die ich schreibe, haben jetzt eine Form von Rx, was großartig ist! (bis es nicht ist). Ich stelle jetzt fest, dass einige Methoden eine Menge Arbeit erfordern, um die verschiedenen beobachtbaren Produktionsmethoden zu kombinieren. Ich habe das Gefühl, dass, obwohl ich verstehe, was ich jetzt schreibe, der nächste Programmierer es wirklich schwer haben wird, meinen Code zu verstehen.
Bevor ich zur unteren Zeile komme, lassen Sie mich ein Beispiel aus meinem Code in Kotlin geben (Tauchen Sie nicht zu tief hinein):
%Vor%Kurz gesagt, was das ist:
Und hier kommt meine eigentliche Frage:
Reaktive Programmierung bietet einige wirklich mächtige Konzepte. Aber wie wir wissen with great power comes great responsibility .
Wo zeichnen wir die Grenze? Ist es in Ordnung, unsere gesamten Programme mit fantastischen reaktiven Oneliner zu füllen oder sollten wir es nur für wirklich alltägliche Operationen speichern?
Offensichtlich ist das sehr subjektiv, aber ich hoffe, dass jemand mit mehr Erfahrung sein Wissen und seine Fallstricke teilen kann. Lass es mich besser ausdrücken
Wie gestalte ich meinen Code so, dass er reaktiv und dennoch leicht zu lesen ist?
Wenn du Rx nimmst, wird es zu diesem tollen glänzenden Hammer und alles sieht aus wie ein rostiger Nagel, der nur wartet damit du hineinknallst.
Persönlich denke ich, dass der größte Hinweis im reaktiven Framework liegt. Bei einer Anforderung müssen Sie darüber nachdenken, ob eine reaktive Lösung wirklich Sinn macht.
In jedem Rx-Vorschlag möchten Sie einen oder mehrere Ereignisströme einführen und als Reaktion auf ein Ereignis eine Aktion ausführen.
Ich denke, es gibt zwei Schlüsselfragen zu stellen:
Wenn Sie nicht die Kontrolle über den Ereignis-Stream haben und Sie müssen mit der Rate des Ereignisstrom dann Rx ist ein guter Kandidat.
In jedem anderen Fall ist es wahrscheinlich eine schlechte Wahl.
Ich habe viele Beispiele gesehen, wo Leute durch die Reifen gesprungen sind, um die Illusion eines Kontrollmangels zu erzeugen, um Rx zu rechtfertigen - was mir verrückt vorkommt. Warum geben Sie die Kontrolle auf, die Sie haben?
Einige Beispiele:
Sie müssen Daten aus einer festen Liste von Dateien extrahieren und in einer Datenbank speichern. Sie beschließen, jeden Dateinamen in einen Betreff zu schieben und eine reaktive Pipeline zu erstellen, die jede Datei öffnet und die Daten projiziert, dann die Daten auf irgendeine Weise verarbeitet und sie schließlich in die Datenbank schreibt.
Dies schlägt den Kontrolltest und den Geschwindigkeitstest fehl. Es wäre viel einfacher, über die Dateien zu iterieren und sie zu ziehen und so schnell wie möglich zu verarbeiten. Der Ausdruck "entscheide dich, um zu drücken" ist das Werbegeschenk hier.
Sie müssen die Aktienkurse von einer Börse anzeigen lassen.
Offensichtlich ist dies eine gute Wahl für Rx. Wenn Sie nicht mit dem Preisniveau im Allgemeinen Schritt halten können, sind Sie geschraubt. Es könnte der Fall sein, dass Sie Preise zusammenführen (vielleicht, um ein Update nur einmal jede Sekunde zur Verfügung zu stellen) - aber das qualifiziert noch als das Aufrechterhalten. Die einzige Sache, die Sie nicht tun können, ist, die Börse zu verlangsamen.
Diese (realen) Beispiele fallen ziemlich genau an entgegengesetzten Enden des Spektrums und haben nicht viel Grauzone. Aber da draußen gibt es viele Grauzonen, in denen die Kontrolle nicht klar ist.
Manchmal trägst du den Client-Hut in einem Client / Server-System und es kann leicht sein, in die Falle zu geraten, Kontrolle zu opfern oder die Kontrolle an die falsche Stelle zu setzen - was einfach mit dem richtigen Design behoben werden kann. Bedenken Sie Folgendes:
Eine Client-Anwendung zeigt Updates von einem Server an.
Hier hat die Häufigkeit der Nachrichtenaktualisierungen keine Kontrolle über den Client. Aber die gewünschte Aktualisierungsrate und die Tags von Interesse sind.
Damit der Client alle Nachrichtenaktualisierungen erhält, wenn sie ankommen und sie filtern, wird die Client-Seite nicht funktionieren. Aber es gibt viele Möglichkeiten:
Es gibt viele gültige Möglichkeiten, dieses Problem anzugehen, die mehr oder weniger reaktive Elemente enthalten. Eine gute Lösung sollte jedoch die Kontrolle der Tags und der gewünschten Aktualisierungsrate durch den Kunden sowie die fehlende Kontrolle über die Häufigkeit der Nachrichtenaktualisierung (nach Client oder Server) berücksichtigen. Möglicherweise möchten Sie, dass der Server auf Änderungen im Kundeninteresse reagiert, indem er die Ereignisse aktualisiert, die er an den Client sendet - nur so lange, wie der Client zuhört (wird über einen Heartbeat erkannt). Wenn der Benutzer einen vollständigen Artikel wünscht, würde der Kunde den Artikel herunterziehen
In der Rx-Community wird viel über Gegendruck diskutiert. Dies ist die Idee, dass der Client den Server informieren soll, wenn er überlastet ist und der Server antwortet, indem er den Ereignisstrom irgendwie reduziert. Ich denke, das ist ein fehlgeleiteter Ansatz, der zu verwirrenden Designs führen kann.
Sobald ein Kunde dieses Feedback geben muss, hat er den Response-Rate-Test nicht bestanden. An dieser Stelle befinden Sie sich nicht in einer reaktiven -Situation, Sie befinden sich in einer asynchronen aufzählbaren -Situation. d.h.Der Client sollte "Ich bin bereit" sagen, wenn er für mehr bereit ist und dann auf eine nicht blockierende Weise darauf wartet, dass der Server antwortet.
Dies wäre angemessen, wenn das erste Szenario so geändert würde, dass Dateien in einem Drop-Ordner ankommen, die unterschiedlich lang und komplex zu verarbeiten sind. Der Client sollte für die nächste Datei einen nicht blockierenden Aufruf durchführen, ihn verarbeiten und wiederholen. (Fügen Sie nach Bedarf Parallelität hinzu) - und reagieren nicht auf einen Datenstrom von Ereignissen, die bei der Datei angekommen sind.
Ich habe bewusst andere gültige Bedenken wie Wartbarkeit des Codes, Leistung von Rx selbst usw. vermieden. Die meisten, weil sie woanders angesprochen werden und wichtiger, weil ich denke, dass die Ideen hier spalterischer sind als diese Bedenken.
Wenn Sie also in Ihrem Szenario über die Elemente control und response rate reflektieren, bleiben Sie wahrscheinlich auf dem richtigen Weg.
Das Problem mit der Antwortquote kann subtil sein - und der Aspekt Grad ist wichtig. Die Ankunftsrate kann schwanken, und es wird ein akzeptables Maß an Fluktuation der Antwortquote geben - klar, wenn Sie letztendlich keine Möglichkeit haben, "aufzuholen", dann wird der Kunde irgendwann explodieren.
Ich finde, dass es zwei Dinge gibt, an die ich denke, wenn ich Rx schreibe (oder irgendeine milde, ausgereifte / neue Technologie)
Zu diesem Zweck finde ich auch, dass Sie, weil Sie können, nicht immer meinen, dass Sie sollten. Als Leitfaden versuche ich, Abfragen zu vermeiden, die über 7 Zeilen Code hinausgehen. Bei Abfragen, die größer sind, versuche ich mich in Unterabfragen zu trennen, die ich komponiere.
Wenn Code, den Sie bereitgestellt haben, der Kern der Codebasis ist und sich am äußersten Ende der Komplexität befindet, dann ist es vielleicht in Ordnung. Wenn Sie jedoch feststellen, dass Ihr gesamter Rx-Code so komplex ist, können Sie Schwierigkeiten haben, mit der Codebasis zu arbeiten.
Tags und Links rx-java system.reactive rx-android