Introduksjon til Creational Design Patterns

Introduksjon

I programvareteknikk beskriver et Designmønster en etablert løsning på de mest vanlige problemene i programvare design. Det representerer den beste fremgangsmåten som har utviklet seg over en lang periode gjennom prøving og feiling av erfarne programvareutviklere.

Designmønstre fikk popularitet etter at boka Design Patterns: Elements of Reusable Object-Oriented Software ble utgitt i 1994 av Erich Gamma , John Vlissides, Ralph Johnson og Richard Helm (også kjent som Gang of Four eller GoF).

I denne artikkelen vil vi «utforske skapende designmønstre og deres typer. Vi vil også se på noen kodeeksempler og diskutere situasjonene når disse mønstrene passer til vårt design.

Creational Design Patterns

Creational Design Patterns er opptatt av måten objekter blir opprettet på . De reduserer kompleksiteten og ustabiliteten ved å lage objekter på en kontrollert måte.

Den nye operatøren anses ofte som skadelig da den sprer objekter over hele applikasjonen. Over tid kan det bli utfordrende å endre en implementering fordi klassene blir tett koblet.

Creational Design Patterns adresserer dette problemet ved å koble klienten helt fra den faktiske initialiseringsprosessen.

I denne artikkelen , vi vil diskutere fire typer Creational Design Pattern:

1. Singleton – Sikrer at det maksimalt bare finnes en forekomst av et objekt gjennom hele applikasjonen
2. Factory Method – Oppretter objekter av flere relaterte klasser uten å spesifisere det eksakte objektet som skal opprettes
3. Abstrakt fabrikk – Oppretter familier av relaterte avhengige objekter
4. Builder – Konstruerer komplekse objekter ved hjelp av trinnvis tilnærming

La oss nå diskutere hvert av disse mønstrene i detalj.

Singleton Design Pattern

Singleton Design Pattern har som mål å holde en sjekk ved initialisering av objekter av en bestemt klasse ved å sikre at bare en forekomst av objektet eksisterer gjennom Java Virtual Machine.

En Singleton-klasse gir også ett unikt globalt tilgangspunkt til objektet slik at hvert påfølgende anrop til tilgangspunktet bare returnerer det bestemte objektet.

3.1. Singleton-mønstereksempel

Selv om Singleton-mønsteret ble introdusert av GoF, er den opprinnelige implementeringen kjent for å være problematisk i flertrådede scenarier.

Så her, vi » kommer til å følge en mer optimal tilnærming som bruker en statisk indre klasse:

Her har vi opprettet en statisk indre klasse som har forekomsten av Singleton-klassen. Det oppretter forekomsten bare når noen kaller getInstance () -metoden og ikke når den ytre klassen er lastet.

Dette er en mye brukt tilnærming for en Singleton-klasse, da den ikke krever synkronisering, er trådsikker , håndhever lat initialisering og har relativt mindre kokeplate.

Vær også oppmerksom på at konstruktøren har den private tilgangsmodifikatoren. Dette er et krav for å lage en Singleton, siden en offentlig konstruktør vil bety at noen kan få tilgang til den og begynne å opprette nye forekomster.

Husk at dette ikke er den opprinnelige GoF-implementeringen. For den originale versjonen, besøk denne koblet Baeldung-artikkel om Singletons i Java.

3.2. Når skal du bruke Singleton Design Pattern

• For ressurser som er dyre å lage (som database tilkoblingsobjekter)
• Det er god praksis å holde alle loggere som singletons som øker ytelsen
• Klasser som gir tilgang til konfigurasjonsinnstillinger for applikasjonen
• Klasser som inneholder ressurser som er tilgjengelige i delt modus

Fabrikkmetodedesignmønster

Fabrikkdesignmønsteret eller fabrikkmetodedesignmønsteret er en av mest brukte designmønstre i Java.

I følge GoF definerer dette mønsteret et grensesnitt for å lage et objekt, men la underklasser bestemme hvilken klasse som skal installeres tiate. Factory-metoden lar en klasse utsette instantiering til underklasser ”.

Dette mønsteret delegerer ansvaret for å initialisere en klasse fra klienten til en bestemt fabrikkklasse ved å lage en type virtuell konstruktør.

For å oppnå dette stoler vi på en fabrikk som gir oss objektene, og skjuler de faktiske implementeringsdetaljene. Du får tilgang til de opprettet objektene ved hjelp av et felles grensesnitt.

4.1. Fabrikkmetode Designmønstereksempel

I dette eksemplet lager vi et Polygon-grensesnitt som vil bli implementert av flere konkrete klasser. En PolygonFactory vil bli brukt til å hente gjenstander fra denne familien :

La oss først opprette Polygon-grensesnittet:

Neste, Vi lager noen implementeringer som Square, Triangle osv. som implementerer dette grensesnittet og returnerer et objekt av polygontypen.

Nå kan vi opprette en fabrikk som tar antall sider som argument og returnerer riktig implementering av dette grensesnittet:

Legg merke til hvordan klienten kan stole på at denne fabrikken gir oss en passende polygon uten å måtte initialisere objektet direkte.

4.2. Når skal du bruke fabrikkmetodedesignmønster

• Når implementeringen av et grensesnitt eller en abstrakt klasse forventes å endres ofte
• Når den nåværende implementeringen kan ikke komfortabelt imøtekomme nye endringer
• Når initialiseringsprosessen er relativt enkel, og konstruktøren bare krever en håndfull parametere

Abstrakt fabrikkdesignmønster

I forrige avsnitt så vi hvordan Factory Method-designmønsteret kunne brukes til å lage objekter relatert til en enkelt familie.

Derimot brukes det abstrakte Factory Design-mønsteret for å skape familier med relaterte eller avhengige gjenstander. Det kalles også noen ganger fabrikker av fabrikker.

For en detaljert forklaring, sjekk ut vår abstrakte fabrikkveiledning.

Builder Design Pattern

Builder Design Pattern er et annet skapelsesmønster designet for å håndtere konstruksjonen av relativt komplekse objekter.

Når kompleksiteten i å lage objekt øker, kan Builder-mønsteret skille ut instantiseringsprosessen ved å bruke en annen objekt (en byggmester) for å konstruere objektet.

Denne byggmesteren kan deretter brukes til å lage mange andre lignende representasjoner ved hjelp av en enkel trinnvis tilnærming.

6.1. Byggmønster Eksempel

Det originale Builder Design Pattern introdusert av GoF fokuserer på abstraksjon og er veldig bra når du arbeider med komplekse objekter, men designet er imidlertid litt komplisert.

Joshua Bloch introduserte i sin bok Effektiv Java en forbedret versjon av byggemønsteret som er rent, svært lesbart (fordi det bruker flytende design) og enkel å bruke fra kundens perspektiv. I dette eksemplet vil vi diskutere den versjonen.

Dette eksemplet har bare en klasse, BankAccount, som inneholder en byggmester som en statisk indre klasse:

Merk at alle tilgangsmodifikatorene på feltene blir erklært private siden vi ikke vil at ytre objekter skal få tilgang til dem direkte.

Konstruktøren er også privat, slik at bare byggmesteren tilordnet dette klassen kan få tilgang til den. Alle egenskapene som er satt i konstruktøren er hentet fra byggeobjektet som vi leverer som et argument.

Vi har definert BankAccountBuilder i en statisk indre klasse:

Legg merke til at vi har erklært det samme settet med felt som den ytre klassen inneholder. Eventuelle obligatoriske felt kreves som argumenter for den indre klassens konstruktør, mens de gjenværende valgfrie feltene kan spesifiseres ved hjelp av settermetodene.

Denne implementeringen støtter også den flytende designtilnærmingen ved å få settermetodene til å returnere byggmesteren objekt.

Til slutt kaller byggemetoden den private konstruktøren til den ytre klassen og sender seg selv som argumentet. Det returnerte BankAccount vil bli instansert med parametrene satt av BankAccountBuilder.

La oss se et raskt eksempel på byggemønsteret i aksjon:

6.2. Når skal man bruke byggemønster

1. Når prosessen som er involvert i å lage et objekt er ekstremt kompleks, med mange obligatoriske og valgfrie parametere
2. Når en økning i antall konstruktorparametre fører til en stor liste over konstruktører
3. Når klienten forventer forskjellige representasjoner for objektet som er konstruert

Konklusjon

I denne artikkelen lærte vi om skapelsesdesignmønstre i Java. Vi diskuterte også de fire forskjellige typene, dvs. Singleton, Factory Method, Abstract Factory og Builder Pattern, fordelene, eksemplene og når skal vi bruker dem.

Som alltid er de komplette kodebitene tilgjengelige på GitHub.