1.1 Introducere în modele
După cum am menționat mai devreme, un programator începe să lucreze la un program prin proiectarea modelului acestuia: compilarea unei liste de entități pe care programul va funcționa. Și cu cât sunt mai multe entități în program, cu atât programul este mai complex.
Prin urmare, pentru a reduce complexitatea programului, ei încearcă să standardizeze interacțiunile obiectelor. Și aici este locul în care modelele de design sau modelele de design ajută foarte mult programatorul . Din modelul de design englezesc .
Important! În rusă, cuvântul design înseamnă de obicei design grafic, în engleză nu este cazul. Cuvântul englezesc design este mai apropiat ca înțeles de cuvântul „design” și/sau „dispozitiv”. De exemplu, designul unui motor nu este aspectul său, ci structura sa internă.
Prin urmare, un model de design este exact un model/model de design. Vă recomand să încetați cu totul să folosiți cuvântul design în sensul de „aspect”. Sunteți viitorul inginer software și pentru dvs. designul este exact design.
Deci, ce este acest model de design? În primul rând, un model de design este o soluție standard la o problemă standard . O soluție bună, eficientă și testată în timp.
Să presupunem că vi s-a cerut să proiectați o bicicletă, o puteți face pe două roți, trei sau chiar cinci. Deci, apropo, în zorii designului, așa a fost. Dar abordarea testată în timp este două roți. Dar abordarea evidentă actuală a trecut prin durere și greșeli:
![](https://cdn.codegym.cc/images/article/5d016cef-bd5d-42a7-8874-07e416f7f55f/800.jpeg)
De obicei, un șablon nu este o soluție completă care poate fi convertită direct în cod, este doar un exemplu de soluție bună la o problemă care poate fi folosită în diferite situații.
Modelele orientate pe obiecte arată relațiile și interacțiunile dintre clase sau obiecte , fără a specifica ce clase finale sau obiectele aplicației vor fi utilizate.
1.2 Istoria modelelor de design
În anii 70, programatorii s-au confruntat cu nevoia de a dezvolta programe mari la care trebuiau lucrate de echipe întregi de dezvoltare. S-au încercat diverse metode de organizare a muncii, dar industria construcțiilor a influențat cel mai mult dezvoltarea.
Pentru organizarea muncii unui grup mare de oameni s-au folosit practici și abordări din industria construcțiilor. Apropo, de acolo au intrat în programare termeni precum asamblare (construire), Dezvoltator de software (constructor) și conceptul de arhitectură.
Și după cum ați putea ghici, ideea modelului de design a fost preluată și din industria construcțiilor. Conceptul de modele a fost descris pentru prima dată de Christopher Alexander în The Pattern Language. Orase. Clădire. Constructie". În această carte, un limbaj special, modelele, a fost folosit pentru a descrie procesele de proiectare a orașului.
Modelele în construcții au descris decizii tipice testate în timp: cât de înalte ar trebui să fie ferestrele, câte etaje ar trebui să fie în clădire, câtă zonă din microdistrict ar trebui alocată pentru copaci și gazon.
Prin urmare, nu este de mirare că în 1994 cartea „Tehnici de proiectare orientată pe obiecte. Design Patterns”, care include 23 de modele care rezolvă diverse probleme ale designului orientat pe obiecte.
Cartea a fost scrisă de 4 autori: Erich Gamma, Richard Helm, Ralph Johnson și John Vlissides. Titlul cărții era prea lung pentru ca cineva să-l amintească. Prin urmare, în curând toată lumea a început să o numească „carte de la gașca de patru”, adică „o carte de la o gașcă de patru” și apoi chiar „carte GoF”.
Și de atunci, au fost descoperite și alte modele de design. Abordarea „modelului” a devenit populară în toate domeniile de programare, așa că acum puteți găsi tot felul de modele în afara designului obiectelor.
Important! Modelele nu sunt niște soluții super-originale, ci, dimpotrivă, întâlnite frecvent, soluții tipice pentru aceeași problemă. Soluții bune dovedite.
1.3 Lista de modele
Mulți programatori nu au învățat un singur model în întreaga lor viață, ceea ce, totuși, nu îi împiedică să le folosească. După cum am spus mai înainte, modelele sunt soluții bune testate în timp, iar dacă programatorul nu este un prost, atunci cu experiență găsește el însuși astfel de soluții.
Dar de ce, prin zeci de încercări și erori, se ajunge la soluții optime când există oameni care au mers deja pe acest drum și au scris cărți cu chintesența experienței și a înțelepciunii lor de viață?
Poți lovi un cui cu o cheie, dar de ce? Puteți folosi chiar și un burghiu dacă încercați din greu. Dar o bună posesie conștientă a instrumentului este tocmai ceea ce distinge un profesionist de un amator. Și profesionistul știe că principala caracteristică a burghiului nu este deloc în asta. Deci, de ce trebuie să cunoașteți modele?
- Soluții dovedite. Petreceți mai puțin timp folosind soluții disponibile în loc să reinventați roata. Unele decizii le-ai putea gândi la tine, dar multe pot fi o descoperire pentru tine.
- Standardizarea codului. Faceți mai puține greșeli de calcul atunci când proiectați, folosind soluții unificate tipice, deoarece toate problemele ascunse din ele au fost de mult găsite.
- Dicționar de programare generală. Spuneți numele modelului în loc să petreceți o oră explicând altor programatori ce design cool ați venit și ce cursuri sunt necesare pentru asta.
Care sunt modelele?
Modelele diferă în ceea ce privește nivelul de complexitate, detaliu și acoperire a sistemului proiectat. Făcând o analogie cu construcția, puteți crește siguranța unei intersecții prin amenajarea unui semafor sau puteți înlocui intersecția cu un întreg schimb de mașini cu pasaje subterane.
Cele mai simple și de nivel scăzut modele sunt expresii. Ele nu sunt universale, deoarece sunt aplicabile numai în cadrul unui singur limbaj de programare.
Cele mai versatile sunt modelele arhitecturale care pot fi implementate în aproape orice limbă. Ele sunt necesare pentru a proiecta întregul program, și nu elementele sale individuale.
Dar principalul lucru este că modelele diferă ca scop. Tiparele cu care ne vom familiariza pot fi împărțite în trei grupuri principale:
- Modelele de creare se ocupă de crearea flexibilă a obiectelor fără a introduce dependențe inutile în program.
- Modelele structurale arată diferite moduri de a construi relații între obiecte.
- Tiparele comportamentale au grijă de comunicarea eficientă între obiecte.
1.4 Introducere în UML
Să începem prin a ne uita la aceleași 23 de modele care au fost descrise în cartea Gang of Four. Atât modelele în sine, cât și numele lor sunt lucruri familiare chiar și pentru un programator începător. Vă voi prezenta cu ei, dar vă recomand cu căldură să citiți acea carte despre tipare.
Modelele de design nu sunt legate de un limbaj de programare specific, așa că UML este de obicei folosit pentru a le descrie. Era foarte popular în urmă cu 20 de ani, dar și acum este uneori folosit. Și apropo, descrierea modelelor este doar locul în care utilizarea UML este standardul.
Cu UML, puteți descrie relațiile dintre diferite entități. În cazul nostru, acestea sunt obiecte și clase.
Relațiile dintre clase sunt descrise de patru tipuri de săgeți:
![]() |
compoziție (compoziție) - o subspecie de agregare în care „părțile” nu pot exista separat de „întregul”. |
![]() |
agregare – descrie relația „parte” – „întreg”, în care „partea” poate exista separat de „întreg”. Rombul este indicat din partea „întregii”. |
![]() |
dependenta - o schimbare intr-o entitate (independenta) poate afecta starea sau comportamentul altei entitati (dependenta). Pe partea laterală a săgeții este indicată o entitate independentă. |
![]() |
generalizare - relația de moștenire sau implementare a unei interfețe. Pe partea laterală a săgeții este superclasa sau interfața. |
De fapt, totul este foarte simplu aici. Ultima săgeată înseamnă de fapt că o clasă este moștenită de la o altă clasă. Și prima și a doua săgeată sunt că un obiect stochează o legătură către al doilea obiect. Și e tot.
Dacă diamantul de legătură este negru, atunci legătura este slabă: obiectele pot exista unele fără altele. Dacă diamantul este alb, atunci obiectele sunt strâns legate, cum ar fi o clasă HttpRequest
și clasa sa copil HttpRequest.Builder
.
1.5 Lista modelelor
Tipurile de modele vor fi notate prin diferite culori și litere:
B- comportamentale (comportamentale);
C- generatoare (creative);
S- structurale (structurale).
Și, în sfârșit, o listă de 23 de modele de design:
C- Fabrica de abstracte S- Adaptor S— Podul C- Constructor B- Lanțul de responsabilități B- Echipa S- Linker S- Decorator |
S– Fațadă C- metoda din fabrica S- oportunist B- Interpret B- Iterator B- Intermediar B- Păstrătorul C- Prototip |
S- Proxy B— Observator C— Singuratic B- Stat B— Strategie B— Metoda șablonului B— Vizitator |