ISBN: 0596008678
Autori: Brett D. McLaughlin, Gary Pollice, David West
Editore: O'Reilly
Lingua: Inglese
Anno: 2006
Pagine: 600
Allegati: Nessuno

Questo libro di O'Reilly tratta dell'analisi e progettazione orientata agli oggetti; lo fa con un taglio, usuale per la serie Head First, molto pratico, riportando tanti esempi (non troppo semplici né troppo complessi) e mostrando "con mano" come una soluzione poco object-oriented possa divenire una soluzione dal design appropriato. In pratica il libro è molto più adatto a chi proviene dalla programmazione imperativa tradizionale (che del resto avviene per gran parte delle persone!) piuttosto che a chi si avvicina alla programmazione per la prima volta e vuole scoprire la metodologia orientata agli oggetti.

Il libro presuppone la conoscenza di un linguaggio object-oriented. Benché gli autori indichino la conoscenza di C# come una possibile alternativa tra i requisiti per comprendere il libro, credo che almeno una infarinatura del linguaggio Java e delle sue caratteristiche sia fondamentale prima di affrontare questo testo. Infatti gli esempi e le soluzioni applicative proposti sono tutti realizzati con Java.

La prima parte del testo è introduttiva; in essa si mostra come lo sviluppo di un qualsiasi software debba, nell'ordine, procedere come segue:

1. assicurarsi che il software faccia quello per cui è pensato, o meglio, quello che il cliente, chiunque esso sia, vuole che faccia;
2. applicare i principi object-oriented per aggiungere flessibilità;
3. applicare pattern e principi per garantire la buona manutenibilità grazie ad un design riusabile.

In tutto il primo capitolo vengono analizzati i singoli punti utilizzando un'applicazione di esempio e mostrando come essa evolve per soddisfare, nell'ordine, i passi sopraindicati. Il tutto creando l'applicazione e classi di test per verificare il suo funzionamento e mostrando come, una volta che il software funziona, si possa modificarlo, affinché il suo design sia "migliore" (e viene spiegato in che senso il software possa migliorare). Chiaramente il capitolo introduce i concetti cardine, che verranno poi analizzati in maggior dettaglio nel prosieguo del libro.

Già nel secondo capitolo, si procede a dettagliare come capire cosa davvero voglia il cliente. Si parte dai requisiti per una nuova applicazione, si creano una classe base e la sua classe di test e si mostra come il software, che potrebbe essere finito, in realtà possa non soddisfare il cliente. Il resto del capitolo ci spinge a concentrarci su come chiarire (con il cliente) i requisiti e conoscere i requisiti non espliciti (che è compito dell'analista far emergere), tralasciando per un attimo tutta la parte di sviluppo e codifica; si introduce così il concetto dei casi d'uso (use case).

Una volta che il progetto è funzionante e rispetta i requisiti del cliente, il libro ci ricorda un'amara verità dello sviluppo software: i requisiti cambiano! Nel terzo capitolo viene illustrato cosa accade all'applicazione di esempio al verificarsi di questa possibilità, purtroppo per nulla remota; gli impatti sul design dei cambiamenti dei requisiti saranno analizzati invece nel capitolo cinque del libro, dove si mostrerà come il design stesso possa aiutare o meno il cambiamento.

Il libro prosegue mostrando, nel capitolo quattro, come, da una serie di buoni use case, sia possibile derivare nomi corretti per le classi. Per comprendere come derivare i nomi si introduce l'analisi testuale sui concetti chiave del dominio applicativo. Come anticipato, nel capitolo cinque si vede come si possa minimizzare l'impatto del cambiamento dei requisiti. In questo contesto vengono introdotti i concetti di incapsulamento delle informazioni, uso di interfacce, suddivisione delle responsabilità e si spiega come tutto questo porti a creare certe classi e non altre.

Nei capitoli sei e sette si parla di come affrontare progetti complessi. Nel capitolo sei si mostra come suddividere il problema iniziale in numerosi pezzi funzionalmente isolati e affrontare l'analisi di ciascuno essi, uno alla volta, per gestire la complessità. Prima di farlo però si spiega come sia fondamentale avere una chiara visione delle caratteristiche desiderate (feature) che il cliente si aspetta dal sistema e di quali siano i requisiti - cioè "specifiche" derivate dalle caratteristiche desiderate - i cui destinatari sono gli sviluppatori. Il libro introduce, in questo contesto, i concetti di domain analysis e use case diagrams; segue il concetto di information hiding, così importante nella programmazione object-oriented. Il capitolo si conclude mostrando come, al termine di queste fasi, si possano applicare i design pattern per strutturare opportunamente la soluzione trovata. Il libro analizza un esempio in cui è possibile applicare il design pattern MVC, ma non approfondisce oltre i design pattern, rimandando invece ad un altro libro della collana: Head First Design Patterns.

Nel settimo capitolo si mostra come ordinare i diversi pezzi del sistema derivati dalla scomposizione mostrata nel capitolo precedente, cercando di creare un'architettura applicativa appropriata. In questo caso per architettura si intende la progettazione strutturale, l'evidenziazione delle parti importanti e la definizione di appropriate relazioni tra queste parti. Il testo spiega, con un esempio, come questa analisi porti ad una appropriata gerarchia tra le classi, che grazie all'ereditarietà, permette di fattorizzare le parti comuni.

Nel capitolo otto c'è spazio per alcuni principi:

• open-closed principle: le classi dovrebbero essere aperte per l'estensione, ma chiuse per le modifiche, ovvero non permettere di modificare il comportamento esistente, ma permettere la sua estensione grazie all'ereditarietà e all'overriding o all'overloading dei metodi.
• Don't Repeat Yourself Principle: evitare codice duplicato astraendo le parti comuni e mettendole in un'unica posizione.
• Single Responsibility Principle: tutti gli oggetti del sistema dovrebbero avere un'unica responsabilità; inoltre tutti i servizi dell'oggetto dovrebbero essere orientati a esporre tale unica funzionalità.
• Liskov Substitution Principle: tutti i sottotipi - classi che ereditano da una classe base - devono poter essere sostituibili ai tipi base.

Infine vengono mostrati i concetti di delegation, composition e aggregation come possibili sostituti per l'ereditarietà. Per ciascuno dei principi esposti, oltre che alla descrizione e agli esempi d'uso, vengono fornite modalità pratiche per evidenziarne il corretto o l'errato uso, grazie a semplici test, liste di riscontro e così via.

Nel capito nove si introduce il concetto di sviluppo software interattivo e in particolare si mostra come questo possa essere fatto in diversi modi: feature driven, use case driven oppure test driven. Nel capitolo dieci si mostra quale sia il ciclo di vita di un'applicazione a cui si applicano i principi OO:

• lista delle caratteristiche (feature list);
• use case diagrams;
• suddivisione del problema in sotto-problemi;
• analisi dei requisiti;
• analisi del dominio;
• design preliminare;
• implementazione;
• rilascio.

L'analisi dei requisiti fino all'implementazione sono i passi che, solitamente, si iterano. In conclusione è il caso di ricordare che il libro introduce gradualmente la notazione UML per la descrizione delle diverse parti del sistema analizzato; vengono proposti i principali diagrammi e ne vengono spiegati molto bene l'uso e le potenzialità. Il libro consta anche di due appendici; nella prima sono menzionati (e brevemente illustrati) altri concetti legati all'analisi e progettazione orientata agli oggetti, che però non hanno trovato spazio nel libro. La seconda è un minitutorial sull'UML e sulla notazione usata per i class diagram. Dalla pagina ufficiale del libro è possibile scaricare un capitolo di esempio e verificare se lo stile è adatto ai propri bisogni formativi.

Questo libro è chiaro, semplice e adatto a chi vuole un'introduzione graduale ai concetti di analisi, progettazione e sviluppo object-oriented. Il libro resta sempre ancorato a situazioni "reali", applicabili a contesti concreti e fornendo sempre varie alternative, aiutando il lettore a comprendere i pregi e i difetti di ciascuna soluzione. Moltissime domande, molte in forma di giochi, aiutano a "ragionare" meglio sui concetti appena appresi e ad applicarsi in situazioni e contesti molto simili a quelli che, con tutta probabilità, ci si trova ad affrontare nello sviluppo di applicazioni. Se si è alle primissime armi con i concetti object-oriented, questo è il libro da acquistare per imparare l'analisi e la progettazione con questo paradigma.

Pochi contro, e davvero non significativi: il linguaggio usato vuole essere il più colloquiale possibile; per chi è abituato a leggere libri tecnici può rappresentare una piccolissima difficoltà in più (ma davvero minima). Non è un libro da tenere come "reference" sulla scrivania, ma solo per imparare l'approccio object-oriented. A qualcuno lo stile ripetitivo può venire un po' a noia; ma è indubbio che anche questo espediente (voluto!) ha più vantaggi che controindicazioni. C'è da dire che non è assolutamente un libro per chi conosce un po' di analisi e progettazione orientata agli oggetti e vorrebbe degli approfondimenti. Molto meglio orientarsi verso libri dal contenuto più "denso" di nozioni e da ben altra profondità.