Game of Four: I Pattern del tennis

Nel 1995 venne pubblicato un libro dal titolo: Design Patterns: Elements of Reusable Object-Oriented Software. Per chi non ha dimestichezza con l’ingegneria del software, questo testo rappresenta la Bibbia degli ingegneri informatici. Il testo, scritto da 4 autori, tali Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides rivoluzionarò il modo di concepire il software, e di conseguenza l’informatica, stabilendo dei principi base da seguire per scrivere del “buon codice”. In sostanza gli autori sublimarono il l’idea di pattern che è alla base dell’ingegneria del software, il cui concetto, però, si estende a tutto lo scibile umano. Per pattern si intende, molto semplicisticamente, una soluzione, o meglio una guida per una soluzione ad un problema già posto in passato e conseguentemente risolto. In parole potere gli autori sintetizzarono dei metodi o insiemi di metodi da seguire nel caso in cui qualcuno si fosse trovato davanti ad un vecchio problema che qualcuno aveva avuto l’accortezza e la sagacia di risolvere. Oltre al canovaccio da seguire per risolvere il problema i 4 autori inquadrarono alcune strutture ricorrenti dei software già esistenti, schematizzandoli e dando loro un nome. Nome che doveva essere semplice e intuitivo.

Gli autori del libro diventarono famosi e ben presto fu attribuito loro un soprannome un po’ strano, un po’ equivoco, ossia: Gang of Four. La banda dei 4 propose 23 pattern, che furono la base per lo sviluppo del software da quel momento in avanti.

Volendo cambiare prospettiva, quali possono essere i pattern del tennis? Quali problemi, quali soluzioni e quali schemi ricorrenti è possibile trovare nello strano mondo del tennis. Più che problemi e relative soluzioni è possibile isolare degli schemi assimilabili ai pattern GoF che sintetizzano l’andamento di una stagione, o più in generale di un lungo periodo tennistico. Certamente il tennis è fatto di migliaia di variabili che è difficile inquadrare in degli schemi predefiniti. Ci sono troppi tornei e troppi tennisti perché questi rispecchino uno schema e si conformino a qualcosa che è determinato aprioristicamente. Però vogliamo fare uno sforzo e mettere sul piatto i pattern del tennis.

• Monopolio assoluto – Monarchy

Nel monopolio assoluto esiste uno e un solo tennista che domina la stagione e/o un periodo più lungo. E’ un pattern che si presenta molto raramente perché ci sono tanti fattori che possono ostacolare il monopolio di un solo giocatore, primo tra tutti la differenza di superficie e del gioco su una determinata superficie. Nonostante probabilisticamente questo pattern sia raro da trovare, ci sono degli esempi lampanti come Laver nel 1969, Rosewall nel 1962, oppure Tilden nel 1924-1925-1926. In tempi recenti forse solo la stagione 2015 di Djokovic rispecchia questo pattern

• Monopolio relativo – Commonwealth

Il secondo pattern è simile al primo, ma un po’ più morbido. Il monopolio di un tennista riguarda più del 50% del circuito, però il rimanente 50-x % è appannaggio di uno o diversi tennisti. E’ il caso classico del dominio di Federer datato 2005-2007. Massimo rendimento in tutte le superfici veloci e poi scettro ceduto a Nadal nello scorcio riguardante la parte di stagione dedicata alla terra battuta.

• Duopolio assoluto – Consuls

Nel duopolio assoluto solo 2 giocatori si dividono tutto il piatto e agli altri rimangono le briciole. E’ capitato poche volte nel corso della storia che si applicasse questo pattern. Il 2017 potrebbe rientrare in questa categoria, con Federer e Nadal a spartirsi tutti i titoli più importanti e tutti dietro. Anche il 2016 rispetta lo schema, anche se è molto diverso dal 2017. Nel 2016 c’è stata una prima parte di stagione tutta a favore di Djokovic e da Wimbledon in poi tutto a favore di Murray. Nel 2017 Nadal e Federer si sono alternati nel duopolio perfetto (quasi).

• Duopolio relativo – Tom & Jerry

