"... jumps right in with object-oriented programming, applets and even basic graphical user interface design from Chapter 1! People tell us this is a gutsy move. But Java students really want to cut to the chase. There is great stuff to be done in Java so let's get right to it!" (1)
Even though this course is not a designated introduction to programming Java, the above quote accurately describes the intention behind this course: students neither want to be bothered with the history behind how object oriented programming developed nor do they want to be bored with the underlying theory from square one. Instead, we want to "cut to the chase" by introducing the essence of OOP and by presenting motivating graphical programming examples. This does not at all lead to a theory-deprived student. Important concepts of OOP are presented, but implicitely and by example, rather than as a primary focus.
Many OOP courses are structured to teach topics incrementally, while requiring students' homeworks to reflect on only these topics.
"A frustrating aspect of many courses is that teachers can only give introductory examples and exercises, so that students do not get to work on really interesting applications. One can only get so much excitement out of computing the first 25 Fibonacci numbers, or replacing all occurrences of a word by another in a text -- two typical exercises in an elementary programming course." [(2), 'Progressively opening the black boxes')]
As part of the original research of this project, I have tried to incorporate a different technique, in which students use much more advanced programming methods right away but that are explained later in the course. These more advanced methods are placed in templates that students use for their homework. This way, I would hope for early projects to not seem too boring or plain. Moreover, once the course catches up to the advanced topics, students will already have been exposed to the usage at some point. This approach does have the disadvantage of overwhelming the student. However, using good code/template placement, this may not become too large of a problem. Some of the template code can be hidden in separate classes.
"With the object-oriented method, a good object-oriented environment and, most importantly, good libraries, a less traditional strategy is possible if you give students access to the libraries early in the process. In this capacity students are just reuse consumers, and use the library components as black boxes in the sense defined above; this assumes that proper techniques are available for describing component usage without showing the components' internals. With this technique students can start building meaningful applications early: their task is merely to combine existing components and assemble them into systems. In many respects this is a better introduction to the challenges and rewards of software development than the toy examples that have been the traditional mainstay of introductory courses. [(2), 'Progressively opening the black boxes')]
Such an example has been worked out as part of the lecture notes, and can be viewed under lecture 6: "Using pre-defined objects". Here, students use a Java tool to learn about methods in AWT objects/components. Later on, they are presented with a bare-bone Java file, to which students are to amend code. Since the demo portion of the applet has been placed in a separate class, it does not interfer with the clarity of the template code.
After some more background / original research, I became convinced about the introducing of graphical tools that students use to learn about certain topics as part of their homework. The concept behind these tools is rather simple, yet not trivial to implement. Such a tool must be simple and fun to use, highly graphical in order for it to be interesting and motivating, yet it must convey concrete knowledge by experimentation. More specifically, each tool needs to be designed in a very general way, so as to allow the student to experiment with it to learn the right, and more importantly the wrong way of doing something. Evidently, each of these tools takes much time to develop in both its conceptual as well as its developmental context. By no means have I implemented a series of these tools, yet I have provided an example for lecture 4: "Basics of Programming". With this tool, students can experiment with data types and casting of 4 different types. I have attempted to develop this tool following the previously outlined rules.
This very approach has already been used by CS1001 (3) as a supplemental exercise set taken from the textbook's publisher (4). The tools presented therein were pertaining to more general computer science topics, e.g. Turing Machines and Simple Digital Logic, but there is no reason as to why they could not be developed for an intro to OOP course. I can very well imagine such tools becoming a solid part of lecture and homework.
Following the introduction is a series of 15 or so lectures that dive into the heart of object oriented programming using Java AWT in applets. The series of lectures is broken into segements, each of which gives a different perspective to objects in OOP, while teaching the main parts of the AWT library.
The first and largest segment concentrates on building some fundamental knowledge. Firstly, students use already existing graphical objects in applets, so as to learn about objects and methods. Thereafter, the students' knowledge about objects is extended by means of using existing objects to create their very own objects. This implicitely teaches about inheritance, one of the major conepts in OOP.
The second segment consists of teaching polymorphism, yet another major concept of OOP. Again, this concept is implicitely introduced while teaching about Action Listeners.
At the end of these two segments, the student should have enough knowlegde to create an applet with several embedded interactive features. This is also a good breaking point for a midterm examination.
In the third segment, the student's knowledge about OOP is further strengthened by introducing a very powerful and fun object, namely the Graphics object. The Graphics object is a very good example of an intricate object, that has been made very easy in its usage by means of methods. On top of that, it provides the type of visual pleasure that deviates so nicely from text-mode interaction.
In the next segment, we finally introduce data objects. By now, students should well understand the concepts behind OOP, so that this particular non-visual topic can be digested without much complication. No matter what though, this very topic is so essential in providing all of our visual user interfaces some meaning in terms of data supply.
The fifth and final segment discusses exception handling, where even exceptions themselves are objects. In a sense students are again reminded of the role of objects in OOP.
The course concludes by presenting three more lectures on how to deal with some of the logistics of Java, that is the on-line Java documentation reference, debugging, and a look at other Java technologies so as to interest the student in some of the exciting oportunities in this field.
Like most courses, this one finishes off with a final exam.
The number of outlined lectures is somewhat less than what is expected for a semester, reason being that I am leaving a buffer region for the possibility of some lectures needing more than the alotted time.
(2) Towards and Object-Oriented Curriculum / B. Meyer -- http://www.eiffel.com/doc/manuals/technology/curriculum/page.html (3) CS1001: Introduction to Computer Science, Columbia University, School of Engineering and Applied Science: Spring 2001, Andrew Miller
(4) The Analytical Engine / R. Decker, S. Hirshfield -- http://www.brookscole.com/compsci/aeonline/course