OO-design problemen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Lead back-end developer met Product Owner skills g

Functie Momenteel zijn ze op zoek naar een ervaren developer die binnen het team de lead kan nemen, en vanuit die ervaring ook de rol als Product Owner vervult voor een team van externe developers. Bijvoorbeeld door duidelijke stories te schrijven en hun werk naderhand te controleren. Hiernaast zul je ook zeker zelf code blijven schrijven. Je ontwikkelt nieuwe uitbreiding op de back-end (geschreven in Java en PHP), zoals bijvoorbeeld integraties met derde partijen (Alexa, Google Home). Ook ben je bezig met de ontwikkeling van nieuwe functionaliteiten. Eisen • Je hebt een groot analytisch vermogen • Je hebt minimaal 5

Bekijk vacature »

Senior Java Back End Developer

Functieomschrijving Owning your product, freedom to be creative and make mistakes, and above all, a passion for experimentation and innovation: that’s what defines our talent domain in their own words. As Senior Java Developer at RGN IT you join us as we expand our permanent teams focused on building the best solutions to support the entire spectrum of talent the Randstad Group engages with. What do we offer? Trust and freedom to do your work within the goals and vision of the team Support to grow your skills - whether that’s leadership or technical A hybrid way of working in

Bekijk vacature »

Senior developer (fullstack)

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en je kijkt verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Team Lead PHP

As Team Lead PHP, you make our customers smile by providing great software and building an effective team. How do I become a Team Lead PHP at Coolblue? As a Team Lead Web Development you build and lead a team that excels in providing high-quality and cost-efficient software. You support team members in defining their personal growth goals and with the approach to achieve them. Would you like to become a Team Lead PHP at Coolblue? Read below if the job suits you. You enjoy doing this Building and leading a team that excels in providing high quality and cost

Bekijk vacature »

Angular Developer Software Ontwikkelaar / JAVA / 3

Samengevat: Wil jij werken bij een bedrijf dat zich specialiseert in software voor vastgoed? Wil jij onderdeel uitmaken van een ontwikkelteam? Heb jij ervaring met Angular? Vaste baan: Angular Developer Angular Developer 3.200 - 5.000 Angular Developer Deze werkgever levert innovatieve All-in-One Property Management Software voor Vastgoed Beleggings– en Property Management Organisaties. We zijn voorloper op het gebied van het toepassen van bewezen nieuwe technieken, die ervoor zorgen dat vastgoedprocessen en werkzaamheden die nog niet geautomatiseerd konden worden, nu wel volledig geautomatiseerd kunnen worden. Met hun oplossingen worden inzicht en rust gecreëerd, aantoonbaar tijd bespaard en groei gerealiseerd. Zij werken

Bekijk vacature »

Speculative Application Java Developer

Functieomschrijving Keeping up with the future of work requires ever changing, ever innovating technologies. Our java developers and the software they build play a vital role in connecting our workforce, optimizing our processes and enabling us to stay ahead. What are we working on? As java developer at randstad your role can vary. Java is a core part of many of our 36 scrum teams, giving you the opportunity to contribute to a large number of different applications and projects. Some of the things our teams work on are designing and building our candidate portals and the first point of

Bekijk vacature »

Productontwikkelaar

Over het werk Als productontwikkelaar weet jij als geen ander hoe je de kwaliteit van je product tot perfectie kunt krijgen. In deze functie houd je je bezig met de producten die je toekomstige nieuwe medewerker produceert. Je buigt je, samen met je collega's, over verschillende onderdelen die met de productie te maken hebben. Zo ben je verantwoordelijk voor het verbeteren van de producten, het aanleveren van nieuwe producten en het optimaliseren van het productieproces. Hierbij is het belangrijk om de haalbaarheid van het proces te waarborgen. Alles wat je doet documenteer je, registreer je en kun je overtuigend presenteren

Bekijk vacature »

Medior Java developer (backend)

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en je kijkt verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Fullstack developer

Bedrijfsomschrijving Yacht is dé organisatie van en voor professionals. Wij verbinden professionals en organisaties die het verschil willen maken. Ons doel is optimaal resultaat: jou als professional uitdagend werk bieden waarmee jij de organisaties van onze opdrachtgevers blijvend verbetert. Yacht is een dochter onderneming van Randstad Holding met een focus op hoog opgeleide professionals. Geïnteresseerd? Dan willen we jou graag beter leren kennen! Functieomschrijving Ben jij een Fullstack developer die de uitdaging zoekt om op detacheringsbasis tijdelijke opdrachten te doen bij grote klanten als: Heineken, Bol.com Philips, KPN, ABN AMRO, Rabobank, ING, PWC, VodafoneZiggo, Leaseplan, Athlon International, Randstad Holding etc

