Ontwerppatronen - Een korte handleiding voor het Singleton-patroon.

Dit is weer een beknopte handleiding voor het beheersen van een veelgebruikt ontwerppatroon, het Singleton-patroon. Singleton-patroon is een van de eenvoudigste maar meest controversiële ontwerppatronen (met voor- en nadelen). Dit is een van de belangrijkste redenen waarom het heel gebruikelijk is bij het programmeren van interviews.

Singleton-patroon is geclassificeerd in de creatieve ontwerppatronen die allemaal over klasse / object-instantiatie gaan. Meer precies, hoe overerving (klassecreatiepatronen) of delegatie (objectcreatiepatronen) effectief te gebruiken. [door Design Patterns eenvoudig uitgelegd]

Singleton-definitie: in de wiskunde wordt gedefinieerd als "een set die precies één element bevat". Dit patroon is zeer eenvoudig te begrijpen en eenvoudig te implementeren, omdat het slechts een paar regels code zijn en de toepassing vrij eenvoudig is. Het is een patroon dat ervoor zorgt dat een klasse slechts één instantie heeft en er een wereldwijd toegangspunt voor biedt. We kunnen bijvoorbeeld slechts één actieve paus van Italië hebben, daarom is het mogelijk dat de paus kan worden weergegeven met een Singleton-patroon.

Stap 1 - Zoekwoorden

Het definiëren van trefwoorden is het geheime recept in deze serie beknopte handleidingen. Deze methode heeft me geholpen de ontwerppatronen echt te begrijpen, ze hard te coderen en de verschillen tussen andere ontwerppatronen te begrijpen.

Deze keer nemen de trefwoorden ons een reis terug naar de basis. Het is een inleiding tot de zeer eenvoudige code die volgt. Ga gerust naar de volgende stap als u zich vertrouwd voelt met de voorwaarden.

  1. Klasse-instantie: een instantie is een concreet voorkomen van een object. Het bestaat meestal tijdens de looptijd van een computerprogramma en het benadrukt het object duidelijk te identificeren. Op dezelfde manier worden klasse-instanties gemaakt van klassen door subroutines zoals constructors / destructors.
  2. Particuliere constructor: een private constructor is een constructor van een speciale instantie. Het wordt meestal gebruikt in klassen die alleen statische leden bevatten. Als een klasse een of meer privéconstructors heeft en geen openbare constructors, mogen andere klassen (behalve geneste klassen) geen instanties van deze klasse maken.
  3. Statische gegevensleden: wanneer we een lid van een klasse statisch verklaren, betekent dit dat het niet uitmaakt hoeveel objecten van de klasse zijn gemaakt, er is slechts één exemplaar van het statische lid. [van TutorialPoint]
  4. Statische functie: een statische lidfunctie kan worden opgeroepen, zelfs als er geen objecten van de klasse bestaan. [van TutorialPoint]

Stap 2 - Diagram

Er zijn een-twee programmeertrucs om een ​​klasse Singleton te maken. Anders dan dat is het vrij triviaal. Het diagram van boven naar beneden lezen: dat zou moeten

  • Een statische (onderstreepte) en privé (-) instantie van de klasse
  • Een particuliere aannemer.
  • Een openbare (+) en statische functie die de instantie retourneert.

De klassendefinitie mag niet meer zijn dan 7–8 regels code, afhankelijk van de programmeertaal.

Stap 3 - Codeer als voorbeeld

Ik stel voor om de code klasse per klasse te kopiëren vanuit mijn git-repository “Andreas Poyias” of uit de fragmenten hier en deze in een van de beschikbare online C ++ editors zoals c ++ shell, jdoodle, onlineGDB te plakken en uit te voeren om de uitvoer te observeren. Lees dan de opmerkingen of beschrijving hieronder.

Klasse definitie
Ik toon de klassedefinitie in C ++ die uit 8 regels code bestaat.

# include 
klasse Singleton
{
openbaar:
    statische Singleton * getInstance ();
privaat:
    Singleton () {}
    statische Singleton * s_instance;
};

