[Java]Hoe kan ik het object georieënteerd houden

[mpegernie]

Dit is een erg lang verhaal maar ik hoop dat het hier op de goede plaats is en dat er zo op de zaterdag avond mensen zijn die zin hebben hier aandacht aan te geven.
In het kort: Ik heb een vraag over hoe ik nette programma's schrijf.

Ik heb een tijdje geleden geleerd om bij een nieuw programma de GUI gescheiden te houden van methodes die op de achtergrond werken. Globaal houd het in dat de GUI het object kent dat naast zich zit. Zo kan het gemakkelijk methodes in dat andere object aanspreken die, zoals eerder gezegd, niet in de GUI thuishoren.
Mijn zorg is nu dat dit code opleverd die niet onafhankelijk is en is gebaseerd op het bestaan van bepaalde classes met bepaalde methodes boven zich en naast zich. En aangezien ik al eerder een programma heb geschreven dat werd beoordeeld als "spagetti" wil ik het ook wel eens graag goed doen
Ter verduidelijking een probleem waar ik vaak tegenaan loop...

Situatie schets
Ik heb een main waaronder een GUI en een manager hangt. (zie ook schema onderaan)
De manager zorgt voor het laden van het juiste plaatje (bekend door de <param>-tags).
De GUI zorgt voor het weergeven van het plaatje en heeft een knop om het volgende plaatje te laden.

De GUI kent de manager en de main doordat deze objecten aan hem meegegeven zijn:

code:

gui = new Gui(this, this.manager);

De Manager kent alleen de main, op dezelfde manier meegeven.

Op deze manier kan ik gemakkelijk in de GUI bijvoorbeeld manager.loadImage(iImageNumber) aanspreken.

Maar nu voer ik dit nog verder door met het maken van meerdere layers in de GUI (JLayerdPane) waarin nieuwe objecten worden gemaakt.
3 stuks:
de background (een plaatje),
de controls (2 knoppen)
en displayImage (de laag waarin het plaatje wordt geladen).

En ook enkele van deze objecten kennen de Main en de Manager. Dit omdat controls ervoor moet zorgen dat de manager het plaatje laadt waarna DisplayImage het moet weergeven.

De totale situatie schematisch weergegeven:


Mijn vraag
Nu, gegeven de eventuele bezwaren die ik in de inleiding noemde:
is het slim, of beter gezegd netjes, om voortdurend bovenhangende objecten mee te geven naar onderen?
Of moet ik dit beperken tot GUI en Manager zodat deze over en weer objecten kunnen sturen. Terwijl in GUI een serie methodes zijn ingebouwd die zorgen dat de onderliggende classes worden aangestuurd.
En ifso, hoe moet ik er dan voor zorgen dat een event in Controls (knop ingedrukt) ervoor zorgt dat GUI een opdracht aan Manager geeft, zonder dat Controls de GUI kent?

[ Voor 0% gewijzigd door mpegernie op 02-11-2002 22:49 . Reden: hmmm... rare tags ]

[talpje]

Het is niet netjes om al die objecten zo door te geven nee... Je kunt beter een Controller-View-Model systeem gebruiken. Dus in je main maak je: Controller c = new Controller(new View(), new Model()), en zo kan de controller de interactie tussen je model (de functionaliteit) en je View(de GUI) regelen. Dit is veel netter imho.

[ Voor 0% gewijzigd door talpje op 02-11-2002 22:57 . Reden: foutjes ;) ]

[Soultaker]

Ik zal Alarmnummer maar even voor zijn met z'n gezeur over design patterns, MVC en Mediators.

Het is in het algemeen handig om elk object (dus ook elk GUI element) zich zoveel mogelijk te laten beperken tot de kernfunctionaliteit. Een veelvoorkomende structurering, is het maken van een enkel object dat de gegevens die je wilt presenteren bevat (in MVC termen de 'Model', ook wel bekend als 'Document' uit de Document-View architectuur).

De GUI elementen die de gegevens weergeven en wijzigen, zijn dan de Views respectievelijk de Controllers (MVC terminologie) of gewoon de Views. In principe communiceren de Views en Controllers niet direct met elkaar. Als een gebruiker iets met een controller doet (op een knopje klikt of aan een scrollbar schuift) dan geeft die dat door aan het Model (of Document) object. Deze zorgt er vervolgens voor dat de juiste Views bijgewerkt worden (dit kan vaak het beste met gebruik van het Observer pattern, ook wel bekend onder de term EventListeners).

Het is dus zaak, om voor elk View object methoden te definieren om de weergave te wijzigen, en voor het Model object om methoden te definieren waarmee de beschikbare gegevens gemanipuleerd worden (ten behoeve dan de Controllers). Ook moeten de View objecten op de een of andere manier geregistreerd zijn bij het Document object; vaak kan dit gewoon door ze te hardcoden. Een Applet object kan vaak als Controller dienst doen en zelf wat Views aanmaken, die als attributen van de klasse beschikbaar zijn.

Misschien een wat beknopte verhandeling, maar waar ik naar toe wil is dit. Probeer klassen zoveel mogelijk onafhankelijk van elkaar te maken. Dit kan in jou geval door alle gegevens in een enkele klasse bij te houden. GUI elementen die gegevens wijzigen kunnen methoden op het object met de gegevens aanroepen om de gegevens te wijzigen. GUI elementen die afhankelijk zijn van bepaalde gegevens, kunnen door dit object aangeroepen worden, wanneer de gegevens veranderen.

Als je meer details nodig hebt (waar ik me iets bij kan voorstellen) dan kun je zoeken naar Document-View en Model-View-Controller (MVC) architecturen. Daar is vast het een en ander over te vinden.

[talpje]

zo ja khad geen zin om het helemaal uit te tekenen

[mpegernie]

talpje schreef op 02 november 2002 @ 23:07:
zo ja khad geen zin om het helemaal uit te tekenen

daar kan ik me iets bij voorstellen
maar ik moet zeggen dat jou practische voorbeeldje al erg veel zei. Het een en ander word me nu wel duidelijk. Ik zal het eens in praktijk brengen en kijken wat ik tegen kom. en ook Soultaker erg bedankt natuurlijk

[mpegernie]

ik moet nog zeggen dat ik leraren ook vaak een JApplet object helemaal naar beneden naar het model zie doorgeven. dit omdat het model bijvoorbeeld plaatjes moet laden:

code:

img = applet.getImage(new URL(applet.getCodeBase() + imagefile));

mag dat, is dat de enige mogelijkheid of is het gewoon lui?

[Soultaker]

mpegernie schreef op 02 november 2002 @ 23:16:
mag dat, is dat de enige mogelijkheid of is het gewoon lui?

Dat is een beetje gemakzuchtig, maar het mag wel en in niet al te complexe applicaties kan het weinig kwaad. Het is niet de enige mogelijkheid, je kunt ook gewoon 't singleton Toolkit* object opvragen en daar je plaatjes uit laden. Je hebt daar je Applet niet voor nodig, maar het is vaak praktisch om van de methoden die de Applet standaard heeft, gebruik te maken.

Zeker als je specifieke code (zoals foutafhandeling of iets dergelijks) wilt doen, kan ik me goed voorstellen dat je de code daarvoor op een enkele plaats wilt neerzetten.

*_{of hoe heet dat ding, ik programmeer nooit in Java}

[wasigh]

Soultaker schreef op 02 november 2002 @ 23:19:
[...]


*_{of hoe heet dat ding, ik programmeer nooit in Java}

dat ding heet idd Toolkit en kun je op de volgende manier benaderen:

Toolkit.getDefaultToolkit()