C# è già vecchio?

Quest’anno ho avuto la possibilità di partecipare alla NDC2010, una delle migliori conferenze a cui abbia mai partecipato sia per la qualità delle sessioni che degli speaker presenti.

Ho seguito alcune sessioni (e discussioni) su Ruby/IronRuby di Scott Bellware e Shay Friedman che mi hanno portato ad alcune riflessioni sulle quali sto ancora ragionando e che vorrei condividere.

C# è senza dubbio un bellissimo linguaggio, appena ho iniziato a lavorarci (parliamo del 2001) ho amato il suo rigore la sua sinteticità e la sua eleganza. Ho sempre amato il fatto che i metodi non sono virtuali per default che posso dichiarare una classe sealed cosi che nessuno possa ereditarla e gli altri costrutti che in qualche modo proteggono il mio codice da un uso improprio.

Poi ho scoperto Ruby, beh a dire il vero l’ho scoperto qualche anno fa, ma solo negli ultimi mesi ho iniziato seriamente a provarlo e a farci qualcosa di concreto.

Ruby è un linguaggio semplice, senza vincoli la sua natura dinamica permette di fare cose fuori dal controllo di un programmatore inesperto.

Imparare Ruby mi sta facendo cambiare alcune opinioni su C# che in confronto è molto più “cerimonioso” e ingessato di Ruby.

Inoltre, quei costrutti citati prima, che da un lato sembrano aiutarci a rendere le nostre classi più solide in realtà rendono molto problematico il testing della classe stessa (a tal proposito consiglio la visione della sessione di Michael Feather sul tema della testabilità di C#).

Molti ritengono che C# sia più protettivo rispetto a Ruby (o ad altri linguaggi dinamici) perchè il compilatore, il type system, l’intellisense, ecc... aiutano a commettere meno errori, ma, visto che siamo professionisti, ne abbiamo davvero bisogno? Non li vedete come dei limiti alla vostra creatività e produttività?

Pensate che piloti di formula 1 usino l’ABS?

Anche C# versione dopo versione va nella direzione dei linguaggi dinamici, ma forse le sue radici non lo renderanno mai libero come altri linguaggi. E’ giunta l’ora di ricominciare a guardarsi in giro?

Per ora sono solo pensieri sparsi, idee, dubbi, s#$£e mentali, sui quali però mi piacerebbe discuterne….magari in una delle prossime conf.

posted @ lunedì 21 giugno 2010 15.42 | Feedback (13)

Primo NHibernate Day

Come già annunciato poco fa da Simone qui il 9 ottobre a Bologna si terrà il primo NHibernate day.

L’evento è organizzato da UgiALT.NET insieme a DotNetMarche e sarà un’intera giornata dedicata al noto ORM e a tutto il mondo della persistenza.

La giornata è organizzata su due tracce, sulla principale si tratteranno temi avanzati riguardanti NHibernate mentre la seconda sala sarà a tema libero con la possibilità di organizzare Open space, Coding Dojo, Discussioni, Confronti e tutto ciò che vi viene in mente.

Avremo importanti (-issimi) speaker internazionali che ci parleranno degli internals di NH per questo molte sessioni saranno in inglese.

E’ aperto Call for Presenters per tutti coloro che vogliono proporre una sessione (e ci aspettiamo varie proposte da tutti voi) basta mandare una mail a cfp@ugialt.net con una descrizione della sessione/open space/code kata/ecc… che volete organizzare.

Il 15 giugno apriremo le iscrizioni e le donazioni. Come nelle precedenti edizioni la conferenza è autofinanziata quindi gli iscritti se vorranno potranno fare una piccola donazione per aiutarci a coprire le spese. I posti sono limitati quindi tenete d’occhio il calendario i blog e twitter (#nhday)per essere informati sulle modalità d’iscrizione.

posted @ martedì 18 maggio 2010 11.01 | Feedback (9)

Eliminare gli if con i dictionary

Talvolta si trova questo codice usato (ad esempio) nei ValueConverter di WPF:

public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
  MyEnum myValue = (MyEnum)value;
  String imageUri;
  switch(myValue)
  {
    case MyEnum.Value1: 
      imageUri = "...";
      break;
    case MyEnum.Value2: 
      imageUri = "...";
      break;
    case MyEnum.Value3: 
      imageUri = "...";
      break;
  }
  return new Uri(imageUri , UriKind.Relative);
}

La presenza di questo tipo di switch, sebbene non sia in parti core dell’applicazione (è un semplice converter) mi infastidisce sempre, sarà per quell’indice di complessità che cresce per ogni nuovo caso.

Spesso la rimozione degli if si risolve con l’uso del polimorfismo, ma in questo caso potrebbe essere più comodo utilizzare un dictionary per memorizzare le associazioni enumerator – immagine:

public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
  IDictionary<MyEnum, string> dictionary = new Dictionary<MyEnum, string>();
  dictionary.Add(MyEnum.Value1, "...");
  dictionary.Add(MyEnum.Value2, "...");
  dictionary.Add(MyEnum.Value3, "...");

  MyEnum myValue= (MyEnum) value;
  return new Uri(dictionary[myValue] , UriKind.Relative);
}

