OOP

Il golf e le architetture layered

Gianluca Carucci — Mon, 14 Jul 2008 18:19:20 GMT

Il discorso introduttivo sull'OOD, fatto da Andrea nella sua sessione ai Community Days, mi ha riportato alla mente l'ultima pagina del Regolamento del Golf. Cito testualmente:

Gioca la palla come si trova

Gioca il campo come lo trovi

E se non puoi fare l'una o l'altra cosa,

fai ciò che è giusto

Ma per fare ciò che è giusto,

hai bisogno di conoscere le

Regole del Golf

Trovo in queste poche righe molte similitudini su come credo sia necessario approcciare lo sviluppo software. La difficoltà del nostro lavoro sta tutta nel fare "ciò che è giusto".

Technorati Tag: Golf,OOD,architettura

AOP NET la parola a Don Box....

Gianluca Carucci — Fri, 15 Apr 2005 12:29:00 GMT

Riprendo il post di Lorenzo riguardo l'AOP e Net fornendo uno stralcio dell'intervista a Don Box (per la quanle nn finirò mai di ringraziare il nostro caro presidente :) che esprime il suo parere proprio sull'AOP e sulle tecniche di interception.

Personally, I think there are a lot of interesting programming paradigms out there, and I think that the industry has beaten the "attributes+interception" style of AOP to death. Personally, I've been much more inspired by the ideas that sprang from functional programming and think that Whidbey brings several of those ideas to the masses. Specifically, C#'s anonymous methods (closures) and iterators are far more interesting than yet another way to inject logging code.

BTW, the definitive method for injecting interceptors is the profiling API, which lets you catch every method invocation, not just those that cross a boundary. That stated, the API is so low level that statistically no one is qualified to program with it. In contrast, the C# features borrowed from functional programming are pretty darned accessible to a wide audience.

Il futuro dell'AOP nn sembra molto roseo...:) Prometto di scrivere al più presto un articolo sull'intervista con il testo integrale e qualche commento e considerazione... Parola di lupetto:D

Technorati tags: AOP, design

Initializer nei costruttori: C++ Vs C#

Gianluca Carucci — Fri, 03 Sep 2004 17:51:00 GMT

Spesso, programmando in c++, mi scontro con diversità nell'interpretazione (ed effettiva implementazione) della programmazione a oggetti rispetto al c#. Quando mi trovo in queste situazioni mi viene da pensare il motivo di questa differenza e perchè in fase di progettazione dei due linguaggi Straustrup e Hejlsberg sono arrivati a due conclusioni differenti. L'esempio più eclatante riguarda sicuramente la diatriba sull'ereditarietà multipla. In questo post invece mi volevo soffermare su un problema molto meno rilevante dell'esempio appena citato: l'initializer nei costruttori e in particolare richiamare nell'initializer un'altra versione del costruttore della classe.

In entrambi i linguaggi l'initializer è opzionale e in c# accetta solo costruttori, tramite la parola chiave this (che invoca un costruttore della stessa classe) o base (che invoca il costruttore della classe base). In c++ l'inizializer accetta solo o membri della classe oppure un costruttore della classe base, senza dare la possibilità di richiamare un altro costruttore della stessa classe. Vediamo un esempio:

Abbiamo una classe A e una classe B che eredita da A. Le dichiarazione delle classi è sostanzialmente analoga:

[C#]
public class A
{
private int _a;
//Constructor....
}
public class B: A
{
private int _b;
//Constructor...
}
[C++]
public class A
{
private:
int _a;
//Constructor....
};
public class B: public A
{
private:
int _b;
//Constructors....
};

La parte interessate riguarda l'implementazione dei costruttori. Vediamo i costruttori della classe A:
[C#]
public A() : this(0)
{}

public A(int a)
{
_a = a;
}
....
[C++]
public:
A(void) : _a(0)
{}

A(int a): _a(a)
{}

Le differenze tra i due linguaggi balzano subito agli occhi: In C# non possono essere inizializzati i membri nell'initializer (anche perchè in realtà non ci sarebbe differenza, se non sintattica, rispetto ad inizializzarli nel corpo del costruttore) mentre in c++ non può essere richiamata dal costruttore A(void) la versione del costruttore A(int a).
Vediamo ora i costruttori della classe B:
[C#]
public B() : this(0)
{}

public B(int b): this(0, b)
{}

public B(int a, int b): base(a)
{
_b = b;
}
....
[C++]
public:
B(void) : A(0), _b(0) //Richiamo del costruttore con un parametro della classe base e inizializzazione del membro _b
{}

B(int b): A(0), _b(b)
{}

B(int a, int b): A(a), _b(b)
{}

Dalla classe figlia B balza all'occhio ancora la comodità (e spesso necessità) del c++ di inizializzare i membri nell'initializer e l'impossibilità di richiamare una versione diversa del costruttore della classe. E' possibile invece richiamare un costruttore della classe figlia.
Come si dice in questi casi la domanda nasce spontanea: perchè inell'initializer, n c++, si può richiamare un costruttore della classe base e non un costruttore diverso della classe figlia? E' una scelta progettuale ed è dettata da una ragione ben precisa o più semplicemente in fase di progettazione del linguaggio non è stata proprio pensata una situazione di questo genere? Visto e considerato che C# è un linguaggio più nuovo, e permette questa situazione, mi viene da pensare che sia stata una "dimenticanza" del c++. La sensazione è che a questa domanda può rispondere solo Mr. Straustrup:)

Ai POSTeri l'ardua sentenza....

Design Pattern&Reflection

Gianluca Carucci — Fri, 02 Apr 2004 10:37:00 GMT

Volevo fare i complimenti ad Adrian per il bellissimo articolo sulla ricerca del pattern Singleton. Oltre ad essere molto interessante lo trovo scritto veramente bene. Complimenti Adrian! A quanto il prossimo numero?:)

Il 90% dei problemi di performance sono nel design non nel codice

Gianluca Carucci — Thu, 12 Feb 2004 10:25:00 GMT

Questa è una delle "Ten Rules of Performaces" scritte da Paul Vick nel suo blog. C'è sempre da imparare... :)