UNIVERSITY OF MANCHESTER
School of Computer Science
Java Just in Time: a first course in programming
Pedagogical design principles
Back in early 2004, a small group of experienced lecturers here at Manchester sat down to indentify the pedagogical principles behind the `ideal' first programming in Java course. For the previous three years, we had run an objects-first Java course, and we were not happy with the experience!
Having identified the principles, we then invited publishing rep.s to find a book that matched. They could not, and so Java Just in Time was born.
Here are some of the pedagogical principles we identified. For each area, we present various views or choices and mark whether we believe them to be `right' or `wrong'.
Section links
| Objects first or later? | Should objects be introduced on day one, or at the end, or `soon'? |
| Inheritance when? | Should inheritance be introduced at the same as time as objects, or later? |
| Arrays before or after objects | Should arrays be covered before, objects, or after? |
| Class introduction: fanfare versus stealth | As we are not doing objects first, when they are covered properly how should the reader find them? |
| Motivation for objects | How should objects be motivated? |
| Example versus Topic oriented | The relationship between programming concepts and program examples. |
| Full programs, or fragments? | Should examples and coursework be full stand alone examples, or just, say, methods within a given framework? |
| Just in Time concept coverage | There is no easy way into Java as it is conceptually circular. How are early concepts introduced? |
| Making first objects: open or closed box | Should students see instances being made before classes, or classes than instances at the same time? |
| Class design | How much emphasis on class design should there be? |
| UML | How, if at all, should UML be used? |
| Method design | How much emphasis on method (algorithm) design should there be? |
| Testing | How should program testing be covered? |
| Use of special classes | Should special support classes be used to help hide language/API details early on? |
| Environment tools | What IDE should be used, if any? |
| Nature of coursework | Large exercises or small ones? |
Objects first or later?
Should objects be introduced on day one, or at the end, or `soon'?
Arguments / choices: tick means we agreed, cross means we did not!- Thinking in object oriented ways is already natural to novice programmers.
- Students who have not programmed before have a `self centric' view of problem solving -- i.e. what tasks they must perform to achieve the goal. All problems they have ever solved have had this `task oriented' view at the heart of the solution.
- Objects are so central to (OO) programming, that `bolting them on later' undermines them.
- Programming is at least 51% confidence. Introducing objects late undermines that confidence, so can destroy it (unless it is very late).
Anecodote: we tried an objects first course here at Manchester for three years. The students fell into three categories, as follows.
- ~50% Those who had programmed before, nearly all not with objects. These were the most successful -- we merely had to beat them over the head to take OO progamming on board! Their overall learning was not objects first.
- ~17% Those who had not programmed before, but liked `messing' with object diagrams from day one, and could happily regurgitate any diagram we had shown them. When we finally started using loops, they screamed in agony -- ``please can we stick to diagrams?''. They didn't seem to have a feeling for how the diagrams related to programming, but didn't mind.
- ~33% Those who had not programmed before, could not see how the diagrams had anything to do with programming and were worried about that -- ``Mammal, subclass Lion, instance Leo -- is this because zoos have computers?'' is what they often asked (literally!). When we started covering loops they said ``at last -- this is what I expected programming to be''.
Conclusion: basics first, objects soon.
Back to topInheritance when?
Should inheritance be introduced at the same as time as objects, or later?
Arguments / choices: tick means we agreed, cross means we did not!- Inheritance is fundamentally central to the idea of objects, is a great motivator for them, and should be introduced at the same time as objects.
- Students take time to understand the difference between class and instance, particularly the difference between instance variables / methods and class variables / methods. The relationship between superclass and subclass muddies this, if that idea is introduced at the same time.
Conclusion: basics first, objects soon, inheritance later.
Back to topArrays before or after objects
Should arrays be covered before, objects, or after?
Arguments / choices: tick means we agreed, cross means we did not!- Arrays before objects: concern that the students can then write real programs, and so objects are more difficult to motivate when they arrive.
- Arrays after objects: this makes objects arrive sooner, which is consistent with `objects soon'. Also, arrays are objects, but are more complicated than instances of classes.
Conclusion: Objects before arrays.
Back to topClass introduction: fanfare versus stealth
As we are not doing objects first, when they are covered properly how should the reader find them?
Arguments / choices: tick means we agreed, cross means we did not!- Fanfare: classes appear as a change of paradigm, introducing `object-oriented' programming. Concern that students new to programming will have their new-found confidence shaken.
- Stealth: classes and objects are slipped in as `just another programming concept', well motivated, at the right time.
Conclusion: Stealth, although it is necessary to warn students who have previously programmed that they may be meeting new ideas at that point.
Back to topMotivation for objects
How should objects be motivated?
Arguments / choices: tick means we agreed, cross means we did not!- It is important that students understand the relationship between objects within a Java program, and objects pertaining to the `real world' problem being solved by that program.
- The benefits of modelling `real world' objects as Java objects is immediately obvious to students, and thus is the motivation for doing so.
- The benefits of modelling `real world' objects as Java objects is only obvious to people who have tried programming in a context where doing so would really help, but without doing so!
- Students typically find the details of how objects are created and used quite tricky, and thus it is most important that they see the benefits of the ideas as they are introduced.
Conclusion: Objects are presented as a device to simplify a program previously seen. This is done in stages, the first introducing the minimum Java technology to use objcts at all, the later one adding on more technology. Once complete, the whole program design is revisited in the context of objects, i.e. OO design.
Back to topExample versus Topic oriented
The relationship between programming concepts and program examples.
Arguments / choices: tick means we agreed, cross means we did not!- The order should be fully example driven. Each chapter is an example. This either makes the chapters too short, or the examples too long!
- The order should be fully topic driven. Each chapter is a topic, each section is a topic. Concern that concepts are introduced for their own sake, giving the impression that programming language is more important than programming. Examples support the topics (if we are lucky!).
- The order should be half way between the above extremes. Each chapter is a topic, but each section is an example. Examples are short, full programs, and are focused to support new and recent concepts. Concepts are only ever introduced to solve examples, and so their motivation is never questioned. Some longer examples are good too.
Conclusion: Half way: one (or two) main topic(s) per chapter, one example per section.
Back to topFull programs, or fragments?
Should examples and coursework be full stand alone examples, or just, say, methods within a given framework?
Arguments / choices: tick means we agreed, cross means we did not!- Computers can be analysed at various levels of abstraction, e.g. atomic level, chip, hardware, low level software, higher level software, application level, etc.. Problem solving can take place at every level, and to some extent the solving process is the same.
- In order to learn programming, it is not necessary to work at all levels of abstraction.
- Students have previously used computers without worrying about the levels of abstraction.
- Thus there is no particular level of abstraction of intrinsic benefit to students new to programming.
- Details such as main method and command line arguments, are too difficult to teach to new programmers, and should therefore be avoided.
- Thus students should learn programming by writing classes and methods that are invoked by a hidden mechanism.
- Motivation for learning is critical to successful learning, and students want to learn `proper programming'.
- When students download and run `proper programs', they don't have to start some specific mysterious environment in which to run them.
- Writing anything other than full (`proper') programs undermines student motivation.
Conclusion: Within reason, all examples should be full programs.
Back to topJust in Time concept coverage
There is no easy way into Java as it is conceptually circular. How are early concepts introduced?
Arguments / choices: tick means we agreed, cross means we did not!- Fully explained: every cocnept is fully explained when it is first met. Assuming we are showing full programs, this means the course must be objects/classes first!
- Fully listed: alternatives (e.g. visibility modifiers) get listed but not explained when one of them is to be explained.
- Boiler plate: things not ready to be explained yet are stated as ''to be explained later, just type it for now''. Concern that students `want to know' and/or feel insecure about what they should and should not understand.
- Just in Time: things are explained only at a level of understanding appropriate to the knowledge and experience of the reader, and only those concepts which are currently visible to the reader. Then they are explained in more detail at an appropriate point later.
Conclusion: Just in Time.
Back to topMaking first objects: open or closed box
Should students see instances being made before classes, or classes than instances at the same time?
Arguments / choices: tick means we agreed, cross means we did not!- Closed box: making instances of already written classes, e.g. API classes, enables the objects to be introduced and manipulated whilst protecting students from the complexities of how objects are described.
- Such closed box coverage can give students the wrong idea about encapsulation -- that it is for `dumb' users, rather than busy users. It can cause them to not understand the line between class and object properly.
- Open box: first objects should be instances of classes the students have (just) seen, so they understand the difference between class and object, and appreciate what encapsulation means.
- Later they can see and use many API and be invited to either read the documentation or the source code!
Conclusion: Classes and instances are introduced together, i.e. there should be absolutely no occurences of the word new before that point.
Back to topClass design
How much emphasis on class design should there be?
Arguments / choices: tick means we agreed, cross means we did not!- High priority: students get lots of practise designing class hierarchies. Concern that there is too much to fit into the first year, and this needs experience of programming to appreciate properly.
- Low priority: students are given class hierarchies as needed, with some discussion about design principles.
Conclusion: Low priority -- emphasis on OO-programming, upon which more complex OO-design can later be built.
Back to topUML
How, if at all, should UML be used?
Arguments / choices: tick means we agreed, cross means we did not!- Lots / all of UML, for its own sake: concern that students have to learn more notation when its usefulness in introductory programming is doubtful. The benefits of some of UML is not immediately obviosu even to a seasoned programmer, let alone a novice, and so its exposure is likely to undermine the growing but fragile confidence.
- Only as helpful: none for its own sake, only where and when it helps to explain programming concepts. That is, places where the student can immediately see how it applies, and that it is useful.
Anecodote: we tried an objects first course here at Manchester for three years, using a book which used UML throughout. The students fell into two categories:
- Those who could not see the relevance of UML, but did not mind -- it was `easy marks' -- certainly easier than writing code!
- Those who could not see the relevance of UML, but did mind -- they thought they were supposed to see, and thus their comfort, and worst case, their confidence was undermined.
Conclusion: Only as helpful -- in practise this means nowhere except inheritance heirarchies.
Back to topMethod design
How much emphasis on method (algorithm) design should there be?
Many Java books often put plenty of emphasis on class design, but somehow expect the reader to be already a natural algorithm designer!
Arguments / choices: tick means we agreed, cross means we did not!
- Implicit/absent: students get shown lots of algorithms, but never given any hints about how to design algorithms.
- Explicit: early examples are just presented, but at an
appropriate time, we present design strategies, including:
- use of pseudo-code
- top-down step-wise refinement (is there a more modern name for this?)
- data driven design (i.e. emphasis on meaning of variables, and then merely maintain their consistent value throughout the code);
Conclusion: Explicit.
Back to topTesting
How should program testing be covered?
Arguments / choices: tick means we agreed, cross means we did not!- Full on: bang on about testing, with theory (at first year level) from day one. Concern that this makes the early programs boring, and overloaded with concepts.
- Stealth: tests are visible from day one, at first as random tests, then as appropriate with more thought about testing, and later some discussion of testing theory.
- Flaky: just some random tests all the way through.
Conclusion: Stealth. (???? Testing theory discussion is on this web site, rather than in the book. ?????)
Back to topUse of special classes
Should special support classes be used to help hide language/API details early on?
Many books use some specially written Java classes to aid students early on.
Arguments / choices: tick means we agreed, cross means we did not!
- Use special classes: whilst is might help early on, it creates a dependence which is hard to shake off later. Also, despite best efforts, many students think they are part of the standard Java API!
- No special classes: use only the standard Java classes, to support ones exemplified in the book.
Anecodote: we tried an objects first course here at Manchester for three years, using a book that had an API of special classes to support it. They were simple to use, although they didn't always work, and were not very flexible. We had terrible trouble weaning the students off them onto the standard API classes. Many students insisted on using these toy classes for their third year project -- they simply could not let go of these `swimming floats', and so never really gained the confidence to swim in deep waters.
Conclusion: No special classes..
Back to topEnvironment tools
What IDE should be used, if any?
Arguments / choices: tick means we agreed, cross means we did not!- The students' programming environment should not be unduly uncomfortable.
- So, make it trvially comfortable -- use an IDE from the start. Concern that students will not appreciate what the IDE is doing for them, the IDE will obscure the very basics (e.g. compile versus run cycle); and lock the students' confidence into that environment.
- A very large portion of the learning to program process involves the student building confidence in their own skill. This confidence is typically grounded in the environment used whilst gaining it.
- The students' programming environment should, at least
initially, use only the minimum basic features common to all environments.
This way their their confidence will be based upon the most general
foundation, and is thus transferable to other environments. These most basic
features are:
- A text editor so the student can write program source.
- Access to the compiler, javac.
- Access to the virtual machine java.
Conclusion: A clean, uncluttered command line! Linux is ideal, and that is what we use!
Windows command prompt is a little messy, but still usable. Can anyone suggest an IDE that only has the three features listed above? E.g. a text editor that has plug-in compile and run programs?
Can anyone suggest how Eclipse can be used in `minimalist' mode?
Back to topNature of coursework
Large exercises or small ones?
Arguments / choices: tick means we agreed, cross means we did not!>>>>>>Please note this page is under development.<<<<<<<
Conclusion:
Back to top