29 Teaching the method dinoustudy of methodoicaseofth principal questions facing companies and universities that adopt object technology:how best to educate those who will have to apply it.This chapter presents teaching principles and points to common errors. The first part of the discussion takes the view of someone who is in charge of organizing a training program in a company;the following parts take the view of a university or high school professor.All emphasize the pedagogical issues ofO-O training, and so they should be relevant to you even if you are in neither of these positions-in particular if you are a trainee rather than a trainer. 29.1 INDUSTRIAL TRAINING Let us start with a few general observations about how to teach object technology-either in public seminars or as part of an in-company training plan-to software professionals previously trained in other approaches. Paradoxically,the trainer's task may be harder now than when object technology started to attract wide interest in the mid-eighties.It was new then to most people,and had an aura of heresy which made the audience listen.Today,no one will call security if one of the cocktail guests declares object-oriented tastes.This is the buzzword effect, which has been dubbed mOOzak:the omnipresence,in the computer press,of O-O this and O-O that,causing a general dilution of the concepts.The words flow so continuously from the loudspeakers-object,class,polymorphism...-as to seem familiar,but are the concepts widely understood?Often not.This puts a new burden on the trainer: convincing the trainees that they do not yet know everything,since no one can learn a subject who thinks he already knows it. The only strategy guaranteed to overcome this problem applies the following plan: Initial training:the "hit them twice"strategy TI.Take the initial training courses. T2.Try your hand at O-O development. T3.Take the initial training courses
29 Teaching the method Ending our study of methodological issues, we turn our attention to one of the principal questions facing companies and universities that adopt object technology: how best to educate those who will have to apply it. This chapter presents teaching principles and points to common errors. The first part of the discussion takes the view of someone who is in charge of organizing a training program in a company; the following parts take the view of a university or high school professor. All emphasize the pedagogical issues of O-O training, and so they should be relevant to you even if you are in neither of these positions — in particular if you are a trainee rather than a trainer. 29.1 INDUSTRIAL TRAINING Let us start with a few general observations about how to teach object technology — either in public seminars or as part of an in-company training plan — to software professionals previously trained in other approaches. Paradoxically, the trainer’s task may be harder now than when object technology started to attract wide interest in the mid-eighties. It was new then to most people, and had an aura of heresy which made the audience listen. Today, no one will call security if one of the cocktail guests declares object-oriented tastes. This is the buzzword effect, which has been dubbed mOOzak: the omnipresence, in the computer press, of O-O this and O-O that, causing a general dilution of the concepts. The words flow so continuously from the loudspeakers — object, class, polymorphism… — as to seem familiar, but are the concepts widely understood? Often not. This puts a new burden on the trainer: convincing the trainees that they do not yet know everything, since no one can learn a subject who thinks he already knows it. The only strategy guaranteed to overcome this problem applies the following plan: Initial training: the “hit them twice” strategy T1 • Take the initial training courses. T2 • Try your hand at O-O development. T3 • Take the initial training courses
936 TEACHING THE METHOD $29.1 T3 is not a typo:after having tried to apply O-O ideas to real development,trainees take the class again.O-O training companies sometimes suggest this strategy to their customers,not always with success since it suspiciously looks like a marketing ploy to sell the same thing twice.But that is not the case. The second iteration is what really gets the concepts through.Although the first is necessary to provide the right background,it may not be fully effective,partly because of the mOOzak effect,your students may not quite internalize the concepts.Only when they have grappled with the day-to-day challenges of object-oriented software construction- Is a new class necessary for this concept?Is this a proper use ofinheritance?Do these two features justify introducing a new node in the inheritance structure?Is this design pattern from the course relevant here?-will they have the necessary preparation to listen properly.The second session will not,of course,be identical to the first(if anything,the audience's questions will be more interesting),and might straddle the border between training and consulting;but it is really a second presentation of the same basic material- not merely an advanced course following an elementary one. In practice only the more enlightened companies are ready to accept the "teach it once, then teach it again"strategy.Others will dismiss the idea as a waste of resources.In my experience,however,the result is well worth the extra effort.The strategy is the best I know to train developers who truly understand object technology and can apply it effectively to serve the company's needs. The next principle addresses what should be taught: Training Topics principle Especially in initial training,focus on implementation and design. Some people assume that the curriculum should start with object-oriented analysis. This is a grave mistake.A beginner in object technology cannot understand O-O analysis (except in the mOOzak sense of recognizing the buzzwords).To master O-O analysis,you must have learned the fundamental concepts-class,contracts,information hiding, inheritance,polymorphism,dynamic binding and the like-at the level of implementation,where they are immediately applicable,and you must have used them to build a few O-O systems,initially small and then growing in size;you must have taken these projects all the way to completion.Only after such a hands-on encounter with the operational use of the method will you be equipped to understand the concepts of O-O analysis and their role in the seamless process of object-oriented software construction. Two more principles.First,do not limit yourselves to introductory courses: Advanced Curriculum principle At least 50%of a training budget should be reserved for non-introductory courses. Finally,do not consider developers alone:
936 TEACHING THE METHOD §29.1 T3 is not a typo: after having tried to apply O-O ideas to real development, trainees take the class again. O-O training companies sometimes suggest this strategy to their customers, not always with success since it suspiciously looks like a marketing ploy to sell the same thing twice. But that is not the case. The second iteration is what really gets the concepts through. Although the first is necessary to provide the right background, it may not be fully effective; partly because of the mOOzak effect, your students may not quite internalize the concepts. Only when they have grappled with the day-to-day challenges of object-oriented software construction — Is a new class necessary for this concept? Is this a proper use of inheritance? Do these two features justify introducing a new node in the inheritance structure? Is this design pattern from the course relevant here? — will they have the necessary preparation to listen properly. The second session will not, of course, be identical to the first (if anything, the audience’s questions will be more interesting), and might straddle the border between training and consulting; but it is really a second presentation of the same basic material — not merely an advanced course following an elementary one. In practice only the more enlightened companies are ready to accept the “teach it once, then teach it again” strategy. Others will dismiss the idea as a waste of resources. In my experience, however, the result is well worth the extra effort. The strategy is the best I know to train developers who truly understand object technology and can apply it effectively to serve the company’s needs. The next principle addresses what should be taught: Some people assume that the curriculum should start with object-oriented analysis. This is a grave mistake. A beginner in object technology cannot understand O-O analysis (except in the mOOzak sense of recognizing the buzzwords). To master O-O analysis, you must have learned the fundamental concepts — class, contracts, information hiding, inheritance, polymorphism, dynamic binding and the like — at the level of implementation, where they are immediately applicable, and you must have used them to build a few O-O systems, initially small and then growing in size; you must have taken these projects all the way to completion. Only after such a hands-on encounter with the operational use of the method will you be equipped to understand the concepts of O-O analysis and their role in the seamless process of object-oriented software construction. Two more principles. First, do not limit yourselves to introductory courses: Finally, do not consider developers alone: Training Topics principle Especially in initial training, focus on implementation and design. Advanced Curriculum principle At least 50% of a training budget should be reserved for non-introductory courses
$29.2 INTRODUCTORY COURSES 937 Manager Training principle A training curriculum should include courses for managers as well as software developers. It is unrealistic,for a company or group that is adopting object technology on any scale,to hope to succeed by training developers only.Managers,regardless of the depth of their technical background,must be introduced to the basic O-O ideas and apprised of their repercussions on distribution of tasks,team organization,project lifecycle, economics of software development.The lifecycle discussion of the next chapter and, more exhaustively,management-oriented books such as [Goldberg 1995],[Baudoin 1996] and [M 1995],are typical of the material to be covered in such(usually short)courses. Here is an example of what manager education must include to avoid potential trouble, allow effective development and benefit the bottom line.The industry's measures of productivity are still largely based,deep-down,on ratios of produced code to production effort.In a reuse-conscious software process,you may spend some time improving software elements that already work well to increase their potential for reuse in future projects.This is the generalization task,an important step of the lifecycle model presented in the next chapter.Often,such efforts will remove code,for example because you have given a common ancestor to two originally unrelated classes,moving commonality to that ancestor.In the productivity ratio,the numerator decreases (less code)and the denominator increases(more effort)!Managers must be warned that the old measures do not tell the whole story,and that the extra effort actually improves the software assets of the company.Without such preparation,serious misunderstandings may develop,jeopardizing the success of the best planned technical strategies. 29.2 INTRODUCTORY COURSES Let us turn our attention now to the teaching of object technology in an academic environment(although many observations will also be applicable to industrial training). As the software community recognizes the value of the object-oriented approach,the question increasingly arises of when,where and how to include object-oriented concepts, languages and tools in a software curriculum-university,college or even high school. Phylogeny and ontogeny When should we start? The earlier the better.The object-oriented method provides an excellent intellectual discipline;if you agree with its goals and techniques,there is no reason to delay bringing it to your students;you should in fact teach it as the first approach to software development.Beginning students react favorably to O-O teaching,not because it is trendy, but because the method is clear and effective. This strategy is preferable to a more conservative one whereby you would teach an older method first,then unteach it in order to introduce O-O thinking.If you think object- oriented development is the right way to go,there is no reason to make a detour first
§29.2 INTRODUCTORY COURSES 937 It is unrealistic, for a company or group that is adopting object technology on any scale, to hope to succeed by training developers only. Managers, regardless of the depth of their technical background, must be introduced to the basic O-O ideas and apprised of their repercussions on distribution of tasks, team organization, project lifecycle, economics of software development. The lifecycle discussion of the next chapter and, more exhaustively, management-oriented books such as [Goldberg 1995], [Baudoin 1996] and [M 1995], are typical of the material to be covered in such (usually short) courses. Here is an example of what manager education must include to avoid potential trouble, allow effective development and benefit the bottom line. The industry’s measures of productivity are still largely based, deep-down, on ratios of produced code to production effort. In a reuse-conscious software process, you may spend some time improving software elements that already work well to increase their potential for reuse in future projects. This is the generalization task, an important step of the lifecycle model presented in the next chapter. Often, such efforts will remove code, for example because you have given a common ancestor to two originally unrelated classes, moving commonality to that ancestor. In the productivity ratio, the numerator decreases (less code) and the denominator increases (more effort)! Managers must be warned that the old measures do not tell the whole story, and that the extra effort actually improves the software assets of the company. Without such preparation, serious misunderstandings may develop, jeopardizing the success of the best planned technical strategies. 29.2 INTRODUCTORY COURSES Let us turn our attention now to the teaching of object technology in an academic environment (although many observations will also be applicable to industrial training). As the software community recognizes the value of the object-oriented approach, the question increasingly arises of when, where and how to include object-oriented concepts, languages and tools in a software curriculum – university, college or even high school. Phylogeny and ontogeny When should we start? The earlier the better. The object-oriented method provides an excellent intellectual discipline; if you agree with its goals and techniques, there is no reason to delay bringing it to your students; you should in fact teach it as the first approach to software development. Beginning students react favorably to O-O teaching, not because it is trendy, but because the method is clear and effective. This strategy is preferable to a more conservative one whereby you would teach an older method first, then unteach it in order to introduce O-O thinking. If you think objectoriented development is the right way to go, there is no reason to make a detour first. Manager Training principle A training curriculum should include courses for managers as well as software developers
938 TEACHING THE METHOD $29.2 Teachers may unconsciously tend to apply an idea that was once popular in biology: that ontogeny (the story of the individual)repeats phylogeny (the story of the species);a human embryo,at various stages of its development,vaguely looks like a frog,a pig etc. Transposed to our subject,it means that a teacher who first learned Algol,then went on to structured design and finally discovered objects may want to take his students through the same path.There is little justification for such an approach,which inelementary education would make students first learn to count in Roman numerals,only later to be introduced to more advanced"methodologies"such as Arabic numerals.If you think you know what the right approach is,teach it first. Paving the way for other approaches One of the reasons for recommending(without fear of fanaticism or narrow-mindedness) the use of object technology right from the start is that,because the method is so general, it prepares students for the later introduction of other paradigms such as logic and functional programming-which should be part of any software engineer's culture.Ifyour curriculum calls for the teaching of traditional programming languages such as Fortran, Cobol or Pascal,it is also preferable to introduce these later,as knowledge of the object- oriented method will enable students to use them in a safer and more reasoned way. O-O teaching is also good preparation for a topic which will become an ever more prevalent part of software education programs:formal approaches to software specification,construction and verification,rooted in mathematics and formal logic.The use of assertions and more generally of the Design by Contract approach is,in my experience,an effective way to raise the students'awareness of the need for a sound, systematic,implementation-independent and at least partially formal characterization of software elements.Premature exposure to the full machinery of a formal specification method such as Z or VDM may overwhelm students and cause rejection;even if this does not occur,students are unlikely to appreciate the merits of formality until they have had significant software development experience.Object-oriented software construction with Design by Contract enables students to start producing real software and at the same time to gain a gentle,progressive exposure to formal techniques. Language choice Using the object-oriented method for introductory courses only makes sense if you can rely on a language and an environment that fully support the paradigm,and are not encumbered by ghosts of the past.Note in particular that"hybrid"approaches,based on object-oriented extensions ofolder languages,are unsuitable for beginning students,since they mix O-O concepts with unrelated remnants from other methods,forcing the teacher to spend much of the time on excuses rather than concepts. In C-based languages,for example,just explaining why an array and a pointer have to be treated as the same notion-a property having its roots in optimization techniques for older hardware architectures-would consume precious time and energy,which will not be available for teaching the concepts of software design.More generally,students
938 TEACHING THE METHOD §29.2 Teachers may unconsciously tend to apply an idea that was once popular in biology: that ontogeny (the story of the individual) repeats phylogeny (the story of the species); a human embryo, at various stages of its development, vaguely looks like a frog, a pig etc. Transposed to our subject, it means that a teacher who first learned Algol, then went on to structured design and finally discovered objects may want to take his students through the same path. There is little justification for such an approach, which in elementary education would make students first learn to count in Roman numerals, only later to be introduced to more advanced “methodologies” such as Arabic numerals. If you think you know what the right approach is, teach it first. Paving the way for other approaches One of the reasons for recommending (without fear of fanaticism or narrow-mindedness) the use of object technology right from the start is that, because the method is so general, it prepares students for the later introduction of other paradigms such as logic and functional programming – which should be part of any software engineer’s culture. If your curriculum calls for the teaching of traditional programming languages such as Fortran, Cobol or Pascal, it is also preferable to introduce these later, as knowledge of the objectoriented method will enable students to use them in a safer and more reasoned way. O-O teaching is also good preparation for a topic which will become an ever more prevalent part of software education programs: formal approaches to software specification, construction and verification, rooted in mathematics and formal logic. The use of assertions and more generally of the Design by Contract approach is, in my experience, an effective way to raise the students’ awareness of the need for a sound, systematic, implementation-independent and at least partially formal characterization of software elements. Premature exposure to the full machinery of a formal specification method such as Z or VDM may overwhelm students and cause rejection; even if this does not occur, students are unlikely to appreciate the merits of formality until they have had significant software development experience. Object-oriented software construction with Design by Contract enables students to start producing real software and at the same time to gain a gentle, progressive exposure to formal techniques. Language choice Using the object-oriented method for introductory courses only makes sense if you can rely on a language and an environment that fully support the paradigm, and are not encumbered by ghosts of the past. Note in particular that “hybrid” approaches, based on object-oriented extensions of older languages, are unsuitable for beginning students, since they mix O-O concepts with unrelated remnants from other methods, forcing the teacher to spend much of the time on excuses rather than concepts. In C-based languages, for example, just explaining why an array and a pointer have to be treated as the same notion — a property having its roots in optimization techniques for older hardware architectures — would consume precious time and energy, which will not be available for teaching the concepts of software design. More generally, students
$29.2 INTRODUCTORY COURSES 939 would be encouraged,at the very beginning of their training,to reason in temms of low- level mechanisms-addresses,pointers,memory,signals.They would inevitably spend much of their time,if they eventually produce a compilable program,chasing various bugs.The approach would leave the students perplexed and might end up in disaster. An introductory course must do the reverse:present the students with a clear, coherent set of practical principles.The notation must directly support these principles, ensuring a one-to-one correspondence between method and language.Any time you spend explaining the language per se is time lost.With a good language,you explain the concepts,and use the notation as the natural way to apply them. Although the main quality of an introductory language is its structural simplicity and its support of O-O ideas such as class-based modularization,design by contract,static typing and inheritance,you should not underestimate the role of syntactic clarity.C++and Java texts are replete with lines such as Examples from the public static void main(String]args basic book on.Java, if (this-fd=-1 &lopen_fd(this)) [Arnold 1996]. if ((xfrm=(char *)malloc(xfrm len 1))==NULL) showing cryptic and confusing syntax relying on many special operators.Beginners should not be subjected to such contortions,justified only by historical considerations;learning to program well is hard enough without the interposed obstacle of a hostile notation. Exceprts from post- David Clark from the University of Canberra went through this experience and ing of 15 October posted some of his conclusions on Usenet: 1996. Last semester I taught the second half of a first year programming course]using Java...My experience has been that students do not find Java easy to learn.Time and again the language gets in the way of what I want to teach.Here are some examples: The first thing they see is public static void main (String[]args)throws IOException There are about 6 different concepts in that one line which students are not yet ready to learn... You get output for "free",but have to jump through several hoops to input anything. (import,declare,initialize.).The only way to read a number from the keyboard is to read a string and parse it.Again,this is something that crops up in the first lecture. Java treats the primitive data types (int,char,boolean,float,long,...)differently from other objects.There are Object-type equivalents (Integer,Boolean,Character etc.). There is no relation between int and Integer. The String class is a special case.(Again,for efficiency.)It is only used for strings that don't change.There is a StringBuffer class for strings that do change.Fair enough.but there is no relationship between String and String Buffer.There are few features in common. The lack ofgenerics means that you are forever casting ifyou want to use a collection of elements such as Stack or Hashtable.[These things]are hurdles for beginning students,and distract them from the main learning outcomes of the course. Prof.Clark goes on to compare this experience with his practice of teaching with the notation of this book,for which,he writes,"I do virtually no language teaching beyond giving some examples of code
§29.2 INTRODUCTORY COURSES 939 would be encouraged, at the very beginning of their training, to reason in terms of lowlevel mechanisms – addresses, pointers, memory, signals. They would inevitably spend much of their time, if they eventually produce a compilable program, chasing various bugs. The approach would leave the students perplexed and might end up in disaster. An introductory course must do the reverse: present the students with a clear, coherent set of practical principles. The notation must directly support these principles, ensuring a one-to-one correspondence between method and language. Any time you spend explaining the language per se is time lost. With a good language, you explain the concepts, and use the notation as the natural way to apply them. Although the main quality of an introductory language is its structural simplicity and its support of O-O ideas such as class-based modularization, design by contract, static typing and inheritance, you should not underestimate the role of syntactic clarity. C++ and Java texts are replete with lines such as public static void main(String[] args { if (this–>fd == –1 && !open_fd(this)) if ((xfrm = (char ∗)malloc(xfrm_len + 1)) == NULL) { showing cryptic and confusing syntax relying on many special operators. Beginners should not be subjected to such contortions, justified only by historical considerations; learning to program well is hard enough without the interposed obstacle of a hostile notation. David Clark from the University of Canberra went through this experience and posted some of his conclusions on Usenet: Last semester I taught the second half of a first year programming [course] using Java… My experience has been that students do not find Java easy to learn. Time and again the language gets in the way of what I want to teach. Here are some examples: • The first thing they see is public static void main (String [ ] args) throwsIOException There are about 6 different concepts in that one line which students are not yet ready to learn… • You get output for “free”, but have to jump through several hoops to input anything. (import, declare, initialize.). The only way to read a number from the keyboard is to read a string and parse it. Again, this is something that crops up in the first lecture. • Java treats the primitive data types (int, char, boolean, float, long,…) differently from other objects. There are Object-type equivalents (Integer, Boolean, Character etc.). There is no relation between int and Integer. • The String class is a special case. (Again, for efficiency.) It is only used for strings that don't change. There is a StringBuffer class for strings that do change. Fair enough. but there is no relationship between String and StringBuffer. There are few features in common. • The lack of generics means that you are forever casting if you want to use a collection of elements such as Stack or Hashtable. [These things] are hurdles for beginning students, and distract them from the main learning outcomes of the course. Prof. Clark goes on to compare this experience with his practice of teaching with the notation of this book, for which, he writes, “I do virtually no language teaching beyond giving some examples of code”. Examples from the basic book on Java, [Arnold 1996]. Exceprts from posting of 15 October 1996