Aanpassingseenheid tussen twee systemen, meestal waarmee een toestel dat op laagspanning werkt ook op het lichtnet kan worden aangesloten.

Wat mij betreft is dit een prima definitie want het beschrijft exact wat dit patroon is: Aanpassingseenheid tussen twee systemen.

Stel: ik heb interface A en klasse B. B implementeerd niet A en kan dus niet direct door clients van A gebruikt worden. Als dit wel wenselijk is dan kun je dit probleem oplossen met behulp van een Adapter: maak een nieuwe klasse C die interface A implementeerd en klasse B encapsuleerd. Implementeer de methods van interface A en map deze naar de geencapsuleerde instantie van B. Klaar! Je kunt nu op de plaatsen waar je interface A wilt hebben object B ‘adapten’.

Ik gebruik dit pattern in mijn eigen framework bijvoorbeeld om mijn applicatie context geschikt te maken voor gebruik in de Apache Velocity template engine.

Kort en krachtig, net zoals als het Adapter patroon zelf.

Maar dan: de applicatie moet meer gaan rekenen met die bedragen: optellen, percentages en (hopelijk) vermenigvuldigen. Geen probleem: de meeste programmeertalen kunnen deze eenvoudige operaties al uitvoeren op primitives. So far, so good. Echter zijn deze berekeningen nu overal versplinterd in de codebase terug te vinden.

Nu de applicatie zo succesvol is dat er ook andere valuta dan de euro gebruikt gaan worden, gaat het jammerlijk mis: overal moeten bedragen omgerekend worden naar de ene valuta.Vervolgens moet er een bedrag bij opgeteld worden, waarna het resultaat weer terug omgerekend moet worden naar de begin valuta. Dit is natuurlijk vragen om problemen.

Er is echter een oplossing: het Money pattern zoals beschreven door Martin Fowler in zijn boek Patterns of Enterprise Application Architecture. En dit is werkelijk een schitterende oplossing met dank aan zijn eenvoud: maak een Money klasse die verantwoordelijk is voor het beheren van het bedrag, de valuta en het uitvoeren van berekeningen en transformaties van de ene valuta naar het andere. Er is nu een verantwoordelijke voor beheren van de kleintjes: de Money klasse. Heerlijk, ik wou dat mijn persoonlijke financiën ook zo makelijk te beheren waren.

Persoonlijk maak ik altijd gebruik van een Money klasse, ook in de meest eenvoudige applicaties omdat je maar nooit weet of het nodig zal zijn. In dit geval: better safe than sorry. Zijn jullie het hier mee eens? Of heb je een eigen oplossing? Plaats een reactie en deel je mening of ervaring!

Eigenlijk is het Strategy pattern het verbergen van de implementatie achter een interface. De interface definieert een methode en de client maakt alleen gebruik van deze methode. Nu kun je verschillende implementaties maken van deze methode door een klasse te definieren die erft van de interface. De client weet dan niet meer welke implementatie er nu achter de interface zit: de implementaties zijn dus uitwisselbaar geworden. Deze ‘uitwisselbaarheid’ is vooral krachtig in combinatie met dependency injection frameworks.

Ik gebruik het Strategy pattern vooral in het ontwerpen van mijn eigen framework, ik wil bepaalde delen kunnen vervangen zondat dat ik daar code voor hoef aan te passen.

Dat is het voor deze week. Iemand die hier iets aan toe wil voegen?

Het Flyweight pattern komt van pas wanneer je een groot aantal objecten verwacht die hetzelde zijn. Het meest tot de verbeelding sprekende voorbeeld is een tekst editor applicatie. Stel dat  er voor elke individuel teken in deze post een apart object aangemaakt zou moeten. Ik heb het niet geteld maar ik vermoed dat de letter E het vaakst voorkomt. Het zou natuurlijk zonde zijn om over elke letter E geheugen te reserveren omdat ze allemaal hetzelde zijn.

