PHP – Design Pattern Abstract Factory

6 Mag

Out Of Date Warning

Questo post è stato pubblicato più di 2 anni fa (il 6 maggio 2013). Le idee vanno avanti velocemente, le prospettive cambiano quindi i contenuti potrebbero non essere aggiornati. Ti prego di tenere in considerazione questo, e di verificare le informazioni tecniche presenti nell'articolo prima di farne affidamento per i tuoi scopi.

Si tratta sicuramente di uno dei design pattern fondamentali introdotti dalla GoF.
Come il factory method rientra nella categoria dei pattern creazionali, cioè tra i modelli che forniscono meccanismi per la creazione di oggetti.

Partecipanti

  • AbstractFactory: Dichiara l’interfaccia per i metodi che creano i prodotti astratti.
  • ConcreteFactory: Implementa l’interfaccia AbstractFactory per creare i prodotti concreti.
  • AbstractProduct: Dichiara l’interfaccia per un tipo di oggetto prodotto.
  • ConcreteProduct: Implementa l’interfaccia AbstractProduct e definisce l’oggetto prodotto che deve essere creato dalla factory concreta corrispondente (ConcreteFactory).
  • Client: Utilizza solo le interfacce dichiarate da AbstractFactory e AbstractProduct.

Riassumendo, la responsabilità della creazione dei prodotti (ConcreteProduct) è dei ConcreteFactory, mentre AbstractFactory funge soltanto da interfaccia per questi.

Struttura

Abstract Factory

Obiettivo

Supponiamo che abbiamo varie famiglie di prodotti… il nostro scopo sarà quello di sostituire facilmente una famiglia con un’altra evitando una chiamata esplicita ai costruttori delle classi prodotto.
Possiamo raggiungere tale obiettivo rendendo astratto il processo di creazione degli oggetti.
Prendiamo in considerazione il diagramma del pattern, ci sono due famiglie di prodotti la famiglia1 (ProductA1 e ProductB1) e la famiglia2 (ProductA2 e ProductB2).
Il nostro obiettivo quindi sarà quello, previa configurazione del sistema con una famiglia prodotto, di renderlo indipendente da come gli oggetti vengono creati.

AbstractFactory

Rappresenta l’interfaccia utilizzata dai client per creare i prodotti concreti.
I client utilizzeranno questa interfaccia per creare famiglie di oggetti connessi tra loro in modo che non gli venga richiesto di specificare esplicitamente il nome delle classi concrete all’interno del proprio codice.

ConcreteFactory

Implementano l’interfaccia AbstractFactory e servono per creare i prodotti concreti. Ogni ConcreteFactory sarà responsabile della creazione di una famiglia di prodotti ed avrà tanti metodi quanti sono i prodotti concreti da creare.

AbstractProduct

Dichiara l’interfaccia per i prodotti concreti. I client utilizzeranno questa interfaccia indipendentemente dalla famiglia di prodotto con cui stiamo lavorando.

ConcreteProduct

Rappresenta un prodotto concreto, cioè l’oggetto che abbiamo bisogno di istanziare attraverso le fabbriche. Naturalmente ogni ConcreteProduct dovrà implementare l’interfaccia AbstractProduct corrispondente.

Client

Infine vediamo come il client utilizzerà questa struttura.
Come detto il nostro obiettivo sarà quello di rendere il sistema indipendente dalla creazione degli oggetti (prodotti) al fine permettere un’agile sostituzione di una famiglia di prodotti con un’altra.

L’esempio, anche se completamente privo di senso, ci dimostra come sia semplice passare da una famiglia ad un’altra, e come per il client non faccia nessuna distinzione la creazione di un oggetto sia quello di una famiglia piuttosto che di un’altra.
Senza il pattern se avessimo voluto creare il prodottoA della famiglia1 avremmo utilizzato il seguente codice:

Questo è proprio quello che vogliamo evitare, al fine di minimizzare la dipendenza con un particolare tipo di famiglia.
Con il nostro approccio:

