Overview #

In this tutorial we build on the observer tutorial Part 3, dive into Interfaces and work with the factory pattern - one of the Gang of Four creational patterns.

Scenario #

A NewsAgency shall be able to load news from a DataStore.

In general, the NewsAgency is not interested in a concrete implementation of the DataStore, the NewsAgency is only interested in the behavior respectively functionality of a DataStore.

Several DataStore implementations could be available, e.g., one DataStore implementation could read the new from a database, another DataStore implementation could read news from flat files.

Excursus: Classes and Interfaces #

Classes #

In object oriented programming, Classes are a means to declare a blueprint to build a specific type of Object. In other words, Objects built from a specific Class are an Instance of that Class and represent “something”. This “something” has some specific “behavior”. Such “behavior” is declared with Methods. Another word for Methods is also Operations because Methods operate on the State of a specific Object. The State of an object is declared with Properties. Another word for Properties is Attributes because an Object can remember its specific State with these Attributes. Properties respectively Attributes are also called Instance Variables. Methods respectively Operations can change the values of these Properties respectively Attributes respectively Instance Variables, and, in such, change the State of the Object respectively the Instance of the Class.

Example
Let us assume we work with cars. We create a class Car. A Car has the properties owner and locked. owner is assigned a string with the name of the owner of the car. locked can have the values true or false. Objects respectively instances of Cars are created with the constructor Car. The constructor initializes the instance variables to the default value. In this example, the default for locked is false. Moreover, the constructor has a parameter owner to hand in the name of the owner at time of object creation. The constructor initializes the instance variable owner at object creation by assigning the handed in value for owner to the instance variable owner. We declare the operations lock() and unlock().

lock() locks the car in that it assigns the instance variable locked the value true. In doing so, lock() changes the state of the object of that class because initially, before the fist call to lock(), the instance variable locked had the value false. In other words, lock() operates on the state of the object by changing the value of locked from false to true, or, assigning locked the value true is an operation on an object of Car. An Object of Car remembers its state, i.e., it remembers whether it is locked or not in the instance variable locked. The state of an object of Car can be queried with the method isLocked(). As a result, the instance variable locked is only operated on with the methods lock()and unlock(). The outside word “communicates” with objects of Car by calling the methods respectively the operations of Car.

public class Car {
    private final String owner;
    private boolean locked; 

    Car(String owner) {
        this.owner = owner;
        // isLocked does not to be initialized here 
        // because false is the default value of booleans.
        // Without any explicit initialization, instance
        // variables are always initialized with their 
        // default value at object creation.
    }

    public void lock() {
        this.locked = true; 
    }

    public void unlock() {
        this.locked = false; 
    }

    public boolean isLocked() {
        return this.locked; 
    }

}

Interfaces #

Interfaces are a means to declare a specific behavior or functionality that belongs together. In contrast to Classes, Interfaces cannot be instantiated, and hence, are not “something”. Rather, Interfaces just declare a wanted behavior respectively functionality for users of that interface. Classes can realize such behavior in that Classes implement Interfaces. By implementing Interfaces, Classes agree to comply with the contract of the respective implemented Interface. The contract of that interface is the description of the behavior intended with the declaration of that Interface. As a result, users of an Interface can trust that Classes that implement an Interface behave according to the contract.

Example
Let us continue with the example. We assume we also work with houses. We create a class Door. Similar to Cars, Doors have a property house which names the house they belong to. Also, Doors have a property locked which can be operated on with the methods lock() and unlock(). Moreover, Doors can report their state with isLocked().

public class Door {
    private final String house;
    private boolean locked; 

    Door(String house) {
        this.house = house;
        // isLocked does not to be initialized here, see Car above
    }

    public void lock() {
        this.locked = true; 
    }

    public void unlock() {
        this.locked = false; 
    }

    public boolean isLocked() {
        return this.locked; 
    }

}

