Hoi RSZ!
Uitgebreide reply volgt...
---
Ik denk dat je een beetje in de war bent over het relatietype. Dat wil zeggen, je geeft wel een mooie structuur aan, maar je zegt er niet bij wat de structuur moet voorstellen.
Ik denk dat je hier het beste onderscheid kunt maken tussen twee relaties van klassen. De ene is `isEen' (ook wel bekend als `isA', op z'n Engels), de andere is `bevat'.
`isEen' is een term die de lading niet helemaal dekt, en waarschijnlijk is dit ook niet helemaal de juiste naam
. In elk geval gebruik je die relatie om een specialisering, of subclassering aan te geven. Je hebt twee objecten, en het eerste is
net zoals het tweede, maar dan specifieker. Een typisch voorbeeld hier is natuurlijk de klasse Mens, en je kunt daarbij een subklasse Man hebben. Je kunt dan zeggen `Man isEen Mens'. Deze relatie programmeer je met
extends. extends zorgt er daarbij voor dat Man alle eigenschappen van Mens
overerft, en daar nog dingen aan toe kan voegen.
Dit is echter waarschijnlijk niet de relatie die je bedoelt. Immers, een Category isGeen (
) Shop, en een Product isGeen Subcategory. Ik denk dat je de `bevat' relatie wilt modelleren. Dat wil zeggen, een Shop bevat Categories, een Category bevat Subcategories, en een Subcategory bevat Producten.
Dit kan, uiteraard, maar er is geen ingebouwde taalconstructie om dit aan te geven. Het beste wat je kan doen is een klasse Shop maken, die een verzamelign van Categories bevat, en dat is weer een klasse die Subcategories bevat, etc. Hoe maak je zo'n verzameling? Nou, in PHP wordt zo'n beetje
alles gedaan met Arrays. Dus ik zou zeggen, met een Array
.
---
Tot zover over inheritance en aggregatie (mooi woord) relaties.
Je zegt dat de website is opgebouwd uit frames. Nou is dat leuk (ieeeekk!), maar dat beïnvloedt denk ik niet het aantal queries. Elke pagina moet toch op zich geladen worden.
TENZIJ je van plan bent om alle klassen in een sessie te gaan bewaren, en op die manier queries naar de database te besparen.
Mmm... ik weet niet. Ik heb er geen praktische ervaring mee, en ik zou er zo niet de vinger op een zere plek kunnen leggen, maar het idee staat me een beetje tegen. Queriën moet je toch, en je kunt jezelf waarschijnlijk veel bugs en gotcha's besparen als je gewoon 1 (of een paar) queries per pagina uitvoert. Bovendien is een database er tenslotte toch op gemaakt om gequeriet te worden, dus zo'n vaart zal het met de performance niet lopen
.
---
Hoe kun je een complete hiërarchische structuur aan objecten opbouwen gegeven alleen het id van het onderste element (product). Nou, niet in Product zelf, en ik zou het ook niet doen in een van de andere klassen. Dit is een typisch voorbeeld waar een Factory goed werk kan bewijzen (Ik zou zeggen, Google ook eens op het Factory pattern, of kijk op
http://www.phppatterns.com/).
Ik stel voor dat je een ShopFactory klasse aanmaakt (een functie kan ook, maar klasses zijn netter, dus wen er maar alvast aan
), die je op elke pagina vraagt om een Shop object (Voor de duidelijkheid, een object is de naam voor een
instantie van een klasse. Niet teveel op letten als je 't niet meteen doorhebt, is niet zo relevant). Wat deze Factory nu zal doen is de invoer controleren op product id's, category id's etc, en het Shop object meteen met de relevante informatie vullen. Als je dat hebt, kun je in je hoofdcode altijd gewoon de ShopFactory een Shop laten uitpoepen, en weet je meteen zeker dat alle relevante informatie erin staat.
Je gaat hier alleen tegen problemen aanlopen, als bijvoorbeeld een (sub)category id gespecificeerd is. Ga je dan meteen alle producten in die categorie uit de database queriën, zodat je ze daarna makkelijk weer kan geven? Maar als je nou met pagina's werkt? Alle producten queriën is dan teveel van het goeie en slecht voor de performance. Maar om wel fatsoenlijk te kunnen queriën op pagina's, moet de ShopFactory kennis hebben van pagina's. Slecht idee, want als je zo bezig bent begin je alle logica in de Factory te proppen en daar is-'ie niet voor bedoeld.
Je hebt een paar keuzes om dat op te lossen, die ik zo uit mijn hoofd kan bedenken. Waarschijnlijk zijn er nog (veel?) meer, maar hier zijn er alvast een paar :-
- De makkelijkste en duidelijkste: niet automatisch producten laten ophalen bij de initialisatie. Voor categoriën zou je dat bijvoorbeeld wel kunnen doen, omdat die er niet zoveel zullen zijn, maar producten wordt te erg. Zodra je producten wilt gaan opzoeken, roep je bijvoorbeeld een methode aan: $category->retrieveProducts($page). Daar wordt de productenlijst gevuld en daarna kun je er doorheen gaan wandelen. Niet super-elegant, maar adequaat.
- Het ophalen doen in een aparte initialisatiemethode, bijvoorbeeld init(), die aangeroepen wordt door de Factory. Deze methode haalt het gewenste paginanummer uit de invoer van de pagina ($_REQUEST), en haalt de daarvoor juiste producten op uit de database. Voordeel: de code die categorie gebruikt hoeft er niks speciaals voor te doen. Van de andere kant, je kan dit net zo goed doen in de constructor. En dat brengt ons op:
- Het ophalen doen in de constructor. Werkt hetzelfde als in de vorige methode, maar is netter omdat je niet nog eens een expliciete aanroep naar een initialisatiemethode hoeft uit te voeren. Deze methode zou mijn voorkeur hebben.
Ik merk nu alleen dat de initialisatie nogal context-afhankelijk is. Je kan in een categorie namelijk wel alle (of een deel van de) producten op gaan halen, maar als de gebruiker nu een product aan het bekijken is, zijn die allemaal voor niks. Je moet dus flinke case-analysis doen om het juiste gedrag te voorschijn te toveren. Daar wordt je code onnodig ingewikkeld en weinig robuust van. En daarom...
(P.S: Case analysis is ook weer een heel erg mooie term die niks anders betkent dan `met een hele hoop IFjes kijken in wat voor situatie we ons precies bevinden'. Dit wil je dus zoveel mogelijk vermijden, daarom hebben we ook object-oriëntatie.)
---
...schoot mij net een volledig ander ontwerp te binnen. In principe ligt de focus van de gebruiker altijd op één van de elementen die je aangeeft in je lijstje, te weten Shop, Category, Subcategory of Product. De gebruiker is altijd één van die dingen aan het bekijken (minus uitzonderingspagina's zoals het winkelmandje of zo, die laten we even voor wat ze zijn). Van de bovenliggende objecten hoeven we geen details te weten, van de onderste wel. Het probleem is alleen, dat als we de datastructuur van boven af opbouwen (en ook beginnen bij het bovenste object), dat we dan elke keer moeten gaan kijken hoe diep we de structuur in kunnen duiken om te weten waar we zijn. Dat is vervelend, en bovendien onnodig.
In plaats van deze top-down strategie, denk ik dat een bottom-up strategie veel meer van toepassing is. Dat wil zeggen, we beginnen bij het laagste element uit de lijst, kijken wat voor type het is en bouwen aan de hand daarvan een pagina op. Eventuele hoger liggende niveaus worden wel ingeladen, maar de details niet. Waarschijnlijk heb je ze toch alleen nodig om een "escape"-link te laten zien, of de structuur.
We introduceren even de term "focus", om aan te geven dat een gebruiker op het moment geïnteresserd is in een object. Dus een category kan focus hebben, of een product. Als de gebruiker net de site binnenkomt zeggen we dat de Shop focus heeft.
Terug naar de Factory. De Factory analyseert wat voor object er op het moment focus heeft (van alle id's die beschikbaar zijn pakt hij het id dat hoort bij het object dat het diepst in de lijst zit, dus eerst Product, dan Subcategory, Dan Category en dan Shop), en maakt daar een instantie van aan.
Elk object heeft wel een link naar zijn ouder. Merk op dat dit net andersom is dan wat ik net zei, namelijk dat een ouder een verzameling kinderen heeft. De andere kinderen zijn niet relevant, we willen alleen de ouder van het kind met focus weten.
In principe kan elk object in zijn constructor zelf zijn ouder opzoeken en aanmaken, en de link in zichzelf opslaan. Wat we dan alleen nog nodig hebben, zijn een methode om details over het object op te vragen (die wordt alleen aangeroepen op het onderste object, dus het object met focus), en het is natuurlijk helemaal mooi om elk object zijn eigen pagina te laten weergeven. Nog minder case analysis!
Een kort stukje code om te laten zien hoe elegant de code dan kan worden:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| class ItemFactory {
function ItemFactory() {
}
function getFocused($input) {
// Kijk welk item gefocused is (waar de id van beschikbaar is)
// en maak die aan.
if (isset($input["pid"])) $ret =& new Product($input["pid"]));
elseif (isset($input["uid"])) $ret =& new SubCategory($input["uid"]));
elseif (isset($input["cid"])) $ret =& new Category($input["cid"]));
elseif (isset($input["sid"])) $ret =& new Shop($input["sid"]));
else $ret =& new Shop(DEFAULT_SHOP);
$ret->setFocus();
return $ret;
}
}
// Dit is de hoofdcode -- haal het gefocuste object op een toon het
$fact =& new ItemFactory();
$focused = $fact->getFocused($_REQUEST);
// Het object weet zelf hoe het zichzelf moet afbeelden op het scherm
// Dat laten we 'm nu doen
$focused->display(); |
Dit is natuurlijk een puur programmatisch verkooppraatje
. KIJK nou toch eens hoe mooi die code kan worden! Uiteraard is de code nog lang niet compleet. De echte nitty-gritty details over de objecten zelf zijn weggelaten. Om te beginnen moeten ze allemaal afgeleid zijn van één basisobject, wat de eigenschappen in zich heeft om "gefocused" te worden (met
setFocus()), en om zichzelf af te beelden (met
display()). Elk object moet op zijn beurt weten wat er van verwacht wordt als het focus heeft, èn het moet zijn ouder opzoeken in de database. Hier gebruik je dus wèl de
extends relatie, omdat de subobjecten specialisaties zijn van het hoodfobject. Bovendien speelt de andere relatie ook nog een rol (zij het in mindere zin), want de verschillende klassen kunnen onderling nog verwijzingen naar elkaar hebben.
Mocht je daar nog voorbeeldcode van willen zien, laat het dan ff weten, dan zal ik die hier ook nog neerplakken. Maar ik denk, geen reden om mijn vingers extra moe te maken, eerst zien of 't aanslaat
.
---
En bij nader inzien is dit waarschijnlijk ook wat jij in gedachten had toen je de post schreef. Ik moet toch eens leren beter te lezen
. En om je vraag over referenties naar ouders te beantwoorden: je kan doen wat je zelf maakt. Dus als je referenties naar ouders maakt, dan heb je die. Dit heeft echter alleen betekenis in een `bevat' relatie (of een ander soort). In een `isEen', of subclassing, relatie
bestaat een referentie naar je vader niet, want
je bent daar zelf hetzelfde object als je vader. Jij hebt alleen wat meer eigenschappen.
Groeten,
One
[
Voor 67% gewijzigd door
Verwijderd op 16-07-2004 10:54
]
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
