Abstraction

[comp1110-7Z]
  • Fabian Muehlboeck

Construction 1. Interfaces

[comp1110-3L]
  • Liam O'Connor, Fabian Muehlboeck

An interface is a reference type in Java that specifies a set of method signatures but does not provide their implementations. It serves as a contract: any class that implements the interface promises to provide the logic for those methods.

An interface is typically open: any number of classes can implement it across different parts of a codebase.

You cannot create instances of interfaces directly, they must always be objects of a class implementing the interface.

Example 2. Generalizing Accounts

[comp1110-8A]
  • Fabian Muehlboeck

Here is an interface describing the operations in Bank account class on a high level:

public interface Account { /** * @param amount >= 0 */ void deposit(int amount); /** * * @param amount <= getBalance() */ void withdraw(int amount); int getBalance(); }

This matches the structure of the public methods of the BankAccount class in Bank account class. That is a necessary, but not sufficient condition to be able to use Account to abstract over BankAccount. In Java, you need to explicitly declare that this is your intention, by adding an implements declaration to the definition of the BankAccount class:

class BankAccount implements Acount { ... }

With this declaration, the Java compiler will check that the class has a public method matching each of the signatures in the interface.

We can now write a method that deals with any form of Account:

void handleAccount(Account a) { IO.println(a.getBalance()); a.deposit(500); IO.println(a.getBalance()); }

The above method takes an Account object, prints its balance, deposits 500, and prints the balance again. This works fine with any BankAccount. In addition, it will also work with other kinds of accounts, such as the following one modelling a frequent flyer account:

public class PointsAccount implements Account { private int points = 10000; /** * * @param amount >= 0 */ public void deposit(int amount) { if(amount>0) { points = points + amount + amount/100; } } /** * * @param amount <= getBalance() */ public void withdraw(int amount) { if(amount<=points) { points = points - amount; } } public int getBalance() { return points; } }

This class behaves differently from a BankAccount. It starts with an opening balance of 10000 as a "new member bonus". In addition, whenever points are deposited, the member gets a 1The important thing here is that both kinds of accounts behave according the specification given by the Account interface, which only specifies preconditions and method signatures, both satisfied by both implementations.

Definition 3. Abstract Data Types

[comp1110-3P]
  • Liam O'Connor

Abstraction is the elimination of detail. In art, a realistic sketch of a bull captures every muscle and shadow, whereas an abstract version strips those away to convey the "bull" in a few lines. You lose specific texture but gain a universal representation.

In computer science, the interface is that line drawing. We eliminate the details of how data is stored and processed, instead defining a type, called an abstract data type or ADT, by the behaviour of the operations it supports alone. This separation of interface from implementation is a very powerful concept in programming. This allows the rest of the system to interact with the type abstractly, without regard to implementation details. This reduction of detail minimizes the mental load on the programmer and makes the code more flexible.

Construction 4. Inner Class

[comp1110-8B]
  • Fabian Muehlboeck

An inner class is a class defined within some other class, usually for the purpose of encapsulation. Inner classes have access to the private members of the enclosing class, and vice versa. Their objects must be constructed for a particular parent object of the enclosing class (this is implicit when creating the new instance from within an instance method of the parent class), so that accessing fields of the parent class makes sense.

Inner classes are often private, because in most cases the form part of the inner representation of a given class. They do not have to be, though in most cases where their objects would be access from outside of the parent class, they would still be private, but implement a public interface.

Example 5. The List ADT

[comp1110-8C]
  • Fabian Muehlboeck

One of the most standard abstract data types is that of a List. A list is an ordered collection of items - ordered means that there is an order to the items in the list, that is, there is a first item, a second item, and so on. The list is not necessarily "sorted". Lists may contain duplicate values. One can typically query the element at a particular index in the list, add elements to a list, remove elements from a list, and get the length of a list.

There are in fact multiple levels of abstraction. The above description applies to pretty much anything a computer scientist would call a "list". The ability to change the size of the list by adding or removing elements is the key thing that distinguishes lists from arrays (lists can be, and in many cases are, implemented using arrays). But the description is at a very high level, and leaves out certain details that vary a lot between different libraries and programming languages, for example whether lists are mutable entities or the above abstract operations construct a new, slightly changed copy of the original list every time.

In Java, the typical choice is for things to be mutable, and so a standard list interface might look as follows:

public interface List { int size(); Object getElement(int index); void add(Object o); void remove(Object o); }

This interface describes the above basic operations. Using void as the return type of the add and remove operations indicates that it is the particular list object itself that is changing when those methods are called. A more "functional" version of this code would return a new List object for those methods.

There are multiple ways to implement this interface. Here, we choose a linked list.

public class LinkedList implements List { class ListNode { Object value; ListNode next; ListNode(Object v, ListNode n) { value = v; next = n; } int size() { if(this.next==null) { return 1; } return 1 + this.next.size(); } void add(Object element) { if(next == null) { next = new ListNode(element, null); } else { next.add(element); } } ListNode remove(Object element) { if(Objects.equals(value, element)) { return next; } else if(next!=null) { next = next.remove(element); } return this; } } ListNode head = null; @Override public int size() { if (head == null) { return 0; } else { return head.size(); } } /** * * @param index < size() * @return */ @Override public Object getElement(int index) { try { ListNode current = head; while (index >= 0) { index = index - 1; current = current.next; } return current.value; } catch(NullPointerException e) { throw new IndexOutOfBoundsException(); } } @Override public void add(Object o) { if(head!=null) { head.add(o); } else { head = new ListNode(o, null); } } @Override public void remove(Object o) { if(head!=null) { head=head.remove(o); } } }

The above class implements our List interface. It uses an inner class to have a linked list implementation inside - the advantage for the user here is that they do not need to distinguish the base case from the recursive case themselves anymore, the list implementation does this for them. The methods in the class are implemented with a mix of recursion and iteration for demonstration purposes. In general, one should use iteration here in Java.

One can now write code using just the List interface. The only point at which the LinkedList class comes in is when the particular list object is constructed, though in that place, it could also be replaced with any other class implementing the List interface.

