Mga pattern ng disenyo

1.1 Panimula sa mga pattern

Tulad ng nabanggit kanina, ang isang programmer ay nagsisimulang magtrabaho sa isang programa sa pamamagitan ng pagdidisenyo ng modelo nito: pag-compile ng isang listahan ng mga entity kung saan gagana ang programa. At kung mas maraming entity sa programa, mas kumplikado ang programa.

Samakatuwid, upang mabawasan ang pagiging kumplikado ng programa, sinusubukan nilang i-standardize ang mga pakikipag-ugnayan ng mga bagay. At dito ang mga pattern ng disenyo o mga pattern ng disenyo ay nakakatulong ng malaki sa programmer . Mula sa English design pattern .

Mahalaga! Sa Russian, ang salitang disenyo ay karaniwang nangangahulugang graphic na disenyo, sa Ingles ay hindi ito ang kaso. Ang salitang Ingles na disenyo ay mas malapit sa kahulugan sa salitang "disenyo" at / o "aparato". Halimbawa, ang disenyo ng isang makina ay hindi ang hitsura nito, ngunit ang panloob na istraktura nito.

Samakatuwid, ang pattern ng disenyo ay eksaktong pattern/pattern ng disenyo. Inirerekomenda ko na ihinto mo ang paggamit ng salitang disenyo sa kahulugan ng "hitsura" sa kabuuan. Ikaw ang hinaharap na Software Engineer, at para sa iyo ang disenyo ay eksaktong disenyo.

Kaya ano ang pattern ng disenyo na ito? Una sa lahat, ang pattern ng disenyo ay isang karaniwang solusyon sa isang karaniwang problema . Isang mahusay, epektibo at nasubok sa oras na solusyon.

Sabihin nating hinilingan kang magdisenyo ng bisikleta, maaari mong gawin itong dalawang gulong, tatlo o kahit lima. Kaya pala, sa madaling araw ng disenyo, ito ay. Ngunit ang diskarte na nasubok sa oras ay dalawang gulong. Ngunit ang kasalukuyang halatang diskarte ay dumaan sa sakit at pagkakamali:

Karaniwan, ang isang template ay hindi isang kumpletong solusyon na maaaring direktang i-convert sa code, ito ay isang halimbawa lamang ng isang mahusay na solusyon sa isang problema na maaaring magamit sa iba't ibang mga sitwasyon.

Ang mga pattern na nakatuon sa object ay nagpapakita ng mga ugnayan at pakikipag-ugnayan sa pagitan ng mga klase o object , nang hindi tinukoy kung aling mga huling klase o application object ang gagamitin.

1.2 Kasaysayan ng mga pattern ng disenyo

Noong dekada 70, ang mga programmer ay nahaharap sa pangangailangang bumuo ng malalaking programa na kailangang pagsikapan ng buong mga development team. Sinubukan ang iba't ibang paraan ng pag-oorganisa ng trabaho, ngunit ang industriya ng konstruksiyon ang higit na nakaimpluwensya sa pag-unlad.

Upang ayusin ang gawain ng isang malaking grupo ng mga tao, ginamit ang mga kasanayan at diskarte mula sa industriya ng konstruksiyon. Sa pamamagitan ng paraan, ito ay mula doon na ang mga termino tulad ng pagpupulong (build), Software Developer (builder), at ang konsepto ng arkitektura ay dumating sa programming.

At tulad ng maaari mong hulaan, ang ideya ng pattern ng disenyo ay kinuha din mula sa industriya ng konstruksiyon. Ang konsepto ng mga pattern ay unang inilarawan ni Christopher Alexander sa The Pattern Language. Mga lungsod. Gusali. Konstruksyon". Sa aklat na ito, isang espesyal na wika, mga pattern, ang ginamit upang ilarawan ang mga proseso ng disenyo ng lungsod.

Inilarawan ng mga pattern sa konstruksiyon ang mga tipikal na desisyong nasubok sa oras: kung gaano kataas ang mga bintana, gaano karaming palapag ang dapat nasa gusali, kung gaano karaming lugar sa microdistrict ang dapat ilaan para sa mga puno at damuhan.

