Motivo di progettazione per la rimozione di ascoltatori predefiniti

Question

Motivo di progettazione per la rimozione di ascoltatori predefiniti

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

1

Abbiamo un controllo GUI standard con un gruppo di listener predefiniti come questo:

class OurControl extends Control {

    OurControl() {
         addMouseWheelListener(new DefaultMouseWheelListener());
    }

}

I valori predefiniti sono buoni per i casi d'uso standard, ma ora il cliente desidera utilizzare i propri ascoltatori in alcuni casi. Sto cercando il modo più elegante per farlo.

Idea 1: (mi sembra strano per me e non mi piace mantenere un elenco di listener che potrebbero essere rimossi)

class OurControl extends Control {

    MouseWheelListener defaultListener = new DefaultMouseWheelListener();

    OurControl() {
         addMouseWheelListener(defaultListener);
    }

    void removeDefaultMouseWheelListener() {
         removeMouseWheelListener(defaultListener);
    }
}

Idea 2: (Mi piace questo, anche se tecnicamente parlando l'ascoltatore rimane dov'è, almeno segue il modello standard del bean)

class OurControl extends Control {

    public boolean enableMouseWheel = true;

    OurControl() {
         addMouseWheelListener(new MouseWheelListener() {
             void mouseWheelMoved(final MouseWheelEvent e) {
                 if (enableMouseWheel)
                     doMagic();
             }
         });
    }
}

Quale è un buon modo per raggiungere questo obiettivo?

design-patterns

posta Steffi S. 20.02.2015 - 12:09

fonte

2 risposte

0

Un approccio alternativo che ho visto è che gli ascoltatori hanno la possibilità di cancellare gli ascoltatori successivi. Ad esempio, DOM Events supporta questo.

Ciò dipende dal fatto che gli ascoltatori vengano chiamati in un ordine ben definito. Penso che sia abbastanza normale che gli ascoltatori vengano chiamati in ordine inverso rispetto alla registrazione, ma controlla il tuo particolare framework.

risposta data 20.02.2015 - 12:23

fonte

Leggi altre domande sui tag design-patterns

Come gestire responsabilmente gli errori di licenza? È possibile creare un arco che consenta di scaricare e installare un'app allo stesso tempo?

score 1 · Accepted Answer

L'opzione 2 è di gran lunga la migliore, se capisco correttamente cosa intendi.

Il tuo ascoltatore di mouse wheel predefinito presumibilmente fa un determinato lavoro; diciamo, scorre.

Il bisogno del tuo cliente di impostare il proprio listener mi dice che non vogliono che tu scorra, in modo che possano usare la rotellina del mouse per qualcos'altro.

Ma vedi, il modo in cui ottieni questo scorrimento sulla rotellina del mouse non è affar tuo, e il fatto che tu lo realizzi con un ascoltatore di mouse non è altro che un piccolo dettaglio di implementazione che non è necessario e non dovrebbe si occupi di. Quindi, il tuo controllo dovrebbe offrire un'opzione "Scorri sulla rotella del mouse", controllando questo aspetto del suo comportamento, che il tuo cliente potrebbe impostare come falso se non gli piace.

Quindi, il tuo cliente è anche libero di aggiungere il proprio listener del mouse per fare le proprie cose, come forse lo zoom al posto dello scroll. Se dimenticano di annullare l'opzione "Scorri sulla rotella del mouse", otterranno entrambi i comportamenti, e questo è perfettamente comprensibile.