عرض عملي: استبدال الفئات المجهولة بتعبيرات lambda

Written Explanation

The starting point

We have a small Contact class with a name and an age:

static class Contact {
    private final String name;
    private final int age;
    Contact(String name, int age) { this.name = name; this.age = age; }
    String getName() { return name; }
    int getAge() { return age; }
    @Override public String toString() { return name + "(" + age + ")"; }
}

and a list we will reuse:

List<Contact> contacts = new ArrayList<>(List.of(new Contact("Sara", 12),
        new Contact("Omar", 34), new Contact("Amal", 17), new Contact("Adam", 52)));

The list is wrapped in new ArrayList<>(...) because List.of is unmodifiable and we want to sort it in place (BEG-030).

Step 0: the rule of refactoring

Before changing anything, record what the code does now (the output). After each step run it again and compare. If the output changes, the last step was not a refactoring. This is the habit that makes shrinking code safe.

Step 1: the anonymous Comparator

Collections.sort(contacts, new Comparator<Contact>() {
    @Override
    public int compare(Contact a, Contact b) {
        return a.getName().compareTo(b.getName());
    }
});
System.out.println(contacts);

Output:

[Adam(52), Amal(17), Omar(34), Sara(12)]

Seven lines for one idea: "compare by name".

Step 2: the lambda

Collections.sort expects a Comparator<Contact>, a functional interface, so the entire anonymous class collapses to its one method body. We use list.sort, the instance method you know from BEG-032:

contacts.sort((a, b) -> a.getName().compareTo(b.getName()));

That is one line. To prove the lambda really does the job, here is the same call written so the order is reversed (b before a):

contacts.sort((a, b) -> b.getName().compareTo(a.getName()));

Output after this reversed version:

[Sara(12), Omar(34), Amal(17), Adam(52)]

Step 3: the method reference and the builder

The lambda still repeats the idea "get the name" twice. Comparator.comparing takes a key extractor, a Function, so we can pass a method reference:

contacts.sort(Comparator.comparing(Contact::getName));

[Adam(52), Amal(17), Omar(34), Sara(12)]

Same result as step 1, now in a line that reads "sort by contact name". Here is the whole evolution side by side:

Each step removed noise and kept the output identical. For a numeric key such as age, the builder Comparator.comparingInt(Contact::getAge) avoids boxing.

Step 4: from a hard-coded loop to a Predicate

Now the filtering code. The "before" version has the condition fixed inside the loop:

static List<Contact> adultsLoop(List<Contact> in) {
    List<Contact> out = new ArrayList<>();
    for (Contact c : in) {
        if (c.getAge() >= 18) {
            out.add(c);
        }
    }
    return out;
}

If you also need "names starting with A", you would copy it. Instead, make the condition a parameter:

static List<Contact> keep(List<Contact> in, Predicate<Contact> p) {
    List<Contact> out = new ArrayList<>();
    for (Contact c : in) {
        if (p.test(c)) {
            out.add(c);
        }
    }
    return out;
}

System.out.println(adultsLoop(contacts));
System.out.println(keep(contacts, c -> c.getAge() >= 18));
System.out.println(keep(contacts, c -> c.getName().startsWith("A")));

[Adam(52), Omar(34)]
[Adam(52), Omar(34)]
[Adam(52), Amal(17)]

The first two lines are identical: the refactoring preserved behavior. The third line is new behavior that cost one line, not a whole new method.

Step 5: the planned mistake

Suppose you want to count adults, and, in the spirit of the lesson, you reach for forEach and a lambda:

int count = 0;
ages.forEach(x -> { if (x >= 18) { count++; } });
System.out.println(count);

The compiler stops you:

Bad.java:6: error: local variables referenced from a lambda expression must be final or effectively final
        ages.forEach(x -> { if (x >= 18) { count++; } });
                                           ^
1 error

You met this rule in the lambda syntax lesson. The lambda wants to change a local variable owned by the method, and Java forbids it. There are two ways out.

Fix 1, restructure (preferred). Counting is not what forEach is for. A plain loop is fine, and so is the keep method you already have:

int count = 0;
for (Contact c : contacts) {
    if (c.getAge() >= 18) {
        count++;
    }
}
// or, reusing what we built:
int count2 = keep(contacts, c -> c.getAge() >= 18).size();

Fix 2, a mutable holder (use sparingly). The restriction is on the variable, not on the object it points to. An AtomicInteger is an object whose value can change, so the variable counter itself is never reassigned:

AtomicInteger counter = new AtomicInteger();
contacts.forEach(c -> {
    if (c.getAge() >= 18) {
        counter.incrementAndGet();
    }
});
System.out.println(counter.get());

AtomicInteger comes from java.util.concurrent.atomic and is designed for counters shared between threads; the concurrency modules explain it. Treat it here as a preview. It works, but it is a workaround that hides the real problem (a lambda that changes outside state). With the fix-1 code all three versions printed 2.

The final comparison

The refactoring achieved the lab's acceptance rule, same behavior with less code:

• Sort by name: 7 lines became 1.
• Each new filter: a new 8-line method became 1 line.
• Less duplicated logic, so fewer places for bugs.

Stop shrinking when the code stops getting clearer. A lambda that has grown braces and several statements should become a method (see the earlier lesson on lambda syntax), and a reference that puzzles readers should become a lambda or a named method.