User Tools
Problem constructing authldap
test_grila_ian2015
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
test_grila_ian2015 [2015/01/21 00:19] Adriana Draghici |
test_grila_ian2015 [2015/01/21 00:53] Adriana Draghici [Design patterns, Junit, reflection] |
||
|---|---|---|---|
| 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 acestea, sau 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 196: | Line 207: | ||
| == Clase abstracte și interfețe == | == Clase abstracte și interfețe == | ||
| - | **13. Care afirmații sunt corecte? (Ci denotă clase, Ii denotă interfețe)** | + | **8. Care afirmații sunt corecte? (Ci denotă clase, Ii denotă interfețe)** |
| A) C1 extends I1; | A) C1 extends I1; | ||
| Line 209: | Line 220: | ||
| * **B, D** | * **B, D** | ||
| - | **Explicație**: Este o întrebare standard despre fundamentele limbajului Java. Esențial este că o clasă //poate extinde o singură altă clasă și poate implementa oricâte interfețe//. Afirmația E este deci greșită, deci pică din start 2 variante. Afirmațiile A și C iarăși nu au sens, o clasă //extinde// altă clasă și o interfață //extinde// altă interfață. Afirmația D este corectă și apare des în viața reală. Ce este potențial tricky la această întrebare este afirmația B, care este corectă. De ce este corectă: în virtutea implementării mai multor interfețe, compilatorul este doar interesat de adunat semnături de metode în cadrul interfețelor. Vă puteți pune întrebarea ce se întâmplă dacă I1 și I2 conțin aceeași semnătură de metodă și pe care dintre ele o moștenește I. Un răspuns (cu niște simplificări) e că nu contează; ceea ce contează este ca acea semnătură de metodă să se afle în I. Deci faptul că o interfață extinde mai multe alte intefețe cu semnături de metode potențial identice nu deranjează compilatorul, pentru că nu există și implementări diferite care să declanșeze eventuale ambiguități. | + | **Explicație**: Este o întrebare standard despre fundamentele limbajului Java. Esențial este că o clasă //poate extinde o singură altă clasă și poate implementa oricâte interfețe, iar o interfață poate extinde oricâte alte interfețe//. |
| + | Afirmația E este deci greșită, deci pică din start 2 variante. Afirmațiile A și C iarăși nu au sens, o clasă //extinde// altă clasă și o interfață //extinde// altă interfață. Afirmația D este corectă și apare des în viața reală. Ce este potențial tricky la această întrebare este afirmația B, care este corectă. De ce este corectă: în virtutea implementării mai multor interfețe, compilatorul este doar interesat de adunat semnături de metode în cadrul interfețelor. Vă puteți pune întrebarea ce se întâmplă dacă I1 și I2 conțin aceeași semnătură de metodă și pe care dintre ele o moștenește I. Un răspuns (cu niște simplificări) e că nu contează; ceea ce contează este ca acea semnătură de metodă să se afle în I. Deci faptul că o interfață extinde mai multe alte intefețe cu semnături de metode potențial identice nu deranjează compilatorul, pentru că nu există și implementări diferite care să declanșeze eventuale ambiguități. | ||
| - | ** 8. Fie: ** | + | |
| + | ** 9. Fie: ** | ||
| <code java> | <code java> | ||
| Line 231: | Line 244: | ||
| * 4 | * 4 | ||
| - | **Explicație**: Esențial este faptul că orice variabilă în corpul unei interfețe este automat (dedus) ''public static final'', iar metodele sunt implicit ''abstract''. Înarmați cu aceste cunoștințe, să luăm acum fiecare linie pe rând: | + | **Explicație**: Esențial este faptul că //orice variabilă din corpul unei interfețe este automat (dedus) ''public static final'', iar metodele sunt implicit ''public abstract''//. Înarmați cu aceste cunoștințe, să luăm acum fiecare linie pe rând: |
| - ''protected'' și ''public'' (dedus) intră în contradicție - greșit | - ''protected'' și ''public'' (dedus) intră în contradicție - greșit | ||
| Line 237: | Line 250: | ||
| - corect | - corect | ||
| - puteți considera declarația un pleonasm, dar compilatorul nu este deranjat, ''abstract'' este oricum dedus - corect | - puteți considera declarația un pleonasm, dar compilatorul nu este deranjat, ''abstract'' este oricum dedus - corect | ||
| - | - metodele din interfețe sunt prin definiție ''abstract''; final + abstract = compiler headbang. Greșit. | + | - metodele din interfețe sunt prin definiție ''abstract''; final + abstract = compiler headbang - greșit. |
| == Clase interne == | == Clase interne == | ||
| - | **14. Cu ce poate fi înlocuită linia (xxx) pentru a obține o instanță a B?** | + | **10. Cu ce poate fi înlocuită linia (xxx) pentru a obține o instanță a B?** |
| <code java> | <code java> | ||
| Line 263: | Line 276: | ||
| - | + | **11. Fie interfața ''Runnable'' cu singura metodă ''public void run()''. Clasa ''Thread'' are un constructor ce primește un ''Runnable'' ca parametru și expune o metodă ''public void start()''. Ce concluzie trageți de la următorul cod?** | |
| - | **1. Fie interfața ''Runnable'' cu singura metodă ''public void run()''. Clasa ''Thread'' are un constructor ce primește un ''Runnable'' ca parametru și expune o metodă ''public void start()''. Ce concluzie trageți de la următorul cod?** | + | |
| <code java> | <code java> | ||
| Line 284: | Line 296: | ||
| - | **3. Ce cuvânt cheie introdus la (xxx) va permite compilarea programului:** | + | **12. Ce cuvânt cheie introdus la (xxx) va permite compilarea programului:** |
| <code java> | <code java> | ||
| Line 309: | Line 321: | ||
| * static | * static | ||
| - | **Explicație:** Pentru a folosi variabile locale din afara contextului (//scope//-ului) unei clase interne (cum e și cazul nostru), e necesar cuvântul cheie ''final''. Motivul este layout-ul în memorie al claselor și variabilelor, iar ''final'' permite (prin copiere) și garantează accesul la valoarea corectă a variabliei ''x'' la orice moment. ''static'' și ''public'' nu au oricum sens pentru variabile locale, iar diferențierea dintre "nu e nevoie de modificator" și "final" este motivul precedent. | + | **Explicație:** //Pentru a folosi variabile locale din afara contextului (//scope//-ului) unei clase interne (cum e și cazul nostru), e necesar cuvântul cheie ''final''//. Motivul este layout-ul în memorie al claselor și variabilelor, iar ''final'' permite (prin copiere) și garantează accesul la valoarea corectă a variabliei ''x'' la orice moment. ''static'' și ''public'' nu au oricum sens pentru variabile locale, iar diferențierea dintre "nu e nevoie de modificator" și "final" este motivul precedent. |
| == Colecții și genericitate == | == Colecții și genericitate == | ||
| - | **12. Dacă dorim să stocăm un șir de elemente fără duplicate într-o colecție fără să ne intereseze ordinea elementelor sau sortarea lor, clasa cea mai potrivită este** | + | **13. Dacă dorim să stocăm un șir de elemente fără duplicate într-o colecție fără să ne intereseze ordinea elementelor sau sortarea lor, clasa cea mai potrivită este** |
| * Vector | * Vector | ||
| Line 325: | Line 337: | ||
| - | **4. Ce se întâmplă la rularea următorului cod:** | + | **14. Ce se întâmplă la rularea următorului cod:** |
| <code java> | <code java> | ||
| Line 347: | Line 359: | ||
| - | **19. Care dintre următoarele variante este corectă (compilează)?** | + | **15. Care dintre următoarele variante este corectă (compilează)?** |
| * ''ArrayList <Person>mylist = new ArrayList<Student>();'' | * ''ArrayList <Person>mylist = new ArrayList<Student>();'' | ||
| Line 354: | Line 366: | ||
| * ''ArrayList<Student>mylist = new ArrayList<Person>();'' | * ''ArrayList<Student>mylist = new ArrayList<Person>();'' | ||
| - | **Explicație**: Ideea cheie în această întrebare și în lucrul cu generics în general este că, de exemplu (exemplul nostru), dacă ''Student'' e subclasă a ''Person'', atunci ''ArrayList<Student>'' **nu** e subclasă a ''ArrayList<Person>'', deci atribuirea nu este corectă. Matching-ul tipului generic (cel dintre paranteze unghiulare) este făcut la compilare și singura variantă care trece de această verificare este varianta în bold. Am fi putut avea matching corect cu wildcard-uri, dar nu a fost cazul aici. | + | **Explicație**: Ideea cheie în această întrebare și în lucrul cu generics în general este că, de exemplu (exemplul nostru), dacă ''Student'' e subclasă a ''Person'', atunci ''ArrayList<Student>'' **nu** e subclasă a ''ArrayList<Person>'', deci atribuirea nu este corectă (un astfel de exemplu este și în [[:laboratoare:genericitate#genericitatea-in-subtipuri|laboratorul de genericitate]]). |
| - | Pentru cultura voastră generală, citiți despre //covarianță/contravarianță// și despre //type erasure// ca să înțelegeți motivele pentru care Java se comportă astfel. | + | Matching-ul tipului generic (cel dintre paranteze unghiulare) este făcut la compilare și singura variantă care trece de această verificare este varianta în bold. Am fi putut avea matching corect cu wildcard-uri, dar nu a fost cazul aici. Pentru mai multe detalii puteți să citiți despre //covarianță/contravarianță// și despre //type erasure// ca să înțelegeți motivele pentru care Java se comportă astfel. |
| == Excepții == | == Excepții == | ||
| - | **5. Despre excepțiile unchecked:** | + | **16. Despre excepțiile unchecked:** |
| * clasele lor nu pot fi extinse | * clasele lor nu pot fi extinse | ||
| Line 411: | Line 423: | ||
| - | == Design patterns, Junit, reflection == | + | == Design patterns, Junit, misc == |
| - | **16. Vrem să implementăm un framework de user interface. Cu ce design pattern am putea modela comportamentul de onClick -> doSomething pentru un element de tip buton oarecare?** | + | **18. Vrem să implementăm un framework de user interface. Cu ce design pattern am putea modela comportamentul de onClick -> doSomething pentru un element de tip buton oarecare?** |
| * Visitor | * Visitor | ||
| Line 424: | Line 436: | ||
| - | **11. Care cuvânt dintre următoarele este rezervat în Java?** | + | **19. Care cuvânt dintre următoarele este rezervat în Java?** |
| * method | * method | ||
| Line 437: | Line 449: | ||
| - | **18. Fie următorul ters JUnit funcțional. Ce se va afișa în urma execuției lui?** | + | **20. Fie următorul ters JUnit funcțional. Ce se va afișa în urma execuției lui?** |
| <code java> | <code java> | ||
| Line 461: | Line 473: | ||
| * **before:test1:after:before:test2:after:** | * **before:test1:after:before:test2: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. | + | **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
Page Tools
