Pattern Dappertutto

Lazy loading in una riga

Adrian Florea — Thu, 29 May 2008 10:04:38 GMT

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.

Best practice Path.Combine

Adrian Florea — Mon, 05 May 2008 09:44:32 GMT

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";

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 SLAR 1 alla pagina 360, Joel Marcey aggiunge questa nota sulla storia del metodo Combine:

The Combine method had an interesting ride in the standardization process. It was originally part of the Path class, then removed because it was thought to be too platform-specific, then added back because it was decided it was not any more platform-specific than any of the other methods in this class.

Un'API generico a provider per i metadata dei vari ORM

Adrian Florea — Sat, 03 May 2008 13:53:11 GMT

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 poi mi piacerebbe in futuro vedere questa API staccata dal ASP.NET Dynamics Data con cui non dovrebbe avere tanto in comune.

Il pattern Decorator e la decorazione con un extension method generico

Adrian Florea — Thu, 29 Nov 2007 14:47:56 GMT

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 class Decorator : IComponent {
    private readonly IComponent component;

    protected Decorator(IComponent component) {
        if (component == null) throw new ArgumentNullException("component");
        this.component = component;
    }

    public virtual void Operation() {
        this.component.Operation();
    }
}

public class ConcreteDecoratorA : Decorator {
    public ConcreteDecoratorA(IComponent component) : base(component) { }

    public override void Operation() {
        Console.WriteLine("ConcreteDecoratorA");
        base.Operation();
    }
}

public class ConcreteDecoratorB : Decorator {
    public ConcreteDecoratorB(IComponent component) : base(component) { }

    public override void Operation() {
        Console.WriteLine("ConcreteDecoratorB");
        base.Operation();
    }
}

class Program {
    public static IComponent CreateComponent() {
        return
            new ConcreteDecoratorB(
            new ConcreteDecoratorA(
            new ConcreteComponent()));
    }

    static void Main() {
        IComponent component = CreateComponent();
        component.Operation();
    }
}

Questo snippet quindi stampa:

ConcreteDecoratorB
ConcreteDecoratorA
ConcreteComponent

a console. L'idea per modificare il metodo CreateComponent e' semplice: se definiamo una classe statica ComponentExtension contenente un'extension method generico come di seguito:

public static class ComponentExtension {
    public static Decorator DecorateWith<T>(this IComponent component) where T : Decorator {
        return (T)Activator.CreateInstance(typeof(T), component);
    }
}

il metodo CreateComponent diventa:

public static IComponent CreateComponent() {
    return new ConcreteComponent()
            .DecorateWith<ConcreteDecoratorA>()
            .DecorateWith<ConcreteDecoratorB>();
}

che, a mio parere, e' piu' espressivo. Che ne dite?

Collecting Parameter e Fluent Interface - due pattern simmetrici

Adrian Florea — Tue, 30 Oct 2007 11:52:01 GMT

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.

Un modo di marcare il valore di default di un enum

Adrian Florea — Sun, 29 Jul 2007 07:12:00 GMT

"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?

EqualsDefault e l'Equals statico della System.Object

Adrian Florea — Mon, 30 Oct 2006 00:24:00 GMT

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 avere t.Equals(default(T)) perché se t è null, abbiamo NullReferenceException.

Utilizzando l'Equals statico invece, la soluzione diventa banale:

return object.Equals(t, default(T));

[GUISA] Generic Special Case?

Adrian Florea — Sat, 28 Oct 2006 07:10:00 GMT

Un altro thread sul forum di GUISA, partendo da una frase di Janky. Solo un invito a trovare una soluzione insieme...

[GUISA] Enumerable State Machine

Adrian Florea — Fri, 27 Oct 2006 00:56:00 GMT

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.

[GUISA] Quando non rispettare le linee guida?

Adrian Florea — Thu, 26 Oct 2006 03:29:00 GMT

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.