Progettazione e Programmazione

Orientata agli Oggetti

Slide 1

Orientata agli Oggetti

In Collaborazione con Paola Turci (Università di Parma)

Paradigmi di Programmazione

� Un linguaggio supporta uno stile di programmazione se possiede funzioni che ne rendono conveniente (semplice, sicuro, efficiente) l’uso:

• librerie standard

Slide 2

• librerie standard• ambienti di programmazione• controlli in compilazione e/o in esecuzione

Programmazione Procedurale

� Definire le procedure

I linguaggi supportano questo paradigma se

Slide 3

I linguaggi supportano questo paradigma se forniscono la possibilità di:

• passare argomenti • restituire valori

Programmazione Modulare

� Definire i moduli

Realizzazione Organizzazionedelle procedure dei dati

Slide 4

delle procedure dei dati

• Modulo: insieme di procedure poste in relazione ai dati che utilizzano (pila, lista, ...)

• Risulta sufficiente lo stile di programmazione procedurale se non esiste la necessità di definire un insieme di procedure con dati associati

Tipo di Dato Astratto

� Definire tipi di dato e insieme completo di operazioni

• I tipi di dato astratto (o tipi definiti dall’utente) presentano caratteristiche simili ai tipi di dato predefiniti dal linguaggio• visibilità, controlli in fase di compilazione, ecc.

• Se non esiste la necessità di più istanze di un tipo di dato

Slide 5

• Se non esiste la necessità di più istanze di un tipo di dato astratto, risulta sufficiente lo stile di programmazione con “dati nascosti” (programmazione modulare)

• Il tipo di dato astratto è, in generale, poco flessibile; non è possibile adattarlo ad un nuovo utilizzo, se non modificandone la definizione.

Paradigma di Programmazione ad Oggetti

� Occorre uno strumento che consenta di operare una distinzione tra le proprietà di tipi di dati più generali e le proprietà specifiche di singoli sottotipi • Nota: se non vi è alcuna similitudine tra i tipi del problema è sufficiente

l’astrazione di dato.

Slide 6

Programmazione Orientata agli Oggetti

� Analisi del problema in termini di concetti (oggetti) che lo costituiscono (modello concettuale del problema)

Paradigma di Programmazione ad Oggetti

� Intende promuovere nei programmi caratteristiche ritenute fondamentali:• Modularità • Information hiding (incapsulamento)• Riusabilità• Progettazione incrementale• Rapida prototipizzazione

Slide 7

• Rapida prototipizzazione

� I linguaggi di programmazione orientati agli oggetti sono accomunati da tre fattori:

Incapsulamento - Estendibilità - Polimorfismo

• Incapsulamento, consente di nascondere i dati ed esporre solo (alcuni) metodi

• Estendibilità, introduce il concetto di classificazione degli oggetti.• Polimorfismo, è caratterizzato dalla frase “un’interfaccia più metodi”.

Gli Oggetti

� Un oggetto è un’area di memoria inizializzata� Un oggetto è un’aggregazione software di attributi

(stato) e relativi metodi/servizi (comportamento)� Un oggetto è un’astrazione che descrive oggetti

Slide 8

� Un oggetto è un’astrazione che descrive oggetti reali del problema e concetti astratti che fanno parte della sua soluzione

Metodi (pubblici)

Attributi + Metodi(dettagli implementativi privati)

Concetto di Classe

� “Entitá”/tipo che definisce le proprietà (attributi, metodi) che accomunano una famiglia di oggetti:• Uno stesso insieme di operazioni

Slide 9

• Una stessa struttura esterna • Uno stesso comportamento

� Consente la creazione di istanze (oggetti)

� Riunisce proprietà dei tipi di dato e dei moduli

Classi e Istanze (Oggetti)

� Un oggetto è un’istanza di una classe (che è il suo tipo ed il modulo che ne regola l’accesso). • Istanziare un oggetto di una determinata classe significa:

• Dichiarare una variabile di quel tipo• Allocare dinamicamente spazio per un oggetto di quel tipo

Slide 10

• Allocare dinamicamente spazio per un oggetto di quel tipo

• Oggetti della stessa classe hanno operazioni uguali (metodi), ma specifici valori per gli attributi (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).

Chiamata a Metodo

res = obj.meth(par)

Meccanismo fondamentale di computazione della OOP

Slide 11

res = obj.meth(par)

Programma = Rete di Oggetti

� Tutto è un oggetto• Ogni componente concettuale del problema viene rappresentata da un

oggetto.

• Un programma è costituito da un insieme di oggetti che si scambiano messaggi (ordini e richieste).

Slide 12

• Ogni oggetto è fatto di altri oggetti (o di tipi base).

� I programmi saranno costituiti da una rete di oggetticonnessi da relazioni client-server.

� La rete che rappresenta l’architettura del programma avrà spesso una struttura gerarchica.

Classi

� Una classe Point, espressa nella notazione standard UML (Unified Modeling Language).

Point- double x- double y- numOfPoints

Slide 13

Language).• Dati privati.

• Funzioni pubbliche.

• Membri di istanza.

• Membri di classe.

- numOfPoints

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

Oggetti

� Un oggetto in notazione UML.• Un oggetto è un’istanza

di una classe (che è il suo tipo ed il modulo che

aPoint:Point

Slide 14

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.

x:double = 1.3y:double = -5.8

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

Slide 15

interfaccia ed ereditarietà di implementazione .

Subtyping

� Se le classi sono tipi, l’ereditarietà è una relazione tra tipi, che chiamiamo subtyping.

� Se il tipo C è un sotto-tipo del tipo B, cosa significa C is-a B ?

Slide 16

significa C is-a B ?• Tutto quello che posso fare ad un B lo posso fare

anche ad un C .

⇒ Principio di Sostituibilità di Liskov.

Inheritance

� L’ereditarietà è una relazione tra moduli, che chiamiamo inheritance.

� L’inheritance garantisce l’Open/Closed Principle.• Un sotto-modulo avrà accesso privilegiato al modulo

Slide 17

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

Sintassi per l’ereditarietà in Java

Shape

Estensione singola

public abstract class Shape {

// …

}

class Square extends Shape {

// …

Slide 18

Shape

Circle Triangle Square

// …

}

Sintassi per l’ereditarietà in Java

public interface Shape {

// …

}

class Square implements Shape {

// …

}«interface»

Shape

Implementazione singola

Slide 19

}Shape

Circle Triangle Square

Sintassi per l’ereditarietà in Java

public abstract class Shape {

// ...

}

public interface Persistent {

// ...

Derivazione multipla

Shape«interface»

Persistent

Slide 20

// ...

}

class Square extends Shape

implements Persistent {

// ...

}

Circle Triangle Square

Persistent

Gerarchie di ereditarietà

Object

Component

Button Check box C hoice List Scrol lbar

… …

Gen

erico

Slide 21

Canvas Container Label TextC om ponent

TextArea TextField Panel

Applet

ScrollPane Window

Dialog Frame

FileDialog

S

pecializzato

Polimorfismo

� Il polimorfismo è una caratteristica essenziale dei linguaggi orientati agli oggetti.

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

Slide 22

ma rispettandone le differenze.� Spesso il polimorfismo si usa per garantire il

Single Choice Principle.

Polimorfismo

� Si individuano delle operazioni comuni per interfaccia, ma diverse per comportamento.

� Una classe dichiara la funzione e delle sottoclassi ne forniscono diverse implementazioni.

Slide 23

Shape

Circle Triangle Square

+ void draw(GC& aCtx)

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

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 :

Slide 24

Esiste un tipo statico ed un tipo dinamico :

Tipo statico Tipo statico tipo del riferimento,

dichiarato a compile time

Tipo dinamico Tipo dinamico tipo dell’oggetto

puntato a run time

Relazioni part–of

� Tra gli oggetti spesso sussiste una relazione part–of(detta anche di composizione ).

Slide 25

Delega

� Attraverso la relazione part–of è possibile realizzare un importante comportamento: la delega (delegation). • Una classe demanda ad un’altra classe alcune parti del

servizio che la prima deve rendere disponibile.

Modularità nel codice: ogni classe si occupa di

Slide 26

� Modularità nel codice: ogni classe si occupa di realizzare una specifica funzionalità, senza mescolare aspetti concettualmente diversi tra loro

� Nel disegnare l’architettura di un programma dobbiamo decidere quale tipo di relazione utilizzare per connettere le nostre classi:

is–a (ereditarietà) o part–of (delega)

OOP

� Le tecnologie OO permeano tutto il ciclo di sviluppo del software• OOA - (Object Oriented Analysis)

