Designmønstre - En hurtig guide til Singleton-mønster.

Dette er en anden hurtig guide til at mestre et meget almindeligt anvendt designmønster, Singleton-mønsteret. Singleton-mønster er et af de enkleste, men mest kontroversielle designmønstre (med fordele og mange ulemper). Dette er en af ​​hovedårsagerne til, at det er meget almindeligt i programmeringssamtaler.

Singleton-mønster klassificeres i de kreative designmønstre, som handler om klassificering af objekt / objekt. Mere præcist, hvordan man effektivt bruger arv (klasseskabelsesmønstre) eller delegering (objektoprettelsesmønstre). [af designmønstre forklaret ganske enkelt]

Singleton-definition: I matematik defineres det som "et sæt, der indeholder nøjagtigt et element". Dette mønster er meget enkelt at forstå og let at implementere, da det kun er et par kodelinjer, og applikationen er ret ligetil. Det er et mønster, der sikrer, at en klasse kun har én forekomst og giver et globalt adgangspunkt til det. For eksempel kan vi kun have en aktiv pave fra Italien, derfor er det muligt, at paven kan repræsenteres med et Singleton-mønster.

Trin 1 - Nøgleord

Definition af nøgleord er den hemmelige opskrift i denne serie af hurtigguider. Denne metode hjalp mig virkelig med at forstå designmønstre, hardkode dem i mit sind og forstå forskellene mellem andre designmønstre.

Denne gang tager nøgleordene os en tur tilbage til det grundlæggende. Det er en introduktion til den meget enkle kode, der følger. Du er velkommen til at springe til næste trin, hvis du føler dig godt tilpas med betingelserne.

  1. Klasseinstans: Et eksempel er en konkret forekomst af ethvert objekt. Det eksisterer normalt i løbet af et computerprograms driftstid, og det lægger vægt på at identificere objektet tydeligt. Tilsvarende oprettes klasseforekomster fra klasser af subroutiner som konstruktører / destruktører.
  2. Privat konstruktør: En privat konstruktør er en speciel instans konstruktør. Det bruges generelt i klasser, der kun indeholder statiske medlemmer. Hvis en klasse har en eller flere private konstruktører og ingen offentlige konstruktører, har andre klasser (undtagen indlejrede klasser) ikke tilladelse til at oprette forekomster af denne klasse.
  3. Statiske datamedlemmer: Når vi erklærer et klassemedlem som statisk, betyder det, uanset hvor mange objekter i klassen der er oprettet, der kun er en kopi af det statiske medlem. [fra TutorialPoint]
  4. Statisk funktion: En statisk medlemsfunktion kan kaldes, selvom der ikke findes nogen objekter i klassen. [fra TutorialPoint]

Trin 2 - Diagram

Der er en-to programmeringstricks til at lave en klasse Singleton. Bortset fra at det er ret trivielt. Læs diagrammet fra top til bund: Vi skulle have det

  • Et statisk (understreget) og privat (-) eksempel på klassen
  • En privat konstruktør.
  • En offentlig (+) og statisk funktion, der returnerer forekomsten.

Klassedefinitionen må ikke være mere end 7–8 kodelinjer, afhængigt af programmeringssproget.

Trin 3 - Kode ved eksempel

Jeg foreslår at kopiere kodeklassen efter klasse fra mit git-arkiv "Andreas Poyias" eller fra uddragene her og indsætte det i en af ​​de tilgængelige online C ++ -redaktører som c ++ shell, jdoodle, onlineGDB og køre det for at se output. Læs derefter kommentarer eller beskrivelse nedenfor.

Klasse definition
Jeg viser klassedefinitionen i C ++, som er 8 kodelinjer.

# inkluder 
klasse Singleton
{
offentlig:
    statisk Singleton * getInstance ();
privat:
    Singleton () {}
    statisk Singleton * s_instance;
};

Nu går vi videre til erklæringen af ​​getInstance () -metoden og det statiske data medlem, der ligger uden for klassedefinitionen. Der er forskellige måder at skrive getInstance-funktionen på. For nemheds skyld valgte jeg den, der er vist i uddraget nedenfor. Så hvis forekomsten ikke findes, skal du instantiere en, hvis den findes, så returner den bare.

Singleton * Singleton :: s_instance = 0;
Singleton * Singleton :: getInstance ()
{
    hvis (! s_instance) {
        s_instance = new Singleton ();
        std :: cout << "Der er ingen tilfælde, så vi oprettede en. \ n";
        tilbage s_instance;
    }andet{
        std :: cout << "Hej, dette er den samme instans! \ n";
      tilbage s_instance;
    }
}

Hovedfunktion
Hovedfunktionen fungerer som klient. Klienten kan ikke oprette en anden forekomst af singletonklassen og tvinges til at bruge den eksisterende. Dette kan også vises af output.

int main ()
{
 Singleton * singlA = Singleton :: getInstance ();
 Singleton * singlB = Singleton :: getInstance ();
 retur 0;
}
// Output
// Der er ingen tilfælde, så vi oprettede en.
// Hej, dette er den samme instans!

Der er et par fordele ved brugen af ​​Singleton-mønster. Andre designmønstre som Abstract Factory, Facade kan bruge Singleton-mønster (normalt kræves kun et Facade-objekt). Som jeg nævnte i det første afsnit er dette designmønster temmelig kontroversielt, og det er grunden til et populært interviewspørgsmål: "hvad er der galt med Singleton-mønster, eller hvorfor betragtes Singleton-mønster som antimønster?"

Anti-mønster
Jeg vil opsummere årsagerne til, at singleton betragtes som anti-mønster. Der er en meget populær diskussion om StackOverflow, som giver virkelig god retfærdighed, der begrunder, hvorfor man skal være forsigtig med dette designmønster.

  1. Singleton-mønstre krænker princippet om enkeltansvar: i kraft af det faktum, at de kontrollerer deres egen skabelse og livscyklus.
  2. De bruges generelt som et globalt eksempel, der kan føre til skjulte afhængigheder i koden, der kunne blive eksponeret via grænseflader.
  3. De får i sagens natur koden til at være tæt koblet.
  4. Det er meget vanskeligt at justere Singleton-mønsteret i et multithreading-miljø og meget let at falde i racerproblemer under initialisering.

For en dybere forståelse af, hvorfor dette betragtes som antimønster, se på dette sted af Michael Safyan.

Da vi nævnte det ovenfor, vil den næste blog være en hurtig guide til facade-designmønsteret. Facaden er ikke et kreativt mønster som Singleton og Abstract Factory, men er klassificeret som et strukturelt designmønster. Glem ikke at lide / klappe mit blog-indlæg og følge min konto. Dette er for at give mig den tilfredshed, at jeg hjalp nogle medudviklere og presser mig til at fortsætte med at skrive.

Andre hurtigguider om designmønstre:

  1. Designmønstre - En hurtig guide til Abstract Factory.
  2. Designmønstre - En hurtig guide til Bridge Pattern.
  3. Designmønstre - En hurtig guide til Builder Pattern.
  4. Designmønstre - En hurtig guide til Decoratormønster.
  5. Designmønstre - En hurtig guide til Fasademønster.
  6. Designmønstre - En hurtig guide til observatørmønster.
  7. Designmønstre - En hurtig guide til Singleton-mønster.