progettazione e programmazione orientata agli oggetti · • la programmazione ad oggetti (oop) è...

Post on 15-Feb-2019

224 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Progettazione e ProgrammazioneOrientata agli Oggetti

Giovanni RimassaDII - Università di Parma

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Programmazione ad Oggetti

• La programmazione ad oggetti (OOP) è unaparte importante delle moderne tecniche disviluppo del software.

• Le tecnologie OO permeano tutto il ciclo disviluppo del software– OOA - (Object Oriented Analysis)– OOD - (Object Oriented Design)– OOP - (Object Oriented Programming)

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Programmazione ad Oggetti

• Negli ultimi 15 anni, le tecnologie OOhanno preso sempre più piede.

• Oggi gli oggetti sono talmente mainstreamche nessuno li contesta più apertamente.

• Tuttavia, la comprensione dei principilinguistici e di progetto alla base della OOPnon è così diffusa come sembra.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Programmazione ad Oggetti

• Le soluzioni proposte dalla OOP nasconoda considerazioni generali di Ingegneria delSoftware.

• Le tecnologie orientate agli oggetti cercanodi favorire la progettazione di software diqualità.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

La Qualità del Software

• Un sistema software può essere valutato inbase a molte qualità, che si possonodividere in due grandi categorie:

• Qualità Esterne (viste dal cliente/utente)– Correttezza, Efficienza, Usabilità, ...

• Qualità Interne (viste dallo sviluppatore)– Mantenibilità, Estendibilità, ...

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Modularità

• La modularità viene spesso considerata unaqualità interna, ma in realtà non èchiaramente definita.

• Si potrebbe definire informalmente così:– Un sistema è modulare se i suoi moduli sono

“ben strutturati” e “ben collegati insieme”.

⇒ Cerchiamo delle proprietà più precise.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Modularità

• Per descrivere la modularità e mostrarecome essa supporti le qualità interne delsoftware, vedremo:– Cinque Criteri (per valutarla)– Cinque Regole (per garantirla)– Cinque Principi (per praticarla)

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Criteri (1)• Decomponibilità

– Un sistema modulare può essere decomposto in partipiù piccole, connesse da una struttura semplice,abbastanza indipendenti da lavorarci separatamente.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Criteri (2)• Componibilità

– Un sistema modulare favorisce la produzione dielementi che possono essere combinati insieme in unambiente diverso da quello in cui sono stati creati.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Criteri (3)• Comprensibilità

– In un sistema modulare ogni parte può essere compresaisolatamente da un osservatore umano, senza chequesto debba conoscere le altre parti.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Criteri (4)• Continuità

– Un sistema modulare è tale che ad un cambiamento“piccolo” nelle specifiche del sistema corrisponda uncambiamento “piccolo” nell’implementazione.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Criteri (5)• Protezione

– Un sistema modulare confina gli effetti di condizionianormali all’interno del modulo in cui avvengono, o alpiù in un numero ristretto di moduli.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Regole(1)

• Corrispondenza Diretta– La struttura modulare del sistema software

dovrebbe rimanere compatibile con quella delproblema che il sistema tenta di risolvere.

• Una qualità molto citata dell’approccio OOè che si riesce a modellare il software sullabase del “mondo reale”– Ma “compatibile” non vuol dire “speculare”

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Regole(2)

• Poche Interfacce– Ogni modulo dovrebbe comunicare con il

minor numero possibile di altri moduli.

• Questa regola serve a supportare lacontinuità e la protezione.– Se un modulo ha poche interfacce, i suoi

cambiamenti si rifletteranno su pochi altri.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Regole(3)

• Interfacce Piccole– Quando due moduli comunicano, dovrebbero

scambiarsi meno informazioni possibile.

• Anche questa regola supporta la continuitàe la protezione.– Se un modulo ha interfacce piccole, i suoi

cambiamenti si rifletteranno poco sui suoi(pochi) vicini.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Regole(4)

• Interfacce Esplicite– Il fatto che due moduli comunicano dovrebbe

