April 2010 Entries
Negli ultimi tempi sono stato coinvolto in una attività di recruitment mirata a reperire figure professionali nel mondo IT con skill particolarmente elevato, diciamo una figura di senior developer con conoscenze anche in ambito architetturale. Ho accettato con entusiasmo questa attività poichè ero curioso di capire se la preparazione universitaria in ambito informatico fosse sufficientemente in grado di reggere l'impatto con il mondo del lavoro e con la realtà di tutti i giorni (questo ovviamente per i laureati, ma lo stesso discorso può essere applicato anche per chi laureato non è).
E le sorprese non sono mancate.
Ecco, in sintesi, le mie considerazioni:
-...
E’ online il mio primo articolo per UgiDotNet, ovvero “Programmazione per contratti con il Framework .Net 4.0”, argomento molto molto interessante poichè è ora possibile adottare l’approccio cosiddetto “Contract First Development” nel design delle proprie applicazioni. Questo approccio aiuta sicuramente a scrivere applicazioni più robuste, cercando di limitare per quanto possibile i bugs a runtime. Ovviamente sono graditissimi eventuali feedback, contattandomi mediante la form contact di questo blog.
Gli extension methods sono una feature estremamente potente ed interessante, introdotta a partire dal .Net Framework 3.5 SP1.
A tal proposito, su Codeplex è presente un interessantissima libreria di codice che raccoglie extension methods applicati a svariati tipi.
Davvero molto molto utile.
Come detto qui da Gianluca Carucci, questa feature non necessita necessariamente della versione 3.5 del .Net Framework per essere utilizzata, ma, con un piccolo accorgimento, è possibile sfruttarne a pieno le potenzialità utilizzando anche il .Net Framework 2.0.
Pertanto, nella pagina Codeplex sopra citata, i “requirements” sono errati.
Il pattern “Decorator” appartiene alla famiglia dei design pattern della GoF (Gang of Four), ed è classificato come pattern strutturale. E’ un pattern molto semplice da usare, che permette di aggiungere dei comportamenti personalizzati, e quindi delle responsabilità, ad una certa classe senza per questo utilizzare tecniche di subclassing. Immaginiamo di avere un componente per il log delle informazioni. Esso invoca un servizio di logging e rispetta questo contratto definito mediante una semplice interfaccia: 1: public interface ILogger
2: {
...