Observer Design Pattern – klassikern i händelsedrivna system

Observer, precis som andra designmönster, lyfter abstraktionsnivån utöver syntax eller notation. I likhet med några få (som t ex Proxy) ligger den nära arkitektur. För egna anpassningar, eller för att skippa dem, behövs en del arkitektglasögon.

Vi börjar med standardfrågan: hur pass mycket av det den uträttar är redan löst i plattformen, ”på burk”? EventHandler i Java? Ett bibliotek eller ramverk för GUI? Publish-Subscribe i en event bus (t ex ESB i ett företag eller databuss i en bil)? Observer spred sig av anledningar som många funderat kring, på olika håll.

I anpassningen av mönstret bör arkitekten sedan ta hänsyn till möjliga svagheter i runtime, vad gäller säkerhet, modifierbarhet/uppgraderingar, prestandakrav, användbarhet mm.

Mönstret Observer (bild) kopplar ihop verksamhetsobjektet (eng. subject dvs ungefär ”änmesobjektet”, kallat Bevakad i klassdiagrammet nedan)  till andra objekt. De blir observatörer och prenumererar på dess tillståndsövergångar (händelser), som det sedan skickar automatiskt till dem, d v s ”push” (den som växte upp med att i stället regelbundet polla verksamhetsobjektet kan se Observer som ett enkelt sätt att automatisera bort pollningen). Vid första anblick liknar strukturen i klassdiagrammet mycket annat. Kompletterar man med ett enkelt sekvensdiagram (nedre delen i bilden) som visar hur kommunikationen går genom (nedärvda, från mönstret) associationslänkar så blir det lättare att se vad Observer är till för.

Har vi alltså inte någon liknande mekanism klar ”på burk” så är det dags att även fundera på tänkbara anpassningspunkter. En är multipliciteten i Klassdiagrammet, som i verkligheten lutar besvärande ofta åt många till många, dvs ”*” i båda ändarna. Här uppstår en vanlig tradeoff för arkitekten: mellanhand (”Prenumerationsförmedlare”, t ex som tillägg i infrastrukturen) - eller inte. M a o ett val mellan modifierbarhet/återanvändbarhet och snabb exekvering. 2016 är svaret oftast modifierbarhet/återanvändbarhet, med infrastruktur (men det finns undantag även idag, tänk budgethårdvara för t ex Internet of Things).

Skillnaden i ett tecken ( ”*” i stället för ”1” i klassdiagrammet) medför flera konsekvenser för arkitekten, som t ex mellanhand med exekveringstid och single point of failure (eller kostnad för replikering) men även nya möjligheter att validera resp filtrera data i mellanhanden, eller att prioritera vissa observatörer.

Mellanhanden gör det dessutom praktiskt möjligt att minska ”bruset” av oönskade meddelanden från verksamhetsobjektet till olika observatörer.

Ett sätt att minska är att observatörerna prenumererar, m h a parametrar till mellanhanden, endast på relevanta händelser, d v s de som respektive observatör verkligen behöver känna till.

Ett ytterligare steg är att m h a ytterligare parametrar låta mellanhanden vidarebefordra enbart relevanta händelser med relevanta parametervärden, som t ex kursförändring där den nya aktiekursen hamnar över en önskad gräns. D v s mellanhanden skulle filtrera bort händelser som är försumbara för respektive observatör.

Poängen med ”push” framgår också i en längre övning i agil modellering, kursnr T2715 (modernisering och webbanslutning av systemarvet hos ett mäklarföretag). En mer detaljerad genomgång av Observer m fl mönster gör vi i Avancerad modellering med UML, T2716.

Milan Kratochvil

konsult, Kiseldalen.com

Huvudförfattare: Growing Modular: Mass Customization of Complex Products, Services and Software samt UML Xtra Light: How to Specify Your SW Requirements

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i modellering (T2715, T2716), grundläggande Arkitektur, Modular Product Line Architecture (T1430), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.