AlexP

Dopo aver programmato per oltre 10 anni in C++ e da poco più di 2 anni in C#, posso trarre alcune considerazioni su questi due linguaggi che penso di conoscere in modo approfondito.

C++  (non gestito, non .NET)

C#  (gestito,  .NET)

Come tutte le persone, quando si cambia, si vuole cambiare sempre in meglio.

Passando da C++ a C#, per me, la prima e più tangibile differenza è stato un aumento notevole della produttività dovuta al fatto che il tempo delle compilazioni si è ridotto notevolmente!

Un mio progetto in C++ di 200.000 righe di codice veniva compilato in 45 minuti, mentre lo stesso progetto in C#, si è ridotto a 100.000  righe di codice (ho ottimizzato anche l’architettura) e lo compila in 15 secondi!!

Per quanto riguarda le prestazioni a tempo d’esecuzione (a runtime), passando da C++ a C# si erano ridotte, ma ho ottimizzato l’architettura e sfruttato il multi-thread ottenendo così prestazioni addirittura superiori.

Voi vi chiederete, perché non l’ho fatto anche in C++, semplice, perché i tools di gestione del codice non sono molto efficienti (reattivi) come quelli in C# e ci vuole molto più tempo per ottenere un’architettura complessa (che sfrutta il multi-thread)  ottimizzata al massimo.

Per quanto riguarda i Template (generics) qui è il punto dolente che non sono riuscito a colmare.

Così come sono implementati, i Generics in C#, sono poco utili (esempio banale, non è possibile fare A + B se A e B sono tipi generici).

Niente di nuovo è arrivato con C# 3.0 in quanto si basa ancora su .NET 2.0 che è la causa del problema menzionato.

Spero che .NET 4.0 colmi finalmente questo problema che io sento in modo particolare!

Risultato finale:

C# promosso!... con riserva.

Tutti non fanno che parlare di questi pattern come se fossero la panacea di tutti i mali.

Molti si sentono dei guru spiegando questi pattern, ma dai risultati che si ottengono mi viene da chiedere: ma li hanno mai applicati a dei grandi progetti, realmente?

Anche perché non ho mai sentito parlare di quantità, cioè quanta parte del codice è realmente riutilizzabile.

Sono arrivato al 90% di una applicazione stand-alone basata solo in minima parte su database, ma centrata su elaborazioni e calcoli, realizzata in C# per .NET 2.0.

Visto che si parla già da tempo di .NET 3.0 e 3.5 o voluto seguire i consigli degli “esperti” e utilizzare i pattern MVC e MVP (a seconda delle form) in modo da poter passare da un’interfaccia WinForm a una WPF nel modo più indolore possibile.

Da bravo… architetto / progettista / sviluppatore , ho preso la mia applicazione e l’ho fatta analizzare da uno dei programmi in circolazione (Source Monitor vers. 2.3.6.1) per ottenere le metriche del codice.

Dei risultati ottenuti, riporto i seguenti:

Legenda:

·         UI            : View + Controller + Application;

·         Core        : Model + tutte le altre classi indipendenti dalla UI.

Dall’esperienza si evince che il “Controller” essendo vicino alla “View” ne è dipendente, cioè cambiando la View deve cambiare il Controller. Inutile farsi false illusioni, le UI sono così diverse le une dalle altre che se si vogliono sfruttare a pieno il Controller deve essere realizzato specifico per quella View (UI). Si osservino tutti i casi in cui si è cercato di riutilizzare il Controller (vedi: NSK) l’interfaccia risulta molto scarna (essenziale).

Da questi risultati si evince che metà del codice deve essere riscritto per passare da WinForm a WPF.

A cosa sono serviti i Pattern MVP, MVC ?

Vediamo gli aspetti negativi e positivi dei pattern in questione.

Negativi

1)       se il fine è quello di riutilizzare quanto più codice possibile passando da un tipo di User Interface a un’altra (es. da WinForm  a WPF); conviene dividere il codice in due parti (invece che in tre): uno dipendente dall’interfaccia grafica (View) e l’altro indipendente (Model). Il Controller (nell’MVC) può benissimo essere integrato nella View. Si eviteranno molte complicazioni.

2)        L’architettura del codice è più complessa e la quantità di codice da scrivere aumenta! Quando il nostro fine era proprio quello di riutilizzarlo per scriverne di meno!

3)       Alcuni dicono che si devono utilizzare questi pattern in modo che si possa testare la UI, ma siamo quasi all’assurdo! Il codice da scrivere per poter fare un test è così tanto che è molto più probabile che l’errore si trovi nel codice con cui si vuole testare piuttosto che in quello che si testa. Più semplice è utilizzare manualmente un debugger e si risparmia tempo e si evitano falsi allarmi di bug inesistenti dovuti al codice di test errato.

Positivi

1)       I Controller possono essere organizzati in una gerarchia e quindi, una parte comune (classe base) può essere riutilizzata in altri Controller, avendo così la gestione dell’interazione riutilizzabile all’interno dello stesso progetto. Questo permette anche una gestione più standard e diminuiscono notevolmente il numero di bug dovuti alla gestione delle View.

2)       Il 5% del codice dei Controller (quello delle classi base) può essere riutilizzato quando si cambia la UI.

In questo mio progetto, anche una parte del Model non è riutilizzabile cambiando interfaccia grafica; questo ha fatto si che il Model l’ho dovuto dividere in due parti, uno dipendente dalla UI e l’altro indipendente.

Questo capita nei progetti che non sono solo un trasferimento di dati da e vero un database, ma svolgono anche elaborazioni complesse da un punto di vista grafico.