Appunti riassuntivi Programmazione (parte 7, factory e linee guida)

Factory

=>

RIASSUNTO CAPITOLO 12 PROGRAMMAZIONE LIBRO

A volte può essere necessario istanziare diversi 3pi di ogge5 di classi derivate da

una classe base senza che il codice client sappia quali 3pologie precise di ogge5

sono sta3 crea3 a compile-3me.

Dunque, il codice client userà dei metodi polimorfici degli ogge5 così da poter usare

l’interfaccia definita dalla classe base senza dover conoscere i vari deCagli

implementa3vi.

Tale paCern prende il nome di Factory e può essere riassunto nel seguente modo:

1. Problema: vogliamo una classe che crei classi tra loro collegate in modo

polimorfico.

2. Contesto: ogni classe conosce quale versione delle classi collegate deve

creare.

3. Soluzione: si definisce un’interfaccia con metodi astra5 che le classi derivate

vanno a specializzare per creare le versioni specializzate delle classi collegate.

4. Conseguenze: i 3pi istanzia3 corrispondono ai 3pi che devono essere usa3.

Nel Factory avremo la presenza di una classe il cui scopo è quello di creare più

facilmente e ritornare istanze di altre classi; quindi, sostanzialmente, rende più

semplice creare ogge5 complessi dove l’uso del costruCore non è sufficiente. Infa5,

in questo paCern spesso si invoca un metodo della classe Factory al posto del

costruCore.

Come per gli altri due paCern, anche di questo ne esistono due versioni differen3: il

Factory Method e l’Abstract Factory a cui si aggiunge anche un altro paCern

creazionale che si u3lizza quando si vuole istanziare solo un oggeCo ossia il

Singleton.

- 4.1: Factory Method

Questo design paCern viene u3lizzato quando una classe non può an3cipare quali

ogge5 deve creare e delega alle sue classi derivate la specifica di quali ogge5

creare.

(LEGGI PARTE DIAGRAMMA UML E ESEMPIO DEL VIDEOGIOCO FATTO CON IL

FACTORY).

Il Factory method oltre a istanziare l’oggeCo provvede a prepararlo per renderlo

pronto all’uso impostandogli l’immagine da disegnare.

Per usare smart pointer al posto di raw pointer il Factory method usa unique_ptr

specializza3 per la classe base che ges3scono ogge5 di 3po derivato; in ques3 casi si

usa il polimorfismo dello smart pointer al posto del 3po di ritorno covariante.

Normalmente è più conveniente usare unique_ptr come 3po di smart pointer reso

da una Factory; questo perché se si usasse uno shared_ptr lo si userebbe dallo

unique_ptr con un costruCore sovraccaricato.

L’uso di uno shared_ptr ha, però, effe5vamente senso solo se la proprietà

dell’oggeCo creato dovesse essere condivisa con la factory.

In conclusione, si può dire che il seguente paCern è basato sul polimorfismo per

ridefinire nelle Factory la 3pologia di prodo5 da creare e per usare i prodo5 che

vengono istanzia3.

L’idea è quella di incapsulare i prodo5 così che venga rispeCato senza problemi

l’OCP (Open/Closed Principle) in modo che ques3 risul3no aper3 al cambiamento

ma chiusi alla modifica.

Allo stesso tempo il paCern segue anche il Principio di inversione della dipendenza

dato che le classi concrete di basso livello dipendono dalle interfacce e il codice

client è dipendente solo dalle astrazioni e non dalle implementazioni concrete.

- 4.2: abstract Factory

Lo scopo di questo Factory è quello di fornire un’interfaccia