4.1 Bouwer
Builder is een generatief ontwerppatroon dat een manier biedt om een samengesteld object te maken.
Scheidt de constructie van een complex object van zijn representatie zodat hetzelfde constructieproces kan resulteren in verschillende representaties.
Sterke punten:
- stelt u in staat de interne weergave van het product te wijzigen;
- isoleert de code die constructie en presentatie implementeert;
- geeft meer controle over het ontwerpproces.
Zwakke kanten:
- het algoritme voor het maken van een complex object mag niet afhangen van de onderdelen waaruit het object bestaat en hoe ze in elkaar passen;
- het constructieproces moet verschillende representaties bieden van het object dat wordt gebouwd.
Een goed voorbeeld is de klasse HttpRequest, die een subklasse HttpRequest.Builder heeft die kan worden gebruikt om instanties van de klasse HttpRequest te maken en ervoor te zorgen dat ze geldig zijn.
4.2 Luie initialisatie
Luie initialisatie is een programmeertechniek waarbij een resource-intensieve bewerking (objectcreatie, waardeberekening) wordt uitgevoerd onmiddellijk voordat het resultaat wordt gebruikt.
De initialisatie wordt dus "op aanvraag" uitgevoerd en niet van tevoren. Een soortgelijk idee vindt toepassing op verschillende gebieden: bijvoorbeeld on-the-fly compilatie en het Just-in-Time logistiek concept.
Een speciaal geval van luie initialisatie - het creëren van een object op het moment dat het wordt geopend - is een van de generatieve ontwerppatronen. Het wordt meestal gebruikt in combinatie met patronen zoals Factory Method, Loner en Proxy.
Sterke punten:
- Initialisatie wordt alleen uitgevoerd wanneer het echt nodig is;
- De initiële initialisatie van de applicatie wordt versneld: alles wat kan worden uitgesteld, wordt uitgesteld.
Zwakke kanten:
- Het is niet mogelijk om expliciet de volgorde in te stellen waarin objecten worden geïnitialiseerd;
- Er is een vertraging bij de eerste toegang tot het object, wat kritiek kan zijn wanneer parallel een andere resource-intensieve bewerking wordt uitgevoerd. Daarom is het noodzakelijk om de geschiktheid van het gebruik van luie initialisatie in multithreaded softwaresystemen zorgvuldig te overwegen.
Weet je nog hoe je bij het schrijven van web.xml de startvolgorde van servlets daar kon specificeren? Dit is precies het resultaat van lazy loading. Tomcat maakt servlet-objecten de eerste keer dat ze worden geopend.
4.3 Objectpool
Een objectpool is een bovenliggend ontwerppatroon, een set geïnitialiseerde en gebruiksklare objecten. Wanneer het systeem een object nodig heeft, wordt dit niet aangemaakt, maar uit de pool gehaald. Wanneer een object niet meer nodig is, wordt het niet vernietigd maar teruggeplaatst in het zwembad.
Objectpooling wordt gebruikt om de prestaties te verbeteren wanneer het maken van een object aan het begin van een taak en het vernietigen ervan aan het einde duur is. De prestatieverbetering is vooral merkbaar wanneer objecten vaak worden gemaakt en vernietigd, maar er slechts een klein aantal tegelijkertijd bestaat.
Een objectpool is handig wanneer een object andere bronnen dan geheugen bezit, zoals netwerksockets. Of als de verzameling objecten een aanzienlijk deel van het geheugen van de computer in beslag neemt en er veel "rotzooi" ontstaat.
Zoals u zich herinnert, voert Tomcat elk verzoek uit in een afzonderlijke thread. Maar threads worden niet elke keer opnieuw gemaakt, maar worden opgeslagen in de threadpool. Dit maakt een snellere uitvoering van verzoeken mogelijk: wanneer een thread nodig is, wordt deze eenvoudig uit de pool gehaald. De vraag is trouwens: hoe zou je de lopende draad in het zwembad leggen en uit het zwembad halen?