interface

Huh, wat bedoel je met serialized paths en frozen paths? :-s
Een path is in mijn systeem gewoon dit "/root/foo/path/" en heeft een ID. Je hebt toch geen andere soorten paden?

Je dat is een Path, en dan heb je dus een Paths object die meerdere Path objecten heeft. Die kan frozen (locked) zijn, of serialized, enz.

Hmmm, oké... mijn Paths object is een verzameling van paden. Ik heb niet voor ieder pad een apart object, maar alle paden zitten gewoon in een class property (array). Als ik een pad nodig heb, dan is het dus heel simpel: echo $paths->get('image');

Ik zou me geen situatie kunnen bedenken waarom ik paden zou willen serializen of het object zou willen locken. Ik denk dus echt dat ik aan 1 Paths object voldoende heb. (In de meeste gevallen zal dat anders zijn en zul je wel een interface nodig hebben inderdaad.)

Wat ik me nog wel afvraag. Stel je hebt een Foo class... nee, wacht, laten we het gewoon een cacher class noemen, en je wil daar een interface voor maken. Stel de cacher class moet o.a. een delete() en een deleteAll() functie hebben, maar je weet dat er meerdere classes zijn die een delete() en deleteAll() functie hebben. Is het dan de bedoeling dat je een cacher interface maakt die dan de "deleteInterface" extendt? Of stop je alle functies die in de cacherInterface thuishoren gewoon in 1 class?

Nee, je wilt niet dat één cache-gebruiker alle caches (ook die van anderen) kan legen. Je maakt daarom een cache pool die als gemeenschappelijke resource gedeeld kan worden. Via de pool kunnen verschillende objecten dezelfde cache delen.

En dan heb je hier twee interfaces nodig: een voor een cache entry en een voor de cache pool.

Ward, ik snap niet helemaal wat je bedoelt. Met deleteAll() bedoel ik dat de cache wordt verwijderd die bij een specifieke cacher hoort. Bijv. ik heb een LibraryFooCacher. Deze verwijdert dan alleen dingen die bij library Foo horen. Of stel ik heb een WebsiteCacher. Deze verwijdert dan alleen de bestanden die bij een specifieke website horen. DeleteAll verwijdert dus niet alle cache, maar alleen de cache data die aan dat specifieke cache object toebehoort. Stel ik zou een Ward library hebben:

<?php
$cacher = $this->container->get('ward_library_cacher');
$cacher->delete('foo'); // verwijder cache data met ID foo uit de Ward library cache
$cacher->deleteAll(); // verwijder alle cache data uit de Ward library cache
?>

Dat een specifieke cache bij een specifieke site hoort, is een heel duidelijke keuze: je koppelt hier een bepaalde cache uit de cache pool volgens bepaalde regels aan iets anders. Je maakt de inrichting van de cache al redelijk specifiek.

Objecten in de cache zijn in jouw opzet gerelateerd aan websites, hoewel er véél méér cacherelaties mogelijk zijn.

Ik zeg niet dat die keuze verkeerd is. Ik constateer slechts dat die keuze er is.

Als je al zó ver gevorderd bent, met zo veel doorslaggevende keuzen, zou ik inderdaad gericht typehinten op een class die een sleutelrol in het framework speelt. Maar meer in het algemeen zou ik liever typehinten op een interface.

>> Objecten in de cache zijn in jouw opzet gerelateerd aan websites, hoewel er véél méér cacherelaties mogelijk zijn.

Nee, niet altijd. Kan dus ook aan een library zijn gekoppeld.

>> Als je al zó ver gevorderd bent, met zo veel doorslaggevende keuzen, zou ik inderdaad gericht typehinten op een class die een sleutelrol in het framework speelt. Maar meer in het algemeen zou ik liever typehinten op een interface.

Voor een cacher zou ik dus ook typehinten op een interface. Maar wat zou jij doen met (bijv.) een paths class (zoals 2 berichten hierboven beschreven)?

Laten we het dan eens sterk vereenvoudigen. In het ene pad moet je \ gebruiken en in het andere pad /. Je wilt daarom typehinten op een interface die paden snapt, niet op een specifieke class die paden implementeert.

Ward, ik begrijp helemaal niet wat je bedoelt met:

"In het ene pad moet je \ gebruiken en in het andere pad /"

"Je wilt daarom typehinten op een interface die paden snapt"

Kun je dit eens nader toelichten? Er gaat bij mij nog geen lampje branden, maar wie weet met jouw uitleg?

Windows gebruikt \, linux/ OSX gebruiken / bij paden
Maar PHP heeft al native checks ingebouwd om het juiste slashteken te gebruiken dus ik snap niet echt waarom Ward hier een interface voor wilt implementeren.