• OOD - (Object Oriented Design)

• OOP - (Object Oriented Programming)

Slide 27

• OOP - (Object Oriented Programming)

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

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; funzionalità

Slide 28

• Qualità Esterne (viste dal cliente/utente; funzionalità fornite dal sistema)• Usabilità, Correttezza, Efficienza,...

• Qualità Interne (viste dallo sviluppatore; legate allo sviluppo del software, non sono visibili all’utente)• Mantenibilità, Estendibilità, ...

• Esiste ovviamente un collegamento/relazione tra le due categorie • Non è possibile rilasciare all’utente un software di qualità se

il sistema non si basa su buone qualità interne

Evoluzione Del Software

� Il costo del software è principalmente dovuto al mantenimento/evoluzione

Slide 29

Breakdown ofmaintenancecosts. Source:[Lientz 1980]

Dati validi ancora oggi

Modularità

� La modularità viene spesso considerata una qualità interna, ma in realtà non è chiaramente definita.

� Si potrebbe definire informalmente così:

Slide 30

� Si potrebbe definire informalmente così:

Un sistema è modulare se i suoi moduli sono “ben strutturati” e “ben collegati insieme”.

⇒ Cerchiamo delle proprietà più precise.

Modularità

� Per descrivere la modularità e mostrare come essa supporti le qualità interne del software, vedremo:• Cinque Criteri (per valutarla)

Slide 31

• Cinque Criteri (per valutarla)• Cinque Regole (per garantirla)• Cinque Principi (per praticarla)

Cinque Criteri (1)

� Decomponibilità• Un sistema modulare può essere decomposto in parti più piccole,

connesse da una struttura semplice, abbastanza indipendenti da lavorarci separatamente.

Slide 32

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.

Slide 33

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.

Slide 34

Cinque Criteri (4)

� Continuità• Un sistema modulare è tale che ad un cambiamento “piccolo” nelle

specifiche del sistema corrisponda un cambiamento “piccolo” nell’implementazione.

Slide 35

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.

Slide 36

Cinque Regole(1)

� Corrispondenza Diretta• La struttura modulare del sistema software dovrebbe

rimanere compatibile con quella del problema che il sistema tenta di risolvere.

Slide 37

� 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 ”

Cinque Regole(2)

� Poche Interfacce• Ogni modulo dovrebbe comunicare con il minor

numero possibile di altri moduli.

� Questa regola serve a supportare la continuità e

Slide 38

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

cambiamenti si rifletteranno su pochi altri.

Cinque Regole(3)

� Interfacce Piccole• Quando due moduli comunicano, dovrebbero

scambiarsi meno informazioni possibile.

� Anche questa regola supporta la continuità e la

Slide 39

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.

Cinque Regole(4)

� Interfacce Esplicite• Il fatto che due moduli comunicano dovrebbe essere

ovvio leggendo il loro codice.

� Questa regola supporta comprensibilità,

Slide 40

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

prevedere gli effetti dei cambiamenti, ed a comporlo/scomporlo.

Cinque Regole(5)

� Information Hiding• un modulo deve dichiarare un sottoinsieme pubblico

delle sue informazioni.

� Questa regola è il cardine fondamentale per

Slide 41

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.

Cinque Principi

� I criteri e le regole visti prima esprimono (apparentemente) concetti legati più al progetto del sistema che al linguaggio di programmazione.

Slide 42

� I cinque principi seguenti, invece, si riflettono sui costrutti linguistici e sono il riflesso pratico delle regole viste prima.

Cinque Principi (1)

� Unità Linguistiche Modulari• Il linguaggio di programmazione deve supportare i

moduli come unità sintattiche.

� I criteri di modularità devono arrivare fino

Slide 43

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.

Cinque Principi (2)

� Documentazione Incorporata• La documentazione interna di un modulo deve

essere contenuta nel modulo stesso.

� Una buona documentazione incrementa la

Slide 44

Una buona documentazione incrementa la comprensibilità, ma deve essere aggiornata o diventa addirittura fuorviante e dannosa.• Mantenere la documentazione vicino al codice.

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

Slide 45

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.

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.

Slide 46

� Chi usa un modulo vuole saperne il meno possibile (black box).

� Per essere esteso, un modulo deve rivelare qualcosa in più (white box).

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.

Slide 47

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