オブジェクト指向は愚かな考え。この世は計算式 ★3©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2016/01/05(火) 02:10:25.72

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
https://twitter.com/ProgrammingMono/status/665702678006140928

研究グループは、血管新生注において血管が伸長する際の血管内皮細胞注運動を制御するしくみを、生物学と数理モデル・
コンピュータシミュレーションを融合させた先端的な研究手法により明らかにしました。

生物は、最小の機能単位である細胞が寄り集まった多細胞体です。しかし、細胞の集まりが、組織や器官といった
秩序ある形態や構造をつくり機能するしくみはほとんど分かっていません。中でも血管は、体中の全組織に十分な
酸素や栄養源を効率よく供給するため、組織や組織の間に入り込み、血管外の環境との相互作用により、巧妙な
枝分かれ構造をとっています。

これまでに本研究グループは、新しく血管がつくられる（血管新生）際の細胞の動きに着目し、特に血管内皮細胞の
動きをリアルタイムで可視化し、定量的に捉えることを可能にしてきました。

今回さらに、血管の伸長を制御するしくみについて、細胞が自発的に自らを制御して動く過程（自律的過程）と、
隣接した細胞から適宜影響を受けて動く過程（協調的過程）がうまく共存することで、全体の動きが巧みに統制
されていることを世界に先駆けて実証しました。

興味深いことに、血管内皮細胞が前後したり、お互いに追い抜きあったりという血管新生で見られる複雑な細胞集団の
動きを制御している中枢部分は、細胞一つ一つの動き（スピードと方向性）の「確率的な変化」として十分説明できる
ことをコンピュータシミュレーションで実証しました。
http://www.jst.go.jp/pr/announce/20151120-2/#YOUGO3

前スレ
オブジェクト指向は愚かな考え。この世は計算式 ★2
http://peace.2ch.net/test/read.cgi/tech/1450153388/

**デフォルトの名無しさん** · 2016/08/04(木) 00:31:24.04

デコレータパターンと同等の機能をクロージャで実装した
じゃね？

同等の機能を持った違った実装があるのは当たり前じゃね？
デコレータパターンと同じような機能をもたらすけど
デコレータパターンじゃない実装は普通にあり得るんじゃね？

**デフォルトの名無しさん** · 2016/08/04(木) 00:34:51.00

>>595
パターンは機能じゃないよ。設計。
デコレータパターンという設計

この設計の実装はいろいろある。
決まっていない。

Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。

**デフォルトの名無しさん** · 2016/08/04(木) 00:36:04.52

wikipediaにすら書いてあるしｗ

https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)

デザインパターンは、よく使われる設計を一般化された形でまとめたものに過ぎない。
そのため、具体的な実装を提供するものではなく、
あくまでもコンセプトとして参照されることが意図されている。
つまり、サンプルコードは、実装例に過ぎない。

**デフォルトの名無しさん** · 2016/08/04(木) 00:42:01.96

>パターンは機能じゃないよ。設計。

それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ？
俺の言ってることと一緒だね

**デフォルトの名無しさん** · 2016/08/04(木) 00:44:00.26

ID:jTAWnEUaを教育してあげる義務は我々には無い

**デフォルトの名無しさん** · 2016/08/04(木) 00:45:06.02

>>599
わざわざ複雑にしないでいいよｗ

やりたいことがある。
でも説明するのが面倒くさい。

じゃあ「デコレーターパターン」と呼びましょう。

これで話は通じてるじゃん。
だからこれだけの情報でコードを書くことができる。

そのデコレーターパターンを
クロージャーで実装したんでしょ？
そういえば良いんだよ。

**デフォルトの名無しさん** · 2016/08/04(木) 00:48:34.94

>>600
じゃあ一緒に勉強していきましょう（笑）

http://www.techscore.com/tech/DesignPattern/foundation/foundation1.html/#dp0-2

