>>718
了解した。ｊこれでいいか？
・（いわゆる）ファクトリメソッド＝factory関数は非仮想関数
・Factory Methodパターン＝factory関数は仮想関数でオーバーライドされる
・Abstract Factoryパターン＝数クラスのfactory関数を纏めて抽象化

上2つは区別の必要なし、
下1つはメタ気味だからこれが適切な場合に「ファクトリ」と言えば上2つと混同することはなさそう。
って感じだなあ、俺は。

ちと補足すると、

・（いわゆる）ファクトリメソッド＝factory関数は非仮想関数
・Factory Methodパターン＝factory関数は仮想関数でオーバーライドされる

この2つが普通に「ファクトリ」と呼ばれるもので、俺は区別する必要が無いと思っている。
これらを使ったクラスが複数合った場合、それらを束ねるために

・Abstract Factoryパターン＝数クラスのfactory関数を纏めて抽象化

が使われると思うので、下から組む場合には、文脈的に混同されることはないはず。
上から組む場合は若干齟齬があるかも。

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

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

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

>>739
いる/いらないの言い合いは意味無いが、やっぱり俺は区別の必要は無いと思うぞ。
「言語のイテレータ」は「デザパタのイテレーターパターン」を言語側に取り入れた機能であり、
「言語のイテレータ」を正しく使える＝「デザパタのイテレーターパターン」を正しく使える、となるから、
別に学ぶ必要はない。

言語と設計(思想)の分離と言うのは、例えば依存性逆転の法則(DI)等であって、
これは言語とはまったく無関係だから、どの言語でも使えるし、また、使わなくとも実装可能だ。
とはいえこれも、例えばフレームワークは基本的にDI的であるので、
フレームワークを正しく使うようにすれば自然と身に付く。
(フレームワークに沿って記述することが必要であり、これはプチDI）

上達を登山に例えれば、デザパタは一つの登山道であるが、それ以外のルートもあるということ。
どれが効率がいいのかは知らんが、
少なくともデザパタを通らないと頂上にたどり着けない、って事はない。
本来デザパタの目的はこの「上達への最短ルートの開発」だったはずだが、
GoFからして冗長で暴走気味だと思うよ。

>>746
本人に学ぶ気があれば、使っていれば身につくんだよ。
お前は日本語を学んで上達したのか？違うだろ。使って上達したんだよ。

もっと分かりやすい例で言うと、ギャグだな。
「鉄板」「お約束」「乗り突っ込み」等のデザパタはあるが、
これらをデザパタとして学ばないと「乗り突っ込み」出来ないのか？
違うだろ。使ってるのを見て学んだんだよ。
（トンキンでは学ぶのかもしれないが、関西人のは地だぞあれは。
「ふーん、で、オチは？」という環境にいるから自然と身につくんだよ）

>>750
むしろお前は何しに来てんだ？
デザパタ学べば上達するなら、本なりサイトでも読めばいいではないか。

>>751
× > 英語だと学ばないとカタコトのまま
○　英語は使わないとカタコトのまま
これはほぼ通説だぞ。むしろ俺の説を補強してどうする？

学ぶ＝イメトレであって、それは上達を早める方法ではあるが、
学ぶだけでは上達しないんだよ。使わないといけない。
もちろん使ってさえいれば上達するか？と言えばそうじゃない。
日本人内でも文章の上手下手があるように、いろいろ意識して使って無いと駄目だ。
いわゆる職人気質だよ。今よりも上を常に求めているか？ということ。

>>756
もう完全に脱線しているが、さらに続けると、

> 発音は意識して学ばないと
> いくら使っててもカタコトのままというのが定説
これは正確ではない。
一般日本人について、確かに君の上記意見は当てはまる。
しかしこれはエラーをフィードバックする「耳が無い」からであって、
逆に言えば「耳がある」人は意識して学ぶ必要はない。例えばネイティブの幼児とかがそうだ。

脳科学的に、確か聴覚は幼児期に発達して、そのまま終わりだったはず。
それで俺たちはLとRが聞き分けられない耳になってしまって、結果、LとRの発音が出来なくなる。
これは、先天的聴覚障害者がアーウーとしか言えず、正しく発音ができない（滑舌が著しく悪い）ことからもわかる。
聴覚障害は口蓋の障害ではないのに正しく発音できないのは、
自分の発音が聞こえず、正しく発音できていないことを認識して修正できないから。
（分かりやすく言えば、噛んだことが分からないから）

英語についていえば、LとRの違いがわかる耳があれば、明らかに違う（らしい）のであっさり上達する。
(むしろ、何でこれが聞き分けられないの？と不思議らしい）
俺らみたいに、「耳がない」人が「正しい発音」をする為には、
俺らも聴覚障害者と同様に、正しい発音をする為の口や舌の動きを意識しないと上達しない、というだけ。

だからまあ、エラーをフィードバックできれば自己学習で上達はする、ということにはなる。
つまり自分で書いた糞コードが糞だと認識できれば、上達する、とも言える。