essere ovvio leggendo il loro codice.

• Questa regola supporta comprensibilità,componibilità, decomponibilità e continuità.– Le interfacce esplicite aiutano a capire il

modulo ed a prevedere gli effetti deicambiamenti, ad anche a comporlo/scomporlo.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Regole(5)

• Information Hiding– un modulo deve dichiarare un sottoinsieme

pubblico delle sue informazioni.

• Questa regola è il cardine fondamentale perottenere la continuità.– Ogni decisione di progetto o implementazione

che non viene rivelata agli altri moduli puòessere rivista senza influenzarli.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Principi

• I criteri e le regole visti prima esprimono(apparentemente) concetti legati più alprogetto del sistema che al linguaggio diprogrammazione.

• I cinque principi seguenti, invece, siriflettono sui costrutti linguistici e sono ilriflesso pratico delle regole viste prima.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Principi (1)

• Unità Linguistiche Modulari– Il linguaggio di programmazione deve

supportare i moduli come unità sintattiche.

• I criteri di modularità devono arrivare finoall’implementazione: se il linguaggio non saesprimere in forma compilabile i moduliindividuati nelle fasi precedenti, non si puòcostruire un sistema modulare.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Principi (2)

• Documentazione Incorporata– La documentazione interna di un modulo deve

essere contenuta nel modulo stesso.

• Una buona documentazione incrementa lacomprensibilità, ma deve essere aggiornatao diventa addirittura fuorviante e dannosa.– Mantenere la documentazione vicino al codice.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Principi (3)

• Accesso Uniforme– I servizi esposti da un modulo non devono

rivelare se sono implementati con calcoli o condati.

• Questo principio serve a rispettarel’information hiding ed aiuta a garantire lacontinuità; consente al modulo di cambiarei trade-off spazio-tempo senza problemi.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Principi (4)

• Aperto/Chiuso (Open/Closed Principle)– Il linguaggio di programmazione deve

permettere di creare moduli aperti perl’estensione, ma chiusi per l’utilizzo.

• Chi usa un modulo vuole saperne il menopossibile (black box).

• Per essere esteso, un modulo deve rivelarequalcosa in più (white box).

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Cinque Principi (5)

• Scelta Singola (Single Choice Principle)– Ogni volta che ci sono un certo numero di

alternative, al più un modulo deve conoscernel’elenco.

• Quando “i casi sono due” nella versione1.0, si può star sicuri che “i casi sonoquindici” nella versione 2.0.– Per salvaguardare continuità ed estendibilità.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Tipi di Dato

• Al livello più basso, programmi e dati nonsono altro che sequenze di byte.– Un virus infetta tutti i programmi nello stesso

modo.– Le tecniche di protezione e cracking sono

indipendenti dal tipo di programma.– MAME o VMWare fanno girare applicazioni

sconosciute ai progettisti dell’emulatore.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Tipi di Dato

• Curiosamente, anche alcuni linguaggi dilivello molto alto rappresentano dati eprogrammi in modo omogeneo.– In LISP si esprime tutto come cella o lista.– Molti linguaggi di scripting hanno un solo tipo

di dato.– Una Macchina di Turing ne può simulare

un’altra.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Tipi di Dato

• “Si è tanto ciechi nell’oscurità totalequanto nella luce totale”.

• Modelli troppo omogenei riducono lacomprensibilità e la decomponibilità.– Linguaggi strettamente tipati.– Typing statico e typing dinamico.– Tipi come categorie per la modellazione.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Tipi di Dato

• Insegnando un linguaggio, si devonointrodurre i tipi di dato supportati.

• A livello elementare, si introducono i tipiattraverso una loro rappresentazione.– Gli array bidimensionali in C sono memorizzati

per righe.– Una struct in C è fatta dalla sequenza dei suoi

campi.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Tipi di Dato

• Per ottenere alcune qualità interne qualidecomponibilità e protezione, non ci si devebasare sulla rappresentazione di un tipo, ma:– Sulle operazioni ad esso applicabili.– Sulle proprietà garantite per ogni istanza del

