[alg/pattern] data awareness in transparante gelaagde apps

[Verwijderd]

Ik schrijf een conference-programmatje met drie layers (gui, protocol+state, multicast) waarbij de lagen zo transparant mogelijk zijn. De klassen roepen alleen methodes op zichzelf aan en met AOP (aspect orientated programming) filter ik message-calls en zorg ik voor de lower-level communicatie.

Nu moeten meerdere lagen weten wat de username van de client is op het moment dat deze zich heeft aangemeld in een conference. In de gui bijvoorbeeld om zinnen van de client zelf in een andere kleur weer te geven. In de protocol layer om een afzender aan een bericht te kunnen hangen.

Of dit echt noodzakelijk is doet er in principe niet toe. Ik bedacht me echter dat voor dit soort problemen misschien wel een design pattern is. Waar laat je data die door verschillende klassen moet worden gebruikt die in principe niet eens van elkaars bestaan afweten. Niet in een van de lagen zelf lijkt me. Om elke laag de data te laten bijhouden is ook niet mooi. Iemand een mooi (qua design) idee?

[Alarmnummer]

Verwijderd schreef op 20 september 2004 @ 09:09:
Ik schrijf een conference-programmatje met drie layers (gui, protocol+state, multicast) waarbij de lagen zo transparant mogelijk zijn. De klassen roepen alleen methodes op zichzelf aan en met AOP (aspect orientated programming) filter ik message-calls en zorg ik voor de lower-level communicatie.

Andere lagen mogen wel afweten van je domeinlaag. Dus het achterhalen van de naam van een user moet geen probleem zijn.

[Verwijderd]

Alarmnummer schreef op 20 september 2004 @ 09:12:

Andere lagen mogen wel afweten van je domeinlaag. Dus het achterhalen van de naam van een user moet geen probleem zijn.

HA! Okee door je antwoord ging een belletje rinkelen Kan je antwoord niet direct gebruiken omdat er dus sprake is van superloose coupling - ik heb niet eens een instantie van de onderliggende laag.

Ik kan via dezelfde AOP techniek een methode toevoegen aan een laag waarvan de implementatie gebruikt wordt in een andere klasse. Dus ik zeg in de gui gewoon this.getUsertitle() (ondankt dat deze methode niet bestaat) en m'n message-filtering zorgt ervoor dat de methode in de protocol-laag wordt geexecuteerd. Gewoon een uitbreiding van het protocol dus eigenlijk.

tx

[Alarmnummer]

Verwijderd schreef op 20 september 2004 @ 09:20:
[...]
HA! Okee door je antwoord ging een belletje rinkelen Kan je antwoord niet direct gebruiken omdat er dus sprake is van superloose coupling - ik heb niet eens een instantie van de onderliggende laag.

Iedereen kan in principe bij mijn domein laag komen (eventueel via services of remote facades). Kijk trouwens ook even naar Pico en Spring (beanfactory) voor container oplossingen (handig om bij referenties van objecten te komen zonder dat ze hard aan elkaar gekoppeld zijn).

Ik kan via dezelfde AOP techniek een methode toevoegen aan een laag waarvan de implementatie gebruikt wordt in een andere klasse. Dus ik zeg in de gui gewoon this.getUsertitle() (ondankt dat deze methode niet bestaat) en m'n message-filtering zorgt ervoor dat de methode in de protocol-laag wordt geexecuteerd. Gewoon een uitbreiding van het protocol dus eigenlijk.

Ik ben bekend met AOP, maar krijg je zo geen ongelovelijk grote puinzooi? AOP is voornamelijk bedoelt om crosscutting concerns (zoals transacties, logging) aan te pakken, en niet om een enkele class uit te gaan breiden met allerlei business methods.

[ Voor 7% gewijzigd door Alarmnummer op 20-09-2004 09:39 ]

[farlane]

Verwijderd schreef op 20 september 2004 @ 09:20:
Kan je antwoord niet direct gebruiken omdat er dus sprake is van superloose coupling - ik heb niet eens een instantie van de onderliggende laag.

Klinkt allemaal erg interessant allemaal. Ik kan me er alleen niets bij voorstellen.

Heb je misschien tijd en zin om een beetje uit te leggen hoe dat dan in zijn werk gaat ? Hoe spreek je dan die laag aan ?

[EfBe]

