Beteendemönster, del 2

2.1 Stat

Tillstånd är ett beteendedesignmönster. Det används i de fall då objektet under körningen av programmet måste ändra sitt beteende beroende på dess tillstånd.

Mönstret består av 3 block:

Kontext är en klass vars objekt bör ändra sitt beteende beroende på tillstånd.

Tillstånd är gränssnittet som var och en av de konkreta staterna måste implementera. Genom detta gränssnitt interagerar kontextobjektet med tillståndet genom att delegera metodanrop till det. Gränssnittet bör innehålla medel för återkoppling till objektet vars beteende ska ändras.

För detta används en händelse (mönster Publisher - Prenumerant). Detta är nödvändigt för att ersätta tillståndsobjektet under körningen av programmet när händelser inträffar. Det kan finnas fall där kontexten själv regelbundet avfrågar tillståndsobjektet för en övergång.

ConcreteState1, ConcreteState2 - klasser av betongtillstånd. Bör innehålla information om under vilka förhållanden och i vilka tillstånd objektet kan passera från nuvarande tillstånd. Till exempel, från ConcreteState1 kan ett objekt gå till ConcreteState2 och ConcreteState3, och från ConcreteState2 tillbaka till ConcreteState1, och så vidare. Objektet för en av dem måste innehålla kontexten när det skapas.

Du skriver till exempel ett spel där en karaktär kan springa, simma och flyga. Om din karaktär hamnade i vattnet, är det rimligt att begränsa sitt beteende i vattnet: nu kan han inte skjuta, men han har fortfarande några handlingar: simma framåt, höger, vänster, etc.

Tillståndet för din karaktär kan beskrivas av ett State-objekt, som har metoder som kan anropas och som kommer att göra något. Och efter att din karaktär kommit i vattnet ändrar du bara referensen till ett annat tillståndsobjekt inuti det - och det ändrar dess tillstånd.

2.2 strategi

Strategi är ett beteendedesignmönster för att definiera en familj av algoritmer, kapsla in var och en och göra dem utbytbara. Detta låter dig välja en algoritm genom att definiera lämplig klass.

Strategimönstret låter dig ändra den valda algoritmen oavsett klientobjekt som använder den.

Strategimönstret låter dig använda olika affärsregler eller algoritmer beroende på sammanhanget. Den används i fall där olika algoritmer måste användas på samma plats beroende på systemets (eller dess miljö) aktuella tillstånd.

Styrkor:

• inkapsling av implementeringen av olika algoritmer, systemet blir oberoende av möjliga förändringar i affärsregler;
• anropa alla algoritmer på ett standardsätt;
• att inte använda switchar och/eller villkorliga uttalanden.

Detta mönster liknar till viss del statens mönster, men här ligger tyngdpunkten inte på staten, utan på beteendet. Låt oss säga att en karaktär i ditt spel kan byta vapen. Sedan när du byter vapen kan du helt enkelt ändra referensen till objektet som beskriver hur detta vapen fungerar.

2.3 Mallmetod

Abstrakt klass (abstrakt klass) - definierar de abstrakta operationerna som ersätts i arvingarna för att implementera stegen i algoritmen; implementerar en mallmetod som definierar skelettet för algoritmen. Mallmetoden anropar den ersatta och andra operationer som definieras i klassen Abstract.

Betongklass (betongklass) - implementerar de ersatta operationerna på det sätt som krävs för implementering. Klassen Concrete antar att de invarianta stegen i algoritmen kommer att utföras i AbstractClass.

Detta mönster används ofta vid behov:

• Engångsanvändning av den invarianta delen av algoritmen, lämnar den föränderliga delen efter arvingarnas gottfinnande.
• Lokalisering och isolering av kod som är gemensam för flera klasser för att undvika dubbelarbete.
• Tillåt arvtagare att utöka koden endast på vissa platser.

Ja, det här mönstret beskriver användningen av ett par: en abstrakt klass och dess implementering.

2.4 Ansvarskedja

Ansvarskedja är ett beteendedesignmönster utformat för att organisera ansvarsnivåer i ett system.

Mallen rekommenderas för användning under förhållanden där:

• i det utvecklade systemet finns en grupp objekt som kan bearbeta meddelanden av en viss typ;
• alla meddelanden måste behandlas av minst ett systemobjekt;
• meddelanden i systemet behandlas enligt schemat "bearbeta det själv eller skicka det vidare till en annan", det vill säga vissa meddelanden behandlas på den nivå där de togs emot, medan andra vidarebefordras till objekt på en annan nivå.

2.5 Memento

Keeper (Memento) är ett beteendedesignmönster som låter dig fixa och spara det interna tillståndet för ett objekt utan att bryta inkapslingen så att det kan återställas till detta tillstånd senare.

Guardian-mönstret används när:

• det är nödvändigt att spara en ögonblicksbild av objektets (eller en del av det) tillstånd för efterföljande restaurering;
• Det direkta gränssnittet för att få ett objekts tillstånd avslöjar implementeringsdetaljer och bryter objektinkapsling.