Come riutilizzare il codice comune tra i relatori

Question

Come riutilizzare il codice comune tra i relatori

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Nella mia applicazione ci sono 2 viste che hanno entrambi il 70% di campi comuni come nome, icona ecc. Una vista riguarda la lista (contiene 2-3 campi). Cliccando sulla lista, la prossima vista che è i dettagli dovrebbe essere chiamata.

Altre funzionalità in entrambe le viste sono le stesse. per esempio durante il caricamento, verrà chiamato il presentatore per caricare i dati dall'URL. (L'URL per entrambe le viste è diverso). La funzionalità comune include 1. Carica dati XML dall'URL 2. Impostare la barra di avanzamento del caricamento in attività 3. Rimozione della barra di avanzamento. 3. I metodi del 50% per l'impostazione delle visualizzazioni dell'attività saranno comuni. 4. Chiama il parser xml

Le differenze saranno specifiche per la vista: 1. I campi sono comuni solo al 50%. 2. l'azione sul pulsante clic

Il mio dubbio è che userò 2 presentatori o un presentatore per entrambe le viste. Molti metodi sono diversi, mentre molti sono uguali nei 2 presentatori.

Qual è la strategia di progettazione corretta ?: 1. Devo usare la classe helper 2. Entrambi i presentatori hanno la stessa classe base. 3. Devo usare il modello startegy? Qual è il modo giusto per farlo in MVP? O tutti sono corretti.

mvp

posta user4057066 03.11.2014 - 05:58

fonte

3 risposte

Leggi altre domande sui tag mvp

Pattern / algoritmo di progettazione JS per evitare ridisegni duplicati in un sistema abbastanza accoppiato Gestione del comportamento dell'applicazione non di dominio in CQRS

score 3 · Answer 1

Suggerirei di iniziare scrivendo i tuoi due relatori in modo indipendente, quindi rifattorici per rimuovere la duplicazione. Questo può essere fatto spostando il codice in una o più classi di helper o introducendo una nuova classe di abstract ancester per i tuoi presentatori. Quale di questi è più appropriato dipenderà dai dettagli del tuo progetto che non sono nella tua domanda, ma a meno che non ci siano buoni motivi per favorire l'ereditarietà di solito andrei a cercare il primo.

score 0 · Answer 2

Su Ruby dovrei includere una terza classe che condivide il codice comune tra i relatori o i delegati, a seconda della quantità di codice condiviso e di quali dipendenze hanno i presentatori. Probabilmente dalla tua descrizione renderei il delegato ListPresenter al DetailsPresenter se i metodi che hanno in comune.

score 0 · Answer 3

L'approccio corretto per questo tipo di situazione è di avere un presentatore di base e una vista di base, in cui puoi fare le cose comuni.

class BasePresenter<T:BaseView>
{
    BasePresenter(T view)
    {
        View = view;
        View.Presenter = this;
    }

    T View { get; private set; }    
}

class BaseView<T : BasePresenter> : [base view component such as asp net component]
{
    T Presenter { get; set; }  

    protected void ShowProgress()
    {
       ...
    }

    protected void HideProgress()
    {
       ...
    }
}

class ListPresenter : BasePresenter<ListView>
{
    ListPresenter(ListView view) : base(view)
    {

    } 

    void FetchData()
    {
        .....
        View.ShowList(data);
    }
}

class ListView : BaseView<ListView>
{
    void ShowList(List<object> data)
    {
        .....
    }
}

Senza dare un'occhiata al tuo codice base, non posso dire altro su come organizzare il codice.