Refactoring OO

Refactoring the Teaching of Object-Oriented Programming

W. Gardner, R. Sutcliffe, and D. Ariel

Department of Computing Science
Trinity Western University, Langley, BC
{wgardner, rsutc, dariel}@twu.ca

Abstract

In expanding on the base of our established Applied Mathematics with Computing degree program to create a distinct degree in Computing Science, we wanted to build on strength--to expand, complete, and professionalize our course offerings. However, for pedagogical reasons, we wished to continue teaching beginners using procedural paradigms. We already had a Java course, but not one in C++ (another perceived necessity). We wanted a framework to accommodate both without duplication, and to be versatile enough to use other OO notations instead of or in addition to these two. Our solution was to refactor the material into separate components--the common theory and the notational-specific practice. This paper reports on our motivations, experiences, and conclusions.

Keywords: object-oriented programming, team teaching, C++, Java, pedagogy

1. Introduction

Computing science at Trinity Western University, a Christian liberal arts institution near Vancouver, Canada, has a history in the Department of Mathematical Sciences going back to 1983, originally in a combined degree with applied mathematics. In 1997, we commenced offering a specialized B.Sc. in Computing Science, and expect on the basis of current enrolments to be graduating 20-30 students a year in the future.

In the earlier curriculum we emphasized procedural programming, with object-oriented programming (OOP) being taught in third-year courses entitled "Advanced Programming," and "Programming Languages." However, since the ability to use C++ and Java is routinely expected of graduates now, and since we desired to reorient our software engineering courses around OO methodologies, we wanted to move OOP to an earlier, more prominent place in the curriculum.

This paper relates our experience with a new group of team-taught first-year courses in OOP. It begins with a brief rationale for our keeping OOP in the "second language"category, in contrast to the practice at many schools. We then describe the details of what we call our "refactored" curriculum, plus the results of a student survey, and consequent plans for improvement. We hope that our experiences may assist others who are searching, as we are, for optimal ways of teaching OOP.

2. OOP In a Second Language Course

2.1 Educational Strategy

We believe the purpose of the university computer science curriculum is the preparation of well-rounded, integrated, goal-oriented, competent, professionals ("software engineers"). To this end, students need to be taught with sound pedagogy to use proven and applicable problem-solving tools, and in such a manner as to be themselves versatile and adaptable professionals in a rapidly changing environment.

Students entering a first year university program have a wide variety of backgrounds. It is our (subjective) perception that this is a broader span than, say, a decade ago. More students arrive self-taught, or, having had some informal coursework, usually in a subset of C++. At the same time, more arrive with minimal exposure to problem solving with computers, as few British Columbia high schools teach programming.

Few freshmen (and not many transfer students) have any concept of problem solving, of planning a program, of programming paradigms, of writing for readability and re-use, or of documentation skills. At best, they arrive as "hackers", knowing a few tricks of one particular programming notation, but with no idea that computing science consists of anything beyond throwing together a few lines of non-reusable code to meet short-term objectives. Thus, for all practical purposes, nearly all must start from square one with the most basic concepts--in many cases unlearning numerous bad habits.

It is therefore necessary to begin with the teaching of a discipline of good problem solving habits, and to do so in an environment where the tools assist the process, rather than hinder it. That is, introductory computing courses must be about using a computing system efficiently and effectively as a problem-solving tool; not about the details of a particular programming notation.

Most professionals will be handed programming tools and languages they have never seen before and expected to master these in short order without breaking stride in software production. Thus, we believe, they need to be familiar with a variety of languages and operating systems by the time they graduate. This suggests that beginning with the most teachable notation for the introductory course, and shifting to others (as course material dictates in later years) is a sound strategy.

2.2. The Language Question

The perennial problem of choosing the most appropriate beginning programming notation has long sparked periodic outbursts of the "language wars" in computing science departments around the world. There are many ways to evaluate notations for this purpose, but most would include points on what we call the ASTIM scale:

Applicability

	To what extent is the notation used in the "real" world?
	Is it complex enough to solve real-world problems?

