5

Dec

Demo 10 – Delegate e User Controls

I delegate sono il perno fondamentale di tutta la potenza intrinseca di C#. Usare i delegate in maniera corretta può darvi quel differenziale in più in termini di produttività ed eleganza che un programmatore Java difficilmente potrà avere. Io stesso ci ho messo anni a capire l’effettiva importanza dei delegate e il loro utilizzo. Oggi non è che ne faccia un uso estremo e ci sono ancora cose che faccio fatica a digerire; tuttavia per alcune necessità di sviluppo il delegate non è una opzione, è l’unica scelta percorribile.

Quindi, partiamo proprio da questa scelta per capire a cosa servano.

User Controls – Controlli dell’Utente

Siamo abituati a sviluppare classi complesse e strutture dati molto articolate. Il goal è spesso quello di costruire una infrastruttura che permetta la massima elasticità e riusabilità, generalizzando il più possibile e ottenendo componenti logicamente separati dal nostro particolare programma o da una particolare implementazione.

Questo significa che, dai primordi della nostra formazione di programmatori, ci è sempre stato detto che dobbiamo sviluppare in ottica di riusare il nostro codice qua e là: cosa quanto mai complessa e spesso una triste chimera mai raggiunta e mai capita appieno. Ho personalmente visto team superskillati di sviluppatori perdere mesi per creare una infrastruttura generale, quando le esigenze erano assolutamente custom e il design era comunque vincolante.

Scelte di questo tipo sono anch’esse sbagliate; e questo ci riporta al grande problema che nulla è meglio in assoluto e che bisogna vedere sempre ciò di cui abbiamo bisogno (come la direbbe obi-wan: “solo un sith vive di assoluti”). Non sono un nerd, giuro.

Bene, cominciamo: l’obiettivo è costruire un controllo che mi permetta di fare login in un determinato meccanismo di autenticazione. Definiamo gli attori: IO devo sviluppare SOLO il controllo di login, QUALCUN’ALTRO dovrà sviluppare la logica di autenticazione/autorizzazione. Sia ben chiaro quindi che il mio componente dovrà essere assolutamente generico e riusabile in diversi contesti.

Inizio – Creazione del controllo

Nota: Sebbene questa demo sia trattata in ambito Mobile, è anche vero che è identicamente valida sia per lo sviluppo windows (e le cose che cambierebbero, sarebbero virgole al più) sia per lo sviluppo web (lì cambierebbe il modo di disegnare l’interfaccia, ma stessi concetti).

image Per questa demo creo una soluzione vuota, un progetto windows mobile vuoto e una class library (per rimarcare che il mio controllo dovrà essere un componente separato in una libreria separata).

A questo punto, nel progetto library (che ho chiamato Componenti) aggiungo uno User Control che chiamerò Logins.

image

Ora va disegnato, ovvero nel nostro caso trasciniamo due label descrittive, due textbox e due bottoni (uno login e uno reset). Dovrebbe venire qualcosa del genere (destra) =>

A questo punto definiamo il comportamento di Azzera:

image Mentre quando premiamo il tasto login dovrà essere eseguita la logica di autorizzazione/autenticazione di chi userà il componente sulla sua applicazione. E qui entrano in gioco i delegate e gli eventi. Il ragionamento che dobbiamo fare ora è:

  • Quando uno preme Login, dobbiamo fare dei controlli sul testo inserito INDIPENDENTEMENTE dalla logica di login, quindi cominciamo con implementare un controllo sulle stringhe vuote

image

  • Dopo questo controllo va invocato il codice dell’utente per effettuare il login, quindi questa parte NON dipende da noi. Però in qualche modo dobbiamo dire, nel codice, che verrà eseguito codice di altri per fare il login effettivo. E questo non lo sappiamo fino a che qualcuno non utilizzerà il controllo… quindi?
  • Creiamo un delegate, ovvero un “puntatore a funzione” che si prenda in pasto (a runtime) una funzione e che in tempo di sviluppo mi possa dare uno scheletro da chiamare. Poi ci penserà lo sviluppatore ad “agganciare” allo scheletro l’implementazione reale.

Vediamo un pò, partiamo dal delegate:

image Ora dichiariamo una funzione che sia di questo tipo, ma che per il momento punta a null:

image Ed ora, nell’evento click del bottone, invoco la funzione a cui punterà l’evento “Login”:

   image Così facendo, la funzione di login sarà implementata dall’utilizzatore, il quale avrà il compito di tornare true o false come risultato della sua procedura custom di autenticazione.

Utilizzo del controllo

Ora utilizziamo il controllo all’interno di un’applicazione:

  • image Aggiungiamo una reference al progetto Componenti
  • Aggiungiamo alla toolbox la dll di Componenti, così VS si accorgerà del componente di login al suo interno (questa operazione sarà automatica alla prima build del progetto, essenzi
    ale invece se il progetto è FUORI dalla soluzione corrente)
  • A questo punto trasciniamo il nuovo componente sul form e vediamo che si comporta come un normale controllo.

 

image

image

Vediamo quindi che il controllo presenta le proprietà classiche di base di un controllo e gli eventi di base. In particolare sulla finestra eventi avremo un evento “in più”, quello Login.

Ora non ci resta che scrivere il codice di controllo nel nostro evento, proprio come siamo abituati a fare:

image NB: ovviamente non ha molto senso creare un controllo così povero, tuttavia è un buon esempio per cominciare a sporcarsi le mani.

by Roberto Freato on 12/5/2009
Post archive