Beteendemönster

Iterator

Iterator är ett beteendedesignmönster. Representerar ett objekt som tillåter sekventiell åtkomst till elementen i ett aggregerat objekt utan att använda beskrivningar av vart och ett av de aggregerade objekten.

Till exempel kan element som ett träd, en länkad lista, en hashtabell och en array passeras (och modifieras) med hjälp av ett Iterator-objekt.

Iteration genom elementen görs av iteratorobjektet, inte av själva samlingen. Detta förenklar gränssnittet och implementeringen av samlingen och främjar en mer logisk separation av bekymmer.

En funktion hos en fullt implementerad iterator är att koden som använder iteratorn kanske inte vet något om typen av itererade aggregat.

Detta tillvägagångssätt används mycket ofta. Till exempel skickar du en SQL-fråga till databasen, och som svar returnerar den dig en iterator (i SQL-termer kallas det vanligtvis en markör). Och med hjälp av den resulterande iteratorn kan du ta rader från SQL-svaret en efter en.

kommando

Ett kommando är ett beteendedesignmönster som används i objektorienterad programmering som representerar en handling. Kommandoobjektet innehåller själva åtgärden och dess parametrar.

För att anropa en metod behöver du vanligtvis:

• objektreferens
• metodnamn (metodreferens)
• metodparametervärden
• referens till sammanhanget som innehåller de använda objekten

Alla dessa data måste packas i ett objekt - Kommando ( kommando ).

Men det är inte allt: trots allt måste någon utföra kommandot. Så detta mönster inkluderar ytterligare fyra enheter: kommandon ( kommando ), en kommandomottagare ( mottagare ), en kommandoanropare ( invoker ) och en klient ( klient ).

Ett objektkommandokänner till mottagaren och anropar mottagarens metod. Mottagarens parametervärden lagras i kommandot. Den som ringer (anroparen) vet hur man utför kommandot och håller eventuellt reda på de utförda kommandona. Den som ringer (anroparen) vet ingenting om ett visst kommando, den vet bara om gränssnittet.

Båda objekten (det anropande objektet och flera kommandoobjekt) tillhör klientobjektet. Klienten bestämmer vilka kommandon som ska utföras och när. För att utföra ett kommando skickar den kommandoobjektet till den som ringer (anroparen).

Att använda kommandoobjekt gör det enkelt att bygga delade komponenter som du behöver för att delegera eller göra metodanrop när som helst utan att behöva känna till klassmetoderna eller metodparametrarna.

Genom att använda caller-objektet (invoker) kan du hålla ett register över utförda kommandon utan att kunden behöver känna till denna redovisningsmodell (en sådan redovisning kan vara användbar, till exempel för att implementera kommandon ångra och gör om).

Du skriver till exempel ett program som låter dig utföra olika uppgifter enligt ett schema. Å ena sidan håller ditt program reda på uppgifter och hanterar deras lansering, å andra sidan kan det ha flera executorer som var och en kan utföra kommandon av sin egen typ. Till exempel att skicka SMS, skicka brev, skicka meddelanden till Telegram osv.

Observatör

Observer är ett beteendedesignmönster. Implementerar en klassmekanism som gör att ett objekt i den här klassen kan ta emot meddelanden om förändringar i andra objekts tillstånd och därmed observera dem.

Klasser som andra klasser prenumererar på kallas Subjects , och prenumererande klasser kallas Observers .

När du implementerar Observer-mönstret används vanligtvis följande klasser:

• Observerbar - ett gränssnitt som definierar metoder för att lägga till, ta bort och meddela observatörer;
• Observer - gränssnittet genom vilket observatören tar emot meddelandet;
• ConcreteObservable är en konkret klass som implementerar gränssnittet Observable ;
• ConcreteObserver är en konkret klass som implementerar Observer- gränssnittet .

Observer-mönstret används när systemet:

• det finns minst ett objekt som skickar meddelanden;
• det finns minst en mottagare av meddelanden, och deras antal och sammansättning kan ändras medan programmet körs;
• undviker stark koppling av interagerande klasser.

Detta mönster används ofta i situationer där avsändaren av meddelanden inte är intresserad av vad mottagarna gör med den information som de får.

Besökare

Besökare är ett beteendedesignmönster som beskriver en operation som utförs på objekt av andra klasser. När du besöker eller byter, finns det inget behov av att ändra de betjänade klasserna.

Mallen demonstrerar den klassiska tekniken för att återställa förlorad typinformation utan att behöva tillgripa dubbelsändning.

Du måste göra några frånkopplade operationer på ett antal objekt, men du måste undvika att förorena deras kod. Och det finns inget sätt eller någon önskan att fråga typen av varje nod och kasta pekaren till rätt typ innan du utför den önskade operationen.

Mallen ska användas om:

• det finns olika objekt av olika klasser med olika gränssnitt, men operationer måste utföras på dem som beror på specifika klasser;
• på strukturen är det nödvändigt att utföra olika operationer som komplicerar strukturen;
• nya operationer på strukturen tillkommer ofta.

medlare

Mediator är ett beteendedesignmönster som tillåter flera objekt att interagera med bibehållen lös koppling och undviker behovet av att objekt explicit hänvisar till varandra.

Mediator-mönstret låter dig säkerställa interaktionen mellan många objekt, samtidigt som det bildar en lös koppling och eliminerar behovet av att objekt explicit hänvisar till varandra.

Medlaren definierar ett gränssnitt för utbyte av information med objektKollegor, En viss medlare koordinerar objektens handlingarKollegor.

Varje kollegaklass känner till sitt objektMedlare, alla kollegor utbyter information endast med en mellanhand, i hans frånvaro skulle de behöva utbyta information direkt.

Kollegorskicka förfrågningar till återförsäljaren/span> och ta emot förfrågningar från den. Medlaren implementerar samarbetsbeteende genom att vidarebefordra varje begäran till en eller fleraKollegor.