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

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/ 528 名前：デフォルトの名無しさん [2016/08/01(月) 10:06:54.28 ID:Q0J3uZmP.net] いや、デザパタはOOと関係無いから。 関係あるのはOOPの方 529 名前：デフォルトの名無しさん [2016/08/01(月) 10:50:43.99 ID:pyyhbxGP.net] 【閲覧注意】戦闘に巻き込まれて頭部を切断された少女の遺体。これがリアルなシリア。 dqnworld.com/archives/34.html これが本当の戦争の恐怖。この少女には大人の戦争は関係ないですからね。巻き込まれた少女の遺体を持って何か を訴えかけている男たちの映像です。 【閲覧注意】シリアで反体制派の兵士が顔を吹き飛ばされてしまう瞬間。 dqnworld.com/archives/89.html スローモーションが怖すぎる・・・。 【閲覧注意】アッラーフアクバルを叫びながら少年を斬首する映像を公開する。 dqnworld.com/archives/3975.html 点滴？のようなものが見えるんだけど。助けられた少年じゃなかったのか。助けられた所を強奪されてアッラーフ アクバル？なのかしら・・・。 【閲覧注意】磔にされた戦闘機パイロットの遺体。シリアにて。 dqnworld.com/archives/3996.html 今日のアッラーフアクバル動画。 妻の目の前でぶっ飛ばされた旦那さん？これは死んだかな(°_°) dqnworld.com/archives/4004.html さすがにこれだけ飛ばされたら助からないかな・・・。 【閲覧注意】あおむけでゲロを吐きまくっている男性。助けてやれよ・・・。窒息するぞ(@_@;) dqnworld.com/archives/4007.html これ結構危ないんじゃないの？撮影してないで横向きにしてやれよ。これ窒息する可能性あるだろ。 衝撃映像。事故って大回転した車から少女がポロリ。 dqnworld.com/archives/4013.html この少女がどうなったのかが気になる所ですが動画の説明には何も書かれていなかった・・・。 530 名前：デフォルトの名無しさん mailto:sage [2016/08/01(月) 10:52:18.11 ID:IZIdUKpU.net] ここまでLSPの話題なし 531 名前：デフォルトの名無しさん mailto:sage [2016/08/01(月) 17:10:00.57 ID:GD9lEFl6.net] >>525 > デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、 おしい。 デザパタはJavaやC++に適さない問題を無理やりJavaやC++で解決するためのもので、 SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。 532 名前：デフォルトの名無しさん mailto:sage [2016/08/01(月) 18:06:20.18 ID:99zq/hjd.net] smalltalk だと、人間クラスと美少女クラスの問題は どう解決するの？ 533 名前：デフォルトの名無しさん mailto:sage [2016/08/01(月) 20:14:16.64 ID:NIKdUbwx.net] Squeak Smalltalk だと、こんな感じか？ Object subclass: #人間 　　instanceVariableNames: 'もろもろ' 　　classVariableNames: '' 　　poolDictionaries: '' 　　category: '美少女-排便'. 人間 compile: '排便 ^#便'. Trait named: #美少女 uses: #() category: '美少女-排便'. 美少女 compile: '排便 self notify: ''トイレには行きません''. ^#プリン'. おまえら := 人間 new. おまえら 排便. "=> #便 " 橋本環奈 := 人間 new. 橋本環奈 assureUniClass class uses: 美少女. 橋本環奈 排便. "Warning: トイレには行きません => #プリン" 534 名前：デフォルトの名無しさん mailto:sage [2016/08/01(月) 20:39:01.26 ID:E1waX2Jm.net] >>531 > SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。 例えば、どのパターンが簡潔明瞭に記述できるの？ 一番簡単なパターンでいいので書いてみて。 考えるのが面倒なら俺が出題しても良い？ Singletonは個人的につまらないので そうだね、DecoratorはSmalltalkやSelfで書いたらどうなる？ 535 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 00:07:55.94 ID:6KXXOitA.net] >>534 試しにウィキペの Decorator パターン https://ja.m.wikipedia.org/wiki/Decorator_パターン にある例を Smalltalk で書いてみた ideone.com/Y1WAxY けど、圧倒的に簡潔になった感じはしないな >>531 ならどんなふうに書く？ 536 名前：デフォルトの名無しさん [2016/08/02(火) 00:11:39.50 ID:xLK/JaT/.net] シングルトンなんて言語に最初から組み込んでおけ（Scala信者並感） 537 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 00:40:29.48 ID:Aujbapgh.net] >>532 そもそもきみは継承関係=オブジェクト指向でしか発想してないから クソ邪魔くさい継承取っ払ってモジュール自由に組み外しできるタイプの オブジェクト指向の話にまったくついてこれてないからずっと嗤われてるわけで。 538 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 00:44:39.63 ID:flPsn8Jo.net] >>535 別にDecoratorじゃなくていいんだけどね。 圧倒的に簡潔かつ明瞭に記述できるっていってるから そのコードを見たいだけ。 539 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 05:55:14.53 ID:wOSsX6OQ.net] デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。 型が完全に動的なSmalltalkやSelfではデコレータパターン自体が不要。 540 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 10:26:45.37 ID:KjBiyzhL.net] 型が動的だと>>535の例のようなコードはどうなるの？ 541 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 10:29:15.63 ID:YMxtX/GD.net] そそ 例えばアセンブリや機械語は制約がないからデコレータパターンとか要らないでしょ それと同じでSmalltalkには何も必要ないよ 542 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 13:11:20.31 ID:KCBRtMku.net] 全然違うのだが。デコレータもSmallTalkも理解してないとみた。 543 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 13:40:40.79 ID:C0zGukRC.net] アセンブリというかC言語だとこんな感じか。出来るには出来るけどちょっとねえ codepad.org/XgRtJlQb 544 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 15:34:07.46 ID:lROFhaXh.net] なにも知らなくても語れる。 それが Smalltalk のいいところらしい。 人間の悲しさがほの見えるな・・・ 545 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 16:01:47.58 ID:wOSsX6OQ.net] >>540 Smalltalkはよくわからないけど、 DoublePriceとかWholesalePriceとかいうクラスを増やすより、 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。 SmalltalkのPluggableMVCとかもクロージャで柔軟な変換を実装しているし。 546 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 16:53:22.92 ID:I0xQlCpI.net] >>545 > 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。 こんなんでどうですかね？ ideone.com/d8iLSE ついでにRuby版も書いてみた ideone.com/WW8gva 547 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 17:16:35.65 ID:I0xQlCpI.net] >>543 これだと Java 版でいうところの getValue() する前に 毎回、二倍にして 利益80乗せて、また二倍にしてもう一度 利益200乗せて…とかって いちいち書かないと 840を返せないから、結果は合っているけど要求仕様を満たしていないような気がする 548 名前：デフォルトの名無しさん mailto:sage [2016/08/02(火) 18:25:05.78 ID:lROFhaXh.net] いつになったら、 人間クラスと美少女クラスの問題に辿りつけるのかね？ 悲しいの〜。 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の例の要求仕様は満たしているように見えるけど。 具体的にはどこが不満？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef