[Java] Design pattern controller achtig probleem.

[Alarmnummer]

Design patters probleem.

Stel dat ik een class Persoon heb, en een class PersoonTable. In deze PersoonTable staan alle personen in een HashMap op basis van hun achternaam. Als je nu setAchternaam aan gaat roepen om die persoon een andere achternaam te geven dan moet in die HashMap persoon opnieuw geplaatst worden. Je zou ervoor kunnen kiezen om bij persoon.setAchternaam() ook even een verwijzing te maken naar die PersoonTable maar dit is ongelovelijk lelijk. Het meest logische lijkt me om een nieuw object aan te maken waar je een setAchternaam(Persoon persoon) op aan kan roepen. Deze kan dan persoon een nieuwe achternaam geven en de hashkey voor de PersoonTable opnieuw laten berekenen. Je zou er ook voor kunnen kiezen om PersoonTable te laten luisteren naar alle achternamen van personen en dan te updaten als er een achternaam verandering is. Er zijn dus een hele lading oplossing denkbaar, maar er is hier vast wel een design pattern voor. (Mijn Design Patterns boek die komt over een week of 2 ). Ik zoek hier eigelijk wat meer info over.

[ps] vandaag heb ik veel te vragen

[drm]

Ik zie het

Als je dan toch een class PersoonTable hebt, dan is dat toch juist de klasse die daar controle op uit moet oefenen, of zie ik dat nou verkeerd

[Alarmnummer]

Op dinsdag 11 december 2001 13:29 schreef drm het volgende:
Ik zie het

Als je dan toch een class PersoonTable hebt, dan is dat toch juist de klasse die daar controle op uit moet oefenen, of zie ik dat nou verkeerd

Maar stel dat die persoon in meerdere persoon tables zit. Dan moet je ieder persoon table bijlangs om die hashkey opnieuw te laten berekenen. Daarom lijkt het me logischer om hier een algemene 'controller' voor te maken.

dus:

code:

PersoonController.veranderAchternaam(Persoon persoon,String achternaam)
{
   klasPersoonTable.setAchternaam(persoon,achternaam);
   werkPersoonTable.setAchternaam(persoon,achternaam);  
   persoon.setAchternaam(achternaam);
}

Dit zou je ook iets algemener kunnen doen door een lijst met persoontabellen in die controller op te nemen. Dan kun je ongeacht het aantal lijsten iedereen updaten.

[Alarmnummer]

En als je dit soort controller achtige structuren hebt, dan loop je dus met een aantal setAchternamen te rommelen. En dit biedt de mogelijkheid dat een andere programmeur alleen setAchternaam bij persoon aanroept en helemaal die controller vergeet. Ik zit hier dus een beetje met mij handen in het haar (kun je nagaan.. ik heb haar van 3 mm lang )

[drm]

Op dinsdag 11 december 2001 13:34 schreef Alarmnummer het volgende:
Maar stel dat die persoon in meerdere persoon tables zit. Dan moet je ieder persoon table bijlangs om die hashkey opnieuw te laten berekenen. Daarom lijkt het me logischer om hier een algemene 'controller' voor te maken.

hmmm ja, da's waar.

Dit zou je ook iets algemener kunnen doen door een lijst met persoontabellen in die controller op te nemen. Dan kun je ongeacht het aantal lijsten iedereen updaten.

Of in de persoon-class een array opnemen die bijhoudt waar de persoon zelf in zit.

Maar dat mag in principe alleen als persoonobjecten ook altijd in zo'n context voorkomen... En dat is inderdaad ook gewoon lelijk

OO-gezien beetje rottig probleem.

* drm wacht op de guru's

_edit:

Alarmnummer:
En als je dit soort controller achtige structuren hebt, dan loop je dus met een aantal setAchternamen te rommelen. En dit biedt de mogelijkheid dat een andere programmeur alleen setAchternaam bij persoon aanroept en helemaal die controller vergeet. Ik zit hier dus een beetje met mij handen in het haar (kun je nagaan.. ik heb haar van 3 mm lang )

Ja dat is waar. Maar dat is tegelijk ook weer een kwestie van goed documenteren

[Alarmnummer]

Misschien is het mogelijk om het met een access modifier te beschermen.

[Verwijderd]

Waarom kunnen personen in meerdere personentables zitten. Ligt daar niet je probleem?

[Alarmnummer]

Op dinsdag 11 december 2001 14:04 schreef fladder het volgende:
Waarom kunnen personen in meerdere personentables zitten. Ligt daar niet je probleem?

Waarom zou een persoon niet in meerdere tabellen kunnen voorkomen? Ik vind dit eerlijk gezegd een duidelijk voorbeeld. En ook al zou hij in 1 table voorkomen dan heb je nog het probleem dat bij die table ook een hashkey verandering gedaan moet worden en daar gaat het hier om: een algemene design pattern als iets moet veranderen bij meerdere objecten.

[Rhythmic]

OK, het probleem is dus dat de verandering van een Object (in dit geval een Persoon) gevolgen kan hebben voor een aantal andere objecten. Dat houdt in dat je als je het object veranderd, ook alle objecten die ervan afhankelijk zijn moet veranderen. Ik zie 2 mogelijkheden:

1) je veranderd alleen d.m.v. een soort Control object, dat alle plekken waar het object gebruikt wordt bijhoudt. Dit houdt in dat je objecten alleen kan wijzigen via die controller. Zodra je dat doet zal de controller ook alle afhankelijke objecten bijwerken. Dit is jouw PersoonController. Het is alleen niet zo'n mooie oplossing. Voor elk soort afhankelijkheid moet je dan immers een nieuwe controller schrijven.

2) je laat het object zelf bijhouden welke objecten ervan afhankelijk zijn. Dit is jouw 'luister' optie, en komt overeen met het Observer pattern. Java bevat al een Observer en Observable class (in java.util), dus als je die gebruikt ben je d'r. Dit zou betekenen dat elke PersoonTable zich registreert als Observer bij alle Persoon-objecten die in de table zitten. Omdat alle tables hun personen observeren zal de verandering van 1 Persoon ervoor zorgen dat het Persoon object zelf een methode update() aanroept in alle PersoonTables waar die Persoon in zit, waarna elke table zelf kan beslissen wat er gedaan moet worden.

De laatste oplossing heeft het voordeel dat een geinteresseerd object zelf kan bepalen wat het doet als een object waarvan het afhankelijk is veranderd; bij de controller optie ga je er van uit dat alle kennis in de controller zit.

[Alarmnummer]

Alle kennis van de geintereseerden hoeven niet bij de controller te zitten. Je maakt een achternaamListerer interface en die meld zich aan bij die controller. Dan hoeft de controller niets meer af te weten van het aantal luisteraars.

[edit] ik loop je te herhalen.. sorry.. verstand er niet bij..

[Alarmnummer]

Nadeel aan die oplossing is (dat als iedere persoon een lijst met observers bijhoud) er nogal een groot geheugen verbruik is. En dat bij persoon dingen zitten die er eigelijk niet horen. Mijn eigen ervaring is dat je nogal lelijke code hierdoor krijgt. Vandaar de controller.

[Tomatrix]

Waarom wil je eigenlijk de achternaam veranderen? Voor trouwende vrouwen?

Niet echt een antwoord op je design-pattern vraag, maar ik denk dat het beter is om te hashen op een veld of velden die niet veranderen. Neem bijvoorbeeld het sofinummer of de geboortedatum.

[Alarmnummer]

Op dinsdag 11 december 2001 15:45 schreef Tomatrix het volgende:
Waarom wil je eigenlijk de achternaam veranderen? Voor trouwende vrouwen?

Niet echt een antwoord op je design-pattern vraag, maar ik denk dat het beter is om te hashen op een veld of velden die niet veranderen. Neem bijvoorbeeld het sofinummer of de geboortedatum.