Bekijk vacature »

Medior Java developer (backend)

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en je kijkt verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Junior java developer, interested in modelling

Due to the expansion of our applied modelling software team, we are looking for a junior java developer, with modelling ambitions. Aad van Gerwen, Team Manager Applied Modelling: “As a junior model driven engineer at Capgemini Engineering you are involved in the next revolutionary step in software engineering! Our department is focusing on creating and applying (domain-specific) models to drive the engineering process. This approach ensures the time-to-market and quality increase demands our clients face today are met. I am looking for someone who is passioned in this revolutionary approach and is ready to learn and grow together with the

Bekijk vacature »

Senior Java developer (backend)

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en je kijkt verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Programmeur

Ben jij technisch ingesteld en help jij graag met de voorbereiding van installaties? Ben jij gemotiveerd en neem je graag verantwoordelijkheid? Dan is de functie van Programmeur misschien wel wat voor jou! Nu al enthousiast? Lees dan snel verder! Wat bieden wij jou Goede werksfeer Flexibiliteit in de werktijden Uitzicht op een vast contract Programmeur Automatisering Nodige opleidingen en ondersteuning Marktconform salaris Wie ben jij Je bent positief ingesteld en heel erg gemotiveerd. Je neemt graag de verantwoordelijkheid en zorgt altijd dat je werk op tijd af is. Kunnen werken in teamverband is voor jou geen probleem, en zelfstandig functioneren

Bekijk vacature »

Java Fullstack ontwikkelaar

Functie Werk jij graag met Java, maar ben jij graag breed inzetbaar? In deze rol kom je werken in een hecht team van ontwikkelaars dat de komende jaar wil gaan uitbreiden. Ons team bestaat voor de helft uit vrouwelijke ontwikkelaars. Wij hebben een mix van ervaren ontwikkelaars en starters. Voor deze rol zoeken wij iemand met minimaal twee jaar werkervaring op het gebied van Java development. Als Java developer zul je ook werken aan de fontend van onze SAP-applicatie. Je zal applicaties opbouwen van scratch. Ons plan is om de komende jaren van 6 applicaties naar 16 te gaan. Hier

Bekijk vacature »

Senior Software Developer

Dit ga je doen Het ontwikkelen van nieuwe futures en updates; Het doorontwikkelen van de applicatie; Het analyseren van incidenten; Het oplossen van 2e en 3e lijns incidenten; Het implementeren van het ERP systeem op nieuwe locaties; Het bieden van ondersteuning. Hier ga je werken Deze Enterprise organisatie heeft meerdere locaties en zal op niet al te lange termijn nog meer locaties openen! Dit brengt met zich mee dat het ERP systeem, welke als levensader door de organisatie heen loopt, op deze locaties nog geïmplementeerd zal gaan worden. Het ERP systeem waar zij mee werken is een maatwerksysteem en is

Bekijk vacature »
Lasse

Lasse

20/02/2008 14:03:00
Quote Anchor link
Hallo,

Ik ben bezig met het (ter oefening) ontwerpen van een forum in OOP. Nu heb ik twee problemen, en ik wil daar graag jullie oplossing/visie van horen:

1: Een heleboel klassen maken gebruik van PDO. Aangezien ik in PDO geen singleton heb gevonden zoek ik nu naar een andere oplossing om geen overdreven veel verbindingen met de database te maken:
-Ik kan een nieuwe klasse maken die PDO extend, en waar wel een singleton in zit
-Ik kan gebruik maken van persistente connecties, maar ik weet niet tot in hoevere dat handig is
-Ik kan een soort register klasse maken, maar dat heeft ook niet mijn voorkeur...

Heeft iemand hier nog een andere oplossing voor, of wil iemand mij zeggen waarom één van de drie hierboven beschreven oplossingen het beste zijn?

Probleem 2:
Stel ik heb de klasse Topic. Die heeft een compositieverbinding met de klasse Post. Dat houd dus in dat in de klasse topic een array moet zitten waarin alle posts zijn opgeslagen (en uiteraard bijbehorende methoden). In de klasse Post moet een method zitten waar de juiste instantie van Topic in zit (of is dit niet nodig?).
Als ik nu een nieuwe post wil defineren, doe ik dat dan via een methode createPost() (of iets dergelijks) in klasse Topic? Als ik dat namelijk niet doe, en ik maar gewoon rechtstreeks een new Post, dan moet ik hem daarna nog registreren bij een instantie van Topic.
En geldt dan ook dat ik bij het verwijderen van een Post, gewoon een functie deletePost() aanroep? Want anders verwijder ik vrolijk een Post, en dan staat hij nog wel geregistreerd in de instantie van Topic.

