- 1 名前：デフォルトの名無しさん mailto:sageteoff [2016/01/05(火) 02:10:25.72 ID:hJUQcrkl.net]
- オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
https://twitter.com/ProgrammingMono/status/665702678006140928
研究グループは、血管新生注において血管が伸長する際の血管内皮細胞注運動を制御するしくみを、生物学と数理モデル・
コンピュータシミュレーションを融合させた先端的な研究手法により明らかにしました。
生物は、最小の機能単位である細胞が寄り集まった多細胞体です。しかし、細胞の集まりが、組織や器官といった
秩序ある形態や構造をつくり機能するしくみはほとんど分かっていません。中でも血管は、体中の全組織に十分な
酸素や栄養源を効率よく供給するため、組織や組織の間に入り込み、血管外の環境との相互作用により、巧妙な
枝分かれ構造をとっています。
これまでに本研究グループは、新しく血管がつくられる（血管新生）際の細胞の動きに着目し、特に血管内皮細胞の
動きをリアルタイムで可視化し、定量的に捉えることを可能にしてきました。
今回さらに、血管の伸長を制御するしくみについて、細胞が自発的に自らを制御して動く過程（自律的過程）と、
隣接した細胞から適宜影響を受けて動く過程（協調的過程）がうまく共存することで、全体の動きが巧みに統制
されていることを世界に先駆けて実証しました。
興味深いことに、血管内皮細胞が前後したり、お互いに追い抜きあったりという血管新生で見られる複雑な細胞集団の
動きを制御している中枢部分は、細胞一つ一つの動き（スピードと方向性）の「確率的な変化」として十分説明できる
ことをコンピュータシミュレーションで実証しました。
www.jst.go.jp/pr/announce/20151120-2/#YOUGO3
前スレ
オブジェクト指向は愚かな考え。この世は計算式 ★2
peace.2ch.net/test/read.cgi/tech/1450153388/
- 549 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 20:24:15.92 ID:wOSsX6OQ.net]
- >>548
とっくに解けてるじゃん
ばか？
- 550 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 20:30:55.27 ID:lROFhaXh.net]
- どう解けてるんだよ。
人間の肛門と天使の肛門にコンポーネントするのか？
- 551 名前：デフォルトの名無しさん [2016/08/02(火) 20:41:47.88 ID:UCo4tbLK.net]
- 用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。
- 552 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 20:42:03.85 ID:9rM4/wP9.net]
- 美少女は偶像であり人間ではない
- 553 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 20:57:34.64 ID:flPsn8Jo.net]
- もうそろそろいいかな？
みんな「デコレーターパターン」をどうするか？というテーマで
会話が成り立ってるよね？
つまりこういうことさ。デザインパターンっていうのは用語。
実装じゃない。
デコレーターパターンをJavaならこう書く、SmallTalkならこう書くと
いうふうに共通認識ができてる。これこそデザインパターンの有用な所。
だからコードの書き方が決まってるわけじゃないんだよ。
設計だからね。言語が決まらない状態であっても話はできる。
デザインパターンをどういうふうに書くかってのは例でしか無いんだよ。
目的を達成できるならどう書くてもいいし、デコレータパターンを
どう書いてもそれはデコレータパターンなのさ。
SmallTalkであってもデコレーターパターンっていうのは存在する。
だからこそSmallTalkでデコレータパターンをシンプルに書くことができる！と
主張できる。
- 554 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:16:53.04 ID:LOKS06K+.net]
- >>553
なんでみんなより二歩も三歩も手前な意見を
そんな長文で書き込めるの？
- 555 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:20:29.76 ID:flPsn8Jo.net]
- >>554
言いたいことはそれだけかｗ
- 556 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:22:05.73 ID:LOKS06K+.net]
- ごめんね
- 557 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:24:18.11 ID:e9gYPknx.net]
- Smalltalk の t を大文字で書くやつは無知か知ったかぶり
- 558 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:24:35.32 ID:lROFhaXh.net]
- 実は誰も Smalltalk なんて知らない www
- 559 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:27:22.36 ID:flPsn8Jo.net]
- 反論あるなら待ってるよｗ
- 560 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:32:29.72 ID:LOKS06K+.net]
- >>557
ワロタｗ
- 561 名前：デフォルトの名無しさん [2016/08/02(火) 21:38:39.55 ID:UCo4tbLK.net]
- 言語は関係無いと言う内容の話への反論が、言語名のミスプリントの指摘とか、レベル低過ぎだろw
小学生の負け惜しみかよw
- 562 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:39:26.48 ID:flPsn8Jo.net]
- >>561
え？それ反論だと思ってたの？
反論はまだ一つも来てませんよｗ
- 563 名前：デフォルトの名無しさん [2016/08/02(火) 21:40:28.47 ID:UCo4tbLK.net]
- うゎw
保育園だなここはw
- 564 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 21:47:57.27 ID:6KXXOitA.net]
- >>561
「プリント」とかまさに小並
- 565 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 22:08:58.16 ID:e9gYPknx.net]
- >>553
>>538で「見たいだけ」って言ってるところをみると、これは反語で
>>546みたいに簡潔なのが出てくるとはこの時点では考えてなかったんじゃない？
だからデザパタは用語で実装じゃない、言語は関係ないって趣旨替えしたように読むのは穿ちすぎ？
- 566 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 22:14:56.76 ID:flPsn8Jo.net]
- >>565
いやｗ
最初からこのために、
デコレータパターンをSmallTalkで書いたらどうなるの？って
話題を振って会話をさせたんだよ。
デコレータパターンという共通知識があり、
SmallTalkでそれを実装することができるという会話をね。
もし実装が決まっているものであれば、
SmallTalkでデコレータパターンを実装すれば
シンプルな形で実装できるんだっていう話はでてこない。
- 567 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 22:27:10.71 ID:KCBRtMku.net]
- そもそもC++でデコレーターでもそんな難しくないでしょｗ
シングルトンの方がよっぽどややこしい。
- 568 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 22:30:18.68 ID:flPsn8Jo.net]
- 「シングルトン」だけで話が通じる所がデザインパターンの
便利なところだね。
さてシングルトンにもいろんな実装があるけど、
DIコンテナを使ってシングルトンに見せるっていう方法もあるよね。
これだと普通にクラスを作るだけで良くなる。
- 569 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 22:34:48.24 ID:qU1dasmj.net]
- 兄さん、そこでPythonですよ
ですしおすし
- 570 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 23:26:19.20 ID:QqIbwu4d.net]
- Java8ならもっとHENTAIなコードが書けるぞ
ideone.com/DbIiD0
- 571 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 23:41:10.66 ID:6KXXOitA.net]
- >>570
>>547
- 572 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 23:59:46.02 ID:lROFhaXh.net]
- Smalltalk の最大の魅力は、
それが雑談に過ぎないということである。
by アラン・ケイ
- 573 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 00:45:18.40 ID:qJ0ntPw4.net]
- >>570
new Price((120*2+80)*2+200) を作りたいわけではなくて
new Price(120) をデコって 840 を返させるのが Decorator
だからデコったあとに setValue(100) してから getValue() すると 760 が返るはず
ideone.com/Z24LFA
ideone.com/Diod1I
ideone.com/x2goNr
ideone.com/do6fT9
- 574 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 11:21:17.97 ID:nNt8IZmK.net]
- >>566
まるでちがう。>>546はデコレータパターンじゃない。
Javaではデコレータパターンを使う問題を
デコレータパターンを使わずにより簡潔に記述した例。
- 575 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 12:45:10.82 ID:XBNCNfrP.net]
- >>539
型が動的だと>>535の例のようなコードはどうなるの？
- 576 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 15:55:24.00 ID:8J75MUHP.net]
- SmallTalkとか
- 577 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 17:09:10.94 ID:R0iPm5qU.net]
- 関数型インターフェースの方が簡潔になる
ideone.com/6MAwKM
>>573
setValue(100)してからgetValueしたら100返らなきゃバグってるだろ
setOriginalValueとかに修正するところだな
- 578 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 18:07:08.01 ID:8J75MUHP.net]
- Wikipediaにある
> Decorator パターンの方針は、既存のオブジェクトを新しい Decorator オブジェクトでラップすることである。
がわかってない奴がいるな
- 579 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 18:17:54.35 ID:qhbdc1zB.net]
- デザパタの目的とされがちであるが
常に失敗しているのが語彙の共有
いつでもつねに認識がバラバラｗ
- 580 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 18:21:38.71 ID:8J75MUHP.net]
- >>579
ごく一部の人間が正しく理解できてないだけで、
> いつでもつねに認識がバラバラｗ
は言い過ぎ
- 581 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 18:45:37.19 ID:9oohU77o.net]
- >>577
> 関数型インターフェースの方が簡潔になる
そんなんでいいなら Smalltalk でも簡潔に書けるけどね
ideone.com/RZHQ7P
- 582 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 19:57:46.85 ID:N9MmOijn.net]
- Smalltalkに意味なんかないよ
登場してから30年とか40年とか経ってるのに
誰も現場で使ってない言語だからね
40年という歳月は結論を出すのに十分な時間だと思うよ
これから先もずっと使われないだろう
こんな言語についてあれこれ考えるのは時間の無駄だよ
御幣を恐れずに言うと、Smalltalkは間違っている、机上の空論
本当によくできていたなら、もうちょっとぐらい使われていてもおかしくない
少なくともRuby程度ぐらいには使われてないと話にならない
Smalltalkは実用にならないスジの悪い言語だということ
- 583 名前：デフォルトの名無しさん [2016/08/03(水) 20:22:04.47 ID:M+rE/wd/.net]
- Smalltalkは言語だけじゃダメで。
windows上では使い物にならないから仕方無い。
- 584 名前：デフォルトの名無しさん [2016/08/03(水) 20:23:22.86 ID:M+rE/wd/.net]
- 要するに、windows自体がオブジェクト指向に向いてないんだよ。
- 585 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 20:29:26.00 ID:1jcdD/Xi.net]
- 結論。
誰も Smalltalk なんて知らない www
- 586 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 20:32:04.15 ID:N9MmOijn.net]
- それは関係ない
なぜなら概念上の問題より運用上の問題のほうが大事だから
いくら概念的な素晴らしさを語ったところで
まともに運用できないならゴミ
使えない
- 587 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 20:45:27.46 ID:YtpqVXv4.net]
- >>574
> Javaではデコレータパターンを使う問題を
> デコレータパターンを使わずにより簡潔に記述した例。
お前は勘違いしているな。
デコレータパターンを実装しなさいというお題なんだから
それがデコレータパターンなんだよ。
Javaならこういう実装でやるが、他の言語では
その実装方法が違うだけ。
- 588 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 21:24:23.35 ID:TE6NppPB.net]
- >>582
まあ仮にSmalltalkが本当に誰も使ってなくて
処理系も失われたり、あるいは as-is で放置された言語だとしたら
そんなものに意味がないって意見は全くもって正しいよね
- 589 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 21:37:23.40 ID:46yxFVyN.net]
- シングルトンやアイテレーターなどは時代が変わっても重要だろうけど、
デコレーターは継承関係への依存度が高いから微妙だな。
- 590 名前：デフォルトの名無しさん mailto:sage [2016/08/03(水) 22:46:55.08 ID:PwtoF+FA.net]
- >>583
Smalltalkは独自のGUIもそうだけれども、もうひとつ、通常のセルフホスティング
（自身で自身を記述）にとどまらず、処理系を構成する実行時オブジェクト群を
仮想イメージと呼ばれる、ある種のオブジェクトストアに永続化して次回起動時も
継続利用する運用スタイルも毛嫌いされるよね。個人的には示唆に富んでいて好きなんだけど
- 591 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:17:31.35 ID:iDV12Qqy.net]
- >>587
いや？
クロージャで実装しているのだから、デコレータパターンによる実装ではないよ。
コード読めない子？
- 592 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:19:01.73 ID:jTAWnEUa.net]
- > クロージャで実装しているのだから、
クロージャで "何を" 実装しているの？
- 593 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:24:24.39 ID:ClPuKc3B.net]
- デコレータパターンを実装できてはいないんだよｗ
これでわかった？ｗ
- 594 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:25:35.63 ID:jTAWnEUa.net]
- いや、何を実装したのかを聞いたんだが？
実装したものは何？
- 595 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:30:18.03 ID:ynLXOlFE.net]
- >>590
あのあたりはむしろメモリや記憶装置いくらでも使える現代向けというか
過去にオブジェクト指向の要素をちょっとだけ輸入してみた中途半端なオブジェクト指向言語が次々出ては滅びの興亡続けてたのは
"コンパイル後のサイズが大きいじゃないか"とかいまじゃヘソが茶を沸かすような理由がメインなわけだし。
- 596 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:31:24.04 ID:w6fnMNqO.net]
- デコレータパターンと同等の機能をクロージャで実装した
じゃね？
同等の機能を持った違った実装があるのは当たり前じゃね？
デコレータパターンと同じような機能をもたらすけど
デコレータパターンじゃない実装は普通にあり得るんじゃね？
- 597 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:34:51.00 ID:jTAWnEUa.net]
- >>595
パターンは機能じゃないよ。設計。
デコレータパターンという設計
この設計の実装はいろいろある。
決まっていない。
Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。
- 598 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:36:04.52 ID:jTAWnEUa.net]
- 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)
デザインパターンは、よく使われる設計を一般化された形でまとめたものに過ぎない。
そのため、具体的な実装を提供するものではなく、
あくまでもコンセプトとして参照されることが意図されている。
つまり、サンプルコードは、実装例に過ぎない。
- 599 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:42:01.96 ID:w6fnMNqO.net]
- >パターンは機能じゃないよ。設計。
それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ？
俺の言ってることと一緒だね
- 600 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:44:00.26 ID:fESKb5E9.net]
- ID:jTAWnEUaを教育してあげる義務は我々には無い
- 601 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:45:06.02 ID:jTAWnEUa.net]
- >>599
わざわざ複雑にしないでいいよｗ
やりたいことがある。
でも説明するのが面倒くさい。
じゃあ「デコレーターパターン」と呼びましょう。
これで話は通じてるじゃん。
だからこれだけの情報でコードを書くことができる。
そのデコレーターパターンを
クロージャーで実装したんでしょ？
そういえば良いんだよ。
- 602 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 00:48:34.94 ID:jTAWnEUa.net]
- >>600
じゃあ一緒に勉強していきましょう（笑）
www.techscore.com/tech/DesignPattern/foundation/foundation1.html/#dp0-2
> 前章でも説明したとおり、デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」を
> まとめたものです。 デザインパターンを利用するメリットとして、最初にあげられるのが、
> 「再利用性の高い柔軟な設計ができる」という点です。各パターンには、多くの知恵が凝縮されています。
> これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
> 初心者でも先人たちが詰め込んだ「知恵」を利用した設計をすることが可能となります。
> また、先人たちの知恵を参考にすることで、設計力の向上も期待できます。
>
> 次のメリットは、「技術者どうしの意思疎通が容易になる」ことが挙げられます。
> デザインパターンを習得している技術者どうしであれば、設計について相談するとき
> 「Singleton パターンで行きましょう」とか「Strategy パターンが応用できるのではないでしょうか」と
> いうようにパターン名で設計の概要の合意を取ることが可能です。デザインパターンを
> 習得していない技術者には「こんなクラスを作って、このクラスはこんな役割を持っていて・・・。」と
> 延々と説明しなければなりません。このように、デザインパターンを学習しておくことで
> 開発者どうしの意思疎通がスムースになるのです。
あなたは何で勉強していますか？
- 603 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 01:13:23.05 ID:w6fnMNqO.net]
- 話をややこしくしているのはあなたです
>パターンは機能じゃないよ。設計。
↑これは君が言ったことだよね
その上で俺は、同等の機能を持った、違ったデザインなんじゃね？って言ってるわけ
機能が同じであっても、同じデザインパターンとは限らない
何故なら、デザインパターンは機能じゃないから、設計のパターンだから
↑君の言ってることと全く同じだよね
だから同じ機能だけど、違った設計パターンであり
同じデザインパターンに属さない設計は有る
ということを君は認めているということ
- 604 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 01:43:58.02 ID:w6fnMNqO.net]
- デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの
ってのは正に君が自分で言ったことであって
それは俺も了承している
だから同じ機能であっても、それだけで同じデザインパターンとは言えないよね
と俺は言ってるわけ
なぜならデザインパターンは機能では無いから(君の言ったことだよね)
そもそも俺とお前とのやり取りに、何のとどこおりも無い
俺は、>>596で同等の機能を別の設計で実装したんじゃないか、と言い
お前は>>597でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている
合わせると、「同等の機能であっても同じデザインパターンであるとは限らない、設計で決まる」
という結論が得られる
- 605 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 01:56:34.90 ID:tMKvO+zV.net]
- デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。
これと同じことが他のデザインパターンでもできるんじゃね？という主張だったと思うんだが。
Singletonは言語によって容易に達成できるものもあればそうでない言語もあるが、そう難しくは無いはず。
OCamlだったらmutable valueを持ったモジュール使えば同等のことが実現できる。
Adapterパターンも変更できない物がオブジェクトだったら関数1つで済むし、
モジュールだったらファンクタ使えば良い。
これを続けていけばデザインパターンがOOPの表現力の低さを解決する妥協案である、と示せる気がするが、
逆にOOPでデザパタ使うのが一番簡潔になる問題を探す方が難しいかもね。
- 606 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 03:16:53.36 ID:jTAWnEUa.net]
- やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。
まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。
そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。
- 607 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 03:18:24.28 ID:jTAWnEUa.net]
- OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。
C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。
- 608 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 06:27:25.67 ID:iDV12Qqy.net]
- >>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。
JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。
- 609 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 09:14:32.03 ID:jTAWnEUa.net]
- >>608
それはオレオレ定義ですよね。
- 610 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 09:31:36.26 ID:0aO0sFCL.net]
- デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。
「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。
プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。
- 611 名前：デフォルトの名無しさん [2016/08/04(木) 09:33:28.01 ID:IwXa2U8x.net]
- 内容を理解してないから例にある記述方法しか受け付けないんだよ。
- 612 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 09:33:48.07 ID:jTAWnEUa.net]
- > だから、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
- 613 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 09:34:24.97 ID:0aO0sFCL.net]
- >>610
あ。引用部分は自炊本の OCR のコピペなんで、タイポは脳内補完ねがいます。
- 614 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 09:35:44.09 ID:0aO0sFCL.net]
- >>612
GoF も「Smalltalk では簡単に記述できるものもある」とは言っているけど、
ぜんぶがぜんぶとは言っていないよね。
- 615 名前：デフォルトの名無しさん [2016/08/04(木) 09:35:54.66 ID:IwXa2U8x.net]
- >>612
おまいみたいなバカに本を売り付ける為だろw
- 616 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 09:38:22.54 ID:jTAWnEUa.net]
- >>615
え？捨て台詞？ｗ
- 617 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 10:07:48.33 ID:e/09ny1R.net]
- これはまさに捨て台詞で十分な一例。
- 618 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 10:14:03.24 ID:0aO0sFCL.net]
- > だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。
Smalltalkを好意的にとらえて持ち上げてくれるのは、狭い視野で意味なし認定しちゃう人たちよりは
ファンとしてはありがたいけど、これはさすがにオーバーエスティメートだし、
もうちょっとSmalltalkならではのアドバンテージを学んでから、適切な持ち上げ方をしてほしい…
- 619 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 10:47:43.12 ID:iDV12Qqy.net]
- 「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。
- 620 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 11:37:47.99 ID:0aO0sFCL.net]
- >>619
もしそうだとしても、少なくとも>>591は「GoFの（デコレーター）」と明記すべきですよね
- 621 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 12:27:01.14 ID:CY/jwgqy.net]
- smalltalkって簡単に色々できるんでしょ？
なんで現代でメジャーじゃないの？
- 622 名前：デフォルトの名無しさん [2016/08/04(木) 12:30:59.74 ID:IwXa2U8x.net]
- 日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ？
- 623 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 12:31:27.57 ID:79cTVfxr.net]
- MSがVisual Smalltalkをつくらなかったから
- 624 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 12:57:32.53 ID:iDV12Qqy.net]
- >>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが？
- 625 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 13:05:00.50 ID:rDDGHvQu.net]
- はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。
- 626 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 13:16:23.28 ID:0aO0sFCL.net]
- >>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン（GoFの定義如何に関わらない）というのを提示してもらうことはできますか？
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。
そもそも Smalltalk ではデコレーターパターンが不要（なので、実装はナンセンス）とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。
- 627 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:01:27.52 ID:gwNa+xfa.net]
- つか、>>546のruby版って一体何？
デコレータパターンのつもり？
- 628 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:13:24.61 ID:0aO0sFCL.net]
- >>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満？
- 629 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:41:37.79 ID:gwNa+xfa.net]
- >>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
- 630 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 14:42:24.41 ID:gwNa+xfa.net]
- 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
- 631 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 16:18:58.29 ID:0aO0sFCL.net]
- >>629
これでいい？
ideone.com/WGTiOD
- 632 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 16:59:33.41 ID:gwNa+xfa.net]
- >>631
なんか実装手段が違ってきてますが・・・。
>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。
- 633 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 17:09:10.90 ID:0aO0sFCL.net]
- >>632
> なんか実装手段が違ってきてますが・・・。
本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので
> closureを使えばデコレータパターン同等のことができる
>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい
- 634 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 17:41:28.54 ID:gwNa+xfa.net]
- >>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。
WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。
一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか？
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。
- 635 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:07:30.87 ID:iDV12Qqy.net]
- >>626
だーかーらー、
デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装（当然、上記デコレータパターンの実装ではない）で実現できる。
という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる？
- 636 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:33:42.23 ID:0aO0sFCL.net]
- >>634
> 一方、>>546のコードだとそうはいかない。
単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。
- 637 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:57:12.60 ID:0aO0sFCL.net]
- >>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。
- 638 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 18:59:34.21 ID:iP1jJ0aF.net]
- >>610
iteratorはどっちが楽なの？
- 639 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 19:27:18.45 ID:0aO0sFCL.net]
- >>638
Smalltalk と C++ との比較で？ それならもちろん Smalltalk です。
（同書P.289より）
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。
（標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。）
- 640 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 19:40:49.06 ID:HlIXxJdQ.net]
- >>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね？
別にSmalltalkが特別ってことにはならない。
- 641 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:21:25.52 ID:jTAWnEUa.net]
- >>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、
修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。
- 642 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:23:12.92 ID:jTAWnEUa.net]
- デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。
- 643 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:37:49.54 ID:0aO0sFCL.net]
- >>640
Smalltalkが特別ってことにはならないという点については同意します。
ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも
とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか？
あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を
qiita.com/jonichonpa/items/208dc2361414f93efacf
Smalltalkで書いてみました
ideone.com/oplhQu
もちろんSmalltalk方式を採用した言語（たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため
ideone.com/xlQZqc
- 644 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:41:57.05 ID:jTAWnEUa.net]
- イテレーターパターンをSmalltalkで書いてみたわけね。
- 645 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:47:45.80 ID:XSjm71+w.net]
- イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ
- 646 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 20:55:24.22 ID:HlIXxJdQ.net]
- >>643
for each (range based for）でいいじゃん。
for (auto& item : collection)
{
// print an item
}
クロージャ風がいいなら、
std::for_each(collection.end(), collection.begin(), [](auto& item){ /* print */}
アイテレーターが登場するけど昔の名残みたいなもんで、
本質じゃないだろ？（範囲を指定してるだけ）
- 647 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:08:55.10 ID:ILqHD9/M.net]
- >>642
クロージャを使ったらデコレータとは言わないのでは？
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。
無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。
言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。
- 648 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:15:46.97 ID:jTAWnEUa.net]
- >>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。
- 649 名前：デフォルトの名無しさん mailto:sage [2016/08/04(木) 21:21:02.95 ID:CmNfOhbZ.net]
- >>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。
|
 |