Samakatuwid, hindi nakakagulat na noong 1994 ang aklat na "Techniques of Object-Oriented Design. Mga Pattern ng Disenyo", na kinabibilangan ng 23 mga pattern na lumulutas sa iba't ibang mga problema ng object-oriented na disenyo.

Ang aklat ay isinulat ng 4 na may-akda: Erich Gamma, Richard Helm, Ralph Johnson at John Vlissides. Masyadong mahaba ang pamagat ng libro para maalala ng sinuman. Samakatuwid, sa lalong madaling panahon ang lahat ay nagsimulang tawagan itong "libro ng gang ng apat", iyon ay, "isang libro mula sa isang gang ng apat" , at pagkatapos ay kahit na "GoF book".

At mula noon, natuklasan ang iba pang mga pattern ng disenyo. Ang diskarte na "pattern" ay naging popular sa lahat ng mga lugar ng programming, kaya ngayon ay mahahanap mo ang lahat ng uri ng mga pattern sa labas ng disenyo ng bagay.

Mahalaga! Ang mga pattern ay hindi ilang mga super-orihinal na solusyon, ngunit, sa kabaligtaran, madalas na nakakaharap, karaniwang mga solusyon sa parehong problema. Magandang napatunayang solusyon.

1.3 Listahan ng mga pattern

Maraming mga programmer ang hindi natutunan ang isang solong pattern sa kanilang buong buhay, na, gayunpaman, ay hindi pumipigil sa kanila na gamitin ang mga ito. Tulad ng sinabi namin dati, ang mga pattern ay mahusay na mga solusyon na nasubok sa oras, at kung ang programmer ay hindi isang tanga, pagkatapos ay may karanasan siya mismo ang nakakahanap ng mga naturang solusyon.

Ngunit bakit, sa pamamagitan ng dose-dosenang mga pagsubok at pagkakamali, ay nagkakaroon ng pinakamainam na solusyon kapag may mga tao na napunta na sa ganitong paraan at nagsulat ng mga libro na may kabuuan ng kanilang karanasan at karunungan sa buhay?

Maaari mong martilyo ang isang pako gamit ang isang wrench, ngunit bakit? Maaari ka ring gumamit ng drill kung susubukan mo nang husto. Ngunit ang isang mahusay na nakakamalay na pag-aari ng instrumento ay tiyak na nagpapakilala sa isang propesyonal mula sa isang baguhan. At alam ng propesyonal na ang pangunahing tampok ng drill ay wala sa lahat dito. Kaya, bakit kailangan mong malaman ang mga pattern?

• Mga napatunayang solusyon. Gumugugol ka ng mas kaunting oras sa paggamit ng mga off-the-shelf na solusyon sa halip na muling likhain ang gulong. Ang ilang mga desisyon na maaari mong isipin ang iyong sarili, ngunit marami ay maaaring isang pagtuklas para sa iyo.
• Standardisasyon ng code. Gumagawa ka ng mas kaunting mga maling kalkulasyon kapag nagdidisenyo, gamit ang mga tipikal na pinag-isang solusyon, dahil ang lahat ng mga nakatagong problema sa mga ito ay matagal nang natagpuan.
• Pangkalahatang diksyunaryo ng programming. Sabihin mo ang pangalan ng pattern sa halip na gumugol ng isang oras na nagpapaliwanag sa ibang mga programmer kung anong magandang disenyo ang iyong naisip at kung anong mga klase ang kailangan para dito.

Ano ang mga pattern?

Ang mga pattern ay naiiba sa antas ng pagiging kumplikado, detalye, at saklaw ng system na idinisenyo. Pagguhit ng isang pagkakatulad sa konstruksyon, maaari mong dagdagan ang kaligtasan ng isang intersection sa pamamagitan ng paglalagay ng isang ilaw ng trapiko, o maaari mong palitan ang intersection ng isang buong pagpapalitan ng kotse sa mga underpass.

