(Ik heb maar wat om de flames heen gewerkt, dat viel nog niet mee)
H!GHGuY schreef op maandag 19 maart 2007 @ 19:58:
Ik heb je reeds een minimalistisch voorbeeld gegeven, wat je in deze hele monoloog (een discussie is het niet aangezien je niets leest wat ik schrijf) duidelijk aantoont dat de onderhoudbaarheid van je software er serieus kan onder leiden.
Nou, ik ben nog opgegroeid in unix/C en ik ben niet onder de indruk van je bezwaren: een backreference moet je inderdaad onderhouden, maar dat moet je met alle references. Die backreferences heb je nodig om vrij door een graph te kunnen navigeren.
Het rare is nl. dat jij dat wel erkent en dan met een overhead oplossing aankomt: een lijst met objects buiten je graph. Maar die moet je OOK onderhouden, sterker, die zijn lastiger te onderhouden.
Verder vind ik het ironisch dat je, wanneer je toch tegen de reference in wilt navigeren de objects maar opnieuw gaat ophalen. No offence, maar dat is wel erg moeilijk doen terwijl het makkelijk kan. En waarom? WAAROM zijn backreferences dan zo verschrikkelijk naar voor je dat je al die moeite doet?
Ik zie niet in wat er nu zo moeilijk aan is. Tja, als men niet snapt hoe je een double linked list moet updaten, dan wordt het inderdaad lastig, maar wellicht is het dan beter om maar te stoppen met software bouwen.
Toch wel.
Ik ken geen enkele discussie waarbij slechts 1 partij moet argumenten aanvoeren.
Oh, dus als jij wat beweert wat kant noch wal raakt dan is het aan de ander om aan te tonen dat je uit je nek lult? Rare manier van 'discussieren'.
Ik heb meer nog dan jou een structureel mooie oplossing gegeven. Als hij de boel vervangt door een soft-reference dan is zijn probleem ook opgelost.
Tja, zo kan ik ook makkelijk praten, maar dat betekent nog niet dat het ook daadwerkelijk opgelost is. soft references of hoe je ze ook noemen wilt, zijn niet bruikbaar met dezelfde constructs als de normale reference, verder moet je ze OOK bijhouden, en per saldo zijn die dingen nog lastiger bij te houden dan een simpele back reference.
Bovendien moet jij, die zo hard op frameworks kickt, niet komen aandraven over extra round-trips naar persistent storage. Een beetje deftig framework cachet objecten.
Ah, nog een 'makkelijk praten' opmerking die eigenlijk geen reet voorstelt. Cachen van objects? Ooit een persistence framework gemaakt met cache? Nee? Ik wel. Ik kan je verzekeren, die cache werkt niet zoals men dat te pas en te onpas roept, het lullige is namelijk dat die mensen geen reet van de hele materie afweten.
http://weblogs.asp.net/fb...ch-data-faster_2E00_.aspx
Ook de reden waarom in mijn framework geen cache zit, het heeft geen zin. Er zit wel een cache in, maar alleen voor single entity PK based fetches. Het lullige is echter dat dat niet 'gratis' is: de hoeveelheid operaties nodig om cache misses op te vangen of uberhaupt in een cache te zoeken is hoger dan een simpele '.' operator actie.
En DAAR gaat het om. Jij doet zo verschrikkelijk veel moeite om die . operator te vermijden. Ik kan alleen maar concluderen dat je dan niet echt bijster slim bezig bent.
Maar goed, aangezien jij allang vindt dat ik het niet snap, ga vooral zo door zou ik zeggen, ik hoop alleen voor jouw klanten / werkgever dat ze er niet teveel onder lijden.
En omdat je dit ook zou kunnen negeren:
1) Wie de LoD toepast gebruikt zowiezo geen backpointers.
van de LoD is bewezen dat ze de kwaliteit van software behoorlijk kan verhogen.
LoD? Je snapt er werkelijk weinig van. LoD zegt juist:"The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents)." (
http://en.wikipedia.org/wiki/Law_of_Demeter). Dit houdt dus in dat van infrastructure limitaties je geen weet hebt, en als een Order een reference naar Customer zou moeten hebben, dan heeft Order dat. Order gaat er echter NIET van uit dat hij informatie kan betrekken van 3 niveaus diep bijvoorbeeld, maar dat heeft met DIT probleem niets te maken want die beperking is ook van toepassing op jouw parent -> child reference! Immers, de ENKELE reference die jij zo graat ziet is OOK gelimiteerd door LoD: customer kan niet weten van Order zijn child references.
M.a.w.: LoD heeft hier echt niets mee te maken, temeer omdat Order's backreference naar Customer gewoon een reference is naar een directe buur.
2) Er zijn gevallen waarin backpointers noodzakelijk zijn.
Je meent het...
3) Ik werk dagelijks in software waarin backpointers een gehaat fenomeen zijn die we er liever vroeger dan later uithalen.
Komt dat omdat de code geschreven is door prutsers of komt dat omdat het concept fout is?
Code met verwijzingen als de volgende over verschillende modules heen
C++:
1
2
3
4
5
6
7
8
9
| void SomeClass::SomeFunction()
{
if (GetParent()->GetParent()->SomeFunction())
{
GetParent()->SetSomeProperty();
GetParent()->GetParent()->RecheckChildren();
UpdateSelf();
}
} |
zijn geen ongekend fenomeen.
Dit heeft dus geen reet met backpointers te maken, maar WEL met LoD. Immers:
GetParent().GetParent().GetParent() kun je vervangen door:
Child.Child.Child.SomeMethod();
en dan heb je hetzelfde probleem, maar dan met forward references. Zie je nu dat wat jij beweert niet echt werkt en dat het NIET ligt aan de backreferences maar aan een design flaw?
En dat daargelaten, leg mij eerst maar eens uit waarom een method in class C een method moet aanroepen in class A die daar 2 hops vandaan zit. Die code die je hierboven gepost hebt is fout, maar niet omdat er backreferences in zitten, maar omdat je ipv GetParent().GetParent().GetParent().SomeMethod() je had moeten zeggen:
GetParent().SomeMethod(), waarbij de parent dus die method verder uitvoert, wellicht door zn parent te vragen of wat dan ook. Maar NOG beter was het geweest om de logica BUITEN deze class te plaatsen, immers het is een cross-class method geinitieert IN een van de classes. Veelal wordt dit dan ge-outsourced naar een derde class die het management van de routine op zich neemt.
Als je dan weet dat er enkele extra niveaus in de hierarchie moeten komen dan weet je welke heibel ervan komt. Denk dus niet dat de impact op onderhoudbaarheid pure nonsense is.
Tja, maar dat is jouw eigen architecturele blunder, dat heeft niets met backpointers te maken. Als jij 3 niveaus diep naar children zoekt en daar dingen aanroept gaat het net zo fout, en dat zijn dan FORWARD references. Dus, ga je die dan ook weghalen?
De kluwen van references naar allerlei objects in een graph zie je vaak terugkomen in DDD based code, waarbij men kost wat kost wil vermijden dat men aenemic classes krijgt, ("want boooee!!! dat is een antipattern volgens Blah Blah Bliki Fowler!") en dan met een probleem zit waar code te plaatsen waar een aantal andere objects ook bij betrokken zijn. Tja, terwijl dat zo simpel op te lossen is met manager classes, die als een service fungeren en een graph 'consumeren'. Dit verlost je van het feit dat de logica IN een van de objects zit die in de graph zit en die dus over de gehele graph moet navigeren.
Een goed voorbeeld van parent pointers met enige rechtvaardiging is het System.Windows.Forms in .NET. Op zich kent Button zijn container niet, behalve dat het een container is. De buttonclick events worden dan weer niet afgehandeld in Button (geen code ala (Form)GetParent().SetText("blah")) maar in de afgeleide van Form (dus this.SetText("blah") in de buttonclick eventhandler)
Ook dit heeft er niets mee te maken, want de reden waarom de handler van het button click event niet in button zit is heel simpel: het observer pattern zegt dat de observer zich BUITEN de te observen class bevindt, in dit geval is de button de te observen class en het form de observer.
Wanneer Button specifiek code zou hebben voor een Form als parent of voor een Grid als parent dan heb je een serieuze design flaw want wat doe je dan als je je button wil toevoegen op een ander component? Dat Button weet dat hij in een ControlContainer aanwezig is, kan gerechtvaardigd worden.
Niet echt, je kunt dan t.a.t. terugvallen op het observer pattern. Het enige is dat een button in weinig andere contexts gebruikt gaat worden dan op een form (direct of indirect). Een beter voorbeeld had kunnen zijn een willekeurig BO, dat bv in een persistence layer context zit maar ook in een grid (wellicht via een controller). Het BO weet dat niet, roept gewoon dat er iets is gewijzigd en de rest zoekt het maar uit.
Om van het ene voorbeeldje op het andere over te springen:
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class Car
{
public:
AddWheel(Wheel w);
Wheel[] GetWheels();
}
class Wheel
{
SetParent(Car c);
Brand GetBrand();
double GetDiameter();
double GetWidth();
double GetPressure();
} |
Wat doe jij dan om een wiel op je fiets te steken, of een autoband op je fiets?
Car-specifieke code hoort in Car thuis en Wheel-specifieke code in Wheel.
Je mag nu in je haar krabben en zeggen dat ik iets evident vertel, maar code zoals hierboven leidt al gauw tot dit:
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| class Engine
{
double GetRequiredHP();
void SetRequiredHP();
}
class Car
{
Engine GetEngine();
}
class Wheel
{
void SetPunctured()
{
GetParent().GetEngine().SetRequiredHP(GetParent().GetEngine().GetRequiredHP() + 1);
}
} |
wil je nog steeds een autoband op je fiets (in dit geval meteen tot bromfiets herleid) of een fietswiel op je auto?
Sinds wanneer zou ik naar engine willen navigeren vanuit wheel? Logica in Wheel heeft betrekking op wheel, niet op andere objects. Dat soort logica plaats ik altijd in een externe class, temeer omdat het niet duidelijk is in welke van de betrokken classes de logica dan zou moeten. Voorbeeld: inventory management: je hebt: order, order lines, products, inventory per product, bestellingen etc. Ga je dat allemaal in order stoppen? In product? In de inventory per product? Of in een aparte class? Die aparte class is nl. prima in staat om te doen wat jij wilt, stateless. Het leuke is ook dat je de logica op 1 plek hebt en het makkelijk onderhoudbaar is. Een ander bijkomend voordeel is dat je backreferences dan wel degelijk kunt gebruiken, want je kunt makkelijk van de ene naar de andere navigeren, en guess what: beheer van die dingen is nog kinderspel ook.
Oh wacht, ik begreep het niet. Ah dat was het.
:strip_icc():strip_exif()/u/6754/image.jpg?f=community)
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
Dat heeft imho helemaal niets met de :strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
/u/3273/crop62bb0d316df4f_cropped.png?f=community)
) met betrekking tot meer geavanceerde designpatterns speelt voor mij in dit geval weinig tot niet.