I often think of my favorite quote that seems to apply to so many subjects:
Good judgment comes from experience, and experience comes from bad judgment.
I don’t know who originally said it, but you know whoever it was had walked the walk.
Anyhow, for the past couple of weeks, I have been a substitute teacher in an AP CS A class, where the students have no prior exposure to programming. Whether or not it was a good idea to teach the AP class as an introduction to programming, it is what it is. I have been tasked with teaching the students more about OOP, while earlier on, they were introduced to classes and objects. The students in general have a good technical knowledge of the terms and syntax, but I’ve come to realize they really have no practical idea of why they are important or useful. This made me think of the expression above. So what can one do about it?
Because the students have no practical experience with seat-of-the-pants development, or they really don’t have much experience with ‘bad judgment’ in designing programs and the messes that one can get into if not careful, it is hard to appreciate why it is important to start using an OOP perspective. All the example programs so far have been fairly trivial, so the students can’t learn for themselves the missteps that thinking in an OOP way can be avoided.
So how does one expedite the bad judgment part so the students have the buy-in that an OOP approach can help them (to motivate their learning)?
I would love to hear suggestions from teachers in any subject about how to instill the need for a better approach without miring the students in bad habits/practices. My approach to expediting ‘bad judgment’ is to let them choose their own projects, but watch them carefully and discuss the directions they’re choosing so I can put them on a good path before they devolve too far (just enough to show the looming dangers). This involves a lot more effort and attention, but I’m really lucky that I have fewer than 10 students.
To get a sense of where the students were coming from, I thought I would asked them directly in a 20-minute assignment:
Why do you think we want to teach you about Object-Oriented Programming?
Here is the follow-up post I wrote to the class:
As a recap, I really wanted to stress that you should always strive to know why you are doing something - you may not always agree or understand the reason, but you shouldn't be afraid of asking why. Many of you felt that teaching object-oriented programming (OOP) was learning to code in general, or about learning to control computers. As we discussed in class, this isn't true, but I do like your enthusiasm and willingness to take a risk in your response. Object-oriented programming is a style of programming, but not the only style. I think it is generally believed to be a positive way to approach problem-solving, but not the only way. If there is a 'right' answer to my question (which there really isn't, because I asked the question merely to see how you would respond, how you perceive what we're teaching), it would be that we believe that OOP is a constructive way to promote re-use, ease of collaboration, and correctness in programming. That is not to say if you use OOP your programs will be reusable, easy to use, or correct -- you can just as easily abuse OOP and use it to produce incomprehensible and error-ridden code. However, most of the time, you are going to be writing code with others or for others, so making it clear is absolutely important.
Strictly speaking, here are four main principles of OOP (in no particular order) we reviewed:
- Encapsulation: hiding of data implementation by restricting access to accessors and mutators
- Abstraction: development of classes, objects, types in terms of their interfaces and functionality, instead of their implementation details
- Inheritance: classes inherit behaviors and characteristics
- Polymorphism: multiple methods with the same name.
These may not make great cocktail party conversations, but it is a good idea to think about practically what they mean, and by all means, please ask me 'why' if it's not clear. If you wrote your programs completely for yourself (which is almost never), and no one ever would have to develop with your code, it doesn't really matter how you do it -- though you want to write in a style that at least you can understand easily if you have to modify it later, as well as a style in which you let the compiler's precision help you find errors. Even then, using OOP techniques, you can have the compiler help you catch errors before you discover them in your code. The whole purpose of types (what they call 'strong typing') is to help you catch mistakes so they don't get lost in the sea of code (imagine potential errors that can creep into a program that is 1000 lines long, not to mention 100,000's or millions!). I think you've been learning technical words and commands, but without applying them so much. You know a lot already. That's why I want to devote the next couple of weeks to help you apply the concepts of classes, objects, etc. through your own projects. I can't stress enough that I want to help you get practical experience with programming, so email or call me whenever and in however way I can help you.