[alg] Delegating of chaining?

[Michali]

Ik zit een beetje te klooien met een paar classes. Nu heb ik een user class welke altijd gekoppeld is aan een account class welke weer een adresboek waarin groepen met personen zitten. Nu zit ik te twijfelen wat ik moet doen. Is het nou beter om een chain van methods te maken voor bijvoorbeeld het toevoegen van een persoon aan een groep in het adresboek, of zal ik direct in de user class een functie zetten welke delegate naar het account object enz. totdat de call bij de groep aankomt.

Dus of chaining:

code:

oUser->getAccount()->getAddressBook()->getGroup(groupName)->addPerson(oPerson);

of delegating:

code:

oUser->addPersonToGroupInAddressBook(groupName, oPerson);

Nu is de tweede natuurlijk veel netter ook vanwege het verbergen van de implementatie etc. Maar stel dat user nu een stuk of 5 objecten aggregeerd met elk 5 methods die beschikbaar moeten zijn via de user, dan zit je dus met 25 methods die alleen maar een call doorsturen. Moet ik me hier nu gewoon niets van aan trekken en gewoon delegaten of is een chain hier en daar niet zo'n probleem? Waar moet ik een beetje op letten om te zorgen dat ik geen zwakke delen in mijn code krijg?

[Verwijderd]

uhm, waarom niet user->addPerson( GroupObject, PersonObject )

aan de invulling daarvan zou iemand kunnen zien dat het gaan om een person die aan een group binnen iemand zijn adresbook word gehad?

[kvdveer]

Ik stem voor chaining, vooral omdat het flexibeler is. Wat je al zei, je krijgt wel erg veel methods als je alles wilt delegaten. Bovendien komen die extreem lange namen de leesbaarheid niet ten goede.

Als een bepaalde actie erg vaak voorkomt kun je er eventueel een "shortcut" voor maken. Dan kun je later eventueel beslissen om het te optimaliseren, door bijvoorbeeld een reference naar het adresboek achter de hand te houden. (in dit geval is dat trouwens geen grote optimalisatie, 4 bytes extra geheugen per user tegen vier machine-instructies minder per call).

[Michali]

Verwijderd schreef op zondag 19 december 2004 @ 16:27:
uhm, waarom niet user->addPerson( GroupObject, PersonObject )

Dan kun je toch veel beter gelijk GroupObject->addPerson(PersonObject) doen Je moet voor de actie die je geeft natuurlijk wel eerst het groupobject hebben. Je vergeet er wel bij te vertellen hoe je daar aan bent gekomen.

aan de invulling daarvan zou iemand kunnen zien dat het gaan om een person die aan een group binnen iemand zijn adresbook word gehad?

Hmm, ik snap je zin niet helemaal

[kvdveer]

Verwijderd schreef op zondag 19 december 2004 @ 16:27:
uhm, waarom niet user->addPerson( GroupObject, PersonObject )

aan de invulling daarvan zou iemand kunnen zien dat het gaan om een person die aan een group binnen iemand zijn adresbook word gehad?

Ik vermoed dat het dan in ieder geval zoiets wordt als:

C++:

oUser->getAddressbook()->addPerson( sGroupname, oPerson )

Het lijkt me namelijk dat je alle adresboekfunctionaliteit in adresboek klasse wilt houden.
Waar haal jij trouwens GroupObject vandaan? Toch niet met iets als

C++:

oUser->getAddressbook()->getGroup(sGroupName);

Als je dat doet ben je netto niets opgeschoten.

[ Voor 6% gewijzigd door kvdveer op 19-12-2004 16:34 . Reden: Alles helemaal in camel-style.. ]

[Michali]

kvdveer schreef op zondag 19 december 2004 @ 16:29:
Ik stem voor chaining, vooral omdat het flexibeler is. Wat je al zei, je krijgt wel erg veel methods als je alles wilt delegaten. Bovendien komen die extreem lange namen de leesbaarheid niet ten goede.

Ik vind chaining imo ook niet echt de leesbaarheid ten goede komen. Verder maak ik ook wel goed gebruik van caps zodat het zo leesbaar mogelijk blijft.

[muba]

Ik ga voor chaining, dan. Als dat de manier is waarop de methods op je classes staan, is dat gewoon wat je moet aanhouden.

Shortcuts, zoals al genoemd werd, is wel een optie IMO

[Michali]

MUBA schreef op zondag 19 december 2004 @ 16:45:
Ik ga voor chaining, dan. Als dat de manier is waarop de methods op je classes staan, is dat gewoon wat je moet aanhouden.

Dit is gewoon als voorbeeld. Als het niet nodig is om het hele object op te halen, dan voeg ik zo'n method niet gelijk toe.

Shortcuts, zoals al genoemd werd, is wel een optie IMO

Is delegating niet gewoon een shortcut? In princiepe zou je niet moeten of willen weten wat er nou eigelijk gebeurt zo'n shortcut. Of er nou wordt gedelegate of wat dan ook, het maakt toch niet uit voor de client.

[ Voor 4% gewijzigd door Michali op 19-12-2004 16:52 ]

[Alarmnummer]

Het probleem aan chaining is dat je classes last krijgen van Tight Coupling

Dus soms... (ik weet niet of dat in jouw specifieke situatie) is het beter om te vermijden dat je objectstructuren te veel aan elkaar gaat linken. Je krijgt dan een enorm monolytisch stuk code.

Maar nogmaals.. ik weet niet of dat in jouw geval ook problemen oplevert. Sommige code hoeft niet resuable te zijn.. (vooral domein modellen zijn toch helemaal specifiek gemaakt voor 1 app dus een tight coupling lijkt me geen probleem)

[ Voor 7% gewijzigd door Alarmnummer op 19-12-2004 16:59 ]

[Michali]

Dit is inderdaad een stukje domein model en ik denk dat chaining eigenlijk niet te veel problemen moet opleveren. En de functies worden in dit geval toch maar in een stukje code aangeroepen, dus ik denk dat ik het toch bij chaining houd.