|
1.
Introduction
Java is quickly
becoming very popular, both for application development and
for teaching, and many programming environments exist. This
raises the question:
The short answer is: because none of the existing
environments is suitable for teaching.
In particular, we want an environment that is really object-oriented.
An environment that emphasises classes and objects as its
basic units of interaction, so that students are naturally
led into a way of thinking in terms of classes and objects.
Secondly, we want an environment that is sophisticated, but
at the same time easy to use, so that students can
start using it straight away without the need for long introduction.
We do not want to teach about the environment itself.
Thirdly, we want an environment that supports interaction
and experimentation.
Fourthly, we want an environment that uses visualisation
to display class structure. After all, half of the time
in a teaching context we talk about class structure. Structuring
the problem is one of the most important aspects of object-oriented
programming. Yet many teachers find that students have difficulty
thinking in terms of classes and objects. This is not surprising
if all they ever see on the screen are lines of code or interface
buttons and menus!
2.
The problems with existing environments
Several aspects
in existing environments cause a long list of problems in
teaching. One or more of these problems is present in every
other environment.
- The environment is not really object-oriented.
An environment for an object-oriented language does
not make an object-oriented environment. The environment
itself should reflect the paradigm of the language. In particular,
the abstractions students work with should be classes and
objects. In most existing environments, students deal with
files instead. They are forced to think about the operating
system's file system and directory structure. Setting up
projects can be a nightmare. All this creates overhead that
hinders teaching and distracts from the important issues.
Objects as interaction entities are not supported in any
other Java environment. Yet they are one of the most fundamental
abstraction concepts.
- The environment is under- or overkill.
Many teachers do not use an integrated environment (usually
because of problems with finding a suitable one). In that
case, students work from a command line (using Sun's JDK)
and spend considerable time becoming familiar with Unix
or DOS instead of learning about programming. In this case,
valuable opportunities are lost for better teaching and
learning through the use of better tools. Other environments
are developed for more professional users and present an
absolutely overwhelming set of interface components and
functionality. Students are lost in these environments,
and the effect can be as bad as having no integrated environment
at all. Other environments are really modifications of non-object-oriented
(procedural) environments and offer the wrong set of tools
and abstractions. All of those, too minimalist tools, too
complicated tools or the wrong tools, cause considerable
problems.
- The environment focuses on user interfaces.
Many environments using graphics use the graphics for
the wrong tasks. In particular, many environments concentrate
on building graphical user interfaces (GUIs). Building GUIs
from the start conveys a very distorted picture of programming
and object-orientation. Students spend their time dragging
buttons rather than thinking about building an application.
At the same time a much more beneficial use of graphics
is neglected: display of class structure. Object-oriented
program structure can be represented graphically in a way
that makes it easier to understand. Few existing environments
make good use of this.
- The environment is expensive.
Cost is still a big problem with some environments.
One effect of this is the problem for students to work at
home - acquiring a license for home use can be expensive.
3.
The BlueJ solutions
BlueJ addresses
all of these problems:
- BlueJ is object-oriented.
In BlueJ students interact with classes and objects.
They can manipulate class structure graphically and textually.
Objects can be created and methods of any object can be
called interactively.
- BlueJ has been designed for teaching.
BlueJ offers a unique mix of sophisticated support for
visualisation and interaction and a simple and intuitive
interface.
- BlueJ visualises class structure and objects.
In BlueJ, class structure can be seen and manipulated
on screen, and objects can be interactively created and
operations called.
- BlueJ is free.
The environment is available free of charge.
4.
Problems with Java (and BlueJ's answers)
Java is a
reasonably clean language, but by no means free of problems
for introductory teaching. For teachers, it is important to
know those problems and to have a way to deal with them. Two
of the problems most often reported in the literature (for
example in [1] and [4]) are:
- problems with the main function
- problems with text I/O
The main function: The main function has to be written
with the signature
This causes
several problems. Firstly, several concepts are used here
which cannot be explained at this stage (static functions,
arrays, void return types). So teachers have to use some
hand-waiving ("just believe me and write it like this")
and students feel frustrated. Secondly, this has nothing
to do with object-orientation! The main function does not
logically belong to any object. Thus, students start off
with seeing an exception rather than a good example of object-orientation.
I/O: Text I/O, especially input, is not simple and
causes regular problems. In addition, it forces students to
deal with exceptions at a very early stage.
BlueJ solves both of these problems!
Because objects can be created interactively, and methods
can be called interactively, there is no need for a main function.
Students can write classes and call their methods without
a need to have a main. And because parameters can be
passed to interactive method calls and results are displayed,
there is no immediate need for I/O. Students can write and
test very sophisticated code without the need for any I/O
operations!
5.
Real object-oriented teaching
Many Java
text books claim to use an "objects first" approach. We very
much agree with this idea. In reality, most of the books then
go on to explain some low level instructions first and get
to objects and classes in chapter four. The reason is an intrinsic
problem with Java: if you explain classes first, then you
still need a way to execute the class's operations to see
a result. And to do this you have to write some driver code.
To write this code, you need to know some Java instructions.
In BlueJ, no driver code is needed. Operations can be invoked
interactively, so teachers are free to use a real objects-first
approach for the first time. Students can be given a class
of which they can create objects. They can use those objects.
Then they can open them and read, modify or add operations.
This is really "objects first" with the introduction of lower
level constructs after methods (as a means to implement those
methods).
6.
Our experiences
We have previously
worked on a system named Blue
[2,3]. Blue is a programming language and an integrated environment.
BlueJ is an almost identical environment as that used in the
Blue system, with Java as the supported language. Experiences
with Blue have shown the environment to be extremely successful
in getting students to work independently very quickly. It
has proven very helpful in conveying important object concepts,
and students mastered working with object-orientation and
with the environment in very short time. Some aspects of the
Blue environment which apply equaly to BlueJ are described
in [5] and [6].
BlueJ is now used internationally at many universities (see
the list of users, if you
are interested). The feedback
is overwhelmingly positive. We have used BlueJ ourselves in
our own teaching since the start of 1999, with about 300 students
per year. For us, BlueJ has kept all its promises.
7.
Summary
BlueJ offers:
- a project manager, a compiler, an editor, a debugger,
a virtual machine
- full tool integration (compilation from within the editor,
compiler error message display in the editor, setting breakpoints
in the editor, etc.)
- abstraction from operating system
- class structure visualisation
- direct object interaction
- simplicity, easy-to-use interface
References:
[1] David Clark, Cara MacNish and Gordon F.
Royle, Java as a teaching language opportunities,
pitfalls and solutions, in Proceedings of the Third Autralasian
Conference on Computer Science Education, ACM, Brisbane, Australia,
July 1998.
[2] Michael Kölling and John Rosenberg, Blue
- A Language for Teaching Object-Oriented Programming,
in Proceedings of 27th SIGCSE Technical Symposium on Computer
Science Education, ACM, Philadelphia, Pennsylvania, 190-194,
March 1996.
[3] Michael Kölling and John Rosenberg, An
Object-Oriented Program Development Environment for the First
Programming Course, in Proceedings of 27th SIGCSE Technical
Symposium on Computer Science Education, ACM, Philadelphia,
Pennsylvania, 83-87, March 1996.
[4] Robert K. Allen, Kevin Bluff
and Annette B. Oppenheim, Jumping Into Java: Object-Oriented
Software Development for the Masses, in Proceedings of
the Third Autralasian Conference on Computer Science Education,
ACM, Brisbane, Australia, 165-172, July 1998.
[5] John Rosenberg and Michael
Kölling, I/O Considered Harmful (At least for the
first few weeks), in Proceedings of the Second Australasian
Conference on Computer Science Education, ACM, Melbourne,
216-223, July 1997.
[6] John Rosenberg and Michael
Kölling, Testing Object-Oriented Programs: Making
it Simple, in Proceedings of 28th SIGCSE Technical Symposium
on Computer Science Education, ACM, San Jose, Calif., 77-81,
February 1997.
|
