COSC 3P91: Week 1 Notes

Design Principles

Design principles in this course and used by the design patterns:

Use abstraction whenever possible
- Introduce (abstract) superclass (or interfaces) in order to implement or define common behaviour
- Nothing should be implemented twice
Program to an interface, not an implementation
Favour composition over inheritance
- Delegation
Design for change and extension

Basic Programming Principles

The following principles will produce code that is easy to understand without any unforeseen effects (not super strict rules, just suggestions to make code cleaner):

Do not use side effects in expressions
- Commonly used in the condition of a while loop (while (file != null) {})
  - In this example, you are both saving the content of the file to a file and checking if the file is empty
Construct blocks of code as single-exit blocks:
- No break statements
  - Only exception to this rule are break’s within switch statements
  - No “forever”-loops (while (True) {})
- The only return statement in a method should be the last statement of the method

Classes

[ClassModifiers] class ClassName 
		[extends SuperClass]
		[implements Interface, Interface, ...] {
	ClassMemberDeclarations
}

Class modifiers
- visibility: packages vs public
- abstract
- final
  - Class cannot be extended
extends clause specifies superclass
implements clause specifies the interfaces being implemented

Class Members

Class (static) members
- one occurrence for entire class
- shared access by all instances
- if visible, accessed via class name
- public static void main(String[] args) {...}
  - If it were not static, something would need to be created before main(), which obviously makes no sense because main() is the starting point
Member modifiers
public versus protected versus package versus private
abstract
- Specified that method, but doesn’t have an implementation yet (will be implemented in subclasses usually)
final
- Variables: read only
- Method: cannot be overridden (abstract/interface)
synchronized (method)
- For synchronization of threads
native (method)
volatile (field)
- Allow multiple threads to access one variable (prof has never used it before)
transient (field)
- Variable will not be included in the serialization process

Inheritance

Parent/child, superclass/subclass
Instances of child inherit data and behaviour of the parent
implements
- inheritance of specification
extends
- subclassing
- inheritance of code and specification
- overriding
  - creating some type of polymorphism
subclass versus subtype
Subclass is an extension of behaviour (specialization)
- Elements of the superclass are more general than the subclass (cars vs Ford’s)
Subtype is a contraction of a value space (specialization)

Subtypes

A subclass extends the capability of its superclass; the subclass inherits features from its superclass and adds more features
Every instance of a subclass is an instance of the superclass
Each class defines a type

Definition: Subtype

Type $T_{1}$ is a subtype of type $T_{2}$ if every legitimate value of $T_{1}$ is also a legitimate value of $T_{2}$ . In this case, $T_{2}$ is a supertype of $T_{1}$ .

Substitutability of subtypes:

A value of a subtype can appear wherever a value of its supertype is expected

Overriding versus Overloading

Overriding

instance methods
same name, signature and result type
in subclass
effect - replacement implementation
- access superclass version via super

Overloading

methods
same name, different signatures
same class or subclass
effect - multiple methods with same name
do not overuse (readability of programs)
overloading should be used only in two situations:
1. When there is a general, non-discriminative description of the functionality that fits all the overloaded methods
2. When all the overloaded methods offer the same functionality, with some of them providing default arguments

Forms of inheritance

Inheritance for specification

parent provides specification
- abstract classes
- interfaces
behaviour implemented in child
subtype

/* Java Interface */
 
interface ActionListener {
	public void actionPerformed (ActionEvent e);
}
 
 
class CannonWorld extends Frame {
	/* ... */
	// a fire button listener implements the action
	
	// listener interface
	private class FireButtonListener implements ActionListener {
		public void actionPerformed (ActionEvent e) {
		/* ... */ // action to perform in response to button press
		}
	}
}

/* Abstract Class */
 
public abstract class Number {
	public abstract int intValue();
	public abstract long longValue();
	public abstract float floatValue();
	public abstract double doubleValue();
	public byte byteValue()
		{ return (byte) intValue(); }
	public short shortValue()
		{ return (short) intValue(); }
}

Inheritance for extension

adding behaviour (methods, variables, etc.)
subtype

class Properties extends Hashtable {
	…
	public synchronized void load(InputStream in) 
		throws IOException {/* ... */}
 
	public synchronized void save(OutputStream out, String header) {/* ... */}
 
  public String getProperty(String key) {/* ... */}
 
  public Enumeration propertyNames() {/* ... */}
 
  public void list(PrintStream out) {/* ... */}
}

Inheritance for specialization

child is special case
child overrides behaviour to extend
subtype

public class MyCar extends Car {
	/* ... */
	public void startEngine() {
		motivateCar(); // add this function, specific to `MyCar`
		super.startEngine();
	}
	/* ... */
}

Inheritance for construction

inherit functionality
ad hoc inheritance
not a subtype
use composition

