Introduktion til Creational Design Patterns

Introduktion

I softwareteknik beskriver et designmønster en etableret løsning på de mest almindelige problemer i software design. Det repræsenterer den bedste praksis, der er udviklet over en lang periode gennem forsøg og fejl fra erfarne softwareudviklere.

Designmønstre blev populære efter bogen Designmønstre: Elementer af genanvendelig objektorienteret software blev udgivet i 1994 af Erich Gamma. , John Vlissides, Ralph Johnson og Richard Helm (også kendt som Gang of Four eller GoF).

I denne artikel vil vi “undersøge skabelsesmønstre og deres typer. Vi vil også se på nogle kodeeksempler og drøft situationerne, når disse mønstre passer til vores design.

Creational Design Patterns

Creational Design Patterns vedrører den måde, hvorpå objekter oprettes . De reducerer kompleksiteten og ustabiliteten ved at oprette objekter på en kontrolleret måde.

Den nye operatør betragtes ofte som skadelig, da den spreder objekter overalt i applikationen. Over tid kan det blive udfordrende at ændre en implementering, fordi klasser bliver tæt koblede.

Creational Design Patterns løser dette problem ved at afkoble klienten helt fra den faktiske initialiseringsproces.

I denne artikel , vi diskuterer fire typer oprettelsesdesignmønster:

1. Singleton – Sikrer, at der højst kun findes en forekomst af et objekt i hele applikationen
2. Fabriksmetode – Opretter objekter af flere relaterede klasser uden at specificere det nøjagtige objekt, der skal oprettes
3. Abstrakt fabrik – Opretter familier af relaterede afhængige objekter
4. Builder – Konstruerer komplekse objekter ved hjælp af trin-for-trin tilgang

Lad os nu diskutere hvert af disse mønstre detaljeret.

Singleton Design Pattern

Singleton Design Pattern har til formål at holde en kontrol af initialisering af objekter af en bestemt klasse ved at sikre, at der kun findes en forekomst af objektet i hele Java Virtual Machine.

En Singleton-klasse giver også et unikt globalt adgangspunkt til objektet, så hvert efterfølgende opkald til adgangspunktet kun returnerer det bestemte objekt.

3.1. Eksempel på Singleton-mønster

Selvom Singleton-mønsteret blev introduceret af GoF, er den oprindelige implementering kendt for at være problematisk i multitrådede scenarier.

Så her, vi ” vi vil følge en mere optimal tilgang, der gør brug af en statisk indre klasse:

Her har vi oprettet en statisk indre klasse, der har forekomsten af Singleton-klassen. Det opretter kun forekomsten, når nogen kalder getInstance () -metoden, og ikke når den ydre klasse er indlæst.

Dette er en udbredt tilgang til en Singleton-klasse, da den ikke kræver synkronisering, er trådsikker , håndhæver doven initialisering og har relativt mindre kedelplade.

Bemærk også, at konstruktøren har den private adgangsmodifikator. Dette er et krav for at oprette en Singleton, da en offentlig konstruktør ville betyde, at nogen kunne få adgang til den og begynde at oprette nye forekomster.

Husk, dette er ikke den originale GoF-implementering. For den originale version, se denne sammenkædet Baeldung-artikel om Singletons i Java.

3.2. Hvornår skal man bruge Singleton Design-mønster

• For ressourcer, der er dyre at oprette (som database forbindelsesobjekter)
• Det er god praksis at holde alle loggere som singletoner, hvilket øger ydeevnen
• Klasser, der giver adgang til konfigurationsindstillinger for applikationen
• Klasser, der indeholder ressourcer, der er adgang til i delt tilstand

Fabriksmetode designmønster

Fabriksmønsteret eller fabriksmetoden designmønster er en af de mest anvendte designmønstre i Java.

Ifølge GoF definerer dette mønster en grænseflade til oprettelse af et objekt, men lad underklasser bestemme hvilken klasse der skal installeres tiate. Fabriksmetoden lader en klasse udsætte instantiering til underklasser ”.

Dette mønster delegerer ansvaret for at initialisere en klasse fra klienten til en bestemt fabriksklasse ved at oprette en type virtuel konstruktør.

For at opnå dette stoler vi på en fabrik, der giver os objekterne og skjuler de faktiske implementeringsoplysninger. Der er adgang til de oprettede objekter ved hjælp af en fælles grænseflade.

