[OO] Algemeen probleem met medewerker en bedrijf

[Verwijderd]

Met het ontwerp van een applicatie loop ik tegen een klein probleem aan.

In mijn applicatie komen de volgende objecten voor: Medewerker en Bedrijf. Een medewerker werkt altijd bij een bedrijf en een bedrijf heeft een of meerdere medewerkers.

Voor beide objecten heb ik speciala data acces objects gemaakt met daarin de CRUD-methodes voor de specifieke objecten.

Mijn probleem is al volgt: hoe leg ik in de objecten een associatie tussen beide. Ik kan bijvoorbeeld in een bedrijfobject een array maken met daarin alle medewerkers, maar ik kan daar ook puur de medewerkerid's in stoppen. Sterker nog ik kan ook helemaal niets doen in dat object.

Hefzelfde geldt ongeveer voor de medewerker. Ik kan daarin een id zetten van het bedrijf, of het object, of ook helemaal niets.

Ik zou graag willen weten hoe jullie hiermee omgaan en hoezo jullie daarvoor kiezen.

[mulder]

Je bedrijf heeft een collectie van medewerkers?

[Janoz]

Ikzelf zou gewoon een lijst objecten gebruiken. Afhankelijk van de benodigde gegevens kun je in je data access layer beslissen hoe ver je de objecten vult. Je zou bijvoorbeeld bij het ophalen van een medewerker enkel de id's van de bedrijfs objecten kunnen vullen. Zorg in dat geval er trouwens wel voor dat je je equals methoden op orde hebt.

[JHS]

OO gezien wil je volgens mij een stuk liever naar de daadwerkelijke objecten verwijzen, aangezien je met alleen maar de id's best wel eens meerdere instanties kan krijgen waar je er maar één verwacht. Dan loop je straks, bij wijze van spreken, met 20 objecten van dezelfde medewerker rond met allemaal verschillende gegevens.

Ik zou voor de relatie bedrijf 1 -> * medewerker een MedewerkerCollection maken, aangezien je
daarmee ook andere collection voordelen kan gebruiken. In die collection bevinden zich dan de daadwerkelijke medewerker objecten, eventueel met lazy loading pas geïnstantieerd wanneer je ze nodig hebt

Vervolgens zou ik bij het aanmaken van een medewerker, al dan niet vanuit Bedrijf / MedewerkerCollection, inderdaad het object meegeven. Het lijkt me dat de medewerker op de hoogte moet (kunnen) zijn van het bedrijf het toe behoort.

Het moeilijke met het laatste is echter dat als je een nieuwe medewerker instantieerd zonder het bedrijf aan te spreken, en je later hetzelfde bedrijf met haar medewerkers gaat aanspreken, je zowel van de medewerker als het bedrijf twee instanties kan hebben.

Maar misschien is dat helemaal zo erg nog niet. De MedewerkerCollection lijkt me redelijk duidelijk de "juiste" oplossing, voor de medewerker 1 -> 1 bedrijf relatie weet ik het eerlijkgezegd niet zeker .

edit:

Wat ik ook bedoelde, en * Janoz beter zegt, het aanmaken van een object wil niet zeggen dat je hem helemaal moet vullen .

[ Voor 6% gewijzigd door JHS op 05-04-2006 11:34 ]

[Verwijderd]

JHS schreef op woensdag 05 april 2006 @ 11:33:
OO gezien wil je volgens mij een stuk liever naar de daadwerkelijke objecten verwijzen, aangezien je met alleen maar de id's best wel eens meerdere instanties kan krijgen waar je er maar één verwacht. Dan loop je straks, bij wijze van spreken, met 20 objecten van dezelfde medewerker rond met allemaal verschillende gegevens.

Ik zou voor de relatie bedrijf 1 -> * medewerker een MedewerkerCollection maken, aangezien je
daarmee ook andere collection voordelen kan gebruiken. In die collection bevinden zich dan de daadwerkelijke medewerker objecten, eventueel met lazy loading pas geïnstantieerd wanneer je ze nodig hebt

Vervolgens zou ik bij het aanmaken van een medewerker, al dan niet vanuit Bedrijf / MedewerkerCollection, inderdaad het object meegeven. Het lijkt me dat de medewerker op de hoogte moet (kunnen) zijn van het bedrijf het toe behoort.

Het moeilijke met het laatste is echter dat als je een nieuwe medewerker instantieerd zonder het bedrijf aan te spreken, en je later hetzelfde bedrijf met haar medewerkers gaat aanspreken, je zowel van de medewerker als het bedrijf twee instanties kan hebben.

Maar misschien is dat helemaal zo erg nog niet. De MedewerkerCollection lijkt me redelijk duidelijk de "juiste" oplossing, voor de medewerker 1 -> 1 bedrijf relatie weet ik het eerlijkgezegd niet zeker .

edit:

Wat ik ook bedoelde, en * Janoz beter zegt, het aanmaken van een object wil niet zeggen dat je hem helemaal moet vullen .

Befrijp ik je goed als ik zeg: het object bedrijf krijgt een collectie met daarin medewerkerobjecten en een object medewerker krijgt een object 'bedrijf'?

Dan kan je er voor kiezen wanneer deze in de collection voorkomt bedrijf niet geladen hoeft te zijn. Maar bekijk je een medewerker opzich dan laad je het bedrijfobject wel.

[Janoz]

Is het een 1:N of een N:M relatie? Kun je nu garanderen dat een medewerker maar bij 1 bedrijf hoort?

Zorg dat je dit erg goed boven tafel krijgt. Het grote probleem is dat je bij het programmeren rekening moet houden met de uitzonderlijke gevallen terwijl in normale mensen taal (wat over het algemeen wordt geuit door je opdrachtgevers) een kans van 0.1% op een voorkomen van iets compleet genegeerd wordt.

Een live voorbeeld wat ik niet lang geleden meegemaakt heb:

Medewerker heeft 1 manager die hem mag beoordelen. Alles klaar, applicatie in bedrijf, blijkt er toevallig toch 1 iemand te zijn die in 2 projectgroepen zit en dus twee managers heeft. Repliek opdrachtgever "Ja, maar dat komt bijna nooit voor!"... Let hier vooral op de bijna