Introducere în modelele de proiectare creaționale

Introducere

În ingineria software, un model de proiectare descrie o soluție stabilită la problemele cele mai frecvent întâlnite în software proiecta. Reprezintă cele mai bune practici evoluate pe o perioadă lungă de timp prin încercări și erori de către dezvoltatori de software experimentați.

Modelele de design au câștigat popularitate după ce cartea Design Patterns: Elements of Reusable Object-Oriented Software a fost publicată în 1994 de Erich Gamma , John Vlissides, Ralph Johnson și Richard Helm (cunoscut și sub numele de Gang of Four sau GoF).

În acest articol, vom explora modelele de design creaționale și tipurile lor. Ne vom uita și la unele codați probe și discutați situațiile în care aceste modele se potrivesc proiectării noastre.

Modele de proiectare creațională

Modelele de proiectare creațională sunt preocupate de modul în care sunt create obiectele . Acestea reduc complexitatea și instabilitatea prin crearea de obiecte într-un mod controlat.

Noul operator este adesea considerat dăunător, deoarece împrăștie obiecte în întreaga aplicație. De-a lungul timpului, poate deveni dificil să schimbi o implementare, deoarece clasele devin strâns legate.

Modelele de proiectare creațională abordează această problemă prin decuplarea completă a clientului de procesul actual de inițializare.

În acest articol , vom discuta patru tipuri de modele de proiectare creațională:

  1. Singleton – Asigură că există cel mult o singură instanță a unui obiect în întreaga aplicație
  2. Metodă fabrică – Creează obiecte de mai multe clase înrudite fără a specifica obiectul exact care trebuie creat
  3. Abstract Factory – Creează familii de obiecte dependente înrudite
  4. Builder – Construiește obiecte complexe utilizând abordarea pas cu pas

Să discutăm acum fiecare dintre aceste modele în detaliu.

Modelul de proiectare Singleton

Modelul de proiectare Singleton își propune să păstreze o verificare a inițializării obiectelor dintr-o anumită clasă, asigurându-vă că există o singură instanță a obiectului în toată mașina virtuală Java.

O clasă Singleton oferă, de asemenea, un punct de acces global unic la obiect, astfel încât fiecare apel ulterior către punctul de acces returnează doar acel obiect particular.

3.1. Exemplu de model Singleton

Deși modelul Singleton a fost introdus de GoF, implementarea inițială este cunoscută ca fiind problematică în scenarii cu mai multe fire.

Deci, aici, noi ” Vom urma o abordare mai optimă care folosește o clasă interioară statică:

Aici, am creat o clasă interioară statică care deține instanța clasei Singleton. Acesta creează instanța numai atunci când cineva apelează metoda getInstance () și nu când se încarcă clasa exterioară.

Aceasta este o abordare larg utilizată pentru o clasă Singleton, deoarece nu necesită sincronizare, este sigur , impune inițializarea leneșă și are comparativ mai puțină boilerplate.

De asemenea, rețineți că constructorul are modificatorul de acces privat. Aceasta este o cerință pentru crearea unui Singleton, deoarece un constructor public ar însemna că oricine ar putea să-l acceseze și să înceapă să creeze noi instanțe.

Amintiți-vă, aceasta nu este implementarea GoF originală. Pentru versiunea originală, vă rugăm să vizitați acest articol Baeldung legat despre Singletons în Java.

3.2. Când se folosește modelul de design Singleton

  • Pentru resurse care sunt scumpe de creat (cum ar fi baza de date) obiecte de conexiune)
  • Este o bună practică să păstrați toți jurnalele ca singletoni, ceea ce crește performanța
  • Clase care oferă acces la setările de configurare pentru aplicație
  • Clase care conține resurse care sunt accesate în modul partajat

Modelul de proiectare a metodelor din fabrică

Modelul de proiectare din fabrică sau Modelul de proiectare a metodei din fabrică este unul dintre cele mai utilizate modele de proiectare în Java.

Conform GoF, acest model „definește o interfață pentru crearea unui obiect, dar permite subclaselor să decidă ce clasă să instaleze tiate. Metoda Factory permite unei clase să amâne instanțierea la subclasele ”.

Acest model delegă responsabilitatea inițializării unei clase de la client la o anumită clasă de fabrică prin crearea unui tip de constructor virtual.

Pentru a realiza acest lucru, ne bazăm pe o fabrică care ne oferă obiectele, ascunzând detaliile reale de implementare. Obiectele create sunt accesate folosind o interfață comună.