Nu gaan we verder met de verklaring van de methode getInstance () en het statische gegevenslid dat buiten de klassedefinitie valt. Er zijn verschillende manieren om de functie getInstance te schrijven. Voor de eenvoud heb ik gekozen voor degene die in het onderstaande fragment wordt getoond. Dus als de instantie niet bestaat, maak er een instantie van als deze wel bestaat en stuur hem dan terug.

Singleton * Singleton :: s_instance = 0;
Singleton * Singleton :: getInstance ()
{
    if (! s_instance) {
        s_instance = nieuw Singleton ();
        std :: cout << "Er is geen exemplaar dus hebben we er een gemaakt. \ n";
        terugkeer s_instance;
    }anders{
        std :: cout << "Hé, dit is hetzelfde exemplaar! \ n";
      terugkeer s_instance;
    }
}

Hoofdfunctie
De hoofdfunctie werkt als de client. De client kan geen tweede exemplaar van theSingletonclass maken en moet het bestaande exemplaar gebruiken. Dit kan ook worden weergegeven door de uitvoer.

int main ()
{
 Singleton * singlA = Singleton :: getInstance ();
 Singleton * singlB = Singleton :: getInstance ();
 terugkeer 0;
}
// Uitgang
// Er is geen instantie, dus hebben we er een gemaakt.
// Hé, dit is hetzelfde exemplaar!

Er zijn een paar voordelen voor het gebruik van het Singleton-patroon. Andere ontwerppatronen zoals Abstract Factory, Facade kunnen het Singleton-patroon gebruiken (meestal is slechts één Facade-object vereist). Zoals ik in de eerste alinea al zei, is dit ontwerppatroon nogal controversieel en daarom is een populaire interviewvraag: "wat is er mis met het Singleton-patroon, of waarom wordt het Singleton-patroon als antipatroon beschouwd?"

Anti-patroon
Ik zal de redenen samenvatten waarom singleton als anti-patroon wordt beschouwd. Er is een zeer populaire discussie over StackOverflow die echt goede gerechtigheid biedt die rechtvaardigt waarom men voorzichtig moet zijn met dit ontwerppatroon.

  1. Singleton-patronen schenden het principe van één verantwoordelijkheid: omdat ze hun eigen creatie en levenscyclus beheersen.
  2. Ze worden over het algemeen gebruikt als een globale instantie die kan leiden tot verborgen afhankelijkheden in de code die via interfaces kunnen worden blootgelegd.
  3. Ze veroorzaken inherent dat code nauw wordt gekoppeld.
  4. Het is heel moeilijk om het Singleton-patroon aan te passen in een multithreading-omgeving en het is heel gemakkelijk om tijdens initialisatie in problemen met de raceconditie te vallen.

Kijk voor meer inzicht in waarom dit als anti-patroon wordt beschouwd, op deze site van Michael Safyan.

Omdat we het hierboven hebben vermeld, is de volgende blog een beknopte handleiding voor het ontwerppatroon van de gevel. De gevel is geen creatief patroon zoals Singleton en Abstract Factory, maar is geclassificeerd als een structureel ontwerppatroon. Vergeet niet mijn blogpost leuk te vinden / te klappen en mijn account te volgen. Dit is om mij de voldoening te geven dat ik sommige mede-ontwikkelaars heb geholpen en me aanspoort om te blijven schrijven.

Andere snelgidsen over ontwerppatronen:

  1. Design Patterns - Een korte handleiding voor Abstract Factory.
  2. Design Patterns - Een korte handleiding voor Bridge Pattern.
  3. Design Patterns - Een korte handleiding voor Builder Pattern.
  4. Design Patterns - Een korte handleiding voor Decorator Pattern.
  5. Ontwerppatronen - Een korte handleiding voor gevelpatroon.
  6. Ontwerppatronen - Een korte handleiding voor het waarnemerspatroon.
  7. Design Patterns - Een korte handleiding voor Singleton Pattern.