16/07/22 01:30:33.86 znBq8w6k.net
>>407
俺の言いたいことはそういうことじゃなくて
ローレベルな世界ではその言語固有のオブジェクトになってない
単なるメモリブロック、データ、信号を扱わなきゃならない場面が多いんだよ
それはファイルから読み込まれるかもしれないし
ネットワーク越しにやってくるかもしれないし
ディバイスとのやり取りかもしれないし
ま、要するに単なるデータ
Cはメモリモデルがシンプルだからこういった単なるメモリブロックを扱うのに
長けているんだよ
構造体にキャストするだけでそのまま扱えるから
今でもC言語が現場で活躍しているのはこれができるから
もしこういったことが出来なかったとしたら、C言語なんかとっくに滅んでいたに違いない
メモリブロックをキャストして構造体や配列としてアクセスできないとしたら
そんなC言語に価値なんかあるか？
その一点がすごいんだよ、マジセンスある、もしくは運が良かった
416:デフォルトの名無しさん
16/07/22 01:46:19.31 znBq8w6k.net
そして多くの言語が見落としがちな部分でもあったんだよ
オブジェクトにしなきゃならないっつってvtable持たせたり
動的にしなきゃならないと、メンバをオフセットではなくハッシュにしたり
どんどん賢い機能を盛り込んでさ
その点C言語の構造体や配列はフラットでむちゃくちゃシンプルな作り
適当なメモリブロックをキャストしても何の問題も起きない
仕様もシンプルで分かりきってる
417:デフォルトの名無しさん
16/07/22 02:02:58.97 znBq8w6k.net
別に必ずしも偉い機能を盛り込むのがダメと言っているわけじゃないよ
ただ、Cが何故か生き残っていて今でも使われ続けている原因はソレということ
C言語の用途と、うまい具合にマッチしてて、いい感じに生き残っている
418:デフォルトの名無しさん
16/07/22 03:13:29.97 7iYsigKa.net
だからなんだよ？
419:デフォルトの名無しさん
16/07/22 07:29:28.61 cZVknNWP.net
構造体の先頭メンバ以外のオフセットは規定されていない
まぁ、オフセットなのでメンバアクセスでどうとでもなるわけで
構造体が定義されたままメモリ上に存在していると考えているアホ
一般的なコンパイラなら定義通りだろうけど規定されていない
規定されていない規定されていない
420:デフォルトの名無しさん
16/07/22 08:09:11.54 +awE6fq0.net
構造体のメンバ間のパディングは未規定だけど、オフセットが未規定って言うのは
順番も入れ替わるって言ってるの？
421:デフォルトの名無しさん
16/07/22 09:35:29.96 +Z+w/IAX.net
簡単に入れ替わるさ。
わざわざ入れ替えないでねと指定するレベル
422:デフォルトの名無しさん
16/07/22 10:31:03.00 znBq8w6k.net
構造体のメンバの順番が入れ替わらないのは仕様で決まっているよ
決まってないのは間に入る詰め物だけ
URLﾘﾝｸ(portable-c.jugem.jp)
しかし、詰め物をどうするか、指定できるコンパイラがほとんどだから
実質的に詰め物も問題にならない
C言語プログラマーは自分の使っているコンパイラの仕様ぐらい分かって使っているからね
問題になるとすればエンディアンぐらい
423:デフォルトの名無しさん
16/07/22 12:25:18.70 TIRA9iEO.net
JIS規格だろそれ。。。
424:デフォルトの名無しさん
16/07/22 13:24:25.19 +Z+w/IAX.net
intのサイズがアーキ依存だから通信に構造体は使うなってのが常識だけどな。
425:デフォルトの名無しさん
16/07/22 13:25:41.52 +Z+w/IAX.net
ネイティヴアメリカンの件もあるしな。
426:デフォルトの名無しさん
16/07/22 19:29:05.65 5OURMCtc.net
cはメモリは意識するがレジスタは隠蔽するって落とし所がよかったんじゃない。
427:デフォルトの名無しさん
16/07/22 19:41:14.28 jv7yTJni.net
Cはパーサが複雑なのとゼロコストで導入できる便利機能が無いのを除けば悪くはない
428:デフォルトの名無しさん
16/07/22 22:14:58.88 Oi2oQZIZ.net
cの最大の失敗は波カッコ
ブロックのスコープがパイソン風だったら人類は1世紀以上先の進んでいた
429:デフォルトの名無しさん
16/07/23 00:49:12.76 KFsxU+fY.net
代入演算子=と比較演算子==だけは許されざるよ。
つうか、IDEのサジェスチョン機能実装前の
"タイプ数が減る云々"な言語はすべて滅ぶべし。
430:デフォルトの名無しさん
16/07/23 01:22:33.59 tWjtYIW6.net
C言語は特徴ある機能で生き残ることができた。
だけそのその特徴ある機能がなかったら生き残れないのか？というと
そうではない。現にその特徴ある機能がない言語ばかりだからだ。
ここから言えることは、なにもない言語は消え行く定めだが、
C言語の機能がなくとも、それに上回る機能があれば生き残るということだ。
431:デフォルトの名無しさん
16/07/23 01:27:50.24 tWjtYIW6.net
>>429
IDEを使うことでタイプ数が減る機能はどうでもいいんだよね。
どうでもいいというのは、タイプ数が多くても少なくても
さほど違いはないということ。
重要なのはタイプ数じゃなくて読む文字数だから。
ただしタイプした文字数＝読む文字数ではないということ。
どういうことかというと、人間は文章を読むとき
読み飛ばしをするということ。
例えばJavaでいうimportやMainクラス定義なんかは
読み飛ばす部分。だからそんなところで読む数の違いは出てこない。
また型定義は読むところではあるが、型定義だけを読むことで
型を理解できると言うメリットが有る。
これは型が書かれていないコードから、型を解析する
作業よりも読む文字数は少なくなる。
432:デフォルトの名無しさん
16/07/23 18:21:41.45 6yKmk1QH.net
代入演算子は要らなかった
433:デフォルトの名無しさん
16/07/23 23:13:50.14 7iusE9pH.net
代入は文であって値を持つべきでないと？
434:デフォルトの名無しさん
16/07/23 23:53:23.87 zx6tBrAB.net
愚か者めが
435:デフォルトの名無しさん
16/07/24 07:03:52.43 L1GkLU8N.net
Cが生まれた時代はな
シンタクスハイライトどころか下手すると
スクリーンエディタ(ｷﾘｯ カットアンドペースト(ｷﾘｯ
すら高価な機能だったんやで
436:デフォルトの名無しさん
16/07/26 15:33:00.26 ka5+GTWz.net
テキストエディタが数万円してからな
437:デフォルトの名無しさん
16/07/26 16:33:02.33 dc6Ut+6F.net
Cが生まれた頃にはまだコピー＆ペーストはなかったぞ。
438:デフォルトの名無しさん
16/07/26 16:39:32.99 qFADw225.net
最初のクリップボードはAltoかな
Cが1972年でAltoが1973年
439:デフォルトの名無しさん
16/07/26 16:42:33.79 P0pX8+u1.net
>>430
で、その、この先生きのこるのはどの言語！
440:デフォルトの名無しさん
16/07/26 17:29:32.48 XfeIwbpB.net
アセンブラ C Fortran Lisp の古代言語
Javascript COBOL Python
HTML PHP はなんだかんだ言って生き残るんだろな～
あとは Java がどうなるかな
441:デフォルトの名無しさん
16/07/26 21:54:04.74 8mWO7mKy.net
言語じゃないというのはナンセンスか
442:デフォルトの名無しさん
16/07/26 22:19:28.08 3gO7Ljql.net
お前ら、テーマに戻れや。
なぜオブジェクト指向は愚かな考えなんだ？
443:デフォルトの名無しさん
16/07/26 22:55:12.03 wvFbwXsy.net
愚かな設計が蔓延してるってことだな
444:デフォルトの名無しさん
16/07/26 22:55:59.68 wvFbwXsy.net
>>4
これがすべてじゃないの？
445:デフォルトの名無しさん
16/07/26 23:00:24.73 wvFbwXsy.net
初期設計を少しでも間違えたり手抜きしたら
そのシステムの成長絶望的になり死ぬ
446:デフォルトの名無しさん
16/07/27 02:09:24.84 gQfYvWZ4.net
>>444
そして>>41-42で完全に解説完了
ジョークとしてわざとオブジェクト指向として間違ったプログラム例だしてるってのに
「この通りオブジェクト指向は直感に反して～」じゃねぇっつのw
447:デフォルトの名無しさん
16/07/27 02:12:13.92 gQfYvWZ4.net
>>440
Javaは普及してるから残るだろうなぁ
なんか、いつものベストじゃないけど普及したから
ベターとして残るというプログラム史のいつもの展開というか。
448:デフォルトの名無しさん
16/07/27 06:54:54.29 cUWSkWnI.net
問題はそういうジョークを本気にする人が多すぎるってことだろうに。
つまりオブジェクト指向ってのは一般にコンセンサスをとりずらい概念なんだよ。
449:デフォルトの名無しさん
16/07/27 06:58:14.97 LCC7iz/I.net
おまえ等の好きそうなネタ見つけた
オブジェクト指向で料理を例える場合，chicken.cut()かchef.cut()か
URLﾘﾝｸ(teratail.com)
450:デフォルトの名無しさん
16/07/27 07:29:08.70 mL4CmQKe.net
>>446
コーヒーの例は単純明快だからいいけど、美少女は実際に正しく設計できるやつが日本に何人いるかってレベルだろうな
451:デフォルトの名無しさん
16/07/27 07:30:19.55 +Qq3g4cQ.net
>>448
これをジョークだと思って実戦に挑む奴がデスマーチを引き起こす
452:デフォルトの名無しさん
16/07/27 07:32:08.18 iBdKVqyS.net
基底に近いほど修正しづらいのは事実
453:デフォルトの名無しさん
16/07/27 07:33:05.82 8lCNqFHq.net
>>451
ほんとこれ
454:デフォルトの名無しさん
16/07/27 09:54:15.05 8yC4YC1p.net
>>449
tokage.cut()
455:デフォルトの名無しさん
16/07/27 12:23:59.26 mW7SlT40.net
くだらん与太話はこれくらいにしてそろそろ全力でウンコ美少女問題に取り組むか
456:デフォルトの名無しさん
16/07/27 17:21:14.58 8Owc4Qqf.net
ウンコしない美少女は偶像
つまり人間からの派生ではない
457:デフォルトの名無しさん
16/07/27 17:58:49.99 CvwlEFOq.net
なんか、いっつも同じレベルの書き込みするから
自演になってないって自覚しとる？きみ。
458:デフォルトの名無しさん
16/07/27 19:55:41.64 9bIrtjQt.net
ユーザーはうんこなんて機能は求めて無いから削除しろよと
459:デフォルトの名無しさん
16/07/27 20:16:04.55 YbwWr11d.net
人間がウンコするのは、
ユーザーが求めているからなのか？
460:デフォルトの名無しさん
16/07/27 20:21:12.98 9bIrtjQt.net
ソフトの機能に不要な要素まで組み入れても誰も買わないだろ。
現実の要素を完全に網羅する必要は無いから
461:デフォルトの名無しさん
16/07/27 21:23:16.38 dkELqw5/.net
それは当たり前のことではあるな
必要な要素だけ実装すればよいからな
Humanクラスがどういった要素を持つかは案件によるし
もし人の持つすべての機能をHumanクラスに実装できるっていうんなら
そのHumanクラスにプログラムも書いてもらえばよい
よって現実の人間がうんこをするからと言って
必ずしもHumanクラスにうんこをする機能が必要かどうかはわからないし
必要な案件に出会ってから美少女クラスのうんこの扱いについて考えればよい
462:デフォルトの名無しさん
16/07/27 21:50:52.30 eu5RKOJ4.net
要件で一言も触れてないのに「はぁ？○○はあって当然だろ」とか言い出す顧客しかいないから
想像できるものは全て詰め込んでおく必要がある。
ウンコだろうとゲロだろうと例外はない。
463:デフォルトの名無しさん
16/07/27 22:27:39.20 YbwWr11d.net
肝心なことを決めずに作り込んでいく。
美少女クラスのスーパークラスは人間クラスである。
排便メソッドは関係ないからそれでいい。
だが、ある時ユーザーからの要望で人間クラスに排便メソッドを作った。
人間だもの、当たり前だ。
それでいいと思った。その時がくるまでは。
ある時私は気がついた。
これだと美少女が排便すると www
464:デフォルトの名無しさん
16/07/27 22:41:58.99 60oYSks+.net
このスレ的にはgo言語とかD言語のダックタイピングってどうなん？
465:デフォルトの名無しさん
16/07/27 22:47:49.85 rlINsgdh.net
ダックタイピング
由来
アヒルのの鳴きマネをする人間はアヒルに違いない
466:デフォルトの名無しさん
16/07/28 00:19:19.54 c5ty+8F5.net
ダッチワイフィング
由来
オランダの人妻はエロいに違いない
467:デフォルトの名無しさん
16/07/28 00:47:19.73 6VZFO4sX.net
オブジェクト指向は幻想
468:デフォルトの名無しさん
16/07/28 00:48:34.40 /rI5OmsP.net
COBOLからJavaへの移行で「実際に」成功した案件は存在しない
469:デフォルトの名無しさん
16/07/28 00:49:15.93 LhM4XtYR.net
細胞から実装しろ
470:デフォルトの名無しさん
16/07/28 00:49:41.59 OYshXAPi.net
元素から実装しろ
471:デフォルトの名無しさん
16/07/28 01:51:28.53 y7xhJAs5.net
>>468
COBOLって単なる言語じゃなくて運用まで含めたシステムの総称だからな。かなうわけがない
とは言え、高賃金のCOBOLプログラマーもいずれ死に絶えるわけでなんとかしないといけないんだけどさ
Adaなんか勉強して損した
472:デフォルトの名無しさん
16/07/29 12:00:06.26 TRgFQe5b.net
Ocamlならあるいは
473:デフォルトの名無しさん
16/07/29 18:48:09.16 POEPtDrt.net
ないない
そもそもCが小文字の時点で語る資格なし
474:デフォルトの名無しさん
16/07/30 00:08:52.44 lNYXBi4+.net
ならScalaでスイス銀行の例もあるし？
475:デフォルトの名無しさん
16/07/30 00:35:24.99 gkAo/Cig.net
具体的に
476:デフォルトの名無しさん
16/07/30 15:22:29.13 OSfj7rnr.net
オブジェクト指向を考え出した人間もオブジェクト指向の解釈を誤っていたのではないか
クラスというのは人間が直感的に思い描く世界の事物をプログラムコードにマップする手段ではなくて、
プロセスという大きなチューリングマシンの中の小さなチューリングマシンを記述する手段にすぎなかった
（チューリング完全性の利用例の一つだった
クラスのコンストラクタは状態機械であるところのチューリングマシンの初期化と生存期間の始まりに相当する
デストラクタは後始末と生存期間の終わり。
メソッドはチューリングマシンにlive timeを与え、計算を進めさせる。
そんだけ
状態（mutableなデータ）を含むから関数型プログラミングとは似て非なるものだし、
数学的にカタをつけるにはチューリングマシンの一変種で無限長の磁気テープをクラスで小分けにしたもの、
としか言い様が無い
477:デフォルトの名無しさん
16/07/30 15:46:36.80 OSfj7rnr.net
こう考えると継承のしくみを使ったプログラミングが
ごく一部のデザインパターンにおいてしか成功しないことも理解できる
継承というしくみのは人間が「こうだったらｲｲなあ…」と思い描いて作っただけで、
>>476な解釈からは必然性が出てこない
つまり継承というしくみは論理的妥当性を欠いており、
継承を下手に使ったらあちこちで矛盾が生じて話が発散していく傾向なのも仕方が無い
478:デフォルトの名無しさん
16/07/30 18:44:13.74 TLvR+07H.net
だいたいプログラミング業界って、
新しいものが導入される
→古いものはやめてこれ使いましょう
→新しいものも色々問題があることが分かってくる
→極力使わないようにしましょう
の繰り返しだからな。継承しかり例外しかり。
最近はテンプレート使いすぎなんじゃねーのって思うけど。
479:デフォルトの名無しさん
16/07/30 19:01:15.21 TM2kAcv9.net
> 継承しかり例外しかり。
継承も例外も極力使わないようにしましょうなんて
誰も言ってないが？
間違った使い方が明らかになって、
間違った使い方をしないで
正しい使い方をしましょう。
っていう結論ならばいつもそうなっている。
継承しかり例外しかり。
480:デフォルトの名無しさん
16/07/30 19:38:58.24 XUUv9y4D.net
結局、人間クラスと美少女クラスは
どうすればいいんだ？
481:デフォルトの名無しさん
16/07/30 20:02:32.96 TLvR+07H.net
>>479
正しく使おうってのは常に真だから内容が無いのと同じだな。
できるだけ使わないようにって風潮はある。程度の差はあれgotoとかと同じ。
482:デフォルトの名無しさん
16/07/30 20:08:02.92 OEu/5F3U.net
javaはオラクルがVMを提供しなくなったら
廃れるだろ。
483:デフォルトの名無しさん
16/07/30 21:52:18.63 NYI5chEQ.net
>>479
結局、言語の問題よりも馬鹿を入れない事のが重要ってことだろ。
そういう意味じゃ linus のやり方は正しいってことになる。
484:デフォルトの名無しさん
16/07/30 22:13:41.04 TM2kAcv9.net
>>481
> できるだけ使わないようにって風潮はある。
無いよそんなのｗｗｗ
アルアル言っていても、
嘘がホントになったりしないアルよ～ｗ
485:デフォルトの名無しさん
16/07/30 22:18:10.45 OSfj7rnr.net
（定義が論理的に妥当でなかったりあいまいだったりするとお議論が紛糾する例
486:デフォルトの名無しさん
16/07/30 22:23:44.57 3WJAVcau.net
多少コピペが多くなっても継承をむやみに使ってはいけない場面ってのは想定しなきゃなぁ
487:デフォルトの名無しさん
16/07/30 22:38:52.82 TM2kAcv9.net
なんで継承をやめたらコピペが多くなるのかそれがわからんｗ
正しく継承使うといういうのは、
継承以外の方法を使うべきときに、違う方法を使うという意味であって、
ならばその違う方法で、コピペを回避すれば良いんだよ。
488:デフォルトの名無しさん
16/07/30 22:44:09.77 XUUv9y4D.net
委譲を使えばいいんだろ。
肛門クラスを作って、
人間クラスと美少女クラスのプロパティに肛門インスタンスを持てばいいんだ。
排便できる肛門と出来ない肛門と。
489:デフォルトの名無しさん
16/07/30 23:06:52.83 FiK/AfbE.net
コーデングテクニックでごまかすのはアカンね
そーゆーことするから所謂ひとつのスパゲッテイー的ソースコードが出来上がるんや
デザインの問題はデザインで解決出来な一生炎上商法プログラマーのまんまやで
490:デフォルトの名無しさん
16/07/30 23:38:21.39 3WJAVcau.net
>>487
ミックスインの手法が確立されてないってことは、継承が害悪になる場面ってのはあるんだよ。
そういう場合は、下に書かれてる通り、コンポーネント的な設計が必要。
そういう時に、コンストラクタでコピペが必要ってこと。
491:デフォルトの名無しさん
16/07/30 23:41:35.20 3WJAVcau.net
そうするとインタフェースの定義が必要になってくるから、結局継承が楽だし、よほどのことじゃなければそれで済ませるんだけどね
492:デフォルトの名無しさん
16/07/31 00:01:52.81 VGavY/X3.net
if文ですべて解決できるんじゃね
493:デフォルトの名無しさん
16/07/31 00:35:50.52 UuqrLdJE.net
だから、委譲というか、
デリゲート使えっていうか。
494:デフォルトの名無しさん
16/07/31 01:44:59.39 LD4Pss8J.net
ほんと最近、is-a関係、has-a関係っていうの
軽視されてるよな。
is-aのときに継承すれば良いんだって
昔から言われてるんだが。
これは古い概念じゃないぞｗ
495:デフォルトの名無しさん
16/07/31 03:56:26.93 Wl4/o5Bb.net
フリーザは美少女クラスのis-a関係
496:デフォルトの名無しさん
16/07/31 09:04:47.96 xuMLlix3.net
>>494
is-a関係は一般に存在しない
例外なのは同値関係と包含関係が数学的に定義できて無矛盾性が担保された
（＝直接証明されたか、より一般的な体系の無矛盾性に帰着できる）ケースだけだが
そんなのはｽｹﾞｰまれ
いっぱいあると感じるのは錯覚
不用意にis-a関係を導入することでクラス分けにあいまいさが紛れ込み、
プログラムの設計とか簡単に壊滅する
497:デフォルトの名無しさん
16/07/31 09:09:00.42 xuMLlix3.net
その点ha-a関係はやりやすいなぜなら単なる集約であって分類が絡まないから
has-a関係の導入自体が矛盾を生じることは無いからだ
498:デフォルトの名無しさん
16/07/31 09:36:24.74 tLh0Iyun.net
is-a関係だと思っているものは全てhas-aとしても実装できる。
概念系統が複数ある場合、is-aでは多重継承もしくは、
全ての組み合わせの派生クラスを定義することが必要だが、
has-aではそういう問題は無く柔軟に設計できる。
499:デフォルトの名無しさん
16/07/31 09:41:31.16 /E3bqgob.net
OO使わない場合に
フラグとかカウンタとかステータスってのをどう管理するのかを
単刀直入に知りたい。
関数型なんかでもこの辺がよくわからない
（消せるはずはないから何か別の概念などで整理・管理されるんだとは思うけど）
500:デフォルトの名無しさん
16/07/31 09:46:59.05 tLh0Iyun.net
>>499
普通の構造体でいいのでは？（Cでいうところの）
501:デフォルトの名無しさん
16/07/31 09:59:49.33 p/Oh4nGe.net
>>499
そこでクロージャですよ
502:デフォルトの名無しさん
16/07/31 10:00:24.80 P4D/j0eN.net
is-a だったらliskov置換原則の方が理解し易いし、コード書くときの指針になる。
503:デフォルトの名無しさん
16/07/31 10:09:28.04 xuMLlix3.net
ちなステータスというのは大概I/Oを通じて外界と繋がっている事物の結果を意味し、
実時間軸上でうつろうもの（mutableなﾌﾞﾂ）なので厳密には関数型プログラミングに存在し得ない概念
関数型プログラミングでは「1」を返す関数と、和を返す関数から「1」+「1」=「2」という演繹ステップを経て
「2」を返す関数を作る、というように演繹ステップとしての時間経過しか扱わない
これでどうやって実時間で動くシステムをプログラムするのかというと、
演繹ステップの順序と実時間軸上の物事の変化順序が一致するように関数を設計してやって、
擬似的に演繹順序を実時間軸上の順序と合わせてそれっぽい動きを実現しているわけや
例えばHDDのエラーステータスとか、昨日のステータスに対し今日のステータスが変化した、と捉えるのではなしに、
「HDDの昨日のステータス」を返す関数と、ステータスの適切な処理に対応する何がしかを返す関数とから
「HDDの今日のステータス」に対する処理に対応する何がしかを返す関数を生成する
ことでHDDの今日のステータスを処理する
504:デフォルトの名無しさん
16/07/31 11:53:00.79 LD4Pss8J.net
>>494
女は一般に存在しない
いっぱいあると感じるのは錯覚
って言ってるようなもんだなｗ
一般に存在しないというのなら
存在しないと言う根拠を書け
505:デフォルトの名無しさん
16/07/31 13:06:04.94 xuMLlix3.net
>>504
is-a関係は一般には存在しないと書いたのじゃ
例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう
また、なんで女クラスの派生クラスが妻クラスではいけないのか？その根拠を目下人類は手にしていない
はい論破
ちな、有限集合に関しては無矛盾性は常に証明できるから別に
女クラス←妻クラス
でも
妻クラス←女クラス
でも良いが、有限のケースしか想定しないんならswitch文で良いやという話で
オブジェクト指向の出る必然性がかなり減る
あくまで無限集合としてのクラスXを今数学的に正しく定義付けできるか？（X=妻 or 女 or so on）というのが問題
506:デフォルトの名無しさん
16/07/31 15:57:24.63 Wl4/o5Bb.net
is-aかどうかなんて抽象的すぎて判断の材料になんないよな。
何を持ってしてis-aとするかが大事なんだけど、そこをきちんと答えられる人は少ない。
507:デフォルトの名無しさん
16/07/31 15:58:19.37 JthY0EmQ.net
>>505
そりゃ妻のような一時的な属性に過ぎないものををクラス化するのがそもそも間違ってる
同性婚以前に結婚離婚で既に破綻してるじゃないか
例が悪いので説明になってない、やり直し
508:デフォルトの名無しさん
16/07/31 16:07:11.65 Wl4/o5Bb.net
>>507
男も改造すれば女になりうるから、男クラスのインスタンスを作ると、参照を維持したまま女クラスに変身できない。
だから、is-aなんてものは、性転換をしないという契約がなければなりたたない。
契約をしてないのにis-aなんて言いきれる訳ない。
509:デフォルトの名無しさん
16/07/31 16:07:23.65 kxVM21o1.net
妻とか女とか、単なる属性をクラスにするからワケが分からなくなる。
510:デフォルトの名無しさん
16/07/31 16:27:16.51 iFqDH3lg.net
いいから、肛門クラスを作って
デリケートしろ！
511:デフォルトの名無しさん
16/07/31 16:35:53.61 Wl4/o5Bb.net
口に肛門つけてください。
しゃべれるしうんこできるし便利だと思うんです。
512:デフォルトの名無しさん
16/07/31 21:22:59.29 XDiDpvFC.net
話についていけない子が
必死で面白レスしようとするのが悲痛
人間の悲しみが透けて見える
513:デフォルトの名無しさん
16/08/01 00:44:08.60 E1waX2Jm.net
>>505
> 例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう
ならないなｗ
お前設計がおかしいよ。
妻をクラスするって発想がそもそも
キチガイじみてる。
514:デフォルトの名無しさん
16/08/01 00:46:25.46 E1waX2Jm.net
普通は性別は属性だよなｗ
人クラスがあって、名前・年齢・性別
ほら属性だ。
そのうち佐藤クラスを作るとか言いそうだｗｗｗｗ
515:デフォルトの名無しさん
16/08/01 00:52:22.69 E1waX2Jm.net
is-a関係っていうのは必要条件であって十分条件じゃないんだがｗ
is-aになっていれば必ず継承関係にあるってことじゃない。
継承しようと思ったとき、is-a関係を満たしていなければいけないって話だ。
516:デフォルトの名無しさん
16/08/01 01:01:45.57 8BzY1j1Y.net
オブジェクト指向ってどこで間違ったんだろう
途中までは良い線行ってたと思うんだけど、どこからか使いものにならなくなったよね
517:デフォルトの名無しさん
16/08/01 01:04:20.06 E1waX2Jm.net
オブジェクト指向が使われてない
フレームワークなんて無いんだが？
使い物にならなくなったという考えがそもそも間違いだな。
まあ「使い物にならなくなった」と言い続けることで
他の人に事実だと錯覚させようとする手段ニダ？ｗ
518:デフォルトの名無しさん
16/08/01 01:06:05.40 fJ4xvUon.net
だから、継承捨てて委譲を使えっての！
519:デフォルトの名無しさん
16/08/01 01:41:20.92 C6PCKyxq.net
>>517 本当にオブジェクト指向が必要だから使っているのか、
抽象化の手段がオブジェクト指向しか無いから使わざるをえないのか
昨今の言語なら継承以外の方法で抽象化とか再利用とかできたりする
OOは本当に最小限にして、late bindingやメッセージパッシングの妙を際立たせるとより効果的
Real World OCamlだとヘテロな型を持つ木構造を探索するのに使ってたりしたな
520:デフォルトの名無しさん
16/08/01 01:41:37.76 E1waX2Jm.net
継承捨てて委譲を使えっていうのは
マイクロソフト用語でコンポーネント指向っていうんだが、
これを意図的に取り入れたのが2000年前後に使われていたVB6なんだよな。
そのVB6も.NETになってから継承をサポートしたし、
コンポーネント指向だけではだめだということだろう。
521:デフォルトの名無しさん
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～と続いてるメッセージ/メソッド方式
目的はクラスの独立
もっと進んで命令すればクラスが自分でデータや仕事探すぐらいになるだろ？
というエージェント指向はまだ実現していない。