Held Wednesday, October 13, 1999
Overview
Today, we will return to our consideration of the project. In addition
to considering details of various classes, we will talk about some
details of Java and continue our narrative.
Notes
- By 9 a.m. of the Wednesday after break, I expect the following:
- Well designed interfaces for each class you expect to create.
- A stub class for each interface.
- These should compile.
- Are there questions on the exam?
Contents
Handouts
Summary
- General notes on what you turned in
- Some notes on Java
- Protection levels
- Static methods
- Interfaces, stubs, and testing
- Preconditions and postconditions
- Project narrative, continued
- Using the
Photo class
- Using the
Options class
- Please refer to My general notes
- I expected:
- Polished interfaces
- With clear documentation
- And consideration of how others might use your class
- I generally got:
- Barely-considered classes
- That rarely compiled
- To say the least, I'm less than thrilled.
- Note that I've modified some of your code files so that they will compile.
- You may want to grab the updated versions.
Here are a few questions to get us started thinking about the
relationship of classes. There will be more.
- One of the user interface classes is ready to display the inbox
using the user's preferences as to ordering. (It has the list of
messages, but not the preferences nor the ordering information).
What does it do? What do the classes it calls do?
- The user updates this information. What happens?
- The user is ready to compose a reply. What does the GUI class
do behind the scenes?
- Since most groups will have to depend on other groups for support,
it is important that you have usable (but not necessarily working)
versions of the files from those groups.
- I'd like each group to work out a ``stub'' implementation so
that the classes that rely on you can have something happen.
- It is also important that each file have a contact person who you
can contact for information.
- I will keep the project files in
http://www.math.grin.edu/~rebelsky/Courses/CS152/99F/Project/".
You can copy them from there.
- The sample classes I've received have suggested that it's time to
talk about two topics in Java that have received short shrift:
protection levels and static methods. We'll also talk a little
bit about using ``stub classes''.
- One of the goals of object-oriented design is information
hiding: the clients of your class (that is, the other
classes and programs that use your class) should only know
a limited amount about your class.
- You might also want to restrict what they can do with your
class.
- Java will enforce some mechanisms for information hiding if you
give it information about what you want hid. You do this by
writing a protection level before your field, class,
method, and constructor definitions.
- There are approximately four levels of protection:
-
public elements can be used by anything else.
-
private elements can only be used directly by
members of the same class (not even members of subclasses).
-
protected elements can only be used directly
by members of the same class, members of subclasses, and
other objects in the same package.
- unspecified elements have ``package protection''.
They can only be accessed by other elements of the same package.
- What is a package? It's a way of grouping classes and
saying ``these classes are more trusted than other classes''.
We won't be using packages in 152.
- Let's take a look at the
Photo
class. What methods should be private, public, protected?
- Some of your methods won't use the fields of your objects, either
directly (by referencing the field) or indirectly (by using a
method that uses the field).
- For example, the
parseInt method of the
Integer class should not require an
Integer, since it doesn't look at the current
value but just converts a String to an int.
- In such cases, you don't really need an object. We call methods that
don't need fields or object methods static methods or
class methods.
- To tell Java that something is a static method, you write
static before the name of the method.
- You can then call the method with
ClassName.method.
- You can also make fields static.
- At times, you'll want to test your class with some associated
classes, but the associated classes won't be ready yet.
- In such situations, you typically use stub classes:
classes that provide the same apparent functionality, but
without the same implementation.
- If you use interfaces to generalize the capability of these
classes, it's easier to use a stub class during testing.
- If you write your classes so that constructors take objects as
parameters, it's easier to pass in stub classes during testing.
- Let us return, temporarily, to the issue of information
hiding.
- If your clients don't know how your methods or your classes
work, they need precise specifications of what your methods do.
- In contract-based programming, the author of a method
specifies what must hold before the method is called (other
methods that need to have been called, legal parameter values,
etc.) and what will hold after the method is finished.
- That is, every method needs preconditions (holds before)
and postconditions (holds afterwards).
- Some advocates of contract-based programming state ``If the
preconditions don't hold, the method can do anything
(including crash and burn).''
- Others find that this attitude does not cohere with ideas of
exception-based programming or robustness.
- There are some things that you can't test beforehand. (``The
server must be up.'')
- There are some times that it's wasteful to require the client
to test. (``The comparator must be able to compare any two
elements of the list.'')
- Hence, some people (including myself) believe that methods might
still be required to behave predictably, even if the
preconditions are not met.
- Most typically, the method will throw an exception if preconditions
are not met.
- Some object that this may lead to duplicated work: the client verifies
that the preconditions are meth and then the method does the same
verification.
- They also note it's not always that methods are ``predictable''.
Consider an array in which every element can be compared to some
other elements, but not every other element. Some of the time, sorting
will throw an exception. Other times, it won't.
- I'll admit that I prefer the somewhat practical:
- Preconditions are things that let us guarantee that the
method will work correctly. The method might still work correctly
even if not all the preconditions hold.
- Postconditions are things that must hold afterwards, as long
as no exception is thrown.
- Methods throw exceptions if they observe that they can't
meet postconditions. (Preferably, if they can't meet
postconditions.)
- The client can decide whether or not to check the postconditions.
- Here's one that I'd have trouble deciding on.
/**
* Pick a value between 1 and 10, using a helper array.
* Pre: All the values in the array are between 1 and 10
* Pre: The array is nonempty.
* Post: Returns a value between 1 and 10
*
* @exception ArrayIndexOutOfBoundsException
* if the array is empty
*/
- Suppose the client uses an array with values outside the valid
range. Do we want to require that the method returns a number
within the valid range or simply some value in the array?
- Of course, this example could be improved by using better preconditions
and postconditions.
/**
* Pick a value from an array.
* Pre: The array is nonempty.
* Post: Returns a value that appears in the array.
*
* @exception ArrayIndexOutOfBoundsException
* if the array is empty.
*/
- Let's consider the preconditions and postconditions for the
Network.java class.
- In our narrative, we were up to the stage that we'd filtered
the message list and were ready to display it.
- We'll back up a little bit and talk about filtering again and
then continue with other stuff.
Tuesday, 10 August 1999
- Created as a blank outline.
Monday, 11 October 1999
- Filled in the details. Most were copied from the previous outline.
- Added the notes on preconditions and postconditions.
Wednesday, 13 October 1999
- Added some introductory notes.
Back to Sorting Indexed Collections.
On to The Design of Lists.