Design mönster

1.1 Introduktion till mönster

Som nämnts tidigare börjar en programmerare arbetet med ett program genom att designa dess modell: sammanställa en lista över enheter som programmet kommer att arbeta på. Och ju fler enheter i programmet, desto mer komplext är programmet.

Därför, för att minska komplexiteten i programmet, försöker de standardisera interaktionen mellan objekt. Och det är här designmönster eller designmönster hjälper programmeraren mycket . Från engelskt designmönster .

Viktig! På ryska betyder ordet design oftast grafisk design, på engelska är det inte fallet. Det engelska ordet design ligger närmare i betydelsen ordet "design" och / eller "device". Till exempel är designen av en motor inte dess utseende, utan dess inre struktur.

Därför är ett designmönster precis ett designmönster/mönster. Jag rekommenderar att du helt slutar använda ordet design i betydelsen "utseende". Du är den framtida mjukvaruingenjören, och för dig är design precis design.

Så vad är detta designmönster? Först och främst är ett designmönster en standardlösning på ett standardproblem . En bra, effektiv och beprövad lösning.

Låt oss säga att du blev ombedd att designa en cykel, du kan göra den till två hjul, tre eller till och med fem. Så förresten, vid designens gryning var det det. Men det beprövade tillvägagångssättet är två hjul. Men det nuvarande uppenbara tillvägagångssättet gick igenom smärta och misstag:

Vanligtvis är en mall inte en komplett lösning som direkt kan konverteras till kod, det är bara ett exempel på en bra lösning på ett problem som kan användas i olika situationer.

Objektorienterade mönster visar relationer och interaktioner mellan klasser eller objekt utan att specificera vilka slutliga klasser eller applikationsobjekt som ska användas.

1.2 Designmönsters historia

Redan på 70-talet ställdes programmerare inför behovet av att utveckla stora program som hela utvecklingsteam måste arbeta med. Olika metoder för att organisera arbetet prövades, men byggbranschen påverkade utvecklingen mest.

För att organisera arbetet för en stor grupp människor användes praxis och tillvägagångssätt från byggbranschen. Förresten, det var därifrån som termer som montering (bygga), mjukvaruutvecklare (byggare) och begreppet arkitektur kom in i programmering.

Och som du kanske kan gissa så hämtades designmönsteridén också från byggbranschen. Konceptet med mönster beskrevs först av Christopher Alexander i The Pattern Language. Städer. Byggnad. Konstruktion". I den här boken har ett speciellt språk, mönster, använts för att beskriva stadsdesignens processer.

Mönster i konstruktionen beskrev typiska beprövade beslut: hur höga fönster ska vara, hur många våningar ska vara i byggnaden, hur stor yta i mikrodistriktet som ska avsättas för träd och gräsmattor.

Därför är det inte förvånande att 1994 boken ”Techniques of Object-Oriented Design. Design Patterns”, som innehåller 23 mönster som löser olika problem med objektorienterad design.

Boken skrevs av 4 författare: Erich Gamma, Richard Helm, Ralph Johnson och John Vlissides. Bokens titel var för lång för att någon skulle komma ihåg. Därför började alla snart kalla det "bok av fyra-gänget", det vill säga " en bok från ett fyra-gäng" och sedan till och med "GoF-bok".

Och sedan dess har andra designmönster upptäckts. Metoden med "mönster" har blivit populär inom alla områden av programmering, så nu kan du hitta alla möjliga mönster utanför objektdesign.

Viktig! Mönster är inte några superoriginallösningar, utan tvärtom vanliga, typiska lösningar på samma problem. Bra beprövade lösningar.

1.3 Lista över mönster

Många programmerare har inte lärt sig ett enda mönster i hela sitt liv, vilket dock inte hindrar dem från att använda dem. Som vi sa tidigare är mönster bra beprövade lösningar, och om programmeraren inte är en dåre, så hittar han med erfarenhet själv sådana lösningar.

Men varför, genom dussintals försök och misstag, komma fram till optimala lösningar när det finns människor som redan har gått den här vägen och har skrivit böcker med kvintessensen av sin erfarenhet och livsvisdom?

Du kan slå en spik med en skiftnyckel, men varför? Du kan till och med använda en borr om du försöker hårt. Men en bra medveten besittning av instrumentet är just det som skiljer en professionell från en amatör. Och proffsen vet att borrens huvuddrag inte alls finns i detta. Så varför behöver du känna till mönster?

• Beprövade lösningar. Du spenderar mindre tid på att använda färdiga lösningar istället för att uppfinna hjulet på nytt. Vissa beslut kan du tänka dig själv, men många kan vara en upptäckt för dig.
• Kodstandardisering. Du gör färre missräkningar när du designar, med hjälp av typiska enhetliga lösningar, eftersom alla dolda problem i dem länge har hittats.
• Allmän programmeringsordbok. Du säger namnet på mönstret istället för att lägga en timme på att förklara för andra programmerare vilken cool design du kom på och vilka klasser som behövs för detta.

Vilka är mönstren?

Mönstren skiljer sig åt i komplexitetsnivå, detaljnivå och täckning av systemet som designas. Med en analogi med konstruktion kan du öka säkerheten i en korsning genom att sätta upp ett trafikljus, eller så kan du ersätta korsningen med en hel bilbyte med gångtunnel.

De mest låga och enkla mönstren är idiom. De är inte universella, eftersom de bara är tillämpliga inom ramen för ett programmeringsspråk.

De mest mångsidiga är arkitektoniska mönster som kan implementeras på nästan alla språk. De behövs för att utforma hela programmet, och inte dess enskilda delar.

Men huvudsaken är att mönstren skiljer sig åt i syfte. Mönstren som vi kommer att bekanta oss med kan delas in i tre huvudgrupper:

• Skapande mönster tar hand om flexibelt skapande av objekt utan att införa onödiga beroenden i programmet.
• Strukturella mönster visar olika sätt att bygga relationer mellan objekt.
• Beteendemönster tar hand om effektiv kommunikation mellan objekt.

1.4 Introduktion till UML

Låt oss börja med att titta på samma 23 mönster som beskrevs i Gang of Four-boken. Både själva mönstren och deras namn är välbekanta saker även för en nybörjare. Jag kommer att presentera dig för dem, men jag rekommenderar starkt att du läser just den boken om mönster.

Designmönster är inte knutna till ett specifikt programmeringsspråk, så UML används vanligtvis för att beskriva dem. Det var väldigt populärt för 20 år sedan, men även nu används det ibland. Och förresten, beskrivningen av mönster är bara den plats där användningen av UML är standard.

Med UML kan du beskriva relationer mellan olika entiteter. I vårt fall är det objekt och klasser.

Relationer mellan klasser beskrivs av fyra typer av pilar:

	sammansättning (sammansättning) - en underart av aggregering där "delar" inte kan existera separat från "helheten".
	aggregering - beskriver förhållandet "del" - "helhet", där "delen" kan existera separat från "helheten". Romben indikeras från "hela" sidan.
	beroende - en förändring i en enhet (oberoende) kan påverka tillståndet eller beteendet hos en annan enhet (beroende). En oberoende enhet indikeras på sidan av pilen.
	generalisering - förhållandet mellan arv eller implementering av ett gränssnitt. På sidan av pilen finns superklassen eller gränssnittet.

Faktum är att allt är väldigt enkelt här. Den sista pilen betyder faktiskt att en klass ärvs från en annan klass. Och de första och andra pilarna är att ett objekt lagrar en länk till det andra objektet. Och det är allt.

Om länkdiamanten är svart är länken svag: objekt kan existera utan varandra. Om diamanten är vit är föremålen starkt relaterade, till exempel en klass HttpRequestoch dess underordnade klass HttpRequest.Builder.

1.5 Lista över mönster

Typer av mönster kommer att betecknas med olika färger och bokstäver:

B- beteendemässigt (beteende);

C- generering (skapande);

S- strukturell (strukturell).

Och slutligen en lista med 23 designmönster: