Concetti di Object Orientation
Docente: Gabriele Lombardi
[email protected]
© 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
Sommario
SLIDE
CONTENUTO
Paradigmi di
programmazione
Precedenti all’OOP e loro limiti, OOP, successivi.
Modelli concettuali
Domain Driven Design, Separation of Concerns.
Modellare la realtà
Oggetti e classi, incapsulamento, UML.
Riutilizzo del codice
Relazioni tra oggetti, pattern GRASP.
Modularizzazione
Una gerarchia di astrazioni differenti.
Metaprogrammazione
Quando, come, perché.
Esempi
Analizziamo un caso reale.
© 2010 - CEFRIEL
Paradigmi di programmazione

Spaghetti programming:

• assembly, basic
Procedurale:

• C, Pascal
Funzionale:
–
destrutturato, imperativo, (quasi) mai buono;
–
strutturato, imperativo, basato sul “come” e non sul “cosa”, funzione come unità minima;
–
strutturato, dichiarativo (circa), basato sul “cosa” e non sul “come” (circa), orientato alla
formalizzazione matematica (mantenendo legami con il procedurale);

• lisp, scheme
Symbolic programming:

• Mathematica
Logical programming:

• Prolog, Golog
Stream programming:

• HP VEE, LabView
Object Oriented Programming:

• Java, C++
Object Based Programming:
–
strutturato, dichiarativo, orientato alla sostituzione di simboli tramite l’applicazione di regole;
–
strutturato, dichiarativo, orientato alla manipolazione di sequenti logici con cui effettuare
dimostrazione automatica di teoremi (logici di primo e second’ordine);
–
strutturato, procedurale (spesso visuale), orientato alla definizione di stream di elaborazione;
–
strutturato, misto dichiarativo/procedurale, oggetti e classi come concetti chiave;
–
strutturato, procedurale, tutto è un oggetto, istanziazione tramite clonazione (prototyping);
• Python, SmallTalk
© 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).
Nome
Polimorfismo:
Attributi
– la relazione “è un” nella gerarchia dei tipi;
– principio di sostituibilità di Liskov.
© 2010 - CEFRIEL
Metodi
Modellare la realtà: l’UML

Diagramma delle classi:
– rappresenta la struttura statica del modello:
• cosa contiene.. con quali relazioni.
+Estremità2
*
Aggregazione
«interfaccia»
Interfaccia
+metodo()
#Estremità2
Implementazione
*
{attributo>0}
Classe
-attributo : tipo
+metodo(in parametro : tipo) : tipo
#metodo(out parametro : tipo) : tipo
-metodo(inout parametro : tipo) : tipo
+metodo(in parametro : tipo) : tipo
Composizione
-Estremità1
1
1
Dipendenza
Interfaccia
«type»
AltraClasse
SottoClasse
Generalizzazione
-Estremità1
© 2010 - CEFRIEL
Classe
stereotipata
Modellare la realtà: l’UML

Diagramma di sequenza:
– rappresenta l’evoluzione di un caso d’uso:
• chi chiama cosa e quando.
Oggetto1:tipo
Attivazione sequenza
Oggetto2
Messaggio
Attivazione
Ritorno
Procedura
Messaggio
Ritorno
© 2010 - CEFRIEL
Linea vita
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 sottoproblema 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 ObjectOriented 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).
mittente
______
_____
______
– OOP:
crea_connessione
_____
invia_dati
_____
chiudi_connessione
_____
– 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
«interfaccia»
Connessione
+inviaDati(in dati)
+chiudi()
mittente
new
connessione
inviaDati
chiudi
ConnessioneTCP
ConnessioneGSM
ConnessioneUMTS
© 2010 - CEFRIEL
Esempio precedente in esecuzione
Oggetti
Mittente
spedisciMail
new
Conessione
inviaDati
tempo
Record di
attivazione
chiudi
Messaggi
stack
© 2010 - CEFRIEL