Gestione del codice comune tra i relatori

4

Sto affrontando alcuni problemi relativi alla duplicazione del codice quando si segue il modello architettonico MVP in un progetto Android con cui sto lavorando. La mia struttura del progetto è separata da pacchetti: data, dominio, infra, ui. All'interno del pacchetto ui ci sono altri pacchetti per ogni schermata dell'app. Molti di questi contengono questa struttura:

  • Contratto: contiene due interfacce, una per la vista e un'altra per il presentatore;
  • Attività: che eredita l'interfaccia di visualizzazione e implementa alcuni metodi;
  • Presentatore: contiene pochissime regole aziendali e comunica con il mio modello;

Ho altre due interfacce (BaseView e BasePresenter) per il minimo di una vista e un presentatore deve implementare.

Alcuni dei miei schermi hanno così tanto codice comune. Differiscono fondamentalmente nel layout e in alcuni dettagli. Questo comportamento si verifica a causa dell'adozione delle regole MVP (ciascuna vista ha il suo presentatore).

Ho trovato due risposte per questo problema su SO:

Si suggerisce la creazione di una classe presentatore base con metodi comuni o una classe astratta e l'altra accetta come stanno le cose. Ho intenzione di implementare il presentatore di base o la classe astratta, che conduce alla mia domanda:

In base alla struttura menzionata, come posso ottenere un buon risultato senza intaccare o ferire un po 'questa struttura? Creo un nuovo pacchetto per questa classe astratta o un presentatore di base? Credo che questo approccio porti l'intera struttura. Allora, cosa devo fare?

    
posta learner 23.11.2017 - 16:24
fonte

1 risposta

0

MVP è architetturale e le classi di base, le classi astratte, sono dettagli specifici della lingua della tua implementazione.

MVP si occupa solo della separazione di M, V e P. In realtà non risolve il riutilizzo del codice, che varia a seconda dell'implementazione.

Probabilmente la migliore risposta qui è usare una classe relatore base per mantenere i metodi di supporto. Ma potresti anche avere una classe Helper che mantenga quella logica; che è meglio dipende da se si sta costruendo il proprio quadro pesante, o semplicemente facendo una singola app leggera. In una singola app, probabilmente hai solo bisogno di una classe di relatore base. Se stai costruendo un framework, hai bisogno di un altro strato di separazione all'interno del livello P per mantenere gli Helpers.

    
risposta data 02.01.2019 - 23:41
fonte

Leggi altre domande sui tag