Template Method

Nella vita si sa, gran maestra è l’esperienza. Molto spesso è lo scontrarsi coi problemi e le avversità che si incontrano che ci insegna come poter affrontare quest’ultime nel miglior modo possibile, imparando a superarle, di volta in volta, in maniera sempre più semplice ed immediata.
E difatti è d’uso comune individuare la saggezza e l’esperienza solo in persone non più giovani ma con un bagaglio di esperienze notevoli sulle spalle. E che c’entra tutto ciò con questo post, e con il tema generale di questo blog? In fondo c’entra qualcosa (o almeno la mia testa mi fa’ pensare così… J ) Difatti nella dissertazione filosofico-sociale di sopra c’è una piccola omissione voluta che forse riuscirebbe a far diventare “saggio” anche una persona non proprio anziana. Tale “segreto” è, banalmente l’arte di saper copiare!?! Affrontare un problema riuscendo a trovarne la soluzione semplicemente copiando la soluzione migliore con cui, altra gente, l’ha affrontato in precedenza.
Ma ancora: che c’entra tutto ciò con questo post, e con il tema generale di questo blog?
Ok! andiamo sul concreto. Supponiamo di avere una nostra applicazione e ammettiamo che questa riesca a risolvere un determinato caso d’uso “U.C. – 1” mediante la classe A in linea con le business-rules di progetto. Un giorno, in fase di revisione progettuale, si supponga che venga inserito un nuovo caso d’uso “U.C. – 2” che sia, in pratica, molto simile all’ “U.C. – 1” nella definizione e nelle funzionalità a meno di qualche pre-conditizione e post-condizione aggiuntiva. Schematizzando con un diagramma a blocchi potremmo vedere la cose nei termini sotto proposti:

intendendo la relazione tra la Business Rule 1 e la 2 come un’estensione della 2 rispetto all’originale con l’aggiunta di una nuova funzionalità “x”.

A questo scendendo più sulla pratica, ci chiediamo come risolvere, in termini di codice, la problematica proposta? La cosa più immediata sarebbe copiare la classe A rinominarla in classe B ed inserire i blocchi di codice che soddisfano la funzionalità “x” così da risolvere la faccenda in maniera rapida e praticamente indolore.

Ma, ovviamente, così facendo si incorrerebbe nell’errore di duplicare codice sorgente con l’enorme svantaggio della scarsa manutenibilità del software (se in futuro si dovesse andare a modificare qualcosa in una delle due classi dovrà esser fatto inevitabilmente anche sull’altra).

Un soluzione estremamente più funzionale ed elegante potrebbe essere quella mostrata successivamente:

In questo caso nella classe A viene aggiunto un metodo X con lo scopo di risolvere la funzionalità “x”; tale metodo sarà definito di tipo virtual e potrà essere sovrascritto da classi che ereditano dalla quest’ultima.

La classe B, a questo punto, altro non dovrà fare che ereditare dalla classe A ed implementare il metodo X così come mostrato sotto :Così facendo si è riusciti a risolvere la problematica originale mantenendo immutata la struttura del codice e inserendo solo le righe di codice riferenti alla risoluzione della nuova funzionalità richiesta in fase di revisione di progetto.

L’enorme vantaggio è la riusabilità del codice scritto (che talaltro sarà probabilmente composto da poche righe) e la sua manutenibilità e comprensione.

Ciò che in pratica è stato fatto in questo caso è stato applicare il Template Method uno dei design pattern architetturali fondamentali della programmazione ad oggetti; la base per la reale comprensione del fine vero della programmazione ad oggetti.

A mio parere, oggi, sempre di più si tende a scrivere righe di codice senza, permettetemi, sapere programmare. Che l’esito immediato sia poi lo stesso (cioè il programma in ogni caso farà qualcosa) non è una giustificazione a questo modo di operare. E da qui, quindi, che mi sento di suggerire a quanti volessero cominciare a programmare e scrivere del buon software di studiare e far proprie quelle che sono le vere fondamenta della programmazione ad oggetti.

Ecco il significato dello sproloquio iniziale. Se altra gente ha già affrontato problemi analoghi, li ha studiati, li ha risolti e ha messo a disposizione per altri le logiche di risoluzione, perché non far proprie queste conoscenze (o parte di esse) e diventare dei veri sviluppatori e scrivere del buon codice e, non ultimo, sviluppare dei buoni programmi? Ai posteri l’ardua sentenza…

OSS. 1 : Nell’esempio ho utilizzato codice in sintassi C#, ma i pattern, ovviamente, vanno bene con qualsiasi altro linguaggio di programmazione.

OSS. 2 : Lo spunto per questo articolo mi è venuto dopo aver affrontato un’analoga situazione a quella riportata nel progetto sul quale sto lavorando attualmente. Quindi i pattern architetturali non sono solo teoria…