MVP-Muster android dupicated Methoden in Moderatoren

Question

ich ein paar Aktivitäten, während jeder von ihnen ziemlich einzigartig ist, hat es einige gemeinsame API-Aufrufe wie GetCurrentUser() oder Updateuser()

das MVP-Muster gegeben werden (I verwende derzeit MVP mosby), da jede dieser Aktivitäten nur einen einzigen Moderator hat. Während ich mich entwickle, scheint es, dass ich manchmal viele dieser allgemeinen API-Aufrufe über diese Moderatoren kopiere. Sagen I API-Aufruf A, B, C, D.

A, C verwendet werden in Präsentator 1,

B, D, A werden verwendet in Präsentator 2,

C, E werden verwendet, haben in presenter 3 .....

und so weiter. Es ist wirklich schwierig, einen "gewöhnlichen" Moderator zu finden, von dem er erbt. Also die Api-Aufrufe, C und A sind grundsätzlich kopiert eingefügt.

Meine Frage ist, angesichts der aktuellen Situation, was ist der beste Weg, um Code Copy-Pasting zu vermeiden? Ist es fast nicht vermeidbar? Oder sollte ich mein Bestes geben, um OOP zu machen, aber jedes Mal, wenn API-Aufrufe von verschiedenen Präsentatoren hinzugefügt/entfernt werden, eine Menge Refactoring zu riskieren?

Answer 1

Sie sollten den gemeinsamen API- und Presenter-Code entkoppeln, indem Sie alle API-Aufrufe in eine oder mehrere Java-Klassen einfügen, auf die von jedem Presenter verwiesen werden kann.

Daher. ServiceA existiert (eine Java-Klasse).

ServiceA führt API-Aufrufe A, B, C, D durch.

Service A kann von Presenter1, Presenter2, PresenterN, PresenterN + 1 aufgerufen werden. Es sollte egal sein, was der Moderator ist.

Wenn Sie bestimmten Präsentatoren den Zugriff auf verschiedene API-Aufrufe beschränken möchten. Dann sollten Sie ServiceA, ServiceB, ServiceC in Betracht ziehen. Wenn ServiceA den API-Aufruf A und D nur ausführen kann, verhalten sich Dienst B und Dienst C ähnlich.

Entkopplung von Presenter-Code und Common (Web-Service, interne API, w/e-Code) können Sie skalieren, ohne dass Sie kopieren und einfügen müssen.

Viel Glück.

Answer 2

Ich glaube, Sie riskieren mehr Refactoring, wenn Sie es nicht den OOP-Stil, mit Vererbung tun. Nehmen wir an, Sie möchten die Art und Weise ändern, wie Sie mit einem API-Anruf umgehen. Wenn Sie Code kopieren, müssen Sie überall, wo Sie den Code kopiert haben, umgestalten. Wenn Sie von einem gemeinsamen Moderator erben, können Sie nur einmal ändern.

Answer 3

Sie sollten eine Schnittstelle für Ihre API erstellen, die alle API-Anforderungen enthält. Machen Sie dann eine Singleton-Klasse, die diese Anfragen ausführt, und Sie können einfach von Ihren Referenten auf diese Klasse zugreifen.

Jetzt haben Sie noch einige Vervielfältigungen und Sie müssen diesen Singleton mehrere Male im Präsentator aufrufen und die Antwort in jedem von ihnen behandeln, aber das ist, was Sie tun müssen. Jeder Moderator sollte in der Lage sein, die Antwort anders zu handhaben, so dass Sie sie nicht einfach als eine Einheit verpacken können (selbst wenn sie dies normalerweise auf die gleiche Art und Weise tun - indem sie Daten zur Ansicht weitergeben).

Wenn Sie denken, dass Sie eine Menge ähnlichen Code schreiben, der nichts tut, gut das, was Sie mit MVP bekommen.Sie erhalten auch großartige Testfähigkeiten, einfacheres Refactoring und einfaches Nachahmen von Anfragen - Sie könnten Ihr echtes Singleton gegen Mock tauschen, das die gleiche Schnittstelle implementiert und alles funktioniert.

Answer 4

Interactor-Muster (Use-Case-Muster) kann Ihr aktuelles Problem des Duplizierens lösen.

Die Idee ist, dass Sie alle Logik hinter getCurrentUser() und updateUser() Methoden in eine Klasse (Interaktor) extrahieren und diesen Interaktor in mehreren Presenter verwenden.

Dies ist eine sehr vereinfachte Erklärung. Ich schlage vor, dass Sie mehr Forschung beginnen, beginnend mit this post und this post zum Beispiel.