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.

Context

    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.

    Related

      Warning. String comparisons

      [comp1110-0H]
      • July 30, 2026
      • Liam O'Connor, Fabian Muehlboeck

      If you are familiar with other programming languages, you might be wondering why we compared strings in Example [comp1110-0G] using a.equals(b) instead of something like a == b. While a == b is indeed the normal way to compare (e.g.) numbers, in Java equality for Strings is a little more complicated. In Example [comp1110-0G], a comparison answer == "yes" would always fail, even if the contents of answer were identical to the contents of the string "yes", because the two strings themselves have different identities, and exist at different locations in memory. Using the notation answer.equals("yes") instead compares the contents of the strings rather than their location, which is usually the functionality that we want.

      Definition. Enums

      [comp1110-2G]
      • Liam O'Connor, Fabian Muehlboeck

      An enum (short for enumeration) is a user-definable type whose values come from a fixed finite list. Instead of using arbitrary integers or strings, we define a small set of allowed values and give each one a name. For example:

      enum Month { JANUARY, FEBRUARY, MARCH, APRIL, MAY, JUNE, JULY, AUGUST, SEPTEMBER, OCTOBER, NOVEMBER, DECEMBER }

      This defines a new type called Month. A variable of type Month can only hold one of these twelve values. For example:

      Month m = Month.AUGUST;

      The names (which are by convention written in ALL_CAPS) inside the enum definition are called constants. They are always written with the type name in front, such as Month.JANUARY or Month.DECEMBER. This prevents confusion if different enums contain constants with the same name.

      Example. Inserting into a binary search tree

      [comp1110-2W]
      • Liam O'Connor, Fabian Muehlboeck

      Here BST is our example of a binary search tree type:

      BST insert(BST tree, int element) { if(tree == null) { return new BST(element, null, null); } if(tree.value <= element) { tree.right = insert(tree.right, element); return tree; } else { tree.left = insert(tree.left, element); return tree; } }

      The above code (almost) always modifies an existing tree. A more "functional" version that always creates a new (slightly modified) copy of the original tree would look as follows:

      BST insert(BST tree, int element) { if(tree == null) { return new BST(element, null, null); } if(tree.value <= element) { BST newRight = insert(tree.right, element); return new BST(tree.value, tree.left, newRight); } else { BST newLeft = insert(tree.left, element); return new BST(tree.value, newLeft, tree.right); } }

      Either version of the function ensures that the Data Invariant on the BST Definition is preserved.

      Reference vs. Value Equality

      [comp1110-1T]
      • Liam O'Connor, Fabian Muehlboeck

      The difference between value types and reference types explains the differences between == and other methods to decide equality.

      For value types, == happens to capture regular equality - for example, there are no two int values that represent the number 32 but are somehow different.

      On the other hand, for reference types, == describes reference equality, identifying whether two references point to the same object in memory. Since there may be two different objects representing the same value, == is too strict in many cases. We have seen this for String equality and Array equality. It is the same way in general for objects of arbitrary classes, except that for those, by default, no other notion of equality comparison exists. We'll see later how to define our own equality comparison.

      Finally, Enums are a special case: they are a reference type, but with a guarantee that each case of a Enum refers to the same object in memory. As such, comparing the references to Enum values using == is fine - as for ints, there are no two distinct values representing the same case.

      Understanding sorting

      [comp1110-1V]
      • Liam O'Connor

      Definition. A spec and a test suite for sorting

      [comp1110-1W]
      • March 10, 2026
      • Liam O'Connor

      Any in-place sorting algorithm, no matter how it is implemented, should satisfy the following spec:

      /** Sort an array in-place. There are two postconditions: - After executing, the array must be sorted. - After executing, the array must be some permutation of the values that existed before. (many programmers will get the former but forget the latter) @param arr the array to sort */ void sort(int[] arr)

      Assuming we had such a function, we might test it (using proper array comparison) as follows:

      void sortAndCheck (int[] toSort, int[] toCheck) { sort(toSort); assert Arrays.equal(toSort, toCheck); } void main (String[] args) { // already sorted sortAndCheck(new int[]{1,2,3,4,5,6,7,8,9}, new int[]{1,2,3,4,5,6,7,8,9}); // inversely sorted sortAndCheck(new int[]{9,8,7,6,5,4,3,2,1}, new int[]{1,2,3,4,5,6,7,8,9}); // random order sortAndCheck(new int[]{6,-5,212,42,19,0,0,5,9718}, new int[]{-5,0,0,5,6,19,42,212,9718}); // negative and inverse sortAndCheck(new int[]{-1,-2,-3,-4,-5}, new int[]{-5,-4,-3,-2,-1}); // empty sortAndCheck(new int[]{}, new int[]{}); // singleton sortAndCheck(new int[]{0}, new int[]{0}); // two sortAndCheck(new int[]{100,100}, new int[]{100,100}); }

      Definition. Quadratic sorting methods

      [comp1110-1X]
      • August 11, 2026
      • Liam O'Connor, Fabian Muehlboeck

      We demonstrated two sorting algorithms in the lecture:

      • Selection sort: We divide the array into an "unsorted zone" and a "sorted zone". The sorted zone begins empty at the start of the array, and the unsorted zone begins by occupying the whole array. Each loop iteration, we look through the unsorted zone, find the minimum, and swap it with the first element of the unsorted zone (right next to the sorted zone). This means that the sorted zone can be expanded by one element. Repeat until the unsorted zone is of size zero.
      • Bubble sort: Here, the "sorted zone" grows from the end of the array rather than the beginning. Loop through the unsorted zone comparing adjacent elements. If they are not in order, swap them. This will result in the highest element reaching the top. This means we can increase the size of the sorted zone. Repeat until all sorted.

        If we go through the unsorted zone without doing any swaps, we can immediately stop — the array is sorted. This is called an early exit trick.

      I briefly mentioned another one at the start of the workshop:

      • Insertion sort: The most popular of these three, and somewhat similar to selection sort, in that the sorted zone begins empty and grows from the left. Instead of finding the minimum, however, we take the first element from the unsorted zone and remember it (call it X) and shift everything greater than X in the sorted zone to the right one spot. Then we place X in the slot left over.

      These algorithms are called "quadratic" because they take a quadratic amount of key operations (in terms of the size of the array), in this case comparisons and moves/swaps to perform.

      While insertion sort is generally the most popular of the three, each of them have their own advantages, depending on your particular situation. On arrays:

      • Selection sort minimizes the number of times you have to move an array element.
      • Bubble sort only swaps adjacent elements and has an easy way to exit early on sorted arrays.
      • Insertion sort can minimize the number of comparisons that you do (these can become expensive on more complex data types).

      Which of these you actually get depends on the particulars of your implementation, and minor variations (say starting from the other direction) can make a huge difference for certain scenarios.

      Example. Selection sort

      [comp1110-1Y]
      • August 11, 2026
      • Liam O'Connor, Fabian Muehlboeck
       void selectionSort(int[] arr) { int i = 0; while(i < arr.length) { //INV : arr[0..i-1] is sorted AND for every j in // [i..arr.length-1], arr[j] >= every element // in arr[0..i-1] int currentMin = arr[i]; // could as well be always referred // to as arr[currentPos] int currentPos = i; int j = i + 1; while(j < arr.length) { //INT: arr[currentPos] is the minimum element in arr[i..j-1] if(arr[j] < currentMin) { currentMin = arr[j]; currentPos = j; } j = j + 1; } //arr[currentPos] is the minimum element in arr[i..arr.length-1] // from above, we know that it is greater than or equal to every // element in arr[0..i-1] int swap = arr[i]; arr[i] = arr[currentPos]; arr[currentPos] = swap; //therefore, swapping arr[currentPos] with arr[i] makes arr[0..i] // still sorted, and every element in arr[i+1..arr.length-1] // is >= every element in arr[0..i] . i = i + 1; } }

      Example. Bubble sort

      [comp1110-1Z]
      • August 11, 2026
      • Liam O'Connor

      Bubble sort swaps a lot of elements, but the key idea is that once it finds the maximum element in the unsorted part of the array, it keeps "bubbling" it up further and further, until we reach the end of the unsorted part, where a sorted array of elements larger than the new element is waiting. In that sense, it works like selection sort (either one of them could also just work in the other direction), but with more elements being moved around. We include the "early exit" trick mentioned by Definition [comp1110-1X]:

      void bubbleSort(int[] arr) { int i = arr.length - 1; while(i > 0) { // INV: arr[i..arr.length-1] is sorted, and // for every j in [0..i], arr[j] <= every element // in arr[i+1..arr.length-1] int j = 0; boolean swapped = false; while(j < i) { // INV: for every k < j, arr[k] < arr[j] // and if swapped == false, then arr[0..j-1] is sorted if(arr[j] > arr[j + 1]) { int swap = arr[j]; arr[j] = arr[j + 1]; arr[j+1] = swap; swapped = true; } j = j + 1; } // for every k < i, arr[k] < arr[i], and if // swapped == false, then arr[0..i-1] is sorted if(!swapped) { // at this point, both arr[0..i-1] and arr[i..arr.length-1] // are sorted, and we know that every element in // arr[0..i-1] is less than or equal to every element in // arr[i..arr.length-1]. hence, the whole array is sorted i = 0; } i = i - 1; } // arr[0..arr.length-1] is sorted }

      Definition. In-place

      [comp1110-20]

        An algorithm is in-place if only modifies existing structures, rather than create new ones. For example, for sorting an in-place function returns void, as they don't produce a new array, they just modify an old one. All our sorting algorithms in this section are in-place.

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