Standards compliance

	Is the notation the subject of a complete ISO standard?
	Can source code in the base notation be used cross-platform with a re-compile?

Teachability/learnability

	How easy is the notation to teach to beginners?
	Is it simple enough to master in a semester?
	Do notation rules and typical implementations provide assistance to the beginner, or do they hinder the learning process?

Implementability

	Are good textbooks available?
	Are standard-compliant implementations available cross-platform?

Modern features

- separate compilation of libraries
- the ability to separate definition and declaration (implementation)
- object oriented paradigms
- generics

Are modern abstraction features available?

No one notation meets all the requirements, and for this reason computing science departments show little inclination to standardize on any particular one for beginning instruction.

We believe the first course should deal with standard programming abstractions: sequence, selection, repetition, and composition, (confining the latter to functions, procedures, and libraries, rather than introducing class types.) Despite the notation's other drawbacks, this means Modula-2 [1] is our first choice. Ada would be the probable runner-up.

Afterwards, it makes sense to have a second course in programming in a suitable language for focusing on the object-oriented paradigm. Since the introduction of notations and their features is a relatively low level task, we decided to position the OOP courses in the second semester of the first year.

3. The "Refactoring" experiment

Our first attempt to move OOP from the upper-level course context was to offer second-year CMPT 241 (Java) for two semester hours of credit. While this is sufficient credit for a second-language course, we found two hours a week too little time to cover the material from a high-level (theoretical) view. So often, when operating in a rushed mode, one teaches just language syntax, not programming principles and practice. We were therefore unsatisfied with the 2-credit approach.

At the same time, we also had demand for a course in C++. Yet there was clearly significant overlap in the two languages, and it seemed a pity to go over the same ground twice by mounting separate courses in the typical watertight compartments. Since we had no great stake in the status quo regarding OOP, it was tempting to try a fresh approach.

3.1 Advantages of Factoring out the Theory

This train of thought to the idea of refactoring: extracting the common elements of the languages into a "pure" OO seminar (naturally dubbed the "base class", while teaching the language-specific features in separate sessions. We achieved this by demoting the existing Java course to first year status, paralleling it with a new C++ course, and extracting the common factors in a separate theory course.

Students learning Java would take CMPT 167, "Introduction to Java," and CMPT 160, "OO Seminar." Those learning C++ would take CMPT 165, "Introduction to C++," and the same CMPT 160. Since these were scheduled on different days, students could, in principle, enrol in all three courses and study both languages concurrently.

This approach appeared to present a number of advantages:

(1) Efficiency

We hoped to avoid repetitive teaching (and the students studying) of foundational OO concepts. The Java and C++ instructors could assume the necessary foundation had been laid by the seminar class, and restrict themselves to teaching the language-specific application of the basic OO principles. Students also would benefit from the efficiency, for they would not have to go over old ground if they decided to take a second OO course.

(2) Pedagogy

We hoped that by learning the foundational OO concepts in a separate class--the OO seminar--students would better grasp that these are indeed generic principles and not think of them as just the peculiar features of a particular language. This fits our overall philosophy of teaching for the retention of high-level, adaptable programming patterns for professional practice rather than for the memorization of a multiplicity of specific, detailed, low-level minutiae from particular notations.

(3) Pattern Reusability

We desired to provide a "substrate," as it were, into which additional OOP courses (e.g., Smalltalk) could be plugged in the future, should this prove desirable. We felt this would:

- help build up our curriculum,

- give us flexibility to make the inevitable changes that come with the passing fads of the discipline,

- allow us to offer "packages" of "pluggable" course modules consisting of one, two or three notational offerings at a time.

3.2 Team Teaching Strategy

3.2.1 The Team

The three courses and instructors were deployed as follows: CMPT 160 (Object Oriented Seminar) [theory; one semester hour; one hour lecture Fridays] was taught by Rick Sutcliffe, Professor of Mathematics and Computing Science, a long-time teacher, language specialist, and participant in ISO standards, who is also the Academic Computing Coordinator at Trinity Western University, and has shepherded the computing program from its beginnings in 1983.
CMPT 165 [C++; two semester hours; two hour lecture Wednesdays] was taught by Bill Gardner, Assistant Professor of Computing Science, who is also responsible for courses in software engineering, databases, computer hardware, and embedded systems.
CMPT 167 [Java; two semester hours; two hour lecture Mondays] was taught by Don Ariel, Professor of Mathematics and Computing Science, who also teaches Artificial Intelligence (using Prolog), Modelling and Simulation, and applied mathematics.

3.2.2 Course Schedule

Utilizing the notion of refactoring, it was not difficult to come up with a strategy for scheduling the courses. We decided the semester would be organized in three phases: Phase I: In the first phase, the OO seminar would begin teaching OO concepts such as class types and objects. Meanwhile, language instructors would be rapidly covering procedural elements that could be taught by analogy to the students' first language. This is easy to do in C++ of course, where only syntax need be covered, but more difficult in Java, where object ideas are integral to everything.
Phase II: When enough foundational concepts had been laid down, the second phase would commence with the language instructors shifting gears into their respective OO constructs. During those weeks, the students would hear principles explained in the OO seminar (with sketchy examples in several languages), and then days later, see the same concepts fleshed out in one or both languages.
Phase III: A third phase was planned in recognition of the fact that C++ and Java have important distinctive features, for example, templates and the extensive built-in class libraries, respectively. This phase was reserved for teaching these features, meanwhile giving the seminar instructor an opportunity to explore more esoteric OO topics that might not be well-represented by either Java or C++. In this latter phase, such ideas as the MVC model of Smalltalk and the meta-concept of (design) patterns could be covered in the seminar, while the other instructors went into the unique methods and features of their respective notations.

What follows is the schedule given to students as the tentative course outline. With only minor exceptions involving some carry over of topics from one week to the next, all three instructors were able to adhere to this schedule.

Wk	160 / OO Seminar (Fri.)	167 / Java (Mon.)	165 / C++ (Wed.)
1	-	-	Elements of C++: source files, preprocessor, & development environments; variables, builtin types, assignment, operators, simple text I/O; control structures
2	Basic OO concepts: vocabulary, declaration, classes, objects	Variables, builtin types, assignment, sequence, decisions, loops	Functions & simple exceptions: prototypes, enum, storage classes, function overloading
3	Members, access, exceptions	Arrays, references, function calls	Arrays, pointers, strings
4	Rudimentary OO design	Text I/O	Structures, typedef, bit & character ops
5	Constructors, destructors, garbage collection	Classes, objects, access control, garbage collection	Classes & objects: members, access control, constructors, destructors, "this" pointer, const & static members, operator overloading, friends
6	Constructors, destructors, garbage collection	Classes, objects, access control, garbage collection
7	Inheritance	Inheritance	Inheritance
8	Inheritance (cont.)	Interfaces & midterm exam	Multiple inheritance & midterm exam
9	Virtual/abstract methods & classes; polymorphism	Abstract classes	Virtual functions & abstract classes
10	MVC architecture	AWT & Swing	GUI in C++: MS Foundation Classes, document/view architecture, event loop
11	Object persistence	File I/O
12	Component architectures	JavaBeans	Stream and file I/O
13	Design patterns	Useful class libraries	Overview of COM Templates & Standard Template Library
14	OO strategies	-

3.2.3 Assessment

Having factored the material into three courses, we were then hesitant to have this result in students writing three sets of exams. Therefore, we decided there would be no exams in CMPT 160, but that its material would be tested in the exams for the other two courses. Moreover, the letter grade reported to the registrar in CMPT 160 for transcript purposes would be equal to the letter grade obtained in the respective language section that a student was taking. (Someone taking both languages would get the average mark of the two for CMPT 160.) As will be seen below, this innovation was not particularly successful in the students' view.

3.3 Course Distinctives

Within the refactoring philosophy and schedule phases described above, each instructor still had the freedom to choose resources and deal with programming assignments however they preferred. These distinctive features are described in the sections below.

3.3.1 OO Seminar

Prof. Sutcliffe did not require students to purchase a text, but prepared his own lecture notes as overheads and made them available online [2]. The seminar gave no assignments nor exams--both were left to the language courses. In-class reaction of students varied. Those with some prior knowledge of the concepts participated in discussion that was at times spirited and vigorous, but those relatively new to programming struggled with the theory, even during those portions of the course where it was illustrated with specific notational examples. Important references to the theory of OO programming are [9] and [10].

3.3.2 Introduction to C++

Prof. Gardner chose a popular C++ text by Deitel and Deitel [3], bundled by the publisher with Microsoft Visual C++ 6 and an accompanying textbook [4] for little more cost. This was the same version of VC++ that was installed in the school labs, which made it possible for most students to do the assignments at home. As we adhered strictly to ANSI C++ (except for a unit on Microsoft Foundation Classes), students could alternatively telnet to our Linux host and compile with GNU g++. Some installed Linux on their own computers for this purpose.

This textbook's topics were ordered roughly the same as our 3-phase schedule, so it was eminently suitable for a C++-as-a-second-language course. The book has good value as a language reference, so it will be useful to the students for several years to come. It also includes a detailed introduction to the Standard Template Library (STL), which was touched only lightly in class due to most of the students' not yet having taken our second-year "Data Structures and Algorithms" course. In the instructor's experience, too many books on STL suffer from being written at an excessive level of abstraction, and are hardly useful for undergraduate students. This book is a welcome exception.

Heretofore, we have not used automatic evaluation tools for programming assignments. But, taking a leaf from colleagues at Malaspina University-College, Prof. Gardner decided to try out their CEW [5], Component Exerciser Workbench, courtesy of P. Walsh, M. Horie, and J. Uhl. He added an e-mail front end, so that students could attach their .h and .cpp source files, and mail in their code for testing on the Linux host from wherever they happened to be working on it--on campus or at home (Indonesia, in one case)--and receive a virtually immediate reply. The service was enhanced to handle submissions as well as testing. This was a complete success, despite the diversity of mail clients, compilers, and operating systems. We adopted the Malaspina policy that code which failed a basic acceptance test suite (BATS) would not be marked at all. Students could mail-test their code against the BATS as often as they wished. Code that passed the BATS was run by the (human) marker against a more stringent test (RATS) and visually inspected for coding style. Automated scripts on the Linux host enabled the marker to make short work of the six assignments from nearly 40 students, and provide personal comments on each one.

3.3.3 Introduction to Java

Prof. Ariel chose a text by Joyce Farrell [7] from Course Technology. Other references are [6] and [8]. He found that students studying Java were at home with the basic constructs of the notation because both C++ and Java have the same control structures as C and ideas they learned in one language were reinforced in the other during the same week. They were able to appreciate the ease of use of arrays and strings in Java as the language does not employ pointers. They were asked to write two substantial programs in their assignments, namely the eight queen problem and the well-known game of life due to John Conway. The eight queen problem in particular gave them a good understanding of recursion.

The main thrust of the course was the understanding of the concepts of objects, inheritance and polymorphism. In view of the material in CMPT 160, in turn reinforced in CMPT 165 (though there were not many students in both), and by suitably selected examples in CMPT 167, little difficulty was encountered understanding concepts. This also led to a proper understanding of the necessity and desirability of using Java interfaces.

There was an in-depth coverage of AWT, Java's showcase. Students were given a couple of assignments using various AWT. The assignments were both instructive and entertaining and students wrote GUI applications using Java with ease.

Finally the I/O in Java were discussed. Students had difficulty appreciating the need for the intermediate classes, feeling strongly felt there should be a simpler mechanism for doing I/O, especially, for getting the input. This has been handled in various texts by introducing special classes. However, this was not done in the present course, and it remains to be seen how it would be received if it is introduced in future.

One disappointment was that initially there were a number of business majors enrolled; however, they could not cope with the computer science contents and most eventually dropped out. A similar experience was also encountered by the author (DA) when the course was taught standing alone. There is a need to determine the best way to deal with students majoring in business who do not have much aptitude for programming concepts.

4. The Results

Despite the lofty aims and deliberate planning, it was recognized that this would essentially be an experiment. What we did not know and wanted to find out were the answers to these two questions:

1) Does it help or hinder students to study more than one OOP language literally at the same time, i.e., not even in rapid succession? Ideally, the multiple exposures reinforce the common concepts, while the contrasts reinforce the language distinctions. At worst, we feared mass confusion could result.

2) Is it feasible to closely synchronize multiple courses running concurrently, or is it more trouble than it's worth for the instructors to organize themselves like this? This was intensive team-teaching. If our schedule proved impractical, or if we drifted away from it, the neat principle-and-application sequencing of phase two would break down.

Happily, a significant number of students registered for both languages, so we were in a good position to get feedback on the first question. Our own experience would provide the answer to the second.

4.1 The Teaching Team's Perspective

From a teaching point of view, all three instructors were satisfied that the principle of refactoring was sound and that theory topics were well-selected, appropriate, and teachable as designed.

The C++ instructor felt pressed for time in Phase I, the procedural syntax portion of the course, this despite getting a one-week head start relative to the OO Seminar and Java. C++ is, with its predecessor C, notoriously laden with pitfalls in the areas of pointers, arrays, and type definition syntax. Lengthening Phase I would allow more gradual treatment of these troublesome topics.

The theory instructor found that students' attention wandered when illustrations were taken from other than the language they were specifically interested in. This illustrates a potential pitfall in attempting to teach theory at the first year level.

4.2 The Students' Perspective

The students were surveyed, using the instrument in the Appendix. Where specific averages from the survey are mentioned, they are on five-point scale, with five being the most positive response, and one the most negative.

Because this was our first offering of a C++ course, and there was pent-up demand, we allowed third- and fourth-year students to register. A total of 38 students registered in C++, 20 in Java, and 49 in OO Seminar, which implies 9 taking both languages. We managed to extract surveys from 27 respondents: 20 for C++ and 11 for Java. (Four of these took both.)

We included an "ESL student" category on the survey, intending to look for correlations between opinions and possible English difficulties (which have given us a lot of trouble in the first-year programming courses), but since only two respondents self-identified, there is no meaningful data.

The most meaningful results of the survey are summarized below:

1. Third and fourth year students reacted more positively to the unique features of the experiment than did first and second year students, especially with respect to their overall experience. (3.5 vs 3.1). This might suggest that, though the course was intended to be at the first year level, it resonated at a higher level. On the other hand, it might simply reflect that the upper level students had better preparation and were already determined on a career in computing.

2. The few who had taken Java before as a stand-alone language course without the theory seminar in support much preferred things done the new way.

3. Results were sharply bimodal on these questions:

- separating the theory and notation into distinct courses,

- having separate instructors for the for the theory and notation courses,

- combining exams for CMPT 160 with the notation courses.

On the latter point there was criticism of the CMPT 160 instructor for placing questions on the exam such as "Show how to declare and instantiate objects in two languages we have studied." Some felt that they ought to be required to know only the theory that applied to the specific language they wanted to study, which would of course partially defeat the purpose of separating theory from language.

4. Despite the bimodal distribution, overall results were quite positive on #1 the separation of theory and notation (3.41) with the Java students (3.73) much more positive that the C++ students (3.35).

5. Very positive results (3.41) were also found from question #3, which asked if the attempt to abstract the big picture of OO concepts from notational details was helpful. Again, the Java students were significantly more positive than the C++ students. Overall, this response would appear to suggest that the basic plan of instruction succeeded with the students.

6. Almost no one thought those taking a second course from the package should have to re-write the 160 (theory) part of the exam. We weren't planning to require this anyway, and expected most students to agree.

7. Most thought that the two-hour classes were too heavy, and preferred two one-hour blocks for the individual languages (question #5), and by the time we took the survey the instructors had come to the same conclusion themselves.

8. Results were quite indecisive on #4 (Were illustrations from a variety of languages helpful?) and #8 (overall experience) but for different reasons. On #4, responses were evenly distributed, except that upper level students were more positive. On #8, responses clustered heavily in the middle, suggesting students did not feel their individual experience was significantly better or worse, even though they had agreed strongly that overall strategy was sound and helpful. We take this to mean that some fine tuning to improve the overall experience is indicated.

9. Despite this, most who answered #10 (would you take the other language in the package) said they would if they got the chance.

10. Students in the Java course were more positive about the two course, 2 instructor aspect (questions #1-4) but found the total experience less satisfactory (#8). This result is somewhat contradictory, but there were only eleven respondents for Java, and so it may not be significant.

11. The four students who responded as taking both languages may not comprise a significant sample, but were uniformly positive about their experience.

We had some concern about the survey response rate (27 out of a possible 49), but the survey was taken on a Friday afternoon late in the semester when there are many other activities, and the lower than average attendance is not too surprising, especially since some of the third and fourth year students felt it unnecessary to attend the seminar due to the lecture material being available on the TWU web site.

5. Conclusions and Plans For Future Work

We believe the refactoring of our teaching of the introduction to object oriented programming was successful and achieved its goals of improved efficiency and good pedagogy. With only minor timing problems we were able to synchronize the schedules of the three instructors. Moreover, the pattern is now available to be re-used for other courses. Some changes seem indicated:

1. The topic outline needs to be revised to reflect the fact that some theory portions took longer than a lesson, and others less. Alternately, we could use a sixty-five minute time block instead of a fifty minute block for the theory portion. Either is a minor change.

2. Phase I of the schedule needs to be slightly lengthened to avoid pressuring C++.

3. The bundling of exams needs to be revisited, since it seemed to cause some confusion.

4. With the third- and fourth-year students eliminated from the next round, we need to take more care to target the less-experienced audience in terms of the depth and pacing.

5. We found no significant positive or negative indications on the question of whether students had a problem taking both languages at once.

Encouraged by the results of our experiment, we plan to offer the same package in the Spring semester of 2001, with minor modifications, and survey the students a second time.

6. References

[1] Sutcliffe, Richard J. Modula-2: Abstractions for Data and Programming Structures (Using ISO-Standard Modula-2) 1999-2000 Edition http://www.twu.ca/rsbook/Index.html
[2] Sutcliffe, Richard J. CMPT 160 Overheads Spring 2000 http://faith.csc.twu.ca/~rsutc/CMPT160. These pages should be viewed with a style-sheet enabled browser.
[3] Deitel & Deitel. C++: How to Program. Second Edition. Prentice Hall, 1998.
[4] Deitel & Deitel. Getting Started with Microsoft Visual C++ 6 with an Introduction to MFC. Prentice Hall, 2000. The book includes a CD-ROM with the student edition of Visual Studio.
[5] P. Walsh and J. Uhl. On the Benefits of Integrating Systematic Verification into CS1 and CS2. The First Annual Consortium for Computing in Small Colleges Northwest Conference, Spokane, Washington, 1999. Postscript version at http://malun1.mala.bc.ca:8080/~pwalsh/research/spokane99.ps.
[6] Arnold, Ken and Gosling, James: The Java Programming Language. Addison Wesley, Reading, Massachusetts, 1996.
[7] Farrell, Joyce: Java Programming: Comprehensive. Course Technology, Cambridge, Massachusetts, 1999.
[8] Deitel H.M. and Deitel P.J., Java: How to Program, 3rd Edition. Prentice Hall, Upper Saddle River, New Jersey, 2000.
[9] Budd, Timothy Object Oriented Programming. Addison Wesley, Reading, MA, 1999.
[10] Gamma, Erich; Helm, Richard; Johnson, Ralph; and Vlissides, John. Design Patterns--Elements of Object-Oriented Software. Addison Wesley, Reading, MA, 1995.

Appendix: Student Survey

What follows is an abbreviated form of the survey instrument:

CMPT 16x OO Courses Survey Spring 2000

Help us evaluate the effectiveness of our OO teaching strategy. Anonymity assured.

ESL student?

Year # (1-5) (Students were also asked a variety of questions about their TWU course background.)

Please note: Later, you will have a chance to evaluate the individual 16x courses in the normal TWU evaluation process. That is not the purpose of this survey. Here, we are looking for feedback on the 160 + 165/7 packaging concept.

Which OO course(s) are you taking this semester? circle: 160 OO Concepts 165 C++ 167 Java

The 16x experiment: We factored out the language-neutral OO theory into the 1-sem. hr. 160 "base class," and taught the language-specific practical elements in 165 and 167 @ 2 sem. hours each. We hoped that by teaching OOP (object-oriented programming) in this way, we could highlight the underlying theoretical concepts (so you'd be able to identify them more easily when you learn another OO language later), and reduce the redundancy (avoid going over the same ground) in the language-specific courses. Also, if you take the other language course later, you won't have to take 160 again (saving both time and tuition money).

Opinion questions: Write a number 1..5 according to the scale given. Generally, 1 is strongly negative, 5 is strongly positive. Leave blank if not applicable. Explanations or comments are more than welcome!

1. How did you feel about learning the OO concepts in a separate class from Java/C++?
[1=better to learn it all in one class .. 3=doesn't matter .. 5=separate classes helpful]

2. How did you feel about learning the OO concepts from a different instructor than Java/C++?
[1=better with just one instructor .. 3= doesn't matter.. 5=two instructors was great]

3. 160 tried to abstract the OO concepts and give the "big picture," which you would ordinarily not get in a language-specific course. Was this helpful?
[1=NO, I was confused by the "big picture" .. 3=no opinion .. 5=YES, excellent!]

4. 160 introduced examples from a number of OO languages, in order to illustrate differing terminology and syntax. Was this helpful?
[1=NO, I didn't want to learn about other languages .. 3=didn't matter .. 5=YES, excellent!]

5. How did you feel about the 2-hour blocks for 165/167?
[1=use 2 1-hr classes .. 3=don't care .. 5=2-hr class was great]

6. How did you feel about combining 160 and Java/C++ on one midterm exam?
[1=give 2 separate exams .. 3=don't care .. 5=having only one exam was great!]

7. If someone takes the other 16x language course in the future (they won't repeat 160), should they write the 160 part of the midterm and final exams again?
[1=NO, it's not fair .. 3=doesn't matter .. 5=YES, they should still know that material]

8. Rate your overall learning experience with the 16x courses.
[1=well below average .. 3=average .. 5=as good as it gets!]

9. If you would be interested in having us offer another CMPT 16x OOP course (not Java or C++), please write the language name(s) here:_____________ ________________ _____________

Individual situations: Please read the conditions carefully before answering the next questions.

If you have not yet taken both C++ and Java, answer this question #10:

10. Would you like to take the other 16x course in the future (you won't repeat 160)? (check one)
[1] YES, probably.
[2] Wait and see.
[3] NO, I'll study it on my own because I can pick it up without another formal course.
[4] NO, I'll study it on my own because I don't like the 160 + 16x approach.
[5] NO, not interested in the other language.
[6] NO, some other reason. Explain:

If you are presently taking both 165 & 167, answer questions #11-13:

1. What do you think about studying Java and C++ at the same time?
[1=quite confusing .. 3=neither good/bad .. 5=quite helpful] Comments:

2. Did you appreciate having the redundancy removed (into 160), or would it been better to leave it in and have two 3-credit courses with considerable conceptual overlap?
[1=leave in the overlap .. 3=either way OK .. 5=good to remove the redundancy] Comments:

3. Based on your experience, do you prefer studying two OO languages together, or in different semesters?
[1=better apart .. 3=either way OK .. 5=better together] Comments:

If you took 241 Java before, answer question #14:

14. Compare the 160 + 16x combination to taking a single language-specific OOP course.
[1=single course better .. 3=about the same .. 5=combination better] Comments: