Applicare alcuni principi Solid con Symfony

Antonio Turdo
2 min readJul 8, 2023

--

[Available also in English]

Di recente ho lavorato ad un progetto che richiede di trattare lo stesso problema utilizzando il servizio offerto da due vendor differenti. La logica di business è condivisa, ma alcuni dettagli implementativi dipendono dai formati utilizzati e dalle specifiche di ciascun vendor.

Un caso d’uso perfetto per applicare i principi Solid e della Clean Architecture. In particolare noi lo abbiamo fatto utilizzando Symfony e la sua implementazione della Dependency Injection.

Interfacce

Alcune interfacce definiscono i comportamenti che richiedono una diversa implementazione per i due vendor. Ciascuna interfaccia contiene metodi che operano sullo stesso concetto o che comunque lavorano nello stesso ambito. L’obiettivo è sempre quello di mantenere alta la coesione all’interno di un’interfaccia e basso l’accoppiamento tra le interfacce.

Inoltre, tutte le interfacce contengono un metodo statico che ritorna la stringa che identifica il vendor supportato.

Implementazione con Symfony

I servizi che implementano le interfacce appena discusse, specifici quindi per un particolare vendor, vengono taggati usando la chiave _instanceofnel file di configurazione.

I servizi che implementano la logica di business hanno tra le loro dipendenze uno o più Service Locator, un costrutto della Dependency Injection di Symfony, che permette di accedere ad un sottoinsieme dei servizi contenuti nel service container, in questo esempio quelli con uno specifico tag.

Noi lo utilizziamo per recuperare l’implementazione per uno specifico vendor, utilizzando la chiave ad esso corrispondente, tra tutte le implementazioni scritte per un particolare problema, formalizzato in una delle interfacce.

Solid principles applicati

Vediamo quali dei principi Solid abbiamo applicato con questa soluzione:

  • Open-closed principle: se ci fosse l’esigenza di supportare un nuovo vendor non dovrebbe essere necessario apportare modifiche alla logica di business, ma soltanto aggiungere le implementazioni delle interfacce per il nuovo vendor
  • Interface segregation principle: avendo spezzato i comportamenti in diverse interfacce, ogni servizio che implementa la logica di business utilizza soltanto le interfacce ed i relativi Service Locator di cui ha effettivamente bisogno
  • Dependency inversion principle: la nostra logica di business dipende da astrazioni, cioè dalle interfacce, e non esplicitamente dalle implementazioni per i vari vendor

Conclusioni

In questo breve articolo abbiamo visto come è possibile utilizzare i costrutti della Dependency Injection di Symfony, in particolare i tag ed i Service Locator, per applicare facilmente alcuni dei principi Solid, per rendere l’applicazione più elegante e più facile da manutenere.

--

--

No responses yet