Il duopolio relativo è una versione degenere del Commowealth. Le caratteristiche sono simili, solo che in questo caso 2 tennisti si spartiscono il bottino più grosso, ma subentra un 3° che raccoglie quello che rimane, che poi è una bella fetta della torta, ma non tanto grande da superare i 2 che gli stanno davanti. E’ il caso rarissimo del 1989 con Lendl padrone assoluto, con Becker vincitore di 2 Slam, uno in più di Ivan e con Chang 3° incomodo al Roland Garros.

• Tripolio – Triumvirate

Il tripolio, come è facile intuire, è quella configurazione in cui 3 giocatori si dividono tutti i tornei più importanti in maniera più o meno equa. E’ il caso del 1995 con Smpras, Agassi e Muster a spartirsi la torta.

• Oligopolio – Spartans

Nell’oligopolio i protagonisti della stagione e/o periodo sono più di 3, solitamente 4, e non più di 4. Se il numero supera il 4 si ha un caso di anarchy. E’ il caso nel 2003 con Federer, Agassi, Ferrero e Roddick protagonisti in scorci differenti di stagione.

• Anarchia relativa – Anarchy

Nell’Anarchy si capisce poco o niente, nel senso che esiste un tennista di riferimento, però a vincere sono lui e tanti altri, tutti diversi tra loro. E’ il caso del 2002 con Sampras ormai agli sgoccioli e tanti altri tennisti come Hewitt, Roddick, Federer a vincere i tornei importanti, ma con grandi sorprese come Johansson agli Australian Open e Albert Costa al Roland Garros.

• Anarchia totale – Hippie

Nella configurazione Hippie non si ha nessuna logica dominante. I tennisti si susseguono al numero 1 con un’elevata frequenza. Non c’è un tennista di riferimento e si naviga a vista. E’ il caso della WTA attuale e per certi versi il 2000 e il 2001 dell’ATP Tour.

Oltre ai pattern GoF per la progettazione di un buon software è opportuno seguire altri pattern, che non appartengono alla categoria dei famosi 23, ma sono più che altro delle linee guida da seguire per non commettere degli errori banali. Tutti questi sono racchiusi nella categoria chiamata GRASP (General Responsibility Assignment Software Patterns). I pattern GRASP sono 9, molti non si prestano bene al mondo del tennis perché sono specifici della programmazione orientata agli oggetti, ma 2 di essi sembrano fatti di proposito per l’affascinante mondo della racchetta. Nello specifico sono: High Coesion e Low Coupling.

• High Coesion

il principio base dell’alta coesione esplicato in maniera molto semplicistica ci dice che non bisogna sovraccaricare una classe di troppe operazioni. Se nella progettazione del software “un pezzo” fa troppo è opportuno delegare a classi correlate alcune sue funzioni. Questo è il classico caso in cui un solo tennista monopolizza il tennis, non solo in termini di risultati-record, ma soprattutto in termini mediatici. Nello specifico è opportuno spostare un po’ l’attenzione verso una nuova classe, che in questo caso sarebbe un altro tennista ,in modo tale che se crollasse quella più importante sarebbero garantiti almeno i servizi più importanti. Manco a dirlo, l’esempio lampante è quello di Federer e tutto quello che ne consegue.

• Low Coupling

Per low coupling o basso accoppiamento si intende quel principio che vuole che le classi non dipendano tra loro in maniera eccessiva. Se le chiamate da una all’altra e viceversa sono eccessive è opportuno crearne un’altra per rompere questa interdipendenza. Nel tennis l’alto accoppiamento è presente qualora una rivalità supera un certo limite soglia e i 2 membri di questa rivalità non possono fare a meno di pensare all’altro. E’ il caso del Fedal che in alcune occasioni è stato molto invasivo. L’assenza di Nadal o Federer faceva cambiare totalmente la percezione di quel torneo. Oppure poteva capitare che, essendo uno dei 2 fuori dalla top 2, che l’eventuale scontro si sarebbe consumato in semifinale e non in finale, evenenzia considerata inaccettabile. Dramma. Bene, il principio indica che i giocatori devono essere accoppiati,, ma non troppo.

…a questo punto rimane al lettore collocare le varie stagioni nei rispettivi pattern e/o inventarne di nuovi come accade quotidianamente nel mondo del software