Adfærdsmønstre

Iterator

Iterator er et adfærdsdesignmønster. Repræsenterer et objekt, der tillader sekventiel adgang til elementerne i et aggregeret objekt uden brug af beskrivelser af hvert af de aggregerede objekter.

For eksempel kan elementer som et træ, en sammenkædet liste, en hash-tabel og en matrix krydses (og ændres) ved hjælp af et Iterator-objekt.

Iteration gennem elementerne udføres af iteratorobjektet, ikke af selve samlingen. Dette forenkler grænsefladen og implementeringen af ​​samlingen og fremmer en mere logisk adskillelse af bekymringer.

En funktion ved en fuldt implementeret iterator er, at koden, der bruger iteratoren, muligvis ikke ved noget om typen af ​​det itererede aggregat.

Denne tilgang bruges meget ofte. For eksempel sender du en SQL-forespørgsel til databasen, og som svar returnerer den dig en iterator (i SQL-termer kaldes den normalt en markør). Og ved hjælp af den resulterende iterator kan du tage rækker fra SQL-svaret én efter én.

kommando

En kommando er et adfærdsdesignmønster, der bruges i objektorienteret programmering, der repræsenterer en handling. Kommandoobjektet indeholder selve handlingen og dens parametre.

For at kalde en metode skal du normalt bruge:

• objektreference
• metodenavn (metodereference)
• metodeparameterværdier
• reference til den kontekst, der indeholder de anvendte objekter

Alle disse data skal pakkes i ét objekt - Kommando ( kommando ).

Men det er ikke alt: nogen skal trods alt udføre kommandoen. Så dette mønster inkluderer yderligere fire entiteter: kommandoer ( kommando ), en kommandomodtager ( modtager ), en kommandokalder ( opkalder ) og en klient ( klient ).

Et objektkommandokender til modtageren og kalder modtagermetoden. Modtagerparameterværdier gemmes i kommandoen. Den, der ringer (invoker) ved, hvordan kommandoen skal udføres og holder muligvis styr på de udførte kommandoer. Den, der ringer (opkalderen) ved intet om en bestemt kommando, den kender kun til grænsefladen.

Begge objekter (det kaldende objekt og flere kommandoobjekter) tilhører klientobjektet. Klienten bestemmer hvilke kommandoer der skal udføres og hvornår. For at udføre en kommando sender den kommandoobjektet til kalderen (opkalderen).

Brug af kommandoobjekter gør det nemt at bygge delte komponenter, som du skal uddelegere eller foretage metodekald til enhver tid uden at skulle kende klassemetoderne eller metodeparametrene.

Brug af opkaldsobjektet (invoker) giver dig mulighed for at føre en fortegnelse over udførte kommandoer, uden at klienten behøver at vide om denne regnskabsmodel (en sådan bogføring kan f.eks. være nyttig til at implementere kommando fortryd og gentage).

For eksempel skriver du et program, der giver dig mulighed for at udføre forskellige opgaver efter en tidsplan. På den ene side holder dit program styr på opgaver og styrer deres lancering, på den anden side kan det have flere eksekvere, som hver kan udføre kommandoer af sin egen type. For eksempel at sende SMS, sende breve, sende beskeder til Telegram mv.

Observatør

Observer er et adfærdsdesignmønster. Implementerer en klassemekanisme, der gør det muligt for et objekt af denne klasse at modtage meddelelser om ændringer i andre objekters tilstand og dermed observere dem.

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

Ved implementering af Observer-mønsteret bruges følgende klasser almindeligvis:

• Observerbar - en grænseflade, der definerer metoder til at tilføje, fjerne og underrette observatører;
• Observer - grænsefladen, hvorigennem observatøren modtager meddelelsen;
• ConcreteObservable er en konkret klasse, der implementerer Observable- grænsefladen ;
• ConcreteObserver er en konkret klasse, der implementerer Observer- grænsefladen .

Observer-mønsteret bruges, når systemet:

• der er mindst ét ​​objekt, der sender beskeder;
• der er mindst én modtager af beskeder, og deres antal og sammensætning kan ændre sig, mens programmet kører;
• undgår stærk kobling af interagerende klasser.

Dette mønster bruges ofte i situationer, hvor afsenderen af ​​beskeder ikke er interesseret i, hvad modtagerne gør med den information, de får.

Besøgende

Besøgende er et adfærdsdesignmønster, der beskriver en operation, der udføres på objekter fra andre klasser. Ved besøg eller ændringer er der ingen grund til at ændre de servicerede klasser.

Skabelonen demonstrerer den klassiske teknik til at gendanne tabte typeinformationer uden at ty til dobbelt-afsendelse af downcast.

Du skal udføre nogle afbrudte operationer på en række objekter, men du skal undgå at forurene deres kode. Og der er ingen måde eller ønske om at forespørge om typen af ​​hver node og kaste markøren til den korrekte type, før du udfører den ønskede operation.

Skabelonen skal bruges, hvis:

• der er forskellige objekter af forskellige klasser med forskellige grænseflader, men der skal udføres operationer på dem, der afhænger af specifikke klasser;
• på strukturen er det nødvendigt at udføre forskellige operationer, der komplicerer strukturen;
• nye operationer på strukturen tilføjes ofte.

mægler

Mediator er et adfærdsdesignmønster, der gør det muligt for flere objekter at interagere, samtidig med at løs kobling bevares og man undgår behovet for, at objekter eksplicit henviser til hinanden.

Mediator-mønsteret giver dig mulighed for at sikre interaktion mellem mange objekter, samtidig med at de danner en løs kobling og eliminerer behovet for, at objekter eksplicit refererer til hinanden.

Mediatoren definerer en grænseflade til udveksling af information med objekterKollegaer, En bestemt mediator koordinerer objekternes handlingerKollegaer.

Hver kollegaklasse kender sit objektMægler, alle kolleger udveksler kun information med en mellemmand, i hans fravær ville de skulle udveksle oplysninger direkte.

Kollegaersende anmodninger til forhandleren/span> og modtage anmodninger fra den. Mægleren implementerer samarbejdsadfærd ved at videresende hver anmodning til en eller flereKollegaer.