Kreativt designmønster: 1. Singleton-mønster

Hva er et skapelsesdesignmønster?

(26. des. 2020)

Kreasjonelle designmønstre omhandler opprettelse eller kloning av nye objekter i en klasse. Kloning skjer når en lignende type gjenstand allerede eksisterer, og i stedet for å instantiere et nytt objekt, kloner vi det eksisterende.

De forskjellige måtene å lage objekter vil i stor grad påvirke hvordan et problem blir løst. Forskjellige språk påvirker derfor hvilke mønstre som er mulige å bruke.

Singleton-mønster

Singleton-mønster brukes når vi bare trenger en enkelt forekomst av en klasse. For eksempel å lage DB-tilkobling i et program, skrive ut kø til skriveren, ved hjelp av loggere da de krever mye ressurser. I alle disse tilfellene, hvis det er flere forekomster, vil det skape forvirring så vel som inkonsekvens.

Dette mønsteret brukes når forekomsten er delt og tilgjengelig globalt i hele applikasjonen. Å sørge for at tilgang til delte ressurser er trådsikker er et veldig godt eksempel på hvor denne typen mønster kan være viktig. hensikten med et Singleton-mønster er å gi global tilgang til en klasse som er begrenset til en forekomst.

La oss se hvordan objektet blir opprettet

public class DummyClass{ DummyClass(){}
}DummyClass dc = new DummyClass(); //every time when this line is called a new object of DummyClass is created

Nå, når et objekt av DummyClass er nødvendig, kalles det konstruktøren og det opprettes et objekt. Dette kalles Eager initialization.

Men i singleton-mønster krever vi bare en forekomst av en klasse. Si, hvis en DB-tilkobling allerede er konfigurert, trenger vi ikke opprette en ny DB-forbindelse, og vi bør bruke den allerede eksisterende tilkoblingen. La oss se hvordan vi kan oppnå det.

Her har vi begrenset omfanget av konstruktøren til selve klassen. Så, for å lage objektet til denne klassen, må getDBConnection () statiske metoden for klassen kalles. Den vil da sjekke om dbConnection-objektet er null, og deretter opprette et nytt tilkoblingsobjekt og returnere ellers returnere det eksisterende tilkoblingsobjektet.

Dette eksemplet viser begrepet lat initialisering . Det betyr at vi ikke skaper klassens objekt med mindre det virkelig er nødvendig. Derfor er dette programmet mer effektivt når det gjelder ressurser.

Det er avveininger med Singleton-designprinsippet. Hvis det er flere datatråder som kjører, kan det være problemer forårsaket av at tråder prøver å få tilgang til det delte enkeltobjektet.

Problemer i implementeringen ovenfor

Nå er det mulig at to tråder kaller samtidig getDBConnection-metoden, og objektet er ikke opprettet ennå. For begge trådene vil dbConnection-objektet være null, og de prøver begge å opprette en ny forekomst og bruke den i stedet. Det er derfor veldig viktig å sørge for at en enkelt tråd kan få tilgang til getDBConnection om gangen, slik at flere forekomster ikke opprettes.

For å oppnå en tråd -safe singleton-klassen er å gjøre den globale tilgangsmetoden synkronisert, slik at bare en tråd kan utføre denne metoden om gangen.

Bare en tråd har tilgang til denne synkroniserte kodeblokken om gangen

Du tenker kanskje at problemet er løst nå. Men dessverre nei! For å håndheve singleton-egenskapen setter vi en lås på den statiske getDBConnection-metoden, men samtidig kompromitterer ytelsen. Når et objekt allerede er opprettet, må også flere tråder vente på å få den eksisterende forekomsten av det objektet. Kan vi gjøre noe bedre? La oss se.

Som det er tydelig at, er låsing bare nødvendig når forekomsten er null slik at forskjellige tråder ikke lager flere forekomster. Så vi kan sette en synkronisert tilstand i if-tilstanden der vi sjekker om forekomsten er null eller ikke, og legger til en dobbel sjekk for å eliminere scenariene for flere forekomster.

I reell bruk kan singleton-mønsteret implementeres på forskjellige måter. Den definerer bare det grunnleggende formålet dette mønsteret tjener, men implementeringen av koden kan variere.

Det er alt fra min side. Jeg håper det er klart nå, hvor, når og hvordan du bruker singleton-designmønsteret. Du kan referere til boken Gang of Four’s design pattern catalog for more understanding.

Gi meg beskjed i kommentarene nedenfor, hvis du er i tvil. Hvis du liker denne bloggen, kan du dele den med vennene dine. Happy software engineering!

Del 2: