Originally published in the July/August 2014 issue of Java Magazine. Subscribe today.
by Michael Kölling
Published July 2014
Visualization and interaction tools illustrate aspects of object-oriented programming.
In this second part of a two-part series, we continue our discussion of BlueJ’s interaction features—the main aspect that differentiates BlueJ from other environments. In Part 1, we discussed why interaction and visualization are important for learners, and we started by demonstrating the first (and most fundamental) examples of the visualization of object-oriented concepts in BlueJ: the depiction of classes and objects. Both are visualized graphically and allow direct interaction that illustrates and reinforces their roles, characteristics, and behavior.
However, while the class diagram and object bench are the most immediately visible and obvious features in BlueJ, they are not the only tools available for developing or reinforcing an understanding of object-oriented concepts. In this article, we examine a number of additional BlueJ design elements and tools that help learners develop consistent mental models and explore aspects of object orientation.
When learners start working in BlueJ, they can work at a conceptual level that is abstracted from some of the underlying implementation details. For example, users of BlueJ create classes, not files. The distinction might be subtle at first, but it is meaningful. Users do not need to be concerned with the file system structure, or, for example, with the rule that the filename has to match the class name. In fact, they do not even need to know, initially, that the source code for classes is stored in files. In BlueJ, when a programmer changes the class name in the class’ source code, BlueJ automatically changes the underlying filename accordingly. Similarly, when a programmer changes the package name, BlueJ moves the source file to the right location.
At this point, experienced programmers often say “But it is important to know how Java classes are stored,” to which my answer is, “No, it isn’t—at least not at first.” The principle of named, interacting classes is fundamental to object-oriented programming; this is what beginners should concentrate on. The file system structure, filenaming rules, and other storage details are merely a coincidental detail of Java—there is no fundamental principle here. Classes might just as well be stored in a database or in any other persistent storage—it is really not important while you are still struggling with programming fundamentals.
A similar mechanism for working at a higher level exists for the relationships of classes in the class diagram: Inheritance and client relationships are depicted by two different kinds of arrows (see Figure 1). These arrows can be drawn in the diagram graphically, or the relationship can be defined textually in the source code, and the two representations will be kept in sync. If, for instance, a user inserts an inheritance arrow from class A to class B, the
extends B clause will be automatically inserted into class A’s source code. If the
extends clause is edited in the text, the diagram is updated to reflect this.
As discussed in Part 1 of this article, public methods of objects can be called interactively without the need to write test drivers. This mechanism illustrates communication with objects. However, the mechanism also helps users experiment with another concept: the passing of parameters.
When a method that expects parameters is invoked, a dialog box opens that shows the message signature and its comment, and the user is prompted to enter values for the expected parameters (see Figure 2). This interaction allows students to experience and understand the relationship between the parameter specification in a method signature and the actual parameter values that must be passed. A first encounter of this feature usually also includes a first discussion of datatypes.
An interactive invocation in BlueJ is internally translated into a transient class, which is then compiled using the standard compiler. This ensures that possible errors in an interactive invocation are reported using the same mechanism and the same message as equivalent errors in source code.
Objects as parameters. The interactive entry of parameters is not restricted to primitive types. Object composition—the passing of one object as a parameter to another—is also supported. When a parameter of an object class is expected, the user can click an object on the object bench to cause the object to be used as the parameter.
The last missing element related to method calls is the display of return values. If a method returns a result, the result is displayed in a separate dialog box. The user can then inspect the result or—if it is an object—place it on the object bench. If the user is in the process of recording a unit test, an assertion can also be added.
Taken together, interactive method invocation, parameter passing, and return value display provide a consistent and meaningful illustration of object communication in object-oriented systems. Performing this process interactively imbues students with a sense of how this interaction works, and it helps them gain a good understanding of the mechanism.
Methods, however, do not always return values; their effect might be a state change rather than an explicit result. State is the third of the three characteristics that define objects in object-oriented systems. (The other two are identity and behavior—and we have already seen how these are illustrated through interactive object creation, object display on the object bench, and method invocation.)
State is also visualized in BlueJ. Each object’s context menu includes an Inspect option, which displays a visualization of the object’s internal state (see Figure 3). Fields of the objects are listed with their type and name, and current values are displayed.
In the early phases of learning, it is especially enlightening to inspect two objects of the same type side by side and observe the similarity in fields, but the differences in values. Object inspectors can also remain open during interactive method calls to observe a state change more immediately.
Again, this tool visualizes an important principle of object-oriented programming and supports obtaining a valid model of machine behavior.
Static methods and inspection. Static methods can also be invoked interactively. This is done by selecting them from the class’—rather than the object’s—context menu. Similarly, static fields are displayed by inspecting the class rather than the object. This distinction in the interface reinforces the differences in definition between static attributes and object attributes.
As every teacher knows, understanding the object model is not the only difficulty in learning to program in Java. Beginning students also struggle with details of Java’s syntax when writing their programs.
One of the most common problems, especially for young learners, is the correct balancing of curly brackets to define scopes. The very concept of nested scopes—so seemingly natural for all of us who have programmed for some time—is difficult to grasp for many beginners, and the placement of matching opening and closing scope brackets is prone to errors. Professional environments have tried to help by automating the insertion of bracket pairs and by highlighting matching brackets. However, this has not caused a great reduction in beginners’ errors.
BlueJ goes a step further by automatically highlighting scopes in the editor using colored boxes (see Figure 4). Different types of scope (class, method, loop, and so on) are shown using different background colors, which serves two purposes. First, in syntactically valid programs, this visualization helps illustrate the concept of nested scopes, and it aids understanding. Second, if scopes are ill-defined—for example, because a bracket is missing—this display makes this fact immediately visually obvious. Scope highlights are updated in real time with every keystroke.
The object interaction discussed above supports a better appreciation of the object model, but students also need to develop an understanding of small-scale constructs: the individual statements and expressions of the programming language. Again, experimentation can help with developing an insight into these constructs.
To support this kind of experimentation, BlueJ provides the Code Pad (see Figure 5). The Code Pad is an interactive interpreter of individual textual Java statements or expressions. Statements are executed, and expression results are displayed.
In the Code Pad, variables can be defined, assigned, and inspected. The namespace is the same as the object bench, so references can be made to the classes in the project and the objects currently on the object bench. If the result of a Code Pad expression is itself an object, it is shown using a small object icon that can then be inspected or dragged to the object bench.
In terms of teaching and learning, the availability of the Code Pad (and the other experimentation features) fundamentally changes how we as instructors can interact with our students. Frequently in a class, I am asked questions of the type “What happens when I do X?” or “Can I do Y?” (for example, “What happens if I use the modulo operator with a negative number?” or “Is the second parameter in
substring the end or the length?”).
Having the Code Pad available, my answer invariably is, “Try it!”
Being able to give this answer, from a teaching point of view, is highly valuable for two reasons: Not only do students remember the answer better if they have found it through their own experiments rather than by being told, but they are also given tools and strategies for answering future questions independently.
The last tool that I want to mention is the interactive recording of unit tests. In BlueJ, tests can be performed manually and interactively, and this interaction can be recorded to automatically create JUnit test classes.
This mechanism was discussed in detail in an earlier issue of Java Magazine, so I won’t repeat a description here. However, this tool supports the same spirit as the other functionality we’ve discussed: Interaction allows experimentation, which leads to better understanding.
Environments designed for beginning programmers cannot assume that users already have a well-formed mental model of the constructs and principles involved in their programming systems. On the contrary, they must help users acquire such models.
BlueJ uses a range of carefully designed visualization and interaction tools to illustrate many aspects of object-oriented programming. They are integrated closely and complement each other. These tools include some that illustrate aspects—such as the overall object model—at the conceptual level and others that illustrate small-scale concepts, such as scope or the functionality of individual operators.
An educational environment such as BlueJ does not compete with professional development environments. It provides a transitional step, and it is hoped that every BlueJ user will eventually outgrow BlueJ and move on to use one of the more traditional environments. However, BlueJ has an important place in the learning of programming. Developing a thorough understanding of the principles before getting bogged down with professional tools can turn every learner into a better programmer.