Ontwerp patronen

1.1 Inleiding tot patronen

Zoals eerder vermeld, begint een programmeur aan een programma door het model te ontwerpen: het samenstellen van een lijst met entiteiten waarop het programma zal werken. En hoe meer entiteiten in het programma, hoe complexer het programma.

Om de complexiteit van het programma te verminderen, proberen ze daarom de interacties van objecten te standaardiseren. En dit is waar ontwerppatronen of ontwerppatronen de programmeur veel helpen . Van Engels ontwerppatroon .

Belangrijk! In het Russisch betekent het woord design meestal grafisch ontwerp, in het Engels is dit niet het geval. Het Engelse woord design lijkt qua betekenis meer op het woord “design” en/of “device”. Het ontwerp van een motor is bijvoorbeeld niet het uiterlijk, maar de interne structuur.

Daarom is een ontwerppatroon precies een ontwerppatroon/patroon. Ik raad je aan om het woord design helemaal niet meer te gebruiken in de zin van 'uiterlijk'. Jij bent de toekomstige Software Engineer, en voor jou is design precies design.

Dus wat is dit ontwerppatroon? Allereerst is een ontwerppatroon een standaardoplossing voor een standaardprobleem . Een goede, effectieve en beproefde oplossing.

Laten we zeggen dat je werd gevraagd om een ​​fiets te ontwerpen, je kunt er twee wielen van maken, drie of zelfs vijf. Dus trouwens, aan het begin van het ontwerp was dat zo. Maar de beproefde aanpak is twee wielen. Maar de huidige voor de hand liggende aanpak ging door pijn en fouten:

Doorgaans is een sjabloon geen volledige oplossing die direct kan worden omgezet in code, het is slechts een voorbeeld van een goede oplossing voor een probleem dat in verschillende situaties kan worden gebruikt.

Objectgeoriënteerde patronen tonen relaties en interacties tussen klassen of objecten , zonder te specificeren welke uiteindelijke klassen of toepassingsobjecten zullen worden gebruikt.

1.2 Geschiedenis van ontwerppatronen

In de jaren '70 werden programmeurs geconfronteerd met de noodzaak om grote programma's te ontwikkelen waaraan hele ontwikkelteams moesten werken. Er werden verschillende methoden geprobeerd om het werk te organiseren, maar de bouwsector had de meeste invloed op de ontwikkeling.

Om het werk van een grote groep mensen te organiseren, werden praktijken en benaderingen uit de bouwsector gebruikt. Het was trouwens van daaruit dat termen als assemblage (build), softwareontwikkelaar (bouwer) en het concept architectuur in de programmering kwamen.

En zoals je misschien wel kunt raden, is het idee voor het ontwerppatroon ook overgenomen uit de bouwsector. Het concept van patronen werd voor het eerst beschreven door Christopher Alexander in The Pattern Language. Steden. Gebouw. Bouw". In dit boek is een speciale taal, patronen, gebruikt om de processen van stadsontwerp te beschrijven.

Patronen in de bouw beschrijven typische beproefde beslissingen: hoe hoog de ramen moeten zijn, hoeveel verdiepingen er in het gebouw moeten zijn, hoeveel ruimte in het microdistrict moet worden toegewezen voor bomen en gazons.

Het is dan ook niet verwonderlijk dat in 1994 het boek “Techniques of Object-Oriented Design. Design Patterns", dat 23 patronen bevat die verschillende problemen van objectgeoriënteerd ontwerpen oplossen.

Het boek is geschreven door 4 auteurs: Erich Gamma, Richard Helm, Ralph Johnson en John Vlissides. De titel van het boek was te lang om te onthouden. Daarom begon iedereen het al snel "boek van de bende van vier" te noemen, dat wil zeggen "een boek van een bende van vier" en toen zelfs "GoF-boek".

En sindsdien zijn er andere ontwerppatronen ontdekt. De "patroonbenadering" is populair geworden in alle gebieden van programmeren, dus nu kun je allerlei soorten patronen vinden buiten het ontwerpen van objecten.

Belangrijk! Patronen zijn geen superoriginele oplossingen, maar integendeel vaak voorkomende, typische oplossingen voor hetzelfde probleem. Goede bewezen oplossingen.

1.3 Lijst met patronen

Veel programmeurs hebben hun hele leven geen enkel patroon geleerd, wat hen er echter niet van weerhoudt om ze te gebruiken. Zoals we al eerder zeiden, patronen zijn goede beproefde oplossingen, en als de programmeur geen dwaas is, dan vindt hij met ervaring zelf dergelijke oplossingen.

Maar waarom, door tientallen pogingen en fouten, tot optimale oplossingen komen als er mensen zijn die deze weg al zijn ingeslagen en boeken hebben geschreven met de essentie van hun ervaring en levenswijsheid?

Je kunt een spijker slaan met een sleutel, maar waarom? Je kunt zelfs een oefening gebruiken als je je best doet. Maar juist een goed en bewust bezit van het instrument onderscheidt een professional van een amateur. En de professional weet dat het belangrijkste kenmerk van de boor hier helemaal niet in zit. Dus waarom moet je patronen kennen?

• Bewezen oplossingen. U besteedt minder tijd aan kant-en-klare oplossingen in plaats van het wiel opnieuw uit te vinden. Sommige beslissingen zou je zelf kunnen bedenken, maar veel kunnen voor jou een ontdekking zijn.
• Standaardisatie van codes. U maakt minder misrekeningen bij het ontwerpen, met behulp van typische uniforme oplossingen, omdat alle verborgen problemen erin al lang zijn gevonden.
• Algemeen programmeerwoordenboek. Je zegt de naam van het patroon in plaats van een uur lang aan andere programmeurs uit te leggen wat voor een gaaf ontwerp je hebt bedacht en welke klassen hiervoor nodig zijn.

Wat zijn de patronen?

Patronen verschillen in het niveau van complexiteit, detail en dekking van het systeem dat wordt ontworpen. Naar analogie met de bouw kun je de veiligheid van een kruispunt vergroten door een stoplicht te plaatsen, of je kunt het kruispunt vervangen door een heel autoknooppunt met onderdoorgangen.

De meest laagdrempelige en eenvoudige patronen zijn idiomen. Ze zijn niet universeel, omdat ze alleen toepasbaar zijn binnen het kader van één programmeertaal.

De meest veelzijdige zijn architecturale patronen die in bijna elke taal kunnen worden geïmplementeerd. Ze zijn nodig om het hele programma te ontwerpen, en niet de afzonderlijke elementen ervan.

Maar het belangrijkste is dat de patronen qua doel verschillen. De patronen waarmee we kennis gaan maken, kunnen worden onderverdeeld in drie hoofdgroepen:

• Aanmaakpatronen zorgen voor de flexibele creatie van objecten zonder onnodige afhankelijkheden in het programma te introduceren.
• Structurele patronen tonen verschillende manieren om relaties tussen objecten op te bouwen.
• Gedragspatronen zorgen voor efficiënte communicatie tussen objecten.

1.4 Inleiding tot UML

Laten we beginnen met te kijken naar dezelfde 23 patronen die werden beschreven in het boek Gang of Four. Zowel de patronen zelf als hun namen zijn bekende dingen, zelfs voor een beginnende programmeur. Ik zal ze aan je voorstellen, maar ik raad je ten zeerste aan om juist dat boek over patronen te lezen.

Ontwerppatronen zijn niet gebonden aan een specifieke programmeertaal, dus de UML wordt meestal gebruikt om ze te beschrijven. Het was 20 jaar geleden erg populair, maar ook nu nog wordt het soms gebruikt. En trouwens, de beschrijving van patronen is nu juist de plek waar het gebruik van UML de standaard is.

Met UML kun je relaties tussen verschillende entiteiten beschrijven. In ons geval zijn dit objecten en klassen.

Relaties tussen klassen worden beschreven door vier soorten pijlen:

	compositie (compositie) - een ondersoort van aggregatie waarin "delen" niet los van het "geheel" kunnen bestaan.
	aggregatie - beschrijft de relatie "deel" - "geheel", waarbij het "deel" los van het "geheel" kan bestaan. De ruit is aangegeven vanaf de "hele" kant.
	afhankelijkheid - een verandering in een entiteit (onafhankelijk) kan de toestand of het gedrag van een andere entiteit (afhankelijk) beïnvloeden. Aan de zijkant van de pijl is een onafhankelijke entiteit aangegeven.
	generalisatie - de relatie van overerving of implementatie van een interface. Aan de kant van de pijl bevindt zich de superklasse of interface.

In feite is alles hier heel eenvoudig. De laatste pijl betekent eigenlijk dat een klasse is geërfd van een andere klasse. En de eerste en tweede pijl zijn dat het ene object een link naar het tweede object opslaat. En het is alles.

Als de schakelruit zwart is, is de schakel zwak: objecten kunnen zonder elkaar bestaan. Als de ruit wit is, zijn de objecten sterk verwant, zoals een klasse HttpRequesten zijn onderliggende klasse HttpRequest.Builder.

1.5 Lijst met patronen

Soorten patronen worden aangeduid met verschillende kleuren en letters:

B- gedragsmatig (gedrag);

C- genereren (creatief);

S- structureel (structureel).

En tot slot een lijst met 23 ontwerppatronen: