Teoria 1 parte Flashcards
(153 cards)
1
Q
La seguente dichiarazione del metodo main è corretta:
public static main(String argoment[]) {…}
A
Falso, manca il tipo di ritorno (void).
2
Q
La seguente dichiarazione del metodo main è corretta:
public static void Main(String args[]){…}
A
Falso,l’identificatore dovrebbe iniziare con lettera minuscola
3
Q
La seguente dichiarazione del metodo main è corretta:
public static void main(String argomenU[]) {…}
A
Vero
4
Q
La seguente dichiarazione del metodo main è corretta:
public static void main(String Argomenti[]) {…}
A
Vero
5
Q
La seguente dichiarazione di classe è correYa:
public class {…}
A
Falso, manca identificatore
6
Q
La seguente dichiarazione di classe è correYa:
public Class Auto {…}
A
Falso, la parola chiave si scrive con leYera iniziale minuscola (class).
7
Q
La seguente dichiarazione di classe è correYa:
public class Auto {…}
A
Vero
8
Q
È possibile dichiarare un metodo al di fuori del blocco di codice che definisce una classe.
A
Falso
9
Q
Il blocco di codice che definisce un metodo è delimitato da due parentesi tonde.
A
Falso
10
Q
Il blocco di codice che definisce un metodo è delimitato da due parentesi quadre.
A
Falso
11
Q
Compilare ed eseguire il seguente programma:
public class HelloWorld {
public static void main(String args[]) {
}
}
cosa viene stampato?
A
Niente
12
Q
Compilare ed eseguire il seguente programma:
public class HelloWorld {
public staUc void main(String args[]) {
System.out.println(“”);
}
}
cosa viene stampato?
A
Niente, o meglio viene stampata una stringa vuota.
13
Q
public class HelloWorld {
public static void main(String args[]) {
System.out.println(args);
}
}
cosa viene stampato?
A
In questo caso l’output sarà simile al seguente:
[Ljava.lang.String;@5679c6c6
È stato “stampato un oggeYo” (chiamato args) e capiremo nei prossimi capitoli il perché abbia una
rappresentazione soYo forma di stringa così misteriosa.
14
Q
Una variabile d’istanza deve essere per forza inizializzata dal programmatore.
A
Falso, una variabile locale deve essere per forza inizializzata dal programmatore.
15
Q
Una variabile locale condivide il ciclo di vita con l’oggetto in cui è definita.
A
Falso, una variabile d’istanza condivide il ciclo di vita con l’oggetto a cui appartiene
16
Q
Un parametro ha un ciclo di vita coincidente con il metodo in cui è dichiarato: nasce
quando il metodo viene invocato, muore quando termina il metodo.
A
Vero
17
Q
Una variabile d’istanza apparUene alla classe in cui è dichiarata.
A
Falso, una variabile d’istanza apparUene ad un oggeYo istanziato dalla classe in cui è
dichiarata.
18
Q
Un metodo è sinonimo di azione, operazione.
A
Vero
19
Q
Sia le variabili sia i metodi sono uUlizzabili di solito mediante l’operatore dot, applicato ad
un’istanza della classe dove sono staU dichiarati
A
Vero
20
Q
Un costruYore è un metodo che non resUtuisce mai niente, infap ha come Upo di ritorno
void.
A
Falso
21
Q
Un costruYore viene deYo di default, se non ha parametri.
A
Falso, un costruYore viene deYo di default se viene inserito dal compilatore. Inoltre non ha
parametri, ma non tup i costruYori di default non hanno parametri.
22
Q
Un costruYore è un metodo e quindi può essere uUlizzato mediante l’operatore dot,
applicato ad un’istanza della classe dove è stato dichiarato.
A
Falso, un costruYore è un metodo speciale che ha la caraYerisUca di essere invocato una ed
una sola volta nel momento in cui si istanzia un oggeYo.
23
Q
Un package è fisicamente una cartella che conUene classi, le quali hanno dichiarato
esplicitamente di far parte del package stesso nei rispepvi file sorgente.
A
vero
24
Q
Nella dichiarazione di un metodo (non costruYore), il nome è sempre seguito dalle parentesi che
circondano i parametri opzionali, ed è sempre preceduto da un Upo di ritorno
A
Vero
25
Il seguente metodo è dichiarato in maniera correYa:
public void metodo() {
return 5;
}
Falso
26
Il seguente metodo è dichiarato in maniera correYa:
public int metodo() {
System.out.println("Ciao");
}
Falso
27
La seguente variabile è dichiarata in maniera correYa:
public int a = 0;
vero
28
La seguente variabile x è uUlizzata in maniera correYa (fare riferimento alla classe Punto definita
in questo capitolo):
Punto p1 = new Punto();
Punto.x = 10;
Falso, l’operatore dot deve essere applicato all’oggeYo e non alla classe:
Punto p1 = new Punto();
p1.x = 10;
29
La seguente variabile x è uUlizzata in maniera correYa (fare riferimento alla classe Punto definita
in questo capitolo):
Punto p1 = new Punto();
Punto.p1.x = 10;
Falso, l’operatore dot deve essere applicato all’oggeYo e non alla classe, inoltre la classe non
"conUene" l’oggeYo.
30
La seguente variabile x è uUlizzata in maniera correYa (fare riferimento alla classe Punto definita
in questo capitolo):
Punto p1 = new Punto();
x = 10;
Falso
31
Il seguente costruYore è uUlizzato in maniera correYa (fare riferimento alla classe Punto definita
in questo capitolo):
Punto p1 = new Punto();
p1.Punto();
Falso, un costruYore è un metodo speciale che ha la caraYerisUca di essere invocato una ed una
sola volta nel momento in cui si istanzia un oggeYo.
32
Il seguente costruYore è dichiarato in maniera correYa:
public class Computer {
public void Computer(){
}
}
Falso, il costruYore non dichiara Upo di ritorno e deve avere nome coincidente con la classe.
33
Il seguente costruYore è dichiarato in maniera correYa:
public class Computer {
public computer(int a) {
}
}
Falso, I nomi non si trovano
Computer e computer
34
Data la seguente classe:
public class Esercizio2N {
public String string;
public int intero;
final public String integer = "inzializzazione";
}
Quale delle seguenti affermazioni è vera (scegliere una sola affermazione)?
1. Il codice può essere compilato correYamente.
2. Il codice non può essere compilato correYamente perché non è possibile dichiarare una variabile
con nome string.
3. Il codice non può essere compilato correYamente perché non è possibile dichiarare una variabile
con nome intero.
4. Il codice non può essere compilato correYamente perché non è possibile dichiarare una variabile
di Upo String chiamandola integer.
5. Il codice non può essere compilato correYamente perché la variabile con nome integer dichiara i
modificatori in ordine inverso (dovrebbe essere prima dichiarata public e poi final).
La soluzione è la risposta numero 1, ovvero il codice può essere compilato senza errori. Non ci si
faccia trarre in inganno dai nomi delle variabili (vedi altre possibili risposte) che potrebbero portare
(volontariamente) a fare confusione. Inoltre non è un problema l’ordine in cui sono specificaU i
modificatori.
35
public class Esercizio2O {
public String toString() {
return "Esercizio2O"
staUc public void main(String argomenU[]) {
}
}
}
}
public void main() {
public staUc void metodo() {
}
C’è un solo errore in questa classe che ne impedirà la compilazione, quale?
L’errore è che manca il ; accanto allo statement del metodo toString:
36
public class Esercizio2P {
public String stringa;
public staUc void main(String argz[]) {
public int intero = 0;
}
}
C’è un solo errore in questa classe che ne impedirà la compilazione, quale?
L’errore è che non si può dichiarare public una variabile locale all’interno di un metodo.
37
Ci sono 3 errori
public class Esercizio2Q {
public staUc void main(String args) {
System.out.println("Quelo")
}
}
}
Le quadre vicino ad args
il ;
una graffa in più
38
public class Esercizio2R {
public int var1;
public int var2;
System.out.println("Esercizio 2.r");
public Esercizio2R() {
}
public Esercizio2R(int a , int b) {
var1 = b;
var2 = a;
}
public staUc void main(String args[]) {
Esercizio2R esercizio2R = new Esercizio2R (4,7);
System.out.println(esercizio2R.var1);
System.out.println(esercizio2R.var2);
}
}
Una volta eseguito, cosa stamperà questo programma?
1. Questo programma non può essere eseguito.
2. Questo programma non compila.
3. Stamperà 74.
4. Stamperà 47.
Il programma non compilerà per via dello statement:
System.out.println("Esercizio 2.r");
Che non apparUene a nessun blocco di codice di metodo.
39
public class Corso {
public String nome;
public Corso() {
}
public Corso(String n) {
nome = n;
}
}
public class Esercizio2t {
public staUc void main(String args[]) {
Corso corso1 = new Corso();
corso1.nome = "Java";
Corso corso2 = new Corso("Java");
System.out.println(corso1.nome);
System.out.println(corso2.nome);
}
}
Una volta eseguito, cosa stamperà questo programma?
1. Questo programma non può essere eseguito.
2. Questo programma non compila.
3. Stamperà:
Java
Java
4. Stamperà:
Java
Java
Java
40
public class Esercizio2u {
int c = 3;
public staUc void main(String args[]) {
int a = 1;
int b = 2, c, d = 4;
System.out.println(a+b+c+d);
}
}
Una volta eseguito, cosa stamperà questo programma?
1. Questo programma non compila.
2. Stamperà "10".
3. Stamperà: "7".
4. Stamperà: "0".
La risposta correYa è la 1. Infap la variabile locale c non è stata inizializzata.
41
Un array è un oggeYo e quindi può essere dichiarato, istanziato ed inizializzato.
Vero
42
Un array bidimensionale è un array i cui elementi sono altri array.
vero
43
Il metodo length restituisce il numero degli elementi di un array.
Falso, restituisce la dimensione
44
Un array non è ridimensionabile.
vero
45
Un array è eterogeneo di default.
Falso, è omogeneo può contenere solo elementi di un tipo
46
Un array di interi può contenere come elemenU byte, ovvero le seguenU righe di codice non
producono errori in compilazione:
int arr [] = new int[2];
byte a = 1, b = 2;
arr [0] = a;
arr [1] = b;
Vero, un byte (che occupa solo 8 bit) può essere immagazzinato in una variabile int (che occupa 32
bit).
47
package parcheggio;
public class Auto {
public String Upo;
public Auto(String t) {
Upo = t;
}
}
Affinché la seguente classe compili:
package lavoratori;
//Inserisci il codice qui
public class AuUsta {
public void guida(Auto auto) {
System.out.println("Sto guidando l'auto " + auto.Upo);
}
}
Bisogna inserire una riga di codice. Quale (o quali, potrebbero essere valide anche più di una) tra le
seguenU righe permeYerebbe alla classe AuUsta di essere compilata?
1. import parcheggio.Auto;
2. import parcheggio.*;
3. import parcheggio.lavoratori.*;
4. import parcheggio.Auto.*;
5. import parcheggio.*.Auto;
6. import lavoratori.parcheggio.Auto;
Le risposte correYe sono la 1 e la 2
48
Gli operatori unari di pre-incremento e post-incremento applicaU ad una variabile danno
lo stesso risultato, ovvero se abbiamo:
int i = 5;
sia
i++;
sia
++i;
aggiornano il valore di i a 6;
vero
49
d += 1 è equivalente a d++, dove d è una variabile double.
Vero
50
Se abbiamo:
int i = 5;
int j = ++i;
int k = j++;
int h = k--;
boolean flag = ((i != j) && ( (j <= k ) || (i <= h)) );
flag avrà valore false.
Falso, la variabile booleana flag avrà valore true
51
L'istruzione:
System.out.println(1 + 2 + "3");
stamperà 33.
Vero
52
Il costruYo switch può in ogni caso sosUtuire il costruYo if.
falso
53
Qual è l'output del seguente programma?
public class Esercizio4O {
public staUc void main(String args[]) {
int i = 99;
if (i++ >= 100) {
System.out.println(i+=10);
} else {
System.out.println(--i==99?i++:++i);
}
}
}
Scegliere tra le seguenU opzioni:
1. 10
2. 101
3. 99
4. 110
La risposta correYa è: 99.
54
Una classe dichiarata private non può essere utilizzata fuori dal package in cui è dichiarata.
Falso, private non si può uUlizzare con la dichiarazione di una classe.
55
La seguente dichiarazione di classe è scorreYa:
public staUc class Classe {...}
Vero, staUc non si può uUlizzare con la dichiarazione di una classe.
56
La seguente dichiarazione di classe è scorretta:
protected class Classe {...}
Vero, protected non è applicabile a classi.
57
La seguente dichiarazione di metodo è scorretta:
public void staUc metodo () {...}
Vero, static deve essere posizionato prima del void.
58
Un metodo staUco può uUlizzare solo variabili staUche,locali e parametri e non bisogna per
forza istanziare un oggeYo dalla classe in cui è definito per uUlizzarlo
Vero
59
Se un metodo è dichiarato staUc, non può essere chiamato al di fuori del proprio package.
Falso, staUc non è un modificatore d'accesso
60
Una classe staUc non è accessibile fuori dal package in cui è dichiarata.
Falso, staUc non è applicabile a classi.
61
Un metodo protected viene ereditato in ogni soYoclasse qualsiasi sia il suo package.
Vero
62
Una variabile staUc viene condivisa da tuYe le istanze della classe a cui apparUene.
Vero
63
Se non anteponiamo modificatori ad un metodo, il metodo è accessibile solo all'interno
dello stesso package.
Vero
64
Un metodo staUco deve essere per forza pubblico.
Falso
65
L'implementazione dell'incapsulamento implica l'uUlizzo delle parole chiave set e get.
Falso
66
Per uUlizzare le variabili incapsulate di una superclasse in una soYoclasse bisogna
dichiararle almeno protected.
Falso
67
I metodi dichiaraU privaU non vengono ereditaU nelle soYoclassi.
Vero
68
Un inizializzatore d'istanza viene invocato prima di ogni costruYore.
Vero
69
Una variabile privata risulta disponibile (tecnicamente come se fosse pubblica) tramite
l'operatore dot, a tuYe le istanze della classe in cui è dichiarata.
vero
70
La parola chiave this permeYe di referenziare i membri di un oggeYo che sarà creato solo al
runUme all'interno dell'oggeYo stesso.
vero
71
La parola chiave this è sempre facoltaUva.
Falso
72
La parola chiave this permeYe di chiamare un costruYore, da un metodo della stessa classe
con la sintassi this(). È necessario però che questa sia la prima istruzione del metodo.
Falso, solo un altro costruYore della stessa classe può usare quella sintassi.
73
Il singleton paYern permeYe di creare una classe che può essere istanziata una sola volta.
vero
74
Quali delle seguenU dichiarazioni di import staUci sono valide?
1. import staUc java.lang.*;
2. import staUc java.lang.Math;
3. import staUc java.lang.Math.*;
4. import staUc java.lang.Math.PI;
5. import staUc java.lang.Math.random();
6. import staUc java.lang.Math.random;
Le dichiarazioni correYe sono la 3, la 4 e la 6.
75
Qual è l'output del seguente programma?
public class InitTest {
{
System.out.println("IniUalizer");
}
staUc {
System.out.println("StaUc IniUalizer");
}
public InitTest () {
System.out.println("Constructor");
}
public void method() {
System.out.println("Method");
}
public staUc void staUcMethod() {
System.out.println("StaUc Method");
new InitTest().method();
}
public staUc void main(String args[]) {
InitTest.staUcMethod();
}
}
StaUc IniUalizer
StaUc Method
IniUalizer
Constructor
Method
76
L'implementazione dell'ereditarietà implica scrivere sempre qualche riga in meno.
Falso, il processo di generalizzazione implica scrivere una classe in più e ciò non sempre
implica scrivere qualche riga in meno.
77
La seguente dichiarazione di classe è scorreYa:
public final class Classe extends AltraClasse {...}
Falso
78
La parola chiave super permeYe di chiamare metodi e costruYori di superclassi. La parola
chiave this consente di chiamare metodi e costruYori della stessa classe in cui ci si trova.
vero
79
L'ereditarietà mulUpla non esiste in Java perché non esiste nella realtà.
Falso, l'ereditarietà mulUpla esiste nella realtà, e in Java esiste in una versione soW perché si
eredita solo la parte funzionale.
80
Un'interfaccia funzionale è un'interfaccia che dichiara un unico metodo di default.
Falso, è un'interfaccia che dichiara un unico metodo astraYo.
81
Una soYoclasse è più "grande" di una superclasse (nel senso che solitamente aggiunge
caraYerisUche e funzionalità nuove rispeYo alla superclasse).
vero
82
Supponiamo di sviluppare un'applicazione per gesUre un torneo di calcio. Esiste ereditarietà
derivata da specializzazione tra le classi Squadra e Giocatore.
Falso, una squadra non "è un" giocatore, né un giocatore "è una" squadra. Semmai una
squadra "ha un" giocatore ma questa non è la relazione di ereditarietà. Si traYa infap della
relazione di associazione.
83
Supponiamo di sviluppare un'applicazione per gesUre un torneo di calcio. Esiste ereditarietà
derivata da generalizzazione tra le classi Squadra e Giocatore.
Vero, infap entrambe le classi potrebbero estendere una classe Partecipante
84
In generale, se avessimo due classi Padre e Figlio, non esisterebbe ereditarietà tra queste
due classi.
Falso, un Padre è sempre un Figlio, o entrambe potrebbero estendere la classe Persona.
85
La seguente dichiarazione di classe è scorreYa:
public abstract final class Classe {...}
Vero
86
La seguente dichiarazione di classe è scorreYa:
public abstract class Classe;
vero
87
La seguente dichiarazione di interfaccia è scorreYa:
public final interface Classe {...}
vero, final non ha senso su un interfaccia
88
Una classe astratta contiene per forza metodi astratti
Falso
89
Un'interfaccia può essere estesa da un'altra interfaccia.
vero
90
Una classe può estendere una sola classe ma implementare più interfacce.
Vero
91
Il pregio delle classi astraYe e delle interfacce è che obbligano le soYoclassi ad implementare i
metodi astrap ereditaU. Quindi rappresentano un opmo strumento per la progeYazione object
oriented.
vero
92
Un'interfaccia può dichiarare più costruYori.
Falso, un'interfaccia non può dichiarare costruYori perché non si può istanziare.
93
Un'interfaccia non può dichiarare variabili ma costanU staUche e pubbliche.
Vero
94
Una classe astraYa può implementare un'interfaccia.
vero
95
I metodi staUci non si ereditano.
Vero
96
La seguente dichiarazione di interfaccia è scorreYa:
public staUc interface Interface;
Vero, il modificatore staUc non si può applicare a classi ed interfacce.
97
La seguente dichiarazione di interfaccia è scorreYa:
public interface class {...}
Vero, class è una parola chiave e non può essere uUlizzata come idenUficatore.
98
I metodi astratti di un'interfaccia non vengono ereditati da un'altra interfaccia.
Falso
99
I metodi astratti di un'interfaccia non possono essere implementati da un'altra interfaccia.
Falsop
100
I metodi staUci di un'interfaccia non possono essere implementaU da un'altra interfaccia.
Vero
101
Un'interfaccia E, definisce un metodo astraYo m(). L'interfaccia F estende l'interfaccia E
ridefinendo il metodo m() con un'implementazione di default. Una classe astraYa G implementa
l'interfaccia E ma non ridefinisce il metodo m(). Una classe concreta (non astraYa) H estende la
classe astraYa G e implementa l'interfaccia F, senza ridefinire il metodo m(). La classe H non può
essere compilata correYamente.
Falso, potrebbe trarre in inganno il faYo che la classe astraYa G anche ereditando il metodo
astraYo dall'interfaccia E faccia valere i moUvi della regola "class always win". Invece in questo
caso, vale la regola 4, ovvero vince l'implementazione più specifica. Infap la classe G, eredita un
metodo dell'interfaccia E, che è meno specifico di quello ridefinito nell'interfaccia F (cfr.
listaU E.java, F.java, G.java, H.java, TestEFGH.java).
102
Un'interfaccia può estendere una classe astraYa e un'interfaccia.
Falso, un'interfaccia non può estendere una classe in qualsiasi caso.
103
public class Persona {
private String nome;
public void setNome(String nome) {
this.nome = nome;
}
public String getNome() {
return this.nome;
}
}
public class Impiegato extends Persona {
private int matricola;
public void setMatricola(int matricola) {
this.matricola = matricola;
}
public int getMatricola () {
return this.matricola;
}
public String getDaU() {
return getNome() + "\nnumero" + getMatricola();
}
}
Quale sarà l'output del processo di compilazione (scegliere una sola opzione)?
1. Nessun output (compilazione correYa).
2. Errore nel metodo getDaU di Impiegato.
3. Errore nel metodo getNome di Persona.
4. Errore nel metodo getMatricola di Impiegato.
La risposta esaYa è la prima. Nessun errore da segnalare.
104
Quali di queste affermazioni sono vere?
1. L'ereditarietà permeYe di meYere in relazione di aggregazione più classi.
2. L'ereditarietà permeYe di meYere in relazione di aggregazione più interfacce.
3. L'ereditarietà permeYe di meYere in relazione di estensione più classi ed interfacce.
4. L'ereditarietà permeYe di meYere in relazione di aggregazione più classi ed interfacce.
Il conceYo di aggregazione, uUlizzato più volte negli esercizi precedenU, è una relazione che indica
contenimento, che semmai può essere considerata un'alternaUva all'estensione. Quindi l'unica
risposta correYa è la terza.
105
Considerato il seguente codice:
class Animale {}
interface Felino {}
class Leone {}
Se volessimo meYere in relazione di ereditarietà i Upi precedenU, quali dei seguenU snippet sono
validi dal punto di vista del compilatore?
1. class Animale extends Felino {}
2. interface Felino extends Animale {}
3. class Leone extends Felino {}
4. class Leone extends Animale implements Felino {}
5. class Animale extends Leone implements Felino {}
La quarta e la quinta opzione sono entrambe correYe per il compilatore. La quinta però, ha meno
senso dal punto di vista della logica (un animale è un leone? Non per forza).
106
interface Volante {}
class Aereo implements Volante {}
quali tra i seguenU snippet sono correp?
1. Aereo a = new Aereo();
2. Volante v = new Volante();
3. aereo1.equals(aereo2); (dove aereo1 e aereo2 sono oggep di Upo Aereo)
4. Volante.aereo = new Aereo();
1-3
107
Data la seguente gerarchia:
interface A {
void metodo();
}
interface B extends A {}
abstract class C implements B {}
public final class D extends C {
public void metodo() {}
Quali delle seguenU affermazioni sono false (è possibile scegliere più di un'affermazione):
1. La classe C non può essere dichiarata astraYa perché implementa un'interfaccia, quindi questo
codice non compila.
2. L'interfaccia B non può estendere un'altra interfaccia.
3. La classe C implementando B, eredita anche il metodo metodo() astraYo di A.
4. La classe D non compila perché non può essere dichiarata final.
5. La classe D non compila perché è dichiarata public.
6. La classe D non compila perché il suo metodo è dichiarato public.
Le risposte sono tuYe false tranne la 3
108
Quali delle seguenU affermazioni sono vere:
1. I metodi staUci dichiaraU in un'interfaccia non vengono ereditaU nelle soYo-interfacce.
2. Non è possibile dichiarare una classe abstract e final perché i due modificatori non sono
compaUbili tra loro.
3. Una classe astraYa deve dichiarare per forza metodi astrap.
4. Le interfacce possono anche dichiarare costruYori.
5. Le classi astraYe possono dichiarare metodi staUci.
Le risposte correYe sono la 1, la 2 e la 5.
109
L'overload di un metodo implica scrivere un altro metodo con lo stesso nome e diverso Upo di
ritorno.
Falso, l'overload di un metodo implica scrivere un altro metodo con lo stesso nome e diversa
110
L'overload di un metodo implica scrivere un altro metodo con nome differente e stessa lista di
parametri.
Falso
111
La segnatura (o firma) di un metodo è cosUtuita dalla coppia idenUficatore - lista di parametri.
Vero
112
Per sfruYare l'override bisogna che sussista l'ereditarietà.
Vero
113
Per sfruYare l'overload bisogna che sussista l'ereditarietà.
Falso
114
Supponiamo che in una classe B, la quale estende la classe A, erediUamo il metodo:
public int m(int a, String b) { ... }
Se nella classe B scriviamo il metodo:
public int m(int c, String b) { ... }
sUamo facendo overload e non override.
Falso, sUamo facendo override
115
Supponiamo che in una classe B, la quale estende la classe A, erediUamo il metodo:
public int m(int a, String b) { ... }
Se nella classe B scriviamo il metodo:
public int m(String a, String b) { ... }
sUamo facendo overload e non override.
Vero, la lista dei parametri dei due metodi è diversa.
116
interface A {
void metodo();
}
interface B extends A {
staUc void metodoStaUco() {}
}
final class C implements B {}
public abstract class D implements A {
@Override
void metodo() {}
}
Scegliere tuYe le affermazioni vere:
1. La classe C non eredita il metodo metodoStaUco.
2. L'interfaccia B non può implementare un'altra interfaccia.
3. La classe C implementando B eredita anche il metodo astraYo metodo di A, e non essendo
dichiarata astraYa non può essere compilata.
4. La classe D non compila perché non può essere dichiarata abstract. Infap non dichiara alcun
metodo astraYo.
5. La classe D non compila perché il metodo che dichiara non è dichiarato public.
6. La classe D compila solo perché il metodo è annotato con Override.
Le risposte vere sono la 1, la 3 e la 5. La numero 5 è vera perché il metodo ereditato è
implicitamente pubblico, e ridefinendolo senza il modificatore public, si sta cercando di renderlo
meno accessibile di quello ereditato. Infap compilando la classe D oYerremo il seguente errore:
error: metodo() in D cannot implement metodo() in A
void metodo() {}
^
aYempUng to assign weaker access privileges; was public
1 error
117
Quali delle seguenU affermazioni è correYa (scegliere tuYe quelle correYe):
1. Un'interfaccia estende la classe Object.
2. Un metodo che prende come parametro un reference di Upo Object, può prendere in input
qualsiasi oggeYo di qualsiasi Upo, anche di Upo interfaccia.
3. Un metodo che prende come parametro un reference di Upo Object, può prendere in input
qualsiasi oggeYo di qualsiasi Upo, anche un array.
4. Un metodo che prende come parametro un reference di Upo Object, può prendere in input
qualsiasi oggeYo di qualsiasi Upo, anche una collezione eterogenea.
5. Tup i cast di oggep, sono valutaU al tempo di compilazione.
Vere 2-3-4
118
Considerando le seguenU classi:
public class StampaNumero {
public void stampa(double numero) {
System.out.print(numero);
}
}
public class StampaIntero extends StampaNumero {
public void stampa(int numero) {
System.out.print(numero);
}
public staUc void main(String args[]) {
StampaNumero stampaNumero = new StampaIntero();
stampaNumero.stampa(1);
}
}
Eseguendo StampaIntero, qual è l'output di questo programma?
1. 1.2
2. 1
3. 1.0
4. 11.2
1.0
119
Tenendo presente che Number è superclasse della classe Integer , consideriamo la seguente
gerarchia:
public abstract class SommaNumero {
public abstract Number somma (Number n1, Number n2);
}
public class SommaIntero extends SommaNumero {
@Override
public Integer somma(Number n1, Number n2) {
return (Integer)n1 + (Integer)n2;
}
}
Scegliere tuYe le affermazioni correYe:
1. La classe SommaIntero compila senza errori.
2. La classe SommaIntero non compila perché l'override non è correYo: i Upi di ritorno non
coincidono.
3. La classe SommaIntero non compila perché non è possibile uUlizzare l'operatore + se non con
numeri di Upo primiUvo.
4. La classe SommaIntero potrebbe causare un'eccezione al runUme.
Le affermazioni correYe sono le numero 1 e 4.
120
Ogni eccezione che estende una ArithmeUcExcepUon è una unchecked excepUon.
Vero, perché ArithmeUcExcepUon è soYoclasse di RunUmeExcepUon.
121
Un Error si differenzia da una ExcepUon perché non può essere lanciato; infap non estende la
classe Throwable.
Falso
122
Il seguente frammento di codice:
int a = 10;
int b = 0;
try {
int c = a/b;
System.out.println(c);
}
catch (ArithmeUcExcepUon exc) {
System.out.println("Divisione per zero...");
}
catch (NullPointerExcepUon exc) {
System.out.println("Reference nullo...");
}
catch (ExcepUon exc) {
System.out.println("Eccezione generica...");
}
finally {
System.out.println("Finally!");
}
produrrà il seguente output:
Divisione per zero...
Eccezione generica...
Finally!
Falso, produrrà il seguente output:
Divisione per zero...
Finally!
123
Il seguente frammento di codice:
int a = 10;
int b = 0;
try {
int c = a/b;
System.out.println(c);
}
catch (ExcepUon exc) {
System.out.println("Eccezione generica...");
}
catch (ArithmeUcExcepUon exc) {
System.out.println("Divisione per zero...");
}
catch (NullPointerExcepUon exc) {
System.out.println("Reference nullo...");
}
finally {
System.out.println("Finally!");
}
produrrà un'eccezione al runUme.
Falso, produrrà un errore in compilazione (l'ordine dei blocchi catch non è regolare).
124
La parola chiave throw permeYe di lanciare "a mano" solo le soYoclassi di ExcepUon che crea il
programmatore.
Falso
125
La parola chiave throw consente di lanciare "a mano" solo le soYoclassi di ExcepUon.
Falso, solo le soYoclassi di Throwable.
126
Se un metodo fa uso della parola chiave throw, affinché la compilazione abbia buon esito nello
stesso metodo deve essere gesUta l'eccezione che si vuole lanciare, o il metodo stesso deve
uUlizzare una clausola throws.
Vero
127
Non è possibile estendere la classe Error.
Falso
128
Se un metodo m2 fa override di un altro metodo m2 posto nella superclasse, non potrà
dichiarare con la clausola throws eccezioni nuove che non siano soYoclassi rispeYo a quelle che
dichiara il metodo m2.
vero
129
Quali delle seguenU affermazioni sono correYe?
1.Le RunUmeExcepUon sono equivalenU alle unchecked excepUon.
2. ArithmeUcExcepUon è una checked excepUon.
3. ClassCastExcepUon è una unchecked excepUon.
4. NullPointerExcepUon è una checked excepUon.
Solo al 3 è corretta
130
Quali delle seguenU affermazioni sono correYe?
1. Nella clausola throws è possibile dichiarare solo le checked excepUon.
2. Nella clausola throws è possibile dichiarare solo le unchecked excepUon.
3. Nella clausola throws è possibile dichiarare una NullPointerExcepUon.
4. Con la clausola throw è possibile lanciare solo checked excepUon.
5. Con la clausola throw è possibile lanciare solo unchecked excepUon.
6. La clausola throws è obbligatoria se nel nostro metodo potrebbe essere lanciata una checked
excepUon.
7. Un metodo che dichiara una clausola throws può essere invocato solo se si gesUsce all'interno di
un blocco try-catch
Sono correYe le affermazioni numero 3 e numero 6. Infap la clausola throws e il comando throw
possono essere uUlizzaU per ogni Upo di eccezione, e questo esclude che siano correYe le
affermazioni 1, 2, 4 e 5. L'affermazione 7 è invece scorreYa perché il metodo che invoca un metodo
che dichiara la clausola throws, potrebbe a sua volta dichiarare la clausola throws.
131
Quali delle seguenti affermazioni sono corrette?
1. È possibile definire nuove eccezioni solo di tipo checked exception.
2. Se definiamo una sottoclasse di NullPointerException, questa potrà essere catturata come
NullPointerExcepUon.
3. Se definiamo una sottoclasse di NullPointerException, questa verrà catturata al posto della
NullPointerExcepUon.
4. Se definiamo una sottoclasse di ArithmeticException, questa verrà lanciata nel caso ci sia un
problema in un'operazione aritmetica.
Nessuna delle affermazioni è corretta.
132
Non tenendo conto del costruYo try-with-resources, il blocco finally è obbligatorio (scegliere tuYe
le affermazioni valide):
1. Quando non ci sono blocchi catch dopo un blocco try.
2. Quando non ci sono blocchi try prima di un blocco catch.
3. Quando ci sono almeno due blocchi catch dopo un blocco try.
4. Mai.
Solo la prima affermazione è correYa.
133
Considerando il seguente metodo:
public void metodoCheLanciaEccezione() throws ArrayIndexOutOfBoundsExcepUon {
//INSERIRE CODICE QUI
}
Scegli tra i seguenU snippet quelli che potrebbero essere inseriU nel metodo
metodoCheLanciaEccezione affinché il codice precedente sia valido:
1.
throw new ArrayIndexOutOfBoundsExcepUon;
2.
int i=0, j=0;
3.
try {
i = i/j;
} catch(ArithmeUcExcepUon e) {
throw new ArrayIndexOutOfBoundsExcepUon ();
}
}
4.
5.
int i = 0;
System.out.println();
Tup gli snippet sono validi perché, nella clausola throws, viene dichiarata
la ArrayIndexOutOfBoundsExcepUon che è un'eccezione unchecked, e che quindi non è
obbligatoria esplicitamente. Si noU che la risposta 2 fa scaYare una ArithmeUcExcepUon, la gesUsce
e rilancia una ArrayIndexOutOfBoundsExcepUon.
134
public class Esercizio8S {
public staUc void main(String args[]) throws NullPointerExcepUon {
Esercizio8S e = new Esercizio8S();
e.metodo();
}
public NullPointerExcepUon metodo() throws ExcepUon {
String s = null;
try {
s.toString();
} catch(ArithmeUcExcepUon e) {
throw new NullPointerExcepUon ();
}
return null;
}
}
Scegliere tuYe le affermazioni correYe:
1. Il codice non compila perché il metodo metodo non può ritornare NullPointerExcepUon.
2. Il codice non compila perché il metodo metodo ritorna null e non una NullPointerExcepUon.
3. Il codice non compila perché il metodo main non dichiara la giusta eccezione nella sua clausola
throws.
4. Il codice compila ma al runUme termina con una NullPointerExcepUon.
5. Il codice compila ma al runUme termina con una ExcepUon.
6. Il codice compila ma al runUme termina con una ArithmeUcExcepUon.
L'unica affermazione correYa è la 3. La sua correYezza esclude la correYezza delle affermazioni 4, 5
e 6. La 1 e la 2 sono false perché NullPointerExcepUon è comunque una classe.
135
I Upi generici e i Upi parametro sono la stessa cosa.
Falso
136
Un vantaggio principale dei generics, è che permeYono di evitare bachi come quelli provocaU da
una ClassCastExcepUon al runUme, individuandoli in compilazione.
Vero
137
Le collecUon possono essere usate anche senza specificare i Upi parametro. In tal caso si parla di
raw type.
vero
138
L'ereditarietà ignora i Upi parametro.
Vero
139
Le wildcard si usano quando non abbiamo Upi parametrici a disposizione da usare
Vero
140
Se creiamo un Upo generico con Upo parametro della classe PortaMonete, possiamo usare lo
stesso parametro anche nei metodi dichiarati nel tipo
Vero
141
Nei metodi generici il Upo parametro viene messo come parametro di input del metodo.
Falso
142
public class MyGeneric {
private List list;
public MyGeneric () {
list = new ArrayList();
}
public void add(Pippo pippo) {
list.add(pippo);
}
public void remove(int i) {
list.remove(i);
}
public Pippo get(int i) {
return list.get(i);
}
public void copy(ArrayList al) {
Iterator i = al.iterator();
while (i.hasNext()) {
Object o = i.next();
add(o);
}
}
}
compila senza errori.
Falso, oYerremo il seguente errore:
error: incompaUble types: Object cannot be converted to Pippo
add(o);
^
where Pippo is a type-variable:
Pippo extends Number declared in class MyGeneric
143
Il seguente codice:
public void print(List list) {
for (Iterator i = list.iterator();
i.hasNext( ); ) {
System.out.println(i.next());
}
}
compila senza errori.
Vero
144
Per risolvere le wildcard capture bisogna usare un metodo helper definito nella libreria
standard.
Falso, il metodo helper bisogna crearselo da soli.
145
Il seguente codice:
List strings = new ArrayList();
strings.add(new Character('A'));
compila senza errori.
Falso
146
Il seguente codice:
List ints = new ArrayList();
compila senza errori.
Falso
147
Il seguente codice:
List ints = new ArrayList();
compila senza errori.
Falso
148
Il seguente codice:
List ints = new ArrayList();
ints.add(1);
compila senza errori.
Vero
149
Il seguente codice:
List ints = new ArrayList();
compila senza errori.
Vero
150
Quali dei seguenU statement è compilabile (scegliere tup gli statement correp):
1.
ArrayList al = new ArrayList();
2.
ArrayList al = new ArrayList<>();
3.
ArrayList al = new ArrayList();
4.
ArrayList al = new ArrayList<>();
5.
ArrayList al = new ArrayList();
1-2-4
151
Qual è l'output delle seguenU righe di codice?
import java.uUl.*;
public class Esercizio10G {
public staUc void main(String args[]) {
List list = new ArrayList();
list.add("1");
list.add('2');
list.add(3);
Iterator iterator = list.iterator();
while (iterator.hasNext()) {
System.out.print(iterator.next());
}
}
}
1. 123
2. 321
3. Nessuno, il programma non si può compilare perché non è possibile aggiungere elemenU diversi
alla collezione.
4. "1"'2'3
5. Nessuno, il programma non si può compilare perché non è possibile recuperare un Iterator da
una collezione eterogenea.
6. L'esecuzione sarà stoppata nel momento in cui si proverà a stampare il secondo valore della
collezione.
123
152
import java.uUl.*;
public class Esercizio10H {
public staUc void main(String args[]) {
List
123
153
Qual è l'output delle seguenU righe di codice?
import java.uUl.*;
public class Esercizio10I {
public staUc void main(String args[]) {
List list = new ArrayList<>();
list.add("1");
list.add(null);
list.add('3');
Iterator iterator = list.iterator();
while (iterator.hasNext()) {
System.out.print(iterator.next());
}
}
}
1. Nessuno, il programma non si può compilare perché la collezione non ammeYe valori null.
2. Nessuno, il programma non si può compilare perché la collezione non ammeYe valori primiUvi.
3. L'esecuzione sarà stoppata nel momento in cui si proverà ad aggiungere null alla collezione.
4. L'esecuzione sarà stoppata nel momento in cui si proverà ad aggiungere '3' alla collezione.
5. 1null3
La risposta correYa è la 2. Non è possibile aggiungere un Upo primiUvo (né altri Upi complessi
diversi da String) ad una collezione che è parametrizzata con un Upo String.
