Object-Oriented Programming

The Real Cost of Software

The dominant cost in software is not writing it — it is maintaining it. Studies consistently show that 60–80% of a software system’s total lifetime cost goes into maintenance: fixing bugs, adding features, adapting to new requirements, and understanding what the original authors intended. Code is read far more often than it is written. The primary goal of good software design is therefore to maximise maintainability.

The Maintainability Wishlist

Well-engineered software should be:

• Readable: another developer (or your future self) can understand the code quickly without reconstructing intent from implementation details
• Modular: the system is divided into independent, interchangeable components that can be developed, tested, and understood in isolation
• Reusable: common functionality is written once and used everywhere, avoiding duplication that leads to inconsistent bug fixes
• Robust: the system handles unexpected inputs and states gracefully, without crashing or corrupting data
• Testable: individual components can be verified independently, ideally through automated unit tests

What OOP Brings

Object-oriented programming organises programs as collections of interacting objects. Each object bundles together:

• State (fields, attributes, data members): the values the object knows about itself
• Behaviour (methods, member functions, operations): the things the object can do

This bundling — called encapsulation — means that an object’s internal data can only be manipulated through its own methods. The object presents a controlled interface to the outside world while keeping its implementation details private.

Objects interact by sending messages to each other — in Java, this means calling methods on object references. A program written in OOP style is a society of cooperating objects, each with a clearly defined role.

Two Important Warnings from the Course

Few Languages Are Pure OOP

Java is not a purely object-oriented language. It has:

• Primitive types (int, double, boolean, etc.) that are not objects and live outside the object model
• Static methods and fields that belong to classes rather than instances
• Lambda expressions and functional interfaces (since Java 8) that introduce functional-programming patterns

This is not a flaw — it is a pragmatic choice. Primitives exist for performance; static methods exist because not every operation naturally belongs to an object instance. Real-world languages hybridise paradigms.

OOP Is Not Always Appropriate

OOP is a tool, not a religion. It is not the best fit for every problem:

• Small scripts (a few hundred lines of procedural logic) gain little from class hierarchies and design patterns
• Heavily numerical code (scientific computing, signal processing) often expresses more naturally in procedural or array-oriented styles where the focus is on transforming data rather than modelling entities
• Pure data pipelines (extract, transform, load) may be better served by functional approaches

The course teaches OOP as one paradigm among several. OCaml is taught in Foundations of Computer Science (FoCS) as the functional counterpart, and the two courses are designed to complement each other.

Benefits and Costs

Benefits

• Models the problem domain more naturally when the domain contains entities with state and behaviour
• Encapsulation limits the ripple effect of changes
• Polymorphism lets new behaviour be added without modifying existing code
• Inheritance enables code reuse through shared interfaces and implementations

Costs

• Boilerplate: Java requires explicit class declarations, getters, setters, and constructor code even for simple data carriers
• Indirection: method calls through interfaces and abstract types add layers that make control flow harder to trace
• Over-engineering risk: applying design patterns and abstractions before they are needed adds complexity without benefit

Encapsulation, Inheritance, and Polymorphism

These three concepts are often presented as the pillars of OOP, but the course frames them differently: they are tools in service of the maintainability goals, not goals in themselves.

• Encapsulation serves modularity and robustness by hiding internal state behind a stable public interface
• Inheritance serves reusability by letting classes share implementation code through an “is-a” hierarchy — but used carelessly it creates brittle, tightly coupled designs
• Polymorphism serves readability and testability by letting code work with any type that satisfies an interface, rather than being hard-coded to specific concrete types

A well-designed OOP system uses these tools judiciously. A badly designed one uses them because it feels they ought to be used. The measure of success is the maintainability wishlist, not the presence of design pattern vocabulary.

Two Paradigms

Programming languages can be broadly classified by the style of computation they encourage. The two paradigms most relevant to the Part IA course are the imperative and functional paradigms.

Imperative Programming

In an imperative language, a program is a sequence of statements that mutate the program’s state. Execution order matters because each statement may depend on the state left behind by the previous one.

Key characteristics:

• Mutable state: variables hold values that change over time. x = x + 1 is a common expression because x really does take on a new value.
• Explicit control flow: loops (for, while), conditionals (if/else), and subroutine calls drive computation
• Side effects: functions can modify global state, perform I/O, or alter their arguments — the function’s effect is not limited to its return value
• Statement-oriented: computation is structured as “do this, then do that”

Examples of imperative languages: C, Java, Python, JavaScript (though all have absorbed some functional features).

Java as an Imperative Language

Java is fundamentally imperative and object-oriented. Consider:

int total = 0;
for (int i = 0; i < numbers.length; i++) {
    total = total + numbers[i];
}

The variable total is explicitly mutated through each iteration. The loop counter i changes with every step. The state of the program at any point is the collection of all variable values at that point.

Functional Programming

In a functional language, a program is a collection of expressions built from pure functions. Computation proceeds by evaluating expressions rather than executing statements.

Key characteristics:

• Immutability: once a value is bound to a name, it does not change. There is no assignment statement that alters an existing variable.
• Pure functions: a function’s output depends only on its inputs. Calling the same function with the same arguments always produces the same result. There are no side effects.
• Recursion over loops: instead of mutating a loop counter, functional languages use recursive function calls to process sequences
• Expression-oriented: everything evaluates to a value. An if expression returns a value; a function body is a single expression.

Examples of functional languages: OCaml, Haskell, F#, Elm.

OCaml in the Part IA Course

OCaml is taught in Foundations of Computer Science (FoCS). It is a statically typed functional language with powerful type inference and pattern matching. A typical OCaml function:

let rec sum lst =
  match lst with
  | [] -> 0
  | x :: xs -> x + sum xs

There is no mutable variable being updated. The computation is expressed as a recursive decomposition of the list. The function is pure — its result depends only on its input list.

Where Java Stands

Java is fundamentally an imperative, object-oriented language, but it has absorbed functional features since Java 8:

• Lambda expressions: anonymous functions that can be passed as arguments
• Streams API: a functional-style pipeline for processing collections without explicit loops
• Method references: shorthand for lambdas that call a single method
• Optional: a container type that avoids null and encourages functional-style chaining

The imperative loop above can be rewritten in a functional style:

int total = Arrays.stream(numbers).sum();

No explicit mutation of a running total. No loop counter. The stream pipeline abstracts away the iteration. However, Java lambdas are still ultimately compiled into objects and invoked through interfaces — the functional style is syntactic sugar over an imperative core.

Trade-offs

Imperative

Functional

Complementarity

The two courses — OOP (Java) and FoCS (OCaml) — are designed to give you fluency in both paradigms. Each illuminates the other: understanding immutability and pure functions from OCaml helps you write better Java code (fewer mutable fields, prefer immutable objects where possible), and understanding object modelling from Java helps you appreciate OCaml’s module system as an alternative approach to abstraction.

Traditional Compilation

In a traditional compiled language like C, the pipeline is:

Source code  →  Compiler  →  Platform-specific machine code  →  CPU executes directly
  (.c)           (gcc)             (.exe / ELF / Mach-O)

The compiler translates the source directly into the native instruction set of the target CPU (x86-64, ARM, etc.). The resulting executable runs at full native speed, but it only works on the platform it was compiled for. To support Windows, macOS, and Linux, you must compile three separate binaries — and that is before considering different CPU architectures.

The Java Model

Java uses a two-stage compilation model:

Source code  →  javac  →  Bytecode  →  JVM interprets/JIT-compiles  →  Native machine code
  (.java)                 (.class)         (at runtime)

Stage 1: Source to Bytecode

The Java compiler (javac) translates .java source files into .class files containing bytecode. Bytecode is a platform-independent intermediate representation — a kind of portable assembly language. It is not tied to any particular CPU architecture. The bytecode instructions operate on an abstract stack machine rather than physical registers.

Stage 2: Bytecode to Native Code

At runtime, the Java Virtual Machine (JVM) loads the bytecode and executes it. Two execution strategies are used, often in combination:

• Interpretation: the JVM reads each bytecode instruction and carries out the corresponding operation. Slow but starts immediately.
• Just-In-Time (JIT) compilation: the JVM identifies frequently executed code (hot spots) and compiles those bytecode sequences into native machine code on the fly. Subsequent executions of that code run at near-native speed.

Modern JVMs (like HotSpot) use tiered compilation: start with interpretation, then apply increasingly aggressive optimisations as code proves itself hot.

”Write Once, Run Anywhere”

Because bytecode is platform-independent, the same .class file can run on any machine that has a JVM installed — whether it is a Windows x86 machine, a macOS ARM laptop, or a Linux server. The JVM abstracts away the underlying operating system and hardware.

This was a revolutionary idea when Java was released in 1995. At the time, cross-platform development usually meant maintaining separate codebases or wrestling with #ifdef preprocessor directives.

Pros and Cons

Advantages

• Portability: compile once, deploy anywhere with a JVM
• Memory safety: no raw pointers, no manual memory management, arrays are bounds-checked — entire classes of C/C++ bugs (buffer overflows, use-after-free, double-free) are eliminated
• Automatic garbage collection: the JVM reclaims memory from objects that are no longer reachable, removing the burden of manual free() and eliminating memory leaks from forgotten deallocations
• Rich standard library: the JDK provides data structures, networking, I/O, concurrency, and much more out of the box

Disadvantages

• Startup overhead: the JVM must initialise itself, load classes, and warm up the JIT compiler before reaching peak performance — a native binary starts instantly
• Runtime dependency: the target machine must have a JVM installed (though jlink and jpackage can bundle a minimal runtime)
• Execution overhead: interpreted or not-yet-JITted code runs slower than native code, though heavily optimised JIT code can sometimes outperform ahead-of-time compiled code because JIT optimisation has runtime information available

The Broader JVM Ecosystem

The two-stage model has an important consequence: any language that can compile to JVM bytecode can run on the JVM and interoperate with Java code. The JVM has become a polyglot platform:

• Kotlin: a modern, concise alternative to Java (now Google’s preferred language for Android)
• Scala: fuses object-oriented and functional programming
• Clojure: a dynamic, functional Lisp dialect
• Groovy: a dynamic scripting language with Java-friendly syntax

All of these languages share the JVM’s garbage collector, threading model, and standard library access. A Kotlin class can extend a Java class; a Scala function can call a Java method. The JVM is the common substrate that makes this possible.

The Core Commands

Three commands form the basic Java workflow:

javac — The Java Compiler

The javac command reads .java source files and produces .class bytecode files. The filename of a public class must match the filename: HelloWorld.java must define public class HelloWorld.

javac HelloWorld.java

This produces HelloWorld.class in the current directory. If the source file contains multiple classes (at most one public), javac produces one .class file per class.

Useful Flags

If your program depends on external libraries, you must tell javac where to find them. Assuming a library JAR at lib/utils.jar:

javac -cp lib/utils.jar:. src/MyProgram.java -d out/

The :. (or ;. on Windows) includes the current directory in the classpath so that previously compiled classes can be found.

java — The JVM Launcher

The java command starts the JVM and runs the main method of the specified class. Note: you provide the class name, not the filename — no .class extension.

java HelloWorld

The JVM loads the class, verifies the bytecode, and executes public static void main(String[] args).

Useful Flags

Classpath at runtime works the same as at compile time:

java -cp lib/utils.jar:out/ MyProgram

jshell — The Interactive REPL

jshell, introduced in Java 9, provides a Read-Eval-Print Loop for interactive experimentation. It lets you write Java statements, expressions, and declarations without a full compile-build-run cycle. This is useful for exploring APIs, testing small code snippets, and learning the language.

jshell> int x = 42;
x ==> 42

jshell> x * 2
$2 ==> 84

jshell> String s = "Hello, " + x;
s ==> "Hello, 42"

jshell supports tab completion, forward references, and declaration redefinition. It uses a slightly relaxed syntax — semicolons are optional for top-level expressions. To exit, type /exit.

The Build-Run Cycle

A typical development workflow:

javac -d out/ src/HelloWorld.java
java -cp out/ HelloWorld

For a multi-file project:

javac -d out/ src/*.java
java -cp out/ MainClass

Or, if you are avoiding explicit compilation during experimentation:

java src/HelloWorld.java

Since Java 11, the java command can directly run a single source file — it compiles the file in memory and executes it. This is convenient for small scripts but does not produce persistent .class files.

Comparison with Python

Python does something similar under the hood:

Both languages compile to a platform-independent bytecode and then execute it on a virtual machine. The key difference is that Python hides the compilation step — you rarely see .pyc files unless you look for them — while Java makes it an explicit part of the workflow.

Common Pitfalls

• Class name mismatch: public class HelloWorld must be in a file called HelloWorld.java, and the java command expects the class name, not HelloWorld.class or HelloWorld.java
• Classpath issues: if your classes are in out/, you must include out/ on the classpath when running
• Forgetting to recompile: after editing a .java file, you must run javac again before running java — the JVM sees the .class file, not the source
• Case sensitivity: helloworld and HelloWorld are different identifiers on all platforms (unlike Windows filenames)

Every Program Lives in a Class

In Java, all code belongs to a class. There are no standalone functions, no global variables, and no code outside of a class definition. Even the simplest program requires wrapping logic inside a class and a method.

This is a defining characteristic of Java’s object-oriented design: the class is the fundamental unit of organisation.

The main Method

The Java Virtual Machine (JVM) looks for a specific method to start execution. The entry point must have exactly this signature:

public static void main(String[] args)

Each keyword serves a specific purpose:

The name main is conventional and mandatory — the JVM looks specifically for main, not start or run or entryPoint.

Command-Line Arguments

java MyProgram hello 42 "some text"

Inside the program, args will be:

args[0] = "hello"
args[1] = "42"
args[2] = "some text"

All arguments arrive as String objects regardless of type. If you need numbers, you must parse them:

int n = Integer.parseInt(args[0]);

Console Output

System.out.println() sends text to standard output, followed by a newline. System.out.print() does the same without a newline.

System.out.println("Hello, World!");
System.out.print("No newline after this.");

System.out is a PrintStream object — a static field of the System class. println is overloaded for all primitive types and for objects (calling the object’s toString() method).

Annotated HelloWorld

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello, World!");

        if (args.length > 0) {
            System.out.println("First argument: " + args[0]);
        }
    }
}

To compile and run:

javac HelloWorld.java
java HelloWorld
java HelloWorld Alice

Package Declarations

A package is a namespace that organises classes and prevents name collisions. The package declaration must be the first non-comment line in the file:

package com.example.myapp;

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello from a package!");
    }
}

Package names follow a reversed-domain convention (com.example.myapp), and the directory structure mirrors the package hierarchy:

src/
  com/
    example/
      myapp/
        HelloWorld.java

If no package is declared, the class belongs to the unnamed default package — fine for small programs, but real projects always use packages.

Import Statements

The import statement lets you refer to classes from other packages by their short name rather than their fully qualified name:

import java.util.ArrayList;
import java.util.List;

Without the import, you would write java.util.ArrayList every time. A wildcard import (import java.util.*) imports all classes from the package but not subpackages.

java.lang is imported automatically — classes like String, Math, Integer, and System are always available without an explicit import.

Java Syntax Rules

• Case sensitivity: count, Count, and COUNT are three distinct identifiers
• Semicolons: every statement ends with a semicolon. Forgetting one is a compile error.
• Braces: code blocks are delimited by { and }. Indentation is for human readers only — the compiler ignores whitespace.
• One public class per file: a .java file may contain multiple classes, but at most one of them can be public. The public class’s name must match the filename.

Class Naming Conventions

• Use PascalCase (also called UpperCamelCase): HelloWorld, BankAccount, ArrayList
• Class names should be nouns or noun phrases
• The filename must match the public class name exactly, including capitalisation: HelloWorld.java contains public class HelloWorld

Summary of File Layout

package com.example;           /* package declaration (optional) */

import java.util.ArrayList;    /* import statements (optional) */
import java.util.List;

public class ClassName {       /* class definition — must match filename */

    private int field;         /* fields (state) */

    public ClassName() {       /* constructors */
        this.field = 0;
    }

    public int getField() {    /* methods (behaviour) */
        return this.field;
    }

    public static void main(String[] args) {   /* entry point */
        ClassName obj = new ClassName();
        System.out.println(obj.getField());
    }
}

The Two Kinds of Type

Every type in Java falls into one of two categories: primitive or reference. Understanding the distinction is essential for reasoning about assignment, parameter passing, equality comparison, and null handling.

Primitive Types

Primitives represent simple, atomic values. They are:

• Fixed-size: each primitive type occupies a known number of bytes, specified by the language specification and independent of platform
• Stored directly by value: a variable of primitive type holds the actual value, not a pointer to it
• Never null: a primitive variable always contains a value (even if uninitialised, it gets a default zero value as a field)
• Live on the stack or inline in objects: primitives are not heap-allocated unless they are fields of a heap-allocated object

The Eight Primitive Types

The sizes in the table are fixed by the Java Language Specification. An int is always 32 bits, regardless of whether the JVM runs on a 32-bit or 64-bit platform. This is a key difference from C, where int may be 16, 32, or 64 bits depending on the compiler and target.

Literals

• Integer literals (42) are int by default; append L for long (42L)
• Floating-point literals (3.14) are double by default; append f for float (3.14f)
• char literals are enclosed in single quotes ('A', '\n', '\u0041')
• boolean literals are true and false

Reference Types

Reference types include classes, arrays, interfaces, enums, and String. A variable of reference type holds a reference — a handle or pointer to an object allocated on the heap. The variable itself does not contain the object’s data; it contains the memory address (abstractly) of where the object lives.

String s = new String("hello");

The variable s is a reference. The actual string object lives on the heap. The reference is what gets stored in the variable.

Key Properties of Reference Types

• Assignment copies the reference, not the object:

Point p1 = new Point(3, 4);
Point p2 = p1;

p2 now refers to exactly the same object as p1. Modifying p2’s state will be visible through p1. This is called aliasing.

• Can be null: a reference variable can hold null, meaning “no object.” Attempting to call a method on null throws a NullPointerException at runtime.

• Equality has two meanings:

  • == compares references — are these the same object in memory?
  • .equals() compares values — do these objects represent the same logical value? (Behaviour depends on whether the class overrides equals.)

• Live on the heap: the object itself is always heap-allocated. The reference variable may live on the stack (if it is a local variable) or be a field of another heap object.

Memory Layout

• Stack: holds local variables (primitives and references) and method call frames. Fast allocation/deallocation (just move the stack pointer). Each thread has its own stack.
• Heap: holds all objects and arrays. Managed by the garbage collector. Slower allocation, but objects can outlive the method that created them.

A local variable of type int stores the integer value directly on the stack. A local variable of type Point stores a reference on the stack; the Point object’s fields (x and y, which are primitives) live inside the object on the heap.

Why the Distinction Matters

Parameter Passing

Java is pass-by-value, always. For primitives, the value is the number itself — the method receives a copy, and mutations to the parameter do not affect the caller’s variable. For references, the value is the reference — the method receives a copy of the reference, so it can mutate the object’s state, but it cannot make the caller’s variable point to a different object.

void increment(int x) { x = x + 1; } // does nothing to caller's variable

void move(Point p) { p.x = 10; } // mutates the caller's object

void reassign(Point p) { p = new Point(0, 0); } // does nothing to caller's reference

Null Handling

Only reference types can be null. Primitives are never null. This means:

Integer boxed = null;   // OK — Integer is a reference type
int primitive = null;   // Compile error — int cannot be null

Auto-unboxing a null Integer to int throws a NullPointerException.

String: A Special Reference Type

String is a reference type — it is a class — but it has several special behaviours:

• Immutability: once created, a String object’s character sequence cannot change. Methods like toUpperCase() and substring() return new strings rather than modifying the original.
• String pool: string literals (e.g. "hello") are interned — the JVM maintains a pool of unique string literals. String s1 = "hello"; String s2 = "hello"; results in s1 == s2 being true because they reference the same interned object.
• Concatenation operator: the + operator is overloaded for strings. Any non-string operand concatenated with a string is converted via its toString() method.
• StringBuilder: for repeated concatenation in loops, use StringBuilder to avoid creating many intermediate String objects.

String s1 = "hello";
String s2 = "hello";
String s3 = new String("hello");

s1 == s2;    // true — same interned object
s1 == s3;    // false — s3 is a new object, not from the pool
s1.equals(s3); // true — same character sequence

Why Conventions Matter

Java has a strong set of naming conventions that are universally followed in professional code. The Tripos explicitly marks adherence to these conventions — a solution that mixes Python’s snake_case with Java code will lose marks even if the logic is correct. Conventions also serve a deeper purpose: they signal the role of an identifier (class, method, variable, constant) without needing to read its declaration.

The Four Case Styles

PascalCase for Classes and Interfaces

Every class, interface, and enum name starts with a capital letter and capitalises the first letter of each subsequent word:

public class BankAccount { ... }
public interface Comparable<T> { ... }
public enum DayOfWeek { ... }

Class names should be nouns or noun phrases — they represent things. An interface often names a capability and may be an adjective: Runnable, Serializable, Comparable.

camelCase for Variables and Methods

Variable and method names start with a lowercase letter and capitalise subsequent words:

int studentCount = 0;
String firstName = "Ada";

public double calculateArea() { ... }
public boolean isValid() { ... }

Method names should be verbs or verb phrases — they represent actions. Common prefixes:

• get / set: accessor and mutator methods (the JavaBeans convention)
• is / has / can: boolean-returning methods (isEmpty(), hasNext(), canExecute())
• to: conversion methods (toString(), toCharArray())
• create / build / of: factory methods (createAccount(), of())

UPPER_SNAKE_CASE for Constants

A static final field whose value is immutable is treated as a constant:

public static final double PI = 3.141592653589793;
public static final int MAX_RETRIES = 3;
public static final String DEFAULT_TITLE = "Untitled";

The static final combination means the value belongs to the class, exists as a single copy, and cannot be reassigned. By convention, the name shouts its constancy with all-caps and underscores.

Meaningful Names

Variable names should describe what the variable stores, not how it is stored:

int d;                     // terrible — meaningless
int elapsedTimeInDays;     // clear but verbose
int daysElapsed;           // good balance of clarity and brevity

Method names should describe what the method does:

public void p(int x) { ... }             // terrible
public void process(int value) { ... }   // better but vague
public void validateInput(int age) { ... } // clear and specific

Single-Letter Names

The only generally accepted single-letter variable names are loop indices:

for (int i = 0; i < n; i++) { ... }
for (int j = 0; j < m; j++) { ... }

The convention is i, then j, then k for nested loops. Avoid using l (lowercase L) because it is easily confused with 1 (digit one).

Java Is Case-Sensitive

count, Count, and COUNT are three distinct identifiers. This compiles (but should never be written):

int count = 1;
int Count = 2;
int COUNT = 3;

Each declaration creates a separate variable. Conflating them in your head because “they’re the same word” is a common source of bugs.

Common Traps for Tripos

Mixing Python and Java Conventions

Python uses snake_case for variables and functions. Java uses camelCase. Writing this in Java is wrong:

int account_balance = 100;      // Python style — incorrect in Java
public void calculate_area() {} // Python style — incorrect in Java

The correct forms:

int accountBalance = 100;
public void calculateArea() {}

Using PascalCase for Variables

int AccountBalance = 100; // looks like a class name — incorrect

The compiler does not complain, but a human reader will mistake AccountBalance for a class. This is the kind of error Tripos “spot the mistake” questions test.

Forgetting That Acronyms Follow the Rules

String XMLParser;    // correct if it's a class
String xmlParser;    // correct if it's a variable
String parseXML();   // correct method name
int HTTPPort;        // preferred over HttpPort (treat HTTP as a unit)

Summary Table

Implicit Conversion: Widening

A widening conversion moves from a smaller (narrower) type to a larger (wider) type. No information is lost, so the compiler performs these conversions automatically — no explicit cast is needed.

The widening chain for numeric types:

byte → short → int → long → float → double

Additionally: char widens to int, and any integer type widens to float or double.

int i = 42;
long l = i;       // OK — int fits in long
double d = i;     // OK — int fits in double precisely (up to 2^53)
float f = 3.14f;
double d2 = f;    // OK — float fits in double

The compiler silently inserts the widening conversion. The assignment long l = i compiles as though you wrote long l = (long) i.

Watch for Float Widening

long to float is a widening conversion — float has a larger range than long — but float has only ~7 significant digits of precision. Widening a large long to float preserves the magnitude but may lose low-order bits:

long big = 123456789123456789L;
float f = big;   // compiles, but precision loss — f != big

Explicit Conversion: Narrowing

A narrowing conversion moves from a larger type to a smaller type. Information may be lost, so the compiler requires an explicit cast — the programmer must acknowledge the risk.

double d = 3.14159;
int i = (int) d;       // truncates: i == 3

long l = 300L;
byte b = (byte) l;     // overflow: 300 mod 256 = 44

float f = 5.7f;
int j = (int) f;       // truncates: j == 5 (not rounded)

Narrowing an integer truncates the high-order bits. Narrowing a floating-point value truncates the fractional part — it does not round to nearest (use Math.round() for that).

Truncation vs Rounding

double positive = 3.7;
double negative = -3.7;

int a = (int) positive;   // 3 (truncation toward zero)
int b = (int) negative;   // -3 (truncation toward zero)
long c = Math.round(positive); // 4 (rounds to nearest)
long d = Math.round(negative); // -4

Integer Division Trap

When both operands are integers, Java performs integer division — the result is an integer, and any fractional part is discarded. This is a classic source of bugs:

double result = 5 / 2;     // result is 2.0, not 2.5

Why? 5 and 2 are both int literals. Integer division yields 2. Only then is that 2 widened to 2.0 for assignment to double.

To get floating-point division, at least one operand must be a floating-point type:

double r1 = 5.0 / 2;       // 2.5
double r2 = 5 / 2.0;       // 2.5
double r3 = (double) 5 / 2; // 2.5

String Concatenation with +

The + operator is overloaded for strings. When one operand is a String, the other operand is converted to a String via toString(), and the two are concatenated:

String s = "Value: " + 42;          // "Value: 42"
String t = "Result: " + 3.14;        // "Result: 3.14"
String u = "Object: " + new Point(); // "Object: Point@1a2b3c" (or custom toString)

Concatenation is left-associative, which can produce surprising results:

String s = "Sum: " + 5 + 3;   // "Sum: 53" — ("Sum: 5") then + 3
String t = "Sum: " + (5 + 3); // "Sum: 8" — parentheses force addition first

In the first line, "Sum: " + 5 produces "Sum: 5" (a string), then + 3 concatenates again. In the second line, (5 + 3) evaluates to 8 first, then the string concatenation runs.

Wrapper Class Conversions

Each primitive type has a corresponding wrapper class that provides utility methods for conversion between strings and primitives.

String to Primitive

int i = Integer.parseInt("42");
double d = Double.parseDouble("3.14");
boolean b = Boolean.parseBoolean("true");
long l = Long.parseLong("123456789");

parseInt and friends throw a NumberFormatException if the string is not a valid representation.

Primitive to String

String s1 = Integer.toString(42);        // "42"
String s2 = Double.toString(3.14159);    // "3.14159"
String s3 = String.valueOf(42);          // "42" — works for any type
String s4 = "" + 42;                     // "42" — lazy concatenation trick

Autoboxing and Unboxing

Since Java 5, primitives are automatically boxed into their wrapper types and unboxed back:

Integer boxed = 42;          // autoboxing — Integer.valueOf(42)
int unboxed = boxed;         // auto-unboxing — boxed.intValue()

List<Integer> list = new ArrayList<>();
list.add(5);                 // autoboxing int to Integer
int value = list.get(0);     // auto-unboxing Integer to int

Autoboxing creates hidden overhead — each boxing allocates an Integer object on the heap. In performance-sensitive loops, prefer primitives.

Conversion Hierarchy Summary

          Widening (implicit, safe)
          ←←←←←←←←←←←←←←←←←←←
byte  →  short  →  int  →  long  →  float  →  double
                                   ↗
                               char

          Narrowing (explicit cast, may lose data)
          →→→→→→→→→→→→→→→→→→→

What var Does

var, introduced in Java 10, performs local variable type inference. The compiler deduces the static type of a local variable from the type of its initialiser. The programmer writes var instead of an explicit type declaration, and the compiler fills in the type at compile time.

var message = "Hello";          // infers String
var count = 42;                 // infers int
var price = 9.99;               // infers double
var names = new ArrayList<String>(); // infers ArrayList<String>

The compiled bytecode is identical to what it would be with explicit types. var is purely a convenience for the programmer — it does not introduce dynamic typing.

This Is Still Static Typing

This is a crucial point for Tripos: var does not make Java dynamically typed. The type is fixed at compile time, exactly as if you had written the type explicitly. You cannot reassign a var variable to a value of an incompatible type:

var x = 42;     // x is int
x = "hello";    // COMPILE ERROR: incompatible types: String cannot be converted to int

This is entirely different from JavaScript’s var or Python’s untyped variables. In those languages, the variable can hold any type at any time. In Java with var, the type is inferred once and enforced thereafter.

Where var Works

var can only be used for local variables with initialisers:

var s = "text";                          // OK — local variable with initialiser
for (var item : collection) { ... }      // OK — enhanced for loop
var result = switch (x) { ... };         // OK — switch expression (Java 14+)

Where var Does NOT Work

var cannot be used for:

• Fields (instance or static variables): the compiler needs the explicit type in the class declaration
• Method parameters: the method signature must declare parameter types explicitly
• Method return types: the return type is part of the method’s contract
• Uninitialised local variables: var x; is a compile error — there is nothing to infer from

class Example {
    var field = 42;          // COMPILE ERROR: var not allowed for fields

    public var compute() {   // COMPILE ERROR: var not allowed for return type
        return 42;
    }

    public void method(var x) { // COMPILE ERROR: var not allowed for parameters
        var y;                  // COMPILE ERROR: cannot infer type without initialiser
    }
}

When to Use var

Good Uses

var shines when the type is obvious from the right-hand side and writing it out adds no value:

var scanner = new Scanner(System.in);
var map = new HashMap<String, List<Customer>>();
var stream = files.stream().filter(f -> f.isFile());

The new keyword makes the type immediately clear to the reader. Similarly, factory methods with descriptive names (Files.newBufferedReader(...)) are self-documenting.

Bad Uses

var hurts readability when the type is not obvious:

var result = process(data);    // What type is result? Must look up process().
var x = getSomething();        // Completely opaque.

A reader should not need to navigate to the method signature to understand what type a variable holds.

Tripos Relevance

The exam may test your understanding that:

1. var is compile-time inference, not runtime dynamic typing
2. The compiler must be able to determine a unique, concrete type from the initialiser
3. var cannot be used for fields, parameters, or return types
4. The inferred type is the static type of the initialiser expression, not the runtime type of the object

Consider this case:

Animal pet = new Dog();
var pet2 = new Dog();

pet has static type Animal (the declared type of the variable). pet2 has static type Dog (the inferred type from new Dog()). This can affect which overloaded methods are called and which fields are visible.

Type Inference with Diamond Operator

Be careful with the diamond operator:

var list = new ArrayList<>();      // infers ArrayList<Object>, not ArrayList<String>

Without a type argument, the diamond defaults to Object. If you want a specific generic type with var, provide it:

var list = new ArrayList<String>();  // infers ArrayList<String>

What Arrays Are

An array in Java is a fixed-size, homogeneous, reference-type container that holds a sequence of elements of a single type, indexed from zero. Arrays are objects — they are allocated on the heap, and the variable holds a reference to the array object.

Declaration and Allocation

Arrays are declared by appending [] to the element type:

int[] numbers;         // preferred style — type[] variable
String[] names;        // an array of String references
Point[] points;        // an array of Point references

The alternative C-style syntax (int a[]) is legal but discouraged — it places the brackets on the variable name, suggesting (misleadingly) that int a[], b declares two arrays, when in fact b is just an int.

A declaration does not create the array — it only declares a reference. To allocate storage:

int[] numbers = new int[5];     // array of 5 ints, each defaulting to 0
String[] names = new String[3]; // array of 3 references, each defaulting to null

Allocation zeroes or nulls the elements: numeric types get 0 (or 0.0), boolean gets false, char gets '\u0000', and reference types get null.

Length

Every array has a length field — note, not a method call, no parentheses:

int[] data = new int[10];
int size = data.length;   // 10

length is final and cannot be changed. Once allocated, an array’s size is fixed for its lifetime. If you need a resizable sequence, use ArrayList.

Access and Mutation

Indexing is zero-based and uses square brackets:

int[] a = new int[3];
a[0] = 10;
a[1] = 20;
a[2] = 30;
int x = a[0];          // 10
a[1] = a[2];           // copy element 2 into element 1

Accessing an index outside [0, length-1] throws an ArrayIndexOutOfBoundsException at runtime. The JVM performs bounds checking on every array access.

Allocation Options

Explicit Size with Default Values

int[] a = new int[5];        // {0, 0, 0, 0, 0}
String[] s = new String[3];  // {null, null, null}

Array Initialiser Syntax

int[] a = {1, 2, 3, 4, 5};
String[] days = {"Mon", "Tue", "Wed", "Thu", "Fri"};

This is only valid when declaring a variable (or as part of an anonymous array expression). It cannot be used after the variable is declared:

int[] a;
a = {1, 2, 3};     // COMPILE ERROR — initialiser only valid in declaration
a = new int[]{1, 2, 3}; // OK — anonymous array creation

Arrays Are Reference Types

This is one of the most important facts for the Tripos: an array variable holds a reference to the array object on the heap.

int[] a = {1, 2, 3};
int[] b = a;

Now a and b refer to the same array object. Changing b[0] is visible through a[0] — they are aliases.

b[0] = 99;
System.out.println(a[0]);  // 99

Copying an Array

To get an independent copy, use Arrays.copyOf():

int[] a = {1, 2, 3};
int[] b = Arrays.copyOf(a, a.length);  // new array with same values
b[0] = 99;
System.out.println(a[0]);  // 1 — a is unaffected

System.arraycopy() provides low-level bulk copying. clone() creates a shallow copy (for arrays of primitives, this is fine; for arrays of references, the references are copied but the objects themselves are not duplicated).

Iterating Over Arrays

Index-Based For Loop

for (int i = 0; i < a.length; i++) {
    System.out.println(a[i]);
}

Enhanced For Loop (For-Each)

for (int element : a) {
    System.out.println(element);
}

The enhanced for loop is cleaner when you do not need the index. But you cannot modify the array contents through the loop variable (assigning to element changes the local copy, not the array element).

Multi-Dimensional Arrays

Java has no true multi-dimensional arrays. Instead, an “array of arrays” is used:

int[][] matrix = new int[3][4];   // 3 rows, each row is an int[4]

matrix is a reference to an array of int[] references, each of which refers to a row array. This means rows can have different lengths (jagged arrays):

int[][] triangle = new int[3][];
triangle[0] = new int[1];
triangle[1] = new int[2];
triangle[2] = new int[3];

Initialiser syntax for multi-dimensional arrays:

int[][] matrix = {
    {1, 2, 3},
    {4, 5, 6},
    {7, 8, 9}
};

Array Covariance

Java considers Dog[] to be a subtype of Animal[] (if Dog extends Animal). This is called array covariance and is a known design flaw — it permits code that compiles but fails at runtime:

Dog[] dogs = new Dog[3];
Animal[] animals = dogs;        // OK — arrays are covariant
animals[0] = new Cat();         // COMPILES but throws ArrayStoreException at runtime

The JVM inserts a runtime check when storing into an array of reference type to enforce that the element is actually compatible with the array’s component type. This issue is discussed more thoroughly in the generics notes, but the key takeaway: prefer ArrayList<Dog> over Dog[] when you need collection-style operations.

Common Tripos Traps

• Mutating through an alias: if two references point to the same array, a mutation through one is visible through the other — trace carefully in “what does this print” questions
• length is a field, not a method: a.length() is a compile error; a.length is correct
• Default values: uninitialised array elements have default values (0, false, null) — do not assume they contain anything meaningful
• Off-by-one: iterate from 0 to a.length - 1, not to a.length
• Null array elements: arrays of reference types are initially filled with null, and calling a method on a[i] will throw a NullPointerException if that element was never assigned

