Model de proiectare de creație: 1. Model de singleton

Ce este un model de proiectare creațională?

(26 decembrie 2020)

Modelele de proiectare creațională se referă la crearea sau clonarea obiectelor noi ale unei clase. Clonarea are loc atunci când există deja un tip similar de obiect și, în loc să instanțiem un obiect nou, îl clonăm pe cel existent.

Diferitele moduri de a crea obiecte vor influența foarte mult modul în care se rezolvă o problemă. Prin urmare, diferite limbi au impact asupra tiparelor care sunt posibile de utilizat.

Modelul Singleton

Modelul Singleton este utilizat atunci când avem nevoie de o singură instanță a unei clase. De exemplu, realizarea conexiunii DB într-o aplicație, coada de imprimare a imprimantei, folosind jurnalele, deoarece acestea necesită o mulțime de resurse. În toate aceste cazuri, dacă există mai multe instanțe, atunci va crea confuzie, precum și inconsistență.

Acest model este utilizat atunci când instanța este partajată și accesibilă la nivel global în întreaga aplicație. Asigurarea faptului că accesul la resursele partajate este sigur pentru fire este un foarte bun exemplu în care acest tip de model poate fi vital. intenția unui model Singleton este de a oferi acces global la o clasă care este restricționată la o singură instanță.

Să vedem cum este creat obiectul

public class DummyClass{ DummyClass(){}
}DummyClass dc = new DummyClass(); //every time when this line is called a new object of DummyClass is created

Acum, ori de câte ori este nevoie de un obiect din DummyClass, este chemat constructorul acestuia și se creează un obiect. Aceasta se numește Eager initialization.

Dar, în modelul singleton, avem nevoie de o singură instanță a unei clase. Spuneți, dacă o conexiune DB este deja configurată, atunci nu este nevoie să creăm o nouă conexiune DB și ar trebui să folosim conexiunea deja existentă. Să vedem cum să o realizăm.

Aici, am limitat domeniul de aplicare al constructorului la clasa însăși. Deci, pentru a crea obiectul acestei clase, trebuie chemată metoda statică getDBConnection () a clasei. Apoi va verifica dacă obiectul dbConnection este nul, apoi va crea un nou obiect de conexiune și va returna în caz contrar va returna obiectul de conexiune existent.

Acest exemplu demonstrează conceptul de inițializare leneșă . Asta înseamnă că nu creăm obiectul clasei decât dacă este cu adevărat necesar. Prin urmare, acest program este mai eficient din punct de vedere al resurselor.

Există compromisuri la principiul proiectării Singleton. Dacă există mai multe fire de calcul care rulează, ar putea exista probleme cauzate de firele care încearcă să acceseze obiectul partajat unic.

Probleme în implementarea de mai sus

Acum, este posibil ca două firele în același timp apelează metoda getDBConnection și obiectul nu este creat încă. Pentru ambele fire, obiectul dbConnection va fi nul și ambii vor încerca să creeze o nouă instanță și să o folosească în schimb. Prin urmare, este foarte important să vă asigurați că un singur fir poate accesa getDBConnection la un moment dat, astfel încât să nu se creeze mai multe instanțe.

Pentru a realiza un fir -safe clasa singleton este de a sincroniza metoda de acces global, astfel încât un singur fir să poată executa această metodă la un moment dat.

Un singur fir poate accesa simultan acest bloc de cod sincronizat

S-ar putea să vă gândiți că problema este rezolvată acum. Dar, din păcate, nu! Pentru a impune proprietatea singleton am pus o blocare pe metoda statică getDBConnection, dar compromitând performanța acesteia în același timp. Când un obiect este deja creat, atunci, de asemenea, mai multe fire trebuie să aștepte pentru a obține instanța existentă a acelui obiect. Putem face ceva mai bun? Să vedem.

Întrucât este evident că, blocarea este necesară numai atunci când instanța este nulă, astfel încât firele diferite să nu creeze instanțe multiple. Deci, putem pune o condiție sincronizată în condiția if în care verificăm dacă instanța este nulă sau nu și putem adăuga o verificare dublă pentru a elimina scenariile mai multor instanțe.

În utilizare reală, modelul singleton poate fi implementat în diferite moduri. Pur și simplu definește scopul de bază pe care îl servește acest model, dar implementarea codului poate diferi.

Totul este din partea mea. Sper că este clar acum, unde, când și cum să utilizați modelul de design singleton. Puteți face referire la carte, catalogul modelelor de design Gang of Four pentru mai multă înțelegere.

Vă rog să mă anunțați în comentariile de mai jos, dacă aveți îndoieli. Dacă îți place acest blog, te rog să-l împărtășești prietenilor tăi. Fericită inginerie software!

Partea 2: