2.1 Adapter
Adapter (Adapter) är ett strukturellt designmönster utformat för att organisera användningen av funktionerna hos ett objekt som inte är tillgängligt för modifiering genom ett speciellt skapat gränssnitt.
Den officiella definitionen är lite knepig, men om du beskriver den med dina egna ord är en adapter ett designmönster som gör att objekt med inkompatibla gränssnitt kan arbeta tillsammans .
Används för att organisera användningen av funktionerna för ett objekt som inte är tillgängligt för modifiering genom ett speciellt skapat gränssnitt. En extra klass skapas som har det gränssnitt som krävs, och denna klass anropar i sin tur metoderna för det önskade objektet (som inte har det gränssnitt som krävs).
Viktig! Om du i koden möter suffixet Adapter för en klass, har du all rätt att anse att denna klass fungerar som en adapter och är associerad med en grupp klasser som fungerar enligt schemat som beskrivs ovan.
Det används i de fall där systemet stöder nödvändiga data och beteenden, men har ett olämpligt gränssnitt. Den vanligaste användningen av adaptermönstret är när du vill skapa en klass som ärver från en ny eller befintlig abstrakt klass.
Styrkor:
- Övergången till att använda andra externa klasser kräver inte omarbetning av själva systemet, det räcker med att implementera ytterligare en Adapter-klass.
- Oberoende från implementering av externa klasser (klasser från bibliotek vars kod vi inte kan ändra). Ditt program blir oberoende av gränssnittet för externa klasser.
2.2 Dekoratörer
Decorator är ett strukturellt designmönster för att dynamiskt fästa ytterligare beteende till ett objekt. Decorator-mönstret ger ett bra och flexibelt alternativ till övningen med underklassning för att utöka funktionaliteten.
Används för att dynamiskt koppla ytterligare skyldigheter till ett objekt.
Många av er kommer att fråga: hur kan du dynamiskt (medan programmet körs) lägga till nytt beteende till ett objekt? Ett föremål kan sättas ihop av bitar, det vill säga små föremål. Kommer du ihåg filterkedjor i servlets? Eller Stream API när du skrev en fråga med filter(), map(), list()?
IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);Decoratormönstrets styrkor:
- Det finns inget behov av att skapa underklasser för att utöka funktionaliteten för ett objekt.
- Möjligheten att dynamiskt ansluta ny funktionalitet var som helst: före eller efter huvudfunktionaliteten för ConcreteComponent-objektet.
2.3 Fullmakt
Proxy är ett strukturellt designmönster som ger ett objekt som kontrollerar åtkomst till ett annat objekt, avlyssnar och passerar alla dess anrop.
Proxymönstret tillhandahåller ett ersättningsobjekt i stället för det verkliga objektet. Detta objekt styr åtkomsten till det ursprungliga objektet. Används väldigt ofta.
Kommer du ihåg hur vi använde Mockito-ramverket och avlyssnade ett anrop till ett riktigt objekt med metoden Mockito.spy() eller @Spy-kommentaren? Det var då som ett speciellt proxyobjekt skapades, genom vilket alla anrop till det ursprungliga objektet gick.
Och sedan kunde vi hantera dessa anrop genom att lägga till regler i objektet. Det stämmer - det ursprungliga objektet förändras inte, och arbetet med det blir mycket mer flexibelt. Det är särskilt användbart när vi inte anropar proxyobjektet från vår kod, utan skickar det någonstans. Alltså kontrollera kommunikationen av två objekt oberoende av oss.
Typer av fullmakter efter syfte:
- Loggningsproxy : loggar alla anrop till "Ämnet" med deras parametrar.
- Fjärrproxy (fjärrproxy): ger kommunikation med "Ämnet", som finns i ett annat adressutrymme eller på en fjärrdator. Den kan också vara ansvarig för att koda förfrågan och dess argument och skicka den kodade förfrågan till det riktiga "Ämnet".
- Virtuell proxy (virtuella proxyservrar): säkerställer att det verkliga "Ämnet" skapas endast när det verkligen behövs. Den kan också cache en del av informationen om det verkliga "Ämnet" för att fördröja skapandet.
- Copy-on-write : Ger en kopia av "ämnet" när klienten utför vissa åtgärder (ett specialfall av "virtuell proxy").
- Skyddsproxies : Kan kontrollera om den som ringer har nödvändiga behörigheter för att göra begäran.
- Cachingproxy : Ger tillfällig lagring av beräkningsresultat innan de skickas till flera klienter som kan dela resultaten.
- Screening Proxy: Skyddar "Ämnet" från farliga klienter (eller vice versa).
- Synkroniseringsproxy : utför synkroniserad åtkomstkontroll till "Ämnet" i en asynkron flertrådsmiljö.
- "Smart" länk (smart referens proxy): utför ytterligare åtgärder när en länk till "Ämnet" skapas, till exempel beräknar antalet aktiva länkar till "Ämnet".
2.4 Bro
Bridge-mönstret är ett strukturellt designmönster som används för att "separera abstraktion och implementering så att de kan förändras oberoende av varandra."
Bromönstret använder inkapsling, aggregering och kan använda arv för att dela ansvar mellan klasser.
När abstraktion och implementering separeras kan de förändras oberoende av varandra. Med andra ord, när det implementeras genom bryggmönstret, stör ändring av gränssnittets struktur inte ändring av implementeringens struktur.
Betrakta en sådan abstraktion som en figur. Det finns många typer av former, alla med sina egna egenskaper och metoder. Det finns dock något som förenar alla figurer. Till exempel måste varje form kunna rita sig själv, skala och så vidare.
Samtidigt kan ritningsgrafik skilja sig beroende på typen av operativsystem eller grafikbibliotek. Former ska kunna rita sig själva i olika grafiska miljöer. Men det är opraktiskt att implementera alla ritmetoder i varje form, eller att modifiera formen varje gång ritmetoden ändras.
I det här fallet hjälper bromönstret, så att du kan skapa nya klasser som kommer att implementera ritning i olika grafiska miljöer. Med detta tillvägagångssätt är det mycket enkelt att lägga till både nya former och sätt att rita dem.
Kopplingen som representeras av pilen i diagrammen kan ha två betydelser: a) "en sort", i enlighet med Liskov-substitutionsprincipen, och b) en av de möjliga implementeringarna av abstraktionen. Språk använder vanligtvis arv för att implementera både a) och b), vilket tenderar att blåsa upp klasshierarkier.
Bron tjänar exakt till att lösa detta problem: objekt skapas i par från ett objekt av en klass av hierarki A och hierarki B, arv inom hierarkin A har betydelsen av "variation" enligt Liskov, och för begreppet "implementering" of abstraction” används en länk från objekt A till dess parade objekt B.
2.5 Fasad
Fasadmönstret är ett strukturellt designmönster som döljer komplexiteten i ett system genom att reducera alla möjliga externa anrop till ett enda objekt som delegerar dem till lämpliga objekt i systemet.
Hur tillhandahåller man ett enhetligt gränssnitt med en uppsättning olika implementeringar eller gränssnitt, till exempel till ett delsystem, om stark koppling till det delsystemet inte är önskvärt, eller om implementeringen av delsystemet kan förändras?
Definiera en interaktionspunkt med delsystemet - ett fasadobjekt som ger ett gemensamt gränssnitt med delsystemet, och tilldela det ansvaret för att interagera med dess komponenter. En fasad är ett externt objekt som tillhandahåller en enda ingångspunkt för delsystemtjänster.
Implementeringen av andra delsystemkomponenter är privat och inte synlig för externa komponenter. Fasadobjekt ger en implementering av GRASP-mönstret Resistent mot förändringar vad gäller skydd mot förändringar i implementeringen av delsystemet.
Viktig! Detta mönster används när vi helt vill dölja någon grupp av objekt och skicka all kommunikation med dem genom vårt objekt. Om du bara vill ge viss kontroll över kommunikationsprocessen för objekt och inte nödvändigtvis dölja dem, är det bättre att använda proxymönstret.