Ne avevo già parlato in un precedente post,
ma provo ad illustrare altri aspetti che avevo ignorato.
Una delle cose che viene data per scontato in XP è che si sappia pensare ad oggetti che è un prerequisito per il simple design.
Ma cosa significa veramente?
Nella programmazione tradizionale o formale un oggetto è dato dai suoi dati (attributi) e i metodi che agiscono su tali dati.
Questo però porta ad un esplosione del numero di classi perché basta un solo dato diverso e devo creare una nuova classe.
L'idea centrale del pensare ad oggetti sono i comportamenti cioè la decomposizione di un problema avviene individuando i comportamenti
e assegnandoli agli oggetti.
Ad esempio: prendiamo una tigre e un gatto nella programmazione formale ho una classe unica e due istanze diverse con i valori degli attributi
diversi perché la tigre e il gatto hanno le stesse caratteristiche. Se pensiamo ad oggetti invece sono due classi diverse in quanto dalla tigre
mi aspetto che mi aggredisca mentre un gatto è un animale domestico e quindi hanno diversi comportamenti.
Un modo utile per scoprire gli oggetti adatti a risolvere un problema è quello della metafora, cioè cerco di capire se esiste un qualcosa di
analogo nel mondo reale che si mappa con il mio problema. Bisogna tenere presente che la metafora è un modello del problema e quindi ci possono
essere delle differenze.
Ad esempio supponiamo di voler realizzare un sito per cercare un volo tra due destinazioni. Una metafora potrebbe essere quella dell'agenzia di viaggio
a cui comunico dove voglio andare, in che data e mi viene fornito un catalogo con tutte le informazioni per poter scegliere il volo.
Seguendo la metafora posso iniziare a disegnare l'oggetto agenzia di viaggio a cui mando il messaggio forniscimi il catalogo e gli passo una richiesta.
A quel punto il risultato del messaggio puo' essere l'oggetto catalogo che contiene un elenco delle offerte e così via.
Il punto cruciale è provare a fare una simulazione mentale o facendosi aiutare dai colleghi dell'interazione tra i vari oggetti per capire se il modello
è adatto a risolvere la storia da realizzare. Quindi si ragiona nello spazio del problema o dominio e inizialmente si ignora la soluzione del problema, cioè la sua implementazione.
Una volta individuati gli oggetti si può inziare l'implementazione utilizzando il TDD; ricordandosi che non sempre ad un oggetto di dominio corrisponde
una classe, a volte puo' essere più di una a volte nessuna come nel caso in cui avessi creato, durante l'analisi, l'oggetto utente che fa la richiesta.
Per approfondire l'argomento consiglio la lettura del libro Object Thinking di David West (ringrazio
Matteo per la segnalazione). Mentre per gli effetti
sulla produttività usando il TDD consiglio la lettura del post Flipping the Bit
di Zio Bob.