2.1 Stat
Tilstand er et atferdsdesignmønster. Den brukes i de tilfellene når objektet under kjøringen av programmet må endre oppførselen avhengig av tilstanden.
Mønsteret består av 3 blokker:
Kontekst er en klasse hvis objekter bør endre oppførselen sin avhengig av tilstanden.
State er grensesnittet som hver av de konkrete statene må implementere. Gjennom dette grensesnittet samhandler Context-objektet med staten ved å delegere metodekall til det. Grensesnittet bør inneholde midler for tilbakemelding til objektet hvis oppførsel skal endres.
Til dette brukes en hendelse (mønster Publisher - Abonnent). Dette er nødvendig for å erstatte tilstandsobjektet under kjøringen av programmet når hendelser oppstår. Det kan være tilfeller der selve konteksten med jevne mellomrom spørre tilstandsobjektet for en overgang.
ConcreteState1, ConcreteState2 - klasser av betongtilstander. Skal inneholde informasjon om under hvilke forhold og i hvilke tilstander objektet kan passere fra gjeldende tilstand. For eksempel, fra ConcreteState1, kan et objekt gå til ConcreteState2 og ConcreteState3, og fra ConcreteState2 tilbake til ConcreteState1, og så videre. Objektet til en av dem må inneholde konteksten når den er opprettet.
Du skriver for eksempel et spill der en karakter kan løpe, svømme og fly. Hvis karakteren din kom i vannet, er det rimelig å begrense oppførselen hans i vannet: nå kan han ikke skyte, men han har fortsatt noen handlinger: svøm fremover, høyre, venstre, etc.
Tilstanden til karakteren din kan beskrives av et State-objekt, som har metoder som kan kalles og som vil gjøre noe. Og etter at karakteren din kom i vannet, endrer du bare referansen til et annet State-objekt inne i det - og det endrer tilstand.
2.2 strategi
Strategi er et atferdsdesignmønster for å definere en familie av algoritmer, innkapsle hver enkelt og gjøre dem utskiftbare. Dette lar deg velge en algoritme ved å definere riktig klasse.
Strategimønsteret lar deg endre den valgte algoritmen uavhengig av klientobjektene som bruker den.
Strategimønsteret lar deg bruke forskjellige forretningsregler eller algoritmer avhengig av konteksten. Den brukes i tilfeller der forskjellige algoritmer må brukes på samme sted avhengig av den nåværende tilstanden til systemet (eller dets miljø).
Styrker:
- innkapsling av implementeringen av ulike algoritmer, systemet blir uavhengig av mulige endringer i forretningsregler;
- kaller alle algoritmer på en standard måte;
- ikke bruker brytere og/eller betingede utsagn.
Dette mønsteret ligner noe på Statens mønster, men her er det ikke lagt vekt på staten, men på atferden. La oss si at en karakter i spillet ditt kan bytte våpen. Så når du bytter våpen, kan du ganske enkelt endre referansen til objektet som beskriver hvordan dette våpenet fungerer.
2.3 Malmetode
Abstrakt klasse (abstrakt klasse) - definerer de abstrakte operasjonene som erstattes i arvingene for å implementere trinnene til algoritmen; implementerer en malmetode som definerer skjelettet til algoritmen. Templatemetoden kaller de erstattede og andre operasjonene som er definert i Abstract-klassen.
Betongklasse (betongklasse) - implementerer de erstattede operasjonene på den måten som er nødvendig for implementering. Concrete-klassen antar at de invariante trinnene til algoritmen vil bli utført i AbstractClass.
Dette mønsteret brukes ofte ved behov:
- Engangsbruk av den invariante delen av algoritmen, og etterlater den skiftende delen etter arvingenes skjønn.
- Lokalisering og isolering av kode felles for flere klasser for å unngå duplisering.
- Tillat arvinger å utvide kode bare på visse steder.
Ja, dette mønsteret beskriver bruken av et par: en abstrakt klasse og implementeringen av den.
2.4 Ansvarskjede
Ansvarskjede er et atferdsdesignmønster designet for å organisere ansvarsnivåer i et system.
Malen anbefales for bruk under forhold der:
- i det utviklede systemet er det en gruppe objekter som kan behandle meldinger av en bestemt type;
- alle meldinger må behandles av minst ett systemobjekt;
- meldinger i systemet behandles i henhold til "behandle det selv eller gi det videre til en annen", det vil si at noen meldinger behandles på nivået der de ble mottatt, mens andre videresendes til objekter på et annet nivå.
2.5 Memento
Keeper (Memento) er et atferdsdesignmønster som lar deg fikse og lagre den interne tilstanden til et objekt uten å bryte innkapslingen, slik at den kan gjenopprettes til denne tilstanden senere.
Guardian-mønsteret brukes når:
- det er nødvendig å lagre et øyeblikksbilde av tilstanden til objektet (eller en del av det) for påfølgende restaurering;
- Det direkte grensesnittet for å få tilstanden til et objekt avslører implementeringsdetaljer og bryter objektinnkapsling.