> 前章でも説明したとおり、デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」を
> まとめたものです。デザインパターンを利用するメリットとして、最初にあげられるのが、
> 「再利用性の高い柔軟な設計ができる」という点です。各パターンには、多くの知恵が凝縮されています。
> これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
> 初心者でも先人たちが詰め込んだ「知恵」を利用した設計をすることが可能となります。
> また、先人たちの知恵を参考にすることで、設計力の向上も期待できます。
>
> 次のメリットは、「技術者どうしの意思疎通が容易になる」ことが挙げられます。
> デザインパターンを習得している技術者どうしであれば、設計について相談するとき
> 「Singleton パターンで行きましょう」とか「Strategy パターンが応用できるのではないでしょうか」と
> いうようにパターン名で設計の概要の合意を取ることが可能です。デザインパターンを
> 習得していない技術者には「こんなクラスを作って、このクラスはこんな役割を持っていて・・・。」と
> 延々と説明しなければなりません。このように、デザインパターンを学習しておくことで
> 開発者どうしの意思疎通がスムースになるのです。

あなたは何で勉強していますか？

**デフォルトの名無しさん** · 2016/08/04(木) 01:13:23.05

話をややこしくしているのはあなたです

>パターンは機能じゃないよ。設計。

↑これは君が言ったことだよね

その上で俺は、同等の機能を持った、違ったデザインなんじゃね？って言ってるわけ

機能が同じであっても、同じデザインパターンとは限らない
何故なら、デザインパターンは機能じゃないから、設計のパターンだから
↑君の言ってることと全く同じだよね

だから同じ機能だけど、違った設計パターンであり
同じデザインパターンに属さない設計は有る
ということを君は認めているということ

**デフォルトの名無しさん** · 2016/08/04(木) 01:43:58.02

デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの
ってのは正に君が自分で言ったことであって
それは俺も了承している

だから同じ機能であっても、それだけで同じデザインパターンとは言えないよね
と俺は言ってるわけ
なぜならデザインパターンは機能では無いから(君の言ったことだよね)

そもそも俺とお前とのやり取りに、何のとどこおりも無い
俺は、>>596で同等の機能を別の設計で実装したんじゃないか、と言い
お前は>>597でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている
合わせると、「同等の機能であっても同じデザインパターンであるとは限らない、設計で決まる」
という結論が得られる

**デフォルトの名無しさん** · 2016/08/04(木) 01:56:34.90

デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。

これと同じことが他のデザインパターンでもできるんじゃね？という主張だったと思うんだが。

Singletonは言語によって容易に達成できるものもあればそうでない言語もあるが、そう難しくは無いはず。
OCamlだったらmutable valueを持ったモジュール使えば同等のことが実現できる。
Adapterパターンも変更できない物がオブジェクトだったら関数1つで済むし、
モジュールだったらファンクタ使えば良い。

これを続けていけばデザインパターンがOOPの表現力の低さを解決する妥協案である、と示せる気がするが、
逆にOOPでデザパタ使うのが一番簡潔になる問題を探す方が難しいかもね。

**デフォルトの名無しさん** · 2016/08/04(木) 03:16:53.36

やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。

まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。

そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。

**デフォルトの名無しさん** · 2016/08/04(木) 03:18:24.28

OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。

C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。

**デフォルトの名無しさん** · 2016/08/04(木) 06:27:25.67

>>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。

JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。

**デフォルトの名無しさん** · 2016/08/04(木) 09:14:32.03

>>608
それはオレオレ定義ですよね。

**デフォルトの名無しさん** · 2016/08/04(木) 09:31:36.26

デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。

「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。

プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。

**デフォルトの名無しさん** · 2016/08/04(木) 09:33:28.01

内容を理解してないから例にある記述方法しか受け付けないんだよ。

**デフォルトの名無しさん** · 2016/08/04(木) 09:33:48.07

> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。

じゃあなんでこんな本が存在するんですか？ｗ

Rubyによるデザインパターン-Russ-Olsen/
https://www.amazon.co.jp/dp/4894712857

JavaScriptデザインパターン
https://www.oreilly.co.jp/books/9784873116181/

The Design Patterns Smalltalk Companion
https://www.amazon.com/dp/0201184621

**デフォルトの名無しさん** · 2016/08/04(木) 09:34:24.97

>>610
あ。引用部分は自炊本の OCR のコピペなんで、タイポは脳内補完ねがいます。

**デフォルトの名無しさん** · 2016/08/04(木) 09:35:44.09

>>612
GoF も「Smalltalk では簡単に記述できるものもある」とは言っているけど、
ぜんぶがぜんぶとは言っていないよね。

**デフォルトの名無しさん** · 2016/08/04(木) 09:35:54.66

>>612
おまいみたいなバカに本を売り付ける為だろw

**デフォルトの名無しさん** · 2016/08/04(木) 09:38:22.54

>>615
え？捨て台詞？ｗ

**デフォルトの名無しさん** · 2016/08/04(木) 10:07:48.33

これはまさに捨て台詞で十分な一例。

**デフォルトの名無しさん** · 2016/08/04(木) 10:14:03.24

> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。

Smalltalkを好意的にとらえて持ち上げてくれるのは、狭い視野で意味なし認定しちゃう人たちよりは
ファンとしてはありがたいけど、これはさすがにオーバーエスティメートだし、
もうちょっとSmalltalkならではのアドバンテージを学んでから、適切な持ち上げ方をしてほしい…

**デフォルトの名無しさん** · 2016/08/04(木) 10:47:43.12

「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。

**デフォルトの名無しさん** · 2016/08/04(木) 11:37:47.99

>>619

もしそうだとしても、少なくとも>>591は「GoFの（デコレーター）」と明記すべきですよね

**デフォルトの名無しさん** · 2016/08/04(木) 12:27:01.14

smalltalkって簡単に色々できるんでしょ？
なんで現代でメジャーじゃないの？

**デフォルトの名無しさん** · 2016/08/04(木) 12:30:59.74

日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ？

**デフォルトの名無しさん** · 2016/08/04(木) 12:31:27.57

MSがVisual Smalltalkをつくらなかったから

**デフォルトの名無しさん** · 2016/08/04(木) 12:57:32.53

>>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが？

**デフォルトの名無しさん** · 2016/08/04(木) 13:05:00.50

はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。

**デフォルトの名無しさん** · 2016/08/04(木) 13:16:23.28

>>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン（GoFの定義如何に関わらない）というのを提示してもらうことはできますか？
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。

そもそも Smalltalk ではデコレーターパターンが不要（なので、実装はナンセンス）とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。

**デフォルトの名無しさん** · 2016/08/04(木) 14:01:27.52

つか、>>546のruby版って一体何？
デコレータパターンのつもり？

**デフォルトの名無しさん** · 2016/08/04(木) 14:13:24.61

>>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満？

**デフォルトの名無しさん** · 2016/08/04(木) 14:41:37.79

>>628
あ、デコレータパターンの実装だったんだ。
同じ感じでこれ実装できる？
class Log
def output(s)
puts s
end
end

class TimeStampLog
def initialize(log)
@log = log
end

def output(s)
@log.output "#{Time.now} #{s}"
end
end

class PidLog
def initialize(log)
@log = log
@pid = Process.pid
end

def output(s)
@log.output "[#{@pid}] #{s}"
end
end

**デフォルトの名無しさん** · 2016/08/04(木) 14:42:24.41

log = TimeStampLog.new(PidLog.new(Log.new))
log.output 'aaa'
log.output 'bbb'

log2 = PidLog.new(TimeStampLog.new(Log.new))
log2.output 'aaa'
log2.output 'bbb'

結果：
[24968] 2016-08-04 14:41:58 +0900 aaa
[24968] 2016-08-04 14:41:58 +0900 bbb
2016-08-04 14:41:58 +0900 [24968] aaa
2016-08-04 14:41:58 +0900 [24968] bbb

**デフォルトの名無しさん** · 2016/08/04(木) 16:18:58.29

>>629

これでいい？

http://ideone.com/WGTiOD

**デフォルトの名無しさん** · 2016/08/04(木) 16:59:33.41

>>631
なんか実装手段が違ってきてますが・・・。

>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。

**デフォルトの名無しさん** · 2016/08/04(木) 17:09:10.90

>>632
> なんか実装手段が違ってきてますが・・・。

本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので

> closureを使えばデコレータパターン同等のことができる

>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい

**デフォルトの名無しさん** · 2016/08/04(木) 17:41:28.54

>>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。

WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。

一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか？
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。

**デフォルトの名無しさん** · 2016/08/04(木) 18:07:30.87

>>626
だーかーらー、

デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装（当然、上記デコレータパターンの実装ではない）で実現できる。

