Model de design

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 19 decembrie 2021; verificările necesită 6 modificări .

Un model sau model de design ( model de design în limba engleză  ) în dezvoltarea de software este un design arhitectural  repetabil , care este o soluție la o problemă de design într-un context care apare frecvent .

De obicei, un șablon nu este un exemplu complet care poate fi convertit direct în cod ; acesta este doar un exemplu de soluție de 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.

Tiparele „la nivel scăzut” care iau în considerare specificul unui anumit limbaj de programare sunt numite idiomuri . Acestea sunt decizii bune de proiectare care sunt specifice unui anumit limbaj sau platformă software și, prin urmare, nu sunt universale.

La cel mai înalt nivel, există modele arhitecturale care acoperă arhitectura întregului sistem software .

Algoritmii sunt în mod inerent și modele, dar nu modele de proiectare, ci calcule , deoarece rezolvă probleme de calcul.

Istorie

În anii 1970 , arhitectul Christopher Alexander a compilat un set de modele de design. În domeniul arhitecturii, această idee nu a fost dezvoltată la fel de mult ca mai târziu în domeniul dezvoltării software.

În 1987, Kent Beck și Ward Cunningham au preluat ideile lui Alexander și au dezvoltat șabloane pentru software-ul de dezvoltare GUI Smalltalk .

În 1988, Erich Gamma a început să-și scrie teza de doctorat la Universitatea din Zurich despre portabilitatea generală a acestei tehnici în dezvoltarea de software.

Între 1989 și 1991, James Coplien a lucrat la dezvoltarea unor expresii de programare C++ și a publicat Advanced C++ Idioms în 1991.

În același an, Erich Gamma își finalizează teza de doctorat și se mută în SUA , unde, în colaborare cu Richard Helm (Richard Helm), Ralph Johnson (Ralph Johnson) și John Vlissides (John Vlissides), publică cartea Design Patterns - Elemente ale software-ului reutilizabil orientat pe obiecte . Această carte descrie 23 de modele de design. De asemenea, echipa de autori ai acestei cărți este cunoscută publicului sub numele de „Gang of Four” ( ing.  Gang of Four , adesea prescurtat la GoF ). Această carte a cauzat creșterea popularității modelelor de design.

Pro

În comparație cu designul complet independent, șabloanele au o serie de avantaje. Principalul beneficiu al utilizării șabloanelor este reducerea complexității dezvoltării prin abstracții gata făcute pentru a rezolva o întreagă clasă de probleme. Șablonul dă soluției numele, ceea ce facilitează comunicarea între dezvoltatori , permițând referințe la șabloane binecunoscute. Astfel, datorită șabloanelor, detaliile soluțiilor sunt unificate: module, elemente de proiect, iar numărul de erori este redus. Aplicarea șabloanelor este similară conceptual cu utilizarea bibliotecilor de coduri gata făcute. Un model de design bine formulat permite, după ce a găsit o soluție bună, să îl folosești din nou și din nou. Un set de șabloane ajută dezvoltatorul să aleagă opțiunea de design posibilă și cea mai potrivită. [unu]

Contra

În timp ce modificarea cu ușurință a codului pentru a se potrivi unui model cunoscut poate face codul mai ușor de înțeles, conform lui Steve McConnell , există două probleme cu utilizarea modelelor. În primul rând, urmărirea orbește a unui model ales poate duce la complexitatea programului. În al doilea rând, un dezvoltator poate fi tentat să încerce un anumit model fără un motiv anume (vezi Ciocanul de Aur ). [2]

Multe modele de design în designul orientat pe obiecte pot fi gândite ca reproduceri idiomatice ale elementelor limbajelor funcționale [3] . Peter Norvig susține că 16 dintre cele 23 de modele descrise în Gangs of Four sunt mult mai ușor de implementat în limbaje tipizate dinamic decât în ​​C++ sau sunt invizibile [4] . Paul Graham consideră însăși ideea de modele de design ca fiind un antipattern , un semnal că sistemul nu are un nivel suficient de abstractizare și trebuie reelaborat cu atenție [5] . Este ușor de observat că însăși definiția unui șablon ca „ o soluție gata făcută, dar nu un apel direct la o bibliotecă ” înseamnă în esență respingerea reutilizării în favoarea duplicării . Acest lucru poate fi evident inevitabil pentru sistemele complexe atunci când se utilizează limbaje care nu acceptă combinatoare și polimorfism de tip și poate fi exclus în principiu în limbaje care au proprietatea de homoiconicitate (deși nu neapărat eficient), deoarece orice tipar poate să fie implementat în cod executabil [6] .

