オブジェクト指向は愚かな考え。この世は計算式 ★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/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

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

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

>>695
おっしゃりたいことがよくわからなかったのですが
「イテレーター（内部なり外部なりの）が標準で提供されていればイテレーターパターン（GoFの）はいらない」
という主張（>>639,646）に対して「そもそも～」はどういう反論で、
range-based forがなぜ「どうでもいい」という話になるのしょうか？

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

>>693
おいおい、Neinに続いて肯定文とか、なんなんだその日本語みたいなドイツ語もどきはw

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

>>696
はいはい、あなたは馬鹿ですよ。認めてあげましょう。

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

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

だめだ、こいつは手の施しようがないw

**デフォルトの名無しさん** · 2016/08/07(日) 00:32:53.21

>>697
ごめん
流れつかめて無かったわ

標準のコンテナにイテレータがあるんなら
それを使う限りはイテレータパターンの必要も無い
（内部イテレータ形式もrange-based forも無くてもいい）

それだけの話
スレの最初のほうに既に書かれてる話

**デフォルトの名無しさん** · 2016/08/07(日) 00:34:17.18

もう少し正確に言えば、言語やライブラリが
イテレータパターンを実装しているから、
あとはそれに従うだけって感じかな。
意識せずにイテレータパターンを使っている。

**デフォルトの名無しさん** · 2016/08/07(日) 00:40:31.89

>>702
そやね
その言い方は正しい

**デフォルトの名無しさん** · 2016/08/07(日) 06:55:15.73

>>702
「意識せずにイテレータパターンを使っている」は大間違い。

**703** · 2016/08/07(日) 08:03:17.31

>>704
そやね
そっちが正しい
パターンを使うのは設計者だからね

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

おっすおらフリーダムプログラマ
日夜社畜プログラマと戦ってるだ

**デフォルトの名無しさん** · 2016/08/08(月) 13:46:12.84

>>702
> もう少し正確に言えば、言語やライブラリが
> イテレータパターンを実装しているから、

正確に言うなら、イテレータパターンというのは、
> コンテナオブジェクトの要素を列挙する手段を独立させることによって、コンテナの内部仕様に依存しない
> 反復子を提供することを目的とする
実装パターンのことで(Wikipediaより)、言語やライブラリがiterableな何かを提供しているからといって、
それらがイテレータパターンを実装しているとは限らない。

**デフォルトの名無しさん** · 2016/08/08(月) 13:48:55.90

>>680
> 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
発想が逆だね。
ある機能を実現するための実装パターンを分類・カタログ化したものが、GoFのデザインパターンだ。

**デフォルトの名無しさん** · 2016/08/08(月) 21:13:01.03

まさしくその通りだね
そして同じ機能だったらどんな設計でもOKとしてしまっては
デザインパターンの意味がない
でもこの話題はもう終わりにしたいね

**デフォルトの名無しさん** · 2016/08/08(月) 21:24:02.49

だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
だから積み木のおうちでも構わないんだよなぁ

**デフォルトの名無しさん** · 2016/08/08(月) 21:38:41.07

パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。

**デフォルトの名無しさん** · 2016/08/08(月) 21:41:39.71

>>709
とは言っても言語が違ってもデザインパターンは通用するわけで
実装がたった一つというわけじゃないのは確か

C言語でオブジェクト指向をすることだってあるし、
クラスがなかったES5時代のJavaScriptでもデザインパターンは作れた。

重要なのはデザインパターンの設計に出てくる登場人物があるかどうかではないだろうか？
例えば、Decoratorパターンだと、Component、ConcreteComponent、
Decoretor、ConcreteDecoratorという登場人物がある。

これはクラス図で書かれているだろうけど、別にクラスである必要はない。
例えばクロージャーを使って実装してもかまわない。
またインターフェースは明示的に継承していなくても、事実上特定の関数を実装していなければ
正しく動かないなら、それはインターフェースを使っていると言ってもいいだろう。

これと同じ登場人物が出てくるものは同じデザインパターンといっても良いだろう。

**デフォルトの名無しさん** · 2016/08/08(月) 21:46:47.76

そこまで行ったら別物だって。
クロージャーやら使ってクラス図レベルで逸脱してもいいという
宗派をひらきなよ。

**デフォルトの名無しさん** · 2016/08/08(月) 21:57:23.36

>>713
そうはいってもだね。
クラス図がないES5でもデザインパターンの
設計通りに作れるでしょ？

**デフォルトの名無しさん** · 2016/08/09(火) 05:48:45.82

>>712
ばーか

**デフォルトの名無しさん** · 2016/08/09(火) 07:42:08.32

>>714
クラス、クラス図がないからデザパタにクラスは不要というのは、本末を転倒してますよ。

GoF も述べているように（>>610）クラスの無い言語では、クラスの役割りを「カプセル化」パターン、
「継承」パターン等で補ってから、その上でたとえばデコレーターパターンを実現しているというだけです。

