Atferdsmønstre

Iterator

Iterator er et atferdsdesignmønster. Representerer et objekt som tillater sekvensiell tilgang til elementene i et aggregert objekt uten å bruke beskrivelser av hvert av de aggregerte objektene.

For eksempel kan elementer som et tre, en koblet liste, en hash-tabell og en matrise krysses (og endres) ved hjelp av et Iterator-objekt.

Iterering gjennom elementene gjøres av iteratorobjektet, ikke av selve samlingen. Dette forenkler grensesnittet og implementeringen av samlingen, og fremmer en mer logisk separasjon av bekymringer.

En funksjon ved en fullt implementert iterator er at koden som bruker iteratoren kanskje ikke vet noe om typen itererte aggregat.

Denne tilnærmingen brukes veldig ofte. For eksempel sender du en SQL-spørring til databasen, og som svar returnerer den deg en iterator (i SQL-termer kalles den vanligvis en markør). Og ved hjelp av den resulterende iteratoren kan du ta rader fra SQL-svaret én etter én.

kommando

En kommando er et atferdsdesignmønster som brukes i objektorientert programmering som representerer en handling. Kommandoobjektet inneholder selve handlingen og dens parametere.

For å kalle en metode trenger du vanligvis:

• objektreferanse
• metodenavn (metodereferanse)
• metodeparameterverdier
• referanse til konteksten som inneholder objektene som brukes

Alle disse dataene må pakkes inn i ett objekt - Kommando ( kommando ).

Men det er ikke alt: noen må tross alt utføre kommandoen. Så dette mønsteret inkluderer fire flere enheter: kommandoer ( kommando ), en kommandomottaker ( mottaker ), en kommandooppringer ( oppkaller ) og en klient ( klient ).

En gjenstandkommandokjenner til mottakeren og kaller mottakermetoden. Mottakerparameterverdier er lagret i kommandoen. Den som ringer (invoker) vet hvordan kommandoen skal utføres og holder muligens styr på de utførte kommandoene. Den som ringer (invoker) vet ingenting om en bestemt kommando, den vet bare om grensesnittet.

Begge objektene (det kallende objektet og flere kommandoobjekter) tilhører klientobjektet. Klienten bestemmer hvilke kommandoer som skal utføres og når. For å utføre en kommando, sender den kommandoobjektet til den som ringer (påkaller).

Å bruke kommandoobjekter gjør det enkelt å bygge delte komponenter som du trenger for å delegere eller foreta metodekall når som helst uten å måtte kjenne klassemetodene eller metodeparameterne.

Ved å bruke caller-objektet (invoker) kan du føre en oversikt over utførte kommandoer uten at klienten trenger å vite om denne regnskapsmodellen (slik regnskapsføring kan for eksempel være nyttig for å implementere kommando angre og gjøre om).

For eksempel skriver du et program som lar deg utføre ulike oppgaver etter en tidsplan. På den ene siden holder programmet ditt styr på oppgaver og administrerer deres lansering, på den andre siden kan det ha flere utførere, som hver kan utføre kommandoer av sin egen type. For eksempel sende SMS, sende brev, sende meldinger til Telegram, etc.

Observatør

Observer er et atferdsdesignmønster. Implementerer en klassemekanisme som lar et objekt av denne klassen motta varsler om endringer i tilstanden til andre objekter og dermed observere dem.

Klasser som andre klasser abonnerer på kalles emner , og abonnerende klasser kalles observatører .

Når du implementerer Observer-mønsteret, brukes følgende klasser vanligvis:

• Observerbar – et grensesnitt som definerer metoder for å legge til, fjerne og varsle observatører;
• Observatør - grensesnittet som observatøren mottar varselet gjennom;
• ConcreteObservable er en konkret klasse som implementerer Observable- grensesnittet ;
• ConcreteObserver er en konkret klasse som implementerer Observer- grensesnittet .

Observer-mønsteret brukes når systemet:

• det er minst ett objekt som sender meldinger;
• det er minst én mottaker av meldinger, og deres nummer og sammensetning kan endres mens programmet kjører;
• unngår sterk kobling av interagerende klasser.

Dette mønsteret brukes ofte i situasjoner der avsenderen av meldinger ikke er interessert i hva mottakerne gjør med informasjonen de får.

Besøkende

Besøkende er et atferdsdesignmønster som beskriver en operasjon som utføres på objekter fra andre klasser. Ved besøk eller endringer er det ikke nødvendig å endre de betjente klassene.

Malen demonstrerer den klassiske teknikken for å gjenopprette tapt type informasjon uten å ty til dobbel-dispatching downcast.

Du må gjøre noen frakoblede operasjoner på en rekke objekter, men du må unngå å forurense koden deres. Og det er ingen måte eller ønske om å spørre typen til hver node og kaste pekeren til riktig type før du utfører ønsket operasjon.

Malen skal brukes hvis:

• det er forskjellige objekter av forskjellige klasser med forskjellige grensesnitt, men operasjoner må utføres på dem som avhenger av spesifikke klasser;
• på strukturen er det nødvendig å utføre forskjellige operasjoner som kompliserer strukturen;
• nye operasjoner på strukturen kommer ofte til.

formidler

Mediator er et atferdsdesignmønster som lar flere objekter samhandle mens de opprettholder løs kobling og unngår behovet for at objekter eksplisitt skal referere til hverandre.

Mediator-mønsteret lar deg sikre samspillet mellom mange objekter, samtidig som det danner en løs kobling og eliminerer behovet for at objekter eksplisitt skal referere til hverandre.

Formidleren definerer et grensesnitt for utveksling av informasjon med objekterKollegaer, En bestemt formidler koordinerer handlingene til objekterKollegaer.

Hver kollegaklasse kjenner til objektet sittFormidler, alle kolleger utveksler informasjon kun med en mellommann, i hans fravær må de utveksle informasjon direkte.

Kollegaersende forespørsler til forhandleren/span> og motta forespørsler fra den. Mekleren implementerer samarbeidsadferd ved å videresende hver forespørsel til en eller flereKollegaer.