Ik heb het idee dat sommige OOP'ers behoorlijk vaak interfaces gebruiken.
Stel je hebt meerdere classes die iets kunnen cachen dan lijkt het me zinvol om een interface toe te passen. Echter er zijn ook classes waarvan je bijv. op voorhand weet dat je er maar 1 van nodig hebt.
Stel ik heb bijv. een Config class waar ik configuratie instellingen in op kan slaan. Ik weet dat ik aan 1 (type) class voldoende heb. Ik zal nooit andere varianten van die class maken. Is de conclusie dan ook dat dergelijke classes geen interface nodig hebben? (je gaat ze namelijk nooit uitwisselen met een andere class)
Het draait me om het ruimere concept "interface". Ja, voor \ of / heeft PHP een interne constante; die constante gebruik je dus om te zeggen wat je wilt. In wezen is die contante een abstractie van een interface: zó moet je het lokale bestandssysteem adresseren.
Maar wat nu als het minder concreet wordt? Wat betekent "pad" eigenlijk? Is dat een tijdelijk pad? Een lokaal pad? Een pad binnen het netwerk? Of ruimer een pad binnen het internetnetwerk, dus eigenlijk een URI?
Kortom, wat injecteer je wanneer je funct(Paths $path) voorschrijft?
Een pad is een pad (en dus geen uri). Voor mij is een pad dit:
"/path/to/foo/"
Deze sla ik op in een Paths object.
Wanneer gebruik je nu een interface? Mij lijkt het logisch om een interface toe te passen als je op voorhand weet of kunt verwachten dat van het type class er meerdere varianten mogelijk zijn. Van een cacher weet je dat er meerdere types mogelijk zijn. Om ervoor te zorgen dat je deze classes onderling kunt uitwisselen gebruik je een interface, zodat alle classes die een cacher gebruiken nog steeds werken als je het type cacher omwisselt.
Nu is mijn vraag... zover ik het nu zie, heb je binnen je systeem maar 1 object dat paden opslaat. Ik zie zeg maar geen verschillende TYPES van paths objects. Daarom lijkt het me in dit geval dus niet zinnig om een interface te implementeren. Tenzij iemand hier zegt, nee... je kunt wel verschillende TYPES paths objects hebben, namelijk... ???
Als … je bij voorbaat al uitsluit dat je paden naar andere volumes, andere stations en andere servers in je netwerk nodig hebt, dan is dat een keuze.
Als … je vindt dat een pad altijd slechts een directory is, en niet een URN als een directory plus bestandsnaam, dan is ook dat een keuze.
Als … je /foo/bar/ wel een pad vind maar ftp://.../foo/bar/ inclusief protocolvoorvoegsel niet, dan is dat opnieuw een keuze.
Als …
Met al die keuzen ligt je implementatie redelijk vast. Maak je alle file handling direct afhankelijk van deze rigide Paths class, dan zul je eerder moeten gaan verbouwen dan wanneer je een PathsInterface implementeert.
De grap is dat mijn paths class in feite niet meer is dan een object dat data vasthoudt. Op het moment dat ik besluit dat een pad niet "/path/to/foo/" is, maar "ftp://.../foo/bar/" dan stop ik er toch gewoon dat pad in? Of ik er nu "/path/to/foo/" in stop of "maaktnietuitwatikhierneerzet". Het zal altijd werken.
Ik heb via m'n service container één object waar al m'n paden in zitten.
Als je het zo omschrijft, is de toegang tot paden een onderdeel van de API van de servicecontainer. Je hebt dan niet zomaar directe toegang tot de paden, maar de servicecontainer is in control.
Maar de services zijn allemaal classes. Sommige services hebben paden nodig en aan die services geef ik dan (via de container) het Paths object mee. In de constructor van zo'n class zal ik dan typehinten op Paths. Omdat ik maar 1 paths class heb typehint ik dus niet op een interface. En dat was dus mijn vraag, als je van een class maar 1 type hebt, of je dan wel of niet een interface moet gebruiken. Ik zie nog steeds niet de mogelijkheid tot meerdere varianten van een Paths class, dus lijkt me een interface in dit geval niet gerechtvaardigd?