Tipuri de modele de design

De bază

Nume numele original Descriere Descris în Design Patterns
Șabloane de bază (fundamentale)
Model de delegare model de delegare Un obiect exprimă în exterior un anumit comportament, dar în realitate transferă responsabilitatea efectuării acestui comportament unui obiect asociat. N / A
șablon de proiectare funcțională design funcțional Se asigură că fiecare modul al unui program de calculator are o singură responsabilitate și o realizează cu un minim de efecte secundare asupra altor părți ale programului. N / A
Interfață imuabilă Interfață imuabilă Crearea unui obiect imuabil . N / A
Interfață Interfață O metodă generală de structurare a programelor de calculator astfel încât acestea să fie mai ușor de înțeles. N / A
Marker de interfață Interfață marker Ca atribut (ca marcă a unei entități), este utilizată prezența sau absența unei implementări a interfeței markerului. Limbajele de programare moderne pot folosi în schimb atribute sau adnotări. N / A
Container de proprietate container de proprietate Vă permite să adăugați proprietăți suplimentare pentru clasă la container (în cadrul clasei), în loc să extindeți clasa cu noi proprietăți. N / A
Canal de evenimente canalul de evenimente Extinde modelul Publicare/Abonare pentru a crea un canal centralizat pentru evenimente. Utilizează un proxy pentru a te abona și un proxy pentru a publica evenimentul pe canal. Reprezentantul există separat de editorul sau abonatul real. Un abonat poate primi evenimente publicate de la mai multe entități, chiar dacă este înregistrat pe un singur canal. N / A
Modelele creaționale  sunt modele de design care abstrac procesul de instanțiere. Ele fac posibilă ca sistemul să fie independent de metoda de creare, compunere și prezentare a obiectelor. Șablonul care generează clase folosește moștenirea pentru a modifica clasa instanțiată, în timp ce șablonul care generează obiecte delegă instanțierea unui alt obiect.
Fabrica de abstracte fabrică abstractă O clasă care reprezintă o interfață pentru crearea componentelor sistemului. da
Constructor Constructor O clasă care reprezintă o interfață pentru crearea unui obiect complex. da
metoda din fabrică metoda din fabrică Definește o interfață pentru crearea unui obiect, dar lasă la latitudinea subclaselor să decidă ce clasă să instanțieze. da
Inițializare leneșă Inițializare leneșă Un obiect care este inițializat prima dată când este accesat. Nu
Multiton Multiton Se asigură că clasa are instanțe de obiect denumite și oferă un punct de acces global pentru acestea. Nu
Bazin de obiecte bazin de obiecte O clasă care reprezintă o interfață pentru lucrul cu un set de obiecte inițializate și gata de utilizare. Nu
Prototip prototip Definește o interfață pentru crearea unui obiect prin clonarea unui alt obiect în loc să-l creeze printr-un constructor. da
Achiziția de resurse este inițializare Achiziția de resurse este inițializare (RAII) Obținerea unei resurse este combinată cu inițializarea și eliberarea - cu distrugerea obiectului. Nu
singuratic Singleton O clasă care poate avea o singură instanță. da
Șabloanele structurale (Structural) definesc diverse structuri complexe care modifică interfața obiectelor existente sau implementarea acesteia, facilitând dezvoltarea și optimizarea programului.
Adaptor Adaptor/Wrapper Un obiect care permite altor două obiecte să interacționeze, dintre care unul folosește, iar celălalt oferă o interfață care este incompatibilă cu primul. da
Pod Pod O structură care vă permite să schimbați interfața de apel și interfața de implementare a clasei în mod independent. da
linker Compozit Un obiect care combină obiecte asemănătoare cu el însuși. da
Decorator sau Wrapper decorator O clasă care extinde funcționalitatea unei alte clase fără a utiliza moștenirea. da
Faţadă faţadă Un obiect care abstractizează lucrul cu mai multe clase combinându-le într-o singură entitate. da
Punct unic de intrare controler frontal Oferă o interfață unificată pentru interfețele dintr-un subsistem. Front Controller-ul definește o interfață de nivel înalt care simplifică utilizarea subsistemului. Nu
oportunist Greutatea muștei Acesta este un obiect care se prezintă ca o instanță unică în diferite locuri din program, dar de fapt nu este. da
Adjunct proxy Un obiect care mediază între alte două obiecte și care implementează/restrânge accesul la obiectul accesat prin intermediul acestuia. da
Tiparele comportamentale definesc interactiunea dintre obiecte, crescand astfel flexibilitatea acesteia.
Lanțul de responsabilități Lanț de responsabilitate Conceput pentru a organiza nivelurile de responsabilitate din sistem. da
Comandă , Acțiune, Tranzacție comanda Reprezintă o acțiune. Obiectul de comandă conține acțiunea în sine și parametrii acesteia. da
Interpret interpret Rezolvă o problemă comună, dar care poate fi schimbată. da
Iterator , Cursor Iterator Reprezintă un obiect care vă permite să obțineți acces secvenţial la elementele obiectului agregat fără a utiliza descrieri ale fiecăruia dintre obiectele care fac parte din agregare. da
Mediator mediator Oferă interacțiunea multor obiecte, formând în același timp un cuplaj liber și eliminând nevoia ca obiectele să se refere în mod explicit unele la altele. da
Păstrătorul Memento Permite, fără a încălca încapsularea , să repare și să salveze stările interne ale unui obiect pentru ca ulterior să poată fi restabilit în aceste stări. da
Obiect nul Obiect nul Previne pointerii nuli prin furnizarea unui obiect „implicit”. Nu
Observator sau editor-abonat Observator Definește o dependență unu-la-mulți între obiecte, astfel încât, atunci când starea unui obiect se schimbă, toți cei dependenți de acesta sunt notificați despre eveniment. da
Servitor Servitor Folosit pentru a oferi funcționalități comune unui grup de clase. Nu
Specificație Specificație Folosit pentru a lega logica de afaceri. Nu
Stat Stat Se folosește în acele cazuri când, în timpul execuției programului, obiectul trebuie să își schimbe comportamentul în funcție de starea sa. da
Strategie Strategie Se urmărește definirea unei familii de algoritmi, încapsularea fiecăruia dintre ei și asigurarea interschimbabilității acestora. da
metoda șablonului metoda șablonului Definește baza algoritmului și permite descendenților să redefinească niște pași ai algoritmului fără a-și schimba structura în ansamblu. da
Vizitator Vizitator Descrie o operație care este efectuată pe obiecte din alte clase. Când se schimbă clasa Vizitator, nu este nevoie să se schimbe clasele deservite. da
Politică simplă politică simplă Nu
ascultător de evenimente ascultător de evenimente Nu
Vizitator unic Vizitator cu o singură porție Optimizează implementarea modelului vizitator, care este inițializat, folosit o dată și apoi eliminat. Nu
Vizitator ierarhic Vizitator ierarhic Oferă o modalitate de a parcurge toate nodurile unei structuri de date ierarhice (de ex. arbore). Nu

