Interactive Programming

in Java

Lynn Andrea Stein

©1999 Lynn Andrea Stein || http://www.mkp.com/ipij

 contents
List of Sidebars
Preface

Part 1 Introduction To Interactive Program

Design
Chapter 1 Introduction to Program Design
Chapter Overview
Objectives of this Chapter
1.1 Computers and Programs
1.2 Thinking Like a Programmer
1.3 Programming Primitives, Briefly
1.4 Ongoing Computational Activity
1.5 Coordinating a Computational Community
1.5.1 What is the Desired Behavior of the Program?
1.5.2 Who are the Members of the Community?
1.5.3 What Goes Inside Each One?
1.5.4 How Do They Interact?
1.6 The Development Cycle
1.7 The Interactive Control Loop
Chapter Summary
Exercises

Interlude 1 A Community of Interacting Entities

Overview
Objectives of this Interlude
1.1 Introduction: Word Games
1.2 Designing a Community
1.2.1 A Uniform Community of Transformers
1.2.2 The User and the System
contents

1.2.3 What Goes Inside

1.3 Building a Transformer

1.3.1 Transformer Examples
1.3.2 Strings
1.3.2.1 String Concatenation
1.3.2.2 String Methods
1.3.3 Rules and Methods
1.3.4 Classes and Instances
1.3.5 Fields and Customized Parts
1.3.6 Generality of the Approach
1.4 Summary
Suggested Exercises
Sidebar: Selected String Methods

Part 2 Entities and Interactions

Chapter 3 Things, Types, and Names
Chapter Overview
Objectives of this Chapter
3.1 Things
3.1.1 Primitive Things and Literals
3.1.1.1 Numbers
3.1.1.2 Characters and Strings
3.1.1.3 Booleans
3.1.2 Objects
3.2 Naming Things
3.2.1 Referring to Things
3.2.2 Assignment
3.3 Types
3.3.1 Declarations and The type-of-thing name-of-thing Rule
3.3.2 Definition = Declaration + Assignment
3.3.3 Primitive Types
3.3.4 Object Types
3.4 Types of Names
3.4.1 Shoebox Names
3.4.2 Label Names
 contents

Chapter Summary
Exercises
• Sidebar: Java Naming Syntax and Conventions
• Sidebar: Java Primitive Types

Chapter 4 Specifying Behavior: Interfaces

Chapter Overview
Objectives of this Chapter
4.1 Interfaces are Contracts
4.1.1 Generalized Interfaces and Java Interfaces
4.1.2 A Java Interface Example
4.2 Method Signatures
4.2.1 Name
4.2.2 Parameters and Parameter Types
4.2.3 Return Type
4.2.4 Putting It All Together: Abstract Method Declaration Syntax
4.2.5 What a Signature Doesn't Say
4.3 Interface Declaration
4.3.1 Syntax
4.3.2 Method Footprints and Unique Names
4.3.3 Interfaces are Types: Behavior Promises
4.3.4 Interfaces are Not Implementations
Chapter Summary
Exercises
 Style Sidebar: Method Documentation
 Style Sidebar: Interface Documentation
See also Java Chart on Interfaces.

Chapter 5 Expressions: Doing Things With Things

Chapter Overview
Objectives of this Chapter
5.1 Simple Expressions
5.1.1 Literals
5.1.2 Names
5.2 Method Invocation
5.3 Combining Expressions
5.4 Assignments and Side-Effecting Expressions
5.5 Other Expressions that Use Objects
contents

5.5.1 Field Access

5.5.2 Instance Creation
5.5.3 Type Membership
5.6 Complex Expressions on Primitive Types: Operations
5.6.1 Arithmetic Operator Expressions
5.6.2 Explicit Cast Expressions
5.6.3 Comparator Expressions
5.6.4 Logical Operator Expressions
5.7 Parenthetical Expressions and Precedence
5.7.1 String Concatenation
Chapter Summary
Exercises
 Style Sidebar: Don't Embed Side-Effecting Expressions
• Sidebar: Java Operators
• Sidebar: Arithmetic Expressions
• Sidebar: Coercion and Casting
• Sidebar: Java Operator Precedence
• Sidebar: Other Assignment Operators
See also Java Chart on Expressions

Chapter 6 Statements and Rules

Chapter Overview
Objectives of this Chapter
6.1 Statements and Instruction-Followers
6.2 Simple Statements
6.3 Declarations and Definitions
6.4 Sequence Statements
6.5 Flow of Control
6.5.1 Simple Conditionals
6.5.2 Simple Loops
6.6 Statements and Rules
6.6.1 Method Invocation Execution Sequence
6.6.2 Return
Chapter Summary
Exercises
 Style Sidebar: Formatting Declaration Statements
 Style Sidebar: Formatting Blocks
 Style Sidebar: Using Booleans
 contents

 Style Sidebar: Documentation

See also Java Chart on Statements

Chapter 7 Building New Things: Classes and Objects

Chapter Overview
Objectives of this Chapter
7.1 Classes are Object Factories
7.1.1 Classes and Instances
7.1.2 Recipes Don't Taste Good
7.1.3 Classes are Types
7.2 Class Declaration
7.2.1 Classes and Interfaces
7.2.1.1 implements and type inclusion
7.2.1.2 contract vs. implementation
7.3 Data Members, or Fields
7.3.1 Fields are not Variables
7.3.1.1 Hotel Rooms and Storage Rental
7.3.1.2 Whose Data Member is it?
7.3.1.3 Scoping of Fields
7.3.1.4 Comparison of Kinds of Names
7.3.2 Static Members
7.4 Methods
7.4.1 Method Declaration
7.4.2 Method Body and Behavior
7.4.3 A Method ALWAYS Belongs to an Object
7.4.3.1 this.
7.4.3.2 Static Methods
7.4.4 Method Overloading
7.5 Constructors
7.5.1 Constructors are Not Methods
7.5.2 Syntax
7.5.3 Execution Sequence
7.5.4 Multiple Constructors and the Implicit No-Arg Constructor
7.5.5 Constructor Functions
Chapter Summary
Exercises
 Style Sidebar: Class Declaration
• Sidebar: Java Types and Default Initialization
contents

¾ Table: Comparison of Kinds of Names

 Style Sidebar: Field Documentation
 Style Sidebar: Method Implementation Documentation
• Sidebar: Method Invocation and Execution
 Style Sidebar: Constructor Documentation
 Style Sidebar: Capitalization Conventions
See also Java Charts on Classes, Methods, and Fields.

Part 3 Refining Designs

Chapter 8 Designing with Objects
Chapter Overview
Objectives of this Chapter
8.1 Object-Oriented Design
8.1.1 Objects are Nouns
8.1.2 Methods are Verbs
8.1.3 Interfaces are Adjectives
8.1.4 Classes are Object Factories
8.1.5 Some Counter Code (An Example)
8.1.6 Public and Private
8.2 Kinds of Objects
8.2.1 Data Repostories
8.2.2 Resource Libraries
8.2.3 Traditional Objects
8.3 Types and Objects
8.3.1 Declared Types and Actual Types
8.3.2 Use Interface Types
8.3.3 Use Contained Objects to Implement Behavior
8.3.4 The Power of Interfaces
Chapter Summary
Exercises
 Style Sidebar: Class and Member Documentation
• Sidebar: Final
• Sidebar: class Math
Exercises
 contents

Chapter 9 Animate Objects

Chapter Overview
Objectives of this Chapter
9.1 Animacies are Execution Sequences
9.2 Being Animate-able
9.2.1 Implementing Animate
9.2.2 AnimatorThread
9.2.3 Creating the AnimatorThread in the Constructor
9.2.4 A Generic AnimateObject
9.3 More Details
9.3.1 AnimatorThread Details
9.3.2 Delayed Start and the init() Trick
9.3.3 Threads and Runnables
9.3.4 Thread Methods
9.4 Where do Threads come from?
9.4.1 main
9.4.2 Why Constructors Need to Return
• Sidebar: class AnimatorThread
• Sidebar: Thread Methods
• Sidebar: class Main
 Style Sidebar: Using main()
Chapter Summary
Exercises

Chapter 10 When Things Go Wrong: Exceptions

Chapter Overview
Objectives of this Chapter
10.1 Exceptional Events
10.1.1 When Things Go Wrong
10.1.2 Expecting the Unexpected
10.1.3 What's Important to Record
10.2 Throwing an Exception
10.3 Catching an Exception
10.4 Some Examples
10.4.1 throw
10.4.2 throw new
10.4.3 Basic catch
10.4.4 re-throw
contents

10.4.5 Cascaded catch

10.4.6 Which Exceptions are Caught Where?
10.5 Throw vs. Return
10.6 Signatures
10.7 Designing Good Test Cases
• Sidebar: Exceptions, Errors, and RuntimeExceptions
• Sidebar: Throw Statements and Throws Clauses
• Sidebar: Try Statement Syntax
Chapter Summary
Exercises

Chapter 11 Reusing Implementation: Inheritance

Chapter Overview
Objectives of this Chapter
11.1 Derived Factories
11.1.1 Simple Inheritance
11.1.2 java.lang.Object
11.1.3 Superclass Membership
11.2 Overriding
11.2.1 super.
11.2.2 The Outside-In Rule
11.2.3 Problems with Private
11.3 Constructors are Recipes
11.3.1 this()
11.3.2 super()
11.3.3 Implicit super()
11.4 SuperType as View
11.4.1 Peephole metaphor
11.4.2 Multiple Views
11.4.3 Overriding
11.5 Interface Inheritance
11.6 Relationships Between Types
• The class Object
 Style Sidebar: Explicit Use of this. and super()
• Sidebar: Abstract Classes
Chapter Summary
Exercises
 contents

Part 4 Refining Interactions

Chapter 12 Dealing with Difference: Dispatch
Chapter Overview
Objectives of this Chapter
12.1 Conditional Behavior
12.2 If and else
12.2.1 Basic Form
12.2.2 Else
12.2.3 Cascaded Ifs
12.2.4 Many Alternatives
12.3 Limited Options: Switch
12.3.1 Constant Values
12.3.1.1 Symbolic Constants
12.3.1.2 Using Constants
12.3.2 Syntax
12.3.2.1 Basic Form
12.3.2.2 The Default Case
12.3.2.3 Variations
12.3.2.4 Switch Statement Pros and Cons
12.4 Arrays
12.4.1 What is an Array?
12.4.1.1 Array Declaration
12.4.1.2 Array Construction
12.4.1.3 Array Elements
12.4.2 Manipulating Arrays
12.4.2.1 Stepping through An Array Using a for Statement
12.4.3 Using Arrays for Dispatch
12.5 When to Use Which Construct
• Sidebar: if statement syntax
• Sidebar: switch statement syntax
• Sidebar: constants
• Sidebar: array syntax
• Sidebar: for statement syntax
Chapter Summary
Exercises
contents

Chapter 13 Encapsulation
Chapter Overview
Objectives of this Chapter
13.1 Design, Abstraction, and Encapsulation
13.2 Procedural Abstraction
13.2.1 The Description Rule of Thumb
13.2.2 The Length Rule of Thumb
13.2.3 The Repetition Rule of Thumb
13.2.4 Example
13.2.5 Benefits of Abstraction
13.3 Protecting Internal Structure
13.3.1 private
13.3.2 Packages
13.3.2.1 Packages and Names
13.3.2.2 Packages and Visibility
13.3.3 Inheritance
13.3.4 Clever Use of Interfaces
13.4 Inner Classes
13.4.1 Static Classes
13.4.2 Member Classes
13.4.3 Local Classes and Anonymous Classes
Chapter Summary
Exercises (to come)

Chapter 14 Intelligent Objects and Implicit Dispatch

Chapter Overview
Objectives of this Chapter
14.1 Procedural Encapsulation and Object Encapsulation
14.2 From Dispatch to Objects
14.2.1 A Straightforward Dispatch
14.2.2 Procedural Encapsulation
14.2.3 Variations
14.2.4 Pushing Methods Into Objects
14.2.5 What Happens to the Central Loop?
14.3 The Use of Interfaces
14.4 Runnables as First Class Procedures
14.5 Callbacks
14.6 Recursion
 contents

14.6.1 Structural Recursion

14.6.1.1 A Recursive Class Definition
14.6.1.2 Methods and Recursive Structure
14.6.1.3 The Power of Recursive Structure
14.6.2 Function Recursion
Chapter Summary
Exercises

Chapter 15 Event-Driven Programming

Chapter Overview
Objectives of this Chapter
15.1 Control Loops and Handler Methods
15.1.1 Dispatch Revisited
15.2 Simple Event Handling
15.2.1 A Handler Interface
15.2.2 An Unrealistic Dispatcher
15.2.3 Sharing the Interface
15.3 Real Event-Driven Programming
15.3.1 Previous Examples
15.3.2 The Idea of an Event Queue
15.3.3 Properties of Event Queues
15.4 Graphical User Interfaces: An Extended Example
15.4.1 java.awt
15.4.2 Components
15.4.3 Graphics
15.4.4 The Story of paint
15.4.5 Painting on Demand
15.5 Events and Polymorphism
Chapter Summary
Exercises

See also the AWT Quick Reference.

Chapter 16 Event Delegation (and AWT)

Chapter Overview
Objectives of this Chapter
16.1 Model/View: Separating GUI Behavior from Application Behavior
16.1.1 The Event Queue, Revisited
contents

16.2 Reading What the User Types: An Example

16.2.1 Setting up a User Interaction
16.2.2 Listening for the Event
16.2.3 Registering Listeners
16.2.4 Recap
16.3 Specialized Event Objects
16.4 Listeners and Adapters: A Pragmatic Detail
16.5 Inner Class Niceties
• Sidebar: cs101.awt.DefaultFrame
Chapter Summary
Exercises

See also the AWT Quick Reference.

Appendices
Applets
Java.awt Quick Reference
Java Charts
About Java Charts
1 Program File
2 Class Declaration
3 Field Declaration
4 Method Declaration
5 Expression
6 Statement
7 Disclaimers, Notes, Amendments, etc.
Glossary
 contents

To come…

Part 5: Systems of Objects

Chapter 17 Models of Communities
Chapter Overview
Objectives of this Chapter
17.1 State Machines
17.2 State Spaces
17.3 Organizational Behavior
17.4 Network Models
17.5 Patterns
17.6 UML
17.7 Metrics
17.7.1 Static Complexity
17.7.2 Throughput and Latency
• Sidebar: FSM Rules
Chapter Summary
Exercises

Chapter 18 Interfaces and Protocols: Gluing Things Together

Chapter Overview
Objectives of this Chapter
18.1 Pacing
18.2 Procedure Calls
18.3 Callbacks
18.4 Explicit Communication Channel Objects
18.5 Protocols
Chapter Summary
Exercises

Chapter 19 Communication Patterns

Chapter Overview
Objectives of this Chapter
19.1 What is a Client-Server Interaction?
19.2 Implementing Client-Server Interactions
19.2.1 Client Pull
contents

19.2.2 Server Push

19.3 The Nature of Duals
19.4 Pushing and Pulling Together
19.4.1 Passive Repository
19.4.2 Active Constraint
Chapter Summary
Exercises

Chapter 20 Synchronization
Chapter Overview
Objectives of this Chapter
20.1 Reads and Writes
20.2 An Example of Conflict
20.3 Synchronization
20.4 Java synchronized
20.4.1 methods
20.4.2 (blocks)
20.5 What synchronization buys you
20.6 Safety rules
20.7 Deadlock
20.8 Obscure Details
Chapter Summary
Exercises

Chapter 21 Network Programming

Chapter Overview
Objectives of this Chapter
21.1 java.io Streams
21.1.1 Abstract Streams
21.1.2 Readers and Writers
21.1.3 Modifier Streams
21.1.4 Source Type Streams
21.2 A Reader/Writer
21.3 Opening a Client-Side Socket
21.4 Opening a Single Server-Side Socket
21.5 Serving Multiple Sockets
21.6 Server Bottlenecks
Chapter Summary
 contents

Exercises

Chapter 22 Conventional Architectures

Chapter Overview
Objectives of this Chapter
22.1 Server Architechtures
22.1.1 Dumb broadcast server
22.1.2 Routing server
22.1.3 DNS
22.2 RPC
22.3 Peer Architectures
22.3.1 Ring
22.3.2 Round Robin
22.3.3 Cubes
22.4 Arbitration
22.5 Blackboard
22.6 Tuple-space
Chapter Summary
Exercises
 list of sidebars

Java Sidebars by Chapter

• Interlude 1 A Community of Interacting Entities

• Sidebar: Selected String Methods

• Chapter 3 Things, Types, and Names

• Sidebar: Java Naming Syntax and Conventions

• Sidebar: Java Primitive Types

• Chapter 5 Expressions: Doing Things With Things

• Sidebar: Java Operators

• Sidebar: Arithmetic Expressions

• Sidebar: Coercion and Casting

• Sidebar: Java Operator Precedence

• Sidebar: Other Assignment Operators

• Chapter 7 Building New Things: Classes and Objects

• Sidebar: Java Types and Default Initialization

• Table: Comparison of Kinds of Names

 list of sidebars

• Sidebar: Method Invocation and Execution

• Chapter 8 Designing with Objects

• Sidebar: Final

• Sidebar: class Math

• Chapter 9 Animate Objects

• Sidebar: class AnimatorThread

• Sidebar: Thread Methods

• Sidebar: class Main

• Chapter 11 When Things Go Wrong: Exceptions

• Sidebar: Exceptions, Errors, and RuntimeExceptions

• Sidebar: Throw Statements and Throws Clauses

• Sidebar: Try Statement Syntax

• Chapter 10 Reusing Implementation: Inheritance

• Sidebar: The class Object

• Sidebar: Abstract Classes

Style Sidebars by Chapter

• Chapter 4 Specifying Behavior: Interfaces

• Style Sidebar: Method Documentation

• Style Sidebar: Interface Documentation

• Chapter 5 Expressions: Doing Things With Things

• Style Sidebar: Don't Embed Side-Effecting Expressions

• Chapter 6 Statements and Rules

 list of sidebars

• Style Sidebar: Formatting Declaration Statements

• Style Sidebar: Formatting Blocks

• Style Sidebar: Using Booleans

• Style Sidebar: Documentation

• Chapter 7 Building New Things: Classes and Objects

• Style Sidebar: Class Declaration

• Style Sidebar: Field Documentation

• Style Sidebar: Method Implementation Documentation

• Style Sidebar: Constructor Documentation

• Style Sidebar: Capitalization Conventions

• Chapter 8 Designing with Objects

• Style Sidebar: Class and Member Documentation

• Chapter 9 Animate Objects

• Style Sidebar: Using main()

• Chapter 10 Reusing Implementation: Inheritance

• Style Sidebar: Explicit Use of this. and super()

All Sidebars by Topic

• Abstract Classes

• Chapter 10 Reusing Implementation: Inheritance

• Arithmetic Expressions

• Chapter 5 Expressions: Doing Things With Things

• Capitalization Conventions (Style)

 list of sidebars

• Chapter 7 Building New Things: Classes and Objects

• Class and Member Documentation (Style)

• Chapter 8 Designing with Objects

• class AnimatorThread

• Chapter 9 Animate Objects

• Class Declaration (Style)

• Chapter 7 Building New Things: Classes and Objects

• class Math

• Chapter 8 Designing with Objects

• class Main

• Chapter 9 Animate Objects

• The class Object

• Chapter 10 Reusing Implementation: Inheritance

• Coercion and Casting

• Chapter 5 Expressions: Doing Things With Things

• Comparison of Kinds of Names (Table)

• Chapter 7 Building New Things: Classes and Objects

• Constructor Documentation (Style)

• Chapter 7 Building New Things: Classes and Objects

• Documentation (Style)

• Chapter 6 Statements and Rules

• Don't Embed Side-Effecting Expressions (Style)

• Chapter 5 Expressions: Doing Things With Things

 list of sidebars

• Exceptions, Errors, and RuntimeExceptions

• Chapter 11 When Things Go Wrong: Exceptions

• Explicit Use of this. and super() (Style)

• Chapter 10 Reusing Implementation: Inheritance

• Field Documentation (Style)

• Chapter 7 Building New Things: Classes and Objects

• Final

• Chapter 8 Designing with Objects

• Formatting Blocks (Style)

• Chapter 6 Statements and Rules

• Formatting Declaration Statements (Style)

• Chapter 6 Statements and Rules

• Interface Documentation (Style)

• Chapter 4 Specifying Behavior: Interfaces

• Java Naming Syntax and Conventions

• Chapter 3 Things, Types, and Names

• Java Operator Precedence

• Chapter 5 Expressions: Doing Things With Things

• Java Operators

• Chapter 5 Expressions: Doing Things With Things

• Java Primitive Types

• Chapter 3 Things, Types, and Names

• Java Types and Default Initialization

 list of sidebars

• Chapter 7 Building New Things: Classes and Objects

• Method Documentation (Style)

• Chapter 4 Specifying Behavior: Interfaces

• Method Implementation Documentation (Style)

• Chapter 7 Building New Things: Classes and Objects

• Method Invocation and Execution

• Chapter 7 Building New Things: Classes and Objects

• Other Assignment Operators

• Chapter 5 Expressions: Doing Things With Things

• Selected String Methods

• Interlude 1 A Community of Interacting Entities

• Throw Statements and Throws Clauses

• Chapter 11 When Things Go Wrong: Exceptions

• Try Statement Syntax

• Chapter 11 When Things Go Wrong: Exceptions

• Using Booleans (Style)

• Chapter 6 Statements and Rules

• Using main() (Style)

• Chapter 9 Animate Objects

 P
Preface
Interactive Programming in Java is an introduction to computer programming
intended for students in standard CS1 courses (or interested professionals) with no
prior programming experience. It is the first textbook to rethink the traditional
curriculum in light of the current interaction-based computer revolution.
Interactive Programming in Java shifts the foundation on which the teaching of
Computer Science is based, treating computation as interaction rather than
calculation, thus providing students with a solid grounding in the thought that
underlies modern software practice. Students still learn the basic and necessary
elements of computer programming and the Java language, but the context in
which they learn it is more consistent both with Java's tools and philosophy and
with the prevailing practice from which it arises.

Why Interactive Programming?

Traditionally, introductory programming teaches algorithmic problem-solving. In
this view, a program is a sequence of instructions that describe the steps necessary
to achieve a desired result. The 'pieces' of this program are these steps. They are
combined by sequencing. The program produced is evaluated by means of its end
result. Students trained in this way often have difficulty moving beyond the
notion that there is a single thread of control over which they have complete
control.
In contrast, most programs of interest today are made up of implicitly or explicitly

IPIJ || Lynn Andrea Stein

concurrent components that interact to provide ongoing services. Buzzwords such
as "client/server" and "event-driven" are part of the descriptive language of this
new generation of programs. Embedded systems and software agents typify their
incarnations. User interface design, distributed programming, and the world-wide
web are logical extensions of a way of thinking that has interaction at its core.
When programming is taught from a traditional perspective, important topics like
these are treated as advanced and inaccessible to the introductory student. It is
unsurprising that senior software engineers report that today's undergraduates are
ill-equipped to handle the realities of embedded interactive software. Most require
on-the-job retraining to "think concurrently." Students trained in the traditional
curriculum are often so indoctrinated in the "sequence of steps" mentality that
they can no longer rely on the intuition common to every child coordinating a
group of friends or trying to sneak a cookie behind her parent's back.
Interactive Programming in Java provides an alternate entry into the computer
science curriculum. It teaches problem decomposition, program design,
construction, and evaluation, beginning with the following premises: A program
is a community of interacting entities. Its "pieces" are these implicitly or
explicitly concurrent entities: user interfaces, databases, network services, etc.
They are combined by virtue of ongoing interactions which are constrained by
interfaces and by protocols. A program is evaluated by its adherence to a set of
invariants, constraints, and service guarantees -- timely response, no memory
leaks, etc.
Because it begins from this alternate notion of what programming is about,
Interactive Programming in Java tells a rather different story from the traditional
introductory programming book. By its end, students are empowered to write and
read code for client-server chat programs, networked video games, web servers,
user interfaces, and remote interaction protocols. They build event-driven
graphical user interfaces and spawn cooperating threads. Each of these programs -
- all of which are beyond the scope of traditionally taught introductory courses --
is a natural extension of the community metaphor for computation.
Many computer science departments are contemplating a change to the Java
programming language for introductory computer science courses. While it is
possible to make this change without transforming the introductory curriculum,
adopting Java without a corresponding curricular change amounts to sweeping
more and more of what is important in today's computational world under the rug.
Java embodies much of modern programming practice. Insisting on traditional
approaches actually makes certain aspects of the language less accessible.
Shifting to a curriculum in which concurrent interacting entities play a central role

IPIJ || Lynn Andrea Stein

makes far more of modern computation theory, practice, and tools accessible to
today's introductory student.
A more complete argument for rewriting the introductory computer science
curriculum in this way is contained in "What We've Swept Under the Rug:
Radically Rethinking CS1" (Computer Science Education Journal, to appear). See
also http://www.ai.mit.edu/projects/cs101/.

Ramifications for Later Curriculum

Interactive Programming in Java includes a number of topics not often taught to
introductory students: networks, user interfaces, client/server architecture, and
event-driven programming. At the same time, students will develop a basic
facility for programming and for problem decomposition, the most crucial skills
taught in most existing CS1 courses.
In all respects, this course is still an introductory programming course. Its
thematic lesson concerns a model of computation as interaction, rather than
calculation. But its pragmatic goals include most of the skills that are learned in
standard introductory CS. The fundamental lesson of this course remains how to
take a description of a problem and construct a program whose behavior solves
that problem. It differs from traditional courses in its underlying assumptions, the
kinds of descriptions that can be considered, and the corresponding
conceptualizations that are used to build a program. The computational constructs
and modeling tools have changed; the problem still remains the programming.
As a result, this new CS1 course requires little revision of the rest of the
computational course sequence. Upper level courses can continue as they are, but
are likely to find their task simplified somewhat by the new perspective that
students bring to them.
The remainder of the curriculum which begins with an introduction to
computation on these terms may thus look much like the existing computer
science undergraduate curriculum. Nonetheless, there are subtle but significant
improvements. Several important topics that are currently covered only in
advanced undergraduate or graduate level classes can be introduced earlier in the
curriculum. For example, topics in distributed algorithms and parallel complexity
-- such as the time/processor tradeoff -- can be taught in the first course in
computer science theory if the model of parallel computation is already familiar.
Since modern algorithms increasingly makes use of such approaches, it seems
only natural to expose our undergraduates to the fundamental ideas in these areas.

IPIJ || Lynn Andrea Stein

Other topics, already present at the undergraduate level, become much easier to
explain when students come equipped with this world view. Much of operating
systems becomes an exploration of different methods for implementing and
ensuring appropriate behavior multiprocessing, rather than focusing on the
concept of parallel execution itself. Students seeing these ideas for the second
time, now in depth, are more likely to appreciate some of the subtleties of the
problem rather than being confused by the many levels at which operating system
code must operate. Synchronization and interprocess communication can be
introduced along with scheduling. Transaction-safety, remote procedure call, and
shared memory models similarly follow smoothly from this approach.
Further, a whole host of issues that now fit into our curriculum poorly, if at all,
now become sensible parts of the model of computation that we teach our
students. For example, the traditional curriculum has a tremendously difficult time
introducing the topic of user interfaces. In many schools, this "special case" is
tacked on to the curriculum as an afterthought (or altogether ignored), largely
because it just doesn't fit. To readers of this book, however, accounting for the
role of the user becomes straightforward. The user is another member of the
community of interacting processes that together constitute our computation. The
programmer's job is to develop an acceptable interface that gives each participant
-- program or person -- an appropriate set of responsibilities and services. Of
course, a human has different skills and needs from a computer program, but this,
too, is a natural part of our larger way of thinking -- and teaching -- about
computational systems.
Teaching computation this way also has the potential to harness our students'
natural instincts. Traditional introductory courses tell their students, "Forget all of
your intuitions about how the world works. This is computation; it is nothing like
the world in which you live." Instead, Interactive Programming in Java teaches
that computation is very much like the world in which we live. It harnesses our
intuitions about that world---about simultaneity and ordering constraints, about
when it is more useful to partition a task and when it is simpler not to, and about
what information must be available to whom at what time and how to get it there-
--and teaches readers to use that intuition to become better programmers.

A Short History of the Rethinking CS101 Project

This book is a part of a larger project to reshape the ways in which introductory
computer science is taught (and, indeed, the ways in which the field itself is
conceptualized). The Rethinking CS101 Project grew out of work in a variety of
computational fields -- artificial intelligence, robotics, software agents, human-
computer interaction, as well as programming languages -- and their common

IPIJ || Lynn Andrea Stein

difficulties with the conventional wisdom concerning how computation is
constituted. For example, introductory computer science teaches that a program's
job is to calculate some desired result and then to stop. When a robot stops,
however, this is generally a sign that it has broken. (Further, there's not really a
"result" that the robot "calculates"; instead, it is supposed to continually exhibit
appropriate behavior.)

Research Roots
In the early 1990s, the author worked to bring intuitions about computation into
the classroom through the use of simple, inexpensive robotics. The use of robots
enabled a focus on software life cycle, non-repeatability, and pragmatic software
engineering uncommon in traditional introductory classrooms. The curriculum
that developed from this experimentation marked a radical departure from the
traditional single-threaded, sequentialist story.
The use of robotics clearly forced a shift in perspective in the introductory
programming curriculum. In the first half of the decade, this shift was echoed, if
more subtly, in the popular software market through approaches such as event-
driven programming, client-server architectures, and enterprise computing. Those
techniques -- increasingly important to industry -- were still not deemed suitable
for an introductory computing classroom. Nonetheless, they were inescapably
changing the face of the computing sciences. Computing-in-the-raw is no longer
calculate-and-stop. Instead, it is made up of agents and services, communities of
ongoing interacting entities. Yet today's introductory classrooms shed little light
on these now-prevalent industry practices.
Courses taught during this period included MIT freshmen, MIT graduate students,
and international researchers in artificial intelligence. Spin-offs of these efforts
include robotics classes at a variety of universities and colleges as well as the
now-annual Robot-Building Laboratory at the National Conference on Artificial
Intelligence and the establishment of the KISS Institute for Practical Robotics (of
which the author is an Institute Fellow).
With the advent of the world-wide web and the popular adoption of Java, a new
avenue towards teaching these approaches has been opened. The current
Rethinking CS101 Project has shifted its focus away from physical robots and
towards the underlying principles of interactive computation as illustrated by
purely software systems. (A side effort within the project continues to pursue the
robot hook, both in software simulations and in the interests of capitalizing on the
newly emerging commodity robot market. Although robots are not central to the
curricular shift represented by this project, they are easily integrated into its

IPIJ || Lynn Andrea Stein

methods and models.) Interactive Programming in Java represents the
codification of the underlying approach to computation in a form suitable for
adoption in otherwise-traditional university computer science curricula, thereby
bringing them closer to state-of-the-art practice.

Classroom Experience
The curriculum presented in Interactive Programming in Java has been taught in
a variety of venues. The first course taught with the current set of materials was
held in the summer of 1996, in a one-week intensive minicourse using the Java
1.0 API and Sun's JDK, the only Java available at the time. Its students were
executives, managers, and a few software engineers enrolled in MIT's Summer
Professional Programs. The majority had no substantial prior programming
experience.
The course was subsequently taught twice in MIT's regular curriculum. Students
were largely first-semester freshmen and others with no prior programming
experience. (The course is also popular among advanced students in non-
computational fields who want a single semester of computational coursework.)
Student feedback has been resoundingly positive. The MIT course has been
adopted by the EECS Department as a regular offering and is listed in the catalog
as subject number 6.030, Introduction to Interactive Programming.
Precursors to this textbook were also used in teaching several other minicourses to
professional audiences. These include the 1997 and 1998 Professional Institutes at
MIT and a tutorial offered at the ACM SIGPLAN's Conference on Object
Oriented Programming Systems, Languages, and Applications (OOPSLA '97).
Students in these courses included software professionals, academics, and
trainers. Generally versed in traditional programming, they attended the
minicourses to learn a new way to think about computation.
Other instructors have used the beta release of the textbook. In the fall of 1998,
the course materials was used at a handful of undergraduate institutions with
student bodies substantially less sophisticated than MIT's, as well as an advanced
class in a secondary school. Serious beta testing began in the fall of 1999, when
over a thousand students at more than a dozen colleges and universities around
the world used Interactive Programming in Java as their primary text. Additional
non-traditional classroom tests are also underway. Ultimately, the textbook is
intended for deployment in mainstream undergraduate classrooms as well as
certain advanced secondary classes, perhaps AP.
The curriculum itself has attracted widespread attention. It has been presented at a

IPIJ || Lynn Andrea Stein

variety of international meetings and its agenda is documented in a variety of
publications (see enclosures). The Rethinking CS101 Project at MIT has recently
received the donation of a 30-machine teaching laboratory from Microsoft
Research/University Curriculum Programs. A strategic relationship with Sun
Microsystems is also under negotiation, and the National Science Foundation has
selected Rethinking CS101 for an Educational Innovation Award.

How to Use This Book

Interactive Programming in Java is designed for use by students who have no
prior programming experience (typically college freshmen). It ultimately teaches
both the fundamentals of computer programming and the details of the Java
programming language.
The book is divided into five parts. The first briefly overviews the idea of
programs built out of communities of interacting entities. The second part
introduces the mechanics of Java programming, from things, types, and names to
objects and classes. It is essential to the book and is intended to be read in the
order presented. Part three elaborates on these ideas, introducing threads as first-
class citizens of the programming world and exploring inheritance, exception-
handling, and design. Part four emphasizes a variety of issues in the design of an
individual entity. It is not necessary to read this section in any particular order,
and certain chapters can be omitted entirely without serious detriment. Part five
similarly surveys a variety of interrelated topics, in this case concerning the ways
in which communities are coupled together, and its chapters, too, can be taken out
of order or omitted.
The five parts, taken together, constitute a single-semester introductory course in
computer programming. In such a course, some of the supplementary material
(described below) will not be used. For a one-quarter course, part five and
selected earlier chapters should probably be omitted. Alternately, the complete
book can be spread over two quarters or over a full year, augmented as necessary
from the supplementary materials.

Part By Part
Part 1 is brief and introductory, providing an overview of the approach to
computer programming taken. Part 2 begins with the basic syntax and semantics
of programming constructs. At the same time, from the earliest examples, students
are introduced to concurrent, interactive, embedded programs. For example,
interfaces are introduced early as they specify a contract between two parts of a
computer system. By the middle of part 3, students have learned to write what

IPIJ || Lynn Andrea Stein

might in other contexts be called "stand-alone" programs -- complete programs
including class definitions and a main routine. They have also learned that every
program is a part of a system of interacting entities -- including the user, libraries
and other software, hardware, etc. -- and that no program truly stands alone.
The remainder of the book addresses issues and alternatives that arise in the
design of software communities. Part 4 focuses on ways to extend the basic
entities that students build. The notion of a dispatching control loop provokes an
exploration of procedural abstraction, in which separate routines handle each
possible case. This in turn leads to a de-emphasis of the central control loop and a
shift to event-driven programming, in which individual "handler" procedures take
center stage. In a typical event system, dispatch may be provided implicitly, i.e.,
by underlying hardware or software. A third model -- smart objects that handle
their own behavior -- is also explored. Java's AWT is introduced as both a tool
and an example of an event-based system.
Part 5 addresses the issue of how entities are tied together. A recurring theme --
throughout the book, but emphasized here -- concerns interface design. This refers
both to the Java construct -- a signature specification, introduced in chapter 4 --
and to the more general concept, including human (user) interface design. In
addition to learning how to specify an interface, students learn what the interface
does not specify. In other chapters, students learn about streams, messages, and
shared memory, about connecting to objects in the same name space and to those
running under different processes or on different machines, and about how to
communicate with them. They also learn the basic ideas of safety and liveness,
that shared mutable state can lead to program failures, and some simple
mechanisms for coping with them. They do not, of course, learn to build
arbitrarily complex programs that avoid deadlock under all circumstances. This
topic will be visited later in the computer science curriculum. Instead, they learn
to recognize the general preconditions for the possibility of safety failures and the
kinds of solutions that might be possible. The goal, throughout this course, is to
give students the basic conceptual vocabulary that will allow them to ask the right
questions as they meet more complex issues later in their education.
Interactive Programming in Java ends with an overview of various patterns of
large-scale systems architecture, reviewing tradeoffs among various approaches
and providing a common language for software architects. The last chapter
examines conventional patterns by which complex concurrent and distributed
systems are constructed. The emphasis is on designing and understanding a
variety of interactive communities. This chapter also leads naturally into final
projects. In courses taught using this curriculum and preliminary drafts of the
book, typical final projects have included client/server chat programs and

IPIJ || Lynn Andrea Stein

networked video games. Not what you would generally expect from first semester
freshmen!

Pedagogical Elements and Supplementary Materials

Although this book is primarily intended for an introduction to computer science
course, it will include enough reference material to stand alone as a self-study
course in Java, without requiring a language supplement. Three kinds of
supplementary materials help provide this support: in-chapter sidebars, between-
chapter interludes, and auxiliary case studies. Reference charts and a glossary are
also included.
To avoid muddying the text with too many language-specific details, sidebars are
used throughout to explain details of Java syntax and semantics. The text
explicates the conceptual development of the ideas; the sidebars are intended to
provide detailed information on technical aspects of the language or the
programming process.
Sidebars come in two flavors. Syntax sidebars explain language-specific details
and pragmatics in the form of a reference manual. Style sidebars explain good
documentation and coding practice. The use of sidebars serves two purposes.
First, it frees the main text of some of the details that confuse rather than elucidate
the presentation of central concepts. Second, the sidebars, together with the
reference charts in Appendix B, form a supplementary desktop reference for
students while they are programming.
The narrative of the book is periodically interrupted for an extended example,
called an interlude. Interludes are adapted from potential programming
assignments. They are presented between chapters, rather than within them, and
can be included or omitted at the instructor's preference. Interludes provide
detailed illustrations for the student to study. They exemplify the themes of the
course in terms of the material studied to that point. They also provide the basis
for exercises allowing students to practice and assess their mastery of relevant
skill sets. Complete code for each interlude is supplied on the textbook's web site.
Also supplementing the book is a set of case studies. These are not included
within the bound text. Instead, they will be made available over the world-wide
web. The case studies provide descriptions of current applications exemplifying
the principles central to the course. For example, one case study is based on an
article in the trade literature on constructing an http server. With only minor
modification, this article is an excellent illustration of the relevant themes of the
course as well as a concrete example of a real-world application that is accessible

IPIJ || Lynn Andrea Stein

to students in the later chapters.
In addition to the materials described above, the supporting materials include a set
of exercises, lecture notes, programming assignments, and sample quizzes. Some
exercises appear chapter by chapter in the bound book. Other resources are
available through the online supplement.

About the Author

Lynn Andrea Stein is Associate Professor of Computer Science and Engineering
at the Massachusetts Institute of Technology, where she has been a member of the
faculty since 1990. She is also a member of both MIT's Artificial Intelligence
Laboratory and its Laboratory for Computer Science. Stein, an internationally
recognized researcher and educator, has been teaching computer science since the
early 1980s. Stein received her undergraduate degree (AB cum laude in Computer
Science) from Harvard and Radcliffe Colleges and both ScM and PhD degrees
from the Department of Computer Science at Brown University. While at Brown,
she held an IBM Graduate Fellowship and received the Sigma Xi Graduate
Student Award.
Stein's research work spans a variety of fields and her publications include
seminal work in fields as diverse as the semantics of sharing in object-oriented
programming languages, non-monotonic taxonomic reasoning, and cognitive
architectures for robotics. Within the past year, Stein has given invited addresses
at the National Conference on Artificial Intelligence, the European Meeting on
Cybernetics and Systems Research (W. Ross Ashby Plenary Lecture of the
International Federation for Systems Research), and the Consortium for
Computing in Small Colleges Northeastern Conference (Keynote Address). She
will present a keynote address at SIGCSE's European analog, the International
Conference on Innovation and Technology in Computer Science Education, in
Helsinki in July, 2000.
Stein is a 1993 recipient of the National Science Foundation Young Investigator
Award. She recently ended a term of service as an Executive Councilor of the
American Association for Artificial Intelligence and is the former Chair of that
organization's Symposium Committee. She currently serves on several
international advisory and steering committees.
Stein has recently returned from a on sabbatical leave from MIT as an Office of
Naval Research Science Scholar at the Mary Ingraham Bunting Institute of
Radcliffe College, a multidisciplinary think tank in Cambridge Massachusetts.

IPIJ || Lynn Andrea Stein

Acknowledgements
This document would not have been possible without the generous support of the
National Science Foundation under Young Investigator Award No. IRI-9357761
and more recently under Educational Innovation Award EIA-9979859. Any
opinions, findings, conclusions, or recommendations expressed in this material
are those of the author and do not necessarily reflect the views of the National
Science Foundation. Additional support was provided by the Massachusetts
Institute of Technology's Classes of 1951 and 1955 Funds and by the Department
of Electrical Engineering and Computer Science, by Microsoft Research, and by
Sun Microsystems. The initial revision of these notes was supported by the Office
of Naval Research through the Science Scholars Program at the Mary Ingraham
Bunting Institute of Radcliffe College, where the author was on sabbatical leave
as a 1997-98 and 1998-99 Fellow.
The earliest inklings of these ideas probably took root while I was
teaching&emdash;and learning to teach&emdash;at Harvard. There is no doubt
that that they were nourished in the dynamic environment of Brown's CS
Department, which supported many parallel growths. Both my students and my
teachers over the years have taught me more than I can say, and the debt I owe
them cannot begin to be repayed. My more recent colleagues, at MIT and
elsewhere, have been a source of inspiration and challenge, both of which have
strengthened the work immeasurably. Feedback, especially concerning industrial
relevance and especially from the networked community, has been invaluable.
A significant portion of the writing of this book was completed in the wonderfully
nurturing environment that is Radcliffe's Mary Ingraham Bunting Institute. I
could not possibly do justice to what that space and time meant to me. Suffice it
to say that the Bunting Fellows of 1997-99 are a most remarkable cohort, in
whose debt I will forever remain. I hope that this project will be one more
testament to the power of Polly Bunting's campaign against the "climate of
unexpectation."
Many people have contributed to the development of these ideas; here I can only
single out a few individuals to whom I owe the greatest debts. Early versions of
some of these ideas were developed jointly with Jim Hendler, and his continued
support has been of tremendous benefit. Hal Abelson has been both mentor and
inspiration throughout this project, and I'm sure I don't begin to appreciate the
extent of his contributions. Kim Bruce was among the work's earliest (and
greatest) supporters. Robert Duvall has been a fellow traveller along this road.
I have had tremendous assistance from the teaching staff who have helped me

IPIJ || Lynn Andrea Stein

over the years with the development of this material: Ben Adida, Alfred C.
Ashford, Joshua Reuben Brown, Duncan Bryce, Jennifer Chung, Daniele De
Francesco, Matt Deeds, Robert Duvall, Mike Harder, Craig Henderson, Stephanie
Hong, Pavel Langer, Emily Marcus, Paul Njoroge, Todd Parnell, Ben Pick, Salil
Pitroda, Lydia Sandon, Luis F. G. Sarmenta, Emil Sit, Maciej Stachowiak, Ben
Vandiver, Mike Wessler, Nathan Williams, and Henry Wong; also Matt Domsch,
Carol Lee, Karsten Ulland, and Anne Wright, who helped me with an earlier but
crazier experiment.
The students who have participated in the several versions of this course -- 6.80s,
6.75s, conference tutorials, the various versions of 6.096 and 6.030, and those at
other institutions whom I have yet to meet -- have left their mark in untold ways
upon this material. I am indebted to them for their insights as well as their
patience.

IPIJ || Lynn Andrea Stein

part 1
 1
Chapter 1 Introduction to Program Design

Chapter Overview
• What is a computer program?
• What are the parts of a program? How are they put together?
• What kinds of questions does a program designer ask?
In this chapter you will learn how a computer can be controlled by a set of
instructions called a program. This chapter introduces two different aspects of
computation: single-minded instruction following and coordination among
instruction followers. The programs in this book involve both aspects of
computation.
The first aspect of computation is as step-by-step instruction following, like the
process of making a single sandwich. This kind of computation is a sequence of
instructions that produce some desired result. The question that drives this part is
"What do I do next?" Pieces are put together using "Next,...", "If ... then ... else
...", and "until...". This kind of computation has an end goal that execution of
these instructions will accomplish. The programs in this book use short sequences
of instructions, executed over and over, to create entities that can provide services
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
1~2 Introduction to Program Design Chapter 1

or respond to requests (e.g., a sandwich-maker).

The second aspect of computation involves coordinating among many of these
instruction-following entities. This is like gathering the sandwich-makers (and
table-waiters and others) together to run a restaurant. This kind of computation is
creating (and managing) a community. The driving questions are "Who are the
members of the community?", "How do they interact?", and "What is each one
made of?" The members of the community -- the instruction-following entities --
are glued together through their interactions and communications. Executing this
kind of computation provides an ongoing program such as your car's cruise
control, a web browser, or a library's card catalog.
When you finish this chapter, you will know the basic questions to ask about
every computational system. These questions will allow you to begin to design a
wide variety of computer programs.

1.1 Computers and Programs

Computers provide services. A suitably equipped computer can retrieve a web
page, locate the book whose author you're thinking of, fly an airplane, cook
dinner, or send a message to your friend half way around the world. In order for a
computer to do any one of these things, two things must happen. First, the
computer must be told how to provide the required services. Second, the computer
must be asked to do so.
The how-to instructions that enable computers to provide services are called
programs. A computer program is simply a set of instructions in a language that
a computer can (be made to) follow. When the computer actually follows the
program instructions, we say that it is executing that program. The program is
like the script for a play. It contains instructions for how the play should go. But
the script itself is just a piece of paper: no actors, no costumes, no set, no action.
Executing a program is like performing the play. Now there is something to
watch.
This analogy goes further, too. The same script can be performed multiple times,
just as the same program can be executed again and again. If audience reaction (or
the director's interpretation, or the theater, or the time of day) influences the
performance, two performances of the same script may be quite different.
Similarly, user input, hardware, software, or other environmental circumstances
may make two different executions of the same program quite different from one

IPIJ || Lynn Andrea Stein

1.2 Thinking like a programmer 1~3

another. (Think of running the same word processing program on two different
occasions; the experiences are extremely different even though the computer
follows the same general-purpose instructions both times.)
When you sit down at a computer, someone else has already told it how to do a lot
of things. For example, when you press the power switch, it boots up, or gets
started running, in the way that it has been instructed to. Personal computers
typically come with a fairly sophisticated set of startup instructions already
installed. Simply turning on the computer causes the computer to execute this
startup program.1 Each computer has a program that it runs automatically. The
program that your desktop or laptop PC runs is called its operating system. A disk
drive -- which is really a separate computer plus the electronic equivalent of a
huge filing cabinet -- comes equipped with instructions for how to retrieve
information from (or store information in) that filing cabinet plus how to transmit
that information across the cable that connects the disk drive with your "main"
computer. A microwave oven comes with a computer that follows instructions for
how to tell time and how to turn on its microwave generator for specified periods.
The library's card catalog provides lookup services. Your car's cruise control
accelerates and decelerates to keep you car moving at a steady rate. A web
browser fetches and displays information it retrieves from the hard drives (file
cabinets) of computers scattered around the world (at your request) (with the
assistance of the "web server" programs running on those distant computers as
well as the network (transmission) services provided by a set of intervening
computers.
When you load a new piece of software onto your computer -- a cool new game,
for example -- what you are actually doing is giving your computer a copy of the
program -- the set of instructions that tells it how to do display graphics and make
appropriate sound effects or whatever it is that the particular piece of software
does. Writing down these instructions was the job of the person (or people) who
wrote the software, the programmer. Loading the software makes the
instructions (the script) available to your computer. Just having these instructions
lying around doesn't do you much good, though. To actually play the game
(perform the play), you need to do one more thing. You need to run the program.2

1
Starting a computer is called "booting it up", presumably from the phrase "pulling yourself up by
your bootstraps". The startup program that a computer executes each time that it is turned on is
called the computer's "boot sequence".
2
Some computer games can be run off of removable media, like CD ROMs. In this case, you don't
need to load the program onto the computer, but you do need to make sure that the disk is in the
drive, i.e., that the instructions are available to the computer.

IPIJ || Lynn Andrea Stein

1~4 Introduction to Program Design Chapter 1

Tomorrow, if you want to play the game again, you only have to run it; you don't
have to start by loading it onto your computer.

1.2 Thinking like a programmer

A computer program -- "how-to" instructions for your computer -- must be
written in a language that the computer can follow. There are many languages
designed for instructing computers. These languages are called programming
languages, and they are typically quite different from the kinds of languages in
which people talk to one another. One of the main differences between talking to
a person and programming a computer is the increased level of precision required
to tell a computer how to do things. With people, it is often possible to give very
vague instructions and still get the behavior you want. A computer has no
common sense. You must be very specific with it. Your instructions must be step
by step, in great detail. In some ways, programming a computer can be a lot like
talking to a very young child or a creature from a different planet.
Imagine teaching a Martian how to make a peanut butter and jelly sandwich. You
need to give detailed, step by step instructions:
1. Get a loaf of bread.
2. Remove two slices of bread and put them on the counter.
3. Get a jar of peanut butter. Put it on the counter, too.
4. Get a jar of jelly. Put it next to the peanut butter.
5. Get a knife.
6. Open the jar of peanut butter.
7. Pick up a slice of bread.
8. Using the knife, pick up a glop of peanut butter and spread it on the top of the
slice of bread.
9. ....
These instructions tell the Martian, in very specific terms, what to do. To follow
the instructions, the Martian simply needs to perform each step, one by one, in the
order given. As long as each of these instructions is one that the Martian knows
how to perform, when the Martian finishes executing this program, the Martian
will have a peanut butter and jelly sandwich.

IPIJ || Lynn Andrea Stein

1.2 Thinking like a programmer 1~5

If there is an instruction here that the Martian does not understand, that instruction
needs to be rewritten in more detail so that the Martian will be able to execute it.
For example, "pick up a glop of peanut butter" might require further explanation:
1.
a. Insert the knife blade half-way into the jar of peanut butter.
b. Remove the knife from the jar of peanut butter at a slight angle so that
some peanut butter is carried out of the jar by the knife.
c. ....
An instruction that needs further explanation before the Martian (or computer)
can execute it is one that we call high level. We can use high level steps in our
programs only if we can supply additional instructions to explain how to actually
execute these higher level steps.
Although we don't know what instructions Martians are likely to understand, a
programmer knows what kinds of instructions are a part of the particular
programming language in which s/he is developing a computer program. In this
book, we will use a programming language called Java. As you read this book,
you will learn how to think like a programmer and how to write instructions that
computers can understand. You will also learn specifically about the kinds of
instructions that are part of the Java programming language.
As a programmer, you will design sequences of steps much like the peanut butter
and jelly sandwich instructions. The goal of such a sequence is to get something
done, to find an answer or to create something. In order to design a program like
this, you will need to repeatedly answer the question, "What do I do next?" until
you have reached your desired result. In many ways, this approach makes
computers seem much like sophisticated calculators. In fact, this is where
computers got their start: the word "computer" used to refer to people who did
(mathematical) computations, and the original mechanical computers were
designed to perform these computations automatically.
When you are designing a program, you should ask yourself, "What do I do
next?" You don't necessarily have to write out all of the basic steps in one long
sequence. You can group them together in bigger, more abstract, higher level
chunks:
I. Assemble the ingredients.
II. Spread the peanut butter.

IPIJ || Lynn Andrea Stein

1~6 Introduction to Program Design Chapter 1

III. Spread the jelly.

IV. Put the sandwich together.
V. Clean up.
This is a perfectly good set of instructions. But, as in the case of the Martian who
didn't know how to "pick up a glop of peanut butter", these instructions will
require further elaboration. A programming language such as Java allows you to
make up your own high level steps, like "Assemble the ingredients", and then to
explain how to do this: "1. Get a loaf of bread...." Your program is complete only
when every line is either understandable by the computer or further explained in
terms that are understandable by the computer. When you are done asking
yourself "What do I do next?" you must then ask "How do I do each of these
things?" until every line of your program is something that the computer knows
how to do.

1.3 Programming Primitives, Briefly

What kinds of things to computers know how to do? Most computers don't know
how to make peanut butter and jelly sandwiches. Most computers do know how to
manipulate numbers and also other kinds of information, like words. In the Java
programming language, you will find tools that let you send messages to other
computers on a network or create windows and buttons to communicate with
people using your programs. Other computers may have special kinds of
instructions. A robot control system has instructions that tell the robot when,
where, and how to move. A security system may have an instruction to sound an
alarm. These are the basic instructions out of which programs for each of these
systems can be constructed.
These basic instructions can be combined by sequencing them, as we've already
seen. They can also be grouped into mini-programs and given names, like
"Assemble the ingredients". These names can then be used as new instructions.
When the computer needs to execute one of these new instructions, it simply
looks up the rule for how to do it. (When the Martian needs to assemble the
ingredients, it uses the detailed instructions that begin "1. Get a loaf of bread....")
Instructions can also be combined in other ways. Sometimes, there is a choice to
be made. For example, after spreading a glop of peanut butter on top of the bread
(step 8), the next step in the peanut butter and jelly program might say:

IPIJ || Lynn Andrea Stein

1.3 Programming Primitives, Briefly 1~7

[ Number is wrong; should continue list above. Same problem above and below.]
1. If the top of the slice of bread is covered in peanut butter, go to step 10.
Otherwise, go back to step 8.
This step contains a choice; the next step might be 8 or it might be 10, depending
on whether the slice of bread is full. The Martian (or computer) executing this
program will have to keep track of which step comes next. This kind of choice
step is called a conditional, and it is a common construct in programming
languages. It is especially useful when the answer to the question "What do I do
next?" depends on something you won't be able to figure out until you're
executing the program.
We might want to go further, replacing steps 8 and 9 with a new kind of step that
says
1. Repeat the following substeps until the top of the slice of bread is
completely covered in peanut butter
a. pick up a glop of peanut butter
b. spread it on the top of the slice of bread.
This step ("repeat until") is called a loop. It, too, is a common construct in
programming languages. Some loops tell you to keep going until something is
true (like the bread becoming full), while others tell you how many times to do
the steps inside the loop. Some loops even go on forever. For example, a clock is
basically a loop that moves its hand(s) (or changes its display) once a minute.
Loops are especially useful when part of "What do I do next?" is to repeat
(almost) the same thing several times.
Each of the techniques described above -- sequencing steps, conditionals, loops,
and grouping steps into new basic steps (also called procedural abstraction) -- is
an important part of building computer programs. You will learn more about how
to do these things in Part 2 of this book. These are the pieces that a programmer
uses to answer the questions "What do I do next?" and "How do I do each of these
things?" But this is only one part of the programming problem. The second part of
programming is coordinating the activities of many interdependent participants in
a computational community.

IPIJ || Lynn Andrea Stein

1~8 Introduction to Program Design Chapter 1

1.4 Ongoing Computational Activity

Some computer programs are very much like peanut butter and jelly sandwich
making instructions. They start with some ingredients and step by step calculate
whatever it is they're designed to create, producing an answer or result before
stopping. The original mechanical computers, which mimicked human computers
performing mathematical calculations, were very much like this. Sometimes, you
would bring your program to a computer operator and then come back the next
day for the result!
Today, most computer programs aren't like this. Instead, computer programs
today are constantly interacting. They may interact with people, machines, other
computers, or other programs on the same computer. For example, a word
processing program or spreadsheet waits for you to type at it, then rearranges
things on the page or recalculates values as you type. A video game moves things
around on your screen, some in response to you and others by itself. A web
browser responds to your requests, but also talks to computers all across the
network. The cruise control system for your car responds to road conditions,
sensor readings, and your input. A robot control system interacts with the robot
and, through the robot, with the robot's environment, perhaps with no human
input at all.
These computations aren't concerned with solving some pre-specified problem
and then stopping. Most computations of interest these days are things called
servers or agents or even just applications. Most of them have some basic control
loop that responds to requests or other incoming information continually. These
computations are embedded in an environment and they interact with that
environment: users, networks or other communication devices, physical devices
(like the car), and other software that runs at the same time.
These programs are not just interacting with the things around them, either. In
fact, each of these programs may itself be composed of many separate pieces that
interact with each other (as well as with the world outside the program).
Coordinating the activity among the many entities that make up your program --
and their interactions with the world around them -- is the second aspect of
computer programming.
This is kind of like taking a group of Martians and organizing them to run a
restaurant. Some of the Martians will take orders from and serve food to the
customers. Other Martians will need to cook food for the customers. Still others
will need to check on supplies, make change, or coordinate other aspects of the
restaurant's operation. Each of these Martians will provide services to and make

IPIJ || Lynn Andrea Stein

1.4 Introduction to Program Design 1~9

request of other Martians (or to the restaurant's customers or suppliers or other

parts of the environment in which the restaurant is embedded). Coordinating the
interactions among these Martians (and between the Martian restaurant and its
environment) involves different kinds of questions from the instruction-following
"What do I do next?"
Before we turn to the coordination of activity, though, let's look closely for a
moment at one of the Martians who will staff our restaurant. We will see that,
deep down, peanut butter and jelly programming still has an important role to play
in creating computational activity. Keep in mind that this Martian represents just
one of the many things going on in our restaurant.
The instructions that a Martian chef follows might look very much like this:
1. Pick up a new food order.
2. Find the instructions for the dish ordered and follow them.
3. Put the completed dish and the order information on the counter for pickup.
4. Go back to step 1.
Step 2 of this program is the kind of "higher level" step that we described above.
It is not itself complete; instead, it refers to other, more detailed instructions to be
followed. For example, if an order comes in for a peanut butter and jelly
sandwich, the Martian chef will need to use the instructions developed above for
how to make a peanut butter and jelly sandwich. A computer still follows simple
sequenced steps written in a language that it can execute. But while this Martian
is making a peanut butter and jelly sandwich, another Martian is asking the
customer at table 3 whether she would like some more water. Later, the Martian
waiter will come into the kitchen and pick up the sandwich that the Martian chef
just made. And when the Martian chef is done making the peanut butter and jelly
sandwich, the Martian will turn to the next food order, continuing its ongoing
interaction.
The peanut butter and jelly style of program instructions is an important part of
how the Martian chef does its job. But the Martian chef's instructions are not
simply the steps of the peanut butter and jelly program. The basic structure of the
Martian chef program is an infinite loop -- a loop that goes on forever. This
program accepts requests (in the form of new food orders) and provides services
(in the form of the completed dishes) over and over again. We sometimes call this
kind of loop -- one that provides the main behavior for a participant in the
interactive program community -- its control loop. Many program community

IPIJ || Lynn Andrea Stein

1~10 Introduction to Program Design Chapter 1

participants take this form, and we will look more closely at control loops in Part
3 of this book. Programs with ongoing central control loops like this are the
members of our interactive computational community.

1.5 Coordinating a Computational Community

At its most basic level, every computer program is made of instructions that are
followed, one by one. But a single computer program may have many instruction-
followers inside it, just as our restaurant is run by many individual Martians.
When you look at the whole program -- like the whole restaurant -- you don't
necessarily see the individual instruction steps. Instead, you see coordinated
activity among a group of interacting entities. The behavior of this community --
providing customers with hot meals -- is not the responsibility of any particular
member of the community. Instead, it is the result of many community members
working together in a coordinated fashion.
Building modern interactive software involves something very much like
organizational design. We call this part of programming "constituting a
community of interacting entities". The programmer's job to figure out how to tell
the computer what to do, and no matter what the specific problem to be solved
may be, there are fundamental questions that each programmer must ask.
Designing a computation which is a community of interacting entities involves
figuring out who the members of this community are, how each one works, and
how they interact. This is like setting the cast of a play, or deciding what the sub-
units of your business will be, as well as how they should interrelate. In planning
the organizational structure of your business (or program), you also have to figure
out how each unit works and what -- and how -- they are supposed to
communicate. These are the big questions of this second aspect of programming.
When you are designing this kind of activity, you ask yourself several questions:
• What is the desired behavior of the program?
• Who are the entities who interact to produce this behavior?
• How does each one work?
• How do these entities interact?
In the remainder of this section, we will expand these questions and begin to
explore them in somewhat greater detail. Understanding these questions and their

IPIJ || Lynn Andrea Stein

1.5 Coordinating a Computational Community 1~11

ramifications is the theme of this entire book. Coordinating communities is a

special focus of Part 4.

1.5.1 What is the desired behavior of the program?

Before you can design a system to solve your problem, you must know what your
problem is. This involves knowing not only what you want, but how it should
work or fail to work under a variety of different circumstances.
Some questions that you ought to be able to answer about your desired program
include:

• What services should your program provide?

• What guarantees does your program make about these services?
• Under what assumptions (circumstances, conditions) does your program
make these guarantees?
Consider the restaurant of the previous section. What can we say about its
behavior? In answering this question, we consider both the experiences of
individual customers and the ongoing properties that the restaurant must maintain,
such as remaining solvent. A basic specification of the service provided by the
restaurant might be: Each customer is seated at a clean table, the order is taken,
food is served, a bill presented, and payment collected.
There are a number of guarantees we want to make about these services. For
example, customers should not have to wait for an unduly long time. Different
parts of the restaurant must communicate; customers should not be charged for
food that they were not served, etc. Over time, the restaurant should take in at
least enough revenue to cover its operating expense. Supplies should not run out,
nor should they rot.
We will make certain assumptions in order to be able to provide these guarantees.
For example, the "timely service" guarantee will only be possible if the load on
the restaurant is reasonable. We might decide that we will only be able to uphold
this guarantee if the number of people wanting to eat in the restaurant at one time
never exceeds its capacity, and if the rate of arrival of these people doesn't exceed
the rate at which the restaurant can serve them.3 These assumptions should be

3
How many customers the restaurant can handle is called its bandwidth. How quickly each one
can be served is called its latency. The number of customers per hour that the restaurant can
handle is its throughput. These quantities -- bandwidth, latency, throughput -- are common

IPIJ || Lynn Andrea Stein

1~12 Introduction to Program Design Chapter 1

made explicit, and we will also need to say what happens when they are violated.
(In this case, the timely service guarantee won't be upheld, but how slow the
service gets should be related to how overloaded the restaurant is.)
There are other assumptions we do not make about our program, and we can
articulate these as well.. We do not assume that only one customer will be served
at a time. Instead, we expect that multiple tables must be handled (roughly)
simultaneously. It certainly won't do to wait until the first has eaten, paid, and left
before addressing the second. We also permit different interactions with each
table to be handled simultaneously or at least overlapped; food may be cooking
while checks are being written up.
This description is still fairly general, and we can imagine making it more
specific. (For example, are customers constrained to ordering off of a menu?) In
general, the more detail you can give of what your program ought to do, the easier
your task will be in designing and building it.

1.5.2 Who are the members of the community?

This question can't be answered in isolation, because any and every decision you
make about who the entities are is also at least a partial commitment to what they
are and how they work. So answering this question is in many ways like solving
the whole problem. The trick is to answer this question in fairly high-level,
general terms, then to sit down and try to hash out the answers to all of the what
and how questions. In answering those, you'll almost certainly have to return to
this question and rearrange your answer a few times. This is fine; it's even typical
enough to have a name: incremental program design.
In the restaurant, an appropriate high level division of labor might have a wait
staff unit (the people who deal directly with the customers), a kitchen staff unit
(the people who cook the food), and a financial unit (who keep track of how much
which things cost, collect money, and buy supplies). At this point, we haven't
committed to whether these are three roles played by a single Martian, three
separate Martians, or even three groups of several Martians each.

1.5.3 What goes inside each one?

To answer this question requires knowing a bit about how each entity will interact
with the other members of its community. This means that answering "what goes

measures of program performance.

IPIJ || Lynn Andrea Stein

1.5 Coordinating a Computational Community 1~13

inside" is closely related to "how do they interact." After all, specifying what
interactions each entity needs to support goes a far way towards telling you
whether the "what goes inside" meets the requirements of the community.
Some subsidiary questions to ask about how each of the entities is constituted
include:
• What responsibilities does it have?
• What guarantees (promises, commitments) does it make? Under what
assumptions?
• What resources does it control?
• How does it work?
• Is it a community, too?
For example, the restaurant's wait staff might be responsible for greeting the
customers in a timely fashion, supplying each one with a menu (a structure that
the program will have to provide and keep updated!), taking the order, delivering
it to the kitchen staff, picking up and serving the cooked meal, obtaining a price
from the accounting entity, and obtaining payment for that amount from the
customer. The wait staff might guarantee to communicate with (most of) the
customers within minutes, provided the total number of customers is limited and
the maximum time spent with each is under a certain amount. It might also
promise to deliver food within some small amount of time after it's done cooking,
provided that the kitchen staff notifies the wait staff in a timely manner. The wait
staff controls menus, knows which food items were ordered by which customers,
and is the only part of the restaurant that deals directly with the customers. And so
on.
When it comes to "How does it work?", there are two kinds of answers. One
answer is that the behavior of the entity is accomplished by a single rule-follower
running an interactive control loop. We saw an example of this when we
considered the Martian chef earlier. In this case, we ask "What does the Martian
do next?" over and over, until we wind up with a well-defined set of instructions
for this Martian to follow.
The other possible answer to the question "How does this entity work?" is that
this entity is itself a community. (The wait staff might be further divided into the
person who takes the order, the person who clears the table, and the person who
serves the wine.) In this case, we need to figure out how to build each of these
entities, asking again "What goes inside each one?" The problem of figuring out

IPIJ || Lynn Andrea Stein

1~14 Introduction to Program Design Chapter 1

how to coordinate the activity of a community continues until each community

member is a single (rule-follower) Martian. Then we ask about the instructions
this Martian follows.

1.5.4 How do they interact?

This question concerns coordination and communication among two or more
entities. Some of the questions that you should ask about how these entities
interact include:

• What are the entities' interfaces?

 What promises does each one make?
 What contracts does it fulfill?
 What services does it provide?

• How do they communicate?

 What mechanisms do they use?
 What interaction patterns do they use?
 How do they preserve liveness, i.e., make sure that things keep moving?

• What interaction patterns are possible?

• What happens when something goes wrong?

A protocol is the specification for an interaction between two entities. For
example, a common protocol for the interaction between the wait staff and
kitchen staff of a restaurant involves a slip of paper with the customer's order
written on it. The waiter hangs this piece of paper in the window over the
kitchen's food pickup counter, a place where it will be easy to find when someone
from the kitchen is ready for a new job. When a member of the kitchen staff is
ready to process the order, the piece of paper is removed and used to guide the
food preparation. When the order is ready, it is placed on the food pickup counter
together with the original order slip. This identifies the food with the original
request when the waiter returns to retrieve it. The slip of paper serves as a crucial
reminder of several associated pieces of information: what was ordered, by
whom, and where they are seated.
Protocols can also address temporal issues. For example, the wait staff/kitchen

IPIJ || Lynn Andrea Stein

1.5 Coordinating a Computational Community 1~15

staff interaction described in the preceding paragraph needs to happen in real

time, meaning that the protocol itself can't introduce significant delays. There
must also be guarantees made about the frequency with which the wait staff
checks for completed dishes (or the kitchen staff for incoming orders). If
assumptions such as these are built into protocols, they must be documented so
that they are maintained in the behavior of participant entities.
In contrast, the wait staff interacts with the financial unit by obtaining prices for
food and turning over any moneys collected. These interactions could happen in
batch, meaning that it is OK for the wait staff to get the price list at the beginning
of the week or for money to be handed over at the end of the day.4 The difference
between real time and batch interactions is only one dimension that must be
determined in order to coordinate the activities of the members of your
computational community.
A protocol specifies the interface, or meeting, between various entities in the
community that constitutes your program. Once the interfaces have been
thoroughly fleshed out, each entity can in theory be implemented by a separate
programmer (or team of programmers) provided that it is built to spec, i.e., that it
meets the specifications of the agreed-upon interface.
In practice, the task of implementing an entity to match a given specification often
results in questions about or revision of that interface. Programming is not so neat
a task as students of computer science would often like to believe; there's a cycle
of specification and implementation, debugging and testing, usage and revision,
that characterizes almost all real-world software. The later stages of this process
are sometimes called the software life cycle; but the repeated revision that
characterizes those later stages start before a piece of software is even born.

1.6 The Development Cycle

The sections above concern the design of a computer program. Typically, you will
be given a set of specifications and some components that need to be integrated
into the system you build. Perhaps you will only be asked to build a single entity
or to modify existing entities to facilitate coordination. Regardless of your
particular design problem, you will find it useful to situate your task in the context

4
Batch processing is like the old-fashioned computations in which you handed your program to a
computer operator and came back the next day for your results.

IPIJ || Lynn Andrea Stein

1~16 Introduction to Program Design Chapter 1

of these six questions:

• What is the behavior of this program?
• Who are the entities that combine to produce this behavior?
• How do they interact?
• What is each one made of? (A community of entities or a single instruction-
following control loop?)
And, when we get down to instruction-followers,
• What does it do next?
• How does it do each one of these things?
Once you have the answers to all of these questions, you can start to build your
program. Of course, you will already have found that you needed to go back to
earlier parts of the design process to modify or flesh out various decisions. You
may also have shown your completed design to other programmers -- or, perhaps
more importantly, to the users or customers for whom you are creating this
service -- and revised your design specification in response to their feedback.
The implementation phase of the project is no different. In building a program
that is supposed to meet your specification, you will often find that you need to go
back and change that specification. When this happens, you need to be careful to
consider all of the interdependencies that led you to your original design. That is,
the development of software is cyclic, beginning with design but often returning
to it. It will not always be desirable (or even possible) to change your design, but
it is quite common to discover additional assumptions or nuances that must be
percolated through the design during later phases of development.
When you begin to build your program, it is often advisable to implement only a
small piece of your system first. This may mean implementing only some of the
entities, or it may mean implementing all of the entities but only simple, basic
versions of each. In large scale system development, this initial phase is called
prototyping. Even in most of the smaller scale programs that you will encounter in
your early coursework, it is a good idea to utilize this approach of incremental
program development. Part of developing good programming skills involves
learning to consciously and explicitly design a staged development plan in which
smaller simpler programs are constructed and debugged, then gradually expanded
until the desired functionality is obtained.

IPIJ || Lynn Andrea Stein

1.6 The Development Cycle 1~17

Building a simpler version of your system gives you an opportunity to test your
basic approach before you have built up too much complexity. It also means that
your bugs, or program errors, will be easier to find. Bugs come in many flavors,
ranging from simple syntactic errors such as spelling mistakes, to programming
errors such as incorrect variable scoping, to conceptual design problems such as
impossible-to-meet but critical guarantees.
Even after you've found the bugs that keep your program from running, you will
need to subject your code to rigorous testing. This means trying out not only the
"normal" expected behavior, but also checking how your program handles
unexpected or anomalous behavior. Think of your program as an opponent you're
trying to trick; see if you can get it to misbehave. This testing -- when done right -
- will lead you to modify your code or even your design.
This repeated cycling through and between the various stages of specification (or
design) development, implementation, and testing is a crucial skill for any good
programmer. Classroom programs are too often written once and tested on
obvious cases. Most of the time and money spent on real-world software is spent
on revision and maintenance rather than on initial development. Acquainting
yourself with this cycle -- and with writing clean, easy-to-read, reusable code --
may be the most important part of becoming a skilled programmer. These issues -
- together with a tour through the development cycle -- are the topic of the next
chapter.

1.7 The Interactive Control Loop

This book focuses on the problem of designing interactive software. At the heart
of our approach is the idea of an interactive control loop. This is a simple
program that repeatedly receives an input -- a new request, a set of sensor
readings, or some other information -- and responds appropriately. In the general
case, the response may involve initiating a series of other activities, so this kind of
program can in principle become almost arbitrarily complex. The basic idea is
rather simple, though.
To conclude this chapter, we present an extremely simple interactive control loop.
This example will be used as a motivator for the development of the next part of
the book. The interactive control loop idea is a theme that runs through this entire
book. In a way, it might be thought of as the "atomic unit" or basic vocabulary
element of this kind of computation.

IPIJ || Lynn Andrea Stein

1~18 Introduction to Program Design Chapter 1

Perhaps the simplest interactive control loop is an echo program. When run, this
program waits for the user to type something. When the user finishes typing, the
program simply repeats back what it has been given. That is, it's a loop that gets
some input, processes that input (in this case trivially), and then spits out its
result.
Although the echo program seems too trivial to be of much use, a minor variant of
it runs in almost every program you type to: it's what makes the characters appear
on the screen. Far more importantly, the basic structure of this program underlies
essentially every interactive computation. And it demonstrates many of the
important properties of an interactive computation:
• It is embedded in an environment (in this case involving a user's typing and
a display that the user can see).
• It is interactive (with that user, but we could have it talk to another program
or over a network instead).
• It is concurrent: other things happen at the same time that the program is
running. (In this case, the user might be typing the next line even while the
echo program is producing its output.)
The idea of an interactive control loop is the root of this approach to
programming. By putting together interactive control loops, you constitute a
community of interacting entities. Interactive control loops are what goes inside;
communication between them is how they interact. In other words, as they say, all
the rest is corollary....

Chapter Summary
• Computers follow special instructions, called a program, which is written in a
special programming language.

• Computation results when a computer has access to these instructions and

executes them.

• Each set of instructions must answer:

 What should the program do next?

IPIJ || Lynn Andrea Stein

 Summary 1~19

 How should it do it?

• Groups of steps can be combined to make a "higher order" step.

• Steps can involve choices or decisions.

• Steps can be executed over and over again using a loop.

• Most modern programs combine many separate looping instruction-followers

into an interacting community.

• Every computation is embedded in an environment and interacts with the

other (computational and physical) entities around it.

• The programmer's job is to figure out:

 What services (behavior) does my program provide?
 Who are the entities that together provide this behavior?
 How does each one work?
 How do they interact?

• Program construction is a cycle of designing, building, testing, and then

designing again.

Exercises
1. Give step by step instructions for how to tie shoelaces.
2. Select your favorite recipe and give step by step instructions for how to cook it.
3. Give detailed directions for how to get from your classroom to where you live.
Include indications that will tell whether you've gone too far and how to get back
on track.
4. Specify the expected behavior for each of the following interrelated services
provided by a bank account:
1. A deposit.
2. A withdrawal request.

IPIJ || Lynn Andrea Stein

1~20 Introduction to Program Design Chapter 1

3. Checking your balance.

Does your specification permit overdrafts?
5. You are at a fruit market. Describe the protocol by which you purchase a piece
of fruit from the fruit seller.
6. Describe the division of responsibility and coordination of activities among the
players on a soccer team.

IPIJ || Lynn Andrea Stein

 I1
Interlude 1 Interlude: A Community of Interacting
Entities

Overview
This interlude provides a whirlwind introduction to most of the basic concepts of
Java programming. It uses a simple community of word games and other String
transformers to illustrate this exploration.
This interlude is not intended to be read as standalone coverage of these ideas.
Instead, it introduces many concepts only briefly, but in context. Each of the
programming concepts presented here is reintroduced in much greater detail in the
chapters of section 2 of this book.

Objectives of this Interlude

1. To increase familiarity with the design process.
2. To understand how to describe a system design in terms of types,
components, and interactions.

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
I1~2 A Community of Interacting Entities Interlude 1

3. To discover how design translates into executable code.

4. To be able to read and begin to understand fragments of Java programs.

1.1 Introduction: Word Games

When I was a child, we used to amuse ourselves by speaking to one another in a
special language called Pig Latin. The simplest version of Pig Latin has just one
rule: To turn an English word into a Pig Latin one, you take the first letter off the
word, then add the first letter plus "ay" to the end of the word. So, for example,
"Hello" in Pig Latin is "ello-Hay", and "How have you been?" is "ow-Hay ave-
hay ou-yay een-bay?" There are more sophisticated rules for Pig Latin that deal
with consonant blends and words that begin with vowels, but the basic idea
remains the same. It turns out that there are children's games like Pig Latin in
many, many languages, though each has a slightly different set of rules. Another
such game, popularized by the children's Public Television show Zoom, is Ubby
Dubby, in which you add "ubb" before every vowel (cluster): "Hubbellubbo",
"Hubbow hubbave yubbou bubbeen?"
This interlude explores such word- and phrase- transformations. In fact, we're
going to build a system in which you can have many of these different
transformers, and you can glue them together in almost any order. In this sense,
the transformers will be interconnectable modules like Lego(tm) or Capsela(tm).

IPIJ || Lynn Andrea Stein

1.1 Introduction: Word Games I1~3

In addition to transformers such as Pig Latin and Ubby Dubby, we'll want
capitalizers ("HELLO"), name droppers ("Lynn says Hello", or "Chris says
Hello", or "Pat says How are you doing?"), even delayers (e.g., that don't produce
"Hello" until after they've already received "How are you doing?") or network-
senders (that can move one of these strings-of-words from one computer to
another). We'll also have some community members that can read information
that a user types to them or display information on a computer screen. And we'll
have transformers that can take listen to two different inputs, producing only one
output, as well as transformers that can produce two outputs from only one input.
(The first of these is a collector; the second is a repeater. The first is good when
you have lots of people trying to talk all at once; the second is a nice way to
circulate (or broadcast) information that needs to get to a lot of people.)
In the system that we're going to explore, we will need a way to create individual
transformer-boxes like the ones described above. We'll also need a way to connect
them together. Finally, the transformer-boxes will need to act by themselves, to
read inputs, do transformations, and produce outputs. The complete system will
be a community of interacting entities, many of which will themselves be
communities. At the most basic level, each of these entities will need to follow
specific instructions. In this interlude, we will explore both the design of the
community and the specific instructions that some of these entities will follow.

1.2 Designing a Community

We need to design

• What behavior does the system provide?

• Who are the members of the community?

• How do they interact?

• What goes inside each one?

We can start at the bottom (bottom-up design) or at the top (top-down design).
Both are legitimate and useful design techniques. However, design in practice
often mixes these techniques. In this case, we're actually going to start in the
middle; in this particular system, that is one of the easiest places to begin thinking
about what we want to produce.

IPIJ || Lynn Andrea Stein

I1~4 A Community of Interacting Entities Interlude 1

At the end of the design process, we should be able to sketch out a scenario for
each of the major interactions with our system, including what roles need to be
filled (i.e., the types of things in our system), who fills these roles (i.e., the
individual objects that make up the system), and how they communicate among
themselves (i.e., the flow of control among these objects).

1.2.1 A Uniform Community of Transformers

There are several communities implicit in the system that we're building. Let's
start in the middle, where the system can be understood as a community of
interacting transformers. In this picture, each transformer is an entity. The
interactions in this community are quite simple: Each string transformer reads in a
phrase and writes out a transformed version of it. In this system, we want to be
able to interconnect these transformers in arbitrary ways. This means that the
services each transformer provides will need to be compatible, so that one
transformer can interact with any other transformer using the same connection
mechanism.

Transformer Entity interactions, version 1

• Read a word/phrase (from a connection)

• Write a word/phrase (to a connection)

We will accomplish this generic connection between transformer entities using a
computer analog of the tin can telephones that we built as children. 1 This is a
simple device that allows you to put something in one end and allows someone
else to retrieve it at the other end. The computer analog will be Connection
objects that allow one transformer to write a word or phrase and another
transformer to read it from the connection. The transformers on either end don't
have to know anything about one another; they can simply assume that the
transformers will interact appropriately with the Connection. And the connections
don't have to know much of anything about the transformers, either
Connection Entity interactions

1
Take two tin cans with one end removed from each. Punch a whole in the center of the intact end
of each can. With a long piece of string, thread the two cans so that their flat ends face each other.
Tie knots in the ends of the string. Pull the string tight, so that it is stretched between the two cans.
Talk into one can; have someone else listen at the other.

IPIJ || Lynn Andrea Stein

1.2 Designing a Community I1~5

• Accept a word/phrase written to you

• Supply a word/phrase when requested (read)

Connections provide one particular way of providing interconnections among
objects. In this system, the components are designed so that any outputter can be
connected to any inputter. In other parts of this book, we will see examples of
other kinds of interaction mechanisms. For example, in some systems, the pieces
to be interconnected are not uniform. In others, the particular choices of
interconnections must be made at the time that the system is designed rather than
while the system is running. In part 4 of this book, we will pay particular attention
to the tradeoffs implicit in different interconnection mechanisms.

1.2.2 The User and the System

Before we look at how each transformer (and connector) is built, let's step back
from this community of interacting transformers to ask how it came into
existence. At this level, the members of our community are the user who
constructs the community and the system to be constructed. The user expects the
system to provide a way to create transformer entities and a way to connect them.
System/User interactions

• Create a Transformer (of a specified type)

• Connect two Transformers (in a particular order)

[Picture of Control Panel & tranformers.]

We'll accomplish the first of these by adding another entity to the community: a
user interface containing a control panel that allows the user to specify that a
transformer should be created as well as what type of transformer it should be.
The second interaction, connecting transformers, we will handle by letting the
user specify two transformers (through the user interface) and then asking the
specified transformers to accept a new connection. So allowing the system to
interact with the user creates one additional entity (the user interface) and adds an
interaction to the transformer:
User Interface interactions

• Create a Transformer (of a specified type)

• Create a Connection between two Transformers

IPIJ || Lynn Andrea Stein

I1~6 A Community of Interacting Entities Interlude 1

Transformer Entity interactions, version 2

• Accept an input Connection2

• Accept an output Connection

• Read a word/phrase (from a connection)

• Write a word/phrase (to a connection)

Specifically, the Control Panel will have buttons representing each kind of

2
Maybe more than one.

IPIJ || Lynn Andrea Stein

1.2 Designing a Community I1~7

transformer available. Clicking on a button will create a new transformer of the

appropriate type. Clicking on first one transformer, then another, will create a
connection between them. This task is actually cooperative: the user interface will
create the connection and it will ask the Transformers to accept it.

1.2.3 What Goes Inside

In the two subsections immediately above, we've designed transformer-

transformer interactions (via connections) and user-system interactions (via the

IPIJ || Lynn Andrea Stein

I1~8 A Community of Interacting Entities Interlude 1

user interface). We've addressed the question of who our community members are
(UI, transformers, connections, and -- stepping back -- the user) and, to a first
approximation, how they interact. In terms of system design, transformers and
connectors represent kinds of things of which there may be many separate
instances. For example, a particular community of transformers may contain five
transformers and four connectors, or eight transformers and three connectors, or
twelve. Each community will contain only a single control panel, though.
The next step in a full design process would be to look inside each of these
entities to discover whether they are, themselves, monolithic or further
decomposable into smaller communities. We will not decompose the user
interface further in this chapter; much of the necessary background for this task
will not be introduced until part 3 of this book. Instead, the remainder of this
interlude will look inside the transformer type to see how these objects are built.

1.3 Building a Transformer

We have seen above the specification of the interactions that a Transformer Entity
will be expected to fulfill. We can turn this interaction specification around to
provide a specification of the behavior that an implementation will need to satisfy:
A Transformer must be able to:

• Accept an input Connection

• Accept an output Connection

• Have its own instruction-follower that acts independently to read its input,
transform that input as appropriate, and write its output.
In fact, this Transformer is itself a community. The connection acceptors are each
entities that are activated only on a connection accept request; their jobs are to
remember the connections that they have been handed. For example, the
acceptInputConnection instructions basically say, "To accept an input connection
(let's call it in), simply store in away somewhere so that you can use it later."
There's also a little bit of additional code to say what to do if you've already got
an input connection stored away. Output connections -- another part of the
community inside an individual Transformer -- are handled in the same way as
input connections. Also, some kinds of Transformers will have code that needs to
be run when an individual Transformer is created. Finally, the independent

IPIJ || Lynn Andrea Stein

1.3 Building a Transformer I1~9

instruction-follower is an additional ongoing interacting entity. It makes use of the

connections (such as in) that the connection-acceptors have stored. Each
transformer will have its own instruction follower, allowing the transformer to do
its work without any other entity's needing to tell it what to do.
For the moment, we will focus on the heart of the Transformer, the work done by
this independent instruction-follower, especially the transformation it actually
performs. We begin by looking at some specific Transformers and describing the
behavior we expect.

1.3.1 Transformer Examples

The instructions for the behavior of a Capitalizer will say
1. Read the input.
2. Produce a capitalized version of it.
3. Write this as output.
Every individual Capitalizer is the same, and each one does the same thing. You
can tell them apart because they're connected to different parts of the community
and are capitalizing different words, though.
NameDropper is a different kind of Transformer. Each individual NameDropper
has its own name that it likes to drop. So the instructions for a NameDropper will
say

1. Read the input.

2. Produce a new phrase containing your name, the word "says", and the
input.
3. Write this as output..
Variations in Transformer behavior aren't restricted to the transformation itself.
Yet another kind of Transformer is a Repeater. The repeater is different because it
can accept more than one OutputConnection: two, in fact. The instructions for a
Repeater say:
1. Read the input.
2. Write this to one OutputConnection.
3. Write this to the other OutputConnection.

IPIJ || Lynn Andrea Stein

I1~10 A Community of Interacting Entities Interlude 1

And, of course, the instructions for a (simple) PigLatin should say

1. Read the input.
2. Produce a new phrase containing all but the first letter, then the first letter,
then the letters "ay".

3. Write this as output.

As you can see, the basic instructions for a Transformer are of the form
1. Read the input.
2. Produce a transformed version of it.
3. Write this as output.
We will begin by looking at the second of these instructions.

1.3.2 Strings
In Java, there is a special kind of object, called a String, that is designed to
represent these words or phrases. In fact, in Java a String can be almost any
sequence of characters typed between two double-quote marks, including spaces
and most of the funny characters on your keyboard. (The double quotes aren't
actually a part of the String itself; they simply indicate where it begins and ends.)
For example, legitimate Java Strings include "Hello" and "this is a String" and
even "&())__)&^%^^". (Strings don't have to make sense.) The Transformers that
we will build are really StringTransformers, since each one takes in a String at a
time and produces a corresponding, potentially new or transformed String as
output.

1.3.2.1 String Concatenation

Once you have a String, there are several things that you can do with it. For
example, you can use two Strings to produce a third (new) String using the String
concatenation operator, +. In Java,
"this is a String" + "%%^$^&&)) mumble blatz"

is for all intents and purposes the same as just typing the single String3

3
Note that there is no space between the g at the end of String and the % at the beginning of

IPIJ || Lynn Andrea Stein

1.3 Building a Transformer I1~11

"this is a String%%^$^&&)) mumble blatz"

So, for example, a NameDropper transformer might use + to create a new String
using the input it reads, the name of the particular dropper, and the word "says".
Pig Latin and Ubby Dubby might use +, too, but they'll have to pull apart the
String they read in first.

1.3.2.2 String Methods

Java Strings are actually rather sophisticated objects. Not only can you do things
with them, they can do things with themselves. For example, you can ask the
String "Hello" to give you a new String that has all of the same letters in the same
order, but uses only upper case letters. (This would produce "HELLO".) The way
that the String does this is called a method, and you ask the String to do this by
invoking its method. In this case, the name of the method that each String has is
toUpperCase(). You ask the String to give you its upper-case-equivalent by
putting a . after the String, then its method name:
"Hello".toUpperCase()

yields the same thing as "HELLO".

You can also ask a String for a substring of itself. In a String, each character is
numbered, starting with 0. (That is, the 0th character in "Hello" is the H; the o is
the 4th character.)4 So you can specify the substring that you want You can do
this by supplying the index of the first character of the substring, or by supplying
the indices of the first and last characters. "Hello".substring(3) is "lo";
"Hello".substring(1,3) is "ell"; and "Hello".substring(0) is still
"Hello".

These and other useful functions are summarized in the sidebar on String
Methods.

%%^$^&&))
4
Computer scientists almost always number things from 0. This is apparently an occupational
hazard.

IPIJ || Lynn Andrea Stein

I1~12 A Community of Interacting Entities Interlude 1

Selected String Methods

Below are some selected methods that can be invoked on individual
Strings, along with brief explanations and examples of their usage.

• toUpperCase() produces a String just like the String you start with, but
in which all letters are capitalized. For example,
"MixedCaseString".toUpperCase()
produces
"MIXEDCASESTRING"

• toLowerCase() produces a similar String in which all letters are in

lower case. So
"MixedCaseString".toLowerCase()
produces
"mixedcasestring"

• trim() produces a similar String in which all leading and trailing white
space (spaces, tabs, etc.) has been removed. So
" a very spacey String ".trim()
is just
"a very spacey String"

• substring( fromIndex ) produces a shorter String containing the

same characters that you started with, but beginning at index
fromIndex. Bear in mind that the index of the first character of a String
is 0.
substring( fromIndex, toIndex ) produces the substring that
begins at index fromIndex and ends at toIndex.
"Hello".substring(3) is "lo"
"Hello".substring(1,3) is "ell", and
"Hello".substring(0) is "Hello" again.

• length() returns the number of characters in the String. For example,

"Tee hee!".length()
is 8. Since the String is indexed starting at 0, the index of the final
character in the String is the String's length() - 1.

IPIJ || Lynn Andrea Stein

1.3 Building a Transformer I1~13

• replace( old, new ) requires two characters, old and new, and
produces a new String in which each occurrence of old is replaced by
5
new: For example,
"Tee hee!".replace('e', '*' )
produces
"T** h**!"

• charAt( pos ) requires an index into the String and returns the
character at that index. Recall that Strings are indexed starting at 0.
"Hello".charAt( 2 ) is the same as "Hello".charAt( 3 )

• indexOf( character ) returns the lowest number that is an index of

character in the String.
"Hello".indexOf( 'H' ) is 0 and
"Hello".indexOf( 'l' ) is 2. Also,
"Hello".indexOf( 'x' ) is -1, indicating that 'x' does not appear in
"Hello".

• lastIndexOf( character ) returns the highest number that is an

index of character in the String.
"Hello".lastIndexOf( 'H' ) is 0 and
"Hello".lastIndexOf( 'x' ) is -1, but
"Hello".lastIndexOf( 'l' ) is 3.

1.3.3 Rules and Methods

Using the String manipulations described in the previous section and sidebar, we
can construct the instructions that a variety of Transformers would use to
transform a String. For example, we might write:

to transform a String ( say, thePhrase ),

return thePhrase.toUpperCase();

This rule describes the transformation rule for an UpperCaser. Note that theString

5
A character is, roughly, a single alphanumeric or symbolic character (one keystroke) inside
single quotation marks. For more detail on what exactly constitutes a character, see the chapter on
Java types.

IPIJ || Lynn Andrea Stein

I1~14 A Community of Interacting Entities Interlude 1

is intended to stand in for whatever String needs to be transformed. The

transformation rule can't operate unless you give it a String. Within the body of
the transformation rule, a temporary name (in this case, thePhrase) is used to refer
to this supplied String. The formal term for such a piece of supplied information
is an argument, and the formal term for the temporary name that is used to refer
to it is a parameter.
A different transformation rule -- this one for a pedantic Transformer that seems
to think it knows everything -- might say

to transform a String ( say, whatToSay ),

return "Obviously " + whatToSay;

Note that we have chosen a different temporary name to represent the String
argument. The parameter name doesn't matter; we can choose whatever (legal
Java) name we wish.[Footnote: Legal Java names are covered in the sidebar on
Java names in the chapter on Types.] It can be the same name in every
transformer rule, or different in each one. It is only important that we use the
same name in a particular rule both when we're specifying the parameter (in the
first line of the rule) and in the body of the rule.

Q. Can you think of another kind of Transformer and write its rule? Remember, it
should take a String and produce a String.
The rules as we've presented them aren't really Java code, but they are pretty
close. To make them legal Java, we need to add a bit more formality and syntax.
The formal name for a rule in Java is a method, just like the String methods --
toUpperCase(), substring( index ), etc. -- above. Somewhere, someone has
provided instructions for how to toUpperCase() so that you can use that method
without worrying how it is done. Here, we are providing the instructions for
transform, so that someone else can use it.

A definition of UpperCaser's transform method might say:

String transform ( String thePhrase )
{
return thePhrase.toUpperCase();
}
Aside from the syntax (the details of which are covered in chapters 6 and 7), the
one big difference from the rule specification above is that the method definition
begins with the word String to indicate that the method will produce a String
when it is invoked.

Q. Quick quiz: How would you write the pedantic Transformer's transform

IPIJ || Lynn Andrea Stein

1.3 Building a Transformer I1~15

method?

1.3.4 Classes and Instances

What we just described was how to specify a rule. This rule is the rule used by all
Transformers of that particular type. In fact, the rule is really the only thing that
distinguishes Transformers of that type from other Transformers. We can describe
a type of Transformer by wrapping the method definition in a bit of code that says
it's a type. In Java, a type that provides instructions implementing behavior is
called a class.
class UpperCaser extends StringTransformer
{
String transform ( String thePhrase )

{
return thePhrase.toUpperCase();
}
}
This says that UpperCaser is a type (or class) that is very much like the more
general class StringTransformer. Its behavior differs from generic
StringTransformers by using the particular transform rule contained inside the
braces {} that delineate UpperCaser's body.
Pedant is similar:
class Pedant extends StringTransformer
{
String transform ( String whatToSay )

{
return "Obviously " + whatToSay;
}
}

Q. A class that uses your transformer rule should be very much like these. Can
you write it?
These classes are descriptions of what an UpperCaser or a Pedant should do. They
are not UpperCasers or Pedants themselves, though. They're really more like
recipes from which a particular UpperCaser or a particular Pedant can be made.
To make an UpperCaser, you use the special Java construction expression new
UpperCaser(). Thisk "cooks up" a particular UpperCaser using the recipe we just
wrote. A Pedant is created similarly, but using a different recipe: new Pedant().

IPIJ || Lynn Andrea Stein

I1~16 A Community of Interacting Entities Interlude 1

If we say it again, we can "cook up" another Pedant: new Pedant().

Stepping back, this is exactly what we want the buttons on our control panel to
do. Pressing the button marked Pedantic Transformer should invoke the
expression new Pedant(), causing an Pedant to appear on our screen. Pressing it
again should invoke it again, making a second Pedant appear. We can connect
these two together using other user interface functions. Now, if we send the String
"I'm here!" through a Connector to the first Pedant, it should send the String
"Obviously I'm here" to the second Pedant, and the second Pedant should produce
"Obviously Obviously I'm here".

Q. Connecting a Pedant's output to an UpperCaser's input and supplying the

Pedant with "not much" will produce "OBVIOUSLY NOT MUCH". What
happens if you connect an UpperCaser's output to a Pedant's input?

Q. How about Pedant, then Pedant, then UpperCaser, then Pedant? Then
UpperCaser?

1.3.5 Fields and Customized Parts

You can already see from the examples in the previous subsection how one class,
or type, can describe many different instances. For example, phrases passed
through the first Pedant contain at least one "Obviously" at the beginning; phrases
passed through the second Pedant will begin with at least two "Obviously"s. But
to really appreciate the power of multiple distinct instances of a type, we need to
look at a type that has local state associated with each instance. The
NameDropper Transformer type is a good example of this.

The transformation rule for NameDropper is

to transform a String ( say, thePhrase ),

return my name + " says " + thePhrase;

But my name here isn't a parameter. It isn't a piece of information that is supplied
to the NameDropper each time the NameDropper performs a transformation, the
way that thePhrase is. Instead, my name is a persistent part of the NameDropper.
And it is a part of the particular NameDropper instance, not a part of the
NameDropper type. After all, each NameDropper drops its own name.
So where does this name come from? As each individual NameDropper is
created, it must be supplied with a name. Then, the particular NameDropper

IPIJ || Lynn Andrea Stein

1.3 Building a Transformer I1~17

remembers its own name, and when it comes time to transform a String, the
NameDropper uses its own name.
To do this, we need to create a local storage spot that sticks around between
transformations. This is done using a special kind of name that is associated with
the NameDropper instance. Such a name is called a field. In this case, we'll use a
field called name, because that's what it will hold. To make it clear in our code
that we're referring to a field, we use a syntax sort-of like saying my name; we
refer to the field using this.name. In Java, this is a way of letting an individual
instance say "my own".
So the actual transform method for NameDropper should read:
String transform ( String thePhrase )
{
return this.name + " says " + thePhrase;
}
This way, if one NameDropper has the name Pat and another has the name Chris,
Pat would transform the String "Hello" into "Pat says Hello" while Chris would
make it "Chris says Hello".

This method definition needs to be embedded in a class, of course. We also need

to add a bit more machinery to the class to make sure that the name is available
when transform needs it. The first change is to actually create a place to put the
name; the second is to write explicit instructions as to how to create a
NameDropper so that it has a name from the very beginning. This second --
constructor -- rule will need to say:

to construct a NameDropper with a String ( say, whatTheNameShouldBe

),
assign my name the value of whatTheNameShouldBe;

IPIJ || Lynn Andrea Stein

I1~18 A Community of Interacting Entities Interlude 1

When we translate this into Java using the special syntax for a constructor rule, it
looks like this:
NameDropper( whatMyNameShouldBe )
{
this.name = whatMyNameShouldBe;
}
So the whole NameDropper class reads:
class NameDropper extends StringTransformer
{
String name; // the persistent storage,
// a permanent part of each
NameDropper

NameDropper( whatMyNameShouldBe )
{ // the creation
rule
this.name = whatMyNameShouldBe;
}

String transform ( String whatToSay )

{ // the transform
rule

return "Obviously " + whatToSay;

}
}
Now, when we invoke NameDropper's construction method, we give it a
parameter:
new NameDropper( "Pat" ), for example.

We have actually seen -- or at least alluded to -- a similar situation earlier. When

discussing the other entities that together constitute a Transformer, we said that
the input-connection-acceptor's job was to stick the input connection it receives
somewhere where the rest of the Transformer community can use it. Like
NameDropper, the generic StringTransformer accomplishes this using a field.
Fields, methods, and constructors are the building blocks of Java objects. We will
see each of these things in action in the next several chapters. In chapter 7, on
Classes and Instances, we will go through each of these items in greater detail For
now, it is enough to have a general sense of how things fit together.

IPIJ || Lynn Andrea Stein

1.3 Building a Transformer I1~19

1.3.6 Generality of the approach

In writing this code, we have relied on the existence of a generic
StringTransformer class. In that class, we include rules for how to accept an input
connection (using a field to store it away), how to accept an output connection,
and how to create an individual StringTransformer, including creating its own
instruction follower to explicitly invoke the transform method over and over again
on each String read from the stored input connection. The ways in which this
StringTransformer class is put together are much like the ways in which the
examples here are constructed, but the StringTransformer class is about four times
the size of the classes described above. The complete code for StringTransformer
is included in the on-line supplement to this book.
The transformers that we have written here each obey the same general rules and
interfaces. Each defines a transform method that takes a String and returns a
String. The apparent uniformity among StringTransformers makes it possible for
the connection mechanism that we outlined in the previous section to work with
each of them. The differences among StringTransformer behaviors are hidden
inside the transform method that each of them implements. In the course of this
book, we will see many different cases in which hiding behavior behind a
common interface makes a system more general and more powerful. Good design
specifications are crucial; they amount to deciding in advance how entities will
interact.

1.4 Summary
In this chapter, you have been exposed to many of the most basic pieces of Java
programming. None of these has been presented in sufficient detail to achieve
mastery of it. Each of these topics will be revisited, most in the next part of the
book. But the example described above gives a context within which to place the
detail that occupies the next several chapters.
In the next chapter, we will explore the role of types in Java systems and the
relationship between types and names. The final chapter of this section looks at
interfaces, the contracts that one type of object makes with another. In the next
section, we turn to expressions -- such as method invocation, field access,
instance construction, and even String concatenation -- and learn how evaluating
an expression produces a value of a specified type. Expressions are combined to
make statements, the step-by-step instructions of Java code that produce behavior
and flow of control. Classes allow us to implement behavior and to encapsulate

IPIJ || Lynn Andrea Stein

I1~20 A Community of Interacting Entities Interlude 1

both instructions and local state -- such as the NameDropper's name -- into
individual objects. And self-animating objects contain their own instruction
followers that execute sequences of instructions over and over, communicating
with other objects and interacting to provide desired behavior on an ongoing
basis.

Suggested Problems
See the text for things marked with a Q. Also:
1. Implement LowerCaser.
2. Implement SentenceCaser (1st letter capitalized, rest not).
3. Implement Pig Latin.
4. An improved Pig Latin would leave the first letter in place if it were a vowel,
and add -way instead. This requires understanding basic conditionals and flow of
control. (See Statements.)
5. Ubby Dubby is pretty hard. You may want to look carefully at the chapter on
Dispatch.
6. Combiners and Repeaters involve extending StringTransformer in other ways,
overriding acceptInputConnection or acceptOutputConnection. (See the online
code supplement for StringTransformer source code.)
7. Really challenging problem: extract words, one word at a time, only reading an
input when all words have been used up.

IPIJ || Lynn Andrea Stein

part 2
 3
Chapter 3 Things, Types, and Names

Chapter Overview
• What kinds of Things can computers talk about?

• How do I figure out what they can do (or how they interact)?

• How can I keep track of Things I know about?

This chapter introduces some of the conceptual structure necessary to understand
Java programs. It begins by considering what kinds of things a program can
manipulate. Some things are very simple--like numbers--and others are much
more complex--like radio buttons. Primitive things can't do anything by
themselves, but in later chapters you'll learn how to do things with them. Many
complex things can actually act, either by themselves (e.g. a clock that ticks off
each second) or when you ask them to (e.g. a radio that can play a song on
request). These complex things are called Objects.
The remainder of this chapter introduces two important concepts for
understanding and manipulating things in Java: typing and naming.
Types are ways of looking at things. A type specifies what a thing can do (or what
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
3~2 Things, Types, and Names Chapter 3

you can do with a thing). Types are like contracts that tell you what kinds of
interactions you can have with things. Sometimes, the same thing can be viewed
in different ways, i.e., as having multiple types. For example, a person can be
viewed as a police officer or as a mother, depending on the context. (When
making an arrest, she is acting as a police officer; when you ask her for a second
helping of dessert, you are treating her as a mother.) A thing's type describes the
way in which you are regarding that thing. It does not necessarily give the
complete picture of the thing.
Names are ways of referring to things that already exist. A name doesn't bring a
thing into existence, but it is a useful way to get hold of a thing you've seen
before. Every name has an associated type, which tells you what sorts of things
the name can refer to. It also tells you what you can expect of the thing that that
name refers to. In other words, the type describes how you can interact with the
thing that the name names. There are actually two different kinds of names in
Java: primitive (shoebox) names and reference (label) names.
Sidebars in this chapter cover the details of legal Java names, Java primitive
types, and other syntactic and language-reference details.

Objectives of this Chapter

1. To recognize Java types.
2. To distinguish Java primitive from object types.
3. To be able to declare and define variables.
4. To understand that a declaration permanently associates a type with a
name.
5. To recognize that each shoebox name contains exactly one value at any
time.
6. To understand how a label name can have a referent or have no referent
(i.e., be null).
7. To be able to tell when the values associated with two names are equal.

IPIJ || Lynn Andrea Stein

3.1 Things 3~3

3.1 Things
What kinds of things can your programs involve? Almost anything, as it turns out.
But we'll start with some very simple things.

3.1.1 Primitive Things and Literals

Java, like many programming languages, has some built-in facilities for handling
and manipulating simple kinds of information. For example, Java knows about
numbers. If you type 6 in a(n appropriate place in a) Java program, the computer
will "understand" that you are referring to an integer greater than 5 and less than
7. 6 is a Java literal: an expression whose value is directly "understood" literally
by the computer. In addition to integers, Java recognizes literals that approximate
real numbers expressed in decimal notation as well as single textual characters.
This means that all of the following are legitimate things to say in Java:

• 6

• 42

• 3.5

• -3598.43101

Details of Java numeric literals -- and of all of the other literals discussed here --
are covered in the sidebar on Java Primitive Types. As we will see in the next
chapter, you can perform all of the usual arithmetic operations with Java's
numbers.1
Java can also manipulate letters and other characters. When you type them into
Java, you have to surround each character with a pair of single quotation marks:
'a', 'x', or '%'. Note that this enables Java to tell the difference between 6 (the
integer between 5 and 7) and '6'(the character 6, which on my keyboard is a
lower case '^'). The first is something that you can add or subtract. The second is
not.
One character by itself is not often very useful, so Java can also manipulate
sequences of characters called strings. Strings are used, for example, to

1
Be warned, though, that non-integer values -- real numbers -- are represented only
approximately.

IPIJ || Lynn Andrea Stein

3~4 Things, Types, and Names Chapter 3

communicate with the user. Error message, user input (i.e., what you type to a
running Java program), titles and captions are all examples of Java strings. To
describe a specific string in Java -- for example, the message that your computer
prints to the screen when you boot it up -- you can write it out surrounded by
double quotes: "Hi, how are you?" or "#^$%&&*%^$" or even "2 + 2". Your
computer doesn't understand the string, it just remembers it. (For example, the
computer doesn't know of any particular relationship between the last example
and the number 4 -- or the string "4".)
It turns out that it's also useful for many programs to be able to manipulate
conditions, too, so Java has one last kind of primitive value. For example, if we
are making sandwiches, it might be important to represent whether we've run out
of bread. We can talk about what to do when the bread basket is empty:
if the bread basket is empty, buy some more bread....
Conditions like this -- bread-basket emptiness -- are either true or false. We call
this kind of thing a boolean value. Booleans are almost always used in
conditional -- or test -- statements to determine flow of control, i.e., what should
this piece of the program do next? Java recognizes true and false as boolean
literals: if you type one of them in an appropriate place in your program, Java will
treat it as the corresponding truth value.
There are lots of rules about how these different things work and how they are
used. For many of the detailed rules about the primitive things that we have just
covered, see the sidebar on Java Primitive Types.

3.1.2 Objects
The things described above are very specific kinds of things, and they have very
limited functionality. In the next chapter, we will see what we can do to
manipulate these primitive kinds of things. Most of what goes on in Java, though,
concerns another kind of thing. This kind of thing can include anything you might
want to represent in a computer program. Some examples of these other things
include the radio button that the user just clicked, the window in which your
program is displaying its output, or the url of your home page. These things --
everything else your program can talk about -- are called objects. In Java, objects
include everything that is not one of the aforementioned primitive types.2

2
In fact, in Java, strings are objects and not primitives.

IPIJ || Lynn Andrea Stein

3.1 Things 3~5

There are many different kinds of objects, from buttons and windows to
dictionaries and factories. Each kind of object has a type associated with it.
Objects can be asked to do things, and each kind of object -- each object type --
determines what individual objects of that type can do. For example, windows can
close; dictionaries can do lookups. Each particular kind of object provides a
particular set of services or actions that objects of that kind can do. Further, each
individual object of that type can perform these actions. For example, if
myWindow and yourWindow are two different window-type objects, myWindow
can close, and so can yourWindow. But if myWindow closes, that doesn't in
general affect yourWindow.
Some objects can even act on their own without being asked to do anything; they
are "born" or created with the ability to act autonomously. For example, an
Animator may paint a series of pictures rapidly on a screen, so that it looks to a
human observer like the picture is actually moving. The animator may do this
independently, without being asked to change the picture every 1/30th of a
second. Similarly, an alarm clock may keep track of the time and start ringing
when a preset time arises.
As you can see, objects can be much more interesting than the kinds of things
represented by Java primitive types. However, objects are somewhat more
complex than Java primitives. In particular, there are no object literals:3 you can't
type an arbitrary object directly into your program the way that you can type 3 or
'x' or "Hello!" or false.
Almost everything that you do in Java uses objects, and you will hear much more
about them throughout this book. This chapter concentrates on how you identify
the Things in a program and how names can be used to refer to them. In the next
chapter, we will see in more detail how to use these Things to produce other
Things. Chapter 5 concentrates on combining these pieces into a full-blown
recipe, a single list of instructions that can be followed to accomplish a particular
job. The three chapters following (6-8) look at objects in more detail, describing
how to create and use the objects that are manipulated by these instructions, and
how these instructions themselves can be combined to form objects and entities
that interact in a community.

3
Except String literals.

IPIJ || Lynn Andrea Stein

3~6 Things, Types, and Names Chapter 3

3.2 Naming Things

With all of these things floating around in our program, it is pretty easy to see that
we'll need some ways to keep track of them. The simplest way Java offers for
keeping track of things is to give them names. This is called assigning a value to
a name. Giving something a name is sort-of like sticking a label on the thing or
putting the thing in a particular shoebox. (We'll see later that there are actually
two different kinds of name/thing relationships, one more like labels and the other
more like shoeboxes.) We sometimes say that the name is bound to that value.

IPIJ || Lynn Andrea Stein

3.2 Naming Things 3~7

Java Naming Syntax and Conventions

Java identifiers can contain any alphanumeric characters as well as the
symbols $ and _. The first character in a Java identifier cannot be a
number. So luckyDuck is a legitimate Java identifier, as is
_Alice_In_Wonderland_, but 24T is not.

Certain names in Java are reserved words. This means that they have
special meanings and cannot be used as names -- i.e., to refer to things,
other than any built-in meaning they may have -- in Java. Reserved words
are sometimes also called keywords. These are:
abstract default if private throw
boolean do implements protected throws
break double import public transient
byte else instanceof return try
case extends int short void
catch final interface static volatile
char finally long super while
class float native switch
const for new synchronized
continue goto package this
Java is case-sensitive. This means that double and Double are two
different words in Java. However, you can insert any amount of white
space -- spaces, tabs, line breaks, etc. -- between two separate pieces of
Java -- or leave no space at all, provided that you don't run words together.
You can't stick white space into the middle of a piece of Java -- a name or
number, for example -- though.
Punctuation matters in Java. Pay careful attention to its use. Note, however,
that white space -- spaces, tabs, line breaks, etc. -- do not matter in Java.
Use white space to make your code more legible and easier to understand.
You will discover that there are certain conventions to the use of white
space -- such as lining up the names in a column, as we did above --
although these tend to vary from one programmer to the next.

To actually assign a value to a name -- to create a binding between that name and
that value -- Java uses the syntax
name = value

For example,

IPIJ || Lynn Andrea Stein

3~8 Things, Types, and Names Chapter 3

myFavoriteNumber = 4

This associates the value 4 with the name myFavoriteNumber. 4 may be

associated with more than one name, but only one value may be associated with a
name at any given time. (One thing can be referred to by any number of names at
once -- including no names at all. The same person can be "the person holding my
right hand", "my very best friend", and "Chris Smith". But only one person is "the
person holding my right hand".4)

Once a particular name refers to a particular thing -- say greeting has the value
"Hi, how are you?" -- then we can use the name wherever we would use its
value, with the same effect. The name becomes a stand-in for the thing it refers to.
In the next chapter, we will see that a name is a simple kind of expression. But
before we can assign a value to a name, we need to know whether the name is
allowed to label values of that type.

3.3 Types
Up to now, we've been pretty casual about our things. Java, however, is a strongly
typed language, meaning that it is not at all casual about what kind of thing
something is. Each Java thing comes into the world with a type, i.e., an indication
of what kind of thing it is. Java names, too, are created with types, and a Java
name can only be used to label objects of the appropriate type. Before we can use
a name -- as myFavoriteNumber, above -- we have to declare it to be of a
particular type. Declaring a name means stating that that particular name is to be
used for labeling values (things, objects) of some particular type.

3.3.1 Declarations and the type-of-thing name-of-thing rule

Names are declared using the type-of-thing name-of-thing rule:
int myFavoriteNumber;
char firstLetterOfMyName;
The second word on each line is a name that is being declared. The first word on
each line is the type that the name is being declared to have. In the first line of the
example above, myFavoriteNumber is being declared to have type int. This is a
Java name for an integer. Finally, each declaration ends with a semi-colon (;). So

4
Barring weird interpersonal pileups, of course.

IPIJ || Lynn Andrea Stein

3.3 Types 3~9

the first declaration here creates a name, myFavoriteNumber, suitable for naming
integers (or, in Java, ints). The second line creates the name
firstLetterOfMyName, suitable for naming single characters (i.e., things of Java
type char).
A name has a certain lifetime, sometimes called its scope. Within that scope --
over its lifetime -- the name may be bound to many different values, though it can
only be bound to one value at a time. (For example, myFavoriteNumber may
initially be 4, but later change to be 13.) The association between a name and a
type persists for the lifetime of the name, however. (myFavoriteNumber can only
name an int, not a String or a boolean.)

3.3.2 Definition = Declaration + Assignment

Declaring a name begins its useful lifetime. At that time, nothing else necessarily
needs to happen -- and frequently, it doesn't. But sometimes it is useful to
associate the name with a value at the time that it is declared. This combination of
a declaration and an assignment is called a definition. (Declarations tell you what
type is associated with a name. Assignments tell you what value that name is
bound to. In fact, assignments set the values of names. Definitions combine the
"what kind of thing it can name" and "what value it has" statement types.) For
example:
boolean isHappy = true;
double degreesCelsius = 0.0;
Thread spirit = new Thread(this);
Cat myPet = marigold;
The first and second of these make use of boolean and double constants,
respectively, to assign values to the names isHappy and degreesCelsius. The
Thread definition actually creates a new Thread using a constructor with one
argument; much more on this later. The final definition makes the name myPet
refer to the same Cat currently named by marigold. This is a case of marigold
standing in for the actual Cat, that is, the name being used in place of the thing it
refers to. After the assignment completes, myPet is bound to the actual Cat, not to
the name. If marigold later refers to some other Cat -- say both Cats undergo
name changes -- myPet will still refer to the Cat originally known as marigold.

IPIJ || Lynn Andrea Stein

3~10 Things, Types, and Names Chapter 3

3.3.3 Primitive Types

A type tells Java something about how it should represent and manipulate the
information internally. All of the Java types discussed above except Cat have
built-in type names. These type names are a part of the Java language. For
example, characters -- such as 'x', '3', ';', or '#' -- have type char. The
second line of the first example above shows the Java type for a character -- char
-- and declares that firstLetterOfMyName is a name that can be used to refer to a
character. Each Java type also has associated representational properties. All of
the Java primitive type names, along with their properties, are described in the
sidebar on Java Primitive Types.

IPIJ || Lynn Andrea Stein

3.3 Types 3~11

Java Primitive Types

Each Java primitive type has its own built-in name. For example, int is a
name for a type-of-thing corresponding to an integer value. There are
actually four Java names for integers, depending on how much space the
computer uses to store them. An int uses 32 bits, or binary digits. It can
represent a number between -2147483648 and 2147483647 -- from -231 to
231 - 1 -- which is big enough for most purposes. An integral number (i.e., a
number without a decimal point) appearing literally in a Java program will
be interpreted as an int.

If you need a larger range of numbers, you can use the Java type long,
which can hold values between - 263 and 263 - 1. You can't just type in a
value like 80951151051778, though. Literals intended to be interpreted as
long end with the character L (or l): 80951151051778L. There are also two
smaller integer types: the 16-bit short and the 8-bit byte. There are no
short or byte literals. For most purposes, the int is probably the Java
integral type of choice.
Real valued numbers are represented using floating point notation. There
are two versions of real numbers, again corresponding to the amount of
space that the computer uses to store them. One is float, short for floating
point; the other is double, for double precision floating point. Both are
only approximations to real numbers, and double is a better approximation
than float. Neither is precise enough for certain scientific calculations. A
38 -45
float is 32 bits, from positive or negative 3.4e to +/-1.4e ; a double is
308 -324
64 bits, from 1.8e to 4.9e . The double type gives more precise
representations of numbers (as well as a larger range), and so is more
appropriate for scientific calculations. However, since errors are magnified
when calculations are performed, computations with large numbers of
calculations mean that unless you are careful, the imprecision inherent in
these approximations will lead to large accumulated errors.5

The default floating point literal is interpreted as a double; a literal to be

treated as a float must end with f or F. (A double literal optionally ends
with d or D.)
You can express both integral and real number literals with or without a

5
These issues are studied by the field of mathematics known as numerical analysis.

IPIJ || Lynn Andrea Stein

3~12 Things, Types, and Names Chapter 3

leading -. Real and rational numbers can be written using decimal notation,
as in the text, or in scientific notation (e.g., 9.87E-65 or 3.e4).

The Java character type is called char. Java characters are represented
using an encoding called unicode, which is an extension of the ascii
encoding. Ascii encodes English alphanumeric characters as well as other
characters used by American computers using 8 binary digits. Unicode is a
16-bit representation that allows encoding of most of the world's alphabets.
Character literals are enclosed in single quotation marks: 'x'.
Characters that cannot easily be typed can be specified using a character
escape: a backslash followed by a special character or number indicating
the desired character. For example, the horizontal tab character can be
specified '\t'; newline is '\n''; the single quote character is '\'', double
quote is '\"', and backslash is '\\'. Characters can also be specified by
using their unicode numeric equivalent prefixed with the \u escape.

The true-or-false type is called boolean. There are exactly two boolean
literals, true and false.
The names of Java primitive types are entirely lower case.

The double-quoted-sequence-of-characters type is called String. String

doesn't actually belong in this list because, unlike the other type listed here,
String is not a primitive type. Note that its name begins with an upper case
letter. String does have a literal representation, though. (String is the only
non-primitive Java type to have a literal representation.) A String literal is
enclosed in double quotation marks: "What a String!" It may contain
any character permitted in a character literal, including the character
escapes described above. The String "Hello, world!\n" ends with a
newline.
The names of Java primitive types are reserved words in Java. This means
that they have special meanings and cannot be used to name other things in
Java. (See the sidebar on Java Names.)

3.3.4 Object Types

Java also comes with certain predefined object types, such as String and Button. If
you are using the cs101 course libraries, you'll also have access to object types

IPIJ || Lynn Andrea Stein

3.3 Types 3~13

such as AnimateObject and DefaultFrame. And, in the rest of this book, you will
be learning to define object types--and create instances of those types--to do what
you want. These types -- whether a part of the Java language or of your own
definition -- are all kinds of objects. Note that, by convention, the name of each
object type -- each class -- starts with a capital letter. The names of the primitive
types start with lower case letters, as do (most) names and methods.

Object types may include KlingonStarship (if you're building a space battle
adventure game), IllustratedBook (if you're building an electronic library
system), or PigLatinTranslator (if you're building a networked chat program).
Each of these object types may describe many different individual objects -- the
three KlingonStarships visible on your screen, the five hundred and seven
IllustratedBooks in the children's library, or the particular
PigLatinTranslator that your particular chat program is using. (These
individual objects are sometimes called instances of their types. For example, the
KlingonStarship that you just destroyed is a different KlingonStarship
instance from the one that is getting ready to fire its phasers at you. We'll explore
this idea in greater detail in chapter 7.)
Each individual object comes ready-made with certain properties and behavior.
An IllustratedBook has an author and an illustrator, for example. A
PigLatinTranslator may be able to translate a word that we supply it into Pig
Latin. We ask objects to do things (including telling us about themselves) using
specific services that these objects provide. Often, these services are accessed by
giving the name of the object we're asking followed by a dot (or period), followed
by the request we're making of the object. So if theLittlePrince is the name of
an IllustratedBook, theLittlePrince.getAuthor() would be a request for
the name of the author of the book: "Maurice de Saint Exupery". Similarly, if
myTranslator is a PigLatinTranslator,
myTranslator.processString("Hello") might be a request to myTranslator
to produce the Pig-Latin-ified version of "Hello", which is "ello-Hay". These
requests are the most basic form of interaction among the entities in our
community.
One particularly useful object is Console. Console is an object that can print a
String to the Java console, a standard place where someone running a Java
program can look for information. Console can also readln a String that the user
types to the Java console.

IPIJ || Lynn Andrea Stein

3~14 Things, Types, and Names Chapter 3

Console
Console is a special cs101 object that knows how to communicate with the
user in some very basic ways. If your program says
Console.println( "Hello there!" );
then the String "Hello there!" will appear on the Java console. The
command
Console.print( "Hi" );
is similar, except that Console.print doesn't end the line of output, while
Console.print does. This means that
Console.print( "A " );
Console.print( "is for apple." );
would produce the output
A is for apple.
while
Console.println( "A " );
Console.println( "is for apple." );
would produce
A
is for apple.
You can of course combine prints and printlns arbitrarily. Printing a
String containing a newline character escape (\n) causes the line to end as
well.
You can also use Strings that are associated with names or any other
Strings you may have access to, not just String literals.

Console has one other important method, Console.readln(), which takes

no arguments and returns a String, specifically the String typed by the
user (and ending with a return or enter character) on the Java console.

3.4 Types of Names

In Java, every name has a type. This type is associated with the name when the

IPIJ || Lynn Andrea Stein

3.4 Types of Names 3~15

name is declared. The type associated with a particular name never changes. It
turns out that there are two rather different kinds of names in Java. In this section,
we will look at each in turn and see what it means for a name to be declared to be
of a particular type.

Figure 2. Shoebox names.

3.4.1 Shoebox Names

Names, in Java, come in two flavors. The first kind of name is rather like a
shoebox. Declaring the name to be of that type creates a space in the computer
just the right shape and size to hold the appropriate thing.
For example,
int i;

associates i with storage appropriate for a 32-bit integer. In fact, the declaration
of a shoebox-type name not only sets up an appropriately sized shoebox, it also
fills that shoebox with an appropriate value. If -- as in this declaration of i -- no
value is specified, the shoebox contains the default value for the type -- in this
case, 0. There is no such thing as an empty shoebox. You must give a name a
value before you can use it.6
Assigning a value to such a name replaces the value stored in the shoebox with a
new copy of the appropriate value. There is no sharing between shoeboxes.
Instead, there are multiple copies of, say, the int 3. Every shoebox always
contains exactly one thing. When a new value is assigned to a shoebox, any value
previously stored in that shoebox is discarded. So, for example,
i = 3;

6
Some special kinds of names get values by default. We will mention these values as the names
are introduced.

IPIJ || Lynn Andrea Stein

3~16 Things, Types, and Names Chapter 3

makes the i-shoebox hold 3; the 0 initially stored in the i-shoebox is discarded.
The declaration-plus-assignment definition
int j = i;

creates another int-sized shoebox, j. In this case -- because this is a definition, not
simply a declaration -- j starts out containing a copy of the value that happens to
be in i when the definition is executed. That is, this definition makes a copy of the
value currently in i -- 3 -- and creates a new shoebox, called j, to hold it. Once
this is done, there is no special relationship between i and j.

In particular, if we now change the value of i:

i = 4;

-- which sets the value of i to 4 -- j is unchanged; it still holds 3.

At any point in time, each shoebox contains exactly one thing. A shoebox cannot
be empty. A shoebox also cannot contain more than one thing. If you put a new
thing into a shoebox, the thing that was previously there is no longer there.
Strictly speaking, the kinds of things that go into shoeboxes are things that are the
same exactly when they look the same. For example, two "different" copies of the
(int-sized) number 3 are, for all intents and purposes, the same.7
This might make more sense if contrasted with two things that "look" the same,
but aren't. Consider, for example, identical twins. Although they may look exactly

7
Note, however, that this does not extend to 3 and 3.0 and 3.0f, each of which is a different thing.
This is because each of these has a different type.

IPIJ || Lynn Andrea Stein

3.4 Types of Names 3~17

the same, they are still two different people. If one gets a haircut, the other's hair
doesn't automatically get shorter. If one takes a bath, the other doesn't get clean. 3,
on the other hand, has no internal structure that can be changed (the way that one
twin's hair can be cut). If you change 3, you don't have 3 any more.
Notice, though, that although 3 is 3 is 3 (i.e., there aren't "different" 3s the way
that there are different twins), there may be different shoeboxes that CONTAIN 3.
If myBox and yourBox are both int-sized shoeboxes, each containing 3, changing
the number in myBox doesn't automatically change the number in yourBox. So
after
int myBox = 3;
int yourBox = 3;
myBox = 5;
yourBox will still contain 3. Each shoebox is separate and (unless we find some
way to actively connect it to another) independent.
The only thing that remains to say about shoebox-type names is how to recognize
one. The rule is quite simple: All names with primitive type are shoebox-type
names.
A more formal term for shoebox types is value type.

Figure 4. Label names.

3.4.2 Label Names

We have seen that names associated with primitive types are shoebox-type names.
Names associated with all other types -- including all Object types -- are label or
reference names. (This includes String names.)
Label-type names are names that can be stuck onto (appropriately typed) objects.
When a label-type name is declared, a new label suitable for affixing on things
with that type is created. For example, a building name might be a cornerstone
label, a person's name might go on a badge, and a dog's name might belong on a
collar. You can't label a person with a cornerstone or pin a badge on a dog, at least

IPIJ || Lynn Andrea Stein

3~18 Things, Types, and Names Chapter 3

not without raising an error. Unlike cornerstones or dog tags, though, labeling a
Java object doesn't actually change that object. It just gives you a convenient way
to identify (or grab hold of) the object.
In Java terms, if we declare
RadioButton myButton;

this creates a label, myButton, that can be stuck onto things of type RadioButton.
Note that is not currently so stuck, though. At the moment, myButton is a label
that isn't stuck to anything. (Cornerstones and badges and dog tags don't come
with buildings and people and dogs attached, either. Having a label is different
from having something to label with it.) Labels don't (necessarily) come into the
world attached to anything. The value of a label not currently stuck onto anything
is the special non-value null. (That is, null doesn't point, or refer, to anything.)
So the declaration above is (in most cases) the same as defining
RadioButton myButton = null;

Figure 5. A label name that's not yet stuck on anything.

Of course, we can attach a label to something, though we need to have that

something first. We'll return to the question of where things come from in a few
chapters. For the moment, let's suppose that we have a particular object with type
RadioButton, and we stick the myButton label onto it. (Now myButton's value is
no longer null.)

After we give myButton a value -- stick it onto a particular RadioButton -- we

can check to see whether it's pressed:

IPIJ || Lynn Andrea Stein

3.4 Types of Names 3~19

myButton.isSelected()

(This is an expression that returns a boolean value; see the discussion of

expressions in the next chapter.)

If we now declare
RadioButton yourButton = myButton;

a new label is created. This new label is attached to the same object currently
labeled by myButton. Assignments of label-type names do not create new (copies
of) objects. In this case, we have two labels stuck onto exactly the same object,
and we say that the names myButton and yourButton share a reference. This
just like saying that "the morning star" and "the evening star" both refer to the
same heavenly body.

Figure 6. Multiple labels can refer to the same object.

Because myButton and yourButton are two names of the same object, we know
that
myButton.isSelected()

and
yourButton.isSelected()

will be the same: either the button that both names label is pressed, or it isn't. But
we can separate the two labels -- say

IPIJ || Lynn Andrea Stein

3~20 Things, Types, and Names Chapter 3

myButton = someOtherButton

-- and now the values of

myButton.isSelected()

and
yourButton.isSelected()

would differ (unless, of course, someOtherButton referred to the same thing as

yourButton). Note that moving the myButton label to a new object doesn't have
any effect on the yourButton label.
Note also that the labeled object is not in any way aware of the label. The actual
radioButton doesn't know whether it has one label attached to it, or many, or
none. A label provides access to the object it is labeling, but not the other way
around.

All non-primitive types work like labels.

Chapter Summary
• Literals are Things you can type directly to Java.

• Java has several primitive types:

• char is the type for single keystrokes (letters, numbers, etc.)

• int is the standard type for integers. Other integer types include
byte, short, and long.

• double is the standard type for real numbers. float is another real
type.

• boolean is a type with only two values, true and false.

• All other Java types are object types.

• String is the type for arbitrary text. String is not a primitive type, but
Java does have String literals.

IPIJ || Lynn Andrea Stein

 Exercises 3~21

• Names can be used as placeholders for values. Every name is born

(declared) with a particular type, and can only label Things having that
type.

• Primitive types have shoebox names. A shoebox name always has an

associated value. Two shoeboxes cannot share a single value; each has its
own copy.

• Object types have label names. Two label names can label the same
object. A label that is not currently stuck on anything is associated with
the non-value null.

Exercises

1. Assume that the following declarations apply:

int i;
char c;
boolean b;
For each item below, give the type of the item.

1. 42

2. -7.343

3. i

4. 'c'

5. "An expression in double-quotes"

6. b

7. false

8. "false"

9. c

10. 'b'

11. "b"

IPIJ || Lynn Andrea Stein

3~22 Things, Types, and Names Chapter 3

2. For each of the following definitions, fill in a type that would make the
assignment legal.8
__________ a = 3;
__________ b = true;
__________ c = 3.5;
__________ d = "true";
__________ e = "6";
__________ f = null;
__________ g = 0;
__________ h = '3';
__________ i = '\n';
__________ j = "\n";

3.a. Assume that the following statements are executed, in order.

int a = 5, b = 7, c = 3, d=0;
a = b;
c = d;
a = d;
What is the value of c? Of a? Of b? Of d?
b. Assume that the following statements are executed, in order.
int a = 5, b = 7, c = 3, d=0;
a = b;
b = c;
What is the value of a? Of b? Of c?
c. Assume that the following statements are executed, in order.
char a = 'a', b = 'b', c = 'c', d='d';
a = b;
c = a;
a = d;
What is the value of a? Of b? Of c? Of d?

d. Assume that myObject is a name bound to an object (i.e., myObject is not

null). After the following statements are executed in order,
Object a = myObject;
Object b = null;
Object c = a;

8
There are several answers to some of these, but in each case only one "most obvious" type. It is
this "most obvious" type that we are after.

IPIJ || Lynn Andrea Stein

 Exercises 3~23

a = b;
which of a, b, c, or myObject is null? (The answer may be none, one, or more than
one.)

e. Assume again that myObject is a name bound to an object (i.e., myObject is

not null). After the following statements are executed in order,
Object d = myObject;
d = null;
is either one or both of d, myObject null?

f. Assume one more time that myObject is a name bound to an object (i.e.,
myObject is not null). After the following statements are executed in order,
Object e = myObject;
myObject = null;
Now which of e, myObject (or neither, or both) is null?
4. Which of the following could legitimately be used as a name in Java?
3PO
R2D2
c3po
luke
jabba_the_hut
PrincessLeia
Han Solo
obi-wan
foo
int
Double
character
string
goto
elsif
fi
5. Assume that the following declarations have been made:
int i = 3;
int j;
char c = '?';
char d = '\n';
boolean b;
String s = "A literal";
String s2;
Object o;

IPIJ || Lynn Andrea Stein

3~24 Things, Types, and Names Chapter 3

Complete the following table:

Name shoebox or label? Value (or null?)

s2

6. Assume that there is an already-defined object type called Date and that today
is an already-defined Date name with a value representing today's date. Declare a
new name, yesterday, and give it the value currently referred to by today. (This
would be useful, e.g., if it were midnight and we might soon want to update the
value referred to by today.)

IPIJ || Lynn Andrea Stein

 4
Chapter 4 Specifying Behavior: Interfaces

Chapter Overview
• How do programs (and people) know what to expect?

• How do I describe a part or property of an entity to other

community members?
This chapter introduces the idea of interfaces as partial program specifications. An
interface lets community members know what they can expect of one another and
what they can call on each other to do; in other words, interfaces specify "how
they interact". In this way, an interface describes a contract between the provider
of some behavior and its user. For example, the post office promises to deliver
your letter to its intended recipient if you give it to them in the appropriate form.
This promise (together with its requirements for a properly addressed and
stamped envelope, etc.) constitutes a part of the post office's interface.
In this chapter, you will learn how to read and write Java interfaces. These allow
you to use code designed by others -- in the same way that you can drop off an
appropriately addressed letter at the post office -- and to tell others how to use the
services that you provide. You will also learn about things that an interface

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
4~2 Specifying Behavior: Interfaces Chapter 4

doesn't tell you. For example, when you drop a letter off at the post office, you
don't necessarily know whether it's going by truck or by train to its destination.
You may not know when it is going to arrive. This chapter concludes with a
discussion of what isn't specified by an interface and how good documentation
can make some of these other assumptions explicit.
This chapter is supplemented by a reference chart on the syntax and semantics of
Java interfaces.

Objectives of this Chapter

1. To learn how to recognize and read Java method signatures.
2. To understand how an interface specifies a contract between two entities
while separating the user from the implementation.

4.1 Interfaces are Contracts

Programs are communities of interacting entities. How does one entity know what
kinds of services another entity provides? How do programmers know what kinds
of behavior they can expect from objects and entities that they haven't built? A
key to understanding these questions is the notion of interface.
An interface is a contract that one object or entity makes with another. Interfaces
represent agreements between the implementor (or builder) of an object and its
users. In many ways, these are like legal contracts: they specify some required
behavior, but not necessarily how that behavior will be carried out. They also
leave open what other things the parties to the contract may be doing.
An excellent example of a standardized interface is an electrical outlet. In the
United States, there is a particular standard for the shape, size, and electrical
properties of wall outlets. This means that you can take almost any US appliance
and plug it in to almost any US wall outlet and rest assured that your appliance
will run. The power company doesn't need to know what you're plugging in --
there are no special toaster outlets, distinct from food processor outlets, for
example -- and you don't need to know whether the power company produced this
electricity through a hydroelectric plant or a wind farm. The outlet provides a

IPIJ || Lynn Andrea Stein

4.1 Interfaces are Contracts 4~3

standard interface, with a particular contract, and as long as you live within the
parameters of that contract, the two sides of the interface can remain relatively
independent.
Of course, there are places where this contract breaks down. US appliances don't
generally work in European outlets, for example. There are several standard
electrical outlet interfaces throughout the world. It isn't clear that one of them is
particularly better than another, but it is unquestionably true that you can't use one
side of the US outlet interface (e.g., a US appliance) with the other side of the
European interface (a 220V outlet). If you want to mix and match disparate
interfaces, you will need a special adapter component. The same is true for
software.

There are also, even in the US, certain appliances that can't use standard wall
outlets. For example, an electric oven draws too much current, and so needs a
special kind of wall outlet. The physical connector -- the plug -- is different on
this appliance, to indicate that it fits a different interface. You can't plug an
electric oven in to a standard US wall outlet. This is because its needs don't meet
the (sometimes implicit) constraints of standard (15 or 25 amp) US circuits.
Sometimes this happens in software, too -- you need a different interface because
the standard one doesn't provide precisely the functionality that you need.

4.1.1 Generalized Interfaces and Java Interfaces

The dictionary defines interface as "the common region of contact between two
independent systems." In Computer Science, we use interface to mean the
boundary between two (or more) things. In general, when you are constructing a
community of interacting entities, interface refers to the "face" that one of these

IPIJ || Lynn Andrea Stein

4~4 Specifying Behavior: Interfaces Chapter 4

entities shows another: what services it provides, what information it expects. One
entity may, of course, have many interfaces, showing different "faces" to different
community members.
Interface is a piece of the answer to the question of how things interact.
User interface refers to the part of a computer program that the person using the
computer actually interacts with. For example, a graphical user interface (GUI)
is one that uses a certain interaction style, e.g., typically contains buttons and
menus and windows and icons. (Before GUIs, computer interfaces typically used
text, one line at a time, the way that some chat programs work now.) A good user
interface takes into account the properties of the program as well as those of
human users. Not surprisingly, humans and computers have different skill sets.
Like user interfaces, every interface should be designed bearing in mind the needs
of the entities on both sides. We will learn more about graphical user interfaces in
particular in Parts 3 and 4 of this book.
This Computer Science use of the word interface is one sense in which we will
use the term in this book. In Java, there is a second, related but much more limited
use of the word interface. A Java interface refers to a particular formal
specification of objects' behavior. The keyword interface is used to specify the
formal declaration of a particular kind of contract guaranteeing this behavior. (For
example, there might be an interface defining clock-like behavior.) The Java
language defines the rules for setting out that contract, including what can and
can't be specified by it. A particular Java interface is a particular promise.
In this book, when we use the term "Java interface" or the code keyword
interface, we are referring to this formal declaration. When we use the term
"generalized interface", we are referring to the more general computer science
notion of interfaces. A Java interface is one way to (partially) specify a
generalized interface. There may be things that are part of the general promise --
such as how long a particular request might take to answer -- that can't be
specified in a Java interface.
This chapter deals specifically with Java interfaces. The ideas of generalized
interfaces permeate all parts of this book; the generalized notion of an interface is
central to interactive program design. We will explicitly revisit this issue --
generalized interface design -- in the chapters on Protocols and Communication in
Part 4 of the book.

4.1.2 A Java Interface Example

Consider, for example, a counter such as appears on the bottom of many web

IPIJ || Lynn Andrea Stein

4.1 Interfaces are Contracts 4~5

pages, recording the number of visitors. Most such counting objects have a very
simple interface. If you have a counting object, you expect to be able to increment
it -- add one to the number that the counting object keeps track of -- or to be able
to read -- or get -- its current value. This is true pretty much no matter how the
counting object actually works or what other behavior it might provide. In fact, by
this description, a stopwatch might be a special kind of counting object that
automatically increments itself. So we might say that increment and getValue
form a useful interface contract specifying what a (minimal sort of a) counting
object might be. In Java, we write this as:
interface Counting // gives the name of the interface
{
void increment(); // describes the increment contract

int getValue(); // describes the get value contract

}
We will see below how to read this interface declaration.
Once you and I agree on an interface for a counting object, I can build one and
you can use it without your needing to know all of the details of how I built it.
You can rely on the fact that you will be able to ask my counting object for its
current value using getValue(). Your code, which uses my counting object,
doesn't need to know whether increment adds one point (for a soccer goal) or six
(for a touchdown in American football). It doesn't need to know whether I
represent the current value internally in decimal or binary or number of
touchdowns, field goals, etc.

Your code should work even if I exchange my original counting object for one
that can be reset before each game or each time I rewrite my web page, since your

IPIJ || Lynn Andrea Stein

4~6 Specifying Behavior: Interfaces Chapter 4

code depends only on being able to increment and read the value of my counting
object. In turn, I can go off and build a counting object using whichever internal
representations I wish to provide, so long as I meet the contract's commitments
(increment() and getValue()).
Of course, you may want to know more about my counting object than what the
increment/getValue interface tells you. Some of this information may be
contained in the documentation for Counting. (This counting object's value will
always be non-negative.) Other information may be contained in the
documentation for my particular implementation. (My BasicCounter Counting
object implementation is guaranteed to increase; its value cannot decrease.) If you
want to know whether my clock provides additional services, though, you may
need to use an interface that specifies this additional behavior (e.g., a Resetable
interface). We will discuss the kinds of information conveyed by an interface, and
that which should be included in interface documentation, later in this chapter.

4.2 Method Signatures

In the StringTransformer interlude and briefly in the discussion of objects, we
have seen methods, behavior that objects provide. These methods are essentially
rules for how to accomplish particular behaviors. In an interface, we focus on the
specifications for these rules and not on the instructions for how to achieve them.
That is, an interface is a collection of rule specifications. Any object that
implements that interface must satisfy those specifications, though there are
virtually no limits on how it might do that.
The formal name for a rule specifications is a method signature. For example,
the Counting interface specifies two rules -- increment and getValue -- that
every counting object must provide. The body of the interface declaration is these
two method signatures, or rule specifications. A method signature describes what
things that rule expects (or needs to know about) and what the rule will return. It
also needs a name, so that you can refer to and invoke the rule (of course). In the
chapter on Exceptions, we will see that there is one other kind of thing that can be
a part of a rule specification.
Unlike the method itself, a method signature does NOT need a body. The body is
the part of the method (or rule) that contains the instructions specifying how to do
the behavior, and that is not a part of the interface/promise. The rule specification

IPIJ || Lynn Andrea Stein

4.2 Method Signatures 4~7

is only that part of the promise that users of the object need to know: what request
to make, what things to give the rule, and what to expect back. The rule body --
how to do the rule -- is only needed by the rule implementor, not by the rule user.
In the particular case of the counting interface, there are two rules that every
counting object must implement: increment and getValue. So the Counting
Java interface would need to specify these two method signatures. Each method
signature has three parts: name, parameter specification, and return type.1
For each of the elements below, we describe both the obligations of the designer
of the interface and the ways in which the interface is used by another entity.

4.2.1 Name
When you are building an interface, a rule can have any name that you want to
give it. It is a good idea to give it a name that will help you (and the users of your
code) remember what it does. Remember the syntax of Java names --
alphanumeric and a few symbolic characters -- and that rule/method names should
start with a lower case letter.
When you are using an interface, the name of the rule is whatever name the
interface says it is. Hopefully, the name was chosen well so that it is easy to
remember and to figure out what that rule does.

4.2.2 Parameters and Parameter Types

These are the things that your rule needs to be able to work. (For example, the
StringTransformer's transform rule needs to know what String to transform.) A
parameter is a temporary name associated with a value supplied when the
method is called, i.e., when the rule that it represents is invoked. During the
execution of the rule, the parameter name can be used to refers to the supplied
value.
When you are designing an interface, you will need to specify a type and a name
for each parameter. (The type-of-thing name-of-thing rule (from the Chapter on
Things, Types, and Names) strikes again.) The type can be any legal Java type

1
There is actually one other part of some method signatures, the throws clause. Every method
signature must have a name, parameter list, and return type, but some methods do not have a
throws clause. The throws clause will be introduced in the chapter on Exceptions. In addition,
certain modifiers -- such as abstract, explained below -- may be included in a method
signature.

IPIJ || Lynn Andrea Stein

4~8 Specifying Behavior: Interfaces Chapter 4

(including both primitive and object types); the name can be any Java-legal name
that you choose to give the parameter. It is advisable that you give your
parameters names that make it easy for the users and implementors of your rule to
figure out what role the particular parameter plays in the rule. Our convention is
to use names that begin with a lower-case letter for parameters.
The list of parameters is separated by commas: type-of-thing name-of-thing, type-
of-thing name-of-thing, and so on until the last type-of-thing name-of-thing which
doesn't have a comma after it. The whole list is enclosed in parentheses. You can
list your parameters in any order. Of course, some orders will naturally make
more sense than others, and although the choice is arbitrary, once chosen the
order is fixed. This means that users and implementors of the method will need to
follow the order declared in the interface.

The getValue and increment rules of Counting don't have any parameters, i.e.,
they don't need any information to begin operation. Their parameter lists are
empty: () StringTransformer's transform rule needs one parameter, a String.
We can call that String anything we want to. For example, transform's
parameter list might be: ( String whatToTransform ).

A more complex AlarmedCounting interface might be mostly like our Counting

interface but in addition have a setAlarm method that takes two parameters, one
an int indicating the value at which the alarm should go off and the other a
String that should be printed out when the alarm is supposed to be sounded.
setAlarm( int whatValue, String alarmMessage )
When you are using a method, you need to pass the method a set of arguments
that match the parameter list. That is, between the parentheses after the name of
the method you're invoking, you need to have an expression whose type matches
the type of the first parameter, followed by a comma, followed by an expression
whose type matches the type of the second parameter, and so on, until you run out
of parameters: increment(), transform( "a string to transform" ), or
setAlarm( 1000, "capacity exceeded" )

4.2.3 Return Type

The rule also needs to specify what its users can expect to get back. In many
cases, the rule returns a value. The return type is then the type of the value
returned. In some cases, the rule does not return a value. (increment is an
example of such a rule: it changes the value stored inside the counting object, but
doesn't give anything back to the entity that invoked it.) The return type of such a
rule is a special Java keyword: void. The only purpose for void is as the return

IPIJ || Lynn Andrea Stein

4.2 Method Signatures 4~9

type of rules that don't return a value. The Counting interface's increment
method presumably doesn't return anything, so its return type would be void. The
return type of the getValue method is presumably int.
When you use a method, you may or may not want to do something with the
value returned. The return type of the method signature tells you what type of
thing you can expect to get back, e.g., so that you can declare an appropriate name
to store the result:
int counterValue = myCounting.getValue();
where myCounting is something that implements the Counting interface, i.e.,
satisfies the Counting contract (and therefore has an int-returning getValue
method). After this statement, counterValue is a name that refers to whatever
int myCounting's getValue method returned.

4.2.4 Putting It All Together: Abstract Method Declaration

Syntax
Now you know about all of the components of a method signature. All you need
to know is how to put them together. The type-of-thing name-of-thing rule comes
into play here as well. The type of a method is its return type, so a method
specification is:
returnType ruleName ( paramType1 paramName1, ... paramTypeN
paramNameN );
For example,
int getValue();
or
void increment();
Note that these declarations end with a semi-colon (;). This means that the
method signature is being used here as a specification -- a contract. It doesn't say
anything about how the method -- say increment -- ought to work. That is, it
doesn't even have a space for the rule body, just the rule specification.
This form -- method signature followed by a semi-colon -- is called an abstract
method. There is even a Java keyword -- abstract -- to describe such methods. It
is OK, if sometimes redundant, to say
abstract void increment();
instead of the form given above. This is different from the use of a method
signature together with its body to define behavior (i.e., in a class declaration).
We will see how to use method signatures in the declaration of classes in the next

IPIJ || Lynn Andrea Stein

4~10 Specifying Behavior: Interfaces Chapter 4

chapter.
Since interfaces always specify only method signatures, interface method
declarations are always abstract. If you don't say so explicitly, Java will still act
like the word abstract is there. However, if your method definition does not end
with a semi-colon, your Java interface will not compile.

4.2.5 What a Signature Doesn't Say

The properties of a method that are documented by its signature are its name, its
parameters, and its return type.2 That leaves a whole lot open.

For example, for each parameter:

• What is that parameter intended to represent?

• What if any relationships are expected to exist among the parameters?

• Are there any restrictions on the legal values for a particular parameter?

• Will the object represented by a particular parameter be modified during

the execution of the method?
For the return type:

• What is the relationship of the returned object to the parameters (or to

anything else)?

• What may you do with the object returned? What may you not do?
Other questions not included in the method signature:

• What preconditions must be satisfied before you invoke this method?

• What expectations should you have after the method returns?

• How long can the method be expected to take?

• What other timing properties might be important?

• What else can or cannot happen while this method is executing?

2
In addition, method signatures may include visibility and other modifiers and any exceptions that
the method may throw.

IPIJ || Lynn Andrea Stein

4.2 Method Signatures 4~11

Not all of these questions are relevant to every method. For example, the precise
amount of time taken by the counting object's getValue method is probably not
important; it is important that it return reasonably quickly, so that the value
returned will reflect the state at the time that the request was made. However, it is
important to recognize that these and other questions are not answered by your
method signatures alone, so you must be careful to document your assumptions
using Java comments.

Style Sidebar

Method Documentation
Documentation for a method should always include the following items:
Why would you want to use this method? What does it do? When is it
appropriate (or not appropriate) to use this method? Are there other
methods that should be used instead (or in addition)? Are there any other
"hidden assumptions" made by this method?
What does each parameter represent? Is it information supplied by the
caller to the method? Is it modified during the execution of the method?
What additional assumptions does the method make about these
parameters?
What does the return value of the method represent? How is it related to the
method's arguments or other Things in the environment? What additional
assumptions may be made about this return value?
What else might be affected by the execution of this method? Is something
printed out? Is another (non-parameter) value modified when it is run?
These non-parameter non-return effects are called side effects.
In addition, if there are other assumptions made by the method -- such as
how long it can take to run or what else can (or cannot) happen at the same
time -- these should be included in the method's documentation.
Java provides additional support for some of these items in its javadoc
utilities. See the appendix on javadoc for details.

IPIJ || Lynn Andrea Stein

4~12 Specifying Behavior: Interfaces Chapter 4

4.3 Interface Declaration

Now that we know all about Java method signatures, it is very easy to declare a
Java interface. A Java interface is simply a collection of method signatures.

4.3.1 Syntax
A Java interface is typically declared in its very own file. The file and the
interfaces generally have the same name, except that the file name ends with
.java. (For example, the Counting interface would be declared in a file called
COunting.java.)

Like most other declarations, an interface follows the type-of-thing name-of-thing

rule. The type-of-thing is, in this case, interface. The name is whatever name
you're giving the interface, if you're declaring it:
interface Counting
Now comes an interface body: an open-brace followed by a set of method
signatures followed by a close-brace. Note that it doesn't matter in which order
the two methods are declared; the two possible orders are equivalent. The whole
thing (including the interface Counting part) looks like this:
interface Counting
{
abstract void increment();

abstract int getValue();

}
That's all there is to it.

Q. In this definition of Counting, the word abstract appears twice. In the

previous definition, above, it doesn't appear at all. Explain.

In fact, that was so easy, let's try another interface. This one is Resetable, and it
is a very simple interface. (Good interfaces often are.) Resetable has a single
method:
interface Resetable
{
abstract void reset();
}
This interface is fine, but it could do with a little bit of documentation. After all,

IPIJ || Lynn Andrea Stein

4.3 Interface Declaration 4~13

there are many things that an interface doesn't specify.

Q. Can you identify some things that should be included in Resetable's

documentation?
For the precise specification of what may be included in an interface definition, in
what order, and under what circumstances, see the Java Chart on Interfaces.

4.3.2 Method Footprints and Unique Names

It might seem that each method in an interface would have a unique name.
However, it turns out that this isn't the case -- at least, not exactly. Instead of a
unique name, each method in an interface (or class) definition must have a unique
footprint. The method's footprint consists of its name plus its ordered list of
parameter types. Only the ordered list of parameter types counts; the return type
of the method, and the names given to the parameters, are not relevant to its
footprint.

For example, a reset() rule with no parameters (an empty parameter list, () )
has a different footprint from a reset( int newValue ) rule (with the parameter
list (int) ), and both are different from reset( String resetMessage )
(parameter list (String) ). Only the parameter type matters, though, not the
parameter names: reset( String resetMessage ) is the same as reset(
String whatToSay ).

As long as two methods have different footprints, they can share the same name.
This is very common and even has its own name: overloading. Overloading
allows an object to have two (or more) similar methods that do slightly different
things. For example, there are two very similar mathematical rounding methods.
One has the signature
int round( float f );
while the other has the signature
long round( double d );
The Math object has both of these methods, and if you pass Math.round a float,
you get back an int, while if you pass it a double, you get back a long. This is
very convenient -- in both cases, a floating point number is converted to an
integer, but in either case the more appropriate size is used.
An alternate kind of overloading might happen if our hypothetical
AlarmedCounting interface had, in addition to its
void setAlarm( int whatValue, String alarmMessage )

IPIJ || Lynn Andrea Stein

4~14 Specifying Behavior: Interfaces Chapter 4

method, a second method that just allowed you to specify the alarm message,
without changing the value for which it was set:
void setAlarm( String alarmMessage )
If you called yourAlarm.setAlarm( 1000, "Capacity reached" ), you'd set
the alarm message to trigger at 1000, printing the message "Capacity reached".
yourAlarm.setAlarm( "Oops, all full" ) might then be used when to
change the warning to be issued when the AlarmedCounting reaches capacity.
Overloading method names is the choice of the interface builder. The interface
user simply makes use of the interface as it is given.

4.3.3 Interfaces are Types: Behavior Promises

Now that we have these interfaces, what good do they do? Interfaces are kinds of
Things: they are Java types.
In Java, every interface name is automatically a type name. That is, when you are
declaring a (label) name, you can declare it suitable for labeling things that
implement a specific interface. In the next chapter, we will see how to declare
Java classes and how to indicate what interface(s) the class implements.

So, for example, the declared type of myCounting, above, was Counting:
Counting myCounting;
In this example, myCounting is declared to be of type Counting, i.e., something
that satisfies the Counting contract (interface) that we declared in the preceding
sections. For example, we might have an interface called Game that includes a
getScoreCounter() method that returns a Counting:
interface Game
{
abstract Counting getScoreCounter();
// maybe some other method signatures....
}
If theWorldCupFinal is a Game, then we might say
Counting myCounting = theWorldCupFinal.getScoreCounter();
In this case, we don't know anything more about the type of myCounting ; we just
know that it is a Counting. Often, as users of other people's code, interfaces are
the only types we need to know about.

IPIJ || Lynn Andrea Stein

4.3 Interface Declaration 4~15

4.3.4 Interfaces are Not Implementations

We have seen that an interface can be used as the type of an object. You can use
names associated with that type to label the object. You can pass objects
satisfying that interface to methods whose parameter types are that interface type,
and you can return objects satisfying that interface from a method whose return
type is that interface. The Counting in the previous paragraph was an example of
the power of interfaces.
However, there are certain things that you cannot do with an interface.

Of course, when we're manipulating that Counting object, we don't know

anything about how it works inside. We don't know, for example, whether it has a
touchdown part and a field goal part, or is represented in decimal or in binary, or
is likely to keep going up while we're thinking about it (since players might keep
scoring). To figure this out, we'd need to know more than just the interface -- the
contract -- that it satisfies; we'd need to know how it is implemented.
Interfaces are about contracts, promises. They don't, for example, tell you how to
create objects that satisfy those promises. In the next several chapters, we'll learn
about building implementations that satisfy these promises and about creating
brand new objects that meet these specifications. To do that will require
additional machinery beyond the contract/promise of an interface.

IPIJ || Lynn Andrea Stein

4~16 Specifying Behavior: Interfaces Chapter 4

Style Sidebar

Interface Documentation
An interface should be properly documented, typically using a multi-line or
javadoc comment immediately preceding its declaration.
Documentation for an interface should include the following information:
What kind of thing does this interface represent? Why would you want to
use an object of this kind? What could it do for you? What could you do
with it?
What kinds of assumptions or conditions does this kind of object need to do
its job? Are there any special objects that it might need to have around or to
work with?
What services does this kind of object provide, and how do you use them?
These questions are typically answered by the individual methods, but a
brief overview of what methods the interface provides is always useful. It is
may also be useful for the interface to document which method(s) to use
when, especially when multiple similar methods exist.
The interface's documentation should make it easy for a potential user to
find the method(s) s/he wants. It should also make it possible for someone
seeking to implement this interface to determine whether s/he has met the
intent as well as the formal specification of the interface. If I am building a
stopwatch, do I want to subscribe to the Clock interface?
Remember that an interface declaration is largely about what, not how. It
specifies contracts and promises, not mechanism.
Java provides additional support for some of these items in its javadoc
utilities. See the appendix on javadoc for details.

IPIJ || Lynn Andrea Stein

 Summary 4~17

Chapter Summary
• An interface is a contract that a particular kind of object promises to keep.

• Java interfaces are Java types.

• Every (public) interface must be declared in a Java file with the same
name as the interface.

• Java interfaces contain method signatures.

• A method signature specifies a method's name, parameter types, and

return type. It does not say anything about how the method actually works.

• A method signature is also called an abstract method.

• One interface may have multiple methods with the same name, as long as
they have different ordered lists of parameter types. Method name plus
ordered parameter type list is called the method's footprint.

• An interface does not contain enough information to create a new object,

though it can be used as a type for an existing object (that implements the
interface's promises).

• Many important properties of a method specification or interface are not

specified by the method or interface declaration. Good documentation
describes these additional assumptions.

Exercises
1. StringTransformer has a transform method. Declare an interface, Transformer,
that contains this single method specification, so that StringTransformer might be
an implementation of this interface.

2. A Clock is an object that needs a method to read the time (say, getTime) and
one to set the time (say setTime). Assuming that you have a type Time already,
write the interface for a Clock.

IPIJ || Lynn Andrea Stein

4~18 Specifying Behavior: Interfaces Chapter 4

3. Extend the interface of Clock (from the previous exercise) to include a

setAlarm method (that should specify the Time at which the alarm should go off.
4. Extend the Clock interface further so that there is a second setAlarm method
that takes a Time and a boolean specifying whether the alarm should be turned on.
5. Write the interface AlarmedCounting.
6. Consider the following interface:
interface Game
{
/* returns the Counting that keeps track of the team's
score */
abstract Counting getScoreCounter;

/* returns the Counting that keeps track of how many

fouls */
/* each player has committed */
abstract Counting getFoulCounter( int playerNumber );

/* returns the counting that keeps track of how much

time */
/* has passed in the period so far */
abstract AlarmedCounting getTimeCounter();

/* returns the length of a period */

abstract int getPeriodLength();
}
Assume that theWorldCup is a particular Game, according to this interface.

a. Write a type declaration for the name theWorldCup. Don't worry about
where its value comes from.
b. Write a type declaration
suitable for holding the result of
theWorldCup.getTimeCounter().

c. Write an expression that returns the object that counts player 5's fouls.

d. Write an expression that returns the current score of theWorldCup.

e. Write a method invocation that sets up theWorldCup (and its internal
representation) so that it will print "Period over!" when the elapsed time
reaches the length of the period.

IPIJ || Lynn Andrea Stein

 5
Chapter 5 Expressions: Doing Things With Things

Chapter Overview
• How do I use the Things I have to get new (or other) Things?
This chapter and the next introduce the mechanics of executable code, the
building blocks for individual sequences of instruction-following. The previous
chapter's Things each come with a Type, which specifies how that Thing can
interact. An expression is a piece of code that can be evaluated to yield a value
and a type
Simple expressions include literals -- Things that java literally understands as you
write them -- and names, which stand in for the Things they refer to. More
complex expressions are formed by combining other Things according to their
types, or promised interactions.
To understand a complex expression, you must understand its parts (a basic form
of "what goes inside") and how they are combined (a basic "how they interact").
Sometimes, you have to understand this without knowing all of the details of
what's inside.
Sidebars in this chapter cover details of various Java operators, including casts
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
5~2 Expressions: Doing Things With Things Chapter 5

and coercion rules. In addition, supplementary reference charts are provided

outlining the syntax and semantics of Java expressions.

Objectives of this Chapter

1. To understand that an expression is a piece of java code with a type and a
value.
2. To become familiar with the rules of evaluation for basic Java expressions.
3. To learn how to understand complex expressions as combinations of
simpler expressions.

4. To be able to evaluate both simple and complex expressions.

5.1 Simple Expressions

An expression is the simplest piece of Java code. An expression is a Thing, so it
has both a value and a type. An instruction-follower--an execution of Java code--
evaluates an expression to obtain its value, which will always be of the
expression's type. There are many kinds of expressions, and each has its own rules
of evaluation that determine what it means for an instruction-follower to evaluate
that expression. Legitimate Java expressions include 2 + 2, "Hi, there", and
this.out.writeOutput( this.in.readInput() ). The last of these is an
expression whose evaluation involves inter-object (and inter-entity)
communication.

5.1.1 Literals
The very simplest Java expression is a literal: an expression whose value is
interpreted literally, such as 25 or 32e-65 or "How about that?". Java literals
include the various kinds of numbers, characters, Strings, and booleans. For a
more complete enumeration of literal expressions and rules regarding their syntax
(i.e., how you write them), see the sidebar on Java Primitive Types, above.
Every expression has a value and a type, obtained by evaluating the expression.
The value of a literal is its prima facie value, i.e., what it appears to be. The type
of an expression is the type of its value. Integer literals are always of type int
unless an explicit type suffix (l, s, or b) is included in the literal. Non-integral

IPIJ || Lynn Andrea Stein

5.1 Simple Expressions 5~3

numeric literals are always of type double unless explicitly specified to be of type
float (using the f suffix).

5.1.2 Names
Names are also Java expressions. A name is only a legitimate expression once it
has been declared, i.e., within its scope.1 The value of that name is the value
currently associated with it -- i.e., stored in the shoebox if it is a shoebox name, or
labeled by it if it is a label name. The type of a name expression is always the type
associated with that name at the time of its definition.2

For example, if we are within the scope of a declaration that says

int myFavoriteNumber = 4;
and nothing has occurred to change the value associated with (stored in the
shoebox called) myFavoriteNumber, then the value of the expression
myFavoriteNumber
is 4 and its type is int. That is, the int 4 is the result of evaluating
myFavoriteNumber.

5.2 Method Invocation

Method invocation is the primary way in which one object asks another to do
something. It is the primary basis for inter-entity communication and interaction,
because it is the main way in which objects talk to one another.
We have seen in previous chapters that objects are able to perform certain
services. These service requests are called methods, and asking an object to do

1
Strictly speaking, the area of text within which a name is legal is called its scope. The scope of a
variable -- a name with no special properties beyond being a name -- begins at its declaration and
extends to the end of the enclosing block. (See blocks, below.) Later, we will see three other kinds
of names: classes, fields and parameters. Class names have scope throughout a program or
package; they may be used anywhere. Field names have scope anywhere in their enclosing class,
including textually prior to their declaration. Parameter names have scope throughout their method
bodies only.
2
Note that the type of a name expression is the declared type of the name rather than the type of
the value associated with the name. That is, even where there is disagreement between the
declared type of a name and its value, the type of a name expression is always its declared type.

IPIJ || Lynn Andrea Stein

5~4 Expressions: Doing Things With Things Chapter 5

something is called method invocation. In Java, a method invocation involves:

• An expression whose value is the object to whom the request is directed,

followed by

• A period (or "dot"), followed by

• The name of the method to be invoked, followed by

• Parentheses, within which any information needed by the method request

must be supplied.
An example method invocation might be
"a test string".toUpperCase()

This example consists of a String literal expression ( "a test string") and a
request to that object to perform its toUpperCase() method. A String's
toUpperCase() method doesn't require any additional information, so the
parentheses are empty. (They can't be omitted, though!) The value of a String's
toUpperCase() method is a new String that resembles the old one, but contains
no lower case letters. So the value of this expression is the same as the value of
the literal expression "A TEST STRING".
Another example of method invocation is
Console.println( "Hello" )

This asks the object named by the name expression Console to print the line
supplied to it. It requires that a String -- the line to be printed -- be supplied inside
the parentheses. This is "necessary information" is called an argument to the
method.

What is the value of this method invocation expression? Console.println(

"Hello" ) is a method invocation whose primary use, like that of assignment, is
for its side effect, not its value. We use this method to make something appear on
the user's screen. Good style dictates that we wouldn't use this expression inside
any other expression. It turns out that many methods have no real return values, so
(as we saw in the previous chapter) there's a special Java type for use on just such
occasions. This type is called void. It is only used for method return types, and it
means that the method doesn't return anything.
The evaluation rule for a method invocation expression is as follows:
1. Evaluate the object expression to determine whose method is to be

IPIJ || Lynn Andrea Stein

5.2 Method Invocation 5~5

invoked.
2. Evaluate any argument subexpressions.
3. Evaluate the method invocation by asking the object to perform the
method using the information provided as arguments.
4. The value of the expression is the value returned by the method
invocation. The type of the method invocation expression is the declared
return type of the method invoked.
In order for step 3 to work, the object must know how to perform the method, i.e.,
it must have instructions that can be followed in order to produce the return value
needed in step 4. We have already seen how an interface can describe an object's
commitment to provide such behavior. We will see in the next chapters how this
may be accomplished in detail.
From the perspective of the method invoker, however, the transition from step 3
to step 4 happens by magic (or by the good graces of the object whose method is
invoked). The object offers the service of providing a particular method requiring
certain arguments and returning a value of a particular type. For example, if we
look at the documentation (or code) for String, we will see that it has a
toUpperCase() method that requires no arguments and returns something of type
String. The println method of Console requires a String as an argument, and
println's return type is void. We will learn more about the methods that objects
provide the chapters on Classes and Objects and Designing with Objects.

5.3 Combining Expressions

Since expressions are things -- with types and values -- expressions can be
combined to build more complicated expressions. For example, the expression
"serendipitous".toUpperCase() has the type String and the same value as
the literal "SERENDIPITOUS". That is, you can use it anywhere that you could use
the expression "SERENDIPITOUS". So, for example, you could get an adverbial
form of this adjective by using "serendipitous".toUpperCase() + "LY",
producing " SERENDIPITOUSLY", or extract the word "REND" using
"serendipitous".toUpperCase().substring(2,5).

In general, since every expression has a type, you can use the expression
wherever a value of that type would be appropriate. The exception to this rule
about reuse of expressions is that some expressions are constant -- their value is

IPIJ || Lynn Andrea Stein

5~6 Expressions: Doing Things With Things Chapter 5

fixed -- while other expressions are not. Some contexts require a constant
expression. In these cases, you cannot use a non-constant expression of the same
type. (For example, "to"+"get"+"her" is a constant expression, but
3
str+"ether" is (in general) not, even if str happens to have the value "tog". )
There are a few places where Java requires a constant value. These will be noted
when they arise.
The evaluation rule for a compound expression is essentially the same as the
evaluation rules for the expressions that make it up: Evaluate the subexpressions
that make up this expression, then combine the values of these subexpressions
according to the evaluation rule for this expression. For example, when we
evaluate "serendipitous".toUpperCase(), we are actually evaluating the
simpler (literal) expression "serendipitous", then evaluating the method
invocation expression involving "serendipitous"'s toUpperCase() method.
Similarly, str + "ether" evaluates the (name) expression str and the (literal)
expression "ether", and then combine these values using the rules for +
expressions, detailed below. In this case, str and "ether" are subexpressions of
str + "ether". There are two additional details: 1) Evaluating the
subexpressions may itself involve several evaluations, depending on how complex
these expressions are and 2) it may not always be clear which operation should be
performed first.
Method invocation, like other expressions, can be used to form increasingly
complex expressions. For example, we can combine two method invocations we
used above to cause the value of "A TEST STRING" to appear on the user's screen:
Console.println( "a test string".toUpperCase() )

In this case, the value of the toUpperCase() invocation is used as an argument to

println. We can also cascade other kinds of expressions, such as
"This is " + "a test string".toUpperCase()

or
Console.readln().toUpperCase()

3
The expression str+"ether" would be constant if str were declared final, though. Names
declared to be final cannot be assigned new values.

IPIJ || Lynn Andrea Stein

5.4 Assignments and Side-Effecting Expressions 5~7

5.4 Assignments and Side-Effecting Expressions

Another kind of operator is assignment. We have already seen some simple
assignments -- including some that were mixed with declarations and buried
inside definitions. An assignment is actually a kind of expression. Its first operand
-- the expression on the left-hand side -- must be a name or another expression
that can refer to a shoebox or a label. In this context, and in this context only, the
name expression refers to the shoebox or label, not to the particular value
currently associated with the name.
Like all expressions, every assignment has a type and returns a value. The type of
an assignment is the type of its left-hand side. The value of an assignment
expression is the value assigned to the left-hand side. For example, the type of the
expression
myNumber = 4563129

is int, because the type of 4563129 is int, and the value is 4563129 for the same
reason.

Note that we must have declared myNumber before we get to this expression; and
that this expression is legitimate if myNumber has type int, long, float, or
double. Note, also, that if myNumber were already declared, we wouldn't want to
declare it again. Every time that you declare a name, it creates a brand new
shoebox or label with that name.
Although assignments are expressions in Java, they are not generally used for the
resulting value. Instead, an assignment statement is generally used because it will
cause the shoebox or label on its left-hand side to be associated with a new value.
This effect is not a part of the value of the expression; instead, it happens "on the
side" and is called a side effect. Assignment statements are among the most
common expressions used for their side effects, but we will see several other
expressions with important side effects in the remainder of this chapter.

IPIJ || Lynn Andrea Stein

5~8 Expressions: Doing Things With Things Chapter 5

Style Sidebar

Don't Embed Side-Effecting Expressions

When you use a side-effecting expression, it is best if this expression is not
a subexpression of any other expression. So, for example, while
assignments--as expressions--can be used inside other expressions, it is
generally considered bad style to do so. Embedding side-effecting
expressions inside other expressions can make the logic of your code very
difficult to follow. Side effects are also important and often difficult to
catch. By highlighting the side effecting expression by making it the
outermost expression, you are increasing the likelihood that it will be read
and understood.

5.5 Other Expressions that Use Objects

We have already seen method invocation, perhaps the most common object
expression. In this section, we cover three additional expressions that use objects:
field access, instance creation, and type membership. Each of these kinds of
expressions will be discussed further when we explore how objects are actually
created, beginning in the chapter on Classes and Objects.

5.5.1 Fields
In addition to methods, objects sometimes have fields: data members that behave
as names. That is, fields are either shoeboxes or labels. Like methods, fields are
also accessed using the dot syntax, but without following parentheses. A field
access expression is essentially a name expression, though a more complex one
than the simple names described above. The value of a field access expression is,
as for a simple name, the value associated with the shoebox or label. So, for
example, Math.PI is a double shoebox, belonging to an object called Math,
containing a value approximating a real number whose most significant digits are
3.14159.

We can use field invocations in compound expressions, too. If myWindow is a

Window with a getSize() method that returns a Dimension,
myWindow.getSize().height first asks myWindow to perform its getSize()
method, resulting in a particular Dimension object, then asks the Dimension
object for its height field. This compound expression is the same as first creating a

IPIJ || Lynn Andrea Stein

5.5 Other Expressions that Use Objects 5~9

name for the Dimension and assigning it the result of the method invocation:
Dimension mySize = myWindow.getSize();

and then asking the newly named Dimension mySize for its height field.
Because field access expressions are actually name expressions, they also have
special behavior in the specific context of the target of an assignment statement.
That is, you can assign to a field access expression just as you would to a simple
name, and the field access expression behaves like the shoebox or label to which
it refers. For example, if height is an int shoebox owned by mySize, the
expression
mySize.height = mySize.height / 2

halves the value contained in the height shoebox of mySize, which might shrink
mySize vertically by half.

5.5.2 Instance Creation

A second object-related expression is the new expression, used with a class name
to create a new object. The details of this expression type are covered in the
chapter on Classes and Objects; for now it is enough to recognize it. A new
expression has three parts: the keyword new, the class name, and a (possibly
empty) list of arguments, enclosed in parentheses. This description of how to
write an expression is called its syntax, and we can abbreviate it as:
new ClassName ( argumentList )

The words in italics -- ClassName and argumentList -- are placeholders to

indicate that you need to supply the details. The rest of the expression -- new and
the parentheses -- are to be taken literally. For example,
new File ( "myData" )

creates a new File object with external (outside of Java) name myData. Like all
other expressions, this one has a type -- ClassName, the kind of object created, in
this case File -- and a value -- the new object created. The new expression is
typically used inside an assignment or method invocation.
The rules of evaluation for creation expressions are similar to the rules of
evaluation for method invocation. The return value is always a new instance of
the type (or class) whose instance creation expression is invoked (in this case,
File). The return type is always the type whose instance creation is invoked.

IPIJ || Lynn Andrea Stein

5~10 Expressions: Doing Things With Things Chapter 5

Instance creation is a side effecting expression (since it creates a new object).

5.5.3 Type Membership

There is one last operator that is useable only with objects. This is an operator
called instanceof, which checks whether an object has (or can have) a certain
type. It takes two operands:
anObjectExpression instanceof ObjectTypeName

The first operand, which precedes the keyword instanceof, can be any
expression whose value is of any object (non-primitive) type. The second
operand, which follows the keyword instanceof, must be the name of an object
type. As we shall see in the next few chapters, this name may be the name of any
class or any interface.
The instanceof operator is used to determine whether it is appropriate to treat its
first operand according to the rules of the type named by its second operand. (For
example, is it appropriate to cast the object to this type?) The value of an
instanceof expression is a boolean, true if it is appropriate to treat the object
according to this type, false otherwise. So, for example,
"a String" instanceof String

has the value true (because "a String" is a (literal) instance of the type String),
while
new Object() instanceof String

has the value false (because the new Object created by the instance creation
expression new Object() is not a String.

5.6 Complex Expressions on Primitive Types: Operations

Perhaps the most common kind of expression on primitive types is made up of
two expressions combined with an operator. Java operators are described in the
sidebar on Java Operators. They include most of the common arithmetic operators
as well as facilities for comparisons, logical operations, and other useful
functions. Of special note are + for String concatenation and unary - for negation.
Each operation takes arguments of specified types and produces a result with a
particular value and type. For example, if x and y are both of type int, so is x +

IPIJ || Lynn Andrea Stein

5.6 Complex Expressions on Primitive Types: Operations 5~11

y. The + operator can be used to combine any two numeric types. The two things
combined with the operator are called the operands. In the expression x + y, + is
the operator and x and y are the operands. Some operators take two operands.
These are called binary operations. Other operators take only one operand; these
are the unary operations. One operator -- ?: -- takes three operands.

IPIJ || Lynn Andrea Stein

5~12 Expressions: Doing Things With Things Chapter 5

Java Operators
Java operators include
+ - * / | & ^ % << >> >>>
+= -= *= /= |= &= ^= %= <<= >>= >>>=
< > <= >= == != ! && || ++ --
= ?:
The operators in the first row are, respectively, addition, subtraction,
multiplication, division, bitwise or, bitwise and, bitwise negation, modulus,
left-shift, sign-extended right-shift, and zero-extended right-shift. Addition
is also used for String concatenation when at least one of its arguments is a
String. Subtraction can also be used as unary (one-argument) negation.
The operators in the second row combine their correlate in the first with an
assignment operation. Thus x += 2 is the same as x = x + 2; the
difference is that the left-hand side of the combined operator is evaluated
only once. The value of an operator assignment expression is the new value
of the left-hand side; the type is the type of the left-hand side. All
assignment expressions modify the name that is their left-hand side.
The third row above begins with six comparisons, each of which returns a
boolean. The final comparison is not-equal. These are followed by logical
negation, logical conjunction (and), and logical disjunction (or). Each of
these takes boolean arguments, one in the case of negation, two in the case
of conjunction and disjunction, and returns a boolean.
The final operators in the third row are autoincrement and autodecrement.
These can be used as either prefix or postfix operators. Both ++x and x++
modify x, leaving it incremented. However, ++x returns the incremented
value of x, while x++ returns the unincremented value. The -- operator
works similarly.
The final two operators are simple assignment (which works like the
compound assignments, above) and the ternary (three-operand) expression
conditional.

5.6.1 Arithmetic Operation Expressions

The operator + is an example of a kind of operator called an arithmetic operator.
The rules for evaluation of the binary arithmetic operators +, -, *, /, and % are

IPIJ || Lynn Andrea Stein

5.6 Complex Expressions on Primitive Types: Operations 5~13

simple: compute the appropriate mathematical function (addition, subtraction,

multiplication, division, and modulus, respectively), preserving the types of the
operands. As explained in the sidebar on Java Operators, type op type has type
type for all of the basic arithmetic operations on most of the primitive type: For
these arithmetic operators, if the types of the two operands are the same, the result
-- the value of the complete expression -- will generally also be of that type. For
example, evaluating 3 + 7 yields the int 10; 2.0 * 5.6 evaluates to produce
11.2, and -- perhaps surprisingly -- 5 / 2 evaluates to 2, not 2.5 (or 2.0).
Sometimes, an operator needs to treat one of its operands as though it were of a
different type. For example, if you try to add 7.4 (a double) and 3 (an int), Java
will automatically treat the int 3 as though it were the equivalent double, 3.0.
This way, Java can add the two numbers using rules for adding two numbers of
the same type. This kind of treating numbers -- or other things -- as though they
had different type is called coercion. Coercion does not actually change the thing,
it simply provides a different version (with a different type). For shoebox types,
this version is essentially a copy. For label types, it is another "view" of the same
object. Coercion is described more fully in the sidebar on Coercion and Casting.

Other arithmetic operators work in much the same way as +. Additional

information on arithmetic expressions is summarized in the sidebar below. Note
in particular that / (the division operator) obeys the same type op type is type rule.
This means that 7 / 2 has type int (and the value 3). If you want a more precise
answer -- 3.5 -- you can make sure that at least one operand is a floating point
number: 7.0 / 2 has type double, as does 7 / 2.0.
In addition to the binary (two-argument) arithmetic operators described above,
Java includes a unary minus operator that takes one argument and negates it. So -
5 is an integer, while - 5 is an arithmetic expression that has value -5 and type
int. (Subtle, no?)

IPIJ || Lynn Andrea Stein

5~14 Expressions: Doing Things With Things Chapter 5

Arithmetic Expressions
Arithmetic expressions include the binary operators for addition (+),
subtraction (-), multiplication (*), division (/), and the modulus or
remainder operation (%). In addition, there are two unary arithmetic
operators, + and -.

Arithmetic operations work only with values of type int, long, float, or
double. When a (unary or binary) arithmetic expression is invoked with a
value of type short, byte, or char, Java automatically widens that operand
to int (or to a wider type if the other operand so requires). For further
details on widening, see the sidebar on Coercion and Casting.
When the operands of a binary arithmetic expression are of the same type,
the complete expression also has that type, except that no binary arithmetic
expression has type short, byte, or char. This is because operands of
these types are automatically widened.
When the operands are of different types, Java will automatically widens
one to the other.

The values of the expressions involving the binary operators +, -, *, and /

are the sum, difference, product, and quotient of their (possibly widened)
operands, respectively.

The value of x % y is the (appropriately widened) remainder when x is

divided by y.

The value of a unary - expression is the additive inverse of its (possibly

widened) operand; a unary + expression has the value of its (possibly
widened) operand.

5.6.2 Explicit Cast Expressions

If the numbers you wish to divide -- or otherwise combine -- are not literals, you
can still change their types using an explicit cast expression (as described in the
sidebar on Coercion and Casting). Like coercion, this gives you a view of the
thing cast as a different type. It is accomplished by putting the name of the type
that you wish the thing to have in parentheses before the (expression representing
the) thing. For example, if myInt is an int-sized shoebox holding the value 3,

IPIJ || Lynn Andrea Stein

5.6 Complex Expressions on Primitive Types: Operations 5~15

(long) myInt is a view of 3 as a long and (double) myInt is an expression

with the same type and value as the literal expression 3.0. Throughout this, myInt
itself remains an int-sized shoebox holding the value 3.
Evaluating a cast expression yields the value of the cast operand (in this case,
myInt), but with the type of the explicit cast (in this case, long). A cast
expression does not alter its operand in any way; it simply yields a new view of an
existing value with a different type. Some casts are straightforward and
appropriate; some risk losing information; and most are simply not allowed. For
example, in Java you cannot cast an int to boolean. Casts are also allowed from
one object type to another under certain circumstances. See the sidebar on
Coercion and Casting for further details.

IPIJ || Lynn Andrea Stein

5~16 Expressions: Doing Things With Things Chapter 5

Coercion and Casting

Sometimes things don't have the types we might wish. Coercion is the
process of viewing a thing as though it had a different type. Coercion does
not change the thing itself; it merely provides a different view.
Java only makes certain automatic -- implicit -- coercions. For example,
Java knows how to make byte into short, short into int, int into long,
long into float, and float into double. This works because each type
spans at least the magnitude range of the ones appearing before it in the list.
(A few of these coercions-- such as long to float -- may lose precision.)
These coercions -- which are, in general, information-preserving -- are
called widening. We will see in the chapter on Objects and Classes that
there are also widening coercions on reference types.
Coercions in the opposite direction are called narrowing. Java does not
generally perform narrowing coercions automatically. For example, Java
cannot automatically convert an arbitrary int to a short, because the int
might contain too much information to fit into a short. The number 60000
is a perfectly legitimate value for an int, but not for a short. There is no
mapping from ints to shorts that accurately captures the magnitude
information in each possible int. A coercion of this kind -- such as int to
short-- which may not preserve all of the information in the original
object, is called lossy.4
Sometimes, you need to change the type of an object when Java will not do
so automatically. This is accomplished by means of an explicit cast
expression. The syntax of a cast expression is

(type-name) expression to be cast

For example, if myInt is a name of type int with value 7 (e.g., int myInt
= 7;), then

(long) myInt

4
There is one instance in which Java performs a narrowing but non-lossy coercion automatically.
This is in the case of a sufficiently small int constant assigned to a narrower integer type. This
allows literals-- which would otherwise have type int -- to be assigned to names with byte and
short type: short smallNumber = 32;

IPIJ || Lynn Andrea Stein

5.6 Complex Expressions on Primitive Types: Operations 5~17

is an expression with type long and value 7. (Note that myInt still has type
int. Casting, like implicit coercion, does not actually modify the castee.)
Explicit coercion allows both widening and narrowing coercions: you can
cast an int to long, as in the example above, or to short -- a cast that may
lose information. Certain casts may be illegal and will cause (compile- or
run-time) errors or exceptions.

5.6.3 Comparator Expressions

Not all operators are arithmetic. There is a set of boolean-yielding operators,
sometimes called comparators, that operate on numeric types. These include <,
<=, ==, etc. (See the sidebar on Java Operators for a complete list.) These take two
numbers, coerce appropriately, and then return a boolean indicating whether the
relationship holds of the two numbers in the order specified. For example, 6 >
3.0 is true, but 5 <= 3 is false. Beware: == tests for equality; = is the
assignment operator (see below) .
Equality testing -- the operators == and != -- are not restricted to numeric types.
For any type, these operators combine two expressions of the same type, returning
true only of both operands are the same. When are two operands the same? For
primitive types, values are the same whenever they "look" the same, i.e., when
their values are indistinguishable. For object types, values are the same exactly
when the two expressions refer to the same object. It is not sufficient for two
objects to look alike (as in the case of identical twins); they must actually be the
same object, so that modifications to one will necessarily be reflected in the other.
(This is like giving one twin an haircut as we did in the chapter on Things, Types,
and Names.)
Evaluating one of these expressions is much like evaluating an arithmetic
expression. The values of the operands are compared using a rule specific to the
operator -- such as > or <= -- and the resulting boolean value is the value of the
expression.

5.6.4 Logical Operator Expressions

Another set of operators combines booleans directly. These include &&
(conjunction, or "and") and || (disjunction, or "or"). For example, the

IPIJ || Lynn Andrea Stein

5~18 Expressions: Doing Things With Things Chapter 5

expression true || false is true. While this is not very interesting by itself,
these boolean operators can be used with names (of type boolean, of course) or in
complex expressions to great effect. For example, rainy || snowy might be a
reasonable way to express bad weather; it will (presumably) have the value true
exactly when it is precipitating. There is also a unary boolean negation operator:
!. The Java fragment

!(rainy || snowy || overcast)

might be a good expression for sunshine.

The rule for evaluating negation is simply to invert the boolean value of its
operand. The rules for evaluating conjunction and disjunction are a bit more
complex. First, the left operand is evaluated. If the value of the expression can be
determined at this point (i.e., if the first operand to a conjunction is false or the
first operand of a disjunction is true), evaluation terminates with this value.
Otherwise, the second operand is evaluated and the resulting value computed. The
type of each of these expressions is boolean.
These odd-seeming rules are actually quite useful. You can exploit them to insert
tests. For example, you might want to compute whether (x / y) > z, but it might be
the case that y is 0. By testing whether (y == 0) || (( x / y ) > z ), you can eliminate
the potential divide-by-zero error. (If y is 0, the first operand to the disjunction -- (
y == 0 ) -- will be true, so evaluation will stop and the value of the whole will be
true. (A comparable formula can be written to return false if either y is 0 or ( x / y
) > z.)

5.7 Parenthetical Expressions and Precedence

A parenthetical expression is simply an expression wrapped in a pair of
parentheses. The value of a parenthetical expression is the value of its content
expression, i.e., the value of the expression between the ( and the ). The type of a
parenthetical expression is the same as the type of the expression between the
parentheses. Parenthetical expressions are extremely useful when combining
expressions. For example, in the previous section, we mentioned that

"I have " + x + 3 + " monkeys"

might yield 63 monkeys. We could fix this by rewriting the expression as

"I have " + (x + 3) + " monkeys"

IPIJ || Lynn Andrea Stein

5.7 Parenthetical Expressions and Precedence 5~19

This isolates x + 3 as a separate expression, making the + in x + 3 behave like

addition, not String concatenation.
Note that, in giving the evaluation rules for expressions, white space doesn't
matter -- x >= 2 + 3 is identical to x >=2 + 3 -- but punctuation does. For
example, 2+3*2 doesn't have the same value as 5*2 -- 2+3*2 is 8. We can use
parentheses to fix this, though: (2+3)*2 is 10 again. In this case, parentheses
change the order of evaluation of subexpressions (or, equivalently, how the
expression is divided into subexpressions.) In the case of 2+3*2, if you evaluate
the + first, then the *, you get 5*2, while if you evaluate the * first, you get 2+6.
How do you know which way an expression will be evaluated? In these situations,
where one order of operation would produce a different answer from another, we
fall back on the rules of precedence of expression evaluation. In Java, just as in
traditional mathematics, * and / take precedence over + and -, so 2+3*2 really is 8.
(Another way of saying this is that the * is more powerful than the +, so the *
grabs the 3 and combines it with the 2 before the + has a chance to do anything.
This is what we mean when we say that * has higher precedence than +: it claims
its operands first.)
A full listing of the order of precedence in Java is included in the sidebar on Java
Operator Precedence. Parentheses have higher precedence than anything else, so it
is always a good idea to use parentheses liberally to punctuate your expressions.
This makes it far easier for someone to read your code as well.

IPIJ || Lynn Andrea Stein

5~20 Expressions: Doing Things With Things Chapter 5

Java Operator Precedence

Expressions with multiple subexpressions are evaluated according to the
rules of Java precedence. The following chart gives the rules for order of
evaluation of Java expressions, with the expression types listed higher
having higher priority, i.e., being evaluated first.
Operators in the table below are grouped by equivalent precedence. Within
these groups, order of evaluation of an expression is from left to right in
that expression.
Since an expression cannot be evaluated until its subexpressions have been,
precedence determines the extent of operands to each operator, i.e., what
the operand subexpressions of an operator are.

++, --, +, -, ~, !, explicit cast

*, /, %

+, -

<<, >>, >>>

<, <=, >, >=, instanceof

==, !=

&

&&

||

?:

= and all compound assignments

IPIJ || Lynn Andrea Stein

5.7 Parenthetical Expressions and Precedence 5~21

Other Assignment Operators

Compound Assignment
Java has several variants on the simple assignment statement. If we have
already declared total as an int, we can say:
total = 6

or
total = total + 1

(The second uses the fact that total + 1 is an expression with type int
and value one greater than total to form an assignment expression whose
second operand is an arithmetic expression.) This last expression -- adding
to a name -- is pretty common, and so it has a convenient shorthand:
total += 1

The += operator is one of a class of compound assignment operators. It

works by computing the value of its first operand, then adding its second
operand to that value and assigning the result to the name represented by
the first operand. In other words, the expression above is exactly the same
as saying total = total + 1. This kind of compound assignment can be
used with any number -- or other appropriate expression -- as the second
operand, of course. There are also other compound assignment operators in
Java, including -=, *=, /=, and %=. Like the + operator, the += operator
works for both numeric addition and String concatenation. Like their
longhand forms -- the simple assignment equivalents -- these expressions
have type and value of their left-hand side (after the assignment).

AutoIncrement and AutoDecrement

There is another family of side-effecting operators that are related to
assignment. These operators are autoincrement and autodecrement. The
postfix autoincrement expression
total++

is similar to total = total + 1 (or total += 1), but it has the value of
total before the assignment. The prefix autoincrement expression

++total

IPIJ || Lynn Andrea Stein

5~22 Expressions: Doing Things With Things Chapter 5

also adds one to total, but has the value of total after the assignment.
(Remember: ++var first increments, then produces a value; var++ produces
the value first.) The two (prefix and postfix) autodecrement operators work
similarly.

Chapter Summary
• Every expression has both a type and a value.

• Simple expressions include literals and names.

• A literal has its apparent type and value.

• A name has its declared type and assigned value.

• Operator expressions combine or produce modifications of simpler

expressions.

• Arithmetic operators compute mathematical functions; the type of

an arithmetic operation expression is typically the wider of its
operand types.

• Logical operators compute binary logical functions; the type of a

logical operation expression is boolean.

• Explicit cast expressions have the type of the cast operation and
the same value as the cast operand.

• None of the above expressions actually modifies any of its

operands. However, autoincrement, autodecrement, and the shift
operators do modify their operands.

• Assignment expressions are generally used for their effects -- modifying

the value associated with a (shoebox or label) name -- but, as expressions,
also have type and value. The value of an assignment expression is the
value assigned; the type is the type of the value assigned.

• Several kinds of expressions operate on objects:

• A method invocation expression has the type and value returned by

IPIJ || Lynn Andrea Stein

 Exercises 5~23

the method. Methods may be side-effecting.

• A field access expression is like an ordinary name expression: its

type is the field's declared type and its value is the field's current
assigned value, except in the context of assignment expressions.

• A constructor expression's value is a brand new object whose type

is the type with which the constructor expression is invoked.

Exercises
1. In Java, every expression has a type. Assume that the following declarations
apply:
int i, j, c;
double d;
short s;
long l;
float f;
boolean b;

For each expression below, if it is syntactically legal Java, indicate its type (not its
value). If it is not syntactically valid, indicate why.

1. 6

2. 24L

3. +3.5

4. 3.5f

5. 2e-16

6. -25b

7. i

8. i+3

9. i+3.0

10. i+s

IPIJ || Lynn Andrea Stein

5~24 Expressions: Doing Things With Things Chapter 5

11. l+d

12. f+s

13. i / 0

14. 4 * 3.2

15. i = 0

16. i == 0

17. b = 0

18. b == 0

19. 'c'

20. "An expression in double-quotes"

21. "An expression in double-quotes" + "another one"

22. "6" + 3

23. !b

24. !i

25. b || true

26. i += s

27. s += i

28. i += f

29. l = i = s

30. i = l += s

31. l++

32. (long) s

33. s

34. (short) l

IPIJ || Lynn Andrea Stein

 Exercises 5~25

35. l
2. Give examples of three expressions with side effects.
3. What is the value of each of the following expressions? Which ones produce
errors in evaluation? You may wish to consult the chart on operator precedence.
Assume that i is an already-defined name for an int and that b is a boolean.
1. 2.0 + 3.5 * 7
2. ("top " + "to " + "bottom" ).toUpperCase()
3. "the answer is " + 6 * 7
4. 4 + 6 + " is " + 10
5. i > 0 && i < 100
6. b = i < 0
7. ! (i == 0) && 100 / i
4. Give examples of each of the following:
1. An expression whose type is int and whose value is more than a
previously defined int, x.
2. An expression whose type is boolean and whose value is true when
x is between 5 and 15.
3. An expression whose type is double and whose value is half of x's,
where x is the aforementioned int.
4. An expression whose type is long and whose value is the
remainder when x is divided by 7.
5. An expression whose type is boolean and whose value is the
opposite of a previously defined boolean, b.
6. An expression whose type is boolean and whose value is true
exactly when the int x is evenly divisible by 5.
7. An expression whose type is String and whose value is read from
the user's keyboard.

IPIJ || Lynn Andrea Stein

 6
Chapter 6 Statements and Rules

Chapter Summary
• How do I tell the computer how to do something?
This chapter introduces statements, the simplest forms of complete executable
instructions. Statements are fragments of Java code that have neither value nor
type; instead, they have effects. Statements can be are combined to form rules, or
services that one object can provide to another. Statements and rules form the
backbone of the peanut-butter and jelly model of programming.
Statements can be built out of expressions. However, unlike expressions, which
have both type and value, statements are used for their effect -- to get something
done. Examples of this are asking a thing to do something or assigning a name to
keep track of a value. In addition to declarations, assignments, and method
invocation, this chapter introduces simple control flow statements. More
advanced statement types are introduced later in the book.
The chapter ends with a discussion of methods, the rules implementing behavior.
Method invocation provides the basis for virtually all inter-object interaction.
This chapter is supplemented by a reference chart on the syntax and semantics of
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
6~2 Statements and Rules Chapter 6

java statements.

Objectives of this Chapter

1. To appreciate the difference between evaluating an expression and
executing a statement.
2. To be able to read and understand basic statements including assignments,
method invocations, declarations, blocks, conditionals, and loops.
3. To learn how to combine statements to construct rules that implement
method behavior.

6.1 Statements and Instruction-Followers

In the first chapter of this book, we saw that computations are made of
communities of interacting entities. Each of these entities may be a community of
smaller entities, until eventually an entity can be subdivided no more. At that
point, an entity is a simple instruction-follower that provides behavior -- often in
the form of ongoing services -- to the other members of its community. This
chapter is about how those instructions work. Towards the end of the chapter, we
will begin to see how instructions can be combined to form special sequences that
articulate how service requests can be fulfilled.
In the previous chapter, we saw how to create Java expressions. An expression is
a piece of Java code with a value and a type. The process of producing the value
from an expression is called evaluating that expression. The purpose of evaluating
an expression is generally to produce its value.
In contrast, statements are all about their side effects. A statement is a piece of
executable Java code without either a type or a value. That is, a statement does
something (changes something, produces some visible behavior, etc.). It has an
effect. It does not have a value. A statement is executed (producing an effect), not
evaluated (producing a value).
In order to evaluate an expression, you must evaluate its subexpressions, then use
the evaluation rule for that kind of expression to produce an appropriate value of
an appropriate type. If you understand the evaluation rules for each type of
expression, you understand how expressions work.

IPIJ || Lynn Andrea Stein

6.1 Statements and Instruction-Followers 6~3

Understanding how to execute a statement is similar. A statement is not defined

by a type and a value (it doesn't have either!), but by its effects and by what
happens next. That is, statements do things; they change the values associated
with names. And statements can also cause you to skip around in the instructions
that you are following. This is called flow of control: what instruction to follow
next. Some of these control flow statements involve conditions (if it's raining, do
this) or loops (keep doing this until the light changes color). And many statements
involve either subexpressions--which must be evaluated--or substatements--which
must be executed in order to execute the superstatement.

6.2 Simple Statements

Perhaps the simplest kind of statement is one built directly out of an expression,
such as
this.who = name;
or
Console.println( "Hello" );
Note the trailing semicolon following the ends of these expressions. It is this
semicolon that converts these expressions into statements.
What kinds of expressions can be used to form statements? Only side-effecting
expressions. Many expressions are useful solely because of the value that they
compute. But a statement doesn't have a value; it has effects on state and control
flow. So an expression whose primary purpose is the value it produces doesn't
make a very good basis for a statement on its own.1 In fact, it is not legal in Java
to make an expression-semicolon statement out of a non-side-effecting
expression. (For example, x + 3; is not a legal statement.)
However, some expressions do more than just produce values when they are
evaluated. For example, an expression like x = 3 has the value 3 (and the type
int, assuming that x is an int). It also (and more importantly) has the effect of
storing the value 3 in the shoebox named x. This effect (of evaluating the
expression) is called a side effect. All assignment expressions (including
compound assignments) are side effecting. Autoincrement and autodecrement are
also side-effecting expressions. Method invocation expressions are also side-

1
These expressions may find use in other, more complex statements, though.

IPIJ || Lynn Andrea Stein

6~4 Statements and Rules Chapter 6

effecting, although not every method invocation actually has a side effect.
Instance creations -- new expressions -- are also side-effecting.
So, for example, a simple assignment statement can be made by adding a
semicolon to the end of the assignment expression x = 3
x = 3;

The semicolon turns this into a statement. It no longer has a value or a type; it just
does its work.
To execute an expression-semicolon statement, simply evaluate the expression.
Of course, this expression may have complicated subexpressions that must be
evaluated according to the rules described in the previous chapter. Since the
expression is a side-effecting one, something will happen -- an effect will be
produced -- during the evaluation.
After executing a side-effecting-expression-plus-semicolon statement, execution
proceeds at the following statement.

6.3 Declarations and Definitions

We have also already seen declarations in Chapter 3. A declaration creates a new
name that can be used to store (in the case of primitive types) or label (in the case
of reference types) a value. A declaration follows the type-of-thing name-of-thing
rule: It consists of a Java type followed by a Java name, then a semicolon. For
example,
int i;
Object thing;
A declaration (or definition) statement creates a kind of name called a local
variable.
You can actually declare multiple names of a single type with one declaration
statement. The syntax for this is type-of-thing name-of-thing1, name-of-
thing2, and so on, with commas between the names and a semicolon at the end:
int i, j, k;
Object thingOne, thingTwo;
The same type is associated to each of the comma-separated names, so the
declarations above are identical to
int i;

IPIJ || Lynn Andrea Stein

6.3 Declarations and Definitions 6~5

int j;
int k;
and
Object thingOne; Object thingTwo;
respectively.

Style Sidebar

Formatting Declaration Statements

Remember that Java doesn't care how much white space you leave between
things, so there is no difference in meaning between putting the multiple
declarations on one line or many. It is definitely easier to read on multiple
lines, though, so the convention is to put each declaration on its own line.
When one declaration statement is used to declare many names, you can
put the names on one line or on several. It's good style to indent all of the
names on subsequent lines of a single declaration so that they line up with
the first name declared:
Object thingWithALongName,
anotherThingWithALongName;
This way, it's easy to see that anotherThingWithALongName is involved in
the same declaration statement as thingWithALongName.
Although it is technically correct to mix declarations and definitions of a
single type using the comma-separated multiple declaration notation, this is
not good style. It is too easy to miss a definition among the declarations;
mixing the two makes your code unnecessarily harder to read.

A declaration makes it legal to use the name to hold/label appropriately typed

values. But the declaration, by itself, doesn't explicitly assign a value to the name.
In fact, for the most generic kind of name--a local variable--it is illegal to use a
name without first assigning it a value.2 You can assign this value directly in the

2
It is, however, legal to assign a label-name local variable the special non-value null. Assigning
null to a name means that the name doesn't refer to anything. Not assigning forces the computer
to guess. The rule is that you just can't leave the computer to guess.

IPIJ || Lynn Andrea Stein

6~6 Statements and Rules Chapter 6

declaration (making it a definition), or you can assign it before the first time that
you try to use the name's associated value.
A variant on a declaration statement is a definition. A definition is a declaration
statement with = expr between the name-of-thing and the semicolon (or
comma). This statement declares the name, but it also assigns it the value of expr.
For example:
int i = 2;
String who = "Pat";
double pi = 3.14159,
ninetyDegrees = pi / 2;
Note that the final statement here assigns the value 1.570795 to the name
ninetyDegrees. First 3.14159 is put into the shoebox named pi. Next, the
expression pi / 2 is evaluated: its value is the value inside the pi shoebox
divided by 2. Finally, this value is assigned to (stored in) the (newly created)
shoebox named ninetyDegrees.
It is legal to mix declarations and definitions in a single statement -- assigning
initial values to only some of the names -- but this can make your code hard to
read. It is usually better to use multiple statements in this case.
Executing a declaration statement creates a shoebox or label associated with the
name declared. Executing a definition is the same as declaring a name, plus
immediately afterwards executing an assignment statement. Note that this
assignment is an expression and may have subexpressions, causing a significant
amount of evaluation before execution is complete.
After executing a declaration or definition statement, execution proceeds at the
immediately following statement.

6.4 Sequence Statements

You can also make a bigger statement out of a collection of statements. You do
this by enclosing them in braces:
{
int i = 3;
Console.println( "i is " + i );
int j = i + 1;
j = i + 5;
}
This statement-made-of-statements is a block, and it mostly serves to organize

IPIJ || Lynn Andrea Stein

6.4 Sequence Statements 6~7

your code. Some other statements -- such as if, described below -- are often used
together with blocks.
Any statement can be used at any point inside a block. In particular, declarations
and definitions may appear anywhere in a block. This is useful as it allows you to
declare a name immediately before you need it. Doing so makes it easier to read
your code as the reader is less likely to have forgotten what you mean by that
name.
Blocks also have implications for scoping of names: a variable has scope (its
name can be used) from the point in the code where it is declared until the end of
the first enclosing block.3 So if we declare a name at the top of the block, it has
scope for the whole block, as i does in the example above. But j is not declared
until after the call to println, so the definition of i and the call to println are
outside of j's scope:
{ _
int i = 3; |
Console.println( "i_is " + i ); |
int j = i + 1; | scope of j | scope of i
j = i + 5; | |
} X X
This means, for example, that it would be illegal to use j in i's definition:
{
int i = j; // illegal use of j outside its scope!
Console.println( "i is " + i );
int j = i + 1;
j = i + 5;
}

Beware: The scope of a local variable only persists until the end of the enclosing
block. This means that a local variable must be declared at the same level as (or at
a level enclosing) each of its uses.
{
{
// A variable declared here...
String name;
}
// ...is invisible here, making this reference
name = "Pat";
// illegal!

3
Remember, not all names are variables. We will learn more about parameters and fields in
subsequent chapters. Type names have scope everywhere that they are visible.

IPIJ || Lynn Andrea Stein

6~8 Statements and Rules Chapter 6

}
// ...and so on.
The rules for executing a block statement are: execute each substatement in turn,
from the top (beginning) of the block to the bottom (end) of the block.
After a block, execution continues at the next statement.

Style Sidebar

Formatting Blocks
The open brace of a block should generally appear on its own line. If the
block is part of a compound statement (such as an if), its opening brace can
appear as the last character on a line. However, studies have found code
using this convention harder for programmers to scan than code in which
the open brace appears alone on a line.
Text within a block should always be indented (typically by two or four
characters). This makes the left-hand margin of code in a block line up. The
text -- but not the braces -- of an interior block is indented further; the
original indent is resumed when the interior block is closed, i.e., after the
closing brace.
The closing brace of a block should always begin its own line. If the
closing brace completes the statement, as in a simple block, it should
appear alone on that line.
// Some statements...
{
// Statements in a block
// all line up.
{
// Interior block statements
// are indented further.
}
// Close brace exits the block
// and restores earlier indent.
}
// ...and so on.

IPIJ || Lynn Andrea Stein

6.5 Flow of Control 6~9

6.5 Flow of Control

So far, we have seen declarations, definitions, and a few executable statements
made out of side-effecting expressions such as method invocation and
assignment. You can write some interesting programs using only these constructs,
but typical programs involve more complex structures. One of the most important
features is the ability to control which code is executed when. This is called flow
of control. These statements have execution rules that do not always cause the
next statement to be executed in turn. Instead, a statement may be executed more
than once or not at all.

6.5.1 Simple Conditionals

One of the simplest forms of control flow is conditional execution. Conditional
execution refers to a situation in which a block of code may or may not be
executed, depending on the value of an expression. It is analogous to a set of
instructions that says
Step 1. If your gizmo is not already assembled, you must assemble it
before going on to step 2. To assemble your gizmo, first....

Step 2. Now that your gizmo is fully assembled, ...

In Java, conditional execution is most often and most generally embodied in the
if statement. For example:
if ( theLight.isOn() )
{
theRoom.isLit = true;
}
Let's dissect this statement. It begins with the java keyword if. After the if is a
boolean expression that must be enclosed in parentheses. The closing parentheses
are followed by a block statement.4 This block is sometimes called the if
statement's body or the consequent; the boolean expression is called the if
statement's test or condition.
Execution of the if statement proceeds as follows. First, the boolean condition
expression is evaluated. If the value of this expression is true, the if's body block
is executed. If the value of the boolean condition expression is false, the if's body

4
There are other kinds of statements that can appear in place of this block, but in this book we will
restrict ourselves to the cases in which the if body is a block.

IPIJ || Lynn Andrea Stein

6~10 Statements and Rules Chapter 6

block is skipped.
In either case, execution proceeds at the next statement following the if's body.
The if statement, as defined, is very useful when you want to do something or
skip it. But often you want to do one of two things. We can express this using two
if statements with inverse conditions:
if ( theLight.isOn() )
{
theRoom.isLit = true;
}

if ( ! (theLight.isOn() ) )
{
theRoom.isLit = false;
}
This is poor code in three ways. The first is that it invokes the same method --
theLight.isOn() -- twice, but the code would not work as we want if the value
returned were different in the two invocations. (Imagine that the light were off the
first time you asked and on the second time. The value of theRoom.isLit would
never get set!)
We could fix this problem by temporarily assigning this value to a boolean name,
and then testing the name twice:
boolean itIsLight = theLight.isOn();

if ( itIsLight )
{
theRoom.isLit = true;
}

if ( ! itIsLight )
{
theRoom.isLit = false;
}
But this makes a second problem with the code even more apparent. This code is
testing a boolean expression (theLight.isOn() or itIsLight, depending on
which version) in order to set another boolean expression. It would be cleaner just
to write
theRoom.isLit = theLight.isOn();
This statement is equivalent to the whole previous example (using itIsLight),
and much easier to read. For more on this stylistic point, see the sidebar on Using
Booleans.

IPIJ || Lynn Andrea Stein

6.5 Flow of Control 6~11

Of course, we can write other code that's not subject to these two problems. For
example, we could use this idea to write code to compute absolute value of a
given int, x.
int absValue;

if ( x > 0 )
{
absValue = x;
}

if ( x < 0 )
{
absValue = - x;
}

if ( x == 0 )
{
absValue = 0;
}
This code has neither of the previous problems -- x doesn't change, so we can test
it repeatedly, and the value assigned is an int, not a boolean, so we can't write the
shorter assignment statement. But this code doesn't make it clear that these are
really three cases of the same test. There is a form of an if statement that allows us
to make this clearer. It uses the Java keyword else to denote a situation in which
we know that these conditions are mutually exclusive, i.e., at most one of them
can hold.
So, for example, we could rewrite our light-tester (verbosely) as:
boolean itIsLight = theLight.isOn();

if ( itIsLight )
{
theRoom.isLit = true;
}
else
{
theRoom.isLit = false;
}
This still isn't as nice as the one-line version, but it gives us the opportunity to
illustrate control flow in an if/else statement. To execute an if/else statement:

1. Evaluate the boolean condition expression.

2. If the value of the condition is true, execute the if body block, then skip to
the end of the entire if/else statement (i.e., to step 4).

IPIJ || Lynn Andrea Stein

6~12 Statements and Rules Chapter 6

3. Else (the value of the condition statement is false, so) execute the else
body block. An else body is sometimes called an alternative.
4. Execution continues at the following statement.
Since there might be more than two mutually exclusive conditions -- as in the
absolute value code -- else is allowed to have its own condition. An else with a
condition is like an if, except that you only execute that part of the statement if all
previous conditions in this if/else statement have been false. An else with no
condition is always executed if no previous condition in this if/else statement has
been true.
if ( x > 0 )
{
absValue = x;
}
else if ( x < 0 )
{
absValue = - x;
}
else
{
absValue = 0;
}
Note that this is all one statement, not three as in the previous version. Exactly
one of the assignment statements will be executed, no matter what the value of x
at the beginning of the if statement.
Even now, this is not the most elegant absolute value code we could write; for
example, the final case is redundant and could be folded into the first case using
>= instead of >. It does, however, illustrate the syntax of cascaded ifs. We will
return to examine if statements, and other conditionals, in the chapter on
Dispatch.

IPIJ || Lynn Andrea Stein

6.5 Flow of Control 6~13

Style Sidebar

Using Booleans
There are only two boolean values, true and false. There can be lots of
boolean labels, but each label is attached to either true or false; there is
nothing else. This means that testing whether a boolean is the same as
true --
(boolVal == true)
-- is redundant. You can just use boolVal, since it's either true or false.
Similarly, you don't need to use an if statement to test a boolean if you're
generating a boolean value. For example,
if (boolVal) {
return true;
} else {
return false;
}
is also redundant: just return boolVal;. The same thing applies if you're
assigning to a variable instead of returning: otherBoolVal = boolVal;
(or otherBoolVal = ! boolVal; if you want to reverse its sense).

6.5.2 Simple Loops

Another flow-of-control construct is while. While takes a condition and a block,
just like the simple form of if. Execution of a while statement first evaluates its
boolean condition expression. If the condition is true, the while body block is
executed. When execution of each statement in the body is complete, the while's
condition is checked again. Again, if the condition is true, the body is executed.
This continues until the evaluation of the condition expression yields false; at this
point, execution continues at the next statement after the while body.
There are several uses of a while loop. One is to continually test something until it
becomes true:
int i = 1;

while ( i < 100 )

{
Console.println( "I'm up to " + i );
i = i + 1;

IPIJ || Lynn Andrea Stein

6~14 Statements and Rules Chapter 6

}
This loop prints the numbers from 1 to 99. (Why doesn't it print 100?)
Another use is for a loop that keeps going essentially forever. (It will stop when
something stops the program, but not before:
while ( true )
{
myOutput.writeOutput( myInput.readInput() );
}
This loop continually passes whatever input it gets to its output. Since the value of
true doesn't change, this loop won't end until something nasty happens to it.
Writing loops like this one -- that go on essentially forever -- is much easier than
writing loops like the counting loop, above, because in the counting loop you
have to keep track of what's true each time you go around the loop. For example,
the value of i when you exit the loop above will always be one more than the last
value printed.
Here's an even more tricky one:
while ( x < 25 )
{
x = x + 3;
x = x - 2;
}
If x's value is 20 when we reach the beginning of this loop, what will its value be
when we exit? Remember that the test expression is only checked at the beginning
of each pass through the loop, not in the middle.
There is another looping construct in Java, called do/while statement or just a do
loop. It is much like the while loop, except that the loop body is always executed
once before the condition is tested:
int i = 1;

do
{
Console.println( "I'm up to " + i );
i = i + 1;
} while ( i < 100 )
As with a while loop, once the loop exits, execution proceeds at the statement
following the entire do statement.

IPIJ || Lynn Andrea Stein

6.6 Statements and Rules 6~15

6.6 Statements and Rules

Programs are not simply sequences of instructions to be executed. Instead, the
instruction-followers executing these statements are embedded in a community of
other instruction-followers. A program is a community of interacting entities
providing ongoing behavior and services. In this section, we look at how those
interactions too rely on statements.
When one Thing needs to communicate with another, this is commonly
accomplished through method invocation. Method invocation is an expression in
which one object supplies another with information (in the form of arguments),
and the second supplies the first with other information (in the form of the return
value). These mechanisms are the major means of inter-object communication
and coordination. Of course, method invocation can also be used within an object,
allowing one part of the object to communicate with another.
We have previously seen how interfaces specify methods that an object provides.
Now, we turn to the question of how method behavior is actually implemented.
Statements provide the key. Performing a method amounts to following the
instructions associated with that method, i.e., stepping through the instructions for
that rule. Statements are the steps of those instructions. By sequencing statements,
you can build a rule that the computer can follow to accomplish a desired task.
Some rules require information in order to accomplish their tasks. (For example, a
rule that doubles a number needs the number to be doubled.) Some rules produce
results. (For example, the doubling rule might produce the doubled number.)
Some rules behave differently under different circumstances. (This uses a
conditional statement).
In order to use a rule -- to interact with it -- you need to know whose rule it is,
what information you need to supply in order for the rule to do its work, and what
the rule will give you in return. This prefigures the idea of method signature.
There are other things you'd like to know about a rule -- such as the relationship
between the rule's input and its output -- and these form the basis of the rule's
documentation.

For example, here is a rule for printing a brief form letter:

to printFormLetter using ( String title,

String firstName,
String lastName )

1. print "Dear "

IPIJ || Lynn Andrea Stein

6~16 Statements and Rules Chapter 6

2. if ( title isn't null ) print title + lastName

else print firstName

3. println ":\nWe are tremendously pleased to inform you that

"

4. println "you have won!".toUpperCase()

5. println "Not much, but what did you expect?"

6. println " Sincerely,\n me"

It's just a short hop from this pseudocode rule to real Java:
void printFormLetter( String title,
String firstName,
String lastName )
{
if ( title != null )
{
Console.print( title + lastName );
}
else
{
Console.print( firstName );
}
Console.print( ":\nWe are tremendously pleased "
+ "to inform you that " );
Console.println( "you have won!".toUpperCase() );
Console.println( "Not much, but what did you expect?"
);
Console.println( " Sincerely,\n"
+ " me" );
}

6.6.1 Method Invocation Execution Sequence

Method invocation is, as we have seen, an expression. To invoke the
printFormLetter, we need to know whose method it is. We follow this object
expression with a dot, then the name of the method, then the parentheses-enclosed
parameter list:
theWidgetCompany.printFormLetter( "Prof.", "Pat", "Smith" )
To evaluate this expression, we need to invoke theWidgetCompany's
printFormLetter method (using the rule, or instructions, or method body,
provided above) with the arguments "Prof.", "Pat", and "Smith".

IPIJ || Lynn Andrea Stein

6.6 Statements and Rules 6~17

The first step in method invocation is parameter binding. In this step, each
parameter name (title, firstName, and lastName) is treated as though it were
newly declared and it is given the value of the corresponding argument. (Recall
that parameters are the names in the method declaration, while arguments are the
values supplied in the method invocation expression.) In order for this to work,
each value must be assignable to the corresponding parameter's declared type.
After parameter binding, method invocation proceeds as though the method body
were a simple block. The block is, however, within the scope of the parameter
bindings, so that inside the block the parameter names can be used to refer to the
provided argument values. For example, in the body of the printFormLetter, title
is bound to "Prof", firstName is bound to "Pat", and lastName is bound to
"Smith".
Now the body statements are executed in turn. In this case, the first statement is
an if, so its test expression is evaluated to determine whether to execute the
consequent block or the alternative block. When the test expression
title != null

is evaluated, title is bound to "Prof", so it is not null, causing the consequent to

execute.
This argument-value-providing is one way in which method invocation
implements inter-entity communication: the value is communicated from the
method-invoker to the method owner.

6.6.2 Return
This special statement can only be used inside method bodies. It is used to
terminate the execution of the method body. It is also what is responsible for
making a method body -- which is essentially a block statement -- return a value -
- which is a necessary property of a method invocation expression (unless the
method's return type is void).
The need for this statement arises when the sequence of instructions that you are
writing is turned into a method body. In this case, you need to say what the
method returns. This return value becomes the value produced by evaluating a
method invocation expression. This is accomplished using a return statement.
The syntax of a return statement is
return expression;

where expression can be any arbitrary Java expression. Remember: the return

IPIJ || Lynn Andrea Stein

6~18 Statements and Rules Chapter 6

statement -- a statement -- does not have a value, but the method invocation - an
expression -- does.
To execute a return statement, evaluate the expression. Then, exit the enclosing
method, providing the value of the expression as the return value of the method
invocation expression. Exiting the enclosing method means both exiting from the
block that is the method body and also exiting the scope of the
parameter/argument bindings.
After a return statement, execution proceeds at the method invocation whose
method body contained the return statement; evaluation of this expression is
complete (with its value the value supplied by the return statement) and execution
of the statement containing the method invocation continues.

For example, if we execute

String transformed = this.transform( "Knock, knock" );
and the transform method of this object ends with the line
return "Who's there?";
then the value of the invocation this.transform( "Knock, knock" ) is
"Who's there?". Execution continues by assigning the value of the invocation
("Who's there?") to the name transformed.
Another example is the doDouble( int ) method mentioned above. The code for
doDouble might read:
int doDouble( int whatToDouble )
{
return whatToDouble * 2;
}
To evaluate the application of doDouble to 7,
1. The parameter name whatToDouble is bound to 7.
2. Within the scope of this binding, the body block of doDouble is executed.
a. Each statement in the block is executed in turn. Since there is only
one statement, it is executed.
i. The expression whose value is to be returned is evaluated.
This requires evaluating the subexpressions (name
whatToDouble and literal 2) and then applying the operator
to these values.
ii. The value produced by the operator expression (14) is

IPIJ || Lynn Andrea Stein

6.6 Statements and Rules 6~19

returned by the method

3. This exits both the method body block and the parameter scope, providing
the value (14) as the value of the method invocation expression.
There is also an alternate form of return that does not take an expression. This
form is used in methods whose return type is void. In this case, a return statement
executes by exiting the method (and, with it, the scope of the parameter names).
Since the simple return statement is used only in methods whose return type is
void, there is no value for it to supply.
This return statement can also be left implicit certain methods. For example, in
the printFormLetter method that we saw above, there was no explicit return
statement. In Java, a method without a return statement is presumed to have a
return statement as its final statement. This return statement is a simple return; -
- it is the form that does not return a value. So the end of that method body was
equivalent to saying
//...
Console.println( " Sincerely,\n"
+ " me" );
return;
}
In a method whose return type is not void, an explicit return statement must
always be executed in order to provide the method's return value. Value-returning
is another example of inter-object communication.

Chapter Summary
• Statements combine expressions to produce useful behavior.

• A statement does not have a value or a type.

• A statement is executed to produce an effect.

• A side-effecting expression followed by a semicolon is a simple statement.

• Declarations and definitions are also simple statements.

• A sequence of statements can be grouped into a block by surrounding the

sequence with braces { }

IPIJ || Lynn Andrea Stein

6~20 Statements and Rules Chapter 6

• Conditional statements allow you to write code containing alternative

execution sequences. The execution sequence of a conditional statement
depends on the result of evaluating a boolean expression.

• A loop allows the same block of code to be executed repeatedly, until an

exit condition -- a boolean expression -- is true.

• A return statement is used to exit from a method, with or without a value.

• Method bodies, or rules, use sequenced statements -- including loops and

conditionals -- to produce chunks of executable behavior. A method is
specified by its name, the information it needs, and the value (if any) that
it produces.

Exercises
1. Using Java's if statement, write instructions for determining which team returns
an out-of-bounds ball to play in a soccer game. In soccer, the team that did not
last touch the ball receives possession of the ball and returns it to play.

a. You may presume that you have a method, lastTouch(), that returns either
homeTeam or visitTeam, and that the goal of your code is to assign the correct
team value (either homeTeam or visitTeam) to the already-defined name
possessingTeam.

b. In addition, make your code determine whether returnBallToPlayMethod is

sideThrow, cornerKick, or goalKick. You may make use of the
ballOutLine() method to determine whether the ball exited via the sideLine,
the homeEndLine, or the visitEndLine.5
2. Using Java's while statement, give instructions for building a tall tower of
blocks.
3. Using Java's while statement, give instructions for blowing up a balloon.

5
If the ball has exited via the side line, the return is by side throw. If the ball exits via the home
end line and is last touched by the home team, the visitors return the ball to play by means of a
corner kick. A ball that is pushed beyond the home end line by the visiting team is returned by the
home team via a goal kick. The situation at the visitor's end line is the opposite.

IPIJ || Lynn Andrea Stein

 Exercises 6~21

4. Which of the following are expressions, which statements, and which illegal?
For the expressions, indicate the type and value. For the statements, indicate the
effect (if known) and the execution sequence. You may assume that x is an int, b a
boolean.

a. int x = 5

b. boolean b;

c. x + 3

d. x = x + 3

e. x = x + 3;

f. x == 3

g. x == 3;

h. b = x == 3;

i. {
Console.print( "What is your name? " );
String name = Console.readln();
String cap = name.toUpperCase();
}

5. What will the value of d be after each of the following statements? Also,
indicate any other changes that may occur as a result of executing the statement.
You may assume that they are executed in the order given.

a. double d = 3.5;

b. d = d * 3;

c. if ( d < 8 )
{
Console.println( "d is pretty small" );
}

d. d = 2.0

e. while ( d < 30 )
{
d = d * 2;
}

IPIJ || Lynn Andrea Stein

 7
Chapter 7 Building New Things: Classes and Objects

Chapter Overview
• How do I group together related rules?

• How do I build a computational object?

• What are Java programs really made of?

In this chapter, you will learn to put together the pieces you've already seen --
things, names, expressions, statements, rules, and interfaces -- to create
computational objects that can populate your communities.
In order to create an individual object, you first have to describe what kind of
object it is. This includes specifying what things you can do with it -- as in its
interface(s) -- but also how it will actually work. This description of the "kind of
object" is like building a recipe for the object, but not like the object itself. (You
can't eat the recipe for chocolate chip cookies.) These object-recipes are called
classes.
For each thing that your object can do, your class needs to give a rule-recipe. This
is called a method. Your objects may also have (named) pieces. These are called
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
7~2 Building New Things: Classes and Objects Chapter 7

fields, and they are special java names that are always a part of any object made
from this recipe.
When you actually use your class (recipe) to create a new object, there may be
things that you need to do to get it started off right. These startup instructions are
called a constructor.
When you are building an object, you are bound by the interfaces it promises to
meet. If the interface promises a behavior, you have to provide a rule (method)
body for the object to use.
This chapter is supplemented by reference charts on the syntax and semantics of
Java classes, methods, and fields. It includes style sidebars on good
documentation practice.
Most of the syntax of this section is covered in the appendix Java Charts.

Objectives of this Chapter

1. To recognize the difference between classes and their instances.
2. To be able to read a class definition and project the behavior of its
instances.
3. To be able to define a class, including its fields, methods, and
constructors.

7.1 Classes are Object Factories

In a previous chapter, we saw how to build an interface, or specification, that
described the contract a particular kind of object would fulfill. We also saw that
an interface does not provide enough information to actually create an object of
the appropriate kind. Interfaces do not say anything about how methods actually
work. They do not talk about the information that an object needs to keep track of.
And they do not say anything about the special things that need to happen when a
new object is created.
In this chapter, we will learn how to create objects and how to describe the ways
in which they work. The mechanism that Java provides for doing this is called a
class. Like an interface, a class says something about what kind of thing an object

IPIJ || Lynn Andrea Stein

7.1 Classes are Object Factories 7~3

is. Like an interface, a class defines a Java type. However, interfaces specify only
contracts; classes also specify implementation. Class methods are full-fledged
rules, with bodies telling how to accomplish the task of that rule (not just the rule
specification, or method signature, of abstract interface methods). Classes also
talk about data -- information to be kept track of by objects -- as well as methods,
or behavior. And a special part of a class -- the constructor -- talks about how to
go about creating an object of the type specified by that class.

7.1.1 Classes and Instances

Objects created from a class are called instances of that class. For example, the
class CheckBox refers to the instructions for creating and manipulating a GUI
widget that displays a selectable checkbox on your computer screen. CheckBox is
the name of the class, i.e., of the instructions. Let's say we create two particular
checkboxes:
CheckBox yesCheckBox = new CheckBox();
CheckBox noCheckBox = new CheckBox();

Figure 1. The actual CheckBoxes.

The two objects labeled by the names yesCheckBox and noCheckBox are
instances of the class CheckBox. That is, they are particular CheckBoxes. The
instructions for how to create -- or be -- a CheckBox, on the other hand, aren't a
CheckBox at all; the instructions are instructions, or a class. In fact, the
instructions are an object, too, though a very different kind of object and not one
as obviously useful as a CheckBox or a Timer or a Counter. The kind of object
the instructions are is called a Class.
Because the class contains the instructions for how to make a new instance and
for how to behave like an instance of that class, we sometimes say that a class is
like a factory where instances are made. Both a factory and its product are
objects, but factories and the widgets that they make are very different kinds of
objects. The factory has all of the know-how about its instances. But the factory
isn't one of its instances, just as the class CheckBox isn't a CheckBox. It's a
factory!

IPIJ || Lynn Andrea Stein

7~4 Building New Things: Classes and Objects Chapter 7

7.1.2 Recipes Don't Taste Good

Another analogy for a class (as opposed to its instances) is that the class is like a
recipe for how to make instances. The instances are like food cooked from the
recipe (say, chocolate chip cookies). It isn't hard to tell the difference between
these things. The cookies smell good. If you are hungry, the note-card with the
recipe on it won't be very satisfying. (It probably tastes a lot like cardboard.) On
the other hand, if you're going over to Grandma's to cook, you might want to take
the recipe but you probably don't want to stick the chocolate chip cookie in your
back pocket. Classes actually contain a lot of information other than just how to
make an instance. (The recipe might, too. It might include information on how
long it takes to make the cookies, whether they need to be refrigerated, how long
it will take before they go stale, or even how many calories they contain.)

Figure 2. Two recipes (classes) and two platefuls of cookies

(instances) made from the second recipe.

7.1.3 Classes are Types

Like interfaces, classes represent particular kinds of objects, or types. Once a class
has been defined (see below), its name can be used to declare variables that hold
objects of that type. So an instance of a class can be labeled using a name whose
declared type is that class. For example, the CheckBoxes described above are
labeled using names (yesCheckBox and noCheckBox) whose declared type is
CheckBox. Note that the class CheckBox -- the CheckBox recipe -- can't be labeled
using a name whose declared type is CheckBox. The type of the class CheckBox is
Class, not CheckBox. (This is the recipe vs. cookie distinction again.)

If an object is an instance of a class -- such as yesCheckBox and the class

CheckBox -- then the type membership expression (yesCheckBox instanceof
CheckBox) has the value true. Of course, CheckBox instanceof CheckBox is
false (since the class isn't a CheckBox), but CheckBox instanceof Class is

IPIJ || Lynn Andrea Stein

7.1 Classes are Object Factories 7~5

true.

Style Sidebar

Class Declaration
It is conventional to declare the members of a class in the following order:

• static final fields (i.e., constants)

• static non-final fields

• non-static fields

• constructors

• methods
This order is not necessary -- any class member can refer to any other class
member, even if it is declared later -- but it makes your code easier to read
and understand.
All non-private members of the class should be listed in the class's
documentation.

7.2 Class Declaration

A class definition starts out looking just like an interface declaration, although it
says that it is a class rather than an interface:
class Cat {
....
}
A class definition tells you what type of thing it is -- a class -- what it is called --
its name -- and what it's made of -- its definition, between braces. This last part is
called the class's body. The body of the class definition contains all of the
information about how instances of that class behave. It also gives instructions on
how to create instances of the class. These elements -- fields, methods, and

IPIJ || Lynn Andrea Stein

7~6 Building New Things: Classes and Objects Chapter 7

constructors -- are called the class's members.1 Each member is declared inside
the body of the class, but not inside any other structure within the class. Another
way of saying this is that each member is declared at top level within the class. So
members are all and only those things declared at top level within a class.

For example, each instance of Java's Rectangle class has a set of four
coordinates describing the rectangle's position and extent, as well as methods
including one which tells whether a particular x, y pair is inside the Rectangle.
...class Rectangle {
...
int height;
int width;
int x;
int y;
...
...inside(...)...
}
In this case, height, width, x, y, and inside are all members of the Rectangle
class.

Members and instances are quite different:

• members are parts of a class

• instances are things created from the class.

1
Be careful not to confuse members, which are parts of the class, with instances, which are objects
made from the class. If chocolate chip cookies are instances of the cookie class (recipe), the
chocolate chips are members of the class.

IPIJ || Lynn Andrea Stein

7.2 Class Declaration 7~7

We will return to each of the elements of this declaration later in this chapter.

7.2.1 Classes and Interfaces

A class may implement one or more interfaces. This means that the class
subscribes to the promises made by those interfaces. Since an interface promises
certain methods, a class implementing that interface will need to provide the
methods specified by the interface. The methods of an interface are abstract --
they have no bodies. Generally, a class implementing an interface will not only
match the method specifications of the interface, it will also provide bodies --
implementations -- for its methods.

For example, a ScoreCounter class might meet the contract specified by the
Counting interface:
interface Counting
{
abstract void increment();
abstract int getValue();
}
So might a Stopwatch, although it might have a totally different internal
representation. Both would have increment() and getValue() methods, but the
bodies of these methods might look quite different. For example, a ScoreCounter
for a basketball game might implement increment() so that it counts by 2 points
each time, while a Stopwatch might call its own increment() method even if no
one else does.
A class that implements a particular interface must declare this explicitly:
class ScoreCounter implements Counting {
....
}

IPIJ || Lynn Andrea Stein

7~8 Building New Things: Classes and Objects Chapter 7

If a class implements an interface, an instance of that class can also be treated as

though its type were that interface. For example, it can be labeled with a name
whose declared type is that interface. For example, an instance of class
ScoreCounter can be labeled with a name of type Counting. It will also answer
true when asked whether it's an instanceof that interface type: if
myScoreCounter is a ScoreCounter, then myScoreCounter instanceof
Counting is true. Similarly, you can pass or return a ScoreCounter whenever a
Counting is required by a method signature.

The generality of interfaces and the inclusion of multiple implementations within

a single (interface) type is an extremely powerful feature. For example, you can
use a name of type Counting to label either an instance of ScoreCOunter or an
instance of Stopwatch (and use its increment() and getValue() methods)
without even knowing which one you've got. This is the power of interfaces!

7.3 Data Members, or Fields

The Rectangle class, above, had certain things that were a part of each of its
instances: width, height, etc. This is because part of what it is to be a Rectangle
involves having these properties. A Rectangle-factory (or Rectangle-recipe)
needs to include these things. Of course, each Rectangle made from this class
will have its own width, height, etc. -- it wouldn't do for every Rectangle to have
the same width!

Many objects have properties such as these: information called state or data that
each instance of a class needs to keep track of. This kind of information is stored
in parts of the object called fields. A field is simply a name that is a part of an

IPIJ || Lynn Andrea Stein

7.3 Data Members, or Fields 7~9

object. For the most common kind of field, each instance of a class is born with its
own copy of the field -- its own label or shoebox, depending on the type of name
the field is.
Declaring a field looks just like an ordinary name declaration or definition
(depending on whether the field is explicitly initialized). Such a declaration is a
field declaration if it takes place at top level in the class, i.e., if it is a class
member. (A local variable declared inside a method body or other block is not at
top level in the class.)

Consider the Rectangle class defined above and reproduced here:

class Rectangle {
int height;
int width;
int x;
int y;
...
}
Each instance of this class will have four int-sized shoeboxes associated with it,
corresponding to the height, width, horizontal and vertical coordinates of the
Rectangle instance. These fields are declared at top level inside the class body.

These fields are declared here, but not initialized: none of these fields is explicitly
assigned a value. Fields, unlike variables, are initialized by default. If you don't
give a field a value explicitly, it will have a default value determined by its type.
For example, int fields have a default value of 0. Contrast int local variables,
which don't have a default value and cannot be used until they are initialized. For
details on the default values for each type, see the sidebar on Default
Initialization.

IPIJ || Lynn Andrea Stein

7~10 Building New Things: Classes and Objects Chapter 7

Java Types and Default Initialization

In Java, field names can be declared without assigning them an initial
value. In this case, Java automatically provides the field with a default
value. The value used by Java depends on the type of the field.

Fields with numeric types are initialized by default to the appropriate 0;

that is, either 0 or 0.0 (using the appropriate number of bits).

Fields with type char default to the value of the character with ascii and
unicode code 0 -- '\u000'. This character is sometimes called the null
character, but should not be confused with the special Java value null, the
non-pointer.

Fields with boolean type are by default assigned the value false.

Fields associated with reference types -- including String -- are by default

not bound to any object, i.e., their default value is null.
If a declaration is combined with an assignment -- i.e., a definition -- the
definition value is used and these default rules do not apply.
These rules apply to names of fields as well as to the components of arrays
-- described in a later chapter. In contrast, local variables must be explicitly
assigned values -- either in their declaration (definition) or in a subsequent
assignment statement -- before they are used. There are also names called
parameters, which appear in methods and catch expressions; they are
initialized by their invoking expressions and are discussed in elsewhere in
this book.

7.3.1 Fields are not Variables

The difference in default initialization is only one difference between fields and
local variables. This section covers several other important differences after first
reviewing some properties of local variables.
A local variable is a name declared inside a method body. The scope of a local
variable -- the space within which its name has meaning -- is only the enclosing
block. At most, this is the enclosing method, so the maximum lifetime of a
variable name is as long as the method is running. Once the method exits, the

IPIJ || Lynn Andrea Stein

7.3 Data Members, or Fields 7~11

variable goes away. (A similar variable will come into existence the next time the
method is invoked, but any information stored in the variable during the previous
method invocation is lost.)

7.3.1.1 Hotel Rooms and Storage Rental

Because a field is a part of an object, and because an object continues to exist
even when you're not explicitly manipulating it, fields provide longer-term
(persistent) storage. When you exit a block, any variables declared within that
block are cleared away. If you reenter that block at some later point, when you
execute the declaration statement, you will get a brand new variable. This is
something like visiting a hotel room. If I visit Austin frequently, I may stay in
similar (or even the same) hotel rooms on each trip. But even if I stay in the same
hotel room on subsequent visits, I can't leave something for myself there. Every
time that I check into the hotel, I get what is for all intents and purposes a brand
new room.
Contrast this with a long-term storage rental. If I rent long-term storage space, I
can leave something there on one visit and retrieve it the next time that I return.
Even if I leave the city and return again later, the storage locker is mine and what
I leave there persists from one visit to the next. When I'm in Seattle, the things I
left in my rental storage in Austin are still there. When I get back to Austin, I can
go to my storage space and get the things I left there. This is just like a field: the
object and its fields continue to exist even when your attention is (temporarily)
elsewhere, i.e., even when none of the object's methods are being executed.

IPIJ || Lynn Andrea Stein

7~12 Building New Things: Classes and Objects Chapter 7

The storage locker story is actually somewhat more complex than that, and so is
the field story. It might be useful for someone else to have a key to my storage
locker, and it is possible for that person to go to Austin and change what's in the
locker. So if I share this locker with someone else, what I leave there might not be
what I find when I return. It is important to understand that this is still not the
same as the hotel room. Between my visits, the hotel cleans out the room. If I
leave something in my hotel room, it won't be there the next time I come back.
Each time, my hotel room starts out "like new". In contrast, the contents of my
storage locker might change, but that is because my locker partner might change
it, not because I get a freshly cleaned locker each time that I visit.
The locker partner story corresponds closely to something that can happen with
fields. It is possible for the value of a field to change between invocations of the
owning object's methods, essentially through the same mechanism (sharing) as the
storage locker. To minimize this (when it is not desired), fields are typically
declared private. For more on this matter, see the discussion of Public and
Private in the next chapter. We will return to the issue of shared state (e.g. when
two or more people have access to the same airport locker) in the chapter on
Synchronization.

7.3.1.2 Whose Data Member is it?

A second way in which fields differ from variables is that every field belongs to
some object. For example, in the Rectangle code, there's no such thing as width
in the abstract. Every width field belongs to some particular Rectangle instance,
i.e., some object made from the Rectangle class/factory/recipe.
Because a field belongs to an object, it isn't really appropriate to refer to it without
saying whose field you are referring to. Many times, this is easy:
myRectangle.width, for example, if you happen to have a Rectangle named
myRectangle. The syntax for a field access expression is (1) an object-identifying
expression (often, but not always, a name associated with the object), followed by
(2) a period, followed by (3) the name of the field. You can now use this as you
would any other name:
myRectangle.width = myRectangle.width * 2;
for example.
There is, however, a common case in which the answer to the question "whose
field is it?" may be an object whose name you don't know. This occurs when you
are in a class definition and you want to refer to the instance whose code you are
now writing. (Since a class is the set of instructions for how to create an instance,
it is common to say "the way to do this is to use my own width field....")

IPIJ || Lynn Andrea Stein

7.3 Data Members, or Fields 7~13

In Java, the way to say "myself" is this. That is, this is a special name
expression that is always bound to the current object, the object inside whose code
the name this appears. That means that the way to say "my own width field...."
is this.width. (Note the period between this and width -- it is important!)

7.3.1.3 Scoping of Fields

The final way in which fields differ from (local) variables is in their scoping. The
scope of a name refers to the segment of code in which that name has meaning,
i.e., is a legitimate shoebox or label. (If you refer to a name outside of its scope,
your Java program will not compile because the compiler will not be able to
figure out what you mean by that name.) A local variable only has scope from its
declaration to the end of the enclosing block. (A method's parameter has scope
throughout the body of that method.)
A field name has scope anywhere within the enclosing class body. That means
that you can use the field name in any other field definition, method body, or
constructor body throughout the class, including the part of the class body that is
textually prior to the field declaration! For example, the following is legal, if
lousy, Java code:
class Square{
int height = this.width;
int width = 100;
...
}
(This isn't very good code because (a) it's convoluted and (b) it doesn't do what
you think it does. Although this.width is a legal expression at the point where
it's used, the value of this.width is not yet set to 100. The result of this code is
to set height to 0 and width to 100. The rule is: all fields come into existence
simultaneously, but their initialization is done in the order they appear in the class
definition text.)
A cleaner version of this code would say
class Square{
int height = 100;
int width = this.height;
...
}

IPIJ || Lynn Andrea Stein

7~14 Building New Things: Classes and Objects Chapter 7

Comparison of Kinds of Names2

Class or Interface Field

Parameter (Local) Variable
Name (Data Member)

Everywhere within Everywhere Everywhere From declaration to

Scope containing program within containing within method end of enclosing
or package. class. body. block.

Until program Lifetime of object Until method Until enclosing block

Lifetime execution whose field it is. invocation exits.
completes. completes.

Label names: Value of matching Illegal to use without

null argument explicit initialization.
Default
expression
Initializ -- Shoebox names:
supplied to
ation value depends on
method
type.
invocation.

7.3.2 Static Members

So far, we've said that fields belong to instances made from classes and that each
instance made from the class gets its own copy. Recall that the class itself is an
object, albeit a fairly different kind of object. (The class is like a factory or a
recipe; it is an instance of the class called Class.) Sometimes, it is useful for the
class object itself to have a field. For example, this field could keep track of how
many instances of the class had been created. Every time a new instance was
made, this field would be incremented. Such a field would certainly be a property
of the class (i.e., of the factory), not of any particular instance of that class.
The declaration for a class object field looks almost like an instance field. The
only difference is that class field declarations are preceded by the keyword

2
The column for Class or Interface Name refers only to top-level (non-inner) classes or interfaces.
The scope and lifetime of an inner class is determined by the context of its declaration.

IPIJ || Lynn Andrea Stein

7.3 Data Members, or Fields 7~15

3
static. For example:
class Widget {
static int numInstances;

...
}
In this case, individual Widgets do not have numInstances fields. There is only
one numInstances field, and it belongs to the factory, not the Widgets. To access
it, you would say Widget.numInstances. In this case, this.numInstances is
not legal code anywhere within the Widget class.

Style Sidebar

Field Documentation
In documenting a field, you need to indicate what that field represents
conceptually to the object of which it is a part. In addition, you should
answer these questions as appropriate:

• What range of values can this field take on?

• What other values are interdependent with this one? For example,
must this field's value always be updated in concert with another field,
or must its value remain somehow consistent with another field?

• Are there any "special" values of this field that carry hidden meaning?

• What methods (or constructors) modify this field? Which read this
field? What else relies on its value?

• Where does the value of this field come from?

• Can the value of this field change?

3
The choice of the keyword static, while understandable in a historic context, strikes us as an
unfortunate one as the common associations with the term don't really accord with its usage here.
In Java, static means "belonging to the class object."

IPIJ || Lynn Andrea Stein

7~16 Building New Things: Classes and Objects Chapter 7

7.4 Methods
In a previous chapter, we saw how method signatures describe the name,
parameters, and return type of a method. A method signature declared in an
interface ends in a semi-colon; this method specifies a contract, but doesn't say
anything about how it works. It is essentially a rule specification. This kind of
method -- a specification without an implementation -- is called abstract.
Classes specify more than just a contract. Classes also specify how their instances
work. In order for an instance to do be able to do something, its class must give
more than the rule specification for its methods. An instance needs the rule body
for its methods. Classes must supply bodies for any methods promised by the
interfaces that they implement. They may also supply additional methods with
their own signatures and bodies.
Methods can be identified by the fact that a method name is always followed by
an open parenthesis. (There may then be some arguments or parameters, on which
more below; there will always be a matching close parenthesis as well.)

7.4.1 Method Declaration

A method definition also follows the type-of-thing name-of-thing convention,
but the type-of-thing is the type that is returned when the method is called. So, for
example, the inside method in the definition of Rectangle, above, returns a
boolean value:
...boolean inside( int x, int y) { ... }
Inside the parentheses is the list of parameters to the method: calling
pictureFrame.inside on a particular x and y value returns true or false
depending on whether the point (x, y) is inside pictureFrame. (Remember that
the inside method only exists with reference to a particular Rectangle -- it's
always some object's method!) The list of parameters, like every other declaration,
follows the type-of-thing name-of-thing convention. Note, though, that while a
regular variable definition can declare multiple names with a single type, in a
parameter list each name needs its own type.
A few more notes on methods: If there are no parameters, the method takes no
arguments, but it must still be declared and invoked with parentheses:
pictureFrame.isEmpty(), for example. If there is no return value, the return
type of the method is void. Finally, inside the body of the method, the parameters
may be referred to by the names they're given in the parameter declaration. It

IPIJ || Lynn Andrea Stein

7.4 Methods 7~17

doesn't matter what other names they might have had outside of the method body,
or what else those parameter names might refer to outside the method body. We'll
return to the issue of scoping later.
Recall from previous chapters that the method definition as we've described it so
far -- the return type and the parameter list -- is also called the signature of the
method. It tells you what types of arguments need to be supplied when the method
is called -- it must be possible to assign a value of the argument type to a variable
of the parameter type -- and what type of thing will be returned when the method
is invoked. It doesn't tell you much about the relationships between the method's
inputs and its outputs, though. (The method's documentation ought to do that!)

Style Sidebar

Method Implementation Documentation

Documentation for methods in classes is much like the documentation for
methods in interfaces. However, class/object methods have bodies as well
as signatures. In addition to the usual documentation of the method
signature (see the Style Sidebar on Method Documentation in the chapter
on Interfaces), your method documentation here should include

• ways in which this method implementation differs from or specializes

the documented interface method (signature).

• information concerning the design rationale (why the method works

the way that it does), just as you would for any piece of Java code. For
more detail, see the Style Sidebar on Documentation in the chapter on
Statements.

7.4.2 Method Body and Behavior

This relationship -- how to get from the information supplied as arguments to the
result, or return value -- is the "how to do it" part of the method. Its details are
contained in the method body, which -- like a class body -- goes between a pair of
braces. What goes in here can be variable definitions or method invocations or
any of the complex statements that you will learn about later. You cannot,
however, declare other methods inside the body of a method. Instead, the method
body simply contains a sequence of instructions that describe how to get from its

IPIJ || Lynn Andrea Stein

7~18 Building New Things: Classes and Objects Chapter 7

inputs (if any) to its output (if any), or what else should happen in between.
The body of a method is inside the scope of its parameters. That is, the parameter
names may be used anywhere within the method to refer to the corresponding
arguments supplied at method invocation time. The body of an instance method is
also within the scope of the special name this. Just as in fields, inside a method
the name this refers to the particular instance whose method this is. Static
methods -- methods belonging to the class -- are not within the scope of this,
though. That is, you can't use the special name expression this in a static method.

In order to return a value from a method, you use a special statement: return.
There are actually two forms of this statement: return(...); returns a value
(whatever is in the parentheses) from a method invocation. For example,
return (total + 1);

returns one more than the value of total, though it doesn't change the value of
total at all. The parentheses around the expression whose value is to be returned
are in fact optional, leading to the second form of return: return; is used to exit
from a method whose return type is void, i.e., that does not return anything.
Remember (from the chapter on Expressions) that a method invocation is an
expression whose type is the return type of the method and whose value is the
value returned by the method. You make this happen (when you're describing the
method rule) by using an explicit return statement in a method's body. In the
chapter on Statements, we saw the execution rule for a method body and how it
relates to the evaluation rule for method invocation. This process is summarized
in the sidebar on Method Invocation and Execution.

7.4.3 A Method ALWAYS Belongs to an Object

A method is a thing that can be done (or invoked, or called). For example, a
painting program can draw a line, so drawLine could be the name of a method.
Every method belongs to a particular object. For instance, each increment
method belongs to a particular ScoreCounter (or Stopwatch, or...) object; there
is no such thing as an independent getValue method. So, if myScoreCounter
refers to a particular ScoreCounter, myScoreCounter.getValue() invokes
myScoreCounter's int-returning method. You can't just call getValue(). Whose
getValue() method is it, anyway?

Each time that you refer to a method, you should ask yourself whose method it is.

IPIJ || Lynn Andrea Stein

7.4 Methods 7~19

You can invoke a method by first referring to the object, then typing a period,
then the method name, as in myScoreCounter.getValue(). Sometimes, the
answer to "whose method is it?" will be "my own", that is, the method belongs to
the object whose code is being executed. As with fields, the way to say "myself"
is with the special name expression this, so the way to say "my getValue()
method" is this.getValue(). (Note the period between this and getValue() --
it is important!)
Generally, methods belong to instances of the class in which they're defined.
Occasionally, though, it may be useful to have a method that belongs to the class
itself. This corresponds to a property of the factory (or recipe), rather than one
belonging to the widgets (or cookies) produced. For example, a method that prints
out the number of widgets produced by the factory so far would be a method
belonging to the factory, not one belonging to any particular widget. Methods that
belong to the class instead of to its instances look just like regular methods,
except that they are prefaced with the keyword static. (This name is pretty
unintuitive, though it makes some sense in its historical context. Remember: In
Java, static means "belonging to the class/factory/recipe itself, not to its
instances.") A static method can be addressed by first citing the object it belongs
to, then period, then the method name: Widget.howManyWidgets(). A static
method should not be invoked using this, though, because it doesn't belong to an
instance.

Inside the method body, the name this may be treated as any other name.
it is also possible to refer to the object whose method it is as (for example, if you
want to pass it as an argument to another method).

7.4.4 Method Overloading

Just as in an interface, it is possible for a class to have multiple methods with the
same name. This is called method overloading, since the name of the method is
overloaded -- it actually refers to two or more distinct methods -- belonging to
that object. In this case, each method must have a different footprint, i.e., the
ordered list of parameter types must differ for two methods of the same object
with the same name.
When an object has an overloaded method, the particular method to be invoked is
selected by comparing the types of the arguments supplied with the footprints of
the methods. The method whose footprints best matches the (declared) types of

IPIJ || Lynn Andrea Stein

7~20 Building New Things: Classes and Objects Chapter 7

the arguments supplied is the one that is invoked. This matching is done using the
same type inclusion rules as the operator instanceof.

Method Invocation and Execution

Method invocation is an expression; it is evaluated, producing a value.
Within this expression, the body of the method is treated as a block
(sequence) statement to be executed. This sidebar summarizes this process.
1. Before the method invocation expression can be evaluated, the object
expression describing whose method it is must be evaluated. This object is
called the method's target.
2. Based on this object and the (declared) types of the argument
expressions, the method body is selected.
3. The argument expressions are evaluated and the method parameter
names are bound to the corresponding arguments. If the target is an
instance (i.e., if the method is not static), the name this is bound to the
target as well.
4. Within the scope of these name bindings, the body of the statement is
executed as a normal block except for special rules concerning return
statements.

• If, at any point within the execution of the body, a return statement is
encountered, its expression (if present) is evaluated and then the entire
method body and the scope of parameter names and this are exited
upon completion of the return statement.

• If the method has a return type other than void, the return statement is
mandatory and must include an expression whose type is consistent
with the return type. A suitable return statement must be encountered
on any normal execution path through the method body. In this case,
the value of the return expression is the value returned by the method
invocation expression.

• If the return type of the method is void, the final closing brace of the
method body is treated as an implicit return; statement, i.e., a return
with no expression. This has the effect of exiting the method body and
special name scope.

IPIJ || Lynn Andrea Stein

7.5 Constructors 7~21

7.5 Constructors
So, how do objects get created? Each class has a special member, called a
constructor, which gives the instructions needed to create a new instance of the
class. (If you don't give your class a constructor, Java automatically uses a default
constructor, which roughly speaking "just creates the instance" -- details below.
So some of the classes that you see may not appear to have constructors -- but
they all do.)

7.5.1 Constructor are Not Methods

A constructor is sort-of like a method.
1. It has a (possibly empty) parameter list enclosed in parentheses.
2. It has a body, enclosed in braces, consisting of statements to be executed.

3. Inside the constructor body, this. expressions can be used to refer to

methods and fields of the individual instance under construction.

There are several differences.

1. The name of a constructor always matches the name of the class whose
instances it constructs.
2. A constructor has no return type.

3. A constructor does not return anything; return statements are not

permitted in constructors.
4. A constructor cannot be invoked directly.

Instead, a constructor is invoked as a part of a new expression. The result of

evaluating this new expression is a new instance of the type whose constructor is
evoked.
For example:
class Pie {
might have the constructor
Pie (Ingredients stuff) {
stuff.bake();
}
}

IPIJ || Lynn Andrea Stein

7~22 Building New Things: Classes and Objects Chapter 7

In other words, to create a Pie, bake its ingredients. Note that stuff is a
parameter, just like in a method. Constructor parameters work exactly like method
parameters, and constructors take arguments to match these parameters in the
same way that methods take parameters.
But you don't invoke a constructor in the same way that you invoke a method. In
order to invoke a method, you need to know whose method it is. In order to use a
constructor, you only need to know the name (and parameter type list) of the
constructor. You invoke a constructor with a new expression as follows:
new Pie ( myIngredients )
where myIngredients is of type Ingredients.

7.5.2 Syntax
The syntax of a constructor is similar to, but not identical to, the syntax of a
method. A constructor may begin with a visibility modifier (i.e., public,
protected, or private) or one of a handful of other modifiers. Next comes the
name of the constructor, which is always identical to the name of the class. The
name is followed by a comma-separated parameter list enclosed in parentheses.
This parameter list, like the parameter list of a method, consists of type-of-thing
name-of-thing pairs. As in a method, the constructor name plus the ordered list of
parameter types forms the constructor's footprint. It is possible for a class to have
multiple constructors as long as they have distinct footprints.
After the parameter list, a constructor has a body enclosed in braces. This body is
identical to a method body -- an arbitrary sequence of statements -- except that it
may not contain a return statement. This is because constructors are not methods
that can be called and that return values of specified types; instead, a constructor
is invoked using a new expression whose value is a new instance of the
constructor class's type. The constructor body may contain any other kind of
expression or statement, however, including declarations or definitions of local
variables.
modifiers ClassName ( type_1 name_1, ... type_n name_n )
{
// body statements go here
}
For example, the NameDropper StringTransformer class might begin as follows.
Note that the constructor argument is used to initialize the private field, the
particular name that *this* NameDropper will drop.

IPIJ || Lynn Andrea Stein

7.5 Constructors 7~23

public class NameDropper extends StringTransformer

{
private String who;

public NameDropper ( String name )

{
this.who = name;
}

//etc.
Note the use of a this. expression to refer to the field of the particular
NameDropper instance being created.

This constructor could be invoked using the expression new NameDropper(

"Jean" ) or new NameDropper( "Terry" ).

IPIJ || Lynn Andrea Stein

7~24 Building New Things: Classes and Objects Chapter 7

Style Sidebar

Constructor Documentation
Although a constructor is not a method, documentation for a constructor is
almost identical to documentation for a method. Constructor documentation
should include:

• specifics distinguishing this constructor from others

• preconditions for using this constructor

• parameters required and their role(s)

• relationship of the constructed object to parameters or other factors

• side effects of the constructor

• additional assumptions and design rationale as appropriate

7.5.3 Execution Sequence

Before a constructor is invoked, the instance is actually created. In particular, any
shoeboxes or labels declared as fields of the instance are created before the
execution of any constructor code. This permits access to these fields from within
the constructor body. In addition, any initialization of these fields -- through
definitions in their declarations -- is executed at this time as well. Fields are each
created and then each initialized in textual order, but all fields -- even those
declared after the constructor4 -- are created and initialized prior to the execution
of the constructor. Once each of the instance fields is created, execution of the
constructor itself can begin.
When a constructor is executed, its parameters are matched with the arguments
supplied in the invocation (new) expression. For example, in the body of the
NameDropper constructor, the name name is identified with the particular String

4
There should be no such fields, declared after the constructor, because this makes your code
difficult to read and so is bad style. However, if any such declarations are made, they still executed
prior to the constructor itself.

IPIJ || Lynn Andrea Stein

7.5 Constructors 7~25

supplied to the constructor invocation expression. So if the constructor were

invoked with the expression new NameDropper( "Terry" ), the name name
would be associated with the String "Terry" during the execution of the body of
the NameDropper constructor. When the statement
this.who = name;

is executed, the value of the expression name is the String "Terry".

Once each of the parameter names has been associated with the corresponding
argument, the execution of the statements constituting the constructor's body
proceeds in order (except where that order is modified by control-flow
expressions such as if or while). These statements may include local variable
declarations; in this case, the name declared has scope from its declaration to the
end of the enclosing block, just as in a method. When the end of the constructor is
reached, execution of the constructor invocation expression is complete and the
value -- the new instance -- is produced.
Because a constructor body may not contain a return statement, it is not possible
to exit normally from any part of the constructor body except the end. Judicious
use of conditionals can simulate this effect, however.

7.5.4 Multiple Constructors and the Implicit No-Arg

Constructor
A class may have more than one constructor as long as each constructor has a
different footprint, i.e., as long as they have different ordered lists of parameter
types. So, for example, NameDropper might also have a variant constructor that
took a descriptive phrase as well as name:
public NameDropper ( String name, String adjective )
{
this.who = adjective + " " + name;
}
In this case, new NameDropper( "Marilyn Monroe" ) would create a
NameDropper that started every phrase with "Marilyn Monroe says..." while
new NameDropper( "Norma Jean", "My dear friend" )

(i.e., NameDropper(String, String) )would attribute everything to "My dear

friend Norma Jean..."
If -- and only if -- a class contains no constructors at all, a default constructor is

IPIJ || Lynn Andrea Stein

7~26 Building New Things: Classes and Objects Chapter 7

assumed present. This default constructor takes no arguments and does nothing
beyond creating the object (and initializing the fields if they are defined in their
declarations).
If there is even one constructor, the implicit no-arg constructor is not assumed.
This means that if you define a constructor such as the one for NameDropper,
above, that takes a parameter, the class will not have a no-arg constructor (unless
you define one).
[Hazard: This can cause a problem when extending a class, if you're not careful.
See chapter on Inheritance.]

7.5.5 Constructor Functions

Often, one of the main functions of a constructor is to initialize the state of the
instance you're creating. Some initializations don't require a constructor; they can
happen when the field is declared, by using a definition instead of a simple
declaration:
class LightSwitch {
boolean isOn = false;
}
In this case, each LightSwitch instance is created in the off position. In this kind
of initialization, each instance of the class has its field created with the same
initial value.

Contrast this with the following example, in which the initial value of the name
field isn't known until the particular Student instance is created.
class Student {
String name;

Student( String who ) {

this.name = who;
}
}
In this case, a constructor is used to explicitly initialize the field named name.
When the initial value of a field varies from instance to instance, it cannot be
assigned in the field declaration. Instead, it must be assigned at the time that the
particular instance is created: in the constructor.
A constructor (or a method body) can also refer to properties of the class object
itself. Recall the Widget class, which kept track of how many instances had been

IPIJ || Lynn Andrea Stein

7.5 Constructors 7~27

created. When the constructor is invoked, it can increment the appropriate field:
class Widget {
static int numInstances;

static int howManyWidgets(){

return Widget.numInstances;
}

Widget(){
Widget.numInstances = Widget.numInstances + 1;
}
}
Note that the constructor is not declared static (Constructors don't properly
belong to any object) but that it refers to a static field. Note also that the static
field is referred to using the class name (Widget), not using this. We've also
filled in the static method referred to above.
Finally, note that there is no explicit return statement in a constructor. A
constructor is not a method, and it cannot be invoked directly. Instead, it is used in
a construction expression, with the keyword new: new Widget() is an expression
whose type is Widget and whose value is a brand new instance of the Widget
class, for example.

Q. Construct a Counter class which supports an increment (increase-by-one)

method. Where does the Counter's initial value come from?

IPIJ || Lynn Andrea Stein

7~28 Building New Things: Classes and Objects Chapter 7

Style Sidebar

Capitalization Conventions
By convention, the first letters of all class and interface names are
capitalized. Since constructor names match their classes, constructor names
also begin with capital letters. Java file names also match the class (or
interface) declared within, so Java file names begin with a capital letter.
All other names (except constants) begin with lower case letters. In
particular, the names of Java primitive types begin with lower case letters,
as do fields, methods, variables, and parameters.
After the first letter, mixed case is used, with subsequent capital letters
indicating the beginnings of intermediate words: e.g., ClassName and
instanceName.

The exception to the above conventions is the capitalization of constants

(i.e., static final fields; see below). The names of constants are entirely
capitalized. Intermediate words are separated using underscores (_):
CONSTANT_NAME.

Summary
• A Java class is a Java type.

• Each (public, top level) class must be defined in a separate file whose
name matches the class name.

• An instance of a class is an object whose type is that class.

• If a class implements an interface, its instances must satisfy the interface's

promises.

• Classes have methods, fields, and constructors.

• In a class, methods typically have bodies specifying how to carry out the
method. (Otherwise, the method is abstract, and so is the class.)

IPIJ || Lynn Andrea Stein

 Summary 7~29

• Every method belongs to some object. Unless declared static, a method

belongs to (each of) a class's instances, not to the class itself.

• A field declares (and perhaps also defines) a name whose scope is the
class body (i.e., any methods, fields, or constructors in the class body) and
whose lifetime is the lifetime of the instance it belongs to.

• Every field belongs to some object. Unless declared static, a field

belongs to (each of) a class's instances. Each instance has its own copy of
the field, i.e., its own unique label with that field's name and type.

• In Java, this is a special name, bound in any non-static member, that

refers to the instance whose instructions are being followed. An instance
can refer to its own methods and fields by saying this.methodName(...)
or this.fieldName, or to itself by the name expression this.

• A constructor gives instructions for how to create an instance of the class.

• The class itself is an object. (It is an instance of the class Class.) Fields
and methods declared static belong to the class object itself and are
properly referred to using ClassName.methodName(...) or
ClassName.fieldName.

Exercises
1. Consider the following definition:
public class MeeterGreeter
{
private String greeterName;

public MeeterGreeter( String name )

{
this.greeterName = name;
}

public void sayHello()

{
Console.println( "Hello, I'm " + this.greeterName
);
}

IPIJ || Lynn Andrea Stein

7~30 Building New Things: Classes and Objects Chapter 7

public void sayHello( String toWhom )

{
Console.println( "Hello, " + toWhom
+ ", I'm " + this.greeterName
);
}

public String getNameWithIntroduction ( String toWhom

)
{
// ****
this.sayHello( toWhom );
return this.greeterName;
}
}
Now assume that the following definition is executed:
MeeterGreeter pat = new MeeterGreeter( "Pat" ),
terry = new MeeterGreeter( "Terry" );
a. What is printed by pat.sayHello()? What is returned? Which method is
invoked?

b. What is printed by new MeeterGreeter( "Chris" ).sayHello(

"Terry" )? What is returned? Which method is invoked?

c. What is printed by terry.sayHello( "Pat" )? What is returned? Which

method is invoked?

d. Assume that the expression pat.getNameWithIntroduction( "Chris"

) is being evaluated. What would the value be of each of the following
expressions if they were to appear on the ****'d line:

i. toWhom

ii. this.greeterName

iii. name

iv. this.sayHello()

v. new MeeterGreeter( "Pat" )

vi. this.getNameWithIntroduction( toWhom );

2. Now consider the following modification of the MeeterGreeter code. Assume

that we add the field definition

IPIJ || Lynn Andrea Stein

 Exercises 7~31

private static String greeting = "Hello";

We will want to make several other modifications to the MeeterGreeter code.

a. Write a changeGreeting method that allows a user to change the greeting

string.
i. What arguments should this take?
ii. What should it return?
iii. What should its body say?
iv. To which object should this method belong?

ii. Write an expression that invokes the changeGreeting method that you
have written.
iii. Next, modify the sayHello methods to replace the fixed string "Hello"
with the a reference to the greeting field. Whose greeting field is it?
3. Define a class
whose instances each have one method,
rememberAndReturnPrevious, that takes a String and returns the String it was
previously given. Supply the first return value through the instance creation
expression. Give an example of your code in use.

IPIJ || Lynn Andrea Stein

part 3
 8
Chapter 8 Designing With Objects

Chapter Overview
• How do I design using objects and entities?
In the preceding chapters, we have seen how interfaces specify contracts and how
classes implement them. We have used expressions and statements to create
instructions that describe the processes of performing actions, making up method
and constructor bodies. And we have used names to retain an object's state even
while none of the object's methods is executing. In this chapter, we turn to the
question of how we design systems using these various tools.
The first part of this chapter looks at one simple example to illustrate how the
fields and methods of an object can be identified and implemented. Although the
example is small, the principles described here are general and will be used in the
design of any object-oriented program. This example also provides an opportunity
to look briefly at the question of privacy, or how an object separates internal
information from information that it makes available to other objects.
The next section of this chapter turns to look at three important kinds of objects
that appear in many systems. These kinds of objects -- data repositories, resource

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
8~2 Designing with Objects Chapter 8

libraries, and traditional objects -- each play distinctly different roles in any
system, and their designs reflect these roles. A fourth distinct kind of object --
animate objects -- is the topic of the next chapter.
The chapter concludes with a discussion of the ways in which different objects
and types are interrelated.

Objectives of this Chapter

• To become familiar with the identification of objects, methods, fields,

interfaces, and classes from a problem description.

• To recognize common kinds of objects and the roles that they play.

• To learn to identify opportunities to use these patterns in designing

systems.

8.1 Object Oriented Design

So far, you've seen a lot of Java how-to: how to declare, define, assign, and
invoke variables of primitive and object types, classes, object instances, methods,
and control flow. Now that you have some fluency with the basic building blocks
of Java, it is time to start looking at why each of these constructs is used and how
they are combined to build powerful programs. In this chapter, we'll look at
objects and classes; in the next, we'll continue this discussion by focusing on
instruction-followers and self-animating objects.

8.1.1 Objects are Nouns

When you are constructing a computational system, you need to build pieces of
code to play various roles in the system you're constructing. To a first
approximation, you can do this by writing down a description in English of the
system and the interactions you want to have with it (and that you want its parts to
have with one another), then mapping these things onto elements of Java. When
you do this, you will find that Java objects correspond roughly to the nouns of
your description.
To be a bit more precise, Java objects are things in your computational world, but
not all of the things are Java objects. Some of the things will have primitive types

IPIJ || Lynn Andrea Stein

8.1 Object-Oriented Design 8~3

-- numbers, for example, will probably be doubles or ints -- but most of the
things that are important enough to represent and complex enough that Java
doesn't have a built-in type for them will be objects in your world. This means
that you will have to define a Java class which describes what this type of object
is (more below).
For example:
A counter has a number associated with it. When it starts out, the number is 0.
You can increment the counter, and each time you do so, the number goes up
by one. At any time, the counter can also be asked to provide the current value
of its associated number.
The nouns in this paragraph are counter and number. (And you, but we'll assume
that you either refers to the user, which we don't need to implement, or to some
other component outside of the current system.) The counter will be a Java object;
we can use an int for the number since it isn't asked to do anything, just to be
there.

8.1.2 Methods are Verbs

When you write down your description, you will also find that there are lots of
things that these objects do to/with/for one another, or that you want to do
to/with/for them. These things correspond to the verbs in your English
description, and they are the methods of your Java objects. Every verb has a noun
associated with it -- its subject -- and every Java method belongs to some object.
In our basic counter example, the verbs are increment (and its alternate form, goes
up by one) and provide (as in "provide the current value"). Increment is
something you need to be able to do to the counter object. We could handle
provide in either of two ways: we could give the counter someone or something to
provide the value to, or we could ask it. We will adopt the second of these
options, though we will return to the first option in the chapter on Communication
Patterns. This means that the counter object is going to have to have (at least)
these methods.

8.1.3 Interfaces are Adjectives

Interfaces and classes are both types. How do you know when to use which one?
As a general rule of thumb, names (including parameters, fields, and local
variables) should generally be declared using an interface type whenever possible.
Constructor expressions, of course, require a class type.

IPIJ || Lynn Andrea Stein

8~4 Designing with Objects Chapter 8

Interfaces are good at capturing commonality. It is almost always useful to define

an interface corresponding to the set of features of your objects that would hold
for any implementation of them. For example, the need for any counter to have an
increment method and a getValue method makes these good properties to
encapsulate in an interface. No matter how we implement the counter, these
method properties will hold. In contrast, the fact that most counters will keep
track of their value using a field (perhaps even an int field0 is an implementation-
specific detail that cannot be expressed in an interface. An interface talks about
what an object can do, not about how it accomplishes these tasks.

A Counting interface might say:

interface Counting
{
void increment();
int getValue();
}
Why would we use this? By referring to any actual counters by their interface
type -- Counting -- rather than their implementation types, we make it possible
for the implementor to modify details of the implementation -- or, even, to change
which underlying implementation we're using -- without changing the code that
uses it. We also avoid committing to any specific aspects of the implementation --
such as the representation of the current value through a long or a double or even
a String -- that really shouldn't matter to the user of the class.
The name of this interface is only moderately adjectival, but most interfaces are
named using adjectives. For example, we have seen Resettable and will soon
see Animatable, Runnable, and Cloneable. We could almost call Counting
Incrementable instead.

8.1.4 Classes are Object Factories

So if the nouns are objects, the verbs are methods, and the interfaces are
adjectives, what is left for the classes? Java classes are kinds of objects. They
correspond, roughly, to machines (or factories) that tell you (or Java) how to
make new objects, not (necessarily) to anything explicitly in your English
description.

For example, the class BasicCounter is something that tells Java how to make
a new BasicCounter(). It doesn't appear explicitly in the English description, but
parts of the description are about it and other parts imply things about what it
must say. The phrase "When it starts out, the number is 0" talks about initial
conditions for BasicCounter objects; the class is the thing responsible for

IPIJ || Lynn Andrea Stein

8.1 Object-Oriented Design 8~5

establishing these (since it is the factory where Counters are made).

For that matter, the class is responsible for establishing what the parts of an object
are. "Parts" here refers to methods and fields. What are the pieces of a
BasicCounter object? In this case, its number (and maybe an associated display).
What are the things a BasicCounter can do (or that we can do with/to a
BasicCounter)? increment and provide its value, at least. So the class
BasicCounter will most likely include a number field (which is going to be of
type int), as well as methods corresponding to incrementing and value-providing.
It will also initialize the number field to 0.

Q. Is this a static or dynamic initialization? Where does it take place?

IPIJ || Lynn Andrea Stein

8~6 Designing with Objects Chapter 8

Style Sidebar

Class and Member Documentation

This list summarizes many of the main features that good documentation
will capture about classes and their members. For more detail, see the
specific documentation sidebars in the previous chapter.

• methods

• parameters: type and role

• return value: type and role

• function: why you'd do it

• "side effects": what else it does (esp. values changed)

• fields

• type and role

• how it changes & which methods use/change it

• constraints and interdependencies

• constructors

• parameters: type and role

• relation of parameters to the particular instance produced

• "side effects": what else it does (esp. values changed)

• class

• its interface, especially key methods and fields & how they
interact

8.1.5 Some Counter Code

Here is a very basic implementation of the counter class:

IPIJ || Lynn Andrea Stein

8.1 Object-Oriented Design 8~7

class BasicCounter implements Counting

{
int currentValue = 0;
void increment()
{
this.currentValue = this.currentValue + 1;
}

int getValue()
{
return this.currentValue;
}
}
Some notes on this code:

• The class is a factory for making BasicCounters. Its body talks about
what each individual BasicCounter looks like, not about the factory
itself.

• Each individual BasicCounter has its own currentValue field. Each one
starts out with the value 0, but they can change independently: each
currentValue field belongs to a specific BasicCounter.

• We haven't included a constructor because, in this case, Java's default

constructor does what we want. This is in general true when there is no
dynamic initialization (each instance starts out in the same state).

• The increment and getValue methods are methods that belong to each
BasicCounter instance. In each case, they refer to the currentValue
field of that BasicCounter instance. We note this by using the java
keyword this.

Someone wanting to use a BasicCounter could now do so by invoking an

instance creation expression with this BasicCounter factory:
new BasicCounter()
This expression is probably more useful if we embed it inside another expression
or statement, e.g.,
Counting myCounter = new BasicCounter();
Note the use of the interface type when declaring the name, but the class type
within the construction expression.

Now we can ask myCounter to increment itself or to give us its value:

myCounter.increment();

IPIJ || Lynn Andrea Stein

8~8 Designing with Objects Chapter 8

Console.println( myCounter.getValue() );
// prints 1
myCounter.increment();
myCounter.increment();
myCounter.increment();
Console.println( myCounter.getValue() );
// prints 4

Final
A name in Java may be declared with the modifier final. This means that
the value of that name, once assigned, cannot be changed. Such a name is,
in effect, constant.
The most common use of this feature is in declaring final fields. These are
object properties that represent constant values. Often, these field are static
as well as final, i.e., they belong to the type object rather than to its
instances. Making a constant static as well as final makes it easy for other
objects to refer to this value. It is appropriate for static final fields to be
declared public and to be accessed directly by other objects. Static final
fields are the only fields allowed in interfaces.
In addition to final fields, Java parameters and even local variables can be
declared final. A final parameter is one whose value may not be changed
during the execution of the method. A final variable is one whose value is
unchanged during its scope, i.e., until the end of the enclosing block.1
Java methods may also be declared final. In this case, the method cannot be
overridden in a subclass. Such methods can be inlined by the compiler, i.e.,
the compiler can make these methods execute more efficiently than other
non-final methods. A static method is implicitly final. An abstract method
may not be declared final.
Java classes declared final cannot be extended (or subclassed).

1
Final fields and parameters are unnecessary unless you plan to use inner classes. They may,
however, allow additional efficiencies for the compiler, and in any case they cannot be
detrimental.

IPIJ || Lynn Andrea Stein

8.1 Object-Oriented Design 8~9

8.1.6 Public and Private

When we defined the BasicCounter class, we intended that the rest of the world
would interact with its instances (things produced by the class BasicCounter
factory) only through increment() and getValue(). But there is nothing about
the code we've written that prevents someone from defining a BasicCounter name
and then changing the value of that BasicCounter instance's currentValue field.
For example, it would be perfectly possible for another object to say
BasicCounter anotherCounter = new BasicCounter();
anotherCounter.currentValue = anotherCounter.currentValue +
1;
instead of
anotherCounter.increment();
This would be rather rude of it (and very bad style), but it is technically possible
and unfortunately done all of the time. Using the interface type -- Counting --
rather than the class type -- BasicCounter -- is one way to avoid this, and this is
yet another reason why it is generally better to use the interface type. But as the
implementor of BasicCounter, we can't require that it always be treated as a
Counting instead of as a BasicCounter. Further, coercion (such as
(BasicCounter) myCounter) will get you around the interface-associated
name.2 Class designers don't always get to choose how users of the class will
interact with it or as what type they'll choose to treat it.
We can take a stronger position on the matter of direct field access, though. We
can, in fact, prevent direct field access by protecting the currentValue field of

2
Specifically, it would be legal, if longwinded, to say
((BasicCounter) myCounter).currentValue

= ((BasicCounter) myCounter).currentValue + 1;

IPIJ || Lynn Andrea Stein

8~10 Designing with Objects Chapter 8

each BasicCounter instance. We do this by changing the declaration of the field

in class BasicCounter:
class BasicCounter {
private int currentValue = 0;

void increment ...

}
By making currentValue private to class BasicCounter, only the instance of
BasicCounter itself can access the currentValue field. Now, this rudeness on
the part of the calling object would simply be impossible. (The compiler would
complain that the calling object could not access BasicCounter's private field
currentValue.)

In general, it's a good idea to define fields as private when you don't want them
to be accessed directly by other objects. You can also define private methods,
which are generally things an object uses for its internal computations but not
intended to be used from outside the object. Private things are a part of the class's
or its instances' own internal representations and machinations; they are not to be
shared.

Any member, not just a field or a method, can be private. You can even define
private constructors. Although this may seem like an odd thing to do, it actually
isn't all that strange. It means that the class object (along with any instances it
creates) maintains complete control over whether and when new instances can be
created. The class can refuse to create any instances, or it can create just one
instance and return this any time someone asks for a new one (using a special
method the class defines for this purpose, such as getInstance(), not the (private)
constructor), or it can ask for the secret password before creating an instance if it
(or its designer) wants to.

The opposite of private is public. You should declare things public when you
want them to be accessible from any part of anyone's code. You can also declare
classes and interfaces to be public, in which case they must be defined in a file
whose name is the same as the name of the class or interface, plus .java.

If you don't declare something private or public, it is in an intermediate state.

There are actually two intermediate states, protected and the default state.
These two are in fact equivalent to one another and to public unless you use
packages, a Java feature that we will explore in the chapter on Abstraction. Until
then -- until you are building complex enough code that you need to subdivide it
at finer levels than all-or-none -- you should use public and private all of the
time, i.e., everything in your code should be one or the other.

IPIJ || Lynn Andrea Stein

8.2 Kinds of Objects 8~11

8.2 Kinds of Objects

Objects are the nouns of programming: the people, places, and things. Nouns do a
lot of different things in the world and, similarly, objects to a lot of different
things in programs. In this section, we take a closer look at several kinds of
objects, their typical construction, and why you might use them. The objects
discussed here are all relatively passive; they do nothing until asked. In the next
chapter, we go on to look at active objects, objects that have their own instruction
followers.

8.2.1 Data Repositories

A data repository is a very simple object that exists solely to hold a set of
interrelated data. The data repository object simply glues these things together,
providing a convenient way to deal with the grouped data as a single unit.
One example of a data object might be a postal address. This might consist of a
street address, a city or town, a state or province, a postal code, and a country.
There isn't really much that you would do with an address, other than pull out the
individual pieces or maybe modify one or more of the pieces. (For example, the
postal service just changed my postal code, so although my address object stayed
the same, its postal code field needed to change.) The whole address is useful and
meaningful in a way that the pieces individually are not, so it is often convenient
to be able to package these pieces together and to pass the address object around
as a single unit.

Here is some code for a very simple address object. Note that this code has some
aesthetic problems, which we will address shortly.
public class OversimplifiedAddress {

IPIJ || Lynn Andrea Stein

8~12 Designing with Objects Chapter 8

public String streetAddress,

city,
state,
postalCode;
}
// Problems with this class:
// Non-final fields ought not to be public.
// Fields ought to be initialized by (missing) constructor
or default.
Like instances of this OversimplifiedAddress class, data repository objects exist
to hold a collection of pieces together. Typically, each of these pieces is
represented by a field of the object. The simplest form of data repository object is
one -- like an instance of the Oversimplified Address class -- that has a set of
public fields and nothing else. However, this form is not recommended.
One object should never access another object's fields directly.3
In our simple address object, we violated this rule. To fix that class definition, we
should instead make each of these fields internal to the object. So that other
objects can access these fields, we need to provide getter and setter methods to
access them. A getter method is a method that returns the value of a field. A
setter method is one that has a single parameter, the new (desired) value of the
field; evaluating this method modifies the state of the object to reflect this new
value. Getter methods are sometimes called selectors and setter methods are
sometimes called mutators. It is common to use the name of the field prefixed
with get as the name of the getter method and the name of the field prefixed with
set as the name of the setter method.
Note that getter and setter methods need not correspond one to one with fields.
Instead, a setter method may change the value of more than one field; a getter
value may return an object that encapsulates more than one field value.
Alternately, a getter or setter may make reference to an apparent field that doesn't
actually exist per se.
We can improve the address class by modifying it to use getter and setter
methods. Only one pair of these methods is shown here, although the complete

3
Actually, this should read "One object should never access another object's non-final fields
directly." Final fields are in effect constants; the reasons for objecting to field access do not apply
to read-only accesses to a constant.] Instead, an object should provide methods for accessing its
fields. [Teacher's note: Where getter methods are simply long-winded ways of doing field access,
a good compiler should be able to inline this code. In Java, this can be done when the getter
method is declared final.

IPIJ || Lynn Andrea Stein

8.2 Kinds of Objects 8~13

class definition would presumably contain four pairs of getter and setter methods.
public class BetterAddress {
private String streetAddress,
city,
state,
postalCode;
....
public void setPostalCode( String code )
{
this.postalCode = code;
}

public String getPostalCode()

{
return this.postalCode;
}
}
// Remaining problems with this class:
// Fields should be initialized by (absent) constructor or
default.
Why shouldn't one object access the fields of another directly? (Why should you
use getter and setter methods?)
1. Methods separate use from actual (internal) representation. The user of a
class shouldn't need to know (or care) how information is actually
represented inside the class. For example, US postal codes are commonly
written as five-digit numbers. A different implementation of addresses
intended for use only in the US might actually represent the postalCode
field using an int instead of a String. The getter and setter methods of this
USAddress object could do the conversion for the user:
public String getPostalCode()
{
return new String( this.postalCode );
}
We might have an interface (say, GeneralizedAddress) containing (an
abstract version of) this method. Both USAddress and BetterAddress
classes could implement the GeneralizedAddress interface, even though
they use different internal representations.
Another variant of separating use from actual representation involves
getter and/or setter methods for fields that don't actually exist. For
example, it might be useful for these address objects to have a
getAddressLabel field, which would return the multiline String containing
the complete address suitable for printing on an envelope. This getter

IPIJ || Lynn Andrea Stein

8~14 Designing with Objects Chapter 8

method would automatically calculate the appropriate value from the

individual fields of the address object; there is no actual field
corresponding to the information that this getter field provides.
public String getAddressLabel()
{
return new String( this.streetAddress + "\n"
+ this.city + ", "
+ this.state + " "
+ this.postalCode + "\n"
+ this.country );
}
Getter and/or setter methods like this one, which do not correspond to any
actual field of the object, are sometimes called virtual fields. To the user
of the object, it looks as though there's a field there. Whether that field
actually exists or just looks like it is nobody's business but the
implementing object's.
2. Methods can provide additional behavior, including access control and
error checking. For example, BetterAddress could be augmented with an
internal list of the states or provinces within each country. If the setter
method were given an argument that didn't match one of the appropriate
values, it could report an error. The most extreme case of this is a read-
only field, one in which no non-private setter method is supplied. This
prevents a user of the object from ever modifying the value of that field.4
Another example of augmenting the behavior of a setter might involve
automatically filling in the city and state whenever a postal code is
entered. The postal code's setter method could look up the appropriate city
and state information based on the postal code supplied and propagate this
information to these other fields as well, saving the user the work of
providing this information separately. (Some mail order companies do this
now: you give them your postal code, and they tell you what city and state
you live in!)
There are other reasons why methods, rather than fields, are a good idea. Some of
these involve issues that will not be discussed until later in this book. For
example, if you are using inheritance (Chapter 9), methods give you additional
flexibility and more appropriate behavior than fields. There are also issues that

4
Note that a read only field is different from a constant (final) field. A read-only field can be
changed by its owning object, but not by anyone else. A final field's value, once set, cannot be
changed. This is enforced by the Java compiler.

IPIJ || Lynn Andrea Stein

8.2 Kinds of Objects 8~15

arise when two or more people try to use the same things at the same time
(covered in the chapter on Synchronization); the tools that you can use to address
these issues generally rely on methods rather than fields.
One of the most common reasons for a pure data repository class is to allow
simultaneous return of multiple interrelated values. An example of this type is the
Dimension class in the java.awt package. This class exists so that its instances can
hold both (horizontal and vertical) coordinates, e.g., of a window size. This allows
them to be simultaneously returned from a method such as Window's getSize()
method. If getSize() weren't able to return a data repository type such as
Dimension, you'd first have to invoke a method that returned the Window's
horizontal dimension, then one that returned its vertical dimension. If the
Window's size changed in between these two method invocations, your two
individual dimension components would combine to produce a nonsensical value!
Pure data repository objects are actually quite rare in good object-oriented design.
This is because most objects do more than hold some state. The extensions we've
described above, including propagation of changes, virtual fields, and access
control already begin to expand the data repository idea. In the next subsection,
we look at objects that exist to provide behavior without state. In the following
subsection, we will return to objects that contain both data and more interesting
behavior.

8.2.2 Resource Libraries

We have seen objects that hold together an interrelated set of data. Sometimes, an
object exists to hold together an interrelated set of methods. If these methods are
not tied to any particular state of the world, they may usefully be grouped together
within a (generally non-instantiable) class that exists solely for this purpose.
Consider, for example, the square root function. It is a useful function, and it is
often convenient to have it lying around. But, in Java, any function must be a
method belonging to a particular object. Java has a square root method; but whose
method is it?
The answer to this question is that sqrt() belongs to a special class called Math.
Math is a class that exists precisely so that you can use its methods, like sqrt().
Math is a canonical function library; it has no use beyond being the place to find
its member functions. It exists to provide the answer to the question, "Whose
method is sqrt()?"
Because Math is a place to find these functions, it is not a class of which you

IPIJ || Lynn Andrea Stein

8~16 Designing with Objects Chapter 8

would want to make instances. Instead, Math has only static methods and static
fields. This means that you can use its methods and data members through the
class object (Math) itself.For example, a typical method is Math.sqrt(double d),
which takes a double and returns a double that is the square root of its argument.
Without the Math class to collect it and other mathematical functions, it is hard to
imagine to whom this sqrt function could belong. Math exists so that there is a
place to collect sqrt and a number of other abstract mathematical functions.
The Math class has static methods for the trigonometric functions, logarithms and
exponentiation, various flavors of rounding, and very simple randomization. Math
also has two (static final, i.e., constant) fields: E and PI, doubles representing the
corresponding mathematical constants. See the sidebar on Math for details.

Q. Since it's not instantiable, why couldn't Math be an interface?

Math -- the class, with its static methods and fields -- is a very useful class.
However, it wouldn't make sense to create any instances of it. In fact, Math has no
publicly available constructor. This is a common way to prevent a class from
being instantiated: give it only a private constructor. In general, a resource
collection is the kind of object of which wouldn't have any use for multiple
copies.
Another resource collection class is cs101.util.Console. Console -- documented in
a sidebar in the chapter on Things, Types, and Names -- provides console input
and output through the print(), println() and readln() methods. These, too, are
static methods of the class; you don't need to create a Console instance before
using these methods. (In fact, like Math, Console is a class of which you can't
create instances.) The resources provided by cs101.util.Console (streams) are a bit
more complicated than the resources provided by java.lang.Math, and in the
chapter on networking and I/O we will explore these issues in greater detail. The
Console class is describe more completely in a sidebar of chapter 3.
Other classes that provide static collections of resources (whether functions or
otherwise) include java.lang.System, cs101.util.MoreMath, and cs101.util.Coerce.

IPIJ || Lynn Andrea Stein

8.2 Kinds of Objects 8~17

class Math
The built-in Java class Math may be the canonical resource library. It
contains two (static) fields, Math.E and Math.PI, both doubles,
corresponding to the mathematical constants e and pi, respectively.
Math also contains a host of useful mathematical functions, again all static.
Each of the following methods takes a double as an argument and returns a
double:

cos cosine of its argument acos arc cosine of its argument

sin sine of its argument asin arc sine of its argument

tan tangent of its argument atan arc tangent of its argument

Math.E raised to the power of its Logarithm base Math.E of its

exp log
argument argument

smallest double corresponding to

sqrt square root of its argument ceil an integer value that is larger than
its argument

largest double corresponding to

double corresponding to the
floor an integer value that is smaller rint
integer value nearest its argument
than its argument

Math.abs takes a double, a float, a long, or an int, and produces a value of

the same type as its argument that is guaranteed to be non-negative.

Math.max and Math.min each take two arguments of the same type (both
double, float, long, or int). max returns the larger of its arguments; min the
smaller.

Math.round takes a double and returns the long closest in value to its
argument.
Math.pow takes two doubles and yields the value of the first raised to the
power of the second. (Math.pow( base, expt ) = baseexpt.)
Math.random takes no arguments and returns a double equal to or larger
than 0.0 and strictly smaller than 1.0.

IPIJ || Lynn Andrea Stein

8~18 Designing with Objects Chapter 8

There are a few other Math methods not included here. In addition, there
are extra mathematical functions (including more flexible and powerful
randomization) available in the package java.math. For these additional
methods, see the Java API documentation on the Javasoft web site.

8.2.3 Traditional Objects

Some objects, like data repositories, exist primarily to bundle together certain
pieces of data. Other objects exist primarily to hold stateless, general-purpose
functional behavior. Most objects fall into neither of these categories. Instead,
most objects represent things with both state -- what happens to be true of them
Right Now -- and behavior -- how that object can change over time. Some of
these objects, like Windows, Buttons, and Menus, have visual manifestations.
Other objects, like the ones that represent Strings or URLs, are more obviously
internal to programs. Many of the objects that you create will be of this kind.
A String is an object that keeps track of the sequence of characters of which it is
composed, so somewhere inside the String object must be data that corresponds to
those characters. But a String is not simply a data repository; it has a diverse set
of methods. What kinds of things might you want to do with a String? Certainly
look at some of the characters, which you can do using the String's charAt(int
index) method. Java's String class provides additional methods, though, which
allow you to do more than simply look at parts of the String. For example, there is
toUpperCase(), which returns a String just like the one whose method you
invoke, but with all letters in upper case. (For example, "Hi
there".toUpperCase() returns a String that would print out as "HI THERE".)
String's toUpperCase() method is neither a selector nor a mutator. More
complete descriptions of the String class and its methods are included in the
sidebar on the String class in the first Interlude.
Another kind of traditional object that we've seen is a counter. This object has
internal state (whatever the current count is set to) and methods providing access
to this state (e.g., increment() and getValue()). The methods can't work
without the state; the state isn't directly accessible, but provides the basis for
method behavior. This is an extremely typical kind of object.
Here is some code implementing a slightly more sophisticated Counter class than
the one described at the beginning of this chapter. In addition to the functionality
provided by that BasicCounter class, this class implements the Resettable

IPIJ || Lynn Andrea Stein

8.2 Kinds of Objects 8~19

interface, i.e., provides a reset() method.

public class Counter implements Counting, Resettable
{
private int currentValue;

public Counter()
{
this.reset();
}
public void increment()
{
this.currentValue = this.currentValue + 1;
}

public void reset()

{
this.currentValue = 0;
}

public int getValue()

{
return this.currentValue;
}
}
The two methods -- increment() and reset() -- rely on the current state (count)
of the individual instance whose methods they are. Two different counters can
have two different states (e.g., one can have count 4 and the other count 27).
Incrementing the first will have a different effect (producing 5, etc.) from
incrementing the second (which produces 28). Resetting one will not reset the
other. Increment() and reset() make no sense without reference to the
particular counter instance they're incrementing or resetting. This relationship
between state (data members) and methods is typical of "traditional" objects.

IPIJ || Lynn Andrea Stein

8~20 Designing with Objects Chapter 8

Traditional objects are exemplified by the following properties:

• Each instance has its own state.

• This state is not directly accessible. Instead, it provides the basis for
method behavior.

• Method behavior is dependent on the internal state of a particular instance.

• State plus behavior, packaged together, provide a single logical unit.

8.3 Types and Objects

8.3.1 Declared Type and Actual Type
What happens when we take an object of one type and treat it as though it had
another type? One common example of this that we've seen is using an interface-
type name to hold an object. The object is an instance of some class. The name
says that it's in instance of some interface. The interface provides a much more
limited view of the object than the actual implementation. Does this change the
object? What happens when we ask whether the object is an instanceof its class,
for example.
The answer is that the object is the same object no matter what its declared type
(e.g. the declared type of the name that may be holding it, or of the method that
may return it, or wherever else its type may be declared). It can do all of the same
things regardless of its declared type. And it responds the same way when asked
whether it is an instanceof its class, regardless of whether its declared type is
some more specialized interface.
For example, if we take an instance of the Counter class defined above, with its
reset(), increment() and getValue() methods, and assign it to a name of type
Counting (an interface with only increment() and getValue() methods), we haven't
actually changed the Counter instance:
Counting count = new Counter();
If we ask whether
count instanceof Counter
this is true. Of course
count instanceof Counting

IPIJ || Lynn Andrea Stein

8.3 Types and Objects 8~21

is also true. But

count instanceof BasicCounter
is false, given the definitions earlier in this chapter.
Using a Counting name instead of a Counter name does have some effect, though.
First, we may not know about the Counter type. In this case, we are limited to
treating count as though it were a Counting, not a Counter. For example, we
couldn't call its reset() method, because Countings don't have reset() methods.
Even if we did know about Counters, we'd have to explicitly cast count to be a
Counter before we could use its Counter-specific properties:
( (Counter) count ).reset();
So an interface provides a limited view without limiting the actual object.

8.3.2 Use Interface Types

When declaring names and otherwise using objects, you should generally use
interface types rather than class types. This allows the implementation of objects
to vary independently of their use. It also allows different versions of the object to
be used without dependence on unnecessary or possibly mutable properties. An
interface allows common behavior to be abstracted and relied on. An interface can
also be used to allow for future abstraction and variation, such as the Counting
interface that allowed for the creation of a Timer.
For example, suppose that we are building a video game. The outer window of the
video game is likely to be the same whether the game is Pong or Battleship or
SpaceInvaders. It has controls such as start, stop, reset, and pause. What exactly
happens when these controls are invoked depends on the particular game that is
displayed in this window. But we want to build a generic DefaultGameFrame
window that doesn't have to rely on the particular type of game that it will hold.
We can accomplish this using an interface.
public interface GameControllable
{
public void start();
public void stop();
public void reset();
public void pause();
public void unpause();
}
Now, the DefaultGameFrame can refer to the game using the type
GameControllable. As long as Pong or Battleship or SpaceInvaders implements

IPIJ || Lynn Andrea Stein

8~22 Designing with Objects Chapter 8

GameControllable, any of these games can be used inside the DefaultGameFrame.

When the DefaultGameFrame's reset control is invoked, DefaultGameFrame
simply calls its GameControllable's reset() method. If the GameControllable
happens to be Pong, it will bring the paddles back to rest and set the scores to 0. If
the GameControllable is space invaders, the player will begin again with a full set
of ammunition and plenty of aliens to shoot.

8.3.3 Use Contained Objects to Implement Behavior

One object can use another to provide behavior on the first object's behalf. For
example, we might have a Clock object that provides a getTime() method and a
setTime() method. We might also have a VCR object that includes among its
functionality getTime() and setTIme(). Should the VCR implement its own
getTime() and setTime() methods? This seems awfully inefficient. Or should the
VCR reuse the Clock's getTime() and setTime() methods directly? (We will see a
mechanism by which this can be accomplished in the chapter on Inheritance.) The
problem with this solution is that the VCR isn't really a Clock (or a kind of
Clock). Instead, the VCR can provide these methods by having a Clock inside it.

For example, the code for the VCR might say (in part):
public class VCR
{
private Clock clock;

public Time getTime()

{
return this.clock.getTime();
}

public void setTime( Time t )

{
this.clock.setTime( t );
}

// etc.
}
In this way, the VCR provides access to the Clock's methods indirectly. This
reuse of behavior by inclusion is a very powerful mechanism. In this case, the
VCR might be providing access to the full set o Clock's methods. In another case,
the including class might only provide a subset of the included class's methods, or
it might provide a superset by combining those methods in different ways. The
including class and the included class can even implement a common interface

IPIJ || Lynn Andrea Stein

8.3 Types and Objects 8~23

(such as TimeStorer) so that code that uses one or the other can't really tell the
difference so long as it only uses the interface's methods.
The DefaultGameFrame and GameControllable described above are similar.
When the DefaultGameFrame is asked to perform a reset (or a start or a stop
or...), it passes this request along to the GameControllable. In that case, the use of
an interface type -- GameControllable -- for the included object increases the
flexibility and usability of the including class.

8.3.4 The Power of Interfaces

Why are interfaces so good at providing this flexibility? Because and interface is
all about the contract an object makes and not about implementation. By relying
on an interface, you defer any dependence on implementation details that might
not be true of another implementation. This independence from implementation-
specific details is enforced by the compiler, which will not let you rely on
properties of an object specified by its interface type beyond those explicitly
declared in the interface.
An object can also implement many different interfaces. In this case, it can be
"seen" by other objects through each of these different interface types. Each
interface type provides a different view of the object. By controlling these
interfaces, a programmer controls the view that the object's users have of that
object.
Reliance on interface types doesn't work perfectly, though. For example, a
resource library such as Console or Math doesn't have an interface type. This is
because resource libraries are typically non-instantiable classes. Only instances
can have interface types.

Chapter Summary
• In an informal description of the program, nouns generally correspond to
objects or to fields, methods to verbs, and interfaces to adjectives.

• Classes are the factories from which objects are created.

• Interface types provide a valuable layer of abstraction, allowing the

IPIJ || Lynn Andrea Stein

8~24 Designing with Objects Chapter 8

implementation to vary without affecting the use.

• Members, classes, and instance marked public are accessible from

anywhere within a program. Members marked private are only accessible
within their defining class or instance.

• A data repository object exists to glue together a set of interdependent

data. It has fields corresponding to this data and methods that allow you to
read and modify this data.

• A resource library exists to hold a collection of methods or system-wide

resources. Generally, a resource library supplies these methods and
resources statically, i.e., it is not a class that is ever instantiated.

• Traditional objects mix both data and methods. These objects provide the
kind of integrated state-dependent behavior that we expect of real world
objects.

Exercises
1. Design and implement a class called Time that keeps track of the hour and
minute together. Give it a nextMinute method that returns another Time, a minute
later. How do you access the fields of Time objects?
2. Design and implement a class that provides IntegerArithmetic functions add(
int, int ), sub( int, int ), mul( int, int ), and div( int, int ). You can give it any other
methods you think might be useful. What doe s its constructor do? Why do you
think that Java doesn't have such a class?
3. Design and implement a 2DVector class representing vectors in the plane.
Include sum, difference, and product methods.

IPIJ || Lynn Andrea Stein

 9
Chapter 9 Animate Objects

Chapter Overview
• How do I create an object that can act by itself?
This chapter builds on the previous ones to create an object capable of acting
without an external request. Such an object has its own instruction follower, in
Java called a Thread. In addition, an object with its own instruction-follower must
specify what instructions are to be followed. This is accomplished by
implementing a certain interface -- meeting a particular contract specification --
that indicates which instructions the Thread is to execute.
The remainder of this chapter deals with examples of how Threads and animate
objects can be used to create communities of autonomously interacting entities.

Objectives of this Chapter

• To understand that Threads are Java's instruction-followers.

• To appreciate the relationship between a Thread and the instructions that it

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
9~2 Animate Objects Chapter 9

executes.

• To be able to construct an animate object using AnimatorThread and

Animate.

9.1 Animate Objects

In previous chapters, we saw how objects group together state and behavior.
Some objects exist primarily to hold together constituent pieces of a single
complex state. Other objects exist to hold a static collection of primarily
functional or system-specific resources. Most objects contain both local state and
methods that rely on and interact with this state in complex ways. Many of these
objects wait for something to happen or for someone else to ask them to act. That
is, nothing happens until something outside the object invokes a method of the
object. In this chapter, we look at objects that are capable of taking action on their
own, without being asked to do so from outside. These objects have their own
instruction-followers, making them full-blown entities.
Consider, for example, the Counter. This is a relatively traditional object. It has
both state and methods that depend on that state. An individual counter object
encapsulates this state-dependent behavior, wrapping it up into a neat package.
But a counter doesn't do anything unless someone asks it to, using its increment()
or reset() method. By itself, a counter can't do much.
Contrast this with a timer. A timer is very similar to a counter in having a method
that advances it to the next state (paralleling the counter's increment() method)
and one that sets the state back to its default condition (such as reset()). A timer
differs from a counter, however in that a timer counts merrily along whether
someone asks it to or not. The timer's reset() method is a traditional (passive)
method; the timer resets only when asked to. But the timer's increment() method
is called by the timer itself on a regular basis.
This kind of object -- one that is capable of acting without being explicitly asked
to do so -- is called an animate object. Such an object has its own instruction-
follower, or actor, associated with it. While traditional objects are roles that an
actor may take on and then leave, an animate object is a role that is almost always
inhabited by an actor and tightly associated with it. Often, animate objects will
use traditional objects (as well as data repositories, resource libraries, and other
kinds of objects) to perform their tasks, temporarily executing instructions

IPIJ || Lynn Andrea Stein

9.1 Animate Objects 9~3

contained in these objects. But the animate object is where it begins and ends.
What makes an animate object different from other (passive) objects? Recall that
on the first page of the first chapter of this book, we learned about the two
prerequisites for a computation: The instructions for the computation must be
present, and those instructions must be executed. Every method of every object is
a set of instructions -- a rule -- that can be executed. When a method is invoked,
its body is executed. (The method body is executed by the instruction-follower
that invoked the method; this is how a method invocation expression is
evaluated.)
An animate object differs from other objects because it also has its instruction
follower. It does not need to wait for another instruction-follower to invoke one of
its methods (although this may also happen). Instead, it has a way to start
execution on its own.
In Java, an instruction-follower is called a Thread. No object can act except a
Thread. A Thread is a special object that "breathes life" into other objects. It is the
thing that causes other objects to move. An animate object is simply an object that
is "born" with its own Thread. (Typically, this means that it creates its own
Thread in its constructor and starts its Thread running either in its constructor or
as soon as otherwise possible.)

9.2 Animacies are Execution Sequences

In every method of every object, execution of that method follows a well-defined
set of rules. When the method is invoked, its formal parameters are associated
with the arguments supplied to the method call. For example, recall the
UpperCaser StringTransformer:
public class UpperCaser extends StringTransformer
{
public String transform( String what )
{
return what.toUpperCase();
}
}
If we have UpperCaser cap = new UpperCaser(); then evaluating the
expression cap.transform( "Who's there?") has the effect of associating the
value of the String "Who's there?" with the name what during the execution of
the body of the transform method.

IPIJ || Lynn Andrea Stein

9~4 Animate Objects Chapter 9

Now, the first statement of the method body is executed. In the case of the method
invocation expression cap.transform( "Who's there?"), there is only one
statement in the method body. This is the return statement, which first evaluates
the expression following the return, then exits the method invocation, returning
the value of that expression. To evaluate the method invocation expression
what.toUpperCase() involves first evaluating the name expression what and
then invoking the toUpperCase() method of the object associated with the name
what.

No matter how complex the method body, its execution is accomplished by

following the instructions that constitute it. Each statement has an associated
execution pattern. A simple statement like an assignment expression followed by
a semicolon is executed by evaluating the assignment expression. Expressions
have rules of evaluation; in the case of an assignment, the right-hand side
expression is evaluated, then that value is assigned to the left-hand side (shoebox
or label). Evaluating the right-hand side expression may itself be complicated, but
by following the evaluation rules for each constituent expression, the value of the
right-hand side is obtained and used in the assignment.
A more complex statement, such as a conditional, has execution rules that involve
the evaluation of the test expression, then execution of one but not both of the
following substatements (the "if-block" or the "else-block"). Loops and other
more complex statements also have rules of execution. Declarations set up name-
value associations; return statements exit the method currently being executed.
At any given time, execution of a particular method is at a particular point and in
a particular context (i.e., with a particular set of name-value associations in force).
If we could keep track of what we're in the middle of doing and what we know
about while we're doing it, we could temporarily suspend and resume execution of
this task at any time. Imagine that you're following an instruction booklet to
assemble a complex mechanism. This problem is a lot like placing a bookmark
into your instructions while you go off to do something else for a while. All you
need to know is where you were, what you had around you, and what you were
supposed to do next; the rest of the instructions will carry you forward.
Inside the computer, there are things that keep track of where you are in an
execution sequence. These are special Java objects called Threads. The trick is
that there can be more than one Thread in any program. In fact, there are exactly
as many things going on at once as there are Threads executing in your program.
A Thread keeps track of where it is in its own execution sequence. Each Thread
works on its own assembly project using its own instruction booklet, just like
multiple people can work side by side in a restaurant or a factory.

IPIJ || Lynn Andrea Stein

9.2 Animacies are Execution Sequences 9~5

In this book, we will make extensive use of a special kind of Thread called an
AnimatorThread. An AnimatorThread is an instruction follower that does the
same thing over and over again. It also has some other nice properties: it can be
started and stopped, suspended and resumed. These last two mean that it is
possible to ask your instruction follower to take a break for a while, then ask it
later to continue working. AnimatorThreads provide a nice abstraction for the
kinds of activities commonly conducted by the animate objects that are often
entities in our communities.

9.3 Being Animate-able

In order for a Thread to animate an object, the Thread needs to know where to
begin. A Thread needs to know that it can rely on the object to have a suitable
beginning place. There must be special contract between the Thread and the
object whose instructions this Thread is to execute. The object promises to supply
instructions; the Thread promises to execute them. (In the case of the
AnimatorThread, it promises to execute these instructions over and over again.)
As we know, such a contract is specified using a Java interface. This interface
defines a method containing the instructions that the Thread will execute. The
Thread will begin its execution at the instructions defined by this method.

9.3.1 Implementing Animate

If we use an AnimatorThread to animate our object, our object must fulfill the
specific contract on which AnimatorThread begins. This contract is specified by
the interface Animate:
public interface Animate
{
public abstract void act();
}
The Animate interface defines only a single method, void act(). A class
implementing Animate will need to provide a body for its act() method, a set of
instructions for how that particular kind of object act()s. An AnimatorThread will
call this act() method over and over again, repeatedly asking the Animate object
to act().
For example, the Timer that we described above could be implemented just as the
Counter, but with the addition of an act() method:
public void act()
{

IPIJ || Lynn Andrea Stein

9~6 Animate Objects Chapter 9

this.increment();
}
Of course, we'd also have to declare that Timer implements the Animate interface.
It isn't enough for Timer to have an act() method; we also have to specify that it
does so as a commitment to the Animate interface. Here is a complete Timer
implementation:
public class Timer implements Animate
{
private int currentValue;
public Timer()
{
this.reset();
}
public void increment()
{
this.currentValue = this.currentValue + 1;
}

public void reset()

{
this.currentValue = 0;
}

public int getValue()

{
return this.currentValue;
}

public void act()

{
this.increment();
}
}
Note that the implementation is entirely identical to the implementation of
Counter except for the clause implements Animate and Timer's act() method.1

1
As we shall see in the next chapter, we could significantly abbreviate this class
by writing it as
public class Timer extends Counter implements Animate
{
public void act()
{
this.increment();
}
}

IPIJ || Lynn Andrea Stein

9.3 Being Animate-able 9~7

Now Timer tick = new Timer(); defines a Timer ready to be animated.

9.3.2 AnimatorThread
On the other side of this contract is the instruction follower, an AnimatorThread.
Like any other kind of Java object, a new AnimatorThread is created using an
instance construction (new) expression and passing it the information required by
AnimatorThread's constructor. The simplest form of AnimatorThread's
constructor takes a single argument, an Animate whose act() method the new
AnimatorThread should call repeatedly.
For example, we can animate a Timer by passing it to AnimatorThread's
constructor expression:
Timer tick = new Timer();
AnimatorThread mover = new AnimatorThread( tick );
There is one more thing that we need to do before tick starts incrementing itself:
tell the AnimatorThread to startExecution():
mover.startExecution();
An AnimatorThread's startExecution() is a very special method. It returns
(almost) immediately. At the same time, the AnimatorThread comes to life and
begins following its own instructions. That is, before the evaluation of the method
invocation mover.startExecution(), there was only one Thread running. At the
end of the evaluation of the invocation, there are two Threads running, the one
that followed the instruction mover.startExecution() and the one named
mover, which begins following the instructions at tick's act() method.

Once started, the AnimatorThread's job is to evaluate the expression tick.act()

over and over again. Each time, this increments tick's currentValue field. The
AnimatorThread named mover calls tick's act() method over and over again,
repeatedly causing tick to act.
We can collapse the two AnimatorThread statements into one by writing
new AnimatorThread( tick ).startExecution();
However, this form does not leave us holding onto the AnimatorThread, so we
couldn't later tell it to suspendExecution(), resumeExecution(), or
stopExecution(). (See below.) If we anticipate needing to do any of these things,
we should be sure to hold on to the AnimatorThread (using a label name).

IPIJ || Lynn Andrea Stein

9~8 Animate Objects Chapter 9

9.3.3 Creating the AnimatorThread in the Constructor

If our Timers will always start ticking away as soon as they are created, we can
include the Thread creation in the Timer constructor:
public class AnimatedTimer implements Animate
{
private int currentValue;
private AnimatorThread mover;
public AnimatedTimer()
{
this.reset();
this.mover = new AnimatorThread( this );
this.mover.startExecution();
}
public void increment()
{
// ... rest of class is same as Timer

In this case, as soon as we say

Timer tock = new AnimatedTimer();
tock will begin counting away. If we invoke tock.getValue() at two different
times -- even if no one (except its own AnimatorThread) asks tock to do anything
at all in the intervening time -- the second value might not match the first. This is
because tock (with its AnimatorThread) can act without needing anyone else to
ask it.

IPIJ || Lynn Andrea Stein

9.3 Being Animate-able 9~9

Here is another class that could be used to monitor a Counting (such as a Counter
or a Timer):
public class CountingMonitor implements Animate
{
private Counting whoToMonitor;
private AnimatorThread mover;

public CountingMonitor( Counting whoToMonitor )

{
this.whoToMonitor = whoToMonitor;
this.mover = new AnimatorThread( this );
this.mover.startExecution();
}

public void act()

{
Console.println( "The timer says "
+ this.whoToMonitor.getValue()
);
}
}
Note in the constructor that the first whoToMonitor (this.whoToMonitor) refers to
the field, while the second refers to the parameter.

9.3.4 A Generic Animate Object

The way that AnimateTimer and CountingMonitor use an AnimatorThread is
pretty useful. There is a cs101 class, AnimateObject, that embodies this behavior.
It is probably the most generic kind of animate object that you can have; any other
animate object would behave like a special case of this one. We present it here to
reinforce the idea of an independent animate object. It generalizes both
CountingMonitor and AnimateTimer.
At this point, you should regard this class as a template. Change its name and add
a real act() method to get a real self-animating object. In the chapter on
Inheritance, we will return to this class and see that there is a way to make this
template quite useful directly.
public class AnimateObject implements Animate
{
private AnimatorThread mover;

public AnimateObject()
{

IPIJ || Lynn Andrea Stein

9~10 Animate Objects Chapter 9

this.mover = new AnimatorThread( this );

this.mover.startExecution();
}

public void act()

{
// what the Animate Object should do repeatedly
}
}
It is worth noting that an Animate need not be animated by an AnimatorThread.
For example, a group of Animates could all be animated by a single
SequentialAnimator that asks each Animate to act(), one at a time, in turn. No
Animate could act() while any other Animate was mid-act(). Each would have to
wait for the previous Animate to finish. This SequentialAnimator would require
only a single instruction follower (or Thread) to execute the sequential Animates'
instructions, because it would execute them one act() method at a time. When one
animate is acting, no one else can be.
The nature of execution under such a synchronous assumption would be very
different from executions in which each Animate had its own Thread and they
were all acting simultaneously. Roughly it's the difference between a puppet show
with one not-very-skillful puppeteer, who can only operate a single puppet at a
time, and a whole crowd of puppeteers each operating a puppet. The potential for
chaos is much greater in the second scenario, but so is the potential for exciting
interaction. When each object has its own AnimatorThread -- as in the
AnimateObject template -- any other Animate (or the methods it calls) can
execute at the same time.

9.4 More Details

This section broadens the picture painted so far.

9.4.1 AnimatorThread Details

The AnimatorThread class and the Animate interface reside in the package
cs101.lang. This means that any file that uses these classes should have the line
import cs101.lang.*;
before any class or interface definition.

IPIJ || Lynn Andrea Stein

9.4 More Details 9~11

The class AnimatorThread specifies behavior for a particular kind of instruction

follower. Its constructor requires an object that implements the interface
cs101.lang.Animate, the object whose act() method the AnimatorThread will
repeatedly execute.
After constructing an AnimatorThread, you need to invoke its startExecution()
method.2 This causes the AnimatorThread to begin following instructions. In
particular, the instructions that it follows say to invoke its Animate's act() method,
then wait a little while, then invoke the Animate's act() method again (and so on).
To temporarily suspend execution, use the AniamtorThread's suspendExecution()
method. Execution may be restarted using resumeExecution(). To permanently
terminate execution, AnimatorThread has a stopExecution() method. Once
stopped, an AnimatorThread's execution cannot be restarted. However, a new
AnimatorThread can be created on the same Animate object.
An object -- like an Animate -- is a set of instructions -- or methods -- plus some
state used by these instructions. There is nothing to prevent more than one Thread
from following the same set of instructions at the same time. For example, it
would be possible to start up two AnimatorThreads on the same Timer. If the two
AnimatorThreads took turns fairly and evenly, one AnimatorThread would always
move from an odd to an even numbered currentValue, while the other would
always move from an even to an odd numbered value. Of course, there's nothing
requiring that the two AnimatorThreads play fair. Like children, one might take
all of the turns -- incrementing the Timer again and again -- while the other might
never (or rarely) get a turn. AnimatorThreads are designed to minimize this case,
but it can happen. The problem is more prevalent with other kinds of Threads.
One of the ways in which AnimatorThread tries to "play fair" is in providing
intervals between each attempt to follow the act() instructions of its Animate
object. The AnimatorThread has two values that it uses to determine the minimum
interval between invocations of the Animate's act() method and the maximum
interval. Between these two values, the actual interval is selected at random each
time the AnimatorThread completes an act(). You can adjust these parameters
using setter methods of the AnimatorThread. Values for these intervals may also
be supplied in the AnimatorThread's constructor. See the AnimatorThread sidebar
for details.

2
AnimatorThread's instances also have a startExecution() method that is identical to the
startExecution() method. This is for historical reasons.

IPIJ || Lynn Andrea Stein

9~12 Animate Objects Chapter 9

class AnimatorThread
AnimatorThread is a cs101 class (specifically, cs101.lang.AnimatorThread)
that serves as a special kind of instruction-follower. An AnimatorThread's
constructor must be called with an instance of cs101.lang.Animate. The
AnimatorThread repeatedly follows the instructions in the Animate's act()
method.
An AnimatorThread is an object, so it can be referred to with an
appropriate (label) name. It also provides several useful methods:

void startExecution() causes the AnimatorThread to begin following

the instructions at its Animate's act() method. Once started, the
AnimatorThread will follow these instructions repeatedly at semi-random
intervals until it is stopped or suspended

void stopExecution() causes the AnimatorThread to terminate its

execution. Once stopped, an AnimatorThread cannot be restarted. This
method may terminate execution abruptly, even in the middle of the
Animate's act() method.

void suspendExecution() causes the AnimatorThread to temporarily

suspend its execution. If the AnimatorThread is already suspended or
stopped, nothing happens. If the AnimatorThread has not yet started and is
started before an invocation of resumeExecution(), it will start in a
suspended state, i.e., it will not immediately begin execution. This method
will not interrupt an execution of the Animate's act() method; suspensions
take effect only between act()s.

void resumeExecution() causes the AnimatorThread, if suspended, to

continue its repeated execution of its Animate's act() method. If the
AnimatorThread is not suspended or already stopped, this method does
nothing. If the AnimatorThread is suspended but not yet started, invoking
resumeExecution() undoes the effect of any previous suspendExecution()
but does not startExecution().
Between calls to the Animate's act() method, the AnimatorThread sleeps,
i.e., remains inactive. The duration of each of these sleep intervals is
randomly chosen to be at least sleepMinInterval and no more than
sleepMinInterval + sleepRange. These values are by default set to a
range that allows for variability and slows activity to a rate that is humanly
perceptible. If you wish to change these defaults, they may be set either

IPIJ || Lynn Andrea Stein

9.4 More Details 9~13

explicitly using setter methods or in the AnimatorThread constructor.

void setSleepRange( long howLong ) sets the desired variance in sleep

times above and beyond sleepMinInterval

void setSleepMinInterval( long howLong ) sets the range of

variation in the randomization
By setting sleepRange to 0, you can make your AnimatorThread's activity
somewhat more predictable as it will sleep for approximately the same
amount of time between each execution of the Animate's act() method.
Setting sleepMinInterval to a smaller value speeds up the execution rate of
the AnimatorThread. Setting it to 0 can be dangerous and should be
avoided. If sleepRange is 0, it is possible that this AnimatorThread will
interfere with other Threads' ability to run.
AnimatorThread supplies a number of constructors. The first requires only
the Animate whose act method supplies this AnimatorThread's instructions:
AnimatorThread( Animate who )

The next two constructors incorporate the same functions as setRange and
setMinInterval:
AnimatorThread( Animate who, long sleepRange )

AnimatorThread( Animate who, long sleepRange,

long sleepMinInterval )

It is also possible to specify explicitly whether the AnimatorThread should

start executing immediately. By default, it does so. The following
constructor allows you to override this explicitly using the boolean
constants AnimatorThread.START_IMMEDIATELY and
AnimatorThread.DONT_START_YET.

AnimatorThread( Animate who, boolean startImmediately )

Finally, there are two additional constructors that incorporate both startup
and timing information:
AnimatorThread( Animate who, boolean startImmediately,
long sleepRange )

AnimatorThread( Animate who, boolean startImmediately,

long sleepRange, long sleepMinInterval )

IPIJ || Lynn Andrea Stein

9~14 Animate Objects Chapter 9

9.4.2 Delayed Start and the init() Trick

It is awfully convenient to be able to define an animate object as an Animate that
creates and starts its own AnimatorThread. This hides the Thread creation and
manipulation inside the Animate (as in the example of AnimateTimer), making it
appear to be a fully self-animating object from the outside. However, sometimes
we need to separate the construction of the Animate and its AnimatorThread from
the initiation of the AnimatorThread instruction follower. That is, we want the
AnimatorThread set up, but not yet actually running. For example, we might need
a part that isn't yet available at Animate/AnimatorThread creation time. On these
occasions, it would be awkward to start the execution of an AnimatorThread in
the constructor of its Animate. For example, if the Animate's act() method relies
on other objects and these other objects may not yet be available, you wouldn't
want the AnimatorThread to start executing the act() method yet.
An example of this might be in the StringTransformer class in the first interlude,
in which you can't read or transform a String until after you've accepted an input
connection. Since the input connection might not be available at
StringTransformer construction time, one solution to this problem is to delay the
starting of the execution of the act() method until after the input connection has
been accepted. Once the constructor completes, the newly constructed object's
acceptInputConnection method can be invoked. At this point -- and not before --
the AnimatorThread's startExecution() method can be invoked. This means that
the call to the AnimatorThread's startExecution() method can't appear in the
constructor. But it can't be invoked by any object other than the Animate, because
the AnimatorThread is held by a private field of the Animate.
This situation -- that there are things that need to be done that are logically part of
the setup of the object, but that cannot be done in the constructor itself -- is a
common one. To get around it, there is a convention that says that such objects
should have init() methods. Whoever is responsible for setting up the object
should invoke its init() method after this setup is complete. The object can rely on
the fact that its init() method will be invoked after the object is completely
constructed and -- in this case -- connected. We could then put the call to the
AnimatorThread's startExecution() method inside this init() method.
Here is a delayed-start version of the AnimateObject template.
public class InitAnimateObject implements Animate
{
private AnimatorThread mover;

IPIJ || Lynn Andrea Stein

9.4 More Details 9~15

public InitAnimateObject()
{
this.mover = new AnimatorThread( this );
}

public void init()

{
this.mover.startExecution();
}

public void act()

{
// what the Animate Object should do repeatedly
}
}
A concrete example of this issue arises if we look at CountingMonitor and don't
assume that the Counting will be supplied to the constructor. Here is another
version of CountingMonitor without the constructor parameter:
public class InitCountingMonitor implements Animate
{
private Counting whoToMonitor;
private AnimatorThread mover = new AnimatorThread(
this );

public void setCounting( Counting whoToMonitor )

{
this.whoToMonitor = whoToMonitor;
}

public void init()

{
this.mover.startExecution();
}

public void act()

{
Console.println( "The timer says "
+ this.whoToMonitor.getValue()
);
}
}
The use of a method named init() here is completely arbitrary. You are free to
define your own method and call it whatever you want. However, you will see
that many people follow this convention and provide an init() method for their
objects when there is initialization that must take place after the constructor and
setup process is complete.

IPIJ || Lynn Andrea Stein

9~16 Animate Objects Chapter 9

9.4.3 Threads and Runnables

The Animate/AnimatorThread story that we've just seen is not a standard part of
Java, though it is only a minor variant on something that is. There are two reasons
why we've used AnimatorThreads here. The first is that most of the self-animating
object types in this book are objects whose act method is executed over and over
again. AnimatorThread is a special kind of Thread designed to do just that. The
second is that AnimatorThread contains some special mechanisms to facilitate its
use in applications where you might want to suspend and resume its execution or
even to stop it entirely. AnimatorThread provides methods supporting this
behavior.
There is, however, in Java a more primitive type of Thread, called simply Thread.
Like an AnimatorThread, a simple Java Thread can be given an object to animate
when the Thread is created. (Its constructor takes an argument representing the
object whose instructions the Thread is to follow once it has been started.)
However, the Thread does not execute this method repeatedly; it executes it once,
then stops. The contract that a Thread requires of the object providing its
instructions is not Animate, meaning it can be called on to act repeatedly. Instead,
it is Runnable, meaning it can be executed once.
Thread (as of Java 1.1) does not provide suspension, resumption, or cessation
methods. In this book, we avoid the use of plain Java Threads.
In addition, it is technically possible in Java to extend a Thread object rather than
passing it an independent Runnable. Except in code that creates special kinds of
Threads (such as AnimatorThread) capable of animating other objects, the
extending of Thread is highly discouraged in this book. Extending Thread to
create an executing object (whose own run() method is the set of instructions to be
followed) confounds the notion of an executor with the executed.

9.4.4 Thread Methods

start, yield, sleep, (interrupt, join (many versions), isAlive

IPIJ || Lynn Andrea Stein

9.4 More Details 9~17

Thread methods
Threads are Java's instruction followers. In this book, we will most often
make use of AnimatorThreads. However, it is useful to understand how
Java's built-in Thread class works as well.
Like an AnimatorThread, each Thread provides a few methods for its
management.

void start() Like AnimatorThread's startExecution(), this method

causes the target Thread to begin following instructions. If the
Thread's constructor was supplied a Runnable, the Thread begins
execution at this Runnable's run() method. When the run() method
terminates, the Thread's execution is finished.

boolean isAlive() tells you whether the target Thread is alive, i.e.,
has been started and has not completed its execution.

void interrupt() sends the target Thread an InterruptedException.

Useful if that Thread is sleeping, waiting, or joining.

void join() causes the invoking Thread to suspend its execution

until the target Thread completes. Variants allow time limits on this
suspension: void join( long millis ) and void join( long
millis, long nanos ).

Unlike AnimatorThread, a Thread cannot safely be stopped, suspended, or

resumed.
In addition to its role as the type of Java's instruction followers, the Thread
class provices useful static (i.e., class-wide) functionality. These methods
are static methods of the class Thread:

static void sleep( long millis ) causes the currently active

Thread to stop executing for millis milliseconds. This method throws
InterruptedException, so it cannot be used without some additional
machinery (introduced in the chapter on Exceptions). There is a
variant method, sleep( long millis, long nanos ) that allows
more precision in controlling the duration of the Thread's sleep.

static void yield() is intended to pause the currently executing

Thread and to allow another Thread to run. However, not all versions

IPIJ || Lynn Andrea Stein

9~18 Animate Objects Chapter 9

of Java implement Thread.yield in a way that ensures this behavior.

Other Thread features are outside the scope of this course.

9.5 Where do Threads come from?

We have discussed the idea of AnimatorThreads above, showing how to create
self-animating objects by having an AnimatorThread created in an object's
constructor. Such an object is born running; it continually acts, over and over,
until its Thread is suspended or stopped.
In fact, no execution in Java can take place without a Thread. But something must
call the AnimatorThread constructor; this instruction must be executed by a
Thread! So where does the first Thread come from? This depends on the
particular kind of Java program that you are running. In this book, we look
primarily at Java applications. In the appendix, we also answer these questions for
Java applets.

9.5.1 Starting a Program

What does it mean for a Java program to run? It means that there is an instruction
follower that executes the instructions that make up this program. In Java, there is
no execution without a Thread, or instruction-follower, to execute it. So when a
program is run, some Thread must be executing its instructions. Where does this
Thread come from, and how does it know what instructions to execute?
Let's answer the first of these questions first. When a Java program is run, a single
Thread is created and started. This is not a Thread that your program creates; it is
the Thread that Java creates to run your program. Depending on whether your
Java program is an application (as we're discussing in this book) or an applet (as
you may have encountered on the world-wide web) or some other kind of Java
program, there are different conventions as to where this Thread begins its
execution. But running a program by definition means creating a Thread -- an
instruction follower -- to execute that program.
How does the Thread know where to begin? By convention. What do we mean by
a convention? AnimatorThread's use of Animate is a convention. This convention
is, in some sense, completely arbitrary. That is, a different interface name or other

IPIJ || Lynn Andrea Stein

9.5 Where do Threads come from? 9~19

method might have been used. For example, the raw Thread class uses a different
convention, that of Runnable/run(). If you were to design your own type of
Thread, you could create a different convention for it to follow. However, once
these names and contracts have been selected by the designers of AnimatorThread
and Thread, they are absolute rules that cannot be violated.
Similarly, there must be some arbitrary convention as to how a Java program
begins. In a standalone application, the convention is that running a Java program
means supplying a class to the executable, and by convention a particular method
of the class is always the place that execution begins. This default execution does
not create an instance of the class, so the method must be a static one. Again by
convention, the name of this method is main, it takes as argument an array of
Strings, and it returns nothing. That is, the arbitrary but unvarying start point for
the execution of a standalone Java application is the
public static void main ( String[] args )
method of the class whose name is supplied to the executable.3
So if you want to write a program, you simply need to create a class with a
method whose signature matches the line above. The body of that main method
will be executed by the single Thread that is created at the beginning of a Java
execution. When execution of main terminates, the program ends. If you do not
want the program to end, you need to do something during the course of
executing main that causes things to keep going. Typically, this means that you
use the body of main to create one or more objects that themselves may execute.
For example, if the body of main creates an animate object (with its own
AnimatorThread), then that object will continue executing even if the body of
main is completed. This is called "spawning a new Thread".
Here is a very simple class that exists solely to create a new instance of the
AnimateTimer class:
public class Main
{
public static void main ( String[] args )
{
Counting theTimer = new AnimateTimer();
}
}
This program simply counts. The instruction follower that begins when this

3
Typically, this means the class you select before choosing run from the IDE menu or the class
whose name follows the command java on the command line.

IPIJ || Lynn Andrea Stein

9~20 Animate Objects Chapter 9

program starts up (e.g., using java Main) executes the main() method, invoking
new AnimateTimer() and assigning the result to theTimer. This Thread is now
done executing and stops. However, the constructor for AnimateTimer has created
a new AnimatorThread and then called that AnimatorThread's startExecution()
method. This starts up the new Thread which repeatedly calls AnimateTimer's
act() method. The program as a whole will not terminate until the
AnimatorThread stops executing, which it will not do by itself. If you run this
program, you will need to forcibly terminate it from outside the program!
Since we didn't give this program any way to monitor or indicate what's going on,
running it wouldn't be very interesting. But we can use the CountingMonitor
above to improve this program:
public class Main
{
public static void main ( String[] args )
{
Counting theTimer = new AnimateTimer();
Animate theMonitor = CountingMonitor( theTimer );
}
}

Q. Can you find a more succinct way to express the body of the main method?
Q. What will be printed by this program? On what does it depend? (Hint:
fairness.)
The instruction follower executing the Main class's main method exits. However,
before it completes it executes the instructions to create and start two separate
AnimatorThreads. These AnimatorThreads continue after the execution of the
main Thread exits. Again, this program must be forcibly terminated from outside.

Q. Can you cause this program to stop by itself sometime after it has counted to
100? (This is a bit tricky.)
The two versions of the Main class above each contain just the instructions to
create an instance or two. In the cs101 libraries, we have provided a Main that
does this for you. This allows you to write applications without needing to write
public static void main( String[] ) methods yourself.

IPIJ || Lynn Andrea Stein

9.5 Where do Threads come from? 9~21

class Main
The cs101 libraries include a class, cs101.util.Main, that can be run from
the java command line to create an instance of a single class with a no-args
constructor. For example, we could implement the unmonitored Timer
example using the following command:
java cs101.util.Main AnimateTimer
This causes code much like the first Main class to execute, creating a single
instance of AnimateTimer (using its no-args constructor).
The class cs101.util.Main contains nothing but the single static method
main (taking a String[] argument). The command above tells Java to start
its initial instruction follower at this method -- the static main( String[] )
method of the class cs101.util.Main. The remainder of the information on
the command line (in this case, AnimateTester) is supplied to the main
method using its parameter.4

4
For more detail on arrays ([]), see the chapter on Dispatch.

IPIJ || Lynn Andrea Stein

9~22 Animate Objects Chapter 9

Style Sidebar

Using main()
If you do decide to write your own main() method, you should do so in a
class separate from your other classes, generally one called Main and
containing only the single public static void main() method requiring a
String[] (i.e., an array of Strings). This method may have some complexity,
creating several objects and gluing them together, for example.
Alternately, you can create an extremely simple main method in any (or
even every) class that you write. In this case, however, the main method
should do nothing more than to create a single instance of the class within
which it is defined, using that class's no-args constructor. Of course, the
signature of each main method is the same: public static void main( String[]
args ) The main that will actually be executed is the one belonging to the
(first) class whose name is supplied to the java execution command. So, for
example, in the sidebar on class Main, we said
java cs101.util.Main AnimateTimer
causing cs101.util.Main's main method to be run.
The logic behind these restrictions on the use of main() is as follows. In the
second case -- main in many instantiable class's files -- the presence of
main allows that object to be tested independently. However, this test is
extremely straightforward and predictable. If the main method takes on any
additional complexity, it should be separated from the other (instantiable)
classes and form its own resource library, one that exists solely to run the
program in all its complexity.

9.5.2 Why Constructors Need to Return

In the code above, each Animate's constructor calls the startExecution() method
of a new Thread. This in turn repeatedly calls the act() method of the Animate.
Why doesn't the constructor just repeatedly call the Animate's act() method itself
(e.g., in a while loop)?
This is a fundamental issue. If the Animate's constructor called the act() method
itself, the instruction follower -- or Thread -- executing the constructor would be
trapped forever in a loop calling act() over and over. The constructor invocation --

IPIJ || Lynn Andrea Stein

9.5 Where do Threads come from? 9~23

the new expression -- would never complete. In the monitored counting example,
the invocation of AnimateTimer's constructor would cause the instruction
follower to execute the act() method of AnimateTimer over and over again. This
instruction follower -- the only instruction follower to be running so far -- would
never complete the repeated execution of the act() method. This means that it
would never get around to creating the CounterMonitor.
This is why AnimatorThread.startExecution() must be a very special kind of
method. The Thread, or instruction follower, that executes startExecution() must
return (almost) immediately. It is the new Thread, the one just started, that goes
off to execute the act() method. The original Thread returns from this invocation
and goes about its business just as if nothing ever happened. In personal terms,
this is the difference between doing the job yourself and assigning someone else
to do it. True, when someone else does it you have less control over how or when
the job gets done; but while someone else is working on it, you can be doing
something else.

Chapter Summary
• In Java, activity is performed by instruction followers called Threads.

• An animate object is simply one that has its very own Thread.

• An AnimatorThread is a useful kind of Thread that repeatedly follows the

instructions provided by some object's act() method.

• This object must implement the Animate interface.

• It must be supplied to the AnimatorThread's constructor.

• An AnimatorThread can also be asked to start, stop, suspend, or resume

execution.

• Java programs may involve other Threads.

• One Thread begins execution at public static void main( String[]

args ) when a Java application is begun.

• GUI objects involve their own Threads.

IPIJ || Lynn Andrea Stein

9~24 Animate Objects Chapter 9

• Other Threads may be explicitly created.

Exercises
1. Define a class whose instances each have an internal value that doubles
periodically. Each time that the value doubles, the instance should print
this new value to the Console.
2. Define a class that periodically reads from the Console and writes the
value back to the Console.
3. Define a main class that creates three instances of your doubler.
4. Using the timing parameters of AnimatorThread, demonstrate that not all
doublers have to run at the same rate.

IPIJ || Lynn Andrea Stein

 10
Chapter 10 Inheritance

Chapter Overview
• How do I simplify the program design task by reusing existing
code?

• How do I create variants on things I already have?

• When is it not appropriate to reuse code?

This chapter covers class-based inheritance as a way to reuse implementation.
Inheritance allows you to define a new class by specifying only the ways in which
it differs from an existing class. Those differences can include: additional (or
alternative) contracts that it satisfies, behaviors that it provides, internal
information that it stores, or startup instructions. Inheritance means that existing
code can be adapted and reused, with some modification, in new contexts.
The mechanism by which inheritance works involves extending the parent class
definition either by augmenting or overriding behavior defined there. Most of this
chapter concentrates on how these mechanisms work. Not every instance of
similar behavior is an appropriate context for inheritance. The chapter concludes
with a discussion of the limitations of inheritance.
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
10~2 Inheritance Chapter 10

This chapter includes sidebars on the details of method and field lookup. It is
supplemented by reference charts on the syntax and semantics of java methods,
fields, and class declarations.

Objectives of this Chapter

1. To understand how one class can build on behavior supplied by another.
2. To be able to extend and modify existing definitions
3. To recognize when to use mechanisms other than inheritance to extend
behavior.

10.1 Derived Factories

We have so far seen several cases in which we wanted to build multiple kinds of
things that shared a basic similarity. When this similarity was largely in the
contract implemented -- as with Counters and Timers -- we abstracted this
similarity into an interface. The interface allowed us to deal with objects without
knowing the details of their implementations, i.e., to treat them solely in light of
the contracts that they provided.
In this chapter, we are more concerned with situations in which two kinds of
objects share not only the same contract but almost the same implementation. For
example, the BasicCounter and the Resettable Counter contained almost precisely
the same code. In fact, the BasicCounter's code was (except for the class and
constructor name) a proper subset of the Resettable Counter's code. Similarly, the
code for AnimateObject was contained in the code for AnimateTimer and the
code for CountingMonitor. And almost every StringTransformer simply
elaborates on the generic StringTransformer, simply providing a specialized
version of the transform() method.
In cases where code really matches at the level of wholesale textual reuse of a
class, Java provides a mechanism to allow one type of object to build on the
behavior specified by another. This is a relationship between one class and
another. Since classes are essentially object factories, we can think of this as a
situation in which one factory produces its widgets by buying widgets wholesale

IPIJ || Lynn Andrea Stein

10.1 Derived Factories 10~3

from another factory, then adding its own minor tweaks (bells and whistles) to the
widgets before claiming to have produced them.
The mechanism by which this is accomplished in Java is called inheritance, and it
applies to a relationship between two classes. There is a similar relationship
between two interfaces, described below. Inheritance is not ever a relationship
between a class and an interface (or between an interface and a class). Inheritance
really means an almost literal subsuming of one thing by another.

10.1.1 Simple Inheritance

Consider, for example, the AnimateObject class from the previous chapter and its
near relative, the CountingMonitor. The AnimateObject class says:
public class AnimateObject implements Animate
{
private AnimatorThread mover;

public AnimateObject()
{
this.mover = new AnimatorThread( this );
this.mover.startExecution();
}

public void act()

{
// what the Animate Object should do repeatedly
}
}
In implementing the CountingMonitor class, we really only want to change the
underlined things:
public class CountingMonitor implements Animate
{
private Counting whoToMonitor;

private AnimatorThread mover;

public CountingMonitor( Counting whoToMonitor )

{
this.whoToMonitor = whoToMonitor;
this.mover = new AnimatorThread( this );
this.mover.startExecution();
}

public void act()

IPIJ || Lynn Andrea Stein

10~4 Inheritance Chapter 10

{
Console.println( "The timer says "
+ this.whoToMonitor.getValue()
);
}
}
It would be really nice only to have to write the underlined information, not the
rest. In fact, we can do almost exactly that. The following definition is almost
equivalent to the Counter definition above:
public class CountingMonitor extends AnimateObject
{
private Counting whoToMonitor;

public CountingMonitor( Counting whoToMonitor )

{
this.whoToMonitor = whoToMonitor;
}

public void act()

{
Console.println( "The timer says "
+ this.whoToMonitor.getValue()
);
}
}
We have preserved the underlining, and you can see that almost the entire new
class is underlined. One of the few non-underlined items is the phrase extends
AnimateObject. This is the phrase that does almost all of the work. It means,
roughly, a CountingMonitor is an AnimateObject, it just provides the additional
specified behavior.
1. It has its own private field, whoToMonitor, suitable for labeling a
Counting.
2. It has a constructor that takes one argument, a Counting, and holds on to
it.
3. Its act() method has a much more interesting body than AnimateObject's.
This code is equivalent to the original definition of CountingMonitor. It is much
shorter to write. To use it, simply begin with the instructions for AnimateObject
and add the pieces that CountingMonitor provides, extending the behavior of the
AnimateObject (in the absence of conflicting instructions) to do these additional
things.

IPIJ || Lynn Andrea Stein

10.1 Derived Factories 10~5

In essence each CountingMonitor instance has an AnimateObject instance inside

of it. Whenever the CoutingMonitor can't figure out how to do something, it
simply defaults to the behavior of its AnimateObject. That way, the
CountingMonitor doesn't have to provide all of the behavior that an
AnimateObject already has; it can just rely on the existing implementation.
The remainder of this chapter deals with the details of this proposition.

10.1.2 java.lang.Object
There is actually a single built-in type called Object, and all other object types
(directly or indirectly) extend Object. In other words, anything which is not one
of the built in types is an Object of some sort or another.
class Cat extends Animal
{
....
}
A class declaration is followed by an optional extends clause, then a pair of
braces around the body of the class definition. If the extends clause is missing
(e.g., class Widget {...}), the default clause extends Object is assumed.
Thus, every class (implicitly or explicitly, directly or indirectly) extends
Object.

The class Object provides some basic functionality that every other class
necessarily inherits. This means that you can guarantee that every Java object has,
e.g., a toString() method. See the sidebar on The class Object for details.

IPIJ || Lynn Andrea Stein

10~6 Inheritance Chapter 10

The class Object

The class java.lang.Object is the root of the inheritance hierarchy, i.e., the
class of which all other classes are subclasses. Every Java object is
guaranteed to implement each of the methods provided by Object (though
their implementations may vary).

boolean equals( Object ) returns true exactly when the argument

Object is the same Object as the one whose method is invoked. This is
exactly the same thing that == would do on two Objects. You may override
equals to do something somewhat more interesting.

String toString() returns a String ostensibly suitable for printing. It

contains a lot of useful information in a generally illegible format, so if you
are interested in being able to read your objects, you may wish to override
this method to print something more easily human-readable.

class getClass() returns the class object (i.e., factory) from which this
instance was created.

Object clone() is a peculiar method of Object because although every

object implements it, it can only be used with instances of classes that also
implement the Cloneable interface. If a class implements the Cloneable
interface, the inherited version of clone() simply creates a new object of
the same type as the original and whose fields have the same values as the
fields of the original. You may override clone() to do whatever you wish.1
Object also provides other methods (finalize, hashcode, wait, notify, and
notifyAll) that are beyond the scope of the material covered here.

10.1.3 Superclass Membership

When one class extends another -- as in the CountingMonitor/AnimateObject
example above, we say that the extending class (CountingMonitor) is a subclass
of the extended class (AnimateObject), and that the extended class is a superclass
of the extending class. Neither subclass nor superclass is an absolute description;

1
If you call the clone() method of an object that doesn't implement Cloneable, it will throw
CloneNotSupportedException. See the next chapter for more on Exceptions.

IPIJ || Lynn Andrea Stein

10.1 Derived Factories 10~7

instead, both describe relationships between two classes.

When we say that one class is a subclass of another, what we mean is that we can
treat instances of the subclass in all respects as though they were members of the
superclass. For example, we can use a CountingMonitor anywhere we can use an
AnimateObject. We can assign a CountingMonitor to a name whose type makes it
appropriate for labeling AnimateObjects. (After all, a CountingMonitor is an
AnimateObject.) We can return a CountingMonitor from a method that expects to
return an AnimateObject, or pass one as an argument to a method expecting an
AnimateObject parameter. A CountingMonitor is simply a special kind of
AnimateObject.
In fact, subclasses have all of the type-relational properties of classes and the
interfaces that they implement. A subclass instance can be assigned to a name of
the superclass type. It answers true to the instanceof predicate on the
superclass. It can even be automatically coerced up-cast to its superclass type.
This is the same kind of automatic coercion that happens from int to long, and it is
similarly guaranteed always to succeed and never to lose information.
Treating a CountingMonitor as an AnimateObject doesn't actually change the
CountingMonitor, though. The CountingMonitor is still a CountingMonitor, with
its extended act() method and its Counting to keep track of. This is the same
situation as when an object is treated according to its interface type: this narrows
the view of the object, but it doesn't change the underlying object.
If you are currently holding what looks like a superclass instance (e.g., an
AnimateObject), and you suspect that it is actually an instance of a subclass, you
can attempt to do a down-cast coercion on it. As with primitive types, a
narrowing conversion is one that may not work or may lose information.
For example, if AnimateObject ao has some value that you think might be a
CountingMonitor, you can try the expression
(CountingMonitor) ao
(e.g., in an assignment statement or in a method invocation). However, if you're
wrong and this AnimateObject is not a CountingMonitor, this will cause your
program serious problems. (See the next chapter for information about how these
problems arise and what you can do about them.) So you may want to test
whether this is an OK thing to do first, using a guard expression:
CountingMonitor cm;
if ( ao instanceof CountingMonitor )
{
cm = (CountingMonitor) ao;
}

IPIJ || Lynn Andrea Stein

10~8 Inheritance Chapter 10

This first checks to see whether it's OK to treat the AnimateObject as a

CountingMonitor.
So far, we have seen that instances have several types: the type of the class from
which the instance was created, the types of any interfaces that class
implemented, and the types of any superclass that this class extends. This may
mean many interface types (since a class can implement many interfaces). A class
can only extend a single superclass, but this does not limit the number of legal
class types because the superclass may itself extend another class, and so on.
Where does this end?
We can use the idea of superclass membership to create very powerful
abstractions, but not without the help of casting. For example, Java provides a
class, Vector, that allows us to hold on to a collection of Objects; it behaves sort-
of like a whole bunch of names, but indexed by number. Vector provides an
addElement() method that takes any Object as an argument. This means that any
Object can be inserted into a Vector. For example, you can insert a String into a
Vector, and an AnimateObject as well:
Vector v = new Vector();
v.addElement( "Silly string" );
v.addElement( new Timer() );
However, when we retrieve the elements we've inserted, we discover that Vector's
elementAt() method doesn't know the type of the Object we've inserted. Instead,
elementAt() returns an Object; it is up to us to figure out what kind of thing we've
gotten back. For example, the first thing in the Vector (at element 0) is the String
"Silly string". So we can say
Object o = v.elementAt( 0 );
or
String s = ( String ) v.elementAt( 0 );
but not
String s = v.elementAt( 0 );
because this is an illegal attempt to assign a value of type Object ( v.elementAt( 0
) ) to a name of type String. The explicit cast expression of the previous line is
needed to make this statement legal.

10.2 Overriding
The examples of inheritance in the previous section demonstrated that a subclass

IPIJ || Lynn Andrea Stein

10.2 Overriding 10~9

can extend the functionality of its superclass. The subclass can also modify
superclass functionality by overriding, or redefining, methods provided by the
superclass. In fact, CountingMonitor overrode the act() method provided by
AnimateObject. This just wasn't a very interesting example because
AnimateObject's act() method didn't do anything.
Consider the following classes:
public class Super
{
public void doit()
{
Console.println( "super method" );
}

public void doitAgain()

{
this.doit();
}

public class OverridingSub extends Super

{
public void doit()
{
Console.println( "overridingSub method" );
}
}
Now suppose that we create an instance of OverridingSub and ask it to doit():
OverridingSub over = new OverridingSub();
over.doit();
As expected, this prints overridingSub method. What if we labeled the
OverridingSub with a Super name?
Super supe = new OverridingSub();
supe.doit();
The same thing: overridingSub method Recall that using a different type of
name doesn't change the underlying object.

10.2.1 super.
What if we still want to be able to access Super's doit() method from the subclass?
To do this, we need a special expression much like this. The expression this

IPIJ || Lynn Andrea Stein

10~10 Inheritance Chapter 10

refers to the instance whose code is being executed. The expression super refers
to the superclass of the object containing the actual executing code.
public class ExpandingSub extends Super
{
public void doit()
{
super.doit();
Console.println( "expandingSub method" );
}
}
In this case, we'll get the effect of executing the superclass method followed by
the local println:
super method
expandingSub method
If we reverse the lines of the method body, we will reverse the order of the printed
lines.

10.2.2 Outside-in rule

There is one more trick lurking in this example. This is the doitAgain() method in
Super. We know what happens when we ask an instance of Super to doitAgain():
it does the same thing as if we'd asked it to doit(). But what if we ask a subclass
instance?
over.doitAgain()
The first thing that happens is that we have to find the doitAgain() method for
OverridingSub. To do this, we start looking at the outermost (sub) class. This is
OverridingSub. But it doesn't contain an appropriate method. So we move up the
hierarchy, inside the object, to the superclass. Super does define doitAgain(), so
now we know what code to execute. But the body of Super's doitAgain() method
says this.doit(). Who is this?

The expression this always refers to the object on behalf of whom you are
executing. At the moment, we're executing some code in the class Super. But we
are doing it for an instance of OverridingSub; we just happen to be looking at
over as though it were a Super, just as we did when we labeled it with a Super-
type name. Looking at over as a Super doesn't make it one, though. So when we
call this.doit(), we go right back to the outside (OverridingSub) and start
working our way in again, looking for a doit() method. So the effect of invoking
over.doitAgain() is the same as invoking over's doit(), not the Super method.

IPIJ || Lynn Andrea Stein

10.2 Overriding 10~11

10.2.3 Problems with Private

It isn't always completely straightforward to extend a class. Consider the
BasicCounter and Resettable Counter classes from the chapter on Designing with
Objects. Because the BasicCounter wasn't designed with inheritance in mind,
there is a problem in extending it. In fact, we have to go back and modify the
BasicCounter before we can describe the Resettable version directly in terms of it.
class BasicCounter implements Counting
{
int currentValue = 0;
void increment()
{
this.currentValue = this.currentValue + 1;
}

int getValue()
{
return this.currentValue;
}
}
To implement the Resettable Counter class, we would like to be able to write the
following:
public class Counter extends BasicCounter implements
Resettable
{

IPIJ || Lynn Andrea Stein

10~12 Inheritance Chapter 10

public Counter()
{
this.reset();

public void reset()

{
this.currentValue = 0;
}
}
We have preserved the underlining, and you can see that almost the entire new
class is underlined. This says that a Counter is just like a BasicCounter except:
1. It implements the Resettable interface (in addition to Counting, already
implemented by -- and hence inherited from -- BasicCounter).
2. It has a no-args constructor that calls its own reset method.
3. It has a reset method that sets its currentValue field to 0.
But this code is not entirely adequate. In fact, it does not compile as is. The
problem is that the currentValue field is not a part of the Counter class any more.
The field currentValue is defined in BasicCounter. But BasicCounter's
currentValue field is private, meaning that only BasicCounters (and the
BasicCounter class, or factory) can access that field. The solution is to change the
visibility of the field from private to protected. This allows the Counter subclass
to access BasicCounter's currentValue field. Now, the Counter code in this
chapter does the same thing as the Counter code in the Chapter on Designing with
Objects.
The moral here is that if you want your class to be extensible -- to be able to be
inherited from -- you will need to make sure that subclasses can get access to
anything that they need to be able to manipulate. This in turn opens those aspects
of your class up to manipulation by other classes, since that information is no
longer private. The visibility level protected is an intermediate point between
private and public, but it does not always provide adequate protection. For details,
see the chapter on Abstraction.

IPIJ || Lynn Andrea Stein

10.3 Constructors are Recipes 10~13

10.3 Constructors are Recipes

We already know that constructors give the special instructions for how to create
a particular kind of object. How does this interact with inheritance?

10.3.1 this()
When a class has more than one constructor, we can express one constructor in
terms of another using the special syntax this(). For example, we might define a
Point class that either could be instantiated using specified values for the x and y
coordinates or could take on the default value (0,0). We might define the
constructors this way:
public class Point
{
private int x, y;

public Point()
{
this( 0, 0 );
// constructor would continue here....
}

public Point( int x, int y )

{
....
The line this( 0, 0 ); in the first (no-args) constructor means "create me using
my other constructor and the arguments 0, 0". In other words, when we say new
Point(), invoking the no-args constructor, this line transfers the responsibility of
providing the instructions for the construction of the Point to the two-int
constructor, supplying the ints 0 and 0 as values. Now, the second constructor
would execute, creating a Point. This new Point's construction process would
continue in the first constructor at the comment
// constructor would continue here....
The point being constructed would be the point resulting from the second
constructor's invocation on 0, 0. Since there are in fact no more instructions in the
first constructor after the comment, execution of this constructor would terminate
and the new point returned would be the point corresponding to (0, 0).
The special buck-passing constructor this() can only be used as the first line of a
constructor.

IPIJ || Lynn Andrea Stein

10~14 Inheritance Chapter 10

10.3.2 super()
Constructors and inheritance work similarly. Making an inherited object (the
"inner object" that belongs to the superclass) is just like passing the buck to a
same-class constructor. The first line of any constructor may be an explicit
invocation of the superclass constructor, supplying whatever arguments are
necessary between the parentheses.
For example, if we wanted to extend the CountingMonitor class, above, to
determine whether the reading of its Counting had changed since the previous
reading, we could add a field (to keep track of the previous reading) and a
conditional in the act() method. But how would we deal with the constructor? The
beginning of this class might read:
public class ChangeDetectingCountingMonitor extends
CountingMonitor
{
private int previousReading;

public ChangeDetectingCountingMonitor( Counting who )

{
super( who );
// ....
The first line of this constructor says "create my inner CountingMonitor instance
using who as its constructor parameter." When the superclass constructor
completes its execution, the remainder of the ChangeDetectingCountingMonitor
constructor body is executed, extending the CountingMonitor instance and
wrapping it in whatever it needs to be a full-fledged
ChangeDetectingCountingMonitor.

10.3.3 implicit super()

We have seen that, when no explicit constructor is supplied, Java blithely inserts a
no-args constructor. Java actually has two dirty little secrets about constructors:

1. If no constructor is provided for a class, Java automatically adds a no-

arguments constructor.
2. Unless a constructor explicitly invokes its superclass constructor or
another (this()) constructor of the same class, Java automatically

IPIJ || Lynn Andrea Stein

10.3 Constructors are Recipes 10~15

inserts super(); as the first line of the constructor.

This means that a class that doesn't seem to have a constructor actually has the
following one:
public ClassName () {
super();
}
What does this do? It means that you can create an instance of the class with new
ClassName() -- because the constructor has no parameters, so you don't have to
give it any arguments -- and it also means that each instance of ClassName has an
instance of the superclass hiding inside it. That is, super(); is a special
incantation that means "Make me an instance of my superclass." (Be careful: there
are two readings of this request: "Give me an instance..." and "Turn me into an
instance...". The second reading is correct.)

The BasicCounter class has such an implicit, automatically inserted constructor,

but the Counter class doesn't. Counter does automatically get the implicit call to
super(); though:
public BasicCounter () {
super();
}
and
public Counter()
{
super();
this.reset();
}
You can, of course, insert this no-args make-me-an-instance-of-my-superclass
constructor into every class definition, and some people like to do so explicitly.

Details:

1. super(); may only appear as the first line of a constructor.

2. The form super(args) may be used if the superclass constructor takes

arguments.
3. If a constructor is defined, this constructor is not automatically added. So,
for example, Echo does not have a no-args constructor.
4. If a superclass does not have a no-args constructor, an explicit call to
super(args) must be used as Java's automatic insertion of super() will
cause a compile-time error.

IPIJ || Lynn Andrea Stein

10~16 Inheritance Chapter 10

What if a class doesn't have a superclass? Every class is a subclass except

Object. If a class doesn't have an extends in its declaration, Java
automatically inserts extends Object. That means that the automatically-
inserted constructor will in general make sense.

Beware: Since Java will automatically invoke the no-args version of super()
unless you explicitly invoke a superclass constructor, either (1) the superclass
must have a no-args constructor or (2) you must explicitly invoke the superclass
constructor yourself, supplying the requisite arguments. If you create a class
without a no-args constructor, you can get into trouble extending it.

Style Sidebar

Explicit use of this. and super()

Although it is not strictly speaking necessary, it is good style to Use this.
wherever it is appropriate, i.e., to denote calls to an object's own fields or
methods. While it makes your code somewhat more verbose, it also makes
it easier to read and to understand what's going on. No method call should
ever be made without reference to its target (i.e., whose method is being
called). Field accessor expressions should always include a reference to the
field's owner, distinguishing them from other name accesses (including
parameter and local variable references).

A class declaration that does not contain an explicit extends clause still
extends Object. Stating this explicitly may make it easier to read your
code.

A constructor that does not call another (this()) constructor explicitly

calls the superclass constructor. If the superclass constructor is not invoked
explicitly, Java will insert a(n implicit) call to super(), the superclass's no-
args constructor. You can make this implicit call explicit by including
super(); as the first line of any constructor that doesn't explicitly invoke
another self- or superclass constructor. This helps to remind you that it is
being called anyway.

IPIJ || Lynn Andrea Stein

10.4 Interface Inheritance 10~17

10.4 Interface Inheritance

A class cannot inherit from an interface; it implements the interface, providing
behavior to match the interface's specification. But one interface can extend
another. Interface inheritance is much simpler than class inheritance. In interface
inheritance, the methods and fields of the inherited (super) interface are simply
combined into the methods and fields of the inheriting (sub) interface. The syntax
for interface inheritance is identical to the syntax for class inheritance, but since
there can be no overriding of method specifications, and since all fields are public
and static therefore cannot be overridden, there is really no complexity to
interface inheritance.
As with class inheritance, if one interface extends another, all instances
implementing the subinterface are instances belonging to both types.

10.5 Relationships Between Types

There are three different type-to-type relationships that will be important in
creating systems. These three relationships correspond to three distinct
mechanisms: implementation, extension, and coupling.
Implementation is a relationship in which one type provides a specification and a
second type provides a specific way of implementing that specification. In this
case, the first type is called an interface and the second type is called a class. For
example, an Alarm is one way of implementing the Resetable specification; an
Animation is another.
Extension is a relationship in which one type adds functionality to another. There
are actually two variants of extension. In one, both types are specifications (i.e.,
interfaces) and the extending specification adds commitments to the extended
specification. StartableAndResetable is an extension of Startable. In the other,
both types are implementations (i.e., classes) and the extending implementation
adds functionality to the extended implementation. A CheckingAccount adds
check-writing functionality to a BankAccount. Extension is implemented using
inheritance, the primary subject of this chapter.
Coupling is a way of giving one object the ability to ask another to help it. For
example, a MicrowaveOven may have a Clock, but a MicrowaveOven isn't a
Clock. MicrowaveOven doesn't implement Clock behavior or extend it. Each
MicrowaveOven has a corresponding Clock, and when the MicrowaveOven needs
to know what time it is, it checks with its own Clock. In this case, the relationship

IPIJ || Lynn Andrea Stein

10~18 Inheritance Chapter 10

is one-to-one (one MicrowaveOven per Clock, one Clock per MicrowaveOven).

There are other cases in which the relationship may be many-to-one (many
Chickens, one Coop) or one-to-many. [IM: Unlike extension and implementation,
coupling is really a relationship between instances; however, like implementation
and extension, it is generally defined within the class.]
It is important to know which of these three relationships ought to hold as you
design your code.
It is always advisable to factor out common commitments and to separate the
users of these contracts from their implementors. Wherever possible, an object
should be known by an interface type rather than a class type to make it possible
for alternate implementations to be used. This is true for both name declarations
and method return types. The only time when an interface cannot be used
routinely is in a construction expression.2
Interface implementation, the result of introducing these interfaces, is generally
easy to recognize. An interface, after all, provides the contract without the actual
implementation.
It is generally more difficult, especially for the novice programmer, to determine
whether it is appropriate to use inheritance or merely containment. Inheritance is
actually relatively rare (among classes) and should be used only when the new
class really reuses the complete behavior of the existing class. This is because
inheritance makes the implementation of the new class tremendously dependent
on the details of the implementation of the existing class. Coupling is a much
more general mechanism. In this case, the new kind of object simply relies on a
previously existing kind of object to provide behavior, forwarding messages on to
the instance of the pre-existing class. If the coupling relies on an interface type
rather than on a class type, a different implementation can easily be substituted.
If you are constructing a class and want to make use of behavior implemented by
another class, you must determine whether you are better off using inheritance
(i.e., extension) or coupling. Here are some questions that you should ask:

• Does this new class present to its users the full range of behavior provided
by the existing class (inheritance) or just some of that behavior
(coupling)?

• Does this new class add behavior to the existing class (inheritance) or

2
But see, e.g., the Factory pattern [GHJV] for an approach to this problem.

IPIJ || Lynn Andrea Stein

10.5 Relationships Between Types 10~19

override it (coupling or a common subclass)?

• Can instances of this new class legitimately be treated as instances of the

existing class (inheritance) or would this be inappropriate (coupling or
common interface)?

• Does an instance of this new class have a different lifetimes from the
associated instance of the existing class (coupling)?
It is only when the superclass will be wholly reused, and when the subclass really
is an extension of the implementation provided by the superclass, that inheritance
should be used. Occasionally, this justifies the use of an abstract class to
encapsulate common behavior that is extended differently by different classes.

Abstract Classes
A class can have a method that is just a signature -- an abstract method.
In a class, however, the abstract method must be explicitly declared
abstract. (Recall that methods in an interface are assumed to be
abstract, even if they are not explicitly so declared.)

If a class has one or more abstract methods, it isn't a complete

implementation. (It doesn't specify how to do the un-implemented method!)
In this case you cannot directly make an instance of this class. (This is like
a partial recipe -- you can't cook anything edible with it, but it may be
useful in building more complete recipes. We will see how to use one
recipe to build another in the chapter on Inheritance.)

A class with one or more abstract methods is called an abstract class.

You cannot construct an instance of an abstract class.3
Abstract classes can be useful when you want to specify a partial
implementation. You should not use an abstract class when you only want
to specify a contract; that is the function of an interface.
We will see examples of abstract classes in later chapters.

3
Technically, a class can be abstract even if it has no abstract methods. However, every
class with at least one abstract method must be declared abstract.

IPIJ || Lynn Andrea Stein

10~20 Inheritance Chapter 10

Chapter Summary
• Inheritance is a mechanism that allows one class to reuse the
implementation provided by another.

• Inheritance should be used only when instances of the subclass can also
reasonably be considered instances of the superclass.

• A class always extends exactly one superclass. If a class does not

explicitly extend another, it implicitly extends the class Object.

• Method lookup always begins with an object's actual (most specific

sub)class, even when the method is invoked by a this. expression in
superclass code.

• A superclass method or (non-private) field can be accessed using a super.

expression.

• If a constructor does not explicitly invoke another (this() or super())

constructor, it implicitly invokes the superclass's no-args constructor.

Exercises
1. In the first interlude, we wrote "UpperCaser extends StringTransformer".
Explain.
2. Extend the Counter to count by 2.

3. Complete the definition of ChangeDetectingCountingMonitor from above.

4. In this exercise, you will re-implement AnimateTimer in two different ways
and then compare them.

a. Re-implement Timer by extending Counter.

b. Extend the class in the previous exercise by making it Animate.
c. Now re-implement AnimateTimer by extending AnimateObject directly.
d. What if any type relations would exist between an instance of the class
produced in (b) and the class produced in (c)?

IPIJ || Lynn Andrea Stein

 11
Chapter 11 When Things Go Wrong: Exceptions

Chapter Overview
• What happens when something goes wrong?

• How do I create alternate ways to handle atypical circumstances?

This chapter covers mechanisms for dealing with atypical behavior. Sometimes,
exceptional circumstances arise and require different mechanisms to cope with
them. In this case, the normal entity-to-entity communication in your system may
need to be interrupted. Java provides certain mechanisms for creating alternate
paths through your community. These include the throw and catch statements as
well as special Exception objects that keep track of these atypical circumstances.
This chapter includes sidebars on the syntactic and semantic details of throw and
catch statements, exception objects, and the requirement to declare exceptions
thrown. It is supplemented by portions of the reference charts on java methods
and statements.

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
11~2 When Things Go Wrong: Exceptions Chapter 11

Objectives of this Chapter

1. To be able to read, understand, and write throws clauses as a part of
interface and class contracts.

2. To learn how to throw and catch Exceptions and other Throwables.

3. To appreciate the role that anticipating exceptional circumstances plays in
the design and testing of programs.

11.1 Exceptional Events

So far, the code that we have written has addressed "normal" situations in which
nothing goes wrong. But sometimes, unusual things happen in our code, and we
have to deal with them. In some cases, these unusual things are unexpected errors;
in others, their existence is predictable but we may not know in advance when
they are likely to happen. An example of this second kind is a network outage,
which happens from time to time and can reasonably be anticipated, but is
unexpected when it occurs. Planning for these exceptional circumstances and
writing code that can cope with them is an important part of robust coding.

11.1.1 When Things Go Wrong

Consider the following example, drawn from the StringTransformers application
of the first interlude. In that scenario, entities called StringTransformers are
connected by "tin can telephone" entities called Connectors. Each Connector has
an end that you can put something into and an end that produces what you put into
it. A StringTransformer can write to (or read from) a connector if it is holding the
appropriate end. In the user interface of that application, there is a way that a user
can specify two StringTransformers to be connected. We are going to look in
more detail at how the Connector actually gets attached to these two
StringTransformers.
Let's say that the two transformers we're going to connect are transformerA and
transformerB. In the code that is making the connection, we invoke the specific
Connector constructor with these transformers as arguments:
new StringConnector( transformerA, transformerB )
The constructor code for StringConnector asks each of the transformers, in turn,
to accept a(n input or output) connection. In fact, strictly speaking, A and B need
not be StringTransformers at all; they need only implement the OutputAcceptor or

IPIJ || Lynn Andrea Stein

11.1 Exceptional Events 11~3

InputAcceptor interfaces, since that is the only aspect of their behavior that we
rely on here.
public StringConnector( OutputAcceptor a, InputAcceptor b )
{
a.acceptOutputConnection( this );
b.acceptInputConnection( this );
}
This code is perfectly reasonable assuming that everything goes right. But what
happens if transformerA already has an outputConnection in place? It might be
that transformerA is a Broadcaster or AlternatingOutputter or some other kind of
transformer that can have many outputConnections. It might be that transformerA
is willing to throw away its existing outputConnection and replace it with the one
currently on offer. But it might also quite reasonably be that transformerA is
unwilling and unable to accept an OutputConnection if it already has one in place.
In this case, the StringConnector constructor code is in trouble.
This is precisely the sort of situation that we will deal with in this chapter.
Something has gone wrong. We can anticipate in our design that this might
happen. We want our code to respond appropriately. In other words, we want to
design our programs to be able to handle exceptional circumstances.

11.1.2 Expecting the Unexpected

When you are designing a program, it is relatively easy to think about what is
supposed to happen. You can act out the interactions that you want your program
to have. You can draw out storyboards describing what comes next. You design
interfaces and protocols to describe the roles each entity plays and the contracts it
makes with others. But this is not enough.
In addition to figuring out what ought to happen, you also need to anticipate what
might happen. That is, you need to understand what happens if a component does
something unexpected; if the user does something foolish; if a resource that you
depend on becomes unavailable or temporarily out of service; or even if a change
that you make to your code inadvertently violates an assumption. In all of these
cases, unexpected behavior of one portion of the system needs to be dealt with.
Good design involves anticipating these possibilities and explicitly deciding what
to do and designing for these circumstances.
Exceptional circumstances can be partitioned into three groups. One is the
catastrophic failure. In case of a catastrophic failure, there's really nothing that
your program can do. This might happen, for example, if someone tripped over

IPIJ || Lynn Andrea Stein

11~4 When Things Go Wrong: Exceptions Chapter 11

the power cord of the computer on which your program was running. In this case,
it is reasonable to expect that your computer program will stop executing
immediately. There's really nothing that you can do about a catastrophic failure. 1
The second kind of exceptional circumstance is at the other end of the spectrum.
This is a situation that is not the intended course of your program, but is so benign
that it is dealt with almost as a matter of course. These are the unexpected
situations that can be handled with a simple conditional or other testing
mechanisms. For example, if we are about to perform a division operator, we
might check to make sure that the divisor is not 0. In the extreme, these situations
can be difficult to distinguish from "normal" operation.
Most exceptional circumstances fall between these two extremes. That is, they
admit some intervention or even solution (unlike catastrophic failure), but
handling these circumstances requires cooperation among entities or other
addtional complexity; it isn't possible or desirable to deal with this situation
locally. These are the situations that you must take into account in your design.
When you are planning your program, you will be deciding how to partition the
problem among a community of interacting entities and designing how these
entities interact. At this point, you should also ask:

• What should happen if one of these entities is unreachable?

• What are all of the ways in which an entity might violate expectations?

• What should happen in each of these cases?

• What should an entity do if it has difficulty fulfilling its contract?

In each of these cases, you should decide whether the circumstance amounts to a
catastrophic failure or can be handled by another entity. If it is a catastrophic
failure, this circumstance ought to be documented; if not, it provides another set
of interactions to build into your system. This exception-handling becomes
another part of your system design.
As you break each entity down -- asking what is inside it, decomposing it into
further communities of interacting entities -- you should repeat these questions

1
At least at the time of failure. There are still things that you can do to plan for recovery from
catastrophic failure. For example, a banking system may temporarily lose the functioning of an
ATM, but it will not lose track of your bank balance entirely. It has been designed to keep this
information safe even in the face of computer crashes.

IPIJ || Lynn Andrea Stein

11.1 Exceptional Events 11~5

with respect to these entities' mutual commitments. Eventually, you will

decompose your problem to the level of individual operations and of interactions
with entities outside the system that you are actually building. For these
situations, you should ask:

• In what ways might this operation or outside entity fail?

• How else might it violate my expectations?

• Can I test for these circumstances prior to invocation of this operation or

resource?

• What should I do if the failure or expectation violation occurs?

If the situation is one that can be ruled out using a simple test -- such as checking
for a zero divisor or verifying that the user's input is a legal value and asking for
new input if not -- such error checking should be introduced into your design.
This strengthens the contracts that entities make with one another. Where
violations cannot be handled locally, you will need to decide who should handle
the issue and how it should behave.

11.1.3 What's Important to Record

At the time that an exceptional circumstance arises, the currently executing code
is in the best position to determine what the problem is. It should take pains to
record any information that might help other parts of the program (or a human
user or debugger) to figure out what happened. So, for example, in the case of a
divide-by-zero error, it would be important to know what the expression was
whose value was zero, causing the error. In the case of an invalid value entered by
a user, it may be important to know what the invalid value is or what the legal
values might be. It is also important to know what kind of thing went wrong:
division by zero or illegal argument passed to a method or a label name that's null
and shouldn't be or any of a whole host of possible values.
This information -- what kind of thing went wrong and kind-specific additional
information that might be useful for figuring out what the problem was or
correcting it -- is, in Java, encapsulated in a special kind of object. These are
Exception objects. They signal what's gone wrong. There are many different
(more specific) types of Exception objects, such as NullPointerException or
IllegalArgumentException. You can also define Exception types of your own
(using inheritance). In addition to Exceptions, Java also defines a (similar but

IPIJ || Lynn Andrea Stein

11~6 When Things Go Wrong: Exceptions Chapter 11

distinct) class of Errors, meant to designate conditions of catastrophic failure,

such as NoClassDefFoundError. You can (but rarely will) define your own Errors
as well.
Since Exceptions are objects, you can use them like any other object. If you
define your own Exception classes, you can add any fields or methods that you
think might be important to allow your program to handle the exceptional
circumstance. One thing that is especially useful for an Exception to have is a
String (suitable for printing to a user) that explains something about what has
gone wrong. In Java's Exception classes, such a String can be supplied to the
constructor and retrieved using the instance's getMessage() method.
It can also be very important to know where the problem occurred. Java's
Exception classes record the point at which they were thrown (see below), but it
can in addition be useful to record (e.g., in the message or in an additional field
that you define) some program-specific indication of which code is reporting the
exceptional circumstance and what it was trying to do when the exception
occurred.
For example, in our OutputAcceptor code, we might recognize that we can't
accept an OutputConnection if we already have one. In this case, we might create
a new ConnectionRejectedException recording this circumstance:
new ConnectionRejectedException( this.toString()
+ " rejecting redundant OutputConnection" )
The ConnectionRejectedException uses the toString() method of the
OutputAcceptor within which this code occurs to record who is rejecting the
connection. An alternative is just to list the class name and method in a constant
String: "OutputAcceptor.acceptOutputConnection(): ". The
ConnectionRejectedException might also record the existing OutputConnection
and the newly supplied one; in the code fragment above, it does not do this.
Just defining a new exception isn't enough, though. Defining an exception is like
composing a letter of complaint. In order for it to have any effect, you have to
send out the letter. In the case of an Exception, this is accomplished by throwing
the Exception.

IPIJ || Lynn Andrea Stein

11.2 Throwing an Exception 11~7

11.2 Throwing an Exception

An Exception is an unusual circumstance that requires special handling. In order
to understand how an Exception works -- and what it means to throw one -- we
first need to look at how method invocation and return normally works.
Let us begin by looking more closely at what happens in our new Connector
example, when the user interface calls the StringConnector constructor, which in
turn calls the OutputAcceptor's acceptOutputConnection method. We might
diagram the normal control flow as follows:
User Interface Constructor OutputAcceptor
-------------------->
------------------->
(records Connection)
<-------------------
(more activity)
<--------------------
The code from the user interface invokes the StringConnector constructor, then
the StringConnector constructor invokes the OutputAcceptor's
acceptOutputConnection method. When the acceptOutputConnection method
completes, it returns (nothing) to the StringConnector's constructor, which
completes its work and provides the newly constructed StringConnector to the
User Interface. These arrows are sometimes called the call path (and return path)
of this execution.
Communication among pieces of code is very simple. Each piece of code can only
talk to the other pieces of code about which it knows. In this case, the User
Interface knows about the StringConnector's constructor, and the
StringConnector's constructor knows about the OutputAcceptor's
acceptOutputConnection method. Think of it like an old-fashioned fire-fighting
bucket brigade. All of the people line up from the water supply to the fire. A full
bucket is passed from hand to hand down the line from the water supply to the
fire. The empty bucket must be passed back the same way. In the normal motion
of buckets, there is no way for a bucket to skip over a person; it must be passed
from hand to hand, returning the way that it came.2

2
In this example, the "more activity" line inside the constructor is a shorthand for a more complex
picture. This "more activity" actually involves another method call, this one to the InputAcceptor's

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
11~8 When Things Go Wrong: Exceptions Chapter 11

Throwing an Exception is different. What happens in this case looks more like the
following:
User Interface Constructor OutputAcceptor
-------------------->
------------------->
OH NO!!
When the OutputAcceptor's acceptOutputConnection method realizes that it has a
problem it generates an Exception object, as we have seen above. Then, it throws
the exception as hard as it can back the way it came. The Exception zooms back
along the call path, flying too fast to stop and execute any statements waiting for
its return. In fact, the Exception keeps going until it encounters a compatible

acceptInputConnection method. So the whole picture is more accurately represented as

User Interface Constructor OutputAcceptor InputAcceptor

------------------->
------------------>
(records Connection)
<------------------
------------------------------------->
(records
Connection)
<-------------------------------------
<------------------
This doesn't violate the bucket brigade idea, but it does mean that the bucket brigade has a fork in
it. The constructor can pass buckets to (i.e., invoke) both the OutputAcceptor's
acceptOutputConnection method and the InputAcceptor's acceptInputConnection method.

IPIJ || Lynn Andrea Stein

11.2 Throwing and Exception 11~9

catch statement. If necessary, it may exit several method bodies. Or, if the catch
is in the same block as the throw, it may not exit any method bodies at all. In
other words, a throw statement sets an Exception flying, and the flying Exception
can only be caught by a matching catch statement; no other intervening statement
along the call path matters.
This is, in fact, just what we want. If the OutputAcceptor can't accept an output
connection, we don't want the rest of the Constructor to execute. For example, we
don't want it to try to convince the InputAcceptor to accept the input end of the
connection, because this connection isn't going to work out (since the
OutputAcceptor isn't cooperating) and if the InputConnector accepts this one, then
it won't later be able to accept a fully operational input connection. So when the
OutputAcceptor decides that it has a problem, we want the Exception to
propogate all the way back to the user interface code, which should decide that
connecting this particular pair of String Transformers may not be such a good
idea after all.
The code for the OutputAcceptor might look like this:
... implements OutputAcceptor
{
private OutputConnection out;

public void acceptOutputConnection( OutputConnection out )

{
if ( this.out == null )
{
this.out = out;
}
else
{
throw new ConnectionRejectedException( this.toString()
+ " rejecting redundant OutputConnection"
);
}
}

This example introduces a new statement type, throw, and a new declaration
element, throws. (Note the s on the declaration element.) The throw statement
works just as we have described; it abruptly terminates the execution of this
method and causes the Exception to propogate backwards along the return path
until a compatible catch statement is encountered. (We will see this below.)
What about the throws clause? Throwing an exception is actually part of the
contract that one object makes with another. It is as much a part of a method's
contract as its (normal) return type or the parameters it needs. So a method must
declare that it may throw an exception (and what type of exception it may throw).

IPIJ || Lynn Andrea Stein

11~10 When Things Go Wrong: Exceptions Chapter 11

This way, anyone calling the method knows to be prepared for it to throw this
exception. The throws clause is the final part of a method signature, and throws
clauses may appear in interface (abstract) method declarations as well as in
method definitions.
Throws clauses are not restricted to methods. Constructors, too, must declare any
exceptions that they throw. A constructor can explicitly throw an exception using
a throw statement. A constructor (or method) can also throw an exception by
calling something that throws an exception and then not catching it. This is what
happens with the StringConnector constructor. Here it is, reprinted from above,
with the added throws clause underlined.
public StringConnector( OutputAcceptor a, InputAcceptor b )
throws ConnectionRejectedException
{
a.acceptOutputConnection( this );
b.acceptInputConnection( this );
}

The StringConnector constructor invokes OutputAcceptor's

acceptOutputConnection method. If the OutputAcceptor doesn't accept the output
connection, the StringConnector constructor isn't going to be able to fix this. So
the StringConnector constructor should itself exit abruptly. In other words, the
Exception thrown by acceptOutputConnection flies right out of the
StringConnector constructor as well, still waiting to find a compatible catch
clause.

IPIJ || Lynn Andrea Stein

11.2 Throwing and Exception 11~11

Throw Statements and Throws Clauses

A throw statement looks a lot like a return statement, but it always takes
an argument (which can be in parentheses or not), and its argument must be
something legal to throw. Anything that extends Throwable is legal to
throw. In particular, this includes anything that extends Exception.

The effect of a throw statement is that execution abruptly returns up the

call path until a compatible catch clause is encountered. Nothing except a
compatible catch clause can stop the propogation of a thrown object.
If an Exception (except a RuntimeException) is thrown and not caught
within a method or constructor body, you must also declare that that
method or constructor throws the exception. This is a part of the signature,
like saying what a methodreturns or what arguments a method or
constructor expects.

The throws clause appears after the argument list, but before the
method/constructor body. The syntax for a throws clause is
throws ExceptionType1, ExceptionType2, ... ExceptionTypeN

Every exception thrown and not caught within the body must match (at
least) one of the exception types declared thrown by the method or
constructor. If the method or constructor throws only a single exception
type, the list contains no commas.

11.3 Catching an Exception

We have seen how an Exception can be generated and thrown. We have also seen
that a thrown exception keeps flying until it encounters a compatible catch
statement. Now, we will look at catch statements and how they work. This code
introduces new syntax: the try/catch statement type. If throws is syntactically
like return, try/catch is a bit like if/else.
A catch statement is properly a try/catch statement (or even more properly a
try/catch/finally statement). If you are about to execute a statement that might
throw an exception that you'd like to catch, you must first enter a try block. This
is just like a regular block, except that it is preceded by the Java keyword try. This
notifies Java that exceptions may be thrown and that it should be on the lookout

IPIJ || Lynn Andrea Stein

11~12 When Things Go Wrong: Exceptions Chapter 11

for the ones that you want to catch.

At the end of the possible-exception-throwing code, you end the try block and
introduce a catch clause. A catch clause contains a parameter declaration of the
type that you wish to catch. The catch clause has a block that describes the
instructions to execute if one of these is caught.
For example, the code in the user interface that is trying to connect transformerA
(here named by to) and transformerB (here named by from) might say:
try
{
new StringConnector( to, from );
}
catch ( ConnectionRejectedException e )
{
Console.println( "Sorry, can't make that connection. "
+ "Please try again." );
}

• This try/catch statement type has two bodies: one after the keyword
try,and one after the catch parameter.

• The try body is a statement or set of statements that may throw an

exception. In this case, we know that the StringConnector constructor
may throw ConnectionRejectedException. We can tell this from its
declaration, and so can the Java compiler.

• The catch portion of the statement has a single parameter, the exception
(type and name) that is to be caught. In this case, the exception type is
ConnectionRejectedException, and the name of the exception is e.
The name is required, and it may be used inside the catch body, just like a
method parameter name can be used inside the method body. It is common
to name the exception e, though there's no particular reason for it; it's just
like loop variables are often named i.

• The catch body contains statements which are executed if and only if the
appropriate type of exception is thrown. (The "appropriate type" is the
type of the catch's parameter.) Inside the catch body, the parameter name
may be used to refer to the exception, though there isn't a whole lot you
can do with an exception other than print its message.
In this case, once the exception is caught, a message is printed to the user. This
statement might itself appear inside an animate object's act method, so that
something is continually listening to the user and trying to make connections on

IPIJ || Lynn Andrea Stein

11.3 Catching an Exception 11~13

the user's behalf. This message lets the user know that this particular attempt
didn't work. If we had supplied additional information along with the exception,
we might use it at this point to give the user more information (perhaps flashing
the object that refused the connection) or to try to repair the situation (asking
whether the user means to delete the existing connection, for example, and then
retrying the connection creation).

One try can actually have several catch statements. In this case, once something
is thrown inside the try body, it is compared against the catch parameter
statements in order until one that matches is found. If a match is found, only the
first matching catch body is executed; then control continues at the end of the
try/catch statement. If no match is found, the thrown object continues exiting
statement blocks until a corresponding catch is found.

For completeness's sake, it is worth mentioning that a try/catch statement can

have a finally clause (so that it's really try{}catch(){}finally{}). In this
case, no matter how the statement is exited -- regardless of whether something is
thrown, and regardless of whether the thrown object is caught -- the finally
statement will be executed. At this point, you shouldn't need to be using finally,
but if you ever need to know, the gory details are included in the Java language
specification.

IPIJ || Lynn Andrea Stein

11~14 When Things Go Wrong: Exceptions Chapter 11

Try Statement Syntax

A try/catch/finally statement has a body after try, a body after each
catch clause, and a body after the finally clause if it is present. Each of
these bodies is a normal block executed according to the usual block
execution rules. If a catch block is executed (i.e., if a matching throwable
has been caught), the catch parameter is bound to the caught object during
execution of the catch block.

The try body is a statement or set of statements that may throw an

exception. Although not every execution of the try statement must throw an
exception, the try statement must contain at least one expression that is
declared as throwing each of the types of exceptions listed in its catch
clauses.

Each catch clause has a single parameter (type and name) followed by a
block. A catch clause matches the thrown object exactly when the thrown
object can be named by a name of the catch clause's parameter type. Only
the first matching catch clause is executed.

The try statement is executed as follows:

• The try block is executed in order until something is thrown or the end
of the try body is reached.

• If nothing is thrown during the try body, execution continues after the
final catch clause of the try/catch statement.)

• If something is thrown during the try body, it is compared against the

parameter of each catch block, in turn, until a match is found. In this
case, that catch block is executed (as a normal block) with the parameter
bound to the (matching) caught object. At most one catch block of a try
statement is executed.
A try statement may also have a single optional finally clause. This is
the keyword finally followed by a block. If the try statement is entered,
the finally clause is always executed. This leads to somewhat
complicated execution rules, described below and further documented in
Sun's Java Language Specification. Finally clauses are largely outside
the scope of this book and are included here only for completeness.
The following two points explain the special behavior of try statements

IPIJ || Lynn Andrea Stein

11.4 Throw vs. Return 11~15

with finally blocks

• After execution of at most one matching catch block, execution proceeds

at the finally block (if it is present). If a try statement is entered, its
finally block is always executed, regardless of the execution within the
try statement.

• If no uncaught exceptions remain on exiting the finally block, execution

proceeds after the end of the try/catch/finally statement. If there is an
outstanding thrown object, execution proceeds with the continued flight
of that throwable.

11.4 Throw vs. Return

There are both similarities and differences between throw and return statement
types. Both involve a single Thread following instructions that may take it from
one method or constructor to another, often moving across multiple objects. From
the perspective of the Thread, the objects (and their methods and constructors) are
providing roles that it plays, scripts that it reads, or instructions that it follows.
When a Thread is executing some instructions and reaches a method invocation
expression (or an instance creation expression), it carefully records its current
place in the script, puts the current script down on the table in front of it, and
picks up the invoked method script. If fulfilling that expression in turn involves a
further invocation, yet another script will be added to the pile on the table. When
an invocation completes, the Thread puts the corresponding script away and
returns to the carefully marked pending method invocation (or instance creation)
expression on top of the pile.
In other words, to clear off the pile, the Thread must pick up each script in order
on its way out and complete any remaining instructions before going on to the
next. Every method invocation or instance creation expression eventually returns
control to the body of code from which the call was invoked. The Thread
eventually returns to the carefully marked spot and continues from there.
A major difference between return and throw statements is in how this execution
proceeds, i.e., whether the Thread continues executing one instruction at a time or
simply flies over the instructions looking for a matching catch statement. When
a Thread returns normally from a method, execution continues one instruction at a
time. When a Thread encounters a throw statement, it steps back through its pile

IPIJ || Lynn Andrea Stein

11~16 When Things Go Wrong: Exceptions Chapter 11

of carefully marked scripts rather rapidly, scanning down the instructions until an
appropriate catch statement is encountered. If the current script doesn't contain a
matching catch statement, it is summarily discarded and the next script is
examined in turn.

This means that a return statement always causes the current method to
complete, returning control to whomever called this method. This is true no
matter how many statement blocks the return is buried inside. A return always
exits exactly one method invocation.

In contrast, a throw exits one block at a time until a catch of the appropriate type
is found. This means that a throw may not exit any methods (if the throw occurs
directly inside an appropriate try/catch), or the throw may exit many methods
(if the exception is not caught in any of these calling methods). A throw exits
blocks until an appropriate catch is encountered.

IPIJ || Lynn Andrea Stein

11.4 Throw vs. Return 11~17

Exceptions, Errors, and RuntimeExceptions

In Java, any instance whose class extends the class Throwable can be
thrown and caught. Two special subclasses of Throwable are defined for
use under exceptional circumstances.

Error is the Java class that denotes a catastrophic failure. This is an event
from which your program is not expected to be able to recover. A well-
designed robust program that is expected to have an extended lifetime (such
as a banking system or an airline reservation system) must have ways of
dealing with catastrophic failure, but most programs that you write will not
have to worry about such circumstances.

Exception is the Java class that indicates a non-catastrophic failure.

Exceptions are cirucmstances from which your program should recover (or
at least exit gracefully).
All Java built-in error and exception classes have two constructors, one that
takes no arguments and one that takes a single String argument. This String
can be accessed using the getMessage() method of Error or Exception. If
you define your own subclass, it is a good idea to define these two
constructors there as well.

RuntimeException is a special subclass of Exception. RuntimeExceptions

are circumstances from which your program should recover, but -- unlike
for other Exceptions -- methods and constructors throwing
RuntimeExceptions do not have to declare this fact.
All Exceptions other than RuntimeExceptions are called checked
exceptions. A method or constructor that may throw a checked exception
must declare this fact, allowing the compiler to check for the presence of
exception handlers. This can be very helpful in debugging, so you will
generally want to extend Exception rather than RuntimeException.
When overriding a superclass method, a subclass method may only throw
those checked exceptions also declared by the (overridden) superclass
method. In other words, an overriding method may throw fewer things than
promised by its superclass, but it may not throw additional (checked)
things.

IPIJ || Lynn Andrea Stein

11~18 When Things Go Wrong: Exceptions Chapter 11

11.5 Designing good test cases

One of the most important parts of being a good programmer is knowing how to
test your code. To begin this phase, write down all of the assumptions that your
code makes. Think of something that violates one of these assumptions; will this
break your code? How about something that violates three of these assumptions?
Once you have all of your assumptions written down, think about things that are
extreme but within your assumptions. Try to design test cases for these. Think of
every feature your code has, and every situation in which this feature could
possibly be exercised. Design test cases for these as well. And don't forget the
simple cases; it is always worth testing these as well as the pathological ones.
Your goal should be to thoroughly and exhaustively test your code, so you should
design your test suite to exercise your program as fully as possible. You should
also design test cases to catch bugs you think that other people might make. In
particular, you should try to identify any weaknesses or difficult cases and design
examples that stress these elements.
Finally, you should keep this test suite around, so that as you modify your code,
you can test it again on these same examples, making sure that it still handles all
of the old cases.

Chapter Summary
• In designing a program, you should anticipate things that can go wrong
and design in mechanisms to deal with them.

• Catastrophic failures cannot be prevented, but certain systems need

to design in mechanisms to minimize the damage that they cause.

• Some failures can be anticipated and avoided through simple

checks and guards.

• Other failures must be handled as they arise, often using Java's

exception handling mechanims.

• Exceptions should record information that is useful for addressing the

problem as well as information that is useful for advising the debugger or
the human user.

IPIJ || Lynn Andrea Stein

 Exercises 11~19

• When an exception is thrown by a method or constructor, it exits each

enclosing block in turn until a matching catch statement is encountered.

• Methods and constructors that may throw checked exception types must
declare this fact in their signatures.

• A method invocation or constructor that may throw a checked exception

may be safely invoked within a try block with a corresponding catch
statement. The catch statement is responsible for attempting to recover
from the exception.

Exercises
1. Describe the process of baking a cake. Include at least three exceptional
circumstances that might arise and how these should be handled.
2. Describe the normal conduct of a soccer game. Include at least three
exceptional circumstances that might arise and how these should be handled.
3. Define an Exception type called UnbelievableException. Remember to define
two constructors.
4. Using your UnbelievableException type, write an animate object that
continually asks the user for the user's age, then throws an UnbelievableException
if appropriate. Note: the presence of an unbelievable age should not cause the
program to terminate.

IPIJ || Lynn Andrea Stein

 12
Chapter 12 Dealing With Difference: Dispatch

Chapter Overview
• How can I do different things at different times or under different
circumstances?

• How can one method respond appropriately to many different

inputs?
In previous chapters, we have looked at entities that respond to each input in
roughly the same way. In this chapter, we will look at how an entity can respond
differently depending on its input. In particular, we will look at how to build the
central control loop of an entity whose job is to dispatch control to one of a set of
internal "helper" procedures.
This chapter introduces several mechanisms for an entity to generate different
behavior under different circumstances. Conditionals allow you to specify that a
certain piece of code should only be executed under certain circumstances. This
allows you to prevent potentially dangerous operations -- such as dividing by zero
-- as well as to provide variant behavior.
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
12~2 Dispatch Chapter 12

The decision of how to respond often depends on the value of a particular

expression. If there are a fixed finite number of possible values, and if the type of
this expression is integral, we can use a special construct called a switch statement
to efficiently handle the various options. A switch statement is often used together
with symbolic constants, names whose most important property is that each one
can be distinguished from the others.
Arrays are specialized collections of things. They allow you to treat a whole
group of things uniformly. Arrays can be used to create conditional behavior
under certain circumstances.
Procedural abstraction (covered in the next chapter) also plays a crucial role in
designing good dispatch structures.
This chapter includes sidebars on the syntactic and semantic details of if, switch,
and for statements, arrays, and constants. It is supplemented by portions of the
reference chart on Java Statements.

12.1 Conditional Behavior

The animate objects that we have seen so far generally execute the same
instructions over and over. A clock ticks off the time. A stringTransformer reads a
string, transforms it, and writes it out. A web browser receives a url request,
fetches, and displays the web page. And so on. These entities repeatedly execute
what we might call a central control loop, an infinitely repeated sequence of
action.
In this chapter, we look instead at entities whose responses vary from one input to
the next, based on properties of that input. The actual responses are not the subject
of this chapter; instead, we will largely assume that the object in question has
methods to provide those behaviors. The topic of this chapter is how the central
control loop selects among these methods. This function -- deciding how to
respond by considering the value that you have been asked to respond to -- is
called dispatch.
Imagine that we are building a calculator. One part of the calculator -- its
graphical user interface, or GUI -- might keep a list of the buttons pressed, in
order. The central controller might loop, each time asking the GUI for the next
button pressed. The primary job of this central control loop would be to select the
appropriate action to take depending on what kind of button was pressed, and then
to dispatch control to this action-taker. For example, when a digit button is

IPIJ || Lynn Andrea Stein

12.1 Conditional Behavior 12~3

pressed, the calculator should display this digit, perhaps along with previously
pressed numbers.1 Pressing an arithmetic function key -- such as + or * -- means
that subsequent digits should treated as a new number -- the second operand of the
arithmetic operator -- rather than as additional digits on the first. Pressing =
causes the calculator to do arithmetic. And so on.
In this example, the calculator's central control loop is behaving like a middle
manager. It's not the boss, who gets to set direction. It's not the worker, who
actually does what needs to be done. The dispatcher is there to see that the boss's
directions (the button pressed) get translated into the appropriate action (the
helper procedure). The dispatcher is simply directing traffic. This kind of
behavior, in which different things happen under different circumstances, requires
conditional behavior. We have already seen a simple kind of conditional behavior
using Java's if statement. In this chapter, we explore several different means of
achieving conditional behavior in greater detail.
Throughout this chapter, we will assume that we have methods that actually
provide this behavior. For example, the calculator might have a
processDigitButton method which would behave like exercise # in Chapter 7.
Another method, processOperatorButton, would apply the appropriate
operation to combine the value currently showing on the calculator's display with
the number about to be entered. We will also use methods such as
isDigitButton to test whether a particular buttonID corresponds to a number
key. Separating the logic surrounding the use of these operations from their
implementation is an important part of good design and the topic of much of the
chapter on Encapsulation.
In this chapter, we are going to concern ourselves with what comes after the first
line of the calculator's act method:
public void act()
{
SomeType buttonID = this.gui.getButton();
....
}
The remainder of this method should contain code that calls, e.g.,
processDigitButton if buttonID corresponds to one of the buttons for digits 0
through 9, or processOperatorButton if buttonID corresponds to the button for

1
Pressing 6 right after you turn on a calculator is different from pressing 6 after pressing 1 right
after you turn on a calculator. In the first case, the calculator displays 6; in the second, it displays
16.

IPIJ || Lynn Andrea Stein

12~4 Dispatch Chapter 12

addition. This chapter is about deciding which of these is the correct thing to do.

12.2 If and else

We have already seen the if statement, Java's most general conditional. Almost
every programming language has a similar statement type. An if statement is a
compound statement involving a test expression and a body that can include
arbitrary statements. Any conditional behavior that can be obtained in Java can be
accomplished using (one or more) if statements. An if statement corresponds
closely to normal use of conditional sentences in every-day language. For
example, "If it is raining out, take an umbrella with you" is a sentence that tells
you what to do when there's rain. Note that this sentence says nothing about what
to do if there is no rain.

12.2.1 Basic Form

Every if statement involves two parts: the test expression and the consequent
statement. The test expression represents the condition under which the
consequent should be done. The test expression is some expression whose type
must be boolean. In our example sentence, this boolean expression is "it is
raining out". This expression is either true or false at any given time2, making it a
natural language analog to a true-or-false boolean. In Java, this expression must
be wrapped in parentheses.
When an if statement is executed, this conditional expression is evaluated, i.e., its
value is computed. This value is either true or false. The evaluation of the
boolean test expression is always the first step in executing an if statement. The
rest of the execution of the if statement depends on whether this test condition is
true or false.

In the English example above, if "it is raining out" is true -- i.e., if it is raining out
at the time that the sentence is spoken -- then you should take an umbrella with
you. That is, if the condition is true, you should do the next part of the statement.
This part of the if statement -- the part that you do if the test expression's value is

2
Excluding that sort of grey dreary drippy weather that haunts London and certain times of the
year in Maine, of course.

IPIJ || Lynn Andrea Stein

12.2 If and else 12~5

true -- is called the consequent.

In Java, execution of an if statement works the same way. First, evaluate the
boolean test. If the value of the test expression is true, then execute the
consequent. If the value of the test expression is false, the consequent is not
executed. In this case, evaluating the test expression is the only thing that happens
during the execution of the if statement. Note that the value of the expression
that matters is its value at the time of its evaluation. If the test is executed at two
different times, it may well have two different values at those times.
In Java, the consequent may be any arbitrary statement (including a block). In this
book, we will always assume that the consequent is a block, i.e., a set of one or
more statements enclosed in braces.

true {
if ( booleanTes tExpression ) consequentStat ements
}

false

if execution path

We could write pseudo-code for our English conditional as follows:

if ( currentWeather.isRaining() )
{
take(umbrella);
}
This isn't runnable code, of course, but it does illustrate the syntax of a basic if
statement: the keyword if, followed by a boolean expression wrapped in
parentheses, followed by a block containing one or more statements. To execute
it, we would first evaluate the (presumably boolean) expression
currentWeather.isRaining() (perhaps by looking out the window) and then,
depending on whether it is raining, either take an umbrella (i.e., execute take(
umbrella )) or skip it.

A somewhat more realistic example is the following code to replace a previously

IPIJ || Lynn Andrea Stein

12~6 Dispatch Chapter 12

defined number, x, with its absolute value:

if ( x < 0 ) {
x = - x;
}
This code does nothing just in case x is greater than or equal to 0.3 If x happens to
be less than 0, the value of x is changed so that x now refers to its additive
inverse, i.e., its absolute value.

Note that the same if statement may be executed repeatedly, and the value of the
boolean test expression may differ from one execution of the if statement to the
next. (For example, it may be raining today but not tomorrow, so you should take
your umbrella today but not tomorrow.) The value of the boolean test expression
is checked exactly once each time the if statement is executed, as the first step of
the statement's execution.

12.2.2 Else
The if statement as described above either executes its consequent or doesn't,
depending on the state of the boolean test expression at the time that the if
statement is executed. Often, we don't want to decide whether (or not) to do
something; instead, we want to decide which of two things to do. For example, if
it's raining, we should take an umbrella; otherwise, we should take sunglasses. We
could express this using two if statements:
if ( currentWeather.isRaining() )
{
take(umbrella);
}

if ( ! ( currentWeather.isRaining() ) )
{
take(sunglasses);
}
Recall that ! is the Java operator whose value is the boolean opposite of its single
argument. So if currentWeather.isRaining() is true, then !
(currentWeather.isRaining()) is false; if currentWeather.isRaining() is
false, then ! (currentWeather.isRaining()) is true.

3
It evaluates the expression x < 0, of course, but it "does nothing" that has any lasting effect.

IPIJ || Lynn Andrea Stein

12.2 If and else 12~7

These two conditional statements, one after the other, are intended to express
alternatives. But they don't, really. For example, the two statements each check
the boolean condition currentWeather.isRaining(). This is like looking out
the window twice. In fact, the answer in each of these cases might be different. If
we don't get around to executing the second if statement (i.e., looking out the
window the second time) for a little while, the weather might well have changed
and we'd find ourselves without either umbrella or sunglasses (or with both). The
weather doesn't usually change that often (except in New England), but there are
plenty of things that your program could be checking that do change that quickly.
And, since your program is a community, it is always possible that some other
member of the community changed something while your back was turned.4
Instead of two separate if statements, we have a way to say that these two actions
are actually mutually exclusive alternatives. We use a second form of the if
statement, the if/else statement, that allows us to express this kind of situation.
An if/else statement has a single boolean test condition but two statements, the
consequent and the alternative. Like the consequent, the alternative can be
almost any statement but will in this book be restricted to be a block.

true {
if ( booleanTestExpression ) consequentStatements
}

false

else {
alternativeStatements
}

if/else execution path

4
But see chapter 20, where we discuss mechanisms to prevent the wrong things from changing
behind your back.

IPIJ || Lynn Andrea Stein

12~8 Dispatch Chapter 12

Executing an if/else statement works mostly like executing a simple if

statement: First the boolean test expression is evaluated. If its value is true, the
consequent statement is executed and the if/else statement is done. The
difference occurs when the boolean test expression's value is false. In this case,
the consequent is skipped (as it would be in the simple if) but the alternative
statement is executed in its place. So in an if/else statement, exactly one of the
consequent statement or the alternative statement is always executed. Which one
depends on the value of the boolean test expression.
The following code might appear in the calculator's act() method, as described
above. It is looking at which button is pressed, just like a good manager, and
deciding which helper procedure should handle it.
if ( this.isDigitButton( buttonID ) )
{
this.processDigitButton( buttonID );
}
else
{
this.processOperatorButton( buttonID );
}
This code presumes some helper functions. The method isDigitButton verifies
that the buttonID corresponds to the keys 0 through 9. The process... methods
actually implement the appropriate responses to these button types.
Because there is only one test expression in this statement, it is always the case
that at the single time of its evaluation (per if statement execution), it will be
either true or false. If the test expression is true, the consequent statement will be
executed (and the alternative skipped). If it is false, the alternative statement will
be executed (and the consequent skipped). Exactly one of the consequent or the
alternative will necessarily be executed each time that the if statement is executed.

12.2.3 Cascaded Ifs

The if/else statement is a special case of a more general situation. Sometimes, it is
sufficient to consider one test and decide whether to perform the consequent or
the alternative. But the example we gave of determining whether the buttonID
was a digit or not probably isn't one. After all, a non-digit might be an operator,
but it also might, for example, be an =. We probably need to check more than one
condition, although we know if any one of these conditions is true, none of the

IPIJ || Lynn Andrea Stein

12.2 If and else 12~9

others is. This is a perfect situation for a cascaded if statement. 5

if ( this.isDigitButton( buttonID ) )
{
this.processDigitButton( buttonID );
}
else
{
if ( this.isOperatorButton( buttonID ) )
{
this.processOperatorButton( buttonID );
}
else
{
this.processEqualsButton( buttonID );
}
}
In fact, the situation is really even more complex:
if ( this.isDigitButton( buttonID ) )
{
this.processDigitButton( buttonID );
}
else
{
if ( this.isOperatorButton( buttonID ) )
{
this.processOperatorButton( buttonID );
}
else
{
if ( this.isEqualsButton( buttonID ) )
{
this.processEqualsButton( buttonID );
}
else
{
// and so on until...
throw new NoSuchButtonException(
buttonID );
}
}
}

5
The test for isDigitButton, etc., may seem mysterious right now, and indeed we will simply
assume the existence of these boolean-returning predicates for now. An implementation is
provided in the section on Symbolic Constants, below, and discussed further in the chapter on
Encapsulation.

IPIJ || Lynn Andrea Stein

12~10 Dispatch Chapter 12

These ifs inside elses can get to be quite difficult to read, not to mention the
pressure that they put on the right margin of your code as each subsequent if is
further indented.6 In order to avoid making your code too complex -- and too
right-handed -- there is an alternate but entirely equivalent syntax, called the
cascaded if statement. In this statement, an else clause may take an if statement
directly, rather than inside a block. Further, the consequent block of this
embedded if statement is lined up with the consequent block of the original if
statement. So the example above would now read

if ( this.isDigitButton( buttonID ) )
{
this.processDigitButton( buttonID );
}
else if ( this.isOperatorButton( buttonID ) )
{
this.processOperatorButton( buttonID );
}
else if ( this.isEqualsButton( buttonID ) )
{
this.processEqualsButton( buttonID );
}
// and so on until...
else
{
throw new NoSuchButtonException( buttonID );
}

Note that instead of ending with many close braces in sequence, a cascaded if
statement ends with a single else clause (generally without an if and test
expression) followed by a single closing brace.

6
The final lines of such a sequence also contain an awful lot of closing braces.

IPIJ || Lynn Andrea Stein

12.2 If and else 12~11

true {
if ( booleanExpression 1 ) consequentStatements1
}

false

true {
else if ( booleanExpression 2 ) consequentStatements2
}

false

true {
else if ( booleanExpression n ) consequentStatementsn
}

false

else {
alternativeStatements
}

Cascaded if execution path

Like a simple if/else statement, exactly one block of a cascaded if statement is

executed. Once that block executes, the entire statement is finished. The
difference is that if the first expression's value is false, the next condition is
evaluated, and then the next, and so on, until either

• one test expression evaluates to true, in which case the corresponding

body is executed and execution of the statement is then terminated, or

• an else without an if and test is reached, in which case the corresponding

body is executed, or

• the end of the statement is reached, in which case its execution is

complete.

Since an else with no if and test is always executed, such an else must be the
last clause of the cascaded if.

IPIJ || Lynn Andrea Stein

12~12 Dispatch Chapter 12

12.2.4 Many Alternatives

A conditional is a very general statement. With it, it is possible to write extremely
convoluted programs. In order to make your program as easy to understand as
possible, it is a good idea to keep your conditionals clean. A reasonable rule of
thumb is that you should be able to explain the logic of your if statement easily to
a friend. If you have to resort to pen and paper, your conditional expression may
be too complex. If you have to write down more than two or three things, your
conditional logic is most likely out of control.
For example, you should not test too many things simultaneously in one test
expression. If you have a complex condition to test, use a boolean-returning
method (a predicate) to keep the test expression simple. By naming the predicate
appropriately, you can actually make your code much easier to read, as we did
with isDigitButton and isOperatorButton, above. We will return to this point in
the section on Procedural Abstraction in the chapter on Encapsulation.
As we have seen, you can embed if statements. In the example that we gave
above, the embedded statements were actually mutually exclusive alternatives in
the same set of tests: the button is either a digit or an operator or the equals button
or.... In this case, you should use the cascaded if syntax with which we replaced
our embedded ifs.
But sometimes it is appropriate to embed conditionals. For example, in the
calculator's act() method, inside the isOperatorButton block, we might further test
whether the operation was addition or subtraction or multiplication or division.

if ( this.isDigitButton( buttonID ) )
{
this.processDigitButton( buttonID );
}
else if ( this.isOperatorButton( buttonID ) )
{
if ( this.isPlusButton( buttonID )
{
this.handlePlus();
}
else if ( this.isMinusButton( buttonID ) )
{
this.handleMinus();
}
else if ( this.isTimesButton( buttonID ) )
{
this.handleTimes();

IPIJ || Lynn Andrea Stein

12.2 If and else 12~13

}
else if ( this.isDivideButton( buttonID ) )
{
this.handleDivide();
}
else
{
throw new NoSuchOperatorException( buttonID );
}
}
else if ( this.isEqualsButton( buttonID ) )
{
// etc.

In this case, these further tests are a part of deciding how to respond to an
operator button, including an operator-specific exception-generating clause. Note
that the additional tests appear inside an if body, not inside an unconditional else.
Using an embedded conditional to further refine a tested condition is a reasonable
design strategy.

Beware of multiply evaluating an expression whose value might change. Instead,

evaluate the expression once, assigning this value to a temporary variable whose
value, once assigned, will not change between repeated evaluations.
The example above of looking out the window to check the weather may work
well in southern California, but it is ill-advised in New England, where the
weather has been known to change at the drop of a hat. Similarly, repeated
invocation of a method returning the current time can be expected to produce
different values. So can repeated invocations of a Counting's getValue method. If
we execute the following conditional

if ( theCounter.getValue() > 1 )
{
Console.println( "My, there sure are a lot of them!" );
}
else if ( theCounter.getValue() == 1 )
{
Console.println( "A partridge in a pear tree!" );
}
else if ( theCounter.getValue() = 0 )
{
Console.println( "Not much, is it?" );
}
else if ( theCounter.getValue() < 0 )

IPIJ || Lynn Andrea Stein

12~14 Dispatch Chapter 12

{
Console.println( "I'm feeling pretty negative" );
}
else
{
Console.println( "Not too likely, is it?" );
}

it is possible that the counter will be incremented in just such a way that "Not too
likely" might be printed.

Q. Describe how the process of executing this conditional might be intertwined

with the incrementing of the counter to result in each of the five different values
being printed. How might no value be printed?

IPIJ || Lynn Andrea Stein

12.2 If and else 12~15

If Statement Syntax
An if statement consists of the following parts:

• The keyword if, followed by

• an expression of type boolean, enclosed in parentheses, followed by

• a (block) statement.
This may optionally be followed by an else clause. An else clause
consists of the following parts:

• The keyword else, followed by either

• a (block) statement
or

• the keyword if, followed by

• an expression of type boolean, enclosed in parentheses, followed by

• a (block) statement, optionally followed by

• another else clause.

Execution of the if statement proceeds as follows:
First, the test expression of the if is executed. If its value is true, the (block)
statement immediately following this test is executed. When this completes,
execution continues after the end of the entire if statement, i.e., after the
final else clause body (if any).
If the value of the first if test is false, execution continues at the first else
clause. If this else clause does not have an if and condition, its body (block)
is executed and then the if statement terminates. If the else clause does have
an if test, execution proceeds as though this if were the first test of the
statement, i.e., at the beginning of the preceding paragraph.

IPIJ || Lynn Andrea Stein

12~16 Dispatch Chapter 12

12.3 Limited Options: Switch

An if statement is a very general conditional. Often, the decision of what action to
take depends largely or entirely on the value of a particular expression. For
example, in the calculator, the decision as to what action to take when a user
presses a button can be made based on the particular button pressed. What we
really want to do is to see which of a set of known values (all of the calculator's
buttons) matches the particular value (the actual button pressed). This situation is
sometimes called a dispatch on case.
There is a special statement designed to handle just such a circumstance. In Java,
this is a switch statement. A switch statement matches a particular expression
against a list of known values.
Before we look at the switch statement itself, we need to look briefly at the list of
known values. In a Java switch statement, these values must be constant
expressions.

12.3.1 Constant Values

When we are choosing from among a fixed set of options, we can represent those
options using symbolic constants. A symbolic constant is a name associated with
a fixed value. For example, it would be lovely to write code that referred to the
calculator's PLUS_BUTTON, TIMES_BUTTON, etc. But what values would we give
these names? For that matter, what is the type of the calculator's buttonID?
The answer is that it doesn't matter. At least, it doesn't matter as long as
PLUS_BUTTON is distinct from TIMES_BUTTON and every other buttonID on the
calculator. We don't want to add PLUS_BUTTON to TIMES_BUTTON and find out
whether the value is greater or less than EQUALS_BUTTON, or to concatenate
PLUS_BUTTON and EQUALS_BUTTON. But we do want to check whether buttonID
== PLUS_BUTTON, and the value of this expression ought to be (guaranteed to be)
different from the value of buttonID == TIMES_BUTTON (unless the value of
buttonID has changed). Contrast this with a constant such as Math.PI, whose
value is at least as important as its name.
These symbolic constants, then, must obey a simple contract. A particular
symbolic constant must have the same value at all times (so that EQUALS_BUTTON
== EQUALS_BUTTON, always), and its value must be distinct from that of other
symbolic constants in the same group ( PLUS_BUTTON != EQUALS_BUTTON).

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~17

These are the ONLY guaranteed properties, other than the declared type of these
names.

12.3.1.1 Symbolic Constants

It is common, though not strictly speaking necessary, to declare symbolic
constants in a class or interface rather than on a per instance basis. It makes sense
for them to appear in an interface when they form part of the contract that two
objects use to interact. For example, you might communicate with me by passing
me one of a fixed set of messages -- MESSAGE_HELLO, MESSAGE_GOODBYE, etc. --
and the interface might declare these constants as a part of defining the messages
that we both are expected to understand and use. This means that these symbolic
constants are declared static.
It makes sense that a name such as this, which is part of a contract, might be
declared public. This allows it to be used by any objects that need to interact
with the symbolic constant's declaring object. Symbolic constants like this need
not be public, but they often are. (Private symbolic constants would be used only
for internal purposes. Package-level or protected symbolic constants might be
used in a restricted way.)

In Java, a name is declared final to indicate that its value cannot change. This is
one of the properties that we want our symbolic constants to have: unchanging
value. A value declared final cannot be modified, so you need not worry that extra
visibility will allow another object to modify a constant inappropriately.

It is common, though somewhat arbitrary, to use ints for these constants. There
are some advantages to this practice, and it does simplify accounting. For
example, by defining a set of these constants in sequence one place in your code,
it is relatively easy to keep track of which values have been used or to add new
values.
public static final int ...
PLUS_BUTTON = 10,
MINUS_BUTTON = 11,
TIMES_BUTTON = 12,
...
Of course, you should never depend on the particular value represented by a
symbolic constant (such as EQUALS_BUTTON), since adding a new symbolic name
to the list might cause renumbering. The particular value associated with such a
name is not important.

IPIJ || Lynn Andrea Stein

12~18 Dispatch Chapter 12

So symbolic constants are often public static final ints.

final
In Java, a name may be declared with the modifier final. This means that
the value of that name, once assigned, cannot be changed. Such a name is,
in effect, constant.
The most common use of this feature is in declaring final fields. These are
object properties that represent constant values. Often, these fields are static
as well as final, i.e., they belong to the class or interface object rather than
to its instances. Static final fields are the only fields allowed in interfaces.
In addition to final fields, Java parameters and even local variables can be
declared final. A final parameter is one whose value may not be changed
during execution of the method, though its value may vary from one
invocation of the method to the next. A final variable is one whose value is
unchanged during its scope, i.e., until the end of the enclosing block.7
Java methods may also be declared final. In this case, the method cannot be
overridden in a subclass. Such methods can be inlined (i.e., made to
execute with especially little overhead) by a sufficiently intelligent
compiler.
Java classes declared final cannot be extended (or subclassed).

12.3.1.2 Using Constants

Properties such as the button identifiers are common to all instances of
Calculators. In fact, they are reasonably understood as properties of the Calculator
type rather than of any particular Calculator instance. They can (and should) be
used in interactions between Calculator's implementors and its users. In general,
symbolic names (and other constants) can be a part of the contract between users
and implementors.

7
Final fields and parameters are not strictly speaking necessary unless you plan to use inner
classes. They may, however allow additional efficiencies for the compiler or clarity for the reader
of your code.

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~19

This means that it is often useful to declare these static final fields in an interface,
i.e., in the specification of the type and its interactions. In fact, static final fields
are allowed in interfaces for precisely this reason. Thus, the definition of
interfaces in chapter 4 is incomplete: interfaces can contain (only) abstract
methods and static final data members.
For example, the Calculator's interface might declare the button identifiers
described above:
public interface Calculator
{
public static final int PLUS_BUTTON = 10,
MINUS_BUTTON = 11,
TIMES_BUTTON = 12,
...
EQUALS_BUTTON = 27;
}
Now any user of the Calculator interface can rely on these symbolic constants as a
part of the Calculator contract. For example, the isOperatorButton predicate might
be implemented as8
public boolean isOperatorButton( int buttonID )
{
return ( buttonID == PLUS_BUTTON )
|| ( buttonID == MINUS_BUTTON )
|| ( buttonID == TIMES_BUTTON )
|| ( buttonID == DIVIDE_BUTTON );
}

If we choose our numbering scheme carefully, the predicate isDigitButton could

be implemented as
public boolean isDigitButton( int buttonID )
{
return ( 0 <= buttonID ) && ( buttonID < 10 ) ;
}
Of course, this is taking advantage of the idea that the digit buttons would be
represented by the corresponding ints. This is a legitimate thing to do, but ought
to be carefully documented, both in the method's documentation and in the
declaration of the symbolic constants:

8
Note the absence of any explicit conditional statement here. Using an if to decide which boolean
to return would be redundant when we already have boolean values provided by == and by ||. See
the Sidebar on Using Booleans in the chapter on Statements.

IPIJ || Lynn Andrea Stein

12~20 Dispatch Chapter 12

/**
* Symbolic constants representing calculator button IDs.
* The values 0..9 are reserved for the digit buttons,
* which do not have symbolic name equivalents.
*/
public static final int PLUS_BUTTON = 10,
MINUS_BUTTON = 11,
TIMES_BUTTON = 12,
...
EQUALS_BUTTON = 27;

and
/**
* Assumes that the digit buttons 0..9 will be represented by
* the corresponding ints. These values should not be used for
* other buttonID constants.
*/
public boolean isDigitButton( int buttonID )
{
return ( 0 <= buttonID ) && ( buttonID < 10 ) ;
}

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~21

Style Sidebar

Use Named Constants

A constant is a name associated with a fixed value. Constants come in two
flavors: constants that are used for their value, and symbolic constants, used
solely for their names and uniqueness. Calculator.PLUS_BUTTON (whose
value is meaningless) is a symbolic constant, while Math.PI (whose value is
essential to its utility) is not. But constants -- named values -- are a good
idea whether the value matters or not.
Introducing a numeric literal into your code is generally a bad idea. One
exception is 0, which is often used to test for the absence of something or to
start off a counting loop. Another exception is 1 when it is used to
increment a counter. But almost all other numeric literals are hard to
understand. In these cases, it is good style to introduce a name that explains
what purpose the number serves.
Numbers that appear from nowhere, with no explanation and without an
associated name, are sometimes called magic numbers (because they
appear by magic). Like magic, it is difficult to know what kind of stability
magic numbers afford. It is certainly harder to read and understand code
that uses magic numbers.
In contrast, when you use a static final name, you give the reader of your
code insight into what the value means. Contrast, for example,
EQUALS_BUTTON vs. 27. You also decouple the actual value from its
intended purpose. Code containing the name EQUALS_BUTTON would still
work if EQUALS_BUTTON were initially assigned 28 instead of 27; it relies
only on the facts that its value is unchanging and it is distinct from any
other buttonID.

12.3.2 Syntax
We turn now to a switch statement. A switch statement begins by evaluating the
expression whose value is to be compared against the fixed set of possibilities.
This expression is evaluated exactly once, at the beginning of the execution of the
switch statement. Then, each possibility is compared until a match is found. If a
match is found, "body" statements are executed. A switch statement may also
contain a default case that always matches. In these ways, a switch statement is

IPIJ || Lynn Andrea Stein

12~22 Dispatch Chapter 12

similar to, but not the same as, a traditional conditional.

12.3.2.1 Basic Form

A simple switch statement looks like this:
switch ( integralExpression )
{
case integralConstant:
actionStatement;
break;
case anotherIntegralConstant:
anotherActionStatement;
break;
}
To execute it, first the integralExpression is evaluated. Then, it is compared to the
first integralConstant. If it matches, the first actionStatement is executed. If
integralExpression doesn't match the first integralConstant, it is compared to
anotherIntegralConstant instead. The result is to execute the first actionStatement
whose integralConstant matches, then jumps to the end of the switch statement.

For example, we might implement the calculator's act method like this:
switch ( buttonID )
{
case Calculator.PLUS_BUTTON:
this.handlePlus();
break;
// ...
case Calculator.EQUALS_BUTTON :
this.handleEquals();
break;
}
The presence of the break statements as the last statement of each set of actions is
extremely important. They are not required in a switch statement, but without
them the behavior of the switch statement is quite different. See the Switch
Statement Sidebar for details.

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~23

Break and Continue Statements

The break statement used here is actually more general that just its role in
a switch statement.

A break statement is a general purpose statement that exits the innermost

enclosing switch, while, do, or for block.

A variant form, the labeled break statement, exits all enclosing blocks until
a matching label is found. A labeled break does not exit a method,
however. The labeled form of the break statement looks like this:
label:
blockStatementText
{
// body text
break label;
// more body text
} endBlockStatementText

One or both of blockStatementText or endBlockStatementText may be

present; for example, this block may be a while loop, in which case
blockStatementText would be the code fragment while ( expr ) and
there would be no endBlockStatementText.9
This code is equivalent to10
try
{
blockStatementText
{
// body text
throw new LabelBreakException();
// more body text
} endBlockStatementText
}
catch ( LabelBreakException e )
{

9
The labeled block may be any statement containing a block, including a simple sequence
statement. The body text may contain any statements, including -- in the case of a labeled break
-- other blocks, so that a labeled break may exit multiple embedded blocks.
10
Here, LabelBreakException is a unique exception type referring to this particular labeled
break statement.

IPIJ || Lynn Andrea Stein

12~24 Dispatch Chapter 12

}
That is, the labeled break statement causes execution to continue
immediately after the end of the corresponding labeled block.

label : label :
{
loopBegin
statements
{

statements
break label;

continue label;
statements

statements
}

Break and continue execution paths

A similar statement, continue, also exists in unlabelled and labeled forms.

An unlabelled continue statement terminates the particular body execution

of the (while, do, or for) loop it is executing and returns to the (increment
and) test expression.

The labeled continue statement works similarly, except that it continues at

the test expression of an enclosing labeled while, do, or for loop. The
labeled continue statement
label:
blockStatementText
{
// body text
continue label;
// more body text
} endBlockStatementText

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~25

is equivalent to
blockStatementText
{
try
{
// body text
throw new LabelContinueException();
// more body text
}
catch ( LabelContinueException e )
{
}
} endBlockStatementText

12.3.2.2 The Default Case

In an if statement, if none of the test expressions evaluates to true, a final else
clause without an if and test expression may be used as the default behavior of
the statement. Such an else clause is always executed whenever it is reached.

In a switch statement, a similar effect can be achieved with a special case

(without a comparison value) labeled default:
switch ( buttonID )
{
case Calculator.PLUS_BUTTON:
this.handlePlus();
break;
// ...
case Calculator.EQUALS_BUTTON :
this.handleEquals();
break;
default :
throw new
NoSuchButtonException( buttonID );
}
If no preceding case matches the value of the test expression, the default will
always match. It is therefore usual to make the default the final case test of the
switch statement. (No case after the default will be tested.) When the default
clause is the last statement of your switch, it is not strictly speaking necessary to
end it with a break statement, though it is not a bad idea to leave it in anyway.
The final break; statement is omitted in this example because it would never be
reached after the throw. (Any instruction follower executing the throw would exit

IPIJ || Lynn Andrea Stein

12~26 Dispatch Chapter 12

the switch statement at that point.)

It is often a good idea to include a default case, even if you believe that it is
unreachable. You would be amazed at how often "impossible" circumstances arise
in programs, usually because an implicit assumption is poorly documented or
because a modification made to one part of the code has an unexpected effect on
another.

switch ( integralExpression )

matches consequentStatements 1
case: integralConstant :
break;

doesn’t match

matches consequentStatements 2
case: integralConstantn :
break;

doesn’t match

matches consequentStatements n
case: integralConstant :
break;

doesn’t match
default:
defaultStatements
}

Switch execution path with default

12.3.2.3 Variations
It is possible to write a switch statement without using breaks. In this case, when a
case matches, not only its following statements but all statements within the
switch and up to a break or the end of the switch statement will be executed. This
can be useful when the action for one case is a subset of the action for a second
case.

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~27

Beware of accidentally omitted break statements in a switch. Because omitting

the break is sometimes what you want, it is legal Java and the compiler will not
complain. Omitting a break statement will cause the statements of the following
case(s) to be executed as well.
If two (or more) cases have the same behavior, you can write their cases
consecutively and the same statements will be executed for both. This is, in effect,
giving the first case no statements (and no break) and letting execution "drop
through" to the statements for the second case. For example:
switch ( buttonID )
{
case Calculator.PLUS_BUTTON:
case Calculator.MINUS_BUTTON:
case Calculator.TIMES_BUTTON:
case Calculator.DIVIDED_BY_BUTTON:

this.handleOperator( buttonID
);
break;
// ....
In this case statement, the same action would be taken for each of the four
operator types. The buttonID pressed is passed along to the operator handler to
allow it to figure out which operator is needed.

12.3.2.4 Switch Statement Pros and Cons

A switch statement is very useful when dispatch is based on the value of an
expression and the value is drawn from a known set of choices. The switch
expression must be of an integral type and the comparison case values must be
constants (i.e., literals or final names) rather than other variable names. When a
switch statement is used, the switch expression is evaluated only once.
A switch statement cannot be used when the dispatch expression is of an object
type or when it is a floating point number. It also cannot be used with a boolean,
but since the boolean expression has only two possible values, an if statement
with a single alternative makes at least as much sense in that case.
The requirement that a switch expression must be of integral type is one reason
why static final ints are often used as symbolic constants. int is a
convenient integral type and symbolic constants are naturally compatible with
switch statements.

IPIJ || Lynn Andrea Stein

12~28 Dispatch Chapter 12

A switch statement cannot be used when the comparison values are variable or
drawn from a non-fixed set. That is, if the dispatch expression must be compared
against other things whose values may change, the switch statement is not
appropriate. For example, you wouldn't want to use a switch statement to compare
a number against the current ages of the employees of your company, because
these are changing values.
The switch statement is also not appropriate for expressions that may take on any
of a large range of values. ("Large" is subjective, but if you wouldn't want to write
out all of the cases, that's a good indication that you don't want a switch
statement.) For example, you wouldn't want to do a dispatch on a the title of a
returned library book, testing it against every book name in the card catalog, even
if you represented names as symbolic constants rather than as Strings.11

11
Of course, if you represented the names as Strings, you couldn't use a switch statement because
String is an object type.

IPIJ || Lynn Andrea Stein

12.3 Limited Options: Switch 12~29

Switch Statement Syntax

A switch statement contains a test expression and at least one case clause.
After that, the switch statement may contain any number of case clauses or
statements in any order:
switch ( integralExpression )
{
caseClause
caseClauses or statements
}
The integralExpression is any expression whose type is an integral type:
byte, short, int, long, or char.

A caseClause may be either

case constantExpression :
or
default :
If the caseClause contains a constantExpression, this must be an
expression of an integral type whose value is known at compile time. Such
an expression is typically either a literal or a name declared final,
although it may also be an expression combining other constant expressions
(e.g., the product of a literal and a name declared final).

Note that each caseClause must end with a colon.

The embedded statements may be any statement type [!!?!].
Typically, the actual syntax of a switch statement is
switch ( integralExpression )
{
caseClauses
statements ending with break;
caseClauses
statements ending with break;
...
default :
statements optionally ending with break;
}
where caseClauses is one or more case clauses.

IPIJ || Lynn Andrea Stein

12~30 Dispatch Chapter 12

12.4 Arrays
Sometimes, what we really want to do when dispatching is to translate from one
representation to another. For example, in constructing a Calculator, we might
want to move from the symbolic constants used to identify buttons above to the
actual labels appearing on those buttons. We might even want to move between
the labels on buttons and the buttons themselves. If our collection of objects is
indexed using an integral type -- either because it is naturally indexed or because
we have used ints as symbolic constants -- we can often accomplish this
conveniently using arrays.

mailboxes[0] mailboxes[1] mailboxes[2] mailboxes[3] mailboxes[4] mailboxes[5] mailboxes[6] mailboxes[7]

Mailboxes

12.4.1 What is an Array?

An array is an integrally indexed grouping of shoeboxes or labels. You can think
of it sort-of like a wall full of numbered mailboxes. In identifying a mailbox, you
need to use both a name corresponding to the whole group ("the mailboxes in the
lobby") and an index specifying which one ("mailbox 37").Similarly, an array
itself is a thing that can be named -- like the group of mailboxes -- and it has
members -- individual mailboxes -- named using both the array name and the
index, in combination. For example, my own particular individual mailbox might
be named by lobbyMailboxes[37].
An array has an associated type that specifies what kind of thing the individual
names within the array can be used to refer to. This type is sometimes called the
base type of the array. For example, you can have an array of chars or an array of
Strings or an array of Buttons. The individual names within the array are all of the
same type, say char or String or Button.
That is, an array is a collection of nearly-identical names, distinguished only by
an int index. An array of shoebox-type--for example, an array of chars--really is

IPIJ || Lynn Andrea Stein

12.4 Arrays 12~31

almost like a set of mailboxes, each of which is an individual shoebox-name. To

identify a particular shoebox, you give its mailbox number. For example, you can
look and see what (char) is in mailbox 32 or put an appropriately typed thing
(char) in mailbox 17. Label-type arrays work similarly, though it's hard to find an
analogously appropriate analogy. (A set of dog-tags or post-it notes is along the
right lines, but it is harder to visualize these as neatly lined up and numbered.) A
label-type array -- such as an array of Buttons - is an indexed collection of labels
suitable for affixing on things of the appropriate type -- such as Buttons. The
names affixed on individual Buttons are names like myButtons[8], the ninth
button in my array.12

la
be
ls

labels[0] labels[1] labels[2] labels[3] label[4] labels[5] labels[6] labels[7]

Label array

12.4.1.1 Array Declaration

An array type is written just like the type it is intended to hold, followed by
square braces. For example, the type of an array of chars is char[] and the type
of an array of Buttons is Button[]. Note that, like char and Button, char[] and
Button[] denote types, not actual Things. So, for example,
char[] initials;
makes the name initials suitable for sticking on things of type char[]; it
doesn't create anything of type char[] or otherwise affix initials to some
Thing. Similarly,

12
Yes, that's right, myButtons[8], the ninth button. Array elements, like the characters in
Strings, are numbered starting from 0.

IPIJ || Lynn Andrea Stein

12~32 Dispatch Chapter 12

Button[] pushButtons;
creates a label, pushButtons, suitable for attaching to a Button[], and nothing
more. Note that both initials and pushButtons are label names, notshoebox names.
The names of array types are always label types, although a particular array may
itself be suitable either for holding shoebox (e.g., char) or label (e.g. Button)
types.

0 1 2 3 0 1 2 3 0 1 2 3

h-
Pus - h- h- h-
t
Bu s Pus - Pus - Pus -
t t t
ton Bu s Bu s Bu s
ton ton ton

Button[] pushButtons; pushButtons = new Button[4]; pushButtons[3] = new Button(); pushButtons[1] = pushButtons[3];

Array declaration and construction

12.4.1.2 Array Construction

To actually create a char[] or Button[]13, you need an array construction
expression. This looks a bit like a class instantiation expression, but it is actually
not quite the same. An array construction expression consists of the keyword new
followed by the array type with an array size inside the square braces. For
example,
new char[26]
is an expression that creates 26 char-sized mailboxes, numbered 0 through 25.
Similarly,
new Button[ 518 ]
is an expression whose value is a brand new array of 518 Button-sized labels.
Note that arrays are indexed starting at 0, so the last index of a member of this
array will be 517, one less than the number supplied to the array construction

13
Pronounced "Button array" or "array of Buttons".

IPIJ || Lynn Andrea Stein

12.4 Arrays 12~33

expression.14
The expression
pushButtons = new Button[ numButtons ]
makes the name pushButtons refer to a new array of Button-sized labels. How
many? That depends on the value of numButtons at the time that this statement is
executed.

The statement
String[] buttonLabels = new String[16];
combines all of these forms, creating a name (buttonLabels) suitable for labeling
an array of Strings (String[]), constructing a 16-String array, and then attaching
the name buttonLabels to that array. Note that the text String[] appears twice in
this definition, once as the type and once (with an integral argument between the
brackets) in the array construction expression.

12.4.1.3 Array Elements

To access a particular member of the array, you need an expression that refers to
the array (such as its name), followed by the index of the particular member
inside square braces. For example,
buttonLabels[2]
is an expression of type String that refers to the element at index 3 of the String
array named by buttonLabels. Recall that, since the indices of buttonLabels run
from 0 to 15, buttonLabels[2] is the third element of the array.
This expression behaves very much as though it were a name expression. Like a
name, an array element expression of label type may be stuck on something, or
may be null. An array element of shoebox type (e.g., initials[6]) behaves like a
shoebox name.
You can use these array member expressions in any place you could use a name
of the same type. So, for example, you can say any of the following things:
buttonLabels[2] = "Hi there";

14
An array construction expression can be passed any expression with integral type (byte, short,
int, long, or char) and its size and indexing will be set accordingly.

IPIJ || Lynn Andrea Stein

12~34 Dispatch Chapter 12

String firstString = buttonLabels[0];

buttonLabels[7] = buttonLabels[6] + buttonLabels[5];

Console.println( buttonLabels[ Calculator.PLUS_BUTTON ] );

if ( buttonLabels[ currentIndex ] == null ) ...

(assuming of course that Calculator.PLUS_BUTTON and currentIndex are both
int names).

IPIJ || Lynn Andrea Stein

12.4 Arrays 12~35

Array Syntax
Array Type

An array is a label name whose type is any Java type followed by []. The
array is an array of that type. Admissible types include shoebox (primitive)
types, label (object) types, and other array types. An array is declared like
any other Java name, but using an array type. For example, if baseType is
any Java type, then the following declaration creates a label, arrayName,
suitable for affixing on an array of baseType:
baseType[] arrayName;
Array Initialization

By default, an array name's value is null. An array name may be defined at

declaration time using an array literal. This consists of a sequence of
comma-separated constant expressions enclosed in braces:
baseType[] arrayName = { const0, const1, ... constN };
[Check this: literals only, or also symbolic constants? Can this be done
w/non-String object types?]
Array Construction

Unless an array initialization expression is used in the declaration, an array

must be constructed explicitly using the array construction expression
new baseType[ size ]
Here, baseType is the base type of the array (i.e., this expression constructs
an array of baseType) and size is any non-negative integral expression.
Array Access

The expression arrayName[index ] behaves as a "regular" Java name. Its

type is the array's base type.

Arrays are numbered from 0 to arrayName.length - 1. Attempting to

access an array with an index outside this range throws an
ArrayOutOfBoundsException.

IPIJ || Lynn Andrea Stein

12~36 Dispatch Chapter 12

12.4.2 Manipulating Arrays

The particular names associated with individual members of an array behave like
ordinary (shoebox or label) names. What is unusual about them is how you write
the name -- arrayName[ index ] -- and not any of how they actually behave.
You can find out how many elements are in a particular array with the expression
arrayName.length. Note that there are no parentheses after the word length in
this expression. Technically, this is not either a field access or a method
invocation expression, although it looks like one and behaves like the other.

Note also that the value of the expression arrayName.length is not the index of
the last element of the array. It is in fact one more than the final index of the
array, because the array's indices start at 0. Attempting to access an array element
with a name smaller than 0 or greater than or equal to its length is an error. In this
case, Java will throw an ArrayOutOfBoundsException.

di di
als als

int[] dials = new int[8]; dials[5] = 25;

di
als

dials = new int[3];

Changing array references

Once you construct an array, the number of elements in that array does not
change. However, this immutable value is the number of elements in the array
itself, not the number of elements associated with the name. If the name is used to
refer to a different array later, it may have a different set of legal indices. For

IPIJ || Lynn Andrea Stein

12.4 Arrays 12~37

example:
char[] firstInitials = new char[ 10 ];
// firstInitials[3] would be legal, but firstInitials[12] would not.

firstInitials[ 5 ] = 'f';
firstInitials[ 5 ] = 'g';
// changes the value associated with a particular mailbox

firstInitials = new char[ 2 ]

// changes the whole set of mailboxes
// now pushButtons[3] isn't legal either!

12.4.2.1 Stepping through An Array Using a for Statement

One common use of arrays is as a way to step through a collection of objects. If
you are going to work your way through the collection, one by one, it is common
to do so using a counter and a loop.
We can write this with a while loop:
int index = 0;

while (index < array.length)

{
// do something
index = index + 1;
}
Note that index can't be initialized inside the while statement or it wouldn't be
bound in the test expression. Local (variable) names have scope only from their
declarations until the end of their enclosing blocks.
This is so common, there's a special statement for it. The while statement above
can be replaced by
for (int index = 0; index < array.length; index = index + 1)
{
// do something
}

Note that the for loop also includes the declaration of index, but that index only
has scope inside the for loop. It is as though index's definition plus the while loop
were enclosed in a block.
For additional detail on for statements, refer to the sidebar.

IPIJ || Lynn Andrea Stein

12~38 Dispatch Chapter 12

For Statement Syntax

The syntax
for ( initStatement; testExpression; incrementStatement )
{
body
}
is the same as
{
initStatement;

while ( testExpression )
{
body
incrementStatement;
}
}
The expression testExpression is any single boolean expression. It falls
within the scope of any declarations made in initStatement.

Both initStatement and incrementStatement are actually allowed to be

multiple statements separated by commas:
e.g.
i = i + 1, j = j + i
Note that initStatement,testExpression and incrementStatement are
separated by semicolons, but that individual statements within
initStatement and incrementStatement are separated by commas.
There is no semicolon at the end of incrementStatement.

12.4.3 Using Arrays for Dispatch

In addition to their use as collection objects, arrays can be used as a mechanism
for dispatch. This is because the same variable can be used to index into multiple
arrays or be passed to appropriate methods. We are not going to use an array to do
the calculator's central dispatch job right now. Instead, we will consider the
problem of constructing actual GUI Button objects that will appear on the screen.
There should be one Button corresponding to each of the symbolic constants
described above. Each of these Buttons will need an appropriate label, to be

IPIJ || Lynn Andrea Stein

12.4 Arrays 12~39

passed into the Button constructor. We might create a method,

String getLabel( int buttonID )
for this purpose.
We could use our getLabel to say
new Button( this.getLabel( buttonID ) )
or even
gui.add( new Button( this.getLabel( buttonID ) ) )
Such a getLabel method, which could translate from buttonIDs to labels, would
also be useful for generating Strings suitable for printing to the Console, e.g., for
debugging purposes.
One way to implement this method would be with an if statement. In this case, the
body of the method might say:
if ( buttonID == Calculator.PLUS_BUTTON )
{
return "+";
}
else if ( buttonID == Calculator.MINUS_BUTTON )
{
return "-";
}
else if ( buttonID == Calculator.TIMES_BUTTON )
{
// and so on....
Of course, this would get rather verbose rather quickly.
Because we are really doing a dispatch on the value of buttonID, and because
we've cleverly chosen to implement these symbolic constants as ints, we could opt
instead to use a switch statement:
switch ( buttonID )
{
case Calculator.PLUS_BUTTON :
return "+";

case Calculator.MINUS_BUTTON :
return "-";
// and so on....
This may be somewhat shorter, but not much. It does have the advantage of
making the dispatch on buttonID more explicit. But we can do still better.

Q. In the immediately preceding switch statement, why are there no break

IPIJ || Lynn Andrea Stein

12~40 Dispatch Chapter 12

statements?
If we create an array containing the button labels, in order, corresponding to the
buttonID symbolic constants, then we can use the buttonID to select the label:
String[] buttonLabels = { "0", "1", "2", "3", "4",
"5", "6", "7", "8", "9",
"+", "-", "*", "/",
// and so on...up to
"="};
In this case, the entire body of our getLabel method might say simply
return this.buttonLabels[ buttonID ];
This example is relatively simple, but in general arrays can be used whenever
there is an association from an index set (such as the buttonIDs) to other values.
The idea is that the index pulls out the correct information for that particular
value. This is a very simple form of a very powerful idea, which we shall revisit
in the chapter on Object Dispatch.

12.5 When to Use Which Construct

Arrays are in many ways the most limited of the dispatch mechanisms. They work
well when the action is uniform up to some integrally indexed decisions, e.g.,
some integrally indexed variables need to be supplied. Setting up the array
appropriately allows for very concise code. This is not always possible, though,
either because there isn't an obvious index set, because the index set is not
integral, because it is not possible to set up the necessary association, or because
the needed responses are nonuniform.
Switch statements also rely on integrally indexed decisions on a single expression,
but they are otherwise quite general in the action(s) that can take place. They are
useful any time the decision is made by testing the expression against a pre-
known fixed set of constants. In other words, a switch statement can be used
whenever an array is appropriate, though it may be more verbose. A switch
statement can also be used in cases of nonuniform response, where an array would
not be appropriate.
Ifs are very general. You can do anything with them. You should use them when
none of the other mechanisms are appropriate.

IPIJ || Lynn Andrea Stein

12.5 When to Use Which Construct 12~41

In a subsequent chapter, we will see an additional dispatch mechanism, object

dispatch, that resembles the implicit nature of array-based dispatch, but without
many of its restrictions.

Chapter Summary
• Dispatch is the process of deciding what action needs to be taken based on
one's input. It is essentially a middle management function.

• Conditional statements are used when a piece of code should be executed

under some but not all circumstances.

• An if statement may consist only of a single boolean test

expression and a body. This body is executed only if the test
expression's value is true.

• An if statement may optionally have an else clause with a body

that is executed only when the if's test expression has the value
false.

• The else clause of an if statement may itself be an if statement. In

this case, it is preferable to use cascaded rather than embedded ifs.

• Each test expression is evaluated independently as it is reached.

• Numbers generally should not appear in code. Instead, use symbolic

constants with descriptive names.

• A switch statement is used when different actions must be taken

depending on the value of a single expression.

• This expression is evaluated only once. Its type must be integral.

• In a switch expression, the value is compared against different

cases, which must be constants. Once a case matches, the
statements of the switch body are executed until either a break or
the end of the switch body is reached.

• Switch has a specialized case, default, which always matches.

IPIJ || Lynn Andrea Stein

12~42 Dispatch Chapter 12

• An array is a uniformly typed collection of names.

• The type of the array member names is the array's base type. The
array member names may be either shoebox names or label names,
depending on the base type.

• The type of the array is "array of base type". The array name is a
label name.

• The names of array members are written using the array name
followed by an integral index enclosed in square brackets.

• The indices of an array run from 0 to arrayName.length - 1.

• Like an object, an array must be explicitly created using new.

Exercises
1. In the section entitled "Many Alternatives", there is an example of a counter
whose getValue() method is invoked repeatedly.
a. Describe an execution sequence in which the value printed would be "My,
there sure are a lot of them!"
b. Describe an execution sequence in which the value printed would be "A
partridge in a pear tree!"
c. Describe how the process of executing this conditional might be
intertwined with the incrementing of the counter to result in the printing of
none of the messages.
of the five different values being printed.
2. Convert the following to a for loop:
int sum = 0;
int i = 1;
while ( i < MAXIMUM )
{
sum = sum + i;
i = i + 2;
}
3. Write a method that takes an array of ints and returns the sum of these ints.

IPIJ || Lynn Andrea Stein

 Exercises 12~43

4. Suppose that you have access to an array of StringTransformers, each of which

has a method satisfying String transform( String ). Write a method,
produceAllTransformations, that takes in a String and returns an array of Strings.
The first element of the returned array should correspond to the transformation of
the argument String by the first transformer, the second to the transformation of
the argument String by the second transformer, and so on. You may assume that
the name of the array of StringTransformers is transformerFunctions.
5. Consider the following code, excerpted from the definition of class
EmotionalSpeaker.
public String transformEmotionally( Type emotion, String what )
{
switch ( emotion )
{
case HAPPY: return sayHappily( what );
case SAD: return saySadly( what );
case ANGRY: return sayAngrily( what );
}
}

Where, e.g.,
private String sayHappily( String what )
{
return "I'm so happy that ";
}
(You may assume similar definitions for the other emotions, with appropriate
modifications.)
Define the symbolic constants HAPPY, SAD, and ANGRY, and provide a type
for emotion.
6. In the previous exercise, the switch statement contains no breaks. What
happens when we invoke transformEmotionally( SAD, "I am here." )?
7. Using an array, modify the code for transformEmotionally so that it fits in a
single line. The array definition need not fit on that line.

IPIJ || Lynn Andrea Stein

 13
Chapter 13 Encapsulation

Chapter Overview
• How do I package up implementation details so that a user doesn't
have to worry about them?

• How do I make my code easier to read, understand, modify, and

maintain?
Good design separates use from implementation. Java provides many mechanisms
for accomplishing this. In this chapter, we review a variety of mechanisms that
allow this sort of separation.
Procedural abstraction is the idea that each method should have a coherent
conceptual description that separates its implementation from its users. You can
encapsulate behavior in methods that are internal to an object or methods that are
widely usable. Methods should not be too complex or too long. Procedural
abstraction makes your code easier to read, understand, modify, and reuse.
Packages allow a large program to be subdivided into groups of related classes
and instances. Packages separate the names of classes, so that more than one class
in a program may have a given name as long as they occur in different packages.
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
13~2 Encapsulation Chapter 13

In addition to their role in naming, packages have a role as visibility protectors.

Packages provide visibility levels intermediate between public and private.
Packages can also be combined with inheritance or with interfaces to provide
additional encapsulation and separation of use from implementation.
Inner classes are a mechanism that allows one class to be encapsulated inside
another. Perversely, you can also use an inner class to protect its containing class
or instance. Inner classes have privileged access to the state of their containers, so
an inner class can provide access without exposing the object as a whole.

Objectives of this Chapter

1. To understand how information-hiding benefits both implementor and
user.
2. To learn how to use procedural abstraction to break your methods into
manageable pieces.
3. To be able to hide information from other classes using visibility
modifiers, packages, and types.
4. To recognize inner classes.

13.1 Design, Abstraction, and Encapsulation

This chapter is about how information can be hidden inside an entity. There are
many different ways that this can be done. Each of these is about keeping some
details hidden, so that a user can rely on a commitment, or contract, without
having to know how that contract is implemented. There are numerous benefits
from such information hiding.
First, it makes it possible to use something without having to know in detail how
it works. We do this all the time with everyday objects. Imagine if you had to
understand how a transistor works to use your computer, or how a spark plug
works to use your car, or how atoms work to use a lever.
Second, information-hiding gives some flexibility to the implementor. If the user
is not relying on the details of your implementation, you can modify your
implementation without disturbing the user. For example, you can upgrade your
implementation if you find a better way to accomplish your task. You can also

IPIJ || Lynn Andrea Stein

13.1 Design, Abstraction, and Encapsulation 13~3

substitute in different implementations on different occasions, as they may

become appropriate.
Finally, hiding information is liberating for the user, who does not expect nor
make great commitment to particulars of the implementation. The name for this
idea -- of using more general properties to stand in for detailed implementation --
is abstraction. To facilitate abstraction, it is often convenient to package up the
implementation details into a single unit. This packaging-up is called
encapsulation.

13.2 Procedural Abstraction

Procedural abstraction is a particular mechanism for separating use from
implementation. It is tied to the idea that each particular method performs a well-
specified function. In some cases, a method may calculate the answer to a
particular question. In others, it may ensure the maintenance of a certain condition
or perform a certain service. In all cases, each method should be accompanied by
a succinct and intuitive description of what it does.1 A method whose function is
not succinctly describable is probably not a good method. Conversely, almost
every succinctly describable function should be a separate method, albeit perhaps
a private or final one.
This idea, that each conceptual unit of behavior should be wrapped up in a
procedure, is called procedural abstraction. In thinking about how to design
your object behaviors, you should consider which chunks of behavior -- whether
externally visible or for internal use only -- make sense as separate pieces of
behavior. You may choose to encapsulate a piece of behavior for any or all of the
following reasons:

• It's a big, ugly function and you want to hide the "how it works" details
from code that might use it. Giving it a name allows the user to ignore
how it's done.

• It's a common thing to do, and you don't want to have to replicate the code
in several places. Giving it a name allows multiple users to rely on the
same (common) implementation.

1
It is not, however, essential that a method have a succinct description of how it does what it does.
How it accomplishes its task is an implementation detail.

IPIJ || Lynn Andrea Stein

13~4 Encapsulation Chapter 13

• It's conceptually a separate "task", and you want to be able to give it a

name.
Note also that the behavior of a method may vary slightly from invocation to
invocation, since the parameters can influence what you the code actually does.

13.2.1 The Description Rule of Thumb

Each method in your program should have a well-defined purpose, and each well-
defined purpose in your program should have its own method. You should be able
to succinctly state what each method in your program does. If you cannot, your
methods are either too large (i.e., should be broken into separable conceptual
units) or too small (i.e., should be combined so that each performs a "complete"
task.
Note that having a succinct description of what a method does is quite different
from being to state succinctly how it accomplishes this. It is unfortunately all too
common that a method's implementation is obscure. It is important that the user
understand when, why, and under what circumstances your method should be
used, i.e., what it does. You provide a method precisely so that the user will not
have to understand how your method works.
For example, it is common to test complex conditions using a single predicate.
One such instance might be the Calculator's isDigitButton() method, which
determines whether a particular Calculator button represents the digits 0 through 9
(or instead is, e.g., an arithmetic operator). The logic behind isDigitButton()
might be somewhat obscure. However, it is easy to succinctly state what the
method determines and, therefore, when and why you might use it. This use of
predicates as abstractions make code for easier to read, decompose, and
understand.
The importance of succinct summarizability does not mean that there is exactly
one method per description. For example, one succinctly summarizable method
may in turn rely on many other succinctly summarizable methods. This is the
"packaging up substeps" idea from Chapter 1: making a sandwich may be
described in terms of spreading the peanut butter, spreading the jelly, closing and
cutting the sandwich. Each substep may itself be a method. When the substeps are
not likely to be useful for anything except the larger method of which they are a
part, these methods should be private to their defining class.
It may also be the case that multiple methods each implement the same well-
defined purpose. For example, multiple similar methods may operate on different
kinds of arguments. A method that draws a rectangle may be able to take a

IPIJ || Lynn Andrea Stein

13.2 Procedural Abstraction 13~5

java.awt.Rectangle, two java.awt.Points, or four ints as arguments. Each of these

methods will have a different signature. They may, however, rely on a common
(shared) method to actually perform much of the work, sharing as much code as
possible. (See the repetition rule of thumb, below.)
Or it may be the case that multiple distinct object types each have similar methods
performing similarly summarized functions. In this case, it may make sense to
have a common interface implemented by each of these classes, documenting
their common purpose. Occasionally it even makes sense to split off the method
into its own class, turning instances of the new class into components of the old.
(See the discussion of using contained objects in the chapter on Object Oriented
Design.)
When a single method does too many things, it can be difficult to decide whether
you want to invoke it. It can be awkward to figure out what it is really doing. And
the interdependencies among subtasks can make your code hard to maintain,
especially if the assumptions that caused you to bundle these pieces together no
longer hold.
Succinct summarizability makes your code immensely easier to read. By choosing
descriptive names, you can often make your code read like the English description
of what it does. This makes it easier to read, understand, modify, and maintain
your code.

13.2.2 The Length Rule of Thumb

A single method should ideally fit on a single page (or screen). Often a method
will only be a few lines long. If you find yourself writing longer methods, you
should work on figuring out how to break them up into separable substeps. The
description rule of thumb is handy here.
When a method's implementation takes up too much space, it is difficult to read,
understand, or modify. It can be hard to hold the whole method in your head. It
can be overwhelming to try to figure out what it is actually doing.
Appropriate method length is a matter of some individual judgement. Some
people don't like to write methods longer than a half-page. Others regularly write
much longer methods. As you become a more skilled programmer, you will
become accustomed to keeping track of larger and more complex programs. But
more complex programs do not mean longer methods. It will always be the case
that brevity of individual units -- such as methods -- makes the overall flow easier
to understand. Mnemonic names (describing what the method accomplishes) and
programs that read like English descriptions of their behavior (through the use of

IPIJ || Lynn Andrea Stein

13~6 Encapsulation Chapter 13

well-chosen names) make your code more comprehensible to subsequent readers.

How do you know when to break code into pieces? If you discover that you have
written a method that does not fit on a single page, you should write an outline for
how the code works. Each of the major steps of this outline should be turned into
a method. The original code should be rewritten in terms of these methods. The
major steps should now be shorter methods. If these are still too long, repeat this
process until each piece of code has a succinct description and occupies no more
than two pages of code.
Note: Do not worry about inefficiency created by having too many small
methods. First, intelligible code is so much easier to read and maintain, and code
carefully optimized for efficiency so much more difficult to work with, that it
rarely pays to do this sort of optimization until you are a skilled programmer.
Further, a good compiler should be able to optimize. For example, if you make a
method private or final, the compiler can in-line it.

13.2.3 The Repetition Rule of Thumb

Any time that the same code appears in two different places, you should consider
capturing this common patterns of usage in a single method. When this happens,
it is often because there is an idea expressed by this code. It is useful to give this
idea a name, and to encapsulate or abstract it for reuse. Even if there are minor
differences in the code as it appears, you may be able to abstract to a common
method by supplying the distinguished information as arguments to the method.
Each of the original pieces of code should be rewritten to use the common
method.
Methods created by abstracting two or more pieces of code within the same class
are often declared private. This is appropriate whenever the common behavior is
local to the particular object and not something you want to make generally
available. At other times, though, the common code is a useful and nameable
function on its own. Though you may discover the commonality by replicating
code, the existence of a separate method to replace this redundancy can be turned
into an opportunity to export this functionality if it should make sense to do so.
Combining redundant code is also important in the case of constructors.
Constructors can share code by having one invoke another -- using the special
this() construct -- or by using a call to one or more (private) helper methods. A
common programming mistake is to modify only one constructor when in reality
the same change must be made to every constructor. Having the bulk of the work
of the constructor done by a common method (or shared by using this()-

IPIJ || Lynn Andrea Stein

13.2 Procedural Abstraction 13~7

constructors) eliminates this error.

Sharing redundant code shortens your program, making it easier to read,
understand, modify, and maintain. It also helps to isolate a single point where
each piece of behavior is performed. This single point can be understood,
modified, and debugged once rather than each time it (redundantly) appears.

13.2.4 Example
In the example immediately below, we will modify code based on redundancy,
i.e., the repetition rule of thumb. The result will also make our code more succinct
and easier to read. The newly created method will be succinctly summarizable
and a legitimately separable subtask.
Consider a bank account, which might have a method that allows the account's
owner to obtain balance information:
int getBalance( Signatory who ) throws InvalidAccessException
{
if ( ! who == this.owner )
{
throw new InvalidAccessException( who, this )
}
// else
return this.balance;
}

It might also have a withdraw method that allows the owner to remove amount
from the account, returning that amount as cash:
public Instrument withdraw( int amount, Signatory who ) throws
InvalidAccessException
{
if ( ! who == this.owner )
{
throw new InvalidAccessException( who, this )
}
// else
this.balance = this.balance - amount;
return new Cash( amount );
}

We could abstract the common pattern here, which is the verification of a

signatory's right to access this account:
private void verifyAccess( Signatory who ) throws
InvalidAccessException
{
if ( ! who == this.owner )
{
throw new InvalidAccessException( who, this )
}

IPIJ || Lynn Andrea Stein

13~8 Encapsulation Chapter 13

Now, we can rewrite getBalance and withdraw:

int getBalance( Signatory who ) throws InvalidAccessException
{
this.verifyAccess( who );
return this.balance;
}

public Instrument withdraw( int amount, Signatory who ) throws

InvalidAccessException
{
this.verifyAccess( who );
this.balance = this.balance - amount;
return new Cash( amount );
}

Much simpler, much more succinct, and in addition if we later need to modify the
access verification routine, there is only a single place -- verifyAccess() --
where changes will need to be made.

Style Sidebar

Procedural Abstraction
• Use procedural abstraction when a method call would make your code
(at least one of)

• shorter, or

• easier to understand.

• Your method should be concisely describable as "single function",

though the function may itself have many pieces.

• Use parameters to account for variation from one invocation to the next.

• Return a value when the target of an assignment varies; leave the actual
assignment out of the method body.

• Share code where possible. This is especially true among constructors,

where one constructor can call another using this().

• Make internal helper procedures private. Make generally useful common

functionality public (or protected).

IPIJ || Lynn Andrea Stein

13.2 Procedural Abstraction 13~9

13.2.5 Benefits of Abstraction

Abstracting procedures -- creating short, succinctly describable, non-redundant
methods -- has many benefits. Even in the simple example of the preceding
section, we can see many of these.
Procedural abstraction makes it easier to read your code, especially if methods
have names corresponding to their succinct descriptions and the flow of code
reads like the logic of the English description. Compare the before-and-after
withdrawal methods of the bank account in the previous section.
Greater readability makes it easier to understand and figure out how to modify
and maintain code. Separating functionality into bite-sized pieces also creates
many opportunities to modify individual methods. Sharing these methods also
centralizes the locations needing modification. For example, we could add a
digital signature check to the verification procedure of the bank account by
modifying only verifyAccess, not the bodies of getBalance or withdraw.
In contrast, long methods with complicated logic can be particularly hard to
modify, either because their interconnected logic can be so difficult to understand
or because it can be hard to find the right place to make the change.
As the needs of your code change, you will also find it easier to rearrange and
reconfigure what your code does if the logical pieces of the code are separated.
For example, we might add a wireTransfer method to the bank account. In doing
so, we can reuse the verifyAccess method.
Of course, smaller methods make for bite-sized debugging tasks. It is much easier
to see how to debug access verification in the newer bank account than in the
version where each account interaction has its own verification code and where
verification is intimately intertwined with each transaction. And if we need to
modify the verification procedure -- to give diagnostic information, to step
through the method, or to fix it -- there is a central place to make these changes.
Procedural abstraction also makes it easier to change behavior by substituting a
new version of a single method. If a method is not private, it can be overridden by
a subclass, specializing or modifying the way in which it is carried out without
changing its succinct specification. We could, for example, have a more secure
kind of bank account using the digital signature verification method alluded to
above.
Many of the advantages of procedural abstraction are also provided by good
object design. A method signature is a reasonable abstraction of the behavior of

IPIJ || Lynn Andrea Stein

13~10 Encapsulation Chapter 13

an individual method. An interface plays a similar role for an entire object,

packaging up (encapsulating) the behavioral contract of an object so that its
particular implementation may vary. Interfaces also make it easier to see how a
single abstraction can have many coexisting implementations.

13.3 Protecting Internal Structure

Procedural abstraction is an important way to separate use from implementation
and a significant part of good program design. Procedural abstraction is not the
only kind of abstraction that you need in a program, though. Often, other
techniques are used, either alone or with procedural abstraction, to hide
implementation details. For example, if you use procedural abstraction to create
local helper methods, you generally will not want these helper methods to be
available for other objects to use.
In this section, we will look at several ways to protect internal structure -- such as
helper methods -- from use by others. These techniques protect implementation by
making parts of the inner structure of an object inaccessible from outside that
object or that group of interrelated objects. This packaging of internal structure is
another kind of encapsulation. This section discusses some Java-specific ways to
encapsulate functionality. Many programming languages offer similar
mechanisms.

13.3.1 private
One of the most straightforward ways to protect internal structure -- such as fields
or helper methods -- is to declare them private. We have seen in the section above
how private methods can be used for procedural abstraction -- to break up a long
procedure, to capture common patterns, etc. -- without exposing these functions to
other objects. A method (or other member) declared private can only be called
from within the class.

Beware: This is not the same thing as saying that only an object can call its own
private methods. An object can call the private methods of any other instance of
the same class.
Private is extremely effective at protecting methods and other members from
being used by other objects. However, a member declared private cannot be
accessed from code within a subclass. This means that if you modify code in a
subclass that relies on a private helper method in the superclass, you will have to

IPIJ || Lynn Andrea Stein

13.3 Protecting Internal Structure 13~11

recreate that private helper method.

13.3.2 Packages
An alternative to the absolute protection of private is the use of packages. A
package is a collection of associated classes and interfaces. You can define your
own packages. Libraries -- such as the Java source code or the cs101 distribution -
- generally define packages of their own. The association among classes and
interfaces in a package can be as loose or as tight as you wish to make it.
Sometimes the association among objects is merely by convenience: many kinds
of objects deal with the same kind of thing. Most of the cs101 packages are of this
sort. Often, it makes sense to define a set of interrelated classes and interfaces in a
single package and to provide only a few entry points into the package, i.e., a few
things that are usable from outside the package. These packages represent
associations by shared interconnectedness. Most of the interlude code is of this
sort. Java defines a large number of packages, some of each kind.

In the bank account, we might well choose to define the interface Instrument
(representing cash and checks, among other things) and classes BankAccount,
CheckingAccount, Cash, etc. in a single package, say finance.

Packages play two roles in Java. The first concerns names and nicknames.
Packages determine the proper names of Java classes and interfaces. The second
role of packages is as a visibility modifier somewhere between private and public.

13.3.2.1 Packages and Names

A class or interface is declared to be in particular package packageName if the
first non-blank non-comment line in the file says
package packageName;

packageName may be any series of Java identifiers separated by periods, such as

java.awt .event and cs101.util. By convention, package names are written entirely
in lower case. A file that is not declared to be in a specific package is said to be in
the default package, which has no name.
Every Java class or interface actually has a long name that includes its package
name before its type name. So, for example, String is actually java.lang.String,
because the first line of the file String.java says
package java.lang;

IPIJ || Lynn Andrea Stein

13~12 Encapsulation Chapter 13

and Console is cs101.util.Console, because it is declared in a file that begins

package cs101.util;

Any (visible) class or interface can always be accessed by prefacing its name by
its package name, as in java.awt.Graphics or cs101.util.Console. If we declare the
package finance as described above, the interface finance.Instrument would
actually have a distinct name from the interface music.Instrument.
In some cases, you can also access the class more succinctly. If you include the
statement
import packageName.ClassName;
after the (optional) package statement in a file, you may refer to ClassName using
just that name, not the long (package-prefaced) name. So, for example, after
import cs101.util.Console;
the shorter name Console may be used to refer to the cs101.util.Console
class. Similarly,
import packageName.*;
means that any class or interface name in packageName may be referred to using
only its short name, unprefaced by packageName.
Note, however, that this naming role for packages is only one of convenience and
does not provide any sort of actual encapsulation. The use of a shorter name does
not give you access to anything additional. In particular, it does not change the
visibility of anything. Anything that can be referred to using a short name after an
import statement could have been referred to using the longer version of its name
in the absence of an import statement.
There are three exceptions to the need to use an import statement, i.e., three cases
in which the shorter name is acceptable even without an explicit import.
1. Names in the default package can always be referred to using their short
names.
2. Names in the current package (i.e., the package of which the file is a part)
can always be referred to using their short names.

3. Names in the special package java.lang can always be referred to using

their short names.
You are not allowed to have an import statement that would allow conflicts. So,
for example, you could not have both statements

IPIJ || Lynn Andrea Stein

13.3 Protecting Internal Structure 13~13

import finance.*;
import music.*;
if both packages contain a type named Instrument. You could, however,
import finance.BankAccount;
import music.*;
since the first of these import statements doesn't shorten the name of the interface
finance.Instrument. If you do import finance.BankAccount and music.*,
you can still refer to the thing returned by BankAccount's withdraw method as a
finance.Instrument.

Package Naming Summary

A class or interface with name TypeName that is declared in package
packageName may always be accessed using the name
packageName.TypeName, provided that it is visible. (See the visibility
summary sidebar.)
The class or interface may be also accessed by its abbreviated name,
TypeName, without the package name, if one of the following holds:

• The class or interface is declared in the default (unnamed) package.

• The class or interface is declared in the current package, i.e.,

packageName is also the package where the accessing code appears.

• The class or interface is declared in the special package java.lang, i.e.,

packageName is java.lang.

• The file containing the accessing code also contains one of the following
import statements:

• import packageName.TypeName;

• import packageName.*;

13.3.2.2 Packages and Visibility

The second use of packages is for visibility and protection. This use does
accomplish a certain kind of encapsulation. We have already seen private and
public, visibility modifiers that prevent the marked member from being seen or

IPIJ || Lynn Andrea Stein

13~14 Encapsulation Chapter 13

used or make it accessible everywhere. These two modifiers are absolute.

Packages allow intermediate levels of visibility.

Between private and public are two other visibility levels. One uses the
keyword package. The other is the level of visibility that happens if you do not
specify any of the other visibility levels. This is sometimes called "package"
visibility, although it differs from friendly visibility in other languages and,
additionally, there is no corresponding keyword for it.

A member marked protected visible may be used by any class in the same
package. In addition, it may be referenced by any subclass. It is illegal -- and
causes a compiler error -- if something outside the package, not a subclass, tries to
reference a member marked protected visible.
A member, class, or interface not marked with a visibility modifier is visible only
within the package. It may not be accessed even by code within subclasses of the
defining class or interface, unless they are within the package.
This means that classes and interfaces may be declared without the modifier
public, in which case they can only be used as types within the package.
Members may be declared without a modifier, in which case they can be used
only within the package, or they may be declared protected, in which case they
can be used only within the package or within a subclass. A non-public class or
interface need not be declared in its own separate Java file.
Note, however that although a subclass may increase the visibility of a member, it
may not further restrict visibility. So a subclass overriding a protected method
may declare that method public, but not unmodified (package) or private.
There is no hierarchy in package names. This means that the package
java.awt.event is completely unrelated to the package java.awt; their names just
look similar.

IPIJ || Lynn Andrea Stein

13.3 Protecting Internal Structure 13~15

Visibility Summary
A member, class, or interface marked public may be accessed anywhere.

A member marked protected may be accessed anywhere within the

containing package or anywhere within a subclass (or implementing class).
A member, class, or interface not marked has "package" visibility and may
be accessed anywhere and only within the containing package.

A member marked private may only be accessed within the containing

class or interface.

We can use this approach to encapsulate certain aspects of our BankAccount

example without making all of the relevant members private. After all, we want to
protect these members from misuse by things outside the financial system (and
therefore presumably outside the package finance), not from legitimate use by
other things within the banking system.
So we might declare:
public class BankAccount
{
...
}
and
public interface Instrument
{
public abstract int getAmount();
public abstract void nullify();
}
but
class Cash implements Instrument
{
private int amount;
private boolean valid;

protected Cash( int amount )

{
this.amount = amount;
this.valid = true;
}

public int getAmount()

{
return this.amount;

IPIJ || Lynn Andrea Stein

13~16 Encapsulation Chapter 13

protected void nullify()

{
this.valid = false;
}
}

This absence of the keyword public on the class definition means that the class
Cash is accessible only to things inside the finance package. The Cash
constructor is declared protected, so Cash may be created only from within this
package. But the two methods that Cash implements for its interface,
Instrument, must be public because you cannot reduce the visibility level
declared for a method and the interface's methods are declared public.2
Unfortunately, the guarantees of packaging are not absolute. There is nothing to
prevent someone else from defining a class to reside in an arbitrary package. For
example, I could declare a class Thief in package financial, allowing Thief
instances full access to the Cash constructor.

13.3.3 Inheritance
Inheritance can be used as a way of hiding behavior. Specifically, you can create
hidden behavior by extending a class and implementing the additional behavior in
the subclass. Conversely, labeling an object with a name of a superclass type has
the property that it makes certain members of that object invisible.
You cannot invoke a subclass method on an object labeled with a superclass type
that does not define that method, even though the object manifestly has the
method. You can take advantage of this in combination with the visibility
modifiers, for example creating a package-only subclass of a public class. Outside
the package, instances of this subclass will be regarded as instances of the
superclass, but because the subclass type is not available (since it is not visible
outside the package), its additional features cannot be used.

For example, a specialized package-internal type of BankAccount might allow

checks to be written:
class CheckingAccount extends BankAccount
{

2
The methods of a public interface must be public, but an interface not declared public may have
methods without a visibility modifier.

IPIJ || Lynn Andrea Stein

13.3 Protecting Internal Structure 13~17

...

protected Instrument writeCheck( String payee,

int amount,
Signatory who )
{
try
{
return new Check( payee, amount, who );
}
catch ( BadCheckException e )
{
return null;
}
}
}

Now, if I have a CheckingAccount but choose to label it with a name of type

BankAccount, I cannot write a check from that account:
BankAccount rainyDayFund = new CheckingAccount(...);

rainyDayFund.withdraw( 10000 );
works fine, but not
rainyDayFund.writeCheck( "Tiffany's", 10000, diamondJim );
That is, the only methods available on an expression whose type is BankAccount
are the BankAccount methods. The fact that this is really a CheckingAccount is
not relevant.
The idea of using superclass types as ways of abstracting the distinctions between
a CheckingAccount and a MoneyMarketFund is an important one. Sometimes
subclasses provide extra (or different versions of) functionality. These distinctions
are not necessarily relevant to the user of the class, who should be able to treat all
BankAccounts uniformly.

Note, however, that the true type of an object is evident at the time of its
construction; it must be constructed using the class name in a new expression.
Also, if the type is visible, an explicit cast expression can be used to access
subclass properties.3
Finally, recall the discussion in chapter 10 on the inappropriateness of inheritance
unless you are legitimately extending behavior. Inheritance should not be used,
for example, when you need to "cancel" superclass properties.

3
For example, (CheckingAccount) rainyDayFund;

IPIJ || Lynn Andrea Stein

13~18 Encapsulation Chapter 13

13.3.4 Clever Use of Interfaces

The discussion above of inheritance and encapsulation applies doubly for
interfaces. Interfaces are a good way of achieving the subtype properties of
inheritance without the requirements of strict extension. Further, an interface type
cannot contain implementation, only static final fields and non-static method
signatures. This means that an interface cannot divulge any properties of the
implementation that might vary from one class to another or that a subclass might
override. If it's in the interface, it's in every instance of every class that
implements that interface.

The example in the preceding section of a CheckingAccount protected by

subclassing are even cleaner in the case of the Cash and Check classes, which are
package-local but implement the public interface Instrument. This means that
things outside the package may hold Cash or Check objects, but will not know
any more than that they hold an Instrument. Any methods defined by Cash or
Check but not by Instrument are inaccessible except inside the package
finance.

Like a superclass, the protections of an interface can be circumvented if the

implementing class type is visible to the invoking code. And, as always, the true
type of an object is known when you invoke its constructor.
These issues are covered further in chapters 4 and 8, on Interfaces and Designing
With Objects.

13.4 Inner Classes

The final topic in this chapter is inner classes. Inner classes allow a variety of
different kinds of encapsulation. At base, an inner class is a remarkably simple
idea: An inner class is a class defined inside another. There are several varieties of
inner classes, and some of their behavior may seem odd.
Because an inner class is defined inside another class, it may be protected by
making it invisible from the outside, for example by making it private. This
makes inner classes particularly good places to hide implementation. The actual
types of private inner classes are invisible outside of their containing objects,
making the inheritance and interface tricks of the previous section more powerful.

IPIJ || Lynn Andrea Stein

13.4 Inner Classes 13~19

Conversely, inner classes can also be used to protect their containing objects. An
inner class lives inside another object and has privileged access to the state of this
"outer" object. For this reason, inner classes can be used to provide access to their
containing objects without revealing these outer objects in their entirety. That is,
an inner class's instance(s) can (perversely) be used to limit access to its
containing class.

Beware: Although an inner class is defined inside the text of another class, there
is no particular subtype relationship established between the inner and outer
classes. For example, an inner class normally does not extend its containing
(outer) class.

13.4.1 Static Classes

A static inner class is declared at top level inside another class. It is also declared
with the keyword static. Static inner classes are largely a convenience for
defining multiple classes in one place. A static class declaration is a static member
of the class in which it is declared, i.e., it is similar to a static field or static
method declaration.
Understanding static inner classes is quite straightforward. There are only a few
real differences between a static inner class and a regular class. First, the static
inner class does not need to be declared in its own text file, even if it is public. In
contrast, an ordinary public class must be declared in a file whose name matches
the name of the class. Second, the static inner class has access to the static
members of its containing class. This includes any private static methods or
private static fields that the class may have.

The proper name of a static inner class is OuterClassName.InnerClassName.

Beware: This naming convention looks like package syntax (or field access
syntax), but it is not.
The constructor for a static class is accessed using the class name, i.e.,
new OuterClassName.InnerClassName()
perhaps with arguments as with any constructor.

IPIJ || Lynn Andrea Stein

13~20 Encapsulation Chapter 13

13.4.2 Member Classes

A member class is defined at top level inside another class, but without the
keyword static. A member class declaration is a non-static member of the class in
which it is declared, i.e., it is similar to a non-static field or method declaration.
This means that there is exactly one inner class (type) corresponding to each
instance of the outer class. If there are no instances of the outer class, there are in
effect no inner class types. When an outer instance is created, a corresponding
inner class (i.e., factory) is created and may be instantiated. Note that this does not
necessarily make any inner class instances; it just creates the factory object. The
inner class and all of its instances have privileged access to the state of the
corresponding outer class instance. That is, they can access members, including
private members.
An example may make this clearer. Suppose that we want to have a Check class
corresponding to each CheckingAccount. The Check class that corresponds to my
CheckingAccount is similar to the Check class that corresponds to your
CheckingAccount, but with a few differences. Specifically, my Check class (and
any Check instances I create) should have privileged access to my
CheckingAccount, while your Check class should have privilegedaccess to your
CheckingAccount. So, in effect, the Check class corresponding to my
CheckingAccount is different from the Check class corresponding to your
CheckingAccount. It differs precisely in the details of the particular
CheckingAccount to which it has privileged access. Creating a third
CheckingAccount -- say, Bill Gates's CheckingAccount -- should cause a new
kind of Check, Bill Gates's Checks, to come into existence. These Checks differ
from yours and mine. Note that creating Bill Gates's CheckingAccount also
creates Bill Gates's Check type, but doesn't necessarily create any of Bill Gates's
Check instances. Bill still has to write those....
class CheckingAccount extends BankAccount
{
...

protected class Check implements Instrument

{
private BankAccount originator = CheckingAccount.this;

private String payee;

private int amount;

private boolean valid;

....

protected Check( String payee, int amount, Signatory who )

{
if ( ! who.equals( CheckingAccount.this.owner ) )
{

IPIJ || Lynn Andrea Stein

13.4 Inner Classes 13~21

throw new BadCheckException( this );

}
this.validate( Signatory );
this.payee = payee;
this.amount = amount;
this.valid = true;
}

Instrument cash() throws BadCheckException

{
if ( ! this.valid )
{
throw new BadCheckException( this );
}
Instrument out = this.originator.withdraw( this.amount );
this.nullify();
return out;
}
}

In this case, there is in effect one Check class for each CheckingAccount. This is
precisely what you'd want: each CheckingAccount has a slightly different kind of
Check, varying by who is allowed to sign it, etc.

The proper name of a member class is instanceName.InnerClassName, where

instanceName is any expression referring to the containing instance. So a way to
name Bill's check type is gatesAccount.Check (assuming gatesAccount is
Bill's CheckingAccount), and he can write a new Check using
new gatesAccount.Check( worthyCharity, 1000000,
billSignature )
Note that he can't just say new Check(...), because that leaves ambiguous
whether he's writing a check from his account or from mine.
There is a special syntax that may be used inside the inner class to refer to the
containing (outer class) instance: OuterClassName.this. For example, in the
Check constructor code above, a particular Check's Signatory is compared against
the owner of the containing CheckingAccount by comparing it with the owner of
the containing CheckingAccount instance. This ensures that I can't sign a Bill
Gates Check, nor he one of mine. It is accomplished by looking at
CheckingAccount.this's owner field. Note the use of the
CheckingAccount.this syntax to get at the particular CheckingAccount whose
Check class is being defined.
The Check serves as a safely limited access point into the CheckingAccount. For
example, each Check knows its CheckingAccount's owner. When a new Check is
being created, the Check's Signatory is compared against the account owner
(CheckingAccount.this.owner, a field access expression) to make sure that this

IPIJ || Lynn Andrea Stein

13~22 Encapsulation Chapter 13

person is an authorized signer. The identity of the allowable Signatory of the

check is hidden, but it is fully encapsulated inside the Check itself. Anyone can
get hold of the Check without being able to get hold of the Signatory (or
BankAccount balance) inside.

13.4.3 Local Classes and Anonymous Classes

There are two additional kinds of inner classes, local classes and anonymous
classes. They are briefly explained here but their intricacies are beyond the scope
of this chapter.
A local class declaration is a statement, not a member. A local class may be
defined inside any block, e.g., in a method or constructor. There is in effect
exactly one local class for each execution of the block. For example, if a local
class is defined at the beginning of a method body, there is one local class type
corresponding to each invocation of the method, i.e., the class depends on the
invocation state of the method itself.
The syntax of a local class method is much like member class declaration, but the
name of a local class may only be used within its containing block. A local class's
name has the same visibility rules as any local name, i.e., its scope persists from
its declaration until the end of the enclosing block. You may only invoke a local
class's constructor with a new expression within this scope. You may return these
instances from the method or otherwise use these instances elsewhere, but their
correct type will not be visible elsewhere. Instead, you must refer to them using a
superclass or interface type.
A local class has privileged access to the state of its containing block as well as to
the state of its containing object (class or instance). The local class may access the
parameters of its containing method, as well as any local variables in whose scope
it appears, provided that they are declared final. If a local class is defined in a
nonstatic member (method or constructor), the local class's code may access its
containing instance using the OuterClassName.this syntax. If a local class is
defined in a static member (e.g., in a static method), the local class has only a
containing class, not a containing instance.
An anonymous class declaration is always a part of an anonymous class
instantiation expression. Anonymous classes may be defined and instantiated
anywhere where an instantiation expression might occur. They have a special,
very strange syntax. An anonymous class is only good for making a single
instance as an anonymous class declaration cannot be separated from its

IPIJ || Lynn Andrea Stein

13.4 Inner Classes 13~23

instantiation. Anonymous classes are a nice match for the event handling
approaches of the Event Delegation chapter.
The syntax for an anonymous class declaration-and-instantiation expression is
new TypeName () { memberDeclarations }
where TypeName is any visible class or interface name and memberDeclarations
are non-static field and method declarations (but not constructors). 4 If TypeName
is a class, the anonymous class extends it; if TypeName is an interface, the
anonymous class implements it. In either case, memberDeclarations must include
any method declarations required to make an instantiable (sub-)class. The
evaluation rules for this expression create a single instance of this new -- and
strictly nameless -- class type. Like a local class, the anonymous class's code may
access any final parameters or local variables within whose scope it appears, and
may use OuterClassName.this to refer to its containing instance if its
declaration/construction expression appears within a non-static member.

Inner Classes
Static Inner Member Local Anonymous

InnerClass
, but name is
OuterClass . outerInstance . accessible
Type Name none
InnerClass InnerClass only within
containing
block.

like local
like static member
Type Name like member (public, variable name,
(public, protected, invisible
Accessibility protected, private, etc.) i.e., only
private, etc.)
within block

Class is
contained (outer) class instance of (outer) class block expression
within

4
If there is necessary instance-specific initialization of an anonymous class, this may be
accomplished with an instance initializer expression. Such an expression is a block that appears at
top level within the class and is executed at instance construction time.

IPIJ || Lynn Andrea Stein

13~24 Encapsulation Chapter 13

Access to
static
members of yes yes yes yes
containing
class?

Access to
containing
yes, using yes, using yes, using
instance
no OuterClass . OuterClass OuterClass .
(including its this . this this
fields and
methods)?

Access to
parameters
yes, if they are
and local yes, if they are declared
no no declared
variables of final
final
containing
block?

visibility class
visibility class
static class ClassName
ClassName { only possible in
Declaration ClassName { {
instantiation (see
syntax members
members members below).
}
} }

as statement
inside a block
Where at top level in at top level in in anonymous class
(including
declared? OuterClass OuterClass instantiation expression
method,
constructor)

new
new new SuperTypeName()
new {
Instantiation OuterClass . outerInstanceExp
InnerClass
syntax InnerClass r . InnerClass
(...) members
(...) (...)
}

IPIJ || Lynn Andrea Stein

 Summary 13~25

Chapter Summary
• An abstraction relies only on general properties, leaving implementation
details to vary.

• Encapsulation packages up and hides those details.

• Procedural abstraction uses methods to accomplish abstraction and

encapsulation.

• A method should be short, have a succinctly summarizable function, and

not contain code that is redundant with other methods.

• Abstraction and encapsulation enhance the readability, comprehensability,

modifiability, and maintainability of code.

• Packages provide grouping among interrelated classes.

• The full name of a class or interface is prefaced by its package name.

• Import statements allow you to circumvent this longer name.

• Some other short names are automatically available, even without

an import statement.

• Visibility modifiers limit access to class members, including inner classes.

Together with the use of superclass or interface type names, they provide a
way to limit access to an object.

• Inner classes are a mechanism for defining one class inside another.

• This can be used to hide the inner class.

• This can also be used to limit access to the outer class by

distributing the inner class instead.

Exercises
To come…

IPIJ || Lynn Andrea Stein

 14
Chapter 14 Intelligent Objects and Implicit
Dispatch

Chapter Overview
• How can I exploit method "ownership" to make objects do what I
want?

• How do I pass behavior around?

• How do I know which method will be invoked?

Methods belong to objects. In some cases, as when getter and setter methods
allows access to an object's internal state, the reason for housing methods in
objects is clear. But in many cases, it may be less obvious why a method ought to
be affiliated with a particular object. In this chapter, we look at several cases in
which methods are used in concert with their owning objects to accomplish tasks
that might not be obvious.
Methods can be used as a way to create implicit dispatch. Many objects,

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
14~2 Intelligent Objects and Implicit Dispatch Chapter 14

belonging to many different classes, can each be given a method of the same
name (and footprint). In this case, dispatching to the correct code is as simple as
asking the object to perform this method for you.
Fixing the name of the method but leaving the owning object to vary allows you
to do a wide range of things. You can, in effect, pass a method as an argument (by
passing its containing object), return a method from a procedure (by returning its
containing object), or store it in a name or other structure (by storing its
containing object). You can remember who called you and arrange to call that
object back; you can build complex homogeneous structures by exploiting the fact
that one object is associated with other, equally intelligent, objects that can
cooperatively solve problems that none could solve individually.
Each of these mechanisms works because every method is associated with an
object. If the method name is fixed at the time that the program is written, its
target object can be allowed to vary, allowing a runtime decision as to which
piece of code -- which instructions, which method body -- should actually be
executed.

Objectives of this Chapter

1. To understand Java's method dispatch mechanism.
2. To be able to use the same-named method in different classes of objects to
create an implicit dispatch.
3. To appreciate how Runnables can be used to encapsulate procedures.
4. To learn how to set up and use callbacks so that a method can convey
information to its calling object without returning.
5. To recognize various forms of recursion and to be able to use structural
recursion as a problem-solving technique.
6. To understand, recognize, learn how, increase familiarity, master details,
appreciate, discover, be able to ....

IPIJ || Lynn Andrea Stein

14.1 Procedural Encapsulation and Object Encapsulation 14~3

14.1 Procedural Encapsulation and Object

Encapsulation
In the previous chapters, we saw how a central control loop can be used as a
dispatcher, invoking different methods at different times depending on
circumstances such as the value of a particular piece of state. We also saw how
the different responses can be packaged up inside methods and how these
methods in turn can be encapsulated inside objects. In this chapter, we will take
these ideas one step further and use Java's method dispatch mechanism (plus
some clever design) to determine what response is appropriate under various
circumstances.
Before we turn to the use of objects as a dispatch mechanism, let's briefly review
some of the properties of methods and of objects.
A method is a set of instructions to be followed. The method instructions are
executed when an instruction-follower evaluates a corresponding method
invocation expression, i.e., a call to the method. The method instructions may
require some information to be able to execute; these are the arguments to the
method. The method instructions may also produce some information; this is the
method's return value.
Every method belongs to a particular object; there are no methods "just floating
around" in Java. Each method body is textually contained in a class definition.
Regular methods belong to individual instances of the class in which they are
textually contained. (Static methods belong to the class object itself.)

For example, if yesBox is a Checkbox and you want to find out whether yesBox is
currently selected, you can ask yesBox to supply you with that information by
using the method invocation expression yesBox.isSelected(). There's no way
to just ask isSelected(), though: you have to know whose isSelected()
method it is.
Methods encapsulate behavior, but they do not by themselves encapsulate state.
This is the role of objects. An object typically contains both methods -- sets of
instructions -- and persistent information. For example, the Checkbox named by
yesBox has a method called isSelected(), which provides instructions for how
to determine whether yesBox is currently checked. When the expression
yesBox.isSelected() is evaluated, those instructions are executed and the
desired information is produced. But when the method is not being invoked, the
method itself doesn't have any information or action. In contrast, even in the
absence of any method invocation, the Checkbox yesBox contains state indicating

IPIJ || Lynn Andrea Stein

14~4 Intelligent Objects and Implicit Dispatch Chapter 14

whether it is currently selected, perhaps in the form of a private boolean field.

Objects, then, package both behavior (in the form of methods that can be invoked)
and persistent state that provides a background context for that behavior.
(Presumably yesBox.isSelected() behaves differently depending on whether
the hypothetical private boolean field is true.) An object exists even when none of
its methods is being invoked, and its fields persist between method invocations.
An object is thus a powerful mechanism for modeling parts of the world. By
making that state internal to the object, hiding it from external access, and
providing a set of methods that give selective access to that state, objects can be
used to encapsulate the coherent behavioral aspects of real-world things. The
method isSelected() by itself would have little meaning. The object yesBox
provides a context for the isSelected() method, so that it legitimately models
coherent persistent behavior.
The name of a method to be invoked must be chosen at the time that you are
writing your program. In contrast, the particular object whose method will be
invoked need not be known until the time that you actually run the program. For
example, when the expression yesBox.isSelected() is written, the method
name -- isSelected -- and even its footprint -- no arguments -- is already known.
No other method can be invoked with this expression. But at the time that the
expression is written, it may not be possible to tell to which object the name
yesBox will refer. It may, in fact, not even be possible to tell the exact type of the
object to which yesBox refers, although we know that it will be some type of
Checkbox. (It could be any subtype of Checkbox.)
In the remainder of this chapter, we will see how fixing the method name and
allowing its target object to vary gives the programmer a great deal of additional
power. In the first -- central -- example of this technique, we will shift specialized
behavior from their previous location in the handler methods within a single
object to a new role within separate objects, objects encapsulating both those
handler methods and associated state. We will see how this migration of behavior
from procedural encapsulation to object encapsulation provides a different model
for dispatch, and how it can be used to make object-oriented programming a
remarkably powerful technique.

14.2 From Dispatch to Objects

Consider the following problem: You are writing code that will retrieve objects,
one at a time, and print them out to the user. Some of these objects will be Strings.

IPIJ || Lynn Andrea Stein

14.2 From Dispatch to Objects 14~5

Some of the objects will be Points, items representing two-dimensional

coordinates. A Point object has methods to retrieve its individuate coordinates,
called getX() and getY(), each returning an int. And some of the objects will be
Dimensions, items representing two-dimensional extents, with int-returning
getWidth() and getHeight() methods. Your job is to write the printObject method.

14.2.1 A Straightforward Dispatch

You might implement this by using a simple dispatch mechanism. Since this
dispatch is done on the basis of the object's class, you cannot use a switch
statement. So we'll try an if:1
public void printObject( Object o )
{
if ( o instanceof String )
{
Console.println( o );
}
else if ( o instanceof Point )
{
Point p = (Point) o;
Console.println( "Point: (" + p.getX()
+ "," + p.getY() + ")" );
}
else if ( o instanceof Dimension )
{
Dimension d = (Dimension) o;
Console.println( "Dimension: (" + d.getWidth()
+ "," + d.getHeight() + ")" );
}
}

14.2.2 Procedural Encapsulation

Of course, knowing what we do about procedural encapsulation, this looks like a
superb opportunity to break out the concisely describable code. There are two
relatively obvious routines lurking here:

1
This code suffers from a few problems, not the least of which is that it doesn't do anything about
the possibility that o is none of the above. While we'd never write such code in a real application,
we'll skip the else error condition clause here for pedagogic succinctness.

IPIJ || Lynn Andrea Stein

14~6 Intelligent Objects and Implicit Dispatch Chapter 14

public String pointToString( Point p )

{
return "Point: (" + p.getX() + "," + p.getY() + ")";
}

and
public String dimensionToString( Dimension d )
{
return "Dimension: (" + d.getWidth() + "," + d.getHeight() + ")";
}

We might also, for symmetry, add

public String stringToString( String s )
{
return s;
}
although it doesn't seem particularly well-motivated at the moment.
Given these routines, we might rewrite printObject as
public void printObject( Object o )
{
if ( o instanceof String )
{
Console.println( this.stringToString( (String) o )
);
}
else if ( o instanceof Point )
{
Console.println( this.pointToString( (Point) o ) );
}
else if ( o instanceof Dimension )
{
Console.println( this.dimensionToString(
(Dimension) o ) );
}
}

14.2.3 Variations
The new printObject still has a certain amount of redundant code. We can pushing
the Console.println out of the individual ifs, but then we'll need to remember the
String returned by each toString method. We could write
public void printObject( Object o )
{
String s = "";
if ( o instanceof String )

IPIJ || Lynn Andrea Stein

14.2 From Dispatch to Objects 14~7

{
s = this.stringToString( (String) o );
}
else if ( o instanceof Point )
{
s = this.pointToString( (Point) o );
}
else if ( o instanceof Dimension )
{
s = this.dimensionToString( (Dimension) o );
}
Console.println( s );
}
In yet another optimization, we could actually transfer the coercion into the
individual toString methods, calling them on Objects rather than on specialized
types. This makes the methods somewhat less general -- what if they're called on
the wrong type of objects? -- but if we can be sure that they'll always be called
appropriately, it cleans up our dispatch code further.
public String pointToString( Object o )
{
Point p = (Point) o;
return "Point: (" + p.getX() + "," + p.getY() + ")";
}

public String dimensionToString( Object o )

{
Dimension d = (Dimension) o
return "Dimension: (" + d.getWidth() + "," + d.getHeight() + ")";
}

public String stringToString( Object o )

{
return (String) s;
}

Now the dispatch routine reads

public void printObject( Object o )
{
String s = "";
if ( o instanceof String )
{
s = this.stringToString( o );
}
else if ( o instanceof Point )
{
s = this.pointToString( o );
}
else if ( o instanceof Dimension )
{

IPIJ || Lynn Andrea Stein

14~8 Intelligent Objects and Implicit Dispatch Chapter 14

s = this.dimensionToString( o );
}
Console.println( s );
}

14.2.4 Pushing Methods Into Objects

We can take this whole approach one step further, and in doing so dramatically
simplify our dispatcher code. Instead of trying to give this dispatcher object a
toString method for each individual type that it might need to know about, we can
put the toString methods into the individual types directly. For example, Point
might have a method that says
public class Point
{
//...

public String toString()

{
return "Point: (" + this.getX() + "," + this.getY() + ")";
}
}

This is just the old pointToString, with a few modifications. First, note that we've
eliminated the argument that pointToString needed. This is because the Point
we're converting is this, i.e. the particular object whose toString() method is
being executed. Second, we don't need a coercion. That's because if this set of
instructions is being executed, it is because this (Point) object's toString() method
has been called, i.e., we must be dealing with a Point. You simply can't call
Point's toString() method on a Dimension (or a String).

A similar modification gives us Dimension's toString() method:

public class Dimension
{
//...

public String toString()

{
return "Dimension: (" + this.getWidth()
+ "," + this.getHeight() + ")";
}
}
And finally String's toString method is quite simple:
public class String
{

IPIJ || Lynn Andrea Stein

14.2 From Dispatch to Objects 14~9

//...

public String toString()

{
return this;
}
}
Now, if origin names the Point with coordinates (0,0) and square names the
Dimension with height 25 and width 25, origin.toString() returns the String
"Point: (0,0)", while extentless.toString() returns the String "Dimension:
(25,25)". Each object knows how to turn itself into a String using the toString()
method provided by its class.
In point of fact, the Java class java.lang.Object has a toString() method, and so
any Java object necessarily has a toString() method. In many cases, the toString()
method is inherited from Object and so prints a rather ugly representation of the
object. You may wish to override the toString() method of any class you expect to
be printing out a lot. For example, there is a real class called java.awt.Point, but
its toString() method isn't quite as succinct as the one we've given here.

14.2.5 What Happens to the Central Loop?

We have seen that writing the methods inside their respective classes makes them
considerably more succinct. After all, the toString() method of Point just has to
give instructions for how to print this, i.e., the particular Point whose toString()
method is being invoked. At the time that the method is invoked, all of the
relevant information is present in the target -- the object whose method is
invoked, i.e., this. But we haven't come to the best part yet.
Suppose that our types each implement their own toString() method. What, then,
does the dispatcher look like?

The new dispatch code is

public void printObject( Object o )
{
Console.println( o.toString() );
}
Where did the conditional go? The answer is that it is hidden inside Java's method
dispatch mechanism. Java decides which toString() method to invoke by looking
at the target's type.

IPIJ || Lynn Andrea Stein

14~10 Intelligent Objects and Implicit Dispatch Chapter 14

Whenever an instruction-follower evaluates a method invocation expression, Java

does a quick calculation to determine what kind of object the target -- the
method's owner object -- is. Depending on the class of that object, Java looks up
the appropriate method to invoke. (The argument types also play a role in
selecting the method invoked, specifically by selecting a method whose footprint
is appropriate.) This dispatch based upon the type of the target object is a simple
form of polymorphism. In general, polymorphism means doing different things
with different types of objects.
If we move the dispatchee methods out to their respective classes, we give each
kind of object its own type-specific way to respond to the request. Here, a
particular -- known, fixed -- method name and footprint is polymorphic with
respect to the target object to which it belongs. (Instances of many classes support
the same method footprint. Each class provides a different implementation.) By
allowing the target object to vary, we cause the same expression to invoke
different pieces of code.
This approach has several benefits. First, the dispatcher becomes significantly
more succinct. Second, the code that actually does the work is associated with a
specific type, meaning that it doesn't have to worry about verifying type or
coercion. Java does both dispatch and coercion automatically. The method is
necessarily invoked on a target of the appropriate type, because the target helps to
determine which method is invoked. Finally, if a new object type is to be added
(e.g., to the printObject method), the particular instructions for converting it to a
String can be added in the definition of the object's class; printObject no longer
needs to worry about which types it is suited to handle. In fact, since toString is a
method defined in the class java.lang.Object, printObject can handle any kind of
Object at all.

14.3 The Use of Interfaces

In the example above, we gained great power from pushing the conversion to a
String into each specific object type. Of course, any object type not supplied with
its own toString() method simply inherits one from its superclass. Since
java.lang.Object is the root of the class inheritance hierarchy, each class is
guaranteed to have a toString() method, if only the one defined for Object. But
sometimes you will want to use polymorphism to dispatch to a method that isn't
defined on java.lang.Object. What do you do then?

IPIJ || Lynn Andrea Stein

14.3 The Use of Interfaces 14~11

Consider the Calculator buttons of an earlier chapter. In that example, number

buttons are supposed to display themselves on the Calculator screen, while
arithmetic operator buttons are supposed to perform calculations and the clear
button is supposed to erase whatever happens to be displayed. The central
dispatcher of that program checked which button had been pressed and called the
appropriate helper method, contained within the dispatcher object.
Precisely the same sort of logic that we applied to the object printer would work
here. First, we need to define a series of object types. For example, we might have
a NumberButton class whose ten instances represent the number keys, from 0 to
9. We might have an OperatorButton class, one of whose instances would
represent the addition function of the calculator. And we might have a
ClearButton class with a single instance corresponding to the calculator's clear
key.
Each of these classes might be endowed with a buttonPressed method, to be
invoked by the dispatcher when the corresponding calculator button is pressed.
For example, ClearButton's buttonPressed method might say resetCalculator,
while a NumberButton's buttonPressed method would invoke displayDigit.
Whose resetCalculator and displayDigit methods are these? They belong to the
calculator. In order to do its job, the buttonPressed method will need to be given
access to the CalculatorState -- an object representing what's going on inside the
Calculator -- as an argument.
public class ClearButton
{
public void buttonPressed( CalculatorState calc )
{
calc.resetCalculator();
}
}
When the individual clear button's buttonPressed method is invoked, it will in turn
ask the calculator to reset itself.
public class NumberButton
{
private final int whichDigit;

public NumberButton( int which )

{
this.whichDigit = which;
}

public void buttonPressed( CalculatorState calc )

{

IPIJ || Lynn Andrea Stein

14~12 Intelligent Objects and Implicit Dispatch Chapter 14

calc.displayDigit( this.whichDigit );
}
}
Note that there are ten different NumberButton instances, and each instance will
need to remember which digit it represents.2 When, for example, the 0 button's
buttonPressed method is invoked, it asks its calculator to display its digit, i.e., 0.
The code for other button types is similar.
When we are done writing these button types, we will need to add code to the
calculator dispatcher (or to some other part of the system) that creates all of the
necessary instances of these classes. We might, for example, stick these instances
into an array indexed by the buttonID ints described in chapter 12. This would be
a field of our animate calculator object:
private Object[] buttonObjects = new Object[ Calculator.LAST_BUTTON_ID ];

And then, inside the constructor for that object, we need initialization code:
for ( int buttonID = 0; buttonID < 10; buttonID = buttonID + 1 )
{
this.buttonObjects[ buttonID ] = new NumberButton( buttonID
);
}

// and so on for operators, clear....

Once we have instantiated these button types, what does the dispatcher look like?
Its job will simply be to invoke the appropriate button object's buttonPressed
method.
public void act()
{
int buttonID = this.gui.getButton();
this.buttonObjects[ buttonID ].buttonPressed( this.calcState );
}

There is just one problem: this code won't compile. The array buttonObjects is an
array of Objects. But most Objects don't have a buttonPressed( CalculatorState )
method.
Why wasn't this a problem for the toString method of the object printer? Because
each Object has a toString() method, we didn't have to do anything special to
make the corresponding line of code -- the invocation of the object's toString()
method -- work. However, if we try this trick with a method that isn't possessed
by every object, we will find that our code won't compile. We can resolve this by

2
Once assigned, this digit doesn't change; hence, the field is declared final.

IPIJ || Lynn Andrea Stein

14.3 The Use of Interfaces 14~13

using an interface that specifies this contract.

public interface CalculatorButton
{
public void buttonPressed( CalculatorState calc );
}
This interface gives just the information we need -- the presence of a
buttonPressed method that requires a CalculatorState -- without saying anything
about how a particular CalculatorState should respond to a button's being pressed.
It leaves those aspects of the method to each class that provides an
implementation for CalculatorButton's buttonPressed method.
We will also need to go back and add this interface to each of the individual
calculator button classes. For example:
public class ClearButton implements CalculatorButton
{
public void buttonPressed( CalculatorState calc )
{
calc.resetCalculator();
}
}
Now, we can rewrite our declaration of the buttonObjects array.
private CalculatorButton[] buttonObjects
= new CalculatorButton[ Calculator.LAST_BUTTON_ID ];

Finally, our code will compile!

The calculator button is a more general example than the object printer, but both
illustrate the same set of ideas. By pushing methods out of the central dispatcher
object and into the classes representing distinct types of objects, we can package
up the methods with the information that they need to do their jobs. We can also
largely eliminate the explicit dispatcher of the chapter 12, using Java's method
dispatch mechanism in its place. This approach is very much in keeping with the
philosophy of object-oriented design: keep behavior together with state
encapsulated in objects.

14.4 Runnables as First Class Procedures

We have actually seen a special case of this kind of target-polymorphism-as-
dispatch in our use of Animates as the instructions for AnimatorThreads. In that
case, an AnimatorThread does very different things depending on the class of the
particular object whose act() method it executes. In other words, AnimatorThread

IPIJ || Lynn Andrea Stein

14~14 Intelligent Objects and Implicit Dispatch Chapter 14

uses its constructor argument -- the object whose act() method it is supposed to
execute -- to determine what it is supposed to do. The method footprint -- act() --
is fixed by the Animate contract. Naming this method there allows the
programmer to write it explicitly into code. Remember, method names cannot be
deduced and runtime, though their target objects can.
There is a similar situation in Java involving the interface Runnable (with a single
method, run() ) and the class Thread. A Thread is started on a particular object,
and the Thread follows the instructions supplied by that object's run() method. By
starting them on instances of different classes of Runnable objects, Threads can
be induced to behave in very different ways. Like act(), run() exploit's Java's
target-based dispatch mechanism to create different kinds of behavior.
But Runnables and run() can be used even without starting a new Thread, simply
because they are fixed names for executable behavior that takes no arguments.3
Suppose that you want to pass a procedure around from one object to another. For
example, suppose that you want to create a secret message and later, you will give
that message to a decoder that will print out your secret message. One way to do
this is to make the secret message a Runnable object and to use the secret
message's run() method as a way for the decoder to get the message out.
public class SecretMessage implements Runnable
{
private String message;

public SecretMessage( String message )

{
this.message = message;
}

public void run()

{
Console.println( this.message );
}
}

public class SecretDecoder

{
public void decode( Runnable secret )
{
secret.run();

3
Everything said here for run() could be done with another method with a different name, but that
name, too, would have to be fixed when the program is written. For no-arguments executable
code, run() and Runnable make a convenient convention. If you wish to pass arguments to this
procedure, you will need to define your own interface and your own method signature, as Java
offers no standard conventions.

IPIJ || Lynn Andrea Stein

14.4 Runnables as First Class Procedures 14~15

}
}

Now, if we have
SecretMessage message = new SecretMessage( "Meet me at midnight." );

and
SecretDecoder decoder = new SecretDecoder();

then we can try

decoder.decode( message );

which will print

Meet me at Midnight.

to the Java console. The message stays safe inside the SecretMessage as the
SecretMessage is passed from method to method, stored in fields, returned from
methods, and otherwise passed around the system. Because it has a run() method,
that method can eventually be invoked to get the desired behavior from of the
object.
In fact, by the time that this object makes it to the decoder, we might have lost
track of the fact that it is a SecretMessage. Suppose that we have an object
toBeRun, and all that we know about it is that it is a Runnable. We can still ask
decoder.decode( toBeRun );
And now we might find out, for example, that someone has replaced our message
with some Fireworks:
public class Fireworks implements Runnable
{
private Color color;

public Fireworks( Color color )

{
this.color = color;
}

public void run()

{
Console.println( "Crash! Bang! You see "
+ this.color.toString() );
}
}
Polymorphic dispatch ensures that toBeRun will print its message if it is a
SecretMessage, and will explode colorfully if it is Fireworks. You do not need to
know what kind of thing it is to arrange to send it to the right method; instead,
Java's dispatch mechanism ensures that even when you don't know exactly what

IPIJ || Lynn Andrea Stein

14~16 Intelligent Objects and Implicit Dispatch Chapter 14

type of thing you have, the right method will be invoked.

14.5 Callbacks
A particular circumstance in which this "do the right thing" aspect of Java's
method dispatch is important is called callbacks. A callback is a situation in
which one object has invoked a method of another, and the second object needs to
get some information back to the first without returning from the method
invocation. There are a few prerequisites for callbacks:
1. The invoking object must pass a reference to itself into the original
invocation, or must otherwise indicate whose method is to be "called
back."
2. The invoking method and the invoked method must agree upon the name
of the callback method.
3. The invoked method must record the reference to the invoking object --
the callback target -- e.g., as a parameter to the original invocation or as a
field.
4. At the appropriate occasion, the invoked method must invoke the callback
method on the callback target. The fixed method name is used in this
expression; the reference to the callback target is a variable.
Suppose, for example, that we have an object whose purpose is to create many
separate "web spiders", simple programs that traverse the internet looking for
interesting information.4 Your original object will want to know when the spider
finds interesting information. But the spider won't want to stop executing when it
finds the first interesting piece of information. Instead, the spider should take the
address of its sponsor with it when it goes crawling through the web, and any time
it finds an interesting piece of information it should "call back" the sponsor
object, giving it that information without stopping its execution.
The actual situation for a web spider is a little bit more complicated than this
description because web spiders often don't run on the same computer as their

4
Such programs can be very useful, but you must be extremely careful in writing them. Serious
disasters have been caused by web spiders that got out of control, for example creating so many
spiders that the network filled up with spiders and couldn't sustain its regular traffic.

IPIJ || Lynn Andrea Stein

14.5 Callbacks 14~17

sponsor and so can't make direct method calls. But we can use this idea as the
framework for some code that illustrates callbacks.
public class SpiderStarter
{
private String interestingStuff = "";

public void startSpider()

{
new Spider( this ); // give invoked method a reference
} // to the invoker, i.e., the callback target

/* informationFound is the callback method.

* It simply records the information...
*/
public void informationFound( String interestingItem )
{
if ( this.interestingStuff == null )
{
this.interestingStuff = interestingItem;
}
else
{
this.interestingStuff = this.interestingStuff
+ " and also "
+ interestingItem;
}
}

/* This is a simple utility method.

*/
public void printInfoSoFar()
{
Console.println( "I heard " + this.interestingStuff );
}

This class provides three methods. The first starts up a Spider, telling the Spider
who its sponsor is. The second provides a way for the Spider to call it back (when
it finds information). The third provides a way for other objects to ask the
SpiderStarter to let it know what information it has collected.5
The definition for Spider might read
public class Spider extends AnimateObject
{
// where to record the callback target

5
Strictly speaking, this code might be subject to problems if we start up more than one Spider. We
really need to protect the interestingStuff using synchronization, as described in part 5 of this
book. These issues don't affect the main point of this chapter, but you should be aware of them if
you want to run a code example like this one.

IPIJ || Lynn Andrea Stein

14~18 Intelligent Objects and Implicit Dispatch Chapter 14

private SpiderStarter sponsor;

public Spider( SpiderStarter who )

{
this.sponsor = who; // record the callback target
}

public void act()

{
// Some code that looks for interesting stuff.
// if you find it, call back

this.sponsor.informationFound( interestingInfo );
}

Now, we might say

SpiderStarter mamaTarantula = new SpiderStarter();
mamaTarantula.startSpider();

This starts a spider going. The "looking for interesting stuff" part of the Spider is
missing, but we can still see how a Spider might take advantage of the callback
mechanism. Since a Spider is an AnimateObject, its act() method will be executed
over and over again. Each time, if it finds some interesting information, it will
invoke its sponsor's informationFound method with the interesting information.
But SpiderStarter's informationFound method just adds the new information to its
information store and returns, so the AnimatorThread that runs the Spider
AnimateObject is free to call its act() object again.
Consider trying to write Spider without the callback. SpiderStarter doesn't call a
method of Spider's directly, so Spider can't return a String that way. Even if
SpiderStarter did call Spider directly, mamaTarantula presumably wants the
Spiders to keep going even after they find their first piece of interesting
information. So it is very important that the individual Spiders have a way to get
information back without stopping their own execution. This is precisely the kind
of situation in which a callback is useful.
Callbacks are a very general mechanism that can be used any time one object
needs to get information to its invoker without returning the information directly.
They require agreement on the name of a method -- perhaps specified by an
interface contract -- that will be used to produce the callback. Callbacks take
advantage of the idea that Java's dispatch mechanism will call the appropriate
piece of code. Good object encapsulation ensures that the information supplied in
a callback gets to the appropriate place.

IPIJ || Lynn Andrea Stein

14.6 Recursion 14~19

14.6 Recursion
One final example of how Java's method dispatch mechanisms work is the idea of
recursion. Recursion is the name for a technique in which the same named
method is called over and over again, doing something slightly different each
time. There are two kinds of recursion: structural recursion, which is quite
common in Java and other object-oriented programming languages, and
functional recursion, which is much more prevalent in functional programming
languages.

14.6.1 Structural Recursion

Structural recursion is a natural extension of method dispatch to a uniform
collection of objects. It is really just the idea that an object can act on its own
behalf -- i.e. provides methods specifying its own behavior -- coupled with the
idea that one object can contain -- or have fields that are -- other objects. For
example, the calculator had (access to) many CalculatorButton objects, and it
relied on them to each provide the appropriate behavior. Structural recursion is
just like this, except that the object doing the relying and the component object on
which it relies are instances of the same class.

a.

IPIJ || Lynn Andrea Stein

14~20 Intelligent Objects and Implicit Dispatch Chapter 14

b.

c.

Various linked lists (following code in text). a. After defining shorty. b. After
defining list. c. After assigning to list.

14.6.1.1 A Recursive Class Definition

Suppose, for example, that we have a class called LinkedList:
public class LinkedList
{
private LinkedList next;
private Object contents;

public LinkedList( Object what, LinkedList next )

{
this.contents = what;
this.next = next;

IPIJ || Lynn Andrea Stein

14.6 Recursion 14~21

// maybe some methods....

}
To begin with, this definition is recursive. That is, the LinkedList type is defined
in terms of itself. Note that this isn't at all the same thing as saying that a
particular LinkedList is defined in terms of itself; it just means that a LinkedList
consists of its contents (some arbitrary object) and its next element, which is
either nothing (i.e., this is the last element) or also a LinkedList.
The idea of an object that has associates -- or contains components -- of the same
type really isn't all that strange. For example, if we have a representation for a
person, we might use the same representation for that person's parents. The same
"method" for figuring out who your father is should apply equally well to figure
out who his father is.
To create a LinkedList, you need to give it a LinkedList. To make this work, there
needs to be a simple case that is not explicitly recursive. This is called a base
case. In the case of the LinkedList definition, the base case is null: null is a
(non)value that can be associated with a name of type LinkedList that is not
defined in terms of a LinkedList. A LinkedList with a null next field is the last
element in the list.

So, for example, we can say

LinkedList shorty = new LinkedList( "Not least", null );

We can also say

LinkedList list = new LinkedList( "Pen Ultimate", shorty );

or even
list = new LinkedList( "First and foremost",
new LinkedList( "Sandwich filling", list ) );

Each of these LinkedList objects either has a next field that refers to another
LinkedList object, or has a next field that is unassigned, i.e., has the value null.

14.6.1.2 Methods and Recursive Structure

Structural recursion is simply a way in which methods can take advantage of the
recursive definition of LinkedList. It relies on the idea that each of the recursively
contained objects is itself a full-fledged intelligent entity. For example, suppose
that you are providing a LinkedList with a method to convert itself to a String.
This method might, e.g., be suitable for printing out all of the elements contained
in a LinkedList. Since one LinkedList contains another (through its next field), we

IPIJ || Lynn Andrea Stein

14~22 Intelligent Objects and Implicit Dispatch Chapter 14

can make use of the fact that that next element is also an intelligent LinkedList
and will be able to convert itself to a String as well.
In writing the code to convert a particular LinkedList instance to a String, there
are two possibilities.
1. Perhaps this is the last element in the list, i.e., this LinkedList object's next
field is null. Then we can solve this problem simply: just convert the
contents of this object to a String.
2. Otherwise, this is not the last element; this object contains a non-null next
field. In this case, converting this LinkedList to a String requires
converting the contents of this object, then adding a comma, then
converting this object's next (LinkedList) to a String. But that next
LinkedList is an intelligent object, too. We can just ask it to convert itself!
It may seem like there's a bit of sleight of hand going on here. This argument may
look suspiciously like a circular definition. But it is not. Let's examine the logic
here carefully.
The first of these is the simple case in which there is no further recursion. As in
the definition, this is called the base case. This condition would apply if we asked
the LinkedList labeled shorty to print itself -- i.e., if we invoked
shorty.toString() -- which would return the String "Not Least". There is only
one element in this list, so printing its contents suffices.
The second case is called the recursive case, the case that relies on recursion to
work. It says, roughly, I know how to convert myself to a String, and my next
knows how to convert itself to a String, so I will simply combine those two
answers. Of course, the way that the next LinkedList element converts itself to a
String relies on this same code....so here it is. Imagine this definition inside the
class LinkedList, where the comment says maybe some methods....
public String toString()
{
if ( this.next == null )
{
return this.contents.toString();
}
else
{
return this.contents.toString()
+ ", " + this.next.toString();
}
}

IPIJ || Lynn Andrea Stein

14.6 Recursion 14~23

Suppose that we invoke list.toString(). In this case, the object referred to by

the name list has contents "First and foremost", so it would begin its answer
with that String. But that's not enough. Because list's next field isn't null, it also
needs to do something about that next field. It can't complete its answer until it
knows how to print the LinkedList that is its next field. Luckily, list.next is
also a LinkedList, so it knows how to convert itself to a String. So after "First and
foremost", list adds in a comma. Then list invokes its next field's toString()
method to find out how to end its String.

When list.next's toString() method is invoked, it checks to see whether its

next field is null. Since it isn't, it can't use the base case. So it first converts its
own contents into a String -- "Sandwich filling" -- and then adds a comma, and
then asks its next field to convert itself to a String.

Once again, the LinkedList has a non-null next field, so once again the recursive
case is invoked, creating "Pen Ultimate" + ", " plus the value of its next field's
toString() method.

The next field of this LinkedList is the same object referred to by the name
shorty. We've already seen how shorty converts itself to a String using the base
case -- returning "Not least" -- so now we can finish off "Pen Ultimate" + ", " +
"Not least". This is returned to list.next, completing "Sandwich filling, Pen
Ultimate, Not least". Finally, this String is returned to the LinkedList labeled
list, and that LinkedList can return its value as a String: "First and foremost,
Sandwich filling, Pen Ultimate, Not least".

14.6.1.3 The Power of Recursive Structure

The power of recursion here comes from the fact that each of the individual
LinkedList elements knows how to combine its next field's toString() with its
own contents. "If only my next field could supply its toString()," the LinkedList
seems to say, "I could produce my answer. But of course the answer for the next
field can be constructed out of its contents and its next field, and so on, until we
come to the base case: a LinkedList in which the next field is null, so there's no
need to get its toString().
[Important] Note that it is crucially important that the recursive case invoke the
same-named method on a simplerobject. That is, each recursive step must get a
little bit closer to the base case. Imagine instead a situation in which you were
printing a circular LinkedList. In this case, there would always be a next

IPIJ || Lynn Andrea Stein

14~24 Intelligent Objects and Implicit Dispatch Chapter 14

LinkedList to print, and the process would never end.6

A similar kind of structural recursion could be used to find out whether a
particular object is contained in a LinkedList. In this case, there are actually two
base cases.

1. If this.contents is the desired object, then the LinkedList contains that

object, i.e., return true.

2. If this.contents is not the desired object, but this.next is null, then

this LinkedList doesn't contain the desired object, i.e., return false.

3. Otherwise, since this.contents is not the desired object, this LinkedList

contains the desired object exactly when the desired object is contained by
the LinkedList this.next.
There's a fairly straightforward translation of this into Java code:7
public boolean contains( Object what )
{
if ( this.contents == what )
{
return true;
}
else if ( this.next == null )
{
return false;
}
else
{
return this.next.contains( what );
}
}

6
Actually, to prevent just such situations, the computer may have the ability to detect this
circumstance—an infinite loop—and to object to it by raising an exception.
7
Actually, Java's && and || operators are guaranteed to evaluate their operands from left to write,
proceeding only until the value of the expression is known. In the case of &&, as soon as one
operand is false, no further operands need be evaluated. In the case of ||, evaluation stops as soon
as an operand is true. This means that we could rewrite contains as:
public boolean contains( Object what )
{
return ( ( this.contents == what )
|| ( ( this.next != null )
&& this.next.contains( what ) );
}

IPIJ || Lynn Andrea Stein

14.6 Recursion 14~25

Structural recursion is an extension of "the object can handle it" to the case in
which the method invocation expression is contained within the same method that
it invokes. Because the target of the invoked method is a "simpler" object -- one
that is somehow closer to the base case -- this approach ultimately produces a
satisfactory answer.

14.6.2 Functional Recursion

Functional recursion is a further extension of the idea of recursion. In this case,
there is no structure whose inherently recursive nature is exploited by the
recursion. Instead, the necessary subsequent simplifications -- steps to get closer
to the base case -- happen in one of the method's arguments.
For example, many kinds of numerical calculations can be performed using purely
functional recursion. In this case, it is common to define one or more base cases --
e.g., how the function should behave on a simple number such as 1 -- and then to
recursively build a solution for one number out of the solution for a smaller
number. Factorial is one such function:
1. The factorial of 1 is 1.
2. The factorial of an arbitrary number, n, is n times the factorial of n-1.
The first of these is the base case. It simply produces an answer, with no recursion
necessary. The second of these is the recursive case. It wishfully assumes that you
know how to calculate the factorial of n-1, then uses that to construct the factorial
of n. By "peeling off" one number at a time, it is possible to calculate the factorial
of any number. This is really just like structural recursion, but there's no change
of the method's target here.
public int factorial( int n )
{
if ( n == 1 )
{
return 1;
}
else
{
return n * this.factorial( n - 1 );
}
}
Factorial of 5 is 5*factorial of 4, which is 4*factorial of 3, and so on until factoria
of 1, which is 1. So factorial of 2 is 2*1, and factorial of 3 is 3*(2*1), of 4 is

IPIJ || Lynn Andrea Stein

14~26 Intelligent Objects and Implicit Dispatch Chapter 14

4*(3*2*1), and of 5 is 5*4*3*2*1. This is just like LinkedList's toString()

method, except that the accumulation isn't coming from changing the target of the
method invocation.

Chapter Summary
• Objects encapsulate information necessary to make methods effective.

• When multiple classes have methods with the same name, Java chooses
the method that matches the target's (most specific) type.

• Dispatch can be replaced by empowering objects directly. Depending on

the type of the target object, the same textual method invocation will
actually call different code. This is called method polymorphism.

• A common superclass or interface, providing the method signature for the

polymorphic method, is required for this kind of implicit dispatch.

• Method dispatch based on the target object can be used for other purposes
as well:

• Behavior can be passed to methods, returned from methods, and

stored in objects by making it the run method of a Runnable object.

• An executing method can give information to the object that called

it, without returning, by using an explicitly agreed upon callback
method.

• Recursion is a situation in which one method name is invoked repeatedly.

• In structural recursion, the target of the method varies.

• In functional recursion, at least one of the method's arguments

varies.

• In all recursions, there must be a base case that does not involve
recursion.

• In the recursive case, the recursive call must be to a

method/target/argument that is somehow closer to the base case.

IPIJ || Lynn Andrea Stein

 Exercises 14~27

Exercises
1. Write toString() methods for an Address object and for a Date object. How
would printObject have to change if it might be asked to print an Address or a
Date as well as a String, Point, or Dimension?
2. Write clone() methods for Point and Dimension. (A clone() method should
create a new copy of its target object.) Write a dispatcher called cloneObject(
Object o ).
3. Write an animate AlarmedTimer class that counts by itself, as the Timer class
of chapter 9 does. In addition, it should have a setAlarm( int interval, Alarmable
who) method. When this method is invoked, the AlarmedTimer should callback
the Alarmable's alarmReached() method every int ticks. Here is Alarmable:
public interface Alarmable
{
public void alarmReached();
}
4. Using the LinkedList code above, add a method that returns the Object that is
the contents of the last element in a LinkedList. For example, list.getLast()
would return "Not least", as would shorty.getLast().
5. Define a recursive structure for a family tree. Each person in the tree should
have a father and a mother, which should be either another person or -- e.g., if the
information were not available -- null. Give this a method that prints all ancestors
of a given individual.
Bonus: Give this structure the ability to print only all female ancestors (using
Console.println).
Extra Bonus: Would your female-ancestor-printer print my father's mother?

IPIJ || Lynn Andrea Stein

 15
Chapter 15 Event-Driven Programming

Chapter Overview
• How do we design an entity to emphasize its responses to various
events?
In previous chapters, we have seen how an animate object can use its explicit
control loop as a dispatcher, calling appropriate methods depending on what input
it receives. In this chapter, we discuss a style of programming that shifts the
emphasis from the dispatcher to the various handler methods called by that
control loop. Entities designed in this way highlight their responses to a variety of
situations, now called events. An implicit -- behind-the-scenes -- control loop
dispatches to these event handler methods.
This event-driven style of programming is very commonly used in graphical user
interfaces (GUIs). In Java, AWT's paint methods are an example of this kind of
event-driven programming. This chapter closes with an exploration of a portion of
the java.awt package, including java.awt.Component and its subclasses, to
illustrate the structure of programs written in an event-driven style.

©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
15~2 Event-Driven Programming Chapter 15

Objectives of this Chapter

1. To recognize event-driven control
2. To understand that event handlers describe responses to events, not their
causes
3. To be able to write event handlers for simple event-driven systems

15.1 Control Loops and Handler Methods

In chapter 11, we looked at mechanisms for explicit dispatch. In that chapter, the
job of the central control loop was to decide what needs to be done and then to
call a helper procedure to do it. In this way, a single control loop can handle a
variety of different inputs or circumstances. We saw, for example, how a
calculator might respond differently to a digit, an operation, or another button
such as =. The calculator's central control loop acts as a manager, routing work to
the appropriate procedures. The actual work is accomplished by these helpers, or
handler methods.
In this chapter, we will look at the same kind of architecture from a different
viewpoint. Instead of focusing on the central control loop's role as a dispatcher,
we will take that function largely for granted and look instead at control from the
perspective of the handler methods. In other words, we will explore how one
writes handlers for special circumstances, assuming that these handler methods
will be called when they are needed. By the end of this chapter, we will turn to a
system in which this is true without programmer effort, i.e., in which Java takes
responsibility for ensuring that the handler methods are called when they are
needed.
The basic idea of event-driven programming is simply to create objects with
methods that handle the appropriate events or circumstances, without explicit
attention to how or when these methods will be called. These helper methods
provide answers to questions of the form, "What should I do when xxx happens?"
Because xxx is a "thing that happens", or an event, these methods are sometimes
called event handlers. As the writer of event handler methods, you expect that
the event handlers will somehow (automatically) be invoked whenever the

IPIJ || Lynn Andrea Stein

15.1 Control Loops and Handler Methods 15~3

appropriate thing needs dealing with, i.e., whenever the appropriate event arises.1
The result of this transformation is that your code focuses on the occasions when
something of interest happens -- instead of the times when nothing much is going
on -- and on how it should respond to these circumstances. An event is, after all,
simply something (significant) that happens. This style of programming is called
event-driven because the methods that you write -- the event handlers -- are the
instructions for how to respond to events. The dispatcher -- whether central
control loop or otherwise -- is a part of the background; the event handlers drive
the code.

15.1.1 Dispatch Revisited

Consider the case of an Alarm, such as might be part of an AlarmClock system.
The Alarm receives two kinds of signals: SIGNAL_TIMEOUT, which indicates
that it is time for the Alarm to start ringing, and SIGNAL_RESET, which
indicates that it is time for the Alarm to stop. We might implement this using two
methods, handleTimeout() and handleReset().
public class Alarm
{
Buzzer bzzz = new Buzzer();

public void handleTimeout()

{
this.bzzz.startRinging();
}

public void handleReset()

{
this.bzzz.stopRinging();
}
}

1
Ensuring that those event handler methods will be called is a precondition for event-driven
programming, not a part of it. We will return to the question of precisely how this can be
accomplished later in this chapter.

IPIJ || Lynn Andrea Stein

15~4 Event-Driven Programming Chapter 15

A passive Alarm object, whose methods are invoked from outside.

How do these methods get called? In a traditional control loop architecture, this
might be accomplished using a dispatch loop. For example, we might make Alarm
an Animate and give it its own AnimatorThread. The job of the dispatch loop
would be to wait for and processes incoming (timeout and reset) signals. This
AnimateAlarm's act() method might say:
public class AnimateAlarm extends AnimateObject
{
Buzzer bzzz = new Buzzer();

public void handleTimeout()

{
this.bzzz.startRinging();
}

public void handleReset()

{
this.bzzz.stopRinging();
}

public void act()

{
int signal = getNextSignal();
switch (signal)
{
case SIGNAL_TIMEOUT:
this.handleTimeout();
break;
case SIGNAL_RESET:
this.handleReset();
break;
// Maybe other signals,
too....
}
}
}

IPIJ || Lynn Andrea Stein

15.1 Control Loops and Handler Methods 15~5

An active Alarm object, invoking its own methods.

Of course, the real work is still done by the handleTimeout() and

handleReset() methods. The job of the dispatch loop (or other calling code) is
simply to decide which helper (handler) method needs to be called. The
dispatcher -- this act() method -- is only there to make sure that handleTimeout()
and handleReset() are called appropriately.

15.2 Simple Event Handling

What would happen if we shifted the focus to the helper procedures? What if we
made the dispatch code invisible? Imagine writing code (such as this Alarm) in
which you could be sure that the helper methods would be called automatically
whenever the appropriate condition arose. In the case of the Alarm, we would not
have to write the act method or switch statement above at all. We would simply
equip our Alarm with the appropriate helper methods -- handleTimeout() and
handleReset() -- and then make sure that the notifier mechanism knew to call
these methods when the appropriate circumstances arose. This is precisely what
event-driven programming does.

IPIJ || Lynn Andrea Stein

15~6 Event-Driven Programming Chapter 15

15.2.1 A Handler Interface

We have said that event-driven programming is a style of programming in which
your code provides event handlers and some (as yet unexplained) event dispatcher
invokes these event hander methods at the appropriate time. This means that the
event dispatcher and the object with the event hander methods will need a way to
communicate. To specify the contract between the event dispatcher and the event
handler, we generally use an interface specifying the signatures of the event
handler methods. This way, the event dispatcher doesn't need to know anything
about the event handlers except that they exist and satisfy the appropriate
contract.
In the case of the alarm, this interface might specify the two methods we've
described, handleTimeout() and handleReset():
public interface TimeoutResettable
{
public abstract void handleTimeout();

public abstract void handleReset();

}

An Alarm that handles two event types.

Of course, we'll have to modify our definition of Alarm to say that it implements
TimeoutResettable:

public class Alarm implements TimeoutResettable

IPIJ || Lynn Andrea Stein

15.2 Simple Event Handling 15~7

{
Buzzer bzzz = new Buzzer();

public void handleTimeout()

{
this.bzzz.startRinging();
}

public void handleReset()

{
this.bzzz.stopRinging();
}
}

Note that this is a modification of our original Alarm, not of the AnimateAlarm
class. The TimeoutResettable Alarm need not be Animate. In fact, if it is truly
event-driven, it will not be.
This TimeoutResettable Alarm definition works as long as some mechanism --
which we will not worry about just yet -- takes responsibility for dispatching
handleTimeout() and handleReset() calls as appropriate. That dispatcher
mechanism can rely on the fact that our Alarm is a TimeoutResettable, i.e., that it
provides implementations for these methods. The dispatcher that invokes
handleTimeout() and handleReset() need not know anything about the Alarm
other than that it is a TimeoutResettable.

15.2.2 An Unrealistic Dispatcher

How might our TimeoutResettable Alarm be invoked? There are many answers,
and we will see a few later. For now, though, it is worth looking at one simple
answer to get the sense that this really can be done.
A simple -- and not very realistic -- event dispatcher might look a lot like the act
method of AnimateAlarm. To make it more generic, we will separate that method
and encapsulate it inside its own object. We will also give that object access to its
event handler using the TimoutResettable interface. Major differences between
this code and AnimateAlarm are highlighted. Of course, the dispatcher doesn't
have its own handler methods; its constructor requires a TimeoutResettable to
provide those.

public class TimeoutResetDispatcher extends AnimateObject

{
private TimeoutResettable eventHandler;

IPIJ || Lynn Andrea Stein

15~8 Event-Driven Programming Chapter 15

public TimoutResetDispatcher( TimeoutResettable eventHandler )

{
this.eventHandler = eventHandler;
}

public void act()

{
int signal = getNextSignal();
switch (signal)
{
case SIGNAL_TIMEOUT:
this.eventHandler.handleTimeout();
break;
case SIGNAL_RESET:
this.eventHandler.handleReset();
break;
}
}
}

The details of this dispatcher are rather unrealistic. For one thing, it is extremely
specific to the type of event, and extremely general to its event handler
dispatchees. More importantly, in event-driven programming it is quite common
not to actually see the dispatcher.
But dispatchers in real event-driven programs play the same role that this piece of
code does in many ways. For example, the dispatcher doesn't know much about
the object that will actually be handling the events, beyond the fact that it
implements the specified event-handling contract. This dispatcher can invoke
handleTimeout() and handleReset() methods for any TimeoutResettable,
provided that the appropriate TimeoutResettable is provided at construction time.
Different dispatchers might dispatch to different Alarms. In fact, timeout and reset
are sufficiently general events that other types of objects might rely on them.

15.2.3 Sharing the Interface

An ImageAnimation is a single component that displays a

sequence of images, one at a time. For example, these
frames, displayed in an ImageAnimation, would give the
impression of a clock whose hands move.

IPIJ || Lynn Andrea Stein

15.2 Simple Event Handling 15~9

Another object that might be an event-driven user of timeouts and resets -- and be
controlled by the TimeoutResetDispatcher -- is an image animation. An image
animation is a series of images, displayed one after the other, that give the
impression of motion. In this case, we use the timeout event to cause the next
image to be displayed, while reset restores the image sequence to the beginning.
ImageAnimation simply provides implementations of these methods without
worrying about how or when they will be invoked.
public class ImageAnimation implements TimeoutResettable
{
private Image[] frames;
private int currentFrameIndex = 0;

// To be continued...
The image array frames will hold the sequence of images to be displayed during
the animation. When the ImageAnimation is asked to paint (or display) itself, it
will draw the Image labeled by this.frames[this.currentFrameIndex]. By
changing this.currentFrameIndex, we can change what is currently displayed.
When we do change this.currentFrameIndex, we can make that change
apparent by invoking the ImageAnimation's repaint() method, which causes the
ImageAnimation to display the image associated with
this.frames[this.currentFrameIndex].

We omit the setup code that loads the Images into frames and handles other
construction details.
The next segment of code is the timeout event handler, the helper method that is
called when a timeout occurs. What should the ImageAnimation do when a
timeout is received? Note that the question is not how to determine whether a
timeout has occurred, but what to do when it has. This is the fundamental premise
behind event-driven programming: the event handler method will be called when
appropriate. The event handler simply provides the instructions for what to do
when the event happens. When a timeout occurs, it is time to advance to the next
frame of the animation:
public void handleTimeout()
{
if (this.currentFrameIndex < (this.frames.length - 1))
{
this.currentFrameIndex = this.currentFrameIndex + 1;
this.repaint();
}
}

IPIJ || Lynn Andrea Stein

15~10 Event-Driven Programming Chapter 15

This code checks to see whether there are any frames left. If the animation is
already at the end of the sequence, the execution skips the if clause and -- since
there is no else clause -- does nothing. Otherwise -- if there's a next frame -- the
execution increments the current frame counter, setting up the next frame to be
drawn. Then, it calls this.repaint(), the method that causes the
ImageAnimation to be redrawn. Recall that the ImageAnimation paints itself
using the image that is associated with this.frames[this.currentFrameIndex].
What about a reset? What should the ImageAnimation do when it receives the
signal to reset? Handling a reset event is much like handling a timeout, but even
simpler. The ImageAnimation simply returns to the first image in the sequence:
public void handleReset()
{
this.currentFrameIndex = 0;
this.repaint();
}
No matter what, we reset the current frame index to 0, then repaint the image
animation with the new frame. Note also that the next timeout will cause the
frame to begin advancing again.
The code to actually repaint the image, which we have not shown here, makes
this.frames[this.currentFrameIndex] appear. As a result,
handleTimeout() works by changing the index to the next frame (until the end
of the animation is reached); handleReset() restarts the image animation by
restoring the index to the beginning index of this.frames once more.
Both Alarm and ImageAnimation are objects written in event-driven style. That
is, they implement a contract that says "If you invoke my event handler method
whenever the appropriate event arises, I will take care of responding to that
event." Alternately, we think of the contract as saying "When the event in
question happens, just let me know." When building both Alarm and
ImageAnimation, the question to ask is, "What should I do when the specified
event happens?"

IPIJ || Lynn Andrea Stein

15.3 Real Event-Driven Programming 15~11

15.3 Real Event-Driven Programming

We have seen other examples of event-driven coding style. In this section, we
briefly review these and recast them in light of event-driven programming's
central question, "What should I do when xxx happens?" After reviewing these
examples, we turn to look at the relationship of event providers to event handlers.

15.3.1 Previous examples

In chapter 9, we saw how an Animate's act() method is repeatedly invoked by an
AnimatorThread. This act() method is in effect an event handler. It answers the
question, "What should I do when it is time for me to act?" The Animate doesn't
know who is invoking its act() method or how that invoker decided that it was
time to act. It simply knows that it is, and how to respond to that knowledge, i.e.,
how to act(). The act() method may be invoked by an AnimatorThread instruction
follower, executing at the same time as other parts of the system. It might equally
well be invoked by a TurnTakerAnimator that controls a group of Animates and
gives one Animate at a time a turn to act(). This latter approach might make
sense, for example, in a board game where each player could move only when it
was that player's turn.
Similarly, we saw how a Runnable object has a run() method that can be invoked
in an event-driven style. This is commonly done when the run() method is
invoked by starting up a new Thread. In this case, the Runnable's run() method is
invoked when the Thread is start()ed. From the perspective of the Runnable, its
run() method is automatically invoked whenever it is time for the Runnable to "do
its thing". In a self-animating object like a Clock, run() might be an event-
handler-like method that is called by something "outside" (in this case, the
Thread) when it is time for the Clock to begin execution.
The StringTransformer's transform methods of Interlude 1 were yet other
examples of an event-driven style. These event handler methods simply answer
the question, "What should I do when this StringTransformer is presented with a
String to transform?" or "How do I respond to such a request?" These objects
provide customized implementations for transforming strings. The decision of
when to invoke these methods are outside the control of their owning objects.
In each of the cases described above, the event producer -- the thing that knows
that it is time for a handler method to be invoked -- and the event handler -- which
responds to the occurrence -- communicate fairly directly. For example, the
TimeoutResetDispatcher polls (or explicitly asks) for signals and then directly

IPIJ || Lynn Andrea Stein

15~12 Event-Driven Programming Chapter 15

invokes the event handler methods of its TimeoutResettable.

15.3.2 The Idea of an Event Queue

Event-driven programming by its very nature allows a more distant relationship
between event producers and event consumers. Since the producer disavows
responsibility for handling the event, it doesn't need to know or care who is taking
on that responsibility; it merely needs to indicate that the event has arisen. The
event handler doesn't really care where the event came from ; it just need to know
that it will be invoked whenever the event has happened. This dissociation
between event producers and event consumers is one of the potential benefits of
programming in an event driven style.
Systems that take advantage of this opportunity to separate event producers from
event handlers generally contain an additional component, called the event
queue, that serves as an intermediary. It is important to understand how the event
queue can be used and the role that it plays as an intermediary between event
producers and event handlers. Unless you are building your own event-driven
system from the ground up, it is not important that you be able to build it.
Generally, an event queue is provided as a part of any event-based system, and the
major event-based systems in Java are no exception.

An event queue serves as an intermediary between event

producers and event handlers.

The role of the event queue is to serve as a drop-off place for events that need to
be handled, sort-of like a To Do list. When an object produces behavior that
constitutes an event, it reports that event to the event queue, which holds on to the
event. The report of the event may be as simple as an indication that something
happened ("Timeout!") or as complex as a complete description of the state of the
world at the time that the event happened (e.g., the complete Wall Street Journal

IPIJ || Lynn Andrea Stein

15.3 Real Event-Driven Programming 15~13

report on the stock market crash). What is important is that the event queue stores
(remembers) this event report.
In addition to receiving event reports, the event queue also has an active
instruction-follower that removes an event (typically the oldest one) from the
queue and notifies any interested event handler methods. This is the queue-
checker/dispatcher. An event queue also needs some way to figure out who to
notify when an event has happened. In the cases that we explore in this chapter,
there is always a single event queue per hander object, so it is always that object
to which events are reported. In the next chapter, we will discuss a system that
allows finer-grained control.
Consider the TimeoutResettable event handlers described above. A timer might
generate the timeout events and deposit them into the queue. It would then return
to its own business, keeping time and paying no more attention to the event
queue. A separate instruction follower, the event dispatcher, would discover the
timeout event in the queue and invoke the handleTimeout() method of the relevant
party. The structure of this "queue cleaner" would be very similar to the
TimeoutResetDispatcher we saw above.

15.3.3 Properties of Event Queues

This mechanism allows for a separation between the event producer and the event
handler. The instruction-follower that puts an event into the queue -- the one who
generates the event -- is not necessarily the instruction follower who performs the
handler method (i.e., handles the event). Instead, one or more dedicated
instruction followers have the task of processing events deposited into the queue,
invoking the event handler method(s) as needed. Event suppliers need to know
only about the event queue, not about the event handler methods.
Note that it is the event queue dispatcher's Thread (or instruction follower) that
actually executes the steps of the event handler method. (Method invocation does
not change which instruction follower is executing.) As a result, when you are
writing event handlers, it is important that the event handler code complete and
return (relatively) quickly; for example, it should not go into an infinite loop.2 If
the event dispatcher invoked an event handler that did not return, the dispatcher

2
A Runnable's run() method is an exception to this, because the Thread that executes run() has
nothing to go back to doing. When run() completes, the execution of that Thread stops.

IPIJ || Lynn Andrea Stein

15~14 Event-Driven Programming Chapter 15

would be unable to process other events waiting in the queue.

You will almost never have to deal with an event queue explicitly unless you
write your own event-driven system from scratch. Most programmers who write
event-driven programs do not ever touch the event queue that underlies their
systems. Instead, like many other aspects of event-driven programming, event
queueing is generally a part of the hidden behavior of a system. However, there's
nothing particularly mysterious about it. An event queue's contract provides an
enqueue (add to the queue) operation and a dispatcher that actually invokes the
event handler methods.3
In Java, the graphical user interface toolkit provides an event queue to handle
screen events such as mouse clicking and button pressing. That event queue is
fairly well hidden under the abstractions of the toolkit, so that you may not realize
that it is an event queue at all. In the next chapter, we will explore that more
complex system, which is used for most events in Java's windowing toolkit. That
system decouples the event hander from the object to whom the event happens,
allowing one object to provide the handler for another's significant events. This is
known as event delegation.

15.4 Graphical User Interfaces: An Extended Example

So far, we have left open the question of where and how events get generated.
This is because in the most common kind of event system that you are likely to
encounter -- a windowing system for a graphical user interface -- you do not deal
with event generation directly. Instead, Java takes care of notifying the
appropriate objects that an event of interest has occurred. When you are writing
graphical user interfaces in Java, you will write event handlers without ever
having to worry about when, where, and how the appropriate events are produced.
Before we can begin to talk about event handling in graphical user interfaces, we
need to look briefly at what graphical user interfaces are and how they are built in
Java. A graphical user interface -- sometimes called a GUI, pronounced "gooey" -
- is a visual display containing windows, buttons, text boxes, and other "widgets".
It is common to interact with a graphical user interface using a mouse, though a

3
In the next chapter, we will see that some event queues also provide an event listener registry
service. This is not necessary in the event systems of this chapter, where there is a single event
queue per handler object, but provides yet another layer of flexibility.

IPIJ || Lynn Andrea Stein

15.4 Graphical User Interfaces: An Extended Example 15~15

keyboard is often a useful adjunct. Graphical user interfaces became the standard
interface for personal computers in the 1980s, though they were invented much
earlier.

A sample graphical user interface.4

15.4.1 java.awt
Java provides a few different ways of making graphical user interfaces. In this
section, we will take a look at the package java.awt. This package contains three
major kinds of classes that are useful for making GUIs. The first of these is
java.awt.Component and its subclasses. These are things that appear on your
screen, like windows and buttons. The immediately following subsection explores
this component hierarchy. The second major GUI class is the class
java.awt.Graphics, which is involved in special kinds of drawing. We will
return to java.awt.Graphics at the end of this chapter. The final group of
classes are the event classes: the java.awt.Event class together with the classes
in the java.awt.Event package. We'll come back and look at AWT Events in the
event delegation chapter. Here we'll deal only with one (pseudo-)event, painting.
In the remainder of this section, we are going to focus on Components and, in a
bit, Graphics.
The event that we will be concerned with here is painting. That is, this is the event
that occurs when a window or other user interface object becomes visible, is
resized, or for other reasons needs to be redrawn. This event happens to a
Component. In order to handle this event you need to know what the current state
of the drawing is, including both its coordinate system and what if anything is
currently visible. That information is held by a Graphics. So when the event

4
This is a screen shot from Claris Home Page 3.0.

IPIJ || Lynn Andrea Stein

15~16 Event-Driven Programming Chapter 15

happens, it takes a form roughly paraphrased as "paint yourself on this screen".

The event handler belongs to a Component -- the "self" to paint -- and it takes a
single argument, a Graphics -- the "screen" on which to paint.

15.4.2 Components
A component is a thing that can appear on your screen, like a window or a button.
The parent of all component classes is java.awt.Component. The Component
class embodies a screen presence. You can't have a vanilla Component, though;
you can only have an instance of one of its subclasses. (In fact,
java.awt.Component is an abstract class. See the sidebar in Chapter 7 for further
detail on abstract classes.)

Although you can't instantiate Component directly, Component has several useful
subclasses. One group of these is the set of stand-alone widgets that let you
interact with your screen in stereotyped ways. There are many GUI widgets built
in to java.awt. These include Checkbox, Choice, List, Button, Label, and
Scrollbar. In addition, there are several Menu variants that don't extend
Component directly, but also provide useful widgets. Each of these widgets is
pretty well able to handle its GUI behavior -- showing up, disappearing, allowing
selections to be made, etc. In the event delegation chapter, we will see how to use
these GUI components to allow the user to communicate with your application;
for example, to have something smart happen when a selection is made. (This
involves customizing these widgets' event handlers.)
Another set of components are called Containers. These Components extend
java.awt.Container (which itself is an abstract class extending
java.awt.Component.) Containers are components that can have other components
inside them. For example, a java.awt.Window (which is a kind of component) can
have a java.awt.Scrollbar.
In this chapter, we will confine ourselves to one simple component behavior:
painting itself. To do this, we will use a generic Component, called Canvas, that
you can instantiate. The java.awt.Canvas class doesn't do anything special, but
you can either use it as a generic component or extend it to get specialized
behavior. We will make a Canvas that paints itself with a special picture.

IPIJ || Lynn Andrea Stein

15.4 Graphical User Interfaces: An Extended Example 15~17

Standard screen coordinates, showing the origin, directions of

increasing horizontal (x) and vertical (y) coordinates, and two
other sample points.

15.4.3 Graphics
A java.awt.Graphics (sometimes called a "graphics context") is a special kind of
object that knows how to make pictures appear. A Graphics uses a coordinate
system to keep track of locations within it. The origin of this coordinate system --
the point (0,0) -- is in the upper left-hand corner. Moving right from this point
involves increasing the first (x) coordinate, so (100, 0) is 100 pixels to the right of
the origin, along the top edge of the Graphics.5 Moving down increases the
second (y) coordinate, so (0,50) is 50 pixels below the top of the Graphics, along
its left-hand side. (100,50) is a point that is not on either the top or left edge; it is
100 pixels to the right and 50 pixels down.

Each Graphics has methods such as drawLine, fillOval, and setColor that
allow you to create pictures. For example, if you had a Graphics named g,
g.fillOval(100,100,10,10) would make it display a 10-pixel by 10-pixel
circle with its upper left-hand corner at position 100, 100. If you called
g.setColor(Color.red) first, the circle would be red. A complete list of the
methods of a java.awt.Graphics, together with a brief description of each, can be
found in the java.awt.Graphics reference.
A Graphics is not the kind of object that you are likely to create or have hanging
around. You will probably never run into the Graphics associated with GUI
widgets or containers. However, each time that your Canvas needs to redisplay
itself, it will be handed a Graphics context with which to do that redisplaying. So
there will be times when your code will be given a Graphics to use.

5
A pixel, short for picture element, is the smallest visible unit on your computer's screen. A
higher resolution display is one that has more pixels in the same amount of space, i.e., one with
smaller pixels. Java Graphics are delineated in pixels.

IPIJ || Lynn Andrea Stein

15~18 Event-Driven Programming Chapter 15

15.4.4 The Story of paint

Painting (itself) is what a GUI component does when it becomes visible. For
example, if a window is (partially) covering a component and then the window is
moved, the component needs to make itself look right again. Java takes care of
automatically determining that this should happen and asks the component to
paint itself.
Every java.awt.Component has an event-driven paint method. This method does
not say when the component should be painted, nor why, nor on what. This
method has nothing to do with determining that painting is necessary. Instead, this
method is the set of instructions that describe how to paint the Component. It is
the answer to the question, "What should I do when it is time to paint myself (on
the provided Graphics screen)?" It is the job of whatever calls the paint method to
determine whether and when the Component needs to be painted.
The paint method of a Component is passed a Graphics object. This is the
Graphics which contains, among other things, the coordinate frame within which
drawing on this Component should take place. It also contains a variety of utilities
that will make things actually appear within the Component. Just as you don't
have to determine when or whether paint should be invoked, you don't need to
provide the Graphics object. Like magic, when paint is invoked, the Graphics
object will be there.
Each paint method contains the specific instructions that that component needs to
make itself appear. For example, a Button's paint method makes the button label
appear on the button. A Window's paint method not only makes the Window
appear, it also makes sure that the paint method of each of the components
contained in the Window gets called as well.
When the paint method is invoked, it is equipped with a single argument, a
Graphics. If what the Component does to display itself is, for example, to draw
shapes, this Graphics (the argument passed in to the Component's paint method) is
what actually does the drawing.
Your job, when implementing a paint method, is to make use of this provided
Graphics (and any other information that the object may have) in order to make
the correct picture appear. You supply the instructions to be executed. To paint
me, make a big red dot. Or, to paint me, print my name. Or, to paint me, paint
each of the Components that appear inside me.
Suppose that you want to have your Component contain a rectangle in the upper
left-hand corner. A Graphics has a drawRect method which does just that. When

IPIJ || Lynn Andrea Stein

15.4 Graphical User Interfaces: An Extended Example 15~19

your component's paint method is called, it should ask whatever Graphics object
is supplied to it to drawRect( int x, int y, int width, int height).6
For example, if paint were called with a Graphics named g, the instructions might
read
g.fillRect(0,0,20,20);

to draw a square in the upper left-hand corner of the Component. The whole
method would read
public void paint( Graphics g )
{
g.fillRect(0,0,20,20);
}
A Component's paint method is an event handler. This means that the
Component's paint method is the set of instructions describing the Component's
response to a request to redisplay itself. It triggers whenever Java finds that
something has happened that requires the component to redisplay itself.

15.4.5 Painting on Demand

When we say that paint is an event handler method, what we mean in part is that
your code doesn't call paint directly. Instead, paint is called automatically by the
Java runtime system any time the Component needs to redisplay itself. This could
happen, for example, if a window were covered up and then uncovered: when the
uncovering event occurs, the window needs to repaint itself. Each of the
components, containers, and widgets in java.awt has an event-driven paint
method. Note, however, that there's no Paintable interface; paint is a method of
Component and is inherited by every class that extends Component.

The paint method takes a Graphics context as an argument. You cannot, in

general, supply the appropriate Graphics context to a Component; but since you
don't call paint, you don't need to supply the Graphics. Instead, Java's behind the
scenes bookkeeping takes care of this. (Remember, paint(Graphics g) is used

6
drawRect takes four arguments: the upper left hand coordinates and the size coordinates. All
measurements are in pixels -- tiny boxes that make up your screen -- and the origin -- the point
(0,0) -- is in the upper left-hand corner of the component. These are called "screen coordinates".
Graphics objects have lots of other drawing methods, too. See the java.awt.Graphics
documentation for a comprehensive listing.

IPIJ || Lynn Andrea Stein

15~20 Event-Driven Programming Chapter 15

in event-driven style; that is, it is called by Java, not by your program.)

Your code cannot call paint directly. It is an event handler method and it uses an
event queue; only the queue manager can call paint. But sometimes you will know
that it is necessary for a GUI object to repaint itself. For example, in the code
above the image animation needed to repaint itself each time the
currentFrameIndex changed. Since you can't call the component's event handler
directly, each Component provides another method, called repaint(), that you
can call. If you call the component's repaint() method, it will ask Java to send it
a new paint event.
If you do ever need to tell the system that you want your component to be painted,
you need to arrange for Java to provide the appropriate information to your class.
You can do this by calling the component's repaint() method. Unlike paint,
which takes a Graphics as an argument, repaint takes no parameters. (This is
good, because you don't generally have a Graphics around to give paint. This is
another thing that Java keeps track of automatically.) You don't have to
implement repaint(); java.awt.Component.repaint(), which you will
inherit, queues up a new paint(Graphics g) request (even supplying the
appropriate Graphics) behind the scenes. Remember: You never call paint, and
you never implement repaint. To cause a painting to happen, call repaint(); to
explain how to paint your component, implement (override) the paint(Graphics
g) method -- and don't worry about the Graphics, it will be automatically supplied
to you!

15.5 Events and Polymorphism

One advantage of using an event-driven style is that your code can focus on how
to respond to things that happen. It does not have to spend a lot of time figuring
out whether things happen or deciding what has happened and who should deal
with it. (Of course, event-driven code relies on an event dispatcher, which does
have to deal with these things, but often either one is available -- as in the GUI
case -- or a fairly simple and generic one will do.)
A second advantage of the event-driven style is that, when used in concert with an
event queue (as in Java's AWT), it separates the generator of the event (e.g., the
window motion) from the handler of the event (the component that is uncovered).
This means that these two pieces of the system can be designed independently.
All they have to do is to agree on the event protocol that they will use (in this
case, repaint() and paint(Graphics g)). How each one fulfills its side of the

IPIJ || Lynn Andrea Stein

15.5 Events and Polymorphism 15~21

contract -- how the component decides to paint itself, for example -- is something
that the rest of the system doesn't have to worry about.
A corollary benefit, then, is that different kinds of components can handle the
same event in very different ways. We saw this early in this chapter where the
same pair of events -- timeout and reset -- were used to run both an alarm and an
image animation. In these two objects, the timeout event meant very different
things. The alarm handled a timeout by turning on its buzzer; the image animation
switched to the next image each time a timeout occurred.
The GUI painting system that we have described uses this polymorphism to great
advantage. When a component like a Canvas is asked to paint itself in a Graphics,
it may draw a simple picture using the Graphics supplied. When a widget like a
Button is asked to paint itself, it creates labeled region of the screen appropriate
for clicking into. A Checkbox may paint itself as a square, with or without an X in
it depending on whether the Checkbox is checked. A container such as a Window
not only paints itself, it also asks each of the components contained inside it to
paint themselves. The Window doesn't need to know anything about how these
components appear; it simply asks them to paint themselves in the way that they
know best.

Chapter Summary
• By hiding the central control loop, we shift emphasis from explicit
dispatch to event handler methods.

• Event driven programming separates things that happen from how they're
handled.

• Each object is free to implement the same event handler in a different,

customized way.

• In Java's AWT, certain GUI events are automatically dispatched by the

Java runtime.

• The root of the GUI component hierarchy is java.awt.Component.

Although java.awt.Component is an abstract class, it has many useful
subclasses, including

• widgets such as Checkbox, Choice, List, Button, Label, and

IPIJ || Lynn Andrea Stein

15~22 Event-Driven Programming Chapter 15

Scrollbar.

• Containers, Components that can hold other Components.

• Canvas, a generic Component that you can customize.

• Every java.awt.Component has a paint(Graphics g) method that is

called by Java when Java needs to make the Component (re)appear on the
screen.

• By overriding or implementing a paint(Graphics g) method,

you are describing how your custom component should handle
requests to paint itself.

• You don't generally call a component's paint method. (Among

other things, you don't have a Graphics to pass it.) If you want to
redraw a GUI component, you can call its repaint() method.

Exercises
1. Define a TimeoutResettable that simply prints to the Console whenever an
event happens. The message printed should differ depending on which
event occurs. Implement it in a purely event driven style, i.e., assuming
that something else will manage the event dispatching.
2. Describe a scenario in which an event occurs to the object in the previous
exercise. Explain the sequence of action.

3. Define a class that extends java.awt.Canvas and has an unfilled circle

with its upper left hand corner at 100, 100.
(Bonus) What happens if you make the Canvas very small? Can you
modify your class to keep the circle centered on the Canvas? You can use
Canvas's getSize() method, which returns a java.awt.Dimension with
directly manipulable height and width fields.

4. Define a class that extends java.awt.Canvas and paints itself like a

black-and-white checkerboard. You may assume that the dimensions of
the Canvas are 400x400.
 Exercises 15~23

(Bonus) Make the checkerboard red and black.

5. Define a class that extends java.awt.Canvas and has two different

painting behaviors. (For example, it could paint a black circle or a red
square.) This class should also have a changeMe method. Each time its
changeMe method is called, it should redisplay itself using the other
behavior (e.g., it should switch between a black circle and a red square).
Hook this up to a Timer (from Chapter 8).
You can test your Canvases using the cs101.awt.DefaultFrame class included in
the code supplement to this book.

IPIJ || Lynn Andrea Stein

 16
Chapter 16 Event Delegation and java.awt

Chapter Overview
• How do I separate an entity's core behavior (model) from its on-
screen appearance (view)?

• How do intermediate (listener) objects couple together system

components that don't know about one another?
In the simple event model of the previous chapter, each visible component
provides an event handler method (e.g., paint) that is invoked every time that the
appropriate event is triggered (e.g., by uncovering a window or by an explicit call
to repaint()). The component doesn't (necessarily) have an always-active
animacy (Thread); instead, it is woken -- invoked by the event dispatcher
instruction follower -- whenever an appropriate event occurs.
In the previous chapter, we saw how event driven programming focuses a
system's design on what to do when certain events happen. The mechanism that
recognizes and dispatches these events fades into the background. We saw how
this approach is used to implement painting in java.awt components. In that
©1999 Lynn Andrea Stein. This chapter is excerpted from a draft of Interactive Programming In Java, a
forthcoming textbook from Morgan Kaufmann Publishers. It is an element of the course materials developed
as a part of Lynn Andrea Stein's Rethinking CS101 Project at the MIT AI Lab and the Department of
Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.

Permission is granted to copy and distribute this material for educational purposes only, provided that the
following credit line is included: "©1999 Lynn Andrea Stein." In addition, if multiple copies are made,
notification of this use must be sent to ipij@ai.mit.edu or ipij@mkp.com.
16~2 Event Delegation and java.awt Chapter 16

system, each Component handles its own events. In this chapter, we will look at a
more complicated two-layer model which further separates the event producer
from the event consumer. This mechanism, which relies on an explicit listener
registration protocol, is at the heart of the event handling system in Java's AWT
versions 1.1 and later.
The problem of GUI design is illustrative of larger design issues. The event-
delegation approach described in this chapter arises from our desire to separate
what happens in the GUI (such as clicking a button) from the behavior that this
causes (such as playing a song). To make this work, we connect GUI objects
(such as Buttons) to application objects (such as SongPlayers) indirectly, through
special EventListener objects. The EventListener records the appropriate
connection between GUI events and application behavior, keeping these details
out of both GUI and application components. This allows significant flexibility: a
single application behavior may be invoked by many different GUI events; one
GUI event may give rise to many application behaviors; or the relationship
between GUI events and application behavior may be remapped by a running
program, for example.
This kind of indirect coupling through a Listener object is a useful technique in a
wide range of applications.

16.1 Model/View: Separating GUI Behavior from

Application Behavior
In the previous chapter we explored event-driven programming as a way of
focusing on the important things that happen in a program. An event handler is a
method that responds to some important circumstance, or event. It answers the
question, "What should I do when xxx happens?" It shifts the emphasis from
figuring out what has happened and deciding what to do (the dispatcher) to the
actual code that handles the event, whenever it may arise. Event driven
programming is the idea that an object simply provides an event handler method -
- instructions to follow -- and does not worry about how or when those
instructions are executed. Somehow, an instruction-follower will invoke this
method -- and follow its instructions -- when appropriate.
Java's AWT graphical user interface toolkit uses event-driven programming to
coordinate the display of GUI objects on your computer screen. Each

IPIJ || Lynn Andrea Stein

16.1 Model/View: Separating GUI Behavior from Application Behavior 16~3

java.awt.Component implements its own paint( Graphics g ) method, which

supplies the instructions for making that Component appear in the coordinate
space described by g. As in all event-driven programs, the event handler paint
method does not worry about when, why, or whether it is time to paint. When the
paint method is invoked, it means that the need for painting has arisen -- the event
has occurred -- and the paint method's execution simply responds to that event.
In AWT painting, the need-to-paint event happens to a particular Component.
When a need-to-paint event arises, AWT makes it clear who is responsible for
handling that event: the Component that needs to be painted. But there are many
other kinds of events for which the question, "Who should handle this event?"
does not have such an obvious answer. This chapter is about more general
mechanisms that let programmers answer that question in a more flexible way,
separating the Component to which the event happens from the object that
handles the happening.
In many cases, the appearance of a GUI object and its underlying behavior may
actually be implemented by two different Java Objects. For example, the GUI
object that implements a set of radio buttons may be a Panel containing a number
of Checkboxes. This is called the view: what the mechanism looks like, its screen
appearance. In addition, when the appropriate buttons are pressed, a song may be
played. This is called the model: how the mechanism behaves. The view -- in this
case, the Panel -- is responsible for keeping track of the on-screen appearance of
the CheckBoxes (with their help, of course). The Panel need not be responsible
for playing the song, though. The model, which provides the song-playing
behavior, may in fact be implemented by a different object. Logically, we want to
separate out the GUI appearance (and GUI behavior, e.g., buttons looking pressed
or not pressed) from the underlying application behavior. Java's AWT event
delegation mechanism lets us do just that.1

1
The event delegation mechanism described in this chapter is used in Java's AWT version 1.1 and
later and also in the Java Swing toolkit. In Java's AWT version 1.0, all event handling was done
using a system closer to that of chapter 15.

IPIJ || Lynn Andrea Stein

16~4 Event Delegation and java.awt Chapter 16

Dispatching Events: A fully general scenario.

16.1.1 The Event Queue, Revisited

In the previous chapter, we saw that we can separate the generator of an event
from the actual invocation of an event handler through the use of an event queue.
The event queue is a place where an event producer can "drop off" the
information that an event had occurred. For example, code can call a Component's
repaint() method. This adds a painting request to the event queue. Paint requests
can also get added to the queue by screen events, such as a Window moving to
uncover a Component or a new Window being asked to show(). Inside the queue,
it doesn't matter how the event got added. A separate active event dispatcher
looks at the requests in the queue and figures out which event handlers need to be
called when. The event dispatcher picks up an event (or, in the case of repaint
requests, perhaps several requests) and invokes the appropriate method (e.g.,
paint( Graphics g )).
In the case of painting, you can imagine that there is one event queue per
Component. The dispatcher doesn't need to figure out what code to call; all of the
requests in that queue are for the associated Component. When a need-to-paint
request arises, Java ensures that that Component's paint( Graphics ) method is
called. The Component doesn't have to do anything more than provide a (possibly
inherited) implementation for this method.
All GUI events -- not just painting -- happen to particular Components. The
mouse is clicked inside a particular Component. Only one Component at a time
can be listening to the keyboard.(Being the Component that is listening to the
keyboard is called "having the focus".) So when an event occurs, it will still get

IPIJ || Lynn Andrea Stein

16.1 Model/View: Separating GUI Behavior from Application Behavior 16~5

added to the queue belonging to the Component with which it is associated.

But suppose that we want to separate even event ownership from the
responsibility for handling the event. Suppose, for example, that clicking a radio
button (GUI Component) causes another object -- a SongPlayer -- to play a song.
If responsibility for handling the event doesn't necessarily belong to the
Component -- if we are separating the Component view from a distinct Object
implementing the model -- the event queue's dispatcher needs to figure out who to
notify that the event has occurred. We need a mechanism for associating the
events that happen (and the objects to which they happen) with interested parties
that are willing to handle those events. We call these interested parties listeners.
The system by which a separate event-handling object listens for events that occur
to another (GUI Component) object is sometimes called event delegation.
Java solves the "who to notify" problem by introducing the idea of listener
registration. You can think of this as being something like subscribing to a
newspaper clipping service or personalized online news service. When you
subscribe to such a service, you give the service a list of topics that you're
interested in. This is registering your interest with the event queue, or listening.
The service maintains a list of subscribers along with their interests. These are the
registered listeners. Each time that a new article comes in, it is added to the pile of
clippings to be considered. This is putting an event into the queue. An employee
of the clipping service picks up a clipping (typically the oldest one) and checks to
see who might be interested. If the article matches your interests, the clipping
service sends you a copy. This is dispatching to the event handler methods.
Events -- such as mouse clicks or being uncovered when a Window moves -- still
happen to individual Components. But -- for many such GUI events -- each
java.awt.Component has its own event queue that can dispatch to the
appropriate registered event handlers. These event handlers need to know about
and register with the Component whose events they want to listen for; they need
to tell the event queue which events they are interested in handling. The
Component maintains a list of listeners who will handle its events.
Registering a listener is like leaving a (specialized) request with the clipping
service: If any articles about Indonesian coffee come, please send them to
Working Joe, and if any mouse motion events occur, please send them to the
mouse motion listener that's waiting for them.

IPIJ || Lynn Andrea Stein

16~6 Event Delegation and java.awt Chapter 16

16.2 Reading What the User Types: An Example

Imagine that we want to have the user type her name into a GUI widget. When
she does so, we will print a friendly greeting. This section walks through this
example, providing a pragmatic introduction to the actual AWT mechanisms
required to implement event delegation.
The code that follows assumes that it appears in a method within a class within a
file that imports cs101.awt.DefaultFrame, java.awt.TextField, and
java.awt.event.ActionListener, and java.awt.event.ActionEvent. In general in this
chapter we will omit package names unless they are needed for clarity.

16.2.1 Setting Up a User Interaction

The first thing that we need to do is to create a place where the user can type her
name. Java provides an AWT widget that is useful for just such occasions, a
TextField.
TextField nameField = new TextField( "Type your name here"
);
This line creates a TextField, a rectangular box containing text. The constructor
argument is the text initially displayed in this box.

nameField.setEditable( true ); // Make it possible for the user

// to type into the TextField.
nameField.selectAll(); // Highlight the original text so that
// what the user types replaces it.

The first of these lines makes it possible for the user to type in the TextField. The
second highlights all of the text in the TextField, so that what the user types will
replace the text displayed there.

new DefaultFrame( nameField ).init(); // Create a Frame around the TextField.

Finally, this line creates a cs101.awt.DefaultFrame, an awt Window in which a
single Component can be displayed. DefaultFrame is a restricted kind of Frame,
but has the advantage that it takes care of certain housekeeping details for you.
DefaultFrame's init() method actually makes the window appear on the screen.

IPIJ || Lynn Andrea Stein

16.2 Reading What the User Types: An Example 16~7

See the sidebar on DefaultFrame for details.

Now suppose that the user types her name into the TextField box, replacing the
highlighted text previously displayed. If the user ends her name by typing the
return key, this causes an action event to be registered on the TextField. In other
words, something has happened and we are ready to invoke the appropriate event
handler.

Now, we are ready to print our greeting. For example, we might say
Console.println( "Hello, " + reference_to_nameText.getText() );

Each TextField has a getText() method that returns the String displayed in the
TextField at the time of the getText() invocation. So, if we execute code along
these lines, the text
Hello, Galadriel
should appear on the Java Console. There are, of course, a few issues:
1. Where does this code appear? That is, who is handling the event, and in
what method?

2. How does that event handler access the TextField called nameText (in
order to ask it to getText())?
This is where Java's event delegation system comes in.

IPIJ || Lynn Andrea Stein

16~8 Event Delegation and java.awt Chapter 16

cs101.awt.DefaultFrame
A cs101.awt.DefaultFrame is a cs101 utility provided to make it easy to put
up a window containing a single Component. The DefaultFrame takes care
of sizing, activating the window's close box, causing the window to appear
on the screen, etc.
If c is a Java component, it can be made to appear on the screen using
new cs101.awt.DefaultFrame( c ).init();
// Create a Frame around the component.

The first half of this statement is an object construction expression that

creates a DefaultFrame around c. The second half of the statement invokes
this DefaultFrame's init() method, which is useful for its side effect: it
displays Component inside the DefaultFrame, i.e., in its own window. Of
course, you can use a more complex version of this code that names the
new DefaultFrame, allowing you to use it elsewhere in your program, if
you wish:
cs101.awt.DefaultFrame frame = new cs101.awt.DefaultFrame( c );
frame.init();
// Create a Frame around the component.
The class cs101.awt.DefaultFrame extends java.awt.Frame, documented in
the AWT Quick Reference appendix to this book. For the complete code
implementing cs101.awt.DefaultFrame -- which is straightforward -- see
the online supplement to this book.

16.2.2 Listening for the Event

The event generated by Galadriel's return is associated with the TextField called
nameField. That TextField is like a clipping service, and a new item of potential
interest -- the action taken by Galadriel -- has just arrived. Now, Java needs to
determine who is interested in nameField's action events.
Who might be interested? There is a special interface, called ActionListener, that
describes the contract to be implemented by any object interested in handling
action events. Here is the definition of the ActionListener interface:
public interface ActionListener extends EventListener {
public void actionPerformed( ActionEvent ae );
}
The actionPerformed method is an event handler, so its implementation will

IPIJ || Lynn Andrea Stein

16.2 Reading What the User Types: An Example 16~9

answer the question, "What should I do when an action is performed?" In this

case, the answer is to print out the text currently displayed by the TextField in
which Galadriel typed her name. The object whose actionPerformed method is
invoked is not responsible for deciding whether, when, or why the
actionPerformed method should be called. It is only responsible for behaving
appropriately when the event handler method is called.
We can build an action listener by providing a class that implements this
interface. The implementation of actionPerformed in this class is an answer to the
question, "What should I do when an action is performed?"
public class FieldHandler implements ActionListener {
private TextField whichText;

public FieldHandler( TextField whichTextToHandle )

{
this.whichText = whichTextToHandle;
}

public void actionPerformed( ActionEvent ae ) {

Console.println( "Hello, " + this.whichText.getText() );
}
}

This class actually keeps track of which TextField it wants to associate itself with.
We can create a particular FieldHandler associated with nameText using the
construction expression
new FieldHandler( nameText )
Now, when this FieldHandler's actionPerformed method is invoked -- when the
action happens -- the FieldHandler will use nameText's getText() method to print
a greeting to Galadriel.
Of course, we might want to hang on to that FieldHandler once we've created
it....It will come in handy in another few paragraphs.

16.2.3 Registering Listeners

So far, so good. However, we haven't specified how the FieldHandler gets
notified about the event in the first place. Of course, part of the story is that Java's
event manager identifies that a carriage return has been hit in the TextField and
generates an appropriate ActionEvent. But this event happens to the TextField;
how does the FieldHandler get hold of it?

The answer is that Java needs to be notified that the FieldHandler is interested in
this TextField's action events. To return to our earlier analogy, the FieldHandler
needs to subscribe to the TextField's action event clipping service.

IPIJ || Lynn Andrea Stein

16~10 Event Delegation and java.awt Chapter 16

This is accomplished with the TextField's addActionListener method, which

takes an ActionListener as an argument. The addActionListener method tells
Java that the ActionListener argument addActionListener is wants to know
about any ActionEvents that occur to this TextField. For example,
ActionListener nameHandler = new FieldHandler( nameText );
nameText.addActionListener( nameHandler );2

registers the actionListener called nameHandler as a listener for any

ActionEvents that occur to nameText.

Now, when Galadriel finishes typing, an action event will not only be generated
but also forwarded to nameHandler to handle.

16.2.4 Recap
The code that creates this situation is distributed over the paragraphs above. Here
is the entire setup code. It might, for example, appear in a main method or in the
constructor of an entity that provided the name-greeting behavior described at the
beginning of this section.
// Set up the TextField.
TextField nameField = new TextField( "Type your name here" );
nameField.setEditable( true ); // Allows user typing.
nameField.selectAll(); // Highlights current text.

// Now create and register the ActionListener

ActionListener nameHandler = new FieldHandler( nameText );
nameText.addActionListener( nameHandler );

// Finally, create a Frame around the TextField.

new DefaultFrame( nameField );

The only additional code required is the FieldHandler definition:

public class FieldHandler implements ActionListener {
private TextField whichText;

public FieldHandler( TextField whichTextToHandle )

{
this.whichText = whichTextToHandle;
}

public void actionPerformed( ActionEvent ae ) {

Console.println( "Hello, " + this.whichText.getText() );
}
}

2
or simply nameText.addActionListener( new FieldHandler( nameText ) );

IPIJ || Lynn Andrea Stein

16.3 Specialized Event Objects 16~11

16.3 Specialized Event Objects

In Galadriel's example, we encountered an object whose type was ActionEvent. It
appears as a parameter in the actionPerformed method of ActionListener. In that
example, we blithely ignored the ActionEvent -- as one often does in an action
Performed method -- but this begs the question of what that object is and why it
appears. In this section, we'll look at ActionEvent and other similar event objects,
and explore cases in which these event objects have important roles to play.
In the previous chapter, we looked at an event handler method called paint. That
method needed to be supplied with a fairly specific kind of object, a Graphics,
before it could do anything. In contrast, other handler methods of the previous
chapter -- such as handeTimeout() and handleReset() -- needed no arguments at
all. The event handlers in this chapter do need some information, but that
information is of a fairly generic (though specializable) type. The information
supplied to one of these AWT event handlers is a special Java object called an
AWTEvent. Such an object inherits from java.awt.AWTEvent (which is itself a
java.util.EventObject). The subclasses of java.awt.AWTEvent live in a
separate package, called java.awt.event.
In a general GUI, what kinds of things can happen? The mouse can be moved and
clicked and dragged, the keys can be pressed, windows can be closed, menu items
can be selected, text can be entered, and many, many more things can happen. A
listing of the major event types used in this book may be found in the AWT Quick
Reference appendix in the AWT Events segment. For example, a mouse click
generates a MouseEvent, while clicking in the close box of a window generates a
WindowEvent and clicking a button (or typing return in a text field) causes an
ActionEvent.

Some kinds of events, like ActionEvents, are notable mostly for happening. For
example, when a Button is clicked, an ActionEvent is generated. If you know
what Button was clicked to generate the ActionEvent, you really know
everything worth knowing about the ActionEvent. (If you don't know what
Button was clicked, you can find out by asking the ActionEvent; see below.) An
ActionEvent is also generated when the return key is typed in a TextField (as we
have seen), indicating that the text is complete. In this case, you need to know
both which TextField and, perhaps, what text was typed. But once you know what
TextField generated the ActionEvent, you can ask the TextField for its text. So
the internal structure of an ActionEvent is not likely to be of much interest.
Different kinds of events have methods that provide access to the different kinds

IPIJ || Lynn Andrea Stein

16~12 Event Delegation and java.awt Chapter 16

of information that you'd want if you were dealing with a mouse click or a
window close. These event methods are summarized in the AWT Events segment
of the appendix AWT Quick Reference. For example, a MouseEvent has a few
methods that are especially worth noting. If the MouseEvent is labeled mickey,
then

• mickey.getX() returns an int specifying the mouse's location at the time

of the MouseEvent (in pixels starting at the upper left-hand corner of
mickey's screen-space). .

• mickey.getY() similarly returns mickey's y coordinate.

• If you prefer to get both coordinates at once, you can retrieve a

java.awt.Point object using mickey.getPoint().

Every AWTEvent also has a getSource() method. This method returns the Object
to whom the event happened. For example, we could have replaced the
actionPerformed method of our FieldHandler class with the definition
public void actionPerformed( ActionEvent ae ) {
TextField theField = (TextField) ae.getSource();
Console.println( "Hello, " + theField.getText() );
}
This text uses the TextField that is the source of the action event, rather than the
TextField that is handed to the FieldHandler constructor, as the target of the
getText() method.3
Some AWTEvents, such as MouseEvent, are ComponentEvents. Every
ComponentEvent also has a getComponent() method that returns the same thing
as its getSource() method, but typed as a Component.
A variety of useful event types and their methods are documented in the AWT
Events segment of the AWT Quick Reference appendix.

3
In this case, we could simply eliminate the constructor, making the FieldHandler definition look
like this:
public class FieldHandler implements ActionListener {
public void actionPerformed( ActionEvent ae ) {
TextField theField = (TextField) ae.getSource();
Console.println( "Hello, " + theField.getText() );
}
}

IPIJ || Lynn Andrea Stein

16.4 Listeners and Adapters: A Pragmatic Detail 16~13

16.4 Listeners and Adapters: A Pragmatic Detail

Every AWTEvent type has an associated Listener type.4 This means that when
the AWT event occurs -- the mouse is clicked or the key is pressed, etc. -- there's
a type of object equipped to handle that event. (Actually, MouseEvent is an
exception, as it has two associated listener types: MouseListener, which handles
clicks, entry and exit, presses and releases, and MouseMotionListener, which
handles drags and moves. Most event types only have one Listener.)

The ActionListener defined above will do the trick quite nicely for our
TextField. The ActionListener interface only had a single method to
implement. Other listener interfaces are more complex, though. For example, the
MouseListener interface defines five methods:
public interface MouseListener extends EventListener {
public void mouseClicked( MouseEvent mickey );
public void mouseEntered( MouseEvent mickey );
public void mouseExited( MouseEvent mickey );
public void mousePressed( MouseEvent mickey );
public void mouseReleased( MouseEvent mickey );
}
If you want to be able to respond to mouse clicks, you will need to implement a
class that has an appropriate mouseClicked method. But the
MouseMotionListener interface specifies a contract with five distinct methods. If
clicks are the only kind of MouseEvent that you want to respond to, it would be
rather annoying to have to implement each of the other four methods just to be
able to write the one (mouseClicked) that we need. Our class definition might
say
public class MouseHandler implements MouseListener {
public void mouseClicked( MouseEvent mickey ) {
// Interesting code goes here...
}
public void mouseEntered( MouseEvent mickey ) {}
public void mouseExited( MouseEvent mickey ) {}
public void mousePressed( MouseEvent mickey ) {}
public void mouseReleased( MouseEvent mickey ) {}
}
Not very concise or beautiful, but necessary if we are to implement the interface
directly. After all, an interface is a contract and implementing the interface means
fulfilling the whole contract, not just a part of it.

4
Except PaintEvent, which uses the mechanism described in the previous chapter rather than the
listener registration system described here.

IPIJ || Lynn Andrea Stein

16~14 Event Delegation and java.awt Chapter 16

To avoid this ugliness, java.awt.event gives us a more concise way of saying

the same thing. There is a class called MouseAdapter that implements
MouseListener, providing all of the (non-interesting but also non-abstract)
method bodies required. We can just extend MouseAdapter in our class,
eliminating the need to implement all of the extra (extraneous) methods:
public class MouseHandler extends MouseAdapter {
public void mouseClicked( MouseEvent mickey ) {
// Overrides MouseAdapter's mouseClicked method.
// Interesting code goes here...
}
}
Much nicer!
Each of the listener interfaces that declares more than one method has a
corresponding adapter class. These are listed in the AWT Listeners and Adapters
segment of the AWT Quick Reference appendix.

16.5 Inner Class Niceties

Let's return to the TextField handler class from the Galadriel example, above.
There are still some improvements in functionality that we can make.

We might, for example, make our own class -- our own specialized TextField --
that is born with its own FieldHandler:
public class HandledTextField extends TextField {
public HandledTextField() {
ActionListener nameHandler = new FieldHandler( nameText );
nameText.addActionListener( nameHandler );
}
}

Now each HandledTextField is born with its own FieldHandler. This is similar to
AnimateObject's creating its own AnimatorThread, rather than expecting someone
else to create the AnimatorThread on its behalf.
Using inner classes,5 we can make this innovation do even more work for us.
Inner classes are a relatively advanced feature of Java, and they add only to the
aesthetics of this program, not to its functionality. They do provide a little bit
more protection for code from unanticipated use, a feature that we can exploit.

5
See chapter 12 for details.

IPIJ || Lynn Andrea Stein

16.5 Inner Class Niceties 16~15

After all, a FieldHandler as we have defined it is not really of much general

interest. We can embed the definition of that class inside the HandledTextField
class definition, hiding it from the rest of the world and simultaneously taking
advantage of inner class's privileged access to their containing instance's state.
Using inner classes, we can write:
public class HandledTextField extends TextField {
public HandledTextField() {
ActionListener nameHandler = new FieldHandler();
nameText.addActionListener( nameHandler );
}

private class FieldHandler implements ActionListener {

public void actionPerformed( ActionEvent ae ) {

Console.println( "Hello, "
+ HandledTextField.this.getText() );
}
}
}

Since FieldHandler is defined inside HandledTextField, it has access to its

containing instance directly (through HandledTextField.this), and we can
eliminate the constructor argument (and the constructor itself!) for
FieldHandler. Pretty neat, huh?

Chapter Summary
• EventListeners are interfaces promising particular sets of event handler
methods. There are Listeners for groups of related AWT event types, such
as mouse motion events, in the package java.awt.event.

• That package also includes adapter classes to make implementing these

interfaces easier.

• Listeners are connected to AWT components using a component's

addEventClassListener() (registration) method.

• java.awt.AWTEvent and its subclasses are data repositories that record

relevant information about individual (GUI) events.

• Each event handler method takes one of these Event objects as an

argument, in much the same way that paint() requires a Graphics. Like

IPIJ || Lynn Andrea Stein

16~16 Event Delegation and java.awt Chapter 16

paint(), the event handlers of an EventListener are called by the system,

not by your code.

• Inner classes provide a nice way of packaging the definitions of subsidiary

classes (such as EventListeners) inside other class definitions.

Exercises
1. Define a class that implements java.awt.event.MouseListener and
extends the mouseClicked(MouseEvent) method by printing the
coordinates of the point on which the mouse had clicked. You may also want
to make use of the class java.awt.event.MouseAdapter. (Bonus: also print
the components of the previous mouse click.)

2. Now define a class that extends java.awt.Canvas and sends its mouse events
to your MouseListener.

3. Define a class that implements java.awt.event.WindowListener and

extends the windowClosing()method by printing "Nah, nah, you can't
kill me!" (Alternately, you can do the potentially more useful thing and (1)
call the object's dispose() method and (2) call System.exit(0).) What class
do you think would be useful when implementing WindowListener?

4. Define a class that extends java.awt.Canvas and looks like a (black and
white) Japanese flag, i.e., it has a circle at (100,100). Make the circle change
color when the mouse is over your Canvas. (Hint: mouse enter, mouse leave.)

IPIJ || Lynn Andrea Stein

appendices
 applets

About Applets
An applet is a piece of Java code that can be run under certain network
browsers (and appletviewer, a Java program). Applets are embedded in
html and invoked by viewing the page (or running appletviewer on the
page). Every applet extends java.applet.Applet, which in turn extends
java.awt.Panel. When an applet is invoked, an instance is created (i.e.,
its constructor is called). No arguments are supplied to the constructor;
instead, there is html syntax for providing parameters to applets. At applet
creation time, three methods are called in sequence:
1. the applet's constructor

2. the applet's public void init() method.

3. the applet's public void start() method.

Each of these is provided by java.applet.Applet, but can be overridden

by the subclass. The init method will be called exactly once. The start
method may be called repeatedly, e.g., each time the applet scrolls off of
and then back on to the page. Applets also inherit stop and destroy
methods (both public void, no parameters) which are called when the
applet temporarily disappears or is permanently removed, respectively. It
is conventional to start and stop any Threads that the applet uses in the
applet's start and stop methods. In this sense, start serves some of the

IPIJ || Lynn Andrea Stein

A~2 Appendices

role of public static void main( String[] ) in standalone Java

applications. (Other parts of that role may be played by init or even by
the constructor.)

The primary differences between applets and standalone applications are:

• An instance of the applet is always created, and its constructor,

init, and start methods are always run. (These are the only
things guaranteed to run, but both stop and destroy may also be
called.) In addition, because an Applet instance is a Panel
instance, a visible component is created, awt events are
(potentially) handled, etc.

• When a standalone application is invoked, only public static

void main( String[] ) (and code called by it) is run.

Other than this information, applets are largely outside the scope of this
course.

IPIJ || Lynn Andrea Stein

 Java.awt quick reference

• AWT Components

• Component

• Canvas

• Widgets and their Event Types

• Basic Widgets

• ItemSelectable Widgets

• Text Widgets

• Container

• Panel and Frame

• Dimension, Point, and Rectangle

• Graphics

• AWT Events

• ActionEvent and ActionListener

• AWT Listeners and Adapters

IPIJ || Lynn Andrea Stein

A~4 Appendices

AWT Components
An awt component is a visible gui entity. The root of the component
hierarchy is the class java.awt.Component.
The class java.awt.Component is abstract. Its methods include:

• public void paint( Graphics g), an event-handler method supplying

detailed instructions as to how to paint the Component.

• public void repaint(), a user-invoked method requesting a paint.

Specific widgets extending Component include

• Button, which has a label and can respond to being pressed.

• Label, a non-editable piece of text.

• TextField, a single line (potentially editable) text box.

• TextArea, a multi-line (potentially editable) text box.

• Checkbox, which can be checked or unchecked. If a Checkbox is part of

a CheckboxGroup, only one Checkbox in the CheckboxGroup may be
checked at any time.

• Choice, a popup menu, which contains a set of items. One of these items
may be seleted.

• List, a Component with multiple Strings, some of which are selectable.

Most of the activity of these widgets is accomplished through the use of
specialized event handlers, as described in the chapter on Event
Delegation.
Two other Components deserve special mention:

• Canvas, which does nothing by itself, but is often extended.

• Container, an abstract Component capable of holding other Components

inside it.
There are several varieties of Container, including

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~5

• Panel, an instantiable Container.

• Frame, a top level (outermost) Container

IPIJ || Lynn Andrea Stein

A~6 Appendices

Component
This abstract class is the root of the visible AWT classes. All of the other
classes extend it and inherit its methods. However, few subclasses rely on
the full generality of Component and most of these methods are unused in
most of Component's subclasses. If you want to exploit the behavior of
Component, it is common to extend Canvas, the generic instantiable
Component.
java.awt.Component

• abstract

• extends Object

• To cause the Component to be (re-)displayed on the screen, call its

repaint() method:

° public void repaint();

° public void repaint( long time );

° public void repaint( int x, int y, int width, int height );

° public void repaint( long time, int x, int y, int width, int height );

• To give instructions for how the Component ought to look when it is

time for it to appear, override its paint( Graphics g ) method:

° public void paint( Graphics g );

• Every Component that is not a Window is inside another, called its

parent:

° public Container getParent();

• If you want to know how big the Component is...

° public Dimension getSize();

• Component event types:

° public synchronized void addComponentListener(

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~7

ComponentListener l );

° public synchronized void addFocusListener( FocusListener l );

° public synchronized void addKeyListener( KeyListener l );

° public synchronized void addMouseListener( MouseListener l );

° public synchronized void addMouseMotionListener(

MouseMotionListener l );

° public synchronized void removeComponentListener();

° public synchronized void removeFocusListener();

° public synchronized void removeKeyListener();

° public synchronized void removeMouseListener();

° public synchronized void removeMouseMotionListener();

• Override these to specify a different size from the default for your
Component

° public Dimension getMaximumSize();

° public Dimension getMinimumSize();

° public Dimension getPreferredSize();

• Used for double-buffering:

° public Graphics getGraphics();

There are many, many other methods available in java.awt.Component.
However, the vast majority of these (and even several of the ones listed
here) are not relevant to the material covered in this book. Check the on-
line Java API documentation for details.

IPIJ || Lynn Andrea Stein

A~8 Appendices

Canvas
java.awt.Canvas
A Canvas is an instantiable Component. It has no additional behavior
beyond that inherited from Component. It is often extended and
customized, particularly by overriding its paint() method or supplying
specialized event listeners.

• extends Component

• public Canvas();

• Canonical usage:

• subclass Canvas, create instance of subclass, add this (subclassed)

Canvas to Container:
class SpecialCanvas extends Canvas{ ... }

• common to override paint()

• common to addMouse(Motion)Listener

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~9

Widgets and their Event Types

Button, Checkbox, Choice, List, TextArea and TextField, are each types of
GUI widgets. Each is a subclass of java.awt.Component and a member of
the package java.awt.
Component Name Description Main Event Generated

Clickable button with label. Clicking on this

java.awt.Button java.awt.event.ActionEvent
component generates an ActionEvent.

Label with on/off mark. Clicking this item

causes its state (checked/unchecked) to change.
java.awt.Checkbox java.awt.event.ItemEvent
If a Checkbox is part of a CheckboxGroup, at
most one Checkbox in the group can be selected.

Popup with a list of labels from which a single

java.awt.Choice java.awt.event.ItemEvent
item can be selected

java.awt.Label A non-editable text item. none

List of labels, each of which may be selected or

java.awt.List java.awt.event.ItemEvent
not. Clicking an item toggles (flips) its state.

java.awt.TextArea A multi-line text box. java.awt.event.TextEvent

Box into which a single line of text may be

java.awt.TextField typed. Hitting the return key causes an java.awt.event.ActionEvent
ActionEvent.

The major methods of each widget type are listed in separate sidebars, below.

IPIJ || Lynn Andrea Stein

A~10 Appendices

Basic Widgets
java.awt.Label

• constructors

° public Label();

° public Label( String text );

° public Label( String text, int alignment );

• alignment management: Symbolic constants and getter/setter for Label

text alignement

° public static final int CENTER, LEFT, RIGHT

° public int getAlignment();

° public synchronized void setAlignment( int alignment );

• text management: What should the Label say?

° public String getText();

° public synchronized void setText( String text );

• Canonical usage:

° create Label, add Label to Container:

Label l = new Label(text); container.add(l);
java.awt.Button

• constructors

° public Button();

° public Button( String label );

• label management: What text should appear next to the Button?

° public String getLabel();

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~11

° public synchronized void setLabel( String label );

• ActionListener management: Who needs to know when this Button is

pressed?

° public synchronized void addActionListener( ActionListener l );

° public synchronized void removeActionListener( ActionListener );

• Canonical usage:

° create Button, addActionListener to Button, add Button to

Container:
Button b = new Button(label); cb.addActionListener(listener);
container.add(b);

IPIJ || Lynn Andrea Stein

A~12 Appendices

Item Selectable Widgets

These widgets each contain multiple items, one or more of which may be
selected at any time. Each implements an interface specifying certain
behavior. The methods of this interface are not repeated for each of the
implementing classes below.
java.awt.ItemSelectable (interface)

• Listener management: Who needs to know when one of the items is

selected or deselected?

° public void addItemListener( ItemListener l );

° public void removeItemListener( ItemListener l );

• public Object[] getSelectedObjects; returns null if none currently

selected.

java.awt.Choice (a.k.a. dropdown list)

Has a set of indexed String items. Generates ItemEvents.

• implements ItemSelectable

• constructor

° public Choice();

• item management:

° public synchronized void add( String item );

° public synchronized void addItem( String item );

° public synchronized void insert( String item, int index );

° public synchronized void remove( String item );

° public synchronized void remove( int index );

° public synchrnoized void removeAll();

° public String getItem( int index );

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~13

° public int getItemCount(); returns how many there are currently.

• item selection management: Which item is currently selected?

° public synchronized void select( int index );

° public synchronized void select( String item );

° public int getSelectedIndex();

° public synchronized String getSelectedItem();

• Canonical usage:

° create Choice, add items to Choice (one by one), addItemListener

to Choice, add Choice to Container:
Choice c = new Choice(); /* repeatedly */ c.add( label );
c.addItemListener(listener); container.add(c);
java.awt.Checkbox
Has a label, a state (clicked or not), and possibly a CheckboxGroup.
Generates ItemEvents.

• implements ItemSelectable

• constructor

° public Checkbox();

° public Checkbox( String label );

° public Checkbox( String label, boolean state );

° public Checkbox( String label, boolean state, CheckboxGroup

group );

° public Checkbox( String label, CheckboxGroup group, boolean

state );

• label management: What text should appear next to the Checkbox?

° public String getLabel();

IPIJ || Lynn Andrea Stein

A~14 Appendices

° public synchronized void setLabel( String label );

• state management: True is checked, false is unchecked

° public boolean getState();

° public void setState( boolean state );

• group management: Is this checkbox part of a group of mutually

exclusive alternatives?

° public CheckboxGroup getCheckboxGroup();

° public void setCheckboxGroup( CheckboxGroup group );

• Canonical usage:

° create Checkbox, addItemListener to Checkbox, add Checkbox to

Container:
Checkbox cb = new Checkbox(label);
cb.addItemListener(listener); container.add(cb);

° OR create Checkbox in CheckboxGroup, addItemListener to

Checkbox, add Checkbox to Container:
Checkbox cb = new Checkbox(label, group);
cb.addItemListener(listener); container.add(cb);
java.awt.CheckboxGroup

• Not a Component!

° extends Object implements Serializable

• constructor

° public CheckboxGroup();

• Given a group, you can get the currently selected Checkbox:

° public Checkbox getSelectedCheckbox();

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~15

Text Widgets
These three widget types provide varying kinds of text display and editing.
TextField is by far the simplest, especially as it relies on ActionEvents
triggered only when editing is "complete", e.g., when the user hits return.
TextEvents allow finer-grained access to the user's editing.
java.awt.TextComponent
Parent class for TextArea, TextField; less commonly used directly.

• TextListener management: Who should listen to random text changes.

Note: it is more common to use an ActionListener with a TextField

° protected transient TextListener textListener;

° public void addTextListener( TextListener l );

° public void removeTextListener( TextListener l );

• Manipulating selected (highlighted) text:

° public synchronized String getSelectedText();

° public synchronized int getSelectionStart();

° public synchronized int getSelectionEnd();

° public synchronized void select( int startIndex, int endIndex );

° public synchronized void selectAll();

° public synchronized void setSelectionStart( int index );

° public synchronized void setSelectionEnd( int index );

• Basic text manipulation:

° public synchronized String getText();

° public synchronized void setText( String text );

• Where is insertion point?

IPIJ || Lynn Andrea Stein

A~16 Appendices

° public int getCaretPosition();

° public void setCaretPosition( int index );

• Can user edit text?

° public boolean isEditable();

° public synchronized void setEditable( boolean state );

java.awt.TextField
A single line of text, with facility for hiding (e.g., as password). Primary
event type is ActionEvent, not TextEvent.

• extends TextComponent

• constructors

° public TextField();

° public TextField( String text );

° public TextField( int columns );

° public TextField( String text, int columns );

• Size in columns, i.e., how wide can this line of text be. Note also
interacts with component size.

° public int getColumns();

° public void setColumns( int columns );

° public Dimension getMinimumSize( int columns );

° public Dimension getPreferredSize( int columns );

• If echoChar is set, text typed into the TextField will appear as echoChar.
This is useful if the information typed is secret, e.g., a password.

° public void echoCharIsSet();

° public char getEchoChar();

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~17

° public void setEchoChar( char echoChar );

° ActionListener is TextField's main event handler. It is triggered

when the return (or enter) key is pressed.

° public synchronized void addActionListener();

° public synchronized void removeActionListener();

• Canonical usage:

° create TextField with default size, addActionListener to TextField,

setEditable, add TextField to Container:
TextField tf = new TextField(columns);
tf.addActionListener(listener); tf.setEditable(true);
container.add(tf);
java.awt.TextArea
A full scrollable block of text. Inherits much of its behavior from
TextComponent.

• extends TextComponent

• constructors

° public TextArea();

° public TextArea ( String text );

° public TextArea ( int rows, int columns );

° public TextArea ( String text, int rows, int columns );

° public TextArea ( String text, int rows, int columns, int scrollbars
);

• Size in columns and rows, i.e., how wide and high can this block of text
appear. Note also interacts with component size.

° public int getRows();

° public void setRows( int rows );

IPIJ || Lynn Andrea Stein

A~18 Appendices

° public int getColumns();

° public void setColumns( int columns );

° public Dimension getMinimumSize( int rows, int columns );

° public Dimension getPreferredSize( int rows, int columns );

• Scrollbar appearance management:

° Public static final int SCROLLBARS_BOTH,

SCROLLBARS_HORIZONTAL_ONLY, SCROLLBARS_NONE,
SCROLLBARS_VERTICAL_ONLY;

° public int getScrollbarVisibility();

• Text management (beyond TextComponent's methods):

° public synchronized void append( String text );

° public synchronized void insert( String text, int index );

° public synchronized void replaceRange( String text, int startIndex, int

endIndex );

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~19

Container
This abstract class is the root of the parent (container) AWT classes. All of
the other container classes extend it and inherit its methods. Only classes
extending Container can be a parent to another Component.
Container has four important subclasses:

• java.awt.Panel is a generic instantiable Container. It provides no

additional functionality, but is often used directly or extended to create a
Container instance.

• java.applet.Applet is a specialized Panel that can be used inside an

applet viewer or web browser. See the appendix on Applets for further
information.

• java.awt.Window is a top level Container, i.e., a Container that does not

itself need to be Contained. However, Window contains no platform-
specific niceties (such as resizability), so it is rarely used directly.

• java.awt.Frame is a subclass of Window that is commonly used in its

place.

Java.awt.Container

• abstract

• extends Component and so inherits all of its methods

• protected Container();

• Contained Component management. Position is dictated by this

Container's LayoutManager. In this book, we stick to the default
LayoutManager.

° public void add( Component c );

° public void add( String name, Component c );

° public void add( Component c, int index );

° public Component getComponent( int index );

IPIJ || Lynn Andrea Stein

A~20 Appendices

° public Component getComponentAt( int x, int y );

° public Component getComponentAt( Point p );

° public Component getComponentCount();

° public Component[] getComponents();

° public void remove( int index );

° public void remove( Component c );

° public void removeAll();

° public void removeContainerListener( ContainerListener l );

• Special event handler:

° public void addContainerListener( ContainerListener l );

° public void removeContainerListener( ContainerListener l );

There are many, many other methods available in java.awt.Container as
well. Check the on-line Java API documentation for details.

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~21

Panel and Frame

A Frame is a top-level Window. A Panel is a generic Container. Every
component must be inside a Container except a top-level (Window)
Container such as a Frame.
java.awt.Frame

• extends Window

• implements MenuContainer

• constructors

° public Frame();

° public Frame( String title );

• The title is displayed on the Frame's titlebar:

° public String getTitle();

° public synchronized void setTitle( String title );

• Make the Frame as small as it can be while still holding all of its
contained Components

° public void pack(); inherited from Window

• Make the Frame visible:

° public void show(); inherited from Window

° public boolean isShowing(); inherited from Window

• Is the user allowed to resize the Frame?

° public boolean isResizable();

° public synchronized void setResizable( boolean resizable );

• What to do when you're done with the Frame and its contained
Components:

IPIJ || Lynn Andrea Stein

A~22 Appendices

° public synchronized dispose();

• Special event handler (includes window closing events)

° public synchronized void addWindowListener( WindowListener l

);

° public synchronized void removeWindowListener(

WindowListener l );

• Canonical usage:

° create Frame, create and add Components, add WindowListener,

pack Frame, show Frame
Frame f = new Frame();
Component c = new ComponentSubclass(); f.add( c ); /* repeat
this line */
f.addWindowListener( listener ); f.pack(); f.show();

° OR subclass Frame, create instance of subclass

java.awt.Panel

• extends Container

• constructors

° public Panel();

° public Panel( LayoutManager lm );

• Canonical usage:

° create Panel, create and add Components, add Panel to Container

Panel p = new Panel();
Component c = new ComponentSubclass(); p.add( c ); /* repeat
this line */
container.add( p );

° OR subclass Panel, create instance of subclass

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~23

Dimension, Point, and Rectangle

A dimension represents length and width; a point represents x and y
coordinates. A rectangle is represented in terms of its upper lefthand corner
and its height and width, i.e., combining a Point and a Dimension.
java.awt.Dimension

• Implements Serializable

• Constructors:

° Public Dimension();

° Public Dimension( Dimension d );

° Public Dimension( int width, int height );

• Publicly accesible fields (!!)

° Public int height;

° Public int width;

• A nicer way to access fields:

° Public Dimension getSize();

° Public void setSize( Dimension d );

° Public void setSize( int width, int height );

java.awt.Point

• Implements Serializable

• Constructors:

° Public Point();

° Public Point( Point p );

° Public Point( int width, int height );

IPIJ || Lynn Andrea Stein

A~24 Appendices

• publicly accesible fields (!!)

° public int x;

° public int y;

• A nicer way to access fields:

° public Point getLocation();

° public void setLocation( Point p);

° public void setLocation( int width, int height );

° public void translate( int x, int y );

java.awt.Rectangle

• extends java.awt.geom.Rectangle2D

• implements Serializable

• constructors:

° public Rectangle();

° public Rectangle( Dimension d );

° public Rectangle( int width, int height );

° public Rectangle( int x, int y, int width, int height );

° public Rectangle( Point p );

° public Rectangle( Point p, Dimension d );

° public Rectangle( Rectangle r );

° publicly accesible fields (!!)

° public int height;

° public int width;

° public int x;

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~25

° public int y;

• A nicer way to access fields:

° Public Dimension getSize();

° Public void setSize( int width, int height );

° Public void setSize( Dimension d );

° Public double getHeight();

° Public double getWidth();

° Public Point getLocation();

° Public void setLocation( int x, int y );

° Public void setLocation( Point p );

° Public double getX();

° Public double getY();

° Public Rectangle getBounds();

° Public void setBounds( int x, int y, int width, int height );

° Public void setBounds( Rectangle r );

• Geometric predicates:

° Public boolean contains( Point p );

° Public boolean contains( Rectangle r );

° Public boolean intersects( Rectangle r );

° Public boolean isEmpty();

• Geometric computations:

° public Rectangle intersection( Rectangle r );

° public Rectangle union( Rectangle r );

IPIJ || Lynn Andrea Stein

A~26 Appendices

Graphics
A Graphics is the "screen" object on which all primitive drawing takes
place. Graphics support a huge number of methods. You will almost always
use the Graphics passed into a paint method when it is invoked by Java.
java.awt.Graphics

• abstract

• extends Object

• constructor

° protected Graphics();

• Make pictures on this Graphics:

° public abstract void clearRect( int x, int y, int width, int height );

° public void draw3DRect( int x, int y, int width, int height, boolean
raised );

° public abstract void drawArc( int x, int y, int width, int height, int
startAngle, int arcAngle );

° public abstract boolean drawLine( int startX, int startY, int endX,
int endY );

° public abstract void drawOval( int x, int y, int width, int height );

° public abstract void drawPolygon( int[] xCoords, int[] yCoords,

int numCoords );

° public void drawPolygon( Polygon p );

° public abstract void drawPolyline( int[] xCoords, int[] yCoords,

int numCoords );

° public void drawRect( int x, int y, int width, int height );

° public abstract void drawRoundRect( int x, int y, int width, int

height, int arcWidth, int arcHeight );

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~27

° public abstract void drawString( String string, int x, int y );

° public void fill3DRect( int x, int y, int width, int height, boolean
raised );

° public abstract void fillArc( int x, int y, int width, int height, int
startAngle, int arcAngle );

° public abstract void fillOval( int x, int y, int width, int height );

° public abstract void fillPolygon( int[] xCoords, int[] yCoords, int

numCoords );

° public void fillPolygon( Polygon p );

° public abstract void fillRect( int x, int y, int width, int height );

° public abstract void fillRoundRect( int x, int y, int width, int

height, int arcWidth, int arcHeight );

• A Graphics draws in one color at a time. These methods access and

change the currently active Color:

° public abstract Color getColor();

° public abstract void setColor( Color color );

° public abstract void setXORMode( Color color );

• A Graphics displays text in one Font at a time. These methods access

and change the currently active Font:

° public abstract Font getFont();

° public FontMetrics getFontMetrics();

° public abstract FontMetrics getFontMetrics( Font font );

° public abstract void setFont( Font font );

• Copy whatever is on this Graphics to a new Graphics.

° public abstract Graphics create();

IPIJ || Lynn Andrea Stein

A~28 Appendices

° public Graphics create( int x, int y, int width, int height );

• Get rid of a Graphics you no longer need (only if you've created it!)

° public abstract void dispose();

• You can manipulate java.awt.Images; see the online documentation for

Java for details.

° public abstract boolean drawImage( Image image, int x, int y,

ImageObserver observer );

° public abstract boolean drawImage( Image image, int x, int y, int

width, int height, ImageObserver observer );

° public abstract boolean drawImage( Image image, int x, int y,

Color background, ImageObserver observer );

° public abstract boolean drawImage( Image image, int x, int y, int

width, int height, Color background, ImageObserver observer );

° public abstract boolean drawImage( Image image, int dx1, int dy1,
int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, ImageObserver
observer );

° public abstract boolean drawImage( Image image, int dx1, int dy1,
int dx2, int dy2, int sx1, int sy1, int sx2, int sy2, Color
background, ImageObserver observer );

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~29

AWT Events
There are many different kinds of events in the package java.awt.event. Each
is a subclass of java.awt.event.AWTEvent. It is unlikely that you would ever
need to create an awt event. Instead, you are likely to write Listeners that
handle these Events.
java.awt.AWTEvent
The most important method of the class java.awt.AWTEvent is

public Object getSource();

which returns the Object to which the event occurred. Because all other awt
events extend AWTEvent directly or indirectly, they, too, have getSource()
methods. Their getSource() methods will generally return a Component (or an
instance of one of its subclasses).
Other event objects with fields worth noting are summarized in the following
table:

Event Class Notable Event Methods

public String getActionCommand(); can be used to

disambiguate source.
ActionEvent
public int getModifiers(); indicates alt/ctrl/shift/meta
keys pressed

public Component getComponent(); same as

getSource(), but typed correctly
public Point getPoint();
public int getX();
public int getY();
MouseEvent public int getClickCount();
public boolean isAltDown();
public boolean isControlDown();
public boolean isMetaDown();
public boolean isShiftDown();
public int getModifiers();

ItemEvent public Object getItem(); returns selected item

public ItemSelectable getItemSelectable(); same as

IPIJ || Lynn Andrea Stein

A~30 Appendices

getSource(), but typed correctly

public int getStateChange(); returns
ItemEvent.SELECTED or DESELECTED

public Window getWindow(); same as getSource(), but

WindowEvent
typed correctly

public Component getComponent(); same as

ComponentEvent
getSource(), but typed correctly

public Component getChild(); who was added or

removed
ContainerEvent public Container getContainer(); who it was added
to/removed from. same as getSource(), but typed
correctly

ActionEvent and ActionListener

java.awt.event.ActionEvent and java.awt.event.ActionListener
Although ActionEvent does have some methods, it is most common simply
to register the occurence of an ActionEvent, especially if the
ActionListener is only listening to the ActionEvents of a single Component.
The ActionEvent's getSource() method can always be used to disambiguate
the source of ActionEvents if necessary.
The interface java.awt.event.ActionListener has a single method:

• public abstract void actionPerformed( ActionEvent e );

To handle the action events generated by a Button or TextField, you will
need to write a class that implements java.awt.event.ActionListener and its
actionPerformed method.

IPIJ || Lynn Andrea Stein

 Java.awt Quick Reference A~31

AWT Listeners and Adapters

An Adapter provides trivial implementations of its corresponding Listener's
methods. Generally, you should extend the Adapter class (if available) and
override any methods you wish to handle. If you will be overriding all of
the methods, you may wish to implement the Listener interface directly.
You must implement the interface directly in the cases where no adapter is
available.
All events are public abstract void.

Listener
Event Class Adapter Class Listener/Adapter methods
Interface
ActionEvent ActionListener -- actionPerformed( ActionEvent e );

mouseClicked( MouseEvent e );
mouseEntered( MouseEvent e );
mouseExited( MouseEvent e );
MouseListener MouseAdapter
mousePressed( MouseEvent e );
MouseEvent
mouseReleased( MouseEvent e );

mouseDragged( MouseEvent e );
MouseMotionListener MouseMotionAdapter
mouseMoved( MouseEvent e );

ItemEvent ItemListener -- itemStateChanged( ItemEvent e );

windowActivated( WindowEvent e );
Window gains focus, etc.
windowClosed( WindowEvent e );
successfully closed Window
windowClosing( WindowEvent e );
WindowEvent WindowListener WindowAdapter user requestedWindow close
windowDeactivated( WindowEvent e );
Window loses focus, etc.
windowDeiconified( WindowEvent e );
windowIconified( WindowEvent e );
windowOpened( WindowEvent e );

componentHidden( ComponentEvent e );
componentMoved( ComponentEvent e );
ComponentEvent ComponentListener ComponentAdapter
componentResized( ComponentEvent e );
componentShown( ComponentEvent e );

componentAdded( ContainerEvent e)
ContainerEvent ContainerListener ContainerAdapter
componentRemoved( ContainerEvent e)

FocusEvent FocusListener FocusAdapter focusGained( FocusEvent e );

IPIJ || Lynn Andrea Stein

A~32 Appendices

focusLost( FocusEvent e );

TextEvent TextListener -- textValueChanged( TextEvent e );

keyPressed( KeyEvent e );
KeyEvent KeyListener KeyAdapter keyReleased( KeyEvent e );
keyTyped( KeyEvent e );

IPIJ || Lynn Andrea Stein

 java charts

About Java Charts

These tables give literal specifications for different Java constructs. For example,
the Program File Chart lists exactly what things can be in a .java file, in what
order, and with what syntax. If your code doesn't match these specifications, it is
not legal Java and will not compile.1
See also Java Rules.

Contents
• Program File

• Interface Declaration

• Class Declaration

• Field Declaration

• Method Declaration

• Expressions

• Statements

• Disclaimers, Notes, Amendments, etc.

IPIJ || Lynn Andrea Stein

A~34 Appendices

Program File
A program file (.java) contains:

Optional: 0 or 1 occurences.

package packageName; If present, this file is a part of the package

named packageName and must appear in an
appropriately named sub-directory.

Optional: 0 or more occurrences.

Import statements do not affect visibility. They
serve only to allow more concise naming, i.e.,
elimination of packageName before a class or
interface name reference.

import importableObject may be either

importableObject; packageName.ClassOrInterfaceName or
packageName.
The first form allows ClassOrInterfaceName
to be used as a shorthand for
packageName.ClassOrInterfaceName ; the
second allows any (visible) names within
packageName to be used without explicitly
giving the packageName.

1 or more, but at most 1 may be public, and the

class (or interface)
name of any public class or interface must
definition(s)
correspond to the filename (without the .java)

IPIJ || Lynn Andrea Stein

Java Charts A~35

Interface Declaration7
Optional: 0 or 1.

If public, an interface name is universally

visible for use as a type. Otherwise, the interface
public name is only visible within this package.

Note that the file in which a public interface

InterfaceName is defined must have the name
InterfaceName.java

Exactly 1.
This name is a Java type that can be used
interface anywhere it is visible. If the class is defined in a
InterfaceName
package other than the default, its proper name
is packageName.InterfaceName, though this
may be abbreviated using import statements.

Optional: 0 or 1.
If present, this interface extends the specification
extends provided by OtherInterfaceName. Specifically,
OtherInterfaceName all methods and (static final) fields
specified by InterfaceName are required for
any instance implementing interface
InterfaceName.

Exactly 1, but body may be empty.

{ body } If not empty, body consists only of static final

field declarations and nonstatic abstract method
(signature) declarations.

IPIJ || Lynn Andrea Stein

A~36 Appendices Java Charts

Class Declaration7
Optional: 0 or 1.

If public, a class name is universally visible for

use as a type. Otherwise, the class name is only
public visible within this package.

Note that the file in which a public class

ClassName is defined must have the name
ClassName.java

Optional: 0 or 1.
final
If final, no subclasses of this class can be
defined, i.e., no other class can extend this one.

Optional: 0 or 1.

abstract If abstract, no instances of this class can be

created, i.e., new ClassName(...) is a (compile-
time) error.

Exactly 1.
This name is a Java type that can be used
class ClassName anywhere it is visible. If the class is defined in a
package other than the default, its proper name is
packageName.ClassName, though this may be
abbreviated using import statements.

Optional: 0 or 1.
If present, this class "inherits" implementation
from OtherClassName. Specifically, all non-
extends OtherClassName
private fields and methods defined for
OtherClassName are available to/through class
3
ClassName and its instances, unless they are
explicitly overridden.

IPIJ || Lynn Andrea Stein

Java Charts A~37

In this case, ClassName is said to be a subclass or

child of OtherClassName; OtherClassName is a
superclass or parent of ClassName.

Optional: 0 or 1 implements, followed by 1 or

more comma-separated InterfaceNames.
implements
InterfaceNameList If this declaration is present, ClassName must
provide implementations of each of the methods
declared for each InterfaceName.

Exactly 1, but body may be empty.

{ body } If not empty, body consists of members -- field,

method , constructor, and inner class declarations,
but no freestanding code. 2

IPIJ || Lynn Andrea Stein

A~38 Appendices Java Charts

Field Declaration4
Optional: 0 or 1.

If public, the field is visible and settable

everywhere, and inherited by all subclasses.
public
protected
If protected, it is visible and settable within the
private package but inherited everywhere.
If private, it is visble nowhere, nor is it inherited.
Otherwise, it is visible, settable, and inheritable
only within the package.

Optional: 0 or 1.

If static, the field belongs to the class (factory,

static
recipe) and not to its instances. In this case, it is
referenced as ClassName.fieldName rather than
through its instances.

Optional: 0 or 1.
final
If final, the field must be initialized at its creation
time, and its value cannot later be changed.

Exactly 1.
TypeName
May be a class or interface name, one of the eight
Java primitive types, or an array type.

fieldName Exactly 1.

Optional: 0 or 1.

= value If present, value be an expression assignable to

type TypeName. This is an initialization expression,
and it makes this declaration into a definition.

IPIJ || Lynn Andrea Stein

Java Charts A~39

; Exactly 1.

Method Declaration4
Optional: 0 or 1.

If public, the method is visible and callable

everywhere, and inherited by all subclasses.
public If protected, it is visible and callable within the
protected package but inherited everywhere.
private If private, it is visible nowhere, nor is it
inherited.
Otherwise, it is visible, callable, and inheritable
only within the package.

Optional: 0 or 1.

If static, the method belongs to the class

static
(factory, recipe) and not to its instances. In this
case, it is referenced as ClassName.methodName
rather than through its instances.

Optional: 0 or 1.

If abstract, the method body is replaced by a

semicolon (;) and the class is alsoabstract, i.e., it
abstract cannot be instantiated (used with new). The
final method body is typically defined in a non-
abstract (instantiable) subclass.

If final, the method must not be abstract and

may not be overridden (shadowed) in subclasses.

IPIJ || Lynn Andrea Stein

A~40 Appendices Java Charts

Optional: 0 or 1.

If synchronized, method cannot begin to

synchronized execute an exclusive lock has been obtained on
the containing object (i.e., the instance denoted
by this, for non-static methods, or the class,
for c methods).

Optional: 0 or 1.

native If native, the method is defined in a language

other than Java and hence outside the scope of
this course.

Exactly 1.

ReturnTypeName May be a class or interface name, one of the

eight Java primitive types, an array type, or the
special keyword void

methodName Exactly 1.

Exactly 1, but argument list may be empty.

Each ArgType may be a class or interface name,

one of the eight Java primitive types, or an array
type. When the method is invoked, arguments of
( ArgType argName, ... appropriate types must be supplied.
ArgType argName )
If there is more than one ArgType argName pair,
the pairs are separated by commas.
Parentheses must be present even if the
argument list is empty.

Optional: 0 or 1 throws, followed by 1 or more

throws comma-separated ExceptionNames.
ExceptionNameList
This declaration must be present if methodName

IPIJ || Lynn Andrea Stein

Java Charts A~41

or any method called by it might throw an

uncaught exception of type ExceptionName5

Exactly 1, but body may be empty.

{ body }
Body may contain one or more statement.
;
If braces and body are absent, aemicolon is used
insead and method is abstract.

Expression
Every Java expression has both a type and a value. A Java expression is made up
of exactly one of the following.

This is a literal expression. It represents a

literal literally-expressible value. It is of a primitive
type, String, or null.

This is a name expression. The type of this

expression is the type the name was declared
to have. Its value is the value stored in the
name corresponding shoebox or referenced by the
corresponding label. Name expressions
include fields, local variables, and
parameters as well as classNames.

This is an object self-reference expression.

It may only appear in non-static method or
field definitions.
this
This expression refers to the object whose
method is being executed (field is being
defined). Its type is the class of the object,

IPIJ || Lynn Andrea Stein

A~42 Appendices Java Charts

and its value is the object itself.

This is a parenthetical expression. It is used

( expression )
to disambiguate expressions by grouping
things together. Its value and type are the
same as those of the contained expression.

prefixOperator expression

expression
postfixOperator These are operator expressions. They
include unary operations such as - and ++,
expression1 infixOperator binary operations such as *, >, and =, and the
expression2
ternary conditional operator.
booleanExpression ?
expression1 : expression2

This is a cast expression. typeName is any

type name, including primitive type, class
name, interface name, or array type, but not
void. expression is any expression. The
( typeName ) expression parentheses are required.
The value of this expression is the value of
expression. The type of this expression is
typeName. (Not all cast expressions are
legal.)

This is a method invocation expression.

objectReferenceExpression is any
objectReferenceExpression expression whose value refers to an object.
. methodName ( argList ) argList is empty or a list of comma-
separated expressions. Parentheses must be
super . methodName (
argList ) present even if the argument list is empty.
Expression type and value are return type,
value of method.

objectReferenceExpression This is a field access expression.

IPIJ || Lynn Andrea Stein

Java Charts A~43

. fieldName objectReferenceExpression is any

super . fieldName expression whose value refers to an object.
argList is empty or a list of comma-
separated expressions.
The expression type is the declared type of
the field. The value of the expression is the
shoebox/ label value.

This is an instance creation expression.

ClassName is any class name. argList is
empty or a list of comma-separated
expressions. The parentheses must be
new ClassName ( argList ) present even if the argument list is empty.

The expression's type is ClassName. Its

value is a newly created instance of
ClassName.

This is an array access expression.

arrayExpression is any expression whose
type is an array type.integerExpressionis
arrayExpression [
an expression with intgral type.
integerExpression ]
If arrayExpression is of type type[], this
expression is of type type and its value is
that of the integerExpressionth shoebox or
label.

This is an array creation expression.

typeName is any type name, including
primitive type, class name, interface name,
or array type, but not void.
new typeName [
integerExpressionis an expression with
integerExpression ] integral type.

Expression type is typeName[], i.e., array of

typeName. Its value is a new array of
typeName, i.e., integerExpression

IPIJ || Lynn Andrea Stein

A~44 Appendices Java Charts

shoeboxes or labels suitable for typeName.

Statement
Java statements are executable code with neither type nor value. A Java statement
is made up of exactly one of the following (though its pieces sometimes contain
other statements).

This is an empty statement.

;
Executing it has no effect. Execution
continues immediately after this
statement.

This is a simple statement.

expression must be a side-effecting
expression, i.e., an assignment,
autoincrement, autodecrement,
method invocation, or new
expression ; expression.
This kind of statement simply
evaluates the expression and
terminates. Execution continues
immediately after this statement.

This is a block. statements is

simply a sequence of zero or more
statements, one after the other.
{
statements This kind of statement executes by
} executing each statement in
statements, in order. After it
completes, execution continues
immediately after the closing brace.

IPIJ || Lynn Andrea Stein

Java Charts A~45

This is a simple declaration.

A declaration statement is executed
6 by creating an association between
type name ; the name name and the type type for
the remainder of the execution of the
enclosing block. Execution continues
immediately after this statement.

This is a definition -- a declaration

coupled with an intialization
assigment.
6 The execution of a definition is
type name = value ;
identical to the execution of a
declaration except that the value
associated with name is initially set to
be value.

Executing a return statement has the

effect of exiting the innermost
return optionalExpression ;
enclosing method. If
optionalExpression is present, it is
evaluated and its value is returned by
the method invocation.

A synchronized statement executes

block. However, execution cannot
begin until the exclusive lock on the
synchronized ( objExpression )
block object whose value is
objExpression is held by the
Thread executing the synchronized
statement.

This is a simple conditional

if ( booleanExpression ) statement. booleanExpression is an
statement expression whose type is boolean.
statement is any statement, often a

IPIJ || Lynn Andrea Stein

A~46 Appendices Java Charts

block.
A conditional statement is executed
by first evaluating
booleanExpression. If its value is
true, statement is executed. If the
value of booleanExpression is
false, statement is not executed.
In either case, execution continues
immediately after this statement.

This is another form of conditional

statement. booleanExpression is an
expression whose type is boolean.
Both statement and
anotherStatement are arbitrary
statements. Often statement is a
block and anotherStatement is
another conditional statement
A conditional statement is executed
if ( booleanExpression )
statement
by first evaluating
else booleanExpression. There are two
anotherStatement possibilities
1. If the value of
booleanExpression is true,
statement is executed, then
execution continues after
anotherStatement.

2. If booleanExpression. is false,
execution skips statement and
continues at anotherStatement.

switch ( integralExpression ) A switch statement is a limited

{
case integralValue : contditional. integralExpression
default : is an expression with integral type
statement (i.e., byte, short, int, long,
} boolean, or char). Each

IPIJ || Lynn Andrea Stein

Java Charts A~47

integralValues is a constant
expression of the same integral type.
Any number of case
integralValue : and statement
lines, and at most one default:, can
be intermixed in any order in the
switch body.

A switch statement evaluates

integralExpression and compares
its valuewith the various
integralValues. When the first
matching integralValue is
encountered, the remainder of the
statements in the switch body are
executed. A default: matches any
value. Frequently, a break statement
is used to exit the switch body.
Typically, the format will be one or
more case lines followed by one or
more statements, often terminating in
a break statement. This structure will
then repeat. The final set of
statements will often be preceded by
default:

This is a while loop.

booleanExpression is an expression
whose type is boolean. statement is
any statement, frequently a block.
while ( booleanExpression ) A while loop is executed by first
statement
evaluating booleanExpression. If
its value is false, execution
continues after the while statement.
Otherwise, statement is executed
and then the while loop is executed
again from the beginning.

IPIJ || Lynn Andrea Stein

A~48 Appendices Java Charts

This is a do loop. statement is any

statement, frequently a block.
booleanExpression is an expression
whose type is boolean.
do A do loop is executed by first
statement
while ( booleanExpression )
executing statement. Next,
booleanExpression. is evaluated. If
its value is false, execution
continues after the do loop.
Otherwise the do loop is executed
again from the beginning.

This is a for loop. initExprs is a

comma-separated sequence of
expressions, typically one or more
definitions or other initializations.
booleanExpr is a single expression
of type boolean. updateExprs is a
comma-separated sequence of
expressions, typically assignments or
other updates.
for ( initExprs ; To execute a for loop, first evaluate
booleanExpr ;
updateExprs ) initExprs. These expressions are
statement evaluated only once, at the beginning
of the for loop.

Now evaluate booleanExpr. If its

value is false, the for loop is
complete; execution resumes after
the entire statement. Otherwise,
execute statement. Next, evaluate
updateExprs. Regardless of its
value, return to the beginning of this
paragraph (evaluate booleanExprs).

label : statement This is a labeled statement. label

may be any Java identifier. It does

IPIJ || Lynn Andrea Stein

Java Charts A~49

not interfere with variable scoping,

etc. statement may be any
statement, but is often a block or
block-containing statement.
A labeled statement is executed
exactly as though label were not
present, except that the position
within the code of the identifier
label is recorded. In particular, any
break or continue statements
appearing inside statement may
make reference to label. (See break
and continue statements in this
chart.)

If optionalLabel is present, this is

a labeled break statement; if it is
absent, this is an unlabeled break
statement.

A labeled break statement exits all

enclosing blocks until one whose
break optionalLabel ; label matches optionalLabel is
found. Execution resumes after that
block.

An unlabeled break statement exits

the innermost switch, while, do, or
for statement containing that break.
Execution resumes after that block.

The syntax of a continue statement

is identical to that of a break
statement. A continue statement
continue optionalLabel ; may only appear inside a while, do,
or for loop.

An unlabeled continue statement

exits the current iteration of the

IPIJ || Lynn Andrea Stein

A~50 Appendices Java Charts

innermost loop containing that

continue statement. Execution
resumes at the expression evaluation
(test) of while and do loops, and at
the update expression of a for loop.

A labeled continue statement exits

the current iteration of the enclosing
loop whose label matches
optionalLabel. Execution resumes
at the expression evaluation (test) of
while and do loops, and at the
update expression of a for loop.

Executing a throw statement has the

effect of exiting every enclosing
statement (including those containing
method invocations) until a try
throw expression ; statement with a catch clause
matching the thrown object (the
value of expression) is encountered.
Execution resumes at this catch
clause.

This is a try statement. tryBlock,

catchBlock, and finallyBlock are
each arbitrary blocks of statements.
type is any type that implements
Throwable; name is any Java name.
try
tryBlock The lines finally finallyBlock
catch ( type name ) are optional and may be omitted
catchBlock entirely. The lines catch ( type
finally name ) catchBlock form a catch
finallyBlock
clause. Each try statement may have
zero or more catch clauses (but
exactly one try and at most one
finally).

To execute a try statement,

IPIJ || Lynn Andrea Stein

Java Charts A~51

tryBlock is executed. There are

three possibilities:

1. If the execution of tryBlock

completes normally, then execution
continues at finallyBlock (if
present).

2. If a throw statement is
encountered during the execution of
tryBlock and the type of the thrown
object matches thetype of one of the
catch clauses, execution
exitstryBlock and continues in the
catchBlock of the first catch
clause whose type matches the type
of the thrown object. During
execution of catchBlock, name is
bound to the thrown object. After
completing this catchBlock,
execution continues at
finallyBlock (if present).

3. If execution of tryBlock is
interrupted for any other reason -- a
thrown object that doesn't match a
catch clause, a break or continue
statement -- execution exitstryBlock
and continues at finallyBlock (if
present). If execution of
finallyBlock completes normally
(or if finallyBlock is absent,
execution continues abnormally, i.e.,
as though finallyBlock had thrown
the object or raised the break or
continue. That is, execution
continues exiting blocks until the
throw, break, or continue is
resolved.

IPIJ || Lynn Andrea Stein

A~52 Appendices Java Charts

Disclaimers, notes, amendments, etc.

1
Well, OK, there are a few details left out of or glossed over in these charts, but
it's mostly true that these files specify legal Java.
2
Truth in advertising: A class body contains fields and methods only, no
freestanding code, except for static and instance initializers, which are outside the
scope of this course.
3
Strictly speaking, subclasses inherit non-private fields and methods only if
they are in the same package as their superclasses. If a subclass is in a different
package, it does not inherit fields and methods that are of default visibility either.
Additionally, constructor methods are never inherited directly (though they are
available through the super(...) construct).
4
Fields can also be transient or volatile. Methods can be native. These
keywords are outside the scope of this course.
5
Exceptions that are subclasses of java.lang.RuntimeException need not be
declared in the throws clause of a method.
6
An extended form of declarations and definitions allows multiple names to be
declared or defined with a single type. The format of this is type nameDecls;
where nameDecls is a comma-separated list of names or assigments.
7
These charts correspond only to top level class and interface declarations.
Member classes may also be static or not, public, protected, private or default.

IPIJ || Lynn Andrea Stein

 glossary
A
abstract method
A method with no body; a method signature followed by a semi-colon.
alternative
In a conditional statement, the optional sub-statement to be executed if the
boolean test expression's value is false.

applet
A Java program capable of running embedded in a web browser or other
specialized applet environment. Contrast application.
application
A Java program capable of running "standalone". Contrast applet.
animacy
A Java Thread that enables concurrent execution, e.g., of a self-animating
object. See the chapter on Self-Animating Objects.

animate object
See self-animating object.
array
A structure for holding many Things of the same type.
argument
A value supplied to a method when it is invoked. During the execution of the
method body, this value is named by the matching method parameter.

arithmetic operator

IPIJ || Lynn Andrea Stein

G~2 Glossary

An operator that computes one of the arithmetic functions. See the chapter on
Expressions.
assignment
The association of a name with a value. See the chapter on Things, Types, and
Names.

Also the operator in such an assignment. See the chapter on Expressions.

asterisk
* Sometimes called "star". Used to delineate certain comments and as the
multiplication operator.

B
backslash
\ Used in character escapes.
binary operator
An operator that takes two operands. See the chapter on Expressions.
binding
See name binding.
bit
A single binary digit.
bitwise operator
An operator that computes a bit-by-bit function such as bitwise complement.
See the chapter on Expressions.
block
A segment of code that begins with a { and ends with the matching }. See the
section on Blocks in the chapter on Statements.
body
The body of a method, class, or interface, i.e., either a method body, a class
body, or an interface body.

IPIJ || Lynn Andrea Stein

 G~3

boolean

A true-or-false value. In Java, represented by the primitive type boolean and

by the object type Boolean. See the sidebar on Java Primitive Types in the
chapter on Things, Types, and Names.
boolean expression

An expression whose type is boolean.

boot, boot up
Start up (a computer or program).
bottom-up design
An approach to design that starts with the simplest, most concrete things in
your system and proceeds by combining them.
brace
{ or } Used to enclose bodies or blocks.
bracket
[ or ] Used in array expressions.
bug
An error in a program. Contrast feature.

C
call
See invocation.
call path
The sequence of method invocation (instructions followed by a Thread) that
led up to the currently executing method body. Unless execution exits
abruptly, each of these invocations will return, one at a time, in this order,
along the reverse of the call path, i.e., the return path.
carriage return

IPIJ || Lynn Andrea Stein

G~4 Glossary

One of two line-ending characters. (The other is line feed.) So named after an
archaic device called a typewriter in whose early models the carriage (i.e.,
paper-bearing part) literally needed to be returned to the other side of the
typewriter at the end of each line.
case-sensitive
Distinguishing between upper and lower case letters.
cast expression
An expression involving a type and an operand whose value is the same as its
operand but whose type is the type supplied. Contrast coercion.
catastrophic failure
An exceptional circumstance so incapacitating that your program cannot hope
to prevent or deal with it. At this point, the only hope is in recovery.

catch statement
A particular kind of Java statement, typically used with exceptions, that
receives a thrown object. See the chapter on Exceptions.
character
A single letter, digit, piece of punctuation, or piece of whitespace. In Java,
represented by the primitive type char, using unicode notation, and occupying
sixteen bits, and by the object type Char. See the sidebar on Java Primitive
Types in the chapter on Things, Types, and Names.
character escape
A special sequence indicating a character other than by typing it directly.
Especially useful for non-printing characters, such as carriage return.
class
A (user-definable) type from which new objects can be made. See the chapter
on Classes and Objects.

class body
The portion of a class definition containing the class's members. The portion
of a class definition enclosed by { }. See the chapter on Classes and Objects
and the Java Chart on Classes.

IPIJ || Lynn Andrea Stein

 G~5

class object
The object representing the class itself, i.e., the factory. Itself an instance of
class java.lang.Class.
code
An excerpt from a program.
coercion
Treating an object of one type as though it were of another type. Contrast cast.
See the chapter on Expressions.
comment
Text embedded in a program in such a way that the Java compiler ignores it.
Intended to make it easier for people to read and understand the code.

comparator

An operator in an expression of boolean type.

compiler
The utility that transforms your Java code into something that can be run on a
Java virtual machine.
compount assignment
A shorthand assignment operator (or expression) that also involves an
arithmetic or logical operation.
concatenation
The gluing together of two strings.
condition
In a conditional statement, the boolean expression whose value governs
whether the consequent or the alternative is executed.
conditional
A compound statement whose execution depends on the evaluation of a
boolean expression. Consists of a condition, a consequent, and an optional

IPIJ || Lynn Andrea Stein

G~6 Glossary

alternative.
conjunction

The logical operator && (and).

concurrent
Literally or conceptually at the same time.
consequent
In a conditional statement, the sub-statement to be executed if the boolean test
expression's value is true.
console
See Java console.
constant

A name associated with an unchanging value. Typically declared final.

constructor
The code which specifies how to make an instance of a class. Its name
matches the name of the class. A constructor is a class member. See the
chapter on Classes and Objects.

D
data
Values, as opposed to executable code. Things that might be associated with
names such as variables, parameters, or fields. See also state.

data repository
A kind of object whose primary purpose is to store data. See the chapter on
Designing with Objects.
debug
To attempt to eliminate bugs from your program.
declaration

IPIJ || Lynn Andrea Stein

 G~7

A statement associating a name with a type. Once the name has been declared,
it can be used to refer to Things of the associated type. See the chapter on
Things, Types, and Names.
default value
The value associated with a name that has been declared but not assigned a(n
initial) value. See the sidebar on Default Initialization in the chapter on
Things, Types, and Names.

default visibility
Also called package visibility. The visibility level of an unmodified interface,
class, method, field, or constructor. Visible to only within the package.
definition
A statement that both declares and initializes a name. See the chapter on
Things, Types, and Names.
design
The process of figuring out what your program should do and how it should
accomplish it.

disjunction

The logical operator || (or).

dot
See period.
double precision floating point
A representation for rational numbers (and an approximation for real
numbers) that uses 64 bits of storage. In Java, implemented by the primitive
type double. See floating point.
down cast
A cast from superclass to subclass. May be invalid; should be guarded.

E
embedded

IPIJ || Lynn Andrea Stein

G~8 Glossary

The property of being in an environment (or system) and interacting with it.
entity
A member of the community. A conceptual unit consisting of an object or set
of objects that is (implicitly or explicitly) persistent and that interacts with
other entities.

environment
Where an entity is embedded. What the entity interacts with.
error checking
Code (often a conditional statement) designed to catch illegal values or other
potential problems, and to correct them, before or as they arise. A way to
avoid bugs in your program. An important part of design.
evaluate
To compute the value of an expression.
event
1. Something that happens.
2. A special kind of object used in event-driven programming to record the
occurrence of a particular event (in the conventional sense). See the chapters
on Event-Driven Programming and Event Delegation.
event-driven programming
A style of programming in which an implicit (often, system-provided) control
loop activates event handler methods when a relevant event occurs. See the
chapters on Event-Driven Programming and Event Delegation.
event handler
In event-driven programming, a method that is called when a relevant event
occurs. See the chapters on Event-Driven Programming and Event Delegation.

exit condition
The condition under which the repeated execution of a loop stops. Formally
called the termination condition for the loop.

IPIJ || Lynn Andrea Stein

 G~9

exception
A special kind of Java object used to indicate an exceptional circumstance.
Typically used in conjunction with throw and catch statements. See the
chapter on Exceptions.

execute
To follow the instructions corresponding to a statement or program.
expression
A piece of Java code with a type and a value, capable of being evaluated.
Contrast statement. See the chapter on Expressions.
extend
To reuse the implementation supplied by a superclass through inheritance.

F
factory
A class, metaphorically, for its instances.
feature
1. A deliberately designed and generally beneficial aspect of a program.
2. post hoc. A bug, when discovered by a user after it's too late to fix it.
field
A data member of a class, i.e., a name associated with each instance of a class
(if not static) or with the class object itself (if static). See the chapter on
Classes and Objects.

field access
An expression requiring an object and a field name. Its type is the declared
type of the field and whose value is the value currently associated with that
field.
floating point
A representation for rational numbers (and an approximation for real

IPIJ || Lynn Andrea Stein

G~10 Glossary

numbers) that uses 32 bits of storage. In Java, implemented by the primitive

type float. Contrast double precision floating point.
footprint
See method footprint.

G
getter, getter method
A method that exists solely to provide read access to a field. Formally called a
selector.
global variable
A term with no meaning in Java.
graphical user interface
A user interface that makes use of windows, icons, mouse, etc., and is
typically implemented in an event-driven style. Sometimes abbreviated GUI.
guard expression
A test that prevents execution of a potentially dangerous statement.
GUI
An acronym for graphical user interface.

H
hyphen
- Used as the unary and binary subtraction operator and to indicate negative
numbers.

I
identifier
The formal term for a name.
idiot proofing

IPIJ || Lynn Andrea Stein

 G~11

A not very tactful name for error checking, especially as concerns interaction
with the user.

if, if/else

Java's conditional statement.

implementor
The 1. person or 2. entity that provides the implementation for an interface or
contract.
implementation
Executable code. Also "how to".
incremental program design
The design-build-test-design cycle in which every attempt is made to keep the
program working at all times and to make only minor modifications between
tests.
inheritance
The process by which one class shares the definition and implementation
provided by another. Uses the Java keyword extends. See the chapter on
Inheritance.
initialization
The assignment of an initial value to a name or, by extension, to an object's
fields.
instance
An object created from a class, whose type is that class. See the chapter on
Classes and Objects.
instantiate
To create an instance from a class, typically through the use of a constructor
(and new).
instruction follower
The thing that executes statements. In Java, a Thread.

IPIJ || Lynn Andrea Stein

G~12 Glossary

instructions
Code, generally statements, explaining how to do something. Followed step
by step by an instruction follower.
integer type

In Java, one of byte, short, int, long, char, or boolean. Expressions of

these (and only these) types may be used as the test expression of a switch
statement.

interface
1. The common region of contact between two or more entities.
2. (Java) A formal statement of method signatures and constants defining a
type and constraining the behavior of objects implementing that interface.

See the chapter on Interfaces.

interface body
The portion of an interface definition containing the interface's members. The
portion of an interface definition enclosed by { }.

invocation
To call a method, i.e., execute its body, passing arguments to be associated
with the method's parameters.

J
Java console
A place in every Java environment from which standard input is read and to
which standard output is written. I/O to the Java console is provided by
cs101.util.Console, java.lang.System.in, and java.lang.System.out.

jelly
An exceedingly sticky concoction made from the juice of a fruit, often a
grape, ideally purple. See also peanut butter.

K
keyword

IPIJ || Lynn Andrea Stein

 G~13

A word with special meaning in Java. All Java keywords are reserved, i.e.,
cannot be used as Java names.

L
label name
A name capable of referring to something of an object type, i.e., anything not
of a primitive type. See the chapter on Things, Types, and Names.
left-hand side
In an assignment, the expression representing the shoebox or label to which
the value is assigned.

literal
A Java expression to be read literally, i.e., at face value. Only the primitive
types plus strings have corresponding literal expressions. See the sidebar on
Java Primitive Types in the chapter on Things, Types, and Names.
local
Another term for a variable. Short for local variable.
local variable
The formal term for a variable.
logical operator
An operator that computes an arithmetic function such as conjunction or
disjunction. See the chapter on Expressions.
loop
A construct by which a sequence of statements is executed repeatedly,
typically until some exit condition is met.

M
member
A constructor, field, or method of a class. Alternately, a (static) field or
(abstract) method of an interface. Also member (inner) classes or interfaces.
See the chapter on Classes and Objects.

IPIJ || Lynn Andrea Stein

G~14 Glossary

method
An executable class member. Consists of a signature plus a body (unless
abstract). When a method is invoked on an argument list, the body is
executed with each of the method's parameter names bound to its
corresponding argument.

method body
The portion of a method that contains executable statements. When a method
is invoked (on a list of arguments), its body is executed within the scope of the
parameter bindings, i.e., with the parameter names bound to the corresponding
arguments.
method footprint
The name plus the ordered list of parameter types of a method. An object may
have at most one method with any particular footprint. Contrast method
signature. See the chapter on Interfaces.
method invocation
See invocation.
method overriding
When a subclass redefines a method or field that would otherwise be inherited
from its superclass.
method overloading
When one object has two or more methods with the same name (but different
footprints), typically performing different functions.
method signature
The specification of a method's name, ordered list of parameter types, return
type, and exceptions, possibly including modifiers. Contrast method footprint.
See the chapter on Interfaces.
modifier

A formal Java term such as abstract, final, public, static,

synchronized, etc., which is used in the definition of a class, interface, or
member. See the Java Charts for details.

IPIJ || Lynn Andrea Stein

 G~15

mutator
The formal name for a setter method.

N
name
A Java expression that refers to a particular object or value. Examples include
variables, parameters, fields, class names, and interface names. Every name
has an associated type (fixed when the name is declared). Within its scope, the
name is generally bound to a value (of the appropriate type). See the chapter
on Things, Types, and Names.
name binding
The association of a name with a value, typically through assignment or
through parameter binding during method invocation. The details of this
association depend on whether the name is a shoebox name or a label name,
i.e., of primitive or object type.
no-args
Taking no arguments or, more properly, having no parameters.
null

A Java keyword. The non-value with which an unbound label name is

associated.

null character
The character with unicode number 0. Not to be confused with the non-value
null.

O
object

A non-primitive, non-null Java Thing. An instance of (a subclass of)

java.lang.Object.

object type
In Java, any type other than one of the eight primitive types. All object types
are named by label names.

IPIJ || Lynn Andrea Stein

G~16 Glossary

operand
One sub-expression of an operator expression. See the chapter on Expressions.
operator
The part of an operator expression that determines the particular relationship
of the operands to the expression's value. See the chapter on Expressions.
operator expression
An expression involving an operator (e.g., +) and one or more operands.
Typically, the value of the expression is a particular function of the operands,
with the operator specifying what function. See the chapter on Expressions.

overriding
See method overriding.
overloading
See method overloading.

P
package
1. A named group of Java interface and class definitions.
2. The default visibility level of an unmodified interface, class, method, field,
or constructor. Visible only within the package(1).
paper
An archaic but amazingly persistent storage medium made of wood pulp.
Reported continually over the last half-century to be destined for imminent
obsolesence with the incipient advent of the paperless office. Sometimes used
with a typewriter.
parameter
A name whose scope is a single invocation of the method to which it belongs.
Declared in the method signature. When the method is invoked on a list of
arguments, each parameter is bound to the corresponding argument prior to
(and with scope over) the execution of the method body.

IPIJ || Lynn Andrea Stein

 G~17

parameter binding
The form of name binding that occurs when a method is invoked on a list of
arguments. Each of the method's parameters is bound to the corresponding
argument, i.e., the first parameter to the first argument, etc.
peanut butter
A gooey brown paste made by grinding up a certain legume, often consumed
with jelly between two slices of very bland white bread.
period
. Sometimes also called "dot". Used in method invocation and field access
expressions, package naming, and as a decimal point.

persistent
Existing even when not currently the subject of the coder's or computer's
attention.
pointer
A term with no meaning in Java.
postfix
Coming after.
prefix
Prior to.
primitive type

In Java, one of byte, short, int, long, float, double, char, or boolean.
All primitive types are named by shoebox names. See the sidebar on Java
Primitive Types in the chapter on Things, Types, and Names.
private

A Java keyword. A class or interface member declared private is visible only

within the body of its defining class or interface.
program
n. A collection of executable code. The how-to instructions that a computer

IPIJ || Lynn Andrea Stein

G~18 Glossary

follows.
v. To compose a program. See also incremental program design, debug.
programmer
A person who develops (designs, writes, debugs, modifies) a program.
programming language
A language in which one writes a program. For the purposes of this book,
Java.
protected

A Java keyword. A class or interface member declared protected is visible

within its package and within any class (or interface) that extends (or
implements) its containing class (or interface).
public

A Java keyword. An interface, class, method, field, or constructor declared

public is visible everywhere.

Q
R
read, read access
Interacting with a name by obtaining its associated value, or with an object by
reading the value(s) of one or more of its fields.
recipe
The instructions for how to do something. A class is a recipe for the behavior
of its instances. A constructor is the recipe for how to make an instance of its
class.
recovery
Also recovering from error. What a program ought to do after something has
gone wrong; patch things up as well as possible and move on. If things are
disasterous enough (e.g., after a catastrophic failure), this can be a significant
task. It is facillitated by design that anticipates the need for eventual recovery.

IPIJ || Lynn Andrea Stein

 G~19

reference type
The formal term for the types named by a label name.
reserved word
A word that cannot be used as an identifier in Java, typically because it is a
keyword.
resource library
A class that exists to hold methods that don't logically belong to any particular
object, or other (typically system-wide) resources. Typically not an
instantiable class. See the chapter on Designing with Objects.

return
A statement whose execution causes normal termination of the execution of a
method body. If the return statement contains an expression, its type must
match the return type of the method. In this case, the expression is evaluated
prior to exiting the method body and the value of this expression is the return
value of the method invocation.
return path
See call path.
return type
The type of the value returned by a method invocation. The first item in a
method declaration.
return value
The value returned by a method invocation.
rule
A proto-method. Consists of a specification and a body. See the chapter on
Statements and Rules.

rule body
The set of statements detailing how a rule is to be accomplished. A proto-
method body. See the chapter on Statements and Rules.

IPIJ || Lynn Andrea Stein

G~20 Glossary

rule specification
The information needed and provided by a rule. A proto-signature. See the
chapter on Statements and Rules.

S
scope
The expanse of code within which a name has meaning, i.e., is a valid
expression. See the note on Scoping in the chapter on Expressions. Not quite.
selector
The formal name for a getter method.
self-animating object
An object or entity with its own animacy, i.e., one that runs concurrently and
persistently. See the chapter on Self-Animating Objects.

setter, setter method

A method that exists solely to provide write access to a field, i.e., to change its
value. Formally called a mutator.
shared reference
A situation in which two label names refer to the same object.
shoebox name
A name capable of referring to something of a primitive type, whose value is
encoded directly in the memory reserved by the name. The types named by
shoebox names are formally called value types. See the chapter on Things,
Types, and Names.

side effect
A change to something that occurs as a consequence of evaluating an
expression. For example, an assignment.
signature
See method signature.

IPIJ || Lynn Andrea Stein

 G~21

slash
/ Used to delineate comments and as the division operator.
software
Another term for computer program.
standard input
The stream which reads from the Java console. Bound to
java.lang.System.in.

standard output
The stream which writes to the Java console. Bound to
java.lang.System.out.

state
What is true of a program or entity at a specific time. Especially the current
set of associations of values with names.

statement
A piece of executable Java code. Has neither type nor value. Contrast
expression. See the chapter on Statements and Rules.
static
A modifier indicating a member of a class (rather than of its instances).
stream
A persistent Java object which permits the reading or writing of multiple
sequential values. Represents a connection to another (potentially non-Java)
entity. Used for input or output.

string

A sequence of characters. In Java, represented by the object type String.

Although there is no primitive type representation of strings in Java, they are
described in the sidebar on Java Primitive Types in the chapter on Things,
Types, and Names.

subclass

IPIJ || Lynn Andrea Stein

G~22 Glossary

A class that inherits from another, i.e., extends that other. Contrast
superclass. See the chapter on Inheritance.
superclass

A class that is inherited from by another, i.e., the other extends the
superclass. Contrast subclass. See the chapter on Inheritance.

T
target
In a method invocation expression, the object whose method it is.
termination condition
The formal name for an exit condition.
test
1. A crucial part of program development in which program behavior is
exercised in an attempt to find failures, or bugs.
2. In a conditional statement, another name for the boolean expression known
as the condition.
Thing
The nouns of Java, including Things of primitive type and objects. See the
chapter on Things, Types, and Names.
this

A Java (label) name that is bound to the current instance. Because it refers to
an instance, static members are outside of its scope .

throw statement
A particular kind of Java statement, typically used with exceptions, that
causes an object to be thrown and thereby circumvents the typical return
trajectory. See the chapter on Exceptions.

throws clause
The part of a method signature which specifies any exceptions thrown by that
method. See the chapter on Exceptions.

IPIJ || Lynn Andrea Stein

 G~23

top-down design
An approach to design that starts with the highest level, most abstract, or
largest things in your system and proceeds by decomposing them.
top level
Immediately inside the containing structure. Top level within a class means
inside the class body but not inside any other structure.
trinary operator
An operator that takes three operands. See the chapter on Expressions.
type
A partial specification of the Thing. In Java, a type is either a primitive type or
an object type. See the chapter on Things, Types, and Names.
type-of-thing name-of-thing rule
The rule that says: to declare a name, first state its type, then state its name.
typewriter
An archaic device vaguely resembling a keyboard attached directly to a
printer with no intervening memory. Requires paper.

U
unary operator
An operator that takes one operand. See the chapter on Expressions.
unbound
The state of a label name when it is not associated with an object, i.e., has no
object referent. In this case, the label name is associated with the non-value
null.

unicode
The representation used by Java for characters.
up cast
A cast or coercion from subclass to superclass. Always valid.

IPIJ || Lynn Andrea Stein

G~24 Glossary

user
1. A human being, with respect to a computer program.
2. A piece of code, with respect to another piece of code, especially an
interface. Contrast implementor.

user interface
The portion of a program with which a (human) user interacts. See also
graphical user interface.

V
value
Either a primitive value or an object.
value type
The formal term for the types named by a shoebox name.
variable
A Java name that has scope only from its declaration to the end of the
enclosing block. Variables are formally called local variables; sometimes, this
is abbreviated to locals.

virtual field
A piece of state within an object that is not stored directly as a field, but is
instead calculated using the values of other fields of the object. Must be
accessed using a getter method as there is no field to read directly.
virtual machine
The utility that actually runs your (compiled) Java program.
visibility
Whether a class, field, method,field, or constructor can be used by a particular
piece of code. Visibility levels include private, protected, default (or package),
and public.
void

IPIJ || Lynn Andrea Stein

 G~25

The return type of a method whose invocation does not return anything.
Contrast null.

W
white bread
A substance resembling styrofoam, but with less taste and texture. Generally
available in uniform white squares with pale brown edges, called crusts, that
must be removed before serving to small children. Useful mostly to keep the
peanut butter and jelly from getting on your fingers.
write, write access
Interacting with a name by changing its associated value, or with an object by
changing the value of one or more of its fields.

X
Y
Z

IPIJ || Lynn Andrea Stein