Factory method: differenze tra le versioni

Versione delle 16:11, 23 mar 2022

Versione attuale delle 07:36, 6 giu 2025

(2 versioni intermedie di 2 utenti non mostrate)

Riga 2:

[[File:Factory Method pattern in LePUS3.png|thumb|upright=1.4|Schema logico del Factory method in [[LePUS3]]]]

Nella [[Programmazione orientata agli oggetti|programmazione ad oggetti]], il '''Factoryfactory Methodmethod''' è uno dei [[design pattern]] fondamentali per l'implementazione del concetto di [[factory (informatica)|factory]]. Come altri [[pattern creazionali]], esso indirizza il problema della creazione di [[oggetto (informatica)|oggetti]] senza specificarne l'esatta [[classe (informatica)|classe]]. Questo pattern raggiunge il suo scopo fornendo un'[[interfaccia (informatica)|interfaccia]] per creare un oggetto, ma lascia che le sottoclassi decidano quale oggetto istanziare.<ref>[[Design Patterns|Gang Of Four]]</ref>

La creazione di un oggetto può, spesso, richiedere processi complessi la cui collocazione all'interno della classe di composizione potrebbe non essere appropriata. Esso può, inoltre, comportare la duplicazione di codice, richiedere informazioni non accessibili alla classe di composizione, o non provvedere un sufficiente livello di [[astrazione (informatica)|astrazione]]. Il '''factory method''' indirizza questi problemi definendo un [[metodo (informatica)|metodo]] separato per la creazione degli oggetti; tale metodo può essere ridefinito dalle sottoclassi per definire il tipo derivato di prodotto che verrà effettivamente creato.

== Applicabilità ==

Riga 41:

</syntaxhighlight>

Nel codice summenzionato, il costruttore <code>MazeGame</code> è un [[template]] che fornisce della logica comune e fa riferimento al metodo factory <code>makeRoom</code> che incapsula la logica di creazione delle stanza in modo che le stanze possano essere utilizzate nelle sottoclassi. Per implementare l'altra modalità di gioco, infatti, è necessario solo ridefinire <code>makeRoom</code> per l'implementazione delle stanze magiche:

<syntaxhighlight lang=Java>

Riga 283:

Ci sono tre limitazioni, all'uso di questo metodo. Il primo è relativo al [[refactoring]], gli altri due sono relativi all'estensione di classi.

* La prima limitazione consiste nel fatto che il ''refactoring'' di una classe esistente causa il malfunzionamento dei [[client]] esistenti.

* La seconda limitazione è dovuta al fatto che, poiché il pattern si basa sull'uso di costruttori privati, la classe non può essere estesa. Ogni sottoclasse dovrebbe invocare il costruttore ereditato, ma non può farlo perché quest'ultimo è privato.

* La terza limitazione è dovuta al fatto che, se estendiamo una classe (ad esempio rendendo il costruttore 'protected'; rischioso ma possibile), le sottoclassi devono precedere la reimplementazione di tutti i metodi di ''factory'' con la stessa dichiarazione. La possibilità, fornita da alcuni linguaggi, di usare le classi ''reflection'' può, tuttavia, risolvere questo problema.

Riga 296:

{{interprogetto|commons=Factory method}}

{{Design Patterns patternspattern}}

{{Portale|informatica}}