という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる？

**デフォルトの名無しさん** · 2016/08/04(木) 18:33:42.23

>>634
> 一方、>>546のコードだとそうはいかない。

単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
http://ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。

**デフォルトの名無しさん** · 2016/08/04(木) 18:57:12.60

>>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。

**デフォルトの名無しさん** · 2016/08/04(木) 18:59:34.21

>>610
iteratorはどっちが楽なの？

**デフォルトの名無しさん** · 2016/08/04(木) 19:27:18.45

>>638
Smalltalk と C++ との比較で？　それならもちろん Smalltalk です。

（同書P.289より）
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。

（標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。）

**デフォルトの名無しさん** · 2016/08/04(木) 19:40:49.06

>>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね？
別にSmalltalkが特別ってことにはならない。

**デフォルトの名無しさん** · 2016/08/04(木) 20:21:25.52

>>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、

修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。

**デフォルトの名無しさん** · 2016/08/04(木) 20:23:12.92

デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。

**デフォルトの名無しさん** · 2016/08/04(木) 20:37:49.54

>>640
Smalltalkが特別ってことにはならないという点については同意します。

ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも

とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか？

あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を

http://qiita.com/jonichonpa/items/208dc2361414f93efacf

Smalltalkで書いてみました

http://ideone.com/oplhQu

もちろんSmalltalk方式を採用した言語（たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため

http://ideone.com/xlQZqc

**デフォルトの名無しさん** · 2016/08/04(木) 20:41:57.05

イテレーターパターンをSmalltalkで書いてみたわけね。

**デフォルトの名無しさん** · 2016/08/04(木) 20:47:45.80

イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ

**デフォルトの名無しさん** · 2016/08/04(木) 20:55:24.22

