generatieve patronen

3.1 Eentonig

Singleton is een generiek ontwerppatroon dat garandeert dat een single-threaded applicatie een enkele instantie van een bepaalde klasse zal hebben, en biedt een wereldwijd toegangspunt tot deze instantie.

Heel vaak vinden beginnende programmeurs het leuk om utility-methoden samen te voegen in een of andere statische klasse - een klasse die alleen statische methoden bevat. Deze benadering heeft een aantal nadelen - u kunt bijvoorbeeld geen verwijzing naar een object van een dergelijke klasse doorgeven, dergelijke methoden zijn moeilijk te testen en dergelijke.

Als alternatief werd een singleton-klassenoplossing voorgesteld: een klasse die slechts één object kan hebben. Wanneer u probeert dit object te maken, wordt het alleen gemaakt als het nog niet bestaat, anders wordt een verwijzing naar een reeds bestaande instantie geretourneerd.

Het is essentieel dat het mogelijk is om een ​​instantie van de klasse te gebruiken, aangezien in veel gevallen een bredere functionaliteit beschikbaar komt. Deze klasse kan bijvoorbeeld enkele interfaces implementeren en het object kan worden doorgegeven aan andere methoden als implementatie van de interface. Wat niet kan worden gedaan met een reeks statische methoden.

Voordelen:

• Methoden zijn gebonden aan een object, niet aan een statische klasse - u kunt een object doorgeven door middel van referentie.
• Objectmethoden zijn veel gemakkelijker te testen en te bespotten.
• Een object wordt alleen gemaakt als dat nodig is: luie objectinitialisatie.
• De eerste lancering van het programma versnellen als er veel singles zijn die niet nodig zijn voor de lancering.
• Alleen kan verder worden omgezet in een sjabloonstrategie of meerdere van dergelijke objecten.

minpuntjes:

• Het wordt moeilijker om inter-thread races en vertragingen onder controle te houden.
• Het is moeilijk om een ​​\u200b\u200bmulti-threaded "eenling" "vanuit het hoofd" te schrijven: toegang tot een al lang bestaande singleton zou idealiter geen mutex moeten openen. Beter bewezen oplossingen.
• Een conflict tussen twee threads over een onvoltooide enkele thread zal resulteren in een vertraging.
• Als het object lange tijd wordt gemaakt, kan de vertraging de gebruiker hinderen of de real-time verstoren. In dit geval is het beter om de creatie ervan over te brengen naar de fase van programma-initialisatie.
• Voor het testen van eenheden zijn speciale functies vereist, bijvoorbeeld om de bibliotheek in de "niet-eenzame" modus te zetten en tests volledig van elkaar te isoleren.
• Een speciale tactiek voor het testen van het voltooide programma is vereist, omdat zelfs het concept van "de eenvoudigste startbaarheid" verdwijnt, omdat de startbaarheid afhangt van de configuratie.

3.2 Fabriek [Methode]

Een fabrieksmethode is een generiek ontwerppatroon dat subklassen (classes-inheritors) voorziet van een interface voor het maken van instanties van een bepaalde klasse. Tijdens het maken kunnen afstammelingen bepalen welke klasse ze willen maken.

Met andere woorden, deze sjabloon delegeert het maken van objecten aan de afstammelingen van de bovenliggende klasse. Hierdoor kun je geen concrete klassen in de programmacode gebruiken, maar abstracte objecten op een hoger niveau manipuleren.

Dit patroon definieert een interface voor het maken van een object, maar laat het aan subklassen over om te beslissen op welke klasse het object moet worden gebaseerd. Met een fabrieksmethode kan een klasse het maken van subklassen delegeren. Gebruikt wanneer:

• de klasse weet van tevoren niet welke objecten van welke subklassen ze moet maken.
• een klasse is zo ontworpen dat de objecten die deze maakt, worden gespecificeerd door subklassen.
• de klasse delegeert zijn verantwoordelijkheden aan een van de verschillende helper-subklassen, en het is de bedoeling om te bepalen welke klasse deze verantwoordelijkheden overneemt.

3.3 Abstracte Fabriek

Een abstracte fabriek is een generiek ontwerppatroon dat een interface biedt voor het maken van families van gerelateerde of onderling afhankelijke objecten zonder hun concrete klassen te specificeren.

Het patroon wordt geïmplementeerd door een abstracte klasse Factory te maken, wat een interface is voor het maken van systeemcomponenten (voor een vensterinterface kan het bijvoorbeeld vensters en knoppen maken). Vervolgens worden klassen geschreven die deze interface implementeren.

Het wordt gebruikt in gevallen waarin het programma onafhankelijk moet zijn van het proces en de typen nieuwe objecten die zijn gemaakt. Wanneer het nodig is om families of groepen verwante objecten te creëren, met uitsluiting van de mogelijkheid van gelijktijdig gebruik van objecten uit verschillende sets hiervan in dezelfde context.

Sterke punten:

• isoleert specifieke klassen;
• vereenvoudigt de vervanging van productfamilies;
• garandeert productcompatibiliteit.

Laten we zeggen dat uw programma werkt met het bestandssysteem. Om in Linux te werken, hebt u LinuxFile-, LinuxDirectory- en LinuxFileSystem-objecten nodig. En om in Windwos te werken, hebt u de klassen WindowsFile, WindowsDirectory en WindowsFileSystem nodig.

De klasse Path, die wordt gemaakt via Path.of(), is zo'n geval. Path is niet echt een klasse, maar een interface, en het heeft WindowsPath- en LinuxPath-implementaties. En wat voor soort object er wordt gemaakt, is verborgen voor uw code en wordt tijdens runtime bepaald.

3.4 prototype

Prototype is een generatief ontwerppatroon.

Dit patroon definieert de soorten objecten die worden gemaakt met behulp van een prototype-instantie en maakt nieuwe objecten door dit prototype te kopiëren. Het stelt u in staat om weg te komen van de implementatie en het principe van "programmeren via interfaces" te volgen.

Een interface/abstracte klasse bovenaan de hiërarchie wordt gespecificeerd als het terugkerende type, en afstammelingklassen kunnen een erfgenaam vervangen die dit type daar implementeert. Simpel gezegd, dit is het patroon van het maken van een object door een ander object te klonen in plaats van het via een constructor te maken.

Het patroon wordt gebruikt om:

• het vermijden van de extra moeite om een ​​object op een standaardmanier te maken (dat wil zeggen met behulp van een constructor, aangezien in dit geval ook de constructors van de gehele voorouderhiërarchie van het object worden aangeroepen), wanneer dit onbetaalbaar is voor de toepassing.
• vermijd het overnemen van de maker van het object in de clienttoepassing, zoals het abstracte fabriekspatroon doet.

Gebruik dit ontwerppatroon wanneer het uw programma niet uitmaakt hoe het producten maakt, samenstelt en presenteert:

• geïnstantieerde klassen worden tijdens runtime bepaald, bijvoorbeeld met behulp van dynamisch laden;
• u wilt voorkomen dat u klasse- of fabriekshiërarchieën bouwt die parallel lopen met de hiërarchie van productklassen;
• klasse-instanties kunnen verschillende statussen hebben. Het kan handiger zijn om het juiste aantal prototypes in te stellen en ze te klonen, in plaats van de klasse elke keer handmatig in de juiste staat te instantiëren.