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

**デフォルトの名無しさん転載ダメ©2ch.net** · 2016/01/05(火) 02:10:25.72

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

研究グループは、血管新生注において血管が伸長する際の血管内皮細胞注運動を制御するしくみを、生物学と数理モデル・
コンピュータシミュレーションを融合させた先端的な研究手法により明らかにしました。

生物は、最小の機能単位である細胞が寄り集まった多細胞体です。しかし、細胞の集まりが、組織や器官といった
秩序ある形態や構造をつくり機能するしくみはほとんど分かっていません。中でも血管は、体中の全組織に十分な
酸素や栄養源を効率よく供給するため、組織や組織の間に入り込み、血管外の環境との相互作用により、巧妙な
枝分かれ構造をとっています。

これまでに本研究グループは、新しく血管がつくられる（血管新生）際の細胞の動きに着目し、特に血管内皮細胞の
動きをリアルタイムで可視化し、定量的に捉えることを可能にしてきました。

今回さらに、血管の伸長を制御するしくみについて、細胞が自発的に自らを制御して動く過程（自律的過程）と、
隣接した細胞から適宜影響を受けて動く過程（協調的過程）がうまく共存することで、全体の動きが巧みに統制
されていることを世界に先駆けて実証しました。

興味深いことに、血管内皮細胞が前後したり、お互いに追い抜きあったりという血管新生で見られる複雑な細胞集団の
動きを制御している中枢部分は、細胞一つ一つの動き（スピードと方向性）の「確率的な変化」として十分説明できる
ことをコンピュータシミュレーションで実証しました。
http://www.jst.go.jp/pr/announce/20151120-2/#YOUGO3

前スレ
オブジェクト指向は愚かな考え。この世は計算式 ★2
http://peace.2ch.net/test/read.cgi/tech/1450153388/

**デフォルトの名無しさん** · 2016/07/27(水) 17:21:14.58

ウンコしない美少女は偶像
つまり人間からの派生ではない

**デフォルトの名無しさん** · 2016/07/27(水) 17:58:49.99

なんか、いっつも同じレベルの書き込みするから
自演になってないって自覚しとる？きみ。

**デフォルトの名無しさん** · 2016/07/27(水) 19:55:41.64

ユーザーはうんこなんて機能は求めて無いから削除しろよと

**デフォルトの名無しさん** · 2016/07/27(水) 20:16:04.55

人間がウンコするのは、
ユーザーが求めているからなのか？

**デフォルトの名無しさん** · 2016/07/27(水) 20:21:12.98

ソフトの機能に不要な要素まで組み入れても誰も買わないだろ。
現実の要素を完全に網羅する必要は無いから

**デフォルトの名無しさん** · 2016/07/27(水) 21:23:16.38

それは当たり前のことではあるな
必要な要素だけ実装すればよいからな
Humanクラスがどういった要素を持つかは案件によるし
もし人の持つすべての機能をHumanクラスに実装できるっていうんなら
そのHumanクラスにプログラムも書いてもらえばよい

よって現実の人間がうんこをするからと言って
必ずしもHumanクラスにうんこをする機能が必要かどうかはわからないし
必要な案件に出会ってから美少女クラスのうんこの扱いについて考えればよい

**デフォルトの名無しさん** · 2016/07/27(水) 21:50:52.30

要件で一言も触れてないのに「はぁ？○○はあって当然だろ」とか言い出す顧客しかいないから
想像できるものは全て詰め込んでおく必要がある。
ウンコだろうとゲロだろうと例外はない。

**デフォルトの名無しさん** · 2016/07/27(水) 22:27:39.20

肝心なことを決めずに作り込んでいく。
美少女クラスのスーパークラスは人間クラスである。
排便メソッドは関係ないからそれでいい。
だが、ある時ユーザーからの要望で人間クラスに排便メソッドを作った。
人間だもの、当たり前だ。
それでいいと思った。その時がくるまでは。
ある時私は気がついた。
これだと美少女が排便すると www

**デフォルトの名無しさん** · 2016/07/27(水) 22:41:58.99

このスレ的にはgo言語とかD言語のダックタイピングってどうなん？

