Software Design (CSC-223 97F)
Outline of Class 6: Review
- Reminder: if I'm going to fast, or too slow, let me know (in person,
via email, whatever).
- I've noticed some problems with understanding of Java's model, so
we'll go over it in a little bit more depth today.
- Charles Jepsen will be giving a talk at the Mathematics Journal Club
Thursday in room 2413 at 4:30 pm on Equisum Sets.
Food is available in room 2400 at 4:14 pm.
- Note that I'm really skimming over much of Java. I assume that as
good students, you can read up more on particular features in the
various references available to you. Learning how to read references
is a skill you'll need to develop at some point in your career, so it
might as well be now. We'll still need to spend a
little more time on Java than I'd originally planned.
- The next assignment will probably be ready tomorrow. I'll email you
when it's written.
- Some of you have found the
second assignment quite hard. Not because it's conceptually hard,
but because you're having trouble making the leap to Java's program
model. This was, of course, the intent of the assignment (to help
you make that leap).
- Don't forget about the lunchtime curriculum discussion tomorrow.
Those of you planning next year's schedule should certainly come and
here about our new offerings.
- Java's model of what a program is differs significantly from that
of the languages you've learned in the past (or at least from those
of Scheme and Pascal).
- In Java, a program is a collection of independent "actors" each
of which knows how to do certain things, has certain properties, and
may communicate with other actors.
- These actors are the classes and objects of your program.
- The things an actor knows how to do are its methods.
- Data pertainent to the actor are represented by its
- How does this differ from traditional procedural programming? In
a number of ways.
- You should try to model your algorithms in terms of
communicating objects, rather than functions that call
- You need to remember that, in general, you will be telling
your objects to do things to/with themselves, rather than telling
the system as a whole to do things to/with your objects. For
example, instead of saying "add two objects", you would tell
one object to add another object to itself.
- Instead of one mammoth program, you'll have a number of smaller
class definitions, each in its own file.
- Your programs should be more "modular" in that you will have
developed a number of independent (or partially independent) actors.
- However, the Java interpreter still needs to know where to "start"
setting up and manipulating the actors. Your
serves this purpose.
- Java carefully distinguishes between the objects we create and the
variables that refer to them.
- Each object occupies some area of memory. This area holds the
fields of the object and additional information to help the system
decide which method to execute.
- Instead of containing objects, variables hold references
- We usually indicate this visually by drawing an arrow from a
variable's name to the object it refers to.
- These references are essentially the same as pointers,
except that you may be more limited in what you can do
- Because variables hold references, and not objects, it is possible
for more than one variable to refer to the same object. A change
through variable will be to the underlying object, so the change
will be observable through all variables.
- Because variables hold references, and not objects, it is necessary
to create new objects when we want independent "values" for our variables.
This is why we use the
new operation in conjunction with
- When you pass objects to methods, you are, in effect, passing
references to those objects. This means that if a method modifies
one of its parameters, it will modify it globally, and not just in the