Show page

Differences

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

--- poo-ca-cd:laboratoare:constructori-referinte [2022/10/18 21:29]
andrei.vasiliu2211 [Cuvântul-cheie this. Întrebuințări]
+++ poo-ca-cd:laboratoare:constructori-referinte [2024/10/14 10:27] (current)
alexandru.olteanu [Laboratorul 2: Constructori și referințe]
@@ Line 1: / Line 1: @@
-===== Laboratorul 2: Constructori și referințe =====
+===== Laboratorul 2: Constructori, referințe, static =====
 **Video introductiv:** [[https://www.youtube.com/watch?v=Cz3sNXVrYrM&t|link]]
@@ Line 202: / Line 202: @@
 Student s1 = new Student("Bob", 6);
-s2 = s1;
+Student s2 = s1;
 s2.averageGrade = 10;
@@ Line 261: / Line 261: @@
   * a facilita apelarea ''constructorilor'' din alți constructori, evitându-se astfel replicarea unor bucăți de cod (vezi exemplul de la constructori)
-Iată un exemplu în care vom adăuga codului anterior (reprezentat de clasa ''Student''), o clasă nouă:
+Exemplul următor, în care vom adăuga codului anterior (reprezentat de clasa ''Student''), o clasă nouă, va ilustra aceste concepte:
 <code java5 Group.java>
@@ Line 314: / Line 314: @@
     }
-    @Override
     public String toString() {
         return "Nume student: " + name + "\nMedia studentului: " + averageGrade;
@@ Line 336: / Line 336: @@
 */
 </code>
+==== Cuvântul-cheie "static" ====
+După cum am putut observa până acum, de fiecare dată când creăm o instanță a unei clase, valorile câmpurilor din cadrul instanței sunt unice pentru aceasta și pot fi utilizate fără pericolul ca instanţierile următoare să le modifice în mod implicit.
+Să exemplificăm aceasta:
+<code java5>
+Student instance1 = new Student("Alice", 7);
+Student instance2 = new Student("Bob", 6);
+</code>
+În urma acestor apeluri, ''instance1'' și ''instance2'' vor funcționa ca entități independente una de cealaltă, astfel că modificarea câmpului ''nume'' din ''instance1'' nu va avea nici un efect implicit și automat în ''instance2''. Există însă posibilitatea ca uneori, anumite câmpuri din cadrul unei clase să aibă valori independente de instanțele acelei clase (cum este cazul câmpului ''UNIVERSITY_CODE''), astfel că acestea nu trebuie memorate separat pentru fiecare instanță.
+Aceste câmpuri se declară cu atributul **static** și au o locație unică în memorie, care nu depinde de obiectele create din clasa respectivă.
+Pentru a accesa un câmp static al unei clase (presupunând că acesta nu are specificatorul ''private''), se face referire la clasa din care provine, nu la vreo instanță. Același mecanism este disponibil și în cazul metodelor, așa cum putem vedea în continuare:
+<code java5>
+class ClassWithStatics {
+    static String className = "Class With Static Members";
+    private static boolean hasStaticFields = true;
+    public static boolean getStaticFields() {
+         return hasStaticFields;
+    }
+}
+class Test {
+    public static void main(String[] args) {
+        System.out.println(ClassWithStatics.className);
+        System.out.println(ClassWithStatics.getStaticFields());
+    }
+}
+</code>
+Pentru a observa utilitatea variabilelor statice, vom crea o clasa care ține un contor static ce numără câte instanțe a produs clasa în total.
+<code java5>
+class ClassWithStatics {
+    static String className = "Class With Static Members";
+    private static int instanceCount = 0;
+    public ClassWithStatics() {
+        instanceCount++;
+    }
+    public static int getInstanceCount() {
+        return instanceCount;
+    }
+}
+class Test {
+    public static void main(String[] args) {
+        System.out.println(ClassWithStatics.getInstanceCount());       // 0
+        ClassWithStatics instance1 = new ClassWithStatics();
+        ClassWithStatics instance2 = new ClassWithStatics();
+        ClassWithStatics instance3 = new ClassWithStatics();
+        System.out.println(ClassWithStatics.getInstanceCount());       // 3
+    }
+}
+</code>
+Deși am menționat anterior faptul că field-urile și metodele statice se accesează folosind sintaxa ''<NUME_CLASA>.<NUME_METODA/FIELD>'' aceasta nu este singura abordare disponibilă în limbajul Java. Pentru a referi o entitate statică ne putem folosi și de o instanță a clasei în care se află metoda/field-ul accesat.
+<note important>În acest caz nu este relevant dacă tipul obiectului folosit este diferit de cel al referinței în care e stocat(i.e. avem o referință a clasei Animal care referă un obiect de tipul Dog). Pentru apelul unei metode statice se va lua în considerare numai tipul referinței, nu și cel al instanței pe care o referă.</note>
+<code java5>
+class ClassWithStatics {
+    static String className = "Class With Static Members";
+    private static boolean hasStaticFields = true;
+    public static boolean getStaticFields() {
+         return hasStaticFields;
+    }
+}
+class Test {
+    public static void main(String[] args) {
+        ClassWithStatics instance = new ClassWithStatic();
+        System.out.println(instance.className);
+        System.out.println(instance.getStaticFields());
+    }
+}
+</code>
+<note warning>Deși putem accesa o entitate statică folosind o referință, acest lucru este contraindicat. Field-urile și metodele statice aparțin clasei și nu ar trebui să fie în nici un fel dependente de existența unei instanțe.</note>
+Pentru a facilita inițializarea field-urilor statice pe care o clasă le deține, limbajul Java pune la dispoziție posibilitatea de a folosi blocuri statice de cod. Aceste blocuri de cod sunt executate atunci când clasa în cauză este încărcată de către mașina virtuală de Java. Încărcarea unei clase se face în momentul în care aceasta este referită pentru prima dată în cod (se creează o instanță, se apelează o metodă statică etc.)
+În consecință, blocul static de cod se va executa întotdeauna înainte că un obiect să fie creat.
+<code java5>
+class TestStaticBlock {
+    static int staticInt;
+    int objectFieldInt;
+    static {
+        staticInt = 10;
+        System.out.println("static block called");
+    }
+}
+class Main {
+    public static void main(String args[]) {
+        // Even though we didn't create an instance of the TestStaticBlock class,
+        // the static block of code is executed, and the output will be 10
+        System.out.println(TestStaticBlock.staticInt);
+    }
+}
+</code>
+==== Singleton Pattern ====
+Pattern-ul Singleton este utilizat pentru a restricționa numărul de instanțieri ale unei clase la un singur obiect. Astfel, acest design pattern asigură crearea unei singure instanțe a clasei, oferind un punct de acces global al acesteia.
+Cum ne asigurăm că o clasă are o singură instanță și că instanța este ușor accesibilă?
+O variabilă globală face un obiect accesibil, dar nu restricționeaza de la instanțierea mai multor obiecte.
+{{ :poo-ca-cd:laboratoare:singleton1.png?350 |}}
+=== Utilizări ===
+Pattern-ul Singleton este util în următoarele cazuri:
+  * ca un subansamblu al altor pattern-uri:
+    *   împreună cu pattern-urile Abstract Factory, Builder, Prototype etc. De exemplu, în aplicație dorim un singur obiect factory pentru a crea obiecte de un anumit tip.
+  * în locul variabilelor globale. Singleton este preferat variabilelor globale deoarece, printre altele, nu poluează namespace-ul global cu variabile care nu sunt necesare.
+Singleton este utilizat des în situații în care avem obiecte care trebuie accesate din mai multe locuri ale aplicației:
+  * obiecte de tip  [[https://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html|logger]]
+  * obiecte care reprezintă resurse partajate (conexiuni, [[https://docs.oracle.com/javase/tutorial/networking/sockets/definition.html|sockets]] etc.)
+  * obiecte ce conțin configurații pentru aplicație
+  * pentru obiecte de tip //Factory// (acest design pattern va fi prezentat în cadrul laboratorului 9).
+{{ :poo-ca-cd:laboratoare:singleton2.png?500 |}}
+Exemple din API-ul Java: [[http://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html | java.lang.Runtime]], [[http://docs.oracle.com/javase/8/docs/api/java/awt/Toolkit.html | java.awt.Toolkit]]
+Din punct de vedere al design-ului și testării unei aplicații de multe ori se evită folosirea acestui pattern, în test-driven development fiind considerat un **//anti-pattern//**. A avea un obiect Singleton a cărei referință o folosim peste tot prin aplicație introduce multe dependențe între clase și îngreunează testarea individuală a acestora.
+În general, codul care folosește stări globale este mai dificil de testat pentru că implică o cuplare mai strânsă a claselor, și împiedică izolarea unei componente și testarea ei individuală. Dacă o clasă testată folosește un obiect singleton, atunci trebuie testat și singleton-ul. Soluția este simularea //mock-up// a singleton-ului în teste. Încă o problemă a acestei cuplări mai strânse apare atunci când două teste depind unul de celălalt prin modificarea singleton-ului, deci trebuie impusă o anumită ordine a rulării testelor.
+<note tip>Încercați să nu folosiți în exces metode statice și componente Singleton.</note>
+=== Implementare ===
+Aplicarea pattern-ului Singleton constă în implementarea unei metode ce permite crearea unei noi instanțe a clasei dacă aceasta nu există, și întoarcerea unei referințe către aceasta dacă există deja. În Java, pentru a asigura o singură instanțiere a clasei, constructorul trebuie să fie //private//, iar instanța să fie oferită printr-o metodă statică, publică.
+=== Lazy instantiation ===
+În cazul unei implementări Singleton care folosește //lazy instantiation//, clasa respectivă va fi instanțiată **lazy**, utilizând memoria doar în momentul în care acest lucru este necesar deoarece instanța se creează atunci când se apelează ''getInstance()'', acest lucru putând fi un avantaj în unele cazuri, față de clasele non-singleton, pentru care se face //eager instantiation//, deci se alocă memorie încă de la început, chiar dacă instanța nu va fi folosită (mai multe detalii și exemplu în [[http://www.javaworld.com/article/2077568/learn-java/java-tip-67--lazy-instantiation.html |acest articol]])
+{{ .:design-patterns:singletonclassdiagram.png | Diagrama de clase pentru Singleton}}
+<code java>
+public class SingletonLazy {
+    private static SingletonLazy instance = null;
+    private SingletonLazy() {}
+    public static SingletonLazy getInstance() {
+        if (instance == null) {
+            instance = new SingletonLazy();
+        }
+        return instance;
+    }
+}
+</code>
+  * Instanța ''instance'' este //private//
+  * Constructorul este privat ca să nu poată fi apelat decât din clasa respectivă
+  * Instanța este inițial nulă
+  * Instanța este creată la prima rulare a //getInstance()//
+=== Eager instantiation ===
+În ceea ce privește instanțierea **eager**, instanța clasei este creată la momentul [[https://www.baeldung.com/java-classloaders|class loading]], aceasta fiind cea mai ușoară metodă de a crea o clasă singleton. Are totusi un dezavantaj: instanța este creată chiar daca aceasta nu va fi folosita în cadrul aplicației.
+<code java>
+public class SingletonEager {
+    private final static SingletonEager instance = new SingletonEager();
+    private SingletonEager() {}
+    public static SingletonEager getInstance() {
+        return instance;
+    }
+}
+</code>
+În cazul în care clasa Singleton nu folosește multe resurse, aceasta abordare este recomandata. În majoritatea scenariilor, clasele Singleton sunt create pentru resurse precum sistemul de fișiere, conexiunile la baza de date, iar instanțierea eager ar trebui evitată.
+=== Static block instantiation ===
+Implementarea este similară instanțierii //eager//, cu excepția faptului că instanța clasei este creată în blocul static care poate fi opțiune pentru gestionarea excepțiilor.
+ Atât inițializarea eager, cât și cea cu blocuri statice creează instanța înainte de a fi utilizată - motiv pentru care aceasta nu este cea mai bună practică de utilizat.
+<code java>
+public class SingletonStaticBlock {
+    private static SingletonStaticBlock instance = null;
+    static {
+        instance = new SingletonStaticBlock();
+    }
+    private SingletonStaticBlock() {}
+    public static SingletonStaticBlock getInstance() {
+        return instance;
+    }
+}
+</code>
+Respectând cerințele pentru un singleton enunțate mai sus, în Java, putem implementa o componentă de acest tip în mai multe feluri, inclusiv folosind ''enum''-uri în loc de clase. Atunci când îl implementăm trebuie avut în vedere contextul în care îl folosim, astfel încât să alegem o soluție care să funcționeze corect în toate situațiile ce pot apărea în aplicație (unele implementări au probleme atunci când sunt accesate din mai multe thread-uri sau când trebuie serializate).
+//De ce Singleton și nu clase cu membri statici?//
+O clasă de tip Singleton poate fi extinsă, iar metodele ei suprascrise, însă într-o clasă cu metode statice acestea nu pot fi suprascrise (//overriden//) (o discuție pe aceasta temă puteți găsi [[http://geekexplains.blogspot.ro/2008/06/can-you-override-static-methods-in-java.html | aici]], și o comparație între static și dynamic binding [[http://geekexplains.blogspot.ro/2008/06/dynamic-binding-vs-static-binding-in.html | aici]]).
 ====Exerciții====
+Scheletul se afla {{:poo-ca-cd:laboratoare:lab2.zip|aici}}.
 **Task 1** - 3 puncte

Administrativ

Laboratoare

Teme

Resurse utile

Alte resurse

Arhiva laboratoare

Arhiva teme

Arhiva teste grila

Teste grilă

poo-ca-cd/laboratoare/constructori-referinte.1666117748.txt.gz · Last modified: 2022/10/18 21:29 by andrei.vasiliu2211

Show page Old revisions

Media Manager Back to top