Polymorphic Rants

Spesso ci si arrabbia guardando il codice del proprio progetto e si pensa:
“che schifo !! ma come si può fare cose del genere ? solo in questo progetto si può trovare una cosa così!!”

ma poi, per fortuna (?), basta guardarsi attorno e si scopre che tutto il mondo è paese

Da poco lavoro su un progetto nuovo; qualche giorno fa, guardando i sorgenti mi sono imbattutto in:

< % if (false && !listDocumentB.getDomDocuments().isEmpty()) { %

uff !!! per fortuna...pensavo che solo nei miei vecchi progetti trovassero spazio queste perle!!!

Da qualche giorno sono possessore di un iPod Shuffle:

figo, vero ? )

512 Mb, che lo rendono un’ottimo pen-drive USB con aggiunta di musica portatile…un gran giocattolo !!!

Ho dovuto litigare parecchio perchè iTunes (installato su WinXP) lo riconoscesse: per non-si-sa-quale ragione sia l’Updater che iTunes non riconoscevano il gadget. Inizialmente ho pensato ad un problema della porta USB: il mio pc ha porte USB 1.1, quindi h comprato una scheda PCI con porte 2.0. Problema risolto ? per niente, la situazione non è cambiata di una virgola !!!!
Dopo una serie di installa/disinstalla, un qualche sortilegio è avvenuto ed ora tutto funziona…misteri della tecnologia.

Life is random !!

Ho appena terminato di leggere “Refactoring to Patterns” ed il giudizio è semplice: leggetelo. Dopo aver letto “Design Pattern” ho sempre avvertito un certo smarrimento riguardo i temi affrontati: il libro è complesso, va studiato più che letto e, probabilmente, lo studio deve essere accompagnato da approfondimenti con gente competente. Mi sono sempre reso conto che non ero riuscito a focalizzare qualche elemento di DP, che mi sfuggisse un mattoncino necessario all’impalcatura della gang of four.
Per “Refactoring” di Fowler non riuscivo invece a inquadrare la reale “forza d’urto” che le tecniche di refactoring offrono: cambio nomi qua e là , sposto qualche campo, miglioro la leggibilità ..ma poi ?

Leggendo il libro RtP questi dubbi sono scomparsi: gli esempi sono veri, non codice giocattolo che spesso non aiuta a capire ma anzi fa venire più dubbi del necessario. Il libro propone snippet di codice reale con errori che spesso si commettono: Kierievski mostra come rifattorizzare il codice fino a raggiungere la giusta soluzione. Il libro sottolinea continuamente come la rifattorizzazione verso un pattern non è la soluzione ad ogni problema (adesso rifattorizzo verso Strategy ed è fatto): insiste sulla necessità di comprendere se il pattern è la giusta soluzione, o se invece non basti implementare una soluzione meno complessa ma maggiormente adeguata al problema che si vuole risolvere.

Leggere questo libro credo sia importantissimo per chi, come me, usciva da DP e Refactoring con l’amaro in bocca: man mano che proseguivo nella lettura ho acquisito maggiore consapevolezza ed ho iniziato a rifattorizzare e a cercare di *ascoltare* sempre più il codice per capire quale design emergeva dal codice su cui lavoravo.

Insomma…cosa aspettate a comprarlo ??