Praktisch voorbeeld public/private/protected
Ik ben OOP aan het leren. Ik snap de basis nu, maar kan me moeilijk inbeelden hoe het praktisch gebruikt kan worden.
Kan iemand een praktisch voorbeeld geven van hoe een visibility property bijvoorbeeld nuttig kan zijn?
Mvg
Lees de OOP-tutorial van phptuts.nl eens door.
Maar; het voorbeeld is daar private $username. Waarom zou je ervoor willen zorgen dat $username niet meer direct te benaderen is? Welk voordeel levert dat op? Beveiliging?
Gewijzigd op 23/08/2015 17:32:13 door Lorre Mertens
Hij is nu publiek, dus niks weerhoud ons ervan om hier lekker andere waardes in te gooien:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$blogPost = new BlogPost('De titel', $content);
$blogPost->tags[] = 'een string mag niet';
$blogPost->tags[] = $blogPost; // een blog post die zichzelf als tag heeft mag ook niet echt...
?>
$blogPost = new BlogPost('De titel', $content);
$blogPost->tags[] = 'een string mag niet';
$blogPost->tags[] = $blogPost; // een blog post die zichzelf als tag heeft mag ook niet echt...
?>
We hebben dus geen gecontroleerde omgeving meer binnen deze class. Wanneer we de property nu protected maken hebben weer een, voorlopig, gecontroleerde omgeving:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
class BlogPost
{
protected $tags = array();
public function addTag(Tag $tag)
{
// ... we kunnen hier bijv. ook controleren of de tag niet
// al was toegevoegd
$this->tags[] = $tag;
}
}
$post = new BlogPost('De titel', $content);
$post->addTag(new Tag('phphulp'));
$post->addTag('een string'); // Error: Expected instance of Tag, got "string"
?>
class BlogPost
{
protected $tags = array();
public function addTag(Tag $tag)
{
// ... we kunnen hier bijv. ook controleren of de tag niet
// al was toegevoegd
$this->tags[] = $tag;
}
}
$post = new BlogPost('De titel', $content);
$post->addTag(new Tag('phphulp'));
$post->addTag('een string'); // Error: Expected instance of Tag, got "string"
?>
We kunnen nu echter nog steeds de class extenden en verkeerde waardes toevoegen, dus maken we er private van zodat we erg echt zeker van zijn dat addTag() de enige manier is om tags toe te voegen aan de BlogPost.
Bedankt voor de heldere uitleg Wouter, het is nu veel duidelijker.
Het 'probleem' van een web-omgeving is dat PHP telkens eenmalig reageert op een verzoek van een browser. Dat is nogal procedureel en 'immer gerade aus'. Dan ben je ook nog eens de enige ontwikkelaar, en is het eigenlijk best wel handig dat je overal bij kunt. Private variabelen is dan gewoon onzin. Waarom zou je objecten in het geheugen vasthouden? Geen idee. Lukt ook prima zonder.
Als je deze weg blijft volgen loop je vanzelf tegen een probleem aan, ondanks hergebruik van code via include en require(_once) statements. Afhankelijk van hoe groot je programma wordt, wordt je code steeds meer spaghetti omdat je voor elk scherm weer andere code moet maken. Je kunt alleen nog maar snelheidswinst in programmeren krijgen door je eerdere code te copy-pasten. En als je dan bugs aan de ene kant gaat oplossen ontstaan ze weer aan de andere kant en vice versa. Het schiet niet op, je bent vastgelopen in je eigen denkwerk.
Om code uit elkaar te houden en gestructureerd (als een soort adresboek in familieboomstamvorm) is het concept van OOP geintroduceerd. Wat je dan doet is je code opdelen in zo klein mogelijke stukjes. Dat heeft als voordeel dat die stukjes heel overzichtelijk en foutvrij worden. Je zet die stukjes in een functie (methode) en je groepeert functies die samenwerken in een object. Als je de methoden benoemt naar wat ze doen, kan je je eigen code als een soort pseudo-code lezen, en wordt het voor jezelf volstrekt duidelijk wat de code precies in welke volgorde doet. Documentatie van code heb je dan bijna niet meer nodig.
Om variabelen binnen een naamruimte (namespace ;) qua naam en inhoud per functie gescheiden te houden, heb je een variabele scope met de keuze om variabelen private te houden. Zo van: 'die variabele is niet bedoeld om direct door andere code veranderd te worden', want dan weet je het op een gegeven moment zelf ook niet meer.
Naast dan OOP jezelf ontlast van de internals van je eigengeschreven code, geldt dat ook voor jou met code van anderen en andersom; je hoeft alleen nog maar elkaars API aan te roepen en je bent klaar. Dat vergroot de schaalbaarheid en onderhoudbaarheid van de code enorm. Daarbij worden de objecten/API's een soort zelfbedachte LEGO-stukjes, die niet als spaghetti maar met nopjes aan elkaar hangen, je kunt de code eenvoudig vervangen voor andere code die dezelfde nopjes heeft.
De praktische voorbeelden volgen vanzelf als je code schrijft.
Bedankt An tje, erg waardevol antwoord!