>>643
for each (range based for）でいいじゃん。

for (auto& item : collection)
{
// print an item
}

クロージャ風がいいなら、
std::for_each(collection.end(), collection.begin(), [](auto& item){ /* print */}

アイテレーターが登場するけど昔の名残みたいなもんで、
本質じゃないだろ？（範囲を指定してるだけ）

**デフォルトの名無しさん** · 2016/08/04(木) 21:08:55.10

>>642
クロージャを使ったらデコレータとは言わないのでは？
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。

無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。

言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。

**デフォルトの名無しさん** · 2016/08/04(木) 21:15:46.97

>>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。

**デフォルトの名無しさん** · 2016/08/04(木) 21:21:02.95

>>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。

**デフォルトの名無しさん** · 2016/08/04(木) 21:29:07.85

Structureは日本語にしたら
構造って意味ですよｗ

**デフォルトの名無しさん** · 2016/08/04(木) 21:30:27.36

>>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。

**デフォルトの名無しさん** · 2016/08/04(木) 21:33:42.86

継承してないと使えないとかじゃ困る。

**デフォルトの名無しさん** · 2016/08/04(木) 21:34:27.18

> そこが実質的な定義だと（俺様が）言ってるの。

知らんがなｗ

お前が何を言ったところで、
Structureは日本語にしたら構造
Definition（定義）じゃない。

まさか単語の意味を強弁するとは思わなかったなｗ

**デフォルトの名無しさん** · 2016/08/04(木) 21:39:49.22

>>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。

**デフォルトの名無しさん** · 2016/08/04(木) 21:51:04.78

説得力0ｗ

**デフォルトの名無しさん** · 2016/08/04(木) 21:51:55.34

この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。

**デフォルトの名無しさん** · 2016/08/04(木) 22:03:13.75

構造の一例ねｗ

**デフォルトの名無しさん** · 2016/08/04(木) 22:10:23.67

デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。

**デフォルトの名無しさん** · 2016/08/04(木) 22:12:49.41

まさかデザインパターンがGoFの23個だけだと？
あれはパターン例だよ

**デフォルトの名無しさん** · 2016/08/04(木) 22:14:24.41

>>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ？

**デフォルトの名無しさん** · 2016/08/04(木) 22:20:23.44

Structureは日本語にしたら構造
Definition（定義）じゃない。

国語と英語の問題なｗ

**デフォルトの名無しさん** · 2016/08/04(木) 22:24:49.05

アホの一つ覚えとはこのこと

**デフォルトの名無しさん** · 2016/08/04(木) 22:45:18.74

効いてる効いてるｗ

**デフォルトの名無しさん** · 2016/08/05(金) 05:47:03.48

あるプログラム片の構造がパターンカタログのものと異なっていたら、
そのプログラム片はそのパターンの実装とは言えないな。

実際問題として、このスレで出ているRuby実装は、GoFに掲載されたデコレータパターンの実装ではない。
それを無視するなら、あなた (ID:jTAWnEUa) にはデザインパターンを使うための
最低限の素地が備わっていないということ。

**デフォルトの名無しさん** · 2016/08/05(金) 07:23:44.09

>>644
あまりにひどくて、なにをいっているかわからなかった。SmalltalkはともかくRubyのコードも読めないのかと。

内部イテレーターを使ったこの実装をイテレーターパターンだと言い切るのはどう考えても無理があるし、
同じ理屈でクロージャーを使った件の実装をデコレーターパターンだと言い張っているなら混乱するだけだからやめてほしい。

**デフォルトの名無しさん** · 2016/08/05(金) 08:28:16.86

>>664-665
この二人は単に常識的な発言をしているだけだが
きっと相手には伝わらないだろうね

**デフォルトの名無しさん** · 2016/08/05(金) 11:01:37.11

結局オブジェクト志向が理解出来なくて管を巻いていたら
世間はプロトコル志向に移ってしまったでござるの巻
お前ら何周遅れたら走り出す気になるの？

**デフォルトの名無しさん** · 2016/08/05(金) 12:54:45.79

Swiftのプロトコルも何周回目か遅れですよ？
ScalaやRustのトレイトとか知らないんですか？

**デフォルトの名無しさん** · 2016/08/05(金) 13:11:37.22

イテレータをアイテレータって書いてる人がいるけど
どこの方言なの？
weblioさんの発音もイテレータなんだけど

**デフォルトの名無しさん** · 2016/08/05(金) 14:20:51.80

weblioワロタｗ　もっとちゃんとした辞書持って来いよ。
Merriam Websterとかさ。和英辞書を引用して日本語論じたりしないだろ？

色々調べてみたけど、Wikitionaryのiterateでは二重母音の発音も載せてる。
その他の辞書では見つからなかった。

実際に英語ネイティブのアメリカ人が/ai/でも発音しているのを聴いたこともある。
伝統的には一般的な発音じゃなかったけど、IT界隈でよく使われているうちに、
発音変種が発生したんじゃないか？　英語発音学的にはどちらでも許容されそうだし。

**デフォルトの名無しさん** · 2016/08/05(金) 14:53:55.08

>>669
方言というより極度の経験不足なんだろ
イテレータについて人と語った事が無いから
間違いがずっと正されずにここまで来たんだろうな

**デフォルトの名無しさん** · 2016/08/05(金) 15:20:22.46

>669
iとかitとかitrとかiterとかに略すから
アイ、イット、アイター、アイターとかって呼んでいるのでは
発音している本人に聞かないと真相はわからんがな

**デフォルトの名無しさん** · 2016/08/05(金) 15:25:47.40

クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ

**デフォルトの名無しさん** · 2016/08/05(金) 15:40:45.96

クロージャーを使った実装はデコレーターパターン（GoFの）ではないという話なんだが

**デフォルトの名無しさん** · 2016/08/05(金) 15:47:55.44

>>673
別のパターンって言ってるだけでは？
覚えやすさや関連性からデコレーターの名前を関するのは自由だけど。

**デフォルトの名無しさん** · 2016/08/05(金) 16:10:54.07

Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする

**デフォルトの名無しさん** · 2016/08/05(金) 16:22:03.55

デコレータパターンの機能を持っている設計を
全部デコレータパターンとしてしまっては
デザインパターンの意味がないからな

そりゃどんな方法でも同等の機能は実現するかもだが
ある程度を設計をパターン化して縛るのが目的でもあるからね
なんでもOKだったら意味ないよね

**デフォルトの名無しさん** · 2016/08/05(金) 16:30:02.44

カタログ化の価値を下げようとする連中は居るんだよ
広義のデザインパターンは～とか
○○も××パターンの亜流と言えるだろう～とか
拡大解釈と独自解釈でどんどん元の輪郭をぼやかしていくんだよ

**デフォルトの名無しさん** · 2016/08/05(金) 18:48:03.79

>>677
ケーキにホイップクリームのせるのもおちんぽにコンデンスミルクかけるのもデコレーションには違いないだろ実装が違うだけでやってることは完全に同じなのだから継承か委譲かクラスかクロージャかといった細かい違いを気にしなくていいからこその設計だと思うのだよ

**デフォルトの名無しさん** · 2016/08/05(金) 18:50:15.99

実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ

**デフォルトの名無しさん** · 2016/08/05(金) 19:29:11.85

>>680
そうか、おまえがいう「デザイン」「ソフトウェア設計」は実装を縛らないのか。
ずいぶんフリーダムなプログラマだなw

**デフォルトの名無しさん** · 2016/08/05(金) 19:48:51.35

クラス図レベルがデザインパターン。
そこから実際にどう具体的な言語でコードに落とし込むかが実装。

クラス図レベルで全く違うものはパターンとして別物です。

**デフォルトの名無しさん** · 2016/08/05(金) 20:06:03.26

おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな？

**デフォルトの名無しさん** · 2016/08/05(金) 20:28:42.82

>>670
それ単に英語がなまっているだけだから

**デフォルトの名無しさん** · 2016/08/06(土) 08:01:13.80

>>684
なまってるんじゃなくて、発音が[i]の母音に強いアクセントがつくと[ai]に転じるのは普通。
iterateの第1母音は普通は[i]だが、iterateという語を特に強調する時には[ai]になることもある。

ちなみにweblioはUS出身のNLP研究者にも評価が高かったりするから、そう馬鹿にしたものでもない。

**デフォルトの名無しさん** · 2016/08/06(土) 10:06:20.97

>>685
だから英語の訛りでドイツ語やフランス語では起こらない
https://ja.wikipedia.org/wiki/%E5%A4%A7%E6%AF%8D%E9%9F%B3%E6%8E%A8%E7%A7%BB

**デフォルトの名無しさん** · 2016/08/06(土) 10:13:18.00

だからどうしたんだって話

**デフォルトの名無しさん** · 2016/08/06(土) 10:17:01.24

アイテレータ君は頑張りどころを間違えてる

**デフォルトの名無しさん** · 2016/08/06(土) 11:27:40.31

>>686
Haben Sie gelesen, eine deutsche Übersetzung?

**デフォルトの名無しさん** · 2016/08/06(土) 12:00:01.53

https://translate.google.co.jp/#de/ja/Haben%20Sie%20gelesen%2C%20eine%20deutsche%20%C3%BCbersetzung%3
あなたはドイツ語の翻訳を読んでいましたか？

**デフォルトの名無しさん** · 2016/08/06(土) 12:02:23.29

>>689
Was davon ist im Zusammenhang mit?

**デフォルトの名無しさん** · 2016/08/06(土) 13:54:29.24

>>691
Das ist meine Frage.

**デフォルトの名無しさん** · 2016/08/06(土) 15:01:07.75

Nein, es ist meine Frage

**643** · 2016/08/06(土) 19:33:40.65

そんなアイレテーター君にヒントをもらった>>646 ですが、
週末の余暇を使って調べ調べ C++ で書いてみました。

http://ideone.com/aMHgqO

なるほど。このくらい抽象化して簡潔に書けるなら
今の C++ には35年ほど前の Smalltalk 同様イテレーターパターンは不要と言い切ってよさそうですね。

惜しむらくは逆順用の range-based for くらい用意しておけよ…、という不満は残りますが。^^;

**デフォルトの名無しさん** · 2016/08/06(土) 20:05:53.09

そもそもbegin, endなどのモロモロが
既に（外部）イテレータ以外の何物でもないわけでｗ

内部イテレータ形式を欲しがるかどうかはともかく
range-based forとかはどうでもいいよねこの場合

**デフォルトの名無しさん** · 2016/08/06(土) 20:24:55.16

アメリカ英語なんて
英語の方言そのものだろ。ｗ
トマトをトメイトゥとか、
ポテトをポテイトゥとか
馬鹿みたいな発音するんだぜ。
アイテレーターみたいな馬鹿っぽい発音が好きなのか？