Recensione di Implementation Patterns

Implementation Patterns CoverSono sicuro che da qualche parte sulla rete esiste il vademecum della recensione perfetta o un manuale per scrivere recensioni. Onestamente, preferisco raccontarvi il mio viaggio con il libro di Beck. Intanto una premessa: a partire dal cosiddetto Libro Bianco, ovvero “Extreme Programming Explained: Embrance Change” – prima edizione, ho letto tutti i libri che Beck ha pubblicato. Questo background mi ha sicuramente influenzato, ed è con queste lenti che bisogna approcciare la mia recensione di “Implementation Patterns”.

Beck è un grande comunicatore, questo è innegabile. Ha poi il dono di riuscire a rendere non banali temi che all’apparenza potrebbero sembrare di rilevanza minima. Negli ultimi anni però si è concentrato su aspetti che in qualche modo potremmo definire esoterici, o quantomeno un po’ ostici rispetto al practitioner di XP o al programmatore hardcore (penso innanzitutto a temi come appreciative inquiry) lasciando la discussione sugli aspetti più pratici di XP e TDD a decine di blogger ed esperti di vario tipo.
Il suo libro precedente incentrato sulla programmazione, “Test-Driven Development: By Example”, anche se godibile e fondamentale per coloro che vogliono iniziare un percorso di avvicinamento verso TDD, non ha la cristallina potenza di “XP Explained”. È anche in parte dovuto a ciò che molti, me compreso, avevano caricato di attesa e aspettative l’uscita di “Implementation Patterns”. In ultimo, questo libro avrebbe dovuto essere in realtà una versione riveduta e corretta per Java del più famoso “Smalltalk Best Practice Patterns”, uscito nel 1996, estremamente godibile e utile anche al di là del mondo smalltalk.

Il libro è strutturato in tre parti concettuali, o almeno così io l’ho letto:

  • i primi quattro capitoli gettano le basi teoriche, con il consueto cappello su valori e principi che costituisce il contesto nel quale Beck andrà a discutere i pattern (volendo spingere il paragone con il libro bianco, le pratiche sono costituite dai pattern stessi);
  • i successivi cinque capitoli (6-9) formano il corpo principale del libro, definendo 77 pattern di implementazione specificatamente relativi a classi, stati, comportamenti, metodi e collezioni;
  • i due capitoli finali (10 e appendice) forniscono due varianti sul tema, con considerazioni sull’evoluzione dei framework e un’esempio di implementazione di un mini framework sviluppato da Beck per misurare le diverse performance delle collezioni citate nel capitolo 9.

I più impazienti potranno essere portati a saltare a pie’ pari i primi quattro capitoli, o comunque a leggerli con superficialità. Ecco: questo sarebbe un errore, quantomeno per quanto riguarda i capitoli 3 e 4. Il primo, intitolato “A Theory of Programming”, parte dai valori (Communication, Simplicity, Flexibility) e arriva ai principi (Local Consequences, Minimize Repetition, Logic and Data Together, Symmetry, Declarative Expression, Rate of Change). Il lettore esperto riconoscerà in Local Consequences nient’altro che la nemesi della definizione di fragilità data da Robert Martin (aka Uncle Bob), mentre Logic and Data Together da una parte e Rate of Change dall’altra hanno a che fare con le basi del paradigma e del design OO (in particolare, incapsulazione e SRP). Minimize Repetition altro non è che una versione più edulcorata di DRY. Symmetry cattura bene e in modo più accettabile certi aspetti che taluni categorizzano nell’ambito controverso dell’estetica del codice (si veda a questo proposito il bellissimo “Beautiful Code”). In ultimo, Declarative Expression afferma il primato delle forme dichiarative rispetto a quelle imperative (primato discutibile, ne convengo, ma certe forme dichiarative hanno un’indubbia utilità in linguaggi altrimenti imperativi – un bell’esempio è costituito da Rake e dal DSL che definisce per il build di progetti ruby e non). Il capitolo successivo invece, chiamato “Motivation”, fornisce in modo molto semplice una giustificazione economica a tanta enfasi dedicata a comunicare attraverso il codice, rendere il codice espressivo. Nessuno si ricorda il capitolo sul pricing delle opzioni nel Libro Bianco? Niente paura, niente di così inafferrabile questa volta, ma al contempo il modello economico è forse un po’ troppo semplicistico e conosco dozzine di system integrators che fondano sul cowboy coding la propria ragion d’essere. In soldoni: è necessario dedicare tanta cura a come scrivere il codice inizialmente e nelle evoluzioni successive perché il costo in cui bisogna incorrere per mantenerlo è molto più elevato rispetto a quello speso per scriverlo in prima istanza. Ancora di più, il costo dedicato a leggere, interpretare, capire il codice e successivamente modificarlo è la misura più rilevante.

