Certo, se si devono scrivere applicazioni che girano in ambito non gestito, magari di tipo real time, ci si trova nella necessità di eliminare tutto il superfluo perchè la focalizzazione è centrata sul tempo di risposta.

Ma, se l'obiettivo è quello di scrivere applicazioni object-oriented che girino in un ambito gestito (senza rischi di memory leak o affini), che demandino ad un ambiente di runtime la gestione della memoria, delle eccezioni e dei tipi, che siano facilmente manutenibili nel tempo, affidabili, facilmente debuggabili, estendibili da un punto di vista funzionale senza bagni di sangue inutili, scalabili sulle tecnologie e disaccoppiate da un punto di vista della object-orientation, la soluzione è quella di pensare ad una architettura che crei quell'astrazione necessaria a centrare le feature non funzionali elencate.

Nelle applicazioni enterprise e in quelle "tradizionali" non sono solamente le specifiche funzionali ad essere importanti, ma anche (e spesso soprattutto) le specifiche non funzionali. Insomma, non c'è solo il che cosa, ma anche il come!

Nel caso specifico, applicare il pattern abstract factory permette di creare disaccoppiamento per il particolare caso d'uso esposto nello script. Avremmo certamente potuto scrivere una soluzione simile anche in assembly o con un linguaggio per l'ambiente unmanaged, ma quale sarebbe stato il costo di una operazione del genere, a parità di requisiti funzionali e non? Ne vale sempre la pena?

Ciao, Ricky.