tipo.– Sulle precondizioni di ogni operazione.

⇒ Si parla di Abstract Data Type.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

ADT: Un Esempio• Type: STACK<REAL>• Functions

– push: (STACK<REAL>, REAL)→ STACK<REAL>– … (pop, top, remove)

• Axioms– top(push(s, x)) = x– …

• Preconditions– pop require not empty– …

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Moduli e Tipi

• Moduli e tipi sembrano molto diversi.– I moduli strutturano l’implementazione.– I tipi specificano come usare ogni parte.

• Ma in comune c’è il concetto di interfaccia.– Nei moduli determina la parte pubblica.– Nei tipi descrive le operazioni ammissibili e le

loro proprietà.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

OOP

Il concetto fondamentale dellaIl concetto fondamentale dellaprogrammazione ad oggetti è:programmazione ad oggetti è:

L’OggettoLa Classe

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

OOP

• Def: Classe– “Un tipo di dato astratto corredato da un

modulo che ne è un’implementazione.”

Tipo + Modulo = Classe

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Classi• Una classe Point,

espressa nellanotazione standardUML (UnifiedModeling Language).– Dati privati.– Funzioni pubbliche.– Membri di istanza.– Membri di classe.

Point- double x- double y- numOfPoints

+ Point(double x, double y)+ void move(double dx, double dy)+ int howMany()

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Classi in C++ ed in Java// File Point.Hclass Point { // C++

public: Point(double x, double y); void move(double dx, double dy); static int howMany();

private: double m_x; double m_y; static int numOfPoints;};// Implementazione in Point.cc

// File Point.javaclass Point { // Java

public Point(double x,double y) {…} public void move(double dx, double dy) {…} public static int howMany() {…}

private double myX; private double myY; private static int numOfPoints;}// Implementazione in linea

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Oggetti• Un oggetto in notazione

UML.– Un oggetto è un’istanza

di una classe (che è il suotipo ed il modulo che neregola l’accesso).

– Un oggetto ha strutturaed operazioni della suaclasse, ma specificivalori per gli attributi.

aPoint:Point

x:double = 1.3y:double = -5.8

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Oggetti

• Oggetti della stessa classe hanno operazioniuguali (metodi), ma dati diversi.

• Un metodo può accedere ai dati dell’oggetto(parte privata del modulo).

• Come si indica al metodo su quale oggettoagire ?– Istanza corrente di un oggetto (this o self).

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Chiamata a Metodo

res = obj.meth(par)

Lista di parametri

Meccanismo fondamentale di computazione della OOP

Nome del metodo

Oggetto Target

Risultato

Operatore di accesso

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Oggetti in C++ e Java// File main.cc - C++#include “Point.H”

void main(int argc, char *argv[]) { Point p(1,2); // Oggetto locale Point* pptr; // Puntatore

pptr = new Point(0,0); // Alloca p.move(-4,7); // Method call pptr->move(3,-6); // Method call

delete pptr; pptr = 0;} // p distrutto automaticamente

// File Main.java - Javaimport Point;

class Main { public static void main(String[] args) {

Point p; // Riferimento nullo p = new Point(0,0); // Alloca p.move(-5,-9); // Method call

p = null; // Garbage collection

}}

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Oggetti in C++ e Java// File point.cc - C++#include “Point.H”

// Implementazione separatavoid Point::move(double dx, double dy) {

// this - all’interno di un // metodo e` il puntatore // all’istanza corrente this->m_x = this->m_x + dx;

// ‘this’ si puo` omettere m_y = m_y + dy;

}

// File Point.javaclass Point { // Java

// Implementazione in linea public void move(double dx, double dy) {

// this - all’interno di un // metodo e` il riferimento // all’istanza corrente this.myX = this.myX + dx;

// ‘this’ si puo` omettere myY = myY + dy}

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ciclo di Vita degli Oggetti

