OOP vraag over paden
Ik wil graag even een OOP principe begrijpen.
Tot op heden als ik paden wilde opslaan, dan maakte ik een Paths class. In een config bestandje zette ik dan de paden:
Deze paden sloeg ik op in de Paths class, en als ik dan een Path nodig had dan deed ik dit:
Echter, nu vraag ik me af of ik het eigenlijk niet anders zou moeten doen. Zou ik niet voor iedere directory een eigen object aan moeten maken, en al deze objecten moeten opslaan in een directory container, en dat je dan dit doet?
Is dit laatste beter OOP vraag ik me af? En ik vraag me ook af... stel dat je 500 paden hebt, dan betekent dat dus ook 500 objecten. Vertraagt dat de bedoel niet enorm?
Gewijzigd op 11/02/2014 01:41:41 door Ozzie PHP
Maak je nu alleen een object aan om plaatjes uit een directory te kunnen lezen?
Waarbij je dan de parameter in de constructor onthoudt en dan weet je in de method get() nog in welke directory je moest zoeken.
Maar 1 class maakt nog geen OOP.
Het voordeel is dat je niet steeds jezelf zit te repeteren. En kan onafhankelijk gebruikt worden.
Het voorbeeld $paths->get('images') zou één pad naar een directory /images/ kunnen zijn waarin alle afbeeldingen zijn opgeslagen. Dan is dit pad één eigenschap van een configuratie. Hetzelfde pad is meteen ook een gedeelde en gemeenschappelijke eigenschap van alle afbeeldingen. Eigenschappen dus van andere objecten, geen zelfstandig object.
Bij objectgeoriënteerd programmeren is het object altijd een middel, nooit een doel. Een pad wordt pas een object als je dat object ergens voor nodig hebt, bijvoorbeeld om de rechten op een directory te wijzigen.
Als je het heel ver abstraheert, is elke bit een object en wordt een byte een datacontainer van 8 bits. Een x-aantal stappen verder heb je dan op een gegeven moment het pad als datacontainer van andere objecten (bijvoorbeeld directory's). Je kunt bijvoorbeeld een filesystem zo programmeren, maar altijd als middel, nooit als doel.
De vraag is dus: wat wil je met die paden doen?
Ward, jouw verhaal klopt niet helemaal meer als je gaat kijken naar domain driven development en gaat praten over value objects.
Tot nu toe als ik ergens een path nodig had, bijvoorbeeld het path naar de directory waar images zijn opgeslagen, dan gebruikte ik een $paths object. Hierin had ik alle benodigde paden via een config-bestandje ingeladen. Had ik een pad nodig dan deed ik dit: echo $paths->get('images') . '/plaatje.jpg'.
Nu zat ik hier over na te denken, en toen bedacht ik me dat je eigenlijk 2 soorten paden hebt, namelijk paden van directories en paden van bestanden. Is $paths dan niet te algemeen vroeg ik me af. En toen ging ik nog verder denken, en toen vroeg ik me af of ik niet in plaats van paden te gebruiken, objecten moet maken van de files en directories, en via die objecten het path moet opvragen.
Dan krijg je dus zoiets:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$directories = $this->container->get('directory_collection');
$image_directory = $directories->get('images');
echo $image_directory->getPath() . '/plaatje.jpg'
?>
$directories = $this->container->get('directory_collection');
$image_directory = $directories->get('images');
echo $image_directory->getPath() . '/plaatje.jpg'
?>
Een totaal andere benadering dus. In het eerste voorbeeld heb ik 1 container met daarin alle paden. In het tweede voorbeeld maak ik geen paden, maar directory objecten. Deze objecten stop ik in een container. Uit de container haal ik vervolgs het directory object en daar haal ik dan het path uit.
Graag jullie reactie!
Een huis heeft een adres. Maar je hoeft geen huis te bouwen als je een adres nodig hebt.
Voorbeeld 1. Stel je hebt een pad dat verwijst naar de directory van een library. Hoe noem jij dan die variabele?
1) $foo_library_directory_path
2) $foo_library_path
3) $foo_library_directory
4) anders
Voorbeeld 2.
Stel je hebt een functie makeDirectory(). Hoe noem je dan de paramter die het pad bevat?
Doe je het zo:
1) makeDirectory($path)
2) makeDirectory($directory_path)
3) makeDirectory($directory)
Bedankt voor het meedenken!
Kijk bijvoorbeeld maar eens naar dit pad en je ziet dat zoiets als een "echte" directory niet meer is dan wat je zelf verzint dat het zou kunnen zijn:
<disk>/<volume>/directory/subdirectory/archive.zip/directory/subdirectory/
Bij voorbeeld 1 en 2. Aangezien één directory verschillende paden kan hebben, bijvoorbeeld via symlinks of een router, zou ik de "route" in beide gevallen een path noemen, geen directory.
Er leiden meerdere wegen (paden) naar Rome (directory)...
Zucht...