Show page

Differences

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

--- poo-ca-cd:test:test_2018 [2020/07/28 23:08]
127.0.0.1 external edit
+++ poo-ca-cd:test:test_2018 [2020/08/19 23:15] (current)
florin.mihalache
@@ 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.
@@ Line 9: / Line 9: @@
 Analizăm aici întrebările pe rând, structurat pe secțiuni.
-== OOP ==
+==== OOP ====
 **1.** Care dintre următoarele cuvinte cheie realizează //moștenirea// în Java?
-* implements
+  * implements
-* inherits
+  * inherits
-* **extends**
+  * **extends**
-* 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.
 **2.** Care dintre următoarele concepte reprezintă o relație HAS-A?
-* moștenirea
+  * moștenirea
-* polimorfismul
+  * polimorfismul
-* **agregarea**
+  * **agregarea**
-* încapsularea
+  * încapsularea
 **R:** Agregarea reprezintă o relație HAS-A (vedeți detalii în laboratorul [[:poo-ca-cd:laboratoare:agregare-mostenire#agregare-vs-mostenire|Agregare și moștenire]]), o clasă ținând referință către obiecte ale altei clase. Moștenirea este o relație IS-A, polimorfismul reprezintă abilitatea unei clase să se comporte ca o altă clasă de pe lanțul de moștenire, iar încapsularea se referă la felul în care împachetăm informațiile dintr-o clasă (ce se poate accesa din exterior).
@@ Line 28: / Line 28: @@
 **3.** Care variantă reprezintă o supraîncărcare corectă pentru metoda:
 ''protected int getGrade(String course)''
-* ''protected int getGrade(String course) throws IOException''
+  * ''protected int getGrade(String course) throws IOException''
-* '' private int getGrade(String course)''
+  * '' private int getGrade(String course)''
-* ''protected long getGrade(String course)''
+  * ''protected long getGrade(String course)''
-* **''public long getGrade(int studID)''**
+  * **''public long getGrade(int studID)''**
 **R:** Regula de bază a suprîncărcarii(overloading-ului) este că numele metodei rămâne același dar antetul acesteia se schimbă, adică diferă numărul parametrilor și/sau tipul acestora. Variantele de răspuns greșite au lăsat parametrul identic, schimbând doar modificatorul de acces, excepțiile aruncate și tipul de return, acest lucru nefiind suficient. Detalii despre overloading găsiți în laboratorul [[:poo-ca-cd:laboratoare:visitor#overloading| More OOP & Visitor Pattern]].
@@ Line 56: / Line 56: @@
 }
 </code>
-* Making tea
+  * Making tea
-* **Making drink**
+  * **Making drink**
-* eroare la compilare, metoda make nu poate fi suprascrisă
+  * eroare la compilare, metoda make nu poate fi suprascrisă
-* 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.
-== Constructori și referințe ==
+==== Constructori și referințe ====
 **5.** Ce se afișează?
 <code Java>
@@ Line 81: / Line 81: @@
 }
 </code>
-* 0 true
+  * 0 true
-* null true
+  * null true
-* **0 false null**
+  * **0 false null**
-* 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 [[:poo-ca-cd:laboratoare:constructori-referinte#constructori|Constructori și referințe]]).
@@ Line 111: / Line 111: @@
 }
 </code>
-* WF
+  * WF
-* **DWF**
+  * **DWF**
-* DW
+  * DW
-* DF
+  * DF
 **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 [[:poo-ca-cd: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?
 <code Java>
@@ Line 133: / Line 133: @@
 }
 </code>
-* final, static, private
+  * final, static, private
-* final, static, protected
+  * final, static, protected
-* 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ă).
 . 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 precizează operațiile 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
 . Dacă B extinde clasa abstractă A și C extinde B, atunci care instanțiere este corectă?
-* C cb = new B();
+  * C cb = new B();
-* B ba = new A();
+  * B ba = new A();
-* **A ab = new B();**
+  * **A ab = new B();**
-* 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?
 A. Nu au acces la membri non-statici ai clasei exterioare
@@ Line 162: / Line 162: @@
 C. Trebuie sa moștenească clasa exterioară
 D. Trebuie instanțiată astfel:'' Outer out = new Outer(); Inner in = out.new Inner();''
-* **A**
+  * **A**
-* B, D
+  * B, D
-* A, B
+  * A, B
-* C
+  * C
 **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".
@@ Line 171: / Line 171: @@
 **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 [[:poo-ca-cd: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ă?
 <code Java>
@@ Line 188: / Line 188: @@
 System.out.println(mySet);
 </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ă
 **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**
-* Vector
+  * Vector
-* niciuna din variante
+  * niciuna din variante
 **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 [[:poo-ca-cd: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 [[:poo-ca-cd:https://dzone.com/articles/covariance-and-contravariance|covarianță]] în cazul genericității, după cum este menționat și în [[:poo-ca-cd: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?
-* un framework pentru integration testing
+  * un framework pentru integration testing
-* **un framework pentru unit testing**
+  * **un framework pentru unit testing**
-* un framwork pentru fuzzy testing
+  * un framwork pentru fuzzy testing
-* un framework pentru system testing
+  * un framework pentru system testing
 **R:** JUnit este framework-ul pentru unit testing studiat la [[:poo-ca-cd: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.
@@ Line 259: / Line 259: @@
 </code>
-* **6**
+  * **6**
-* 4
+  * 4
-* 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?
-* Visitor
+  * Visitor
-* Strategy
+  * Strategy
-* Factory
+  * Factory
-* **Observer**
+  * **Observer**
 **R:** Folosind //Observer// putem avea obiecte "observabile" care atunci când își modifică starea să notifice alte obiecte dependente de acestea "observatori".
@@ Line 298: / Line 298: @@
 }
 </code>
-* **true**
+  * **true**
-* false
+  * false
-* 0
+  * 0
-* 1
+  * 1
 **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
-* Factory Pattern
+  * Factory Pattern
-* **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.

Administrativ

Laboratoare

Teme

Resurse utile

Alte resurse

Arhiva laboratoare

Arhiva teme

Arhiva teste grila

Teste grilă

poo-ca-cd/test/test_2018.1595966903.txt.gz · Last modified: 2020/08/19 23:15 (external edit)

Show page Old revisions

Media Manager Back to top