Concurență  - Concurență

Privat

Modele de programare paralelă ( concurență )

Folosit pentru a scrie mai eficient programe cu mai multe fire și pentru a oferi soluții imediate la problemele de sincronizare .

Nume numele original Descriere
Obiect activ obiect activ Servește la separarea firului de execuție al unei metode de firul în care a fost apelată. Folosește apelurile metodei asincrone și modelele de planificare.
Balking Început Folosit pentru a efectua o acțiune asupra unui obiect numai atunci când acesta este în starea corectă.
Proprietăți de legare Combină mai mulți observatori pentru a menține proprietățile sincronizate între diferite obiecte [7] .
Mesaje Model de mesagerie, Model de design de mesagerie (MDP) Permite componentelor și aplicațiilor să facă schimb de informații (mesaje).
Verificați blocarea Închidere dublu verificată Conceput pentru a reduce supraîncărcarea asociată cu obținerea unui lacăt.
bazat pe evenimente Asincron bazat pe evenimente Abordarea problemelor cu modelul Asynchronous care apar în programele cu fire multiple [8] .
Suspensie păzită Suspensie protejată Folosit pentru a bloca executarea unei acțiuni asupra unui obiect numai atunci când acesta este în starea corectă.
Jumătate sincronizat/Jumătate asincron
Lideri/adepti
blocare Lacăt Un fir de execuție blochează o resursă pentru a împiedica alte fire de execuție să o acceseze sau să o modifice [9] .
Monitorizați Monitorizați Un obiect destinat a fi folosit în siguranță de mai multe fire.
reactor Reactor Proiectat pentru transmiterea sincronă a cererilor către serviciu din una sau mai multe surse.
citire/scriere Blocare citire/scriere Permite mai multor fire de execuție să citească informații din spațiul de stocare partajat în același timp, dar permite doar unui fir odată să le modifice.
Programator Programator Oferă un mecanism pentru implementarea unei politici de programare fără a fi dependent de vreo politică anume.
pool de fire Oferă un grup de fire de execuție pentru procesarea joburilor, de obicei reprezentate ca o coadă.
Stocare specifică firului Servește pentru a furniza variabile globale diferite pentru fire diferite.
Execuție cu un singur thread execuție cu un singur fir Împiedică apelarea unei metode simultan, împiedicând astfel executarea concomitentă a acelei metode.
Model de cooperare model de cooperare Oferă un mecanism pentru a opri în siguranță firele de execuție prin utilizarea unui steag comun pentru a semnala terminarea firului de execuție.
Șabloane de generare a obiectelor Modele flexibile de programare a obiectelor Modele de execuție a sarcinilor Modele de arhitectură de sistem Întreprindere
  • Active Record  este o modalitate de a accesa datele de baze de date relaționale în programarea orientată pe obiecte.
  • delegat de afaceri .
  • Entitate compusă .
  • Vedere compusă .
  • DAO (Data Access Object) Obiect de acces la date.
  • DispatcherView .
  • controler frontal .
  • Filtru de interceptare .
  • Registrul .
  • Activator de servicii .
  • Localizator de servicii .
  • Serviciu pentru muncitor .
  • Fațada sesiunii .
  • Transfer Object Assembler .
  • Transfer obiect
  • Handler Listă de valori .
  • Vizualizați Helper .
  • Unitatea de lucru .
Modele de proiectare de procesare a fluxului
  • Gestionarea individuală a evenimentelor
  • Manipulare folosind statul local
  • Procesare/repartiționare în mai multe etape
  • Procesare folosind un director extern: conectarea unui flux de date la un tabel
  • Conectarea fluxurilor de date
  • Evenimente extraordinare
  • Reprocesare
Modele de proiectare a sistemelor distribuite Șabloane baze de date
  • cartografiere de date
  • Harta de identitate
  • Unitatea de lucru
  • Încărcare leneșă
Altele
  • Depozit / Depozit .

Alte tipuri de modele

De asemenea, astăzi există o serie de alte șabloane.

  • Carrier Rider Mapper descrie furnizarea de acces la informațiile stocate.
  • Șabloanele analitice descriu abordarea de bază pentru scrierea cerințelor pentru software (analiza cerințelor) înainte de a începe procesul propriu-zis de dezvoltare a software-ului.
  • Tiparele de comunicare descriu procesul de comunicare între membrii individuali/angajații unei organizații.
  • Tiparele organizaționale descriu ierarhia organizațională a unei întreprinderi/firme
  • Anti -Design-Patterns descriu ce nu trebuie făcut atunci când dezvoltați programe, arătând erori tipice în proiectare și implementare.

Vezi și

