Ontwerpen van een programmeervak

Vandaag is de laatste dag van een periode van twee weken, waarin bij mij thuis een dakkapel is geplaatst. Het eindresultaat ziet er prima uit.
Collegadocent Thomas de Boer (bij het vak SAO) kwam van de week met een aardige metafoor m.b.t. ontwerpen: hij liet een aantal schetsen zien van een ontwerp van een nieuwe betegeling en aankleding van zijn plaatsje en vergeleek dat met het eindresultaat: duidelijk grote verschillen. Datzelfde geldt voor onze dakkapel: het eindresultaat wijkt op een aantal plaatsen duidelijk af van het oorspronkelijke ontwerp (overigens wel steeds binnen de grenzen van de goedgekeurde bouwaanvraag).
In beide gevallen is de belangrijke oorzaak dat in het oorspronkelijke ontwerp niet met alles rekening gehouden is en bovendien wensen veranderen en situaties ter plekke soms net iets anders zijn dan oorspronkelijk gedacht.
Kortom: hoe goed het ontwerp ook is, de uiteindelijke implementatie zal dit ontwerp naar alle waarschijnlijkheid nooit voor 100% volgen.

En dat brengt me op de titel van dit stukje: ontwerpen van een programmeervak. Samen met Thomas geef ik nu ook het vak inleiding programmeren voor o.a. TBK-studenten. Dit vak is dit jaar compleet nieuw ontworpen. Gekozen is voor een OO-aanpak omdat dat beter zou aansluiten bij de menselijke perceptie van dingen, samenstelling van dingen, eigenschappen van dingen enz. Een ding uit de werkelijkheid wordt een object in Java, zeg maar.
Toch is het uitleggen hoe je volgens het OO principe moet programmeren niet zo eenvoudig: leg bijvoorbeeld maar eens uit hoe de main-methode in Java functioneert!
Blijft verder ook de vraag over, hoe gedetailleerd moet je zaken vertellen. Nu zit in het vak een hoofdstuk over arrays. Na de uitleg hierover kwam bij mij de vraag naar boven of uitleg over arrays eigenlijk wel in dit vak nodig is. In plaats van arrays zijn Vectors, Lists en andere structuren eenvoudiger in gebruik. Ik overweeg dan ook volgend jaar het hoofdstuk over arrays te laten vervallen en direct iets over bijvoorbeeld Vectors te melden. Zo leren studenten dat (zeker in OO) zoveel mogelijk hergebruikt moet worden en gelukkig is er al veel in de Java bibliotheken te vinden.
En zo zijn er meer zaken in het oorspronkelijke ontwerp, die al tijdens uitvoering aanpassing vereisen. Zo is het veel studenten onduidelijk wat de betekenis is van this (de aanduiding van het object dat de betreffende methode ontvangt). Het begrip super is zo mogelijk nog onduidelijker.
Een constructor in een klasse is ook zoiets. Wat geef je nu wel en wat geef je niet mee in de parameterlijst van de constructor?
De ideeën voor aanpassing van het ontwerp voor komend jaar liggen al klaar (en zo moet het natuurlijk ook met onderwijs geven).