Verwijderd schreef op 20 september 2004 @ 09:09:
Ik schrijf een conference-programmatje met drie layers (gui, protocol+state, multicast) waarbij de lagen zo transparant mogelijk zijn.

Wat houdt 'zo transparant mogelijk zijn' in? Een stukje plexiglas is transparant, maar wat houdt een transparante laag in een software applicatie in vredesnaam in?

De klassen roepen alleen methodes op zichzelf aan en met AOP (aspect orientated programming) filter ik message-calls en zorg ik voor de lower-level communicatie.
Nu moeten meerdere lagen weten wat de username van de client is op het moment dat deze zich heeft aangemeld in een conference. In de gui bijvoorbeeld om zinnen van de client zelf in een andere kleur weer te geven. In de protocol layer om een afzender aan een bericht te kunnen hangen.

Of dit echt noodzakelijk is doet er in principe niet toe. Ik bedacht me echter dat voor dit soort problemen misschien wel een design pattern is. Waar laat je data die door verschillende klassen moet worden gebruikt die in principe niet eens van elkaars bestaan afweten. Niet in een van de lagen zelf lijkt me. Om elke laag de data te laten bijhouden is ook niet mooi. Iemand een mooi (qua design) idee?

Dat pattern is er, het heet "Pragmatisch omgaan met problemen". Ik klink wellicht als een oude zeikstraal, maar volgens mij ben je eerst zelf de problemen aan het creeeren om ze daarna omslachtig op te lossen.

De user die het programma runt heeft een 'user state'. De applicatie an sig is distributed dus die heeft een 'application state'. De 'user state' is de state van een individuele user binnen de applicatie, dus dat deze is ingelogd, user gegevens, etc. etc. Deze user state geef je een plek in een object bijvoorbeeld en die bewaar je in de client bijvoorbeeld. Bij een call naar beneden waar de user state nodig is geef je die mee.

De client is niet 'de gui', maar de executable.

[EfBe]

Alarmnummer schreef op 20 september 2004 @ 09:28:
Ik ben bekend met AOP, maar krijg je zo geen ongelovelijk grote puinzooi? AOP is voornamelijk bedoelt om crosscutting concerns (zoals transacties, logging) aan te pakken, en niet om een enkele class uit te gaan breiden met allerlei business methods.

Juist wel, AOP is bedoelt voor het toevoegen van behavior at runtime aan objects. Wat die behavior is, dat boeit niet echt.

De TS heeft echter een klassiek user state probleem en dat heeft geen moer met AOP te maken, maar puur met de perceptie wat het verschil is tussen application state en user state.

[Alarmnummer]

EfBe schreef op 20 september 2004 @ 09:43:
Dat pattern is er, het heet "Pragmatisch omgaan met problemen".

En dat is een pattern uit de KISS categorie.

[ Voor 4% gewijzigd door Alarmnummer op 20-09-2004 10:01 ]

[Alarmnummer]

EfBe schreef op 20 september 2004 @ 09:46:
[...]
Juist wel, AOP is bedoelt voor het toevoegen van behavior at runtime aan objects. Wat die behavior is, dat boeit niet echt.

