تمرير السلوك كقيمة

Written Explanation

Data versus behavior

Look at a method you could easily write today: keep only the adults from a list of people.

static List<Person> adults(List<Person> people) {
    List<Person> result = new ArrayList<>();
    for (Person p : people) {
        if (p.getAge() >= 18) {
            result.add(p);
        }
    }
    return result;
}

Now you need "people whose name starts with A". You copy the method and change one line. Tomorrow it is "people from one city". Every method has the same loop; only the condition differs. The condition is behavior, a small piece of logic, and we want to hand it in from outside.

That is the recipe-card idea: the method keeps the stable part (loop through the list and collect), and the caller supplies the part that changes (the test).

Step 1: an interface that describes one action

In BEG-024 you learned that an interface is a contract. We can write a contract for "a test on a person":

interface PersonFilter {
    boolean matches(Person p);
}

An interface with exactly one abstract method is called a functional interface. The Java documentation for @FunctionalInterface explains the exact rule: default methods do not count (they have a body), and neither does an abstract method that merely re-declares a public method of Object, such as equals. You have already used two functional interfaces without the name: Runnable (one method, run) and Comparator<T> (one method, compare, plus default and static helper methods).

Now the method takes the contract as a parameter:

static List<Person> keep(List<Person> people, PersonFilter filter) {
    List<Person> result = new ArrayList<>();
    for (Person p : people) {
        if (filter.matches(p)) {
            result.add(p);
        }
    }
    return result;
}

One loop serves every condition. The only question left is how to write the condition at the call site.

Step 2: the old way, an anonymous class

Before Java 8 you had to create an object that implements the interface. If you need it only once, you can write the class without a name, right where you use it. This is an anonymous class:

keep(people, new PersonFilter() {
    @Override
    public boolean matches(Person p) {
        return p.getAge() >= 18;
    }
});

Count the lines: five lines, and only one carries information, p.getAge() >= 18. The rest is ceremony: new PersonFilter(), the method name, the modifier, the types, the @Override. All of it is forced, because the compiler already knows that keep wants a PersonFilter and that PersonFilter has one method.

Step 3: the new way, a lambda

A lambda expression is a short piece of behavior, written without the ceremony:

keep(people, p -> p.getAge() >= 18);

Read p -> p.getAge() >= 18 as "given a person p, answer p.getAge() >= 18". It is the recipe card with nothing else on it. The arrow -> separates the parameters from the body. The next lesson covers the exact syntax; today we focus on the idea.

How does the compiler know what this card means? It looks at where the card is going. The parameter of keep has type PersonFilter, whose only abstract method takes a Person and returns boolean, so the lambda must be an implementation of that method. The Oracle Java Tutorials describe this: a lambda has no type of its own, and the compiler takes its type from the context, the target type.

So a lambda is simply a compact way to implement a functional interface. Two rules follow:

1. A lambda can only appear where a functional interface is expected. Object o = () -> 1; does not compile, because Object does not tell the compiler which method the lambda implements.
2. The same lambda text can mean different things in different places, because the target type decides. (a, b) -> a.length() - b.length() is a Comparator<String> when passed to sort.

Anonymous class versus lambda: same job, less noise

The last row matters only occasionally; the Oracle tutorial notes that a lambda does not introduce a new scope, so this in a lambda still means the enclosing class. You do not need it yet. What you need is the habit: if a one-method interface wants an object just to hold one small piece of logic, write a lambda.

Behavior as a value

Because a lambda is an object of a functional interface type, you can treat it like any other value:

• Store it in a variable: PersonFilter adult = p -> p.getAge() >= 18;
• Pass it to a method: keep(people, adult);
• Return it from a method.
• Keep several in a list.

That is what "passing behavior as a value" means. Nothing magical happens to the method. You are still passing an object; the lambda simply makes creating that object cheap enough that you stop avoiding the idea.