Let's Have an Agreement

Step 1: Lather, Rinse, Repeat

Surely you noticed that for checking correctness of your progress when solving missions you need to repeat more and more operations after launching the application: creating required objects and connections between them, checking behaviour after calling methods. Alongside tediousness of the whole procedure there is also a risk that in real world without inspector you will find your way with problems. With a goal to avoid this situation we will now introduce means how to create scenarios for testing the mission directly in the code.

In the next tasks you will add actors to scene and plan actions for them from within this method. Effectively, you will write a scenario.

To add new actor into the scene you need to create instance of that actor (or already have one available) and place it into the scene on some position (i.e. define placement of bottom left corner of actor's animation relative to bottom left corner of scene's map).

Adding a reactor and turning it on can be implemented as follows:

Reactor reactor = new Reactor();
scene.addActor(reactor, 64, 64);
reactor.turnOn();

Check the implementation by running the application. Reactor should be placed on provided position and turned on right after the start.

You are already familiar with the action Invoke that can be used for turning a cooler on. In the game library also the action Wait is available, which accepts duration of waiting (in seconds) in its constructor. With these actions, we may try to solve the task as follows.

new Wait<>(5).scheduleFor(cooler);
new Invoke<>(cooler::turnOn).scheduleFor(cooler);

How would such scheduled actions work actually? The scene will call execute() methods of both of these actions before rendering each new frame. This means that the scheduled actions are executed concurrently. In this specific case we will not have the cooler turning on after the action Wait (that will take 5 seconds) finishes. Instead, the cooled will be turned on just after starting the application.

To solve this task, we need to ensure that the action for turning on the cooler is executed after the wait. To chain execution of multiple actions into a sequence we can use another library action - ActionSequence. This action takes a variable number of other actions as consturctor arguments and makes them execute sequentially. And we will schedule just this sequential action, not the wrapped actions.

new ActionSequence<>(
    new Wait<>(5),
    new Invoke<>(cooler::turnOn)
).scheduleFor(cooler);

To solve this task the action requires method repairWith() from reactor. This method expects one argument - a hammer. This allows us to showcase another way of specifying actions: as anonymous classes or lambda expressions.

Up until now you used the Invoke action with references to parameter-less methods. The actual signature of Invoke's constructor is:

public Invoke(Runnable action)

Runnable is a standard Java interface that specifies single method void run(). In combination with anonymous classes - classes written inside expressions where they are also instantiated in place - we could write the action for repairing reactor with hammer as:

new Invoke<>(new Runnable() {
    public void run() {
        reactor.repairWith(hammer);
    }
});

This code will produce an object of type Runnable with the given implementation of its run() method, which is given as argument to the Invoke constructor. This action then calls the run() method of the given object in its execute() method.

The notation of anonymous classes is quite noisy, given that we wanted to implement just one method. But as the Runnable interface is a functional interface - i.e. it defines single abstract method - we can shorten the code by writing it as lambda expression:

new Invoke<>(() -> {
    reactor.repairWith(hammer);
});

