Progettazione e Programmazione Orientata agli Oggetti - Computer ...

ce.unipr.it

Progettazione e Programmazione Orientata agli Oggetti - Computer ...

UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Progettazione e Programmazione

Orientata agli Oggetti

Giovanni Rimassa

DII - Università di Parma

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Programmazione ad Oggetti

• La programmazione ad oggetti (OOP) è una

parte importante delle moderne tecniche di

sviluppo del software.

• Le tecnologie OO permeano tutto il ciclo di

sviluppo del software

– OOA - (Object Oriented Analysis)

– OOD - (Object Oriented Design)

– OOP - (Object Oriented Programming)

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Programmazione ad Oggetti

• Negli ultimi 15 anni, le tecnologie OO

hanno preso sempre più piede.

• Oggi gli oggetti sono talmente mainstream

che nessuno li contesta più apertamente.

• Tuttavia, la comprensione dei principi

linguistici e di progetto alla base della OOP

non è così diffusa come sembra.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Programmazione ad Oggetti

• Le soluzioni proposte dalla OOP nascono

da considerazioni generali di Ingegneria del

Software.

• Le tecnologie orientate agli oggetti cercano

di favorire la progettazione di software di

qualità.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

La Qualità del Software

• Un sistema software può essere valutato in

base a molte qualità, che si possono

dividere in due grandi categorie:

• Qualità Esterne (viste dal cliente/utente)

– Correttezza, Efficienza, Usabilità, ...

• Qualità Interne (viste dallo sviluppatore)

– Mantenibilità, Estendibilità, ...

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Modularità

• La modularità viene spesso considerata una

qualità 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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Modularità

• Per descrivere la modularità e mostrare

come essa supporti le qualità interne del

software, vedremo:

– Cinque Criteri (per valutarla)

– Cinque Regole (per garantirla)

– Cinque Principi (per praticarla)

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Criteri (1)

• Decomponibilità

– Un sistema modulare può essere decomposto in parti

più piccole, connesse da una struttura semplice,

abbastanza indipendenti da lavorarci separatamente.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Criteri (2)

• Componibilità

– Un sistema modulare favorisce la produzione di

elementi che possono essere combinati insieme in un

ambiente diverso da quello in cui sono stati creati.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Criteri (3)

• Comprensibilità

– In un sistema modulare ogni parte può essere compresa

isolatamente da un osservatore umano, senza che

questo debba conoscere le altre parti.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Criteri (4)

• Continuità

– Un sistema modulare è tale che ad un cambiamento

“piccolo” nelle specifiche del sistema corrisponda un

cambiamento “piccolo” nell’implementazione.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Criteri (5)

• Protezione

– Un sistema modulare confina gli effetti di condizioni

anormali all’interno del modulo in cui avvengono, o al

più in un numero ristretto di moduli.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Regole(1)

• Corrispondenza Diretta

– La struttura modulare del sistema software

dovrebbe rimanere compatibile con quella del

problema che il sistema tenta di risolvere.

• Una qualità molto citata dell’approccio OO

è che si riesce a modellare il software sulla

base del “mondo reale”

– Ma “compatibile” non vuol dire “speculare”

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

• Poche Interfacce

Cinque Regole(2)

– Ogni modulo dovrebbe comunicare con il

minor numero possibile di altri moduli.

• Questa regola serve a supportare la

continuità e la protezione.

– Se un modulo ha poche interfacce, i suoi

cambiamenti si rifletteranno su pochi altri.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

• Interfacce Piccole

Cinque Regole(3)

– 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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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 dei

cambiamenti, ad anche a comporlo/scomporlo.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Regole(5)

• Information Hiding

– un modulo deve dichiarare un sottoinsieme

pubblico delle sue informazioni.

• Questa regola è il cardine fondamentale per

ottenere la continuità.

– Ogni decisione di progetto o implementazione

che non viene rivelata agli altri moduli può

essere rivista senza influenzarli.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Principi

• I criteri e le regole visti prima esprimono

(apparentemente) concetti legati più al

progetto del sistema che al linguaggio di

programmazione.

• I cinque principi seguenti, invece, si

riflettono sui costrutti linguistici e sono il

riflesso pratico delle regole viste prima.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Principi (1)

• Unità Linguistiche Modulari

– Il linguaggio di programmazione deve

supportare i moduli come unità sintattiche.

• I criteri di modularità devono arrivare fino

all’implementazione: se il linguaggio non sa

esprimere in forma compilabile i moduli

individuati nelle fasi precedenti, non si può

costruire un sistema modulare.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Principi (2)

• Documentazione Incorporata

– La documentazione interna di un modulo deve

essere contenuta nel modulo stesso.

• Una buona documentazione incrementa la

comprensibilità, ma deve essere aggiornata

o diventa addirittura fuorviante e dannosa.

– Mantenere la documentazione vicino al codice.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Principi (3)

• Accesso Uniforme

– I servizi esposti da un modulo non devono

rivelare se sono implementati con calcoli o con

dati.

• Questo principio serve a rispettare

l’information hiding ed aiuta a garantire la

continuità; consente al modulo di cambiare

i trade-off spazio-tempo senza problemi.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Principi (4)

• Aperto/Chiuso (Open/Closed Principle)

– Il linguaggio di programmazione deve

permettere di creare moduli aperti per

l’estensione, ma chiusi per l’utilizzo.

• Chi usa un modulo vuole saperne il meno

possibile (black box).

• Per essere esteso, un modulo deve rivelare

qualcosa in più (white box).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Cinque Principi (5)

• Scelta Singola (Single Choice Principle)

– Ogni volta che ci sono un certo numero di

alternative, al più un modulo deve conoscerne

l’elenco.

• Quando “i casi sono due” nella versione

1.0, si può star sicuri che “i casi sono

quindici” nella versione 2.0.

– Per salvaguardare continuità ed estendibilità.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Tipi di Dato

• Al livello più basso, programmi e dati non

sono 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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Tipi di Dato

• Curiosamente, anche alcuni linguaggi di

livello molto alto rappresentano dati e

programmi 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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Tipi di Dato

• “Si è tanto ciechi nell’oscurità totale

quanto nella luce totale”.

• Modelli troppo omogenei riducono la

comprensibilità e la decomponibilità.

– Linguaggi strettamente tipati.

– Typing statico e typing dinamico.

– Tipi come categorie per la modellazione.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Tipi di Dato

• Insegnando un linguaggio, si devono

introdurre i tipi di dato supportati.

• A livello elementare, si introducono i tipi

attraverso una loro rappresentazione.

– Gli array bidimensionali in C sono memorizzati

per righe.

– Una struct in C è fatta dalla sequenza dei suoi

campi.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Tipi di Dato

• Per ottenere alcune qualità interne quali

decomponibilità e protezione, non ci si deve

basare 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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

ADT: Un Esempio

• Type: STACK

• Functions

– push: (STACK, REAL)→ STACK

– … (pop, top, remove)

• Axioms

– top(push(s, x)) = x

– …

• Preconditions

– pop require not empty

– …

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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à.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

OOP

Il concetto fondamentale della

programmazione ad oggetti è:

L’Oggetto

La Classe

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

• Def: Classe

OOP

– “Un tipo di dato astratto corredato da un

modulo che ne è un’implementazione.”

Tipo + Modulo = Classe

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Classi

- double x

- double y

- numOfPoints

Point

+ Point(double x, double y)

+ void move(double dx, double dy)

+ int howMany()

• Una classe Point,

espressa nella

notazione standard

UML (Unified

Modeling Language).

– Dati privati.

– Funzioni pubbliche.

– Membri di istanza.

– Membri di classe.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Classi in C++ ed in Java

// File Point.H

class Point { // C++

// File Point.java

class Point { // Java

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

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

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Oggetti

aPoint:Point

x:double = 1.3

y:double = -5.8

• Un oggetto in notazione

UML.

– Un oggetto è un’istanza

di una classe (che è il suo

tipo ed il modulo che ne

regola l’accesso).

– Un oggetto ha struttura

ed operazioni della sua

classe, ma specifici

valori per gli attributi.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Oggetti

Oggetti della stessa classe hanno operazioni

uguali (metodi), ma dati diversi.

• Un metodo può accedere ai dati dell’oggetto

(parte privata del modulo).

• Come si indica al metodo su quale oggetto

agire ?

– Istanza corrente di un oggetto (this o self).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Chiamata a Metodo

Meccanismo fondamentale di computazione della OOP

Risultato

res = obj.meth(par)

Oggetto Target

Operatore di accesso

Nome del metodo

Lista di parametri

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Oggetti in C++ e Java

// File main.cc - C++

#include “Point.H”

// File Main.java - Java

import Point;

void main(int argc, char *argv[]) {

Point p(1,2); // Oggetto locale

Point* pptr; // Puntatore

class Main {

public static

void main(String[] args) {

pptr = new Point(0,0); // Alloca

p.move(-4,7); // Method call

pptr->move(3,-6); // Method call

Point p; // Riferimento nullo

p = new Point(0,0); // Alloca

p.move(-5,-9); // Method call

delete pptr;

pptr = 0;

} // p distrutto automaticamente

}

}

p = null; // Garbage collection

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Oggetti in C++ e Java

// File point.cc - C++

#include “Point.H”

// File Point.java

class Point { // Java

// Implementazione separata

void Point::move(double dx,

double dy) {

// Implementazione in linea

public void 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 - all’interno di un

// metodo e` il riferimento

// all’istanza corrente

this.myX = this.myX + dx;

}

// ‘this’ si puo` omettere

m_y = m_y + dy;

}

// ‘this’ si puo` omettere

myY = myY + dy

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Ciclo di Vita degli Oggetti

• Ogni classe impone dei vincoli su tutti i suoi

oggetti.

– Precondizioni all’ingresso dei metodi.

– Postcondizioni all’uscita dei metodi.

– Invarianti che devono sempre valere.

• Gli oggetti devono gestire risorse durante la

loro esistenza (memoria, file, entità del S.O.).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Ereditarietà

Shape

Shape

Persistent

Circle Triangle Square

Circle Triangle Square

• Esprime una relazione is-a fra due classi.

– Relazione gerarchica ed aciclica.

• Può essere singola o multipla.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Ereditarietà

• L’ereditarietà è un meccanismo base della

OOP, ma ha più aspetti diversi.

• La prima distinzione da fare è tra

ereditarietà di interfaccia ed ereditarietà di

implementazione.

– Tipo + Modulo = Classe.

– Subtyping + Inheritance = Subclassing.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Subtyping

• Se le classi sono tipi, l’ereditarietà è una

relazione tra tipi, che chiamiamo subtyping.

• Se il tipo D è un sotto-tipo del tipo B, cosa

significa D is-a B ?

– Tutto quello che posso fare ad un B lo posso

fare anche ad un D.

⇒ Principio di Sostituibilità di Liskov.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Inheritance

• L’ereditarietà è una relazione tra moduli,

che chiamiamo (solo qui) inheritance.

• L’inheritance garantisce l’Open/Closed

Principle.

– 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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Ereditarietà in Java

• Java supporta quasi completamente

l’ereditarietà.

– Inheritance singola.

– Subtyping multiplo.

– Invocazione dei metodi ereditati tramite il

riferimento super.

• In Java si può avere:

– Subtyping puro (interfacce).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Polimorfismo

• Il polimorfismo è una caratteristica

essenziale dei linguaggi orientati agli

oggetti.

• Permette di trattare in modo uniforme tipi

“simili”, ma rispettandone le differenze.

• Spesso il polimorfismo si usa per garantire

il Single Choice Principle.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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

+ void draw(GC& aCtx)

Circle Triangle Square

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

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Polimorfismo

• Quando tipo statico ≠ tipo dinamico, se le

due classi hanno versioni diverse di una

stessa funzione membro, sorge un problema

di binding.

– Static binding (o early binding) ⇒ tipo statico.

– Dynamic binding (o late binding) ⇒ tipo

dinamico.

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

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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 funzione

fa la cosa giusta!

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Polimorfismo e Class Design

• Il progettista della classe base deve decidere

quali funzioni membro devono essere

polimorfe, 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?”

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Polimorfismo in C++ e Java

Come dichiarare

una funzione f() in

Java e C++, a

seconda di come (e

se) si può ridefinire

nelle sottoclassi

Non Ridefinibile

Implementazione

di Default

Astratta

Java

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

C++

void f() virtual void f() virtual void f() = 0

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Gestione delle Eccezioni

• Le condizioni di errore sono al centro di un

dilemma:

– Nella maggior parte dei casi non si presentano.

– Quando si presentano, possono avere risultati

catastrofici.

• Serve una soluzione che consenta di trattare

gli errori, senza inquinare il codice eseguito

nei casi normali.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Gestione delle Eccezioni

• Sia C++ che Java forniscono un

meccanismo flessibile per gestire le

condizioni di errore:

La Gestione delle

Eccezioni

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

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 chiave

throw.

• I gestori delle eccezioni sono introdotti

dalla parola chiave catch.

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Eccezioni in C++

Program.cc

#include “library.h”

void main() {

try {

f(); // Può tirare un’ecc.

}

catch(Exception& e) {

// Gestisce l’eccezione

}

}

Library.cc

void f() {

X localX;

g();

}

void g() {

Y localY;

h();

}

void h() {

if(something_wrong())

throw Exception(“Argh”);

}

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Eccezioni in Java

Program.java

import Library;

public class Program {

}

}

// ...

public static void main() {

try {

}

f(); // Può tirare un’ecc.

catch(Exception e) {

}

// Gestisce l’eccezione

Library.java

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”);

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti


UNIVERSITÀ DEGLI STUDI DI PARMA

Dipartimento di Ingegneria dell’Informazione

COMPUTER

ENGINEERING

Eccezioni in C++ e Java

• Java obbliga ogni metodo a dichiarare le

eccezioni tirate (opzionale in C++).

• In C++ gli oggetti locali vengono distrutti

mentre l’eccezione si propaga.

• Java ha la parola chiave finally per

eseguire codice comune ai casi normali ed

eccezionali (il C++ sfrutta i distruttori).

G. Rimassa - Progettazione e Programmazione Orientata agli Oggetti

More magazines by this user
Similar magazines