OOP Beginnershandleiding (PHP5)

  1. Inleiding
  2. Object geörienteerd denken
  3. Foute denkwijze
  4. Object georiënteerd programmeren
  5. Visibility
  6. Naamgeving
  7. Constructor __construct()
  8. Voorbeeld: HTML tabel
  9. Inheritance
  10. Voorbeeld: HTML tabel 2 (inheritance)
  11. Static methods en properties
  12. Abstract classes en Interfaces
  13. Magic methods
  14. Slotwoord en referenties
  15. Reacties op deze tutorial

Foute denkwijze

Veel programmeurs denken vaak: class == OOP. Voor de volledigheid, een class is een blauwdruk van een object. Dus het beschrijft hoe een object gemaakt gaat worden, maar het is op zichzelf geen object. Daarom maak je dus instanties van een class, die instanties noem je objecten.

Laten we eens kijken naar een abstract voorbeeld van een class die niets met OOP te maken heeft:
Code
1
2
3
4
5
6
7
8
+ Gastenboek
  - getReacties()
  - insertReactie()
  - printReacties()
  - editReactie(...)
  - getUsers()
  - createUser(...)
  - nextPage()

Nu denk je misschien: hoe kun je nou zeggen dat dit geen OOP is zonder te zien wat het doet? Simpel. Je ziet aan de namen van de methods al direct dat ze:
  • reacties ophalen en invoegen
  • één reactie kunnen wijzigen
  • users kunnen ophalen en aanmaken
  • iets met een volgende pagina kunnen doen

Je zou hier dus sowieso al te maken krijgen met de objecten Reactie en User aangezien er methods tussen zitten die specifiek de eigenschappen van een van deze objecten beïnvloeden. Je zou zeggen dat je ook het object Page krijgt, maar de pagina is slechts een eigenschap van het Gastenboek of zelfs gewoon een tijdelijk iets.

Aan de functienamen kun je dus meestal herkennen dat het geen goed object is. Daarnaast kun je het vaak herkennen aan het aantal regels code. Veel objecten bestaan echt maar uit maximaal 100 regels, meestal een stuk minder. Dit komt omdat elk object slechts z'n eigen functionaliteit definieert en verder alles aan de andere objecten overlaat. Je zult ook zien dat je dan heel weinig if/else statements krijgt en weinig loops en dergelijke. Uiteraard zijn er ook classes te vinden die meer dan 100 regels code bevatten, maar over het algemeen moet je de opbouw van je class nog eens overwegen als die uit honderden regels code bestaat.

Elk zelfstandig naamwoord is een object
Fiets, Plant, Gastenboek, Reactie, Formulier, Gebruiker, SMS, Connection, Filter, Validator, etc. Meestal zie je aan de naam van een class al of het kans van slagen heeft. Als je een class Reacties hebt dan hoor je al aan de naam dat dit niet één object is. Dus geen object. Nu worden dit soort constructies in de praktijk wel gebruikt om meerdere Reactie-objecten in te bewaren (die bijv. uit de database komen), maar dan komt dat terug in de naamgeving van die classes. In dit geval zou je dan bijvoorbeeld een Reactie_Store, of iedere andere variant die aangeeft dat het object meerdere Reactie objecten kan bevatten.

Vorige Volgende