Context

    Lecture. Encapsulation and Abstraction

    [comp1110-2026s2-lec06a]
    • September 1, 2026
    • Fabian Muehlboeck

    Encapsulation

    [comp1110-7T]
    • Fabian Muehlboeck

    Construction. throwing exceptions

    [comp1110-3I]
    • Liam O'Connor, Fabian Muehlboeck

    When a method is asked to do something impossible, like depositing a negative amount or withdrawing more than the balance of an account, we throw an exception. Modifying Example [comp1110-3E]:

    public void deposit(int amount) { if(amount > 0) { balance = balance + amount; } else { throw new IllegalArgumentException(); } } public void withdraw(int amount) { if(amount <= balance) { balance = balance - amount; } else { throw new IllegalArgumentException(); } }

    There are many types of exceptions, and you can create your own, but often the built-in types are sufficient.

    • IllegalArgumentException: Used for invalid inputs (e.g., refilling a negative amount).
    • IllegalStateException: Used when the object is in an incorrect state for the requested action.

    Construction. Packages

    [comp1110-7U]
    • Fabian Muehlboeck

    A Java Package is a collection of Java files that belong together. Those Java files all start with a line that specifies the package:

    package fully.qualified.name.of.the.package;

    The above line specifies a package named package, which is nested in another package named the, and so on, with the outermost package's name being fully.

    Packages form a hierarchy that mirrors the hierarchy of the file system - all Java files belonging to a package are stored in the same folder, whose name matches that of the package, and subfolders of that folder may contain Java files of a sub-package. Conversely, the parent folders of the package folder must match the name of any enclosing packages, and so on.

    Package names are always written in lowercase, so they do not get confused with class names (which should always start with an upperclase letter). Most of the classes in Java's standard library are stored within an outmost package named java. For example, the Arrays class that contains methods to compare arrays for equality is contained in the package java.util. The fully qualified name of the package is java.util, and the fully qualified name of the class is java.util.Arrays.

    If you plan on creating libraries for wide-spread use, the convention is to use package names that start with the inverted top-level domain of your organization (or yourself). For example, any packages published by Google are sub-packages of the com.google package, and any packages that I would publish through ANU would start with au.edu.anu.comp. In general, packages prevent naming conflicts (consider how many different people have written classes named Person) - class names only need to be unique within a package. The fully qualified names can always be used to distinguish multiple classes with the same name.

    Files without a package declaration are in what is called the default package. Code in those files can access definitions in Java files in the same folder, and within explicit packages. However, no code in an explicit package can access code in the default package - that package is really only for small scale and ad-hoc code.

    When a class is within a package, you need to use the fully qualified name of the class to run a main method in it. For example, if you have a class Foo with a main method in the package bar.zorp, you need to call java as follows:

    java bar.zorp.Foo

    You also need to do this from the folder that contains the bar folder.

    Construction. Import Declarations

    [comp1110-7V]
    • Fabian Muehlboeck

    When a class is defined within an explicit package, you can always use its fully qualified name to use it. However, this gets annoying very quickly. Hence, you can use import declarations to import certain classes, which allows you to use them by their own (not fully qualified) name:

    import java.util.Arrays;

    Sometimes, you want to simply import every class in a particular package:

    import au.edu.anu.comp.comp1110.*;

    This construction is generally discouraged, because it can create naming conflicts if a new class is added to a package that conflicts with another name in your package or another imported package, even if you were not intending to use that class.

    Construction. Access Modifiers

    [comp1110-7W]
    • Fabian Muehlboeck

    Data type definitions (e.g. Enums and Class Definitions) and members may be given an access modifier. The following access modifiers exist in Java:

    • public - this means that the data type or member should be accessible by everyone, from anywhere.
    • private - this means that the data type or member should only be accessible from within the scope of the outermost enclosing context.
    • protected - this will be explained later and is not important for now.

    In addition to these modifiers, the meaning of not having a modifier at all is called package private. These data types or members are accessible from everywhere in the same package, as if they were public, but inaccessible from outside of that package, as if they were private.

    Access modifiers are about syntactic scope, that is, about how code is written and nested. In particular, any private field can be accessed from any code within the same class, not just from within the same object.

    Values vs. Entities

    [comp1110-3C]
    • Liam O'Connor, Fabian Muehlboeck

    Think of the number 5. If you add 1 to it, you don't "change" the 5; you simply produce to a completely different value, 6. The number 5 is immutable and has no identity other than its value. Enums behave like this, which is why you can compare them with ==. Strings, on the other hand, are immutable, but have identity, so there can be two String entities that represent the same text, but are different entities, and so == does not work.

    Now think about your bank account. If you deposit 100 dollars into your bank account, you don't get a new bank account, rather, your existing bank account is updated to reflect the new reality. This is also important when there are multiple people accessing the same bank account - they should see the same data, which would not be true if everyone kept creating new copies of it every time they change something. We saw this concept before when sorting arrays and when Inserting into a binary search tree.

    Example. Bank account class

    [comp1110-3E]
    • Liam O'Connor, Fabian Muehlboeck
     class BankAccount { //Data invariant: balance >= 0 private int balance; /** * @param initialDeposit >= 0 */ public BankAccount(int initialDeposit) { this.balance = initialDeposit; } public void deposit(int amount) { if (amount >= 0) { this.balance = this.balance + amount; } } public int getBalance() { return this.balance; } }

    In this snippet, the fiekd balance store the object's data, while the constructor defines how that data is initialised. The balance field uses the private access modifier, while the constructor and the two other methods are public.

    Definition. Encapsulation

    [comp1110-3F]
    • Liam O'Connor, Fabian Muehlboeck

    By marking fields as private, we hide the internal state. We then provide public methods (the interface) as the only way to interact with that state. This is important for two reasons:

    • Integrity - we can maintain data invariants about the object's internal state: properties that should be true before and after each call to a method on the object. For example, in Example [comp1110-3E],because balance is private, a user cannot write account.balance = -500;. They are forced to use deposit(), where we can include logic to ensure that the balance never goes negative. This enforces the data invariant that the account balance is always \(\geq 0\).
    • Abstraction - we can separate the interface (what methods are exposed to the public) from the implementation (the private fields and method implementations). This means that users of this class need only know about the interface, which reduces cognitive load on the programmer — essential for large programs. It also enables flexibility. For example, in Example [comp1110-3E], if we later decide to store the balance in a different currency or a different data type, we only change the code inside the class. Anyone calling getBalance() won't even notice the change.

    Definition. Getter

    [comp1110-3G]
    • Liam O'Connor

    In Example [comp1110-3E], our balance field is private, so we provide getter methods to allow the outside world to read the state without being able to write to it directly.

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

    Note that we do not provide a setBalance method. This ensures that the only way to change the balance is through valid actions like deposit().

    Definition. Setter

    [comp1110-7X]
    • Fabian Muehlboeck

    The counterpart to a getter is called a setter. This describes methods that take a parameter to set a particular property of an object.

    A setter may do a number of checks on the given value before accepting it, may reject it (either by not changing any state or by throwing an exception). Typical setters return void, but may also return the receiving object, the new value, the old value, or a value that indicates the success of the operation. Setters may also affect the state of any sort of related values in order to preserve data invariants.

    A setter does not necessarily have to store the given value directly somewhere, it may be that its representation changes. However, it is generally an expectation for a setter that a corresponding setter would, upon success, return the given value. As such, deposit in Bank account class is not a setter.

    Example. Setter

    [comp1110-7Y]
    • Fabian Muehlboeck

    The following would be a valid setter in Bank account class:

    /** * Sets the balance of the account * @param newBalance - the new balance, >= 0 * @return the old balance of the account, >= 0 */ public int setBalance(int newBalance) { if(newBalance < 0) { throw new InvalidArgumentException(); } int oldBalance = balance; balance = newBalance; return oldBalance; }

    However, for that specific data type, it is generally a bad idea to offer the possibility of arbitrarily changing the account balance to everyone.

    Abstraction

    [comp1110-7Z]
    • Fabian Muehlboeck

    Construction. Interfaces

    [comp1110-3L]
    • Liam O'Connor, Fabian Muehlboeck

    An interface is a reference type in Java that specifies a set of method signatures but does not provide their implementations. It serves as a contract: any class that implements the interface promises to provide the logic for those methods.

    An interface is typically open: any number of classes can implement it across different parts of a codebase.

    You cannot create instances of interfaces directly, they must always be objects of a class implementing the interface.

    Example. Generalizing Accounts

    [comp1110-8A]
    • Fabian Muehlboeck

    Here is an interface describing the operations in Bank account class on a high level:

    public interface Account { /** * @param amount >= 0 */ void deposit(int amount); /** * * @param amount <= getBalance() */ void withdraw(int amount); int getBalance(); }

    This matches the structure of the public methods of the BankAccount class in Bank account class. That is a necessary, but not sufficient condition to be able to use Account to abstract over BankAccount. In Java, you need to explicitly declare that this is your intention, by adding an implements declaration to the definition of the BankAccount class:

    class BankAccount implements Acount { ... }

    With this declaration, the Java compiler will check that the class has a public method matching each of the signatures in the interface.

    We can now write a method that deals with any form of Account:

    void handleAccount(Account a) { IO.println(a.getBalance()); a.deposit(500); IO.println(a.getBalance()); }

    The above method takes an Account object, prints its balance, deposits 500, and prints the balance again. This works fine with any BankAccount. In addition, it will also work with other kinds of accounts, such as the following one modelling a frequent flyer account:

    public class PointsAccount implements Account { private int points = 10000; /** * * @param amount >= 0 */ public void deposit(int amount) { if(amount>0) { points = points + amount + amount/100; } } /** * * @param amount <= getBalance() */ public void withdraw(int amount) { if(amount<=points) { points = points - amount; } } public int getBalance() { return points; } }

    This class behaves differently from a BankAccount. It starts with an opening balance of 10000 as a "new member bonus". In addition, whenever points are deposited, the member gets a 1The important thing here is that both kinds of accounts behave according the specification given by the Account interface, which only specifies preconditions and method signatures, both satisfied by both implementations.

    Definition. Abstract Data Types

    [comp1110-3P]
    • Liam O'Connor

    Abstraction is the elimination of detail. In art, a realistic sketch of a bull captures every muscle and shadow, whereas an abstract version strips those away to convey the "bull" in a few lines. You lose specific texture but gain a universal representation.

    In computer science, the interface is that line drawing. We eliminate the details of how data is stored and processed, instead defining a type, called an abstract data type or ADT, by the behaviour of the operations it supports alone. This separation of interface from implementation is a very powerful concept in programming. This allows the rest of the system to interact with the type abstractly, without regard to implementation details. This reduction of detail minimizes the mental load on the programmer and makes the code more flexible.

    Construction. Inner Class

    [comp1110-8B]
    • Fabian Muehlboeck

    An inner class is a class defined within some other class, usually for the purpose of encapsulation. Inner classes have access to the private members of the enclosing class, and vice versa. Their objects must be constructed for a particular parent object of the enclosing class (this is implicit when creating the new instance from within an instance method of the parent class), so that accessing fields of the parent class makes sense.

    Inner classes are often private, because in most cases the form part of the inner representation of a given class. They do not have to be, though in most cases where their objects would be access from outside of the parent class, they would still be private, but implement a public interface.

    Example. The List ADT

    [comp1110-8C]
    • Fabian Muehlboeck

    One of the most standard abstract data types is that of a List. A list is an ordered collection of items - ordered means that there is an order to the items in the list, that is, there is a first item, a second item, and so on. The list is not necessarily "sorted". Lists may contain duplicate values. One can typically query the element at a particular index in the list, add elements to a list, remove elements from a list, and get the length of a list.

    There are in fact multiple levels of abstraction. The above description applies to pretty much anything a computer scientist would call a "list". The ability to change the size of the list by adding or removing elements is the key thing that distinguishes lists from arrays (lists can be, and in many cases are, implemented using arrays). But the description is at a very high level, and leaves out certain details that vary a lot between different libraries and programming languages, for example whether lists are mutable entities or the above abstract operations construct a new, slightly changed copy of the original list every time.

    In Java, the typical choice is for things to be mutable, and so a standard list interface might look as follows:

    public interface List { int size(); Object getElement(int index); void add(Object o); void remove(Object o); }

    This interface describes the above basic operations. Using void as the return type of the add and remove operations indicates that it is the particular list object itself that is changing when those methods are called. A more "functional" version of this code would return a new List object for those methods.

    There are multiple ways to implement this interface. Here, we choose a linked list.

    public class LinkedList implements List { class ListNode { Object value; ListNode next; ListNode(Object v, ListNode n) { value = v; next = n; } int size() { if(this.next==null) { return 1; } return 1 + this.next.size(); } void add(Object element) { if(next == null) { next = new ListNode(element, null); } else { next.add(element); } } ListNode remove(Object element) { if(Objects.equals(value, element)) { return next; } else if(next!=null) { next = next.remove(element); } return this; } } ListNode head = null; @Override public int size() { if (head == null) { return 0; } else { return head.size(); } } /** * * @param index < size() * @return */ @Override public Object getElement(int index) { try { ListNode current = head; while (index >= 0) { index = index - 1; current = current.next; } return current.value; } catch(NullPointerException e) { throw new IndexOutOfBoundsException(); } } @Override public void add(Object o) { if(head!=null) { head.add(o); } else { head = new ListNode(o, null); } } @Override public void remove(Object o) { if(head!=null) { head=head.remove(o); } } }

    The above class implements our List interface. It uses an inner class to have a linked list implementation inside - the advantage for the user here is that they do not need to distinguish the base case from the recursive case themselves anymore, the list implementation does this for them. The methods in the class are implemented with a mix of recursion and iteration for demonstration purposes. In general, one should use iteration here in Java.

    One can now write code using just the List interface. The only point at which the LinkedList class comes in is when the particular list object is constructed, though in that place, it could also be replaced with any other class implementing the List interface.

    bars magnifying-glass caret-down plus minus arrow-right xmark