What Overloading Is

Overloading allows multiple methods in the same class (or a class and its superclass) to share the same name, provided their parameter signatures differ. The compiler resolves which method to call based on the number, types, and order of arguments at the call site.

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public double add(double a, double b) {
        return a + b;
    }

    public int add(int a, int b, int c) {
        return a + b + c;
    }
}

All three methods are named add, but they have different parameter lists: two ints, two doubles, and three ints. The compiler knows which one to call from the arguments provided.

The Rules

Overload resolution is determined solely by:

1. The number of parameters (arity)
2. The types of parameters
3. The order of parameter types

The method’s return type is not part of the signature for overload resolution. Neither are parameter names, access modifiers, or thrown exceptions.

Return Type Is NOT Sufficient

public int getValue() { return 42; }
public double getValue() { return 42.0; }

This is a compile error: getValue() is already defined. The compiler cannot distinguish these two methods because they have identical parameter lists (both have zero parameters). If the return type were part of the signature, the compiler would not know which method you wanted at the call site:

var x = getValue();  // Which getValue? Ambiguous.

How the Compiler Resolves Overloads

When the compiler encounters a method call, it searches for the most specific applicable overload:

1. Find all methods with the correct name
2. Discard those whose parameter count does not match
3. For each remaining candidate, check whether the arguments can be converted to the parameter types
4. Choose the most specific match — in cases of ambiguity, prefer the overload that does not require a widening conversion

public void foo(int x) { ... }
public void foo(double x) { ... }

foo(42);    // calls foo(int) — exact match
foo(3.14);  // calls foo(double) — exact match
foo(42L);   // calls foo(double) — long widens to double, not to int

The long argument 42L cannot narrow to int implicitly, so it widens to double and calls foo(double).

Constructor Overloading

Overloading is especially common with constructors. A class can provide multiple ways to create an instance:

public class Point {
    private double x;
    private double y;

    public Point() {
        this(0.0, 0.0);
    }

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public Point(Point other) {
        this(other.x, other.y);
    }
}

Three constructors, all named Point, distinguished by their parameters. The first constructor delegates to the second using this(0.0, 0.0) — more on this in the constructor overloading notes.

Overloading vs Overriding

This distinction is a frequent Tripos topic:

Consider:

class Animal {
    public void speak() { System.out.println("..."); }
}

class Dog extends Animal {
    @Override
    public void speak() { System.out.println("Woof"); }   // overriding

    public void speak(int times) {                          // overloading
        for (int i = 0; i < times; i++) {
            speak();
        }
    }
}

Dog.speak() overrides Animal.speak() — same signature. Dog.speak(int) overloads it — different parameter list.

No Standalone Functions

Java has no standalone functions like C or Python. Every method must belong to a class (or interface). Even main is a static method of some class. Utility functions go in classes like Math or Collections as static methods.

This reinforces the object-oriented principle that behaviour is always associated with a type. In practice, it means you will sometimes create “utility classes” — classes with only static methods that exist solely to hold functions — which is a pragmatic necessity but arguably a departure from pure OOP.

Common Traps

Ambiguous Overloads

public void process(int x, double y) { ... }
public void process(double x, int y) { ... }

obj.process(5, 10);   // COMPILE ERROR: ambiguous — both 5 and 10 are ints,
                       // and either could widen to double

Both overloads are equally specific, and neither is unambiguously the best match.

Autoboxing and Overloading

public void handle(Integer x) { ... }
public void handle(int x) { ... }

handle(42);   // calls handle(int) — prefers primitive over boxing

The compiler prefers the primitive overload when both are applicable, because the exact match (no conversion at all) is more specific.

Varargs and Overloading

public void log(String msg) { ... }
public void log(String... msgs) { ... }

log("hello");   // calls log(String) — prefers non-varargs overload

The compiler prefers a fixed-arity overload over a varargs overload when both are applicable.

The Blueprint and the Instance

The relationship between a class and an object is analogous to a blueprint and a house:

• A class is the blueprint — it defines the structure (fields) and capabilities (methods) that objects will have, but it is not itself a usable entity. It describes what every instance will look like.
• An object is a concrete instance — it is built from the blueprint, occupies actual memory, and holds specific values for its fields. There can be many objects built from one class.

In programming terms: a class is a type, and an object is a value of that type. You can declare a variable of type String and assign it the value "hello". String is the class; "hello" is the object.

Creating Objects with new

Objects are created at runtime using the new keyword:

Point p = new Point(3, 4);

The new operator performs three actions:

1. Allocates memory on the heap for the object’s fields
2. Calls the constructor to initialise those fields to the desired values
3. Returns a reference to the newly created object

The returned reference is what gets stored in the variable p. The object itself lives on the heap; p is just a handle that lets us reach it.

Any number of objects can be created from a single class, each with its own copy of the instance fields:

Point a = new Point(1, 2);
Point b = new Point(5, 7);
Point c = new Point(0, 0);

a, b, and c are three distinct objects, each with its own x and y values. Changing a.x does not affect b.x.

The Box-and-Arrow Model

A useful mental model for reasoning about Java memory:

• A variable is a box. For a primitive type, the box holds the value itself. For a reference type, the box holds an arrow (reference) pointing to a heap object.
• The heap object is a separate region of memory containing the object’s fields (which may themselves be boxes with values or arrows).

When you assign one variable to another:

• For primitives, the value is copied. The two variables are independent.
• For references, the arrow is copied. Both variables now point to the same object (aliasing).

int a = 5;
int b = a;        // b gets a copy of the value 5
b = 10;           // a is still 5 — independent

Point p1 = new Point(3, 4);
Point p2 = p1;    // p2 gets a copy of the reference — same object
p2.x = 10;        // p1.x is now also 10 — aliased

Terminology

The course uses “object” and “instance” interchangeably. Both refer to a concrete entity created by new that belongs to a class. “Object” is the more common term; “instance” emphasises the relationship to the class (“this object is an instance of Point”).

Similarly, “fields,” “instance variables,” “attributes,” and “member variables” all refer to the variables declared inside a class that hold an object’s state. The course primarily uses “fields.”

Class vs Object Summary

Reflection: The Class as a Runtime Object

It is worth noting that the JVM represents classes themselves as objects of type Class. When you write obj.getClass(), you get a Class object that describes the class of obj. This is an advanced topic, but it reinforces the idea that even classes are reified in the JVM. For the purposes of the Part IA course, think of the class as the compile-time description and the object as the runtime entity.

Anatomy of a Class

Every Java class is composed of several categories of members. A well-structured class typically contains, in order: fields, constructors, and methods. Here is a complete BankAccount example with full annotation:

public class BankAccount {
    private final String accountNumber;
    private double balance;
    private final String holderName;
    private static int nextId = 1;

    public BankAccount(String holderName) {
        this.accountNumber = "ACC-" + String.format("%04d", nextId);
        nextId = nextId + 1;
        this.holderName = holderName;
        this.balance = 0.0;
    }

    public BankAccount(String holderName, double initialDeposit) {
        this(holderName);
        this.balance = initialDeposit;
    }

    public void deposit(double amount) {
        if (amount <= 0.0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        this.balance = this.balance + amount;
    }

    public boolean withdraw(double amount) {
        if (amount <= 0.0) {
            return false;
        }
        if (amount > this.balance) {
            return false;
        }
        this.balance = this.balance - amount;
        return true;
    }

    public double getBalance() {
        return this.balance;
    }

    public String getAccountNumber() {
        return this.accountNumber;
    }

    public String getHolderName() {
        return this.holderName;
    }

    public String toString() {
        return "BankAccount[" + this.accountNumber
            + ", holder=" + this.holderName
            + ", balance=" + this.balance + "]";
    }

    public static int getNextId() {
        return nextId;
    }
}

Fields (Instance Variables)

Fields hold the state of an object. Each instance gets its own copy:

private final String accountNumber;
private double balance;
private final String holderName;

• private makes them inaccessible from outside the class — a core encapsulation choice
• final means the reference (or primitive value) cannot be reassigned after the constructor completes
• Field names follow camelCase convention

Fields that do not change after construction are marked final to enforce immutability of that aspect of the object’s state.

Constructors

Constructors are special methods that initialise a new object. They share the class name, have no return type (not even void), and are invoked with new:

public BankAccount(String holderName) {
    this.accountNumber = "ACC-" + String.format("%04d", nextId);
    nextId = nextId + 1;
    this.holderName = holderName;
    this.balance = 0.0;
}

The constructor’s job is to establish the class invariant — the set of conditions that must hold for every valid object. For a BankAccount, invariants might include: balance >= 0, accountNumber is non-null and unique, holderName is non-null.

Constructor body pattern: initialise final fields, assign remaining fields, increment any shared static counters. A constructor should leave the object in a consistent, usable state.

The this Keyword

this refers to the current instance — the object on which the method was called. Three uses:

1. Disambiguating parameter names from field names: this.balance = balance; — without this, balance = balance would assign the parameter to itself
2. Passing the current object: someMethod(this) — handing a reference to yourself to another method
3. Constructor chaining: this(holderName) — calling another constructor of the same class

Not every method needs this — you can write balance instead of this.balance when there is no local variable with the same name. However, using this consistently for field access makes the code’s intent clearer.

Methods (Instance Methods)

Instance methods define the behaviour of objects. They are called on an object reference using dot notation:

BankAccount account = new BankAccount("Ada");
account.deposit(100.0);
double bal = account.getBalance();

A method has:

• An access modifier (public, private, etc.)
• A return type (or void if nothing is returned)
• A name (camelCase, typically a verb or verb phrase)
• A parameter list (enclosed in parentheses)
• A body (enclosed in braces)

Inside an instance method, this refers to the object the method was called on.

Accessors (Getters) and Mutators (Setters)

public double getBalance() {     // accessor — reads state
    return this.balance;
}

public void setBalance(double b) { // mutator — writes state
    this.balance = b;
}

Accessors retrieve field values without exposing the field directly. Mutators modify state with the opportunity to validate. Not every field needs a setter — accountNumber is final and has only a getter.

toString()

toString() returns a human-readable representation of the object. It is called implicitly when an object is concatenated with a string or passed to System.out.println():

System.out.println(account);

If you do not override toString(), the default implementation (inherited from Object) returns something like BankAccount@1a2b3c4d — the class name followed by the hash code in hex. Always override toString() for debuggability.

equals()

equals(Object other) compares two objects for logical equality. The default implementation from Object uses reference equality (==). Override equals() when you want objects to be compared by their field values rather than by their identity. A proper equals() override must satisfy the contract: reflexive, symmetric, transitive, consistent, and equals(null) returns false. The companion method hashCode() must also be overridden.

The Class Invariant

The class invariant is a logical condition that must be true for every valid instance, at all times that the object is accessible from outside the class. In BankAccount:

• balance >= 0.0
• accountNumber is non-null and formatted correctly
• holderName is non-null

Constructors establish the invariant. Every public method preserves it. Private helper methods may temporarily break it, but the public methods that call them must restore it before returning. A well-designed class never lets an external observer see a broken invariant.

Multiple Ways to Construct

A class often needs to support different ways of creating an instance. Constructor overloading provides multiple entry points for initialisation, each with a distinct parameter list.

public class Temperature {
    private final double celsius;

    public Temperature(double celsius) {
        this.celsius = celsius;
    }

    public Temperature() {
        this(0.0);
    }

    public Temperature(Temperature other) {
        this(other.celsius);
    }
}

Three constructors: one takes an explicit value, one creates a default (freezing point of water), and one is a copy constructor.

Constructor Chaining with this(…)

Constructor overloading is most useful when combined with constructor chaining: one constructor delegates to another using this(...) to avoid duplicating initialisation logic.

public class BankAccount {
    private final String accountNumber;
    private final String holderName;
    private double balance;
    private static int nextId = 1;

    public BankAccount(String holderName, double initialDeposit, String accountNumber) {
        this.holderName = holderName;
        this.balance = initialDeposit;
        this.accountNumber = accountNumber;
        nextId = nextId + 1;
    }

