2.1 Adapter
Adapter (Adapter) er et strukturelt designmønster designet til at organisere brugen af funktionerne i et objekt, som ikke er tilgængeligt for ændring gennem en specielt oprettet grænseflade.
Den officielle definition er lidt tricky, men hvis du beskriver den med dine egne ord, er en adapter et designmønster, der tillader objekter med inkompatible grænseflader at arbejde sammen .
Bruges til at organisere brugen af funktionerne i et objekt, der ikke er tilgængeligt for ændring via en specielt oprettet grænseflade. Der oprettes en ekstra klasse, som har den påkrævede grænseflade, og denne klasse kalder igen metoderne for det ønskede objekt (som ikke har den nødvendige grænseflade).
Vigtig! Hvis du i koden møder suffikset Adapter for en klasse, så har du fuld ret til at overveje, at denne klasse fungerer som en adapter og er tilknyttet en gruppe klasser, der fungerer efter skemaet beskrevet ovenfor.
Det bruges i tilfælde, hvor systemet understøtter de nødvendige data og adfærd, men har en uhensigtsmæssig grænseflade. Den mest almindelige brug af Adapter-mønsteret er, når du vil oprette en klasse, der arver fra en ny eller eksisterende abstrakt klasse.
Styrker:
- Overgangen til at bruge andre eksterne klasser kræver ikke omarbejdelse af selve systemet, det er nok at implementere en Adapter-klasse mere.
- Uafhængighed af implementering af eksterne klasser (klasser fra biblioteker, hvis kode vi ikke kan ændre). Dit program bliver uafhængigt af eksterne klassers grænseflade.
2.2 Dekoratører
Decorator er et strukturelt designmønster til dynamisk at knytte yderligere adfærd til et objekt. Decorator-mønsteret giver et godt og fleksibelt alternativ til praksis med underklassificering for at udvide funktionaliteten.
Bruges til dynamisk at forbinde yderligere forpligtelser til et objekt.
Mange af jer vil spørge: hvordan kan du dynamisk (mens programmet kører) tilføje ny adfærd til et objekt? En genstand kan samles af stykker, det vil sige små genstande. Husker du filterkæder i servlets? Eller Stream API'en, da du skrev en forespørgsel ved hjælp af filter(), map(), list()?
IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);Decorator-mønsterets styrker:
- Der er ingen grund til at oprette underklasser for at udvide funktionaliteten af et objekt.
- Evnen til dynamisk at forbinde ny funktionalitet hvor som helst: før eller efter hovedfunktionaliteten af ConcreteComponent-objektet.
2.3 Fuldmagter
Proxy er et strukturelt designmønster, der giver et objekt, der styrer adgangen til et andet objekt, opsnapper og passerer alle dets opkald.
Proxy-mønsteret giver et erstatningsobjekt i stedet for det rigtige objekt. Dette objekt styrer adgangen til det originale objekt. Brugt meget ofte.
Kan du huske, hvordan vi brugte Mockito-rammen og opsnappede et kald til et rigtigt objekt ved hjælp af Mockito.spy()-metoden eller @Spy-annotationen? Det var dengang, der blev oprettet et specielt proxy-objekt, som alle kald til det originale objekt gik igennem.
Og så kunne vi administrere disse opkald ved at tilføje regler til objektet. Det er rigtigt - det originale objekt ændres ikke, og arbejdet med det bliver meget mere fleksibelt. Det er især nyttigt, når vi ikke kalder proxy-objektet fra vores kode, men sender det et sted. Styrer således kommunikationen af to objekter uafhængigt af os.
Typer af fuldmagter efter formål:
- Logging proxy : logger alle opkald til "Emnet" med deres parametre.
- Fjernproxy (fjernproxies): giver kommunikation med "Emnet", som er i et andet adresserum eller på en ekstern maskine. Den kan også være ansvarlig for at kode anmodningen og dens argumenter og sende den kodede anmodning til det rigtige "emne".
- Virtuel proxy (virtuelle proxyer): sikrer, at det rigtige "emne" kun oprettes, når det virkelig er nødvendigt. Det kan også cache nogle af oplysningerne om det rigtige "emne" for at forsinke dets oprettelse.
- Copy-on-write : Giver en kopi af "emnet", når klienten udfører visse handlinger (et særligt tilfælde af den "virtuelle proxy").
- Beskyttelsesproxyer : Kan kontrollere, om den, der ringer, har de nødvendige tilladelser til at fremsætte anmodningen.
- Caching-proxy : Giver midlertidig lagring af beregningsresultater, før de vises til flere klienter, som kan dele resultaterne.
- Screening Proxy: Beskytter "Emnet" mod farlige klienter (eller omvendt).
- Synkroniseringsproxy : udfører synkroniseret adgangskontrol til "Emnet" i et asynkront flertrådsmiljø.
- "Smart" link (smart reference proxy): udfører yderligere handlinger, når der oprettes et link til "Emnet", beregner for eksempel antallet af aktive links til "Emnet".
2.4 Bro
Bridge-mønsteret er et strukturelt designmønster, der bruges til at "adskille abstraktion og implementering, så de kan ændre sig uafhængigt."
Bromønsteret bruger indkapsling, aggregering og kan bruge arv til at dele ansvar mellem klasser.
Når abstraktion og implementering er adskilt, kan de ændre sig uafhængigt. Med andre ord, når det implementeres gennem bromønsteret, vil ændring af strukturen af grænsefladen ikke forstyrre ændring af strukturen af implementeringen.
Betragt en sådan abstraktion som en figur. Der er mange former for former, hver med sine egne egenskaber og metoder. Der er dog noget, der forener alle figurerne. For eksempel skal hver form kunne tegne sig selv, målestok og så videre.
Samtidig kan tegningsgrafik variere afhængigt af typen af OS eller grafikbibliotek. Former skal kunne tegne sig selv i forskellige grafiske miljøer. Men det er upraktisk at implementere alle tegnemetoderne i hver figur, eller at ændre formen, hver gang tegnemetoden ændres.
I dette tilfælde hjælper bromønsteret, så du kan oprette nye klasser, der implementerer tegning i forskellige grafiske miljøer. Ved at bruge denne tilgang er det meget nemt at tilføje både nye former og måder at tegne dem på.
Forbindelsen repræsenteret af pilen i diagrammerne kan have 2 betydninger: a) "en slags", i overensstemmelse med Liskov substitutionsprincippet, og b) en af de mulige implementeringer af abstraktionen. Sprog bruger typisk arv til at implementere både a) og b), som har en tendens til at blæse klassehierarkier op.
Broen tjener præcis til at løse dette problem: objekter skabes i par fra et objekt af en klasse af hierarki A og hierarki B, arv inden for hierarkiet A har betydningen af "variation" ifølge Liskov, og for begrebet "implementering" of abstraction” bruges et link fra objekt A til dets parrede objekt B.
2.5 Facade
Facademønsteret er et strukturelt designmønster, der skjuler kompleksiteten af et system ved at reducere alle mulige eksterne kald til et enkelt objekt, der uddelegerer dem til de relevante objekter i systemet.
Hvordan giver man en samlet grænseflade med et sæt forskellige implementeringer eller grænseflader, for eksempel til et undersystem, hvis stærk kobling til det undersystem er uønsket, eller implementeringen af undersystemet kan ændre sig?
Definer ét interaktionspunkt med delsystemet - et facadeobjekt, der giver en fælles grænseflade med delsystemet, og tildel det ansvaret for at interagere med dets komponenter. En facade er et eksternt objekt, der giver et enkelt indgangspunkt for undersystemtjenester.
Implementeringen af andre delsystemkomponenter er privat og ikke synlig for eksterne komponenter. Facadeobjekt giver en implementering af GRASP-mønsteret Modstandsdygtig over for ændringer med hensyn til beskyttelse mod ændringer i implementeringen af delsystemet.
Vigtig! Dette mønster bruges, når vi helt vil skjule en gruppe af objekter og sende al kommunikation med dem gennem vores objekt. Hvis du bare vil give en vis kontrol over objekters kommunikationsproces og ikke nødvendigvis skjule dem, så er det bedre at bruge Proxy-mønsteret.