**デフォルトの名無しさん** · 2016/07/27(水) 22:47:49.85

ダックタイピング

由来

アヒルのの鳴きマネをする人間はアヒルに違いない

**デフォルトの名無しさん** · 2016/07/28(木) 00:19:19.54

ダッチワイフィング

由来

オランダの人妻はエロいに違いない

**デフォルトの名無しさん** · 2016/07/28(木) 00:47:19.73

オブジェクト指向は幻想

**デフォルトの名無しさん** · 2016/07/28(木) 00:48:34.40

COBOLからJavaへの移行で「実際に」成功した案件は存在しない

**デフォルトの名無しさん** · 2016/07/28(木) 00:49:15.93

細胞から実装しろ

**デフォルトの名無しさん** · 2016/07/28(木) 00:49:41.59

元素から実装しろ

**デフォルトの名無しさん** · 2016/07/28(木) 01:51:28.53

>>468
COBOLって単なる言語じゃなくて運用まで含めたシステムの総称だからな。かなうわけがない
とは言え、高賃金のCOBOLプログラマーもいずれ死に絶えるわけでなんとかしないといけないんだけどさ
Adaなんか勉強して損した

**デフォルトの名無しさん** · 2016/07/29(金) 12:00:06.26

Ocamlならあるいは

**デフォルトの名無しさん** · 2016/07/29(金) 18:48:09.16

ないない
そもそもCが小文字の時点で語る資格なし

**デフォルトの名無しさん** · 2016/07/30(土) 00:08:52.44

ならScalaでスイス銀行の例もあるし？

**デフォルトの名無しさん** · 2016/07/30(土) 00:35:24.99

具体的に

**デフォルトの名無しさん** · 2016/07/30(土) 15:22:29.13

オブジェクト指向を考え出した人間もオブジェクト指向の解釈を誤っていたのではないか
クラスというのは人間が直感的に思い描く世界の事物をプログラムコードにマップする手段ではなくて、
プロセスという大きなチューリングマシンの中の小さなチューリングマシンを記述する手段にすぎなかった
（チューリング完全性の利用例の一つだった

クラスのコンストラクタは状態機械であるところのチューリングマシンの初期化と生存期間の始まりに相当する
デストラクタは後始末と生存期間の終わり。
メソッドはチューリングマシンにlive timeを与え、計算を進めさせる。
そんだけ

状態（mutableなデータ）を含むから関数型プログラミングとは似て非なるものだし、
数学的にカタをつけるにはチューリングマシンの一変種で無限長の磁気テープをクラスで小分けにしたもの、
としか言い様が無い

**デフォルトの名無しさん** · 2016/07/30(土) 15:46:36.80

こう考えると継承のしくみを使ったプログラミングが
ごく一部のデザインパターンにおいてしか成功しないことも理解できる
継承というしくみのは人間が「こうだったらｲｲなあ…」と思い描いて作っただけで、
>>476な解釈からは必然性が出てこない
つまり継承というしくみは論理的妥当性を欠いており、
継承を下手に使ったらあちこちで矛盾が生じて話が発散していく傾向なのも仕方が無い

**デフォルトの名無しさん** · 2016/07/30(土) 18:44:13.74

だいたいプログラミング業界って、

新しいものが導入される
→古いものはやめてこれ使いましょう
→新しいものも色々問題があることが分かってくる
→極力使わないようにしましょう

の繰り返しだからな。継承しかり例外しかり。
最近はテンプレート使いすぎなんじゃねーのって思うけど。

**デフォルトの名無しさん** · 2016/07/30(土) 19:01:15.21

> 継承しかり例外しかり。
継承も例外も極力使わないようにしましょうなんて
誰も言ってないが？

間違った使い方が明らかになって、
間違った使い方をしないで
正しい使い方をしましょう。

っていう結論ならばいつもそうなっている。
継承しかり例外しかり。

**デフォルトの名無しさん** · 2016/07/30(土) 19:38:58.24

結局、人間クラスと美少女クラスは
どうすればいいんだ？

**デフォルトの名無しさん** · 2016/07/30(土) 20:02:32.96

>>479
正しく使おうってのは常に真だから内容が無いのと同じだな。
できるだけ使わないようにって風潮はある。程度の差はあれgotoとかと同じ。

**デフォルトの名無しさん** · 2016/07/30(土) 20:08:02.92

javaはオラクルがVMを提供しなくなったら
廃れるだろ。

**デフォルトの名無しさん** · 2016/07/30(土) 21:52:18.63

>>479
結局、言語の問題よりも馬鹿を入れない事のが重要ってことだろ。
そういう意味じゃ linus のやり方は正しいってことになる。

**デフォルトの名無しさん** · 2016/07/30(土) 22:13:41.04

>>481
> できるだけ使わないようにって風潮はある。
無いよそんなのｗｗｗ

アルアル言っていても、
嘘がホントになったりしないアルよ～ｗ

**デフォルトの名無しさん** · 2016/07/30(土) 22:18:10.45

（定義が論理的に妥当でなかったりあいまいだったりするとお議論が紛糾する例

**デフォルトの名無しさん** · 2016/07/30(土) 22:23:44.57

多少コピペが多くなっても継承をむやみに使ってはいけない場面ってのは想定しなきゃなぁ

**デフォルトの名無しさん** · 2016/07/30(土) 22:38:52.82

なんで継承をやめたらコピペが多くなるのかそれがわからんｗ

正しく継承使うといういうのは、
継承以外の方法を使うべきときに、違う方法を使うという意味であって、
ならばその違う方法で、コピペを回避すれば良いんだよ。

**デフォルトの名無しさん** · 2016/07/30(土) 22:44:09.77

委譲を使えばいいんだろ。
肛門クラスを作って、
人間クラスと美少女クラスのプロパティに肛門インスタンスを持てばいいんだ。
排便できる肛門と出来ない肛門と。

**デフォルトの名無しさん** · 2016/07/30(土) 23:06:52.83

コーデングテクニックでごまかすのはアカンね
そーゆーことするから所謂ひとつのスパゲッテイー的ソースコードが出来上がるんや
デザインの問題はデザインで解決出来な一生炎上商法プログラマーのまんまやで

**デフォルトの名無しさん** · 2016/07/30(土) 23:38:21.39

>>487
ミックスインの手法が確立されてないってことは、継承が害悪になる場面ってのはあるんだよ。

そういう場合は、下に書かれてる通り、コンポーネント的な設計が必要。
そういう時に、コンストラクタでコピペが必要ってこと。

**デフォルトの名無しさん** · 2016/07/30(土) 23:41:35.20

そうするとインタフェースの定義が必要になってくるから、結局継承が楽だし、よほどのことじゃなければそれで済ませるんだけどね

**デフォルトの名無しさん** · 2016/07/31(日) 00:01:52.81

if文ですべて解決できるんじゃね

**デフォルトの名無しさん** · 2016/07/31(日) 00:35:50.52

だから、委譲というか、
デリゲート使えっていうか。

**デフォルトの名無しさん** · 2016/07/31(日) 01:44:59.39

ほんと最近、is-a関係、has-a関係っていうの
軽視されてるよな。

is-aのときに継承すれば良いんだって
昔から言われてるんだが。
これは古い概念じゃないぞｗ

**デフォルトの名無しさん** · 2016/07/31(日) 03:56:26.93

フリーザは美少女クラスのis-a関係

**デフォルトの名無しさん** · 2016/07/31(日) 09:04:47.96

>>494
is-a関係は一般に存在しない
例外なのは同値関係と包含関係が数学的に定義できて無矛盾性が担保された
（＝直接証明されたか、より一般的な体系の無矛盾性に帰着できる）ケースだけだが
そんなのはｽｹﾞｰまれ
いっぱいあると感じるのは錯覚

不用意にis-a関係を導入することでクラス分けにあいまいさが紛れ込み、
プログラムの設計とか簡単に壊滅する

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

その点ha-a関係はやりやすいなぜなら単なる集約であって分類が絡まないから
has-a関係の導入自体が矛盾を生じることは無いからだ

**デフォルトの名無しさん** · 2016/07/31(日) 09:36:24.74

is-a関係だと思っているものは全てhas-aとしても実装できる。

概念系統が複数ある場合、is-aでは多重継承もしくは、
全ての組み合わせの派生クラスを定義することが必要だが、
has-aではそういう問題は無く柔軟に設計できる。

**デフォルトの名無しさん** · 2016/07/31(日) 09:41:31.16

OO使わない場合に
フラグとかカウンタとかステータスってのをどう管理するのかを
単刀直入に知りたい。
関数型なんかでもこの辺がよくわからない
（消せるはずはないから何か別の概念などで整理・管理されるんだとは思うけど）

**デフォルトの名無しさん** · 2016/07/31(日) 09:46:59.05

>>499
普通の構造体でいいのでは？（Cでいうところの）

**デフォルトの名無しさん** · 2016/07/31(日) 09:59:49.33

>>499
そこでクロージャですよ

**デフォルトの名無しさん** · 2016/07/31(日) 10:00:24.80

is-a だったらliskov置換原則の方が理解し易いし、コード書くときの指針になる。

**デフォルトの名無しさん** · 2016/07/31(日) 10:09:28.04

ちなステータスというのは大概I/Oを通じて外界と繋がっている事物の結果を意味し、
実時間軸上でうつろうもの（mutableなﾌﾞﾂ）なので厳密には関数型プログラミングに存在し得ない概念

関数型プログラミングでは「1」を返す関数と、和を返す関数から「1」+「1」=「2」という演繹ステップを経て
「2」を返す関数を作る、というように演繹ステップとしての時間経過しか扱わない
これでどうやって実時間で動くシステムをプログラムするのかというと、
演繹ステップの順序と実時間軸上の物事の変化順序が一致するように関数を設計してやって、
擬似的に演繹順序を実時間軸上の順序と合わせてそれっぽい動きを実現しているわけや

例えばHDDのエラーステータスとか、昨日のステータスに対し今日のステータスが変化した、と捉えるのではなしに、
「HDDの昨日のステータス」を返す関数と、ステータスの適切な処理に対応する何がしかを返す関数とから
「HDDの今日のステータス」に対する処理に対応する何がしかを返す関数を生成する
ことでHDDの今日のステータスを処理する

**デフォルトの名無しさん** · 2016/07/31(日) 11:53:00.79

>>494
女は一般に存在しない
いっぱいあると感じるのは錯覚

って言ってるようなもんだなｗ

一般に存在しないというのなら
存在しないと言う根拠を書け

**デフォルトの名無しさん** · 2016/07/31(日) 13:06:04.94

>>504
is-a関係は一般には存在しないと書いたのじゃ
例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう
また、なんで女クラスの派生クラスが妻クラスではいけないのか？その根拠を目下人類は手にしていない
はい論破

ちな、有限集合に関しては無矛盾性は常に証明できるから別に
　女クラス←妻クラス
でも
　妻クラス←女クラス
でも良いが、有限のケースしか想定しないんならswitch文で良いやという話で
オブジェクト指向の出る必然性がかなり減る
あくまで無限集合としてのクラスXを今数学的に正しく定義付けできるか？（X=妻 or 女 or so on）というのが問題

**デフォルトの名無しさん** · 2016/07/31(日) 15:57:24.63

is-aかどうかなんて抽象的すぎて判断の材料になんないよな。

何を持ってしてis-aとするかが大事なんだけど、そこをきちんと答えられる人は少ない。

**デフォルトの名無しさん** · 2016/07/31(日) 15:58:19.37

>>505
そりゃ妻のような一時的な属性に過ぎないものををクラス化するのがそもそも間違ってる
同性婚以前に結婚離婚で既に破綻してるじゃないか
例が悪いので説明になってない、やり直し

**デフォルトの名無しさん** · 2016/07/31(日) 16:07:11.65

>>507
男も改造すれば女になりうるから、男クラスのインスタンスを作ると、参照を維持したまま女クラスに変身できない。

だから、is-aなんてものは、性転換をしないという契約がなければなりたたない。

契約をしてないのにis-aなんて言いきれる訳ない。

**デフォルトの名無しさん** · 2016/07/31(日) 16:07:23.65

妻とか女とか、単なる属性をクラスにするからワケが分からなくなる。

**デフォルトの名無しさん** · 2016/07/31(日) 16:27:16.51

いいから、肛門クラスを作って
デリケートしろ！

**デフォルトの名無しさん** · 2016/07/31(日) 16:35:53.61

口に肛門つけてください。
しゃべれるしうんこできるし便利だと思うんです。

**デフォルトの名無しさん** · 2016/07/31(日) 21:22:59.29

話についていけない子が
必死で面白レスしようとするのが悲痛
人間の悲しみが透けて見える

**デフォルトの名無しさん** · 2016/08/01(月) 00:44:08.60

>>505
> 例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう

ならないなｗ
お前設計がおかしいよ。

妻をクラスするって発想がそもそも
キチガイじみてる。

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

普通は性別は属性だよなｗ

人クラスがあって、名前・年齢・性別
ほら属性だ。

そのうち佐藤クラスを作るとか言いそうだｗｗｗｗ

**デフォルトの名無しさん** · 2016/08/01(月) 00:52:22.69

is-a関係っていうのは必要条件であって十分条件じゃないんだがｗ
is-aになっていれば必ず継承関係にあるってことじゃない。
継承しようと思ったとき、is-a関係を満たしていなければいけないって話だ。

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

オブジェクト指向ってどこで間違ったんだろう
途中までは良い線行ってたと思うんだけど、どこからか使いものにならなくなったよね

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

オブジェクト指向が使われてない
フレームワークなんて無いんだが？

使い物にならなくなったという考えがそもそも間違いだな。

まあ「使い物にならなくなった」と言い続けることで
他の人に事実だと錯覚させようとする手段ニダ？ｗ

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

だから、継承捨てて委譲を使えっての！

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

>>517 本当にオブジェクト指向が必要だから使っているのか、
抽象化の手段がオブジェクト指向しか無いから使わざるをえないのか

昨今の言語なら継承以外の方法で抽象化とか再利用とかできたりする
OOは本当に最小限にして、late bindingやメッセージパッシングの妙を際立たせるとより効果的
Real World OCamlだとヘテロな型を持つ木構造を探索するのに使ってたりしたな

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

継承捨てて委譲を使えっていうのは
マイクロソフト用語でコンポーネント指向っていうんだが、
これを意図的に取り入れたのが2000年前後に使われていたVB6なんだよな。

そのVB6も.NETになってから継承をサポートしたし、
コンポーネント指向だけではだめだということだろう。

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

>>519
オブジェクト指向は必要だから使うんじゃなくて
いくつもある手段の中から一番適切だから使うんだよ。

お前が例示する使い方は、単にオブジェクト指向じゃないほうが
適切だってだけ。そしてオブジェクト指向が適切だから
ほとんどのフレームワークでオブジェクト指向が使われている。
他に代替技術があるにもかかわらずだ。

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

>>513
だからその設計はねーってこと言ってるんだろ。

日本語読めないの？

**デフォルトの名無しさん** · 2016/08/01(月) 03:09:46.97

>>516
＞どこからか使いものにならなくなったよね
C++の奇形めいたオブジェクト指向は衰退して
別方面で進化してきたObjecive-CとJavaが本流として
いま街でみかける全てのスマホアプリを支えてるけどな。

**デフォルトの名無しさん** · 2016/08/01(月) 03:31:24.59

今はObjrctive-CじゃなくてSwiftじゃね？

**デフォルトの名無しさん** · 2016/08/01(月) 04:29:03.24

>>521 適切だから使うというなら何故デザインパターンなんて出てきたのか？
デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
他の手段が使える言語なら間違いなく採用しない

他にもExpression ProblemをJavaで解決しているのとOCamlで解決しているのを比較してみるといい
OOだと論文書けるくらいには面倒な方法があるけど、OCamlのVariant使った方法と比べて圧倒的に可読性と簡潔さに劣っている

**デフォルトの名無しさん** · 2016/08/01(月) 06:27:47.87

JavaはC++よりレガシーな言語になってしまったが…

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

>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、

違う。OO便利だなーって使っているうちに
設計のアルゴリズムが確立されていって、
それをまとめたのがデザパタ

**デフォルトの名無しさん** · 2016/08/01(月) 10:06:54.28

いや、デザパタはOOと関係無いから。
関係あるのはOOPの方

**デフォルトの名無しさん** · 2016/08/01(月) 10:50:43.99

【閲覧注意】戦闘に巻き込まれて頭部を切断された少女の遺体。これがリアルなシリア。
http://dqnworld.com/archives/34.html
これが本当の戦争の恐怖。この少女には大人の戦争は関係ないですからね。巻き込まれた少女の遺体を持って何か
を訴えかけている男たちの映像です。

【閲覧注意】シリアで反体制派の兵士が顔を吹き飛ばされてしまう瞬間。
http://dqnworld.com/archives/89.html
スローモーションが怖すぎる・・・。

【閲覧注意】アッラーフアクバルを叫びながら少年を斬首する映像を公開する。
http://dqnworld.com/archives/3975.html
点滴？のようなものが見えるんだけど。助けられた少年じゃなかったのか。助けられた所を強奪されてアッラーフ
アクバル？なのかしら・・・。

【閲覧注意】磔にされた戦闘機パイロットの遺体。シリアにて。
http://dqnworld.com/archives/3996.html
今日のアッラーフアクバル動画。

妻の目の前でぶっ飛ばされた旦那さん？これは死んだかな(°_°)
http://dqnworld.com/archives/4004.html
さすがにこれだけ飛ばされたら助からないかな・・・。

【閲覧注意】あおむけでゲロを吐きまくっている男性。助けてやれよ・・・。窒息するぞ(@_@;)
http://dqnworld.com/archives/4007.html
これ結構危ないんじゃないの？撮影してないで横向きにしてやれよ。これ窒息する可能性あるだろ。

衝撃映像。事故って大回転した車から少女がポロリ。
http://dqnworld.com/archives/4013.html
この少女がどうなったのかが気になる所ですが動画の説明には何も書かれていなかった・・・。

**デフォルトの名無しさん** · 2016/08/01(月) 10:52:18.11

ここまでLSPの話題なし

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

>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、

おしい。
デザパタはJavaやC++に適さない問題を無理やりJavaやC++で解決するためのもので、
SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。

**デフォルトの名無しさん** · 2016/08/01(月) 18:06:20.18

smalltalk だと、人間クラスと美少女クラスの問題は
どう解決するの？

**デフォルトの名無しさん** · 2016/08/01(月) 20:14:16.64

Squeak Smalltalk だと、こんな感じか？

Object subclass: #人間
　　instanceVariableNames: 'もろもろ'
　　classVariableNames: ''
　　poolDictionaries: ''
　　category: '美少女-排便'.

人間 compile: '排便 ^#便'.

Trait named: #美少女 uses: #() category: '美少女-排便'.

美少女 compile: '排便 self notify: ''トイレには行きません''. ^#プリン'.

おまえら := 人間 new.
おまえら排便. "=> #便 "

橋本環奈 := 人間 new.
橋本環奈 assureUniClass class uses: 美少女.

橋本環奈排便. "Warning: トイレには行きません => #プリン"

**デフォルトの名無しさん** · 2016/08/01(月) 20:39:01.26

>>531
> SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。

例えば、どのパターンが簡潔明瞭に記述できるの？
一番簡単なパターンでいいので書いてみて。

考えるのが面倒なら俺が出題しても良い？
Singletonは個人的につまらないので
そうだね、DecoratorはSmalltalkやSelfで書いたらどうなる？

**デフォルトの名無しさん** · 2016/08/02(火) 00:07:55.94

>>534
試しにウィキペの Decorator パターン
https://ja.m.wikipedia.org/wiki/Decorator_パターン

にある例を Smalltalk で書いてみた
http://ideone.com/Y1WAxY

けど、圧倒的に簡潔になった感じはしないな
>>531 ならどんなふうに書く？

**デフォルトの名無しさん** · 2016/08/02(火) 00:11:39.50

シングルトンなんて言語に最初から組み込んでおけ（Scala信者並感）

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

>>532
そもそもきみは継承関係=オブジェクト指向でしか発想してないから
クソ邪魔くさい継承取っ払ってモジュール自由に組み外しできるタイプの
オブジェクト指向の話にまったくついてこれてないからずっと嗤われてるわけで。

**デフォルトの名無しさん** · 2016/08/02(火) 00:44:39.63

>>535
別にDecoratorじゃなくていいんだけどね。
圧倒的に簡潔かつ明瞭に記述できるっていってるから
そのコードを見たいだけ。

**デフォルトの名無しさん** · 2016/08/02(火) 05:55:14.53

デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。
型が完全に動的なSmalltalkやSelfではデコレータパターン自体が不要。

**デフォルトの名無しさん** · 2016/08/02(火) 10:26:45.37

型が動的だと>>535の例のようなコードはどうなるの？

**デフォルトの名無しさん** · 2016/08/02(火) 10:29:15.63

そそ
例えばアセンブリや機械語は制約がないからデコレータパターンとか要らないでしょ
それと同じでSmalltalkには何も必要ないよ

**デフォルトの名無しさん** · 2016/08/02(火) 13:11:20.31

全然違うのだが。デコレータもSmallTalkも理解してないとみた。

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

アセンブリというかC言語だとこんな感じか。出来るには出来るけどちょっとねえ
http://codepad.org/XgRtJlQb

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

なにも知らなくても語れる。
それが Smalltalk のいいところらしい。
人間の悲しさがほの見えるな・・・

**デフォルトの名無しさん** · 2016/08/02(火) 16:01:47.58

>>540
Smalltalkはよくわからないけど、
DoublePriceとかWholesalePriceとかいうクラスを増やすより、
元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
SmalltalkのPluggableMVCとかもクロージャで柔軟な変換を実装しているし。

**デフォルトの名無しさん** · 2016/08/02(火) 16:53:22.92

>>545
> 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。

こんなんでどうですかね？
http://ideone.com/d8iLSE

ついでにRuby版も書いてみた
http://ideone.com/WW8gva

**デフォルトの名無しさん** · 2016/08/02(火) 17:16:35.65

>>543
これだと Java 版でいうところの getValue() する前に
毎回、二倍にして利益80乗せて、また二倍にしてもう一度利益200乗せて…とかって
いちいち書かないと 840を返せないから、結果は合っているけど要求仕様を満たしていないような気がする

**デフォルトの名無しさん** · 2016/08/02(火) 18:25:05.78

いつになったら、
人間クラスと美少女クラスの問題に辿りつけるのかね？
悲しいの～。

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

>>548
とっくに解けてるじゃん
ばか？

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

どう解けてるんだよ。
人間の肛門と天使の肛門にコンポーネントするのか？

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

用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。

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

美少女は偶像であり人間ではない

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

もうそろそろいいかな？

みんな「デコレーターパターン」をどうするか？というテーマで
会話が成り立ってるよね？

つまりこういうことさ。デザインパターンっていうのは用語。
実装じゃない。

デコレーターパターンをJavaならこう書く、SmallTalkならこう書くと
いうふうに共通認識ができてる。これこそデザインパターンの有用な所。

だからコードの書き方が決まってるわけじゃないんだよ。
設計だからね。言語が決まらない状態であっても話はできる。

デザインパターンをどういうふうに書くかってのは例でしか無いんだよ。
目的を達成できるならどう書くてもいいし、デコレータパターンを
どう書いてもそれはデコレータパターンなのさ。

SmallTalkであってもデコレーターパターンっていうのは存在する。
だからこそSmallTalkでデコレータパターンをシンプルに書くことができる！と
主張できる。

**デフォルトの名無しさん** · 2016/08/02(火) 21:16:53.04

>>553
なんでみんなより二歩も三歩も手前な意見を
そんな長文で書き込めるの？

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

>>554
言いたいことはそれだけかｗ

**デフォルトの名無しさん** · 2016/08/02(火) 21:22:05.73

ごめんね