Interfaces and Lambda Expressions

An interface in Java is like a contract. It defines a set of method signatures (the names, parameters, and return types) that any class agreeing to implement that interface must provide. Before Java 8, interfaces could only contain abstract methods — methods with no body. That changed with Java 8, which introduced default methods (methods with a body inside the interface) and static methods (methods that belong to the interface itself, not to any instance). Default methods let you add new functionality to an interface without breaking all existing classes that already implement it. Static methods provide utility functions that relate to the interface concept.

To create an interface, you use the keyword interface instead of class. For example:

public interface Walkable {
    void walk(); // abstract method, no body
}

Any class that implements Walkable must provide a walk() method. A functional interface is a special type of interface that has exactly one abstract method. This is crucial because lambdas work only with functional interfaces. The @FunctionalInterface annotation is optional, but if you add it, the compiler will check that your interface really does have only one abstract method.

Lambda expressions give you a way to create an instance of a functional interface without writing a separate class. A lambda expression has three parts: the parameter list (in parentheses), an arrow token (->), and the body (an expression or a block of code). For instance:

Walkable w = () -> System.out.println("Walking...");

Here, the lambda () -> System.out.println("Walking...") is the implementation of the walk() method. The compiler knows that Walkable has one abstract method, so it matches the lambda to that method.

Default methods in an interface are declared with the default keyword and have a body. They are inherited by all implementing classes, but a class can override them if needed. This is useful when you want to add a method to an interface that many classes already implement — without forcing those classes to change.

Static methods in an interface are similar to static methods in a class. They are called using the interface name, like Walkable.someStaticMethod(). They are not inherited by implementing classes, so you cannot call them on an instance.

Lambda expressions also work with parameters. If your functional interface has a method that takes arguments, the lambda can accept them:

@FunctionalInterface
interface MathOperation {
    int operate(int a, int b);
}

MathOperation add = (a, b) -> a + b;

If the lambda body has more than one statement, you use curly braces and a return statement:

MathOperation complex = (a, b) -> {
    int result = a * b;
    return result + 10;
};

Type inference means you don't always need to declare the parameter types — the compiler can work them out from the context. But you can include them if you want clarity.

There are several built-in functional interfaces in the java.util.function package that you should know for the exam:

Lambdas can also access local variables from the enclosing scope, but only if those variables are effectively final — meaning they are not modified after being assigned. This is called variable capture.

Method references are a shorthand syntax for lambdas that just call an existing method. Instead of writing s -> System.out.println(s), you can write System.out::println. Method references come in four kinds:

Imagine you work as a junior developer at a logistics company. Your team is building a system that processes packages coming into a warehouse. The business rule is that packages can be handled differently depending on their size, weight, and destination. Your manager tells you that next month, a new client will have completely different handling rules, but you cannot rewrite the whole system each time.

You decide to use interfaces and lambdas to solve this. You create a functional interface called PackageProcessor with a single method void process(Package p). Now, for the existing client, you write a lambda that sorts packages by weight and routes them to the correct conveyor belt. The code looks like this:

PackageProcessor currentClient = (p) -> {
    if(p.getWeight() > 50) {
        routeToHeavyBelt(p);
    } else {
        routeToLightBelt(p);
    }
};

When the new client arrives next month, you don't need to create a whole new class. You just write a different lambda and pass it to the same method that expects a PackageProcessor. The core processing loop remains unchanged.

Here are the concrete steps an IT professional would take:

This approach makes the code flexible, testable, and easy to extend. Each new business rule is just a new lambda, not a new class hierarchy. The exam tests exactly this kind of thinking — being able to recognise when a lambda can replace an anonymous inner class and how to design interfaces for flexibility.