[OO/Disc] objecten en hun verantwoordelijkheden

[4of9]

Hallo,

Ik loop steeds tegen het probleem aan tijdens het maken van classdiagrams dat ik vaak de verantwoordelijkheden van een object niet precies kan bepalen. Ik twijfel vaak welk object nu verantwoordlijk is voor bepaalde functionaliteit etc.

ik heb nu een ontwerpje gemaakt met bijvoorbeeld 3 classes:

(het betreft een webspider, in dit geval de classes die de robots.txt en de metatags (index en follow) gaan afhandelen.

1. RobotsTxtPolicy (bevat een lijst met dissallowed url's)
2. MetaRobotsPolicy (bevat de attributen (bool) follow en index)
3. RobotsPolicyHandler (haalt de policy values op en stored deze in de betreffende objecten)

Nu loop ik bij het RobotsTxtPolicy tegen het probleem aan:

Is dit object zelf verantwoordelijk voor het toevoegen/verwijderen van url aan de dissallowed list?
Moet dit object de Methodes bevatten om te checken of een url benaderd mag worden?

Of liggen deze verantwoordelijkheden bij de RobotsPolicyHandler?

Dit is maar 1 voorbeeld, maar ik heb dit probleem vaker. Hoe bepalen jullie verantwoordelijkheden?
Zijn er guidelines voor dit soort problemen?

Ik hoop dat jullie mij wat meer inzicht kunnen geven in dit soort ontwerp issues.

[kenneth]

Een van de guidelines hiervoor is GRASP.

[4of9]

tijdens het zoeken kwam ik GRASP idd al tegen.

Vaak zijn alleen de voorbeelden van classes (Auto, wielen, stuur etc. etc.) te simplitisch en niet bruikbaar om reallife ontwerpen van af te leiden.

Ik ben dan ook erg benieuwd van methodieken die mensen hier zelf toepassen.

[Alarmnummer]

Dit is maar 1 voorbeeld, maar ik heb dit probleem vaker. Hoe bepalen jullie verantwoordelijkheden?
Zijn er guidelines voor dit soort problemen?

Persoonlijk gebruik ik geen UML omdat het imho te ver van de reailiteit af ligt en ik het niet echt plezierig vind werken. Verantwoordelijkheden bepaal ik gedeeltelijk door kennis en ervaring (aangezien je al veel code hebt geschreven dan kun je daar voor een groot gedeelte van de gevallen je antwoord uit halen) en voor het gedeelte waarbij het niet meteen duidelijk is schrijf ik gewoon code en ga het daarna refactoren.

Ligt er trouwens wel een beetje aan op welke niveau je zit, zit je op de 'hoofd' interfaces van je systeem, ga je daar wel iets voorzichtiger mee om dan 'kleine' interfaces omdat de consequenties van veranderingen veel kleiner zijn. Verder begin ik mijn documentatie bij classes meestal ook met: deze class is verantwoordelijk voor ... Als daaruit blijkt dat hij al te veel verantwoordelijkheden heeft, dan is dit een goeie kandidaat voor refactoring.

Probeer dus niet alles in 1 keer goed op te zetten, maar laat je ontwerp door inzicht groeien. Ik ben trouwens wel een behoorlijke oo-freak, dus ik hou van een heel schoon en strak ontwerp.

En dat is typisch een aanpak die je zit binnen allerlei agile methodieken zoals RUP, XP. Trouwens zijn design pattern kennis ook onmisbaar bij het ontwerpen van goeie oo structuren.

[edit]
Tip:
de client van jouw code heeft meestal veel minder behoeftes aan functionaliteit dan specifieke implementaties. Ik zet interfaces dus daarom ook eerst op van client gebruik: hoe zou de client deze interface moeten aanroepen. De rest is dan een zorg van later (dat zijn dus ook typisch dingen die je ook niet terug zit binnen je basis interface).

[ Voor 21% gewijzigd door Alarmnummer op 21-08-2006 13:39 ]

[4of9]

Persoonlijk gebruik ik geen UML omdat het imho te ver van de reailiteit af ligt

Dit is waar ik ook tegenaan loop. "Volledig Ontwerpen" vs Globaal bedenken en via implementatie issues uit je product halen. Veel boeken/mensen/managers propageren het volledig ontwerpen en proberen alle risico's en issues waar men rekening mee moet houden, terwijl dat IMO onmogelijk lijkt en gewoon niet bij realworld situaties voorkomt. Bijna ieder OO ontwerp verzand in mijn ogen vaak in een discussie of het correct is.

voor het gedeelte waarbij het niet meteen duidelijk is schrijf ik gewoon code en ga het daarna refactoren.

Kost dit meer tijd dan als je eerst zou beginnen met een functioneel/technisch ontwerp via o.a UML waarin je probeerd zo volledig mogelijk te zijn?

Verder begin ik mijn documentatie bij classes meestal ook met: deze class is verantwoordelijk voor ... Als daaruit blijkt dat hij al te veel verantwoordelijkheden heeft, dan is dit een goeie kandidaat voor refactoring.

Daar ligt mijn probleem: hoe bepaal ik welke class waarvoor verantwoordelijk is?


En dat is typisch een aanpak die je zit binnen allerlei agile methodieken zoals RUP, XP. Trouwens zijn design pattern kennis ook onmisbaar bij het ontwerpen van goeie oo structuren.

Tip:
de client van jouw code heeft meestal veel minder behoeftes aan functionaliteit dan specifieke implementaties. Ik zet interfaces dus daarom ook eerst op van client gebruik: hoe zou de client deze
interface moeten aanroepen. De rest is dan een zorg van later (dat zijn dus ook typisch dingen die je ook niet terug zit binnen je basis interface).

Zou je dit eens kunnen verduidelijken? Wat is de client? Zijn interfaces zoals je ze hier beschrijft ook interfaces die in de OO wereld voorkomen?

[Alarmnummer]

4of9 schreef op maandag 21 augustus 2006 @ 14:21:
[...]


Dit is waar ik ook tegenaan loop. "Volledig Ontwerpen" vs Globaal bedenken en via implementatie issues uit je product halen. Veel boeken/mensen/managers propageren het volledig ontwerpen en proberen alle risico's en issues waar men rekening mee moet houden, terwijl dat IMO onmogelijk lijkt en gewoon niet bij realworld situaties voorkomt.

*kuch* waterval *kuch*

En waterval heeft zich in de praktijk al bewezen als waardeloos. Managers vinden het fijn omdat ze dan een prijs kunnen bepalen. Je ziet dat veel bedrijven steeds meer afstappen van waterval achtige aanpakken en meer overgaan op agile aanpakken. Bij mijn vorige werkgever (JTeam) was het helemaal agile/xp en bij mijn nieuwe werkgever (xebia) is het ook een en al agile. En dit zijn clubs die helemaal voorop de techniek zitten.

Bijna ieder OO ontwerp verzand in mijn ogen vaak in een discussie of het correct is.

Correct hangt vaak van een context af, en die heb je pas goed duidelijk als je er echt mee bezig bent.

Kost dit meer tijd dan als je eerst zou beginnen met een functioneel/technisch ontwerp via o.a UML waarin je probeerd zo volledig mogelijk te zijn?

Ligt eraan. Ik doe soms wel wat up front design (de grote lijnen), maar meestal niet veel. Vaak zie je dat je als je bezig bent toch wijzigingen moet doorvoeren omdat je achter issues komt, of omdat de requirements veranderen (of op dat moment pas duidelijker worden). Het zorgt er dus voor dat ik erg Agile ben, terwijl mijn code/tests/documentatie van hoogwaardige kwaliteit zijn. Voordeel verder is ook dat je niet zo bang hoeft te zijn om een misstap te maken aangezien je die meestal vrij gemakkelijk kunt refactoren (refactoren moet dan wel een onderdeel zijn van je dagelijkse manier van werken, en de voorwaarde voor refactoren is het maken van tests). Dus agile methodiek vereist testen en refactoring.

Daar ligt mijn probleem: hoe bepaal ik welke class waarvoor verantwoordelijk is?

Tja... lastige vraag.. ik denk niet dat ik je daar echt een bruikbaar antwoord op kan geven. Door ervaring/lezen (oa design patterns) en schande zul je leren. Verder zijn er veel bruikbare oo modellen voor een bepaald probleem mogelijk, dus er is niet altijd een 'dit is de beste'. Iemand zal een bepaalde oplossing het beste vinden binnen zijn visie op de context en zijn niveau van kennis en ervaring.. Je ziet dat er dus wel een aantal extreem belangrijke variabelen zitten in een functie voor 'beste ontwerp'. Maak er eens van 'goed genoeg' (en dan niet de kantjes er van aflopen uiteraard).

En maak gewoon eerst een implementatie als je geen idee hebt. Ruik aan de code en als je iets gek vind ruiken, refactor het (dit moet je doen). Het gevolg is dat je een beter zicht hebt hoe de class gebruikt moet gaan worden en dat je praktische en continue feedback hebt waardoor je model bij kunt schaven.

Zou je dit eens kunnen verduidelijken? Wat is de client? Zijn interfaces zoals je ze hier beschrijft ook interfaces die in de OO wereld voorkomen?

De client is degene die een implementatie van een bepaade interface gebruikt.

[ Voor 18% gewijzigd door Alarmnummer op 21-08-2006 15:24 ]

[4of9]

*stukje offtopic*

Ik doe nog een Deeltijd studie informatica (HBO) en daar krijgen gek genoeg als eerste ontwikkelmethode de waterval methode (SDM). Ongeveer iedereen die ik nu spreek is het er over eens dat dit iig niet de manier is van ontwikkelen.

Bij mijn vorige werkgever probeerden we een RUP like methode te gebruiken. RUP in de zin van: We weten wat RUP is dus doe het maar ongeveer zo.

Nu gaan we SCRUM (http://scrumforteamsystem.com/) gebruiken bij mijn huidige werkgever. Een verfrissende methode in mijn ogen. Dit is een methode die ook minder gebruik maakt van functioneel en technische ontwerpen en meer idd uitgaat van hapklare brokken die men ontwikkeld. En al gaande weg men het ontwerp laat evolueren tot een beter product.

Ik denk dat een functioneel ontwerp voornamelijk handig is voor klanten, en nieuwe collega's. Hoewel dit vaak als vloeken in de kerk wordt beschouwd.

*/offtopic*

Gek genoeg moet ik wel de verantwoordelijkheden bepalen als ik een classontwerp (in mijn hoofd, al codende of via UML) en dat vind ik echt enorm moeilijk.

De classes die ik opnoem in de startpost, hoe liggen bijvoorbeeld daar de verantwoordelijkheden?
is mijn RobotsTxtPolicy verantwoordelijk voor het updaten van de disallowedlist of moet deze een interface aanbieden om een item aan de arraylist toe te voegen. Of moet mijn policyHandler een ArrayList aanmaken die in de RobotsTxtPolicy stoppen, zodat deze puur een "data object" is.

Ik merk dat ik welk ontwerp ik maak, een (verkeerde) manier van OO denken heb (denk ik) en ik nog niet echt een duidelijk voorbeeld ben tegengekomen waardoor ik het licht zie.

[ Voor 4% gewijzigd door 4of9 op 21-08-2006 15:24 ]

[Alarmnummer]

4of9 schreef op maandag 21 augustus 2006 @ 15:23:
*stukje offtopic*
Dit is een methode die ook minder gebruik maakt van functioneel en technische ontwerpen en meer idd uitgaat van hapklare brokken die men ontwikkeld. En al gaande weg men het ontwerp laat evolueren tot een beter product.

Precies. De praktijk ervaring/kennis/inzicht continu gebruiken om je ontwerp aan te sturen.

Ik denk dat een functioneel ontwerp voornamelijk handig is voor klanten, en nieuwe collega's. Hoewel dit vaak als vloeken in de kerk wordt beschouwd.

Functioneel ontwerp in grote lijnen is op zich wel handig omdat je daarin alleen de functionele (en niet functionele) eisen van een systeem gaat vast leggen. Maar het zegt niets over de technische inrichting.

Gek genoeg moet ik wel de verantwoordelijkheden bepalen als ik een classontwerp (in mijn hoofd, al codende of via UML) en dat vind ik echt enorm moeilijk.

Gewoon iets neerzetten ook al is het kut. Ga er aan ruiken.. ruikt het naar oude vis dan is er iets mis. Soms ruik je wel iets vreemds maar weet je niet of het zweetvoeten of rotte vis is, maar het feit dat je het onderscheid kunt maken of het een lekkere geur is of niet, is al een hele grote stap voorwaards.

De classes die ik opnoem in de startpost, hoe liggen bijvoorbeeld daar de verantwoordelijkheden?
is mijn RobotsTxtPolicy verantwoordelijk voor het updaten van de disallowedlist of moet deze een interface aanbieden om een item aan de arraylist toe te voegen. Of moet mijn policyHandler een ArrayList aanmaken die in de RobotsTxtPolicy stoppen, zodat deze puur een "data object" is.

Welke call zou jij vanuit de client willen doen? In hoeverre ben jij daar geinteresseerd in policies en handlers?

Zal het niets iets zijn van:

List usableUrls = urlFilter.filter(foundUrls);

Het zal de caller (de client) niets uitmaken hoe de urlFilter zijn werk gaat doen. Zadel een client dus niet op met implementatie specifieke functionaliteit.

Ik merk dat ik welk ontwerp ik maak, een (verkeerde) manier van OO denken heb (denk ik) en ik nog niet echt een duidelijk voorbeeld ben tegengekomen waardoor ik het licht zie.

Komt vanzelf.. gewoon proberen, veel lezen en dan zie je vanzelf steeds beter het licht.

[edit]
Het type klussen waar ik de laatste tijd op heb gezeten was ook niet echt fixed price. Dus in grote lijnen wordt een prijs afgegeven, maar het kan zijn dat we erover gaan. We leveren wel software op waar de klant het meeste aan heeft (vooral omdat hij ook nog wijzigingen kan doorvoeren als hij/wij nieuwe inzichten op doet). Maar dat moet dan wel in goed overleg met de klant.

[ Voor 7% gewijzigd door Alarmnummer op 21-08-2006 16:18 ]

[staefke]

Voor een goed voorbeeld om het felle licht te zien zou ik je "Agile Software Development - Principles, Patterns en Practices" van Robert Martin willen aanraden (ook op zijn site www.objectmentor.com staat het nodige aan info). Dit is een van de weinige boeken waarin de evolutie van een ontwerp behandeld wordt, d.w.z. de reeds door Alarmnummer genoemde "Smells" en verschillende design principles worden telkens tegen een op dat moment OK lijkend ontwerp gehouden, waarna dat zelfde ontwerp telkens weer overhoop gehaald wordt.

[4of9]

Ik geloof wel in evolutie van software. Hoewel ik Agile(wat ik er tot nu toe van weet) ook niet het ei van columbus vind. Ik ben erg benieuwd naar de scrum methode die wij in de zeer nabije toekomst gaan toepassen.

Welke methode ook toegepast wordt, ik heb gewoon moeite om de verantwoordelijkheden per object te bepalen, terwijl ik de theorie wel snap. De voorbeelden die alleen gebruikt worden in boeken etc. zijn vaak zo simplistish, dat ze echt niet toe te passen zijn op de problemen die ik tegen kom.

Ik ken ook design patterns nog niet goed genoeg om te kunnen bepalen wanneer ik ze toe moet/kan passen.

Ik ben op het moment 3 boeken aan het lezen: Refactoring van Martin fowler. Design patterns (nederlandse editie), en Code complete. Daar staat opzich een hoop in. Ik hoop dat ik er wat wijzer van ga worden. Hoewel voor mijn gevoel theorie en praktijk ver uit elkaar liggen.

[Alarmnummer]

4of9 schreef op vrijdag 25 augustus 2006 @ 08:36:
Ik geloof wel in evolutie van software. Hoewel ik Agile(wat ik er tot nu toe van weet) ook niet het ei van columbus vind. Ik ben erg benieuwd naar de scrum methode die wij in de zeer nabije toekomst gaan toepassen.

Welke methode ook toegepast wordt, ik heb gewoon moeite om de verantwoordelijkheden per object te bepalen, terwijl ik de theorie wel snap. De voorbeelden die alleen gebruikt worden in boeken etc. zijn vaak zo simplistish, dat ze echt niet toe te passen zijn op de problemen die ik tegen kom.

Ik ken ook design patterns nog niet goed genoeg om te kunnen bepalen wanneer ik ze toe moet/kan passen.

Ik denk dat je voor een goeie agile aanpak ook een sterk team moet hebben dat sowieso goed thuis is in oo.