Let us further assume we have a security service that visits houses and looks after cars to check wether the doors and cars are locked, and, if not, locks the doors and cars. The security service is not interested in whether the object to be controlled is a Car or a Door of a house. It is just interested in how to check if a Car or a Door is locked and how to lock them.

We can define this behavior with an Interface Lockable that declares the methods lock() and isLocked().

The contract specifies that the method lock() operates on the respective object to actually lock it. Moreover, the contract specifies that when the operation lock() is executed, the method isLocked() reports the state true. Hence, isLocked() serves as a proof that the lock() operation has succeeded successfully.

public interface Lockable {

    // locks down a lockable object so that no 
    // intruder can enter the object
    public void lock();

    // reports the state of a lockable object so that
    // users of the interface can check whether 
    // the object is locked and if the lock operation 
    // succeeded successfully
    public boolean isLocked(); 

}

We now can let Cars and Doors realize this interface. We then can declare a class SecurityService to have a list of Lockable objects to check and lock these objects.

public class Car implements Lockable {

    ...

}

public class Door implements Lockable {

    ...

}

public class SecurityService {

    private final List<Lockable> lockableObjects; 

    public SecurityService() {
        this.lockableObjects = new ArrayList<>();
    }

    public registerObject(Lockable lockableObject) {
        this.lockableObjects.add(lockableObject)
    }

    public checkAndLockObjects() {
        for (Lockable lockableObject : this.lockableObjects) {
            if !lockableObject.isLocked() {
                // TODO: log that the object was not locked 
                lockableObject.lock() 
            }
    }

}

... 

public static void main(String[] args) {

    ... 

    var door1 = new Door("8500 WILSHIRE BLVD, BEVERLY HILLS"); 
    var door2 = new Door("9400 BRIGHTON WAY, BEVERLY HILLS"); 

    ...

    var car1 = new Car("Leonardo"); 
    var car2 = new Car("Jennifer"); 
    var car3 = new Car("Johnny"); 

    ...

    var securityService = new SecurityService();
    securityService.registerObject(door1)
    securityService.registerObject(door2)
    securityService.registerObject(car1)
    securityService.registerObject(car2)
    securityService.registerObject(car3)

    ...

    securityService.checkAndLockObjects()

}

Please notice that Lockable does not declare the operation unlock() and hence is not able to unlock an already locked object.

By defining the interface Lockable we can follow the principle of Separation of Concerns and implement a clean separation of tasks into small, maintainable units of code.

Implementation #

We now can apply this knowledge about interfaces and Separation of Concerns to our current scenario. We declare an interface DataStore which can be realized by several distinct implementations. NewsAgency does not need to know about the concrete implementation, it just needs to know about the required behavior and can trust the contract of the DataStore interface to behave as agreed. Initialization code is then responsible to inject an instance that realizes the DataStore interface into NewsAgency.

...

var dataStore = new DatabaseDataStoreImpl("db connection string");
var reuters = new NewsAgency(dataStore, "reuters");

...

This principle is also called Inversion of Control. NewsAgency does not know how to instantiate a DataStore implementation. It just gets this implementation injected and can use it. This allows to decouple different parts of software and decompose a program into self-contained, reusable components.

It also allows to implement a mock implementation MockDataStoreImpl of a specific interface that allows to test NewsAgency without the need of a real database infrastructure.

MockDataStoreImpl can just implement some news in a list that is maintained in memory and return this list of news. The test code can then, e.g., check wether the predefined list of news is broadcasted to NewsChannel and NewsPaper instances. Test setup code just needs to instantiate a MockDataStoreImpl and inject this implementation into the NewsAgency class at creation.

...

var dataStore = new MockDataStoreImpl();
var reuters = new NewsAgency(dataStore, "reuters");

...

Overall, this results in following object diagram that is instantiated in main of the application.

Summary #

In this part we learned about Interfaces and their role in the Separation of Concerns and the Inversion of Control principle. We learned how to use these design principles to create self-contained, reusable, and maintainable software components.