Je wilt met AOP crosscutting concern problematiek op gaan lossen, en die business method is niet zo`n concern. Dus die moet niet met AOP opgelost gaan worden. Dat je met AOP runtime functionaliteit aan objecten kan toevoegen doet daar niet toe.

[Verwijderd]

EfBe schreef op 20 september 2004 @ 09:43:

Wat houdt 'zo transparant mogelijk zijn' in? Een stukje plexiglas is transparant, maar wat houdt een transparante laag in een software applicatie in vredesnaam in?

Nou misschien was m'n woordkeuze niet helemaal juist maar ik wilde deze message-filtering techniek van de communicatie abstraheren. Het idee is dat ik heel algemene methodes aanroep maar wat voor domein ik er via message-filtering aan koppel maakt voor de gui niet uit, in dit geval dus een conference-object maar ik zou er ook een mirc-object aan kunnen koppelen - als dit protocol ongeveer dezelfde functies heeft - zonder ook maar 1 regel in de gui te hoeven aanpassen. Op dezelfde manier kan ik dus onder de domeinlaag de multicast-laag kunnen verwisselen met een op tcp gebaseerde communicatie-laag. Andere toepassingen zijn bijvoorbeeld multiple inheritance en multiple views (door bepaalde messages te blocken.

Dat pattern is er, het heet "Pragmatisch omgaan met problemen". Ik klink wellicht als een oude zeikstraal, maar volgens mij ben je eerst zelf de problemen aan het creeeren om ze daarna omslachtig op te lossen.

De user die het programma runt heeft een 'user state'. De applicatie an sig is distributed dus die heeft een 'application state'. De 'user state' is de state van een individuele user binnen de applicatie, dus dat deze is ingelogd, user gegevens, etc. etc. Deze user state geef je een plek in een object bijvoorbeeld en die bewaar je in de client bijvoorbeeld. Bij een call naar beneden waar de user state nodig is geef je die mee.

De client is niet 'de gui', maar de executable.

Daar heb je wel een punt. Mijn fout was inderdaad om de username als state te zien maar de state is in dit geval alleen of ik wel of niet al aangemeld ben. De username kan inderdaad wel bij elk bericht opnieuw meegegeven worden.

farlane schreef op 20 september 2004 @ 09:33:
[...]
Klinkt allemaal erg interessant allemaal. Ik kan me er alleen niets bij voorstellen.

Heb je misschien tijd en zin om een beetje uit te leggen hoe dat dan in zijn werk gaat ? Hoe spreek je dan die laag aan ?

Zal als ik zo op school ben even wat toelichten, is misschien wel interessant. Het is namelijk vrij nieuw en niet direct een AOP techniek, maar eigenlijk slechts een message-filtering techniek waarbij gefilterde messages in een 'filtermodule' kunnen worden tegengehouden of naar een ander object kunnen worden gedispatched. AOP is slechts een toepassing door zo'n filtermodule bovenop meerdere klassen te leggen (superimposen).

[ Voor 31% gewijzigd door Verwijderd op 20-09-2004 10:06 ]

[EfBe]

Alarmnummer schreef op 20 september 2004 @ 09:48:
Je wilt met AOP crosscutting concern problematiek op gaan lossen, en die business method is niet zo`n concern. Dus die moet niet met AOP opgelost gaan worden. Dat je met AOP runtime functionaliteit aan objecten kan toevoegen doet daar niet toe.

Ik weet niet wat met crosscutting concern bedoeld wordt, maar ik ken geen 'wet' die zegt dat iets niet moet (in software development). AOP is juist erg geschikt voor het at runtime toevoegen van behavior en daardoor JUIST geschikt voor bv het toevoegen van BL aan kale objects. Zodoende kun je dus meer code hergebruiken, immers BL voor een 'customer' kun je dan bv af laten hangen van welke customer het is, of van het systeem wat je aan het bouwen bent. Prak je dat er at compile time in, dan kun je je Customer object niet hergebruiken.

Ik snap dat 'dat moet niet' en 'dat hoort niet' denken niet zo. Dat soort denken praktiseren ze op ministeries, niet binnen software development cycles waar je pragmatisch met problemen moet omgaan.

[ Voor 4% gewijzigd door EfBe op 20-09-2004 12:30 ]

[EfBe]

Verwijderd schreef op 20 september 2004 @ 10:00:
Nou misschien was m'n woordkeuze niet helemaal juist maar ik wilde deze message-filtering techniek van de communicatie abstraheren. Het idee is dat ik heel algemene methodes aanroep maar wat voor domein ik er via message-filtering aan koppel maakt voor de gui niet uit, in dit geval dus een conference-object maar ik zou er ook een mirc-object aan kunnen koppelen - als dit protocol ongeveer dezelfde functies heeft - zonder ook maar 1 regel in de gui te hoeven aanpassen. Op dezelfde manier kan ik dus onder de domeinlaag de multicast-laag kunnen verwisselen met een op tcp gebaseerde communicatie-laag. Andere toepassingen zijn bijvoorbeeld multiple inheritance en multiple views (door bepaalde messages te blocken.

Is dan een MVC pattern niet wat je zoekt?

En bedenk wel: door alle mogelijke zaken zo abstract mogelijk te willen definieren verlies je uit het oog dat abstractielevels leuk zijn, maar eens moet je details gaan invullen, en hoe abstracter je alles definieert, hoe complexer dat wordt. Niets komt voor niets: meer abstractie aan de ene kant is meer complexiteit aan de andere kant (want die abstractie moet wel door iets ondersteunt worden). Ik weet niet of je je problemen wel op de meest efficiente manier oplost op deze manier, want voor je het weet ben je een half jaar bezig met het bouwen van algemene dingen maar worden die nooit gebruikt.

