Denne artikel henvender sig til alle, der for første gang støder på konceptet designmønstre, har hørt udtrykket singleton eller på en eller anden måde implementeret singleton-mønsteret, men ikke forstod, hvad der skete. Velkommen! CodeGym-studerende møder designmønstre for første gang på niveau 15, da kaptajnen uventet beder dem om at "forstærke" deres forståelse ved at implementere Java Singleton-mønsteret med doven implementering. Studerende, der hører om singleton- mønsteret for første gang, har med det samme en masse spørgsmål: hvad i alverden er et designmønster? Hvorfor har vi brug for det? Hvad er en singleton ? Og endelig, hvad er doven implementering? Lad os besvare disse spørgsmål i rækkefølge.
Og singleton- mønsteret er kun en af dem.
med blackjack og talog bruge meget tid på at gøre det, eller du kan implementere en, der har været forstået og beskrevet i lang tid. Det samme er tilfældet med designmønstre. Derudover bliver kode med designmønstre mere standard, og når du bruger det passende mønster, er du mindre tilbøjelig til at lave fejl, da mønstrets almindelige faldgruber blev identificeret og elimineret for længe siden. Ud over alt andet hjælper viden om mønstre programmører til at forstå hinanden bedre. Du kan blot sige navnet på et mønster i stedet for at prøve at give en lang forklaring til dine andre programmører. Sammenfattende hjælper designmønstre dig:
For at afslutte dette afsnit bemærker vi, at hele kroppen af designmønstre kan opdeles i tre store grupper:
Hvad i alverden er et designmønster?
Jeg tror, at lidt historie er for at besvare dette spørgsmål med den bedste forståelse. Der er fire berømte programmeringsforfattere (Erich Gamma, John Vlissides, Ralph Johnson og Richard Helm), som kom med en interessant idé. De bemærkede, at softwareudvikling ofte krævede, at de løser nogenlunde de samme problemer og skrev kode struktureret på samme måde. Så de besluttede at beskrive typiske mønstre, der ofte skal bruges i objektorienteret programmering. Deres bog blev udgivet i 1994 under titlen Design Patterns: Elements of Reusable Object-Oriented Software. Bogens navn viste sig at være for langt, og folk begyndte simpelthen at kalde den for bogen af Firebanden. Den første udgave indeholdt 23 mønstre. Bagefter blev snesevis af andre mønstre opdaget.Et designmønster er en standardiseret løsning på et almindeligt problem. |
Hvorfor har vi brug for designmønstre?
Du kan programmere uden at kende mønstre: på niveau 15 har du allerede skrevet hundredvis af miniprogrammer på CodeGym uden overhovedet at vide, at de eksisterer. Dette tyder på, at designmønstre er en slags værktøj, hvis brug adskiller mesteren fra amatøren: Designmønstre beskriver, hvordan man korrekt løser et typisk problem. Det betyder, at du sparer tid ved at kende mønstre. På den måde ligner de algoritmer. Du kan for eksempel lave din egen sorteringsalgoritme
|

Endelig singleton-mønsteret
Singleton er et kreativt mønster . Dette mønster sikrer, at der kun er én forekomst af en klasse og giver et globalt adgangspunkt til dette objekt. Fra beskrivelsen bør det være klart, at dette mønster skal anvendes i to tilfælde:- når dit program kræver, at der ikke skal oprettes mere end ét objekt af en bestemt klasse. For eksempel kan et computerspil have en Hero-klasse og kun ét Hero-objekt, der beskriver den eneste helt i spillet.
- når du skal angive et punkt for global adgang til et objekt. Med andre ord skal du gøre objektet tilgængeligt hvor som helst i programmet. Ak, det er ikke nok blot at oprette en global variabel, da den ikke er skrivebeskyttet: alle kan ændre variablens værdi, så objektets globale adgangspunkt kan gå tabt. Disse egenskaber for en Singleton er nødvendige, for eksempel når du har et objekt, der fungerer med en database, og du skal have adgang til databasen fra forskellige dele af programmet. En Singleton vil sikre, at ingen skriver kode, der erstatter den tidligere oprettede instans.
-
Find et eksempel på Singleton med doven initialisering.
-
Opret tre singleton-klasser - Sol, Måne, Jord - i separate filer ved at bruge samme princip.
-
ImplementerePlanetgrænseflade i sol- , måne- og jordklasser .
- I statisk blok af Solution -klassen kalder dureadKeyFromConsoleAndInitPlanetmetode.
-
ImplementerreadKeyFromConsoleAndInitPlanetmetode funktionalitet:
-
5.1. Læs en strengparameter fra konsollen
-
5.2. Hvis parameteren er lig med en afPlanetgrænsefladens konstanter, skab passende Planet- objektet.
-
-
Du skal give klassen et privat statisk felt, der gemmer et enkelt objekt:
public class LazyInitializedSingleton { private static LazyInitializedSingleton instance; // #1 }
-
Gør (standard)konstruktøren privat. Det betyder, at den ikke kan tilgås uden for klassen og ikke vil være i stand til at returnere nye objekter:
public class LazyInitializedSingleton { private static LazyInitializedSingleton instance; private LazyInitializedSingleton(){} // #2 }
-
Erklærer en statisk oprettelsesmetode, der vil blive brugt til at få singletonen:
public class LazyInitializedSingleton { private static LazyInitializedSingleton instance; private LazyInitializedSingleton() {} public static LazyInitializedSingleton getInstance() { // #3 if (instance == null) { // If the object has not yet been created instance = new LazyInitializedSingleton(); // Create a new object } return instance; // Return the previously created object } }
GO TO FULL VERSION