| Chap | Assignment |
Std
Docs |
Documentaion Conventions
The following documents were lifted from standard conventions for the Spring 2003 course, Computer Science 110:
Introduction to Programming at Java Kalamazoo College.
It is expected that the work of students of Computer Science 202 will conform to these conventions.
|
BlueJ
![[Home of BlueJ]](../../gifs/bluej.gif) |
BlueJ Integrated Development Environment
BlueJ is an IDE created explicitly for learning OOP with Java.
Students must prepare to learn with the BlueJ IDE. First, do The BlueJ Tutorial. The tutorial explains how to download, install and use the BlueJ IDE.
BlueJ is a special Java IDE that was developed and maintained by a joint research group at
Monash University, Melbourne, Australia, and the
Mćrsk Institute at the
University of Southern Denmark for the explicit purpose of learning
to program in Java generally, and for learning object oriented programming (OOP) in Java in particular.
The most important thing that distringuishes BlueJ from other Java IDEs is that you may "directly interact with
single objects of any class and execute their public methods. This is very helpful during development of an
application - you can test classes individually as soon as they have been written. There is no need to write the
complete application first." [quoted from The BlueJ Tutorial, page 8]
|
GUI |
Graphical User Interface Programming
Segue to OOP
This is the beginning of Computer Science 202. Experience has shown that you will need to be comfortable with
SWING's GUI components so that you can later focus on learning to understand and compose your own OOP programs.
During the initial two weeks of this course, students are required to first navigate their way through an easily
understood set of tutorials for learning the basics of Java's AWT (Abstract Windowing Toolkit) and SWING classes that
enable a GUI interface in Java are chapters 55-64 of Kjell's Introduction to Computer Science Using Java. Students should save the most recent version
on their computer in case the site is down or the Internet slow when you wish to use it.
There is a quiz for each Kjell Tutorial, chapters 55-64 that you will write.
One site that gives a marvelous feat at clarifying Java code with diagrams and tables is the
Markus Falkhausen Java Site.
In the late 1970's a computer was developed that revolutionized the way we do input and output. That computer
was the Xerox Star, developed during the 1970's at Xerox Parc in California. The engineers from Apple Computer
saw, then studied, and then copied the interface of the Xerox Star. In 1984 Apple released their first Mac
personal computer which was essentially a clone of the Xerox Star. Some years later MicroSoft also copied the
GUI interface of the Xerox Star and called it "Windows".
The Java programming language has libraries of classes that allow the Java programmer to do GUI input and output
using windows (Java calls them "frames"), dialog boxes, buttons, sliders, and other GUI "components".
It is expected that students taking further Computer Science courses at Sir Winston Churchill will use a GUI
interface for doing input and output. It is fun to create GUI interfaces. It is easier for users to "talk"
with a program that has a GUI interface. Virtually all commercial and professional programs on the market
today use a GUI interface. GUI interfaces are the most familiar applications of OOP (Object Oriented
Programming) techniques that most students have seen. These are all good reasons to use GUI interfaces.
Do Chapters 25 and 55-64 of the Kjell Course. |
|
Audio |
Sun MicroSytems has a wonderful array of resources for teaching Java, including their
Technology Audiocasts
that deliver technology tutorials in MP3 and RealAudio formats as well as corresponging pdf files. One audiocast
is the Intro To SWING Audiocast.
This 40 minute presentation uses language that is unfamiliar to most
students at the Computer Science 202 level, but only by reaching for what is over our head can we hope to pull
ourselves up. You will remember what you now hear, even if you won't completely understand it at this point. But
by hearing and thinking about formerly unfamiliar ideas and processes, you will be able to draw upon current
efforts when, in the future, you go after the ideas from a different angle with different resources.
|
Litvin |
Gary and Maria Litvin, authors of Advanced Placement computer science text books, created
powerpoint slide shows for their textbook,
Java Methods, An Introduction to Object-Orient Programming. Note that this particular
chapter, numbered 15, is late in their text book and, in any case, assumes that students have progressed
through the earlier 14 chapter. Thus the slide show refers to concepts that Computer Science 101 students are
not yet aware of or comfortable with. That said, take a peek at
Litvin's GUI Components and Events. Much of their
"advanced" material will by now be familiar.
|
GUI
Code |
Graphical User Interface
In Computer Science 201 you were given the following short examples of the Java's SWING GUI classes. They are
reproduced here so that you may again refer to them as you prefer. Use the following snippets of code as models for
various components. They are taken from the book, Java: Your Visual Blueprint for Building Portable Java Programs.
|
GUI COMPONENTS
|
EVENT HANDLING
|
|
MEM |
Java's Memory Model
Review Java's Memory Model with the powerpoint slide show, Truth or Consequences A Discussion of Java’s Memory Model
|
Main |
Should every class have a main method?
|
A 'main' method does not have a good justification in the OO universe. Its existence is caused by a technical requirement
(to somehow link your application to the operating system's invocation mechanism) and not by the object-oriented model that
an application represents."
As such, it is different from the model part of the application and, in the name of cohesion, should be textually separated.
It is clearer and more logical to pull main out into a separate class with its own declared purpose: to start up the application,
And nothing else." -- Michael Kölling [SMTP:mik@mip.sdu.dk], quoted November 12, 2003
|
|
On all of my production software projects I require the inclusion of a "static void main" method in every class. That method
is used for the purposes of testing. It means that we can test every class in the product simply and independently. The only
exceptions are those classes for which "main" is used as the product's "startup". Note that we do this even though we also use
JUnit and have unit testing classes for every class as well.
I don't see this as violating abstract data typing, information hiding, or encapsulation. Rather, I see it as good software
engineering practice. -- Dr. Jody Paul [SMTP:jody@acm.org], quoted November 12, 2003
|
|
Some people use the fact that a public static void main method can be included in any class as a way of building some test code
right into the class. This use of main is not the client code that uses the class, but special test code that is used to test
when the class is developed. Then write a separate driver class that would use the class.
If the main within the class is intended as a driver, that diverges from the principles of O-O and information hding.
-- Chris Nevison [SMTP:chris@cs.colgate.edu], quoted November 12, 2003
|
|
Laziness is one (poor) reason to put the main in a class. The main program in Larry's example program below
certainly does violate the principles of encapsulation and data hiding, just as he says. Putting the main
method for an application in a separate class that represents the application as a whole is a clean design
choice.
Some people, though, put a main method in each class for testing purposes, and this is certainly a defensible
design choice. The main method in this case just runs through a series of test cases to test every method in
the class (using objects and proper encapsulation). I have occasionally used this technique in the past,
although I am moving towards using JUnit instead. JUnit is free software that provides a simple technique for
generating and running a test suite. It makes regression testing easy, and the positive feedback from
successful regression tests actually encourages students to test as they make modifications.
--Alyce Brady, Kalamazoo College, quoted November 12, 2003
|
|
Object
Game |
Professor Joseph Bergin from Pace University in New York created this exercise for beginners of Object-Oriented Programming. It might be fun to try it at this beginning part of the course.
|
Abstract
Class |
What Is The Difference Between An Abstract Class & An Interface
A "new" Advanced Placement computer science teacher asked this question in December of 2004. If you too
wondered about this, check out the replies at How An Interface Differs From An Abstract Class
|
CRC
Cards |
CRC (Class-Responsibility-Collaboration) Cards
If time permits, it should be fun to experiment with CRC (Class-Responsibility-Collaboration) Cards, an activity used by a
number of computer programming teachers throughout North America. The following links explain and implement this learning
strategy.
|
OOP
Basics
 |
Object-Oriented Language Basics
The following series of articles by Jeff Friesen were published in Java World during 2001. Students who find our textbook treatments to be stuffy and formal
may find Jeff's "hobby-geek" enthusiasm to be refreshing.
|
this |
this == instance variable
Read: How do college professors and text authors explain:
this?
|
static |
Using A Static Variable
Read: How do college professors and text authors explain:
a static variable?
|
8 |
Object-Based Programming
Assignments
Preview Fran Tree's powerpoint slide show Object Oriented Programming.
Do Kjell tutorials 25,
26,
27,
28,
29,
30,
31,
32,
33,
34A,
34B,
and 35
covering "Object Oriented Programming".
From Java By Example by Johannes Wallroth,
do the theory and examples of Section Five: Objects and Classes.
Overview the Chapter 8 PowerPoint Slideshow.
This just gives you the "lay of the land" for now. Later, after you read the chapter, this slide show will
be a very meaningful review.
Read the chapter actively! Execute and tinker with the code. Draw diagrams of concepts.
Implement and run the Chapter 8 source code.
-
Read the Optional Case Study (Thinking About Objects: Starting to Program the Classes for the
Elevator Simulation) (434-437)
Mentally review the "Self-Review Exercises" (440) (The section containing the answers to these
questions follow in the book itself.) This may easily alert you to potential holes in your knowledge
and skills.
Study the following practice exercises on the left to get a good feel for how to solve problems in this
chapter. Clicking on their links will present you with the publisher's solutions.
Then solve and submit solutions to exercises on the right that will be reviewed for grading purposes.
Pay special attention to the rational numbers exercise #8.03.
This is a classic problem that serves as an excellent model for how to develop a class. This model is used
in many textbooks to exemplify the construction of a class.
Note that this chapter requires that you develop separate classes of code that may be used by client
programs. You should therefore expect to develop at least two files for each exercise.
One file will contain the source code for the class itself. The other file will be a driver program that
uses and tests the features of the code generated by the class file.
WARNING: Work through some or all of the practice exercises before attempting exercises
to be submitted. Use the syntax and organization of the practice exercises as models. Failure to first
study the practise exercises will probably result in significant frustration!
Convention For Naming A Package: In Section 8.5 the Deitels remind us of Sun
MicroSystems' convention for naming a package of classes. Students at Churchill are asked to name their packages
starting with "swc" (Sir Winston Churchill High School), then an abbreviation of the course name
(eg: "cs202"), followed by the student's initials (eg: "gdd" for Gerry Douglas Donaldson), followed by the
author's name of the textbook being used ("deitel"), followed by a reference to the chapter and exercise
numbers ("c8e18"). Thus, the first statement of a file containing a "package" could be:
package swc.cs202.gdd.deitel.c8e18
Private or Protected:Protected in Java doesn't mean what it would mean
in most languages -- visible to objects of this class and its subclasses. Instead it means visible to objects of
this class, its subclasses, or any other class in the same package as this class. So, protected does NOT stop
unrelated classes from seeing specified fields and methods.
One of the best reasons for declaring variables(fields) to be private is quality assurance of the object. By
having the modifiers as provided by the original class writer can you assure yourself and your company that the
data portion of the object has not been modified in a way that was not specified in a software requirement document.
If you make the fields protected, then a writer of a subclass can develop their own methods that modify the field.
With private fields, once the class has been through your company's quality assurance/configuration management
software test process, the users (who are usually the owners of the data) can be assured that only the approved
methods for modifying their data are going to be used.
| Programming Exercises For Practice | Programming Exercises For Grades |
|---|
| 8.03: |
Create class to manipulate rational numbers. |
| 8.05: |
Error check initializer values. |
| 8.08: |
Use set and get methods to access and error check private variables. |
| 8.09: |
Set and check coordinates of rectangle class. |
| 8.19: |
Create a drawing applet that randomly draws lines, rectangles and ovals. |
|
| 8.12: |
Create class TicTacToe
|
In solving exercise 8.12, create the Tic Tac Toe grid without using a layout manager.
Instead use absolute positioning.
|
|
| 8.16: | Create class SavingsAccount |
| 8.17: | Create class IntegerSet
See a discussion of set theory. |
|
Include the following documentation for each exercise that is submitted to be graded.
You will want to read the first couple of chapters of an excellent online textbook,
Java An Object First Approach
to learn about some new techniques that are used to plan and document objects and programs.
List the specifications of the program. These may be deduced in the statement of the exercise.
Source Code of all new files: html file for applets, class file(s), driver program(s).
Print the source code and screen dump in a Word Processor, two pages per side, double sided.
Simultaneously pressing [Alt][PrtScn] will copy the GUI output to the clipboard from whence you
can paste it just below your source code. Use a non-proportional font (example: Courier New) to
maintain the vertical alignment of the stucture of your source code.
Screen Shots of Input and Output dialog boxes.
Where I/O (Input/Output) inlcudes multiple GUI (Graphical User Interface) dialog boxes, include at
least one screen shot for each input and output dialog box. Where there are various types of
dialog boxes and/or messages and/or types of data, include a "reasonable" number of screen shots.
Typically there will be 1-2 screen shots showing input and 1-2 screen shots showing output.
In extraordinary cases, there could conceivably be a dozen or more screen shots. What is "reasonable"
is the product of using reason (thought) and reasons (related information). BE REASONABLE!
Trace Table of Changes in Values of the Variables During Execution.
There will be a multiple choice test at the end of this chapter.
|
9 |
Object-Oriented Programming
Assignments
Do Kjell tutorials 50,
51,
52,
53,
and 54
covering "Advanced Object Oriented Programming".
For a fun, light explanation of polymorphism, check out How My Dog Learned Polymorphism at the Java Ranch where you will also find an interesting
example of polymorphism.
The references below refer to the 4th Edition of Deitel's Java How To Program because that is, in fact,
the textbook that our school purchased. However, since the Deitel 5th Edition powerpoint slideshows
and corresponding sample source code are available to us, we should overview the 5th Edition powerpoint slideshows.
Note that chapter 9 from the older 4th Edition was split into two chapters 9 & 10 for the 5th Edition.
Overview the Chapter 9 PowerPoint Slideshow.
This just gives you the "lay of the land" for now. Later, after you read the chapter, this slide show will
be a very meaningful review.
Read the chapter actively! Execute and tinker with the code. Draw diagrams of concepts.
Implement and run the Chapter 9 source code.
Read the Optional Case Study (Thinking About Objects: Incorporating Inheritance into the Elevator Simulation)
Note: The chapter 9 section of this case study in the textbook (Section 9.23 on pages 513-520) is the
prepublication version and was published in error. Click on either the foregoing or following link in this
paragraph for the corrected pdf version.
Mentally review the "Self-Review Exercises" (531) (The section containing the answers to these
questions follow in the book itself.) This may easily alert you to potential holes in your knowledge
and skills.
Professor Joseph Bergin of Pace University in New York is a brilliant computer scientist.
Read Joseph Bergin's four email discussions concerning polymorphism and how it relates to using inheritance versus an
interface to define classes and types. You may not understand the issues at this point, but Bergin's email discussions
will immediately expose you to some profound issues concerning computer programming languages. That in itself is a treat.
Volume 8, Issue 9 of the Java Developer's Journal had a really interesting article by Yakov Fain entitled
Are You Using Abstract Classes, Polymorphism and Interfaces?
Read it now with joy and comprehension. Play with the source code.
You will find a thread concerning Usefulness of Java Interfaces from the Java Ranch Big Moose Saloon to be interesting and clarifying of a number of points.
Study the following practice exercises on the left to get a good feel for how to solve problems in this
chapter. Clicking on their links will present you with the publisher's solutions.
Then solve and submit solutions to exercises on the right that will be reviewed for grading purposes.
Note that this chapter requires that you develop separate classes of code that may be used by client
programs. You should therefore expect to develop at least two files for each exercise.
One file will contain the source code for the class itself. The other file will be a driver program that
uses and tests the features of the code generated by the class file.
All classes must now be saved in a packaged named after the student's name. Remember that the
directories identified by the package will be automatically created during compilation. For example,
the first processing line of code in the source code of a class definition file might be:
package org.donaldson.gerry.jhtp4.ch09 ; // location of class definition file
A client program that imports a class might then have the following line near the beginning of the
source code:
import org.donaldson.gerry.jhtp4.ch09.* ;
| Programming Exercises For Practice |
Theory Exercises for Grades |
Programming Exercises For Grades |
|---|
| 9.10: |
Rewrite using composition instead of inheritance. |
| 9.11: |
Write with inheritance and again with composition. |
|
| 9.12: |
Does the subclass-is-a-superclass object relationship hold? |
| 9.13: |
Indicate common attributes and behaviors. |
| 9.14: |
Write an inheritance hierarchy. |
| 9.16: |
Give advantages to programming "in the general" with polymorphism rather than
"in the specific". |
| 9.17: |
Discuss problems of using switch logic. |
| 9.18: |
Distinguish "inheriting interface" from "inheriting implementation". |
| 9.19: |
Distinguish "abstract methods" from "nonabstract methods". |
| 9.20: |
Answer & explain: Must all methods in an abstract interface be declared abstract? |
| 9.22: |
How does polymorphism promote extensibility? |
|
| 9.15: |
Develop a shape class hierarchy. |
| 9.26: |
Write classes & a driver for the Shape class hierarchy. |
| 9.27: |
Rewrite Exercise 9.26 to use a Shape interface instead of an abstract Shape class. |
| 9.28: |
Modify Exercise 8.19 to create a drawing application. |
| 9.29: |
Change 9.28 single MyShape reference into an array of MyShape
references. |
|
Include the following documentation for each exercise that is submitted to be graded.
List the specifications of the program. These may be deduced in the statement of the exercise.
Source Code of all new files: html file for applets, class file(s), driver program(s).
Print the source code and screen dump in a Word Processor, two pages per side, double sided.
Simultaneously pressing [Alt][PrtScn] will copy the GUI output to the clipboard from whence you
can paste it just below your source code. Use a non-proportional font (example: Courier New) to
maintain the vertical alignment of the stucture of your source code.
Screen Shots of Input and Output dialog boxes.
Where I/O (Input/Output) inlcudes multiple GUI (Graphical User Interface) dialog boxes, include at
least one screen shot for each input and output dialog box. Where there are various types of
dialog boxes and/or messages and/or types of data, include a "reasonable" number of screen shots.
Typically there will be 1-2 screen shots showing input and 1-2 screen shots showing output.
In extraordinary cases, there could conceivably be a dozen or more screen shots. What is "reasonable"
is the product of using reason (thought) and reasons (related information). BE REASONABLE!
Trace Table of Changes in Values of the Variables During Execution.
There will be a multiple choice test at the end of this chapter.
|
10 |
Strings and Characters
Assignments
Overview the Chapter 10 PowerPoint Slideshow.
This just gives you the "lay of the land" for now. Later, after you read the chapter, this slide show will
be a very meaningful review.
Read the chapter actively! Execute and tinker with the code. Draw diagrams of concepts.
Implement and run the Chapter 10 source code.
Read the Optional Case Study (Thinking About Objects: Event Handling) (583-590)
Mentally review the "Self-Review Exercises" (594) (The section containing the answers to these
questions follow in the book itself.) This may easily alert you to potential holes in your knowledge
and skills.
Sudy the following practice exercises on the left to get a good feel for how to solve problems in this
chapter. Clicking on their links will present you with the publisher's solutions.
Then solve and submit solutions to exercises on the right that will be reviewed for grading purposes.
Note that this chapter requires that you develop separate classes of code that may be used by client
programs. You should therefore expect to develop at least two files for each exercise.
One file will contain the source code for the class itself. The other file will be a driver program that
uses and tests the features of the code generated by the class file.
WARNING: Work through some or all of the practice exercises before attempting exercises
to be submitted. Use the syntax and organization of the practice exercises as models. Failure to first
study the practise exercises will probably result in significant frustration!
| Programming Exercises For Practice | Programming Exercises For Grades |
BONUS Programming Projects |
|---|
| 10.03: |
Deal a five card poker hand. |
| 10.07: |
Compare two strings input by the user. |
| 10.11: |
Encode English language phrases into pig Latin. |
| 10.14: |
Alphabetize a list of strings. |
| 10.16: |
Determine the number of occurrences of a character in the text. |
| 10.18: |
Output only strings beginning with the letter b. |
|
| 10.04: |
Deal and evaluate two five-card poker hands. |
| 10.09: |
Create sentences with random number generation. |
| 10.13: |
Display tokens in reverse order. |
| 10.15: |
Output text in uppercase and lowercase letters. |
|
WARNING: These projects are challenging and time consuming.
|
| 10.23: | Verify authorship by comparing different manuscripts. |
| 10.27: | Translate an English phrase into Morse Code and vice versa. |
| 10.29: | Design and implement a Spelling Checker. |
| 10.30: | Design and implement a Crossword Puzzle Generator |
|
Include the following documentation for each exercise that is submitted to be graded.
List the specifications of the program. These may be deduced in the statement of the exercise.
Source Code of all new files: html file for applets, class file(s), driver program(s).
Print the source code and screen dump in a Word Processor, two pages per side, double sided.
Simultaneously pressing [Alt][PrtScn] will copy the GUI output to the clipboard from whence you
can paste it just below your source code. Use a non-proportional font (example: Courier New) to
maintain the vertical alignment of the stucture of your source code.
Screen Shots of Input and Output dialog boxes.
Where I/O (Input/Output) inlcudes multiple GUI (Graphical User Interface) dialog boxes, include at
least one screen shot for each input and output dialog box. Where there are various types of
dialog boxes and/or messages and/or types of data, include a "reasonable" number of screen shots.
Typically there will be 1-2 screen shots showing input and 1-2 screen shots showing output.
In extraordinary cases, there could conceivably be a dozen or more screen shots. What is "reasonable"
is the product of using reason (thought) and reasons (related information). BE REASONABLE!
OPTIONAL: JSP Notation
(Jackson Structured Programming Notation) showing the design and documentation of actions.
OPTIONAL: Class Diagram
showing the services that an instance of the class being designed will offer its clients.
OPTIONAL: Instance Diagram
illustrating the actual object instances which are used in the client program.
OPTIONAL: Trace Table of Changes in Values of the Variables During Execution.
There will be a multiple choice test at the end of this chapter.
|
![[Home of Gerry Donaldson's Com Sci Gate]](../../gifs/homeTAN.gif)
![[Gerry Donaldson's Email Address]](../../gifs/emailput.gif)
![[EFC Blue Ribbon - Free Speech Online]](../../gifs/freeTAN.jpg)