La cattiva gestione dell'overget?

2

Ho un'enumerazione con i comandi Play , Stop e Pause per un lettore multimediale. In due classi faccio una commutazione sopra i comandi ricevuti. Il lettore viene eseguito in un thread diverso e recapito i comandi in una coda di comandi al thread.

Se genero diagrammi di classe, l'enumerazione ha dipendenze dappertutto. C'è un modo migliore per gestire i comandi? Se dovessi cambiare / estendere l'enumerazione, dovrei cambiare diverse classi. (Non è molto importante mantenere il lettore estensibile, ma cerco di scrivere un buon software.)

    
posta Puckl 22.09.2012 - 14:36
fonte

2 risposte

4

Un modo "più bello" è di avere tre metodi, uno per comando.

Non è necessario comprimere tutti questi comandi in un unico metodo e utilizzare uno switch in un secondo momento. Dato che questi comandi fanno cose diverse, meritano i propri metodi nell'interfaccia.

Invece di:

public void ChangeState(PlayerState newState)
{
    switch (newState)
    {
        case PlayerState.Play:
            // Start playing.

        case PlayerState.Stop:
            // Stop playing.

        case PlayerState.Pause:
            // Pause or resume.
    }
}

avresti:

public void Play()
{
    // Start playing.
}

public void Stop()
{
    // Stop playing.
}

public void Pause()
{
    // Pause or resume.
}

Perché?

La tua attuale implementazione utilizzando uno switch:

  • o fai più cose,
  • o servirà solo per chiamare i metodi Play , Stop e Pause .

Nel primo caso, infrangi la regola secondo cui un metodo dovrebbe fare una e una sola cosa .

Nel secondo caso, KISS : non scrivere un metodo di cui davvero non hai bisogno e che non porta nulla di utile all'API.

    
risposta data 22.09.2012 - 14:41
fonte
0

Ciò che sembra fare è prendere 3 input separati, unendoli in una singola variabile e passandoli avanti per essere elaborati. Il tuo codice di elaborazione esegue quindi una commutazione / se le istruzioni su questa variabile.

Come accennato MainMa, l'approccio più ovvio e più pulito sarebbe semplicemente quello di avere 3 metodi, e la tua interfaccia chiamarli. Se, per qualche ragione, desideri avere un modello leggermente più disconnesso (per esempio, se devi eseguire il comando in una fase successiva e poi quando viene attivato), il modo tipico è Command Pattern in cui si incapsula in modo efficace una chiamata di metodo in un oggetto (che può essere serializzata / memorizzata / inviata in rete / eseguita più volte, ecc.). Il vantaggio rispetto all'enumerazione è che approvvigiona i parametri di input (ad esempio se si dispone di un comando di controllo del volume). Detto questo, si tratta di un'eccessiva complicazione eccessiva, e mi attenersii ai soliti vecchi metodi.

    
risposta data 22.09.2012 - 14:49
fonte

Leggi altre domande sui tag