The result is same as in the previous example. The code produces a Runnable object (based on the type of Invoke's constructor parameter) with the run() method for which we gave the implementation.

For solving the other part of the task where we need to detect a moment when reactor's temperature reaches given value, we can use action When. Its first argument is a simple predicate, which an object of type Supplier<Boolean> with single abstract method boolean get() (this object can also be written as a lambda expression). The predicate is tested repeatedly and the first time it returns true, the action specified as the second argument to When's constructor is executed.

We can thus implement the required action as follows:

new When<>(
    () -> {
        return reactor.getTemperature() >= 3000;
    },
    new Invoke<>(() -> {
        reactor.repairWith(hammer);
    })
).scheduleFor(reactor);

And because the bodies of both lambda expressions are just single expressions, Java allows us to shorten the code even further:

new When<>(
    () -> reactor.getTemperature() >= 3000,
    new Invoke<>(() -> reactor.repairWith(hammer))
).scheduleFor(reactor);

Try to minimise usage of inspector by writing down several use cases of existing actors.

Step 2: Switchable

Up to now we could control only one type of devices (objects) with a switch. This time you will try to "persuade" and "make an agreement" also with other objects to control them. It is all just a question of what agreement in form of interface you offer them.

Signatures of methods in this interface and their meaning are as follows:

• void turnOn() - method will turn on controlled device
• void turnOff() - method will turn off controlled device
• boolean isOn() - method will return value representing state of device (true - device is turned on, false - device is turned off)

Methods that should be part of the interface are already in the class. Behaviour of method isOn() is implemented by method isRunning() so use refactoring to rename this method.

Use the refactoring feature in development environment when renaming the class.

Modify implementation of class PowerSwitch to provide the following public methods:

• getDevice() - provides a reference to connected device
• switchOn() - turns the connected device on
• switchOff() - turns the connected device off

getAnimation().setTint(Color.GRAY);

If these classes already have implementation of required methods, just add annotation @Override to them. If they have similar methods (functionality), rename them. However, if these methods do not exist, create them.

You will check your implementation by creating instances of classes listed above and creating switch for each of them to control them.

Step 3: Producer/consumer

Right now, reactor can power only devices that are instances of class Light. Your task is to prepare a proper "standard" for powering arbitrary devices (design compatible "sockets" and "plugs").

Interface EnergyConsumer will have only one method. Its signature and meaning is the following:

• void setPowered(boolean) - with this method, the energy supplier will notify devices about providing or not providing energy.

If you proceeded correctly the resulting functionality will not change much - light will still be the only appliance that can be connected. However, this time it will be seen by reactor not as object of type Light but as object of type EnergyConsumer.

Computer will work only in case it is powered by electricity. Otherwise it will not work (its animation will be paused and results of all calculations will be 0).

References to objects of those devices should be stored into a set. Use the following code to create it:

// declaration of instance variable for set of connected devices
private Set<EnergyConsumer> devices;

// instantiating a set in constructor
// (type parameter for HashSet is derived based on type of variable devices)
devices = new HashSet<>();

Adjust methods addDevice() and removeDevice() in class Reactor accordingly. For adding device to set use method call add() on object of set. Modify method removeDevice() to be parametric, with object in parameter being of type EnergyConsumer. To remove device from set use method call remove() in which parameter you will pass reference to specific object that should be removed from the set.

If you proceeded correctly, this time you will be able to connect to reactor not only instances of class Light but also instances of class Computer. The principle of polymorphism is manifested here by using interfaces.

Step 4: Useful generalization

As part of preparation for the real world it is surely necessary to focus on "cleaning up" the code and practising refactoring (changing the structure of already implemented code with preserved behaviour). Our case will regard generalisation of tools into usable actors and rotation of relationship between initiator of usage and used object. We will also use interface to distinguish group of actors that can be repaired.

Interface Usable will have a type parameter A that will be bound to subtypes of Actor:

interface Usable<A extends Actor> {
    // ...
}

Add to this interface one method with signature void useWith(A actor). Actor provided in parameter of method useWith() will serve to define the context of Usable actor's usage.

Adjust method use() from the original implementation of BreakableTool so that it will override method useWith() from interface Usable. Do not forget the annotation @Override.

By type parameter for BreakableTool specify type of actor with which specific tool can work (which it can repair; e.g. hammer can repair reactor).

In individual tools override implementation of method useWith() and perform appropriate correction.

Do not forget to modify methods for repairing reactor repairWith() and extinguishWith(), and now rename them to repair() and extinguish(), since repairing will be initiated by tools themselves (hammer and fire extinguisher). Use return value boolean with these methods to signalise success or failure of using the tool.

In the interface define method with signature boolean repair(). Return value will signify success or failure of the repair.

The repair of light (it will stop blinking) will last only 10 seconds, after which light breaks again.

Wrench should inherit from class BreakableTool and have 2 uses. Use image wrench for its graphical representation.

Step 5: Repository

Upload your implementation even if it's not yet complete. We recommend to comment out parts of the code that could cause compilation errors.