Ik hoop dat mijn verhaal een beetje duidelijk is, en alvast bedankt voor het antwoord!
Gewijzigd op 01/01/1970 01:00:00 door Lasse
 
PHP hulp

PHP hulp

26/09/2022 17:25:30
 
Bo az

Bo az

20/02/2008 14:33:00
Quote Anchor link
Singleton voor een database klasse zou misbruik van het singleton pattern betekenen. Singleton heb je bijna nooit nodig, je mag het alleen gebruiken als je zeker weet dat je maar één instantie van een klasse krijgt, maar wie zegt je dat je maar 1 instantie van PDO mag maken?

Persoonlijk zou ik 'm zo-ie-zo in een registery zetten omdat je 'm dan meteen overal tot je beschikking hebt.
 
Slurp

Slurp

20/02/2008 14:57:00
Quote Anchor link
SIngelton zorgt er voor dat je maar 1 database instatie kan aanmaken. DUs het kan best. OF maak jij altijd per connectie een nieuwe instantie aan?
Dus het is geen misbruik maar juist goed gebruik als je er wilt voor zorgen dat je per instantie maar 1 connectie wilt ;)
 
Bo az

Bo az

20/02/2008 15:22:00
Quote Anchor link
@Slurp, nee dat is het niet, singleton zorgt er voor dat je maar 1 connectie KAN maken, als je bijvoorbeeld ook een connectie wil maken met een postgresql database kan dat niet meer door het singleton pattern. Of als je ook met een andere mysql database wil connecten kan dat niet meer.
Gewijzigd op 01/01/1970 01:00:00 door Bo az
 
Lasse

Lasse

20/02/2008 16:58:00
Quote Anchor link
@Boaz: Dat is niet helemaal waar, want je kunt altijd rechtstreeks de constructor aanroepen, maar verder heb je inderdaad wel gelijk.

Maar hoe zit het dan met een persistente verbinding? In principe kan je die ook wel gewoon gebruiken toch?

En weet iemand nog het antwoord op mijn tweede probleem?
 
Jelmer -

Jelmer -

20/02/2008 17:07:00
Quote Anchor link
Dat zou je eens moeten testen. Met de SQL query 'SHOW PROCESSLIST' kan je kijken hoeveel verbindingen er nog open staan, en door te hameren op je server met bijvoorbeeld apache ab en kijken wanneer hij het opgeeft.

Wat je ook nog kan doen is in plaats van een register gebruiken een Factory voor je klassen (of meerdere factories) gebruiken om de instanties te maken, en de instanties direct te voorzien van een verwijzing naar de instantie van PDO. M.a.w de instantie van PDO door de constructor heen drukken zodat je wel overal maar 1 instantie gebruikt, en vervolgens het 'new Instantie($PDO)' gebeuren laten afhandelen door een aparte klasse/method/functie die die instantie van PDO tot z'n beschikking heeft zodat hij die kan uitdelen aan de nieuw aan te maken instanties.
 
Lasse

Lasse

20/02/2008 17:56:00
Quote Anchor link
@Jelmer: Dat is wel een goed idee (beide). Mag ik weten wat je zelf gebruikt?

En wil er ook nog iemand kijken naar mijn tweede probleem, want ik weet gewoon niet zeker of ik het op die manier goed doe...

Alvast bedankt voor alle reacties!
 
Jelmer -

Jelmer -

20/02/2008 19:04:00
Quote Anchor link
Ik gebruik zelf eigenlijk alleen toegang tot de database in mijn controllers en models. De controllers worden aangemaakt vanuit een centrale klasse, IHGApplication, welke ook de database-instantie beheert. Dus die geef ik mee bij het aanmaken zodat ik die vanuit de controller kan raadplegen. De models haal ik via een method uit de database-klasse, dus op dat moment wordt er ook een verwijzing naar die database meegegeven aan de models. Of ik maak ze aan zonder database, en wanneer ik Model::save aanroep, geef ik een instantie van de database mee (die heb ik immers in de controller tot mijn beschikking, en alleen daar zal ik waarschijnlijk de method save() aanroepen)

Ik probeer nu zelf op het moment zo veel mogelijk instanties mee te geven. In het verleden heb ik veel singleton gebruikt, maar dat beviel achteraf niet zo goed (altijd maar 1 instantie, en wanneer je een soort semi-singleton gebruikte, wist je niet meer welke instantie je nu voor je neus kreeg, en waar geef ik de verbindinggegevens mee?) En ook het register-pattern heb ik geprobeerd, maar dan was het vaak maar de vraag of de database al beschikbaar was, en als ik hem vooraf initialiseerde en registreerde, was het maar de vraag of hij wel nodig was. Daarnaast had je relatief weinig controle over welke database hij nu pakte. Ik gebruik bijvoorbeeld meerdere databases, vaak een MySQL of andere standaard-database, en een SQLite voor de cache of de configuratie. Maar dat wisselde nog wel eens (experimenteren e.d.) dus vind ik het tegenwoordig wel handig als ik veel controle over welke database meegegeven wordt, en vind ik het belangrijk dat ik meerdere databases tegelijkertijd kan aanspreken.
 
Lasse

Lasse

20/02/2008 19:25:00
Quote Anchor link
Maar die IHGApplication kun je ook tot de controller toch? Maar waarom zou je de database in de controller nodig hebben? Je hebt hem alleen in het Model nodig toch? Dus eigenlijk zeg je: Maak in je controller een instantie van PDO, en geef die bij het instantieren van een klasse steeds door (via de constructor ofzo?).
 
Bo az

Bo az

20/02/2008 19:48:00
Quote Anchor link
Hoe initialiseer je meerdere models die uit de database komen als je dat niet via de controller doet? Als je voor ieder model een eigen query gaat uitvoeren ben je nogal inefficiënt bezig.
 
Lasse

Lasse

20/02/2008 20:31:00
Quote Anchor link
Stel ik heb een klasse Topic, en daar wil ik alle Posts van hebben. Dan roep ik toch een method van Topic aan, en die gaat alle informatie uit de database halen (zo heb ik het tenminste geleerd). En aangezien Topic onder het type Model valt...
 
Jelmer -

Jelmer -

20/02/2008 23:56:00
Quote Anchor link
Ik gebruik de database soms vanuit mijn controllers redelijk direct om een wat geavanceerdere query te draaien. Bijvoorbeeld een overzicht van de laatste tien posts van persoon a, die gepost zijn in een topic waar persoon b ook een post heeft geplaatst. Aangezien die query maar op 1 plek wordt uitgevoerd vind ik het zelf niet nodig om hem op te nemen in een method in een of andere factory (die je models opzoekt) mede omdat hij zo specifiek voor dat ene probleem is.

In mijn IHGApplication initialiseer ik een zootje klassen. Helpers, registery, identificatie, configuratie. En dus een database-verbinding (onderdeel van configuratie :) ) Vanuit de IHGApplication instantie wordt dan de URL omgezet in een aanroep naar een Controller-klasse & method, met argumenten. Bij het instantiëren van de controller geef ik de instantie van IHGApplication mee, zodat ik binnen de controller de helpers, configuratie en database e.d. kan gebruiken.

Vanuit de controller wil ik nu bijvoorbeeld 10 personen met een L in de naam opzoeken. Dan maak ik daarvoor een SQL-query, en die prop ik in mijn aangepaste PDO::prepareFor. Als 2e argument geef ik een model waarin de resultaten moeten worden gestopt mee. PDO vraagt nu mijn 10 mensen op, en maakt daar 10 instanties van mijn model voor aan. En geeft bij het aanmaken een verwijzing naar zichzelf mee, zodat ik binnen de models ook een verwijzing naar de goede database heb. Ze komen er immers net uit!

Voor vaker voorkomende queries, bijvoorbeeld 'vind model waarvan primary key = a' gebruik ik wel een simpele aanroep naar het model, maar op zo'n mannier dat de 'factory' eerst wordt aangemaakt door de controller (via een parent-klasse met dit soort handige methods) die dus weer de instantie van de huidige database kan meegeven. $this->models->Persoon->findById(14); Via __get kan je een heleboel gemene trucjes uithalen :) Weer wordt de data via de PDO instantie van IHGApplication (via de controller) gebruikt, en dus weer krijgen alle models een verwijzing naar de database. Dus ik zou in een model Topic nu gewoon findPosts kunnen maken, hij heeft al toegang tot de database.

