marzo 2004 Blog Posts
Molto interessante l'implementazione in C# del pattern Strategy utilizzando delegate! Sto preparando per il nostro user group un articolo su questo argomento. Un altro, promesso in un post precedente, è stato già accettato e sarà pubblicato fra pochissimo con il titolo "L'individuazione via reflection delle classi singleton all'interno del Framework .NET".Stay tuned!
In Visual C# Whidbey, una classe singleton:public sealed class Singleton{ private Singleton(){} public static readonly Singleton Instance = new Singleton();}si potrà scrivere in modo ancora più semplice utilizzando le classi static:public static sealed class Singleton{ public static readonly Singleton Instance = new Singleton();}
Sto finendo di scrivere l'articolo sull'individuazione via reflection delle classi singleton all'interno del Framework .NET e scopro una cosa che non mi spiego: perché la classe singleton System.Reflection.Missing ha il costruttore default internal e non private? Qual è secondo voi il motivo di questa scelta? Il codice della classe lo potete guardare qua.
Un altro caso di costruttore default internal è quello della classe (anch'essa singleton) System.Empty che a differenza della precedente è una classe internal e non public.
A proposito di Nullable types vorrei segnalare due cose:
1. un commento interessante di Anders Hejlsberg via un post di Krzysztof Cwalina, PM CLR:
"When you design APIs using Nullable<T>, you have to be very sensitive to the fact that a Nullable<T> is a lot less convenient to use than a T. Nullable<T> with value types makes sense and solves a real world problem--therefore, users will be amenable to the inconveniences of using it. However, Nullable<T> with reference types makes little sense and solves no real world problem. In fact, it adds nothing but confusion because, in terms capabilities, there is no...
Eric Gunnerson, PM nel team di Visual C# "reinventa" i NullableTypes di Luca Minudel! Bello. Ricordo che la versione 2.0 di C# avrà System.Nullable<T>.
Prendete uno specchio e cliccate qua! :-)
Una tesi di master bella, "Design Pattern Extraction for Software Documentation" presentata da Osvaldo Pinali Doederlein nel '99 è tutta intorno a quest'idea di "pattern detection" - molto simile a quello che ho scritto lo scorso weekend con le classi singleton tirate fuori dal framework via reflection (questo weekend mi metto a finire l'articolo promesso e lo vorrei pubblicare qua su UGIdotNET magari in una categoria nuova , "Design Patterns", che Andrea stava pensando di aprire)
Apro la mail e nella newsletter della Wrox scopro il sorriso di Pierre sopra "Professional InfoPath 2003" che deve uscire prossimamente. Complimenti Pierre! The Italians wRox again! :-) Un altro è Marco Bellinaso
Tanti articoli interessanti nella sezione Patterns del sito della AG Communication Systems di cui molto divertenti questi:
"Catalog of Non-Software Examples of Design Patterns", "Retail-Oriented Software Aggravation: A Syndrome of Patterns", "Non-Software Examples of Software Design Patterns", "Workshop on Non-Software Examples of Software Design Patterns","Resign Patterns Ailments of Unsuitable Project-Disoriented Software"
Vorrei citare solo una riga di testo da "Frameworks and Design Patterns" (B.H. Richards, 1997):
"usually frameworks will contain many design patterns. These two concepts are closely related"
Pierre segnala qua un benchmark di C# per calcoli scientifici. Io ne ho trovato un altro, sempre recente. Mi è rimasto un debole per queste cose visti i quattro anni ('92-'96) spesi pensando a robe CFD e a tanta matematica... Per chi ha la curiosità di leggere le conclusioni dell'inchiesta sul citato fallimento di ARIANE5
Un articolo (vecchio, lo so, ha ormai sette anni e mezzo...) esattamente sulla stessa idea ma per il MFC scritto dai finlandesi Nyberg, Raitio e Sydänmaanlakka: "An Analysis of Design Patterns in MFC". Mi fa ricordare i tempi del bel librone di Blaszczak :-)
Questo weekend ho scritto il codice per il primo articolo della serie "Design Patterns all'interno del Framework .NET", che vorrei finire entro questa settimana. Ho cambiato un po' idea su come strutturarlo: visto che tratterà il più semplice dei pattern (il Singleton), ho giocato con la reflection per tirare fuori tutte le classi singleton del framework.
Piccola sorpresa: non solo la System.DBNull è una classe singleton (esempio dato in un post anteriore), ma lo sono anche System.Reflection.Missing, la classe interna System.Empty (sempre del mscorlib.dll) e Microsoft.JScript.Empty insieme a Microsoft.JScript.Missing del Microsoft.JScript.dll. Potete guardare il loro codice nei sorgenti del Rotor per esempio.
Quindi...
Continuo la serie con il Factory Method (pp. 107-116 in GoF)
Douglas Purdy (program manager per XML Web Services e responsabile per la serializzazione e il remoting in .NET) dice:
"The Factory pattern has a long history at Microsoft [...] the benefits of this pattern were not lost on the designers of the .NET Framework. As with many other design patterns, examples of the Factory pattern can be found throughout the Framework"
Vediamo un esempio:
7. System.Web.IHttpHandlerFactory, System.Web.UI.PageHandlerFactory, System.Web.IHttpHandler e la System.Web.UI.Page fanno il Factory Method
dove:
- l'interfaccia System.Web.IHttpHandlerFactory fa la Creator;- la classe interna System.Web.UI.PageHandlerFactory fa la ConcreteCreator;- l'interfaccia System.Web.IHttpHandler fa la Product;- la classe System.Web.UI.Page...
Un link in riferimento al mio post precedente:
"ICloneable interface provides a generic way for classes inside of the .NET Framework to support this pattern [...] Many classes inside of .NET Framework implement this interface to support Prototype pattern""So next type you hear somebody talking about Prototype Pattern and ability to return a copy of the object you can associate this with .NET Framework implementation of ICloneable interface"
Un altro pattern semplice, prima di andare a letto :-)
6. System.IClonable è l'interfaccia nel pattern Prototype (pp. 117-126 nel libro dei GoF)
Per adesso mi interessa solo identificare i pattern come prima fase
Stavo leggendo un capitolo simpatico su "Factoring Metrics" (pp. 57-58) nel libro "Programming .NET Components" di Juval Lowy e incontrando questi numeri:
"On average, a .NET framework interface has 3.75 members, with a methods-to-properties ratio of 3.5:1. Less than 3% of the members are events [...] you could say that on average, .NET interfaces are well factored"
mi sono ricordato di un altro articolo "CLR Types. Use Reflection to Discover and Assess the Most Common Types in the .NET Framework" dove Panos Kougiouris tramite reflection estrae questo:
"all the types in the .NET Framework: 9202 types!"
e tanti altri numeri in questa tabella.
Vale...
Altri design pattern incontrati nel Framework (vedi anche il post precedente):
4. i DiffGram sono rappresentazioni di Unit of Work (pp. 184-194)5. System.Data.DataSet è un Record Set (pp. 508-510)
Le pagine si riferiscono sempre al libro di Fowler.
E' chiaro che le classi non andranno sempre 1:1 con i pattern, ci mancherebbe!
A riguardo della proposta fatta da Luca nel forum e ulteriormente nel suo blog sull'identificazione dei vari design patterns che si trovano nel Framework, tanto per cominciare, eccone due semplici:
1. System.Object è un Layer Supertype (p. 475 nel libro P of EAA di Fowler)2. Tutti i value types sono Value Object (pp. 486-487 dello stesso libro)
Lui ne aveva proposto un altro, altretanto semplice:
3. System.DBNull è un Singleton (pp. 127-134 nel libro dei GoF)
Ogni suggerimento su come strutturare l'elenco è benvenuto! :-)
Io non sarei così radicale come Ian Griffiths nel suo commento sul post di Dino: "If you ever use new at all, you should aim to remove it at the earliest opportunity. It's not something you would ever choose to design in". Basta fare una ricerca nei sorgenti di Rotor per incontrare più volte public new per esempio e non penso che gli sviluppatori del framework non abbiano trovato la "earliest opportunity" per togliere via new :-)
Il campo System.IO.StreamWriter.Null per esempio "nasconde" il campo System.IO.TextWriter.Null da cui deriva e a prima vista non vedo come si poteva scrivere senza new...
Chi altro poteva rispondere meglio alla domanda di Dino se non appunto il papà di C# Anders Hejlsberg nella sua eccellente conversazione con Bill Venners su versioning (cioè new), virtual and override?
E gli argomenti mi sembrano molto "real-world", come chiedeva Dino
Scopro direttamente dalla bocca di Peter de Jong, il papà della serializzazione .NET (cioè dalle sue slide presentate al secondo Rotor Workshop come "History, Architecture, and Implementation of the CLR Serialization and Formatter classes") che:
Constructor is not in Interface, so compiler can’t check whether it presentConstructor isn’t inherited, so each subclass needs its own constructorEarlier version used SetObjectData instead of constructor
e più avanti nella conferenza:
ISerializable underwent many changes
E' quello che notavo in un mio post anteriore sull'asimmetria dell'ISerializable - quindi nelle prime versioni c'era anche SetObjectData! Sicuramente motivi di performance hanno determinato il disegno attuale.
Per chi vuole vedere il...
QueryDOM di Gianluca mi sembra un'eccellente implementazione del pattern Query Object (vedi il libro "Patterns of Enterprise Application Architecture" di Fowler, pp. 316-321). Bel lavoro, Gianluca!
A proposito dei feedback di Corrado segnalati da Raffaele qua, questa funzionalità sarebbe utile anche per i blogs di UGIdotNET!
L'interfaccia ISerializable presenta un'asimmetria su cui secondo me varrebbe la pena di riflettere in modo più profondo:
il suo metodo GetObjectData offre al formattatore un container (SerializationInfo) con tutti i dati necessari per la serializzazione e un altro (StreamingContext) con tutti i, chiamiamoli, metadati. Al contrario, per la deserializzazione, non si trova un simmetrico SetObjectData (come qualcuno si potrebbe aspettare insieme a Christoph Schittko) ma un costruttore protected per la classe che implementa l'interfaccia, costruttore che deve avere gli stessi parametri con il metodo GetObjectData - l'esistenza di questo però non la costringe nessuno... Un processo così simmetrico come quello della serializzazione/deserializzazione,...
Ciao ragazzi, da quasi quattro anni in Italia e da un anno e mezzo su .NET, ecco arrivato il momento di aprirmi un blog in italiano per serializzare qua le cose belle .NET che incontrerò :-)
Solo per chi è curioso, vengo dallo stesso paese di quelli che suonano tutti i giorni nella metropolitana milanese :-) Lì ho conseguito due lauree (la prima in ingegneria navale, la seconda in matematica-informatica). Ho abbandonato dopo due anni un dottorato di ricerca in meccanica dei fluidi per poter dedicarmi di più all'informatica. Ho fatto poi otto corsi di Informix, uno di OMT (una delle...