Note

  1. ↑ McConnell, 2005 , p. 100-101.
  2. ↑ McConnell, 2005 , p. 101.
  3. ↑ Design Patterns în Haskell
  4. ↑ Peter Norvig - Modele de proiectare în limbaje dinamice (diapozitive)
  5. ↑ Revenge of the Nerds . — „În lumea OO auziți multe despre „modele”. Mă întreb dacă aceste modele nu sunt uneori dovezi ale cazului (c), compilatorul uman, la lucru. Când văd tipare în programele mele, îl consider un semn de probleme. Forma unui program ar trebui să reflecte doar problema pe care trebuie să o rezolve. Orice altă regularitate a codului este un semn, cel puțin pentru mine, că folosesc abstracții care nu sunt suficient de puternice -- adesea că generez manual expansiunile unor macro-uri pe care trebuie să le scriu".
  6. ↑ Abelson, Sussman. Structura și interpretarea programelor de calculator (SICP). . citate: „ Procedura și abstracțiile de date pot fi construite, funcțiile de ordin superior pot fi utilizate pentru a capta modele de utilizare obișnuite, … iar limbajele încorporate pot fi implementate cu ușurință. „(p.16); „ Unul dintre lucrurile la care ar trebui să ne așteptăm de la un limbaj de programare puternic este capacitatea de a construi abstracții prin denumirea de scheme comune și apoi de a lucra direct asupra acelor abstracții. … Adesea, aceeași schemă de program este utilizată cu proceduri diferite. Pentru a exprima aceste scheme ca concepte, trebuie să construim proceduri care să ia alte proceduri ca argumente sau să le returnăm ca valori. „(p. 70); „ definirea schemelor șablon ca proceduri servește ca mijloc de abstractizare. „(p. 263); capitolul 4.1.5 „Datele ca programe” (p.357-360); conceptul de „ mijloace de abstractizare ” și rolul lor este dat la p.25.
  7. ↑ Proprietăți de legare
  8. ↑ Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson și Morgan Skinner. Model asincron bazat pe evenimente // Professional C# 2008  (neopr.) . - Wiley, 2008. - S.  570 -571. — ISBN 9780470191378 .
  9. ↑ Blocare model
  10. ↑ Interviu și fragment de carte: Designul bazat pe domeniu al lui Dan Haywood, folosind obiecte goale

Literatură

  • Zandstra M. PHP. Obiecte, modele și tehnici de programare. - Ed. a 5-a - Sankt Petersburg. : " Dialectica ", 2019. - S. 736. - ISBN 978-5-907144-54-5 .
  • Fowler, Martin. Refactorizarea codului JavaScript: îmbunătățirea designului codului existent. - Ed. a II-a - Sankt Petersburg. : " Dialectica ", 2019. - P. 464. - ISBN 978-5-907144-59-0 .
  • Gamma E., Helm R., Johnson R., Vlissides J. Techniques for object-oriented design. Design Patterns = PHP Objects, Patterns and Practice, Ediția a treia. — ediția a 3-a. - M . : " Williams ", 2015. - S. 368. - ISBN 978-5-496-00389-6 .
  • Jason McColm Smith. Elemental Design Patterns = Elemental Design Patterns. - M . : " Williams ", 2012. - 304 p. — ISBN 978-5-8459-1818-5 .
  • Fowler, Martin, Beck, Kent, Brant, John, Opdike, William, Roberts, Don. Refactoring: îmbunătățirea designului codului existent. - M . : " Dialectica ", 2019. - 448 p. - ISBN 978-5-9909445-1-0 .
  • Martin Fowler. Patterns of Enterprise Application Architecture (Seria Addison-Wesley Signature). - M . : " Williams ", 2012. - 544 p. - ISBN 978-5-8459-1611-2 .
  • Mark Grand. Modele de proiectare în JAVA. Un catalog de modele de design reutilizabile ilustrate cu UML = Patterns in Java, volumul 1. Un catalog de modele de design reutilizabile ilustrate cu UML. - M . : „ Cunoștințe noi ", 2004. - S. 560. - ISBN 5-94735-047-5 .
  • Craig Larman. Aplicarea UML 2.0 și a modelelor de design = Aplicarea UML și a modelelor: o introducere în analiza și designul orientat pe obiecte și dezvoltarea iterativă. - M . : " Williams ", 2006. - S. 736. - ISBN 0-13-148906-2 .
  • Steve McConnell. Cod perfect = Cod complet. - Sankt Petersburg. : Peter, 2005. - S. 896. - (Clasa de master). - ISBN 5-7502-0064-7 , 5-469-00822-3.
  • Nia Narhid, Gwen Shapira, Todd Palino. Apache Kafka. Procesarea fluxului și analiza datelor. Peter, 2019. - p. 320. - (O'Reilly Bestsellers) - ISBN 978-5-4461-0575-5 .

Link -uri