で、ついでに言うと、イテレータ自体はコンテナと必ず密結合してる。
コンテナの内部構造を変更されたらイテレータ自体も変更しないといけないだろ。（イテレータを使う側のコードは変更不要）
そして、
イテレーターパターン：オレオレコンテナにはイテレータを用意しろ --- (A2)
ダックタイピング：オレオレコンテナにはforEachメソッドを用意しろ --- (B2)
だが、イテレータの用意は共通インタフェースにする程度の設計は必要なのに対し、
forEachメソッドの用意はただ回せば済むから、A2よりもB2の方が簡単なんだよ。
ここで「簡単」で済む理由は、B2の方が「自然」だからであり、A2で切るのは「不自然」だからだ。
コンテナとイテレータは一体であり、内部処理はそれとは全く関連無いから元々疎結合。
それを(コンテナ)/(イテレータ＋内部処理）と無理に切るからおかしくなる。
(コンテナ＋イテレータ)/(内部処理)なら元々疎結合のところで疎結合にしてるから余計な手間がかからないという、ごく当たり前の話。

Javaが最初から関数ポインタを扱えれば、イテレーターパターンなんて存在せず、敢えて言うなら
・forEachパターン：コンテナは必ずforEachインタフェースを継承/実装しなければならない
とかになってたと思うぜ。(もはやパターンではなくただのコーディングルールだが）


>>711
> メモリが確保できない時（エラーを生成する余裕すらない時もある）とか
Javaの場合はもしもの時用に1MBのメモリを確保していた。
ただ、メモリで落ちた場合は「あと数KBあったら落ちずに済んだのに…」が大半だろうし、
非常用に1MBはでかすぎるだろ、という事で、最近は500KBに減らされたと聞いた。


>>714
> 必要もねえのに勉強しちゃって
それは「デザインパターンの意義は、命名した事くらいだ」の人達の意見だし、実際これも当たっているが、
もともと「頻出パターンを学んで初心者から中級者へジャンプアップする」為の物であり、学習用だ。

そして「この場合はこう実装しろ」を規定するのはコーディングルールや設計方針であって、
「頻出パターン図鑑」であるデザインパターンではない。