Container pattern: differenze tra le versioni

Versione delle 14:38, 28 mag 2010

Versione attuale delle 18:07, 1 feb 2024

(13 versioni intermedie di 12 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 pattern]] il Container è una buona pratica da seguire per scrivere codice più intelligente e soprattutto sicuro. È stato definito per la prima volta dalla GoF ([[gangGang of Four (scrittori)|Gang of fourFour]]) 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'Incapsulamento in situazioni di [[Ereditarietà_Ereditarietà (informatica)|Ereditarietà]] fra [[Classe_informaticaClasse 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 [[Metodo_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 sovrascrivere il metodo( [[Override]] ) nella nuova. Questo però non è certo il modo più corretto per risolvere tale problema, poiché lascia libertà a chiunque utilizzi la classe madre di sovrascrivere il metodo virtual indiscriminatamente. Neanche ricorrere all'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_sharpC sharp|C#]], si vuole estendere il metodo ''drinkSomething'' della classe Guy. Qui di seguito è mostrata la soluzione con l'uso di una classe derivata.

<sourcesyntaxhighlight lang="csharp">

class Guy

{

Riga 39:

//...

}

</syntaxhighlight>

</source>

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

<sourcesyntaxhighlight lang="csharp">

class Gentleman

{

Riga 60:

//...

}

</syntaxhighlight>

</source>

== Collegamenti esterni ==

{{Design Patterns Patterns}}

[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}}

[[Categoria:Pattern]]

[[Categoria:Programmazione ad oggetti]]

<!-- Fumo -->

{{Portale|informatica}}

[[Categoria:PatternDesign pattern]]