C# Nullable Types: 2 errori nel disegno


Il punto centrale del pattern nullable object o special case che dir si voglia è quello di evitare gli IF per gestire il Null. E invece ...
Nella conversione da int? a string:  non c'è modo di specificare che stringa usare in caso di null senza usare un IF nemmeno con l'operatore ??.  Per es. in una label vorrei poter visualizzare il numero oppure N.A. quando c'è il null e mi tocca mettere un if.    



L'abilita principale di un programmatore è sapersela cavare col codice. E invece...
Al posto di contare sulla capacità dei programmatori di capire e usare correttamente la logica booleana dei NULL standardizzata da SQL ne hanno inventata una nuova perché  "più intuitiva"




Per quanto ogni disegno è opinabile, lo svantaggio qui è evidente
:( nel primo caso un IF in più riduce la semplicità del codice, raddoppia lo sforzo necessario per testarlo e la possibilità di introdurre un bug
:( nel secondo caso un programmatore può dover scrivere un WHERE con una logica SQL dei NULL e un momento dopo una espressione bool? con una logica C# E non voglio sapere quale logica i SqlType  adottano con i NULLABLE BOOL o cosa accade con una espressione bool? in una Stored Procedure C# di SqlServer



A chi fa una osservazione la resposabilità di proporre una alternativa!  Nel primo caso un overload del ToString() che accetta come parametro la stringa per il caso NULL o una implementazione del IFormatter che consente di indicarlo nella stringa di formattazione Nel secondo caso degli extension methods .And .Or .Not che implementano la logica SQL
 
Tags :  |  |

Print | posted @ martedì 24 marzo 2009 22:36

Comments on this entry:

Gravatar # re: C# Nullable Types: 2 errori nel disegno
by Raffaele Rialdi at 27/03/2009 16:31

Luca, da quello che scrivi cerchi un linguaggio meno imperativo e questo non è C#.

Gli IF inevitabili sono parte integrante della programmazione nei linguaggi imperativi e avrai sempre molti casi in cui sono assolutamente inevitabili.

Prova F# e avrai maggiori soddisfazioni per quel genere di costrutti.
Il vantaggio di F# rispetto ai suoi predecessori funzionali è di poter essere usato *anche* in modo imperativo per quei costrutti che non possono essere espressi diversamente.
Gravatar # re: C# Nullable Types: 2 errori nel disegno
by Raffaele Rialdi at 27/03/2009 23:23

Sto facendo un discorso generale. Ad ogni modo considerato che il significato del null cambia a seconda del contesto, le assunzioni che fai per evitare l'if possono stravolgere il significato del null in quel contesto. Sul db il null può stare per diverse cose: 'non applicabile', 'entità non esistente' (outer join), 'default', etc.

Ma dicevo che il mio è un discorso più generale. I linguaggi imperativi come C#, C++, VB devono esprimere l'algoritmo 'guidando' il flusso dell'algoritmo.
Certo alcune volte puoi cercare di semplificare usando OOP ma se l'algoritmo è complesso l'IF è inevitabile per la natura stessa del linguaggio.

I linguaggi funzionali partono da un concetto differente e descrivono una pipeline di costrutti che puoi montare a piacere. Gli IF sono praticamente inesistenti in tutte le dichiarazioni funzionali pure.
Ma visto che prima o poi ti trovi ad usare delle funzioni di libreria o a dover comunque esprimere qualcosa in modo imperativo, F# salva capra e cavoli e ti permette anche di scrivere codice imperativo.
Comments have been closed on this topic.