L’immagine linkata riassume i pattern in categorie e sottocategorie. Per i più intraprendenti metto anche a disposizione la mappa mentale in formato freemind. Le categorie corrispondono ai diversi capitoli e fin qui tutto bene. Le sottocategorie invece sono una mia invenzione: in teoria sarebbero dei pattern a se stanti, anche se definiti in modo talmente vago da essere quasi impalpabili. Di fatto introducono e raggruppano i pattern successivi, per cui io li considero delle sottocategorie vere e proprie. Purtroppo, a ciò non corrisponde una diversa caratterizzazione nella veste grafica, cosa che mi ha dato sui nervi più di una volta.

Mappa mentale Implementation Patterns

Tra i miei pattern preferiti ho voglia di citare Pluggable Selector, perché oltre a spiegare in poche righe come funziona il meccanismo di istanziazione di un plugin, contiene en passant una profonda verità che ho voglia di citare per intero: As with all code compression techniques, the modified code is only easy to read if you understand the “trick”.

Composed Method e Method Object costituiscono gli strumenti principe con cui ridurre la complessità di codice procedurale e iniziare a trasformarlo in codice OO. Il che mi porta alla mente un simpatico metodo Java lungo 1657 linee e con complessità ciclomatica pari a 349 che ho recentemente avuto per le mani. Evidentemente il suo autore non ha avuto modo di leggere “Implementation Patterns”.

Ovviamente non tutto quello che scrive Beck è condivisibile. Ad esempio, io trovo molto discutibile raccomandare di usare ‘I’ come prefisso per le interfacce: ciò rompe la leggibilità del codice che utilizza l’interfaccia in questione. Non solo, il codice dovrebbe essere scritto in modo tale che chi lo usa non faccia assunzione rispetto al codice target.

Il capitolo “Evolving Frameworks” offre alcuni spunti interessanti soprattutto per chi sviluppa framework che poi sono utilizzati da un’ampia base di utenti (ciò avviene spesso e volentieri anche all’interno della stessa azienda). Ovviamente la soluzione caldeggiata è quella di effettuare dei cambiamenti backward compatible o in alternativa fornendo dei meccanismi di adattamento del vecchio codice nella nuova struttura. Tra gli aspetti di cui Beck ci mette in guardia, l’abuso di classi final (quindi non estendibili) è sicuramente uno dei miei preferiti: più volte mi è capitato di vederlo manifestare all’interno di una stessa organizzazione e neanche per favorire l’evoluzione di un framework. Quando ciò si verifica siamo di fronte all’ennesimo esempio di programmazione eccessivamente difensiva, di inutile barriera al cambiamento che deve essere attentamente soppesata prima di essere messa in pratica.
Per motivi diversi, anche la parte riguardante le strategie di creazione di oggetti è molto interessante.

Il capitolo sulle collezioni è come un vinello bianco, frizzante e ghiacciato in una calda giornata d’agosto: va giù che è un piacere, senza lasciare traccia alcuna. Si tratta di informazioni arcinote, più che altro confronti sulle diverse collezioni a disposizione nel JDK. Male non fa e non escludo di riaprire il libro in quelle pagine il giorno in cui non mi ricordassi se la ricerca binaria è più veloce su ArrayList o LinkedList.

È un gran peccato che Beck non abbia messo a disposizione i sorgenti del mini framework che ha sviluppato per i benchmark. Li ho cercati per una decina di minuti tra google e forum vari e poi ho rinunciato (d’altronde se non trovi qualcosa tramite google in 10′ allora per definizione non esiste, giusto? 🙂 Se qualcuno di voi ha più fortuna può postare un link attraverso un commento). Allora me li sono semplicemente riscritti, integrando le parti mancanti come MethodTimer.computeTotalTime. È un esercizio utile, si arriva a capire e apprezzare il codice più in profondità. L’appendice è per certi versi uno dei capitoli più interessanti dell’intero libro perché Beck mostra cosa significa applicare in pratica i pattern appena esposti. In questo modo emergono semplicità e coesione del codice scritto seguendo armoniosamente questi pattern e chi di voi ha mai dato un occhio al codice di JUnit (cosa che tra l’altro raccomando caldamente) riconoscerà lo stile inconfondibile di Beck.

