Agenda Contatti - Requisiti. I Dati. Agenda Contatti. Detail. Detail. Fondamenti di Informatica T2 Modulo 2. Università di Bologna A.A.

Transcript

1 Università degli Studi di Bologna Facoltà di Ingegneria Fondamenti di Informatica T2 Modulo 2 Corso di Laurea in Ingegneria Informatica Anno accademico 2008/2009 Agenda Contatti - Requisiti Si desidera realizzare un applicazione per la gestione di contatti. NOTA: un contatto può Ogni contatto è caratterizzato da: contenere più dettagli nome e cognome; dello stesso tipo (es. due numeri di telefono) un insieme di dettagli. I dettagli possono essere di diverso tipo (telefono, , indirizzo, ecc.) un dettaglio è sicuramente caratterizzato da un nome (Phone, , Address, ecc.) e da una descrizione (Cell1, Cell2, Home, Job, ecc.) L applicazione deve essere realizzata in modo che sia semplice aggiungere un nuovo tipo di dettaglio. 2 Agenda Contatti Al momento ci si limita alla progettazione ed alla realizzazione di: Dominio applicativo: le classi che contengono i dati Logica di persistenza: le classi che si occupano di salvare e recuperare i dati In una successiva esercitazione: Interfaccia utente + Logica applicativa I Dati Quali sono le entità in gioco? Contatto Dettaglio di contatto in tutte le sue varianti Un contatto può essere composto di tanti dettagli composizione Un dettaglio è modellato tramite un astrazione realizzata in diverse varianti ereditarietà o implementazione d interfaccia? 3 4 Interfaccia o classe astratta? Un dettaglio è caratterizzato da: un nome che dipende dal tipo di dettaglio a livello di astrazione è solo una dichiarazione; una descrizione esiste per ogni dettaglio. è una classe astratta con un metodo getnome astratto e due metodi accessor get/setdescrizione concreti. class domainmodel - descriptio n: String + getdescriptio n() : String + setdescription(string) : void Dovendo essere (anche) serializzabile su stream binario implementa Serializable; 5 6

2 Sottoclassi di Phone: memorizza numeri telefonici memorizza indirizzi Address: memorizza indirizzi Phone e ereditano le caratteristiche di (nome, descrizione) ed aggiungono un valore di tipo stringa (il telefono e l ) È possibile evitare replicazione di codice introducendo una classe astratta (non implementa ancora il metodo getname()) che contenga un valore stringa e da cui ereditino le classi con questa caratteristica String Address eredita direttamente da ed aggiunge tutte le caratteristiche del caso class domainmodel Gerarchia Dettagli String - street: String - number: String - value: String - zipcode: String - city: String + getvalue() : String - state: String + setvalue(string) : void + tostring() : String + setstreet(string) : void + getstreet() : String + setnumber(string) : void + getnumber() : String + setzipcode(string) : void + getzipcode() : String EM ail Phone + setcity(string) : void + getcity() : String + setstate(string) : void + getstate() : String + tostring() : String descriptio n: String + getdescriptio n() : String + setdescription(string) : void Address Contact Un contatto è caratterizzato da: nome e cognome; un insieme di dettagli. Si parla di un insieme proprio perché non avrebbe senso avere due volte lo stesso identico dettaglio. Che tipo di collezione si usa? Si vuole mantenere l ordinamento dei dettagli? Sì: TreeSet No: HashSet Voglio poter ordinare i dettagli e voglio che mantengano l ordinamento! 9 Contact Contact deve essere Serializable e Comparable (ordine alfabetico?) class domainmodel - descriptio n: String + getdescriptio n() : String + setdescription(string) : void * Composizione! Contact Compa rable - firstname: String - secondname: String - detaillist: List<> + Contact() + getlist() : List<> + setfirstname(string) : void + getfirstname () : String + setsecondname(string) : void + getsecondnam e() : String + tostring() : String + compareto(contact) : int 10 Persistenza dei dati Deve essere possibile caricare e salvare i dati sia su stream binario, sia su stream di testo Schema simile a quello visto in aula (componenti per PC) con qualche estensione: Composizione + Ereditarietà Interfacce ContactLoader e ContactSaver da implementare a seconda dei casi Serializzazione Binaria Tutte le classi in gioco sono già Serializable La realizzazione di loader e saver è semplicissima: la serializzazione di grafi di oggetti è totalmente automatica! class persistence «interface» ContactLoader + load() : Contact «interface» ContactSaver + save(contact) : void 11 12

3 Persistenza su stream di testo Decisamente più complicata della serializzazione binaria Si ha a che fare con composizione ed ereditarietà È bene partire con la definizione di un formato dei dati di facile lettura Formattazione di contatto e dettagli; due possibilità: 1. Tutto su una unica riga 2. Su righe diverse L ipotesi 1. è già stata ampiamente sviscerata in Fond. T-1, anche se è un ottimo esercizio per casa! Proviamo la strada indicata dall ipotesi Obiettivo secondario (ma non troppo) è ottenere un formato che sia facilmente leggibile Per semplificare la lettura, occorre introdurre dei marcatori di INIZIO e FINE contatto: StartContact, EndContact Tali marcatori occupano da soli una riga Delimitano tutte le informazioni relative ad un contatto (dettagli compresi) Un contatto inizia con StartContact Alla riga successiva si inseriscono first name e second name separati da ; A partire dalla riga successiva a first e second name, compaiono l elenco dei dettagli tale elenco è terminato dal marcatore di fine contatto EndContact Dettagli Per ora: I dettagli possono essere di diverso tipo StartContact Zannoni;Gabriele Dettaglio Dettaglio Dettaglio EndContact Per comodità, è bene mettere in testa il tipo di contatto in modo da sapere subito con chi si ha a che fare (Phone, , Address, ecc.) Poi, si fa seguire la descrizione poiché esiste in tutti i tipi di dettagli Poi, tutte le caratteristiche del dettaglio specifico 17 18

