Generative mønstre, del 2

4.1 Byggherre

Builder er et generativt designmønster som gir en måte å lage et sammensatt objekt på.

Skiller konstruksjonen av et komplekst objekt fra dets representasjon slik at samme konstruksjonsprosess kan resultere i forskjellige representasjoner.

Styrker:

• lar deg endre den interne representasjonen av produktet;
• isolerer koden som implementerer konstruksjon og presentasjon;
• gir bedre kontroll over designprosessen.

Svake sider:

• Algoritmen for å lage et komplekst objekt bør ikke avhenge av hvilke deler objektet består av og hvordan de passer sammen;
• byggeprosessen må gi ulike representasjoner av objektet som konstrueres.

Et godt eksempel er HttpRequest-klassen, som har en underklasse HttpRequest.Builder som kan brukes til å lage forekomster av HttpRequest-klassen og sikre at de er gyldige.

4.2 Lazy initialisering

Lazy initialisering er en programmeringsteknikk når en ressurskrevende operasjon (objektskaping, verdiberegning) utføres rett før resultatet brukes.

Dermed utføres initialisering "på forespørsel", og ikke på forhånd. En lignende idé finner anvendelse på en rekke områder: for eksempel, on-the-fly kompilering og Just-in-Time logistikkkonseptet.

Et spesielt tilfelle av lat initialisering - å lage et objekt på tidspunktet for tilgang til det - er et av de generative designmønstrene. Den brukes vanligvis i forbindelse med mønstre som Factory Method, Loner og Proxy.

Styrker:

• Initialisering utføres kun når det virkelig er nødvendig;
• Den første initialiseringen av applikasjonen akselereres: alt som kan utsettes blir utsatt.

Svake sider:

• Det er ikke mulig å eksplisitt angi rekkefølgen som objekter initialiseres i;
• Det er en forsinkelse ved første tilgang til objektet, som kan være kritisk når en annen ressurskrevende operasjon utføres parallelt. På grunn av dette er det nødvendig å nøye vurdere hensiktsmessigheten av å bruke lat initialisering i flertrådede programvaresystemer.

Husker du hvordan du kunne spesifisere startrekkefølgen til servlets der når du skrev web.xml? Dette er akkurat resultatet av lat lasting. Tomcat vil lage servlet-objekter første gang de åpnes.

4.3 Objektbasseng

En objektpool er et overordnet designmønster, et sett med initialiserte og klare til bruk objekter. Når systemet trenger et objekt, blir det ikke opprettet, men tatt fra bassenget. Når en gjenstand ikke lenger er nødvendig, blir den ikke ødelagt, men returnert til bassenget.

Objektpooling brukes til å forbedre ytelsen når du oppretter et objekt i starten av en jobb og det er dyrt å ødelegge det på slutten. Ytelsesforbedringen er spesielt merkbar når objekter opprettes og ødelegges ofte, men bare et lite antall av dem eksisterer samtidig.

En objektpool er nyttig når et objekt eier andre ressurser enn minne, for eksempel nettverkskontakter. Eller om samlingen av objekter tar opp en betydelig del av datamaskinens minne og det skapes mye «søppel».

Som du husker, utfører Tomcat hver forespørsel i en separat tråd. Men tråder opprettes ikke hver gang på nytt, men lagres i trådpoolen. Dette tillater raskere utførelse av forespørsler: når en tråd er nødvendig, blir den ganske enkelt tatt fra bassenget. Spørsmålet er forresten: hvordan ville du satt den løpende tråden inn i bassenget og tatt den fra bassenget?