Summary

Some more notes on exceptions, making and using your own. We’ll also have a first look at design patterns and look at an example of how they help design programs which are easy to extend and maintain.

Book reference: ~ Chapter 1 of Head First Design Patterns;

Resources: ~ Some small examples of Java code (available from the COMP229 iLearn page) to illustrate some of the topics discussed in lectures.

Overloading, overriding and polymorphism

As we’ve seen, when subclassing we can override previously defined methods in subclasses. An overridden method has the same name and parameter list as a method in the superclass. But methods can also be overloaded; this happens when the method has the same name as another method in the same class, but has a different parameter list or signature.

The related idea polymorphism is when objects of several types can be referred to. This allows programmers to define operations so that the operations appropriate to the referenced object is automatically selected at runtime. An example of this idea is seen in the use of “+” which can be used as addition (when applied to integers) or concatenation when applied to strings.

Inheritance and constructors

Constructors are not inherited; usually the default constructor — i.e. the one without parameters — is automatically called to initialise inherited data members before the body of its sub-class constructor is executed. As we saw last week we also have the super construct to be able to invoke the other (parameterised) constructors of the super-class. (Have a look at some of the examples in last week’s code bundles.) The precise constructor to be called by your super() call is determined by the parameter list.

Initialisers

As you’ve probably seen in various code examples, initialisation is done through the constructors; however Java also provides the option to do that initialisation in initialisation blocks. For example this might be appropriate when there are many constructors all which must have an array initialised in the same way. The syntax of the initialisation block looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
public MyClass {
  private String[][] mArrayOfStrings;
  { // Initialiser
        mArrayOfStrings= new String[3][5];
         for(int i= 0; j <  3; i++)
           for (int j=0 ; j < 3; j++)
}
 // Constructors
 
 }

With so many things to be initialised in different ways, Java does everything in a particular order:

• First, initialisaers and then constructors in super classes are executed
• next sub-class initialisers
• and finally the sub-class constructor body is executed.

Class Hierarchies

As we’ve seen the classes are arranged in a hierarchy from superclass to subclasses. Common class features should be put as high as possible in the class hierarchy, and classes inherit methods and data from all of their ancestors via their parents.

In Java all classes have a special class called an Object class as an ancestor — we say that Object is the root of the class hierarchy.

The Object class

The object class contains some useful methods which are all inherited by all classes:

• default, no argument constructor;
• toString() — a string representation;
• equals(), hashcode() — object equality;
• clone() — object replication;
• readObject(), writeObject() — serialisation.

Typically subclasses will override these methods to provide class specific features — and we’ve already seen some examples of that.

Abstract classes

In Java there is a notion of abstract class consisting of abstract methods — i.e. methods which have declarations and without implementations. Abstract classes cannot be instantiated directly, but their subclasses can. If a class is defined in this way then it is modified with the keyword abstract . Abstract classes are used to define broad features of a class. They are used when you have a superclass for which you can define the fields, but there is no sensible way to define one or more of the methods in the superclass.

Take for example a hierarchy of animals. We might model sheep, goats, cows and birds according to the following class diagram

How could we implement either move or makeNoise in the superclass? There is no reasonable choice which applies to all animals. The right way to deal with this in OO is to mark those methods as abstract. Marking a method abstract means it is a method signature only, not an implementation. This is OK in a sense because only a methods signature is part of it’s interface with the outside world. However, objects built from such a class can’t possibly work because a call to the abstract method would crash (there is no code there!). Thus any class with an abstract method must also be labelled abstract and you cannot call constructors (instantiate) abstract classes.

The above diagram is not correct UML. UML has a notation for indicating something is abstract, which is to write it in italics like so

However, most of us don’t have a separate italic version of our handwriting. Even if we did it is doubtful other people would recognise it. Thus I prefer to use the abstract keywork in my diagrams. This is an example where official UML falls down as a method of getting your ideas out of your head and onto paper.

Interfaces

A class entirely composed of abstract methods is called an interface and is tagged with the interface keyword rather than class .

Interfaces and abstract classes enforce a common design structure which must be adhered to by the subclasses which are implemented. Interfaces can also inherit from other interfaces at once (i.e. we can have multiple inheritance at interfaces); moreover classes can also inherit from multiple interfaces by providing implementations for methods.

In fact multiple inheritance via interfaces avoids many of the problems encountered in other languages where multiple inheritance is allowed between arbitrary classes. For example if a class inherits from two implemented parent classes (which is possible in C++) then it’s possible that the two parent classes might have conflicting implementations, and moreover how would the subclass’s overriding mechanism work, and which parent would super refer to?

Doing all of this via interfaces avoids all of that because interfaces don’t have any implemented methods to conflict! Aside: In my opinion the problems with multiple inheritance are overstated, but they are real and using interfaces does solve them. However, it introduces other problems…

1
2
public FullTime (String first, String last, double s) 
public PartTime (String first, String last, double r, double h)

1
Full time: Horace Snooks, Salary:  $1000

1
Part time: Jane Biggs, Hourly Rate:  $20, Hours: 4

1
2
3
4
  Full time: Fred Smith, Salary:  $1000, Earnings: $1000
  Full time: Samantha Simons, Salary:  $1500, Earnings: $1500
  Part time: Dame Edna Everage,  Hourly Rate: $1000 , Hours: 40, Earnings: $42500
  Part time: Angelina Jolie,  Hourly Rate: $1000 , Hours: 25, Earnings, $25000