Het is een voorbeeld Niet een specifiek geval. Het gaat dus om een design pattern waarbij meerdere objecten afhankelijk zijn een bepaald object zijn waarde.

[Rhythmic]

Over het geheugengebruik:

Een Controller houdt geen referenties bij naar Tables, want die zitten er gewoon hard-coded in. Als de update-operaties altijd op dezelfde objecten werken is dat wellicht geheugen-efficienter. Anders gezegd, als het veranderen van een Persoon altijd alleen maar gevolgen heeft voor 4 dezelfde Table-objecten in je programma is het waarschijnlijk efficienter een Controller object die tables handmatig/hardcoded te laten updaten dan dat elk Persoon object refenties bijhoudt naar de 4 Tables en zelf die tables update.

Een nadeel is natuurlijk dat het iets meer programmeer-discipline vergt: als je ergens een Persoon update zonder gebruik te maken van de Controller heb je een probleem, want dan kloppen je tables niet meer.

Verder is het niet zo dat bij gebruik van Observer in een Persoon dingen zitten die er niet in horen. Een persoon is gewoon een object dat geobserveerd kan worden, en houdt bij wie dat allemaal zijn. Het grote voordeel is dat Persoon nu zelf kan bepalen wanneer het zijn observeerders wil updaten. Verder is deze opzet een stuk flexibeler: niet alle Personen hoeven door dezelfde objecten geobserveerd te worden (wat bij de Controller wel zo is), en interesses kan je runtime veranderen. De vraag is alleen of je zoveel flexibiliteit nodig hebt in je programma.

Over lelijke code: in principe is het werken met Observers hetzelfde als werken met alle Listeners. Heel AWT & Swing werkt daar ook mee. Het programmeert anders, maar niet perse lelijker: in plaats van zelf altijd actie te ondernemen wacht je tot je wat moet doen.

[Tomatrix]

Op dinsdag 11 december 2001 15:46 schreef Alarmnummer het volgende:

[..]

Het is een voorbeeld Niet een specifiek geval. Het gaat dus om een design pattern waarbij meerdere objecten afhankelijk zijn een bepaald object zijn waarde.

Dan gewoon het Observer pattern gebruiken, en maak je maar niet zo druk om het geheugengebruik.

[Alarmnummer]

Een Controller houdt geen referenties bij naar Tables, want die zitten er gewoon hard- coded in. Als de update-operaties altijd op dezelfde objecten werken is dat wellicht geheugen-efficienter. Anders gezegd, als het veranderen van een Persoon altijd alleen maar gevolgen heeft voor 4 dezelfde Table-objecten in je programma is het waarschijnlijk efficienter een Controller object die tables handmatig/hardcoded te laten updaten dan dat elk Persoon object refenties bijhoudt naar de 4 Tables en zelf die tables update.

Je kan ook bij die controller een lijst opnemen met luisteraars (tables bv) naar verandering van achternaam. Hierdoor kan de controller op een willekeurig aantal tables werken.

Maar wat ik hoop te bereiken is dat ik de objecten wat dommer kan houden, en veel logica kan verplaatsen naar die controller.

[Tomatrix]

Beodel je misschien een Mediator?

[Alarmnummer]

Ik weet niet wat een mediator design pattern is. Heb je een link voor mij?

[Rhythmic]

Link: http://www.execpc.com/~gopalan/design/behavioral/mediator/mediator.html

[Alarmnummer]

volgens mij is Mediator design pattern wel iets

Sometimes, the interactions
between these objects become so much that every object in
the system ends up knowing about every other object. Lots
of such interactions prevent an object from working
without the support of a lot of other objects and thus
the whole system ends up becoming one huge monolith - you
ended up in the same mess you tried to un-entangle in the
first place!

[Alarmnummer]

en ook nog van Gemma

Thus,
as defined by Gamma et al, "A mediator serves as an
intermediary that keeps objects in a group from referring to each
other explicitly".

[Alarmnummer]

[edit] links werken niet en waarom krijg ik niet de tekst die ik de laatste keer heb veranderd maar altijd de 1e tekst. Moet je en de oude fouten herstellen + de nieuwe. Waardeloos.

deze doet het wel:
http://www.patterndepot.com/

[Alarmnummer]

deze is volgens mij wel aardig.
http://rampages.onramp.net/~huston/dp/patterns.html

en hier een beschrijving van veel patterns:
http://www.agcs.com/supportv2/techpapers/patterns/papers/patexamples.htm

[mbravenboer]

Dit is toch typisch een Model View Controller probleem denk ik... Je moet die personen zijn als een Model. De Table is een View. Je past het Model aan, waardoor de View zich 'automagisch' moet aanpassen.

Zelf pak ik dit altijd op een aantal niveaus aan:

1. Simpele domein-objecten met set+get methoden en geen luister-mogelijkheden. Dat zou in dit geval dus een klasse 'Person' zijn.

2. Modellen voor domein-objecten: via deze modellen kan je properties van een domein-object aanpassen. Modellen bieden luistermogelijkheid. In dit geval zou dat dus een PersonModel kunnen zijn. Als je veel items hebt is het inderdaad niet prettig om elk item een listener aan te melden, daarom werk ik ook met modellen voor verzamelingen, waarop je dan een listener aanmeldt.

3. Wrappers die je domein-object modellen omzetten naar een Swing model.

Tegenwoordig bouw ik modellen vaak op uit primitieve modellen. Een PersonModel kan je bijvoorbeeld opbouwen uit een StringModel voor de voor en achternaam. Het grote voordeel is dat je dit StringModel bijvoorbeeld ook onder een TextField kan hangen. Als je dit volledig doorvoert, wordt het allemaal erg yummie .

[Alarmnummer]

Bij mvc gaat het over de visualisatie van de model. Maar mijn probleem is dat (model) objecten van elkaar afhankelijk zijn, zoals persoon en persoontable (ivm hashkey persoon). (Ik herhaal nog een keer.. dit is een voorbeeld) Het gaat erom dat de code van persoon niet 'vervuild' gaat worden met het rehashen van de persoon table, en volgens mij is die mediator pattern daar erg geschikt voor. Ik ben verder niet geintereseerd in de visualisatie voor dit probleem.

[edit] voor de duidelijkheid. met een persoonTable bedoel ik geen JTable maar een verzameling met personen

[Woy]

Dit kan je volgens mij wel oplossen met mvc jah. Er zijn hier al standaard klassen voor namenlijk Observer en Observable. volgens mij zitten die in de java.util package

[Alarmnummer]

ik ben niet geinteresseerd in een view, want daar is MVC (Model View Controller) voor geschreven. Ik ben alleen geinteresseerd in het verhinderen van het verweven van objecten en dat kan dus met een Mediator design pattern.

[Woy]

ja dat kan ook en is in dit geval wel beter denk. Maar je hoeft niet altijd alles te gebruiken waar het voor bedoeld is

[Alarmnummer]

Op dinsdag 11 december 2001 23:24 schreef rwb het volgende:
ja dat kan ook en is in dit geval wel beter denk. Maar je hoeft niet altijd alles te gebruiken waar het voor bedoeld is

Ik snap denk ik wel wat je bedoelt. In de controller van MVC kun je vrij veel logica plaatsen, en dat bezit hier die Mediator (is een tussen klasse) ook. Bij MVC praat M met C en C weer met V en dat zou hier dan zijn: Persoon met Mediator en Mediator met PersoonTable. bedoel je dat?

En ik gebruik dingen liever wel waar ze voor zijn, zodat een andere programmeur snapt wat ik bedoel doordat ik een standaard aanpak gebruikt. (een noodoplossing kan iedereen wel bedenken, maar dan krijg je van die spaghetti code)

[Alarmnummer]

een online boek (200+ pagina`s) over java en design patterns.
http://www.patterndepot.com/put/8/JavaPatterns.htm

en nog een van onze grote vriend Bruce Eckel.
http://64.78.49.204/TIPatterns-Word.zip