Pattern Strategy

Summary Un design pattern che incapsula una famiglia di algoritmi in classi rendendoli tra loro intercambiabili.

Conosciuto anche come

Policy.

Intento

Il design pattern Strategy incapsula una famiglia di algoritm in una famiglia (Strategy) di classi (ConcreteStrategyA, ConcreteStrategyB, ...) rendendoli intercambiabili in base alla situazione (Context). La scelta di quale algoritmo della famiglia utilizzare è determinata dal contesto in cui viene impiegato (Context) poi l'utilizzo di un algoritmo piuttosto che l'altro è del tutto trasparente.

La classe (ConcreteStrategyA, ConcreteStrategyB, ...) che determina l'algoritmo impiegato è stabilita a run-time quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Comportamentali.

Diagramma UML

Un'altro diagramma equivalente qui .

Motivazione

Questo design pattern può essere usato quando:

Esistono diverse varianti di un algoritmo implementate come una gerarchia di classi, il design pattern Strategy permette di scegliere di volta in volta l'algoritmo più adatto alla circostanza.
Una classe definisce molti comportamenti che di volta in volta vengono scelti testando delle condizioni con If, questa scelta può essere fattorizzata nelle diverse classi di algoritmi (ConcreteStrategyA, ConcreteStrategyB, ...) da cui selezionarne uno.

Esempi d'uso in .NET

Le classi Array e ArrayList (per i metodi BinarySearch e Sort) SortedList (per l'ordinamento degli elementi), HashTable, ListDictionary e NameValueCollection (per stabilire l'uguaglianza tra 2 chiavi) che utilizza un criterio di confronto definito dagli elementi della lista che può essere sostituito indicando un diverso criterio ordinamento definito in una classe che implementa IComparer (Strategy).

La nuova Membership API di ASP.NET 2.0 utilizza il design pattern Strategy per permettere di selezionare diversi algoritmi (provider) attraverso cui persistere e recuperare tamto gli utenti quanto i ruoli.

Note sulla implementazione in .NET

La scelta dell'algoritmo può essere fatta sia a run-time che a install-time quando il software viene configurato e di conseguenza modificati i . config.

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Le classi degli algoritmi ConcreteStrategyA, ConcreteStrategyB, etc. sono dei buoni candidati per applicare il PatternFlyweight.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Il design pattern Strategy può essere usato anche quando esistono più classi simili che differiscono solo in un loro comportamento, il design pattern Strategy permette di creare una sola classe (Context) e i diversi comportamenti (ConcreteStrategyA, ConcreteStrategyB, ...).

Inoltre quando un comportamento o un algoritmo (ConcreteStrategyA, ConcreteStrategyB, ...) utilizza dei dati di cui l'utilizzatore (Client) desidera non occuparsene, il design pattern Strategy permette di nascondere all'utilizzzatore la complessità dell'algoritmo, della sua scelta, dei dati di cui l'algoritmo ha bisogno (in Context).

Il design pattern Strategy usa una RelazioneDiContenimento nei confronti dell'algoritmo prescelto in alternativa ad una RelazioneDiEreditarietà quindi permette di selezionare l'algoritmo a run-time e anche di utilizzare nuovi algoritmi individuati dinamicamente a run-time (cosa non possibile con l'ereditarietà).

Domande di approfondimento

Cosa accade quando c'è un'esplosione di classi ConcreteStartegy per ridurne il numero?
Se i dati necessari all'algoritmo con sono disponibili in Context, come è possibile rimediare a questo problema?

Link

VediAnche CatalogoDeiDesignPattern