subscribe: Posts | Comments

Apologia di Reactor

0 comments
Apologia di Reactor

I Design Pattern hanno rivoluzionato il modo di risolvere i problemi di programmazione. Ci fanno sentire un po’ meno Archimede e un po’ più Bravi Presentatori.

 

 

Drawings help people to work out intricate relationships between parts.
Christopher Alexander

 

Il Reactor è un Design Pattern, che poi è il tema di questo post. I Design Pattern sono ormai un argomento abusato tra i programmatori, categoria che mi piace continuare a definire così nonostante sia un termine ormai considerato troppo minimal. Sono strategie di soluzione preconfezionate per risolvere i principali problemi algoritmici. Esempi: voglio disaccoppiare la UI dalla logica, come faccio? Devo raggiungere un certo componente, ma per farlo devo passare da uno intermedio, e quindi? I Design Pattern forniscono una risposta (esatta) a tutte queste domande o almeno una risposta largamente condivisibile dai più, una risposta sempre politically correct. La leggenda narra che siano nati da uno spunto off topic: un architetto, Christopher Alexander, uno vero, di quelli che ti ristrutturano anche il monolocale, intendeva codificare modi standard per risolvere i problemi di progettazione edile più diffusi: un caffè, una piazza, un muretto a secco, un gabinetto radiologico ma anche no e tanti altri, e ne fece un volume.

Sempre la solita leggenda insiste nell’aggiungere che il prezioso scritto, per lo più rigettato dai suoi colleghi edili,perché ritenuto troppo manicheo e semplicistico, capitò tra le mani di un informatico da spiaggia, di quelli che anche in vacanza non riescono a staccare la spina; egli nutriva una vaga passione per l’architettura, concetto allora ancora puro ed associato solo a travi e murature. La lettura fu per lo più una folgorazione: pervaso da questa trance mistica, capì che poteva carpire un po’ del sacro fuoco contenuto in quel volume e usarlo per illuminare la fino ad allora angusta strada dei progettisti software, che amavano reinventare la ruota. Perché ristudiare ogni volta una soluzione agli stessi problemi informatici, magari mettendo a punto una soluzione errata? Perché arrivarci da solo, magari male, se qualcuno c’è già arrivato prima e, perché no, si paga il mutuo con i proventi dei diritti di un volume informatico sull’argomento? Da qui l’esplosione e il successo, soprattutto dopo l’uscita di un volume, per l’appunto, il clamoroso Design Patterns: Elements of Reusable Object-Oriented Software dei quattro formidabili Gamma, E., Helm, R., Johnson, R. e Vlissides, J (qui il link su Amazon), il primo ed unico tomo sacro sull’argomento.

È curioso notare quanto ora sia diventato a la mode, ma ricordo ancora quando, incuriosito adepto della prima ora dell’argomento, mi ritrovavo a fare proseliti tra i miei colleghi. Non che fossi necessariamente un esperto dell’argomento, ma semplicemente ne avevo almeno sentito parlare… Ora invece ne parlano tutti, compresi i manager, quelli che dalla slide fluente e dal gergo professional, tant’è che spadroneggia pure negli annunci di lavoro, tra i CSS e l’Agile, a volte senza soluzione di continuità e di logicità.

Questo essere diventato un argomento fashion non è bastato a farmeli piacere di meno e, anzi, il volume con dorsetto in brossura, elegante copertina rigida biancazzurra e doppio filetto segnalibro, continua elegantemente a campeggiare imperioso nella mia libreria, una sorta di Libro di Mormon per nerd. Certo, se fossi stato un medico, al suo posto ci sarebbe stato l’Anatomiadel Gray, oppure un bel manuale sull’Arte e lo Zen del cartongesso, come si richiede ad un operoso muratore; tutte cose assai più nobili ed utili, ma ciascuno ha sempre e solo quel che si merita. Che non sia anche questo un pattern?