2.1 Staat
Staat is een gedragsontwerppatroon. Het wordt gebruikt in die gevallen waarin het object tijdens de uitvoering van het programma zijn gedrag moet veranderen, afhankelijk van zijn toestand.
![Staat](https://cdn.codegym.cc/images/article/0b64173f-b514-4ae1-a073-6cbb386a5716/800.jpeg)
Het patroon bestaat uit 3 blokken:
Context is een klasse waarvan de objecten hun gedrag moeten veranderen afhankelijk van de status.
Staat is de interface die elk van de concrete staten moet implementeren. Via deze interface communiceert het Context-object met de status door er methodeaanroepen naar toe te delegeren. De interface moet middelen bevatten voor terugkoppeling naar het object waarvan het gedrag moet worden veranderd.
Hiervoor wordt een event gebruikt (patroon Uitgever - Abonnee). Dit is nodig om het toestandsobject te vervangen tijdens de uitvoering van het programma wanneer er gebeurtenissen plaatsvinden. Er kunnen gevallen zijn waarin de Context zelf periodiek het toestandsobject peilt voor een overgang.
ConcreteState1, ConcreteState2 - klassen van concrete toestanden. Moet informatie bevatten over onder welke voorwaarden en in welke toestanden het object de huidige toestand kan verlaten. Van ConcreteState1 kan een object bijvoorbeeld naar ConcreteState2 en ConcreteState3 gaan, en van ConcreteState2 terug naar ConcreteState1, enzovoort. Het object van een van hen moet de context bevatten wanneer deze wordt gemaakt.
Je schrijft bijvoorbeeld een spel waarin een personage kan rennen, zwemmen en vliegen. Als je personage in het water is beland, is het redelijk om zijn gedrag in het water te beperken: nu kan hij niet schieten, maar hij heeft nog steeds enkele acties: vooruit zwemmen, rechts, links, enz.
De toestand van je personage kan worden beschreven door een object Staat, dat methoden heeft die kunnen worden aangeroepen en die iets zullen doen. En nadat je personage in het water is beland, verander je gewoon de verwijzing naar een ander staatsobject erin - en het verandert zijn staat.
2.2 strategie
Strategie is een ontwerppatroon op basis van gedrag om een familie van algoritmen te definiëren, ze allemaal in te kapselen en ze uitwisselbaar te maken. Hiermee kunt u een algoritme kiezen door de juiste klasse te definiëren.
Met het strategiepatroon kunt u het geselecteerde algoritme wijzigen, ongeacht de clientobjecten die het gebruiken.
![Strategie](https://cdn.codegym.cc/images/article/673c4c44-ec33-4d4e-860f-399abc388d8d/800.jpeg)
Met het strategiepatroon kunt u verschillende bedrijfsregels of algoritmen gebruiken, afhankelijk van de context. Het wordt gebruikt in gevallen waarin verschillende algoritmen op dezelfde plaats moeten worden gebruikt, afhankelijk van de huidige status van het systeem (of zijn omgeving).
Sterke punten:
- inkapseling van de implementatie van verschillende algoritmen, het systeem wordt onafhankelijk van mogelijke wijzigingen in bedrijfsregels;
- alle algoritmen op één standaardmanier aanroepen;
- geen gebruik maken van schakelaars en/of voorwaardelijke verklaringen.
Dit patroon lijkt enigszins op het staatspatroon, maar hier ligt de nadruk niet op de staat, maar op het gedrag. Laten we zeggen dat een personage in je spel wapens kan veranderen. Als je dan van wapen wisselt, kun je eenvoudig de verwijzing naar het object wijzigen dat beschrijft hoe dit wapen werkt.
2.3 Sjabloonmethode
![Sjabloonmethode](https://cdn.codegym.cc/images/article/be4df3de-e667-4f4d-9ea7-d3b021879bb2/800.jpeg)
Abstracte klasse (abstracte klasse) - definieert de abstracte bewerkingen die in de erfgenamen worden vervangen om de stappen van het algoritme te implementeren; implementeert een sjabloonmethode die het skelet van het algoritme definieert. De sjabloonmethode roept de vervangen en andere bewerkingen aan die zijn gedefinieerd in de klasse Abstract.
Betonklasse (betonklasse) - implementeert de vervangen bewerkingen op de manier die nodig is voor implementatie. De klasse Concrete gaat ervan uit dat de invariante stappen van het algoritme worden uitgevoerd in de klasse Abstract.
Dit patroon wordt vaak gebruikt wanneer dat nodig is:
- Eenmalig gebruik van het invariante deel van het algoritme, waarbij het wisselende deel wordt overgelaten aan het oordeel van de erfgenamen.
- Lokalisatie en isolatie van code die in verschillende klassen voorkomt om duplicatie te voorkomen.
- Sta erfgenamen toe om code alleen op bepaalde plaatsen uit te breiden.
Ja, dit patroon beschrijft het gebruik van een paar: een abstracte klasse en de implementatie ervan.
2.4 Keten van verantwoordelijkheid
Keten van verantwoordelijkheid is een gedragsontwerppatroon dat is ontworpen om verantwoordelijkheidsniveaus in een systeem te organiseren.
![Keten van verantwoordelijkheid](https://cdn.codegym.cc/images/article/41b55822-dc67-4db3-a0e8-b467bc9f320d/800.jpeg)
De sjabloon wordt aanbevolen voor gebruik in omstandigheden waarin:
- in het ontwikkelde systeem is er een groep objecten die berichten van een bepaald type kunnen verwerken;
- alle berichten moeten door ten minste één systeemobject worden verwerkt;
- berichten in het systeem worden verwerkt volgens het schema "zelf verwerken of doorgeven aan een ander", dat wil zeggen dat sommige berichten worden verwerkt op het niveau waarop ze zijn ontvangen, terwijl andere worden doorgestuurd naar objecten van een ander niveau.
2.5 aandenken
Keeper (Memento) is een gedragsontwerppatroon waarmee u de interne status van een object kunt herstellen en opslaan zonder de inkapseling te schenden, zodat het later in deze staat kan worden hersteld.
![Voogd (aandenken)](https://cdn.codegym.cc/images/article/9b1d2d68-74b7-427c-8d7b-cf44640cf51f/800.jpeg)
Het Guardian-patroon wordt gebruikt wanneer:
- het is noodzakelijk om een momentopname van de staat van het object (of een deel ervan) op te slaan voor later herstel;
- De directe interface voor het verkrijgen van de status van een object legt implementatiedetails bloot en verbreekt objectinkapseling.
GO TO FULL VERSION