User Tools

Site Tools


Problem constructing authldap
test_grila_ian2015
Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
test_grila_ian2015 [2015/01/21 00:19]
Adriana Draghici
test_grila_ian2015 [2015/01/21 00:37]
Adriana Draghici [OOP]
Line 10: Line 10:
  
 == Basics == == Basics ==
-**2. Ce obținem la rularea următorului cod:**+**1. Ce obținem la rularea următorului cod:**
  
 <code java> <code java>
Line 38: Line 38:
  
  
-**6. Ce afișează următorul cod:**+ 
 +**2. Care afi rmații sunt corecte? ** 
 + 
 + 
 +//A) Statement-ul ''​package''​ poate fi pus doar pe prima linie necomentată dintr-un fișier 
 +B) Speci ficatorii de acces pentru clase externe sunt doar public și default 
 +C) Un fișier poate avea mai multe clase publice 
 +D) Este obligatoriu pentru un fișier sa conțină statement-ul package 
 +E) Un fișier poate avea mai multe statement-uri import // 
 + 
 +  * A, B, C, E 
 +  * **A, B, E** 
 +  * B, C, E 
 +  * A, B, D, E 
 + 
 +**Explicație**:​ să luăm afirmațiile pe rând: 
 +A) declararea pachetului poate fi doar prima linie necomentată de cod fără dubii, deci corect 
 +B) specificatorii pentru clase externe sunt doar public și default (adică fără modificator);​ ceilalți nu au sens decât în contextul unei alte clase (private, protected față de cine?) - corect 
 +C) un fișier poate avea **o singură** clasă publică - greșit 
 +D) dacă un fișier se află într-un pachet default, nu trebuie să aibă statement-ul package - greșit 
 +E) un fișier poate avea, desigur, mai multe import-uri (și este deseori cazul) - corect 
 + 
 + 
 + 
 + 
 +== Constructori,​ referințe == 
 + 
 +**3. Ce afișează următorul cod:**
  
 <code java> <code java>
Line 64: Line 91:
   * shape rectangle r s   * shape rectangle r s
  
-**Explicație**:​ Expresia ''​new Rectangle()''​ cheamă întâi super-constructorul,​ anume ''​Shape()'',​ care printează "​shape",​ după care se execută instrucțiunile din constructorul propriu al ''​Rectangle'',​ care printează "​rectangle"​. Apoi pe instanța de Rectangle se cheamă metoda ''​go''​ din clasa Rectangle (ar trebui să fie clar), care setează ''​type="​r"''​. Rectangle nu are un câmp ''​type''​ propriu, deci ''​this.type''​ și ''​super.type''​ vor avea aceeași valoare "​r"​. Deducem deci că se va afișa "shape rectangle r r". +**Explicație**:​ Expresia ''​new Rectangle()''​ cheamă întâi super-constructorul,​ anume ''​Shape()'',​ care printează "​shape",​ după care se execută instrucțiunile din constructorul propriu al ''​Rectangle'',​ care printează "​rectangle"​. Apoi pe instanța de Rectangle se apelează metoda ''​go''​ din clasa Rectangle (ar trebui să fie clar), care setează ''​type="​r"''​. Rectangle nu are un câmp ''​type''​ propriu, deci ''​this.type''​ și ''​super.type''​ vor avea aceeași valoare "​r"​. Deducem deci că se va afișa "shape rectangle r r".
- +
- +
-**7. Care afi rmații sunt corecte? +
-A) Statement-ul ''​package''​ poate fi pus doar pe prima linie necomentată dintr-un fișier +
-B) Speci catorii de acces pentru clase externe sunt doar public și default +
-C) Un fișier poate avea mai multe clase publice +
-D) Este obligatoriu pentru un fișier sa conțină statement-ul package +
-E) Un fișier poate avea mai multe statement-uri import ** +
- +
-  * A, B, C, E +
-  * **A, B, E** +
-  * B, C, E +
-  * A, B, D, E +
- +
-**Explicație**:​ să luăm afirmațiile pe rând: +
-A) declararea pachetului poate fi doar prima linie necomentată de cod, fără dubii, deci corect +
-B) specificatorii pentru clase externe sunt doar public și default (adică fără modificator);​ ceilalți nu au sens decât în contextul unei alte clase (private, protected față de cine?) - corect +
-C) un fișier poate avea **o singură** clasă publică - greșit +
-D) dacă un fișier se află într-un pachet default, nu trebuie să aibă statement-ul package - greșit +
-E) un fișier poate avea, desigur, mai multe import-uri (și este deseori cazul) - corect +
- +
- +
-== Constructori,​ referințe == +
  
  
-**10. Ce afișează următorul program?**+**4. Ce afișează următorul program?**
  
 <code java> <code java>
Line 115: Line 118:
   * Nimic   * Nimic
  
-**Explicație**:​ codul compilează;​ singura potențială problemă ar fi atribuirea unei valori ''​boolean''​ (tip primitiv) unei variabile ''​Boolean''​ (tip referință),​ dar știm că Java face //​autoboxing//​ (adică se creează un nou Boolean cu ''​false''​ în interiorul lui). Esența întrebării este diferența dintre == și metoda ''​equals''​. În mod clar ''​b.equals(true)''​ va fi adevărat, deci se va printa 1. Apoi, pentru că operatorul == compară referințele (adică verifică dacă cei doi operanzi sunt de fapt //același obiect//), ''​b == new Boolean(false)''​ va fi ''​false'',​ deci nu se va printa și 2.+**Explicație**:​ codul compilează;​ singura potențială problemă ar fi atribuirea unei valori ''​boolean''​ (tip primitiv) unei variabile ''​Boolean''​ (tip referință),​ dar știm că Java face //​autoboxing//​ (adică se creează un nou Boolean cu ''​false''​ în interiorul lui). **Esența întrebării este diferența dintre == și metoda ''​equals''​**. În mod clar ''​b.equals(true)''​ va fi adevărat, deci se va printa 1. Apoi, pentru că operatorul == compară referințele (adică verifică dacă cei doi operanzi sunt de fapt //același obiect//), ''​b == new Boolean(false)''​ va fi ''​false'',​ deci nu se va printa și 2.
  
  
Line 122: Line 125:
 == OOP == == OOP ==
  
-**9. Care variantă reprezintă suprascrierea corectă a metodei: ''​protected int computeX(int a, float b) {...}''?​**+**5. Care variantă reprezintă suprascrierea corectă a metodei: ''​protected int computeX(int a, float b) {...}''?​**
  
   * ''​int computeX(int a, float b) {...}''​   * ''​int computeX(int a, float b) {...}''​
Line 129: Line 132:
   * ''​protected Integer computeX(int a, float b) {...}''​   * ''​protected Integer computeX(int a, float b) {...}''​
  
-**Explicație**: ​suprascrierea este corectă dacă se păstrează aceeași semnătură (tip de întors, nume + parametri, deci variantele 3 și 4 sunt greșite), iar modificatorul ​de acces este cel puțin protected. Modificatorul default poate sau nu să fie mai vizibil decât protected (exercițiu - gândiți-vă la scenarii)fapt pentru care compilatorul interzice prima variantă ca fiind suprascriere (i.e. dacă adăugați adnotarea ''​@Override''​ veți primi eroare).+**Explicație**: ​Întrebarea verifică cunoașterea regulilor pentru supracriere:​ 
 +* aceeși listă de argumente 
 +* același tip de return ​sau un subtip al acestuia 
 +nu pot avea un modificator de acces mai restrictiv 
 +* pot arunca doar aceleași excepții, excepții derivate din acesteasau excepții unchecked.
  
-**15. Ce afișează următorul cod (//​Student//​ e o subclasă a //Person//, iar //Person// conține metoda //​getName//​)?​**+În cazul de faţă suprascrierea este corectă dacă se păstrează aceeași semnătură (tip de întors, nume + parametri, deci variantele 3 și 4 sunt greșite), iar modificatorul de acces este cel puțin protected. Modificatorul default poate sau nu să fie mai vizibil decât protected (exercițiu - gândiți-vă la scenarii), fapt pentru care compilatorul interzice prima variantă ca fiind suprascriere (i.e. dacă adăugați adnotarea ''​@Override''​ veți primi eroare). 
 + 
 + 
 +**6. Ce afișează următorul cod (//​Student//​ e o subclasă a //Person//, iar //Person// conține metoda //​getName//​)?​**
  
 <code java> <code java>
Line 156: Line 166:
   * Student Alice; Person Bob   * Student Alice; Person Bob
  
-**Explicație**:​ În lipsa altor detalii, ''​getName()''​ este aceeași metodă în clasele ''​Person''​ și ''​Student'',​ care întoarce câmpul de tip ''​String''​ din obiect, nici nu am mai scris-o în întrebare pentru că am fost siguri că înțelegeți scenariul. Ce e important de dedus este //care// metodă ''​printInfo''​ se apelează pentru cele două obiecte ''​s''​ și ''​p''​. Răspunsul este simplu: se apelează acea metodă pentru care //tipurile parametrilor//​ coincid cu tipurile ​//​declarate//​ ale obiectelor pasate efectiv. **A nu se confunda cu runtime dispatch-ul metodelor //​suprascrise//​ în clase derivate**! În cazul nostru ambele obiecte erau declarate de tip ''​Person'',​ deci se apela de două ori metoda ''​printInfo(Person)'',​ o dată pentru Alice, o dată pentru Bob.+**Explicație**:​ În lipsa altor detalii, ''​getName()''​ este aceeași metodă în clasele ''​Person''​ și ''​Student'',​ care întoarce câmpul de tip ''​String''​ din obiect, nici nu am mai scris-o în întrebare pentru că am fost siguri că înțelegeți scenariul. Ce e important de dedus este //care// metodă ''​printInfo''​ se apelează pentru cele două obiecte ''​s''​ și ''​p''​. Răspunsul este simplu: se apelează acea metodă pentru care //tipurile parametrilor//​ coincid cu //tipurile ​declarate// ale obiectelor pasate efectiv. **A nu se confunda cu runtime dispatch-ul metodelor //​suprascrise//​ în clase derivate**! În cazul nostru ambele obiecte erau declarate de tip ''​Person'',​ deci se apela de două ori metoda ''​printInfo(Person)'',​ o dată pentru Alice, o dată pentru Bob. 
 +Întrebara practic verifică că ştiţi că //metodele supraîncărcate(overloaded) sunt '​alese'​ la compile-time,​ iar cele suprascrise (overriden) la runtime.//
  
  
  
-**20. Ce se afișează? **+**7. Ce se afișează? **
  
 <code java> <code java>
Line 462: Line 473:
  
 **Explicație**:​ întrebare simplă despre funcționarea JUnit. Fiecare test în parte este precedat de rularea metodei adnotată cu Before și succedată de rularea metodei adnotată cu After. **Explicație**:​ întrebare simplă despre funcționarea JUnit. Fiecare test în parte este precedat de rularea metodei adnotată cu Before și succedată de rularea metodei adnotată cu After.
- 
test_grila_ian2015.txt · Last modified: 2015/01/21 00:53 by Adriana Draghici