CS101-CS102
Java OOP Labs
Check your design/code against this list to avoid some
common mistakes
Strive to write concise, elegant, maintainable code.
Unless told otherwise, ensure all your Java
classes:
- Declare variables for genuine properties only, and do not initialise them as part of the
declaration.
- Have a constructor that explicitly initialises all
properties, i.e. is not empty!
- Declare local (temporary) variables inside the
method that uses them, not as properties!
- Follow the course style guidelines regarding
layout and Java naming conventions.
- Employ comments and meaningful names to aid
understanding.
- Include a header comment detailing the
classes' purpose, author, creation date, mod's, etc.
Properties:
Property/Instance variables store the state of individual objects of a class.
They are initialised by constructors and used/modified in methods. Variables
which as used only to store intermediate (temporary) results, must be declared
locally in the method where they are used, not as properties of the class.
Constructors:
Constructors are called automatically whenever you create an instance of a
class. Their purpose is give explicit values to each of an instance's
properties. Whilst it is possible to initialise properties when they are
declared, this is generally considered bad practice. The only real exception to
this is for class (static) variables, which exist even if no objects have been
created and must thus be given values when declared. Note that Java does not
require a class to have a constructor. If a class does not have a constructor
explicitly defined, the compiler will automatically add a default (empty) constructor
with no parameters, and initialise numeric-type instance variables to zero and
object-type variables to null. You should not rely on this (since different
languages may have different behaviours.) You must, therefore, always define one
or more constructors in any class you write.
Methods:
Methods implement the services a class provides to its users. They have direct
access to all of the properties of the class. Any additional information they
require to perform their task must be passed into the method via parameters.
Variables, other than properties and parameters, must be declared locally, in
the method. Do not create such local variables unnecessarily. Methods which are
independent of the source and destination of the information they are
manipulating are more reusable. Thus, wherever possible, design methods to
receive information via their input parameters (and properties of the class),
not by reading it directly from the keyboard. Similarly, method results should
be output using the return statement (and by updating properties of the class as
appropriate), rather than printing them on the console.
General:
Include a header comment! Separate sections of your code (especially methods)
from each other with a blank line and (preferably) add descriptive comments as
appropriate. Follow style guidelines relating to (a) naming: names should be
meaningful and follow Java conventions regarding upper/lower case formats, (b)
indentation: each subsection should be indented slightly to the right enabling
the structure of the code to be readily visible, and (c) white space: add spaces
before and after operators, etc. and after opening brackets, commas, etc. to
improve readability (otherwise code becomes like a book without any spaces and
punctuation to separate out words!)
The purpose of design is to ensure we have a correct solution to our problem
before actually implementing it. We have already developed a number of
techniques for improving our chances of success. Chief amongst these is reducing
the number of things we have to consider at any one time (since human beings are
notoriously bad at remembering and manipulating more than about 7 +/- 2 items at
a time!) Your OOP designs should adopt a similar approach. Begin by developing
an overview of the component classes of your program. To ensure others can
understand your design it helps to adopt a common notation. Try to use a subset
of the industry standard, UML (Unified Modeling Language) to communicate your
design. Having others look at and comment on your design, is yet another way to
avoid errors in the final program!
Most designs will begin with the UML Class diagram, which depicts the
individual classes and their relations to each other. Later, we may use the
Object diagram, to show the state of our program during execution, and various
other activity diagrams to model object interactions. For algorithms we will
also continue to use the pseudocode techniques & notations we developed earlier.
The UML Class Diagram has the following basic format (simplified). Note:
the "syntax" is often the reverse of that in Java!
For each class:
| class
--> |
| properties --> |
| constructors
--> |
| methods --> |
|
| ClassName |
| access
name : type |
access
ClassName ( parameters)
access
methodName ( parameters) : returnType |
|
where:
- access is "+", "#", " ", or "-" for public, protected, default &
private, respectively.
- parameters are a comma separated list of "name : type"
pairs.
- the return type "void" is always omitted.
- static (class) items are indicated by an underline.
For relationships between classes:
There are three basic relationships between classes, shown using the
arcs/arrows below:
- Aggregation (ClassA
is a collection of ClassB's)
Composition (ClassA has_a ClassB as property)
- Association (Uses)
(in which ClassA makes use of ClassB without necessarily actually incorporating it
as a property -it may, for example, be a parameter or used locally in a
method)
- Generalisation (Inheritance) (ClassA sub-classes
or is_a ClassB, i.e. it extends -adds / removes / modifies the
functionality of the other).
Note: in CS101 we will not be concerned with the Generalisation/Inheritance relation.
For more details see these
Introduction to UML slides.
Simple example UML class diagram
Last updated:
06 Feb 2011
Please report any errors or omissions to the course instructor.