4.1 Constructor
Builder este un model de design generativ care oferă o modalitate de a crea un obiect compozit.
Separă construcția unui obiect complex de reprezentarea acestuia, astfel încât același proces de construcție poate avea ca rezultat reprezentări diferite.
![Constructor](https://cdn.codegym.cc/images/article/73f76c69-6b2a-4034-9207-93871bb16fae/800.jpeg)
Puncte forte:
- vă permite să schimbați reprezentarea internă a produsului;
- izolează codul care implementează construcția și prezentarea;
- oferă un control mai fin asupra procesului de proiectare.
Părți slabe:
- algoritmul pentru crearea unui obiect complex nu ar trebui să depindă de ce părți este compus obiectul și de modul în care se potrivesc între ele;
- procesul de construcție trebuie să ofere reprezentări diferite ale obiectului care se construiește.
Un bun exemplu este clasa HttpRequest, care are o subclasă HttpRequest.Builder care poate fi folosită pentru a crea instanțe ale clasei HttpRequest și pentru a se asigura că sunt valide.
4.2 Inițializare leneșă
Inițializarea leneșă este o tehnică de programare atunci când o operațiune care necesită mult resurse (crearea obiectului, calculul valorii) este efectuată imediat înainte ca rezultatul să fie utilizat.
Astfel, inițializarea se realizează „la cerere”, și nu în avans. O idee similară se aplică într-o varietate de domenii: de exemplu, compilarea din mers și conceptul de logistică Just-in-Time.
![Inițializare leneșă](https://cdn.codegym.cc/images/article/fa045df5-58b9-4433-bc35-45548f452406/800.jpeg)
Un caz special de inițializare leneșă - crearea unui obiect în momentul accesării acestuia - este unul dintre modelele de design generativ. Este de obicei folosit împreună cu modele precum Factory Method, Loner și Proxy.
Puncte forte:
- Inițializarea se efectuează numai atunci când este cu adevărat necesară;
- Inițializarea inițială a aplicației este accelerată: tot ce poate fi amânat este amânat.
Părți slabe:
- Nu este posibil să se stabilească în mod explicit ordinea în care obiectele sunt inițializate;
- Există o întârziere la primul acces la obiect, care poate fi critică atunci când se efectuează în paralel o altă operațiune care necesită mult resurse. Din acest motiv, este necesar să se ia în considerare cu atenție oportunitatea utilizării inițializării leneșe în sistemele software cu mai multe fire.
Vă amintiți cum, atunci când scrieți web.xml, puteți specifica ordinea de pornire a servlet-urilor acolo? Acesta este exact rezultatul încărcării leneșe. Tomcat va crea obiecte servlet prima dată când sunt accesate.
4.3 Pool de obiecte
Un grup de obiecte este un model de design părinte, un set de obiecte inițializate și gata de utilizare. Când sistemul are nevoie de un obiect, acesta nu este creat, ci luat din pool. Când un obiect nu mai este necesar, acesta nu este distrus, ci returnat în bazin.
![bazin de obiecte](https://cdn.codegym.cc/images/article/780f7d14-5ad3-42e2-bbfe-409cef49851e/512.jpeg)
Gruparea de obiecte este folosită pentru a îmbunătăți performanța atunci când se creează un obiect la începutul unei lucrări și distrugerea acestuia la sfârșit este costisitoare. Îmbunătățirea performanței este vizibilă mai ales atunci când obiectele sunt create și distruse frecvent, dar doar un număr mic dintre ele există în același timp.
Un pool de obiecte este util atunci când un obiect deține alte resurse decât memoria, cum ar fi socketurile de rețea. Sau dacă colecția de obiecte ocupă o parte semnificativă din memoria computerului și se creează o mulțime de „gunoaie”.
După cum vă amintiți, Tomcat execută fiecare cerere într-un fir separat. Dar firele nu sunt create de fiecare dată din nou, ci sunt stocate în pool-ul de fire. Acest lucru permite executarea mai rapidă a cererilor: atunci când este nevoie de un fir, acesta este pur și simplu preluat din pool. Apropo, întrebarea este: cum ați pune firul care rulează în piscină și ați lua-o din piscină?
GO TO FULL VERSION