Just in Time Ah

1280 Pages·2007·17.52 MB·English

int x = y * (100 − z);
if (y > w) x = w;
int x = y * (100 − z);
Too baffling
if (y > w) x = w;
??
Too soon!
Too unsettling
!!
int x = y * (100 − z);
if (y > w) x = w;
Too Late!
int x = y * (100 − z);
if (y > w) x = w;
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
int x = y * (100 − z); Java:
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
if (y > w) x = w; (cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
Ah,
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)J(cid:0)(cid:1)(cid:0)(cid:1)u(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)s(cid:0)(cid:1)(cid:0)(cid:1)t(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
int x = y * (100 − z); (cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
in
if (y > w) x = w; (cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
Just right! (cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)T(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)i(cid:0)(cid:1)m(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)e(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)(cid:0)(cid:1)
Fromzerotoheroin1232pages:astepbystepexampledrivenintroductiontoprogramming
CopyrightJohnLatham,SchoolofComputerScience,ManchesterUniversity, UK
November 14, 2007
ii
Note to reviewers at this draft stage
How is this book being made?
This book is currently being written by a program (shell script) from a structured set of files.
All the example code is being taken from actual Java programs which are also being run in
real time to extract their output when the latex is built! Additionally, the programs contain
their required concept names embedded in comments, with the text to describe the concept in
a separate file of that name. All this makes development of the book easier. Screen dumps of
theGUI programsarecurrently madebyhand. I’mlookingfora way toautomatethat too!
Consequences of the book development approach
Pleasedonottaketoomuchnoticeofthelayoutatthisstage. Currentlyconceptsareexplained
in separate subsections to help with their organisation. This might not be a good idea in the
final book. Code fragments sometimes have unfortunate page breaks in them. I expect a later
versionwilltakemorecare withthis,as wellas haveemboldenedreserved words.
Many concepts identified have not yet been written about. These show up as file not found
errors.
The last chapter contains collected concepts for reference purposes. Eventually, all concepts
willbegroupedintomajorandsometimesminorsectionsforthischapter. Atthemomentsome
ofthemhavenotbeen grouped.
Thereis alsoboundtobelotsoftypospellingmistakesat thisstage.
iii
iv
Preface
Pleasenotethatthisprefaceisat anearlydraftstage.
This book takes neither an objects first nor an objects late approach. Rather, its order of
materialmay besummarisedas basics first, objects soon,inheritance later(BFOSIL).
0.1 Why not objects first?
Itisoftensaidbyproponentsoftheobjectsfirstapproachthatpeoplenaturallylookattheworld
as interacting objects, each with state and behaviour, and so such a model is an appropriate
startingpointforthosenewtoprogramming. Whileonthefaceofitthissoundsplausible,and
obviouslyappealing, my experience of trying to teach first programming using an objects first
approach suggests that it is actually not true! It seems instead that normal people (as opposed
tothosewhohavehadobjectorienteddesigntraining)viewtheworldmostofthetimeinterms
ofhowtheyinteractwithit. So,insteadofseeingakettleasanobjectwithstateandbehaviour,
which interacts with a teapot, etc., the process of making a cup of tea is more likely to be
viewed as the set of steps that the person making it must go through. This is an essentially
imperativeview oftheworld. It is, quiterightly,very concrete, and agalaxy away fromobject
orientedabstractions.
So, when on day one of an objects first course, we talk to our students in object oriented
terms, those new to programming cannot easily relate it to their view of the world. Some are
nevertheless happy to live with these abstractions (but typically, later on, wish they could go
back there when suddenly asked to write a loop!). Most, it seems, struggle to see the point of
it all – for they cannot relate it to their existing idea of what a program is. This easily leads to
a lowering of morale, which becomes a further obstacle to learning, and is suspected to be a
factorin thehighattritionrates currentlyexperienced by manyuniversitycomputingschools.
v
CHAPTER0. PREFACE
0.2 Why not objects late?
Itisbelievedbyproponentsofanobjectsfirstapproachthat anobjectslateapproachisbadbe-
causestudentsfinditverydifficulttoswitchfromanimperativeparadigmtoanobjectoriented
one. This too sounds plausible, as we all know how hard it can be to unlearn. Interestingly
however, from my experience this also seems not to be true. Students who have had signifi-
cant previousprogrammingexperiencein the imperativeparadigm before they start an objects
first, first programming course, have a demonstrable advantage over those who have not pro-
grammedbefore,andnearly allswitchtheirmindsetreasonablysoonifyoupersuadethemto.
(The ultimate persuasion is to award no marks otherwise!) For these people, their program-
ming education was objects very late! Indeed, objects first proponents themselves switched
paradigm with presumably not much difficulty when they first met object oriented program-
ming,aftermanyyears ofprogrammingin theimperativeparadigm.
However, the problems of paradigm switching are more likely to be significant for those who
were new to programming at the start of an objects late course. Having struggled to learn
programming and only just started to gain some real confidence in their programming skills,
these students must be vulnerable to psychological set-back when told they are now going to
meet a different kind of programming. After spending most of the course in the imperative
paradigm, it surely cannot be possible to introduce the object oriented approach without it
beingperceivedas aradical and unsettlingchange.
In other words, the objects late approach introduces object-oriented programming as a radical
change which is too soon for these people, compared with those who have programmed for
years withoutobjects!
0.3 Who are our students?
The expectation of students who have not previously done any programming when starting a
programming course has changed dramatically since, say 1980. Prior to that almost nobody
going to university had done any programming, and everyone expected it to be hard and mys-
terious. Manystudentsstruggled,butmostwererelievedthatitwas onlyas hard asitreally is.
Nowadays their counterparts expect programming to be easy – they have much experience of
using,andtoanextent,installing,softwarewhichisdesignedforthedumbuser,anddonotap-
preciatethedifferencebetweenthisandcreatingprograms. True,theirgeneralfamiliaritywith
computer interaction is far more than the previous generation, but more important is that the
inherentdifficultyofprogrammingisfargreaterthantheir expectation. Thishurdle,especially
when it manifests on day one as a scary feeling of being totally lost for the first time in their
academic life, must be a direct contributor to the high course attrition rate phenomenon cur-
rently experienced by most computing schools. So we as teachers must be even more careful
tofind agentleintroductiontofirst programmingthan everbefore.
Ontheotherhand,nowadaysmanymorestudentshaveprogrammedbeforegoingtouniversity
vi
0.3. WHOAREOURSTUDENTS?
thanwasthecasepriorto1980. Thefractionwithpriorexperienceprobablypeakedaroundthe
late1980’sandthendeclinedtobeabout50%onaComputerSciencedegreecoursetoday. By
observing thedifference in behaviourof groups of students having this 50%, and othergroups
with hardly any students who have programmed before, I am convinced the apparent relative
success of typical modern first programming courses depends on the peer assistance of those
who have a head start, often to the extent of well intentioned help that crosses the line into
plagiarism. Afirstprogrammingcoursethereforeshouldfocusalmostexclusivelyontheneeds
of those who are new to programming, without relying on this peer assistance, indeed at the
riskofboringthosewho havepreviousexperienceat times.
One abstraction that everyone has become used to throughout their life is the idea of a set of
instructions which must be followed. For example, instructions from a parent about how to
tidy a bedroom, a recipe for making a cake, operating instructions for a VCR, or installation
instructionsforapieceofsoftware. Peoplehavemetsomany concreteexamplesofthisprinci-
ple that they are ready forthe step of explicitlygeneralising the idea into an abstraction. Even
priorto1980,studentsoffirstprogramminghadnoreal problemswiththesimpleconceptthat
aprogram isalistofinstructionstobeobeyedby thecomputer.
A programming course which is designed to be comfortable to those who have never pro-
grammed before, must start at the place where those students already are, not expect the stu-
dents to leap on day one to where the teacher is. Such students already believe a program is
somethingwhichcomesonaCDROM (say),mustbeinstalledonthecomputer,started,prob-
ably interacted with by the user, and quit or ended in some way. It is rather like making a cup
oftea– thisisan essentiallyimperativeviewofprogramming.
Traditionally, the biggest early stumbling block for students new to programming has always
been the concept of a variable. In late primary school, all students are introduced to algebra,
and many struggle at first with the principle of mathematical variables such as x. This is be-
cause such abstractions are unnatural in their so far very concrete world. Up to that point, the
few applications of a variable, such as the x in a written letter starting “Dear x”, were taught
by example only, leaving the generalisation still deeply implicit. Variables in a state-based
programming language are even harder than algebraic ones. Algebraic variables are just un-
knowns, or if you like, they are variable constants. The value of x does not change during
the evaluation of a polynomial, such as 3x2+2x. By contrast, program variables are variable
variables – their value changes during the run of a program. Once again, students new to pro-
gramming have never seen this principle generalised. They have only met a few real world
examplesofit,suchas thescoreina gameoffootball.
Anobjectsfirstcoursestartsbytakingthealreadytrickynotionofaprogramvariableandpiles
additional complexityon top of it, without giving the student any chance to see the reason for
this complexity. Many objects first proponents now claim that some kind of graphical tool is
required to help students visualise the objects and classes they are manipulating because the
concepts are tooabstract forthem tohold apictureintheirheads. Perhaps thisis liketeaching
ababy towalk, beforehecan crawl, bygivinghimcrutches?
vii
CHAPTER0. PREFACE
0.4 Basics first, objects soon
The basics first, objects soon approach finds the compromisebetween the two extremes found
in most other courses. Focusing on the needs of those new to programming, it starts at the
place where they are, but slides into object oriented programming at just the right time. This
momentissoonenoughsoitisnotperceivedasachangeofparadigm,butlateenoughthatthe
students can move from their starting point toward it. This is made possible simply because
theimperativeparadigmisasubsetoftheobjectoriented one– objectsand classesare seen as
merely anotherprogrammingconceptbuildingon thelayersalready introduced.
This just in time principle for layering the introduction of concepts has already been estab-
lishedpracticeinimperativeprogrammingcourses,forexamplewithrespecttotheteachingof
program variables. This book too starts with example programs which do not have variables,
rather like the students’existing notion of a set of instructions. Then, before students begin to
think that all programs have no variables, it moves on to examples which do have them, but
do not change them, rather like their existing grasp of mathematical variables. Then, before
the students begin to think program variables really are the same as mathematical variables, it
moves on again to programs which change their variables. None of these steps are presented
too slowly(late)that they are perceived as radical changes, nortoo fast (early) that theyfail to
relatetothestudents’existingunderstandingat thetime. Moreoverall oftheconceptsaremo-
tivated, by the students seeing the need for them through the example problems they allow us
to solve, and always relate to what the students expect programming to be, as that expectation
changes.
0.5 Inheritance later
Applyingthejustintimeprinciple,itfollowsthattheplacetointroduceinheritanceiswhenthe
studentsalreadyhaveathoroughgraspofobjectsandclassesandarereadytolookatexamples
of classes that share characteristics, and thus have significant amounts of repeated code. The
reason for the sharing can be explored, and the concept of inheritance derived. Meanwhile,
theconcept iscompeting withmany otherprogrammingconcepts, such as flow control, GUIs,
arrays,etc..,allofwhichareintroducedinorderoftheirgeneralusefulnesssotheexamplescan
become more exciting. Inheritance is less useful than loops, GUIs and arrays etc., so it comes
later. However, there are no examples which could benefit from it before it is introduced, so it
toois notseen as aradical change.
0.6 Note
Therest ofthispreface is stillin noteform.
I alsouseitas a handyplacetorecord somegeneral notesabout thedevelopmentfornow.
viii
0.7. TEACHINGPRINCIPLES
0.7 Teaching principles
1. Basics first, objectssoon,inheritancelater.
2. A bottom up introduction of concepts, motivated by examples. A top-down, object ori-
ented perspectiveafterobjectsand classesare properlycovered.
3. Thechaptersaretopicbasedbythemajorconceptgroups. Butwithinthese,theconcepts
are example driven. This means they are immediately motivated for use in the example
being presented. This also supports the subtle, but important perspective: programming
isabout solvingproblems,not aboutprogramminglanguage.
4. No “boiler plate” – explain everything when it is first met; but only in minimal detail
to explain the example. This avoids loss of confidence due to not knowing which bits
shouldbeunderstoodand whichcan beignored untillater.
5. Revisit concepts in later examples to explain more, ultimately to explain them properly
whenthestudentisready. Forexample,classisfirstintroducedmerelyasawayofsplit-
ting up large programs. Later it will be explained as a means of categorising behaviour
ofobjects(as wellas ameans ofsplittingup largeprograms).
6. In early chapters (Essential basics) the emphasis will be on reading programs, and ex-
pecting students to modify them or write very similar ones. In the later chapters, the
emphasis will be on design – how the programs are written, not just what they end up
being.
7. When methods (otherthan main) are introduced, it will be motivatedby wanting to use
thesamecodein morethan oneplace inan example.
8. Whenclassesarefirstintroduced(properly)itwillbemotivatedbywantingtoreducethe
numberofvariablesinanexample(datesofbirth),andthenwantingtoputthecodethat
manipulatesthosevariables withthem,tomaketheclass moreselfcontained.
9. When object making is first introduced, it should be making instances of a class the
students have just seen being developed, so they can understand both sides of the line.
Then theyshouldseeaclass whichis big,but onlyuses Javaconcepts theyhavealready
met – sothey could read thecode. They willbeasked to useit in thelab, and willlearn,
gratefully, that they do not have to read the code! They will appreciate the benefit of
class documentation, and thus be motivated to understand encapsulation. Then they are
readytousestandardAPIclasses. Thisisimportant: inanobjectsfirstbook,studentscan
wrongly gain the impression that the reason for not reading the code of classes written
byotherprogrammersis thattheycontainJavaconcepts that havenotyet been taught.
10. Once the principles of classes and objects are introduced, the same program example(s)
willberevisitedfromanOOdesignpointofview: redevelopingit/thembutSTARTING
withtheclassstructure. Fromthen onit willbea moretypicalOO programmingbook.
11. Have coursework associated with each chapter, with the brief description of the lab pre-
sented at the start of the chapter so students can feel that what they are learning (e.g. in
lectures)willbelinkedtothemarkstheywillend upgetting inthelab!
ix
CHAPTER0. PREFACE
0.8 Where and TTD
Thisis(mainly)justformybenefit. Somethingswhichmayneedahomefoundforthem. And
things which needs doing. (Some of these may have already been sorted out since I last went
throughthelist.)
• For-each loop: canh’t changeelementsofarray, butcan changeobjectstheypointto.
• For loop – not *just* for when known number of times, but more generally when want
loopoversomerangeofvalues. ???
• Explain how to use book, including each task done in a separate directory (folder) be-
causeoften variationsofprevioustasks andwillwant tokeep originalversions.
• Sort out index refs for System.out.println(). Use: System.out.println() Also check
forsameintheMath,Integer,Doubleclasses.
• Check forconcepts beingenclosed inLatexconcept command.
• Check forNB versionof
methodafter“called”.
• Checkforconceptswhichareclassmethodsandincludenameofclassinnameofmethod
inconcept title.
• Aimsonchapters?
• Selfassessmentquestionson concepts?
• T... – shouldwecoverthis? In arrays chapter?
• Assert? MaybehaveafinalchapterwhichidentifiessomeoftheaspectsofJavathatwere
notcovered? Threads?
• See NOT-0160-Bitsmissed/*– makesurehaveall been includednow.
• Enumtypes?
• Foreach loops?
• When introducemultiplemethodsofsamenameusetheterm overloading.
• compareTo and equals – somewhere should invite the reader to go find all the places
where compareTo was provided, change it to compareTo of Comparable and make sure
there is an equals method too. Also, danger of equals(ThisClass other) in ThisClass –
overloadingversusoverriding,whenused withcollections.
• Similar: equalsand hashCodeconsistency.
• Unary minus!!! ??? Is thisdoneyet???
x