Un'interfaccia utente grafica dovrebbe implementare Propertychangelistener o i suoi oggetti?

-1

Stavo imparando a conoscere i modelli di progettazione e mi sono imbattuto in una riga in cui un oggetto dominio deve aggiornare la sua vista utilizzando il modello di progettazione dell'osservatore.

Nel libro, Applicando UML e pattern di progettazione, si dice Let the gui object simply apear as an object which implement Propertychangelistener .

Quindi la mia domanda è che è una GUI che implementa Propertychangelistener o shoud un oggetto che risiede in gui, quell'oggetto dovrebbe implementare Propertychangelistener.

Esempio più concreto: nell'immagine qui sotto ho forme diverse. Tutti loro hanno anche una fonte nel dominio. Supponi le coordinate di una variazione di forma nel dominio.

Una forma potrebbe ricevere una notifica o una GUI principale (GuiWindow)? Questo è un po 'confuso e non c'è nemmeno un esempio nel libro.

    
posta Luai Ghunim 26.03.2018 - 22:54
fonte

1 risposta

0

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.

    
risposta data 29.03.2018 - 08:34
fonte

Leggi altre domande sui tag