4.1. Exemplu de model de proiectare a metodelor din fabrică

În acest exemplu, vom crea o interfață Polygon care va fi implementată de mai multe clase concrete. O PolygonFactory va fi utilizată pentru a prelua obiecte din această familie :

Să creăm mai întâi interfața Polygon:

În continuare, vom crea câteva implementări precum Square, Triangle etc. care implementează această interfață și returnează un obiect de tip Polygon.

Acum putem crea o fabrică care ia numărul de laturi ca argument și returnează implementarea corespunzătoare a acestei interfețe:

Observați cum clientul se poate baza pe această fabrică pentru a ne oferi un Poligon adecvat, fără a fi nevoie să inițializeze obiectul direct.

4.2. Când se folosește modelul de proiectare a metodelor din fabrică

  • Când se așteaptă ca implementarea unei interfețe sau a unei clase abstracte să se schimbe frecvent
  • Când implementarea curentă nu poate acomoda confortabil schimbările noi
  • Când procesul de inițializare este relativ simplu și constructorul necesită doar o mână de parametri

Model de proiectare abstractă a fabricii

În secțiunea anterioară, am văzut modul în care modelul de proiectare Factory Method ar putea fi folosit pentru a crea obiecte legate de o singură familie.

În schimb, se utilizează modelul Abstract Factory Design Pattern pentru a crea familii de obiecte înrudite sau dependente. Uneori se mai numește și o fabrică de fabrici.

Pentru o explicație detaliată, consultați tutorialul nostru Abstract Factory.

Model de proiectare a constructorului

Modelul de proiectare a constructorului este un alt model de creație conceput pentru a face față construcției de obiecte comparativ complexe.

Când crește complexitatea creării obiectului, modelul de constructor poate separa procesul de instanțiere utilizând altul obiect (un constructor) pentru a construi obiectul.

Acest constructor poate fi apoi utilizat pentru a crea multe alte reprezentări similare utilizând o abordare simplă pas cu pas.

6.1. Exemplu

Modelul original de design Builder introdus de GoF se concentrează pe abstractizare și este foarte bun atunci când se ocupă de obiecte complexe, cu toate acestea, designul este puțin complicat.

Joshua Bloch, în cartea sa Java eficientă, a introdus o versiune îmbunătățită a modelului constructor care este curat, foarte lizibil (deoarece folosește design fluent) și ușor de utilizat din perspectiva clientului. În acest exemplu, vom discuta acea versiune.

Acest exemplu are o singură clasă, BankAccount care conține un constructor ca o clasă interioară statică:

Rețineți că toți modificatorii de acces de pe câmpuri sunt declarați privați, deoarece nu dorim ca obiectele exterioare să le acceseze direct.

Constructorul este, de asemenea, privat, astfel încât numai constructorul atribuit acestui clasa o poate accesa. Toate proprietățile setate în constructor sunt extrase din obiectul constructor pe care îl furnizăm ca argument.

Am „definit BankAccountBuilder într-o clasă interioară statică:

Observăm că am declarat același set de câmpuri pe care le conține clasa exterioară. Orice câmpuri obligatorii sunt necesare ca argumente pentru constructorul clasei interioare, în timp ce câmpurile opționale rămase pot fi specificate folosind metodele setter.

Această implementare acceptă, de asemenea, abordarea de proiectare fluentă, având ca metodele setter să returneze constructorul. object.

În cele din urmă, metoda de compilare apelează constructorul privat al clasei exterioare și se transmite ca argument. BankAccount returnat va fi instanțiat cu parametrii setați de BankAccountBuilder.

Să vedem un exemplu rapid al modelului constructor în acțiune:

6.2. Când se folosește modelul Builder

  1. Când procesul implicat în crearea unui obiect este extrem de complex, cu o mulțime de parametri obligatorii și opționali
  2. Când un creșterea numărului de parametri ai constructorului duce la o listă mare de constructori
  3. Când clientul așteaptă reprezentări diferite pentru obiectul construit

Concluzie

În acest articol, am aflat despre tiparele de design creaționale în Java. Am discutat, de asemenea, cele patru tipuri diferite ale acestora, și anume, Singleton, Factory Method, Abstract Factory și Builder Pattern, avantajele lor, exemple și când ar trebui le folosim.

Ca întotdeauna, fragmentele de cod complete sunt disponibile pe GitHub.

Începeți cu Spring 5 și Spring Boot 2, prin cursul Learn Spring:

> > VERIFICAȚI CURSUL

Leave a Reply

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *