statisch of niet?
Ik heb hiervoor een class aangemaakt die automatisch alle URLs instelt naar de diverse mappen en er komt automatisch http:// of https:// voor iedere URL te staan. Werkt allemaal als een zonnetje.
Nu mijn eigenlijke vraag.
Die class is (denk ik) niet echt een object en daarom heb ik de functies gewoon statisch gemaakt. Het heeft mijns inziens geen zin om meerdere URL-objecten te maken, want ik heb er maar 1 nodig en dat zal ook nooit veranderen.
Zoals gezegd heb ik de functies dus statisch gemaakt, omdat ... en nu komt het ... ik denk dat het géén object is. Maar is dat ook zo? Of zie ik het wellicht verkeerd?
Als ik nu dus ergens een URL nodig heb, dan roep ik die als volgt (statisch) aan:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
Urls::get('css');
?>
Urls::get('css');
?>
Ik zou echter ook een URL-object kunnen maken als volgt:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$urls = new Urls();
?>
$urls = new Urls();
?>
En dan vervolgens de URL als volgt aanroepen:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$urls->get('css);
?>
$urls->get('css);
?>
Nu is mijn vraag wat juist is. Is het inderdaad geen object en moet ik het dus statisch aanroepen (de eerste optie)? Of is er wel sprake van een object (zo ja, waarom) en moet ik de tweede optie gebruiken?
Iemand die dit weet?
Gewijzigd op 30/01/2019 13:08:50 door Ozzie PHP
Kun je hiermee ook andere links ook echt bouwen? Mogelijk weer op grond van configuratie-bestanden? Dan zou ik namelijk verwachten dat het echt onderdeel is van routing functionaliteit in jouw applicatie. En dan zou die methode (een generieke link-functie) dus bij een Routing-object horen.
Op dit moment klinkt het meer alsof dit "Urls" (meervoud?) een soort van hulpfunctie is, dus als dat zo is lijkt het mij niet echt dat je hier instanties van zou hoeven/moeten maken.
Een van de afwegingen om ergens instanties van te maken of niet was volgens mij of het ding dat je dan zou creëren een toestand ("state") heeft of niet. Dus dat dit object informatie onthoudt die mogelijk over tijd verandert. Als het antwoord hierop "ja" is, dan valt er wellicht iets voor te zeggen om hier objecten van te bakken, zo niet, dan waarschijnlijk niet. Maar dit is slecht één van de kenmerken, dit hoeft niet per se doorslaggevend zijn, maar dit zou je kunnen helpen bij het maken van een keuze.
Inmiddels even wat leeswerk verricht en het wordt over het algemeen vrij afgeraden om statische classes te gebruiken. Ik ga nu gebruikmaken van normale classes in combinatie met een factory class.
Ik kan weer vooruit :)
Als je wat verder leest lees je waarschijnlijk weer wat anders. De programmeerwereld is hier zelf ook over verdeeld. Gebruik gewoon iets simpels in plaats van iets met een bepaald uiterlijk enkel en alleen voor de vorm zonder enige meerwaarde.
op geschillende plaatsen kan ik aanroepen:
\classes\headers::add('form.css', 'css');
en
\classes\headers::add('form.js', 'js');
bijvoorbeeld.
Dat kan in elke method van de control gebeuren. Er is dan geen noodzaak om in elke control een soort van $this->headers te definieren.
In headers wordt hiermee een lijstje van files gevormd.
Bij het opbouwen van de output wordt
\classes\headers::get('css') en ::get('js') aangeroepen.
Daar wordt vervolgens de betreffende lijst weer uitgespuugd.
Zou je er een gewoon $this->header = new headers() van maken, dan moet je zorgen dan dat op de een of andere manier een singleton is, zodat er niet een lijst wordt opgevraagd uit een ander object dan wat je gevuld had.
Het is een veredeld array op deze manier. En ik zie er geen voordelen in op het als object te benaderen.
Zo kun je het inderdaad zien.
>> Gebruik gewoon iets simpels in plaats van iets met een bepaald uiterlijk enkel en alleen voor de vorm zonder enige meerwaarde.
Geloof me, daar ben ik ook van.
Thomas van den Heuvel op 30/01/2019 19:18:49:
Het klinkt nu een beetje alsof je overal een telefoonboek naartoe sjouwt, terwijl je hier af en toe op afroep een adres uit nodig hebt.
Daarom is een data object of value object geen slechte keuze: als je een speciale class PhoneNumber gebruikt, is direct duidelijk wat het object is.
Zodra een string meer dan zomaar een string is, gebruik ik zelf steeds vaker aparte klassen voor de logica.
Gewijzigd op 31/01/2019 16:51:00 door Ward van der Put
Ward van der Put op 31/01/2019 16:46:32:
Zodra een string meer dan zomaar een string is, gebruik ik zelf steeds vaker aparte klassen voor de logica.
Maar toch alleen als het gebruik van een class een zekere meerwaarde heeft? Indien je een simpel array hebt met een 1:1 mapping van key naar value, is er dan iets voor te zeggen om hier een class omheen te breien? Een array lijkt mij dan nog steeds het simpelst.
Neem bijvoorbeeld:
Code (php)
Nu zie je al aan de signature van de methode dat deze niet zomaar een string, een getal of een nummer accepteert, maar uitsluitend een object van het type PhoneNumber. De hele logica van wat nou een geldig telefoonnummer is, kun je zo delegeren aan andere klassen: de class PhoneNumber zelf of bijvoorbeeld een factory.
Toch is dit in de OOP-wereld vrij gebruikelijk. Denk bijv. aan een config object of een registry. Let wel, ik heb het hier dan over een wat uitgebreider systeem waarbij je op meerdere plekken, bijv. in alle controllers, je config object wil kunnen aanroepen. Objecten kun je weer meegeven aan andere objecten en dat is de kracht van OOP.