Modello di progettazione per incapsulare funzionalità comuni tra i controlli dell'interfaccia utente

Sto analizzando alcune idee su un modello da utilizzare per il seguente scenario.Modello di progettazione per incapsulare funzionalità comuni tra i controlli dell'interfaccia utente

Ho alcuni controlli di terze parti a cui voglio aggiungere funzionalità comuni. La funzionalità viene aggiunta gestendo molti degli eventi e facendo determinate cose quando gli eventi si attivano insieme all'aggiunta di alcune variabili private per contenere alcune informazioni di stato tra gli eventi. Voglio riutilizzare il codice e la funzionalità, quindi questo è ciò che normalmente farei.

Creare una classe per questa funzionalità e passare nell'istanza del controllo a cui si desidera aggiungere la funzionalità nel costruttore.

Quindi posso aggiungere gestori di eventi al controllo nell'istanza della classe.

Qualcuno può pensare a schemi alternativi da utilizzare per creare questo tipo di funzionalità riutilizzabile?

fonte

2010-06-07 Dan

Il modello di progettazione più applicabile è Observer. La funzionalità riutilizzabile che desideri sviluppare può essere implementata come semplici osservatori di Control, che sottoscrivono alcuni sottoinsiemi di eventi di controllo. Fortunatamente, i controlli Windows Form implementano molti eventi, rendendo possibile l'aggiunta di funzionalità al di fuori della classe con la stessa facilità con cui vengono eseguite dall'interno, mediante la normale sottoclasse.

Ad esempio, è possibile aggiungere il supporto per il trascinamento della selezione implementando un osservatore che si è iscritto a DragOver e DragDrop (ed eventualmente DragLeave) ed eseguito le azioni appropriate in base ai dati DragDropEvent.

Questa è una tecnica eccellente da considerare, in quanto consente di sviluppare tale funzionalità una sola volta e di aggiungerla a molti controlli.

fonte

2010-06-08 00:49:17 bbudge

Quando arrivi alla carne e alle ossa di quello che sto già facendo, è tutto osservatore dietro le quinte. Non avrebbe più senso estenderlo ulteriormente e creare interfacce Observer e seguire una linea guida rigorosa. Fondamentalmente sto creando una classe in cui passo il controllo nel costruttore e poi delegare eventi per gestire gli eventi di controllo. Il modello di eventi in .NET è già considerato un pattern di Observer. – Dan

Sono d'accordo che questo è molto semplice da implementare con l'API di controllo esistente. Volevo solo affermare che il tuo approccio è buono. – bbudge

Grazie per la descrizione del pattern Observer. – Dan

Si consiglia di dare un'occhiata al:

Il modello di facciata consentirà di incapsulare il comportamento del controllo ai sensi la classe attuale. Il modello di decoratore ti consentirà di creare controlli impilabili. Il modello di osservatore ti consentirà di gestire gli eventi.

fonte

2010-06-07 15:17:44 monksy

Il modello di facciata non incapsula la funzionalità all'interno di un controllo in modo corretto in quanto lo schema di facciata non deve contenere alcun stato tra le chiamate di metodo per il controllo (come da mio requisito, come indicato). Data la mia descrizione, l'utilizzo dello schema di osservatore non avrebbe alcun senso in questo scenario. Il decoratore, ok forse questo potrebbe essere adatto;) .... Se ho torto, per favore dimmi, come vorrei una migliore comprensione di come suggeriresti di implementare questo con questi modelli. – Dan

In realtà, penso che Steven sia proprio qui. Si utilizza la facciata per creare l'interfaccia unificata per i controlli dell'interfaccia utente (si pensi: UserControl). Il concetto di decoratore è simile all'uso della terza parte tramite composizione e aggiungendo funzionalità specifiche. L'osservatore verrebbe utilizzato per ottenere il controllo di livello superiore per rispondere quando si verifica un evento sul controllo di terze parti. –

Capisco dove si inserisce ora Observer. Però, tecnicamente la mia soluzione è osservatore e il modello Event di moduli in .NET da solo potrebbe essere considerato un modello di osservatore. Implicare un modello di Observer nel mis non ha senso perché la mia soluzione è già piuttosto semplice e sta già utilizzando un modello di Observer. – Dan

Ritengo che il modello di Osservatore debba essere utile. In questo modo si può utilizzare:

UtilityClass che accetta un controllo (come lei ha detto): renderlo osservatori

Registra classi di utilità varie (e quindi controlli) a vari Eventi esso interessati a: osservabile

Ora, quando si verifica un evento particolare aggiorna diversi osservatori in cui è possibile delegare l'eventHandling di base per il controllo che è avvolgente e hanno anche un posto per fare Handl personalizzato in base al controllo e all'evento.

fonte

2010-06-07 16:32:14 Nrj

Modello di progettazione per incapsulare funzionalità comuni tra i controlli dell'interfaccia utente

risposta

Problemi correlati