TEORIA PROGRAMMAZIONE II – IL PARADIGMA OO

POSSIBILI DOMANDE

1. Descrivere in maniera esaustiva le relazioni di ereditarietà, aggregazione e composizione nel

paradigma OO. Riportare e commentare un esempio in UML per ciascuna relazione.

2. Definire la relazione di ereditarietà per implementazione nel paradigma OO. Fornire un esempio

UML di classi definite usando la relazione di ereditarietà per implementazione. Tradurre tale

esempio in Java.

3. Descrivere in maniera esaustiva classi astratte e interfacce nel paradigma OO. Spiegare quando è

appropriato usare entrambe.

4. Descrivere in maniera esaustiva tutte le forme di polimorfismo definite nel paradigma OO fornendo

anche esempi.

5. Descrivere il concetto di metaclasse nel paradigma OO. Commentare poi il concetto di metaclasse

in Java fornendone esempi di utilizzo.

6. Definire le relazioni di aggregazione e composizione nel paradigma OO. Descrivere entrambe in

maniera esaustiva. Fornire esempi di entrambe in UML.

7. Illustrare le differenze tra ereditarietà per estensione, variazione funzionale, restrizione e

implementazione e il rapporto con il principio di sostituibilità. Esemplificare la risposta.

8. Fornire le definizioni di classi astratte, classi finali, metaclassi e interfacce nel paradigma OO. Fornire

esempi delle stesse in UML.

9. Descrivere in maniera esaustiva il polimorfismo nel paradigma OO. Riportare e commentare esempi

per ciascuna forma di polimorfismo.

10. Descrivere in maniera esaustiva cosa sono gli stereotipi UML “BCE” applicati alle classi. Per ciascuna

delle 3 classi stereotipabili specificare quali concetti modella, quali sono le caratteristiche peculiari e

un esempio di classe UML con l’appropriata notazione.

11. Relazione di aggregazione tra classi. Spiegare cosa è e come si descrive in linguaggio UML. Fornire

un esempio in codice JAVA che realizzi tale relazione. Spiegare perché, data la sua implementazione,

non rispetta la regola di non condivisione.

12. Descrivere le forme di polimorfismo individuate dalla classificazione di Cardelli e Wegner nel

paradigma OO fornendo esempi appropriati per ciascuna di esse.

13. Descrivere il principio di sostituibilità nel paradigma OO e come si rapporta alle diverse forme di

ereditarietà e al polimorfismo per inclusione.

14. Descrivere classi astratte, classi final e interfacce nel paradigma OO. Fornire esempi in UML.

Mostrare similarità e differenze tra i concetti enunciati.

15. Descrivere in maniera esaustiva la relazione di ereditarietà nel paradigma OO. Fornire esempi in

UML.

16. Definire in maniera esaustiva (con esempi in UML) classi astratte, classi foglia, interfacce. Descrivere

il polimorfismo per inclusione e il suo rapporto con principio di sostituibilità e tipo di legame.

Riportare esempi significativi di quanto descritto.

17. Descrivere i problemi legati alla ereditarietà multipla nel paradigma OO. Descrivere tramite un

esempio UML come modellare alternativamente la ereditarietà multipla. Commentare l'esempio.

18. Descrivere classi astratte e interfacce nel paradigma OO. Evidenziare similarità e differenze tra i due

modelli. Formulare esempi di entrambe in UML.

TEORIA

Stereotipi di classi

L’individuazione delle classi dipende sia dalla realtà che si vuole modellare, sia dalla necessità di individuare

il giusto bilanciamento dei compiti da assegnare, al fine di rendere il sistema software altamente

mantenibile e riutilizzabile. Una metodologia suggerisce di classificare le classi secondo i seguenti gruppi:

•classi entità

•classi di confine

Anteprima parziale del testo

Scarica Programmazione 2 - Paradigma Object Oriented e più Appunti in PDF di Programmazione Java solo su Docsity!

TEORIA PROGRAMMAZIONE II – IL PARADIGMA OO

POSSIBILI DOMANDE

Descrivere in maniera esaustiva le relazioni di ereditarietà, aggregazione e composizione nel paradigma OO. Riportare e commentare un esempio in UML per ciascuna relazione.
Definire la relazione di ereditarietà per implementazione nel paradigma OO. Fornire un esempio UML di classi definite usando la relazione di ereditarietà per implementazione. Tradurre tale esempio in Java.
Descrivere in maniera esaustiva classi astratte e interfacce nel paradigma OO. Spiegare quando è appropriato usare entrambe.
Descrivere in maniera esaustiva tutte le forme di polimorfismo definite nel paradigma OO fornendo anche esempi.
Descrivere il concetto di metaclasse nel paradigma OO. Commentare poi il concetto di metaclasse in Java fornendone esempi di utilizzo.
Definire le relazioni di aggregazione e composizione nel paradigma OO. Descrivere entrambe in maniera esaustiva. Fornire esempi di entrambe in UML.
Illustrare le differenze tra ereditarietà per estensione, variazione funzionale, restrizione e implementazione e il rapporto con il principio di sostituibilità. Esemplificare la risposta.
Fornire le definizioni di classi astratte, classi finali, metaclassi e interfacce nel paradigma OO. Fornire esempi delle stesse in UML.
Descrivere in maniera esaustiva il polimorfismo nel paradigma OO. Riportare e commentare esempi per ciascuna forma di polimorfismo.
Descrivere in maniera esaustiva cosa sono gli stereotipi UML “BCE” applicati alle classi. Per ciascuna delle 3 classi stereotipabili specificare quali concetti modella, quali sono le caratteristiche peculiari e un esempio di classe UML con l’appropriata notazione.
Relazione di aggregazione tra classi. Spiegare cosa è e come si descrive in linguaggio UML. Fornire un esempio in codice JAVA che realizzi tale relazione. Spiegare perché, data la sua implementazione, non rispetta la regola di non condivisione.
Descrivere le forme di polimorfismo individuate dalla classificazione di Cardelli e Wegner nel paradigma OO fornendo esempi appropriati per ciascuna di esse.
Descrivere il principio di sostituibilità nel paradigma OO e come si rapporta alle diverse forme di ereditarietà e al polimorfismo per inclusione.
Descrivere classi astratte, classi final e interfacce nel paradigma OO. Fornire esempi in UML. Mostrare similarità e differenze tra i concetti enunciati.
Descrivere in maniera esaustiva la relazione di ereditarietà nel paradigma OO. Fornire esempi in UML.
Definire in maniera esaustiva (con esempi in UML) classi astratte, classi foglia, interfacce. Descrivere il polimorfismo per inclusione e il suo rapporto con principio di sostituibilità e tipo di legame. Riportare esempi significativi di quanto descritto.
Descrivere i problemi legati alla ereditarietà multipla nel paradigma OO. Descrivere tramite un esempio UML come modellare alternativamente la ereditarietà multipla. Commentare l'esempio.
Descrivere classi astratte e interfacce nel paradigma OO. Evidenziare similarità e differenze tra i due modelli. Formulare esempi di entrambe in UML.

TEORIA

Stereotipi di classi L’individuazione delle classi dipende sia dalla realtà che si vuole modellare, sia dalla necessità di individuare il giusto bilanciamento dei compiti da assegnare, al fine di rendere il sistema software altamente mantenibile e riutilizzabile. Una metodologia suggerisce di classificare le classi secondo i seguenti gruppi:

classi entità
classi di confine

classi di controllo. Tale suddivisione permette il partizionamento del sistema in tre componenti differenti: dominio, vista e controllo. CLASSI ENTITÀ Una classe entità permette di modellare sia entità astratte sia entità concrete necessarie per eseguire compiti interni al sistema. Tali classi sono:
indipendenti dal contesto: non sono sensibili alle modalità con cui il contesto comunica con il sistema;
indipendenti dall’applicazione: possono essere riusate in differenti applicazioni, che si basano sullo stesso dominio. Esempio: in una applicazione relativa all’offerta didattica potremo individuare le seguenti classi entità: Course (corso), ProfessorInformation (docente) e CourseOffering (offerta del corso). CLASSI DI CONFINE Le classi di confine gestiscono la comunicazione fra i dintorni del sistema e l’interno del sistema, risultano quindi dipendenti dal contesto applicativo. Esempio: si rende necessaria un’altra classe denominata AddACourseOffering (AggiuntaOffertaCorso) che si occupi dell’inserimento di una nuova istanza di CourseOffering da parte dell’attore Professor. CLASSI DI CONTROLLO Le classi di controllo coordinano gli eventi necessari a supportare la dinamica prevista in uno o più scenari di utilizzo del sistema software, pertanto sono tipicamente dipendenti dall’applicazione. Esempio: occorre una classe di controllo per gestire il flusso degli eventi: ProfessorCourseManager. Ereditarietà Una classe è considerata come un repertorio di conoscenza a partire dal quale è possibile definire altre classi più specifiche, che completano le conoscenze della loro classe madre. Una sottoclasse è una specializzazione di una classe, detta superclasse, dalla quale ne deriva gli attributi e i metodi. Ci sono diverse forme di ereditarietà. EREDITARIETÀ PER ESTENSIONE La sottoclasse introduce delle caratteristiche non presenti nella superclasse e non applicabili a istanze di essa. La visibilità degli attributi e delle operazioni ereditate non è modificata. La specializzazione per estensione permette di sviluppare del codice estendibile. EREDITARIETÀ PER VARIAZIONE FUNZIONALE La sottoclasse ridefinisce un metodo (overriding) modificandone l’implementazione ma non la segnatura. La ridefinizione non è incrementale, quindi i cambiamenti del metodo originale devono essere riportati anche nei metodi ridefiniti. Essendo un’attività a carico del programmatore, non c’è alcuna garanzia che questo avvenga, introducendo così degli errori. Una soluzione che potrebbe permetterne l’uso e mitigarne gli effetti, sarebbe quello di adottare qualche accorgimento nella realizzazione dei metodi per i quali si riconosce in fase progettuale una incrementalità al cambiamento. Ad esempio, il metodo ridefinito potrebbe richiamare, mediante il costrutto super , il metodo della superclasse. Anche in questo tipo di ereditarietà, la visibilità degli attributi e delle operazioni ereditate dalla superclasse non è modificata. EREDITARIETÀ PER RESTRIZIONE Una sottoclasse restringe il campo di azione della superclasse, in quanto le istanze della sottoclasse soddisfano vincoli che non sono soddisfatti da istanze della superclasse. Nel costruttore della sottoclasse è necessario specificare quali sono le restrizioni da apportare.

In Java tutte le classi ereditano da Object. Inoltre Object dispone di un metodo getClass() che permette di restituire per ogni oggetto una istanza della classe Class che descrive la classe di appartenenza dell’oggetto. Questo modello serve per realizzare il meccanismo di riflessione che permette a un oggetto di stabilire al run-time a quale classe esso stesso appartiene. <> è lo stereotipo usato in UML per indicare una metaclasse. Aggregazione di oggetti Spesso un oggetto è ottenuto aggregando altri oggetti. Una composizione di oggetti può essere rappresentata permettendo alle variabili di istanza di una classe di puntare a oggetti di altre classi. La relazione che si stabilisce in questo modo fra le classi è detta di aggregazione o composizione. Una classe A si dice essere in relazione di aggregazione con una classe B quando alcune istanze di B contribuiscono a formare una parte delle istanze di A. Grady Brooch suggerisce l’uso dell’aggregazione nelle seguenti situazioni:

contenimento fisico
appartenenza
composizione funzionale. L’aggregazione non implica una dipendenza esistenziale. Le aggregazioni sono associazioni deboli fra parti e intero. Questo significa che le parti possono esistere senza l’intero. La composizione Un’associazione forte fra parti e intero è detta composizione. La composizione comporta una dipendenza esistenziale, in quanto le parti non esistono senza il contenitore. Ciò presuppone che:
creazione e distruzione delle parti avvengano nel contenitore
i componenti non siano parti di altri oggetti La composizione è caratterizzata dalla regola di “non condivisione” in quanto, benché una classe possa essere componente di molte classi, ogni sua istanza può essere componente di un solo oggetto. Ereditarietà VS Aggregazione Nell’ereditarietà ogni oggetto della classe specializzata contiene tutti i campi definiti nella superclasse e può accedervi direttamente. Nella aggregazione/composizione ogni oggetto contiene un campo per ogni classe aggregata e può accedere ai suoi campi esclusivamente tramite i metodi. L’ereditarietà corrisponde a una relazione di generalizzazione, vale quindi il polimorfismo di inclusione, cioè un oggetto della sottoclasse può essere utilizzato come istanza della superclasse, mentre ciò non è vero nel caso della composizione. La scelta di progetto è totalmente diversa: con l’ereditarietà possiamo definire una gerarchia di classi e permette di riutilizzare tutti i metodi delle superclassi. Mentre, il meccanismo di aggregazione/composizione è usato quando si vogliono utilizzare i servizi di una classe, ma non la sua interfaccia. POLIMORFISMO Con il termine polimorfismo si intende la possibilità di associare a una operazione diverse realizzazioni o morfismi. Una classificazione dei diversi meccanismi di polimorfismo è data da Cardelli e Wegner. POLIMORFISMO UNIVERSALE Può operare su un numero illimitato di tipi, i morfismi sono generati automaticamente e c’è una base unificante, comune a tutti i diversi morfismi, che può assumere l’entità polimorfa.

 Parametrico: una funzione polimorfa ha un parametro di tipo, che determina il tipo dell’argomento

per ciascuna applicazione della funzione. Le funzioni che esibiscono il polimorfismo parametrico sono anche dette funzioni generiche. Una funzione generica può lavorare su argomenti di molti tipi, generalmente esibendo lo stesso comportamento indipendentemente dal tipo dell’argomento. Un esempio di funzioni generiche è la funzione template del C++. Ad esempio, possiamo definire una funzione max generica:

template ITEM max(ITEM n1, ITEM n2){ // codice che calcola il massimo di n1 e n }

 Di inclusione: Si ha polimorfismo di inclusione se un oggetto appartiene ad una classe e a tutte le

sue superclassi. Si manifesta in almeno due modi:  assegnando un’istanza di una sottoclasse ad una variabile del tipo della superclasse  invocando un metodo di una superclasse su una istanza di sottoclasse. L’utilizzo più interessante si ha quando le invocazioni dei metodi su oggetti di classi diverse (ma gerarchicamente correlate) produce un comportamento differente, anche se la definizione della funzione è unica. Ciò dipende dal tipo di legame statico/dinamico fra identificatore di funzione e relativa realizzazione. Si parla di legame statico se i legami (binding) vengono definiti in fase di compilazione; si parla di legame dinamico se i legami vengono definiti in fase di esecuzione. POLIMORFISMO AD HOC Può operare su un numero finito di tipi, i morfismi sono generati manualmente, non c’è una base comune a tutti i morfismi.

 Coercizione: è il meccanismo di conversione implicita operata da un compilatore per applicare un

operatore definito per oggetti di tipo T1 anche a oggetti di tipo T2. Esempio. La somma è definita per valori reali, ma la si può usare anche per insiemi di tipi più grandi. Altri esempi, in JAVA, sono l’autoboxing di un int in un Integer. La coercizione opera ad un livello semantico, cioè cambiando la rappresentazione del dato.

 Overloading : si ha quando si usa lo stesso identificatore per metodi differenti e si ricorre ad

informazioni di contesto per decidere a quale metodo si sta facendo riferimento. La disambiaguazione necessaria per una corretta compilazione si basa sul tipo degli argomenti del metodo o sulla classe dell’oggetto a cui si richiede il servizio.

Programmazione 2 - Paradigma Object Oriented, Appunti di Programmazione Java

Documenti correlati

Anteprima parziale del testo

Scarica Programmazione 2 - Paradigma Object Oriented e più Appunti in PDF di Programmazione Java solo su Docsity!

TEORIA PROGRAMMAZIONE II – IL PARADIGMA OO

POSSIBILI DOMANDE

TEORIA

 Parametrico: una funzione polimorfa ha un parametro di tipo, che determina il tipo dell’argomento

 Di inclusione: Si ha polimorfismo di inclusione se un oggetto appartiene ad una classe e a tutte le

 Coercizione: è il meccanismo di conversione implicita operata da un compilatore per applicare un

 Overloading : si ha quando si usa lo stesso identificatore per metodi differenti e si ricorre ad