© 2010 - cefriel concetti di object orientation docente: gabriele lombardi [email protected]
TRANSCRIPT
© 2010 - CEFRIEL
The present original document was produced by CEFRIEL and the Teacher for the benefit and internal use of this course, and nobody else may claim any right or paternity on it. No right to use the document for any purpose other than the Intended purpose and no right to distribute, disclose, release, furnish or disseminate it or a part of it in any way or form to anyone without the prior express written consent of CEFRIEL and the Teacher.© copyright Cefriel and the Teacher-Milan-Italy-23/06/2008. All rights reserved in accordance with rule of law and international agreements.
© 2010 - CEFRIEL
SommarioSommarioSLIDE CONTENUTO
Paradigmi di programmazione
Precedenti all’OOP e loro limiti, OOP, successivi.
Modellare la realtà Oggetti e classi, incapsulamento, UML.
Modelli concettuali Domain Driven Design, Separation of Concerns.
Riutilizzo del codice Relazioni tra oggetti, pattern GRASP.
Modularizzazione Una gerarchia di astrazioni differenti.
Esempi Analizziamo un caso reale.
Metaprogrammazione Quando, come, perché.
© 2010 - CEFRIEL
Paradigmi di programmazione Spaghetti programming:
– destrutturato, imperativo, (quasi) mai buono;• assembly, basic
Procedurale:– strutturato, imperativo, basato sul “come” e non sul “cosa”, funzione come unità minima;
• C, Pascal Funzionale:
– strutturato, dichiarativo (circa), basato sul “cosa” e non sul “come” (circa), orientato alla formalizzazione matematica (mantenendo legami con il procedurale);
• lisp, scheme Symbolic programming:
– strutturato, dichiarativo, orientato alla sostituzione di simboli tramite l’applicazione di regole;
• Mathematica Logical programming:
– strutturato, dichiarativo, orientato alla manipolazione di sequenti logici con cui effettuare dimostrazione automatica di teoremi (logici di primo e second’ordine);
• Prolog, Golog Stream programming:
– strutturato, procedurale (spesso visuale), orientato alla definizione di stream di elaborazione;
• HP VEE, LabView Object Oriented Programming:
– strutturato, misto dichiarativo/procedurale, oggetti e classi come concetti chiave;
• Java, C++ Object Based Programming:
– strutturato, procedurale, tutto è un oggetto, istanziazione tramite clonazione (prototyping);
• Python, SmallTalk
…e molti altri!
© 2010 - CEFRIEL
Paradigmi di programmazione
Spaghetti programming:
Procedurale:
Object Oriented Programming:
© 2010 - CEFRIEL
Paradigmi di programmazione
OOP vs DDD:– Object Oriented Programming:
• paradigma di programmazione definisce gli strumenti sintattico/semantici con cui descrivere
formalmente la soluzione al problema posto (programma).
• NON si tratta di una metodologia NON definisce come affrontare il problema; NON definisce come identificarne il modello concettuale.
– Domain Driven Design:
• metodologia di identificazione del modello definisce gli strumenti concettuali con cui identificare e
descrivere il modello astratto per il problema nel suo dominio;
• NON si tratta di un paradigma NON definisce gli strumenti di formalizzazione (linguaggio); NON definisce quale paradigma utilizzare (indipendente da
esso).
© 2010 - CEFRIEL
Modelli concettuali Identificare ciò che appartiene al dominio:
– valori: immodificabili, senza identità, senza storia;
•es.: numeri, stringhe, equazioni (?), …– entità: modificabili, con identità, con storia;
•es.: utenti, carrelli, prenotazioni (?), …– servizi: non rappresentano “qualcosa”, ma offrono
funzionalità coese, rispecchianti funzionalità del SW;
•es.: pagamenti, registrazione utenti, …
… ma non troppo!– un dominio non va rappresentato per quello
che è …– … ma per quello che rappresenta per l’utente.
© 2010 - CEFRIEL
Modelli concettuali
Definire il modello:– Chi lo conosce?
•per lo più gli esperti di dominio:– ma inconsapevolmente, vanno aiutati.. mentre ci
aiutano.
•noi …– … a priori no, le conoscenze di base sono fuorvianti.
– Chi sa(prebbe) rappresentarlo?
•noi (in teoria):– tramite strumenti teorici ed esperienza pratica.
•gli esperti di dominio …– … in genere no.. ma “tentano” comunque di
suggerircelo.
Parola chiave: collaborazione!!!
© 2010 - CEFRIEL
Modelli concettuali Problemi:
– comprensione tra collaboratori diversi:• definire un linguaggio comune (degli esperti):
– definizione di un “ubiquitous language”.
• massimizzare la comunicazione (tra opposti):– ottimo tramite le dinamiche dominanti di Nash.
– tempi sempre molto (troppo) stretti: “Serve per ieri!”;• trade-off sempre d’obbligo;
– processo fortemente iterativo;– l’ottimo si ottiene per approssimazioni successive.
• falso problema:– tentare di ottenere prematuramente un prodotto finito porta ad
un enorme dispendio di tempo ed energie per il suo mantenimento.
– complessità ingovernabile:• intrinseco nell’uomo:
– possiamo comprendere al massimo 5-8 concetti assieme;
• gerarchie di astrazioni a granularità differente:– es.: composizione di valori e/o entità = aggregati.
© 2010 - CEFRIEL
Modellare la realtà Basi teoriche dell’OOP:
– modellazione della realtà come:• classificazione degli oggetti che ne fanno
parte;• identificazione delle istanze;• descrizione della loro “struttura”;• descrizione delle loro “capacità”.
– interazione tramite:• messaggi scambiati tra oggetti;• concetto di “richiesta/risposta” (al posto del
concetto di “chiamata a funzione”).– identificazione e specificazione di:
• relazioni tra le classi di oggetti;• contratto di comunicazione (pre., inv. e post.).
– separazione concettuale tra:• interfacce come “punti di
accesso/comunicazione”;• implementazione delle operazioni.
© 2010 - CEFRIEL
Modellare la realtà
Descrizione di una classe di oggetti:– nome della classe stessa
nel linguaggio di dominio;– caratteristiche che identificano le istanze
attributi;– capacità comunicative e attive metodi.
Incapsulamento:– nascondere la struttura interna:
•mostrare il comportamento (cosa) e non il funzionamento (come).
Polimorfismo:– la relazione “è un” nella gerarchia dei tipi;– principio di sostituibilità di Liskov.
Nome
Attributi
Metodi
© 2010 - CEFRIEL
Modellare la realtà: l’UML
Diagramma delle classi:– rappresenta la struttura statica del modello:
•cosa contiene.. con quali relazioni.
+metodo(in parametro : tipo) : tipo#metodo(out parametro : tipo) : tipo-metodo(inout parametro : tipo) : tipo+metodo(in parametro : tipo) : tipo
-attributo : tipo
Classe
SottoClasse
+metodo()
«interfaccia»Interfaccia
Implementazione
Generalizzazione
{attributo>0}
«type»AltraClasseDipendenza
-Estremità1
1
+Estremità2
*
Composizione
-Estremità1 1
#Estremità2 *Aggregazione
Classestereotipata
Interfaccia
Colorazione???
© 2010 - CEFRIEL
Modellare la realtà: l’UML
Diagramma di sequenza:– rappresenta l’evoluzione di un caso d’uso:
•chi chiama cosa e quando.
Oggetto1:tipo Oggetto2
Messaggio
Ritorno
Messaggio
Ritorno
Attivazione
Linea vita
Procedura
Attivazione sequenza
© 2010 - CEFRIEL
Modellare la realtà: l’UML
Diagramma dei casi d’uso:– Quali attori interagiscono con il sistema, e come?– Quali casi di utilizzo e quali eccezioni interessano?
Diagramma dei package:– Quali pacchetti esistono e con quali responsabilità?
Diagramma di deploy:– Il sistema fisico da quali nodi/componenti è
formato?– Quali sono le relazioni tra componenti SW e HW?
Diagramma degli stati:– Quali sono le specifiche degli automi a stati finiti?
Diagrammi di attività:– Quali sono le componenti concorrenti?– Qual è l’evoluzione dei thread/processi nel
sistema?
© 2010 - CEFRIEL
Riutilizzo del codice Metodi:
– utilizzandoli come procedure (mattoncini riutilizzabili); Classi coese:
– offrono funzionalità generali e riutilizzabili; Associazioni:
– permettono di utilizzare funzionalità “esterne”; Ereditarietà:
– ottenimento “a gratis” ti funzionalità già esistenti; Astrazione:
– tramite interfacce e polimorfismo;– permettono di astrarre maggiormente;
Moduli, framework e meta-programmazione:– aventi lo scopo di semplificare lo sviluppo di sistemi
complessi; Annotazioni:
– programmazione dichiarativa “immersa” in un paradigma OO.
© 2010 - CEFRIEL
Riutilizzo del codice Pattern GRASP:
– Low copuling (basso accoppiamento):
•minimizzare il numero di dipendenze;– High coesion (alta coesione):
•Massimizzare la specificità delle features. Regole auree:
– identificare le sotto-problematiche separate;– costruire moduli per risolverle …
•… in maniera separata dal resto;– separare le “capacità” dall’implementazione;– NON esagerare con l’astrazione:
•si finisce per non raggiungere l’obiettivo.
© 2010 - CEFRIEL
Modularizzazione
Pattern GoF:– Creational:
• singleton, factory method, abstract factory, builder, prototype;
– Structural:
• adapter, composite, decorator, facade, …– Behavioral:
• chain of responsibility, command, iterator, observer, state, strategy, template method …
Altri pattern:– Enterprise (e J2EE);– Parallel Programming;– Real-time e sfaty-systems programming;– … specifici dell’ambito di interesse (dominio).
© 2010 - CEFRIEL
Modularizzazione Sistema (distribuito?):
– una o più applicazioni cooperanti. Applicazione/Modulo:
– SW capace di svolgere azioni di interesse. Framework:
– strumento generale di descrizione di un dominio;– permette di affrontare in maniera più semplice un problema.
Pacchetti:– insieme di meccanismi cooperanti per la risoluzione di un
sotto-problema o di un aspetto del problema affrontato. Meccanismi:
– classi che interagiscono per affrontare un caso d’uso (?). Aggregati/Servizi:
– descrivono valori/entità o funzionalità composte. Valori/entità:
– descrivono “qualcosa” manipolato dal sistema SW. Attributi e metodi:
– descrivono le caratteristiche del “qualcosa” a cui appartengono.
© 2010 - CEFRIEL
Meta-programmazione
Scopo:– costruire nuovi strumenti di programmazione;– non (sempre) può modificare la sintassi;– deve semplificare sia lo sviluppo che la
comprensibilità del SW prodotto. Strumenti:
– macro e template (a compile-time);– Reflection (se disponibile);– Linguaggi autodescrittivi (con operatori e altro);– Astrazioni (per descrivere concetti e non
sintassi). Esempi:
– stream programming;– symbolic manipulation (esempio LINQ?).
© 2010 - CEFRIEL
Esempio pratico
Progettiamo un sistema di gestione di una linea ferroviaria orari + annunci al pubblico.
Considerare in particolar modo:– la gestione della persistenza su DB;– l’interazione col sistema da parte degli operatori:
•creazione e battezzo treni;•tracking materiale rotabile;•imprevisti (motrici rotte, ritardi, incidenti);
– storico dell’accaduto e logging. BUON LAOVORO (a me compreso!)
– per una soluzione parziale (da completare per esercizio) si veda Code\00_OOConcepts\Ferrovie.
© 2010 - CEFRIEL
Da qui?
Il Domain Driven Design (DDD):– è propedeutico per una buona comprensione;– fornisce basi solide per la progettazione;– suggerisce una metodologia iterativa di sviluppo;– da leggere:
• “Domain Driven Design”, Evans Design Pattern:
– permettono di affrontare correttamente le problematiche classiche di progettazione;
– ne esistono moltissimi specializzati (vedasi EE);– da leggere:
• “Design Patterns, Elements of Reusable Object-Oriented Software”, Gamma, Helm, Johnson, Vissides
© 2010 - CEFRIEL
Addendum di OOP Esempio: invio di una mail.
– programmazione procedurale:– funzioni vengono richiamate per svolgere compiti coesi;– insiemi di funzioni formano moduli di libreria (stesso scopo).
– OOP:– le classi fanno le veci degli insiemi di funzioni (moduli);– gli oggetti sono dati più le funzionalità di manipolazione;– gli oggetti rappresentano entità attive, non più passive.
mittente___________
______
crea_connessione_____
chiudi_connessione_____
invia_dati_____
© 2010 - CEFRIEL
Esempio precedente in esecuzione
spedisciMail
Mittente
newConessione
inviaDati
chiudi
tem
po
stack
Record di attivazione
Oggetti
Messaggi