Pattern Dappertutto
Sto leggendo il bellissimo libro di Dino & Andrea, "Microsoft .NET: Architecting Applications for the Enterprise" e mi ha incuriosito questa loro osservazione alla pagina 362: "[...] Microsoft Foundation Classes (MFC) offered more than a decade ago an architecture with some points in common with MVC - particularly, the Document/View (DV) model. DV can be seen as a version of MVC where the view and controller are fused together. We really don't know whether the MFC team intentionally discarded MVC to embrace DV; our feeling, however, is that DV blossomed autonomously during the design by simply applying correctly and diffusely...
Carino questo modo proposto da Frank Quednau di implementare il lazy loading utilizzando l'operatore di null coalescing (ECMA-334, 14.12) e il fatto che il risultato di un'assegnazione e' il valore assegnato all'operando sinistro (ECMA-334, 14.14.1):
internal sealed class PersonProxy : Person
{
public override AddressCollection Addresses
{
get
{
return base.Addresses ?? (base.Addresses = new PersonDataMapper().GetAddressesByCode(this.Code));
}
set
{
base.Addresses = value;
}
}
}
A me sembra molto espressivo.
Se vogliamo che il nostro codice giri anche su Mono, dobbiamo utilizzare:
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "aaa.bbb")
al posto di:
AppDomain.CurrentDomain.BaseDirectory + "aaa.bbb"
perche' su Mono, BaseDirectory ritorna una stringa che non finisce in Path.DirectorySeparatorChar, mentre su CLR si'. E questo va anche in generale, quando costruiamo il path da piu' pezzi, non solo nel caso della BaseDirectory. Per esempio, chi utilizza fyiReporting RDL Project su Mono, dovrebbe modificare la riga 81 nel file Runtime/RdlEngineConfig.cs nei sorgenti del progetto e ricompilare, da:
file = dir + "RdlEngineConfig.xml";
a:
file = Path.Combine(dir, "RdlEngineConfig.xml");
perche' la stringa dir, per come e' stata costruita, su CLR finisce in Path.DirectorySeparatorChar, mentre su Mono no. In...
Via questo post di Frans Bouma ho scoperto sotto il namespace System.Web.DynamicData.ModelProviders dell'assembly System.Web.DynamicData.dll che arriva con l'ultima release della preview di ASP.NET Dynamic Data, un'API generico composto da 4 provider per i metadata dei vari ORM (non solo Microsoft): DataModelProvider, TableProvider, ColumnProvider ed AssociationProvider. Questo unifica in buona misura le varie API che espongono i metadata degli ORM, per esempio MetaTable, MetaDataMember, MetaAssociation nel caso di LINQ to SQL, oppure quella piu' complessa dell'Entity Framework: EntitySet, EdmMember, NavigationProperty, etc. Frans ha gia' scritto un model provider per il suo LLBLGen Pro, sarebbe bellissimo averne uno anche per NHibernate. E...
Stamattina, al corso che sto tenendo di architettura base, ho presentato ai ragazzi il classico pattern Decorator per servirci poi nell'implementare i vari servizi di validazione, logging, caching, etc., come decoratori di un repository, ispirato da questo post di Ayende. Uno di loro mi ha chiesto se si poteva scrivere il corpo della CreateComponent in modo ancora piu' usabile. E mi e' venuta l'idea di utilizzare un extension method generico fluente, tanto per introdurli un po' anche nel mondo di C# 3.0
Partiamo dall'implementazione standard del pattern:
using System;
public interface IComponent {
void Operation();
}
public class ConcreteComponent : IComponent {
public void Operation() {
Console.WriteLine("ConcreteComponent");
}
}
public abstract...
Ho notato oggi delle simmetrie tra questi due pattern: il pattern di refactoring, CollectingParameter, che accumula informazioni nell'istanza del parametro (input) e il pattern FluentInterface, che accumula informazioni nel valore di ritorno (output). Il tipo del parametro e' diverso dal tipo che contiene i metodi nel CollectingParameter, mentre il tipo del valore di ritorno e identico al tipo che contiene i metodi nel FluentInterface.
Esempi di altre simmetrie nei pattern trovate nel nostro wiki, raccolti da Luca.
"Do provide a value of zero on simple enums" dice una linea guida del FDG (p. 95). Ma forse sarebbe ancora piu' espressivo marcare questo valore di default di un enum appunto come una default value expression (ECMA-334, 14.5.14) anziche' impostarlo a 0. Cioe', scrivere:
public enum Compression{ None = (int)default(Compression), GZip, Deflate}
al posto di None = 0. In ogni caso, il compilatore genera lo stesso IL. E' solo un'idea, che ne dite?
A volte, un umile metodo come l'Equals statico della classe System.Object può rendersi sorprendentemente utile. Per esempio, in una classe generica in cui il type parameter T può essere sia una class che una struct, abbiamo la necessità di controllare che un'istanza di T sia default(T).
class Foo<T> { public bool EqualsDefault(T t) { /* ? */ } }
Senza l'Equals statico le soluzioni sono abbastanza bruttine:
non possiamo avere t == null perché T può essere una struct;
non possiamo avere t == default(T) per l'errore CS0019 ("Operator '==' cannot be applied to operands of type 'T' and 'T'");
non possiamo...
Un altro thread sul forum di GUISA, partendo da una frase di Janky. Solo un invito a trovare una soluzione insieme...
Sul forum di GUISA ho postato qui un'implementazione del pattern State sfruttando la macchina a stati generata dal compilatore C# 2.0 per un iteratore generico. L'idea mi è venuta per gioco, diciamo che per adesso potrebbe essere interessante soprattutto per quelli che vogliono capire gli iteratori generici, non necessariamente come implementazione "seria" del pattern State.
Ho appena creato un thread sul forum di GUISA (Gruppo Utenti Italiani Solution Architect) in cui offro un esempio dove ha senso che il metodo GetHashCode ritorni sempre un valore costante e dove il metodo Equals è molto atipico: due istanze sono uguali se sono istanze del tipo contenente questi metodi - quindi semantica statica per una classe non-statica.
Cercherò di postare lì le cose che riguardano l'architettura, per seguire sia io che voi più facilmente i feedback, mentre qui sul blog solo una piccola info.
In "verticale":
Il metodo del Framework con il corpo più lungo (sia per la versione 1.1 che per la 2.0) è il metodo pubblico void Go() della classe internal System.Web.RegularExpressions.TagRegexRunner1 che si trova nell'assembly System.Web.RegularExpressions.dll; il suo corpo in IL ha 5770 bytes, che corrispondono a 862 righe di codice C# in Reflector! - posso dire pazzesco?...
Se invece consideriamo solo i metodi pubblici dei tipi pubblici, abbiamo:
per la versione 2.0, il metodo pubblico void Register() della classe pubblica System.Globalization.CultureAndRegionInfoBuilder che si trova nell'assembly sysglobl.dll; il suo corpo in IL ha 1088 bytes, che corrispondono a 69 lunghe righe di codice C#...
Stamattina ho incontrato questa frase del grande matematico ungherese George Pólya:
"If you can't solve a problem, then there is an easier problem you can solve: find it"
e ho pensato subito al refactoring pattern Compose Method:
"You can't rapidly understand a method's logic. Transform the logic into a small number of intention-revealing steps at the same level of detail"
che, volendo, ci porta al buon Divide et impera.
A volte, il codice "riflesso" con il Reflector, ci mette su false piste. Qualcuno, guardando per esempio l'implementazione dei singleton delle classi factory dei provider ADO.NET, tramite il Reflector, potrebbe erroneamente pensare che inizializzare esplicitamente un campo statico nel costruttore statico fosse una best practice:
// snippet 1// codice tramite il Reflectornamespace System.Data.SqlClient{ public sealed class SqlClientFactory : DbProviderFactory { public static readonly SqlClientFactory Instance; // codice non ottimizzato static SqlClientFactory() { Instance = new SqlClientFactory(); } private SqlClientFactory() { } // ... }}
E invece, il codice "reale" è questo:
// snippet 2namespace System.Data.SqlClient{ public sealed class SqlClientFactory : DbProviderFactory { ...
Nel libro di Cwalina & Abrams (p. 93), la regola "avoid publicly exposing enums with only one value" ha questo commento:
"A common practice for ensuring future extensibility of C APIs is to add reserved parameters to method signatures. Such reserved parameters can be expressed as enums with a single default value. This should not be done in managed APIs. Method overloading allows adding parameters in future releases."
E' proprio il caso del enum nidificato SingleSignonTicketType (SharePoint Portal Server 2003), creato solo per "riservare" il parametro Type nel metodo ReserveCredentialTicket, metodo a cui corrisponde la procedura esterna dallo stesso nome (vedi la...
Ho letto con molto piacere nel libro di Cwalina & Abrams i seguenti frammenti di Abrams e Mariani che mi hanno portato subito a ricordare la frase di Exupéry che fa sin dall'inizio da sottotitolo al mio blog:
Antoine de Saint-Exupéry:
"You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away"
Brad Abrams (p. 22):
"One of the important principles in designing .NET Framework was the notion of addition through subtraction. That is, by removing (or never adding) features from the framework we could actually make developers more productive because...
Certi linguaggi, come per esempio J#, impongono l'accesso public al metodo entrypoint. Però, dal punto di vista del utilizzatore della classe che contine l'entrypoint, questo membro public non presenta alcun interesse, cioè non viene quasi mai richiamato dal codice. Sto pensando quindi che si potrebbe decorare con l'attributo EditorBrowsable(EditorBrowsableState.Never) in tal modo da non comparire nell'elenco intellisense dei membri pubblici della classe.
Facendo oggi con Massimo il refactoring con generics della classe DotNetNuke.Common.Utilities.Null, sono nate alcune considerazioni sui tipi generici. Di seguito il post a 4 mani - si nota anche dall'italiano :-)
Avendo una classe static Foo che espone funzionalità generiche e più conveniente definire il type parameter per un metodo (Dummy) piuttosto che per la classe. Questo perché a runtime verrà generata un'unica classe Foo con più metodi Dummy anziché più classi Foo con un metodo Dummy ciascuna. Per esempio, il seguente snippet:using System; class Foo<T>{ static Foo() { Console.WriteLine("Foo<{0}>", typeof(T)); } public static void Dummy() { }} class Foo{ static Foo() { ...
Mi è venuta in mente questa idea e mi interesserebbe un feedback da parte vostra a riguardo.
Per obbligare una classe ad avere un costruttore default (public e senza parametri), mi sono costruito una marker interface generica con constructor constraint:
public interface IDefaultConstructor<T> where T : new() {}
e quindi basta che la classe Foo implementi IDefaultConstructor per essere sicuri in fase di compilazione che essa abbia un costruttore default:
class Foo : IDefaultConstructor<Foo>{ public Foo() // garantito! { // ... } // altri costruttori... public Foo(int i) { //... } // il resto dei membri}
Potete sfruttare questa bella e rara occasione per porre le vostre domande sul futuro dei pattern, scrivendo al mio connazionale Dragos Manolescu che salirà lunedì 26 settembre sul palco della JAOO Conference 2005 per il panel "Panel of experts on the future of patterns" all'interno del track "Patterns - Past, Present, and Future", insieme ad altri 4 massimi esperti.
Un progetto interessante, soprattutto per MCT, speaker, altri formatori, almeno come esercizio intellettuale.
Come utilizzare un'enumeration come attribute?
Nello snippet seguente mostro un semplice ma elegante pattern per il wrapping di un'enumeration (ho inserito le spiegazioni come commenti nel codice).
Il fatto che il wrapper deriva da System.Attribute è solo per offrire una situazione concreta in cui il wrapping diventa utile e necessario. Con il valore 0 per il primo elemento dell'enumeration ho voluto ricordare una best practice spesso dimenticata: "ensure that 0 is a valid state for value types" (vedi l'item 8 del libro "Effective C#" di Bill Wagner, oppure (aggiornamento 1: 06/07/05) la regola 10.9 nel libro di Balena e Dimauro).
using...
Succede che a volte dovete cambiare i nomi degli elementi in un'enum, per esempio, da ConsoleKey.BackSpace a ConsoleKey.Backspace, oppure da ConsoleKey.SpaceBar a ConsoleKey.Spacebar, utilizzando l'attributo Obsolete. Attenzione all'ordine degli elementi con lo stesso valore! L'elemento obsolete deve essere posizionato dopo l'elemento valido dello stesso valore.
Il seguente snippet:
class Test{ static void Main() { Foo f = (Foo)1; System.Console.WriteLine(f); }}
stampa SomeThing a console se l'enum è:
// NO!public enum Foo{ [Obsolete("Use Foo.Something.")] SomeThing = 1, Something = 1}
e Something se l'enum è:
// OK!public enum Foo{ Something = 1 [Obsolete("Use Foo.Something.")] SomeThing = 1,}
Sfogliando le quasi 600 slide del corso di Design Patterns, tenuto dal Prof. Uwe Aßmann alla Linköpings Universitet, mi ha colpito questa splendida metafora aritmetica per i design pattern:
"The basic solution strategy of a design pattern is factoring:
a * b + a * d = a * (b + d)
Design patterns are the “binomial formulas” of software engineering!"
Il corso non è per niente standard e quindi, un'utilissima lettura anche per i più esperti, per l'inedita prospettiva che offre!
class Foo{ static Foo() { System.Console.WriteLine("Ciao!"); } static void Main(){}}
Questo innocente snippet stampa a console Ciao! pur avendo un Main vuoto. Per evitare stranezze di questo tipo, ho tirato fuori una best practice per i Main: evitare di avere un costruttore di tipo nella classe che contiene l'entry point.
Una specie di wrapper si potrebbe utilizzare quando si ha bisogno di un "attributo enumerato"
using System;public enum FooEnum{ Foo1, Foo2}public class FooAttribute: Attribute{ private FooEnum _foo; public FooEnum Foo { get { return _foo; } } public FooAttribute(FooEnum foo) { _foo = foo; } public static readonly FooAttribute Foo1 = new FooAttribute(FooEnum.Foo1); public static readonly FooAttribute Foo2 = new FooAttribute(FooEnum.Foo2);}
Da notare i due campi statici e in sola lettura, Foo1 e Foo2, che corrispondono ai valori del tipo enumerato. Fanno la ricerca dell'attributo, più usabile:
IList attributes = typeof(Bar).GetCustomAttributes(false);if (attributes.Contains(FooAttribute.Foo2)){ //}
dove, per esempio, abbiamo:
[Foo(FooEnum.Foo2)]class Bar{ //}
Un esempio...
Un esempio semplice d'implementazione del pattern TemplateMethod all'interno del Framework .NET è costituito dalla renderizzazione dei server control web:
// ...namespace System.Web.UI.WebControls{ public class WebControl // ... { protected override void Render(HtmlTextWriter writer) { RenderBeginTag(writer); RenderContents(writer); RenderEndTag(writer); } public virtual void RenderBeginTag(HtmlTextWriter writer) { // ... } protected virtual void RenderContents(HtmlTextWriter writer) { // ... } public virtual void RenderEndTag(HtmlTextWriter writer) { // ... } // ... }}
I ruoli sono chiari:
la classe WebControl fa da AbstractClass (anche se non è abstract);
le classi che derivano da WebControl fanno da ConcreteClass;
il metodo Render fa da TemplateMethod;
i metodi RenderBeginTag, RenderContents e RenderEndTag fanno...
Dopo un non breve scambio di email con Paolo Arvati e in base a un suggerimento di Stefano Grevi, posto una nuova implementazione per il pattern:
public class FriendlyInheritableType{ internal FriendlyInheritableType() { if (this.GetType().Assembly != typeof(FriendlyInheritableType).Assembly) { throw new NotSupportedException(); } } public static FriendlyInheritableType NewInstance() { return new FriendlyInheritableType(); }}
Altrimenti, nella notazione del post precedente, FooInside deve o essere sealed, o implementare anche essa il pattern di FooBase, per non spezzare il limite di ereditarietà.
La soluzione che ho trovato per impedire l'ereditarietà cross-assembly ha profumo di pattern:
Come fare sì che la classe pubblica FooBase sia ereditabile esclusivamente all'interno di FooIn (l'assembly che la contiene) ma istanziabile anche all'esterno di questo?
// FooIn.cs// csc /t:library FooIn.csusing System;public class FooBase{ internal FooBase(){} public static FooBase CreateFooBase() { return new FooBase(); } public void DoSomething() { Console.WriteLine("FooBase"); }}// OKpublic class FooInside: FooBase{ public void DoSomethingElse() { Console.WriteLine("FooInside"); }}
Quindi riusciamo a derivare FooInside da FooBase (perché si trovano tutte e due in FooIn.dll) ma non è possibile derivare FooOutside da FooBase (perché si trova in un altro...
Don Box nel suo libro (pp. 362-363) suggerisce il fatto che MSCOREE.DLL è un Facade al CLR:
"In fin dei conti il CLR è implementato come una famiglia di DLL Win32/COM. [...] MSCOREE.DLL è detta a volte "supporto" poiché è semplicemente una facciata che nasconde le reali DLL che comprendono il CLR. [...] MSCOREE.DLL si trova di fronte a una di due DLL: MSCORWKS.DLL e MSCORSVR.DLL. La DLL MSCORWKS.DLL è la build monoprocessore del CLR; MSCORSVR.DLL la build multiprocessore CLR. [...] E' compito di MSCOREE.DLL selezionare la build appropiata sulla base di un certo numero di fattori, incluso (ma non solo)...
Se nel vostro assembly di test (NUnit) avete un file "App.config", dovete copiare questa riga esattamente così com'è, senza sostituire nulla:
copy "$(ProjectDir)app.config" "$(TargetDir)$(TargetFileName).config"
e incollarla in:
Common Properties > Build Events > General > Post-build Event Command Line
sotto le proprietà del vostro progetto di test.
Utilissimissimo tip se implementate per esempio il pattern Provider (come sto facendo io). Qualcuno conosce un'altra soluzione?
Il mio primo post, dopo quello di presentazione, è stato su "L'asimmetria dell'ISerializable", seguito a brevissima distanza da un altro sullo stesso argomento: "Prima ISerializable aveva SetObjectData". Stamattina sul treno, vedo che anche Juval Lowy (Regional Director, Software Legend), nel suo libro "Programming .NET Components", alla pagina 224, scrive:
"The design decision the architects of .NET serialization took was to force a runtime check for the deserialization constructor instead of a compile-time check. However, I believe a better design decision would have been to provide a SetObjectData() method on ISerializable and, during deserialization, use reflection to set the fields of a...
Ho scoperto dal post "GUI patterns" di Jeff Atwood, questo meraviglioso sito di Martijn van Welie. E' d'obbligo navigarlo per bene!
In un post di due settimane fa segnalavo la possibilità di creare classi proxy dinamiche in .NET con NMock. Siccome ho l'intenzione di scriverci un articolo, non appena troverò una finestra di tempo, mi sono preparato la tabella qui sotto che riassume lo stato dell'arte dei progetti open-source che implementano in .NET la creazione di classi proxy dinamiche
J2SE (questa riga serve da confronto con i progetti qui sotto)
Sun Microsystems
java.lang.reflect.InvocationHandler
java.lang.reflect.Proxy
Progetto
Autore
Classi
NMock
Joe Walnes
NMock.IInvocationHandler
NMock.Dynamic.ClassGenerator
Apache Avalon Castle DynamicProxy
Hamilton Verissimo de Oliveira
Apache.Avalon.DynamicProxy.IInvocationHandler
Apache.Avalon.DynamicProxy.ProxyGenerator
DynaProx.NET
Sébastien Bouchet
DynaProx.Framework.CallHandler
DynaProx.Framework.ObjectFactory
CIL Programming: Under the Hood of .NET (libro)
Jason Bock
Proxies.InvocationHandler
Proxies.Proxy
Così nel frattempo può servire anche a voi.
Aggiornamento (23/08): Ho cambiato l'impostazione della tabella, grazie ad...
Grady Booch, uno dei tre famosi "Three Amigos", ha raccolto una lista equilibratissima e di finissimo palato di siti dedicati all'architettura software. La riposto qui sotto per chi ha troppa fretta per registrarsi sul sito di Booch:
AcademicSoftware Engineering Institute -> Software ArchitectureUniversity of California, Irvine -> Institute for Software Research -> Software Architecture ResearchUniversity of Illinois, Urbana-Champaign -> The Software Architecture GroupUniversity of Southern California -> Software Architecture GroupUniversity of Stuttgart -> Project BauhausUniversity of Texas -> Product-Line Architecture Research GroupUniversity of Waterloo -> Software Architecture Group
CommercialBredemeyer ConsultingIBM -> IBM Patterns for e-businessMicrosoft -> Microsoft Architects JOURNALPhilips -> Gaudí System...
Interessante l'osservazione di Michael Geary sulle Class Naming Guidelines. Non ci avevo mai pensato :-)
Per chi non ha fatto ancora subscribe al blog di Michael Geary, conviene che legga il suo resume...
A partire da J2SE 1.3, Java ha una classe molto interessante: java.lang.reflect.Proxy che permette la creazione di classi proxy dinamiche. In .NET per adesso manca un meccanismo così semplice. Ho trovato pubblicate 3-4 possibili soluzioni e quella che mi piace di più è con l'aiuto della classe NMock.Dynamic.ClassGenerator di NMock (in questo post di Joe Walnes - uno degli sviluppatori di NMock). Trovare il tempo per scriverne un articolo...
Qualche visitatore del mio blog, magari osserverà leggendo questo paragrafo di Mark Brooks che i pattern non sono così astratti, che vale insomma la pena di passare il ponte che separa il modo in cui costruiamo adesso i nostri prototipi e il modo in cui dovremmo, con un po' di strategia e magari dopo qualche iterazione pensarli. interpretarli, in fine adattare quelli giusti al nostro problema. Non è una roba di facciata, di sola moda, un'ennesima minchiata per decorare il nostro CV ma, ricordatevi sempre questo, è un mezzo per raggiungere quello stato di cose fatte bene, quel mischio di...
Questi giorni, oltre al progetto .NET su cui normalmente lavoro, dedico parte del tempo a preparare un corso di JSP e Servlet che terrò da settembre a dicembre. Sono ormai quasi 2 anni e mezzo da quando ho lasciato Java e sono scappato con .NET in un'inaspettata e dolcissima avventura :-) Guardo quindi Java con altri occhi, adesso che devo rivedere la materia.
Per esempio, il metodo getParameterValues dell'interfaccia javax.servlet.ServletRequest ritorna java.lang.String[] :
public java.lang.String[] getParameterValues(java.lang.String name)
"Returns an array of String objects containing all of the values the given request parameter has, or null if the parameter does not exist."
Già il fatto di ritornare...
Nel mio articolo "L'individuazione via reflection delle classi singleton all'interno del Framework .NET" - grazie per il rating 4,70 :-) - trovavo le seguenti 3 classi singleton:
Microsoft.JScript.Empty
Microsoft.JScript.Missing
System.DBNull
e finivo l'articolo con una mia perplessità:
"Giocando con vari test e cambiando leggermente i requisiti di implementazione ho scoperto che la classe System.Reflection.Missing ha il costruttore internal anziché private, per il resto è un singleton puro. Mi chiedo se si tratta di una disattenzione da parte degli sviluppatori del Framework oppure se è stata pensata come singleton solo all'esterno del Framework. Un caso simile è quello della classe interna System.Empty dove di...
La proprietà Length di System.IO.Stream e di tutte le sue classi derivate non è l'unica proprietà read-only per cui esiste nella stessa classe un metodo setter ma lo sono anche le proprietà In, Out ed Error della classe System.Console:
public sealed class Console{ //... private static TextReader _in; public static TextReader In { get { //... } } public static void SetIn(TextReader newIn) { //... } private static TextReader _out; public static TextReader Out { get { //... } } public static void SetOut(TextWriter newOut) { //... } private static TextWriter _error; public static TextReader Error { get { //... } } public static void SetError(TextWriter newError) { //... } //...}
Ho verificato via reflection che questi sono gli unici casi all'interno del Framework di proprietà read-only pubbliche con setter pubblico nella stessa classe pubblica. Secondo me è interessante questa...
public abstract class Stream: MarshalByRefObject, IDisposable{ //... public abstract long Length {get;} public abstract void SetLength(long value); //...}
Proprietà read-only e setter come metodo...Secondo voi è stata una scelta oppure uno strano errore progettuale? Lo so, prima o poi scriverò una mail a Brad... :-)
"In general I am not a big fan of sealing classes arbitrarly. As a general rule we designed classes in the BCL with extensibility in mind. However, from a pragmatic standpoint that is not always possible. [...] a fully extensible design is not always practical [...]" (Brad Abrams, SLAR, p. 424)
Incuriosito da quanto vuol dire in numeri la frase di Brad "I am not a big fan of sealing" mi sono messo a contare (no, non a mano!) tutte le classi sealed tra le classi non abstract in tutti i namespace sotto System, System ovviamente compreso. Il risultato? 1695 classi...
Visti i feedback abbastanza buoni :-) della serie di quiz su C#, ho pensato ad aprirne un'altra, forse più difficile, su design patterns. L'ho chiamata Patty Quiz per toglierle un po' di occhiaie e non per ultimo, perché mi piace tanto Patty Pravo :-)
Il codice qui sotto vuole calcolare il numero delle foglie (nodi senza figli) del grafo orientato determinato dal nodo di partenza root:
using System;using System.Collections;interface Component{ void Add(Component c); int Count{get;}}class Composite: Component{ private ArrayList _children = new ArrayList(); public void Add(Component c) { _children.Add(c); } public int Count { get { int count = 0; foreach(Component c in _children) { count += c.Count; } return count; } }}class Leaf: Component{ public void Add(Component c) { throw new NotSupportedException("Le foglie non hanno...
Sto guardando la classe System.Collections.Specialized.NameObjectCollectionBase e le sue classi derivate e non capisco la ragione del prefisso "Base" di alcuni suoi metodi protected (BaseAdd, BaseClear, BaseGet, BaseGetAllKeys, BaseGetAllValues, BaseGetKey, BaseHasKeys, BaseRemove, BaseRemoveAt, BaseSet). Questi metodi sono richiamati dai loro metodi corrispondenti (Add, Clear, Get, GetAllKeys, GetAllValues, GetKey, HasKeys, Remove, RemoveAt, Set) nelle classi derivate ma, secondo me, queste richiamate andavano fatte come base.Method() anziché BaseMethod() e i metodi di forma BaseMethod nella classe base rinominati Method. In più, NameObjectCollectionBase sembra l'unica classe che abbia questo pattern strano.Un po' di refactoring o qualcosa mi sfugge?
Ho trovato all'interno del Framework tre interfacce di questa forma:public interface IServiceNameProvider{ ServiceResultType GetServiceName(ServiceParameterType param);}una specie di Strategy.
Service Name
Interface
Method
Service Result
Service Parameter
Format
System.IFormatProvider
GetFormat
System.Object
System.Type
Service
System.IServiceProvider
GetService
System.Object
System.Type
HashCode
System.Collections.IHashCodeProvider
GetHashCode
System.Int32
System.Object
Un altro esempio di Strategy (pp. 315-323 in GoF), continuando questa serie di post: 1, 1.1, 2, 3, 3.1, 4, 4.1, 4.2, 5:- System.Collections.Hashtable fa la Context;- System.Collections.IHashCodeProvider e System.Collections.IComparer fanno le Strategy;- le classi che implementano System.Collections.IHashCodeProvider e System.Collections.IComparer fanno le ConcreteStrategy;- i metodi GetHashCode e rispettivamente Compare fanno gli AlgorithmInterface;- i metodi protetti GetHash e rispettivamente KeyEquals fanno i ContextInterface
Esiste una classe (System.NotSupportedException ma ce ne sono anche altre) che ha un ruolo più profondo nella progettazione in generale di una gerarchia di classi, quasi come se fosse una feature di linguaggio:"There are methods that are not supported in the base class, with the expectation that these methods will be implemented in the derived classes instead. The derived class might implement only a subset of the methods from the base class, and throw NotSupportedException for the unsupported methods." (.NET Framework Class Library Reference)"A typical scenario is when a base class declares a method that derived classes are required to...
Per chi non lo sapesse ancora, dal dicembre scorso un altro peso massimo, Ward Cunningham, ha deciso di lavorare per la Microsoft come architect nel gruppo PAG (Prescriptive Architecture Guidance). Chi manca ancora? :-)
Tante volte forse avete associato l'eredità con la flessibilità. Qui di seguito un punto di vista diverso ma altrettanto interessante:"Sealing members or leaving them non-virtual also allows you more flexibility in changing your class's implementation in the future, by limiting users' points of customization."(Brian Grunkemeyer, SLAR p. 72)
E se vi chiedete cosa vuol dire "begrudgingly" in inglese (nella stessa p. 72) , eccola qui spiegata :-) Pensavo che fosse una parola un po' begrunkemeyeriana... :-)
Full Pattern Dappertutto Archive