4.1. Fabriksmetode Designmønstereksempel

I dette eksempel opretter vi en Polygon-grænseflade, der vil blive implementeret af flere konkrete klasser. En PolygonFactory vil blive brugt til at hente objekter fra denne familie :

Lad os først oprette Polygon-grænsefladen:

Næste, vi opretter et par implementeringer som Square, Triangle osv., der implementerer denne interface og returnerer et objekt af polygontypen.

Nu kan vi oprette en fabrik, der tager antallet af sider som et argument og returnerer den passende implementering af denne grænseflade:

Bemærk, hvordan klienten kan stole på, at denne fabrik giver os en passende polygon uden at skulle initialisere objektet direkte.

4.2. Hvornår skal man bruge fabriksmetode Designmønster

• Når implementeringen af en grænseflade eller en abstrakt klasse forventes at ændre sig ofte
• Når den aktuelle implementering kan ikke komfortabelt rumme nye ændringer
• Når initialiseringsprocessen er relativt enkel, og konstruktøren kun kræver en håndfuld parametre

Abstrakt fabriksdesignmønster

I det forrige afsnit så vi, hvordan Factory Method-designmønsteret kunne bruges til at skabe objekter relateret til en enkelt familie.

Derimod bruges det abstrakte Factory Design-mønster at skabe familier med relaterede eller afhængige objekter. Det kaldes også undertiden en fabrik af fabrikker.

For en detaljeret forklaring, se vores abstrakte fabriksvejledning.

Builder Design Pattern

Builder Design Pattern er et andet skabelsesmønster designet til at håndtere konstruktionen af forholdsvis komplekse objekter.

Når kompleksiteten ved at skabe objekt øges, kan Builder-mønsteret adskille instantieringsprocessen ved hjælp af en anden objekt (en builder) til at konstruere objektet.

Denne builder kan derefter bruges til at oprette mange andre lignende repræsentationer ved hjælp af en simpel trin-for-trin tilgang.

6.1. Builder Pattern Eksempel

Det originale Builder Design-mønster introduceret af GoF fokuserer på abstraktion og er meget godt, når man beskæftiger sig med komplekse objekter, men designet er lidt kompliceret.

Joshua Bloch introducerede i sin bog Effektiv Java en forbedret version af bygmønsteret, som er rent, meget læsbart (fordi det gør brug af flydende design) og nem at bruge fra kundens perspektiv. I dette eksempel diskuterer vi den version.

Dette eksempel har kun en klasse, BankAccount, som indeholder en builder som en statisk indre klasse:

Bemærk, at alle adgangsmodifikatorer på felterne erklæres private, da vi ikke ønsker, at ydre objekter skal få direkte adgang til dem.

Konstruktøren er også privat, så kun Builder tildeles dette klasse kan få adgang til det. Alle egenskaberne, der er indstillet i konstruktøren, udvindes fra bygherreobjektet, som vi leverer som argument.

Vi har defineret BankAccountBuilder i en statisk indre klasse:

Bemærk, at vi har erklæret det samme sæt felter, som den ydre klasse indeholder. Eventuelle obligatoriske felter kræves som argumenter for den indre klasses konstruktør, mens de resterende valgfrie felter kan specificeres ved hjælp af settermetoderne.

Denne implementering understøtter også den flydende designtilgang ved at lade settermetoderne returnere bygherren objekt.

Endelig kalder buildmetoden den private konstruktor i den ydre klasse og sender sig selv som argumentet. Det returnerede BankAccount vil blive instantificeret med de parametre, der er angivet af BankAccountBuilder.

Lad os se et hurtigt eksempel på bygmønsteret i aktion:

6.2. Hvornår skal man bruge Builder-mønster

1. Når processen involveret i oprettelsen af et objekt er ekstremt kompleks, med mange obligatoriske og valgfri parametre
2. Når en stigning i antallet af konstruktorparametre fører til en stor liste over konstruktører
3. Når klienten forventer forskellige repræsentationer for det objekt, der er konstrueret

Konklusion

I denne artikel lærte vi om kreative designmønstre i Java. Vi diskuterede også deres fire forskellige typer, dvs. Singleton, Factory Method, Abstract Factory og Builder Pattern, deres fordele, eksempler og hvornår skal vi bruger dem.

Som altid er de komplette kodestykker tilgængelige på GitHub.