Stel ik maak een algemene class om data in op te slaan. Vervolgens wil ik ook een class maken om configuratiegegevens in op te slaan. Daar kan ik eigenlijk perfect de algemene Data class voor gebruiken.
Nu vraag ik me iets vreemds af. Wat is nu wijsheid. Om voor de configuratie gebruik te maken van de algemene data class? Dus:
<?php
$config_settings = new Data();
?>
Of is het slimmer om toch een aparte Config class te maken die de Data class extend?
<?php
class Config extends Data {
}
$config = new Config();
?>
Nu hebben we wel een aparte Config class, maar deze is wel leeg. Er staan geen methods is. Wat zou jullie voorkeur hebben?
'Male' en 'female' zijn van oudsher de twee yin/yang-zijden van een stekker. Met zo'n interface kun je dus van alles en nog wat aansluiten...
>> Ik weet ook niet of het een goed idee is om een PathsCollectionInterface te maken. Want ben je dan straks niet bezig om voor iedere class een interface te maken?
Dat weet ik ook niet, want het hangt van je ontwerp af. Maar in algemene termen kunnen we er natuurlijk wel wat over zeggen.
Als je een class PathsCollection implements PathsCollectionInterface met één klasse en één interface hebt, verzet je dubbel werk. Je schrijft dan dubbelop één interface die je meteen implementeert in één klasse. In een schetsfase of kladversie gebeurt het wel, maar wat je eigenlijk doet is de omgekeerde wereld: de werking van een klasse achteraf documenteren in een interface in plaats van een klasse ontwikkelen naar een vooraf gedefinieerde interface.
Doe je dat enkel en alleen voor de typehint, dan denk ik dat je maar beter meteen van een interface-hint over kunt stappen op een class-hint. De interface-in-wording wordt anders leidend voor een implementatie die al een concrete klasse heeft.
Eén klasse kan meerdere interfaces implementeren. Je class FooBar implements FooBarInterface met één interface wordt bij nader inzien misschien veel beter als class FooBar implements FooInterface, BarInterface met twee interfaces. En dan komt het dus aan op het ontwerpen van interfaces en API's, niet van klassen.
Hmmm, oké... best lastig. Weer wat zaken om over na te denken dus...
>> Als je een class PathsCollection implements PathsCollectionInterface met één klasse en één interface hebt, verzet je dubbel werk.
Dit ben ik in eerste instantie helemaal met je eens. Ik ga er vanuit dat ik maar 1 path class zal hebben, en uitgaande van die gedachte klopt wat jij zegt als een bus. Het enige nadeel zou zijn als er ooit meerdere varianten van een Paths class bijkomen. Op dit moment kan ik me dat niet voorstellen, maar ja.. zeg nooit nooit.
