Tipare generative

3.1 Singleton

Singleton este un model de design generic care garantează că o aplicație cu un singur thread va avea o singură instanță a unei clase și oferă un punct de acces global la această instanță.

Foarte des, programatorilor începători le place să asambleze metode utilitare într-o clasă statică - o clasă care conține doar metode statice. Această abordare are o serie de dezavantaje - de exemplu, nu puteți trece o referință la un obiect dintr-o astfel de clasă, astfel de metode sunt dificil de testat și altele asemenea.

Ca alternativă, a fost propusă o soluție de clasă singleton: o clasă care poate avea un singur obiect. Când încercați să creați acest obiect, acesta este creat numai dacă nu există deja, altfel se returnează o referință la o instanță deja existentă.

Este esențial să fie posibilă utilizarea unei instanțe a clasei, deoarece în multe cazuri devin disponibile o funcționalitate mai largă. De exemplu, această clasă poate implementa unele interfețe și obiectul său poate fi transmis altor metode ca implementare a interfeței. Ce nu se poate face cu un set de metode statice.

Pro:

• Metodele sunt legate de un obiect, nu de o clasă statică - puteți trece un obiect prin referință.
• Metodele obiectelor sunt mult mai ușor de testat și de batjocorit.
• Un obiect este creat doar atunci când este necesar: inițializarea obiectului leneș.
• Accelerarea lansării inițiale a programului dacă există multe single-uri care nu sunt necesare pentru lansare.
• Singur poate fi transformat în continuare într-un șablon-strategie sau mai multe astfel de obiecte.

Minusuri:

• Devine mai dificil să controlezi cursele și întârzierile între fire.
• Este dificil să scrieți un „solitor” cu mai multe fire „din cap”: accesul la un singleton de lungă durată, în mod ideal, nu ar trebui să deschidă un mutex. Soluții mai bine dovedite.
• Un conflict între două fire asupra unui singur fir neterminat va duce la o întârziere.
• Dacă obiectul este creat pentru o perioadă lungă de timp, întârzierea poate interfera cu utilizatorul sau poate perturba timpul real. În acest caz, este mai bine să transferați creația sa în stadiul de inițializare a programului.
• Sunt necesare funcții speciale pentru testarea unitară - de exemplu, pentru a pune biblioteca în modul „non-singuratic” și a izola complet testele unele de altele.
• Este necesară o tactică specială pentru testarea programului terminat, deoarece chiar și conceptul de „cea mai simplă lansare” dispare, deoarece lansarea depinde de configurație.

3.2 Fabrică [Metodă]

O metodă din fabrică este un model de proiectare generic care oferă subclaselor (clase-moștenitori) o interfață pentru crearea instanțelor unei anumite clase. La momentul creării, descendenții pot determina ce clasă să creeze.

Cu alte cuvinte, acest șablon deleagă crearea de obiecte descendenților clasei părinte. Acest lucru vă permite să utilizați nu clase concrete în codul programului, ci să manipulați obiecte abstracte la un nivel superior.

Acest model definește o interfață pentru crearea unui obiect, dar lasă la latitudinea subclaselor să decidă pe ce clasă să se bazeze obiectul. O metodă din fabrică permite unei clase să delege crearea de subclase. Folosit când:

• clasa nu știe dinainte ce obiecte din ce subclase trebuie să creeze.
• o clasă este proiectată astfel încât obiectele pe care le creează să fie specificate prin subclase.
• clasa își deleagă responsabilitățile uneia dintre mai multe subclase de ajutor și este planificat să se determine care clasă preia aceste responsabilități.

3.3 Fabrica de abstracte

O fabrică abstractă este un model de design generic care oferă o interfață pentru crearea unor familii de obiecte înrudite sau interdependente fără a specifica clasele lor concrete.

Modelul este implementat prin crearea unei clase abstracte Factory, care este o interfață pentru crearea componentelor sistemului (de exemplu, pentru o interfață de fereastră, poate crea ferestre și butoane). Apoi sunt scrise clase care implementează această interfață.

Este folosit în cazurile în care programul trebuie să fie independent de procesul și tipurile de obiecte noi create. Când este necesar să se creeze familii sau grupuri de obiecte înrudite, excluzând posibilitatea utilizării simultane a obiectelor din seturi diferite ale acestora în același context.

Puncte forte:

• izolează clase specifice;
• simplifică înlocuirea familiilor de produse;
• garanteaza compatibilitatea produsului.

Să presupunem că programul tău funcționează cu sistemul de fișiere. Apoi, pentru a lucra în Linux, aveți nevoie de obiecte LinuxFile, LinuxDirectory, LinuxFileSystem. Și pentru a lucra în Windwos, aveți nevoie de clasele WindowsFile, WindowsDirectory, WindowsFileSystem.

Clasa Path, care este creată prin Path.of(), este doar un astfel de caz. Path nu este cu adevărat o clasă, ci o interfață și are implementări WindowsPath și LinuxPath. Și ce fel de obiect va fi creat este ascuns din codul dvs. și va fi decis în timpul execuției.

3.4 Prototip

Prototipul este un model de design generativ.

Acest model definește tipurile de obiecte care sunt create folosind o instanță de prototip și creează obiecte noi prin copierea acestui prototip. Vă permite să scăpați de implementare și să urmați principiul „programarii prin interfețe”.

O interfață/clasă abstractă din vârful ierarhiei este specificată ca tip de revenire, iar clasele descendente pot înlocui un moștenitor care implementează acest tip acolo. Mai simplu spus, acesta este modelul de a crea un obiect prin clonarea unui alt obiect în loc să-l creeze printr-un constructor.

Modelul este folosit pentru:

• evitarea efortului suplimentar de a crea un obiect într-un mod standard (adică folosirea unui constructor, deoarece în acest caz vor fi chemați și constructorii ierarhiei strămoși a întregului obiect), când acest lucru este prohibitiv de costisitor pentru aplicație.
• evitați moștenirea creatorului de obiect în aplicația client, așa cum o face modelul abstract din fabrică.

Utilizați acest model de design atunci când programului dvs. nu îi pasă cum creează, compune și prezintă produsele:

• clasele instanțiate sunt determinate în timpul rulării, de exemplu, folosind încărcarea dinamică;
• doriți să evitați construirea de ierarhii de clasă sau fabrică care sunt paralele cu ierarhia claselor de produse;
• Instanțele de clasă pot fi într-una din mai multe stări diferite. Poate fi mai convenabil să setați numărul adecvat de prototipuri și să le clonați, mai degrabă decât să instanțiați manual clasa în starea corespunzătoare de fiecare dată.