Maurizio's blog 3.0

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:

– Una laurea non è assolutamente garanzia di preparazione e competenza. Spesso i neolaureati, si “adagiano sugli allori”, pensando che il loro titolo di studio basti e avanzi, ma in realtà non è così, poichè i ritmi con cui si evolve la tecnologia sono talmente elevati che solo con una spiccata dose di passione e/o sacrificio è possibile essere aggiornati in modo almeno sufficiente;

– L’attività di senior developer o comunque qualsiasi attività prettamente tecnica spesso sono viste come attività “rognose” e molto impegnative, per cui le ambizioni dei candidati a volte si spostano verso ruoli di più alto livello, o comunque non a stretto contatto con la tecnologia (es. coordinatore di risorse o addirittura analista funzionale);

– I cv sono spesso gonfiati a sproposito. Per un appassionato non c’è nulla di male nell’inserire “ottima conoscenza teorica di …..” senza aver avuto la possibilità di mettere in pratica questa conoscenza. Diverso è inserire esperienze anche pluriennali senza alcuna valenza. Non è possibie sentirsi dire che non si sono mai utilizzate le caratteristiche più elementari del polimorfismo quando sul cv è scritto “pluriennale esperienza nella programmazione ad oggetti”, oppure “ottima conoscenza di ASP. NET” e poi non si sa a cosa serve il ViewState;

– L’atteggiamento del candidato durante una intervista non è spesso quello giusto da tenere in situazioni del genere, dove, a mio avviso, occorre mostrare soprattutto umiltà di fronte a ciò che si conosce e soprattutto di fronte a ciò che non si conosce;

Fortunatamente si incontrano anche persone appassionate di questo lavoro e competenti, che ripagano ampiamente gli sforzi effettuati.

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:

public interface ILogger
{
    void Write(Exception ex);

}  
public class Logger : ILogger
{
   public void Write(Exception ex)
   {
      Console.WriteLine(ex.Message);
   }
}

Abbiamo la necessità di aggiungere una informazione aggiuntiva al messaggio di log, ovvero la data odierna. Questo significa aggiungere responsabilità alla classe, ma per ottenere questo non intendiamo nè modificare la classe originaria, nè usare il subclassing. Il design pattern “decorator” permette di ottenere questo risultato in un modo molto semplice:

public class LoggerDecorator : ILogger
{
   private ILogger loggerObj;
  
   public LoggerDecorator(ILogger logger)
   {
        loggerObj = logger;
   }

public void Write(Exception ex)
{
       Console.WriteLine(DateTime.Now.Date.ToShortDateString());
       loggerObj.Write(ex);
}

Il “decorator” consiste in una classe che implementa la stessa interfaccia della classe originaria, e con un costruttore che accetta come parametro una istanza di quest’ultima. L’implementazione dell’interfaccia permette al “decorator” di iniettare codice aggiuntivo prima ed anche dopo l’invocazione del corrispondente metodo della classe estesa.

Esempio di utilizzo:

E’ importante notare che la classe estesa (Logger in questo caso) non sa assolutamente nulla che un’altra classe è usata come “decorator”.

Nonostante la semplicità e l’utilità di questo pattern è opportuno ricordare che con l’introduzione degli “extention methods” a partire dalla versione 3.5 del .Net Framework è possibile estendere una qualsiasi classe senza usare l’ereditarietà e con l’indubbio vantaggio di ritrovarsi gli extention methods di un tipo visibili nell’Intellisense di Visual Studio.

Esempio con l’extention method:

 public static class LoggerExtention
 {
     public static void WriteData(this Logger logger)
     {
         Console.WriteLine(DateTime.Now.Date.ToShortDateString());
     }
 }
   
// Utilizzo:
Logger loggerEx = new Logger();
loggerEx.WriteData();