[ALG] Composition - Inheritance - of 1 simpele klasse?

[Verwijderd]

Ik worstel nu al een tijdje met de volgende situatie:

Ons systeem kent "Items" deze items hebben een id, name, state, omschrijving, enz enz maar ook een "gepland gedeelte" (startDate, deadLine).

Idee:

Een planner maakt "plannedItems" aan die een name, state, startDate en deadLine hebben.
Nadat een gepland item is gemaakt kan een andere gebruiker deze geplande items aanvullen met 'concrete' informatie en verandert ons gepland item in een (concreet) item.

Echter een gebruiker kan een item aanmaken zonder dat er ooit geplande informatie bij aanwezig is.

Hoe los je nu zo iets technisch op?

Je kan alle informatie in 1 klasse "Item" laten en waarbij bepaalde velden nooit zullen gebruikt worden. Als de gebruiker een gewoon item maakt, zullen de voorziene velden voor een planned item leeg zijn.

Dit is de meest eenvoudige oplossing

Composition - 2 klassen Item en PlannedItem

Een item kent een plannedItem. Op het moment van het aanmaken van een item er de referentie naar een plannedItem leeg en zal nooit aangevuld worden.

Als de gebruiker echter een plannedItem wil aanmaken, moet er ook een item aangemaakt worden, want de algemene informatie zoals de naam, state, omschrijving over dit item horen thuis in het item en niet het plannedItem.

Dus het plannedItem kent een referentie naar het Item waar het bijhoort. Of is het nu omgekeerd? Je maakt een plannedItem aan, je geeft de informatie door naar het item + referentie. Het item kent het plannedItem maar niet omgekeerd? Wie moet nu wie kennen?


Waarom composition?

Het item heeft een plannedItem(gedeelte). Dus een item bestaat uit zijn velden en het eventuele bijhorende plannedItem. Has-a relationship geldt hier

Inheritance - PlannedItem extends Item

Een plannedItem is een soort van item, en extends dus een item. De planner maakt een plannedItem aan, de algemene intem informatie wordt naar de superklasse doorgespeeld, de planned informatie blijft in het plannedItem.

Als de gebruiker een gewoon item aanmaakt kan dit, zolang Item geen abstracte klasse is.

Waarom Inheritance?

De relatie Is-a geldt hier. Een plannedItem is een soort van Item.

Ik had een tijdje de indruk dat compositie de way to go was, maar daar ben ik hoe langer hoe minder zeker van. Zeker omdat dit geen relatie is zoals "een auto heeft een motor" maar het gevoel "een planneditem is een item"

Iemand die een klare kijk heeft op deze situatie?
Oh ja, al deze info moet met hibernate geannoteerd worden dus het kan nog complex worden


Alle input wordt zeer gewaardeerd.

[Nick The Heazk]

Zoals ik het op het eerste zicht kan zien, heb je dus gemeenschappelijke kenmerken geïdentificeerd dewelke horen bij zowel Item als PlannedItem.

Het is dan ook logisch om in een eerste stap te vertrekken van een ontwerp waarbij je een abstracte klasse AbstractItem hebt, waarvan Item en PlannedItem dan erven. Echter, hierdoor zal de Item klasse gewoon leeg zijn. Je kan dus de abstracte klasse verwijderen en gewoon een klasse Item hebben met de gemeenschappelijke kenmerken in. Vervolgens laat je PlannedItem dan erven van Item.

Zulk een ontwerp is in zekere gevallen aanvaardbaar. Maar wat als je alsnog een Item wilt laten plannen? Bestaat er een realistische kans dat dit ook effectief vereist zal zijn? Indien het antwoord op de laatste twee vragen ja is, dan kan je beter niet met overerving werken, daar object migratie niet wordt ondersteund door de huidige OO programmeertalen.

Het alternatief bestaat eruit om een klasse Item te voorzien, dewelke een referentie heeft naar een Plan object. Deze laatste bevat alle informatie omtrent de planning. Een item zonder planning heeft dan gewoon een null-referentie (of eventueel een null-object). Zulk een ontwerp is flexibeler in die zin, dat je aan een gewoon Item alsnog een planning kunt hangen. Verder is het eenvoudig om meerdere plannen te hebben per item (misschien zijn er verschillende planners in de toekomst, elk met hun eigen plan).

De object compositie aanpak die je voorstelt in je OP is ook een mogelijkheid. Persoonlijk ben ik minder voor zulk een aanpak te vinden, omdat je daarin het gebruik van een Plan niet expliciteert. Je geeft gewoon aan dat er ook zoiets is als een PlannedItem. De eerstvolgende ontwerper/programmeur zal zich meteen afvragen waarom PlannedItem dan geen subklasse is van Item.

[ Voor 11% gewijzigd door Nick The Heazk op 20-03-2008 11:54 ]

[Verwijderd]

Dank voor de bijdrage.

Na even nadenken ga ik toch alles opnemen in 1 klasse. De reden is dat code deel uitmaakt van een portal en tijdelijk informatie opslaat. Hierna wordt de informatie doorgegeven aan verschillende business processen waar de informatie anders gestructureerd zal worden.

Door alles in 1 klasse te steken heb ik meer opties open om de informatie op de goede manier aan de rest van het process door te geven.