Polymorphic Rants

Alcuni giorni fa Apple ha presentato il nuovo modello di iPod, l’iPod Nano: ho il sospetto che sarà il gadget tecnologico più richiesto dei prossimi 2 anni…qualcuno ne dubita ?!?

Una frase sentita da Francesco Cirillo durante una sessione della Java Conference ‘05 sta cambiando il mio modo di lavorare : “Object Oriented è dinamicità “.

Non ci interessano le strutture dati statiche, ci interessano i comportamenti dinamici degli oggetti che individuiamo tramite astrazioni dal nostro sistema.

Anche se questa frase può sembrare scontata, in pratica non la è: si parte sempre nel disegnare oggetti ragionando su “quali dati rappresentano” e non su “che tipo di comportamento hanno”, e questo porta ad uno scarso design (se non del tutto assente). Partendo invece dai comportamenti che individuiamo dalle nostre astrazioni, i dati sono una conseguenza.

Sto provando ad utilizzare questo approccio sul progetto su cui sto lavorando e sono molto contento dei risultati;il design infatti emerge dai nostri oggetti in modo naturale, le gerarchie rispettano i principi base del design e si creano architetture semplici da mantenere.

Il rovescio della medaglia è che mi risulta ancora più difficile di prima stimare dei tempi di sviluppo !!!! I comportamenti spesso emergono man mano che si porta avanti lo sviluppo, e quindi i tempi si possono dilatare improvvisamente, con il sommo scontento dei manager che seguono il dogma:

stima rispettata: bene
stima non rispettata: molto male

non prendendo in considerazione le infinite sfumature che il design e sviluppo del software comporta.

In questo ottimo White Paper del Cutter Consortium, vengono presentati le obiezioni che generalmente i senior executive fanno all’utilizzo dei metodi agili nelle aziende. Io sono assolutamente a favore dei metodi agili, e devo dire che questo paper affronta con precisione le lamentele più comuni. La lettura è assolutamente consigliata sia per chi è scettico nei confronti di queste metodi, sia per chi è favorevole all’agilità nel mondo IT.

In Italia, purtroppo, le obiezioni verso i metodi agili sono spesso dettate da non-conoscenza degli stessi e scarsa competenza (guai a spostarsi da un waterfall applicato male!!), ma questo è un altro discorso..o sbaglio ??

Sul blog di Robert Martin Micah Martin commenta lo standard C# di usare una I come prefisso delle interfacce. Micah sostiene che questo è un errore, perchè a fronte dell’evoluzione che le classi avranno nel tempo questa convenzione tenderà a scomparire (ad esempio l’interfaccia evolve in una classe astratta), causando indesiderati problemi nella manutenzione del codice stesso (tutte le classi che saranno rinominato dovranno essere cancellate dal CVS e ricreate nello stesso!).

Avevamo già discusso se quanto è il caso di acquisire degli standard sui nomi in un altro post, dopo aver letto un intervista ad Erich Gamma (non l’ultimo arrivato) sul team di sviluppo di Eclipse.

I due punti di vista sono in assoluto contrasto, e dimostra come forse non esista un’opinione comune anche fra i personaggi più rappresentativi del mondo Object-Oriented.

Personalmente continuo a cercare di limitare l’utilizzo di prefissi e suffissi, perchè preferisco concentrare i miei sforzi nel trovare il nome giusto ad una classe. E’ però vero che spesso il prefisso sulle interfacce è una degli elementi più utili: se da un punto di vista di logica di classe client è indifferente, da un punto di vista di sviluppo riconoscere subito che stiamo lavorando con un’interfaccia può indubbiamente aiutare molto.

Insomma, il dibattito è tutt’altro che chiuso ? e voi siete a favore o contro le I ?