Design mønstre

1.1 Introduksjon til mønstre

Som nevnt tidligere, begynner en programmerer arbeidet med et program ved å designe sin modell: kompilere en liste over enheter som programmet skal operere på. Og jo flere enheter i programmet, jo mer komplekst er programmet.

Derfor, for å redusere kompleksiteten til programmet, prøver de å standardisere interaksjonene til objekter. Og det er her designmønstre eller designmønstre hjelper programmereren mye . Fra engelsk designmønster .

Viktig! På russisk betyr ordet design vanligvis grafisk design, på engelsk er ikke dette tilfellet. Det engelske ordet design er nærmere i betydningen ordet "design" og / eller "enhet". For eksempel er designen til en motor ikke dens utseende, men dens indre struktur.

Derfor er et designmønster akkurat et designmønster/-mønster. Jeg anbefaler at du slutter å bruke ordet design i betydningen "utseende" helt. Du er fremtidens programvareingeniør, og for deg er design akkurat design.

Så hva er dette designmønsteret? Først av alt er et designmønster en standardløsning på et standardproblem . En god, effektiv og tidstestet løsning.

La oss si at du ble bedt om å designe en sykkel, du kan lage den med to hjul, tre eller til og med fem. Så forresten, ved designens begynnelse var det det. Men den tidtestede tilnærmingen er to hjul. Men den nåværende åpenbare tilnærmingen gikk gjennom smerte og feil:

Typisk er en mal ikke en komplett løsning som kan konverteres direkte til kode, den er bare et eksempel på en god løsning på et problem som kan brukes i ulike situasjoner.

Objektorienterte mønstre viser relasjoner og interaksjoner mellom klasser eller objekter uten å spesifisere hvilke endelige klasser eller applikasjonsobjekter som skal brukes.

1.2 Historie om designmønstre

Tilbake på 70-tallet ble programmerere møtt med behovet for å utvikle store programmer som måtte jobbes med av hele utviklingsteam. Ulike metoder for organisering av arbeidet ble prøvd, men byggebransjen påvirket utviklingen mest.

For å organisere arbeidet til en stor gruppe mennesker ble praksis og tilnærminger fra byggebransjen brukt. Forresten, det var derfra begreper som montering (bygg), programvareutvikler (bygger) og arkitekturbegrepet kom inn i programmering.

Og som du kanskje gjetter, er designmønsterideen også hentet fra byggebransjen. Konseptet med mønstre ble først beskrevet av Christopher Alexander i The Pattern Language. Byer. Bygning. Konstruksjon". I denne boken er det brukt et spesielt språk, mønstre, for å beskrive prosessene i bydesign.

Mønstre i konstruksjon beskrev typiske tidstestede beslutninger: hvor høye vinduer skal være, hvor mange etasjer skal være i bygget, hvor mye areal i mikrodistriktet som skal avsettes til trær og plener.

Derfor er det ikke overraskende at i 1994 boken «Techniques of Object-Oriented Design. Design Patterns”, som inkluderer 23 mønstre som løser ulike problemer med objektorientert design.

Boken er skrevet av 4 forfattere: Erich Gamma, Richard Helm, Ralph Johnson og John Vlissides. Tittelen på boken var for lang til at noen kunne huske. Derfor begynte snart alle å kalle det "bok av gjeng på fire", det vil si "en bok fra en gjeng på fire" , og så til og med "GoF-bok".

Og siden den gang har andre designmønstre blitt oppdaget. "Mønster"-tilnærmingen har blitt populær i alle områder av programmering, så nå kan du finne alle slags mønstre utenfor objektdesign.

Viktig! Mønstre er ikke noen superoriginale løsninger, men tvert imot, ofte opptrådte, typiske løsninger på det samme problemet. Gode ​​utprøvde løsninger.

1.3 Liste over mønstre

Mange programmerere har ikke lært et eneste mønster i hele livet, noe som imidlertid ikke hindrer dem i å bruke dem. Som vi sa før, er mønstre gode tidtestede løsninger, og hvis programmereren ikke er en tosk, så finner han med erfaring selv slike løsninger.

Men hvorfor, gjennom dusinvis av forsøk og feiling, komme til optimale løsninger når det er mennesker som allerede har gått denne veien og har skrevet bøker med kvintessensen av deres erfaring og livsvisdom?

