Sovraccarico pulsanti di interfaccia, quali sono le migliori pratiche?

La mia proposta è di avere un singolo pulsante, ma al posto dell'istruzione switch, ha un'interfaccia listener implementata dalle classi che elaborano i clic e, a ogni clic, cambia il listener che ora è responsabile.

class myForm extends Form {
   ClickListener listener1 = new ClickListener_page1(this);

   private Continuebutton1_Click() {
       listener1.click();
   }
}

class ClickListener_page1 implements ClickListener {
    Form form;

    public ClickListener_page1(Form form) {
       this.form = form;
    }

    public click() {
        page++;
        // here goes all the stuff to process page 1
        form.listener1 = new ClickListener_page2(form);
    }
}



class ClickListener_page2 implements ClickListener {
    Form form;

    public ClickListener_page2(Form form) {
       this.form = form;
    }

    public click() {
        page++;
        // here goes all the stuff to process page 2
        form.listener1 = new ClickListener_page2(form);
    }
}

Mi sono imbattuto in questo in passato. Avevo un pulsante che cambiava la sua etichetta (da Avanti a Fine), ma per il resto manteneva la sua posizione. Ho usato due pulsanti distinti.

In generale, preferisco usare diversi pulsanti fisici e giocare con la loro visibilità, invece di usare un singolo pulsante e cambiarne il comportamento. La logica è semplicemente che il primo è più facile da capire e mantenere. Immagina di espandere il tuo problema su più pulsanti che possono avere comportamenti diversi in contesti diversi e dover cambiare gli ascoltatori su quei pulsanti quando il contesto cambia. Questo può spingerti in un modello artificiale di dover salvare i riferimenti o riattivare i tuoi ascoltatori di pulsanti o ideare schemi di gestione dei clic artificiali.

Detto questo, in alcuni casi il modello logico determina l'uso di un'azione con risultati contestuali, come "Salva". Se questa azione viene visualizzata in modo visibile in un'area globale, ad esempio un'intestazione, ad esempio è sempre visibile, allora credo che abbia senso che l'azione rimanga condivisa. Naturalmente, in tal caso, l'azione delega allo schermo attualmente visualizzato per ottenere l'azione, quindi, ancora una volta, la logica determina il tuo risultato.

Se c'è una diversa azione logica, diversi ascoltatori, poca relazione tra le azioni, questi sono forti indicatori della necessità di utilizzare pulsanti diversi e di regolare la loro visibilità in base al contesto.

Se, d'altra parte, le azioni hanno uno schema comune (come supportato dall'etichetta del pulsante - probabilmente il tuo caso), quindi usa un singolo pulsante e studia la possibilità di delega al contesto corrente per ottenere l'azione.

[È interessante pensare, in quest'ultimo caso, alle azioni di pattern comuni in cui alcune richiedono più input da parte dell'utente (azioni che dovrebbero avere un'ellissi (...)), mentre altre no, nel qual caso diventa difficile da usare lo stesso pulsante.]

Se le operazioni sono le stesse solo in un contesto diverso (ad esempio, tutti sono prossimi o tutti sono appply o tutti sono inviati) dovresti usare lo stesso pulsante.

Se le operazioni sono diverse (ad esempio volume su o canale su o regola l'equalizzatore) non utilizzare lo stesso pulsante o posizione.