Anemic Domain Model

[Verwijderd]

Ik werd hierop gewezen in de huiskamer, door Kenneth.

Stel ik heb een klasse die verantwoordelijk is voor het vullen van een Dropdown.
Deze dropdown moet gevuld worden aan de hand van een parameter.
Om deze parameter te vullen subclass ik de klasse die normaal gesproken verantwoordelijk is voor het vullen van deze dropdown en geef ik de parameter door middels een property.

Kenneth wees me erop dat dit duidt op een anemic domain model en strikt genomen heeft hij volgens de definitie van Fowler natuurlijk ook gelijk [ALS ik Fowler goed heb begrepen]. De subclasses zijn verworden in containers met een property, verder niets.

Deze manier van werken is hier heel normaal en ik zie het bezwaar niet zo, je hebt je 'hoofdfunctionaliteit' mooi herbruikbaar gemaakt op deze manier en je hebt 'encapsulate what varies' ook toegepast.

Kunnen jullie dit wellicht wat beter toelichten?

[EfBe]

Dit heeft niet veel met een anemic domain model te maken volgens mij. Een anemic domain model gaat over de situatie waarbij behavior voor bv een Customer class in een CustomerManager class geplaatst wordt, ipv in de Customer class, waardoor de Customer class meer een data-container wordt zonder behavior ipv een class met data EN behavior.

Jouw situatie is hiervan verschillend omdat je het hebt over code die de UI ondersteunt, dus infrastructure en niet over een domain model, verder extend jij de class en dat is wat anders dan een aparte class maken die de behavior overneemt van een andere class.

Ik begrijp ook niet echt waarom een subclass nodig is voor het toevoegen van een property ? Ik denk dat een voorbeeld snippet wel zal helpen.

Dat terzijde, het wordt tijd dat meneer Fowler minder belangrijk gevonden gaat worden. Jarenlang heeft hij veel dingen geroepen die slecht waren etc. en er zijn nauwelijks wetenschappelijke papers over te vinden waarom dat dan zo slecht zou zijn. Het ironische is dat meneer Fowler al een tijdje zich louter bezighoudt met Ruby, omdat static typed languages kennelijk zich niet lenen voor moderne software, maar de realiteit is natuurlijk dat met het OH-en over static-typed talen je geen zalen meer gevuld krijgt en de boeken niet meer verkocht krijgt.

Het geneuzel waarom een anemic domain model dan wel zo slecht is, is bv totaal niet onderbouwd met wetenschappelijk onderzoek, maar met gutt-feeling gebaseerd pseudoscience en ander koffietafelgeklets. Het is bv vrij simpel aan te tonen dat een multi-class consuming process beter in 1 class kan worden geplaatst dan gefragmenteerd over meerdere classes. Maar goed...

[ Voor 12% gewijzigd door EfBe op 08-08-2008 12:45 ]

[mOrPhie]

Wat ik mis in de TS is een uitleg van Kenneth waarom die aanpak (anemic domain model) slecht zou zijn. Zoals al eerder in topics in dit subforum aan de orde is gekomen, lijken mensen te vaak uit te gaan van wat algemeen aangenomen als "goed" wordt gezien. Of sterker nog, dat een bepaalde methode, hoe dan ook, fout zou zijn. Hier ben ik persoonlijk alergisch voor. Voor elke architectuur is wat te zeggen, het hangt puur van de situatie af. Nu klinkt zijn uitspraak een beetje als "dat heb ik ergens gelezen en neem ik nu voor waar aan, want dat klinkt slim". Nofi uiteraard.

Verder geheel met EfBe. Ik heb mensen echt zien stuntelen, omdat ze perse de behavior in de domain-classes wilden hebben. In sommige gevallen leidde dat zelfs tot Business Layer achtige code in de presentatie, om multi-class behavior te beschrijven.

[kenneth]

Ik wil graag melden dat ik die opmerking met een knipoog in de HK maakte, zonder enige details te weten over de structuur van de applicatie

Ben zelf heel pragmatisch, dus ik zou iets wat werkt niet per se ombouwen omdat het op een ADM lijkt oid.

[Verwijderd]

EfBe schreef op vrijdag 08 augustus 2008 @ 12:43:
Jouw situatie is hiervan verschillend omdat je het hebt over code die de UI ondersteunt, dus infrastructure en niet over een domain model, verder extend jij de class en dat is wat anders dan een aparte class maken die de behavior overneemt van een andere class.

Vooral dit stukje geeft in mijn ogen aan waarom je er niet zo puur naar kan kijken als in allerlei boeken wordt uiteengezet. In de boeken staan methoden en best practices die in die kleine voorbeelden perfect werken. In de echte wereld zal je toch echt wel compromissen moeten sluiten.

In mijn ogen is een werkende, onderhoudbare applicatie vele malen belangrijker dan een puur theoretisch 100% correcte applicatie. Ten eerste zal je die 100% nooit halen (er zijn altijd haken en ogen aan je gekozen programmeertaal die het te ingewikkeld zouden maken), en ten tweede kom je op een gegeven moment een breekpunt tegen waar je code van super-elegant en leesbaar overgaat in een te complexe brij code. In mijn ervaring in ieder geval, misschien (ongetwijfeld) doe ik wel ergens iets verkeerd.

Om toch even terug te komen op het punt wat EfBe maakt, je hebt hier niet meer te maken met je domain model, maar met een hulp klasse voor je presentatie logica. Ik zie daarom helemaal geen probleem voor deze oplossing. Misschien dat een stukje voorbeeld dit kan ontkrachten dan wel bevestigen...

[Verwijderd]

Globaal is de structuur, van de in het topic genoemde dropdowns, als volgt.

Het platform van Agresso biedt een WholesaleListService [hier mag ik niet aankomen] aan, deze vult een dropdown op basis van een bepaalde entiteit (stel je hebt een AddressEntity, dan zal de dropdown gevult worden met adressen). Als je de functionaliteit van een dergelijke WholesaleListService aan wilt passen dien je deze te subclassen en de OnGetDataList (deze wordt door het Agresso platform aangeroepen bij de initialisatie van het scherm, wat ook gebaseerd is op een Entity) methode te overriden.

Ik heb een stuk of 6 subclasses van de WholesaleListService met als enige verschil dat een parameter anders is (een parameter die de naam van een Progress procedure voorstelt, aan de hand van de naam van die procedure moet de dropdown gevuld worden).

Het is natuurlijk een beetje onzinnig om 6 classes met exact dezelfde code (op de naam van deze procedure na) te hebben en dus heb ik en property aangemaakt en een extra subclass waarin de property specifiek voor die procedure gezet wordt.

Dus (^ stelt overerving voor ):
WholesaleListService
^
ImportCriteriaListService (bevat de overriden OnGetDataList + property)
^
RegionImportCriteriaListService (ze een property voor deze list specifiek)

Lijkt me prima?

[ Voor 17% gewijzigd door Verwijderd op 08-08-2008 14:17 ]