Introduktion till skapande designmönster

Introduktion

I programvaruteknik beskriver ett designmönster en etablerad lösning på de vanligaste problemen i programvaran design. Det representerar de bästa metoderna som utvecklats under en lång period genom försök och fel av erfarna programvaruutvecklare.

Designmönster fick popularitet efter att boken Design Patterns: Elements of Reusable Object-Oriented Software publicerades 1994 av Erich Gamma. , John Vlissides, Ralph Johnson och Richard Helm (även känd som Gang of Four eller GoF).

I den här artikeln kommer vi ”att utforska skapande designmönster och deras typer. Vi kommer också att titta på några kodprover och diskutera situationerna när dessa mönster passar vår design.

Creational Design Patterns

Creational Design Patterns handlar om hur objekt skapas . De minskar komplexiteten och instabiliteten genom att skapa objekt på ett kontrollerat sätt.

Den nya operatören anses ofta skadlig eftersom den sprider objekt över hela applikationen. Med tiden kan det bli utmanande att ändra en implementering eftersom klasser blir tätt kopplade.

Skapande designmönster löser problemet genom att koppla bort klienten helt från den faktiska initialiseringsprocessen.

I den här artikeln , vi kommer att diskutera fyra typer av skapande designmönster:

1. Singleton – Säkerställer att högst endast en förekomst av ett objekt finns i hela applikationen
2. Fabriksmetod – Skapar objekt av flera relaterade klasser utan att specificera det exakta objektet som ska skapas
3. Abstract Factory – Skapar familjer med relaterade beroende objekt
4. Builder – Konstruerar komplexa objekt med steg-för-steg-metod

Låt oss nu diskutera vart och ett av dessa mönster i detalj.

Singleton designmönster

Singleton designmönster syftar till att hålla en kontroll av initialisering av objekt av en viss klass genom att se till att endast en förekomst av objektet finns i Java Virtual Machine.

En Singleton-klass tillhandahåller också en unik global åtkomstpunkt till objektet så att varje efterföljande samtal till åtkomstpunkten endast returnerar det specifika objektet.

3.1. Exempel på Singleton-mönster

Även om Singleton-mönstret introducerades av GoF, är den ursprungliga implementeringen känd för att vara problematisk i flertrådade scenarier.

Så här, vi ” kommer att följa ett mer optimalt tillvägagångssätt som använder en statisk inre klass:

Här har vi skapat en statisk inre klass som håller förekomsten av Singleton-klassen. Det skapar bara förekomsten när någon anropar getInstance () -metoden och inte när den yttre klassen laddas.

Detta är ett allmänt använt tillvägagångssätt för en Singleton-klass eftersom den inte kräver synkronisering, är trådsäker , tvingar till lat initiering och har relativt sett mindre pannplatta.

Observera också att konstruktören har den privata åtkomstmodifieraren. Detta är ett krav för att skapa en Singleton eftersom en offentlig konstruktör skulle innebära att någon kunde komma åt den och börja skapa nya instanser.

Kom ihåg att detta inte är den ursprungliga GoF-implementeringen. För den ursprungliga versionen, besök den här länkad Baeldung-artikel om singletons i Java.

3.2. När ska man använda Singleton-designmönster

• För resurser som är dyra att skapa (som databas anslutningsobjekt)
• Det är god praxis att hålla alla loggare som singletons vilket ökar prestanda
• Klasser som ger tillgång till konfigurationsinställningar för applikationen
• Klasser som innehålla resurser som nås i delat läge

Designmönster för fabriksmetod

Fabriksmönster eller fabriksmetodsmönster är en av mest använda designmönster i Java.

Enligt GoF definierar detta mönster ett gränssnitt för att skapa ett objekt, men låt underklasser bestämma vilken klass som ska installeras tiate. Fabriksmetoden låter en klass skjuta upp instans till underklasser ”.

Detta mönster delegerar ansvaret för att initiera en klass från klienten till en viss fabriksklass genom att skapa en typ av virtuell konstruktör.

För att uppnå detta förlitar vi oss på en fabrik som förser oss med objekten och döljer de faktiska implementeringsuppgifterna. De skapade objekten nås med ett gemensamt gränssnitt.

4.1. Fabriksmetodsexempelmönster

I det här exemplet skapar vi ett Polygon-gränssnitt som kommer att implementeras av flera konkreta klasser. En PolygonFactory kommer att användas för att hämta objekt från denna familj :

Låt oss först skapa Polygon-gränssnittet:

Nästa, vi skapar några implementeringar som Square, Triangle, etc. som implementerar detta gränssnitt och returnerar ett objekt av polygontyp.

Nu kan vi skapa en fabrik som tar antalet sidor som argument och returnerar lämplig implementering av detta gränssnitt:

Lägg märke till hur klienten kan lita på att fabriken ger oss en lämplig polygon utan att behöva initialisera objektet direkt.

4.2. När ska man använda fabriksmetodens designmönster

• När implementeringen av ett gränssnitt eller en abstrakt klass förväntas förändras ofta
• När den aktuella implementeringen kan inte bekvämt tillgodose ny förändring
• När initieringsprocessen är relativt enkel och konstruktören kräver bara en handfull parametrar

Abstrakt fabriksmönster

I föregående avsnitt såg vi hur Factory Method-designmönstret kunde användas för att skapa objekt relaterade till en enda familj.

Däremot används abstrakt Factory Design Pattern för att skapa familjer med relaterade eller beroende objekt. Det kallas ibland också fabriker av fabriker.

För en detaljerad förklaring, kolla in vår abstrakta fabrikshandledning.

Designmönster för byggare

Builder-designmönstret är ett annat skapande mönster som är utformat för att hantera konstruktionen av jämförelsevis komplexa objekt.

När komplexiteten i att skapa objekt ökar kan Builder-mönstret separera omedelbar process genom att använda en annan objekt (en byggare) för att konstruera objektet.

Denna byggare kan sedan användas för att skapa många andra liknande representationer med ett enkelt steg-för-steg-tillvägagångssätt.

6.1 Byggmönster Exempel

Det ursprungliga Builder Design-mönstret som introducerades av GoF fokuserar på abstraktion och är mycket bra när det gäller komplexa objekt, men designen är lite komplicerad.

Joshua Bloch introducerade i sin bok Effektiv Java en förbättrad version av byggmönstret som är rent, mycket läsbart (eftersom det använder sig av flytande design) och lätt att använda ur kundens perspektiv. I det här exemplet diskuterar vi den versionen.

Detta exempel har bara en klass, BankAccount som innehåller en byggare som en statisk inre klass:

Observera att alla åtkomstmodifierare på fälten förklaras privata eftersom vi inte vill att yttre objekt ska få åtkomst till dem direkt.

Konstruktören är också privat så att endast den byggare som tilldelats detta klass kan komma åt den. Alla egenskaper som ställts in i konstruktorn extraheras från byggarobjektet som vi tillhandahåller som argument.

Vi har definierat BankAccountBuilder i en statisk inre klass:

Observera att vi har förklarat samma uppsättning fält som den yttre klassen innehåller. Alla obligatoriska fält krävs som argument till den inre klassens konstruktör medan de återstående valfria fälten kan specificeras med hjälp av settermetoderna.

Denna implementering stöder också den flytande designmetoden genom att låta settermetoderna returnera byggaren objekt.

Slutligen anropar byggmetoden den yttre klassens privata konstruktör och skickar sig själv som argumentet. Det returnerade BankAccount kommer att instantieras med de parametrar som anges av BankAccountBuilder.

Låt oss se ett snabbt exempel på byggmönstret i aktion:

6.2. När ska man använda byggmönster

1. När processen involverad i att skapa ett objekt är extremt komplex, med många obligatoriska och valfria parametrar
2. När en ökning av antalet konstruktörsparametrar leder till en stor lista med konstruktörer
3. När klienten förväntar sig olika representationer för objektet som konstrueras

Slutsats

I den här artikeln lärde vi oss om skapande designmönster i Java. Vi diskuterade också deras fyra olika typer, dvs. Singleton, Factory Method, Abstract Factory och Builder Pattern, deras fördelar, exempel och när ska vi använder dem.

Som alltid finns de fullständiga kodavsnitten tillgängliga på GitHub.