16/08/01 01:43:39.68 E1waX2Jm.net
>>519
オブジェクト指向は必要だから使うんじゃなくて
いくつもある手段の中から一番適切だから使うんだよ。
お前が例示する使い方は、単にオブジェクト指向じゃないほうが
適切だってだけ。そしてオブジェクト指向が適切だから
ほとんどのフレームワークでオブジェクト指向が使われている。
他に代替技術があるにもかかわらずだ。
522:デフォルトの名無しさん
16/08/01 02:44:42.52 6ITirnPy.net
>>513
だからその設計はねーってこと言ってるんだろ。
日本語読めないの？
523:デフォルトの名無しさん
16/08/01 03:09:46.97 FN/zaXKS.net
>>516
＞どこからか使いものにならなくなったよね
C++の奇形めいたオブジェクト指向は衰退して
別方面で進化してきたObjecive-CとJavaが本流として
いま街でみかける全てのスマホアプリを支えてるけどな。
524:デフォルトの名無しさん
16/08/01 03:31:24.59 cj2k2Gm/.net
今はObjrctive-CじゃなくてSwiftじゃね？
525:デフォルトの名無しさん
16/08/01 04:29:03.24 C6PCKyxq.net
>>521 適切だから使うというなら何故デザインパターンなんて出てきたのか？
デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
他の手段が使える言語なら間違いなく採用しない
他にもExpression ProblemをJavaで解決しているのとOCamlで解決しているのを比較してみるといい
OOだと論文書けるくらいには面倒な方法があるけど、OCamlのVariant使った方法と比べて圧倒的に可読性と簡潔さに劣っている
526:デフォルトの名無しさん
16/08/01 06:27:47.87 c5RAbFYM.net
JavaはC++よりレガシーな言語になってしまったが…
527:デフォルトの名無しさん
16/08/01 09:36:21.09 E1waX2Jm.net
>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
違う。OO便利だなーって使っているうちに
設計のアルゴリズムが確立されていって、
それをまとめたのがデザパタ
528:デフォルトの名無しさん
16/08/01 10:06:54.28 Q0J3uZmP.net
いや、デザパタはOOと関係無いから。
関係あるのはOOPの方
529:デフォルトの名無しさん
16/08/01 10:50:43.99 pyyhbxGP.net
【閲覧注意】戦闘に巻き込まれて頭部を切断された少女の遺体。これがリアルなシリア。
URLﾘﾝｸ(dqnworld.com)
これが本当の戦争の恐怖。この少女には大人の戦争は関係ないですからね。巻き込まれた少女の遺体を持って何か
を訴えかけている男たちの映像です。
【閲覧注意】シリアで反体制派の兵士が顔を吹き飛ばされてしまう瞬間。
URLﾘﾝｸ(dqnworld.com)
スローモーションが怖すぎる・・・。
【閲覧注意】アッラーフアクバルを叫びながら少年を斬首する映像を公開する。
URLﾘﾝｸ(dqnworld.com)
点滴？のようなものが見えるんだけど。助けられた少年じゃなかったのか。助けられた所を強奪されてアッラーフ
アクバル？なのかしら・・・。
【閲覧注意】磔にされた戦闘機パイロットの遺体。シリアにて。
URLﾘﾝｸ(dqnworld.com)
今日のアッラーフアクバル動画。
妻の目の前でぶっ飛ばされた旦那さん？これは死んだかな(°_°)
URLﾘﾝｸ(dqnworld.com)
さすがにこれだけ飛ばされたら助からないかな・・・。
【閲覧注意】あおむけでゲロを吐きまくっている男性。助けてやれよ・・・。窒息するぞ(@_@;)
URLﾘﾝｸ(dqnworld.com)
これ結構危ないんじゃないの？撮影してないで横向きにしてやれよ。これ窒息する可能性あるだろ。
衝撃映像。事故って大回転した車から少女がポロリ。
URLﾘﾝｸ(dqnworld.com)
この少女がどうなったのかが気になる所ですが動画の説明には何も書かれていなかった・・・。
530:デフォルトの名無しさん
16/08/01 10:52:18.11 IZIdUKpU.net
ここまでLSPの話題なし
531:デフォルトの名無しさん
16/08/01 17:10:00.57 GD9lEFl6.net
>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
おしい。
デザパタはJavaやC++に適さない問題を無理やりJavaやC++で解決するためのもので、
SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。
532:デフォルトの名無しさん
16/08/01 18:06:20.18 99zq/hjd.net
smalltalk だと、人間クラスと美少女クラスの問題は
どう解決するの？
533:デフォルトの名無しさん
16/08/01 20:14:16.64 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:デフォルトの名無しさん
16/08/01 20:39:01.26 E1waX2Jm.net
>>531
> SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。
例えば、どのパターンが簡潔明瞭に記述できるの？
一番簡単なパターンでいいので書いてみて。
考えるのが面倒なら俺が出題しても良い？
Singletonは個人的につまらないので
そうだね、DecoratorはSmalltalkやSelfで書いたらどうなる？
535:デフォルトの名無しさん
16/08/02 00:07:55.94 6KXXOitA.net
>>534
試しにウィキペの Decorator パターン
URLﾘﾝｸ(ja.m.wikipedia.org)パターン
にある例を Smalltalk で書いてみた
URLﾘﾝｸ(ideone.com)
けど、圧倒的に簡潔になった感じはしないな
>>531 ならどんなふうに書く？
536:デフォルトの名無しさん
16/08/02 00:11:39.50 xLK/JaT/.net
シングルトンなんて言語に最初から組み込んでおけ（Scala信者並感）
537:デフォルトの名無しさん
16/08/02 00:40:29.48 Aujbapgh.net
>>532
そもそもきみは継承関係=オブジェクト指向でしか発想してないから
クソ邪魔くさい継承取っ払ってモジュール自由に組み外しできるタイプの
オブジェクト指向の話にまったくついてこれてないからずっと嗤われてるわけで。
538:デフォルトの名無しさん
16/08/02 00:44:39.63 flPsn8Jo.net
>>535
別にDecoratorじゃなくていいんだけどね。
圧倒的に簡潔かつ明瞭に記述できるっていってるから
そのコードを見たいだけ。
539:デフォルトの名無しさん
16/08/02 05:55:14.53 wOSsX6OQ.net
デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。
型が完全に動的なSmalltalkやSelfではデコレータパターン自体が不要。
540:デフォルトの名無しさん
16/08/02 10:26:45.37 KjBiyzhL.net
型が動的だと>>535の例のようなコードはどうなるの？
541:デフォルトの名無しさん
16/08/02 10:29:15.63 YMxtX/GD.net
そそ
例えばアセンブリや機械語は制約がないからデコレータパターンとか要らないでしょ
それと同じでSmalltalkには何も必要ないよ
542:デフォルトの名無しさん
16/08/02 13:11:20.31 KCBRtMku.net
全然違うのだが。デコレータもSmallTalkも理解してないとみた。
543:デフォルトの名無しさん
16/08/02 13:40:40.79 C0zGukRC.net
アセンブリというかC言語だとこんな感じか。出来るには出来るけどちょっとねえ
URLﾘﾝｸ(codepad.org)
544:デフォルトの名無しさん
16/08/02 15:34:07.46 lROFhaXh.net
なにも知らなくても語れる。
それが Smalltalk のいいところらしい。
人間の悲しさがほの見えるな・・・
545:デフォルトの名無しさん
16/08/02 16:01:47.58 wOSsX6OQ.net
>>540
Smalltalkはよくわからないけど、
DoublePriceとかWholesalePriceとかいうクラスを増やすより、
元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
SmalltalkのPluggableMVCとかもクロージャで柔軟な変換を実装しているし。
546:デフォルトの名無しさん
16/08/02 16:53:22.92 I0xQlCpI.net
>>545
> 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
こんなんでどうですかね？
URLﾘﾝｸ(ideone.com)
ついでにRuby版も書いてみた
URLﾘﾝｸ(ideone.com)
547:デフォルトの名無しさん
16/08/02 17:16:35.65 I0xQlCpI.net
>>543
これだと Java 版でいうところの getValue() する前に
毎回、二倍にして 利益80乗せて、また二倍にしてもう一度 利益200乗せて…とかって
いちいち書かないと 840を返せないから、結果は合っているけど要求仕様を満たしていないような気がする
548:デフォルトの名無しさん
16/08/02 18:25:05.78 lROFhaXh.net
いつになったら、
人間クラスと美少女クラスの問題に辿りつけるのかね？
悲しいの～。
549:デフォルトの名無しさん
16/08/02 20:24:15.92 wOSsX6OQ.net
>>548
とっくに解けてるじゃん
ばか？
550:デフォルトの名無しさん
16/08/02 20:30:55.27 lROFhaXh.net
どう解けてるんだよ。
人間の肛門と天使の肛門にコンポーネントするのか？
551:デフォルトの名無しさん
16/08/02 20:41:47.88 UCo4tbLK.net
用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。
552:デフォルトの名無しさん
16/08/02 20:42:03.85 9rM4/wP9.net
美少女は偶像であり人間ではない
553:デフォルトの名無しさん
16/08/02 20:57:34.64 flPsn8Jo.net
もうそろそろいいかな？
みんな「デコレーターパターン」をどうするか？というテーマで
会話が成り立ってるよね？
つまりこういうことさ。デザインパターンっていうのは用語。
実装じゃない。
デコレーターパターンをJavaならこう書く、SmallTalkならこう書くと
いうふうに共通認識ができてる。これこそデザインパターンの有用な所。
だからコードの書き方が決まってるわけじゃないんだよ。
設計だからね。言語が決まらない状態であっても話はできる。
デザインパターンをどういうふうに書くかってのは例でしか無いんだよ。
目的を達成できるならどう書くてもいいし、デコレータパターンを
どう書いてもそれはデコレータパターンなのさ。
SmallTalkであってもデコレーターパターンっていうのは存在する。
だからこそSmallTalkでデコレータパターンをシンプルに書くことができる！と
主張できる。
554:デフォルトの名無しさん
16/08/02 21:16:53.04 LOKS06K+.net
>>553
なんでみんなより二歩も三歩も手前な意見を
そんな長文で書き込めるの？
555:デフォルトの名無しさん
16/08/02 21:20:29.76 flPsn8Jo.net
>>554
言いたいことはそれだけかｗ
556:デフォルトの名無しさん
16/08/02 21:22:05.73 LOKS06K+.net
ごめんね
557:デフォルトの名無しさん
16/08/02 21:24:18.11 e9gYPknx.net
Smalltalk の t を大文字で書くやつは無知か知ったかぶり
558:デフォルトの名無しさん
16/08/02 21:24:35.32 lROFhaXh.net
実は誰も Smalltalk なんて知らない www
559:デフォルトの名無しさん
16/08/02 21:27:22.36 flPsn8Jo.net
反論あるなら待ってるよｗ
560:デフォルトの名無しさん
16/08/02 21:32:29.72 LOKS06K+.net
>>557
ワロタｗ
561:デフォルトの名無しさん
16/08/02 21:38:39.55 UCo4tbLK.net
言語は関係無いと言う内容の話への反論が、言語名のミスプリントの指摘とか、レベル低過ぎだろw
小学生の負け惜しみかよw
562:デフォルトの名無しさん
16/08/02 21:39:26.48 flPsn8Jo.net
>>561
え？それ反論だと思ってたの？
反論はまだ一つも来てませんよｗ
563:デフォルトの名無しさん
16/08/02 21:40:28.47 UCo4tbLK.net
うゎw
保育園だなここはw
564:デフォルトの名無しさん
16/08/02 21:47:57.27 6KXXOitA.net
>>561
「プリント」とかまさに小並
565:デフォルトの名無しさん
16/08/02 22:08:58.16 e9gYPknx.net
>>553
>>538で「見たいだけ」って言ってるところをみると、これは反語で
>>546みたいに簡潔なのが出てくるとはこの時点では考えてなかったんじゃない？
だからデザパタは用語で実装じゃない、言語は関係ないって趣旨替えしたように読むのは穿ちすぎ？
566:デフォルトの名無しさん
16/08/02 22:14:56.76 flPsn8Jo.net
>>565
いやｗ
最初からこのために、
デコレータパターンをSmallTalkで書いたらどうなるの？って
話題を振って会話をさせたんだよ。
デコレータパターンという共通知識があり、
SmallTalkでそれを実装することができるという会話をね。
もし実装が決まっているものであれば、
SmallTalkでデコレータパターンを実装すれば
シンプルな形で実装できるんだっていう話はでてこない。
567:デフォルトの名無しさん
16/08/02 22:27:10.71 KCBRtMku.net
そもそもC++でデコレーターでもそんな難しくないでしょｗ
シングルトンの方がよっぽどややこしい。
568:デフォルトの名無しさん
16/08/02 22:30:18.68 flPsn8Jo.net
「シングルトン」だけで話が通じる所がデザインパターンの
便利なところだね。
さてシングルトンにもいろんな実装があるけど、
DIコンテナを使ってシングルトンに見せるっていう方法もあるよね。
これだと普通にクラスを作るだけで良くなる。
569:デフォルトの名無しさん
16/08/02 22:34:48.24 qU1dasmj.net
兄さん、そこでPythonですよ
ですしおすし
570:デフォルトの名無しさん
16/08/02 23:26:19.20 QqIbwu4d.net
Java8ならもっとHENTAIなコードが書けるぞ
URLﾘﾝｸ(ideone.com)
571:デフォルトの名無しさん
16/08/02 23:41:10.66 6KXXOitA.net
>>570
>>547
572:デフォルトの名無しさん
16/08/02 23:59:46.02 lROFhaXh.net
Smalltalk の最大の魅力は、
それが雑談に過ぎないということである。
by アラン・ケイ
573:デフォルトの名無しさん
16/08/03 00:45:18.40 qJ0ntPw4.net
>>570
new Price((120*2+80)*2+200) を作りたいわけではなくて
new Price(120) をデコって 840 を返させるのが Decorator
だからデコったあとに setValue(100) してから getValue() すると 760 が返るはず
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
574:デフォルトの名無しさん
16/08/03 11:21:17.97 nNt8IZmK.net
>>566
まるでちがう。>>546はデコレータパターンじゃない。
Javaではデコレータパターンを使う問題を
デコレータパターンを使わずにより簡潔に記述した例。
575:デフォルトの名無しさん
16/08/03 12:45:10.82 XBNCNfrP.net
>>539
型が動的だと>>535の例のようなコードはどうなるの？
576:デフォルトの名無しさん
16/08/03 15:55:24.00 8J75MUHP.net
SmallTalkとか
577:デフォルトの名無しさん
16/08/03 17:09:10.94 R0iPm5qU.net
関数型インターフェースの方が簡潔になる
URLﾘﾝｸ(ideone.com)
>>573
setValue(100)してからgetValueしたら100返らなきゃバグってるだろ
setOriginalValueとかに修正するところだな
578:デフォルトの名無しさん
16/08/03 18:07:08.01 8J75MUHP.net
Wikipediaにある
> Decorator パターンの方針は、既存のオブジェクトを新しい Decorator オブジェクトでラップすることである。
がわかってない奴がいるな
579:デフォルトの名無しさん
16/08/03 18:17:54.35 qhbdc1zB.net
デザパタの目的とされがちであるが
常に失敗しているのが語彙の共有
いつでもつねに認識がバラバラｗ
580:デフォルトの名無しさん
16/08/03 18:21:38.71 8J75MUHP.net
>>579
ごく一部の人間が正しく理解できてないだけで、
> いつでもつねに認識がバラバラｗ
は言い過ぎ
581:デフォルトの名無しさん
16/08/03 18:45:37.19 9oohU77o.net
>>577
> 関数型インターフェースの方が簡潔になる
そんなんでいいなら Smalltalk でも簡潔に書けるけどね
URLﾘﾝｸ(ideone.com)
582:デフォルトの名無しさん
16/08/03 19:57:46.85 N9MmOijn.net
Smalltalkに意味なんかないよ
登場してから30年とか40年とか経ってるのに
誰も現場で使ってない言語だからね
40年という歳月は結論を出すのに十分な時間だと思うよ
これから先もずっと使われないだろう
こんな言語についてあれこれ考えるのは時間の無駄だよ
御幣を恐れずに言うと、Smalltalkは間違っている、机上の空論
本当によくできていたなら、もうちょっとぐらい使われていてもおかしくない
少なくともRuby程度ぐらいには使われてないと話にならない
Smalltalkは実用にならないスジの悪い言語だということ
583:デフォルトの名無しさん
16/08/03 20:22:04.47 M+rE/wd/.net
Smalltalkは言語だけじゃダメで。
windows上では使い物にならないから仕方無い。
584:デフォルトの名無しさん
16/08/03 20:23:22.86 M+rE/wd/.net
要するに、windows自体がオブジェクト指向に向いてないんだよ。
585:デフォルトの名無しさん
16/08/03 20:29:26.00 1jcdD/Xi.net
結論。
誰も Smalltalk なんて知らない www
586:デフォルトの名無しさん
16/08/03 20:32:04.15 N9MmOijn.net
それは関係ない
なぜなら概念上の問題より運用上の問題のほうが大事だから
いくら概念的な素晴らしさを語ったところで
まともに運用できないならゴミ
使えない
587:デフォルトの名無しさん
16/08/03 20:45:27.46 YtpqVXv4.net
>>574
> Javaではデコレータパターンを使う問題を
> デコレータパターンを使わずにより簡潔に記述した例。
お前は勘違いしているな。
デコレータパターンを実装しなさいというお題なんだから
それがデコレータパターンなんだよ。
Javaならこういう実装でやるが、他の言語では
その実装方法が違うだけ。
588:デフォルトの名無しさん
16/08/03 21:24:23.35 TE6NppPB.net
>>582
まあ仮にSmalltalkが本当に誰も使ってなくて
処理系も失われたり、あるいは as-is で放置された言語だとしたら
そんなものに意味がないって意見は全くもって正しいよね
589:デフォルトの名無しさん
16/08/03 21:37:23.40 46yxFVyN.net
シングルトンやアイテレーターなどは時代が変わっても重要だろうけど、
デコレーターは継承関係への依存度が高いから微妙だな。
590:デフォルトの名無しさん
16/08/03 22:46:55.08 PwtoF+FA.net
>>583
Smalltalkは独自のGUIもそうだけれども、もうひとつ、通常のセルフホスティング
（自身で自身を記述）にとどまらず、処理系を構成する実行時オブジェクト群を
仮想イメージと呼ばれる、ある種のオブジェクトストアに永続化して次回起動時も
継続利用する運用スタイルも毛嫌いされるよね。個人的には示唆に富んでいて好きなんだけど
591:デフォルトの名無しさん
16/08/04 00:17:31.35 iDV12Qqy.net
>>587
いや？
クロージャで実装しているのだから、デコレータパターンによる実装ではないよ。
コード読めない子？
592:デフォルトの名無しさん
16/08/04 00:19:01.73 jTAWnEUa.net
> クロージャで実装しているのだから、
クロージャで "何を" 実装しているの？
593:デフォルトの名無しさん
16/08/04 00:24:24.39 ClPuKc3B.net
デコレータパターンを実装できてはいないんだよｗ
これでわかった？ｗ
594:デフォルトの名無しさん
16/08/04 00:25:35.63 jTAWnEUa.net
いや、何を実装したのかを聞いたんだが？
実装したものは何？
595:デフォルトの名無しさん
16/08/04 00:30:18.03 ynLXOlFE.net
>>590
あのあたりはむしろメモリや記憶装置いくらでも使える現代向けというか
過去にオブジェクト指向の要素をちょっとだけ輸入してみた中途半端なオブジェクト指向言語が次々出ては滅びの興亡続けてたのは
"コンパイル後のサイズが大きいじゃないか"とかいまじゃヘソが茶を沸かすような理由がメインなわけだし。
596:デフォルトの名無しさん
16/08/04 00:31:24.04 w6fnMNqO.net
デコレータパターンと同等の機能をクロージャで実装した
じゃね？
同等の機能を持った違った実装があるのは当たり前じゃね？
デコレータパターンと同じような機能をもたらすけど
デコレータパターンじゃない実装は普通にあり得るんじゃね？
597:デフォルトの名無しさん
16/08/04 00:34:51.00 jTAWnEUa.net
>>595
パターンは機能じゃないよ。設計。
デコレータパターンという設計
この設計の実装はいろいろある。
決まっていない。
Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。
598:デフォルトの名無しさん
16/08/04 00:36:04.52 jTAWnEUa.net
wikipediaにすら書いてあるしｗ
URLﾘﾝｸ(ja.wikipedia.org)(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
デザインパターンは、よく使われる設計を一般化された形でまとめたものに過ぎない。
そのため、具体的な実装を提供するものではなく、
あくまでもコンセプトとして参照されることが意図されている。
つまり、サンプルコードは、実装例に過ぎない。
599:デフォルトの名無しさん
16/08/04 00:42:01.96 w6fnMNqO.net
>パターンは機能じゃないよ。設計。
それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ？
俺の言ってることと一緒だね
600:デフォルトの名無しさん
16/08/04 00:44:00.26 fESKb5E9.net
ID:jTAWnEUaを教育してあげる義務は我々には無い
601:デフォルトの名無しさん
16/08/04 00:45:06.02 jTAWnEUa.net
>>599
わざわざ複雑にしないでいいよｗ
やりたいことがある。
でも説明するのが面倒くさい。
じゃあ「デコレーターパターン」と呼びましょう。
これで話は通じてるじゃん。
だからこれだけの情報でコードを書くことができる。
そのデコレーターパターンを
クロージャーで実装したんでしょ？
そういえば良いんだよ。
602:デフォルトの名無しさん
16/08/04 00:48:34.94 jTAWnEUa.net
>>600
じゃあ一緒に勉強していきましょう（笑）
URLﾘﾝｸ(www.techscore.com)
> 前章でも説明したとおり、デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」を
> まとめたものです。 デザインパターンを利用するメリットとして、最初にあげられるのが、
> 「再利用性の高い柔軟な設計ができる」という点です。各パターンには、多くの知恵が凝縮されています。
> これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
> 初心者でも先人たちが詰め込んだ「知恵」を利用した設計をすることが可能となります。
> また、先人たちの知恵を参考にすることで、設計力の向上も期待できます。
>
> 次のメリットは、「技術者どうしの意思疎通が容易になる」ことが挙げられます。
> デザインパターンを習得している技術者どうしであれば、設計について相談するとき
> 「Singleton パターンで行きましょう」とか「Strategy パターンが応用できるのではないでしょうか」と
> いうようにパターン名で設計の概要の合意を取ることが可能です。デザインパターンを
> 習得していない技術者には「こんなクラスを作って、このクラスはこんな役割を持っていて・・・。」と
> 延々と説明しなければなりません。このように、デザインパターンを学習しておくことで
> 開発者どうしの意思疎通がスムースになるのです。
あなたは何で勉強していますか？
603:デフォルトの名無しさん
16/08/04 01:13:23.05 w6fnMNqO.net
話をややこしくしているのはあなたです
>パターンは機能じゃないよ。設計。
↑これは君が言ったことだよね
その上で俺は、同等の機能を持った、違ったデザインなんじゃね？って言ってるわけ
機能が同じであっても、同じデザインパターンとは限らない
何故なら、デザインパターンは機能じゃないから、設計のパターンだから
↑君の言ってることと全く同じだよね
だから同じ機能だけど、違った設計パターンであり
同じデザインパターンに属さない設計は有る
ということを君は認めているということ
604:デフォルトの名無しさん
16/08/04 01:43:58.02 w6fnMNqO.net
デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの
ってのは正に君が自分で言ったことであって
それは俺も了承している
だから同じ機能であっても、それだけで同じデザインパターンとは言えないよね
と俺は言ってるわけ
なぜならデザインパターンは機能では無いから(君の言ったことだよね)
そもそも俺とお前とのやり取りに、何のとどこおりも無い
俺は、>>596で同等の機能を別の設計で実装したんじゃないか、と言い
お前は>>597でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている
合わせると、「同等の機能であっても同じデザインパターンであるとは限らない、設計で決まる」
という結論が得られる
605:デフォルトの名無しさん
16/08/04 01:56:34.90 tMKvO+zV.net
デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。
これと同じことが他のデザインパターンでもできるんじゃね？という主張だったと思うんだが。
Singletonは言語によって容易に達成できるものもあればそうでない言語もあるが、そう難しくは無いはず。
OCamlだったらmutable valueを持ったモジュール使えば同等のことが実現できる。
Adapterパターンも変更できない物がオブジェクトだったら関数1つで済むし、
モジュールだったらファンクタ使えば良い。
これを続けていけばデザインパターンがOOPの表現力の低さを解決する妥協案である、と示せる気がするが、
逆にOOPでデザパタ使うのが一番簡潔になる問題を探す方が難しいかもね。
606:デフォルトの名無しさん
16/08/04 03:16:53.36 jTAWnEUa.net
やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。
まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。
そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。
607:デフォルトの名無しさん
16/08/04 03:18:24.28 jTAWnEUa.net
OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。
C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。
608:デフォルトの名無しさん
16/08/04 06:27:25.67 iDV12Qqy.net
>>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。
JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。
609:デフォルトの名無しさん
16/08/04 09:14:32.03 jTAWnEUa.net
>>608
それはオレオレ定義ですよね。
610:デフォルトの名無しさん
16/08/04 09:31:36.26 0aO0sFCL.net
デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。
「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。
プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。
611:デフォルトの名無しさん
16/08/04 09:33:28.01 IwXa2U8x.net
内容を理解してないから例にある記述方法しか受け付けないんだよ。
612:デフォルトの名無しさん
16/08/04 09:33:48.07 jTAWnEUa.net
> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。
じゃあなんでこんな本が存在するんですか？ｗ
Rubyによるデザインパターン-Russ-Olsen/
URLﾘﾝｸ(www.amazon.co.jp)
JavaScriptデザインパターン
URLﾘﾝｸ(www.oreilly.co.jp)
The Design Patterns Smalltalk Companion
URLﾘﾝｸ(www.amazon.com)
613:デフォルトの名無しさん
16/08/04 09:34:24.97 0aO0sFCL.net
>>610
あ。引用部分は自炊本の OCR のコピペなんで、タイポは脳内補完ねがいます。
614:デフォルトの名無しさん
16/08/04 09:35:44.09 0aO0sFCL.net
>>612
GoF も「Smalltalk では簡単に記述できるものもある」とは言っているけど、
ぜんぶがぜんぶとは言っていないよね。
615:デフォルトの名無しさん
16/08/04 09:35:54.66 IwXa2U8x.net
>>612
おまいみたいなバカに本を売り付ける為だろw
616:デフォルトの名無しさん
16/08/04 09:38:22.54 jTAWnEUa.net
>>615
え？捨て台詞？ｗ
617:デフォルトの名無しさん
16/08/04 10:07:48.33 e/09ny1R.net
これはまさに捨て台詞で十分な一例。
618:デフォルトの名無しさん
16/08/04 10:14:03.24 0aO0sFCL.net
> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。
Smalltalkを好意的にとらえて持ち上げてくれるのは、狭い視野で意味なし認定しちゃう人たちよりは
ファンとしてはありがたいけど、これはさすがにオーバーエスティメートだし、
もうちょっとSmalltalkならではのアドバンテージを学んでから、適切な持ち上げ方をしてほしい…
619:デフォルトの名無しさん
16/08/04 10:47:43.12 iDV12Qqy.net
「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。
620:デフォルトの名無しさん
16/08/04 11:37:47.99 0aO0sFCL.net
>>619
もしそうだとしても、少なくとも>>591は「GoFの（デコレーター）」と明記すべきですよね
621:デフォルトの名無しさん
16/08/04 12:27:01.14 CY/jwgqy.net
smalltalkって簡単に色々できるんでしょ？
なんで現代でメジャーじゃないの？
622:デフォルトの名無しさん
16/08/04 12:30:59.74 IwXa2U8x.net
日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ？
623:デフォルトの名無しさん
16/08/04 12:31:27.57 79cTVfxr.net
MSがVisual Smalltalkをつくらなかったから
624:デフォルトの名無しさん
16/08/04 12:57:32.53 iDV12Qqy.net
>>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが？
625:デフォルトの名無しさん
16/08/04 13:05:00.50 rDDGHvQu.net
はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。
626:デフォルトの名無しさん
16/08/04 13:16:23.28 0aO0sFCL.net
>>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン（GoFの定義如何に関わらない）というのを提示してもらうことはできますか？
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。
そもそも Smalltalk ではデコレーターパターンが不要（なので、実装はナンセンス）とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。
627:デフォルトの名無しさん
16/08/04 14:01:27.52 gwNa+xfa.net
つか、>>546のruby版って一体何？
デコレータパターンのつもり？
628:デフォルトの名無しさん
16/08/04 14:13:24.61 0aO0sFCL.net
>>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満？
629:デフォルトの名無しさん
16/08/04 14:41:37.79 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:デフォルトの名無しさん
16/08/04 14:42:24.41 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:デフォルトの名無しさん
16/08/04 16:18:58.29 0aO0sFCL.net
>>629
これでいい？
URLﾘﾝｸ(ideone.com)
632:デフォルトの名無しさん
16/08/04 16:59:33.41 gwNa+xfa.net
>>631
なんか実装手段が違ってきてますが・・・。
>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。
633:デフォルトの名無しさん
16/08/04 17:09:10.90 0aO0sFCL.net
>>632
> なんか実装手段が違ってきてますが・・・。
本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので
> closureを使えばデコレータパターン同等のことができる
>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい
634:デフォルトの名無しさん
16/08/04 17:41:28.54 gwNa+xfa.net
>>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。
WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。
一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか？
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。
635:デフォルトの名無しさん
16/08/04 18:07:30.87 iDV12Qqy.net
>>626
だーかーらー、
デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装（当然、上記デコレータパターンの実装ではない）で実現できる。
という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる？
636:デフォルトの名無しさん
16/08/04 18:33:42.23 0aO0sFCL.net
>>634
> 一方、>>546のコードだとそうはいかない。
単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
URLﾘﾝｸ(ideone.com) というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。
637:デフォルトの名無しさん
16/08/04 18:57:12.60 0aO0sFCL.net
>>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。
638:デフォルトの名無しさん
16/08/04 18:59:34.21 iP1jJ0aF.net
>>610
iteratorはどっちが楽なの？
639:デフォルトの名無しさん
16/08/04 19:27:18.45 0aO0sFCL.net
>>638
Smalltalk と C++ との比較で？ それならもちろん Smalltalk です。
（同書P.289より）
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。
（標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。）
640:デフォルトの名無しさん
16/08/04 19:40:49.06 HlIXxJdQ.net
>>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね？
別にSmalltalkが特別ってことにはならない。
641:デフォルトの名無しさん
16/08/04 20:21:25.52 jTAWnEUa.net
>>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、
修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。
642:デフォルトの名無しさん
16/08/04 20:23:12.92 jTAWnEUa.net
デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。
643:デフォルトの名無しさん
16/08/04 20:37:49.54 0aO0sFCL.net
>>640
Smalltalkが特別ってことにはならないという点については同意します。
ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも
とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか？
あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を
URLﾘﾝｸ(qiita.com)
Smalltalkで書いてみました
URLﾘﾝｸ(ideone.com)
もちろんSmalltalk方式を採用した言語（たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため
URLﾘﾝｸ(ideone.com)
644:デフォルトの名無しさん
16/08/04 20:41:57.05 jTAWnEUa.net
イテレーターパターンをSmalltalkで書いてみたわけね。
645:デフォルトの名無しさん
16/08/04 20:47:45.80 XSjm71+w.net
イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ
646:デフォルトの名無しさん
16/08/04 20:55:24.22 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:デフォルトの名無しさん
16/08/04 21:08:55.10 ILqHD9/M.net
>>642
クロージャを使ったらデコレータとは言わないのでは？
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。
無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。
言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。
648:デフォルトの名無しさん
16/08/04 21:15:46.97 jTAWnEUa.net
>>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。
649:デフォルトの名無しさん
16/08/04 21:21:02.95 CmNfOhbZ.net
>>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。
650:デフォルトの名無しさん
16/08/04 21:29:07.85 jTAWnEUa.net
Structureは日本語にしたら
構造って意味ですよｗ
651:デフォルトの名無しさん
16/08/04 21:30:27.36 CmNfOhbZ.net
>>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。
652:デフォルトの名無しさん
16/08/04 21:33:42.86 TDXgEb4R.net
継承してないと使えないとかじゃ困る。
653:デフォルトの名無しさん
16/08/04 21:34:27.18 jTAWnEUa.net
> そこが実質的な定義だと（俺様が）言ってるの。
知らんがなｗ
お前が何を言ったところで、
Structureは日本語にしたら構造
Definition（定義）じゃない。
まさか単語の意味を強弁するとは思わなかったなｗ
654:デフォルトの名無しさん
16/08/04 21:39:49.22 CmNfOhbZ.net
>>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。
655:デフォルトの名無しさん
16/08/04 21:51:04.78 jTAWnEUa.net
説得力0ｗ
656:デフォルトの名無しさん
16/08/04 21:51:55.34 VNJ4iqic.net
この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。
657:デフォルトの名無しさん
16/08/04 22:03:13.75 jTAWnEUa.net
構造の一例ねｗ
658:デフォルトの名無しさん
16/08/04 22:10:23.67 CmNfOhbZ.net
デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。
659:デフォルトの名無しさん
16/08/04 22:12:49.41 jTAWnEUa.net
まさかデザインパターンがGoFの23個だけだと？
あれはパターン例だよ
660:デフォルトの名無しさん
16/08/04 22:14:24.41 CmNfOhbZ.net
>>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ？
661:デフォルトの名無しさん
16/08/04 22:20:23.44 jTAWnEUa.net
Structureは日本語にしたら構造
Definition（定義）じゃない。
国語と英語の問題なｗ
662:デフォルトの名無しさん
16/08/04 22:24:49.05 CmNfOhbZ.net
アホの一つ覚えとはこのこと
663:デフォルトの名無しさん
16/08/04 22:45:18.74 jTAWnEUa.net
効いてる効いてるｗ
664:デフォルトの名無しさん
16/08/05 05:47:03.48 Q5sCXOre.net
あるプログラム片の構造がパターンカタログのものと異なっていたら、
そのプログラム片はそのパターンの実装とは言えないな。
実際問題として、このスレで出ているRuby実装は、GoFに掲載されたデコレータパターンの実装ではない。
それを無視するなら、あなた (ID:jTAWnEUa) にはデザインパターンを使うための
最低限の素地が備わっていないということ。
665:デフォルトの名無しさん
16/08/05 07:23:44.09 TLRbqbFt.net
>>644
あまりにひどくて、なにをいっているかわからなかった。SmalltalkはともかくRubyのコードも読めないのかと。
内部イテレーターを使ったこの実装をイテレーターパターンだと言い切るのはどう考えても無理があるし、
同じ理屈でクロージャーを使った件の実装をデコレーターパターンだと言い張っているなら混乱するだけだからやめてほしい。
666:デフォルトの名無しさん
16/08/05 08:28:16.86 liZAD7d5.net
>>664-665
この二人は単に常識的な発言をしているだけだが
きっと相手には伝わらないだろうね
667:デフォルトの名無しさん
16/08/05 11:01:37.11 RHt058cj.net
結局オブジェクト志向が理解出来なくて管を巻いていたら
世間はプロトコル志向に移ってしまったでござるの巻
お前ら何周遅れたら走り出す気になるの？
668:デフォルトの名無しさん
16/08/05 12:54:45.79 Vwi1FrEy.net
Swiftのプロトコルも何周回目か遅れですよ？
ScalaやRustのトレイトとか知らないんですか？
669:デフォルトの名無しさん
16/08/05 13:11:37.22 ccW8btWE.net
イテレータをアイテレータって書いてる人がいるけど
どこの方言なの？
weblioさんの発音もイテレータなんだけど
670:デフォルトの名無しさん
16/08/05 14:20:51.80 1PWjv4l0.net
weblioワロタｗ もっとちゃんとした辞書持って来いよ。
Merriam Websterとかさ。和英辞書を引用して日本語論じたりしないだろ？
色々調べてみたけど、Wikitionaryのiterateでは二重母音の発音も載せてる。
その他の辞書では見つからなかった。
実際に英語ネイティブのアメリカ人が/ai/でも発音しているのを聴いたこともある。
伝統的には一般的な発音じゃなかったけど、IT界隈でよく使われているうちに、
発音変種が発生したんじゃないか？ 英語発音学的にはどちらでも許容されそうだし。
671:デフォルトの名無しさん
16/08/05 14:53:55.08 1z/JWFxp.net
>>669
方言というより極度の経験不足なんだろ
イテレータについて人と語った事が無いから
間違いがずっと正されずにここまで来たんだろうな
672:デフォルトの名無しさん
16/08/05 15:20:22.46 Y7jgmn2a.net
>669
iとかitとかitrとかiterとかに略すから
アイ、イット、アイター、アイターとかって呼んでいるのでは
発音している本人に聞かないと真相はわからんがな
673:デフォルトの名無しさん
16/08/05 15:25:47.40 j/FnlCNZ.net
クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ
674:デフォルトの名無しさん
16/08/05 15:40:45.96 O4e+hfU+.net
クロージャーを使った実装はデコレーターパターン（GoFの）ではないという話なんだが
675:デフォルトの名無しさん
16/08/05 15:47:55.44 1PWjv4l0.net
>>673
別のパターンって言ってるだけでは？
覚えやすさや関連性からデコレーターの名前を関するのは自由だけど。
676:デフォルトの名無しさん
16/08/05 16:10:54.07 b8/AN42w.net
Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする
677:デフォルトの名無しさん
16/08/05 16:22:03.55 VlcB2rw7.net
デコレータパターンの機能を持っている設計を
全部デコレータパターンとしてしまっては
デザインパターンの意味がないからな
そりゃどんな方法でも同等の機能は実現するかもだが
ある程度を設計をパターン化して縛るのが目的でもあるからね
なんでもOKだったら意味ないよね
678:デフォルトの名無しさん
16/08/05 16:30:02.44 1z/JWFxp.net
カタログ化の価値を下げようとする連中は居るんだよ
広義のデザインパターンは～とか
○○も××パターンの亜流と言えるだろう～とか
拡大解釈と独自解釈でどんどん元の輪郭をぼやかしていくんだよ
679:デフォルトの名無しさん
16/08/05 18:48:03.79 zTXcoGD+.net
>>677
ケーキにホイップクリームのせるのもおちんぽにコンデンスミルクかけるのもデコレーションには違いないだろ実装が違うだけでやってることは完全に同じなのだから継承か委譲かクラスかクロージャかといった細かい違いを気にしなくていいからこその設計だと思うのだよ
680:デフォルトの名無しさん
16/08/05 18:50:15.99 zTXcoGD+.net
実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
681:デフォルトの名無しさん
16/08/05 19:29:11.85 Q5sCXOre.net
>>680
そうか、おまえがいう「デザイン」「ソフトウェア設計」は実装を縛らないのか。
ずいぶんフリーダムなプログラマだなw
682:デフォルトの名無しさん
16/08/05 19:48:51.35 7blLYh/r.net
クラス図レベルがデザインパターン。
そこから実際にどう具体的な言語でコードに落とし込むかが実装。
クラス図レベルで全く違うものはパターンとして別物です。
683:デフォルトの名無しさん
16/08/05 20:06:03.26 i8crE51h.net
おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな？
684:デフォルトの名無しさん
16/08/05 20:28:42.82 1l5AtzWC.net
>>670
それ単に英語がなまっているだけだから
685:デフォルトの名無しさん
16/08/06 08:01:13.80 70rUJ/gH.net
>>684
なまってるんじゃなくて、発音が[i]の母音に強いアクセントがつくと[ai]に転じるのは普通。
iterateの第1母音は普通は[i]だが、iterateという語を特に強調する時には[ai]になることもある。
ちなみにweblioはUS出身のNLP研究者にも評価が高かったりするから、そう馬鹿にしたものでもない。
686:デフォルトの名無しさん
16/08/06 10:06:20.97 FhFbCTi8.net
>>685
だから英語の訛りでドイツ語やフランス語では起こらない
URLﾘﾝｸ(ja.wikipedia.org)
687:デフォルトの名無しさん
16/08/06 10:13:18.00 BacY3CwA.net
だからどうしたんだって話
688:デフォルトの名無しさん
16/08/06 10:17:01.24 BZ9Nu5V3.net
アイテレータ君は頑張りどころを間違えてる
689:デフォルトの名無しさん
16/08/06 11:27:40.31 70rUJ/gH.net
>>686
Haben Sie gelesen, eine deutsche Übersetzung?
690:デフォルトの名無しさん
16/08/06 12:00:01.53 rJo5wxwi.net
URLﾘﾝｸ(translate.google.co.jp)
あなたはドイツ語の翻訳を読んでいましたか？
691:デフォルトの名無しさん
16/08/06 12:02:23.29 rJo5wxwi.net
>>689
Was davon ist im Zusammenhang mit?
692:デフォルトの名無しさん
16/08/06 13:54:29.24 70rUJ/gH.net
>>691
Das ist meine Frage.
693:デフォルトの名無しさん
16/08/06 15:01:07.75 rJo5wxwi.net
Nein, es ist meine Frage
694:643
16/08/06 19:33:40.65 rdi0Pbkh.net
そんなアイレテーター君にヒントをもらった>>646 ですが、
週末の余暇を使って調べ調べ C++ で書いてみました。
URLﾘﾝｸ(ideone.com)
なるほど。このくらい抽象化して簡潔に書けるなら
今の C++ には35年ほど前の Smalltalk 同様イテレーターパターンは不要と言い切ってよさそうですね。
惜しむらくは逆順用の range-based for くらい用意しておけよ…、という不満は残りますが。^^;
695:デフォルトの名無しさん
16/08/06 20:05:53.09 OCZ+hMAU.net
そもそもbegin, endなどのモロモロが
既に（外部）イテレータ以外の何物でもないわけでｗ
内部イテレータ形式を欲しがるかどうかはともかく
range-based forとかはどうでもいいよねこの場合
696:デフォルトの名無しさん
16/08/06 20:24:55.16 fG7kY+EI.net
アメリカ英語なんて
英語の方言そのものだろ。ｗ
トマトをトメイトゥとか、
ポテトをポテイトゥとか
馬鹿みたいな発音するんだぜ。
アイテレーターみたいな馬鹿っぽい発音が好きなのか？
697:デフォルトの名無しさん
16/08/06 21:29:05.67 rdi0Pbkh.net
>>695
おっしゃりたいことがよくわからなかったのですが
「イテレーター（内部なり外部なりの）が標準で提供されていればイテレーターパターン（GoFの）はいらない」
という主張（>>639,646）に対して「そもそも～」はどういう反論で、
range-based forがなぜ「どうでもいい」という話になるのしょうか？
698:デフォルトの名無しさん
16/08/06 22:17:57.01 70rUJ/gH.net
>>693
おいおい、Neinに続いて肯定文とか、なんなんだその日本語みたいなドイツ語もどきはw
699:デフォルトの名無しさん
16/08/06 22:19:24.01 70rUJ/gH.net
>>696
はいはい、あなたは馬鹿ですよ。認めてあげましょう。
700:デフォルトの名無しさん
16/08/06 22:20:26.81 70rUJ/gH.net
>>695
>そもそもbegin, endなどのモロモロが
>既に（外部）イテレータ以外の何物でもないわけでｗ
だめだ、こいつは手の施しようがないw
701:デフォルトの名無しさん
16/08/07 00:32:53.21 Z9t6ZbaZ.net
>>697
ごめん
流れつかめて無かったわ
標準のコンテナにイテレータがあるんなら
それを使う限りはイテレータパターンの必要も無い
（内部イテレータ形式もrange-based forも無くてもいい）
それだけの話
スレの最初のほうに既に書かれてる話
702:デフォルトの名無しさん
16/08/07 00:34:17.18 JriZaYfU.net
もう少し正確に言えば、言語やライブラリが
イテレータパターンを実装しているから、
あとはそれに従うだけって感じかな。
意識せずにイテレータパターンを使っている。
703:デフォルトの名無しさん
16/08/07 00:40:31.89 fZ/XAaEO.net
>>702
そやね
その言い方は正しい
704:デフォルトの名無しさん
16/08/07 06:55:15.73 N62pNMnU.net
>>702
「意識せずにイテレータパターンを使っている」は大間違い。
705:703
16/08/07 08:03:17.31 vAScX9Az.net
>>704
そやね
そっちが正しい
パターンを使うのは設計者だからね
706:デフォルトの名無しさん
16/08/08 12:57:55.81 TCnmrmuR.net
おっすおらフリーダムプログラマ
日夜社畜プログラマと戦ってるだ
707:デフォルトの名無しさん
16/08/08 13:46:12.84 jSuSjrUB.net
>>702
> もう少し正確に言えば、言語やライブラリが
> イテレータパターンを実装しているから、
正確に言うなら、イテレータパターンというのは、
> コンテナオブジェクトの要素を列挙する手段を独立させることによって、コンテナの内部仕様に依存しない
> 反復子を提供することを目的とする
実装パターンのことで(Wikipediaより)、言語やライブラリがiterableな何かを提供しているからといって、
それらがイテレータパターンを実装しているとは限らない。
708:デフォルトの名無しさん
16/08/08 13:48:55.90 jSuSjrUB.net
>>680
> 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
発想が逆だね。
ある機能を実現するための実装パターンを分類・カタログ化したものが、GoFのデザインパターンだ。
709:デフォルトの名無しさん
16/08/08 21:13:01.03 BQ4UM/x3.net
まさしくその通りだね
そして同じ機能だったらどんな設計でもOKとしてしまっては
デザインパターンの意味がない
でもこの話題はもう終わりにしたいね
710:デフォルトの名無しさん
16/08/08 21:24:02.49 aqLNls7E.net
だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
だから積み木のおうちでも構わないんだよなぁ
711:デフォルトの名無しさん
16/08/08 21:38:41.07 dN7u7NbH.net
パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。
712:デフォルトの名無しさん
16/08/08 21:41:39.71 q4pU/gN8.net
>>709
とは言っても言語が違ってもデザインパターンは通用するわけで
実装がたった一つというわけじゃないのは確か
C言語でオブジェクト指向をすることだってあるし、
クラスがなかったES5時代のJavaScriptでもデザインパターンは作れた。
重要なのはデザインパターンの設計に出てくる登場人物があるかどうかではないだろうか？
例えば、Decoratorパターンだと、Component、ConcreteComponent、
Decoretor、ConcreteDecoratorという登場人物がある。
これはクラス図で書かれているだろうけど、別にクラスである必要はない。
例えばクロージャーを使って実装してもかまわない。
またインターフェースは明示的に継承していなくても、事実上特定の関数を実装していなければ
正しく動かないなら、それはインターフェースを使っていると言ってもいいだろう。
これと同じ登場人物が出てくるものは同じデザインパターンといっても良いだろう。
713:デフォルトの名無しさん
16/08/08 21:46:47.76 rabkqueT.net
そこまで行ったら別物だって。
クロージャーやら使ってクラス図レベルで逸脱してもいいという
宗派をひらきなよ。
714:デフォルトの名無しさん
16/08/08 21:57:23.36 q4pU/gN8.net
>>713
そうはいってもだね。
クラス図がないES5でもデザインパターンの
設計通りに作れるでしょ？
715:デフォルトの名無しさん
16/08/09 05:48:45.82 tGFAeOU0.net
>>712
ばーか
716:デフォルトの名無しさん
16/08/09 07:42:08.32 ttLAI02G.net
>>714
クラス、クラス図がないからデザパタにクラスは不要というのは、本末を転倒してますよ。
GoF も述べているように（>>610） クラスの無い言語では、クラスの役割りを「カプセル化」パターン、
「継承」パターン等で補ってから、その上でたとえばデコレーターパターンを実現しているというだけです。
717:デフォルトの名無しさん
16/08/09 09:40:43.48 zWs+JfAu.net
>>716
なるほど。言語仕様としてクラスの有無ではなく
継承パターンができていれば、その実装がクロージャーでも
かまわないということですね。
そして継承パターンと言うものには、何が何を継承している
という概念があるはずですから、その「何」が登場人物に
なるわけですか。
718:デフォルトの名無しさん
16/08/09 10:28:51.94 GFJow9Sf.net
登場人物という考え方がバカっぽくて無理
719:デフォルトの名無しさん
16/08/09 15:03:31.41 V7FsU68Q.net
「○○言語だともっと簡単に実装できる」君と
「クロージャを使えばもっと簡単に実装できる」君は
いい加減うざいよ？
720:デフォルトの名無しさん
16/08/09 16:26:29.88 tGFAeOU0.net
>>719
その通りだと思います。
まずはソフトウェア設計は実装ではないが、
実装を縛る規範であるということを
理解したらいいと思います。
それが理解できたら帰っておいで。
721:デフォルトの名無しさん
16/08/09 17:57:41.45 7qytW98y.net
デザインパターン
日本語で
設計見本でいいですか？
722:デフォルトの名無しさん
16/08/09 18:04:53.60 c6svxtGU.net
そんな日本語があるか
723:デフォルトの名無しさん
16/08/09 19:57:07.69 AUCg5/Tk.net
>>708
それは過程の話な結果として実装を示すならインプリメンテーションパターンと言っているだろうしかしデザインパターンと言っているから実装を抽象化したものだ具体的な実装を示すものではないってことさ
724:デフォルトの名無しさん
16/08/09 20:07:31.05 GFJow9Sf.net
その前に君の書き込みを日本語のパターンにしてください
725:デフォルトの名無しさん
16/08/09 20:08:56.33 AUCg5/Tk.net
>>681
設計が実装を具体的に決めてしまったら設計の意味がないと思うんだよおトイレとお風呂が一緒になってますってことと具体的な便器の形とは分けられると思うんですデザインパターンっていうのはいわばそういうものでお風呂とトイレを一緒にしたら便利だよってことさ
726:デフォルトの名無しさん
16/08/09 20:10:54.82 AUCg5/Tk.net
>>724
おだまり便器野郎
727:デフォルトの名無しさん
16/08/09 20:24:12.28 FqlEy475.net
どうせ計算式をクラスにするんだろ？
728:デフォルトの名無しさん
16/08/11 18:28:28.20 vQt/3MfO.net
濃厚電波、完飲。
729:デフォルトの名無しさん
16/08/15 00:10:10.82 NEOTEyUk.net
いい加減、オブジェクト指向 vs 関数型なんていう無意味な議論やめようよ
直交する概念じゃん
関数型言語でも「本物の」オブジェクト指向プログラミングは出来るし、
最近の流行りはオブジェクト指向言語に関数型的な機能を付けることだろう
730:デフォルトの名無しさん
16/08/15 01:36:24.27 Yh7//hE4.net
本当のオブジェクトプログラムは、メッセージ交換だから、関数型が入る余地なんか無いけどな。
731:デフォルトの名無しさん
16/08/15 02:08:53.20 6fraHMZW.net
お前ら、早く本論に入れ！
美少女クラスはなぜ人間クラスを継承出来ないのよ！！！
732:デフォルトの名無しさん
16/08/15 03:13:33.69 Y0Jnfl62.net
美少女はクラスじゃなくて人間クラスのインスタンスで
パラメータが特定の値のものなだけだよ。
プリンセスメーカーであれば「魅力」のパラメータが
高くて「年齢」が若ければ美少女なんじゃね？
733:デフォルトの名無しさん
16/08/15 11:57:12.25 P1EAyeII.net
排便メソッドはどうなるんだ！
734:デフォルトの名無しさん
16/08/15 13:00:28.85 TUIKyN4z.net
>>729
本物…
735:デフォルトの名無しさん
16/08/15 13:36:04.19 Yh7//hE4.net
>>732
まあそうだな。
人間クラスの女性属性で年齢属性が十代で、
あとはいろんなパラメータがバランス良く絶妙なバランスであるだけ。
736:デフォルトの名無しさん
16/08/15 13:43:17.25 Y0Jnfl62.net
>>733
排便性能とでもいうパラメータ作れば良いんじゃねーの？
美少女じゃなくても排便が困難な人っているからな。
737:デフォルトの名無しさん
16/08/15 15:37:08.19 Yh7//hE4.net
便秘気味な美少女かw
738:デフォルトの名無しさん
16/08/15 16:44:15.38 uCi+R87y.net
|
| 彡 ⌒ ミ
＼ (´･ω･`)またうんこの話してる...
(| |)::::
(γ /:::::::
し ＼:::
＼
739:デフォルトの名無しさん
16/08/15 16:45:21.70 P1EAyeII.net
オブジェクト指向は愚かな考え。
排便メソッドを実装した人間クラスから美少女クラスが作れない。
740:デフォルトの名無しさん
16/08/15 17:02:42.33 NHD7YcMK.net
アヒルががーがーなくのではなく、がーがー鳴けばそれがアヒルなのである
うんこができればそれは人間なのである
741:デフォルトの名無しさん
16/08/15 17:08:50.15 Y0Jnfl62.net
オウムがガーガーなけばそれはアヒルなのである？
742:デフォルトの名無しさん
16/08/15 19:19:30.08 ATo5mwbJ.net
>>738
「ウンコを覗くときウンコもまたおまえを覗いているのだ。」
もうこの子は脳の端までウンコになっちゃったんだよ…
743:デフォルトの名無しさん
16/08/16 12:32:47.23 nB+m5lHF.net
頬を紅潮させた少女のアナルは今にも決壊寸前のダムの如くヒクヒクと静かに脈打つのであった
そのアナルをまるで獲物を狙う蜥蜴の様な眼差しでジットリと凝視していたお前は…
744:デフォルトの名無しさん
16/09/04 22:44:30.10 AI4OMPbE.net
やはり、オブジェクト指向は愚かな考えなんでしょうか？
それはなぜですか？
745:デフォルトの名無しさん
16/09/05 23:26:30.97 2pvjX+vh.net
>>744
なんのメリットもないから
746:デフォルトの名無しさん
16/09/10 22:12:27.45 vL431mpn.net
クロージャという秘境
747:デフォルトの名無しさん
16/09/11 09:06:24.12 HdsNani4.net
オブジェクト指向にクロージャーが取り入れられてから、
オブジェクト指向は更に便利になった。
748:デフォルトの名無しさん
16/09/11 09:11:08.53 xTqWSUIJ.net
どうせなら理想のクロージャの構文はどんなものか議論しよう。
美少女のウンコの話はもういいから。
749:デフォルトの名無しさん
16/09/11 10:48:53.37 EVh79L2H.net
いや美少女うんこの方が重要だ
750:デフォルトの名無しさん
16/09/11 18:47:04.73 LruamEXh.net
間をとってクソージャ
751:デフォルトの名無しさん
16/09/12 10:17:01.19 WLe9OZIE.net
おあとがよろしいようで
752:デフォルトの名無しさん
16/09/12 11:18:07.22 DqPwyMnw.net
じゃあ質問
若い時は買ってでもするものな～んじゃ？
753:デフォルトの名無しさん
16/09/12 11:24:36.38 R5hylYBo.net
コンビニでトイレだけ借りるのは気まずいので後で何か買って帰る
754:デフォルトの名無しさん
16/09/12 13:15:37.24 zvXoPKj/.net
美少女を買う
755:デフォルトの名無しさん
16/09/12 21:03:27.94 p0km3lhz.net
>>752
URLﾘﾝｸ(find-travel.jp)
シンガポール初 キッズクラブ
１２歳までの子供が安全に遊べます。小さい子供連れのファミリに―にはうれしい施設です。
セントーサエキスプレスの終点ビーチ駅で下車、徒歩五分ほどです。
子供は有料ですが、付き添いの大人は、無料です。
756:デフォルトの名無しさん
16/09/12 21:04:17.88 p0km3lhz.net
URLﾘﾝｸ(www.dan-b.com)
ウェーブスターライド
すべり台
もくば館の電動木馬
自走式のジェットコースター。小さなお子様でも、
大人の付き添いがあれば乗れる。
付き添いの大人は無料にしてくれる心遣いがうれしい。
757:デフォルトの名無しさん
16/09/17 19:06:05.53 iND/Jut9.net
オブジェクト指向と計算式という対比がまずおかしいスレ
758:デフォルトの名無しさん
16/10/11 13:34:51.26 SPhMZv+b.net
>>757
その前に>> 1の脳みそがオカシイ。
議論以前の話
759:デフォルトの名無しさん
16/11/14 16:47:20.70 cBDVjyju.net
>>733
排便メソッドつくってうんち吐き出させれば良いじゃん…
760:デフォルトの名無しさん
17/03/21 23:51:29.32 RJ2XVIqX.net
できの悪いプログラマはこうやってくだらんことに執着した挙げ句道を外すからな
オブジェクト指向を禁ずるのは当然だが、プログラムも規制すべきだろ
761:デフォルトの名無しさん
17/05/12 17:45:37.79 4b98WttR.net
外に公開するインターフェイスだけオブジェクト指向で中身は手続きとかできないの？
762:デフォルトの名無しさん
17/05/13 00:36:36.42 1iFjjcJx.net
欲張りな事言うんじゃありません！
763:デフォルトの名無しさん
17/05/13 06:58:15.64 tunExteF.net
なんでもかんでもOOPしないといけないという強迫観念も新しい病気みたいなもんだ
764:デフォルトの名無しさん
17/05/14 02:14:38.21 92l7gqU0.net
OOPは自然な概念。
しようとしなくても自然にOOPで書いてしまう。
765:デフォルトの名無しさん
17/05/14 03:31:10.29 DFEPxXnF.net
んじゃ、Cでファイル読んで行毎に番号振るプログラムを自然にOOPで書いてくれ。
OOPな言語でも油断してると手続き的なコードになるのが実感。
手続き型言語や関数型言語のが自然と言えば自然。
OOPはどっちかと言うと手続き型言語の限界を超える苦肉の策。
有効ではあっても、自然ではない。
766:デフォルトの名無しさん
17/05/14 07:58:36.42 HpXv37Pf.net
手続き型の言語使ってるんだからそりゃ書き方は自然に手続き的になるわw
767:デフォルトの名無しさん
17/05/14 08:01:38.88 FpH7uWr+.net
>>765
とりまなんかのOOPLで「ファイル読んで行毎に番号振る」操作の“油断した”版をideone.comあたりで晒して見せてよ
768:デフォルトの名無しさん
17/05/14 09:35:08.29 Kxs5LDLR.net
>>765は愚かな考え
769:デフォルトの名無しさん
17/05/15 00:15:06.25 pPIG/Itw.net
>>765
> Cでファイル読んで行毎に番号振るプログラム
FILE構造体使うからOOPだな。
770:デフォルトの名無しさん
17/05/15 03:18:59.80 sMDSuUUf.net
後での取り回しのために動作分離してオブジェクトにするんであって
なんで"その中身をオブジェクト指向で書けるか？"なんて
頓珍漢な発想が出るのかの方が不思議だよ。
771:デフォルトの名無しさん
17/05/15 07:10:20.57 fipzejMn.net
まぁそうだよね。関数型だって関数の中味に手続き書くだろうし
772:デフォルトの名無しさん
17/05/15 07:18:26.21 Nl227Lk0.net
関数型言語で手続きは書けんですわ
773:デフォルトの名無しさん
17/05/15 09:31:45.07 OVQU3b0Y.net
んなこたーない何のためのモナドだよ
774:デフォルトの名無しさん
17/05/15 12:20:31.47 BOxxzUgK.net
>>771
関数型言語では手続きは書かない。
式か、式とパターンマッチやガードによる条件わけだけ。モナドもdo形式で書くと手続きっぽいけど、実際は大きな一つの式。
if/caseに似てるけど、文と式が入り乱れるのと違って全部式。
それで何が嬉しいかと言うと、正しい動作をすると言う証明が出来る。
775:デフォルトの名無しさん
17/05/15 12:31:36.20 ADjMf5zc.net
せやね関数型言語でも中身はモナド駆使して手続き的に書くのが自然やからね
…せやろか？
776:デフォルトの名無しさん
17/05/16 00:16:27.17 HWJ+4Z2c.net
>>767
import sys
for i, line in enumerate(open(sys.argv[1])):
____print i, line,
Python3だとprint i, line end = ' '
ついついこう書いちゃうだろ？
でも、出力先がGUIになった途端破綻する。
そう言うのを見越して汎用的にしとかんと。
777:デフォルトの名無しさん
17/05/16 06:05:49.63 TdUcLCGW.net
出力先を切り替えられるようにしたい、は別の要件でしょ
778:デフォルトの名無しさん
17/05/16 06:12:48.09 YL1OfOAE.net
>>776が全然破綻しとらん件
779:デフォルトの名無しさん
17/05/19 01:55:11.10 879cm/wV.net
CでOOPしてたやつって、なんかのGUIライブラリでなかったっけか？
780:デフォルトの名無しさん
17/05/19 10:49:17.61 sbMh7Sut.net
gtk
781:デフォルトの名無しさん
17/05/22 08:36:50.27 wGbbC49U.net
X
782:デフォルトの名無しさん
17/06/20 16:22:37.74 AtKkt+PQ.net
オブジェクト指向の方が自然だと思うし好きだけどPythonやjsみたいな動的型付け言語でオブジェクト指向は無理というか無駄な気がしてきた
オブジェクト指向は副作用を限定化するためにカプセル化が必須だけど動的型付け言語だとそれが保証されない
横からいくらでもメンバの付け足しやメソッドのすげ替えができてしまう
そうなると副作用の保証ができないどころか、静的解析によるインテリセンスやエラー検出というメリットさえ捨てる羽目になる
そうなるともうオブジェクト指向で作る意味がない
クラス単位で保証ができない以上、関数で保証する他なく
必然的に関数型にせざるを得ない
783:デフォルトの名無しさん
17/06/20 18:50:11.59 8inGEH6m.net
「世界がどんどん変わって行くのを俺が全部コントロールして阻止しなければならない…
そうでなければ世界はバラバラになってしまう…」
「どうしたんですか？先輩」(もぐもぐ
「おお後輩！…なんだそれ？」
「売店がパンじゃなくて弁当扱い出したんですよ
ゴミかさばるから売店とこで捨てろですって。
まぁ、どうせ僕が一括して持ってくんでしょうがw」
「後輩」
「はい？」
「カレーある？」
「たしか」
「じゃあ、それ一つ」
「はい」
784:デフォルトの名無しさん
17/06/21 09:03:10.49 Y4WM7moX.net
オブジェクト指向と副作用の保証は関係ない
785:デフォルトの名無しさん
17/07/27 03:06:58.86 9ehpllTb.net
パイセン方、JS勉強したてでオブジェクト指向って言葉が出てきたばっかでよく分かってないドブネズミ以下の僕に教えて
オブジェクト指向ってプログラミングのルールとか具体的な所作のことを指すの？
例えば「このプログラムは誰が読んでも分かりやすいものしよう」程度のものはオブジェクト指向とは言わないの？
786:デフォルトの名無しさん
17/07/27 04:46:03.86 wpPsIhCe.net
オブシコきっしょ
787:デフォルトの名無しさん
17/07/27 19:35:15.21 NhSve46F.net
>>785
最初、「適当に飛び先決めて好きなように処理書いて戻す」やってたら
後でプログラマが死にそうになったので
"入り口があったら出口はここ"とブロック化しようぜ！が『構造化プログラミング』
Cなどが直接の成果で今の言語はほぼこの流れを受け継いでる。
次にブロック(サブルーチン)化されたからこれをクラスとして使いまわそうぜ！が『オブジェクト指向』
ここで単純に使い回しの方向でCから発展したのがC++
主目的が使い回し。
それとは別にブロックを使い回すにあたって「これをやれ」という具体的な
コマンドを受けてクラスが独自に動くようにすれば
相互の関係がゆるくなって取り回しと修正が楽になる。というのが
smalltalk>objective-C>JAVA～と続いてるメッセージ/メソッド方式
目的はクラスの独立
もっと進んで命令すればクラスが自分でデータや仕事探すぐらいになるだろ？
というエージェント指向はまだ実現していない。
788:デフォルトの名無しさん
17/07/27 20:29:54.68 5IXklzdW.net
Javaをそちらのダメな考え方の方に入れるのはJavaが可哀そう
789:デフォルトの名無しさん
17/07/27 20:37:05.89 2IdVcl0s.net
メソッドはメッセージ側のスタイルなんでなぁ。
ウィキペディアの「影響を受けた言語」書き換えてくるかい？
「クラスとは構造体に関数がついたもの」って90年代の
C++なんかをベースにしたオブジェクト指向の説明とか
いまじゃ誰も電波すぎて理解できねぇよ。
「自動車は馬車から馬が外れたものである」かっつの…
790:デフォルトの名無しさん
17/07/27 21:48:06.61 5IXklzdW.net
オブジェクトはデータに自身を操作するための処理が付いたもの
というありがちな説明は、これを正しいとするかどうかは別として
電波すぎて理解できない、という程のものではない
厳密かどうかは置いておいたとして、具体性があり、ある種の分かりやすさはある
「データ」とか「処理」とかいう言葉は、プログラマじゃなくても知ってる一般的な言葉だし
大体の人が正しく理解して使っているであろう
ということと、コンピュータの根本の原理も大昔から特に変わってないので
「データ」や「処理」という言葉が、理解できないほどに意味をなさなくなっているわけでもない
普通に理解できる範囲
実際にはもっと賢い表現が適切であろうが、今は理解できる文言かどうかが焦点であるから
関係が無い
どちらかというとsmalltalkというかアランケイのオブジェクト指向の表現の方が若干電波であり
事前に知識が無ければ、何を言っているかよくわからない、正しく理解できない
現実の部分が見えてこない、拡大解釈してしまう、思考が発散する、といったところ
最終的には生態系がどうのこうの言い出すから
791:デフォルトの名無しさん
17/07/28 08:44:57.99 NpsU3dCh.net
>>790
> どちらかというとsmalltalkというかアランケイのオブジェクト指向の表現の方が若干電波
アラン・ケイのメッセージングのオブジェクト指向は、設計・実装・実行・運用・保守とあらゆる局面における
「遅延結合」（…という表現だと実行時のみにひっぱられる人がいるので「決定の遅延」の方がベターか）を
メッセージングというお題目を通じて実践・徹底・サポートするアイデアなのだけど
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(metatoys.org)
具体的にはどこらへんが“電波”だと感じるのか、きかせてもらってもいい？
792:デフォルトの名無しさん
17/07/28 09:16:50.33 oLQXjxeQ.net
全部電波じゃねえかwww
793:デフォルトの名無しさん
17/07/28 10:03:16.12 orh4jmw3.net
>>791
前からちょいちょい思ってたけれど、脳がパソコンの一個のCPUで完結してる人とか
処理時間の遅れとか当人の脳内世界に存在しないから概念が理解できないみたい。
60年代に大学間などの通信ネットワークが作られてこのかた
現代のマルチタスク・マルチコアに至るまで
相手の処理終了が不明な状態で
"逐次実行なんか期待できない"というところから話が始まってるのに
脳が「プログラムってバッチ処理だろ？」で止まってるから
「順番に動かないプログラムなんてあるか！」って本気で思ってるんだよ、こういう人…
794:デフォルトの名無しさん
17/07/28 13:34:41.77 NpsU3dCh.net
>>792
>全部電波じゃねえかwww
うん。だから例えば具体的にはどんなとこころ？
あるいは件の主張を端から理解する気が無いのならレスは無用に願います
795:デフォルトの名無しさん
17/07/28 16:54:15.12 s1JdgxyV.net
>>790
>事前に知識が無ければ、何を言っているかよくわからない、正しく理解できない
Smalltalkを理解するために事前の知識は要らないぞ。
実践せずに本やブログ記事を読むだけで理解しようと思っている人は苦労するだろうけど。
796:デフォルトの名無しさん
17/07/28 19:42:10.36 NpsU3dCh.net
>>795
んー、それはどうだろう。気持ちはわらんでもないけど、ちょっと言い過ぎではないかなぁ…
たとえば同じように Python を“理解するために事前に必要とされる知識”を問われた場合、
どんな答えを想定しているか教えてもらえる？
あるいは Java なら必要だけど、Python であれば Smalltalk と同程度には必要ないとかそんな程度の話？
797:デフォルトの名無しさん
17/07/29 15:03:26.59 sLFMqneM.net
例のFILE構造体を用いたファイル操作はファイルシステムに対する低水準な操作がカプセル化され利用者から見えない設計だからオブジェクト指向設計、
と言って良いものかどうか…
（内部ではiob[ ]という配列操作になっておりインスタンスの個数に上限がある
&& 物理ディスクの個数はもっと小さいから、ファイル操作の内部の実装にはiob[ ]全体を操作対象とする手続き型のコードが含まれる
これをオブジェクト指向と呼んで良いのなら、ユニックスのシステムコールやWin32 APIからハンドルを受け取って
ハンドルに対して操作を行うのは全部オブジェクト指向と呼んで良いことになる
が
798:デフォルトの名無しさん
17/07/29 15:11:23.58 sLFMqneM.net
>>793
順番として書けないプログラムがあるか！！！！１１１！！！！１！
確かに非同期に動く複数のﾌﾞﾂというやつは全体としては順序的でない並列的な振る舞をするが
それらを同期させる手順自体は順序として書ける（そうでないとCPUに処理させられない
799:デフォルトの名無しさん
17/07/29 22:52:17.25 H/n/hEUB.net
>>798
のような話もあると思う
マルチプロセスだろうが、複数のコンピュータだろうが、なんであれ
結局、処理の順番は大事だろう
というのもあるが、それは置いておいたとして
>"逐次実行なんか期待できない"というところから話が始まってるのに
逐次実行が期待できないケースがあったとして、それはそれで置いておくけど
逐次実行が期待できるケースにまでそのモデルを使わなければならないのかどうなのか
ってのは有ると思う
a = 1 + b; ・・・①
b = c + 2; ・・・②
の①②に関しては、少なくとも逐次実行を期待したいし
複雑なモデルは必要ないと思う
全部の個所において、ありとあらゆることを想定した包括的モデル、を適用するのは
あまり好きではない
800:デフォルトの名無しさん
17/07/30 00:46:29.50 k8Kwm2zH.net
a={1,2,........100};
sum(a);
こんな場合、遠くの鯖でも近くの鯖でも10なら10ずつ(実際ににはもっと粒度が大きくないと割に合わないけど)分割して1-10の合計+11-20の合計+...って感じで全部揃いさえすれば順番関係無いって処理もあるお。
801:デフォルトの名無しさん
17/07/30 02:32:19.52 pLyoXQEm.net
>>799
オブジェクト指向（C++とかじゃなくて上でいうアランケイ的な）が
逐次処理を否定していると思ってるなら、それは違う
言うならば、並列処理できるときにも逐次処理するのを否定しているという感じ。
その例にあげた依存のある計算みたいに、逐次処理が必要なところは
そうしなきゃならない。でもそうじゃないところは並列にやればいい。
CPUのスーパースカラも同じだね。前の命令の演算結果を参照するような
場合はパイプラインが止まるけど、依存が無ければ並列にどんどん進められる
802:デフォルトの名無しさん
17/07/30 08:12:50.06 oVuvng50.net
>>800
バ、バラバラに計算した部分和を最後にどうするんです？
803:デフォルトの名無しさん
17/07/30 08:15:16.39 1m5312Xu.net
sumなんだから足し合わせる。
804:デフォルトの名無しさん
17/07/30 08:20:27.85 oVuvng50.net
>>803
1. 同期をとってから
2. 足し合わせる
のでは…
805:デフォルトの名無しさん
17/07/30 10:22:05.09 AatiOL5G.net
C#, Java8 の、Parallel はそう。
並列処理で、最後に同期する
各スレッドでソートして、最後にマージするとか
806:デフォルトの名無しさん
17/07/30 20:37:12.58 OOsADo1S.net
>>804
全部揃いさえすれば=同期とったら
「最後」にどうなる？
解:合計します。
突っ込まれるような事だったかな。。。
807:デフォルトの名無しさん
17/07/30 22:10:03.14 22wh/XXk.net
処理が一つの処理(タスク)単位になった時に
シングルタスク指向じゃやってられないよねってあたりまえの話なのに
なんで2017年に「そんなことはない！俺はオブジェクト指向が嫌いだ！」って
頭ごとシングルタスクのじいさんが湧くんだ…
808:デフォルトの名無しさん
17/07/30 22:15:37.41 uSOmX9+I.net
>>801
そういう風に俺は言ってない
>逐次実行が期待できないケースがあったとして、それはそれで置いておくけど
>逐次実行が期待できるケースにまでそのモデルを使わなければならないのかどうなのか
と書いた
809:デフォルトの名無しさん
17/07/30 22:23:06.49 uSOmX9+I.net
シングルタスクじゃ扱いきれなくて
マルチタスクが合ってるって思える部分が出てきたら
その部分ではマルチタスク指向とやらをやれば良いのでは？
オブジェクト指向とは直接的に関係が無いね
810:デフォルトの名無しさん
17/07/30 22:57:11.52 UpPLfSXm.net
C++とかハードに直結してるのに使い回しにだけオブジェクト指向を使おうとしたクソを通してオブジェクト指向知った人の末路がこれ
811:デフォルトの名無しさん
17/07/30 22:57:44.42 AatiOL5G.net
シングルスレッドで同時接続数、1万をこなす、Node.js の、WebSocket
ただし、CPU を多く使うものは、ダメだけど
812:デフォルトの名無しさん
17/07/30 23:41:28.81 uSOmX9+I.net
そーゆーのとオブジェクト指向は本質的に関係なくない？
タスクの実装に向いているとしたところで
じゃあ、タスクの実装以外ではメリット無いのか？ってことになる
全体的にはマルチタスク的だったとしても、細かく見ていけば、個々はシングルタスクな部分も出てくるだろ
ほとんどのOO言語のオブジェクトの実装は
「データと処理を一纏めにしたもの」、っていう実装になってることが多いんだから
それを考えると、ほとんど何でも実装しやすいんだけども
(↑マルチタスクとかシングルタスクとか関係なくね)
この説明に拒否反応を示す人がいて
> いまじゃ誰も電波すぎて理解できねぇよ。
って言うから、どーなんだよ、と
オブジェクトはデータと処理を一纏めにしたもの、ってそんなに理解しにくいか？という話だったはず
ただ、この説明の仕方は、かなりボトムアップ的で、実装から炙り出したところがあって
「とどのつまりこういうことだろ」と頭ごなしに言われているようで気分が悪い
つまり、オブジェクト指向の効率的で有効な実装は、えてしてそうなる、というような
あとオブジェクトの全貌は語ってなくて、「言っている範囲においては間違ったことは言ってない」
程度の説明でしかないけども
しかし実際にそのような実装になってる言語が多いから、完全に無視してよいというものではないし
頭にはおいておかなければならないね
813:デフォルトの名無しさん
17/07/31 20:33:56.98 E0ER4Q8l.net
>>806
>全部揃いさえすれば=同期とったら
さも最初から書いてあったかのように嘘を言い…
814:デフォルトの名無しさん
17/07/31 20:46:14.25 nj7BetAr.net
「あ、お客さま、こちらのおリンゴ少々傷んでおりますので、交換致しますね」
レジから店員が離れたらどうなっちゃうの！どうなっちゃうの！？
もう仕事できないよね！業務崩壊だよね！！
「はい、こちらで宜しかったでしょうか？ では御会計は～」
戻ってくるなんて説明なかったよね！処理が続くとも言ってないよね！！！
ボク意味わかんない！！！！！！！！
815:デフォルトの名無しさん
17/07/31 21:15:55.31 E0ER4Q8l.net
>>814
お客様はCPUです！！
816:デフォルトの名無しさん
17/08/01 02:33:45.51 A0OBZNC2.net
オブジェクト指向は、データと処理をひと纏めにする？
馬鹿じゃないの。
機能で分けるの。
817:デフォルトの名無しさん
17/08/01 08:15:51.20 9qUpAvFS.net
>>816
機能で分けることはデータと処理を一体化することを否定しない
818:デフォルトの名無しさん
17/08/01 08:17:16.36 9qUpAvFS.net
一体化とはつまり一線を超えるということ
819:デフォルトの名無しさん
17/08/01 09:02:35.58 qHCR3K6Z.net
そんな集合論の話してるんじゃなかろうに
820:デフォルトの名無しさん
17/08/01 15:47:46.27 zRlG3ihR.net
機能で分けるって言ったら、そら、なんでも機能で分けるもんなんだよ
例えばCなんかで関数に分けるって事を考えても、当たり前、機能で分けるわ
機能で分けるってだけじゃ何の説明にもなってない
むしろ機能以外で分ける必然性がないし
だから機能で分けるのはどのような何であろうと、分ける以上は当たり前そうする前提として
「具体的にどのような方法、単位で分けるの？」って部分がないと
その時に、データと処理を一纏めにしたものをオブジェクトとして、ってのが出てくる
クラスは機能で分ける、って文言は、おかしなクラス設計をする人に対して
クラスは機能で分けなきゃダメだよ、と注意するために有るのであって
オブジェクト指向の説明にはなってないんだよ
例えば、「関数は機能でわける」って言い方も出来るし、なんでもそうじゃん
821:デフォルトの名無しさん
17/08/01 19:28:14.48 zRlG3ihR.net
平たく言えば「機能で分ける」ってのは
クラスの作り方や設計方針の話であって
クラスやオブジェクトの根底のメカニズムについては何も言及してないんだよ
822:デフォルトの名無しさん
17/08/01 21:13:20.77 jGPQWGeS.net
ふる～いサブルーチン的な「関数」の発想だと
たとえば「ドルと円を換算する」"関数"はただの「処理機」だから
レートと額を送ると換算額が返ってくる、という発想になる。
そこがオブジェクト指向では「ドルと円を換算する」"クラス"は
そういう処理をする「処理場」なので送るのは
"換算してくれ"という命令コマンドと額になる。
違いはなんだろう？
「関数じゃなくてクラスはレートってデータを持ってて、換算という操作関数が付いてんだろ？」？
違います。自動車が馬抜き馬車ではないように。
ポイントは「換算」というタスクは当該クラスが責任を持つ仕事で
処理を頼んだ側まで責任は及ばない設計になっていることです。
オブジェクト指向の思想ではそれぞれで責任が切り分けられているので
プログラムの修正の際に修正が延々波及する事態を抑制できるし
処理はタスクを行う実行単位で切り分けられているから
処理終了を待つ必要のないタスクは並列実行できる。
"そういうこともできる"ではなく"そういうことをやるように"仕様が作られている。
そういう違いです。
823:デフォルトの名無しさん
17/08/01 23:31:45.78 zRlG3ihR.net
で、結局クラスやオブジェクトの持つメカニズムについては言及しないのであった
書いてある内容は「そういう風に考えてください、そういう風にとらえてください」
程度のものでしかない
後半の並列処理なんか全然オブジェクト指向と関係が無いしな
そういう風に書けば、そうなる、ってだけ
「ポイントは「換算」というタスクは～」の部分に関してなど
一般化して他のものに関しても同じことが言えるし
何の説明にもなってない
唯の一般的に良いといわれるプログラミングの作法を説明しているに過ぎない
もちろんその作法はOOPでも通用するが、OOPの説明にはなってない
例えば、クラスを"関数"に置き換えて
「ポイントは「換算」というタスクは当該"関数"が責任を持つ仕事で
処理を頼んだ側まで責任は及ばない設計になっていることです。
"関数"を使う思想では、それぞれで責任が切り分けられているので
プログラムの修正の際に修正が延々波及する事態を抑制できるし
処理はタスクを行う実行単位で"関数"に切り分けられている」
っていう風に言ったって別に通じるし、オブジェクト指向の説明になってないことが分かる
一般的に良いといわれるプログラミングの作法を説明しているに過ぎない
となれば結局、「関数とクラスは何が違うのか」って事がクローズアップされるべきで
「関数じゃなくてクラスはレートってデータを持ってて、換算という操作関数が付いてんだろ？」
ってのは結構的を得た説明なわけだ、少なくとも君の糞みたいな説明よりは
824:デフォルトの名無しさん
17/08/01 23:33:36.12 zRlG3ihR.net
だたし、オブジェクトはデータと処理を一纏めにしたものって説明は
オブジェクトの性質の全部を言い表しているわけじゃない
「言っている範囲においては間違ったことは言ってない」程度のもの
825:デフォルトの名無しさん
17/08/01 23:58:00.10 jGPQWGeS.net
なんかまだ現実を理解していないみたいだけど
誰かがそう考えているとかそういう話ですらなくて
"君が"一人で自動車が走り回ってるこの時代のど真ん中で
「いいや！自動車は馬なし馬車ともみなせる！誰も自動車の細かいシステムについて
俺に懇切丁寧にマンツーマンで教えてくれないからな！
あくまで自動車とかいうのは馬なし馬車にすぎない！！」
ってほざいてるからみんななんだこのボケジジイwと笑ってるだけだよ。
826:デフォルトの名無しさん
17/08/02 00:03:52.06 fdgsCGyr.net
俺は別に笑われてないんだけど
君の書き込みは電波すぎて誰にも相手にされてないかもしれないが
これが自己紹介乙というやつか
827:デフォルトの名無しさん
17/08/05 13:13:40.78 S4Sewhvz.net
>>823
>書いてある内容は「そういう風に考えてください、そういう風にとらえてください」
>程度のものでしかない
だってOOPとかその程度のものやとしか言いようが無いし…
OOPにしたからといってチューリングマシンでできない計算ができるようになるわけでもないし、
高階関数の系の能力を超えるわけでもない
「オブジェクト」も「機能」や「データ構造」と同じく人間が勝手に設けた区切りと考えたほうが精神衛生上宜しい
「漏れの無い抽象化」を達成せしめたクラスに属するオブジェクトのみが、独立した数学的対象同然の正当性を有す
でもそうじゃないクラス（とそのインスタンスとしてのオブジェクト）も世の中にはゴマンとあり、実用OOPはそれらも包含してゐる
OOPの枠内の全てをスッキリ定義づけて一意のクラス分けを導くような数学は目下無いしこれからも無さげ
828:デフォルトの名無しさん
17/08/05 13:16:50.26 S4Sewhvz.net
ちな
>「関数じゃなくてクラスはレートってデータを持ってて、換算という操作関数が付いてんだろ？」 （823）
というんのはクラスを「レートという束縛変数を有する「換算」という関数」の定義とみなしてゐる、
とみなすこともできる、、
829:デフォルトの名無しさん
17/08/05 18:31:55.27 g5qo54h/.net
そこまでわかってるなら、手続き型言語には何があるかも分かってるだろ
紐解いていけば、手続き型言語には、「テータ構造」と「制御構造」の二つしかない
あとは定数とかもあるけど、無視しといてよいし
本当に、データ構造と制御構造しかない
クラスはこの二つをまとめたパーツ、ぐらいの認識でよろしい
830:デフォルトの名無しさん
17/08/05 18:37:32.12 g5qo54h/.net
データ構造はメモリの空間的分割構造といえるし
制御構造はCPUの時間的分割構造といえる
これで空間と時間がそろったからプログラミングの準備が出来たといえる
クラスは単に、C時代はデータ構造と制御構造を別々に定義していたのを
区切りの良いところで纏めて定義しましょうってだけだよ
小さなプログラム(クラス)の破片を集めて大きなプログラムにしましょうってだけ
実際クラスのメンバ変数はクラス内のグローバル変数だしな
831:デフォルトの名無しさん
17/08/05 21:05:03.20 S4Sewhvz.net
>>830
>実際クラスのメンバ変数はクラス内のグローバル変数だしな
これはそう作ればそうなるし、そうでない作り方もできる
（クロージャにするなら通常はコンストラクタでメンバ変数の値を固定してしまい以後変えないとか、
OOPはハマるべきところにはきっちりハマるから、必要性はある
ハマればセマンティクスとコードの表記がきれいに対応してたいへん保守しやすく書きやすいコードになる
ただしそうなるのは漏れの無い抽象化が可能とか、漏れを設計で見えにくいところに隠せるとかそういうケースに限られる
832:デフォルトの名無しさん
17/08/07 07:48:42.00 GyL1JWIh.net
>漏れの無い抽象化が可能
こんなのよっぽど単純な事象以外ありえんだろ。
833:デフォルトの名無しさん
17/08/07 08:20:11.85 nZ0RU5t+.net
なんか、別なものに見立てての説明ばかり受けたせいで
なにかに見立てないとオブジェクト指向じゃないみたいな変な理解をしてる人がおるけど
要するに会社の「◯◯部」とか「◯◯課」みたいに
仕事と処理を送るとよしなにやってくれる単位で切り分けるってだけの話だし
「こういうことも◯◯課の仕事に新設」でも「仕事の質が変わったから部課を統廃合して編成しなおし」でも
部課が責任を持つことで取り回しが楽になるよね。だし
834:デフォルトの名無しさん
17/08/07 12:21:59.74 +X2y1OVW.net
お前もやんｗ見立て上手やねｗ
835:デフォルトの名無しさん
17/08/07 14:20:12.45 nZ0RU5t+.net
いや、会社みたいな組織は必要な仕事の流れに応じて組み変わるじゃん？
無理ないちゃもんつける人は変化しないもの出してきて
「猫に羽が生えて飛ばないからオブジェクト指向は間違い！」って言いだすからw
836:デフォルトの名無しさん
17/08/07 23:55:38.90 ZYg+qYF7.net
部署部署言ったって、それはプログラムにおいては、何に相当するのか
って話がある
そこが無いと本当に意味のないたとえ話にすぎない
プログラムで会社の部署のように振舞わせるには
データと処理の両方が必要
データだけでも処理だけでも部署のようには振舞えない
classはプログラム環境のフルセットじゃないといけない
その意味で、オブジェクトは処理とデータを纏めたものでなければならないし
そうなってる
それだけの話
837:デフォルトの名無しさん
17/08/16 14:51:22.44 3vyPkFdL.net
変な例え話を出したり、大仰な説明をしたりしないと理解できないだろう、なんて思ってる時点で間違ってると思わないのか
プログラムの素養の無い人でもOOならプログラミングできるようになります！とか妄想してるのか？
838:デフォルトの名無しさん
17/08/17 13:15:34.31 1fq8yyMU.net
そうだね、自動車は馬なし馬車だから運転者は御者だね。
最近の馬なし馬車は馬を繋ぐパーツが欠落してるからけしからんね。
839:デフォルトの名無しさん
17/08/17 14:12:54.09 FW1vzuuL.net
まだ馬なし馬車とか言ってるのかよ、進歩ないな
誰も興味ないんだって、そんなアホで的を得てない例え話
840:デフォルトの名無しさん
17/08/17 14:36:57.93 1fq8yyMU.net
「クラスは構造体」じいさんにはぴったりすぎて例えですらないけれど？
841:デフォルトの名無しさん
17/08/17 15:26:05.48 FW1vzuuL.net
仮想の脳内の敵と戦ってるんだな、がんばれよ
その仮想の敵はお前自身でもあるからな
842:デフォルトの名無しさん
17/08/22 22:49:49.51 UHwuUWMX.net
URLﾘﾝｸ(livedoor.blogimg.jp)
843:デフォルトの名無しさん
18/05/23 21:53:52.54 Au5e7VGg.net
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
MNVZG
844:デフォルトの名無しさん
18/07/05 00:08:30.02 RfoszcD2.net
6OE
845:デフォルトの名無しさん
18/10/21 08:38:21.16 EM6DzNCN.net
＞例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
この車、タイヤがパンクしてるぜ！
この俺、チンポがシコシコしてるぜ！
どちらも「オブジェクト指向」だろう？
注目は、選択肢イです。この上向きが集約で、下向きが分解です。
自動車は、アクセルやブレーキ、ハンドルなどに分解されるからです。
URLﾘﾝｸ(sm.seeeko.com)
浮気に激怒の妻、眠る夫の局部を切断しトイレに流す（印）
2018年02月25日 04:00
URLﾘﾝｸ(www.excite.co.jp)
846:デフォルトの名無しさん
18/10/30 21:12:23.78 elaGjnSQ.net
その計算式とやらだけでプログラムを書いているの?
847:デフォルトの名無しさん
18/11/04 11:29:43.61 hQdPSgHl.net
ブリッジパターンの応用手順のブログみたい。パッケージを開発する時を前提にしているね。
URLﾘﾝｸ(blogs.yahoo.co.jp)
848:デフォルトの名無しさん
18/11/04 17:43:39.34 Q/zWRkIF.net
↑役に立たないゴミ
849:デフォルトの名無しさん
19/06/19 05:01:44.97 tVNS+22r.net
【出資】松本卓朗 人工知能詐欺【注意】
ｽﾚﾘﾝｸ(rikei板)
850:デフォルトの名無しさん
19/06/19 18:05:32.05 GI5x1tg+.net
唯一純粋なオブジェクト指向言語と呼ばれることがあるSmalltalkが
ほとんど世間一般に普及していないのに、
オブジェクト指向が持てはやされるのはなぜ？
いいとこ取り？
851:デフォルトの名無しさん
19/06/19 21:36:29.32 4D/OEXM7.net
いいとこ取りというよりはその時々で模倣可能な機能が徐々に実用化されてずいぶん近づいている
例えばホットスワップとかデバッグ中のコード変更とか
で、後者とかは実行中コンテクストの保持まではまだ模倣できてないとか
852:デフォルトの名無しさん
19/06/20 07:43:12.86 Hk9POxiz.net
このスレタイは「この世は飛行機も自動車も不要！北海道から沖縄までは徒歩で十分！」
みたいに見えるんだがｗ
853:デフォルトの名無しさん
19/06/21 00:58:24.91 o+wFNqi2.net
>>852
墜落した飛行機
854:デフォルトの名無しさん
19/06/22 07:44:30.13 hOohrwXi.net
このスレはC++でオブジェクト指向に挫折したじいさんが
「オブジェクト指向なんてゴミだね！」って喚いて回ってたら
周り中から「あんなもん真のオブジェクト指向じゃねぇよアホw」ってツッコミまくられて
今度は「よくわからないけど“真のオブジェクト指向”ってのがゴミなんだろ！」って
暗闇に向かって手を振り回してみたら敵に当たるだろう！ってスレなんで…