3.1 Singleton
Singleton er et generisk designmønster, der garanterer, at en enkelt-trådsapplikation vil have en enkelt forekomst af en eller anden klasse, og giver et globalt adgangspunkt til denne forekomst.
Meget ofte kan begyndere programmører gerne samle hjælpemetoder i en eller anden statisk klasse - en klasse, der kun indeholder statiske metoder. Denne tilgang har en række ulemper - for eksempel kan du ikke videregive en reference til et objekt i en sådan klasse, sådanne metoder er svære at teste og lignende.
Som et alternativ blev der foreslået en singleton-klasseløsning: en klasse, der kun kan have ét objekt. Når du forsøger at oprette dette objekt, oprettes det kun, hvis det ikke allerede eksisterer, ellers returneres en reference til en allerede eksisterende instans.
Det er vigtigt, at det er muligt at bruge en instans af klassen, da der i mange tilfælde bliver bredere funktionalitet tilgængelig. For eksempel kan denne klasse implementere nogle grænseflader, og dens objekt kan overføres til andre metoder som en implementering af grænsefladen. Hvad kan ikke gøres med et sæt statiske metoder.
Fordele:
- Metoder er bundet til et objekt, ikke en statisk klasse - du kan sende et objekt ved reference.
- Objektmetoder er meget nemmere at teste og håne.
- Et objekt oprettes kun, når det er nødvendigt: initialisering af doven objekt.
- Fremskynde den indledende lancering af programmet, hvis der er mange singler, der ikke er nødvendige for lanceringen.
- Alene kan yderligere omdannes til en skabelon-strategi eller flere sådanne objekter.
Minusser:
- Det bliver sværere at kontrollere inter-thread-løb og forsinkelser.
- Det er svært at skrive en flertrådet "enspænder" "fra hovedet": Adgang til en langvarig singleton bør ideelt set ikke åbne en mutex. Bedre gennemprøvede løsninger.
- En konflikt mellem to tråde over en ufærdig enkelt tråd vil resultere i en forsinkelse.
- Hvis objektet oprettes i lang tid, kan forsinkelsen forstyrre brugeren eller forstyrre realtid. I dette tilfælde er det bedre at overføre dets oprettelse til fase af programinitialisering.
- Der kræves særlige funktioner til enhedstestning - for eksempel at sætte biblioteket i "ikke-ensom" tilstand og fuldstændigt isolere test fra hinanden.
- En særlig taktik til at teste det færdige program er påkrævet, fordi selv begrebet "den enkleste startbarhed" forsvinder, fordi startbarheden afhænger af konfigurationen.
3.2 Fabriks [metode]
En fabriksmetode er et generisk designmønster, der giver underklasser (klasser-inheritors) en grænseflade til at skabe forekomster af en bestemt klasse. På oprettelsestidspunktet kan efterkommere bestemme, hvilken klasse der skal oprettes.
Med andre ord, denne skabelon delegerer oprettelsen af objekter til efterkommerne af den overordnede klasse. Dette giver dig mulighed for ikke at bruge konkrete klasser i programkoden, men at manipulere abstrakte objekter på et højere niveau.
Dette mønster definerer en grænseflade til at skabe et objekt, men overlader det til underklasser at bestemme, hvilken klasse objektet skal baseres på. En fabriksmetode tillader en klasse at uddelegere oprettelsen af underklasser. Bruges når:
- klassen ved ikke på forhånd, hvilke objekter af hvilke underklasser den skal oprette.
- en klasse er designet således, at de objekter, den opretter, er specificeret af underklasser.
- klassen uddelegerer sit ansvar til en af flere hjælperunderklasser, og det er planlagt at bestemme, hvilken klasse der overtager disse ansvarsområder.
3.3 Abstrakt fabrik
En abstrakt fabrik er et generisk designmønster, der giver en grænseflade til at skabe familier af relaterede eller indbyrdes afhængige objekter uden at specificere deres konkrete klasser.
Mønsteret implementeres ved at skabe en abstrakt klasse Factory, som er en grænseflade til at skabe systemkomponenter (for eksempel, for en vinduesgrænseflade, kan den oprette vinduer og knapper). Derefter skrives klasser, der implementerer denne grænseflade.
Det bruges i tilfælde, hvor programmet skal være uafhængigt af processen og typerne af nye objekter, der oprettes. Når det er nødvendigt at oprette familier eller grupper af relaterede objekter, udelukker muligheden for samtidig brug af objekter fra forskellige sæt af disse i samme kontekst.
Styrker:
- isolerer specifikke klasser;
- forenkler udskiftningen af produktfamilier;
- garanterer produktkompatibilitet.
Lad os sige, at dit program fungerer med filsystemet. Så for at arbejde i Linux skal du bruge LinuxFile, LinuxDirectory, LinuxFileSystem-objekter. Og for at arbejde i Windwos skal du bruge klasserne WindowsFile, WindowsDirectory, WindowsFileSystem.
Path-klassen, som oprettes via Path.of(), er netop sådan et tilfælde. Path er egentlig ikke en klasse, men en grænseflade, og den har WindowsPath og LinuxPath implementeringer. Og hvilken slags objekt, der bliver oprettet, er skjult fra din kode og vil blive besluttet under kørsel.
3.4 Prototype
Prototype er et generativt designmønster.
Dette mønster definerer den slags objekter, der oprettes ved hjælp af en prototypeinstans, og opretter nye objekter ved at kopiere denne prototype. Det giver dig mulighed for at komme væk fra implementeringen og følge princippet om "programmering gennem grænseflader".
En grænseflade/abstrakt klasse øverst i hierarkiet er angivet som den returnerende type, og efterkommerklasser kan erstatte en arving, der implementerer denne type der. Kort sagt er dette mønsteret for at skabe et objekt ved at klone et andet objekt i stedet for at skabe det gennem en konstruktør.
Mønsteret bruges til at:
- undgår den ekstra indsats at skabe et objekt på en standard måde (det betyder at bruge en konstruktør, da konstruktørerne i hele objektets forfaderhierarki også vil blive kaldt), når dette er uoverkommeligt dyrt for applikationen.
- undgå at arve objektskaberen i klientapplikationen, som det abstrakte fabriksmønster gør.
Brug dette designmønster, når dit program er ligeglad med, hvordan det skaber, komponerer og præsenterer produkter:
- instansierede klasser bestemmes ved kørsel, for eksempel ved hjælp af dynamisk belastning;
- du vil undgå at bygge klasse- eller fabrikshierarkier, der er parallelle med produktklassehierarkiet;
- klasseforekomster kan være i en af flere forskellige tilstande. Det kan være mere praktisk at indstille det passende antal prototyper og klone dem i stedet for manuelt at instansiere klassen i den passende tilstand hver gang.