Dipende interamente da quanto è disordinato l'oggetto dell'interfaccia utente e dal tipo di lavoro che deve essere svolto nel listener.
Oggetti divini
sono cattivi Non li usano Un oggetto dell'interfaccia utente che implementa molti ascoltatori e che gestisce molti aspetti diversi dei suoi controlli può diventare ingombrante e quella che inizialmente potrebbe essere una singola classe di responsabilità potrebbe diventare un oggetto dio grottesco che fa molte cose diverse. In questo caso, la risposta è no. Chiaramente è necessario estendere alcune delle funzionalità alle classi di utilità in quel caso. Crea uno spazio dei nomi o un pacchetto con il preciso scopo di contenere gli ascoltatori e creare una classe per ogni gestore fino a quando la tua classe di Dio non diventerà almeno una classe di semidio.
Detto questo, se gestisci un singolo listener di proprietà e la classe UI è ragionevolmente autonoma, nessuno ti guarderà per estendere un'interfaccia semplice per un semplice listener.
Metodi divini
sono cattivi Metodi in particolare ascoltatori che eseguono molte molte operazioni complesse. Anche se la classe che lo contiene è semplice, creerei la mia implementazione PropertyChangeListener
per gestire un'azione che coinvolge qualcosa di più complicato dell'apertura di una finestra o dell'aggiornamento di un'etichetta di pulsante.
Se ritieni che questo metodo richieda molte istanze contenute nella tua classe UI, non aver paura di passare le istanze necessarie al suo costruttore. Se si finisce con molte noiose dichiarazioni di basso livello, prendere in considerazione la creazione di classi di supporto che possono semplificare queste chiamate in una singola chiamata di metodo statico. Se è necessario eseguire azioni complesse come la connessione a un database e l'esecuzione di una query, provare a inserire operazioni dao nelle proprie classi e il listener dovrebbe solo chiamarle.
Anche con queste considerazioni, se il tuo metodo finisce per essere complicato e voluminoso, diventa un candidato eccellente da mettere nella sua stessa implementazione e suddiviso in chiamate submethod. Ciò ti consente di liberare la tua classe UI e rimane una classe a responsabilità unica.
Se hai ulteriori domande, chiedi nella sezione commenti e ti risponderemo il prima possibile.