User Tools
Problem constructing authldap
test:test_2015
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
test:test_2015 [2015/01/21 01:00] Adriana Draghici [Design patterns, Junit, misc] |
test:test_2015 [2015/01/21 12:18] (current) Daniel Ciocirlan [Colecții și genericitate] |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| Metoda de evaluare: grilă franceză, -1/4 din punctajul unei întrebări la răspuns greșit, 0 dacă nu este marcat niciun răspuns. | Metoda de evaluare: grilă franceză, -1/4 din punctajul unei întrebări la răspuns greșit, 0 dacă nu este marcat niciun răspuns. | ||
| - | /* | ||
| - | Analizăm aici întrebările în ordinea variantei A a testului. | ||
| - | */ | ||
| + | Analizăm aici întrebările pe rând, structurat pe secțiuni. | ||
| == Basics == | == Basics == | ||
| **1. Ce obținem la rularea următorului cod:** | **1. Ce obținem la rularea următorului cod:** | ||
| Line 167: | Line 165: | ||
| **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.// | + | |
| + | Întrebarea testează că ştiţi că //metodele supraîncărcate (overloaded) sunt 'alese' la compile-time, iar cele suprascrise (overriden) la runtime.// | ||
| Line 222: | Line 221: | ||
| **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//. | **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. | + | Afirmația E este deci greșită, deci pică din start 3 variante, ceea ce vă asigură răspunsul corect, dar să mergem mai departe. 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. |
| Line 368: | Line 367: | ||
| **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]]). | **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]]). | ||
| - | 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. | + | 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 [[http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 | covarianță și contravarianță]] și despre [[http://docs.oracle.com/javase/tutorial/java/generics/erasure.html | type erasure]] ca să înțelegeți motivele pentru care Java se comportă astfel. |
| - | + | ||
| == Excepții == | == Excepții == | ||
| Line 449: | Line 446: | ||
| - | **20. Fie următorul ters JUnit funcțional. Ce se va afișa în urma execuției lui?** | + | **20. Fie următorul test JUnit funcțional. Ce se va afișa în urma execuției lui?** |
| <code java> | <code java> | ||
test/test_2015.1421794837.txt.gz · Last modified: 2015/01/21 01:00 by Adriana Draghici
Page Tools
