User Tools
Problem constructing authldap
test:test_2018
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
test:test_2018 [2018/01/21 19:39] Adriana Draghici |
test:test_2018 [2018/01/22 17:38] Adriana Draghici |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| = Test grilă ianuarie 2018 = | = Test grilă ianuarie 2018 = | ||
| + | |||
| + | Prin acest test am urmărit verificarea înțelegerii conceptelor de bază studiate la laborator, în special cum se aplică conceptele OOP în Java (polimorfism, moștenire, agregare, constructori, abstractizare), structurile de date cu care puteți lucra în Java și utilitatea design patterns. | ||
| Au fost 20 de întrebări, 4 variante de răspuns, un singur răspuns corect. 4 numere, aceleași 20 de întrebări în ordine diferită. | Au fost 20 de întrebări, 4 variante de răspuns, un singur răspuns corect. 4 numere, aceleași 20 de întrebări în ordine diferită. | ||
| Line 14: | Line 16: | ||
| * super | * super | ||
| - | **R:** Cuvântul cheie **extends** este folosit pentru relația de moștenire dintre clase sau dintre interfețe. Implements este folosit când o clasă implementează o interfață, iar super pentru a apela constructorii clasei extinse sau metodele acesteia. | + | **R:** Cuvântul cheie **extends** este folosit pentru relația de moștenire dintre clase sau dintre interfețe. //implements// este folosit când o clasă implementează o interfață, iar //super// pentru a apela constructorii clasei extinse sau metodele acesteia. |
| **2.** Care dintre următoarele concepte reprezintă o relație HAS-A? | **2.** Care dintre următoarele concepte reprezintă o relație HAS-A? | ||
| Line 59: | Line 61: | ||
| * excepție la rulare | * excepție la rulare | ||
| - | **R:** Metodele statice țin de clasă și nu de instanță, deci pentru ele nu are sens suprascrierea (overriding-ul). La execuția main-ului se va apelea metoda make din clasa Tea, același comportament obținându-l și dacă apelam Drink.make(). Sintaxa Java permite să apelați metodele statice și pe instanță dar nu recomandăm acest lucru pentru că afectează lizibilitatea codului, putând fi confundate la o citire rapidă cu metodele ne-statice. | + | **R:** Metodele statice țin de clasă și nu de instanță, deci pentru ele nu are sens suprascrierea (overriding-ul). La execuția main-ului se va apelea metoda make din clasa //Tea//, același comportament obținându-l și dacă apelam //Drink.make()//. Sintaxa Java permite să apelați metodele statice și pe instanță dar nu recomandăm acest lucru pentru că afectează lizibilitatea codului, putând fi confundate la o citire rapidă cu metodele ne-statice. |
| Line 84: | Line 86: | ||
| * null false null | * null false null | ||
| - | **R:** Java inițializează variabilele instanțelor cu valori default: tipurile primitive primesc 0, boolean iar referințele la obiect cu null (vedeți laboratorul [[laboratoare:constructori-referinte#constructori|Constructori și referințe]]. | + | **R:** Java inițializează variabilele instanțelor cu valori default: tipurile primitive primesc 0, boolean iar referințele la obiect cu null (vedeți laboratorul [[laboratoare:constructori-referinte#constructori|Constructori și referințe]]). |
| - | 6. Ce se afișează? | + | **6.** Ce se afișează? |
| <code Java> | <code Java> | ||
| class Device { | class Device { | ||
| Line 114: | Line 116: | ||
| * DF | * DF | ||
| - | 7. Ce înseamnă constructorul implicit (default)? | + | **R:** Se afișează //DWF// datorită apelului constructorilor pe ierarhia de moștenire. În constructorul cu parametru din //Watch// se apelează explicit constructorul său fără parametru (apelul //this()//), iar în acesta se apelează implicit constructorul clasei părinte, Device, care apelează implicit constructorul din Object. Apoi ne întoarcem pe lanțul de apeluri și se afișează D, apoi W, apoi F. |
| + | |||
| + | **7.** Ce înseamnă constructorul implicit (default)? | ||
| * constructor fără parametri declarat de utilizator | * constructor fără parametri declarat de utilizator | ||
| * **constructor fără parametri adăugat de Java dacă nici un constructor nu a fost declarat** | * **constructor fără parametri adăugat de Java dacă nici un constructor nu a fost declarat** | ||
| * constructor fără implementare | * constructor fără implementare | ||
| * constructor fără modificatori de acces | * constructor fără modificatori de acces | ||
| + | |||
| + | **R:** Dacă nu adăugați vreun constructor în clasa pe care ați creat-o, atunci Java vă adaugă un constructor default, vedeți laboratorul [[laboratoare:constructori-referinte#constructori|Constructori și referințe]]. | ||
| == Clase abstracte și interfețe == | == Clase abstracte și interfețe == | ||
| - | 8. Ce cuvinte cheie pot fi folosite pentru membrul MY_VALUE? | + | **8.** Ce cuvinte cheie pot fi folosite pentru membrul MY_VALUE? |
| <code Java> | <code Java> | ||
| public interface Status { | public interface Status { | ||
| Line 131: | Line 137: | ||
| * final, private, abstract | * final, private, abstract | ||
| * **final, static, public** | * **final, static, public** | ||
| + | |||
| + | **R:** Implicit, variabilele declarate în interfețe sunt final, static și public. Atunci când le declarați puteți scrie toate aceste cuvinte cheie sau le puteți omite (IDE-ul chiar vă sugerează să le omiteți). Ele sunt publice pentru ca este vorba de o interfață. Sunt statice din motive de încapsulare, altfel am declara variabile ale instanței publice. Sunt finale pentru a ne asigura că vor fi __constante__ și nu li se vor atribui alte valori (e.g. dacă ar fi doar public static, atunci două sau mai multe clase care implementează interfața vor putea modifica la comun acea variabilă). | ||
| 9. Care variantă definește cel mai bine legătura dintre interfețe și clase? | 9. Care variantă definește cel mai bine legătura dintre interfețe și clase? | ||
| * Atât clasele, cat și interfețele definesc modul în care un obiect execută o operație | * Atât clasele, cat și interfețele definesc modul în care un obiect execută o operație | ||
| - | * **Interfețele precizeaza operatiile expuse de un obiect, în timp ce clasele modul în care acesta le execută** | + | * **Interfețele precizează operațiile expuse de un obiect, în timp ce clasele modul în care acesta le execută** |
| * Nici clasele, nici interfețele nu precizează modul în care un obiect execută o operație | * Nici clasele, nici interfețele nu precizează modul în care un obiect execută o operație | ||
| * Nu pot exista relații între clase și interfețe | * Nu pot exista relații între clase și interfețe | ||
| + | |||
| + | **R:** Self-explanatory | ||
| 10. Dacă B extinde clasa abstractă A și C extinde B, atunci care instanțiere este corectă? | 10. Dacă B extinde clasa abstractă A și C extinde B, atunci care instanțiere este corectă? | ||
| Line 144: | Line 154: | ||
| * C ca = new A(); | * C ca = new A(); | ||
| + | **R:** Varianta corectă este ''A ab = new B()''. Restul variantelor sunt incorecte pentru că nu putem atribui unei referinte de un anumit tip un obiect al supertipului. Dacă s-ar permite așa ceva, atunci la runtime, când apelăm o metodă a lui C, obiectul nu o va avea, pentru ca e de tip B. Încă ceva greșit în acele variante este că încercăm să instanțiem o clasă abstractă, iar acestea, ca și interfețele, nu se instanțiază. | ||
| == Clase interne == | == Clase interne == | ||
| - | 11. Care din următoarele afirmații sunt adevarate despre clase interne statice? | + | **11.** Care din următoarele afirmații sunt adevarate despre clase interne statice? |
| A. Nu au acces la membri non-statici ai clasei exterioare | A. Nu au acces la membri non-statici ai clasei exterioare | ||
| B. Este nevoie de o instanță a clasei externe pentru a o instanția | B. Este nevoie de o instanță a clasei externe pentru a o instanția | ||
| Line 156: | Line 167: | ||
| * C | * C | ||
| - | 12. Care dintre următoarele afirmații este adevărată cu privire la clasele anonime? | + | **R:** Clasele interne statice (nested classes) nu au nevoie de o instanță a clasei externe, la fel ca și câmpurile și metodele statice. Din acest motiv nici nu pot avea acces la membrii non-statici ai acesteia, afirmația A fiind corectă și B incorectă. Afirmația C este falsă, nu există această restricție. Afirmația D este falsă datorită exprimării "trebuie". |
| + | |||
| + | |||
| + | **12.** Care dintre următoarele afirmații este adevărată cu privire la clasele anonime? | ||
| * clasele anonime trebuie să aibă în constructor o referință către clasa exterioară | * clasele anonime trebuie să aibă în constructor o referință către clasa exterioară | ||
| * clasele anonime trebuie să definească explicit constructorul fără parametri | * clasele anonime trebuie să definească explicit constructorul fără parametri | ||
| * **claselor anonime nu li se poate declara un constructor** | * **claselor anonime nu li se poate declara un constructor** | ||
| * niciuna din variante | * niciuna din variante | ||
| + | |||
| + | **R:** Clasele anonime nu au constructor, în laboratorul [[laboratoare:clase-interne#constructori|Clase interne]] puteți vedea mai multe detalii și exemple. | ||
| + | |||
| == Colecții și genericitate == | == Colecții și genericitate == | ||
| - | 13. Ce se afișează? | + | **13.** Ce se afișează? |
| <code Java> | <code Java> | ||
| Set<Integer> mySet = new LinkedHashSet<>(); | Set<Integer> mySet = new LinkedHashSet<>(); | ||
| Line 171: | Line 188: | ||
| System.out.println(mySet); | System.out.println(mySet); | ||
| </code> | </code> | ||
| - | *'' [10, 1, 100]'' | + | * ''[10, 1, 100]'' |
| * ''[100, 10, 1]'' | * ''[100, 10, 1]'' | ||
| - | * ''[1, 10, 100]'' | + | * **''[1, 10, 100]''** |
| * numerele vor fi afișate într-o ordine arbitrară | * numerele vor fi afișate într-o ordine arbitrară | ||
| - | 14. Ce colecție ar fi mai eficientă de folosit dacă dorim să stocăm o secvență de elemente pe care să o modificăm rar dar pe care să o accesăm foarte des? | + | **R:** Implementările interfeței Set variază în funcție de următoarele caracteristici: dacă oferă un set ordonat sau nu, sau daca oferă un set sortat sau nu. Varianta HashSet oferă un set neordonat și nesortat. LinkedHashSet însă reține ordinea în care s-au adăugat elementele, fiind implementată folosind o listă dublu înlănțuită. |
| + | |||
| + | **14.** Ce colecție ar fi mai eficientă de folosit dacă dorim să stocăm o secvență de elemente pe care să o modificăm rar dar pe care să o accesăm foarte des? | ||
| * LinkedList | * LinkedList | ||
| * **ArrayList** | * **ArrayList** | ||
| Line 182: | Line 201: | ||
| * niciuna din variante | * niciuna din variante | ||
| - | 15. Care instanțiere este corectă? | + | **R:** ArrayList este mai eficientă de folosit dacă accesăm des elementele din ea pentru că are complexitate O(1) pt acces. Implementările intefeței List variază în funcție de structura de date folosită pentru reținerea elementelor, astfel oferind complexități diferite pentru acces și modificări, fapt menționat și în laboratorul [[laboratoare:colectii#interfata-list|Colecții]]. În plus, una din implementări, Vector, este ineficientă deoarece toate metodele sale sunt sincronizate, permițând unui singur thread să le acceseze la un moment dat (este și depracated pentru că acum există alternative thread-safe mai eficiente e.g. Collections#synchronizedList). |
| + | |||
| + | **15.** Care instanțiere este corectă? | ||
| * ''Set<Integer> set = new HashSet<Object>();'' | * ''Set<Integer> set = new HashSet<Object>();'' | ||
| * ''HashSet<Integer> set = new Set<Integer>();'' | * ''HashSet<Integer> set = new Set<Integer>();'' | ||
| * **''Set<Integer> set = new HashSet<Integer>();''** | * **''Set<Integer> set = new HashSet<Integer>();''** | ||
| * ''HashSet<Object> set = new HashSet<Integer>();'' | * ''HashSet<Object> set = new HashSet<Integer>();'' | ||
| + | |||
| + | **R:** Varianta corectă este ''Set<Integer> set = new HashSet<Integer>();''. Prima și ultima variantă sunt incorecte pentru că nu avem [[https://dzone.com/articles/covariance-and-contravariance|covarianță]] în cazul genericității, după cum este menționat și în [[laboratoare:genericitate|laborator]], dacă //ChildType// este un subtip (clasă descendentă sau subinterfață) al lui //ParentType//, atunci o structură generică //GenericStructure<ChildType>// nu este un subtip al lui //GenericStructure<ParentType>//. Această restricție se datorează faptului că genericitatea este aplicată la compilare, iar la runtime nu se fac verificări de tipuri. | ||
| + | A doua variantă este greșită pentru că Set e super tipul lui HashSet și Set este și interfață, deci nu poate fi instanțiată. | ||
| == JUnit și Excepții == | == JUnit și Excepții == | ||
| - | 16. Ce este JUnit? | + | **16.** Ce este JUnit? |
| * un framework pentru integration testing | * un framework pentru integration testing | ||
| * **un framework pentru unit testing** | * **un framework pentru unit testing** | ||
| Line 195: | Line 219: | ||
| * un framework pentru system testing | * un framework pentru system testing | ||
| - | 17. Ce se afișează? | + | **R:** JUnit este framework-ul pentru unit testing studiat la [[laboratoare:exceptii|laborator]]. Chiar dacă JUnit poate fi folosit împreună cu alte tool-uri și pentru integration tests (testează mai multe componente, e dependent de sisteme externe, e.g. o bază de date), scopul lui principal este unit testing-ul, iar la laborator s-a folosit pentru acest lucru. |
| + | |||
| + | **17.** Ce se afișează? | ||
| <code Java> | <code Java> | ||
| public class Test { | public class Test { | ||
| Line 237: | Line 263: | ||
| * 5 | * 5 | ||
| * 7 | * 7 | ||
| + | |||
| + | **R:** Întrebarea aceasta verifică înțelegerea conceptului de finally dintr-un bloc de prindere a excepțiilor. Ca și în alte limbaje (e.g. C#, Python, Javascript), și în Java, finally se execută de fiecare dată, după execuția blocului try sau catch. Urmărind codul, avem: try - count=1 ---> try - count=2 ---> try - count=3 ---> catch count=4 ---> finally - count=5 ---> catch (pt ca primul catch aruncă excepția) count=6. | ||
| == Design Patterns == | == Design Patterns == | ||
| - | 18. Care dintre următoarele patternuri ar fi mai util dacă dorim ca anumite clase să fie notificate de schimbări ale altor clase? | + | **18.** Care dintre următoarele patternuri ar fi mai util dacă dorim ca anumite clase să fie notificate de schimbări ale altor clase? |
| * Visitor | * Visitor | ||
| * Strategy | * Strategy | ||
| Line 245: | Line 273: | ||
| * **Observer** | * **Observer** | ||
| - | 19. Ce se afișează? | + | **R:** Folosind //Observer// putem avea obiecte "observabile" care atunci când își modifică starea să notifice alte obiecte dependente de acestea "observatori". |
| + | |||
| + | **19.** Ce se afișează? | ||
| <code Java> | <code Java> | ||
| public class NetworkService { | public class NetworkService { | ||
| Line 273: | Line 303: | ||
| * 1 | * 1 | ||
| - | 20. Pentru a modela mai multe butoane din interfața grafică cu o anumită funcționalitate (ce este executată la apăsare) și diverse proprietăți (icon, text, animație), este o buna idee de a folosi urmatorul design pattern: | + | **R:** NetworkService este implementat ca un Singleton, existând o singură instanță a sa. Variabilele a și b reprezintă același obiect, deci comparația referințelor == este true. |
| + | |||
| + | **20.** Pentru a modela mai multe butoane din interfața grafică cu o anumită funcționalitate (ce este executată la apăsare) și diverse proprietăți (icon, text, animație), este o buna idee de a folosi urmatorul design pattern: | ||
| * Visitor Pattern | * Visitor Pattern | ||
| * Singleton Pattern | * Singleton Pattern | ||
| Line 279: | Line 311: | ||
| * **Command Pattern** | * **Command Pattern** | ||
| - | + | **R:** Folosind Command Pattern putem modela ușor operațiile efectuate sub forma unor comenzi. Butoanele din GUI (interfața grafică a utilizatorului) și elementele din meniuri sunt de multe ori obiecte de tip Command. În plus față de abilitatea de a efectua comanda dorită, o acțiune poate avea o pictogramă asociată, un text sau altele. Hint ar fi trebuit să fie cuvântul "executată" , care duce cu gândul la metoda execute() specifică pattern-ului. | |
test/test_2018.txt · Last modified: 2018/01/22 17:38 by Adriana Draghici
Page Tools