    public BankAccount(String holderName, double initialDeposit) {
        this(holderName, initialDeposit, "ACC-" + String.format("%04d", nextId));
    }

    public BankAccount(String holderName) {
        this(holderName, 0.0);
    }
}

The three-argument constructor is the “full” constructor — it does all the real work. The two-argument constructor delegates to it with a generated account number. The one-argument constructor delegates to the two-argument version with a default deposit of 0.0. The initialisation logic lives in one place.

The First-Statement Rule

A call to this(...) — or to super(...) — must be the first statement in a constructor body. You cannot put any other code before it:

public BankAccount(String holderName) {
    System.out.println("Creating account...");  // COMPILE ERROR
    this(holderName, 0.0);                      // this(...) must be first
}

The reason: the JVM must initialise the object’s state through the constructor chain before any instance-specific logic runs. The delegated-to constructor will initialise the fields; code before the delegation might access uninitialised state.

The Default Constructor

If you write a class with no constructors at all, the Java compiler automatically provides a default no-argument constructor:

public class Point {
    private int x;
    private int y;

}

Point p = new Point();   // OK — default constructor exists

This implicitly supplied constructor is public, takes no arguments, and initialises all fields to their default values (0, false, null).

However, once you write any constructor, the default constructor disappears:

public class Point {
    private int x;
    private int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

}

Point p1 = new Point(3, 4);  // OK
Point p2 = new Point();       // COMPILE ERROR — no no-arg constructor

If you need both a no-arg constructor and a parameterised one, you must write both explicitly.

Common Constructor Patterns

The Full Constructor + Convenience Pattern

Write one constructor that accepts all fields, then define convenience constructors that supply defaults:

public class Person {
    private String name;
    private int age;
    private String email;

    public Person(String name, int age, String email) {
        this.name = name;
        this.age = age;
        this.email = email;
    }

    public Person(String name, int age) {
        this(name, age, "[email protected]");
    }
}

The Copy Constructor

A copy constructor creates a new object from an existing one, copying its state:

public Person(Person other) {
    this(other.name, other.age, other.email);
}

This is a shallow copy — the fields are copied directly. For mutable fields (e.g. arrays, collections), a deep copy might be needed to achieve full independence. See the encapsulation and immutability notes for defensive copying.

The Static Factory Method Alternative

Sometimes, factory methods are clearer than constructor overloading because they can have descriptive names:

public static Temperature fromFahrenheit(double fahrenheit) {
    return new Temperature((fahrenheit - 32.0) * 5.0 / 9.0);
}

public static Temperature fromKelvin(double kelvin) {
    return new Temperature(kelvin - 273.15);
}

Constructors must share the class name; factory methods can express intent through their names. This is discussed further in the static methods notes.

Constructor Invocation Order

When an object is created, the JVM follows a specific sequence:

1. Memory is allocated for all fields (instance and inherited)
2. Fields are initialised to their default values (0, false, null)
3. Field initialisers (int x = 5;) and initialisation blocks run, in source order
4. The constructor body executes

If the constructor calls this(...), step 4 chains to another constructor’s step 4. If it calls super(...) (explicitly or implicitly), the superclass constructor runs first.

Common Tripos Traps

• Default constructor disappears: adding any constructor removes the automatic no-arg constructor. If a subclass constructor does not explicitly call super(...), the compiler inserts super() — which fails if the superclass has no no-arg constructor.
• this(…) not first: placing any statement before this(...) or super(...) is a compile error.
• Recursive constructor call: public Foo() { this(); } — infinite recursion, compile error (the compiler detects this).
• Return type on constructor: public void BankAccount() { ... } — this is not a constructor, it is a regular method with the same name as the class (legal but never correct).

Class-Level State

A static field belongs to the class itself, not to any particular instance. There is exactly one copy of the field, shared by all instances of the class (and accessible even when zero instances exist).

public class Spaceship {
    private static int shipsCreated = 0;
    private String name;

    public Spaceship(String name) {
        this.name = name;
        shipsCreated = shipsCreated + 1;
    }

    public static int getShipsCreated() {
        return shipsCreated;
    }
}

Every Spaceship constructor increments the same shipsCreated counter. The counter tracks a class-wide property: how many spaceships have been created. No individual spaceship owns it.

Accessing Static Fields

Static fields are accessed through the class name, not through an instance reference:

int count = Spaceship.getShipsCreated();   // preferred

Java also allows accessing static members through an instance reference (someShip.getShipsCreated()), but this is misleading — it suggests the field belongs to the instance. The compiler silently replaces the reference with the class name. Modern IDEs warn about this.

From within the class itself, you can use the bare field name (shipsCreated) or qualify with the class name (Spaceship.shipsCreated). Using the class name makes the static nature explicit.

Static vs Instance Fields

Static Final Constants

A static final field with a compile-time constant value is Java’s mechanism for named constants:

public class Math {
    public static final double PI = 3.141592653589793;
    public static final double E = 2.718281828459045;
}

public class Configuration {
    public static final int MAX_CONNECTIONS = 100;
    public static final String DEFAULT_LANGUAGE = "en";
}

These are public because they are part of the class’s interface — they are intended to be read by external code. They are final because they are constants. They are static because there is no reason for each instance to carry its own copy of a fixed value.

The naming convention for static final constants is UPPER_SNAKE_CASE.

Static Counters (Shared Mutable State)

The shipsCreated example above shows a counter: a static field that changes over time. This is shared mutable state — every part of the program that creates a Spaceship implicitly modifies the counter.

Shared mutable static state is powerful but dangerous:

public class IdGenerator {
    private static int nextId = 1;

    public static int generateId() {
        int id = nextId;
        nextId = nextId + 1;
        return id;
    }
}

This works fine in a single-threaded program, but in a multi-threaded program, two threads calling generateId() simultaneously could read the same nextId value, both increment it to the same number, and return duplicate IDs. The fix involves synchronisation (the synchronized keyword or AtomicInteger) — beyond the scope of the Part IA course, but worth knowing as the motivation for minimising mutable static state.

Static Initialisation Blocks

Sometimes static field initialisation requires more than a simple expression. A static initialisation block runs once when the class is first loaded:

public class Config {
    public static final Map<String, String> defaults;

    static {
        defaults = new HashMap<>();
        defaults.put("host", "localhost");
        defaults.put("port", "8080");
        defaults.put("timeout", "30");
    }
}

The static { ... } block runs when the class is initialised, before any static field is accessed or any instance is created. Multiple static blocks run in source order.

Pitfalls and Traps

The Instance-Accessing-Static Illusion

Spaceship s = null;
int count = s.shipsCreated;   // COMPILES and works! Does not throw NullPointerException.

This is a trap. The compiler sees that shipsCreated is static and replaces s.shipsCreated with Spaceship.shipsCreated. The value of s (even null) is irrelevant. Never write this — it confuses readers.

Static State Survives Object Creation

Static fields persist across the program’s lifetime. If a test sets a static flag and does not reset it, subsequent tests may see the stale value. This is why good test frameworks run tests in isolation and why mutable static state is minimised in well-designed systems.

Shadowing

A local variable or parameter can shadow a static field:

public class Example {
    private static int value = 10;

    public void method(int value) {
        System.out.println(value);      // parameter, prints argument
        System.out.println(Example.value); // static field, prints 10
    }
}

Using the class name to qualify resolves the ambiguity.

What Static Methods Are

A static method belongs to the class, not to an instance. It is called on the class name and has no implicit this reference. This means a static method cannot directly access instance (non-static) fields or call instance methods — there is no “current object” to operate on.

public class MathUtils {
    public static double average(double a, double b) {
        return (a + b) / 2.0;
    }
}

double result = MathUtils.average(10.5, 20.3);

No MathUtils object is created. The method is called purely through the class.

The Static Context Rule

The most important rule about static methods — and a favourite Tripos trap — is:

From a static context, you can only reference other static members directly. To access instance members, you need an explicit object reference.

public class Counter {
    private int value = 0;                    // instance field
    private static int totalCount = 0;         // static field

    public void increment() {                  // instance method
        this.value = this.value + 1;           // OK — instance context
        totalCount = totalCount + 1;            // OK — static field accessible from instance
    }

    public static int getTotalCount() {        // static method
        return totalCount;                      // OK — static field
    }

    public static void reset() {               // static method
        value = 0;                              // COMPILE ERROR! Cannot access instance field
        this.value = 0;                         // COMPILE ERROR! No 'this' in static context
        increment();                             // COMPILE ERROR! Cannot call instance method
    }
}

The fix is to create an instance and call methods on it, or to make the method non-static:

public static void reset(Counter c) {
    c.value = 0;   // OK — explicit object reference provided
}

Common Uses of Static Methods

Utility Methods

Pure functions that operate only on their parameters and have no side effects are natural candidates for static methods. The JDK is full of examples:

Math.sqrt(16.0);
Math.max(3, 7);
Collections.sort(myList);
Arrays.copyOf(original, newLength);

These methods do not need object state — they are computational building blocks.

Factory Methods

A static method that creates and returns instances of a class is a factory method. This is often cleaner than overloaded constructors because the method name can describe intent:

public class LocalDate {
    public static LocalDate of(int year, int month, int day) {
        return new LocalDate(year, month, day);
    }

    public static LocalDate now() {
        return new LocalDate(/* current system date */);
    }

    public static LocalDate parse(String text) {
        return new LocalDate(/* parse from ISO format */);
    }
}

LocalDate today = LocalDate.now();
LocalDate birthday = LocalDate.of(2000, 3, 15);
LocalDate parsed = LocalDate.parse("2025-07-15");

Factory methods can also return subtypes, cache instances, or enforce invariants in ways that constructors cannot because constructors must always return a new instance of the exact class.

The main Method

public static void main(String[] args) must be static because the JVM calls it before any objects exist. There is no instance of the containing class at the moment the program starts — the JVM would have no object to call an instance method on.

Static Factories for Immutable Value Types

When a value type is immutable (like String or Integer), static factory methods can offer instance-controlled creation:

Integer.valueOf(42);    // may return a cached instance
Integer.parseInt("42"); // returns a primitive, not an Integer object

Contrast with Instance Methods

Static Import

The import static statement lets you use static members without qualifying them with the class name:

import static java.lang.Math.PI;
import static java.lang.Math.sqrt;

double circumference = 2 * PI * radius;
double root = sqrt(16.0);

Use sparingly — it can make code harder to read when the origin of a name is not obvious. import static org.junit.Assert.* is common in test code.

Common Tripos Traps

Static Method Overriding (Which Does Not Exist)

class Parent {
    public static void greet() {
        System.out.println("Hello from Parent");
    }
}

class Child extends Parent {
    public static void greet() {
        System.out.println("Hello from Child");
    }
}

Parent p = new Child();
p.greet();  // Prints "Hello from Parent" — static dispatch, not dynamic!

Static methods are resolved at compile time based on the declared type of the variable, not the runtime type of the object. The @Override annotation does not compile on static methods. This is called hiding, not overriding.

Calling Non-Static from Static

Every exam will test this in some form. If you see a static method attempting to access an instance field or call an instance method without an explicit object reference, it is a compile error.

The Implicit ‘this’ in Inner Classes

An inner (non-static nested) class has an implicit reference to the enclosing instance. Its methods can access the enclosing instance’s fields. But a static nested class has no such reference — it behaves like a top-level class and can only access static members of the enclosing class.

The Rookie Error

The God class (also called a “blob” or “monolith”) is a single class that attempts to do everything in the system. It parses input, performs computation, manages state, renders output, logs diagnostics, and handles all edge cases — all in one enormous file. It “works” in the narrow sense that the program produces correct output, but it is low-quality design.

Signs of a God Class

A class is likely a God class if:

• It has many unrelated fields: a BankingSystem class that contains customerName, interestRate, filePath, graphicsContext, and errorLogger is mixing concerns that belong in separate classes
• The name contains “Manager”, “Utils”, “System”, “Processor”, or “Handler”: these are often signs that the class does not represent a single well-defined concept but rather a grab-bag of operations
• It exceeds a few hundred lines of code: a well-designed class typically fits on one screen; a God class scrolls through dozens of pages
• Methods within it do not share state: parseConfig() and renderChart() both live in the same class but operate on entirely different data
• Changing one feature risks breaking unrelated features: modifying the database code corrupts the UI because everything is tangled together

Why It Happens

God classes arise naturally when a developer starts by writing a few lines of procedural code, and then keeps adding to the same class as new requirements arrive. Without deliberate decomposition, the class absorbs responsibility after responsibility until it becomes unmanageable.

The main method is a common birthplace: a developer puts the control flow logic directly in main, then adds helper methods to the same class, then adds fields that those methods need. The result is a class that is at once the entry point, the business logic, and the I/O layer.

Why It Is Bad

Hard to Understand

A new developer (or the original developer, six months later) must read the entire class to understand any single part of it. The class’s responsibilities are tangled; you cannot reason about parsing logic without also seeing rendering code interleaved.

Hard to Test

Testing a God class requires setting up every dependency it touches, even the ones irrelevant to the feature under test. If the class reads a file, writes to a database, and sends emails, then testing the calculation logic forces you to mock files, databases, and email services — or to write fragile integration tests.

Hard to Reuse

If you need the parsing logic in another program, you cannot extract it cleanly — it is coupled to rendering and database code through shared fields and helper methods. You must either copy-paste (creating duplication) or pull in the entire God class (bringing all its unrelated dependencies).

Hard to Modify

A change to one feature risks breaking others because the code is not separated by concern. The methods share mutable state through fields, and a seemingly innocent addition of a field can have cascading effects through methods that were never meant to see it.

The Alternative: Decomposition

Good OOP design distributes responsibility across small, focused, cooperating classes. Each class represents a single concept from the problem domain and communicates with others through well-defined interfaces.

Instead of one BankingSystem class that does everything:

┌─────────────────┐
│   God Class     │
│  - parseCSV()   │
│  - calculate()  │
│  - renderHTML() │
│  - logErrors()  │
│  - sendEmail()  │
└─────────────────┘

Decompose into cooperating classes:

┌──────────┐     ┌──────────────┐     ┌──────────────┐
│ CSVParser│────→│ BankAccount  │────→│ HTMLRenderer │
└──────────┘     └──────────────┘     └──────────────┘
                       │
                 ┌─────┴──────┐
                 │ ErrorLogger │
                 └────────────┘

Each class now has:

• A clear, single purpose
• Its own set of fields relevant only to its purpose
• Methods that all operate on those fields
• Independence from unrelated concerns

Benefits of Decomposition

• Easier to understand: you can read and comprehend one small class in isolation
• Easier to test: you can unit-test CSVParser with a string input, without involving databases or renderers
• Easier to reuse: CSVParser can be dropped into any project that needs CSV parsing
• Easier to modify: changing the HTML rendering does not touch the parsing or calculation code

The Principle

The antidote to the God class is the Single Responsibility Principle (SRP): a class should have one, and only one, reason to change. If you can identify multiple distinct reasons why a class might need modification, it has multiple responsibilities and should be split.

A useful heuristic: can you describe what the class does in one sentence without using the word “and”? “This class parses CSV files” — good. “This class parses CSV files, calculates account balances, renders HTML, and logs errors” — God class.

Is It Ever Acceptable?

In very small programs (under ~200 lines total), a single class may be pragmatic. The overhead of decomposition — extra files, interface definitions, wiring code — may not justify itself for a script that fits on one screen. But as soon as the program grows beyond a few hundred lines, or as soon as another person needs to read it, the God class becomes a liability.

The key insight: “works correctly” is not the same as “well-designed.” A God class may pass its tests today, but it creates maintenance debt that will be paid with interest every time the code is touched.

Why UML?

Unified Modeling Language (UML) class diagrams are a visual notation for describing the static structure of an object-oriented system. They show classes, their contents, and the relationships between them. For Tripos purposes, you do not need perfect UML syntax, but you must be able to communicate class structure and relationships clearly in diagrammatic form.

The Class Box

A UML class is drawn as a rectangle divided into three compartments:

Visibility Markers

Field Notation

visibility name : type

Examples:

- balance : double
+ PI : double
# name : String

For static members, underline the entry (or use {static} annotation). For abstract members, use italics or {abstract}.

Method Notation

visibility name(parameter : type, ...) : returnType

Examples:

+ deposit(amount : double) : void
+ getBalance() : double
- validate() : boolean

Relationship Types

UML defines several relationship types, each with a distinct notation:

Association (plain line)

A general relationship between two classes. Drawn as a solid line. Can be annotated with a label, role names, and multiplicity.

Directed Association (arrow)

Shows that one class knows about another but not necessarily vice versa:

Aggregation (hollow diamond)

A “has-a” relationship where the contained object can exist independently of the container. The hollow diamond is on the container side:

Books can exist without the library. If the library is destroyed, the books survive (conceptually).

Composition (filled diamond)

A stronger “has-a” relationship where the contained object’s lifecycle is tied to the container. The filled diamond is on the container side:

An engine is part of a car. If the car is destroyed, the engine is destroyed with it (conceptually — in Java, this means the containing object holds the only reference).

Inheritance / Generalisation (hollow triangle arrow)

An “is-a” relationship. The arrow points from the subclass to the superclass:

Realisation / Implementation (dashed hollow triangle)

A class implementing an interface:

Dependency (dashed arrow)

A “uses” relationship — one class uses another as a parameter, return type, or local variable, but does not hold a lasting reference:

Multiplicity

Numbers at the ends of associations indicate how many instances participate:

One order contains zero or more items; each item belongs to exactly one order.

Abstract Classes and Interfaces

Abstract class names are written in italics. Interface names are written in italics with the «interface» stereotype (guillemets):

Complete Example

A banking system in UML:

A BankAccount has zero or more Transaction objects (aggregation). SavingsAccount is a subclass of BankAccount (inheritance).

Tripos Advice

For exam questions that ask you to draw a class diagram:

1. Start with the class boxes — name and key fields/methods are sufficient; you do not need to list every member
2. Add relationship lines between classes that interact
3. Label relationships with multiplicity where it is important to the question
4. Show inheritance and interface implementation arrows clearly
5. Use visibility markers for fields that are relevant to the question’s concerns about encapsulation

You will not lose marks for minor UML syntax variations (solid vs dashed line thickness, exact arrowhead shapes). You will lose marks for missing relationships, wrong multiplicities, or incorrectly showing a “has-a” as an “is-a” (or vice versa).

Composition over Inheritance

Where inheritance models an “is-a” relationship (a Dog is an Animal), composition models a “has-a” relationship (a Car has an Engine). A class holds a reference to another class as a field, and delegates work to it through method calls.

public class Car {
    private Engine engine;       // Car has-a Engine
    private List<Wheel> wheels;  // Car has-a list of Wheels

    public Car(Engine engine) {
        this.engine = engine;
        this.wheels = new ArrayList<>();
    }

    public void start() {
        engine.ignite();         // delegation
    }
}

Car does not extend Engine — that would be nonsense (a car is not a kind of engine). Instead, Car holds a reference to an Engine and calls its methods.

Why Prefer Composition?

The maxim “favour composition over inheritance” comes from the seminal Design Patterns book (Gamma et al., 1994). The reasons:

Flexibility at Runtime

With inheritance, the class hierarchy is fixed at compile time. With composition, you can swap the composed object at runtime:

public class Car {
    private Engine engine;

    public void setEngine(Engine newEngine) {
        this.engine = newEngine;
    }
}

You can replace the engine without changing the car’s class. Inheritance cannot model this — you cannot change a Dog into a Cat at runtime.

Avoids Deep, Fragile Hierarchies

Inheritance creates tight coupling between subclass and superclass. A change to the superclass can silently affect all subclasses. Over time, as the hierarchy deepens, it becomes difficult to understand which class provides which behaviour and which methods are overridden where.

Composition keeps classes independent. The containing class depends only on the composed class’s public interface, not on its implementation details.

Better Encapsulation

Inheritance exposes the superclass’s protected members to subclasses, breaking encapsulation (the “subclassing for implementation” problem). Composition keeps the composed object as a private field — the containing class controls exactly what is exposed and how.

Multiple Compositions

A class can compose multiple objects but can only extend one superclass. If you need functionality from two sources, composition lets you hold references to both:

public class Smartphone {
    private Screen screen;
    private Battery battery;
    private Camera camera;
    private List<Sensor> sensors;
}

A Smartphone is not a Screen or a Battery — it has them.

Aggregation vs Composition

UML distinguishes two flavours of has-a, which map to different design intentions in Java:

Aggregation (Weaker)

The contained object can exist independently of the container. If the container is destroyed, the contained objects may survive:

public class Library {
    private List<Book> books;

    public Library(List<Book> initialBooks) {
        this.books = new ArrayList<>(initialBooks); // books exist outside
    }
}

Books are created elsewhere and passed into the library. They have an identity and lifecycle independent of any particular library. A book can be in multiple libraries or in none.

Composition (Stronger)

The contained object’s lifecycle is tied to the container. The container creates and destroys the contained object:

public class House {
    private List<Room> rooms;

    public House() {
        this.rooms = new ArrayList<>();
        rooms.add(new Room("Kitchen"));
        rooms.add(new Room("Living Room"));
        rooms.add(new Room("Bedroom"));
    }
}

Rooms are created inside the House constructor and are never exposed to external code. When the House becomes unreachable, the Room objects become unreachable too (assuming no external references were leaked). The rooms cannot exist without the house.

In Java, the distinction is conceptual rather than enforced by language features. Both are implemented as fields holding references. The difference lies in how the references are managed: does the container create the object? Does it expose it externally? Does it accept objects from outside?

Real-World Example: Stack vs JDK Stack

The JDK’s java.util.Stack class extends Vector. This is a classic anti-pattern:

public class Stack<E> extends Vector<E> {
    public E push(E item) { ... }
    public E pop() { ... }
    public E peek() { ... }
}

Because Stack extends Vector, it inherits insertElementAt(), removeElementAt(), setElementAt(), and other methods that let you insert, remove, or modify elements at arbitrary positions. These operations silently violate the LIFO invariant of a stack. A stack should only allow pushing and popping from the top; a Vector inherited by Stack lets you insert into the middle.

The correct design uses composition:

public class Stack<E> {
    private List<E> elements = new ArrayList<>();

    public void push(E item) {
        elements.add(item);
    }

    public E pop() {
        if (elements.isEmpty()) {
            throw new EmptyStackException();
        }
        return elements.remove(elements.size() - 1);
    }

    public E peek() {
        if (elements.isEmpty()) {
            throw new EmptyStackException();
        }
        return elements.get(elements.size() - 1);
    }
}

Stack has-a List, rather than is-a Vector. The public interface exposes only push, pop, and peek. The LIFO invariant is now enforced by the API itself — there is no way for a client to insert into the middle because no such method exists.

When Inheritance Is Appropriate

Composition is not always the answer. Inheritance is appropriate when:

• The subclass genuinely is a more specific version of the superclass — a SavingsAccount truly is a BankAccount
• The subclass obeys the superclass contract — it satisfies the Liskov Substitution Principle (discussed in the inheritance notes)
• The subclass adds or refines behaviour without removing or contradicting superclass behaviour
• The class hierarchy is shallow and stable — deep hierarchies are a warning sign

The decision heuristic: if you find yourself overriding methods to throw UnsupportedOperationException or to make them do nothing, you are fighting the inheritance. Use composition instead.

The Principle

The Single Responsibility Principle (SRP) states:

A class should have one, and only one, reason to change.

Formulated by Robert C. Martin (Uncle Bob), this principle captures the idea that a class should be responsible to one — and only one — stakeholder or concern. If a class serves multiple masters, changes demanded by one will risk breaking functionality that the other depends on.

A “reason to change” corresponds to a distinct axis of change in the system. If the format of input data changes, the class that parses that data must change. If the database schema changes, the persistence class must change. These are separate reasons — they should live in separate classes.

An SRP Violation

Consider a class that mixes three unrelated responsibilities:

public class EmployeeReport {
    public List<Employee> loadFromFile(String path) {
        // parse CSV, handle I/O errors, build Employee objects
    }

