This year I decided to switch up the lab where students first encounter the algorithm for finding the maximum value in an array. In the past, I’ve given them a Movie object that represents a film (title, genre, rating) and had them build a MovieTheater that contains an array of Movie objects and can tell you which of its Movies has the highest rating.
The problem was that the relationship between Movie and MovieTheater (a collection of Movies) isn’t immediately obvious. Maybe a MovieTheater is an object that displays Movies. Maybe a MovieTheater is an object that can match an AudienceMember with a Movie they’ll like. Who knows?
So I decided instead to go with a Song (still with title, genre, and rating properties) and a MusicPlayer. The relationship is much more obvious — everyone got that your MusicPlayer contains a list of Songs. We even agree on what that list is called: a playlist.
The vocab change was good, but it didn’t fix the fact that I was asking students to learn two things at the same time. First, there’s the algorithm itself — ingesting or generating the idea of one variable for the running maximum, another variable to hold the index of that max, and then the question of how to initialize those things properly. That’s okay. But then there’s also the concept of an array of objects, requiring us to access a property of the object in the array so we can use that property value for comparison purposes. Cognitive overload.
This double-whammy may be part of the reason people turn against the “objects-early” approach to CS education. It’s not like we can really get away from using primitives in a language like Java. The object-first way would have us embrace objects (and collection objects like ArrayList, and structures for traversing them, like the for-each loop) from the very start, so that the idea of a set of anything other than objects might seem strange. But to my thinking, objects themselves are more complex entities, comprising both state and functions, and they require a lot of boilerplate when we define them in Java — unless we use some kind of special programming environment.
This all seems a little contraptionary, and leads my thoughts back to TeachScheme, which I have been meaning to investigate since a bunch of people I respect, including Hélène Martin, have good things to say about it. The authors of How to Design Programs recently posted a draft of How to Design Classes and I’m looking forward to reading it more closely now that it’s public.