Design mønstre

1.1 Introduktion til mønstre

Som tidligere nævnt begynder en programmør arbejdet på et program ved at designe dets model: kompilering af en liste over enheder, som programmet vil fungere på. Og jo flere enheder i programmet, jo mere komplekst er programmet.

Derfor forsøger de, for at reducere programmets kompleksitet, at standardisere interaktionerne mellem objekter. Og det er her designmønstre eller designmønstre hjælper programmøren meget . Fra engelsk designmønster .

Vigtig! På russisk betyder ordet design normalt grafisk design, på engelsk er det ikke tilfældet. Det engelske ord design er nærmere i betydningen ordet "design" og/eller "enhed". For eksempel er designet af en motor ikke dens udseende, men dens indre struktur.

Derfor er et designmønster netop et designmønster/-mønster. Jeg anbefaler, at du helt stopper med at bruge ordet design i betydningen "udseende". Du er fremtidens softwareingeniør, og for dig er design præcis design.

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

Lad os sige, at du blev bedt om at designe en cykel, du kan gøre den til to hjul, tre eller endda fem. Så i øvrigt var det ved designens begyndelse. Men den gennemtestede tilgang er to hjul. Men den nuværende åbenlyse tilgang gik gennem smerte og fejl:

Typisk er en skabelon ikke en komplet løsning, der direkte kan konverteres til kode, den er blot et eksempel på en god løsning på et problem, der kan bruges i forskellige situationer.

Objektorienterede mønstre viser relationer og interaktioner mellem klasser eller objekter uden at specificere, hvilke endelige klasser eller applikationsobjekter der skal bruges.

1.2 Designmønstres historie

Tilbage i 70'erne stod programmører over for behovet for at udvikle store programmer, som hele udviklingsteams skulle arbejde videre med. Forskellige metoder til at organisere arbejdet blev afprøvet, men byggebranchen prægede udviklingen mest.

Til at organisere arbejdet for en stor gruppe mennesker blev der brugt praksis og tilgange fra byggebranchen. Det var i øvrigt derfra, at udtryk som assembly (build), Software Developer (builder) og arkitekturbegrebet kom ind i programmering.

Og som du måske kan gætte, er designmønsterideen også hentet fra byggebranchen. Begrebet mønstre blev først beskrevet af Christopher Alexander i The Pattern Language. Byer. Bygning. Konstruktion". I denne bog er et særligt sprog, mønstre, blevet brugt til at beskrive processerne i bydesign.

Mønstre i byggeriet beskrev typiske tidstestede beslutninger: Hvor høje vinduer skal være, hvor mange etager skal der være i bygningen, hvor meget areal i mikrodistriktet der skal afsættes til træer og græsplæner.

Derfor er det ikke overraskende, at bogen i 1994 “Techniques of Object-Oriented Design. Design Patterns”, som omfatter 23 mønstre, der løser forskellige problemer med objektorienteret design.

Bogen er skrevet af 4 forfattere: Erich Gamma, Richard Helm, Ralph Johnson og John Vlissides. Bogens titel var for lang til, at nogen kunne huske. Derfor begyndte alle snart at kalde det "bog af fire-banden", det vil sige "en bog fra en gruppe på fire" og så endda "GoF-bog".

Og siden da er andre designmønstre blevet opdaget. "Mønster"-tilgangen er blevet populær inden for alle områder af programmering, så nu kan du finde alle mulige mønstre uden for objektdesign.

Vigtig! Mønstre er ikke nogle superoriginale løsninger, men tværtimod hyppigt stødte på typiske løsninger på samme problem. Gode ​​gennemprøvede løsninger.

1.3 Liste over mønstre

Mange programmører har ikke lært et eneste mønster i hele deres liv, hvilket dog ikke forhindrer dem i at bruge dem. Som vi sagde før, er mønstre gode tidstestede løsninger, og hvis programmøren ikke er et fjols, så finder han med erfaring selv sådanne løsninger.

Men hvorfor, gennem snesevis af forsøg og fejl, komme til optimale løsninger, når der er mennesker, der allerede er gået denne vej og har skrevet bøger med indbegrebet af deres erfaring og livsvisdom?

Du kan slå et søm med en skruenøgle, men hvorfor? Du kan endda bruge en boremaskine, hvis du prøver hårdt. Men en god bevidst besiddelse af instrumentet er netop det, der adskiller en professionel fra en amatør. Og fagmanden ved, at borets hovedtræk slet ikke ligger i dette. Så hvorfor har du brug for at kende mønstre?

• Gennemprøvede løsninger. Du bruger mindre tid på at bruge hyldeløsninger i stedet for at genopfinde hjulet. Nogle beslutninger kunne du selv tænke på, men mange kan være en opdagelse for dig.
• Kode standardisering. Du laver færre fejlberegninger, når du designer, ved at bruge typiske samlede løsninger, da alle de skjulte problemer i dem for længst er fundet.
• Generel programmeringsordbog. Du siger navnet på mønsteret i stedet for at bruge en time på at forklare andre programmører, hvilket fedt design du fandt på, og hvilke klasser der er nødvendige for dette.

Hvad er mønstrene?

Mønstrene adskiller sig i niveauet af kompleksitet, detaljering og dækning af det system, der designes. Ved at tegne en analogi med konstruktion kan du øge sikkerheden i et vejkryds ved at sætte et lyskryds op, eller du kan erstatte krydset med en hel biludveksling med underføringer.

De mest lave og enkle mønstre er idiomer. De er ikke universelle, da de kun er anvendelige inden for rammerne af ét programmeringssprog.

De mest alsidige er arkitektoniske mønstre, der kan implementeres på næsten ethvert sprog. De er nødvendige for at designe hele programmet, og ikke dets individuelle elementer.

Men det vigtigste er, at mønstrene er forskellige i formål. De mønstre, som vi vil stifte bekendtskab med, kan opdeles i tre hovedgrupper:

• Oprettelsesmønstre tager sig af den fleksible oprettelse af objekter uden at indføre unødvendige afhængigheder i programmet.
• Strukturelle mønstre viser forskellige måder at bygge relationer mellem objekter på.
• Adfærdsmønstre sørger for effektiv kommunikation mellem objekter.

1.4 Introduktion til UML

Lad os starte med at se på de samme 23 mønstre, som blev beskrevet i Banden af ​​Fire-bogen. Både selve mønstrene og deres navne er velkendte ting selv for en nybegynder programmør. Jeg vil præsentere dig for dem, men jeg anbefaler stærkt at læse netop den bog om mønstre.

Designmønstre er ikke bundet til et bestemt programmeringssprog, så UML bruges normalt til at beskrive dem. Det var meget populært for 20 år siden, men selv nu bliver det nogle gange brugt. Og i øvrigt er beskrivelsen af ​​mønstre netop det sted, hvor brugen af ​​UML er standarden.

Med UML kan du beskrive relationer mellem forskellige enheder. I vores tilfælde er disse objekter og klasser.

Relationer mellem klasser er beskrevet af fire typer pile:

	sammensætning (sammensætning) - en underart af aggregering, hvor "dele" ikke kan eksistere adskilt fra "helheden".
	aggregering - beskriver forholdet "del" - "helhed", hvor "delen" kan eksistere adskilt fra "helheden". Romben er angivet fra "hele" siden.
	afhængighed - en ændring i en enhed (uafhængig) kan påvirke tilstanden eller adfærden for en anden enhed (afhængig). En uafhængig enhed er angivet på siden af ​​pilen.
	generalisering - forholdet mellem arv eller implementering af en grænseflade. På siden af ​​pilen er superklassen eller grænsefladen.

Faktisk er alt meget enkelt her. Den sidste pil betyder faktisk, at en klasse er nedarvet fra en anden klasse. Og den første og anden pil er, at det ene objekt gemmer et link til det andet objekt. Og det er det hele.

Hvis linket diamant er sort, så er linket svagt: objekter kan eksistere uden hinanden. Hvis diamanten er hvid, er objekterne stærkt beslægtede, såsom en klasse HttpRequestog dens underordnede klasse HttpRequest.Builder.

1.5 Liste over mønstre

Typer af mønstre vil blive angivet med forskellige farver og bogstaver:

B- adfærdsmæssig (adfærdsmæssig);

C- generere (kreativ);

S- strukturel (strukturel).

Og endelig en liste over 23 designmønstre: