[OODesign] Probleem loose coupling

[Verwijderd]

Ik heb een probleem, namelijk: ik heb 2 classes, genaamd PendingJobList en JobQueue. PendingJobList bestaat uit Jobs die nog _niet_ gestart zijn. JobQueue bestaat uit Jobs die wel gestart zijn en voert ze uit.

Beide hebben dus een associatie met de class Job. Is er een manier om dit uit elkaar te halen, want volgens mij is dit een beetje een 'bad smell'.

Het gaat om een systeem wat bepaalde fragmentjes afspeeld in bepaalde volgorde. Je geeft op welk fragment afgespeeld moet worden en voegt het toe aan de PendingList. Het fragmentje krijgt tevens wat metadata mee. Daarna kan gekozen worden uit de "speellijst" welk fragmentje 'geprocessed' moet worden. Hierdoor wordt de Job (ook wel fragment met metadata) in de JobQueue gezet, welke afgehandeld wordt door een player, die alle items in volgorde stuk voor stuk afspeelt uit de queue.

[Alarmnummer]

Verwijderd schreef op zaterdag 12 maart 2005 @ 15:40:
Ik heb een probleem, namelijk: ik heb 2 classes, genaamd PendingJobList en JobQueue. PendingJobList bestaat uit Jobs die nog _niet_ gestart zijn. JobQueue bestaat uit Jobs die wel gestart zijn en voert ze uit.

Beide hebben dus een associatie met de class Job. Is er een manier om dit uit elkaar te halen, want volgens mij is dit een beetje een 'bad smell'.

Waarom zou dit een bad smell zijn? Ze zijn ten 1e niet aan elkaar gerelateerd.. dus PendingJobList kan onafhankelijk van JobQueue bestaan. En verder.. dit zou zelfs nog niet eens erg zijn aangezien ze samen wel voor een stuk functionaliteit zorgen waarbij ze wel van elkaar afhankelijk zijn. En verder.. gaan deze componenten ooit nog buiten deze context ingezet worden? Waarschijnlijk niet aangezien ze redelijk specifiek zijn...

Het gaat om een systeem wat bepaalde fragmentjes afspeeld in bepaalde volgorde. Je geeft op welk fragment afgespeeld moet worden en voegt het toe aan de PendingList. Het fragmentje krijgt tevens wat metadata mee. Daarna kan gekozen worden uit de "speellijst" welk fragmentje 'geprocessed' moet worden. Hierdoor wordt de Job (ook wel fragment met metadata) in de JobQueue gezet, welke afgehandeld wordt door een player, die alle items in volgorde stuk voor stuk afspeelt uit de queue.

Ik zou er voor kiezen om deze overkoepende functionaliteit eerst een te gaan modeleren... die PendingList en die JobQueue zijn dan componenten binnen dit object... aan de buitenkant kan het maar zo zijn dat je niet meer ziet wat onder de kap van dit overkoepelende object zit. Hierdoor heeft de rest van je systeem al helemaal geen weet meer van een PendingJobList en een JobQueue.... ze zien alleen de JobService (om maar ff een brakke naam te bedenken) Misschien kan je trouwens die hele queues/list eruit kicken en vervangen door stuf dat al standaard in Java zit. Check de 1.5 concurrency library van Doug Lea... zitten prachtige implementaties bij van Queues icm thread/threadpooling.

[ Voor 20% gewijzigd door Alarmnummer op 12-03-2005 17:06 ]

[Verwijderd]

hangt er vanaf, als je Queue en List functionaliteit hebben die in Job thuishoort dan wel,
maar als je Queue en List alleen maar weten hoe ze een job moeten maken/configureren/uitvoeren dan weer niet.
hangt ervanaf wat de associtatie inhoudt,
erven ze van Job?

[Alarmnummer]

Verwijderd schreef op zondag 13 maart 2005 @ 02:53:
erven ze van Job?

Dat zou wel een heel vreemd ontwerp zijn... tenminste met de informatie die ik nu heb.

[Alarmnummer]

En ben je er al uit?

[EfBe]

Verwijderd schreef op zaterdag 12 maart 2005 @ 15:40:
Ik heb een probleem, namelijk: ik heb 2 classes, genaamd PendingJobList en JobQueue. PendingJobList bestaat uit Jobs die nog _niet_ gestart zijn. JobQueue bestaat uit Jobs die wel gestart zijn en voert ze uit.

Dat is wat vreemd, een queue die ze ook uitvoert. IMHO heb je:
- lijst met jobs om uit te kiezen (jouw PendingJobList, rare naam eigenlijk, maar vooruit )
- lijst met jobs die gekozen zijn en wachten op execution (jouw jobqueue)
- active lijst van jobs die nu worden uitgevoerd.

Waarschijnlijk heb je een fixed aantal job slots die kunnen worden uitgevoerd in parallel, dus wanneer er een job klaar is in een slot, gaat de job processor de eerste in de queue eruit halen en starten in dat slot, correct?

Dus hoort de jobqueue bij de processor en de lijst met jobs om uit te kiezen niet.

Beide hebben dus een associatie met de class Job. Is er een manier om dit uit elkaar te halen, want volgens mij is dit een beetje een 'bad smell'.

Het gaat om een systeem wat bepaalde fragmentjes afspeeld in bepaalde volgorde. Je geeft op welk fragment afgespeeld moet worden en voegt het toe aan de PendingList. Het fragmentje krijgt tevens wat metadata mee. Daarna kan gekozen worden uit de "speellijst" welk fragmentje 'geprocessed' moet worden. Hierdoor wordt de Job (ook wel fragment met metadata) in de JobQueue gezet, welke afgehandeld wordt door een player, die alle items in volgorde stuk voor stuk afspeelt uit de queue.

Beetje onduidelijk, je moet dus 2 keer kiezen? Dus een grote bak met allerlei fragments, dan een keuzelijst met fragments (list A) en dan een keuzelijst in de juiste volgorde (lijst B ) met dezelfde fragments?

Overigens kun je je lijst en queue gewoon met standaard classes bouwen, ik weet niet in welke taal je werkt, in .NET gebruik je dan een ArrayList en een Queue class. In je job processor cast je dan. Je kunt ook een typed versie ervan maken, scheelt je wat casts, kost wel extra werk.

[Verwijderd]

Alarmnummer schreef op zondag 13 maart 2005 @ 08:21:
[...]
Dat zou wel een heel vreemd ontwerp zijn... tenminste met de informatie die ik nu heb.

Helaas heeft de TSer niet erbij vermeldt wat de associatie precies inhoudt, maar als ze erven, heeft ie wel gelijk dat er een "bad smell" is, vandaar m'n vraag