Hi all, There's an interesting article called Extreme Teaching: Introducing Objects by Daniel Steinberg available at Java.Net about teaching OO, specifically Java. He strongly recommends a "FIT" framework by Ward Cunningham, one of the inventors of Extreme Programming. It provides a way to foster more "object oriented" thinking. See the article for details. As an alternative, I've seen people use the BlueJ IDE as a way to demonstrate OO principles. It's very nice, and worth a demo. I find, however, that all of those somewhat contrived development environments are great for the basic principles, but don't scale well at all. Students like them at first, but they have to abandon them pretty quickly, making the students wonder whether they were worth the initial learning curve. For a basic OO class, they're very good though. Does anybody have any experience with these tools? Has anybody read the article? Ken
Jess (the bartender, not the book) and I attended the BlueJ talk at JavaOne. It seemed pretty interesting and useful. BlueJ is like a very basic IDE. I think the visual representation of classes works quite well with the concept of OO and so is useful for teaching. (For those not familiar with it, tThe reason it's a very basic, almost trivial, IDE is so students don't get lost in bells and whistles--it's not to be used for real development.) I would also agree with your assessment that students quickly outpace it--probably after 4-8 lessons. It almost seems like, instead of one tool for a class, there should be a series of different tools for differnet lessons. BlueJ is great for the generic "this is what OO is about" big picture. You'd need another tool for language grammer, and another for "putting stuff together." This latter tool might be very similar to BlueJ, but a bit more advanced; introduced only after the students have mastered BlueJ. --Mark
IMO (I'm no teacher) apart from demonstrations no tools should be used that force students away from the code during programming lessons. During theoretical courses on OO concepts and design they are OK, as they prevent students from getting bogged down in code trying to grasp the concept (but again, make sure you don't end up teaching the tool instead of the course subject). Too many people enter the market who know some tools but have no grasp of the programmin language itself. If they need to work in another IDE (or no IDE at all but a basic editor) they're completely lost because the wizards and code templates aren't there. The same would be true of design courses relying too heavily on a tool. If the students spend more time learning the tool than learning the process (the what instead of the why) they're useless when put into a production environment where the tools are different. Start with having them write it all out on paper. You may require a textual representation even as part of assignments so you can check that they know WHY they do X (and don't just do it 'because the teacher said we should'). Some of your students will hate you for such an approach, but they're the ones who weren't motivated properly anyway and would likely have dropped out sooner or later (or cheated their way out). The truly motivated students will become better professionals as a result.
no tools should be used that force students away from the code during programming lessons. Probably true. But if the lesson is actually about design, and not about programming in any particular language, then the less language-specific clutter to deal with, the better. If I'm trying to get over something like the idea of refactoring or the single-respnsibility principle, I don't want to be messing with classpaths and whether the source files have lower-case names.
I agree with nearly all of what Jeroen says about this... except for the "some will hate you". Although that's probably true, I believe my mission is to try as hard as I can to motivate them and put a spin on it in some way. I'm a big advocate of (most of the time) keep the tools out of the way, although what Frank said about keeping the "language issues" out of the way is also true in some scenarios. Maybe it comes down to, keep *anything* which gets in the way of the key objective you have at that moment, out of the way. As for teaching OO, we had so many endless debates about this at Sun -- objects first vs. not, object visualization tools (like BlueJ, only we had our own) vs. not, etc. There were heated and passionate debates from all sides, but the bottom line was that a good teacher could do it in just about any way they wanted, and the result was still really successful. In other words, teacher A would teach OO first, which teacher B would claim is just horrible because the students needed to at least get their hands dirty and feel in their comfort zone with, "Oh, Java is easy -- this looks just like every other loop I've ever done...)" while teacher A would claim that, "If you don't start them with objects first, they'll be in procedural land forever". I felt that both sides were valid, and that either can work, and that there is a happy compromise. Also, a good teacher using objects first can help them feel comfortable and engaged right away, and a good teacher using procedural code first can easily transition them to objects without having done permanent damage! I spent more than a year on Sun's quality review board for our instructor-led training, and evaluated the scores (student evals of the instructors) for every single Java class taught in north America. I was completely unable to find a pattern that said, "Objects first gives better results" or "procedural first gives better results". It all came down to how the class was really taught, and how the teacher 'positioned' OO, regardless of where it actually appeared in the course. (well, within reason. Obviously, and "objects last" approach would never work!) In the Head First Java book, we took a hybrid approach -- a quick dive-in chapter one, for folks who just have to get their hands dirty right away and demystify the whole thing, but then a heavy jump into objects beginning with chapter 2. Then back to basic language stuff, then another chapter on OO, etc. This approach seems to have worked very well for most folks -- and even though we did NOT do objects first, nearly all reviews of Head First Java mention that the best thing they got from it was the OO perspective. But, I don't have a religious view that says this was the only way to have done it. I think we could easily have begun with objects, or even begun with three procedural chapters, and if handled correctly, no permanent damage would have been done. Perhaps it DOES matter, though, that whether you teach objects first or later, you DO emphasize the true importance of objects/polymorphism/interfaces, etc. I have seen too many books that go over all the technical aspects of OO, but really don't seem to offer inspiration about its true beauty, power, and importance. In that case, simply putting objects first would not make all that much difference, Yes, putting it first gives them the OO frame of mind from the beginning, but I think its more about HOW you do it. Bert and I have talked about this with Ward Cunningham and Dan Steinberg, and they've definitely shared our view on that, with respect to the Head First Java book, anyway. Anyway, back to my starting comments about motivation -- I think there is a big difference when you are teaching in a corporate, paid environment than in a school situation. When people are paying $3000 a week to take a class, they damn well have an expectation that they will not just like it, but love it. If they hate it, they walk and take their money elsewhere, so we have to be entertainers, extreme customer-service reps, sales people, marketing people, etc. all while teaching a class. This is definitely a different feeling from when I taught at UCLA. True, I still wanted my students to feel motivated and enjoy the class, but at UCLA I was able to focus more on what I thought was *good* for them rather than what *they* thought was good for them. In that corporate IT training world, it seems you have to work harder to find the right balance. In fact, one of the courses I taught at UCLA was how teachers could use sales, advertising, and marketing training to improve their courses. Madison Avenue spends millions and millions of dollars on knowing how to motivate someone -- often within just 30 seconds. We can learn a lot from their work and research. Giving students a reason to appreciate a particular topic certainly helps motivation, and has been proven to help understanding, retention, and recall. But helping them discover that reason for themselves is even better... I often fail miserably, but this is always my goal. I think it's just about the only thing that has saved my butt, because otherwise, I'm not that good a teacher in any classical sense.