Iterator
Iterator is een gedragsontwerppatroon. Vertegenwoordigt een object dat sequentiële toegang tot de elementen van een geaggregeerd object mogelijk maakt zonder beschrijvingen van elk van de geaggregeerde objecten te gebruiken.
Elementen zoals een boomstructuur, een gekoppelde lijst, een hashtabel en een array kunnen bijvoorbeeld worden doorlopen (en gewijzigd) met behulp van een Iterator-object.
Itereren door de elementen wordt gedaan door het iterator-object, niet door de verzameling zelf. Dit vereenvoudigt de interface en implementatie van de collectie en bevordert een meer logische scheiding van zorgen.
Een kenmerk van een volledig geïmplementeerde iterator is dat de code die de iterator gebruikt mogelijk niets weet over het type herhaalde aggregatie.
Deze aanpak wordt heel vaak gebruikt. U stuurt bijvoorbeeld een SQL-query naar de database en als antwoord geeft deze u een iterator terug (in SQL-termen wordt dit meestal een cursor genoemd). En met behulp van de resulterende iterator kunt u één voor één rijen uit het SQL-antwoord halen.
commando
Een commando is een gedragsontwerppatroon dat wordt gebruikt in objectgeoriënteerd programmeren en dat een actie vertegenwoordigt. Het opdrachtobject bevat de actie zelf en de bijbehorende parameters.
Om een methode aan te roepen, hebt u meestal het volgende nodig:
- object referentie
- methodenaam (methodereferentie)
- methode parameter waarden
- verwijzing naar de context die de gebruikte objecten bevat
Al deze gegevens moeten in één object worden verpakt - Commando ( commando ).
Maar dat is nog niet alles: iemand moet immers de opdracht uitvoeren. Dit patroon bevat dus nog vier entiteiten: opdrachten ( opdracht ), een opdrachtontvanger ( ontvanger ), een opdrachtoproeper ( invoker ) en een client ( client ).
Een voorwerpcommandokent de ontvanger en roept de ontvangermethode aan. De parameterwaarden van de ontvanger worden opgeslagen in de opdracht. De beller (invoker) weet hoe het commando moet worden uitgevoerd en houdt eventueel de uitgevoerde commando's bij. De beller (invoker) weet niets van een bepaald commando, hij weet alleen van de interface.
Beide objecten (het aanroepende object en verschillende commando-objecten) behoren tot het client-object. De klant beslist welke commando's worden uitgevoerd en wanneer. Om een commando uit te voeren, geeft het het commando-object door aan de beller (invoker).
Het gebruik van opdrachtobjecten maakt het gemakkelijk om gedeelde componenten te bouwen die u op elk gewenst moment moet delegeren of methodeaanroepen moet doen zonder dat u de klassenmethoden of methodeparameters hoeft te kennen.
Door het caller-object (invoker) te gebruiken, kunt u een record bijhouden van uitgevoerde opdrachten zonder dat de klant dit boekhoudmodel hoeft te kennen (een dergelijke boekhouding kan bijvoorbeeld handig zijn om commando's ongedaan te maken en opnieuw uit te voeren).
U schrijft bijvoorbeeld een programma waarmee u verschillende taken volgens een schema kunt uitvoeren. Aan de ene kant houdt uw programma de taken bij en beheert het starten ervan, aan de andere kant kan het verschillende uitvoerders hebben, die elk commando's van hun eigen type kunnen uitvoeren. Bijvoorbeeld SMS versturen, brieven versturen, berichten sturen naar Telegram, etc.
Waarnemer
Observer is een gedragsontwerppatroon. Implementeert een klassemechanisme waarmee een object van deze klasse meldingen kan ontvangen over veranderingen in de status van andere objecten en deze dus kan observeren.
Klassen waarop andere klassen zich abonneren , worden Subjects genoemd en klassen die zich abonneren heten Observers .
Bij het implementeren van het Observer-patroon worden de volgende klassen vaak gebruikt:
- Waarneembaar - een interface die methoden definieert voor het toevoegen, verwijderen en informeren van waarnemers;
- Waarnemer - de interface waarmee de waarnemer de melding ontvangt;
- ConcreteObservable is een concrete klasse die de Observable- interface implementeert ;
- ConcreteObserver is een concrete klasse die de Observer- interface implementeert .
Het Observer-patroon wordt gebruikt wanneer het systeem:
- er is tenminste één object dat berichten verstuurt;
- er is ten minste één ontvanger van berichten en hun aantal en samenstelling kunnen veranderen terwijl de toepassing actief is;
- vermijdt een sterke koppeling van op elkaar inwerkende klassen.
Dit patroon wordt vaak gebruikt in situaties waarin de afzender van berichten niet geïnteresseerd is in wat de ontvangers doen met de aan hen verstrekte informatie.
Bezoeker
Visitor is een gedragsontwerppatroon dat een bewerking beschrijft die wordt uitgevoerd op objecten van andere klassen. Bij bezoek of wijziging is het niet nodig om de serviceklassen te wijzigen.
De sjabloon demonstreert de klassieke techniek voor het herstellen van verloren type-informatie zonder toevlucht te nemen tot downcast met dubbele verzending.
U moet een aantal niet-verbonden bewerkingen uitvoeren op een aantal objecten, maar u moet voorkomen dat u hun code vervuilt. En er is geen manier of wens om het type van elk knooppunt op te vragen en de aanwijzer naar het juiste type te casten voordat de gewenste bewerking wordt uitgevoerd.
De sjabloon moet worden gebruikt als:
- er zijn verschillende objecten van verschillende klassen met verschillende interfaces, maar er moeten bewerkingen op worden uitgevoerd die afhankelijk zijn van specifieke klassen;
- op de structuur is het noodzakelijk om verschillende bewerkingen uit te voeren die de structuur bemoeilijken;
- nieuwe bewerkingen op de structuur worden vaak toegevoegd.
bemiddelaar
Mediator is een gedragsontwerppatroon waarmee meerdere objecten kunnen interageren, terwijl de losse koppeling behouden blijft en de noodzaak wordt vermeden dat objecten expliciet naar elkaar verwijzen.
Met het Mediator-patroon kunt u de interactie van veel objecten garanderen, terwijl u een losse koppeling vormt en de noodzaak voor objecten om expliciet naar elkaar te verwijzen, wordt geëlimineerd.
De bemiddelaar definieert een interface voor het uitwisselen van informatie met objectenCollega's, Een bepaalde bemiddelaar coördineert de acties van objectenCollega's.
Elke Collega- klas kent zijn objectBemiddelaar, wisselen alle collega's alleen informatie uit met een tussenpersoon, bij zijn afwezigheid zouden ze rechtstreeks informatie moeten uitwisselen.
Collega'sstuur verzoeken naar de Reseller/span> en ontvang verzoeken van hem. De bemiddelaar implementeert coöperatief gedrag door elk verzoek door te sturen naar een of meerCollega's.
GO TO FULL VERSION