Devo combinare funzioni simili anche se sono leggermente differenti?

2

Su un'applicazione a cui sto lavorando ho una funzione, che si connette a una macchina virtuale, che può essere eseguita in due modi. L'utente può selezionare una macchina da un elenco e fare clic sul pulsante "Connetti". Oppure puoi fare doppio clic sulla macchina nell'elenco. Attualmente sono due gestori di eventi separati perché funzionano in modo leggermente diverso. Se un utente è già connesso, fare clic sul pulsante per disconnetterli e fare doppio clic per ripristinare la finestra.

/// modifica La logica è essenzialmente

button
if(connected)
Disconnect()
else
ConnectAndShowWindow()

List
ConnectAndShowWindow()

La mia domanda è: dovrei tenere separati i metodi o combinare i due metodi anche se sono leggermente diversi e quindi, per la disconnessione / riconnessione, cambiarli in base al mittente?

    
posta Brian Green 27.09.2013 - 18:58
fonte

3 risposte

3

Le tue funzionalità sono:

  • Connetti
  • Disconnetti
  • Porta avanti la finestra

La logica del pulsante "Connetti" è:

if (connected)
    Disconnect
else
    Connect

La logica del clic doppio della macchina è:

if (connected)
    Bring Window Forward
else
    Connect

Per me, questi sono abbastanza handler separati e li lascerei così. Ovviamente dovrebbero chiamare il metodo di connessione comune.

    
risposta data 27.09.2013 - 19:19
fonte
0

Un approccio che ho usato in quel tipo di situazione è quello di refactoring i due metodi in un singolo metodo privato con un parametro per indicare quale dei percorsi dovrebbero essere presi.

public void buttonEventHandler() {
    connectHandler(ConnectEvent.BUTTON);
}
public void DoubleClickEventHandler() {
    connectHandler(ConnectEvent.DOUBLE_CLICK);
}
private void connectHandler(ConnectEvent eventOption) {
    // conditional connection logic
}

Ciò mantiene l'interfaccia semplice e consente di condividere il codice di connessione.

    
risposta data 27.09.2013 - 19:16
fonte
0

Quindi, quello che stai dicendo è che il software agisce in un modo quando il software si trova in uno stato e un'altra cosa quando il software si trova in un altro stato. Bene, benvenuto nel Pattern di stato .

Il racconto è che vuoi due classi, ognuna delle quali implementa la stessa interfaccia. l'interfaccia dovrebbe avere due metodi: OnMachineConnectSelected e OnMachineDoubleClick.

La prima classe si chiama DisconnectedState, la seconda classe si chiama ConnectedState.

  • DisconnectedState esegue Connect e ShowWindow da OnMachineConnectSelected.
  • DisconnectedState esegue la connessione da OnMachineDoubleClick.
  • ConnectedState esegue ShowWindow da OnMachineConnectSelected e OnMachineDoubleClick.

(È difficile dirlo senza ulteriori specifiche, ma è possibile e probabilmente dovresti avere Connect e ShowWindow come metodi sul tuo modulo o altro oggetto dell'applicazione e passare un riferimento, probabilmente tramite un'altra interfaccia, nel costruttore della tua classe di stato.)

Ora la tua applicazione ha semplicemente bisogno di un oggetto sul quale chiamare questi metodi, come si verificano le azioni, e puoi cambiare quell'oggetto tra un'istanza di DisconnectedState e ConnectedState mentre cambia lo stato reale delle tue applicazioni.

Vedi cosa fa questo per te?

In primo luogo, modella la tua applicazione molto bene. Guarda i punti elenco sopra. Non dovresti riorganizzare le parole molto per spiegare cosa stava succedendo a un utente o a un manager non tecnico. Stai separando i concetti di stato (decisioni software / hardware) e azioni (decisioni dell'utente) in modo ordinato.

In secondo luogo, consente l'estensibilità. Quando ti rendi conto che devi agire in modo molto diverso, mentre ti connetti e disconnetti, puoi semplicemente aggiungere due nuove classi di stato. Oppure, se devi aggiungere una nuova azione che dipende dallo stato, puoi semplicemente aggiungere un nuovo metodo a tutti gli oggetti di stato.

In terzo luogo, è più gestibile. Quando un uomo d'affari dice "Ehi, al momento, quando l'applicazione è Disconnected e selezioni Connetti su una macchina, connette e mostra la finestra, ma vogliamo semplicemente connettersi", sai ESATTAMENTE dove esiste quella logica nel codice e puoi modificarlo facilmente, con la certezza che non stai violando nessuna delle altre condizioni.

Infine, è più unità testabile. C'è solo un percorso attraverso ogni metodo. Passa un modulo fittizio al costruttore della classe, chiama il metodo OnX e assicurati che esegua le azioni giuste. E, sul modulo, puoi verificare che la tua azione chiami il metodo giusto, indipendentemente dallo stato in cui si trova.

    
risposta data 27.09.2013 - 20:09
fonte

Leggi altre domande sui tag