**デフォルトの名無しさん** · 2016/08/09(火) 09:40:43.48

>>716
なるほど。言語仕様としてクラスの有無ではなく
継承パターンができていれば、その実装がクロージャーでも
かまわないということですね。

そして継承パターンと言うものには、何が何を継承している
という概念があるはずですから、その「何」が登場人物に
なるわけですか。

**デフォルトの名無しさん** · 2016/08/09(火) 10:28:51.94

登場人物という考え方がバカっぽくて無理

**デフォルトの名無しさん** · 2016/08/09(火) 15:03:31.41

「○○言語だともっと簡単に実装できる」君と
「クロージャを使えばもっと簡単に実装できる」君は
いい加減うざいよ？

**デフォルトの名無しさん** · 2016/08/09(火) 16:26:29.88

>>719
その通りだと思います。
まずはソフトウェア設計は実装ではないが、
実装を縛る規範であるということを
理解したらいいと思います。

それが理解できたら帰っておいで。

**デフォルトの名無しさん** · 2016/08/09(火) 17:57:41.45

デザインパターン
日本語で
設計見本でいいですか？

**デフォルトの名無しさん** · 2016/08/09(火) 18:04:53.60

そんな日本語があるか

**デフォルトの名無しさん** · 2016/08/09(火) 19:57:07.69

>>708
それは過程の話な結果として実装を示すならインプリメンテーションパターンと言っているだろうしかしデザインパターンと言っているから実装を抽象化したものだ具体的な実装を示すものではないってことさ

**デフォルトの名無しさん** · 2016/08/09(火) 20:07:31.05

その前に君の書き込みを日本語のパターンにしてください

**デフォルトの名無しさん** · 2016/08/09(火) 20:08:56.33

>>681
設計が実装を具体的に決めてしまったら設計の意味がないと思うんだよおトイレとお風呂が一緒になってますってことと具体的な便器の形とは分けられると思うんですデザインパターンっていうのはいわばそういうものでお風呂とトイレを一緒にしたら便利だよってことさ

**デフォルトの名無しさん** · 2016/08/09(火) 20:10:54.82

>>724
おだまり便器野郎

**デフォルトの名無しさん** · 2016/08/09(火) 20:24:12.28

どうせ計算式をクラスにするんだろ？

**デフォルトの名無しさん** · 2016/08/11(木) 18:28:28.20

濃厚電波、完飲。

**デフォルトの名無しさん** · 2016/08/15(月) 00:10:10.82

いい加減、オブジェクト指向 vs 関数型なんていう無意味な議論やめようよ
直交する概念じゃん
関数型言語でも「本物の」オブジェクト指向プログラミングは出来るし、
最近の流行りはオブジェクト指向言語に関数型的な機能を付けることだろう

**デフォルトの名無しさん** · 2016/08/15(月) 01:36:24.27

本当のオブジェクトプログラムは、メッセージ交換だから、関数型が入る余地なんか無いけどな。

**デフォルトの名無しさん** · 2016/08/15(月) 02:08:53.20

お前ら、早く本論に入れ！
美少女クラスはなぜ人間クラスを継承出来ないのよ！！！

**デフォルトの名無しさん** · 2016/08/15(月) 03:13:33.69

美少女はクラスじゃなくて人間クラスのインスタンスで
パラメータが特定の値のものなだけだよ。

プリンセスメーカーであれば「魅力」のパラメータが
高くて「年齢」が若ければ美少女なんじゃね？

**デフォルトの名無しさん** · 2016/08/15(月) 11:57:12.25

排便メソッドはどうなるんだ！

**デフォルトの名無しさん** · 2016/08/15(月) 13:00:28.85

>>729
本物…

**デフォルトの名無しさん** · 2016/08/15(月) 13:36:04.19

>>732
まあそうだな。
人間クラスの女性属性で年齢属性が十代で、
あとはいろんなパラメータがバランス良く絶妙なバランスであるだけ。

**デフォルトの名無しさん** · 2016/08/15(月) 13:43:17.25

>>733
排便性能とでもいうパラメータ作れば良いんじゃねーの？
美少女じゃなくても排便が困難な人っているからな。

**デフォルトの名無しさん** · 2016/08/15(月) 15:37:08.19

便秘気味な美少女かw

**デフォルトの名無しさん** · 2016/08/15(月) 16:44:15.38

　　　　　　　　　　 |
　　　　　　　　　　 |　　彡 ⌒ ミ
　　　　　　　　　　　＼ (´･ω･`)またうんこの話してる...
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

**デフォルトの名無しさん** · 2016/08/15(月) 16:45:21.70

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

**デフォルトの名無しさん** · 2016/08/15(月) 17:02:42.33

アヒルががーがーなくのではなく、がーがー鳴けばそれがアヒルなのである
うんこができればそれは人間なのである

**デフォルトの名無しさん** · 2016/08/15(月) 17:08:50.15

オウムがガーガーなけばそれはアヒルなのである？

**デフォルトの名無しさん** · 2016/08/15(月) 19:19:30.08

>>738
「ウンコを覗くときウンコもまたおまえを覗いているのだ。」

もうこの子は脳の端までウンコになっちゃったんだよ…

**デフォルトの名無しさん** · 2016/08/16(火) 12:32:47.23

頬を紅潮させた少女のアナルは今にも決壊寸前のダムの如くヒクヒクと静かに脈打つのであった
そのアナルをまるで獲物を狙う蜥蜴の様な眼差しでジットリと凝視していたお前は…

**デフォルトの名無しさん** · 2016/09/04(日) 22:44:30.10

やはり、オブジェクト指向は愚かな考えなんでしょうか？
それはなぜですか？

**デフォルトの名無しさん** · 2016/09/05(月) 23:26:30.97

>>744
なんのメリットもないから

**デフォルトの名無しさん** · 2016/09/10(土) 22:12:27.45

クロージャという秘境

**デフォルトの名無しさん** · 2016/09/11(日) 09:06:24.12

オブジェクト指向にクロージャーが取り入れられてから、
オブジェクト指向は更に便利になった。

**デフォルトの名無しさん** · 2016/09/11(日) 09:11:08.53

どうせなら理想のクロージャの構文はどんなものか議論しよう。
美少女のウンコの話はもういいから。

**デフォルトの名無しさん** · 2016/09/11(日) 10:48:53.37

いや美少女うんこの方が重要だ

**デフォルトの名無しさん** · 2016/09/11(日) 18:47:04.73

間をとってクソージャ

**デフォルトの名無しさん** · 2016/09/12(月) 10:17:01.19

おあとがよろしいようで

**デフォルトの名無しさん** · 2016/09/12(月) 11:18:07.22

じゃあ質問
若い時は買ってでもするものな～んじゃ？

**デフォルトの名無しさん** · 2016/09/12(月) 11:24:36.38

コンビニでトイレだけ借りるのは気まずいので後で何か買って帰る

**デフォルトの名無しさん** · 2016/09/12(月) 13:15:37.24

美少女を買う

**デフォルトの名無しさん** · 2016/09/12(月) 21:03:27.94

>>752
http://find-travel.jp/article/2123

シンガポール初　キッズクラブ

１２歳までの子供が安全に遊べます。小さい子供連れのファミリに―にはうれしい施設です。
セントーサエキスプレスの終点ビーチ駅で下車、徒歩五分ほどです。
子供は有料ですが、付き添いの大人は、無料です。

**デフォルトの名無しさん** · 2016/09/12(月) 21:04:17.88

http://www.dan-b.com/tp_luna/page1_1.html

ウェーブスターライド

すべり台

もくば館の電動木馬
自走式のジェットコースター。小さなお子様でも、
大人の付き添いがあれば乗れる。
付き添いの大人は無料にしてくれる心遣いがうれしい。

**デフォルトの名無しさん** · 2016/09/17(土) 19:06:05.53

オブジェクト指向と計算式という対比がまずおかしいスレ

**デフォルトの名無しさん** · 2016/10/11(火) 13:34:51.26

>>757
その前に>> 1の脳みそがオカシイ。
議論以前の話

**デフォルトの名無しさん** · 2016/11/14(月) 16:47:20.70

>>733
排便メソッドつくってうんち吐き出させれば良いじゃん…

**デフォルトの名無しさん** · 2017/03/21(火) 23:51:29.32

できの悪いプログラマはこうやってくだらんことに執着した挙げ句道を外すからな

オブジェクト指向を禁ずるのは当然だが、プログラムも規制すべきだろ

**デフォルトの名無しさん** · 2017/05/12(金) 17:45:37.79

外に公開するインターフェイスだけオブジェクト指向で中身は手続きとかできないの？

**デフォルトの名無しさん** · 2017/05/13(土) 00:36:36.42

欲張りな事言うんじゃありません！

**デフォルトの名無しさん** · 2017/05/13(土) 06:58:15.64

なんでもかんでもOOPしないといけないという強迫観念も新しい病気みたいなもんだ

**デフォルトの名無しさん** · 2017/05/14(日) 02:14:38.21

OOPは自然な概念。
しようとしなくても自然にOOPで書いてしまう。

**デフォルトの名無しさん** · 2017/05/14(日) 03:31:10.29

んじゃ、Cでファイル読んで行毎に番号振るプログラムを自然にOOPで書いてくれ。

OOPな言語でも油断してると手続き的なコードになるのが実感。
手続き型言語や関数型言語のが自然と言えば自然。
OOPはどっちかと言うと手続き型言語の限界を超える苦肉の策。
有効ではあっても、自然ではない。

**デフォルトの名無しさん** · 2017/05/14(日) 07:58:36.42

手続き型の言語使ってるんだからそりゃ書き方は自然に手続き的になるわw