4 Quindi: Dettagli Phone;Cell.; Phone;Home; Address;Home;Via F.lli Cervi;9;48011;Alfonsine(RA);Italia completo StartContact Zannoni;Gabriele Phone;Cell.; Phone;Home; Address;Home;Via F.lli Cervi;9;48011;Alfonsine(RA);Italia EndContact La lettura - algoritmo PRIMA PARTE Il Contatto 1. Leggere una riga la stringa letta deve valere StartContact, altrimenti si segnala errore 2. Leggere una riga caricare la stringa in uno StringTokenizer devono esserci due token che vanno inseriti, rispettivamente, in first name e second name del contatto 3. Leggere i dettagli del contatto È un metodo diverso! La lettura - algoritmo SECONDA PARTE I Dettagli 1. Leggere una riga se la stringa letta è diversa da EndContact a. Costruire uno StringTokenizer sulla linea letta b. In base al primo token ottenere un oggetto Loader che sia in grado di interpretare il dettaglio c. Ottenere il dettaglio dal Loader passandogli lo StringTokenizer d. Ricominciare da 1. Uno per ogni tipo di dettaglio! Serve una factory! La lettura Considerazioni Dentro ogni Loader, la lettura è semplice: esiste già uno StringTokenizer con i token del caso Loader un interfaccia con un metodo (load) che prende in ingresso uno StringTokenizer e restituisce un Ci vuole una factory che, dato il nome (tipo) del dettaglio, sia in grado di restituire il relativo Loader La lettura - Considerazioni in realtà non è necessario separare Loader da Saver: a livello di implementazione, sono oggetti senza stato Non riservano risorse di sistema specifiche per lettura o scrittura Collassare Loader e Saver in una unica entità astratta Manager Per quanto riguarda loader e saver del contatto, si mantiene lo schema solito: TextContactLoader, TextContactSaver che implementano, rispettivamente, le interfacce ContactLoader e ContactSaver 23 24

5 Diagramma UML La factory Factory di Manager: è un Singleton! L unico oggetto che conosce quanti e quali siano i possibili dettagli è la factory dei Manager TextManagerFactory Si può costruire in modo semplice utilizzando una mappa (Map) che associ il tipo di dettaglio con un istanza di del Manager (che non ha stato) opportuno TextContactLoader/Saver dipendono solamente da Manager (interfaccia) oltre che, ovviamente da Contact e (classe stratta) 25 Di che tipo è la mappa? L interfaccia: Map<String, Manager> Il tipo esatto: HashMap<String, Manager> Perché un HashMap? 26 La factory Pattern Singleton La mappa può essere caricata nel costruttore della factory: managermap.put(" ", new Manager()); È un Manager! Di quante istanze di questa factory c è bisogno all interno del sistema? Una sola!! Come si fa a rendere obbligatoria l esistenza di una ed una sola istanza di una certa classe? Il Singleton è un design pattern creazionale che ha lo scopo di garantire che di una determinata classe venga creata una e una sola istanza, e di fornire un punto di accesso globale a tale istanza. un costrutture privato: nessuno può costruire istanze dall esterno della classe; un campo statico privato dello stesso tipo della classe che contenga l unica istanza; un metodo statico pubblico che consenta di recuperare l unica istanza che esiste ed eventualmente di crearla se ancora non esiste Pattern Singleton I Dettagli di Contatto public class TextManagerFactory { private static TextManagerFactory instance; } public static TextManagerFactory getinstance() { if (instance == null) { instance = new TextManagerFactory(); } } return instance; Per ora va bene questa definizione ma non è definitiva: problemi in caso di sistemi concorrenti ma cosa sono i sistemi concorrenti? Quanto costa aggiungere un nuovo tipo di dettaglio di contatto? Creare la nuova classe che estenda la classe astratta Creare la nuova classe che consenta il caricamento/salvataggio del nuovo dettaglio: deve implementare Manager Aggiungere una entry nella mappa della factory COSTA POCO! 29 30

6 Pattern Strategy Permette di: definire un insieme di algoritmi tra loro correlati; incapsulare tali algoritmi in una gerarchia di classi; rendere gli algoritmi intercambiabili. Pattern Strategy Dichiara un interfaccia comune a tutti gli algoritmi supportati Referenzia, tramite l interfaccia, l oggetto che implementa un algoritmo. Implementa l interfaccia e fornisce l implementazione di un algoritmo Anche meglio! Quando si aggiungono nuovi dettagli, sarebbe bello poter evitare di modificare la factory dei manager si può fare? SOLO PER GLI SMANETTONI! Certo che sì; occorre usare: Una custom annotation e la reflection per andare a scovare tutte le classi che implementano Manager, che non siano astratte e che siano decorate con la annotation non è un gioco da ragazzi, ma si fa! AutoTextManager nelle soluzioni! Salvataggio Il salvataggio è una passeggiata! Strutturazione simile al caricamento ma decisamente più semplice 33 34