Creatief ontwerppatroon: 1. Singletonpatroon

Wat is een creatief ontwerppatroon?

(26 dec.2020)

Creatief ontwerppatroon gaat over het maken of klonen van nieuwe objecten van een klasse. Klonen vindt plaats als er al een soortgelijk object bestaat en in plaats van een nieuw object te instantiëren, klonen we het bestaande.

De verschillende manieren om objecten te maken zullen een grote invloed hebben op hoe een probleem wordt opgelost. Verschillende talen hebben daarom invloed op welke patronen kunnen worden gebruikt.

Singleton-patroon

Singleton-patroon wordt gebruikt wanneer we slechts één instantie van een klasse nodig hebben. Bijvoorbeeld DB-verbinding maken in een applicatie, afdrukwachtrij van de printer, loggers gebruiken omdat ze veel bronnen nodig hebben. In al deze gevallen, als er meerdere instanties zijn, zal dit zowel verwarring als inconsistentie veroorzaken.

Dit patroon wordt gebruikt wanneer de instantie wordt gedeeld en wereldwijd toegankelijk is binnen de applicatie. Ervoor zorgen dat toegang tot gedeelde bronnen thread-safe is, is een heel goed voorbeeld van waar dit soort patroon van vitaal belang kan zijn. De bedoeling van een Singleton-patroon is om globale toegang te bieden tot een klasse die beperkt is tot één instantie.

Laten we eens kijken hoe het object wordt gemaakt

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

Wanneer een object van DummyClass nodig is, wordt de constructor ervan aangeroepen en wordt er een object gemaakt. Dit wordt Eager-initialisatie genoemd.

Maar in singleton-patroon hebben we slechts één instantie van een klasse nodig. Stel dat als er al een DB-verbinding is ingesteld, we geen nieuwe DB-verbinding hoeven te maken en de reeds bestaande verbinding moeten gebruiken. Laten we eens kijken hoe we dit kunnen bereiken.

Hier hebben we het bereik van de constructor beperkt tot de klasse zelf. Om het object van deze klasse te maken, moet de statische methode getDBConnection () van de klasse worden aangeroepen. Vervolgens wordt gecontroleerd of het object dbConnection null is, maakt vervolgens een nieuw verbindingsobject en retourneert anders het bestaande verbindingsobject.

Dit voorbeeld demonstreert het concept van luie initialisatie . Dat betekent dat we het object van de klasse niet creëren, tenzij het echt nodig is. Daarom is dit programma efficiënter in termen van middelen.

Er zijn compromissen met het Singleton-ontwerpprincipe. Als er meerdere computer-threads actief zijn, kunnen er problemen zijn die worden veroorzaakt doordat de threads proberen toegang te krijgen tot het gedeelde enkele object.

Problemen in de bovenstaande implementatie

Nu is het mogelijk dat er twee threads roepen tegelijkertijd de methode getDBConnection aan en het object is nog niet gemaakt. Voor beide threads is het object dbConnection null en ze zullen allebei proberen een nieuwe instantie te maken en die in plaats daarvan gebruiken. Het is daarom erg belangrijk om ervoor te zorgen dat een enkele thread tegelijkertijd toegang heeft tot de getDBConnection, zodat er niet meerdere instanties worden gemaakt.

Om een ​​ thread te krijgen -safe singleton class is om de globale toegangsmethode gesynchroniseerd te maken, zodat slechts één thread deze methode tegelijk kan uitvoeren.

Slechts één thread heeft tegelijk toegang tot dit gesynchroniseerde codeblok

U denkt misschien dat het probleem nu is opgelost. Maar helaas niet! Om de singleton-eigenschap af te dwingen, hebben we de statische getDBConnection-methode vergrendeld, maar tegelijkertijd de prestaties ervan in gevaar gebracht. Als er al een object is gemaakt, moeten ook meerdere threads wachten om de bestaande instantie van dat object op te halen. Kunnen we iets beters doen? Laten we eens kijken.

Zoals duidelijk is, is vergrendeling alleen vereist als de instantie null is, zodat verschillende threads niet meerdere instanties maken. We kunnen dus een gesynchroniseerde voorwaarde binnen de if-voorwaarde plaatsen, waarbij we controleren of de instantie null is of niet, en een dubbele controle toevoegen om de scenarios van meerdere instanties te elimineren.

In echt gebruik kan het singleton-patroon op verschillende manieren worden geïmplementeerd. Het definieert alleen het basisdoel van dit patroon, maar de implementatie van de code kan verschillen.

Dat is allemaal van mijn kant. Ik hoop dat het nu duidelijk is, waar, wanneer en hoe het singleton-ontwerppatroon moet worden gebruikt. U kunt het boek, de catalogus met ontwerppatronen van Gang of Four, raadplegen voor meer begrip.

Laat het me weten in de opmerkingen hieronder, als u twijfelt. Als je deze blog leuk vindt, deel hem dan met je vrienden. Veel plezier met software-engineering!

Deel 2: