Education and Information Technologies 9:3, 209–218, 2004. 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Rethinking of Teaching Objects-First

CHENGLIE HUDepartment of Computer Science, Carroll College, 100 N East Ave., Waukesha, WI 53186, USAE-mail: chu@cc.edu

Abstract

The issues surrounding teaching object-orientation to novice programmers from day one are revisited first. Ananalysis is then presented showing the harmfulness of teaching objects-first. The attention then is given to ad-dressing the problems of the current textbooks. Furthermore, a remark is made in comparison between teachingobjects-first and Reformed Calculus from a closed discipline. Finally, a new structure for introductory program-ming courses is suggested.

Keywords: teaching of CS1, objects-first, object-orientation, structured programming, CS foundation courses

1. Introduction

Despite the overwhelming adoption of teaching object orientation (OO) in CS1 (the firstcomputer science foundation course) in many universities and colleges of the US, someimportant issues surrounding the suitability of the adoption are still with us. In the re-cent years, the common consensus has been that object-orientation should be taught tobeginners given the fact that it has been, and will continue to be, a major programmingparadigm used in the software industry. However, published studies are often focused onhow a particular programming environment, a piece of software, or a particular method ofteaching would help students understand OO. Negative experiences or outcomes, despitebeing talked about at various professional meetings, are often not published or reported forone reason or another. This paper is not about arguing whether OO should be taught in thefoundation CS courses, rather it is about whether the notion of teaching objects-first andabandoning structured programming is appropriate.

The OO constructs first appeared in SIMULA 67 nearly forty years ago, and peoplein academia were still holding doubts in the early 90s whether OO would be replacedby something better in the near future as they hesitated to introduce OO even in upperlevel undergraduate courses. The important legacy that came out of SIMULA 67 was thatreal-world problems can be solved by identifying the real-world objects and then creat-ing simulations of those objects, their processes, and required communications betweenthose objects. This legacy had long been ignored by academia until late 90s when Javawas becoming one of the major programming languages used in the industry. The fastadvancement of technologies around Java has made OO much more successful than everbefore in the recent years. Yet, the core idea of problem solving through OO remains thesame as what it was nearly forty years ago.

210 HU

As surveyed by Mazaitis (1993) and Decker (1994), the object-oriented programmingwas offered (if at all) in most schools only as a senior course in the early 90s. Now, the fash-ionable slogan has been “Let’s Begin Introducing the Object-Oriented Paradigm” (Temte,1991). What has made this previously considered hard material now become anyhow eas-ier to the beginners in CS1 so that they can learn it from day one? Are students betterprepared now than ever before? If not, does OO then replace structured programming (SP,also known as procedure/process-oriented programming) paradigm? If not, does OO thenmake transition to procedural paradigm easier, or do technologies make the OO learningcurve substantially flatter? These are the questions we try to address in this paper.

First, the issues surrounding teaching OO to beginners are briefly visited. Then, ananalysis addressing questions raised above is given. This is followed by a list of problemsof the current textbooks for CS1. A remark then is made regarding the lessons we havelearned in a closed discipline. Finally, a new structure of implementing CS1 is suggestedunder the general framework for the foundation courses suggested by ACM/IEEE-CS TaskForce (2001).

2. The Issues

