Certo che no.

Il pattern factory è utile se hai bisogno di incapsulare il polimorfismo create-time dai consumatori, cioè, vuoi fornire un punto trasparente da cui vengono create nuove istanze di un tipo polimorfico.

Se il tipo in questione non è polimorfico, lo schema di fabbrica è inutile.

Se un singolo punto di creazione non ha senso, nemmeno lo schema di fabbrica.

Se non è desiderabile nascondere i dettagli del polimorfismo, anche il pattern factory è probabilmente inappropriato.

Come per qualsiasi altra cosa che aggiunge complessità, dovresti utilizzare per impostazione predefinita non ma individuare il punto in cui è utile all'inizio e applicarlo prima che sia troppo tardi.

Inoltre, considera questo: se usi una fabbrica per tutto, chi crea la fabbrica? Un'altra fabbrica? E chi crea questo ?

Non conosco molte persone che usano modelli di progettazione in PHP, ma Joshua Bloch raccomanda il modello Factory nel suo libro "Effective Java". In realtà, è la sua prima raccomandazione: elemento 1 . Ecco alcuni dei suoi punti specifici di Java, ma molto probabilmente si applicano a PHP:

vantaggi

• Come hai detto, un metodo factory può restituire qualsiasi sottotipo di oggetto
• A differenza dei costruttori, i metodi factory non sono necessari per creare un nuovo oggetto ogni volta che vengono richiamati, ciò consente di gestire internamente l'insieme di oggetti. Ad esempio, una classe di caratteri ASCII stampabile richiede sempre solo 95 istanze. Non hai bisogno di due oggetti per rappresentare una "k" minuscola.
• I metodi di produzione possono avere nomi significativi (in Java)

Svantaggi

• In Java, non puoi creare una sottoclasse se la classe genitore manca di un costruttore pubblico o protetto.
• I metodi di produzione statici non sono facilmente distinguibili da altri metodi statici. Bloch suggerisce uno schema di denominazione per distinguerli.

L'obiettivo alla base della maggior parte dei suggerimenti di Bloch è che se si invia la lezione al mondo e molte persone la usano, si desidera presentare un'interfaccia che consente di adattare e modificare l'implementazione delle classi senza infrangere il codice cliente . La prospettiva di Bloch si è formata cercando di correggere bug e difetti di progettazione nelle API Java senza cambiare l'interfaccia che presentano al mondo.

La tua domanda non risponde.

"Factory" è semplicemente troppo vago per essere chiamato pattern.

Se leggi nel libro Pattern Design di GoF, non esiste un modello "Factory".

Invece, ci sono diversi tipi di factory, che sono Factory Method e Abstract Factory. Diversi tipi di fabbrica stanno risolvendo diversi problemi. Dovresti sapere qual è il problema che stai cercando di risolvere, prima di decidere di voler adottare uno schema.

Quindi, dicci, quale problema vuoi risolvere?

Crea una classe static Factory .

Quella classe avrà metodi statici come questo:

public static class Factory{

    public static Vehicle getCarInstance(){ ... }
    public static Vehicle getPlaneInstance(){ ... }
    public static Vehicle getVehicleInstance(int TYPE){ ... }

    public static Vehicle getVehicleWithPlaqueNumber(String plaqueNo){...}

    public static Account getAccountByID(int ID){..}

}

Non hai bisogno di una fabbrica per ogni classe.