Tra il materiale a corredo segnalo:

  • un’intervista concessa a InfoQ il 25 gennaio 2008 (dove le parti non strettamente attinenti a “Implementation Patterns” sono probabilmente le più interessanti);
  • una civile discussione su Java Ranch nel corso di dicembre 2007;
  • due pattern aggiuntivi che Beck ha pubblicato a ottobre 2007 sul proprio sito (Nested Method Object e Conditional Factory);
  • un gruppo di discussione su Yahoo Groups che Beck ha creato ancora prima di pubblicare il libro (ma ormai il traffico si è praticamente azzerato);
  • ovviamente non siamo gli unici ad aver recensito il libro di Beck e sia InfoQ che Amazon riportano già diverse recensioni, ma nessuna è completa come la nostra! 😉

Volendo tirare le somme, questo libro ha un sapore agrodolce: ha sicuramente lasciato l’amaro in bocca ad alcuni ed entusiasmato altri. Che cosa aggiunge al materiale già disponibile in svariate forme e in diversi altri testi? Onestamente non molto. Detto ciò credo che “Implementation Patterns” sia un libro quantomeno discreto, anche per chi ha familiarità con gli idiomi propri del paradigma OO, TDD, refactoring, ecc. Di certo vale i soldi che costa. Se da un lato non posso negare il senso di delusione e incompletezza leggendolo, in gran parte influenzato dalle aspettative elevate che avevo, nonché gli aspetti snervanti segnalati prima, allo stesso modo ne riconosco il valore e non solo per il neofita: è un po’ come rinfrescarsi la memoria, un ricordare a se stessi le buone maniere di tanto in tanto. Se i programmatori, Java e non, leggessero e analizzassero in profondità questo libro, i principi che discute e le tecniche che suggerisce, il codice che scrivono non potrebbe che goderne.

Comments

  1. Kent infatti dice, in modo un po’ provocatorio, che questo è un libro di ‘comunicazione’ più che di informatica.
    Lo scopo infatti è insegnare a comunicare in modo più efficace attraverso il codice.
    PierG
    http://pierg.wordpress.com

  2. Grazie per la recensione, che fa sempre piacere, spero avrò modo di leggerlo al più presto

  3. Bella recensione, penso che voi di StackTrace dovreste/potreste realizzare una sezione apposita del sito con recensioni di libri dal carattare informatico (o anche altri…)!

  4. maelstrom: beh c’è un piccolo bug da sistemare,. poi in teoria dovrebbe bastare andare alla pagina del tag “recensione” 🙂
    Però non dire “voi” di stacktrace, tira fuori una recensione anche tu e passa alla prima persona plurale 😛

    Piergiuliano: dici che questo è una versione javosa di “Smalltalk Best Practice Patterns”..
    A tuo giudizio il testo rimane abbastanza generale da essere utile anche a chi non usa abitualmente questa piattaforma o è stato reso troppo specifico ?

  5. Mah, mentre “Smalltalk Best Practice Patterns” e’ un libro che puo’ aver senso leggere al di la’ del mondo smalltalk, secondo me “Implementation Patterns” mostra meno quel valore.

    Insomma, se non hai un interesse specifico per java penso che ne valga poco la pena.

  6. Innanzitutto, grande recensione!
    Mi hai fatto voglia di comprarmelo, se non altro per vedere se condivido le tue idee.
    A me sinceramente il fenomeno “Beck” ha sempre suscitato sentimenti contrastanti, se da un lato il libro bianco e’ stata una rivelazione, come pure altri suoi articoli su TDD e valori.
    Altre volte ho trovato i suoi toni piuttosto irritanti, piu’ da predicatore che da “guru” informatico. E sinceramente non mi pare la persona piu’ indicata per insegnare a me cosa e’ moralmente corretto (agitar…?).
    Comunque voglio leggerlo.

  7. @Uberto: grazie dei complimenti.

    Solo una nota su Beck: il personaggio e’ complesso e non e’ semplice catalogarlo e relegarlo nel suo posticino. Dal mio punto di vista, quello che dice merita sempre di essere vagliato per bene. Poi si puo’ comunque concludere che si tratta di una baggianata 🙂 ma per lo piu’ riesco a estrarre qualcosa di utile dai suoi libri, articoli, interventi, ecc.

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.