>>733
> 設計の立場に立つまでは分からないだろう
> ならばせめて
> 必要になるまではせめて語らないでほしい
多分ここが間違っていて、というよりはポリシーの違いだが、
君の職場は「設計」と「コーダー」が完全に分離していて、「コーダー」にはデザパタの知識は必要ないのか？
俺が知っている限り、設計とコーダーの分離は失敗だったと聞いているが。

そもそも設計において必要なのは「外部インタフェースの固定」だ。これは
・（いわゆる）ファクトリメソッド(A)
・Factory Methodパターン(B)
・Abstract Factoryパターン(C)
として、(A)→(B)の場合には外部（使う側）のソースコードの改変は全く必要ないし、
(B)→（C)にアップグレードする場合も正しく隠蔽されていれば同様だ。
中身を見せていれば(B)→(C)時にダウンキャストが必要になるが、これはそもそも設計が悪いし、
それでもラップすれば、外部ソースは改変無しで保てる。
だから使う側からすると「ファクトリを必ず呼ぶ」ことを徹底すればそれでよく、
中身が(A)(B)(C)のどれでも関係なく、クラス担当者が最適なものを選べ、でしか無いと思うが。
最悪駄目駄目なら差し替えればいいだけだし。本来これが隠蔽のメリットだろうに。

>>737
いらんだろ。イテレータ自体、
・走査を begin(), next(), end() と抽象化すれば実装によって異なる走査が必要でも隠蔽できます
なんだし、言語側のイテレータもこれとインタフェース合わせてあるし。
同じ思想を2度学んでも意味が無い。
仮にデザパタがGoF以外の100人から提唱されているとして、それぞれ微妙に方言があり、
「○○のデザパタでは△△のことをこう呼びます」ってのを色々覚えても意味無いだろ。
デザパタのイテレータパターンと言語のイテレータ」は違います！ってのは俺にはこう見える。
どうでもいいことにこだわりすぎだ。