Come potete vedere (a parte alcuni dettagli implementativi che ho omesso) abbiamo rimosso completamente gli if riducendo notevolmente la complessità e aumentando la manutenibilità generale del metodo.

PS Con questa tecnica inoltre, il dictionary può essere caricato da una risorsa esterna con tutti i vantaggi che ne conseguono.

posted @ mercoledì 21 aprile 2010 18.25 | Feedback (5)

ViewModel grassi e domini anemici

Il pattern del 2009, per noi sviluppatori Micorosoft, è stato senza dubbio il “Model-View-ViewModel”. L’abbiamo usato con Silverlight, con WPF, qualcuno con ASP.NET MVC ha fatto qualcosa di simile e perfino gli sfortunati che ancora lavorano con WindowsForms hanno provato ad utilizzarlo.

Costruire appplicazioni che usano questo pattern porta spesso ad avere un domain model anemico perchè si tende a spalmare un po’ di logica nei VM e un po’ nei servizi. Di questo ne abbiamo parlato anche sulla ML di ugialt.net.

A mio avviso, se all’inizio questo non è un problema, man mano che l’applicazione cresce si sente la mancanza di un po’ di logica sugli oggetti del DM e ci si ritrova con piccole duplicazioni di codice abbastanza puzzolenti.

Quindi, finchè l’applicazione ha dimensioni medio-piccole possiamo sopravvivere utilizzando i ViewModel++ e usando dei DTO (ossia il domain model anemico) per passare le informazioni dai servizi (model) alle View (anche se mi chiedo perchè usare dei DTO quando potrei far riempire ai servizi direttamente il VM). Se l’applicazione cresce è però conveniente estrapolare la logica dai VM e portarla negli oggetti di dominio.

Sto facendo del refactoring su un’applicazione nata “piccola” ma che sta crescendo bene. Vedremo se i risultati saranno buoni dopo questa rifattorizzazione.

posted @ giovedì 1 aprile 2010 18.49 | Feedback (4)

Corso TDD a Bologna

Segnalo agli interessati che il 25 e 26 Febbraio terrò a Bologna un’altra edizione del corso sul Test Driven Development. Il corso avrà un taglio molto pratico cosi da permettere ai partecipanti di sporcarsi le mani con i test e con i mock objects.

Maggiori informazioni qui: http://www.overneteducation.it/F_Corsi_detail.aspx?Cod_Corso=SQM006 Oppure contattatemi direttamente per saperne di più.

posted @ giovedì 28 gennaio 2010 12.12 | Feedback (12)

WPF ed ereditarietà visuale

Una delle “mancanze” che alcuni lamentano in WPF è l’assenza dell’ereditarietà visuale delle Window e dei UserControl.

In realtà (come per le griglie :-)) non è un problema, esistono semplici meccanismi che permettono di ottenere lo stesso risultato.

Una delle tecniche è quella di utilizzare un template per stilare una BaseWindow o un BaseControl:

Supponiamo di avere una BaseView (Window) base dalla quale facciamo derivare tutte le finestre della nostra applicazione:

Definiremo una classe BaseView che eredita da Window e avrà tutti i metodi/propriertà necessarie:

public class BaseView : Window

{

  // ...

}

    <Style TargetType="{x:Type Common:BaseView}">

        <Setter Property="Template">

            <Setter.Value>

                <ControlTemplate TargetType="{x:Type Common:BaseView}">

                    <StacckPanel>

                            <!-- Altri controlli: toolbar? -->

                            <ContentPresenter/>

                            <!-- Altri controlli: footer? -->

                      </StackPanel>

                </ControlTemplate>

            </Setter.Value>

        </Setter>

    </Style>

Questo stile viene poi applicato a tutte i controlli di tipo BaseView che avranno quindi tutti un aspetto comune.

Quindi per sfruttare il template è sufficiente che le finestre dell'applicazione ereditino da BaseView:

<MyApplication:BaseView>

....

</MyApplication:BaseView>