    public double calculateAverageSalary() {
        // iterate over employees, compute statistics
    }

    public String renderAsHTML() {
        // generate HTML markup with inline styles
    }
}

This class has at least three reasons to change:

1. The file format changes (CSV to JSON, or new columns added) — loadFromFile must change
2. The calculation logic changes (median instead of mean, exclude part-timers) — calculateAverageSalary must change
3. The presentation format changes (HTML to PDF, or a new CSS framework) — renderAsHTML must change

Each of these changes could be requested independently. When they live in the same class, a change to the file format carries the risk of accidentally breaking the HTML rendering. A developer making a presentation change must read and understand the file-parsing code to avoid side effects. This is unnecessary cognitive load.

Applying SRP: The Split

Separate into three classes, each with one reason to change:

public class EmployeeLoader {
    public List<Employee> loadFromFile(String path) { ... }
}

public class SalaryCalculator {
    public double calculateAverageSalary(List<Employee> employees) { ... }
}

public class ReportRenderer {
    public String renderAsHTML(List<Employee> employees, double avgSalary) { ... }
}

Now:

• A file-format change touches only EmployeeLoader
• A calculation change touches only SalaryCalculator
• A presentation change touches only ReportRenderer

Each class is smaller, simpler, and can be tested in isolation.

Model-View-Controller (MVC)

MVC is an architectural pattern that applies SRP at the system level, separating an interactive application into three kinds of component:

User input ──→ Controller ──→ Model (update state)
                  ↑               │
                  │               ↓
                  └──── View ←────┘ (observe state)

Each component has a single responsibility. The model does not know how it is displayed. The view does not know how data is computed. The controller does not know how rendering works. This separation makes each part independently modifiable and testable.

Benefits of SRP

Easier to Understand

A class with one responsibility is small and focused. Its name describes its purpose. A developer can read it without needing to mentally filter out unrelated code.

Easier to Test

@Test
public void testAverageSalary() {
    SalaryCalculator calc = new SalaryCalculator();
    List<Employee> testData = List.of(
        new Employee("Alice", 50000),
        new Employee("Bob", 60000)
    );
    assertEquals(55000.0, calc.calculateAverageSalary(testData), 0.001);
}

Testing SalaryCalculator requires only employee data — no filesystem, no HTML templating. The test is fast, deterministic, and easy to write.

Easier to Reuse

SalaryCalculator can be used in a command-line tool, a web service, and a batch report, without dragging in dependencies on file I/O or HTML libraries.

Easier to Modify

When a class has one responsibility, the scope of any change is clear and bounded. You know exactly which class to modify and what the blast radius will be.

SRP vs God Class

SRP is the principle that directly opposes the God class anti-pattern. A God class is a class with many responsibilities; SRP says a class should have exactly one. The God class is what you get when SRP is ignored.

SRP and Cohesion

SRP and cohesion are closely related but distinct. SRP is about external reasons for change — who might ask for modifications? Cohesion is about internal relatedness — do the class’s members work together toward a single purpose?

A class can have high cohesion (all methods operate on the same data) but still violate SRP (the data represents multiple unrelated concepts that could change for different reasons). In practice, high cohesion correlates with SRP compliance, but the two concepts are conceptually different. The Tripos may ask you to distinguish them.

How Many Responsibilities Does a Class Have?

A practical test: describe the class’s purpose in one sentence. If the sentence contains the word “and” (describing unrelated activities), the class likely has multiple responsibilities.

• “This class loads employees from a CSV file and calculates salary statistics and renders HTML reports.” — three responsibilities.
• “This class loads employees from a file.” — one responsibility.

Another test: list the stakeholders who might request changes to the class. If multiple distinct groups (the DBA team, the UX team, the business analysts) have a stake in the same class, it has multiple responsibilities.

What Cohesion Measures

Cohesion measures how strongly the responsibilities within a single class belong together. It is a measure of internal consistency — do all the fields and methods of the class work toward a single, well-defined purpose?

• High cohesion (good): every field and every method contributes to the same goal
• Low cohesion (bad): the class is a random grab-bag of unrelated functionality, thrown together by convenience rather than by design

High Cohesion: An Example

public class BankAccount {
    private String accountNumber;
    private double balance;
    private String holderName;

    public void deposit(double amount) { ... }
    public boolean withdraw(double amount) { ... }
    public double getBalance() { ... }
    public String getSummary() { ... }
}

Every field is directly used by every method. deposit and withdraw manipulate balance. getSummary uses all three fields to produce a description. All members orbit around the single concept of “bank account.” This is high cohesion.

Low Cohesion: An Example

public class Miscellaneous {
    private String accountNumber;    // used by banking methods
    private double balance;
    private int portNumber;          // used by networking methods
    private String hostName;
    private File logFile;            // used by logging methods

    public void deposit(double amount) { ... }
    public boolean withdraw(double amount) { ... }
    public void connect() { ... }
    public void disconnect() { ... }
    public void writeLog(String message) { ... }
    public String formatCurrency(double value) { ... }
}

The fields and methods form three distinct clusters that do not interact with each other. deposit and withdraw use accountNumber and balance but never touch portNumber or logFile. connect uses portNumber and hostName but never touches accountNumber. writeLog uses logFile but nothing else.

This is low cohesion — the members do not belong together. The class should be split into BankAccount, NetworkConnector, and Logger.

Levels of Cohesion (from Strongest to Weakest)

The course draws on a classic taxonomy of cohesion types:

Functional Cohesion (Strongest — Best)

All parts of the class contribute to a single, well-defined function. Every field and method is necessary for the class’s purpose. Removing any member would break the class.

public class EmailValidator {
    public boolean isValid(String email) {
        return hasAtSymbol(email)
            && hasValidDomain(email)
            && hasNoInvalidCharacters(email);
    }

    private boolean hasAtSymbol(String email) { ... }
    private boolean hasValidDomain(String email) { ... }
    private boolean hasNoInvalidCharacters(String email) { ... }
}

Every private helper is directly used by isValid. There are no stray fields or methods. This is the gold standard.

Informational Cohesion (Strong)

The class operates on the same data structure or resource. All methods access the same set of fields.

public class Rectangle {
    private double width;
    private double height;

    public double area() { return width * height; }
    public double perimeter() { return 2 * (width + height); }
    public boolean isSquare() { return width == height; }
}

All methods use width and height. The class is bound together by its shared state — informational cohesion.

Sequential Cohesion (Moderate)

Methods are grouped because the output of one is the input of the next. Together they form a processing pipeline.

public class ReportGenerator {
    public List<String> readLines(File file) { ... }
    public List<Record> parseRecords(List<String> lines) { ... }
    public String formatReport(List<Record> records) { ... }
}

The methods form a chain, but they do not operate on shared instance state — each takes input and produces output. Sequential cohesion is acceptable but weaker than informational.

Temporal Cohesion (Weak)

Methods are grouped because they are all called at the same time — for example, during initialisation or cleanup.

public class Initializer {
    public void initDatabase() { ... }
    public void initLogger() { ... }
    public void initNetwork() { ... }
    public void initCache() { ... }
}

These methods share no data and perform unrelated tasks. They happen to be called together (at startup), but they belong in different classes (Database, Logger, NetworkManager, Cache). Temporal cohesion is a warning sign.

Logical Cohesion (Weak)

Methods are grouped because they seem to fall under the same category, even though they do different things:

public class IOHandler {
    public void readFile(String path) { ... }
    public void writeFile(String path, String content) { ... }
    public void sendHttpRequest(String url) { ... }
    public void queryDatabase(String sql) { ... }
}

“Yes, these are all I/O” — but file I/O, HTTP, and database access have nothing in common in terms of code, state, or error handling. This is a God class in the making.

Coincidental Cohesion (Worst)

The class is a dumping ground for unrelated utilities with no thematic connection:

public class Utils {
    public static int stringToInt(String s) { ... }
    public static double celsiusToFahrenheit(double c) { ... }
    public static String formatDate(Date d) { ... }
    public static boolean isPrime(int n) { ... }
}

These methods share nothing — no state, no purpose, no relationship. The only thing binding them is the filename Utils.java. This is the lowest form of cohesion.

SRP vs Cohesion

A class can have low cohesion (methods that do not share state) while technically having one responsibility (if the responsibility is defined broadly enough). Conversely, a class can have high cohesion (all methods work on the same data) while violating SRP (if that data serves multiple unrelated stakeholders).

In practice, they are deeply correlated: low-cohesion classes almost always violate SRP, and SRP violations almost always manifest as low cohesion. The distinction matters primarily for the Tripos, which may ask you to define each separately.

Achieving High Cohesion

Practical strategies:

1. Define one clear concept per class: if you cannot name the class with a single noun phrase, it is doing too much
2. Keep methods operating on the same core state: every method should read or write at least one of the class’s fields
3. Avoid convenience grouping: the fact that methods are called from the same place or at the same time is not a reason to put them in the same class
4. Extract classes when clusters emerge: if you notice that certain fields are only used by a subset of methods, those members are a candidate for a new class

What Encapsulation Is

Encapsulation has two related meanings:

1. Bundling: grouping data (fields) together with the methods that operate on that data, inside a single class
2. Information hiding: restricting direct access to an object’s internal representation and exposing only a controlled public interface

The first meaning is structural — it is how classes are designed. The second meaning is protective — it is why fields are private and why accessors exist.

public class BankAccount {
    private double balance;     // hidden — cannot be accessed directly

    public double getBalance() { // controlled access — read via getter
        return balance;
    }

    public void deposit(double amount) {  // controlled access — write via method
        if (amount <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
        this.balance = this.balance + amount;
    }
}

External code cannot write account.balance = -1000.0 because balance is private. It must go through deposit(), which validates the input. Encapsulation enforces the class invariant.

Why Encapsulate?

Protects Invariants

A class invariant is a condition that must be true for every valid instance. For a BankAccount, balance >= 0.0 is an invariant. If balance were public, any code could set it to a negative value, breaking the invariant. With a private field and a validating setter, invalid states become unrepresentable — they cannot occur because the only path to modifying balance checks the invariant first.

Decouples Clients from Representation

Deciding to store a temperature in Celsius vs Kelvin, or a date as a String vs a LocalDate, should not affect every piece of code that uses the class. If the field is private, you can change the internal representation without changing any client code — so long as the public interface (getters, methods) stays the same.

public class Temperature {
    private double kelvin; // changed from celsius to kelvin internally

    public double getCelsius() {
        return kelvin - 273.15; // clients never knew the representation changed
    }

    public void setCelsius(double c) {
        this.kelvin = c + 273.15;
    }
}

Centralises Validation

Validation logic lives in one place — the setter — rather than duplicated everywhere a field might be modified. If the validation rules change, you update one method, not every call site.

Access Modifiers

Java provides four levels of access control:

private

Accessible only within the same class. Use for all instance fields unless there is a compelling reason to do otherwise. Also use for helper methods that are implementation details.

private double balance;
private boolean validate(double amount) { ... }

Default (Package-Private)

No keyword — accessible from any class in the same package. Use when related classes in the same package need access but external code should not. The course will sometimes call this “package access” or “friendly access.”

class PackageHelper {        // class itself is package-private
    int internalValue;       // field is package-private
}

protected

Accessible from the same package and from subclasses (even in different packages). Use when you design a class for extension and want subclasses to access certain internals without exposing them to all clients.

protected double getInternalRate() { ... }

Protected access is a compromise: it allows subclass reuse but weakens encapsulation compared to private. A subclass in a different package can observe and modify protected members, creating coupling between the subclass and superclass implementation.

public

Accessible from everywhere. Use for the class’s public interface: constructors, public methods, and public constants. Any public member is a commitment — changing or removing it will break client code.

public static final int MAX_ATTEMPTS = 3;
public void processOrder(Order order) { ... }

Interface Members

Members declared in an interface are implicitly public. Fields in interfaces are implicitly public static final — they are constants, not instance variables. Methods are implicitly public abstract (unless default or static).

public interface Drawable {
    int DEFAULT_SIZE = 100;      // implicitly public static final
    void draw();                 // implicitly public abstract
}

You cannot make an interface method private (before Java 9), protected, or package-private — it would defeat the purpose of an interface as a public contract.

A Detailed Encapsulation Example

public class Temperature {
    private final double kelvin;
    private static final double ABSOLUTE_ZERO_CELSIUS = -273.15;

