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.

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.

    Backlinks

      Warning. Encapsulation and defensive copying

      [comp1110-47]
      • Liam O'Connor

      Encapsulation means that the internal state of an object can only be changed through its defined methods. This is broken if a method returns a direct reference to an internal array or other mutable object, because the caller can then modify it from outside.

      The fix is to return instead a defensive copy: a fresh object with the same contents. The caller is then free to do whatever they like with the copy without affecting the internal state of the object.

      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.

      Warning. Type erasure

      [comp1110-4D]
      • Liam O'Connor, Fabian Muehlboeck

      Java generics are implemented via type erasure: at runtime, the type parameter T is erased to Object, so the expression new T[n] is illegal: the Java runtime has no idea what T is. Any generic class that needs an array internally must therefore either allocate an Object[] and cast values out of it appropriately, or somehow get an object that knows what to create:

      // Inside a generic class with type parameter T: private Object[] data; // must be Object[], not T[] @Override public T[] coming(Function<Integer, T[]> arrayCreator) { T[] result = arrayCreator.apply(count); int i=0; while(i < count) { result[i] = (T)data[i]; i = i + 1; } return result; }

      The casts inserted here work in practice as long as only values of type T are inserted — and this should be maintained through encapsulation — but it is a genuine limitation of how Java implements generics.

      Related

        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.

        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. Data invariants

        [comp1110-44]
        • Liam O'Connor

        A data invariant (also called a representation invariant) is a condition on the fields of a class that must hold after every constructor call and after every method call. It is not enforced by the compiler; it is the programmer's responsibility to maintain it.

        Data invariants document the assumptions an implementation relies on internally. Like loop invariants, they make it easier to reason about correctness: if every method both assumes the invariant holds on entry and ensures it holds on exit, then by induction it holds throughout the lifetime of the object.

        Construction. Methods

        [comp1110-83]
        • Fabian Muehlboeck

        So far, we have sometimes written code in separate functions from the main function. But in every case so far, we had to give those functions all the arguments that they were supposed to work with.

        Methods defined in a class implicitly have access to the fields defined in that class. This is because methods always need to be called on a specifc object, whose field values can then be used within the method.

        So in principle, writing a method is just like writing a function, except inside a class. Within the class, you can all other methods within the class just like we called functions before.

        By convention, in Java, method names are camelCased. That is, they start with a lower-case letter and otherwise contain only letters and digits, with uppercase letters indicating the start of a new combined word, as in sumOfAllParts.

        class MyClass { int myMethod() { return 42; } }
        bars magnifying-glass caret-down plus minus arrow-right xmark