/* NOT GOOD, just an example of what it would look like */
class Stack extends LinkedList {
 
	public Object push(Object item)
		{ addElement(item); return item; }
 
	public boolean empty()
		{ return isEmpty(); }
 
	public synchronized Object pop() {
		Object obj = peek();
		removeElementAt(size() - 1);
		return obj;
	}
 
	public synchronized Object peek()
		{ return elementAt(size() - 1); }
}

Inheritance for limitation

restricting behaviour
not subtype
use composition

/* NOT GOOD, just an example of what it would look like */
class Set extends LinkedList {
	// methods addElement, removeElement, contains,
	// isEmpty and size are all inherited from LinkedList
 
	public int indexOf(Object obj) {
		System.out.println(“Do not use Set.indexOf”);
		return 0;
	}
 
	public Object elementAt(int index) {
		return null;
	}
}

Inheritance for combination

combining behaviours
multiple inheritance
only through interfaces in Java

public class Mouse extends Vegetarian implements Food {
	/* ... */
	protected RealAnimal getChild() {
		/* ... */
	}
	/* ... */
	public int getFoodAmount() {
		/* ... */
	}
	/* ... */
}

Note

End of lecture 1

Note On Subclasses vs Subtyping

Subclassing implies subtyping (in Java, and most other languages)
- May not happen in other languages, like C++ (it still can happen, but does not always happen)

UML Class Diagram

Truck must have a component Trailer
- Truck cannot exist without a Trailer
+ public
- private
# protected
underlined static
italicized abstract
- Vehicle & Truck should be italicized

classDiagram
    class Vehicle {
        - speed : Integer
        + Vehicle(speed : Integer)
        + getSpeed() : Integer
        + accelerate()
    }

    class MyCar {
        + MyCar(speed : Int)
        + accelerate()
    }

    class Truck {
        # trailer : Trailer
        + Truck(speed : Integer, tr : Trailer)
    }

    class Trailer {
        + CAPACITY : Integer (readonly)$
        + Trailer()
        + clone() : Object
    }

    class Cloneable {
        <<interface>>
        + clone() : Object
    }

    Vehicle <|-- MyCar : inheritance
    Vehicle <|-- Truck : inheritance
    Truck "0..*" o-- "1" Trailer : aggregation
    Trailer ..|> Cloneable : implementation

Composition

Composition $\equiv$ has-a relationship (strong ownership)
Inheritance $\equiv$ is-a relationship
Inheritance vs composition
- desire to reuse existing implementation
- substitutability
- subclass inherits specification and all methods and variables
- composition allows selective reuse

Inheritance Example (bad)

classDiagram
    class LinkedList {
        + addElement(obj: Object)
        + removeElement(obj: Object)
        + contains(obj: Object): boolean
        + isEmpty(): boolean
        + size(): int
        + indexOf(obj: Object): int
        + elementAt(index: int): Object
    }

    class Set {
        + indexOf(obj: Object): int
        + elementAt(index: int): Object
    }

    LinkedList <|-- Set

public int indexOf(Object obj) {
 System.out.println(“Do not use Set.indexOf”);
 return 0;
}
 
public Object elementAt(int index) {
 System.out.println(“Do not use Set.elementAt”);
 return null;
}

Composition Example

classDiagram
    class LinkedList {
        + addElement(obj: Object)
        + removeElement(obj: Object)
        + contains(obj: Object): boolean
        + isEmpty(): boolean
        + size(): int
        + indexOf(obj: Object): int
        + elementAt(index: int): Object
    }

    class Set {
        - content: LinkedList
        + addElement(obj: Object)
        + removeElement(obj: Object)
        + contains(obj: Object): boolean
        + isEmpty(): boolean
        + size(): int
    }

    LinkedList "1" --* "0..*" Set

How functions in the set element are implemented (delegation):

Can also use this type of implementation to change the functionality

public void addElement(Object obj) {
   content.addElement(obj);
}
/* ... */
public int size(){
   return content.size();
}

Generics

Up to Java 4
- container classes store object of class Object
- storing elements in a container uses subtype polymorphism
- accessing elements in a container requires type casting
- note: it is impossible to check the type of the popped value

Stack s = new Stack();
s.push(new Integer(3));
Integer n = (Integer) s.pop();	    // cast required
s.push(”abc”);				        // no error
Integer second = (Integer) s.pop();	// runtime error
					                // (ClassCastException)

From Java 5
- generic classes (similar to templates in C++)

Stack<Integer> s = new Stack();
s.push(new Integer(3));
Integer n = s.pop();		// no cast required
s.push(”abc”);				// type error 
							// (at compile time)

Advantages of Generics

Strong static type-checking
- fewer ClassCastExceptions
- fewer casts
- no unchecked warnings
Improved readability
Better tool support
No future deprecation

