[JAVA] werken met een object tss verschillende klassen

[Verwijderd]

Hoi

Ik heb een formulier klanten waarin ik de gegevens van klanten mee beheer. In dat formulier heb ik een knop "kies gemeente" die het formulier frmKiesGemeente oproept. In dat formulier kan ik mbv comboboxen een gemeente kiezen. Nu moet ik het gemeente-id wat ik daar genereer terug sturen naar mijn frmKlanten.

Probleem is dat dat natuurlijk verschillende klassen zijn en ik niet zomaar aan de variabelen van de klassen kan.

Wat ik al geprobeerd heb:

op het moment als ik op "kies gemeente" maak ik een nieuw object v/d klasse Gemeente ( gemeenteId, gemeenteNaam, gemeentePostcode). Dit object ga ik bmee door te sturen naar frmKiesGemeente. In frmKiesGemeente vul ik dat gemeente bject.
Nu moet ik proberen dat gemeente object terug te sturen naar frmKlanten.
Als ik dan vanuit de code van fmKlanten het gemeente-object inlezen dan kent ie dat object natuurlijk niet.

Hoe kan ik dit oplossen?

Alvast bedankt!

[Voutloos]

Je vraagstelling is niet superduidelijk (de relevante code kan er best bij).

Volgens mij bedoel je dat je een fout krijgt als je dat object opvangt. In dat geval moet je die return methode zo specificeren dat hij een Object returnt, die vangen en dan eerst met Object.instanceOf (zoiets, staat in API) kijken of het een gemeente-object is.

[Stephan Oudmaijer]

beetje dezelfde vraag als: Ik moet dit en dit maken, wie kan het voor me oplossen....

Kom eens met een specifieke vraag, geef code voorbeelden, dit is te vaag...

[Robtimus]

The Reflection API, onderdeel van The Java Tutorial. Staan ook voorbeelden bij.

[whoami]

Als je je Gemeente-form modaal toont, en een public property 'selectedGemeente' oid maakt op die form, kan je die waarde toch uitlezen?

Ik doe geen java, maar dan zou je het ongeveer zo moeten doen:

code:

if( frmGemeente.ShowModal() == ModalResult.OK )
{
     aGemeente = frmGemeente.selectedGemeente;
}

[Verwijderd]

Ik lost dat probleem op door gebruik te maken van events. In die SelecteerFrame of wat ie ook heet ben je namelijk aan het werken naar een GemeenteSelectedEvent.
Bij het aanmaken van de frame schrijf je dus best de aanroepende klasse of tenminste een klasse die weet wat hij moet doen met zo'n gevonden gemeente in als GemeenteSelectedListener. Dan zodra de SelecteerFrame op het punt gekomen is dat er een gemeente geselecteerd is gooi je de GemeenteSelectedEvent die je dan in je oorspronkelijk klasse opvangt aangezien je deze ingeschreven had.

Je hebt dus een interface GemeenteSelectedListener nodig (misschien kan je het ook met bestaande listeners doen zoals ActionListeners... kijk eens in de java API).
Waarschijnlijk kan je ook wel een GemeenteSelectedEvent gebruiken.

Je formulier implementeerd dan de GemeenteSelectedListener en zal wanneer dat event aangeroepen wordt gewoon de gekozen gemeente instellen. Deze kan ie uit GemeenteSelectedEvent halen.

Je frame om de gemeente selecteren moet dan enkel nog methodes hebben om GemeenteSelectedListeners in te schrijven en te verwijderen (met een Collection) en de nodige methodes om de events te gooien. Iets als fireGemeenteSelected()

[Feyd-Rautha]

Het is al een hele tijd geleden dat ik nog eens iets in Java gemaakt heb, maar is de volgende methode ook geen oplossing?

Uw scherm om de gemeente te kiezen kun je toch als een Popup-scherm beschouwen (modal).
Wanneer je je Popup-scherm dan aanmaakt, kun je in de constructor ervan meegeven wat de parent van dit popup-scherm moet zijn. Hier geeft je dan mee dat dat "frmKlanten" is.

Volgens mij (maar ik weet het nu niet zeker) kun je dan toch vanuit uw classe "frmKiesGemeente" de componenten van het parent-form zien ?

Dus wanneer je je op OK geklikt hebt in frmKiesGemeente, kun je gewoon iets doen in de aard van:

code:

((frmKlanten)owner).cboGemeente.setSelectedItem = geselecteerdeItemUitDeCombobox

ps: dit is toch de manier die ik in de school gezien heb. Er kunnen ook betere/mooiere manieren zijn om dit op te lossen ....

[whoami]

Feyd-Rautha schreef op 29 januari 2004 @ 13:11:

code:

((frmKlanten)owner).cboGemeente.setSelectedItem = geselecteerdeItemUitDeCombobox

ps: dit is toch de manier die ik in de school gezien heb. Er kunnen ook betere/mooiere manieren zijn om dit op te lossen ....

Ik vind dit geen mooie oplossing; op die manier zorg je nl. voor een 'vastgekoppeld' gemeente-scherm. Je klantenscherm is hier nu nl. aan gekoppeld, door die cast naar frmKlanten.
Wat ga je nu doen als je dat gemeentenform ook wilt gebruiken op bv. een 'Leveranciersscherm'?
Met deze oplossing weet je gemeentenscherm iets af van z'n owner, en dat is iets wat je imo beter vermijd.

De logica om de geselecteerde gemeente te tonen op je 'owner' form (in dit geval frmKlanten), hoort niet thuis op het gemeente-scherm, maar op het klantenscherm.
Je kan dit verwezenlijken door de manier die ik uitgelegd heb in m'n eerdere post. Nog een andere manier om zoiets op te lossen, is door te werken met functie-pointers/delegates. Ik weet echter niet hoe ver dat in Java mogelijk is. (klik voor een voorbeeld in .NET (C#)).

[Verwijderd]

Probleem dat jouw oplossing al gelijk public attributes vereist wat ik voor zoiets toch ook niet zo praktisch vindt. Ik denk nog steeds dat listeners en events het beset zullen werken. Dat komt trouwens het meeste overeen met de hele overige structuur van communicatie tussen klassen in Swing.

[whoami]

Verwijderd schreef op 29 januari 2004 @ 18:35:
Probleem dat jouw oplossing al gelijk public attributes vereist

Je kan het ook met properties of getters doen.

wat ik voor zoiets toch ook niet zo praktisch vindt. Ik denk nog steeds dat listeners en events het beset zullen werken. Dat komt trouwens het meeste overeen met de hele overige structuur van communicatie tussen klassen in Swing.

Dan heb je zoiets als m"n .NET voorbeeld in m'n bovenstaande post?

[drm]

Volgens mij moet je in dit geval niet zozeer denken aan gemeentes of klanten maar aan wat dat dan precies voor gegevens zijn en hoe je die zou kunnen abstraheren. Als je dan bepaald hebt wat die soort gegevens zijn en wat voor functionaliteit ze moeten kunnen ondersteunen, kun je aan de gang gaan met interfaces voorschrijven voor dat soort gegevens. Vervolgens weet je van elke klasse die die interface implementeert dat die ook een bepaalde functionaliteit ondersteunt.

Ik heb nu even geen zin daar een heel verhaal over te schrijven, maar ik heb het idee dat je iets abstracter moet denken om de functionaliteit te kunnen beschrijven voordat je er daadwerkelijk inhoudelijke gegevens aan verbindt. Die abstractieslag maakt het namelijk ook veel eenvoudiger om aan dezelfde principes toe te passen op andersoortige gegevens.