Du kan slå en spiker med en skiftenøkkel, men hvorfor? Du kan til og med bruke en drill hvis du prøver hardt. Men en god bevisst besittelse av instrumentet er nettopp det som skiller en profesjonell fra en amatør. Og fagmannen vet at hovedtrekket til boret slett ikke ligger i dette. Så hvorfor trenger du å vite mønstre?

• Utprøvde løsninger. Du bruker mindre tid på å bruke hylleløsninger i stedet for å finne opp hjulet på nytt. Noen avgjørelser kan du tenke deg selv, men mange kan være en oppdagelse for deg.
• Kodestandardisering. Du gjør færre feilberegninger når du designer, ved å bruke typiske enhetlige løsninger, siden alle de skjulte problemene i dem lenge er funnet.
• Generell programmeringsordbok. Du sier navnet på mønsteret i stedet for å bruke en time på å forklare andre programmerere hvilken kul design du kom opp med og hvilke klasser som trengs for dette.

Hva er mønstrene?

Mønstre er forskjellige i kompleksitetsnivå, detaljnivå og dekning av systemet som utformes. Ved å tegne en analogi med konstruksjon kan du øke sikkerheten i et kryss ved å sette opp et trafikklys, eller du kan erstatte krysset med en hel bilutveksling med underganger.

De mest lave og enkle mønstrene er idiomer. De er ikke universelle, siden de bare kan brukes innenfor rammen av ett programmeringsspråk.

De mest allsidige er arkitektoniske mønstre som kan implementeres på nesten alle språk. De er nødvendige for å designe hele programmet, og ikke dets individuelle elementer.

Men det viktigste er at mønstrene er forskjellige i formål. Mønstrene vi skal bli kjent med kan deles inn i tre hovedgrupper:

• Opprettingsmønstre tar seg av fleksibel oppretting av objekter uten å introdusere unødvendige avhengigheter i programmet.
• Strukturelle mønstre viser ulike måter å bygge relasjoner mellom objekter på.
• Atferdsmønstre sørger for effektiv kommunikasjon mellom objekter.

1.4 Introduksjon til UML

La oss starte med å se på de samme 23 mønstrene som ble beskrevet i Gang of Four-boken. Både selve mønstrene og navnene deres er kjente ting selv for en nybegynner programmerer. Jeg skal introdusere deg for dem, men jeg anbefaler på det sterkeste å lese akkurat den boken om mønstre.

Designmønstre er ikke knyttet til et spesifikt programmeringsspråk, så UML brukes vanligvis til å beskrive dem. Det var veldig populært for 20 år siden, men selv nå brukes det noen ganger. Og forresten, beskrivelsen av mønstre er bare stedet hvor bruken av UML er standarden.

Med UML kan du beskrive relasjoner mellom ulike enheter. I vårt tilfelle er dette objekter og klasser.

Forholdet mellom klasser er beskrevet av fire typer piler:

	sammensetning (sammensetning) - en underart av aggregering der "deler" ikke kan eksistere separat fra "helheten".
	aggregering - beskriver forholdet "del" - "helhet", der "delen" kan eksistere separat fra "helheten". Romben er indikert fra "hele" siden.
	avhengighet - en endring i en enhet (uavhengig) kan påvirke tilstanden eller oppførselen til en annen enhet (avhengig). En uavhengig enhet er angitt på siden av pilen.
	generalisering - forholdet til arv eller implementering av et grensesnitt. På siden av pilen er superklassen eller grensesnittet.

Faktisk er alt veldig enkelt her. Den siste pilen betyr faktisk at en klasse er arvet fra en annen klasse. Og den første og andre pilen er at ett objekt lagrer en lenke til det andre objektet. Og det er alt.

Hvis lenkediamanten er svart, er lenken svak: objekter kan eksistere uten hverandre. Hvis diamanten er hvit, er objektene sterkt beslektet, for eksempel en klasse HttpRequestog dens underordnede klasse HttpRequest.Builder.

1.5 Liste over mønstre

Typer mønstre vil bli merket med forskjellige farger og bokstaver:

B- atferdsmessig (atferdsmessig);

C- generere (skapende);

S- strukturell (strukturell).

Og til slutt, en liste over 23 designmønstre: