عرض عملي: إعادة كتابة stream غير مقروء على هيئة حلقة

Written Explanation

The "before" code

Here is a realistic chain, the kind that grows by one extra step every month. It takes orders and builds the top three "customer=amount" labels for paid orders of at least 50, adding a ten-unit express fee, and also records the ids of paid orders over 200 in a shared list for auditing.

List<String> before = orders.stream()
    .filter(o -> o.status().equals("PAID"))
    .map(o -> { if (o.amount() > 200) { flagged.add(o.id()); } return o; })
    .filter(o -> o.amount() >= 50)
    .map(o -> o.express()
        ? new Order(o.id(), o.customer(), o.status(), o.amount() + 10, true) : o)
    .sorted(Comparator.comparingDouble(Order::amount).reversed())
    .map(o -> o.customer() + "=" + o.amount())
    .distinct()
    .limit(3)
    .collect(Collectors.toList());

flagged is a field: static final List<String> flagged = new ArrayList<>();.

The record is record Order(String id, String customer, String status, double amount, boolean express).

Why it is hard to read

Ask the ten-second question: what does this do? A reader must decode:

1. Length. Nine stations. The reader must hold the type of the stream in their head after each: Order, Order, Order, Order, then String.
2. Nested lambdas. The express fee is a conditional that builds a whole new Order, hidden in a one-line lambda.
3. A hidden second job. The second line is not about producing the result at all: it writes to an outside list, and the name map suggests a pure transformation.
4. Order dependence. The audit must happen before the >= 50 filter, but that is not visible. Moving a filter line changes which orders get flagged.

Debugging is worse. If the flagged list is wrong, where do you put a breakpoint? Inside a lambda in the middle of a chain. If an order is missing from the top three, which station dropped it?

Why the side effect is fragile

The Java documentation describes side effects in behavioral parameters such as the lambda in map: they are generally discouraged, and no guarantees are made about their visibility to other threads, about whether the same thread handles different operations on an element, or about whether the lambda runs at all if the implementation can elide it. The Stream documentation gives a concrete case: count() may skip running the pipeline when it can compute the answer from the source, so side effects might not happen. We can see that rule in action:

long c = orders.stream()
    .peek(o -> System.out.println("peek " + o.id()))
    .count();
System.out.println(c);

On JDK 21, with a list as the source, this printed only 7 and no peek lines, because the count could be computed from the size of the list. The pipeline "ran", but the stations did not. Add a filter before peek and the stations do run. Whether a station runs can depend on details of the pipeline.

The same fragility appears in two other ways, which we only explain here and do not run:

• Changing the order of operations. If someone later adds a limit earlier in the chain, or a sorted, the set of items that reach the side-effect station changes, and the audit list silently changes with it.
• Parallel streams. If someone switches to parallelStream() to "make it faster", several threads would add to the same ArrayList, which is not thread-safe, and the audit list could lose entries or the program could fail. Even with a thread-safe list, the order of the list would no longer match the order of the orders.

The rewrite as a loop

List<String> flaggedIds = new ArrayList<>();
List<Order> candidates = new ArrayList<>();
for (Order o : orders) {
    if (!o.status().equals("PAID")) continue;
    if (o.amount() > 200) flaggedIds.add(o.id());
    if (o.amount() < 50) continue;
    double charged = o.express() ? o.amount() + 10 : o.amount();
    candidates.add(new Order(o.id(), o.customer(), o.status(), charged, o.express()));
}
candidates.sort(Comparator.comparingDouble(Order::amount).reversed());

List<String> after = new ArrayList<>();
for (Order o : candidates) {
    String label = o.customer() + "=" + o.amount();
    if (!after.contains(label)) after.add(label);
    if (after.size() == 3) break;
}

What changed:

• The audit is now a plain line in the loop: visible, and easy to break on.
• The fee has a name, charged, and a line to itself.
• The order dependence is now the order of lines: the audit check comes before the < 50 skip.
• The early exit (break at three) is explicit.

The middle path: two honest pipelines

A loop is not the only repair. If the real problem is the side effect, you can split the job into two pipelines that each compute one thing:

List<String> flaggedIds = orders.stream()
    .filter(o -> o.status().equals("PAID") && o.amount() > 200)
    .map(Order::id)
    .toList();

and a separate pipeline for the labels, with the fee computed in a small named method. Two pipelines pass over the data twice, a cost that does not matter for a few thousand orders. Choose the loop when state or early exit matters; choose the split streams when the pieces are independent. Both beat the original.

Comparing the two versions

A two-sentence justification, as asked in the exercises, might read: "I rewrote the chain as a loop because the audit side effect inside map hid a second job and depended on step order, which makes the stream fragile and hard to debug. In the loop the audit, the fee, and the early exit are visible lines with named variables."