Deze week bespreek ik een van mijn favoriete patterns: het Adapter pattern. Ik vond de volgende definitie van het woord adapter:

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.

Allereest alle goede wensen voor dit nieuwe jaar! Laten we direct het belangrijkste onderwerp van 2010 bespreken: geld. Dit is wellicht wat kortzichtig en bekrompen echter heeft dit onderwerp menig architect in verlegenheid gebracht. Niet omdat het project duurder uitviel dan verwacht maar meer omdat de rol van geld (bedragen) binnen software architectuur wel eens onderschat wordt. Laten we de waarde van een bedrag maar opslaan in een decimal of floating point veld, we doen er verder toch niet zo veel mee. Fair enough.

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!

Een beetje later dan gepland maar ook deze week laat ik weer een pattern de revue passeren. Deze week het Strategy pattern zoals beschreven bij de Gang of Four omdat het gewoon een heerlijk simpel pattern is.

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?

Welkom bij deze tweede post in de reeks over patterns die wereldwijd toegepast worden bij het ontwerpen van software. Deze week behandel ik het Flyweight pattern zoals vast gelegd door de fameuze Gang of Four.

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.

Lees verder »

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.
Lees verder »