Daar heb je wel een punt. Mijn fout was inderdaad om de username als state te zien maar de state is in dit geval alleen of ik wel of niet al aangemeld ben. De username kan inderdaad wel bij elk bericht opnieuw meegegeven worden.

Je moet niet onderdeeltjes van de userstate als aparte state gaan zien. De user heeft een state in de applicatie. De data die daarbij hoort is een single unit. Logica in je applicatie put uit die unit voor user-specifieke acties. De logica in je applicatie put uit de applicatie state voor applicatie-specifieke acties.

[Verwijderd]

EfBe schreef op 20 september 2004 @ 12:30:
Is dan een MVC pattern niet wat je zoekt?

En bedenk wel: door alle mogelijke zaken zo abstract mogelijk te willen definieren verlies je uit het oog dat abstractielevels leuk zijn, maar eens moet je details gaan invullen, en hoe abstracter je alles definieert, hoe complexer dat wordt. Niets komt voor niets: meer abstractie aan de ene kant is meer complexiteit aan de andere kant (want die abstractie moet wel door iets ondersteunt worden). Ik weet niet of je je problemen wel op de meest efficiente manier oplost op deze manier, want voor je het weet ben je een half jaar bezig met het bouwen van algemene dingen maar worden die nooit gebruikt.

Nee, MVC zoek ik niet. Ik ben namelijk een simpel implementatieveelbeeld aan het schrijven voor precies dat wat ik omschreef: je kent het wel, van die plaatjes van layered netwerkapplicaties met pijltjes tussen de verschillende entiteiten op dezelfde laag maar waarbij communicatie stiekum via de laag eronder gaat. En dat stiekeme los ik dus op via message filtering, wat daar uitermate geschikt voor is: alle uitgaande messages stuur ik dus stiekum in de onderliggende laag naar alle andere members van een conference. Dus m'n aanpak is wat mij betreft wel goed, ik had alleen even een dwaling wat betreft die username.

En wat betreft het uit de hand lopen van abstractielevels: ik heb op alle niveaus de protocolfuncties aan de bovenkant en de onderkant van de laag al vastgelegd, inclusief de informatie die in de laag wordt bijgehouden/toegevoegd, en weet dus al wel dat dat goed komt.

Je moet niet onderdeeltjes van de userstate als aparte state gaan zien. De user heeft een state in de applicatie. De data die daarbij hoort is een single unit. Logica in je applicatie put uit die unit voor user-specifieke acties. De logica in je applicatie put uit de applicatie state voor applicatie-specifieke acties.

Ok ik moet blijkbaar ook iets gedetaileerder blijven in m'n woordkeuze Met "username is state" bedoel ik onderdeel van de state. En met state in m'n conference-layer bedoel ik het state-pattern aldaar dat alleen betrekking heeft op het al dan niet gejoined zijn van een conference en dus al dan niet mogen versturen van een message naar deze conference. De username heeft daar gewoon geen kont mee te maken, my bad.

[Alarmnummer]

EfBe schreef op 20 september 2004 @ 12:24:
[...]
Ik weet niet wat met crosscutting concern bedoeld wordt, maar ik ken geen 'wet' die zegt dat iets niet moet (in software development). AOP is juist erg geschikt voor het at runtime toevoegen van behavior en daardoor JUIST geschikt voor bv het toevoegen van BL aan kale objects.

Met een crosscutting concern wordt bedoelt een bepaald probleem dat je over je hele applicatie terug ziet. Voorbeelden hiervan zijn logging en transacties. Deze concern staat haaks op je normale problemen omdat die meestal maar over 1 klasse gaan.

Ik snap dat 'dat moet niet' en 'dat hoort niet' denken niet zo. Dat soort denken praktiseren ze op ministeries, niet binnen software development cycles waar je pragmatisch met problemen moet omgaan.

Het is geen kwestie van "dat hoort niet zo" maar je meot weten waar AOP geschikt voor is, en waarvoor niet. Misschien dat zijn extra business method wel voor elkaar krijgt, maar met grote projecten kom je enorm in de knoei. Dat is een van de let-op punten van AOP. Je kan binnen no-time een applicatie in elkaar zetten die niet meer te doorgronden is.

[ Voor 10% gewijzigd door Alarmnummer op 20-09-2004 13:58 ]