العمليات الوسيطة

Written Explanation

The six stations

Each one returns a new Stream. Nothing is computed until a terminal operation runs (Lesson 3).

filter and map

filter asks a yes/no question about each item. map computes a replacement:

ps.stream()
  .filter(p -> p.category().equals("Furniture"))   // keep Product items
  .map(Product::name)                               // Product becomes String
  .toList();

After map(Product::name) the belt carries Strings instead of Products. The type of the stream changes, and the compiler tracks that for you: Stream<Product> becomes Stream<String>. This is why generics (BEG-031) appear in every stream signature.

sorted

With no argument, sorted() uses the elements' natural order, so the elements must be Comparable (numbers and strings are). Strings sort alphabetically by code unit, so upper-case letters come before lower-case in plain sorted(). If the elements are not Comparable, the pipeline fails at the terminal operation with a ClassCastException, according to the Javadoc.

With a Comparator, you use exactly the tools from BEG-032:

.sorted(Comparator.comparingDouble(Product::price))
.sorted(Comparator.comparing(Product::category)
        .thenComparing(Product::price, Comparator.reverseOrder()))

For ordered streams (a list is ordered), the sort is stable: items that compare equal keep their original relative order. That is the Javadoc's guarantee, and it is what lets you rely on multi-key sorts behaving predictably.

distinct

distinct() removes duplicates using equals. For a stream from a list, it keeps the first occurrence of each value. For your own classes it only works well if equals and hashCode are properly written (BEG-026), which records give you for free.

limit and skip

limit(n) keeps at most n items. skip(n) drops the first n. Together they make a page: skip(20).limit(10) is "page 3 with ten items per page". If there are fewer items than skip asks for, you get an empty stream, not an error. A negative limit throws IllegalArgumentException.

The order of stations matters

Two pipelines with the same stations in a different order can answer different questions. Take 5, 3, 9, 3, 7, 5, 1 and look at three results:

There is also a cost reason to filter early. If you filter before an expensive map, the expensive work runs on fewer items. A good habit: shrink first, change second, sort last, unless the question needs a different order.

Do not put side effects in map

map is for computing a replacement item. It is not a place to add to an outside list, increase a counter, or print progress. The Javadoc says side effects in behavioral parameters are generally discouraged, and gives no guarantees about when or whether those effects happen, because the implementation is free to skip or reorder work it can prove unnecessary. A pipeline whose correctness depends on a side effect is fragile. Lesson 8 shows one such pipeline and its repair.

Reading a pipeline

A long chain is readable only if you can read it as a sequence of plain sentences:

List<String> result = ps.stream()
    .filter(p -> p.price() > 5)          // only items over 5
    .sorted(Comparator.comparingDouble(Product::price))  // cheapest first
    .map(Product::name)                  // just the names
    .limit(2)                            // the first two
    .toList();

Put each station on its own line, and add a short end-of-line comment if a lambda is not obvious.