Let overigens wel op dat je niet alle SQL wilt weglaten of genereren. In mijn idee is dat niet echt handig achteraf. Het staat misschien wel netjes, en in het begin levert het kortere code op, maar wanneer je nu een extra veld wilt selecteren, of een JOIN erbij wilt maken, of een iets ingewikkeldere WHERE-voorwaarde wilt opstellen gaat dat echt enorm onhandig worden. Daarnaast veranderen de queries amper, en is het dus eigenlijk overbodig om ze iedere keer opnieuw te genereren. Wat wel een goeie gewoonte is is om de veelgebruikte queries in methods van een soort factory onder te brengen, zodat je gemakkelijk deze queries kan aanpassen en verbeteren, en je niet gaat kopiëren en plakken. Zodra je dat gaat doen, gaat er waarschijnlijk iets mis. Knippen en plakken is daarentegen weer wel een goeie handeling, want dat betekent dat je constant je indeling zit door te rekenen en te verbeteren ;)

edit: jezus, kan ik serieus geen korte posts meer schrijven tegenwoordig?
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
 
Frank -

Frank -

21/02/2008 01:48:00
Quote Anchor link
Quote:
Daarnaast veranderen de queries amper
Gebruik voor dat soort zaken een VIEW, dat maakt de SQL in je PHP-code een heel stuk eenvoudiger.

Daarnaast is een VIEW eenvoudiger te optimaliseren, hier zijn prima indexen op te maken, je weet dat ze niet zo maar veranderen. Dit komt de performance zeker ten goede.

Met VIEW's kun je eveneens de rechten op de database beter gaan regelen, dat zorgt weer voor meer veiligheid, ook altijd een belangrijk onderwerp.
 
Lasse

Lasse

21/02/2008 12:15:00
Quote Anchor link
@jelmer: Je hebt inderdaad een punt als je zegt dat je 'speciale' querys uitvoert in de controller.

Maar jij werkt waarschijnlijk met één index bestand voor je hele website, waar je dan de juiste controller in included? Persoonlijk houd ik meer van de aanpak dat je verschillende functies van de website ook echt onderbrengt onder meerdere rechtstreeks aan te roepen pagina's. Daarom zal ik dus die IHGApplication niet nodig hebben, want de controller staat gewoon meteen al in de pagina. En het initialiseren van services waar jij het over hebt kan dan gewoon in de desbetreffende controller gebeuren. Maar dat is denk ik maar net welke stijl je preffereert.

Dank jewel voor je uitleg... Daar heb ik heel wat aan.

@pgFrank:
Een view gebruiken is inderdaad ook een goed idee. Bedankt voor de tip!
 
Lasse

Lasse

25/02/2008 20:58:00
Quote Anchor link
Hier ben ik weer, met een ander probleem:

Stel ik heb de klasse Topic. Deze gaat een compositie aan met de klasse Post. Dat houd dus in dat de klasse Topic een variabele heeft met instanties van Post. Het probleem is nu: Wanneer haal ik welke data op uit de database...
Ik kan bijvoorbeeld meteen als ik een instantie van Topic aanmaak alle Posts ook uit de database halen. Dat met het risico dat al die Post instanties helemaal niet gebruikt gaan worden. Ook kan ik een specifieke post pas uit de database halen als hij ook echt nodig is (bv bij het aanroepen van $topic->nextTopic();). Het nadeel is dan dat ik allemaal aparte query's nodig heb, wat ook niet echt meehelpt voor de performance...

Hoe zouden jullie dit aanpakken? Alvast bedankt voor de hulp.
 
Jelmer -

Jelmer -

27/02/2008 08:45:00
Quote Anchor link
"Wanneer je ze nodig hebt" lijkt mij het meest logische antwoord. Ik zou een 'getter' voor je posts maken die de array met posts teruggeeft. Is de array nog niet intern geset, dan haal je ze op uit de database.
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
class Topic {
    protected $posts;
    
    public function getPosts()
    {

        if(is_null($this->posts)) {
            $stmt = $pdo->prepare nogwat
            $this->posts = $stmt->fetchAll();
        }

        
        return $this->posts;
    }
}

?>

Nu worden de posts alleen opgehaald wanneer ze voor het eerst nodig zijn. Daarna staan ze in het object zelf en is de database niet meer nodig.

Eventueel kan je nog een aantal en een offset als parameter meegeven aan getPosts, zodat hij daarmee een LIMIT-statement vult. Stel dat je dan een topic hebt met 100 posts en je wil er maar 20 weergeven, dan kan je die andere 80 ongeroerd laten. Het is dan wel handig om ook deze 2 parameters even op te slaan ergens, zodat je kan weten of je meer posts uit de database moet halen of dat de $posts-array vol genoeg is bij een volgende aanroep.
 



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.