abbiamo evitato la chiamata diretta al costruttore di ProductA1 ottenendo lo stesso risultato ma con una differenza sostanziale.
L’oggetto factory astrae completamente il processo di creazione non solo del prodotto A della famiglia1, ma per qualsiasi prodotto A, di qualsiasi famiglia.
Non solo, factory non è limitata al prodotto A ma può gestire la creazione dell’intero set di prodotti.
Possiamo raggiungere questo risultato grazie al fatto che factory implementa l’interfaccia AbstractFactory. AbstractFactory implementa difatti tutti i metodi necessari alla creazione delle diverse tipologie di prodotto (createProductA(), createProductB()).

Quando e come istanziare la fabbrica?

Una delle domande ricorrenti circa questo pattern è quella di stabilire in che punto dobbiamo istanziare la factory concreta. Quelli della banda dei quattro suggeriscono l’utilizzo del pattern singleton di modo da avere una sola istanza della fabbrica condivisa tra gli ambienti che la utilizzano.
Tuttavia nel corso degli anni abbiamo imparato come il pattern singleton sia considerato una cattiva pratica e possibilmente da evitare.
Quindi la risposta è: dipende dal contesto. Tuttavia deve essere fatto ragionevolmente presto e comunque prima che il programma abbia bisogno di usarla per la creazione dei prodotti.

Conclusioni

Il pattern Abstract Factory è un modello creazionale, utilizzato per costruire oggetti.
Tutti i linguaggi OO hanno un idioma per la creazione di oggetti. In PHP l’idioma è l’operatore new.
I pattern creazionali ci permettono di scrivere metodi che creano nuovi oggetti senza utilizzare esplicitamente tale operatore.
Questo ci porta ad uno dei principali vantaggi del pattern, e cioè che il client è totalmente disaccoppiato dai prodotti concreti.

Una volta inizializzata la fabbrica, saremo sicuri che l’applicazione sarà in grado di creare gli oggetti (prodotti) appropriati senza bisogno di modifiche.

Inoltre, possono essere aggiunte facilmente al sistema nuove famiglie di prodotti, semplicemente aggiungendo un nuovo tipo di ConcreteFactory che implementa AbstractFactory, e creando le specifiche implementazioni del prodotto.

Anche il factory method è un pattern avente come obiettivo la creazione di prodotti tuttavia l’abstract factory è particolarmente indicato quando il sistema deve creare più famiglie di prodotti, di cui ne sarà utilizzata solo una alla volta.

3 Commenti su “PHP – Design Pattern Abstract Factory”

  1. thor 17 giugno 2013 at 17:14 #

    Ciao,
    ti volevo ringraziare per tutti gli articoli sui design pattern che hai scritto e poi volevo farti una domanda e se puoi magari darmi un consiglio, se ti dicessi che conosco abbastanza bene i design patter e so anche implementarli ma sono incapace di capire dove e quando applicarli, cosa mi manca?
    Dici che è una questione ingegneristica? da premettere che ho sempre studiato informatica e programmazione da autodidatta e lo faccio tuttora. Mi sapresti dare un consiglio su cosa approfondire o cosa studiare?
    grazie

    • grimax 17 giugno 2013 at 19:46 #

      Ciao thor,
      non ti preoccupare, il quando è perchè applicare un design pattern è sicuramente la parte + difficile da comprendere ed assimilare.
      Anch’io ho avuto (ed in parte ho ancora) le tue stesse difficoltà. Il consiglio che ti posso dare è che è meglio leggersi i libri “cult” in materia, anche se non sono (mai) scritti per il PHP. Dammi retta… eppure io non programmo in Java o C++.
      Se non lo hai già fatto, ti consiglio di partire con la “Bibbia”, anche se datato è imperdibile:
      Design Patterns – Elementi per il riuso di software ad oggetti.
      Qua trovi la versione italiana:
      http://www.hoepli.it/libro/design-patterns/9788871921501.html
      i primi 2 capitoli sono illuminanti (io mi sono ispirato molto per i miei articoli).

      Ti consiglio poi letture di Martin Fowler e Robert C. Martin che parlano di design pattern con un’ottica + moderna.
      Buone letture 😉

  2. thor 17 giugno 2013 at 23:08 #

    Va bene grazie, per ora penso che darò un occhiata al primo libro poi controllerò i libri di quei altri due autori.
    ciao a presto 🙂

Lascia un commento