new e troppo potente
L'operatore new in PHP fa una cosa sola: crea un'istanza. Ma nel farlo, lega il codice chiamante alla classe concreta. Se domani CsrfService diventa un singleton, o ha bisogno di un parametro di configurazione, ogni punto che usa new CsrfService() deve cambiare. Il metodo statico CsrfService::make() incapsula la creazione: il chiamante dice "dammi un'istanza" senza preoccuparsi del come.
Il problema con new non e che non funziona — funziona benissimo. Il problema e che espone troppo. Quando scrivi new CsrfService(), stai dicendo: "so esattamente come si costruisce questo oggetto, e mi prendo la responsabilità di costruirlo correttamente". Ma questa responsabilità dovrebbe appartenere alla classe stessa, non a ogni punto del codice che la usa.
Il pattern make() in Soft PHP MVC
Questo pattern, adottato sistematicamente nel framework, ha un vantaggio sottile ma importante: centralizza la logica di istanziazione. Se EncryptionService::make() restituisce sempre la stessa istanza (singleton), il codice chiamante non lo sa e non deve saperlo. Se domani cambia strategia, cambia in un solo punto.
Dove viene usato nel framework
Il pattern make() e applicato in modo coerente attraverso l'intera codebase:
-
Service —
CsrfService::make(),EncryptionService::make(),SessionService::make(): servizi che potrebbero essere singleton -
Helper —
Seo::make(),JsonLd::make(): oggetti configurabili con valori di default -
DataLayer —
QueryBuilder::make(): oggetti che richiedono inizializzazione complessa -
CLI —
Input::make(),Output::make(): oggetti con dipendenze dall'ambiente runtime
La coerenza e fondamentale: quando vedi ::make(), sai che la classe gestisce la propria istanziazione. Non devi chiederti "ha bisogno di parametri?", "e un singleton?", "devo passare dipendenze?". La risposta e sempre: make() sa cosa fare.
make() vs new: quando scegliere cosa
Non e un pattern rivoluzionario — e un factory method al minimo. Ma la sua forza sta proprio nella semplicità: abbastanza semplice da usare ovunque, abbastanza flessibile da adattarsi quando le esigenze cambiano.
La regola nel framework e pragmatica: make() per le classi del framework con logica di istanziazione, new per i DTO, i value object e le classi senza stato. Un new ArticleData(title: '...', slug: '...') e perfettamente legittimo — non c'e logica da incapsulare. Ma new SessionService() nasconde il fatto che probabilmente dovrebbe esserci una sola istanza del servizio sessione nell'intera applicazione.
Il legame con il principio di inversione delle dipendenze
Il pattern make() e un passo intermedio verso l'inversione delle dipendenze (DIP). Non e un container DI completo — non c'e autowiring, non c'e binding di interfacce. Ma introduce il concetto fondamentale: il codice chiamante non deve sapere come si costruisce un oggetto. Quando e se il framework adottera un container DI, la transizione sara naturale perché il codice già non dipende da new.
