statisch of niet?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ozzie PHP

Ozzie PHP

30/01/2019 13:03:59
Quote Anchor link
Stel ik wil binnen mijn website de URLs ergens in opslaan zodat ik die overal kan oproepen.

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)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php

Urls::get('css');

?>

Ik zou echter ook een URL-object kunnen maken als volgt:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php

$urls
= new Urls();

?>

En dan vervolgens de URL als volgt aanroepen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php

$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
 
PHP hulp

PHP hulp

25/04/2019 11:00:05
Honeypot
 
Thomas van den Heuvel

Thomas van den Heuvel

30/01/2019 16:41:43
Quote Anchor link
Ik zou eerder een soort van link-functie verwachten die URL's dynamisch opbouwt, ik weet niet echt of er een voordeel is om een soort van lijst ergens bij te houden. Als het goed is zit er van zichzelf toch wel enige structuur in de CSS-bestanden? Ik zou dan misschien ook eerder verwachten dat de code die deze URLs ergens gebruikt deze zelf (op afroep) genereert en dit niet laat bepalen door een lijst ofzo.

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.
 
Ozzie PHP

Ozzie PHP

30/01/2019 16:50:01
Quote Anchor link
Thanks Thomas. Urls is gewoon een (dynamisch opgebouwde) lijst van urls die ik waar nodig kan gebruiken. Mooi centraal geregeld.

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 :)
 
Thomas van den Heuvel

Thomas van den Heuvel

30/01/2019 17:12:54
Quote Anchor link
Het klinkt in dat geval nog steeds als een veredeld array. Om dit nu in een object te gaan verpakken lijkt mij niet nodig. Tenzij het onderdeel is van een soort globaal beschikbaar configuratie-object ofzo.

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.
 
Ivo P

Ivo P

30/01/2019 17:23:58
Quote Anchor link
ik gebruik iets dergelijks ook. (statisch)

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.
 
Ozzie PHP

Ozzie PHP

30/01/2019 17:24:31
Quote Anchor link
>> Tenzij het onderdeel is van een soort globaal beschikbaar configuratie-object ofzo.

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

Thomas van den Heuvel

30/01/2019 19:18:49
Quote Anchor link
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. Een tussenvorm zoals die van @Ivo lijkt mij dan nog een betere aanpak. Maar daar gebruikt hij al concrete bestandsnamen die hij waarschijnlijk op voorgeschreven plaatsen heeft staan. Ik gebruik iets soortgelijks waarbij ik vanuit een "pagina type" een CSS- of JS-bestand invoeg in een hogere laag (het maintemplate, die weer onderdeel uitmaakt van een pagina-object, wat in wezen de "response" vormt van een "request"). Maar daarbij gebruik ik gewoon het volledige (relatieve) pad. Je zou dit natuurlijk ook dynamisch kunnen construeren door het hergebruiken van de directorystructuur voor de code, en deze dan ook toepassen op gebruikte "media" zoals afbeeldingen, CSS en JavaScript.
 
Ward van der Put
Moderator

Ward van der Put

31/01/2019 16:46:32
Quote Anchor link
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
 
Thomas van den Heuvel

Thomas van den Heuvel

31/01/2019 16:57:33
Quote Anchor link
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.
 
Ward van der Put
Moderator

Ward van der Put

31/01/2019 17:08:20
Quote Anchor link
Klopt, maar die meerwaarde heb je al vrij snel als je DRY werkt.

Neem bijvoorbeeld:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php
class Person
{
    public function setPhoneNumber(\PhoneNumber $number)
    {

        // ···
    }
}

?>


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.
 
Ozzie PHP

Ozzie PHP

31/01/2019 18:00:04
Quote Anchor link
>> 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?

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.