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.

Deze week zijn er nieuwe releases vrijgegeven van een aantal componenten van het Castle Project framework. Het Castle Project is, zoals ze zelf zeggen:

Castle is an open source project for .net that aspires to simplify the development of enterprise and web applications. Offering a set of tools (working together or independently) and integration with others open source projects, Castle helps you get more done with less code and in less time.

Het bevat o.a. support voor een MVC web framework (MonoRail), dependency injection (MicroKernel, Windsor Container) & een ORM mapper (ActiveRecord).

Core 1.2

Het hoofd component van het framework. In deze versie is het Email Sender component en de Logging service geintegreerd.

MicroKernel/Windsor 2.1.1

Dit is het dependency injection component van het Castle Framework. De nieuwe features zijn:

• Type forwarding
• Support for lazy loading van components
• Performance improvements

ActiveRecord 2.1

Dit is het ORM component van het Castle Framework. De nieuwe features zijn:

• Bijgewerkt met versie 2.1.4 van NHibernate
• ActiveRecord bepaald nu zelf op basis van het type wat de primary key generator moet zijn.
• Support voor read-only properties, hiermee kun je door de database gegenereerde waardes in je object beschikbaar maken.

Bronnen:

http://kozmic.pl/archive/2010/01/12/castle-windsor-2.1-dynamic-proxy-2.2-and-more-released.aspx
http://mortslikeus.blogspot.com/2010/01/activerecord-21-released.html

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?

Eergisteren is de nieuwste versie van Mono gereleased. Het open source alternatief voor het Microsoft .NET framework is aangeland op versie 2.6. De kern van deze release is de debugger en cross platform.

De belangrijkste nieuwe features zijn:

• Windows Communication Foundation subset zoals beschikbaar voor Silverlight 2.0
• LINQ to SQL
• De nieuwe debugger geintegreerd met MonoDevelop
• Inclusief de door Microsoft open source gemaakte versies van ASP.NET MVC, ASP.NET AJAX en de Dynamic Language Runtime
• En natuurlijk zijn verbetering op het gebied van performance en compatibiliteit met de Microsoft .NET API

Daarnaast is er een nieuwe versie van de populaire tegenhanger van Visual Studio gereleased: MonoDevelop 2.2. De belangrijkste features van deze nieuwe versie zijn:

• Ingebouwde debugger
• Refactor mogelijkheden (Inline rename, extract method, sort usings, etc.)
• Grafische interface is verbeterd
• Support voor ASP.NET MVC en T4 ontwikkeling

Het originele pers berich is te vinden op: http://www.mono-project.com/news/archive/2009/Dec-15.html

Zijn er al early adopters die hun mening willen delen? Plaats een reactie en laat het ons weten!

Ok, dit is mischien de vreemdste titel in de Nederlandse blog historie, maar er zit een goed verhaal achter geinspireerd op een presentatie van Jim Webber, architect bij ThoughtWorks. Zijn hilarische relaas gaat over service georienteerde architecturen en de Enterprise Service Bus.

Zoals bij jullie bekend is een Service Oriented Architectuur grof gezegd het aan elkaar knopen van systemen. Dit levert traditioneel een spaghetti van verschillende oplossingen op: CSV exports, gedeelde databases en webservices. Overal moeten er datatransformaties gedaan worden en nieuwe endpoints gemaakt worden omdat het ene systeem een SOAP interface heeft maar het andere alleen maar met CSV om kan gaan.

Wat doet een wel denkende object georienteerde developer als dingen complex worden? Juist, encapsuleren. Deze oplossing heet Enterprise Service Bus. De ESB is een grote doos waarin je al je spaghetti kunt verstoppen zodat niemand het meer ziet. Een beetje workflow om het geheel op smaak te brengen en iedereen (de business) is happy.

Eind goed, al goed? Niet volgens Jim Webber. Hij stelt dat je nu vast zit aan de leverancier van de ESB oplossingen en dat het uitbreiden van de ESB een kostbare operatie is. Wat er dan meestal gebeurd is het volgende: Zij (de business) willen weer eens wat anders en dit mag natuurlijk niets kosten omdat de return of investment onduidelijk is. Wat doe je dan? Je maakt een prototype buiten de ESB om met de uitdrukkelijke boodschap dat dit tijdelijk is. Iedereen (de business) blij: alles werkt zoals ze willen en het was ook nog goedkoop.

Lees verder »

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 »

In veel applicaties worden de state van objecten bepaald door tijd. Neem bijvoorbeeld deze blogpost: ik heb deze post vrijdagmiddag geschreven maar pas op maandag laten publiceren. Dit heeft op maandag een verborgen (impliciete) state transitie veroorzaakt; namelijk van ‘scheduled’ naar ‘published’.

Vaak een heeft een state transitie in het domein wel een betekenis. Ik wil bijvoorbeeld zodra er een artikel gepubliceerd is ook een notificatie e-mail uit laten gaan. Je wilt in dit geval dat je applicatie met een expliciete state transitie.

De welbekende blogger Ayende Rahien heeft een mooi stuk over dit ontwerp geschreven op zijn weblog. Zijn stuk is zeker de moeite waard om te lezen.

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 »

De afgelopen maanden heb ik samen met een aantal collega’s een vacatureportaal op het Liferay portal framework geïmplementeerd. Daarbij hebben we veelvuldig gebruik gemaakt van het genereren van Java code vanuit UML diagrammen en visa versa. Deze ervaring wil ik graag met jullie delen.

De opdracht was simpel: neem een bestaande webservice met vacatures, bedrijfsprofielen, zoekprofielen, etc.. Ontwikkel op basis daarvan de portlets die tesamen de portal gaan vormen. De webservice was deels gedocumenteerd en er was een functioneel ontwerp gemaakt. Een goed startpunt voor een project.

Technisch ontwerp

We zijn begonnen met het maken van een technisch ontwerp omdat we de webservice eerst goed wilde begrijpen en omdat we de volgende zaken goed gescheiden wilden houden:

• De portlets
• De webservice client implementatie

We hebben het technisch ontwerp gemaakt met behulp van UML interactie-, klasse- en sequentiediagrammen. Dit hebben we gedaan in Sparkx Enterprise Architect, naar mijn mening een van de beste UML tools.

Lees verder »