• Ogni classe impone dei vincoli su tutti i suoioggetti.– Precondizioni all’ingresso dei metodi.– Postcondizioni all’uscita dei metodi.– Invarianti che devono sempre valere.

• Gli oggetti devono gestire risorse durante laloro esistenza (memoria, file, entità del S.O.).

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ciclo di Vita degli Oggetti

• Momenti critici della vita di un oggetto:– Creazione.– Copia.– Distruzione.

• La creazione è ben più dell’allocazione.• La copia incide sulle chiamate a metodo.• La distruzione deve rimettere tutto a posto.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ciclo di Vita in C++

• In C++ esistono alcuni metodi particolari:– I costruttori, che creano e copiano gli oggetti.– L’operatore di assegnazione, che sostituisce

un oggetto con un altro.– Il distruttore, che distrugge gli oggetti.

• La gestione della memoria è manuale.– Protocollo Prologo/Epilogo.– Allocazione sullo stack, sullo heap o statica.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ciclo di Vita in Java

• In Java, esistono alcuni metodi particolari:– I costruttori, che creano gli oggetti.– Il metodo clone(), che copia gli oggetti.

• La gestione della memoria è automatica.– Nella JVM c’è un garbage collector.– Il momento della distruzione non è noto.– Allocazione sullo heap (tutti puntatori).

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ereditarietà

• Esprime una relazione is-a fra due classi.– Relazione gerarchica ed aciclica.

• Può essere singola o multipla.

Shape

Circle Triangle Square

Shape

Circle Triangle Square

Persistent

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ereditarietà

• L’ereditarietà è un meccanismo base dellaOOP, ma ha più aspetti diversi.

• La prima distinzione da fare è traereditarietà di interfaccia ed ereditarietà diimplementazione.– Tipo + Modulo = Classe.– Subtyping + Inheritance = Subclassing.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Subtyping

• Se le classi sono tipi, l’ereditarietà è unarelazione tra tipi, che chiamiamo subtyping.

• Se il tipo D è un sotto-tipo del tipo B, cosasignifica D is-a B ?– Tutto quello che posso fare ad un B lo posso

fare anche ad un D.

⇒ Principio di Sostituibilità di Liskov.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Inheritance

• L’ereditarietà è una relazione tra moduli,che chiamiamo (solo qui) inheritance.

• L’inheritance garantisce l’Open/ClosedPrinciple.– Un sotto-modulo avrà accesso privilegiato al

modulo base (accesso protected in C++ e Java).– Un sotto-modulo potrà cambiare o estendere

l’implementazione del modulo base.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ereditarietà in C++

• Il C++ supporta completamente l’ereditarietà.– Ereditarietà singola e multipla.– Ereditarietà multipla ripetuta e condivisa.– Ereditarietà pubblica, protetta e privata.

• In C++ si può avere:– Subtyping puro (classi puramente astratte).– Inheritance pura (ereditarietà privata).

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Ereditarietà in Java

• Java supporta quasi completamentel’ereditarietà.– Inheritance singola.– Subtyping multiplo.– Invocazione dei metodi ereditati tramite il

riferimento super.

• In Java si può avere:– Subtyping puro (interfacce).

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo

• Il polimorfismo è una caratteristicaessenziale dei linguaggi orientati aglioggetti.

• Permette di trattare in modo uniforme tipi“simili”, ma rispettandone le differenze.

• Spesso il polimorfismo si usa per garantireil Single Choice Principle.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo• Si individuano delle operazioni comuni per

interfaccia, ma diverse per comportamento.• Una classe dichiara la funzione e delle sottoclassi

ne forniscono diverse implementazioni.

Shape

Circle Triangle Square

+ void draw(GC& aCtx)

+ void draw(GC& aCtx) + void draw(GC& aCtx) + void draw(GC& aCtx)

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo

• Per il Principio di Sostituibilità:– Un riferimento di tipo Shape può puntare a

oggetti di tipo Shape o di una sottoclasse.

• Esiste un tipo statico ed un tipo dinamico:– Tipo statico ⇒ tipo del riferimento, dichiarato a

compile time.– Tipo dinamico ⇒ tipo dell’oggetto puntato a

run time.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo

• Quando tipo statico ≠ tipo dinamico, se ledue classi hanno versioni diverse di unastessa funzione membro, sorge un problemadi binding.– Static binding (o early binding) ⇒ tipo statico.– Dynamic binding (o late binding) ⇒ tipo

dinamico.

• Il late binding è possibile solo con ptr/ref.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo

• Nell’esempio delle figure geometriche:– La funzione draw(ctx) viene chiamata su un

ref di tipo Shape:s.draw(ctx);

– Circle::draw(), se s punta ad un Circle.– Square::draw(), se s punta ad uno Square.

⇒ L’oggetto sa il suo vero tipo e la funzionefa la cosa giusta!

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo

• Nel caso delle figure geometriche:– Shape::draw(), non è definita (non si sa

disegnare una “figura generica”).– Shape ha un’implementazione incompleta.– Shape è una classe astratta.

• Alcune funzioni non si devono cambiare.– Se una funzione non è ridefinibile, il late

binding non serve.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo e Class Design

• Il progettista della classe base deve deciderequali funzioni membro devono esserepolimorfe, quali astratte e quali ordinarie.

• La decisione va presa attentamente,ponendosi due domande sulla funzione:– “Si potrà ridefinire nelle classi derivate?”– “Si può fornire un’implementazione generica

nella classe base?”

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Polimorfismo in C++ e JavaCome dichiarareuna funzione f() inJava e C++, aseconda di come (ese) si può ridefinirenelle sottoclassi

Non Ridefinibile Implementazionedi Default Astratta

Java final void f() void f() abstract void f()

C++ void f() virtual void f() virtual void f() = 0

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Gestione delle Eccezioni

• Le condizioni di errore sono al centro di undilemma:– Nella maggior parte dei casi non si presentano.– Quando si presentano, possono avere risultati

catastrofici.

• Serve una soluzione che consenta di trattaregli errori, senza inquinare il codice eseguitonei casi normali.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Gestione delle Eccezioni

• Errori e valori di ritorno:– Quando un metodo fallisce, non ha senso

chiedergli un valore di ritorno.– L’uso di valori out of band richiede di ridurre il

codominio in modo arbitrario.– Il chiamante deve farcire il codice di test

condizionali.– Il chiamante può ignorare l’errore.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Gestione delle Eccezioni

• Sia C++ che Java forniscono unmeccanismo flessibile per gestire lecondizioni di errore:

La Gestione delleEccezioni

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Sintassi per le Eccezioni

• C++ e Java hanno sintassi molto simile.• Si racchiude il codice da proteggere in un

blocco try.• Un’eccezione si lancia con la parola chiavethrow.

• I gestori delle eccezioni sono introdottidalla parola chiave catch.

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Eccezioni in C++#include “library.h”

void main() { try { f(); // Può tirare un’ecc. } catch(Exception& e) { // Gestisce l’eccezione }}

void f() { X localX; g();}

void g() { Y localY; h();}

void h() { if(something_wrong()) throw Exception(“Argh”);}

Program.cc Library.cc

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Eccezioni in Javaimport Library;

public class Program { // ...

public static void main() { try { f(); // Può tirare un’ecc. } catch(Exception e) { // Gestisce l’eccezione } }}

class Library { void f() throws Exception { X localX = new X(); g(); }

void g() throws Exception { Y localY = new Y(); h(); }

void h() throws Exception { if(something_wrong()) throw new Exception(“Argh”); }}

Program.java Library.java

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Ingegneria dell’Informazione ENGINEERING

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

COMPUTER

Eccezioni in C++ e Java

• Java obbliga ogni metodo a dichiarare leeccezioni tirate (opzionale in C++).

• In C++ gli oggetti locali vengono distruttimentre l’eccezione si propaga.

• Java ha la parola chiave finally pereseguire codice comune ai casi normali edeccezionali (il C++ sfrutta i distruttori).

top related