CISC 370 Lecture Notes for Class No. 6, February 24, 2000

Reminder

Definitely consider doing a team project. Discuss possible ideas with several of your classmates to see if you can find a partner with similar interests and compatible knowledge and work habits.

Graded Assignment #4

Reading:

Horstmann & Cornell, chap 6 up to p. 213, that is to the section "Interfaces and Callbacks"

Exercises:

1. Alter the stick figure demo program so as to add a right leg to the figure.

To prepare programming assignments for submission, do the following for each exercise.

script	        // Produces a file named typescript
whoami 
date 
pwd 
cat *.java 
javac *.java     // mainFile should be the name of the file containing
java mainFile    // your main() method
exit		 // to exit script

Now print the typescript file for submittal at the beginning of lecture and email a copy to the Sivaram at burra@cis.udel.edu.

Today's Lecture Topics

1. If you are having difficulty with the object-oriented concepts now is the time to clarify any puzzling aspects of Java and OOP. Come to my office hours, 1:30-3PM on Weds (or make an appt for another time), or see Sivaram during his office hours, 10-12 Noon on Mondays. Come with as questions that are as specific as possible. Put question marks in the margin of the text where you do not understand and ask Sivaram or me about them.

   We have been moving quickly through the parts of Java that are similar to the C++, a prerequisite for this course. It is imperative that you work diligently to keep up with the assigned reading and that you attend lectures regularly.

2. Last lecture the static method Complex.read() was not implemented. All the code in the directory CISC370HOME/exampleprogs/complexNumbers/ should be working now.

3. Homework solution .

4. Question re protected access and why the protected clone() method of the class Object must be made public if all classes are derived from the class Object and derived classes have access to protected methods. This is a thoughtful question. It is addressed very directly in Arnold and Gosling, The Java Progamming Language, 2nd edition in Section 3.2 entitled "What protected Really Means."

   Here is the explanation. While it is true that every derived class can access protected components of a parent class this cannot be done in a completely unfettered way. There are some additional restrictions. Access restrictions occur when two different classes are derived directly from a common parent so that the inheritance tree has two or more branches emanating from a common parent and the common parent has an entity that is protected. For example, suppose we have the following class hierarchy (this example is taken from The Java Programming Language, pp. 63-64).

                               Dessert
                                 /\  protected int calories
                                /  \
                               /    \
                             Cake  Scone
                              |
                              |
                        ChocolateCake
        

   The calories field in the Dessert class is protected. Each class that extends Dessert inherits its calories field. However, code in the Cake class can access the calories field only through a reference of type Cake or a subclass of Cake like ChocolateCake. Code in the Cake class could not access the calories field via a reference of type Scone. Cake code cannot even reference calories via a more generic Dessert reference, but you could cast such a reference to a Cake reference and use the result--assuming, of course (and this is an important point), that the object being referenced really was (at least) a Cake.

   A protected method, class, or interface is treated in the same way.

   However, protected static fields, methods, classes, and interfaces can be accessed in any extended class. If calories were a static field, any method--static or not--in Cake, ChocolateCake, or Scone could access it.

   In the situation we were discussing in lecture last time, we had the inheritance tree

                              Object
                                /\ protected clone()
                               /  \
                              /    \
                          Complex ComplexTester
        

   In the class ComplexTester, we had an instance of the class Complex that we wished to clone. The implementation of the clone() method in Object was sufficient for the task, but for the reasons explained above, we are unable, in ComplexTester, to invoke the protected clone method of Object via a reference to a Complex object. (that is, we cannot make references horizontally in the diagram).

   To make this possible, in the code for Complex, we override the clone() method of Object with a public method that simply calls the clone() method of Object. Since the clone() method of Complex is public, it can be invoked from any other code via a Complex reference.

   By the way, the two definitive references on the Java language (as opposed to the Java virtual machine and the JDK) are The Java Programming Language, referenced above and Gosling, Joy, and Steele, The Java Language Specification. Both are published by Addison Wesley.

5. An example that uses an interface, inheritance and polymorphism.

   We wish to be able to draw simple figures using characters (instead of pixels that are used for real graphics). For an example, execute the Java program in CISC370HOME/example-progs/sg-demo/Demo.java . This demo program makes use of a package, called sg (sg = Simple Graphics) that is found in the directory CISC370HOME/example-progs/sg/. This package is intended to mimic some of the ways that graphics is done in the java.awt.* package which we will study soon in some detail. There is also documentation for the package that was generated by the javadoc tool and a diagram of the relationships among the various classes.

   The documentation was generated by executing the following command while in the example-progs/sg directory.

        javadoc -private -d ../sg-docs *.java
        

   To learn more about the javadocs tool, navigate to the Java tools documentation by clicking on the Gen'l Docs link in the navigation bar at the top of this page and then follow the SDK tools link.

   To learn more about the exact format of the documentation generated by javadoc, see pp. 201-203 of the Horstmann & Cornell text.

6. Usage of the sg package

   You should be able to use this package by including

        import sg.*;
        

   in your applications file. If this does not work, make sure that you have the directory $CISC370HOME/example-progs in your CLASSPATH. Also, it is NOT recommended to put any file that makes use of the sg package in the same directory with the sg package. Put your application code in another directory.

   You may be wondering exactly what the purpose of a package is. When developing large programming systems, one normally imports code written by others, for example, another person in the development team, existing code developed for other projects in your own company or university, or, increasing often, code for objects that has been developed by others and is obtained over the internet. In such situations, name collisions are likely. If you name a class "BankAccount," there is a good chance that somebody else will use the same name for another class. Sooner or later the two classes will collide in the same process, wreaking havoc. Programmers who begin to use the Java(tm) programming language learn to use packages to prevent name collisions. Instead of naming a class "BankAccount," you place the class in a package, perhaps naming the class something like com.develop.bank.BankAccount (that is, the reverse of your domain name). Hopefully there is minimal danger of a name collision with this approach.
   (Most of the material from the above paragraph was taken from the SUN Microsystes JDC Tech Tips of Oct 31, 2000.)

7. Class Design Hints (from H&C, pp. 159-161)
   • Always keep data private.
   • Always intialize data.
   • Don't use too many instance variables in a class. Group related variables into another class.
   • Not all fields need accessors (getters) and mutators (setters).
   • Use a standard form for class definitions. H&C suggest putting the contents of classes in the following order:

               public features
               package scope features
               private features
               

     And within each section, use the order

               constants
               constructors
               methods
               static methods
               instance variables
               static variables
               

   • Break up classes with too many responsibilities.
   • Make the names of your classes and methods reflect their responsibilites.

     Use noun-like names for classes and interfaces (i.e., Employee, ContainerEvent, IndexOutOfBoundsException, Serializable), verb-like names for methods (i.e., draw(), readObject(), getColor(), setColor(), processMouseEvent()).

Back to the CISC 370 homepage.

This page has been accessed times since 23 Feb 2000.

Copyright 2000 B. F. Caviness