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.

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

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?

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!

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.

Stop de pers! Deze oplossing is tijdelijk! We hebben nog dagen nodig om deze prima werkende oplossing weg te gooien en opnieuw op te bouwen binnen de ESB. Zij: “Heren architect, het werkt toch?”. Probeer nu de business maar eens te overtuigen dat het echt nodig is om een goed werkende oplossing weg te gooien. Ik heb zo het vermoeden dat het niet gaat lukken. 5 jaar later heb je weer een grote doos spaghetti en daartussen zweeft nog ergens een dure complexe gehaktbal (ESB).

Ok, dus de ESB is niet de oplossing. Wat is het dan wel? Volgens Jim Webber was de initiele spaghetti zo erg nog niet omdat (letterlijke quote, don’t shoot the messenger):

Business people have spaghetti for a brain. One day they want this, the next day something else.

Zijn oplossing: kies voor de pragmatische aanpak. Bespaar je de moeite en kosten van een ESB en implementeer simpele SOAP services. Leg de verantwoordelijkheid van de data transformaties bij de service en client implementatie. Zorg ervoor dat de discussie op message niveau plaatsvind omdat de business ook op dit niveau zit. Hij vergelijkt deze aanpak met de guerilla taktiek terwijl de ESB meer weg heeft van een frontale aanval.

Wat vinden jullie? Zijn jullie het met Jim eens of verklaar je hem voor gek? Heeft de ESB jullie geholpen of zorgt het alleen maar voor problemen? Ik hoor graag jullie reactie!

Bron:
http://www.infoq.com/presentations/webber-guerilla-soa

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!

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.

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.

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.

Lagen

Voor het opdelen van de applicatie in verschillende lagen was onze belangrijkste doel om de webservice aanroepen uit de presentatie laag te houden. Om dit te realiseren zijn we tot een betrekkelijk eenvoudig 3 lagen model gekomen om de code functioneel op te delen:

1. Service laag, deze laag is verantwoordelijk voor het aanroepen van de webservice.
2. Model laag, deze laag bevat het domein model van de applicatie.
3. Portlet/Presentatie laag, deze laag verzorgt de presentatie en de afhandeling van de gebruikers acties.

Elke laag heeft een specifieke functie. Ik zal in de volgende secties de drie lagen bespreken.

Model laag

Deze laag bevat de domeinklassen welke bepaald werden door het domein model van de webservice. De klassen in deze laag zijn POJOs (Plain Old Java Objects) met de nodige mapping attributen om van XML (resultaat van een webservice aanroep) naar object de deserialiseren.

Daarnaast hebben we zelf een aantal klassen toegevoegd die fungeerden als aggregate. Een aggregate is bedoel om het aantal relaties tussen objecten te beperken. Je kunt zeggen dat een aggregate als groep fungeert.

Voorbeeld
Om alle gegevens van een vacature op te halen moesten we een handvol webservice methoden aanroepen, dit is niet wat je in je presentatie code wilt terugzien. Dus hebben we een aggregate ontworpen die de resultaten van de diverse aanroepen bundelt.

Door elke klasse te modeleren in UML en direct te voorzien van de juiste mapping attributen en documentatie hebben we veel tijd bespaard: een druk op de knop en de Java klassen in deze laag waren gegenereerd.

Service laag

We hebben de service laag in UML uitgedrukt in de vorm van een klassendiagram met daarin alleen de interfaces. We hebben er voor gekozen om de interfaces functioneel op te delen: De vacature service is verantwoordelijk voor het zoeken en ophalen van vacatures en de bedrijfsprofielenservice is verantwoordelijk voor het ophalen van de bedrijfsprofielen.

De belangrijkste taak van de service laag is het groeperen van de diverse webservice aanroepen en het bundelen van de resultaten in aggregate objecten, lees: het abstraheren van de webservice.

Bij het ontwerpen van de service interfaces hebben we uitgezocht welke webservice aanroepen elke methode moet gaan doen. De namen van de webservice aanroepen hebben we vastgelegd in de documentatie van de desbetreffende methode.

Nadat we de interface gemaakt hadden hebben we de implementatieklassen gedefinieerd puur ter generatie van de code.

Portlet/Presentatie laag

Deze laag is verantwoordelijk voor het presenteren van de informatie en het afhandelen van gebruikershandelingen. We hebben bij het maken van het technisch ontwerp vooral gelet op de gebruikershandelingen die plaats kunnen vinden, de verschillende states waarin een portlet zich kan bevinden en de aanroepen naar de service laag. Dit hebben we gedaan met behulp van state- en interactiediagrammen.

Codegeneratie

Zoals eerder aangegeven hebben we intensief gebruik gemaakt van code generatie van UML diagrammen naar Java code. Dit heeft ons tijdswinst opgeleverd omdat we niet meer handmatig alle klassen over hoefden te zetten, wat saai en foutgevoelig werk is.

Gedurende het project zijn we op een aantal punten afgeweken van het technisch ontwerp. Gelukkig ondersteund Sparkx Enterprise Architect de mogelijkheid om van de gegenereerde code te synchroniseren met de UML diagrammen waardoor het technisch ontwerp gemakkelijk bijgewerkt kon worden.

Conclusie

Door slim gebruikt te maken van codegeneratie en code synchronisatie is het mogelijk om een van een statisch document een meegroeiend ontwerp te maken. Daarnaast kun je door slim gebruik te maken van aggregates complexiteit verbergen.

Ik hoop dat dit artikel je geholpen heeft bij nadenken over de architectuur van je eigen applicaties. Heb je een andere visie of ben je het ergens mee oneens? Plaats dan een reactie!