The issues raised in the mid 90s (see Mazaitis, 1993; Decker and Hirshfield, 1994) havebeen largely non-existent, as we are convinced that the OO paradigm will continue tobe a major paradigm used in the software industry, there has been a comfortable set ofOO languages (C++, Java, C#, Smalltalk, VB.NET, among others) we can now choosefrom for teaching purposes, supporting or facilitating environments (Barnes and Kölling(2003) and Cooper et al. (2003), among others) are now available, the whole curriculumhas been designed or redesigned to accommodate OO in most universities and colleges,and instructors have been much better prepared to teach OO than they were in the mid 90s.Nevertheless, the issues that are still around us include:

1. The students in CS1 are not prepared for the complexity and the level of abstraction ofOO.

2. There’s too much material for a single CS1 course to handle.3. The weakened coverage on traditional algorithms due to the shifted emphasis and time

constraints.4. The concerns of less or no coverage on structured programming.

We are certainly much better off than we were in the early 90s in terms of the technologythat can be exploited in teaching OO. Yet, this technology advancement has unfortunatelyled many of us to believe that we can have it all, but structured programming, in CS1, fromOO (abstract classes, interfaces, inheritance, polymorphism, dynamic binding, exception-handling, and UML) to fun (applets, GUIs, event-driven programming, and animations).This has resulted in a foundation-weakened CS1 that teaches a “spoon fed” and miscon-nected “skill set” to only the best students.

The impact has been felt directly in CS2, data structures. Many students may have showna great deal of inability of writing loops and carrying out other logical thinking skills due

RETHINKING OF TEACHING OBJECTS-FIRST 211

largely to lack of training in CS1 about basic algorithms, although the chances are they donot have good understanding of OO either.

The impact may be far reaching as the students go on in their junior and senior yearsas many of the programming activities they will encounter later in their curricula maystill be largely procedurally or algorithmically oriented such as much of the Web develop-ment, using OpenGL graphics API, writing a compiler, developing a Lisp interpreter, orprogramming numerical computations.

The impact is also been experienced by students from science and engineering disci-plines. It has been studied (see Zeng and Schach, 2000) that most non-trivial scientificcomputations are not object-oriented in nature. These students would have to face chal-lenged transition when they have to use, say, FORTRAN 77 to solve computational prob-lems.

Having laid out the issues and problems, we shall now analyze why objects-first is inap-propriate, or even harmful to the students’ learning experience in CS1.

3. Objects-First Considered Harmful

The success of the object-orientation is not about just making ADTs and their extensions,but about programmers being able to carry out programming-in-the-large (see Schach,2001, p. 119) in terms of using ADTs as decomposition units. We agree that such a view ofthe “world” must be experience by the students early on in any computing science curricu-lum, but we are questioning about the time such abstraction can be exposed to the noviceprogrammers and the notion of abandoning structured programming.

The argument from the advocates of teaching objects-first is basically the follow-ing (Kölling, 1999):

1. OO can’t be “added” on to other language constructs; rather it replaces the fundamentalstructure of procedural programming.

2. Teaching OO in the first programming course is because of avoiding paradigm shift.3. Transition from OO to procedural programming is much easier than the other way

around.

We challenge the above believes.

Teaching objects-first would have been an understandable choice had the students beenbetter prepared than in the past. But, they are not. According to the US Departmentof Education, although average National Assessment of Education Progress (NAEP) mathscores have risen since 1969 (a statistically significant increase), only 16% of the nation’s17-year-olds were at or above a proficient level in 2000, and average NAEP science scoresdeclined 10 points between 1970 and 2000 (not a statistically significant drop), with nearlyhalf (47%) of 17-year-olds scoring below basic levels.

Based on my conversations with educators in other universities and colleges during a re-cent SIGSCE conference, many students are still struggling with the OO concepts in theirsenior years, and we are facing drop/fail-rates of as much as 50% in CS1. The alarming

212 HU

fact (Winslow, 1996) has been that “One wonders . . . about teaching sophisticated mate-rials to CS1 students when study after study has shown that they do not understand basicloops; . . . almost any undergraduate can add a set of numbers or compute an average of aset of numbers; why can’t over half of them write a loop to do the same operations?”

When addressing the reasons students were unable to see forest in their programmingactivities, Reek (1995) pointed out that “the problem isn’t that the students are stupid, butrather that at age eighteen their thinking maturity is still at the concrete level”. Teachingobjects-first ignores this fact and thus creating an environment that forces students to thinkat a higher level of abstraction, which is often the point where the confusion starts.

Teaching objects-first would have been a must had OO replaced SP. It has not and willnot. Structured programming is not simply about writing procedures or functions, butabout step-wise refinement for functional decomposition and the disciplined programmingpractices, which is clearly not derived from the OO paradigm.

A paradigm consists of a way of thinking and a way of doing things. Although somemay have believed (Meyer, 1989) that OO is, to certain extend, incompatible with thetraditional (structured) design method in terms of what we think, there is cross-fertilizationof ideas. An architectural design may now include components of both classic data flowdiagrams and UML state diagrams (a natural extension of classic state machine); step-wise refinement has had its extension in identifying a class hierarchy; classical meaningof cohesion and coupling in modularity is also applied to promoting responsibility-drivenclass design; while classic re-use and disciplined programming practices remain muchapplicable to the design of the instance methods of a class.

If OO is said to be revolutionary in terms of the way we think when designing a program,it is an evolutionary paradigm in terms of what we do. A procedural program can be turnedinto an “OO” program very easily by wrapping static methods into data-less classes oreven subclasses. Conversely, if a program uses classes that involve only static methods,the program is in essence procedurally oriented. In the early languages, heterogeneousdata and procedures that perform on the data were separately encapsulated. It was theabstract data type construct (regardless the syntax in a particular language) that unified twodifferent ways of encapsulation, and thus formed a new paradigm.

From problem-solving standpoint, a process may be inherently procedurally oriented.Playing the paper-rock-scissors game with computer is among the simplest examples, inwhich case, it is natural to decompose the process into displaying rules, getting user input,generating computer response, and judging the winner, etc. (although ADTs, such as deci-sion trees, might be needed for more complicated games). The identifiable objects, the twoplayers, paper, rock, and scissor, lack fundamentally meaningful game-related attributes(other than a user input or a different random number a computer may pick) that woulddistinguish one instance playing game different from another. When a real-world problemis not naturally OO-represented, programmers often have to twist the structure in orderto map those nonmathematical objects to algebraic-type-based classes, thus much of whatcan be observed as OO Programming is just a complex form of “encapsulation”, which isnot an OO approach (Ledgard, 2001).

RETHINKING OF TEACHING OBJECTS-FIRST 213

In solving sophisticated business problems, objects (local or remote) don’t communicatein a program without a “main” procedure, where the business process is faithfully andstructurally executed. A “main” procedure is not only the client of the various businessobjects, it can also be (and usually is) the client of the methods that address the functionaldecomposition of a business process, regardless whether these methods are stand-lone orencapsulated in data-less classes. Even for problems that can be represented in both ways(SP and OO), developers may often choose SP over OO for performance or complexityconcerns (real-time applications may well be such examples).

In conclusion, as Meyer (1989) asserted, object-oriented programming is an extensionof the structured paradigm as “structured programming continued by other means”.

The argument that transition from OO programming to SP is easier than the other wayaround is, in fact, fundamentally invalid. There should not be a transition in the firstplace, as both paradigms must be experienced in any learning process of a modern imper-ative programming language. Only inappropriately focused CS1 may lead to the validityof the question, and hence force the students to go through a difficult transition due to thefollowing factors. (1) Because of the level of sophistication of the objects that can be ex-posed to novice programmers, encapsulated methods students encounter in CS1 are oftenhighly cohesive, parameter-less, and have low degree of coupling. As a consequence, someof the important programming concepts may not be adequately addressed such as parame-ter passing and nested method calls. (2) The basic algorithms, as simple as finding themaximum in an array or swapping the contents of variables, may either be compromisedin their exposure or virtually non-existent due to lack of sophisticated objects or time con-straints (in some instances, loops and one dimensional arrays are the last material to cover).(3) Students may not have been exposed in any way to the step-wise refinement techniqueand/or disciplined programming practices (say, using public instance variables or instancevariables that are not attributes of the object is just as bad as using global variables inclassic sense).

It was said (Stroustrup, 1994) that it takes an average programmer 6 to 18 months toswitch his/her mindset from a procedural to an object-oriented view of the world, whichhas been often cited to justify teaching objects-first. Despite the inappropriate comparisonbetween experienced programmers and students who are learning programming, a mindsetis simply not taught, but gained through extensive practice. For professional programmers,it was precisely the use of OO for programming-in-the-large (not how the OO constructswork), a higher level of thinking in terms of abstraction (which often unfortunately in-volves twisting of the “world-view”), that has prevented many programmers from usingOO languages efficiently, hence needing a possibly long period of transition.

The studies (Pont, 1998) and my own experience have shown that most students learnbetter when programming is introduced using an SP style. In one recent study, Agarwalet al. (2000) pointed out that “an alternative steam of research suggests that human problemsolvers have an innate tendency to apply procedural or PO (process-oriented) approachesto problem solving”. With regard to model interpretation, they found that “the PO repre-sentation was easier to comprehend than the OO representation. This result contradicts the

214 HU

arguments made by proponents of the OO approach, who claim that ‘thinking in objects’is natural for human beings”.

In terms of the transition from SP to OO, Johnson (2000), in another recent study, foundthat “non-OO developers view OOSD (object-oriented system development) as “fairlycompatible” with their existing development processes, that OO programming is relativelyeasy, and that OOSD is suitable for their projects”. He also found that “surprisingly, how-ever, non-OO developers did not believe in many of the reported disadvantages of OOSD,including its presumed complexity”.

We believe that the natural programming learning process should be procedures-firstand objects-second. Objects simply provide new constructs as decomposition units of aprogram, where independent procedures are clients of the objects.

Finally, teaching objects-first would have been acceptable had technologies made signifi-cant difference in flattering the learning curve. It hasn’t and never will. As a promotionof the programming environment BlueJ, Kölling (1999) claimed that the trouble of learn-ing OO is because the wrong languages and environments are being used. The truth is thateducational technologies may help students view abstract concepts (with object-simulatorssuch as Alice (Cooper et al., 2003), organize ideas (with diagramming tools), or facili-tate coding (with smart editors)). Yet, none replaces human intellectual work as coding is.There has been plenty study about the limitations of the technologies. Meyer (1989) wrote,when commenting the graphical design tools of Eiffel, “useful as they may be, however,such tools should not lead us to forget the key lesson of structured programming: that soft-ware design is challenging intellectual problem, and one that is not likely to be solved bygraphical gimmicks”. More recently, Ledgard (2001) indicated, when addressing the prob-lem of lacking scientific measure for the productivity in the software industry, that “onceprogrammers started to code, CASE did not really help”.

For the CS1 students, technologies can be helpfully exploited only when they havegained good programming foundation (loops, selections, algorithms, and procedures),which is best learned in a structured programming environment, where good algorithmscan be addressed through concrete, yet complex in nature, actions or processes. Basedon author’s extensive experience of teaching OO, it has been not the “main” method, thetextural details of I/O, or the syntax of OO that causes problems, it is precisely the inabil-ity of doing programming-in-the-small and having to think at abstract level that has givenstudents most difficulties.

Had a teaching tool or environment been a dominant factor of the poor learning out-comes, we probably would have found “Silver Bullet” (Brooks, 1987) by now to solve allsoftware engineering problems.

4. Textbook Paradox

There are many CS1 textbooks on the market that claim to teach students object-orientedproblem solving skills. Despite different presentation styles, most have shared the follow-ing problems to certain degree:

RETHINKING OF TEACHING OBJECTS-FIRST 215

Traditional examples getting OO-dressed up. Conversion (from miles to kilometers, andthe like) is traditionally one of the very first programming activities students do in CS1.Textbooks (e.g., Wu, 2001) have now created objects for such activities by simply puttinga “class cloth” on “old” procedures. Yet, it’s hardly seen, without any context, why acohesive action (say, implemented in the following method) should be transformed into anobject that basically offers the same service.

double convert(double target, double original, double rate, boolean toOrFrom)

Using isolated OO examples. Although running examples are presented in some text-books (Morelli, 2002), most books use isolated examples to present OO concepts. Forinstance, instead of extending bank account class (introduced in an early chapter) to de-rive saving account or checking account, the book by Lewis and Loftus (2001) uses muchsimpler examples in the chapter about inheritance and polymorphism.

Using misleading “home-made” packages. Some textbooks start with applications oflibrary classes for, say, string manipulations or their “home-made” packages for I/O orframes, hoping that students can be acquainted with objects and method invocation beforethey write one. The obvious drawback of such a treatment is that the special (immutablefor example) or trivial (data-less in essence) objects students have used in the first placeare significantly different from what they will have to write later, which are data-oriented.Mechanical invocation simply does not help conceptual understanding.

OO is said, but not done. The problem is exposed in several aspects. First, concretedata structures such as address books or CD collections may be easy to use in showingencapsulation of data and operations (see Ledgard, 2001). Yet, these examples are inad-equate in exposing the main advantage of the OO data structures over traditional ones intheir hierarchical derivations. While such an exposure may be too early to be included inCS1, these examples wouldn’t serve well to show the benefits of OO. Second, event-drivenprogramming is always included in any Java textbook; yet events are often handled in anon-OO fashion using no classes that encapsulate event listeners and handlers. Third, in-heriting the library GUI components to meet special needs is often not addressed. Fourth,there is often no showing of object interaction using nontrivial real-world simulations, thusdiminishing what the textbooks have promised in the first place: problem solving throughobject-orientation.

Distractions. The concepts such as concurrency and networking sometimes are also in-cluded in textbooks, which have often nothing to do with teaching basic programmingskills.

Weakened algorithm exposure. With much added material in CS1, traditional program-ming skills (writing and analyzing loops and selections, parameter passing, commonlyused algorithms, etc.) have incurred in less coverage or been excluded entirely.

There are indeed good textbooks (e.g., Morelli, 2002). But as often identified, thesebooks can also be used for professional training for experienced programmers who wantto make transition to a different language. These cannot be truly introductory CS1 books.

216 HU

An inappropriate textbook (and unfortunately there are many of those) may easily feedCS1 students with a distorted view about what programming is, while students gain skillsin neither algorithmic development nor problem-solving.

5. A Reformed CS1?

A reformed way of teaching calculus was suggested in the late 80s (in response to highdrop-fail rate in Calculus I classes), and was widely executed in much of the late 90s whensuch reformed textbooks became available in 95. The reformed calculus was characterizedas extensive use of technology, emphasizing more on conceptual understanding than on(the so-called tedious) algebraic manipulation, and problems solving through discoverylearning and group work (the author happened to have taught such reformed courses).While this reformed practice is still going on, many teachers have switched back to thetraditional approach.

The problems with reformed calculus were similar to what has been mentioned in sec-tion 2: students are not ready for the level of conceptual abstraction (e.g., find original func-tions given derivatives); much needed algebraic skills are compromised; and later coursesare mostly not reformed, thus loosing the consistency and creating unnecessary difficulties.Despite some reports claiming successes of teaching reformed calculus to certain group ofpeople (mostly with weak algebra skills), one of the important lessons learned in the math-ematics community was that the technology simply cannot replace algebraic foundation ofthe calculus.

Teaching objects-first philosophically resembles teaching reformed calculus in some es-sential ways. We are compromising hard-skills such as algorithmic programming and cor-rectness verifications; we are hoping that a BlueJ or an Alice can save students lives; andwe are unrealistically raising the level of abstraction, required in understanding OO yet notprepared by most students.

As pointed by Wang (2002), “the essence of building software is its mathematical under-tones and the role of information as raw material”. In mathematics, we cannot expect thatthe students would be able to understand how an abstract algebraic system (that involvesboth elements and operations performed on the elements) can be used to solve problemswithout knowing first how to solve equations and inequalities that involve only real num-bers. In the same token, we cannot expect that the students would understand in whatcircumstances abstract classes or interfaces are used in solving problems without knowingwell first how to process inputs using functions or procedures.

6. Conclusion

Teaching objects-first may well be (and in fact, is, in many schools) counter-productiveand harmful. On the other hand, given the industry demand, students must experience ob-jects early on. Based on the recommendation of ACM Computing Curricula (2001), a threecourse sequence for the computer science foundation is necessary. While CS2 (Data Struc-tures) may largely be intact, CS1 should be divided into two courses. We feel that the first

RETHINKING OF TEACHING OBJECTS-FIRST 217

course may include what we traditionally teach (meaning, structured programming) andthe essentials of the object-based programming (no inheritance and polymorphism). Inother words, we should teach “programming through problem solving” in the first course.For the second course, the focus would be on object-oriented problem solving, where ab-stract classes, interfaces, inheritance, and polymorphism are then introduced. Significantnumber of simulation problems should be presented in an environment that promotes goodsoftware engineering practices. In other words, we should teach “problem solving throughprogramming”, whether topics such as event-driven programming, GUI, or concurrencyshould be covered in this second course should be largely left to the discretion of the in-structors. The choice of the programming language must be consistent.

It’s time for us to reassess what has been done in CS1.

References

ACM/IEEE-CS Task Force, (2001) ACM Computing Curricula 2001 for Computer Science. http://www.computer.org/education/cc2001/final/index.htm

Agarwal, R., et al. (2000) On the usability of OO representations. Communications of the ACM, 43(10), 83–89.Barnes, D. and Kölling, M. (2003) Objects First with Java a Practical Introduction Using BlueJ. Prentice-Hall,

Englewood Cliffs, NJ.Brooks, F. (1987) No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19.Cooper, M., et al. (2003) Teaching object-first in introductory computer science. In Proceedings of the 34th

SIGSCE Technical Symposium on Computer Science Education, pp. 191–195.Decker, R. and Hirshfield, S. (1994) The top 10 reasons why object-oriented programming can’t be taught in

CS1. SIGSCE Bulletin, 26(1), 51–55.Johnson, R. (2000) The ups and downs of object-oriented system development. Communications of the ACM,

43(10), 69–73.Kölling, M. (1999) The problem of teaching object-oriented programming, Part I: Languages. Journal of Object-

Oriented Programming, 11(8), 8–15.Ledgard, H. (2001) The emperor with no clothes. Communications of the ACM, 44(10), 126–128.Lewis, J. and Loftus, W. (2001) Java, Software Solutions, 2nd edition. Addison Wesley, Reading, MA.Mazaitis, D. (1993) The object-oriented paradigm in the undergraduate curriculum: A survey of implementations

and issues. SIGSCE Bulletin, 25(3), 58–64.Meyer, B. (1989) From Structured Programming to Object-Oriented Design: The Road to Eiffel. Springer, Berlin.Morelli, R. (2002) Object-Oriented Problem Solving Java, Java, Java, 2nd edition. Prentice-Hall, Englewood

Cliffs, NJ.Pont, M. (1998) Why Java is dangerous. IEEE Software, January/February.Reek, M. (1995) A top-down approach to teach programming. SIGSCE Bulletin, 27(1), 6–9.Schach, S. (2001) Object-Oriented and Classical Software Engineering, 5th edition. McGraw-Hill, Englewood

Cliffs, NJ.Stroustrup, B. (1994) The Design Evolution of C++. Addison-Wesley, Reading, MA.Temte, M. (1991) Let’s begin introducing the object-oriented paradigm. SIGSCE Bulletin, 23(1), 73–78. US

Department of Education. http://www.ed.gov/offices/OVAE/HS/mst.htmlWang, W. (2002) Beware the engineering metaphor. Communications of the ACM, 45(5), 27–29.Wick, M. (1995) On using C++ and object-orientation in CS1: The message is still more important than the

medium. SIGSCE Bulletin, 27(1), 322–326.Winslow, L. (1996) Programming pedagogy – a psychological overview. SIGSCE Bulletin, 28(3), 17–22.

218 HU

Wu, T. (2001) An Introduction to Object-Oriented Programming with Java, 2nd edition. McGraw-Hill, Engle-wood Cliffs, NJ.

Zeng, N. and Schach, S. (2000) Is the object-oriented paradigm appropriate for scientific software? (Unknownpublication status.)