Generics - UML Class Diagram

Only name of class is displayed (in this example, you can display what you want)

classDiagram
    class MyGenericClass {
        <<generic>> E
    }
    
    class MyInstantiationClass {
    }

    MyGenericClass <|-- MyInstantiationClass : <<bind>> E → MyClass1

Two short forms for an instantiation (useful if generic class is not part of the diagram):

MyGenericClass<E -> MyClass2
MyGenericClass<MyClass2>

All three of these examples (including the diagram) mean the same thing.

Generic Class Example

Generic variables are fine (e.g. X)
Generic arrays is not possible in Java

public class Pair<X,Y> {
	
	private X first;		// first component of type X
	private Y second;		// second component of type Y
	
	public <A extends X,B extends Y> Pair(A a,B b) {
		first = a;
		second = b;
	} // constructor
 
	public Pair(Pair<? extends X, ? extends Y> p) {
		first = p.getFirst();
		second = p.getSecond();
	} // constructor
 
	public X getFirst() {
		return first;
	} // getFirst
 
	public void setFirst(X x) {
		first = x;
	} // setFirst
 
	public Y getSecond() {
		return second;
	} // getSecond
 
	public void setSecond(Y y) {
		second = y;
	} // setSecond
}

Declare this in the Object class (every object will have a equals method)

public boolean equals(Object obj) {
	if (obj instanceof Pair<?,?>) {
	   Pair<?,?> p = (Pair<?,?>) obj;
	   return first == p.getFirst() && second == p.getSecond();
	};
	return false;
} // equals

Example usage:

public class PairTest {
    public static void main(String[] args) {
        // Create two pairs
        Pair<Integer, String> pair1 = new Pair<>(1, "Apple");
        Pair<Integer, String> pair2 = new Pair<>(1, "Apple");
 
        // Check if the pairs are equal using the equals method
        boolean areEqual = pair1.equals(pair2);
 
        // Output the result
        if (areEqual) {
            System.out.println("pair1 is equal to pair2.");
        } else {
            System.out.println("pair1 is not equal to pair2.");
        }
    }
}

Note

Moving to week 2 slides

Auto Boxing

in Java 4

Stack s = new Stack();
s.push(new Integer(3));		// wrapper class needed
Integer n = (Integer) s.pop();

from Java 5

Stack<Integer> s = new Stack<Integer>();
s.push(3);				    // auto boxing (auto converting int to Integer)
int n = s.pop();			// again auto boxing
s.push(new Integer(1));		// without boxing
Integer num = s.pop();		// again without boxing
s.push(2);				    // any combination
num = s.pop();			    // possible

Iterations

in Java 4

List strings;
/* ... */
for(int i = 0; i < strings.size(); i++) {
	String str = strings.elementAt(i);
	System.out.println(str);
}

or better, using an iterator

for(Iterator iter = strings.iterator(); iter.hasNext();) {
	String str = (String) iter.next();
	System.out.println(str);
}

from Java 5
- this is just shorthand for the above code

List<String> strings;
/* ... */
for(String str : strings) {
	System.out.println(str);
}
 
int[] vector = new int[100];
/* ... */
int sum = 0;
for(int elem : vector) sum += elem;

Enumeration Types

in Java 4
- enumeration types are implemented by using the type int

public static final int RED 	 = 0;
public static final int YELLOW	 = 1;
public static final int BLUE	 = 2;
/* ... */
switch(myColor) {
	case Color.RED:    System.out.println(”red”); break;
 	case Color.YELLOW: System.out.println(”yellow”); break;
 	case Color.BLUE:   System.out.println(”blue”); break;
};

Advantages of explicit enumeration types:

type safe (checked at compile time)
- int enums don’t provide any type safety at all
provide a proper name space for the enumerated type
- with int enums you have to prefix the constants to get any semblance of a name space
robust
- int enums are compiled into clients, and you have to recompile clients if you ad, remove, or reorder constants
printed values are informative
- if you print an int enum you just see a number
can be stored in collections (objects)
arbitrary fields and methods can be added

Connor's Notes

⬅️ Back to portfolio

Explorer

COSC 3P91: Week 1 Notes

Design Principles

Basic Programming Principles

Classes

Class Members

Inheritance

Subtypes

Overriding versus Overloading

Overriding

Overloading

Forms of inheritance

Inheritance for specification

Inheritance for extension

Inheritance for specialization

Inheritance for construction

Inheritance for limitation

Inheritance for combination

Note On Subclasses vs Subtyping

UML Class Diagram

Composition

Inheritance Example (bad)

Composition Example

Generics

Advantages of Generics

Generics - UML Class Diagram

Generic Class Example

Auto Boxing

Iterations

Enumeration Types

Graph View

Table of Contents

Backlinks