Hoe werkt het Flyweight pattern? Eigenlijk heel erg simpel: implementeer een Factory klasse die verantwoordelijk is voor het instantieren van objecten om deze vervolgens te cachen. Wanneer de client code de Factory om een soortgelijk object vraagd geeft deze het reeds geinstantieerde object terug uit de cache in plaats van een nieuw object te instantieren. De Factory klasse werkt dus als volgt:

Pseudocode
if (flyweightCache[parameters] exists)
   return existing flyweight
else
   new flyweight(parameters)
   add flyweight to cache
   return flyweight

Zoals je ziet fungeert de Factory klasse in dit pattern als cache zonder dat de client code hier van af weet. De Factory klasse kun je zo intelligent maken als nodig is door bijvoorbeeld sommige object die echt vaak opgevraagd worden uit de cache te serveren, terwijl andere object wel elke keer geinstantieerd worden. Ook kan de Factory beoordelen of parameters er op duid dat het object een eigen unieke state heeft en dus niet uit de cache gehaald kan worden.

Wanneer is het Flyweight pattern geschikt? Als:

• De applicatie enorme hoeveelheden object gebruikt
• Het geheugen vol loopt
• De objecten hebben geen unieke state, of de state kan gemakkelijk ondergebracht worden in een ander minder gebruikt object
• De applicatie niet afhangkelijk is van de identiteit van deze objecten

Gerelateerde patterns:

• Value Object – Domain Driven Design
• Factory Pattern – Design Patterns

Dat is het voor deze week. Ik hoop dat je nu begrijpt hoe het Flyweight pattern werkt. Heb je nog vragen of opmerkingen? Plaats gerust een reactie!

Welkom bij deze eerste post in de reeks over patterns die wereldwijd toegepast worden bij het ontwerpen van software. Deze week behandel ik het Value Object pattern zoals gebruikt in Domain Driven Design.

Veel objecten hebben geen conceptuele identiteit, ze beschrijven simpelweg een aspect van iets. Het is niet van belang of je nu instantie A van dit object hebt of instantie B omdat de instanties conceptueel hetzelfde zijn. Laat ik eerst een voorbeeld geven om dit statement toe te lichten.

Voorbeeld
Ik word gevraagd om een applicatie te bouwen waarin een verzekeraar zijn klanten kan beheren. Stel dat er 2 personen zijn: A en B en stel dat deze personen op hetzelfde adres wonen. Dan kun je gerust een brief sturen bestemd voor persoon A naar het adres van persoon B. Ook kun je onmogelijk op basis van het adres een van deze personen identificeren. Het adres is en heeft dus geen identiteit.

De conclusie dat een object geen eigen identiteit heeft kan grote gevolgen hebben voor bijvoorbeeld het database ontwerp waarvoor je kiest: Om ruimte te besparen zou je de adressen in een aparte tabel op kunnen slaan met een 1 op N relatie met de personen tabel. Of het instantieren van dit object, ik denk bijvoorbeeld meteen aan het Flyweight pattern.

Typische voorbeelden van Value Objects:

• Kleuren
• Tekens en tekenreeksen
• Afmetingen & punten
• Posities & locaties
• Stijlen

Bovenstaande items zijn maar enkele voorbeelden en zijn bovendien niet in alle gevallen Value Objects. Stel je voor dat je een programma aan het maken bent voor het mengen van kleuren, dan zal kleur waarschijnlijk geen Value Object zijn.

Dit pattern heeft mij geholpen om objecten goed te kunnen classificeren wat er toe heeft geleid dat mijn ontwerpen eenvoudiger werden. Ook bij het bepalen welke (N)Hibernate mapping ik het beste kon gebruiken is dit een waardevol pattern.

Gerelateerde patterns:

• Flyweight pattern – Design Pattern

Ik ben benieuwd wat jullie ervaringen zijn met het Value Object pattern. Heeft het jou geholpen? Of juist niet? Deel je ervaring door hier een reactie te plaatsen.