    public Temperature(double kelvin) {
        if (kelvin < 0.0) {
            throw new IllegalArgumentException(
                "Temperature cannot be below absolute zero"
            );
        }
        this.kelvin = kelvin;
    }

    public static Temperature fromCelsius(double celsius) {
        return new Temperature(celsius - ABSOLUTE_ZERO_CELSIUS);
    }

    public double getKelvin() {
        return this.kelvin;
    }

    public double getCelsius() {
        return this.kelvin + ABSOLUTE_ZERO_CELSIUS;
    }

    public double getFahrenheit() {
        return this.getCelsius() * 9.0 / 5.0 + 32.0;
    }

    public String toString() {
        return String.format("%.1f K (%.1f °C)", this.kelvin, this.getCelsius());
    }
}

The internal representation (Kelvin) is entirely private. Clients create temperatures via fromCelsius() or by passing Kelvin values. They read temperatures in any unit through getters. If the internal storage were changed from double to BigDecimal, no client code would need to change. The constructor validates the invariant — no temperature object can represent a value below absolute zero.

The Immutability Recipe

An immutable object is one whose state cannot change after construction. Immutability provides thread safety, safe sharing, and simpler reasoning. The recipe for making a class immutable:

1. Make the class final — prevents subclassing with mutable additions
2. Make all fields private final — prevents reassignment and external access
3. Provide no setter methods — no way to mutate state after construction
4. Defensively copy mutable fields in both the constructor and getters — prevents clients from modifying internal state through shared references

ImmutablePoint Example

public final class ImmutablePoint {
    private final double x;
    private final double y;

    public ImmutablePoint(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public double getX() { return this.x; }
    public double getY() { return this.y; }

    public ImmutablePoint translate(double dx, double dy) {
        return new ImmutablePoint(this.x + dx, this.y + dy);
    }
}

Notice that translate() does not modify the existing point — it returns a new ImmutablePoint. This is the functional-programming approach applied to objects. The original point is unchanged.

Defensive Copying for Mutable Fields

If a field is of a mutable type (e.g. Date, ArrayList, arrays), the immutable class must defensively copy it:

public final class Period {
    private final Date start;
    private final Date end;

    public Period(Date start, Date end) {
        this.start = new Date(start.getTime());  // defensive copy in constructor
        this.end = new Date(end.getTime());
    }

    public Date getStart() {
        return new Date(start.getTime());        // defensive copy in getter
    }

    public Date getEnd() {
        return new Date(end.getTime());
    }
}

Without the copy in the constructor, a caller could retain a reference to the passed-in Date and mutate it after construction, changing the “immutable” Period. Without the copy in the getter, a caller could mutate the returned Date and corrupt the internal state.

This is why java.util.Date is considered a poorly designed class — it is mutable. Modern Java uses the java.time classes (LocalDate, Instant, etc.) which are immutable and do not need defensive copying.

Benefits of Immutability

The JDK uses immutability extensively: String, the primitive wrapper classes (Integer, Double, etc.), BigInteger, BigDecimal, and the java.time classes are all immutable for these reasons.

Encapsulation and Inheritance

Inheritance can weaken encapsulation. A protected field is accessible to subclasses, which means changing it can break code in other packages. A private field with a protected getter gives somewhat more control, but the subclass still depends on the field’s existence.

The safest approach, when designing a class that will be extended: make all fields private and provide protected methods for the specific operations subclasses genuinely need. This keeps the representation hidden while allowing controlled extension.

The Stack

The stack is a region of memory that uses LIFO (last-in-first-out) discipline. Each thread in a Java program has its own private stack — stacks are never shared between threads.

When a method is called, the JVM pushes a stack frame onto the top of the calling thread’s stack. This frame contains:

• Local variables: primitives (int, double, boolean, etc.) are stored directly in the frame. For reference types, the frame stores the reference (a pointer to a heap object), not the object itself.
• Return address: where execution should resume when the method returns.
• Operand stack: intermediate values used during expression evaluation within the method.

When the method returns (normally or via an exception), its frame is popped off the stack and the memory is immediately reclaimed. No garbage collector is involved — the stack cleans up after itself automatically.

Key properties of the stack:

• Fixed size: each thread’s stack has a fixed size set at JVM startup (configurable with -Xss). Because the size is bounded, deep or unbounded recursion leads to a StackOverflowError.
• Fast: allocation and deallocation are simply pointer arithmetic — moving the stack pointer up to allocate a frame and down to free it. No scanning, no compaction, no free-list management.
• Thread-confined: data on a stack is only visible to the owning thread.

The Heap

The heap is a region of memory shared across all threads in the JVM process. Every object created with the new keyword is allocated on the heap.

Key properties of the heap:

• Shared: all threads can access heap objects (subject to reachability through references on their stacks).
• Managed by garbage collection: unlike the stack, heap objects are not freed when the method that created them returns. An object lives until it becomes unreachable — meaning no live thread holds a reference to it. The garbage collector (GC) periodically identifies and reclaims unreachable objects.
• Slower allocation: allocating on the heap involves more work than a stack push. The JVM uses sophisticated techniques (thread-local allocation buffers, bump-pointer allocation) to make it fast, but it is still fundamentally more expensive than stack allocation.
• Configurable size: the maximum heap size is set with -Xmx. The heap can grow up to this limit; if it runs out, OutOfMemoryError is thrown.
• Not bounded by call depth: objects on the heap persist across method returns, which is why you can return an object from a method and have the caller use it.

What Goes Where

Why This Distinction Matters

Parameter passing: when you pass an argument to a method, what gets copied into the callee’s stack frame is a primitive value or an object reference — never the object itself. This is fundamental to understanding Java’s pass-by-value semantics.

Recursion: each recursive call pushes a new frame. If the recursion is deep enough, the stack overflows even if the heap has plenty of space. Iterative solutions (loops) reuse the same frame and avoid this problem.

Garbage collection: the GC only manages the heap. Stack variables are the roots of reachability — if a reference to a heap object exists only on a popped stack frame, the object becomes eligible for collection (assuming no other references exist).

Escape analysis: the JVM may optimise short-lived objects by allocating them on the stack instead of the heap if it can prove they don’t “escape” the method. This is a JIT-compiler optimisation, not a language feature.

How the Call Stack Works

Every Java program starts execution with a main thread, whose stack begins with a frame for main(). Each method invocation pushes a new frame; each return pops that frame. The stack grows and shrinks continuously as the program runs.

Consider this simple program:

public class CallStackDemo {
    public static void main(String[] args) {
        int x = 3;
        int y = methodA(x);
        System.out.println(y);
    }

    static int methodA(int a) {
        int b = methodB(a * 2);
        return b + 1;
    }

    static int methodB(int p) {
        return p + 10;
    }
}

Frame snapshots during execution:

1. After main starts: one frame — main with args, x = 3, y uninitialised.
2. Calling methodA(3): methodA’s frame is pushed. It holds a = 3 (the parameter receives a copy of x), and b uninitialised. main’s frame waits underneath.
3. Calling methodB(6): methodB’s frame is pushed. It holds p = 6. main and methodA wait underneath.
4. methodB returns 16: its frame is popped. Execution resumes in methodA, which assigns b = 16.
5. methodA returns 17: its frame is popped. Execution resumes in main, which assigns y = 17.
6. main prints and returns: its frame is popped. The thread’s stack is now empty.

Recursion and the Stack

A recursive method calls itself. Each call pushes a new frame with its own copies of parameters and local variables.

static int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}

Calling factorial(5) pushes 5 frames: n=5, n=4, n=3, n=2, n=1. Each frame has its own n. When n=1 hits the base case, the frames unwind — factorial(1) returns 1, factorial(2) returns 2, and so on back up to the original call.

Every frame on the stack occupies real memory (a few hundred bytes typically). If the recursion goes deep enough, the stack runs out of space:

factorial(100_000);  // StackOverflowError

Even though the heap might have gigabytes free, the stack is small (typically 1 MB by default). This is why deep recursion fails while the equivalent loop succeeds:

static int factorialIterative(int n) {
    int result = 1;
    for (int i = 2; i <= n; i++) {
        result *= i;
    }
    return result;
}

factorialIterative(100_000) uses a single stack frame regardless of input size — it just loops, updating local variables in place.

Tail Recursion

A recursive call is in tail position if it is the very last operation in the method — nothing remains to be done after the call returns. Tail recursion can be rewritten to use an accumulator:

// Standard recursive — NOT tail-recursive (the multiplication happens after the call returns)
static int factorial(int n) {
    if (n <= 1) return 1;
    return n * factorial(n - 1);
}

// Tail-recursive version — the recursive call is the last thing
static int factorialTail(int n, int acc) {
    if (n <= 1) return acc;
    return factorialTail(n - 1, acc * n);
}

In factorialTail, after the recursive call returns, there is nothing left to compute — the returned value is immediately returned to the next frame up.

THE CRITICAL TRAP: Java Does NOT Guarantee Tail-Call Optimisation

In languages like OCaml and Scheme, tail calls are optimised by the compiler: the current frame is replaced by the callee’s frame, so tail recursion consumes constant stack space regardless of depth. This is called tail-call elimination (TCE) or tail-call optimisation (TCO).

Java does not mandate TCO. The JVM specification does not require it, and the standard HotSpot JVM does not implement it for Java code. This means:

// This WILL overflow for large n, even though it is tail-recursive
factorialTail(10_000, 1);  // StackOverflowError

Rewriting a recursive method to be tail-recursive in Java does not prevent StackOverflowError. It is a useful exercise for understanding the shape of recursion, but it does not change the runtime behaviour regarding stack consumption.

If a Tripos question asks you to “make this recursive method tail-recursive”, do so — but be prepared to note that this does not solve the stack overflow problem in Java.

Recursion vs Iteration: Choosing

Use recursion when the natural structure of the problem is recursive (tree traversal, backtracking) and the depth is bounded. Use iteration when the recursion would be deep and unbounded, or when a simple loop suffices.

What Is a Pointer?

In languages like C and C++, a pointer is a variable that holds a raw memory address — a numeric index into the process’s virtual address space. Pointers give the programmer direct, unmediated control over memory:

int x = 42;
int* p = &x;       // p holds the address of x
*p = 99;           // dereference: write through the pointer
p++;               // pointer arithmetic: now p points elsewhere
int* q = (int*)0;  // null pointer — raw zero

Because a pointer is essentially an integer, you can:

• Increment and decrement it (move to the next/previous object in memory)
• Subtract two pointers to find the distance between addresses
• Cast a pointer to a different type (telling the compiler to reinterpret the memory)
• Cast an integer to a pointer (or vice versa)
• Point into the middle of an object or array
• Free the memory and keep the pointer (a dangling pointer)

These operations are powerful but dangerous. They enable buffer overruns, use-after-free bugs, double-free bugs, type confusion, and arbitrary memory reads and writes — the root causes of most critical security vulnerabilities in C/C++ software.

What Is a Java Reference?

A Java reference is a managed, restricted handle to a heap object. It is implemented as a memory address under the hood, but the language and JVM enforce strict rules that prevent unsafe operations:

• No arithmetic: you cannot add to or subtract from a reference. It points at the start of an object and only at the start.
• No integer casting: you cannot cast a reference to int or long to obtain the underlying address.
• No arbitrary dereferencing: you cannot “follow” a reference to an arbitrary address. The only operation is field access and method invocation on a known type.
• No pointer into middle of object: a reference always designates an entire object, never a byte offset within it.
• No manual deallocation: you cannot free an object. The JVM’s garbage collector determines when an object is truly unreachable and reclaims it automatically.

The Box-and-Arrow Model

When reasoning about Java references, use the box-and-arrow model:

• A box is a variable (the space in a stack frame or inside an object on the heap).
• An arrow points from the box to an object on the heap.

    box                   heap object
  ┌───────┐            ┌──────────────┐
  │   s   │──────────→│   "hello"    │
  └───────┘            └──────────────┘