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.
konsult, Kiseldalen.com
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.
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.