2.1 Adapter
Adapter (Adapter) is een structureel ontwerppatroon dat is ontworpen om het gebruik van de functies van een object te organiseren dat niet beschikbaar is voor wijziging via een speciaal gemaakte interface.
De officiële definitie is een beetje lastig, maar als je het in je eigen woorden beschrijft, is een adapter een ontwerppatroon waarmee objecten met incompatibele interfaces kunnen samenwerken .
Wordt gebruikt om het gebruik van de functies van een object te organiseren dat niet beschikbaar is voor wijziging via een speciaal gemaakte interface. Er wordt een extra klasse gemaakt die de vereiste interface heeft, en deze klasse roept op zijn beurt de methoden van het gewenste object aan (dat niet de vereiste interface heeft).
Belangrijk! Als je in de code het achtervoegsel Adapter voor een klasse tegenkomt, dan heb je het volste recht om te beschouwen dat deze klasse als een adapter fungeert en geassocieerd is met een groep klassen die werken volgens het hierboven beschreven schema.
Het wordt gebruikt in gevallen waarin het systeem de vereiste gegevens en het vereiste gedrag ondersteunt, maar een ongepaste interface heeft. Het adapterpatroon wordt het meest gebruikt wanneer u een klasse wilt maken die overerft van een nieuwe of bestaande abstracte klasse.
Sterke punten:
- De overgang naar het gebruik van andere externe klassen vereist geen herbewerking van het systeem zelf, het volstaat om nog een Adapter-klasse te implementeren.
- Onafhankelijkheid van de implementatie van externe klassen (klassen uit bibliotheken waarvan we de code niet kunnen wijzigen). Uw programma wordt onafhankelijk van de interface van externe klassen.
2.2 Decorateurs
Decorator is een structureel ontwerppatroon voor het dynamisch koppelen van extra gedrag aan een object. Het Decorator-patroon biedt een goed en flexibel alternatief voor de praktijk van subklassen om functionaliteit uit te breiden.
Wordt gebruikt om aanvullende verplichtingen dynamisch aan een object te koppelen.
Velen van jullie zullen vragen: hoe kun je dynamisch (terwijl het programma draait) nieuw gedrag aan een object toevoegen? Een object kan worden samengesteld uit stukjes, dat wil zeggen kleine objecten. Herinner je je filterketens in servlets nog? Of de Stream API toen u een query schreef met behulp van filter(), map(), list()?
IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);Sterke punten van het Decorator-patroon:
- Het is niet nodig om subklassen te maken om de functionaliteit van een object uit te breiden.
- De mogelijkheid om overal dynamisch nieuwe functionaliteit te verbinden: voor of na de hoofdfunctionaliteit van het ConcreteComponent-object.
2.3 Volmachten
Proxy is een structureel ontwerppatroon dat een object biedt dat de toegang tot een ander object regelt, al zijn oproepen onderschept en doorgeeft.
Het Proxy-patroon biedt een vervangend object in plaats van het echte object. Dit object regelt de toegang tot het oorspronkelijke object. Heel vaak gebruikt.
Weet je nog hoe we het Mockito-framework gebruikten en een oproep naar een echt object onderschepten met behulp van de Mockito.spy()-methode of de @Spy-annotatie? Op dat moment werd een speciaal Proxy-object gemaakt, waar alle oproepen naar het oorspronkelijke object doorheen gingen.
En dan kunnen we deze oproepen beheren door regels aan het object toe te voegen. Dat klopt - het oorspronkelijke object verandert niet en het werken ermee wordt veel flexibeler. Het is vooral handig als we het proxy-object niet vanuit onze code aanroepen, maar ergens doorgeven. Zo regelen we de communicatie van twee objecten onafhankelijk van ons.
Soorten proxy's per doel:
- Proxy loggen : registreert alle oproepen naar het "Onderwerp" met hun parameters.
- Externe proxy (externe proxy's): zorgt voor communicatie met het "Onderwerp", dat zich in een andere adresruimte of op een externe machine bevindt. Het kan ook verantwoordelijk zijn voor het coderen van het verzoek en zijn argumenten en het verzenden van het gecodeerde verzoek naar het echte "Onderwerp".
- Virtuele proxy (virtuele proxy's): zorgt ervoor dat het echte "Subject" alleen wordt aangemaakt wanneer het echt nodig is. Het kan ook een deel van de informatie over het echte "Onderwerp" cachen om het maken ervan te vertragen.
- Copy-on-write : Biedt een kopie van het "subject" wanneer de client bepaalde acties uitvoert (een speciaal geval van de "virtuele proxy").
- Beschermingsproxy's : kunnen controleren of de beller de benodigde machtigingen heeft om het verzoek in te dienen.
- Caching Proxy : Biedt tijdelijke opslag van berekeningsresultaten voordat ze worden aangeboden aan meerdere klanten die de resultaten kunnen delen.
- Screening Proxy: Beschermt de "Subject" tegen gevaarlijke clients (of vice versa).
- Synchronisatie Proxy : voert gesynchroniseerde toegangscontrole uit tot het "Onderwerp" in een asynchrone omgeving met meerdere threads.
- "Slimme" link (slimme referentieproxy): voert aanvullende acties uit wanneer een link naar het "Subject" wordt gemaakt, berekent bijvoorbeeld het aantal actieve links naar het "Subject".
2.4 Brug
Het Bridge-patroon is een structureel ontwerppatroon dat wordt gebruikt om "abstractie en implementatie te scheiden, zodat ze onafhankelijk van elkaar kunnen veranderen".
Het brugpatroon gebruikt inkapseling, aggregatie en kan overerving gebruiken om de verantwoordelijkheid tussen klassen te delen.
Wanneer abstractie en uitvoering gescheiden zijn, kunnen ze onafhankelijk van elkaar veranderen. Met andere woorden, wanneer geïmplementeerd via het bridge-patroon, heeft het wijzigen van de structuur van de interface geen invloed op het wijzigen van de structuur van de implementatie.
Beschouw zo'n abstractie als een figuur. Er zijn veel soorten vormen, elk met zijn eigen eigenschappen en methoden. Er is echter iets dat alle figuren verenigt. Elke vorm moet bijvoorbeeld zichzelf kunnen tekenen, schalen, enzovoort.
Tegelijkertijd kunnen tekenafbeeldingen verschillen, afhankelijk van het type besturingssysteem of grafische bibliotheek. Vormen moeten zichzelf kunnen tekenen in verschillende grafische omgevingen. Maar het is onpraktisch om alle tekenmethoden in elke vorm te implementeren, of om de vorm telkens aan te passen wanneer de tekenmethode verandert.
In dit geval helpt het bridge-patroon, waardoor u nieuwe klassen kunt maken die tekenen in verschillende grafische omgevingen implementeren. Met deze aanpak is het heel eenvoudig om zowel nieuwe vormen als manieren om ze te tekenen toe te voegen.
De verbinding weergegeven door de pijl in de diagrammen kan 2 betekenissen hebben: a) "a kind", in overeenstemming met het Liskov-substitutieprincipe, en b) een van de mogelijke implementaties van de abstractie. Talen gebruiken doorgaans overerving om zowel a) als b) te implementeren, wat de neiging heeft om klassenhiërarchieën op te zwellen.
De brug dient precies om dit probleem op te lossen: objecten worden in paren gemaakt van een object van een klasse van hiërarchie A en hiërarchie B, overerving binnen de hiërarchie A heeft de betekenis van "variëteit" volgens Liskov, en voor het concept van "implementatie van abstractie" wordt een link van object A naar zijn gepaarde object B gebruikt.
2.5 Gevel
Het gevelpatroon is een structureel ontwerppatroon dat de complexiteit van een systeem verbergt door alle mogelijke externe oproepen terug te brengen tot een enkel object dat ze delegeert naar de juiste objecten in het systeem.
Hoe kan een uniforme interface worden geboden met een reeks ongelijksoortige implementaties of interfaces, bijvoorbeeld voor een subsysteem, als sterke koppeling met dat subsysteem ongewenst is, of als de implementatie van het subsysteem zou kunnen veranderen?
Definieer één punt van interactie met het subsysteem - een gevelobject dat een gemeenschappelijke interface biedt met het subsysteem, en wijs het de verantwoordelijkheid toe voor interactie met zijn componenten. Een façade is een extern object dat een enkel toegangspunt biedt voor subsysteemservices.
De implementatie van andere subsysteemcomponenten is privé en niet zichtbaar voor externe componenten. Gevelobject biedt een implementatie van het GRASP-patroon Bestand tegen veranderingen in termen van bescherming tegen veranderingen in de implementatie van het subsysteem.
Belangrijk! Dit patroon wordt gebruikt wanneer we een groep objecten volledig willen verbergen en alle communicatie met hen via ons object willen doorgeven. Als u alleen enige controle wilt geven over het communicatieproces van objecten en ze niet noodzakelijkerwijs wilt verbergen, dan is het beter om het Proxy-patroon te gebruiken.