Container pattern: differenze tra le versioni

Versione delle 23:21, 10 apr 2009

Versione attuale delle 18:07, 1 feb 2024

(34 versioni intermedie di 14 utenti non mostrate)

Riga 1:

{{S|informaticaprogrammazione}}

Il '''Container Pattern''' (anche detto Containment Pattern) è un modello specifico della [[programmazione ad oggetti]] che permette in certi casi una migliore gestione dell'[[Incapsulamento (informatica)|incapsulamento]]. Più che un costrutto, come ogni [[Design Patternpattern]] il Container è una buona pratica da seguire per scrivere codice più intelligente e soprattutto sicuro. ÉÈ stato definito per la prima volta dalla GoF (gang[[Gang of fourFour (scrittori)|Gang of Four]]) nel libro [[Design Patterns|''"Design Patterns: Elements of Reusable Object Oriented Software"'']].

== Funzionamento e Utilizzo ==

Il modello proposto risolve il problema del ''"cracking"'' (della rottura) dell'incapsulamentoIncapsulamento in situazioni di ereditarietà[[Ereditarietà (informatica)|Ereditarietà]] fra classi[[Classe informatica|Classi]]. L'ereditarietà è un principio molto potente della programmazione ad oggetti, che però se mal utilizzato genera perdite in fatto di sicurezza. In particolare, si consideri il caso in cui si vogliano estendere le funzionalità di una classe che implementa alcuni metodi[[Metodo (programmazione)|Metodi]]. Se volessimo creare un nuovo oggetto che, oltre ad implementare tutti i metodi della classe di partenza, modificasse in minima parte uno tra tali metodi, cioè volesse aggiungere alcuni passaggi precedenti o successivi all'[[algoritmo]] di base, la pratica consueta sarebbe quella di derivare dalla classe madre una nuova classe, dichiarando virtual il metodo della classe base e unsovrascrivere il metodo( [[Override]] override) nella nuova. QuestaQuesto però non è certo il modo più corretto per risolvere tale problema, poichèpoiché lascia libertà a chiunque utilizzi la classe madre di overridaresovrascrivere il metodo virtual indiscriminatamente. Neanche utilizzarericorrere lall'hiding con l'utilizzo della keyword ''new'' risolve la situazione, infatti non si rispetterebbero più i buoni principi dell'ereditarietà. Allora la risposta viene dal Container Pattern, che consiste nel creare una nuova classe nella quale sarà assegnato un oggetto della nostra classe di partenza come campo della classe, e successivamente la nuova classe creata implementerà un metodo nel quale inseriremo i nuovi passi dell'algoritmo, oltre ad una chiamata all'algoritmo di base tramite l'istanza della classe madre. Per maggiore chiarezza, si faccia riferimento all'esempio proposto.

== Esempio ==

Nell'esempio proposto, scritto in [[C sharp|C#]], si vuole estendere il metodo ''drinkSomething'' della classe Guy. Qui di seguito è mostrata la soluzione con l'uso di una classe derivata.

[[Categoria:Pattern]]

<syntaxhighlight lang="csharp">

[[Categoria:Programmazione ad oggetti]]

class Guy

{

//Campi della classe e costruttore

//...

//Metodo dichiarato virtual

public virtual void drinkSomething()

{

//algoritmo base

Console.WriteLine("I really like it! Thank you!");

}

//...

}

//Pratica consueta: ereditarietà

//Derivo dalla classe Guy

class Gentleman : Guy

{

//Chiamata al costruttore (base)

//...

public override void drinkSomething()

{

//chiamata al metodo della classe madre

//algoritmo base

base.drinkSomething();

//aggiunta

Console.WriteLine("Would you like some?");

}

//...

}

</syntaxhighlight>

Questa invece è la risoluzione del problema con l'uso del Container Pattern. È sottinteso che il metodo ''drinkSomething'' non sia più dichiarato virtual.

<syntaxhighlight lang="csharp">

class Gentleman

{

//Chiamata al costruttore (base)

//Campo della classe Gentleman:

//istanza della classe Guy

Guy johnny = new Guy();

//...

public void drinkSomething()

{

//chiamata al metodo della classe madre

//algoritmo base

johnny.drinkSomething();

//aggiunta

Console.WriteLine("Would you like some?");

}

//...

}

</syntaxhighlight>

== Collegamenti esterni ==

[http://martinfowler.com/articles/injection.html Inversion of Control Containers and the Dependency Injection pattern] di [[Martin Fowler]] articolo in cui viene introdotto il pattern dell'inversione di controllo e la soluzione mediante container

{{Design pattern}}

<!-- Fumo -->

{{Portale|informatica}}

[[Categoria:PatternDesign pattern]]