From an API-design standpoint, why is Iterable separate from Collection, and why did the designers keep Map outside the Collection hierarchy? What does this teach about interface segregation?

## The question behind the question This is really about **interface design**: how the JDK authors decided *what promises each interface makes* and *who is allowed to implement it*. Two choices stand out: (a) `Iterable` is a separate, tinier interface *above* `Collection`, and (b) `Map` is deliberately **not** a `Collection`. ## Background terms - **Interface Segregation Principle (ISP):** the 'I' in SOLID - clients should not be forced to depend on methods they don't use; prefer many small, focused interfaces over one fat one. - **Liskov Substitution Principle (LSP):** a subtype must be usable anywhere its supertype is, *honoring the supertype's contract*. A subtype that can't honestly fulfill the contract shouldn't be a subtype. - **Reified vs erased / capability:** here, the relevant idea is matching an interface to the *capability* a type can truthfully provide. ## Why Iterable is separate from Collection `Collection<E>` is a **rich** contract: `size()`, `isEmpty()`, `add`, `remove`, `contains`, the bulk ops, `toArray`, plus `iterator()`. Many things in software can be **traversed** but are **not** full collections: - A **lazy or infinite sequence** (e.g. all natural numbers) - it has no `size()`, you can't `add` to it, but you *can* walk it. - A **resource-backed cursor** - lines of a file, rows of a result set; traversable once, not a stored container. - A **stream source** - `Iterable` only needs `iterator()`/`spliterator()`. If for-each had required `Collection`, none of these could use the clean loop syntax, and you'd be forced to implement (or throw `UnsupportedOperationException` from) a dozen irrelevant methods. By extracting the **minimal** capability - *"I can produce a one-shot cursor"* - into `Iterable`, the JDK lets all of the above participate in for-each and streams while only promising what they can deliver. This is **ISP in action**: depend on `Iterable<T>` in an API when all you need is to traverse; depend on `Collection`/`List` only when you need their extra powers. It also future-proofed the language: when Java 8 added streams, `Iterable.spliterator()` and the `Collection.stream()` default slotted in without breaking anyone. ## Why Map is NOT a Collection `Collection<E>` is defined *entirely* in terms of **one** element type `E`: `add(E)`, `remove(Object)`, `contains(Object)`, `iterator()` yielding `E`, `toArray()` of elements. A **`Map<K,V>`** stores **pairs**; it has **two** type parameters and no single, honest `E`. If `Map` extended `Collection<?>`, every one of those single-element methods would be a lie: - `add(E)` - add *what*? a key? a value? an entry? None fits cleanly. - `contains(Object)` - of a key or a value? - `iterator()` - over keys, values, or entries? Forcing the subtype relationship would **violate LSP**: a `Map` could not be safely used where a `Collection` is expected without surprising behavior or thrown exceptions. So the designers chose **composition over (inappropriate) inheritance**: `Map` is its own interface, and it *exposes* collection-shaped **views** - `keySet()` (a `Set<K>`), `values()` (a `Collection<V>`), `entrySet()` (a `Set<Map.Entry<K,V>>`). Those views are live (backed by the map), giving you all the Collection power *where it actually makes sense* without pretending the Map itself is a Collection. ## What this teaches 1. **Model the narrowest truthful contract.** `Iterable` promises only traversal; that single, honest promise makes it reusable far beyond collections. 2. **Don't force a subtype relationship that breaks the contract** (LSP). When a type can't honestly *be* a supertype, expose the overlap via **views/adapters** (composition) instead. 3. **Small interfaces compose and evolve well** (ISP). Splitting capabilities let streams be added later without breakage. 4. **APIs should accept the weakest type that suffices** - take `Iterable<T>` when you only iterate, return `List`/`Collection` when callers need more. ## Counterfactual Had the designers made `Map extends Collection<Map.Entry<K,V>>`, you'd gain a uniform `iterator()` but lose key-based clarity and invite contract violations (what does `add(entry)` mean if the key exists?). The chosen design - separate interface + views - is the cleaner trade.