Ang pinakamababang antas at simpleng mga pattern ay mga idyoma. Ang mga ito ay hindi pangkalahatan, dahil ang mga ito ay naaangkop lamang sa loob ng balangkas ng isang programming language.

Ang pinaka maraming nalalaman ay mga pattern ng arkitektura na maaaring ipatupad sa halos anumang wika. Kinakailangan ang mga ito upang idisenyo ang buong programa, at hindi ang mga indibidwal na elemento nito.

Ngunit ang pangunahing bagay ay ang mga pattern ay naiiba sa layunin. Ang mga pattern na makikilala natin ay maaaring nahahati sa tatlong pangunahing grupo:

• Ang mga pattern ng paglikha ay nangangalaga sa nababaluktot na paglikha ng mga bagay nang hindi ipinapasok ang mga hindi kinakailangang dependency sa programa.
• Ang mga istrukturang pattern ay nagpapakita ng iba't ibang paraan ng pagbuo ng mga ugnayan sa pagitan ng mga bagay.
• Ang mga pattern ng pag-uugali ay nangangalaga sa mahusay na komunikasyon sa pagitan ng mga bagay.

1.4 Panimula sa UML

Magsimula tayo sa pamamagitan ng pagtingin sa parehong 23 pattern na inilarawan sa aklat ng Gang of Four. Parehong ang mga pattern mismo at ang kanilang mga pangalan ay pamilyar na mga bagay kahit para sa isang baguhan na programmer. Ipapakilala kita sa kanila, ngunit lubos kong inirerekumenda na basahin ang mismong aklat na iyon tungkol sa mga pattern.

Ang mga pattern ng disenyo ay hindi nakatali sa isang partikular na programming language, kaya ang UML ay karaniwang ginagamit upang ilarawan ang mga ito. Ito ay napakapopular 20 taon na ang nakalilipas, ngunit kahit ngayon ay ginagamit ito minsan. At sa pamamagitan ng paraan, ang paglalarawan ng mga pattern ay ang lugar lamang kung saan ang paggamit ng UML ay ang pamantayan.

Sa UML, maaari mong ilarawan ang mga ugnayan sa pagitan ng iba't ibang entity. Sa aming kaso, ito ay mga bagay at klase.

Ang mga ugnayan sa pagitan ng mga klase ay inilalarawan ng apat na uri ng mga arrow:

	komposisyon (komposisyon) - isang subspecies ng pagsasama-sama kung saan ang "mga bahagi" ay hindi maaaring umiral nang hiwalay sa "buo".
	pagsasama-sama - inilalarawan ang relasyon na "bahagi" - "buo", kung saan ang "bahagi" ay maaaring umiral nang hiwalay sa "buo". Ang rhombus ay ipinahiwatig mula sa "buong" gilid.
	dependency - isang pagbabago sa isang entity (independent) ay maaaring makaapekto sa estado o pag-uugali ng isa pang entity (dependent). Ang isang independiyenteng entity ay nakasaad sa gilid ng arrow.
	generalization - ang kaugnayan ng mana o pagpapatupad ng isang interface. Sa gilid ng arrow ay ang superclass o interface.

Sa katunayan, ang lahat ay napaka-simple dito. Ang huling arrow ay talagang nangangahulugan na ang isang klase ay minana mula sa isa pang klase. At ang una at pangalawang arrow ay ang isang bagay na nag-iimbak ng isang link sa pangalawang bagay. At lahat na.

Kung ang link na brilyante ay itim, kung gayon ang link ay mahina: ang mga bagay ay maaaring umiral nang wala ang isa't isa. Kung ang brilyante ay puti, kung gayon ang mga bagay ay lubos na nauugnay, tulad ng isang klase HttpRequestat ang klase ng bata nito HttpRequest.Builder.

1.5 Listahan ng mga pattern

Ang mga uri ng pattern ay ilalarawan ng iba't ibang kulay at letra:

B- asal (behavioral);

C- pagbuo (paglikha);

S- istruktura (structural).

At sa wakas, isang listahan ng 23 mga pattern ng disenyo: