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

1デフォルトの名無しさん 転載ダメ©2ch.net2016/01/05(火) 02:10:25.72ID:hJUQcrkl
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
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/

2uy ◆Qawu9.2l1E 2016/01/05(火) 02:40:11.66ID:3cj4CitF
>>1 = ハゲ
>>3-1000
ゴミ


死ね

3デフォルトの名無しさん2016/01/05(火) 08:10:47.12ID:WVEw1bNF
相変わらず気が狂ってるね

4デフォルトの名無しさん2016/01/05(火) 21:54:42.69ID:8fihq/Cm
オブジェクト指向は直観に反するんだよな。
こいつを見てくれ。
http://pbs.twimg.com/media/CW4jn4jUkAAqIlA.jpg

Coffeeオブジェクトに振る舞いがある。これはオブジェクト指向的に完全に正しい。
しかし、現実にコーヒーを飲むのは人間だ。コーヒーは人間によってカップに注がれる存在だ。
これが思考を混乱させる。オブジェクト指向に従うとよくわからないソースコードのできあがりだ。
データに振る舞いを持たせるのは大失敗だと言わざるを得ない。

5デフォルトの名無しさん2016/01/05(火) 22:44:58.11ID:zW6slUa6
空かどうか判定するEmpty()を定義したCupクラスとLiquidクラスを継承したCoffeeクラスを作って、HumanクラスにRefill(Cup,Liquid),Drink(Cup)を定義すればいいだけだ

if(cup.Empty())
{
human.Refill(cup,coffee);
}
else
{
human.Drink(Cup);
}

6デフォルトの名無しさん2016/01/05(火) 22:47:52.22ID:i0IFFoJB
コーヒーの属性定義が広範囲すぎる
量をのオブジェクトに突然、実態コーヒーを入れている
量のオブジェクトの範囲のクラスを作っる
コーヒークラスに量をコンポジションさせる
設計の間違え

7デフォルトの名無しさん2016/01/05(火) 22:51:39.37ID:GCWuNCn0
>>4
単純。

コーヒーはただの量であり、人間オブジェクトの一変数だ。
いや、コーヒーはオブジェクトであり、生成からの時間により温度変数の値が変わる。
いや、コーヒー生成の時刻を保持するのは人間であり、コーヒーの温度を計算するのは人間である。
いや、コーヒーはコーヒーサーバーオブジェクトの変数であり、、、、

8デフォルトの名無しさん2016/01/05(火) 22:55:26.17ID:i0IFFoJB
>>5
ま^、これでもいいがこれをオブジェクト指向と思っている時点で
何をやっても後が大変。

9デフォルトの名無しさん2016/01/05(火) 23:02:31.55ID:zW6slUa6
>>8
目的次第としか言えんわ
直感的なコードが求められるなら>>5ってだけ

10デフォルトの名無しさん2016/01/05(火) 23:15:31.85ID:i0IFFoJB
その直感が、直感的だと思う時点
斜め直感にしか見えん

11デフォルトの名無しさん2016/01/05(火) 23:33:07.12ID:QVqdPGfo
すまん、自動で口にコーヒー注いでくれない前時代のコップ使ってる雑魚おる?

12デフォルトの名無しさん2016/01/06(水) 00:33:16.74ID:73ZB/O6z
胃瘻はかなり前に技術だが

13デフォルトの名無しさん2016/01/06(水) 02:56:11.57ID:MPHK5bs1
>>5
おまえはカップを飲むのかw

14デフォルトの名無しさん2016/01/06(水) 06:53:26.42ID:UF966QGg
現実をそのままモデル化してOO否定って5周くらい遅れとるで

15デフォルトの名無しさん2016/01/06(水) 07:15:47.25ID:QNndC4zW
形式主義ではコーヒーを椅子に置き換えても成り立つってことをいいたいんじゃないのか。

16デフォルトの名無しさん2016/01/06(水) 08:11:16.53ID:xFxLYqzC
>>14
>>4は現実をそのままモデル化できていない。
大事なのは、そのままモデル化するのではなく、どうモデル化するかなのだ。

17デフォルトの名無しさん2016/01/06(水) 08:45:38.03ID:/XlzX9bH
人間は現実を直接みてるわけじゃないからね

18デフォルトの名無しさん2016/01/06(水) 08:58:13.58ID:9xF4ChVe
まー初心者(OOだけでなくプログラミング全般の初心者)向けのオブジェクト指向の解説とかでよくある説明だよね。
「オブジェクトとは日本語で物、対象物などという意味です」みたいなさ。とっかかりとしては平易なためによく使われているけど、
数学の定義のように後生大事にするべき、応用の効く、正しいイメージじゃない。

19デフォルトの名無しさん2016/01/06(水) 11:11:49.69ID:wCEM/hYT
>>1

20デフォルトの名無しさん2016/01/06(水) 11:14:02.62ID:Nukx80Um
クラスは原子陽子中性子くらいから完璧に継承すべき

21デフォルトの名無しさん2016/01/06(水) 11:15:12.81ID:nQqbz+/u
メソッドに何かやらせるのはやめて全て物理演算で動作を決めるべき

22デフォルトの名無しさん2016/01/06(水) 11:19:28.24ID:dAXQ+tnq
コンピュータ内でシミュレートするのではなく実際の分子原子を用いるべき

23デフォルトの名無しさん2016/01/06(水) 11:34:29.07ID:KjcuT4OL
そんなことしたら分子原子の仕様変更で全てがひっくり返るぞ

24デフォルトの名無しさん2016/01/06(水) 11:54:24.95ID:nQqbz+/u
メソッドコールのかわりにオブジェクトに対するフォースとトルクを搭載した言語を作ればいい

25デフォルトの名無しさん2016/01/06(水) 11:57:30.95ID:nQqbz+/u
>>13
これ、どう表現すべきなのか?

26デフォルトの名無しさん2016/01/06(水) 12:01:41.51ID:QNndC4zW
beDrank, beRefilledにかえればいいだけだろ。

27デフォルトの名無しさん2016/01/06(水) 12:26:10.76ID:HvQ48C0N
>>25
drinkに渡すのはcup.contentsとかにする?

28デフォルトの名無しさん2016/01/06(水) 13:44:41.72ID:ZUCJrGIg
>>4は一般的なコーヒーのモデル化じゃなくて
コーヒーの消費が常態化したマの皮肉じゃないの
最後にコメント付いてるし

29デフォルトの名無しさん2016/01/06(水) 21:55:30.95ID:kAnzyWXR
オブジェクト指向は無理

30デフォルトの名無しさん2016/01/06(水) 21:55:58.83ID:zRcw+KQb
まったく直感的ではないな

31デフォルトの名無しさん2016/01/06(水) 21:56:37.47ID:fWGpYiip
こうしてクソみたいなソースコードが溢れた

32デフォルトの名無しさん2016/01/06(水) 21:57:33.23ID:ljmmccCR
>>25-27
こんな議論になる時点でオブジェクト指向はヤバいだろ

33デフォルトの名無しさん2016/01/06(水) 21:58:49.59ID:ljmmccCR
>>2
死ね

34デフォルトの名無しさん2016/01/06(水) 22:00:48.90ID:vTtwKBx3
>>9
そこまでしてオブジェクト指向にこだわる意味がわからない。
そんなもんperlやrubyのワンライナーですませろよ

35デフォルトの名無しさん2016/01/07(木) 00:25:26.48ID:idw/W9gn
オブジェクト指向も結局はコミュニケーションというか
メソッド(関数)指向という方が正しい。
結局はメソッド(関数)をどのように呼ばれるか、まとめられるかってことだから。

36デフォルトの名無しさん2016/01/07(木) 01:03:06.56ID:Spe75WNW
メソッドは関数ではない
メソッドとは特定のオブジェクトにのみ適用可能な手続きであり、
関数とは特定のオブジェクトに依存しないものである
特に純粋関数は状態にも依存せず、参照等価性が成り立つものである

ところでオブジェクトが状態を持たず、メソッドを持たなければ、
それは単なるデータ(例えばハッシュマップ)と同じである
従ってオブジェクトというものは状態、及びメソッドの存在を暗示している

オブジェクト志向とは全てのものを変更可能なデータ(言い換えればエンティティ)とメソッドで表そうという観念である
関数型はそれに反して極力多くのものを変更不可能なデータ(値)と関数で表そうとする
ここの話はいわゆるドメイン駆動設計にも絡んでいる

どちらが、現実世界の捨象に有用であるかということが問題なのである

37デフォルトの名無しさん2016/01/07(木) 01:15:30.61ID:Spe75WNW
オブジェクト志向で実装可能なことは、原理的に関数型でも実装可能であり
関数型で実装可能なことは原理的にオブジェクト志向でも実装可能なはずである

関数はオブジェクト志向においては、staticクラスを使えば実装できる
メソッドは関数型においては、第一引数によって動作を変更するポリモーフィズムとして実装できる

問題はどちらが汎化に適しているかということなのである
関数型にはオブジェクト指向では綺麗に実装できない麗としてマルチメソッドというものがある
これは第一引数及び第二引数+・・・の型を持ってして動作を変更するという技であるが、
特定のオブジェクトに依存しているオブジェクトにおいてはこれはif文を内包したディスパッチをする他に実装する方法はないだろう

一方staticクラスによる関数のパッケージ化は煩雑である
必要な関数だけをインポートするには、その関数を内包したstaticクラスをインポートする必要がある
もしここで厳密なカプセル化を適用するならば、
1つの関数のために1つのクラスを使う必要がある、さもなくば利用可能でない関数も同時にインポートしてしまう

カプセル化もまた、オブジェクト志向の特権ではないのである
関数型は関数をカプセル化しているのである
そして変数のカプセル化もまたクロージャで実装できる

オブジェクト志向での変数のカプセル化は容易ではあるが、本当に変数はカプセル化されるべきか
それが私の問いなのである

38デフォルトの名無しさん2016/01/07(木) 01:40:36.54ID:6wDD5ILY
>>37
その問いにおける「変数」とは状態のことであるから、
それは構造化・カプセル化によってアクセス制限されるべきなのは明らか。

39デフォルトの名無しさん2016/01/07(木) 02:02:35.73ID:EDvZlrKk
>>1>>4
結局のところ、この問題に誰もが納得するシンプルな回答を示せない奴が設計するからデスマーチになるんだろ。

40uy ◆Qawu9.2l1E 2016/01/07(木) 03:17:27.43ID:VBUUQOGk
自分も参加してるプロジェクトでデスマが起こるなら多分自分にも原因があるんだと思うよ

41デフォルトの名無しさん2016/01/07(木) 03:22:02.67ID:Y5yasR7+
>>4
そもそもなんでコーヒーに命令するとコーヒーが自分で動作してんだよ。
そんなコーヒーがあるかw
いきなり設計段階から間違ってるじゃねーか

どう考えても最後の"//I am a software developer"って時点で
そういう設計をやらかす>>4みてぇなバカを揶揄したセルフパロじゃんかw

42デフォルトの名無しさん2016/01/07(木) 04:03:14.50ID:Y5yasR7+
ああ、ジョークまで完全に見えた
>>4は「プログラマがコーヒーを飲む」じゃなくて
「コーヒーがプログラマに飲まれる」って逆転ジョークで
絶え間なくコーヒーが自動的にプログラマに注がれ続ける
おかしな逆転コードでプログラマジョークになってんだ。

「こいつをみてくれ」じゃねーよ!プププ

43デフォルトの名無しさん2016/01/07(木) 04:17:18.05ID:boatvz1E
>>36-37 が大嘘であることはOCamlの存在が証明している

44デフォルトの名無しさん2016/01/07(木) 14:46:08.69ID:Geoe+pHe
こういう根本的に理解できてないのが大量に居る時点で、オブジェクト指向は愚かな考えw

45デフォルトの名無しさん2016/01/07(木) 15:46:48.63ID:bWvRU875
コーヒーはどうでもいいけど、
2.log() とか数に数学的関数計算をくっつけるってどうなのよ?
気持ち悪いったらありゃしねえ。

46デフォルトの名無しさん2016/01/07(木) 18:04:34.20ID:nwSyjPdt
数学みたいにlog(2)でいいと思うが。
その()は何のためにあるんだと言いたい。

47デフォルトの名無しさん2016/01/07(木) 19:24:41.82ID:bWvRU875
大分昔だけどフリー関数は気持ち悪くて、1.sin()とか1.cos()とか書けるのが本来の在り方だ、といった
痛い記事を読んだ記憶がある。Rubyがらみだったかなあ。
今ちょっと検索すると見つからないから俺の妄想なのかもしれん。

48デフォルトの名無しさん2016/01/07(木) 19:33:58.76ID:LLMMv1AA
数字は計算をしないからそう書いちゃいかんのだけどな

49デフォルトの名無しさん2016/01/07(木) 19:53:48.55ID:wknU54yj
+ 1 2

50デフォルトの名無しさん2016/01/07(木) 21:42:11.31ID:a7kpSA/c
死ね括弧

51デフォルトの名無しさん2016/01/07(木) 21:57:00.05ID:sG4YEGv+
(スズ)

拝承

52デフォルトの名無しさん2016/01/07(木) 22:18:47.33ID:a7kpSA/c
>>46
> 何のため
関数そのものなのか、関数を呼び出した結果なのかを区別する括弧。
括弧がなければ関数そのもの、あれば関数呼び出しの結果。
括弧がなければlogという関数そのもの、あればlog(hoge)の計算結果。
かどうかは言語による。

53デフォルトの名無しさん2016/01/09(土) 14:00:07.10ID:8eWGVEYX
>>45
こういう主語述語みたいなくだらない議論に陥るのがオブジェクト指向の最大の問題点だな
どっちでもいいからそのためのテストなりサンプルコードをがつがつ作ってくれれば問題ないんだが
糞みたいな議論ばっかりふっかける輩を生むところが最大の問題点だな。

54デフォルトの名無しさん2016/01/09(土) 14:37:25.60ID:hdqMNonU
>>53
何も考えずに作業こなすだけの社畜 VS 議論ばかりやる頭でっかち ファイッ!!

55デフォルトの名無しさん2016/01/09(土) 16:12:34.83ID:8eWGVEYX
>>54
極論煽るだけのカスも大概だけどな

56デフォルトの名無しさん2016/01/09(土) 17:15:53.50ID:3kY/wzgi
>>53
ドット構文を変な風に使うバカの問題であってオブジェクト指向関係ないな。

57デフォルトの名無しさん2016/01/09(土) 18:23:24.86ID:oGyr6/WF
主語述語っていうけど、オブジェクトは目的語だからね

58デフォルトの名無しさん2016/01/09(土) 19:25:35.83ID:oGyr6/WF
昔ながらのfunc( obj ); 形式だと、オブジェクトを主語と考える人はいないだろうし
obj.func(); は↑が変形したものにすぎないから同じ理屈だよね
しかも時期C++ではfunc( obj )でもobj.func()でもどちらの形式でも呼び出せるようにするって
C++の超偉い人がやる気満々だし、見た目は最早重要ではないよね

普通に考えると、主語はコンピュータや処理系だね
プログラミングを全然知らない人でも、主語は誰?って聞いたらコンピュータって答えるだろうね

何するにしても、結局実行するのはコンピュータだからね
これが全く現実世界でおこっている物理現象なのに、あえてオブジェクトを主語という風に
ひねくれた別な観点で考え直す必要は無いね

現実世界に合わせて、主語をコンピュータ、オブジェクトを目的語、関数を述語、と捉えると
それで多態や継承が出来なくなるっつーんなら困るけど、そういうわけではないからね
だったら現実世界で起こっていることに合わせて考えたほうが自然だね

59デフォルトの名無しさん2016/01/09(土) 19:39:23.22ID:OrUjMMRy
メッセージングのオブジェクト指向の言い方で言うと、
主語はメッセージのレシーバであり、文の残りはメッセージだ

60デフォルトの名無しさん2016/01/09(土) 23:40:46.34ID:3kY/wzgi
>>58 チンパンジーのアイちゃんかな?

61デフォルトの名無しさん2016/01/09(土) 23:55:42.86ID:CpCNnIMM
>>58
x.sin() では x がオブジェクトで、sinというメソッド(もしくはメッセージ?)を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。

どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想(?)の根源は何なんだ?

62デフォルトの名無しさん2016/01/10(日) 00:13:34.71ID:MD/fGeTk
ポーランド記法嫌いそう

63デフォルトの名無しさん2016/01/10(日) 00:21:12.30ID:sdj7zt3O
演算子前置のポーランド記法は嫌いだなぁ
存在する意味がわからないレベルで嫌い。
演算子後置の逆ポーランドじゃないとね。

64デフォルトの名無しさん2016/01/10(日) 00:34:49.51ID:0XznusY4
> 存在する意味がわからないレベルで嫌い。

なんで?

> 演算子後置の逆ポーランドじゃないとね。

なんで?

65デフォルトの名無しさん2016/01/10(日) 00:40:13.45ID:hoksOuY6
Add 3 to 5, then multiple it by 2.

66デフォルトの名無しさん2016/01/10(日) 01:09:07.40ID:UgGJRpwk
逆ポーランドの方が実装しやすいと思う。
人それぞれの範疇だが。

67デフォルトの名無しさん2016/01/10(日) 01:11:54.59ID:MiN6/z6v
>逆ポーランドの方が実装しやすいと思う。

意味がわからん。
構文木作るのに一番前と後でなんか変わるか?
AST作らずにそのまま逐次実行するならスタックに
積むだけでいい逆ポーランドの方がいいかもしれんが

68デフォルトの名無しさん2016/01/10(日) 01:16:08.27ID:+l1yiqNW
x.sin() では x がオブジェクトで、sinというメソッド(もしくはメッセージ?)を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。

どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想(?)の根源は何なんだ?

違うよな
どちらがオブジェクト志向的かといえばx.sin()でしょ
xというオブジェクトにsin()というメソッドが属しているという考えなんだから
sin()は関数に対してxというオブジェクト、あるいは単にデータを引き渡しているだけ

後者は明らかに関数的な考え方、動詞優位

69デフォルトの名無しさん2016/01/10(日) 01:27:11.07ID:hZikTLMs
関数へのエイリアスのようなメソッドはドットで繋ぐのでなく、
別の文字にした方がいいよな。

70デフォルトの名無しさん2016/01/10(日) 01:29:17.31ID:sdj7zt3O
釣りじゃなくて単に本当にあたまおかしいのかな?
Xはデータであって演算ではない。Xは演算しない。
Xをオブジェクトとして扱った場合、その操作として実装されるメソッドは
データのゲットセットなど内部状態を隠蔽するためのメソッドと
可変不変などのデータ状態をあらわすメソッド。

まだお前の脳内じゃおまえがコーヒーを飲むんじゃなくて
コーヒーが勝手に口に飛び込んで来てんのか。

71デフォルトの名無しさん2016/01/10(日) 01:29:19.21ID:Ch7U5rc3
x.sin()は手続き言語的だと思うけどなあ
もちろんsin(x)も。
オブジェクト指向ならメッセージを送るような記述の方が自然では

72デフォルトの名無しさん2016/01/10(日) 01:52:12.61ID:hZikTLMs
現実世界をオブジェクト指向に当てはめるやついるけど馬鹿だよなー

コーヒーが勝手に口まで運ばれてくる機能をコーヒにつけただけじゃんw
ついでにコーヒーがしゃべる機能もつけたよ。

問題がないからそういう設計にしたんですよ

73デフォルトの名無しさん2016/01/10(日) 01:53:23.52ID:+l1yiqNW
どちらがより汎化されているかではなく
具体例で語ろうとする人間は、プログラムを実装したことがないのでは?

具体的な手続きによる具体的な文字通りのプログラムを書きたいなら
Cでかいてどうぞ

74デフォルトの名無しさん2016/01/10(日) 01:59:31.92ID:+l1yiqNW
オブジェクト指向だろうと関数志向だろうとやってることは変わらない

オブジェクトはメソッドの第一引数でしかない

コーヒーを飲むという行為を書くためには手続き的に書くしか無い
コーヒーが俺の口の中にあるという結果を宣言的に書きたいのに
その手続きを丹念に描写したいならそうすればいい

I.drink(coffee)と書けばいいんだよ
I.drink(coffee)とyou.drink(coffee)は飲み方が違う!というのならそう実装すればよい

モデリングとは物事を単純化する行為、汎化する行為であって具象化する行為ではない
Iとyouの違いがモデルのキーポイントなら、Iとyouという(メソッドの第一引数)をパラメータに加えればいいし
そうでないなら含まないほうがモデルがシンプルに保たれる

数学ができない自称モデラーはプログラムを手続き的に書いたらいいんだよ

75デフォルトの名無しさん2016/01/10(日) 02:00:42.57ID:hZikTLMs
特化させたいのに汎化する必要ある?
狭い世界で使うなら特化させていい。
広い世界で使うなら汎化させる。

それだけ。

76デフォルトの名無しさん2016/01/10(日) 02:03:41.63ID:hZikTLMs
汎化と特化させるもんを決めるのが設計な

77デフォルトの名無しさん2016/01/10(日) 02:42:12.92ID:JhCLPk/2
>>74
言ってることはわかるがコーヒーを主語に対象を汎化なら
coffee1.drunkBy(me);
coffee2.drunkBy(you);
だろ

78デフォルトの名無しさん2016/01/10(日) 03:01:38.69ID:JhCLPk/2
>>72
普通モデリングなんて想定される実装の多さや効率の問題で変えるものだからね
感性にまかせる初心者ほど文脈や抽象に拘って依存性の上下を無視するよ

79デフォルトの名無しさん2016/01/10(日) 04:22:46.36ID:sdj7zt3O
アクセル→エンジン→ギア→タイヤじゃなくて
タイヤ.回転で自動車設計してそうだなおまえら。

80デフォルトの名無しさん2016/01/10(日) 05:12:47.23ID:JhCLPk/2
>>79
そうやって現実の構造を想定している時点でもう駄目なんだよ

81デフォルトの名無しさん2016/01/10(日) 05:20:12.43ID:JhCLPk/2
ちうかこれオブジェクトが目的語とか言ってる人か?
英語とプログラミングのobject混同とかとてもまともとは思えないよ

82デフォルトの名無しさん2016/01/10(日) 05:34:14.40ID:97NQyWJD
>>74
JavaScriptだと実際foo.barは第0番目の引数を指定するための糖衣構文でしか無い
オブジェクト指向は別にそんな大したものでも、手続き型と相容れないものでもない
指向とは言うが実際の所スタイルの一部だね

83デフォルトの名無しさん2016/01/10(日) 08:13:48.91ID:86WjwACC
いいえ、自転車.操業で設計しています

84デフォルトの名無しさん2016/01/10(日) 08:49:55.36ID:jS8+hJYw
>>82
そういう嘘をまき散らさないでもらいたいなあ。
毛の人といい、技術の普及は嘘との戦いだな。
オブジェクト指向は嘘つきが多すぎた。

85デフォルトの名無しさん2016/01/10(日) 09:36:41.30ID:AcnVMiQc
>>68
いいえ。
sin(x) と書いたときのsinは十分オブジェクトに見えるでしょ。
xとsinは違う階層(空間)に属するモノだけど、後者の方が階層としては高い。
x.sin()と書くと、あるオブジェクトが自分より高い階層のオブジェクトを所有しているように見えてしまう。
これは俺にとっては不自然なので好きになれない。

86デフォルトの名無しさん2016/01/10(日) 09:42:21.66ID:KeJgEHCD
オブジェクト指向は手続き型と直行する概念だと理解してないのが何人かいるな

87デフォルトの名無しさん2016/01/10(日) 09:44:41.71ID:sdj7zt3O
>>80
"現実の構造を想定しちゃダメ"て
おまえの作るシステムはどんな現実離れした
脳内妄想ベースなんだよ。

88デフォルトの名無しさん2016/01/10(日) 09:52:56.57ID:Itquv6VW
sinは関数だろね。
テーブルを持つためにクラスを使わなければならない言語があったとしても、
極力、ユーザーにとって関数に見えるように実装するべきじゃないのかな。

89デフォルトの名無しさん2016/01/10(日) 10:08:13.09ID:jS8+hJYw
関数がオブジェクトじゃ何か困ることでも?

90デフォルトの名無しさん2016/01/10(日) 10:09:40.58ID:jS8+hJYw
>>79
君が設計する自動車ではエンジンブレーキが効かないようだな。

91デフォルトの名無しさん2016/01/10(日) 10:29:26.64ID:hZikTLMs
ブレーキなんてのは外部から
ベクトルの力を操作するんだから
後付けで全然構わないんだが。

92デフォルトの名無しさん2016/01/10(日) 10:41:27.70ID:AcnVMiQc
関数を手続きだと思ってるならそれでいいけど、名前が関数ってだけで数学関数をそういうカテゴリーのものとするのは不適当でしょうね。

93デフォルトの名無しさん2016/01/10(日) 11:09:22.36ID:hXY04te0
クロージャーって、関数なの?オブジェクトなの?
rubyだとProcのインスタンスでしかないよね

94デフォルトの名無しさん2016/01/10(日) 12:33:30.21ID:jS8+hJYw
>>91
わからないなら無理に口を挟まないほうがいいよ。

95デフォルトの名無しさん2016/01/10(日) 13:26:28.06ID:Itquv6VW
>>92
関数が状態を持つべきかどうか考えると自ずと答えが出るのではないだろうか。

96デフォルトの名無しさん2016/01/10(日) 13:37:48.58ID:UyzGSaeg
sin(x)は関数の値であって関数ではないよな。 関数は∀x∈double.sin(x)のことだよな。

97デフォルトの名無しさん2016/01/10(日) 13:51:03.83ID:ainPuYsM
>>85
実装がどうあれ、OOPではメソッドはオブジェクトに属するものとして考えるから、
x.sin(value)の表記は不自然じゃ無いだろ。sinはオブジェクトxに属している。

98デフォルトの名無しさん2016/01/10(日) 14:13:06.68ID:Itquv6VW
>>97
それは不自然な考え方じゃないかな。
原点に立ち返ってみると、オブジェクト志向とはコード再利用に際して
コンポーネント化の要求から発生したもの。
現実に存在する物のように、ディスプレイ上のウィンドウに四角形を
描画しろとメッセージを送るというようなシンプルなものだ。
この場合、四角形自体がオブジェクトであることは問題が無いように感じる。
これは、四角形が状態を保持しているからかもしれない。
一方、数値に対してsinを要求するのは突拍子もないように感じる。
これは、数値を日常いたるところで使用していて、数値がメッセージを受け取る性質を
もたないと良く知ってるからではないだろうか。
あるいは計算機オブジェクトに対してsinを要求するなら不自然に感じないのかもしれない。
どうだろうか?

99デフォルトの名無しさん2016/01/10(日) 14:14:35.30ID:CDx7UjTI
この種のくそ議論って恣意的な答えしかないんだから、
議論するだけ無駄なんだけどねぇ。

100デフォルトの名無しさん2016/01/10(日) 14:15:24.10ID:AcnVMiQc
>>95
状態をもつかどうかは実装しだい。
関数を初期化するとき係数のセットを与えるとかあると思う。

関数がグループとしてまとまって環をなすとか

101デフォルトの名無しさん2016/01/10(日) 14:17:25.96ID:ainPuYsM
つか、sin(x)ってなんやねんw
引数無しのメソッドの話か? それならsinは例として不適当だ。

sinを例にするなら、x.sin(value) か、sin(x, value) だろ。

102デフォルトの名無しさん2016/01/10(日) 14:17:26.78ID:AcnVMiQc
>>97
そりゃメソッドはオブジェクトに属するだろ。
メソッドとして位置付けるのが適切かどうかの議論をしてるんだよ。

103デフォルトの名無しさん2016/01/10(日) 14:17:31.05ID:Itquv6VW
こういうシンプルな考えに基づくと、四角形と三角形は形状クラスから
派生すると思われる。
しかし、四角形オブジェクトと三角形オブジェクトの合成メソッドは、形状クラスあるいは
その派生クラスにあってはならないように感じる。
それは形状合成器クラスに、あるいは単純な関数であった方が良いように感じる。

104デフォルトの名無しさん2016/01/10(日) 14:21:04.23ID:JhCLPk/2
>>87
物理的構造物とは違うんだよ
それすら理解できないならもう向いてないとしか

105デフォルトの名無しさん2016/01/10(日) 14:21:57.10ID:UyzGSaeg
属すじゃなくて依存するだと思うが。

106デフォルトの名無しさん2016/01/10(日) 14:25:29.45ID:JhCLPk/2
例えばゲームでキャラクターが特定のアイテムを使用するモデル
キャラ.使う(アイテム)はもらうアイテムによってメソッドの動作を変える必要があるが
設計としてはアイテム.適用(キャラ)のが遥かに取り回しやすい
なのにあえて前者のクソ設計を選ぶのが>>87のようなオバカさん

107デフォルトの名無しさん2016/01/10(日) 14:26:22.66ID:ainPuYsM
>>102
それならOOPの議論じゃないな。

>>105
いや、属する/所有するという概念の方が適当だと思う。(実装は違うが)
実際クラスを書くときそう書くだろ。

108デフォルトの名無しさん2016/01/10(日) 14:44:22.50ID:AcnVMiQc
>>101
現実の姿を模すという意味だとsinなどは連想配列であって、sin(x)という書き方はそのまんまだよね。
実装においては計算手続きだろうけど。

109デフォルトの名無しさん2016/01/10(日) 14:48:45.22ID:jS8+hJYw
Smalltalkerが引き上げたらもう初心者しか残ってないのかよ

110デフォルトの名無しさん2016/01/10(日) 15:22:03.47ID:yvIOv1as
そもそもクラスだってオブジェクト指向とは直接関係ない
>>84
嘘ではなく現実だ

111デフォルトの名無しさん2016/01/10(日) 15:23:27.70ID:yvIOv1as
美少女が云々言うのも一般的なクラスベースは融通が効かないねという話であって
オブジェクト指向とは直接関係ないし

112デフォルトの名無しさん2016/01/10(日) 15:44:15.32ID:KeJgEHCD
>>111
ほう、それならウンコをしない美少女をオブジェクト指向で設計して貰おうか

113デフォルトの名無しさん2016/01/10(日) 15:50:56.07ID:AcnVMiQc
>>97
見逃したいたが、x.sin(value)の value って何だい?

114デフォルトの名無しさん2016/01/10(日) 16:06:27.16ID:ainPuYsM
>>113
引数だよ。
クラスxのメソッドsinに渡す引数。
俺はそういう話をしてると思ったから。

115デフォルトの名無しさん2016/01/10(日) 16:18:07.80ID:hZikTLMs
xって中身は例えばfloatのデータ自身だぞ?
だから、引数は必要ないんだぞ?

116デフォルトの名無しさん2016/01/10(日) 16:26:17.41ID:ainPuYsM
>>115
理解した。
それなら、x.sin() なんて形が出てくる余地は無いよな。

117デフォルトの名無しさん2016/01/10(日) 16:29:21.43ID:CDx7UjTI
一般に sin に必要な引数は、 pi/2 とかの実数(もしくは複素数) かな。
あとはいくつまでの級数和をとるとか何桁まで計算するとかが引数になるんじゃないかね。
その辺をあいまいなまま value とか x がクラスだの引数だの言ってることに何か意味があると思ってんのかね。

118デフォルトの名無しさん2016/01/10(日) 16:34:25.26ID:ainPuYsM
>>117
いや、sinの引数がオブジェクトの場合はあるよ。
実数や10進型をクラスで表現したりするし、俺も実際やる。
xがそういうオブジェクトなら、sin(x)でいいし、x.sin()はおかしい。
まあ絶対におかしいとか無理ってわけじゃないけどなw

119デフォルトの名無しさん2016/01/10(日) 16:54:55.24ID:yIre7PYR
新しいC++ではsin(x)でもx.sin()でも、どちらの方法でも統一的に呼び出せるようになる予定だから
こんな議論は全く意味ないんだよ?

呼び出す側からしたら、sinがメンバ関数だろうが外部関数だろうが、何であれ、知ったことではないからね
気にしなければならないのは実装する側だけ
だからどちらの方法でも呼び出せるようになる、らしい

どちらの方法でも呼び出せるんだから、喧嘩する必要ないし、気にする必要ないよね

120デフォルトの名無しさん2016/01/10(日) 16:57:47.72ID:yIre7PYR
どちらの方法でも呼び出せるんだから
どちらの方が、よりオブジェクト指向的か、考えるのは意味がないんだよ
等しいわけ、等価と考えてよい
見た目が違うだけ
大した問題じゃない

121デフォルトの名無しさん2016/01/10(日) 17:00:24.30ID:ainPuYsM
なんか違うような気がするなw

122デフォルトの名無しさん2016/01/10(日) 17:07:10.06ID:fbwGqbCo
こんなにややこしいプログラムがオブジェクト指向を使って
こんなに簡潔になりましたって事例が欲しい

123デフォルトの名無しさん2016/01/10(日) 17:12:10.48ID:1042xGua
>>112
思うんだけど、
うんkをしないというのが、
意思を持ってひたすら我慢して(人の目がある場所では)しないのか、
それとも腸内の美少女菌のおかげでする必要が無いのか、
もしくは他の何かなのかによってイメージが変わってくると思う。
でもしないにしろする必要がないにしろ、排便メソッド自体は備わっててもなんら問題ないと思う。
逆に、腸内やなんかの問題を解決せずに、排便メソッドだけ外して他を流用するということは、
オブジェクト指向的であろうがなかろうが不可能だと思う。
それこそ亞人として設計しなおして全ての手続やメソッドを別に用意することが妥当かもしれない。
だから結論を言うと、この例はそもそも良くないと思う。

124デフォルトの名無しさん2016/01/10(日) 17:51:06.88ID:QPFpTdMb
>>122
サイズを持っていてくれるのですら俺は嬉しいと思う
文字列や配列を扱うとき
int string::size() {return strlen(data);} // 数える関数を使うって例
↑こーいうのじゃなくて
int string::size() {return end - begin;} // 簡単な計算(ポインタの差分)で返す
int string::size() {return size;} // 内部でケアしていたprivate変数を返す
こういう実装をしうるのが嬉しい
使うときに
a = s.size * s.size / s.size % s.size
みたいにいっぱい呼び出しても安心
逆に言うとせっかく用意されたsizeメソッドが内部で数えなおしてる場合はつまらないと思う

125デフォルトの名無しさん2016/01/10(日) 19:10:53.94ID:fbwGqbCo
>>124
なるほどねー。

126デフォルトの名無しさん2016/01/10(日) 19:16:06.37ID:fbwGqbCo
>>112
美少女はマーカーインターフェースであり、
美少女として扱うとき排便は隠蔽される。

interface 美少女 {
}

class おっさん implements 美少女 {
 void 排便() {
 }
}

127デフォルトの名無しさん2016/01/10(日) 20:20:59.69ID:VQDMXfno
>>126
それは「何もしない」という排便メソッドを持つ
持たない,ではない

128デフォルトの名無しさん2016/01/10(日) 20:34:00.62ID:fbwGqbCo
>>127
何を言うてんの?排便メソッドを持つのはおっさんだよ。

129デフォルトの名無しさん2016/01/10(日) 20:41:36.36ID:KeJgEHCD
聖水メソッドもないのに美少女とか笑わせんなよw

130デフォルトの名無しさん2016/01/10(日) 21:17:46.16ID:+l1yiqNW
オブジェクト志向の考えだと
大便ableインターフェースを実装するんだろ

131デフォルトの名無しさん2016/01/10(日) 21:57:06.57ID:Hm2sxH4v
美少女クラスを欲する奴が美少女のウンコがついたぱんつを欲しがらないかと考えると
これは要件定義から間違っているような気がしてならない。

132デフォルトの名無しさん2016/01/10(日) 22:05:43.79ID:zd2SpHtU
実装からメソッド設計を考えるより使い方から設計したほうが上手く行くと思う
つまり美少女がうんこ出来るのか、出来ないのかで考えるのでは無く美少女にうんこをさせたいのか、うんこさせたくないのかで考える

133デフォルトの名無しさん2016/01/10(日) 22:12:58.59ID:hZikTLMs
肛門はコンポーネントとしてアタッチする。
美少女は肛門をインプリメントしていない

134デフォルトの名無しさん2016/01/11(月) 02:57:08.55ID:87Jnvcw4
あのさ、どんな美少女もウンコするんだけど?

135デフォルトの名無しさん2016/01/11(月) 03:08:27.43ID:Rwcs8mHW
真の美少女は実在しない

136デフォルトの名無しさん2016/01/11(月) 03:18:02.16ID:4rCdY4Yq

137デフォルトの名無しさん2016/01/11(月) 04:26:03.17ID:3eUcyomA

138デフォルトの名無しさん2016/01/11(月) 14:41:47.97ID:GiqteBDS
関数型言語っていい点もあるけど、変更に弱過ぎない?
ちょっと動作を変えるのにかなり見直さないといけない

139デフォルトの名無しさん2016/01/11(月) 16:00:11.66ID:Rwcs8mHW
作りようだね

140デフォルトの名無しさん2016/01/11(月) 17:41:31.97ID:d9M93+6h
>>138
関数型言語を使えば完璧なプログラミングが可能なので後から変更する必要が無い。

141デフォルトの名無しさん2016/01/11(月) 17:50:34.21ID:KkwWauMD
>>140
完璧なプログラミングは出来ても
将来の仕様の変化を完璧に予測することは出来ないでしょ?

142デフォルトの名無しさん2016/01/11(月) 17:53:14.36ID:GiqteBDS
仕様変更できないって実用上ヤバくないですか

143デフォルトの名無しさん2016/01/11(月) 18:03:26.01ID:RUBsLBHi
オブジェクト指向は細かい修正で済むと手を抜き続けた結果メチャクチャ悲惨なことになる
全て書き直すくらいがちょうどいい

144デフォルトの名無しさん2016/01/11(月) 18:08:52.97ID:hbMmOduf
> メチャクチャ悲惨なこと

たとえば?

145デフォルトの名無しさん2016/01/11(月) 18:13:38.40ID:rz35E4wE
>>144
全て書き直すはめになる

146デフォルトの名無しさん2016/01/11(月) 18:18:05.61ID:V0AQQEoP
関数型言語は仕様変更のたびにめちゃくちゃ悲惨なことをしなければならないのか

147デフォルトの名無しさん2016/01/11(月) 18:31:28.27ID:KoUNfQqa
言語の問題でなくて作ってる奴が馬鹿なだけでは?

148デフォルトの名無しさん2016/01/11(月) 18:59:27.70ID:A5Rx7ofK
ただのリスト操作を関数型と呼んでいる可能性

149デフォルトの名無しさん2016/01/11(月) 19:14:51.77ID:d9M93+6h
>>141
関数型なら完全に未来を予測できる。

150デフォルトの名無しさん2016/01/11(月) 19:37:40.52ID:ugQF1NqL
そらすげーわ

151デフォルトの名無しさん2016/01/11(月) 19:38:18.20ID:rz35E4wE
>>149
そういうのいいから

152デフォルトの名無しさん2016/01/11(月) 19:43:22.94ID:XhrtL63c
関数型言語はコンパイルした瞬間全てが完了される。

153デフォルトの名無しさん2016/01/11(月) 19:46:13.85ID:d9M93+6h
コンパイルが通ればバグが無いことを保証される。

154デフォルトの名無しさん2016/01/11(月) 19:47:17.32ID:rz35E4wE
>>153
それもいいから

155デフォルトの名無しさん2016/01/11(月) 19:49:39.36ID:d9M93+6h
>>154
お前関数型馬鹿にしてんの?

156デフォルトの名無しさん2016/01/11(月) 19:53:45.95ID:XhrtL63c
関数型言語にとって型とはプログラムの設計図なのである。

157デフォルトの名無しさん2016/01/11(月) 19:55:09.91ID:rz35E4wE
>>155
関数型じゃなくてお前を馬鹿にしてるんだよw

158デフォルトの名無しさん2016/01/11(月) 19:55:15.79ID:eiYfk44d
1000近くなった雰囲気だな

159デフォルトの名無しさん2016/01/11(月) 20:02:18.58ID:d9M93+6h
ヨハネの手紙にも関数型が登場する。

160デフォルトの名無しさん2016/01/11(月) 20:05:53.42ID:eiYfk44d
鶏が鳴く前に三度、関数型など知らないと言う

161デフォルトの名無しさん2016/01/11(月) 20:09:36.09ID:d9M93+6h
マタイの福音書、関数型が世界を平和に導く。

162デフォルトの名無しさん2016/01/11(月) 20:40:32.13ID:d9M93+6h
>>157
ああそう、なら良いんだ。
関数型馬鹿にしたら唐沢弁護士に頼んで勝訴しちゃうからね?

163デフォルトの名無しさん2016/01/11(月) 22:15:27.49ID:qSBpiVnS
関数型に不可能はない。関数型は神にのみ扱える至高の言語
関数型を疑ってはならない。汝の実力を疑え

164デフォルトの名無しさん2016/01/11(月) 22:48:28.28ID:CMbhymom
毛の壁の臭いがするな。

165デフォルトの名無しさん2016/01/12(火) 01:32:19.38ID:SYPJaqWI
広く使われてて実用的な言語は多かれ少なかれマルチパラダイム
関数型っていうのも結局は作者がそう言ってるかどうかの線引でしか無い
理想的な関数型gwンゴを想定してなにか言うのはあまり意味が無い

166デフォルトの名無しさん2016/01/12(火) 01:34:43.86ID:uMvEa0J7
関数型ンゴwwwwwwwwwwwwwwwwwwwwwwwwwww

167デフォルトの名無しさん2016/01/12(火) 08:42:46.08ID:V5bMIqIZ
関数型グワンゴ

168デフォルトの名無しさん2016/01/12(火) 09:12:48.84ID:/ZqCERvo
今時は大学とかでも言語比較とか講義しているのかな。

169デフォルトの名無しさん2016/01/12(火) 19:38:37.49ID:7kdSKUGZ
lisp は関数型ですか?

170デフォルトの名無しさん2016/01/12(火) 22:56:29.42ID:uMvEa0J7
いいえ、変態型です

171デフォルトの名無しさん2016/01/14(木) 06:56:24.28ID:/XPEQoow

172デフォルトの名無しさん2016/01/16(土) 23:50:44.88ID:vrXiOUCa
美少女は天使クラスに属している。
排便しない。

173デフォルトの名無しさん2016/01/20(水) 11:46:14.76ID:HskUHurd
「オブジェクト指向プログラミングの例を挙げましょう。2000年代には、オブジェクト指向プログラミングは、企業向けプログラミングにおける基盤的技術の地位を確立したと思われていました。
しかし今では、私を含めて多くの人が、この潮流は20年間に渡って本流から逸れていたものであり、そのほとんどが間違いだったと考えています。」

コーディングを学ぶこと、それはあなたが考えるよりも大変です
http://postd.cc/learn-to-code-its-harder-than-you-think/

174デフォルトの名無しさん2016/01/20(水) 12:33:48.74ID:CF7z5V/R
>>173
記事のベースはイギリスのプログラマ教育のあり方と社会地位の話で
"大学で教えていることが現場で役に立たない"ことと
"高級技術者としてのプログラマの社会的地位の低さ"について
そして、前者関連の話で「教えるべき技術は次々と移り変わる」例として
オブジェクト指向を挙げてみてるが、筆者があまり理解してる感じではないなぁ…
20年前なら単語そのまま「構造化プログラミング」に置き換えて書かれた
単なる流行りワードの扱いだわな。

175デフォルトの名無しさん2016/01/20(水) 12:39:59.33ID:CF7z5V/R
また、書かれている内容のとおりイギリスのプログラミング技術のほとんどが
学校教育ではなく「独学」で学ばねばならないもので、その上でガチで
『しかし今では、私を含めて多くの人が、この潮流は20年間に渡って
本流から逸れていたものであり、そのほとんどが間違いだったと考えています。』
と、思ってるとしたら本当にイギリスのプログラミング業界界隈の危機は
深刻なものだと考えざるをえない…

176デフォルトの名無しさん2016/01/20(水) 12:41:46.50ID:uqyd4S+p
日本も似たようなもんじゃないの? 違うの?

177デフォルトの名無しさん2016/01/20(水) 12:58:06.53ID:CF7z5V/R
>>176
>>173のリンクを読んだ感じではイギリスではどうも国を挙げて
学校や社会人教育で「無償で国民にプログラミングを学ばせる」事業をやってたっぽい
で、たぶん日本でやってもそうなるだろうけれど
みんな合格するようなレベルの簡単な内容なので
わざわざ教える意味がない的な事態になったっぽい?

大学の情報学科だったら日本でもまぁ直でコーディングの役には立たんが
逆に大学レベルの情報工学理論面を広く教えるから
オブジェクト指向なんて〜って池沼はでないだろう(皮肉

178デフォルトの名無しさん2016/01/20(水) 21:59:54.59ID:ftWUH7Q0
オブジェクト指向は思考パターンを破壊されるよ

179デフォルトの名無しさん2016/01/20(水) 22:38:38.89ID:KK1TC/Qj
コードの奇麗さはなになに指向とかとはいつだって無相関だよ。

180デフォルトの名無しさん2016/01/20(水) 23:28:45.86ID:lyH/JRhU
>>179
その評価はとても健全

181デフォルトの名無しさん2016/01/21(木) 12:15:51.15ID:pkb4zgJk
>>179
「奇麗」なコードってどんなの?

182デフォルトの名無しさん2016/01/21(木) 16:38:21.88ID:OmENn3Ct
>>181
測定するツールがある。

183デフォルトの名無しさん2016/01/22(金) 08:41:08.27ID:jWLszG8x
それはツールに設定したルールを守ってるかの判別器でしか無いな。
本当に一般的に綺麗なコードとやらを図るには、
統計を集めて機械学習でもさせる必要があるだろう。

もしくは綺麗というのが、編集しやすいということなら
最低きちんとした理論と根拠を元に基準を決めるべき。
今の基準の多くはただ作者の信念だったり、狭い範囲での多数はを取っているだけ。

184デフォルトの名無しさん2016/01/22(金) 10:24:46.06ID:BOI0ua8w
>>183
コードコンプリートでもよんだら?

185デフォルトの名無しさん2016/01/22(金) 12:53:49.39ID:NE1Xg/XG
コードとは言語だから、綺麗な英語と置き換えてみればわかる。 学校で教えられるのは全部綺麗な英語だから実際の外人の喋ってることなんか一つも役に立たない。 汚いコードを書いてどんな汚いコードも読めるようになるのが大切。

186デフォルトの名無しさん2016/01/22(金) 13:21:50.19ID:p0qaIBjS
実際に効果があるかそっちのけで、主観的な綺麗さばっかり気にしてルールを
固定化しようとするやつなんなの?
どことなく自閉症的で気味が悪い。

187デフォルトの名無しさん2016/01/22(金) 13:23:33.14ID:p0qaIBjS
あ、このスレの発言のことじゃないです。リアルの話。

188デフォルトの名無しさん2016/01/22(金) 14:33:54.36ID:IejezU7v
コードコンプリートを書いたのはマイクロソフト()だぞ
林檎がビューティパーフェクトコードを書くまで待て

189デフォルトの名無しさん2016/01/22(金) 22:02:12.46ID:SlI41mNc
>>185
こういう人が職場にいたらきついお

190デフォルトの名無しさん2016/01/22(金) 22:17:23.23ID:jXHHn5ty
>>186
ルールなんて誰でもわかってると思うけどな。

・重複する処理はかかない。
・同じことに関する値を重複して定義しない。
・計算で求められるものは計算でだす。
・ある処理に関するコードは一箇所にまとめる。
・条件分岐を減らす。
・ループを減らす。
・設計とファイル名やディレクトリ構造を一致させる。
・役割毎に関数やクラスを分ける
・関数やクラスはなるべく短くする
・テストしにくい所を減らす
・適切な名前(グローバルに近いほど長く、ローカルに近いほど簡単な名前)をつける。
・十分にテストされた信頼性が高いライブラリを使用する。独自実装しない。
・コーディングスタイルに適合すること
・メトリクス(複雑度等)が悪いものは認めない

これらは主観じゃないので、このルールにしたがえば、
誰でも良い方がどちらかわかる。

191デフォルトの名無しさん2016/01/22(金) 23:23:12.65ID:p0qaIBjS
>>190
それらは効果があるとわかるものだから問題ないよ。

192デフォルトの名無しさん2016/01/23(土) 03:52:18.65ID:qPctTKOa
Smalltalker達がいなくなったら途端に初心者スレ化w

193デフォルトの名無しさん2016/01/23(土) 14:01:47.22ID:xYcOlVg1
Smalltalkの人はボコボコにされて
Smalltalkに自信を失って帰っちゃったからな

実際全然使われていない現実なわけだから
何を言っても説得力皆無だし机上の空論になるし
こいつマゾと思って皆で玩具にしたが
言うほどマゾじゃなかったのかもね

194デフォルトの名無しさん2016/01/23(土) 19:33:03.55ID:qHL6kF89
7 minutes of Pharo Smalltalk for Rubyists
https://www.youtube.com/watch?v=HOuZyOKa91o

Pharo - Welcome to Pharo!
http://pharo.org/

195デフォルトの名無しさん2016/01/23(土) 19:36:10.46ID:qHL6kF89

196デフォルトの名無しさん2016/01/23(土) 22:09:12.03ID:Sj7C6OsA

197デフォルトの名無しさん2016/01/30(土) 19:31:26.50ID:ZdxrrRsd
>>185
どんな汚いコードも読めることは大切だが
汚いコードは書くなよ…

まあその汚さをある程度許されるようになるオブジェクト指向は嫌いじゃない

198デフォルトの名無しさん2016/02/02(火) 15:15:07.68ID:Kj5oXuy8
>>197
いや、それでも人間クラスに
排便メソッドは必要だ。

199デフォルトの名無しさん2016/02/02(火) 21:15:38.34ID:7zvF4Jbc
刈羽 かりわ JR越後線

200デフォルトの名無しさん2016/02/03(水) 00:10:39.67ID:JLgoV6RT
>>198
そんな汚いコード書くと人間クラスを継承した美少女クラスで不都合が生じる

201デフォルトの名無しさん2016/02/03(水) 08:41:03.18ID:LaxmbkTJ
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...

202デフォルトの名無しさん2016/02/03(水) 08:41:21.38ID:LaxmbkTJ
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...

203デフォルトの名無しさん2016/02/03(水) 08:41:50.93ID:LaxmbkTJ
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...

204デフォルトの名無しさん2016/02/03(水) 08:42:43.86ID:v0iZc+aq
2回連投はよくみるけど3回は珍しいw

205デフォルトの名無しさん2016/02/03(水) 08:57:53.06ID:ffzzO4R/
あのさ…… どんな美少女もウンコするんだけど?

206デフォルトの名無しさん2016/02/03(水) 12:29:23.04ID:8IxY+gWE
人間クラスを継承せずに、
必要に応じて肛門を持たせればいいのでは?

この問題は、設計を誤ると修整が容易ではないと言ってるの?
論点は何?

207デフォルトの名無しさん2016/02/03(水) 23:54:09.81ID:NwkI7iYf
インスタンス化もせずにスレたてとな?

208デフォルトの名無しさん2016/02/04(木) 01:07:49.04ID:K1JlKV3Z
>>206
メンバーの種類を制限したり、メンバー間に何らかの制約を入れたクラスが欲しいときの
ベストプラクティスはっていう話かい?
言語によるけれど c++ のテンプレート使った方法が「Modern C++ Design」に書いてあった気はする。
有用かどうかは知らん。

209デフォルトの名無しさん2016/02/04(木) 21:35:19.21ID:RsO5DH3N
天使クラスを継承するともれなくおちんちんがついてくるぞ

210デフォルトの名無しさん2016/02/04(木) 23:19:55.12ID:NzupaiZw
滑ったな
どうすんのこれ

教えてよ
今すぐあんたが教えてよ

211デフォルトの名無しさん2016/02/04(木) 23:57:46.75ID:+xOonDYt
この板にいたなら知ってる人も多いだろうけど
このスレタイで建てる前に延々「オブジェクト指向は〜」ってスレ建てては
毎回、議論についてけなくなると「美少女クラスはうんこしない」みたいなこと書いて
荒らし逃げしてんだよこいつは。
んで、またそれ始めたから知ってる人々がサーッと逃げた。

212デフォルトの名無しさん2016/02/05(金) 01:20:03.95ID:tLv00hAm
そんな糞みたいな議論に持ってがれる時点でオブジェクト指向って切り口は何か問題があるんだろう。
もう少しバズワードと距離とれるスタンスが必要だったんじゃないのかね。

213デフォルトの名無しさん2016/02/05(金) 10:03:42.67ID:BBqIJr5G
継承とオブジェクト指向は直行してるんだけれどね

214デフォルトの名無しさん2016/02/05(金) 11:35:17.23ID:oOuE6OCl
美少女の件は、キモオタクラスからは美少女の排便参照不可にすれば解決。
また、キモオタクラスからは他のどの処理を呼んだ場合にもキモ例外が発生することにすれば万全。

215デフォルトの名無しさん2016/02/05(金) 18:19:15.34ID:PpryQyj4
>>212
美少女クラスはうんこしない(議論)

216デフォルトの名無しさん2016/02/05(金) 18:21:10.60ID:iF+JFr5E
排便量を0に設定すればいいだけだろ

217デフォルトの名無しさん2016/02/05(金) 19:07:26.01ID:PpryQyj4
排便量を(オブジェクト指向について僕ができる最大の議論)

218デフォルトの名無しさん2016/02/06(土) 18:12:26.16ID:T0MFScki
>>216
排便メソッドの引数にいちいち排便量足すのかよ…

219デフォルトの名無しさん2016/02/06(土) 22:09:32.02ID:64Pydz+a
排便量は流石にインスタンス変数で管理するだろ
トイレに行って半分だけ出すとかいうマニアックな機能をつけたいならともかく

220デフォルトの名無しさん2016/02/07(日) 00:09:19.21ID:smcac5RE
get_unko を仮想関数にして美少女クラスは 0 を返すようにすればよい。

221デフォルトの名無しさん2016/02/07(日) 01:39:26.20ID:R4NvrNxp
便秘のババアもget_unko()が0を返す件

222デフォルトの名無しさん2016/02/07(日) 11:30:22.21ID:smcac5RE
では君は美少女に何を返して欲しいのかね?

223デフォルトの名無しさん2016/02/07(日) 12:40:45.65ID:Dv+rVFbe
ワンチャン便秘のババアクラスを継承しても美少女クラスは成り立つのではないだろうか

224デフォルトの名無しさん2016/02/07(日) 13:03:58.71ID:R4NvrNxp
コーラックが欠かせない美少女w

225デフォルトの名無しさん2016/02/07(日) 13:35:31.74ID:fu54F6yL
美少女は便秘じゃない‥

226デフォルトの名無しさん2016/02/07(日) 15:37:37.70ID:TdnGwusc
日本の現場は永続化層が糞すぎてオブジェクトにマッピング出来ない
これじゃまともにOOPは出来ないから関数型でやらざるをえないんだね
別に関数型がOOPより優れてるという事ではなかったんだね

227デフォルトの名無しさん2016/02/07(日) 16:37:33.38ID:q/UCYgzT
>>226
Do you 意味?

228デフォルトの名無しさん2016/02/07(日) 17:52:18.95ID:TdnGwusc
>>227
OOPが愚かなのではなくDB設計者が愚かだったという事

229デフォルトの名無しさん2016/02/07(日) 18:21:09.45ID:smcac5RE
永続化層が糞でも関数型なら上手く行くならOOPより優れてるってことになるんでは?

230デフォルトの名無しさん2016/02/07(日) 18:38:59.78ID:AJ8T19vA
RDBにオブジェクトをそのまま永続化できないように、
RDBに関数を値として永続化できないんなら同じじゃん

231デフォルトの名無しさん2016/02/07(日) 19:08:05.31ID:v13MCL4I
永続化層に日本と海外で差があると?

232デフォルトの名無しさん2016/02/07(日) 19:24:56.69ID:TdnGwusc
>>229
うまくいくからやるというかそうせざるをえないからやる
そして一見うまくいっているように見えるが保守性も拡張性も悪い
製造が進むほど歪みが大きくなり破綻に近付く
OOPなら最後まで破綻しないが永続化層はOOPに譲歩して合わせなければならない
しかし日本ではDB中心のアプローチしか出来ない老害が支配的だからそれが出来ない
OOPが優れているのに足を引っ張る老害のせいでOOPはダメだという風評被害を受けている

233デフォルトの名無しさん2016/02/07(日) 19:35:10.05ID:R4NvrNxp
>>231
便秘が永続化するババアがいるのは日本だけだぞ?知らんかったんか?

234デフォルトの名無しさん2016/02/12(金) 08:39:25.91ID:NbTuOgvl
このスレもついに終わりか

235デフォルトの名無しさん2016/02/12(金) 11:27:46.75ID:3qOWj7pc
ウンコしない美少女のせい。

236デフォルトの名無しさん2016/02/16(火) 21:31:50.31ID:utvP1D7N
Mutableなオブジェクトは糞

237デフォルトの名無しさん2016/02/16(火) 21:34:55.97ID:utvP1D7N
DBには関係代数という理論的バックボーンが存在するからやり方の是非に真偽をつけられるが
Mutableなオブジェクトを許容するオブジェクト指向にはそれが無い
何でもできるかわりに何でもアリすぐる

238デフォルトの名無しさん2016/02/17(水) 01:36:09.44ID:quKaVBpr
>>237
日本語

239デフォルトの名無しさん2016/02/17(水) 02:04:23.05ID:zhj6/FLZ
美少女のこと語ろうよ。

240デフォルトの名無しさん2016/02/17(水) 07:33:48.75ID:UG2kvZqb
>>237は日本語としての意味はとらえやすいが

241デフォルトの名無しさん2016/02/17(水) 08:52:29.51ID:zhj6/FLZ
mutable なオブジェクトは糞。
美少女はウンコをしない。

オブジェクトの値が破壊的に変更出来てしまっては、
並列的な処理に容易に分割できないから、
マズイだろってな的話じゃないか?

242デフォルトの名無しさん2016/02/17(水) 20:12:53.87ID:sobQnjjW
例えばC++の入門書で必ずと言って良いほど載ってる複素数クラスComplexだけども、
たいてい代入演算詩(かコピーコンストラクタ)とか定義していやがる

藻前はa+2iに3+4iが代入されるのを見たことがあるのかっていうか、
Complexはもはや複素数ではない何か別の異形のものを表してしまっているのではないか、

243デフォルトの名無しさん2016/02/17(水) 20:14:41.29ID:sobQnjjW
スマンorz;
誤1:詩
正1:子

誤2: a+2i
正2: 1+2i

244デフォルトの名無しさん2016/02/17(水) 21:34:07.52ID:ZZNKbDIQ
1+2i + 3+4i = 4+6i

意外と便利かもしれないww

245デフォルトの名無しさん2016/02/17(水) 22:13:27.16ID:BpXyDkaJ
>>242
右辺値に対するoperator = をdeleteすればいいんでしょ?

246デフォルトの名無しさん2016/02/17(水) 22:14:08.77ID:xErgmETY
関数型とかいう産廃はイベントがないから使い物にならない
最近の大規模システムはみんなイベントがないと始まらない

247デフォルトの名無しさん2016/02/18(木) 12:36:55.18ID:9ZrwZ5jU
破壊的うんこが何だって?

248デフォルトの名無しさん2016/02/18(木) 15:25:24.63ID:eyX5WM+u
破壊的激臭は副作用を伴います。

249デフォルトの名無しさん2016/02/19(金) 14:34:33.73ID:hr949zjY
ちょっとだけ期待してスレひらいてみたら美少女のうんこ
λ計算すらないのかよ

250デフォルトの名無しさん2016/02/19(金) 23:39:47.24ID:Tb8XgjPy
良スレ、age!

251デフォルトの名無しさん2016/02/20(土) 12:33:38.85ID:njY71FFO
「美少女はうんこしない」という話を「美少女のうんこ」の話だと理解してしまうようなおっちょこちょいが
オブジェクト指向を理解出来るわけがない

252デフォルトの名無しさん2016/02/21(日) 00:15:17.53ID:Xn8BbX8n
unko.suru( bisyoujo );

253デフォルトの名無しさん2016/02/21(日) 13:27:24.70ID:82b/sWYC
うんこが美少女にナニをするのか

254デフォルトの名無しさん2016/03/10(木) 04:27:45.65ID:+d/NDXY7
依存型とか見てみると結局行き着く先は同じなんだなと思うけどどうよ

255デフォルトの名無しさん2016/03/11(金) 08:07:36.54ID:eLvrEEzR
どうしてハスケラってみんなキモいアニオタなの?

256デフォルトの名無しさん2016/03/11(金) 11:26:20.85ID:Kt9+s/wp
美少女はウンコするのかしないのか。
それでみんな行き詰まる。

257デフォルトの名無しさん2016/03/27(日) 21:21:44.90ID:N7IGtcj3
うんこをした時点で美少女ではない
しかし、うんこを我慢している美少女は萌えるのだ

258デフォルトの名無しさん2016/03/27(日) 23:58:39.00ID:9N4B8hjZ
うんこをしないのにうんこを我慢するわけないだろ
絶対にしないから美少女のうんこには底知れぬ価値があるのだ

259デフォルトの名無しさん2016/03/28(月) 00:59:02.52ID:oM2XJFW1
スコープだったり変数の生存期間を気にしたりってのは関数型だろうとオブジェクト指向だろうと
同じように気にする。
要はまとめ方ってだけの話。

260デフォルトの名無しさん2016/03/28(月) 02:53:49.59ID:T6p957gW
「野球もサッカーも球技だからおなじようなもの!」いただきましたw

261デフォルトの名無しさん2016/03/28(月) 04:13:13.96ID:soILvqz+
オブジェクト指向は役に立っている。
関数型言語はトイプログラムしか作れない。

262デフォルトの名無しさん2016/03/28(月) 10:46:29.30ID:U1rG/r8A
うんこの話題についてこれない人達が必死ですねw

263デフォルトの名無しさん2016/03/28(月) 10:53:32.07ID:Et7Dc3iM
うん、この話についてこれないよ

264デフォルトの名無しさん2016/03/28(月) 12:55:38.08ID:IcMNxByb
 僕みたいな芸人とか人前に出る人は、多かれ少なかれちょっとした発言や態度がネットで炎上したり、
罵詈雑言を浴びせられたりします。けれど、僕はそんなのにまったく腹も立たないし、
むしろオブジェクト指向を“カチャカチャ”してる人のほうが可哀想やなあ、と思うんです。

エラい人たちは、オブジェクト指向で時間を使うことはないでしょう。
だから僕は子どもにも「金持ちやエラい人のマネせえ、幸せな人のマネをせえよ」と言うようにしています。

はい、ここで問題です。オブジェクト指向でカチャカチャしてる人とそうでない人、どっちが幸せですか? 
そんなの100%、カチャカチャじゃないほうですよ。カチャカチャばっかしてたら不幸になることは、みんなわかってる。
 
「あの人幸せそう、エエ人やわ」と評判の20人のおばはんをモニタリングしてみてください。
ちゃんと挨拶して、言葉遣いも優しくて、お店でもエラそうな態度をとらない、とか共通項があるはずです。
逆に「あの人意地悪いわ、不幸やわ」と言われてる20人のおばはんを見ると、絶対カチャカチャみたいな行動をしてるはずです。
 
オブジェクト指向をカチャカチャして、クラスのインスタントを参照して「やったった感」を持ってるのかも
しれんけど、それでハッピーエンドの人生が待ってると思いますか? それよりも、もっとお友だちと
おしゃべりするとか、勉強するとか自分が幸せになる方法を考えるのがいいんじゃないですか。
 
オブジェクト指向をカチャカチャするのは、自分から不幸になりに行ってるようなものですよ。
あまりに生産性がなさすぎる。それを考えると可哀想やなと思えてくるんです。
僕は「日本は沈没しかけとる。こりゃどエラい時代が来るぞ……」とゾッとしたもんですが、
今まさにそれが当たり前のどエラい時代になりましたね。

265デフォルトの名無しさん2016/03/28(月) 15:14:15.80ID:qcCtZJbO
関数型は「このわかりにくい書き方をすればある問題が絶対発生しない!」だからなぁ…
いや、わかりにくいって時点でダメじゃんっつか。

266デフォルトの名無しさん2016/03/28(月) 17:25:44.03ID:soILvqz+
>>265
問題が絶対に発生しないなんてあるわけねえだろ
Haskellだってランタイムエラー出るときは出るわ

267デフォルトの名無しさん2016/03/29(火) 08:53:21.35ID:69Hzy87b
○○は学習コストがーとかわかりにくいってよく聞くけど、仕事でやってる人なら誰でもすぐわかるような(もしくはわかったつもりになれるような)技術だけ使い続けるより安心じゃね? 覚える価値があるなら特に。

268デフォルトの名無しさん2016/03/29(火) 12:04:28.51ID:4NQ/4meq
誰でもわかる

コストがかからない

人気がある

衰退しない

269デフォルトの名無しさん2016/03/29(火) 12:45:16.60ID:mGK48Xag
誰でもわかる

バカが混入する

コードが荒れてプロジェクトが燃える

マトモな技術者が新しい言語に逃げ出す

今、関数型言語界隈がstep 2のど真ん中w

270デフォルトの名無しさん2016/05/01(日) 09:43:39.37ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません

271ャfフォルトの名末ウしさん2016/05/11(水) 13:16:12.60ID:Knti35lY
オブジェクト指向って別に世の中の色んな事を記述するためのものじゃないよねw
pcの制御を記述するためのものじゃん

たぶん世の中 = pcって偏狭な人間が混乱してるだけなんじゃない?

272デフォルトの名無しさん2016/05/11(水) 14:16:15.77ID:1ZZ8JGEs
手続き型の一部に関数型っぽい書き方するのがカコイイという風潮が強くなってきて
熱心な子が意気込んで本格的なものに手を出してみるがわけわからなくて
酷い目に遭って帰ってきました、という感じじゃない?

273デフォルトの名無しさん2016/05/11(水) 15:35:01.38ID:l/Aku55r
誰でもわかる

コストがかからない

人を集めやすい一方、単価が下がる

人気が減る

274デフォルトの名無しさん2016/05/11(水) 16:50:49.33ID:Knti35lY
関数型言語って狭義のプログラミング言語じゃない気がするよ
アルゴリズムをシステマティックに表現するスクリプトに近い
コンピュータが手続きの連鎖で動いている以上、普通は関数を中心に記述するのはオーバーヘッドが大きすぎる
アルゴリズムが最適化される事で最終的な手続きが減るほど複雑なロジックを組む人が使えばいいと思う

275デフォルトの名無しさん2016/05/11(水) 17:31:14.42ID:DbNWRsPF
言語はJavaでもC#でも良いけど、凡人はデータとロジックは分けて扱う方が良いと思う
デザインパターンも、多少スキルのある人に任せて、自分では手を出すべきではない

アホが好き勝手に弄った挙げ句トンズラこいた、巨大でインスタンス変数やstatic変数を弄りまくる分岐とループにまみれたクラスの継承元と継承先を飛び回るのは、とてもツラい
何をもって安心すれば良いのかわからない
仕事戻りたくない

276デフォルトの名無しさん2016/05/11(水) 19:14:51.96ID:1ZZ8JGEs
名前空間で分けられるOOの方が構造化プログラミングより安全だ
バカを隔離するためにクラスを作ると昔の人は言った

277デフォルトの名無しさん2016/05/11(水) 19:20:32.44ID:4+flospS
おお、そのとおりだよw
末端のクラスは融通の効かないバカに作る。
そうすると見通しがいい。

278デフォルトの名無しさん2016/05/11(水) 19:55:02.71ID:AR7pBoGw
「言われたことをちゃんとこなすように」が正解。
途中途中で権限委譲しておかないと
上流がすべての決定をしなきゃいけなくなるので破綻する。

279デフォルトの名無しさん2016/05/11(水) 19:56:37.14ID:PuRMzRqm
バカは2chに集めて隠蔽

280デフォルトの名無しさん2016/05/21(土) 10:17:37.52ID:ikuIjUYo
>>276
藻前の悩みは名前空間の汚染しかないのカヨ…
クラスにして良いのはふるまいに状態を持たせる覚悟のある奴だけ

281デフォルトの名無しさん2016/05/21(土) 10:19:56.73ID:ikuIjUYo
もしくはクロージャとかfunctorを作りたいときとかだが
C++で作るクロージャとかfunctorは
クロージャとかfunctorですよみたいな顔して状態を隠し持ちかねないところが恐ろしい…

282デフォルトの名無しさん2016/05/23(月) 09:30:38.46ID:KJgou+2q
c++のクロージャってレキシカルスコープ以外の状態を持つのか?
後 functorもクロージャって全然違わない?

283デフォルトの名無しさん2016/05/23(月) 13:11:00.57ID:WJyvxaEH
Objectから派生したものは、メンバ変数とメソッド、つまり状態と処理を持つ

クラス・ラムダ・クロージャ・無名関数・Functor・ブロック・Proc、
どういう名前を付けようと、First Class(第1級)オブジェクトである

第1級オブジェクトとはオブジェクトなので、newできて、
簡単に持ち運びできるし、カプセル化してアクセス制御もできる

関数の引数として渡せて、戻り値にもできる

284デフォルトの名無しさん2016/05/23(月) 20:08:36.17ID:amMcSQyA
>>283
なにその中学生がぐぐりながら書いたような文章

285デフォルトの名無しさん2016/05/24(火) 22:30:45.96ID:uzPl1U54
ポケモンってオブジェクト指向が出て来たら
これで効率よくやってそうだよな

286デフォルトの名無しさん2016/05/24(火) 22:33:07.23ID:CFKzRNjb
モンスターは物じゃない
物じゃないんだ、友達なんだ

287デフォルトの名無しさん2016/05/24(火) 22:40:40.32ID:TKpsNxtt
ゲームはオブジェクト指向が適しているだろうが、
それでもやっぱり思考ロジック部分はオブジェクト指向じゃないさ。
ロジックを固めるフレームワークに設計は適している。

288デフォルトの名無しさん2016/05/24(火) 23:09:50.90ID:2+VBUZih
>>287
なにその小学生がヤフりながら書いたような文章

289デフォルトの名無しさん2016/05/24(火) 23:11:07.38ID:TKpsNxtt
>>288
こっちへおいでw

オブジェクト指向システムの設計 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1463663267/

290デフォルトの名無しさん2016/05/24(火) 23:33:41.15ID:2+VBUZih
100レス位まで読んだけどクッソどうでもいい事をぎゃーぎゃー言い合ってるだけやんけ

291デフォルトの名無しさん2016/05/25(水) 23:21:16.29ID:fBBvLnfI
>>287
はっきり言ってゲームにオブジェクト指向なんて適してない
すべてのオブジェクトをエクセルの縦の列に並べて
すべてのパラメータを横の列にすべて書き出す
こういう感じでチェックできるプログラムにしないと完成しない

292デフォルトの名無しさん2016/05/26(木) 13:53:37.27ID:gY5ZvMkJ
オブジェクト指向なんて意味ないよな
スーパーマリオもテトリスもプレイに必要なのはエクセル

293デフォルトの名無しさん2016/05/26(木) 20:55:10.22ID:cAjDmLh7
ネタとしても面白くないなぁw
オブジェクト指向が使われてるのを
目の前にして適していないと言われてもねw

294デフォルトの名無しさん2016/05/26(木) 22:03:14.61ID:cgICe8ci
ここからオブジェクト指向を見た事がない人だけがオブジェクト指向を批判出来るスレになります

295デフォルトの名無しさん2016/05/26(木) 23:27:22.03ID:NlrO/xzC
オブジェクト指向は重複したメソッドが発生する。こういうのは無駄。

coffee.owner=human
coffee.drink()
human.drink(coffee)

296デフォルトの名無しさん2016/05/27(金) 00:14:26.80ID:miERtZSj
>coffee.owner=human
>coffee.drink()
いやいやいや

297デフォルトの名無しさん2016/05/27(金) 04:22:09.83ID:WrCIRuds
オブジェクト指向
「白痴の面倒までみれねーよww」

298デフォルトの名無しさん2016/05/27(金) 10:57:13.85ID:q3bsRKFz
オブジェクト指向が面倒を見なくても
白痴はオブジェクトらしきものをプロジェクトに残してくんだ・・・

299デフォルトの名無しさん2016/05/27(金) 11:13:57.69ID:y0JFsOhL
すべては名前
きちんとした、名前
名前、名前、名前
名前思考でお願いします
機能と名前が違うのがありすぎ
国語力の欠如した人のプログラムでは
反対語で書く奴もいるし
動詞を、名詞で隠す奴

300デフォルトの名無しさん2016/05/27(金) 12:19:19.41ID:bYLZABmN
正しくオブジェクト指向を使ったMacOSXは16年間で11回メジャーアップデートし
オブジェクト差し替えでiOSに派生しiPhoneやiPad、果てはAppleTVにも使われ

一方、間違ったオブジェクト指向を使ってしまったWindowsは
15年間で5回しかアップデートできない上に不具合オンパレードで阿鼻叫喚
ユーザが一つ前のバージョンしか信用しないので常に5年前のバージョンが大半
そして強硬策「いま入れますか、あとにしますか?」地獄へ。

後者をオブジェクト指向だと思ってる奴はそりゃ全力で否定せざる負えないわな。

301デフォルトの名無しさん2016/05/27(金) 12:22:01.29ID:IqC0GNPs
ここオブジェクト指向スレやで
国語力ないんかな

302デフォルトの名無しさん2016/05/27(金) 12:23:05.27ID:DRPbKmeh
iOSとかMacのメジャーアップデートって完全に人柱じゃないですかヤダー

303デフォルトの名無しさん2016/05/27(金) 12:53:43.63ID:sJ1qkk5q
最近推し激しいが今のiOSっていいのか?
まぁiOS使うくらいならLinux使うけどw

304デフォルトの名無しさん2016/05/28(土) 21:36:07.37ID:COiCoXN6
どうなんだろうか。
「お前のは本当のオブジェクト指向じゃない」だとか不毛な論争の火種にしか
なってない気はする。

もうちょっとコードベースのモジュール化やコードの隔離方法なんかを議論した方がよっぽど建設的。

305デフォルトの名無しさん2016/05/29(日) 05:26:16.06ID:uH1/jPAH
>>300
> 一方、間違ったオブジェクト指向を使ってしまったWindowsは

最近2週間で一回ぐらいのペースで、開発者版リリースが行われてる。
これはMSアカウントを作るだけで一般の人が入手できる。
これって正しくオブジェクト指向を使ったからだろうね。

306デフォルトの名無しさん2016/05/29(日) 08:08:38.53ID:1ogDAOAr
何とも言えんね
ぶっちゃけいまのmsのアップデートはデバッグをユーザに押し付けてるようにしか見えんし
よくわからない用語で煙に巻くって点がオブジェクト指向だね

307デフォルトの名無しさん2016/05/29(日) 12:54:56.46ID:uH1/jPAH
オブジェクト指向だから早くリリースしてるんでしょ?w

308デフォルトの名無しさん2016/05/29(日) 13:01:06.42ID:1rU4/WXO
既存のクラスはなるべくいじらずそのまま静かに置いておく
オブジェ思考

309デフォルトの名無しさん2016/05/29(日) 13:23:11.98ID:1ogDAOAr
私のオブジェクト指向は54万です

310デフォルトの名無しさん2016/05/29(日) 14:34:58.16ID:aa6iTjg/
"クラスとは構造体に操作する関数がついたもの"と
"クラスはメッセージコマンドを受けて動く"の違い。
前者はプログラマが陥りがちなタイプ数が少ない暗号みたいなパーツの組み合わせと
責任の所在がわからない動作をぜひ作り込んでくれと言わんばかりのジャンクで
まさにそのとおりのジャンクができた。

311デフォルトの名無しさん2016/05/29(日) 14:40:26.75ID:EevS3JTU
>>310
クラスと(そのインスタンスとしての)オブジェクトとの区別がつかない人間は永久にROMってろ

312デフォルトの名無しさん2016/05/29(日) 15:26:41.75ID:aa6iTjg/
きみが棲んでるジャンク界隈がそういう仕様なのは知ってるけど
こっちはクラスにメッセージ送るとクラスがインスタンス作るんだ。
うん。

313デフォルトの名無しさん2016/05/29(日) 15:50:36.54ID:abg0RIhz
>>312
クラスと(そのインスタンスとしての)オブジェクトとの区別がつかない人間は永久にROMってろ

314デフォルトの名無しさん2016/05/29(日) 16:59:56.20ID:aa6iTjg/
高度すぎたか。

315デフォルトの名無しさん2016/05/29(日) 17:04:53.73ID:9gAtgMOC
いちいち()で囲まなくてもよくない?
無駄な仕事多くしてそう。(どうでもいいけど)

316デフォルトの名無しさん2016/05/29(日) 21:48:27.53ID:T+KHRUkH
クラス厨は害悪

317デフォルトの名無しさん2016/07/08(金) 22:17:20.19ID:gy2KRr8C
高度すぎたかwwwwwwうけるwww

318デフォルトの名無しさん2016/07/08(金) 22:29:11.47ID:zZ/OP7I+
半年ORMれ

319デフォルトの名無しさん2016/07/09(土) 11:06:02.42ID:lXMMLrdi
オブジェクト指向とかクラスが分からないのは多分メモリ周りのことが全然わからないからなんだろうな。
アセンブラからやれとは言わんが、メモリアロケータくらい自作したらオブジェクト指向がいかに理に叶ったものかわかってくるんだけど。

320デフォルトの名無しさん2016/07/09(土) 11:22:11.07ID:3DBY5ZwO
メモリアロケータを自作しないと理解できないってのもなぁ(苦笑)

321デフォルトの名無しさん2016/07/09(土) 12:11:02.75ID:vM1Dv6Aj
オブジェクト指向がわからない人は関数型を勉強してないんだろうな
手続き型はオブジェクト指向のメリットを潰してしまうから手続き型の書き方しか知らないとオブジェクト指向は身に付かない

322デフォルトの名無しさん2016/07/09(土) 12:19:20.59ID:afhBOa0Z
データのカプセル化ができてれば手続き型でもオブジェクト指向でも関数型でもいい気がするが

323デフォルトの名無しさん2016/07/09(土) 12:19:29.29ID:EzNW6797
分からない人がいて欲しいという強い願望w

324デフォルトの名無しさん2016/07/09(土) 13:53:33.65ID:dEWSYkKq
オブジェクト指向つっても当初の「継承で差分プログラミングうまー」
みたいなのは否定されてきたからな。

入門書だと哺乳類クラスから犬クラスと猫クラスとかやってるけど、
動物が沢山出てくるゲームや動物病院のカルテシステムを開発するとして、
いちいち動物種ごとにクラスを作ることはしないだろう。

インターフェイス以外の継承は最小限にというのを教えないと。
でも未だに入門書レベルだと著者が勘違いしている。

325デフォルトの名無しさん2016/07/09(土) 18:59:46.91ID:akOZxrcr
>>324
かといって、というか
継承ってのがどんなものなのか「だけ」を説明するのなら
やっぱ犬猫でもいいんでねえのって俺は今は思う

継承をどう使って設計していくかってのはまた先の話
親、子A、子Bという三者の関係「だけ」示すのが動物犬猫

326デフォルトの名無しさん2016/07/09(土) 19:23:57.17ID:dEWSYkKq
>>325
例自体は反対しないよ。
でもそれで継承というものがどういうものかは分かっても、
継承がどういうときに使うべき物なのかは分からない。
そこまで教えてる本ってあまりないね。

327名無しさん@そうだ選挙に行こう! Go to vote!2016/07/10(日) 18:09:32.57ID:RTWM7o1I
(HP)をプロパティで持った「キャラクター」クラスを作って
それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
これを再利用して、「武闘家」クラスを作れば
おなじ"たたかう"メソッドで武闘家はてつのつめで戦うようにできる。
さらには(MP)と"まほう"メソッドを追加で「魔法使い」クラスが…

ってこの辺りで便利さがわかると同時に
(MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって
継承の不便さが浮き彫りになってくるという。
全部独立パーツでそれを必要に応じて束ねて使っていればもっと取り回しが楽だったり

328デフォルトの名無しさん2016/07/10(日) 20:28:28.05ID:4zLRjbrA
実装の再利用は継承でやるよりtraitが便利
smalltalkで発表されて、PHPに輸入されて、後は知らないが

329デフォルトの名無しさん2016/07/10(日) 22:16:26.35ID:/17c9zmN
Scalaとかの静的型言語がただのmixinをあえてtraitsと呼ぶのは誤解を招くよなぁ…

330デフォルトの名無しさん2016/07/10(日) 22:21:00.81ID:SLnFWOAS
>>327
> それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
> これを再利用して、「武闘家」クラスを作れば

武闘家は戦士を継承していません。

331デフォルトの名無しさん2016/07/10(日) 22:46:02.92ID:YDU79Arx
そもそもオブジェクトの粒度が高すぎんだよ
アビリティクラス的なものを作るべき

332デフォルトの名無しさん2016/07/10(日) 23:04:09.88ID:tx16mOUk
> ってこの辺りで便利さがわかると同時に
> (MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって

全然混乱しないなw

どこにつけるかなんてシステム次第だが
ドラクエ方式であればMPプロパティはキャラクタークラスで
魔法メソッドなんていうのは、特技メソッドの表示名の違いでしか無い。

333デフォルトの名無しさん2016/07/11(月) 08:10:49.21ID:BGpqEWk7
継承ベースだと
キャラクター>戦士>武闘家というクラス階層で
90年代のバカみたいな継承信奉してると武闘家の後ろとかに
"魔法使い"作って泥沼に嵌まるんだよな。
継承=オブジェクト指向だから。

334デフォルトの名無しさん2016/07/11(月) 08:24:29.03ID:DT6nTI14
継承を使いこなせないのは要するに馬鹿なんだよ
オブジェクト指向も関係なくプログラミングの基礎が出来てないから

335デフォルトの名無しさん2016/07/11(月) 09:34:50.03ID:c813o9It
>>333
> キャラクター>戦士>武闘家というクラス階層で
それはどう考えても間違った継承だろ。

継承信奉以前の問題で、継承関係にないものを
継承しているのは、お前が馬鹿だからってだけなんだが。

336デフォルトの名無しさん2016/07/11(月) 10:06:35.54ID:BGpqEWk7
「よくバカな奴が"延々と"を"永遠と"って書いてたりするよねー」
「え、おまえ"延々と"を"永遠と"って書いてんの!?バカじゃね!
俺なんか絶対そんな間違いしないね!!おまえバカだろ!バーカwww」
「えっ?」

337デフォルトの名無しさん2016/07/11(月) 11:14:13.38ID:v8BjKTdy
戸惑いのバカwww

338デフォルトの名無しさん2016/07/11(月) 14:14:51.31ID:BGpqEWk7
えっ?

339デフォルトの名無しさん2016/07/11(月) 21:41:33.01ID:K+QqD/bm
>>326
そやねぇ
あまりないというか、見たことが無いw

あともしそれを書いてる本があっても
入門者には意外と伝わらないと思う

それを必要とする状況まで陥ってないと
デザパタ本ですらろくに伝わってない

困って、考えて、本読むという順じゃないと多分ダメ
…多分だけど

340デフォルトの名無しさん2016/07/11(月) 22:00:34.80ID:DT6nTI14
目的に合わせて正しく抽象化出来れば継承関係は自然に導かれるはず
継承だけに着目して教える/教わるという考えがそもそもおかしい

341デフォルトの名無しさん2016/07/11(月) 22:37:59.77ID:NMj8cyvT
概念の継承関係とコードの継承関係を同じ目線で見ると失敗する

342デフォルトの名無しさん2016/07/11(月) 22:42:17.81ID:DT6nTI14
>>341
それ抽象化が間違ってるからやw

343デフォルトの名無しさん2016/07/12(火) 00:05:30.28ID:dw2VnrEM
>>342
過度な期待期に入った新人君かな

344デフォルトの名無しさん2016/07/12(火) 07:21:41.32ID:jrBRhCE1
自分のモデリングの間違いを言語機能のせいにする
な?要するに馬鹿なんだよ

345デフォルトの名無しさん2016/07/12(火) 08:27:37.68ID:URFMxuYq
オブジェクト指向もずいぶん枯れたわけだし、アンチパターンの確認から入るってのも悪くはない。

346デフォルトの名無しさん2016/07/12(火) 09:41:37.70ID:Q/mNeBI3
正しく抽象化できれば正しくできる、
って意味のないこと言ってどうすんの?

その正しく抽象化する方法が問題なんでしょ?

347デフォルトの名無しさん2016/07/12(火) 09:54:02.01ID:DvYXCZnM
>>328
その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入りしたのでは?

348デフォルトの名無しさん2016/07/12(火) 10:24:32.15ID:QmnH/+e2
たとえば魔法使いと魔法という概念が"新たに生まれた"場合
それは魔法を使える魔法使いのみが使うから魔法使いクラスの固有プロパティなのか。
それとも、使えないだけですべてのキャラクターが持つ基礎パラメータなのか。
すべての基底クラスにMPデータフィールドを追加していいのか。
運を消費して奇跡を起こす聖者、MPやHPを消費して治療を行う僧侶などが
あたらしく出てきた時はどこにパラメータをつけて相互管理すればいいのか。

現実でその時は"ただしい"と思った抽象化が根底から揺さぶられることはいくらでもあって
(固定価格に追加される消費税、新たに追加される福祉控除項目、すべてを一元化しようというマイナンバー…)
まず、そういう認識すら持たずに「ちゃんとちゅうしょうかしないからだよ
ぼくならなんでもただしくちゅうしょうかできるからきみたちよりえらいのさ!」とか
うそぶいている時点で君はいま指をさして静かに嗤われてるのを自覚した方がいい。

349デフォルトの名無しさん2016/07/12(火) 12:19:52.07ID:4cCOY98n
>>348
要するに正しく抽象化モデリング出来てないだけだなw
お前が馬鹿な理由にオブジェクト指向も継承も全く関係ないわw

350デフォルトの名無しさん2016/07/12(火) 12:27:09.89ID:7TrvIOou
>>347
> その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入り

それもありそうな話で笑えるけど、traitsに限ってはModule#mixという名前で同機構の導入が
検討されたものの、既存の機能との整合性で致命的な問題が見つかって結局断念したらしい。
www.rubyist.net/~matz/20100617.html
http://d.hatena.ne.jp/nagachika/20111003/ruby_trunk_changes_33379_33380

351デフォルトの名無しさん2016/07/12(火) 13:18:23.38ID:+8oNQ71Y
振る舞いの抽象化なら型クラスやインターフェイスを使えばいいし、実装の再利用ならtraitのような仕組みを使えばいい
継承による型の階層構造なんて邪魔にしかならんわ

352デフォルトの名無しさん2016/07/12(火) 17:45:58.73ID:h4Vj1dwQ
モデリングに間違いがなくかつモデルが未来永劫変化しないならID:4cC坊やの言い分は正しいね
そんな世界がやってくるといいね

353デフォルトの名無しさん2016/07/12(火) 18:38:57.22ID:J7TxVIFH
とりあえず>>348で言われてることを具体的にイメージできないぐらい"疎い"ってのだけはわかるよね…
多くのクラスに関わるモデリングを変えなきゃいけないぐらい大きな変更の例が列挙されていて
オブジェクト指向の黎明期と違って、オブジェクト指向があたりまえの空気になった現代だからこそ
強力な束縛を持つ継承がシステム組み替えの際の足かせになってきてるって話の流れにまったくついていけてない。

354デフォルトの名無しさん2016/07/12(火) 18:53:29.94ID:jrBRhCE1
お前らのは抽象化でなく、ただのぼんやりしたイメージ
いわば妄想プログラミングだなw
お前らみたいな馬鹿がまともに設計出来ないから
言語が馬鹿を縛れるような進化が求められてるだけなんだぜ
ダメなのは言語ではないお前ら自身だ

355デフォルトの名無しさん2016/07/12(火) 20:11:55.18ID:IS6BTglq
キッズは夢を見るものさ

356デフォルトの名無しさん2016/07/12(火) 20:31:52.34ID:Vv72dLZO
継承にしろオブジェクト指向にしろ
コードを簡潔にしたり、仕様変更に強くするために利用すべき技術だから
「猫と犬は哺乳類クラスを継承する、なぜなら猫も犬も哺乳類だから」ってのは
熟練したプログラマの発想とはだいぶ離れているんだよね
熟練したプログラマは書かなければならないコードが頭に浮かんでいて
それを何処に書くかという整理整頓の意味で継承などの技術を使っているわけで
結局OOは整理整頓術で、どう整理したらプログラミングの効率が上がるかというだけの話
それ以上の意味はない
が、整理整頓は非常に奥が深い

357デフォルトの名無しさん2016/07/12(火) 23:27:20.00ID:4M8hLvVe
そもそも哺乳類と言うのが最初にあって
そこから猫や犬が生まれたわけじゃないからな。

最初に猫や犬があって、そこから共通する特徴を
もっているものを哺乳類と分類した。

どっちかと言ったら名前空間みたいなもので
継承関係じゃない。(だけど理解するのに役立つ)

で実際のプログラミングでは哺乳類がどうとかいう話とは関係なく、
継承構造は役に立つもの

358デフォルトの名無しさん2016/07/12(火) 23:28:32.23ID:4M8hLvVe
>>352
> モデリングに間違いがなくかつモデルが未来永劫変化しないなら

変化するからこそリファクタリングが重要なんだよね。

リファクタリングは汚いコードを修正することじゃなくて
過去の時点では正しかった設計を、
今の時点の変化に合わせて設計を変えることだから。

359デフォルトの名無しさん2016/07/13(水) 08:17:59.46ID:+CQztjRc
継承はそういう時に身動き取れなくなるから困る

360デフォルトの名無しさん2016/07/13(水) 09:38:03.87ID:NLZRxEVY
359 名前:デフォルトの名無しさん[sage] 投稿日:2016/07/13(水) 08:17:59.46 ID:+CQztjRc
継承はそういう時に身動き取れなくなるから困る

361デフォルトの名無しさん2016/07/13(水) 12:39:18.51ID:Fh2kjKhX
大事な事だから2回言いました

362デフォルトの名無しさん2016/07/14(木) 19:03:55.13ID:sG4kt79u
割とマジで「オブジェクト指向って継承って奴だろ」な人で
言われてることがまったくわからなくてパニクってるんじゃないかと。

363デフォルトの名無しさん2016/07/14(木) 20:00:26.88ID:05a8wJuJ
原始時代じゃあるまいしそんなプログラマがいるのか?
にわかに信じがたいな

364デフォルトの名無しさん2016/07/14(木) 22:29:42.85ID:mVH/XKPM
美少女が人間クラスから継承できない問題は
どうなったんだ?
それでオブジェクト指向は破綻したときいたが。

365デフォルトの名無しさん2016/07/14(木) 23:30:26.34ID:0cl6EhrX
ぱっと思いつくだけでも

Unkoオブジェクトに量の概念をもたせて量がゼロのうんこを作るかNullObject的な対処をする

うんこしないAngelクラスを継承する

排便の概念を抽象化したメソッドを用意してうんこ以外の可能性を見出す

などなど
なんとでもなるやろ

366デフォルトの名無しさん2016/07/15(金) 05:19:16.25ID:Md4pEzwy
UnkoのサブクラスとしてOhgonクラスを実装するんや!

367デフォルトの名無しさん2016/07/15(金) 12:49:22.15ID:L1jCNFuA
美少女はウンコをしない
この「しない」という所が美しいんじゃないか
汚れなき乙女を全うする意志の問題だ
これが「出来ない」という物理的構造に由来する問題に成り下がってしまったら
何の味わいもなくなるだろ
チンコ勃たんわ

368デフォルトの名無しさん2016/07/15(金) 14:40:06.76ID:d/Zl1fgq
頭の悪い人の悲しいところは
頭の悪い冗談を好んで言い続けるということだ
飽きもせずに繰り返し繰り返し何度も何度も…

369デフォルトの名無しさん2016/07/15(金) 22:04:56.17ID:iR/HdeCl
これは頭の良い冗談に期待w

370デフォルトの名無しさん2016/07/15(金) 22:47:24.35ID:ibKxDQPd
美少年にクラスチェンジすることで破綻せずにハッテン

371デフォルトの名無しさん2016/07/15(金) 23:49:57.52ID:80GKY2p2
リフレクションで解体して色々いじりたい

372デフォルトの名無しさん2016/07/16(土) 01:53:47.85ID:Bfovl8qZ
面白くないことに気づこうね

373デフォルトの名無しさん2016/07/16(土) 02:59:56.46ID:0ciAe/St
というか>>211で書かれてるとおりをまたワンパターンで始めただけだしな。

374デフォルトの名無しさん2016/07/16(土) 07:28:07.42ID:CNSBQzp5
美少女ウンコ問題は高度すぎて解決の糸口すら見つからないもんな
ついていけない奴の気持ちもわかる

375デフォルトの名無しさん2016/07/16(土) 09:09:49.16ID:DegzgE4N
ちょっとしたネタ書き込みにすら
知能やセンスがもろ出しになっちゃうから悲しいね

>>372
それ言っちゃうと今度は意地になってレスし続ける可能性

376デフォルトの名無しさん2016/07/16(土) 09:38:23.65ID:D3kHuod4
>>372
面白くない→顔が白くない→色白でない→実は美少女ではない→ウンコしても問題ない

なるほど要件の再定義によって解決か

377デフォルトの名無しさん2016/07/16(土) 10:06:22.50ID:BhIXbiPC
なんでよ褐色美少女最高じゃん

378デフォルトの名無しさん2016/07/16(土) 10:11:41.75ID:6YOlPtSF
ワンパターンっすなぁ

379デフォルトの名無しさん2016/07/16(土) 12:26:01.17ID:3oB/Pjks
解決しとらんのにワンパターンもくそもないだろ
根気のない奴だなあ

380デフォルトの名無しさん2016/07/16(土) 20:05:26.83ID:kkC3KqZT
解決できると思ってるのが間違いだと気付くといいよ

分類学的な階層を作っても「書いた人どう対象を捉えているか」というどうでもいいことしかソースに残せない
鳩クラスと鹿クラスが同じ親クラスを持ってて、ニワトリクラスとブタクラスが同じ親クラスを持ってて、
一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ

そういう情報を一切俎上に出さずにAはBの子クラスであるべきか否かなんて話すのは無意味
そういう文脈をソースに組み込む必要があるかもまず考えないといけない

381デフォルトの名無しさん2016/07/16(土) 21:15:33.39ID:CNSBQzp5
なるほど
現状の研究成果に比べると一風変わった意見だが私は興味深く聞かせてもらったよ
つまり君はウンコをしない美少女が人間クラスから派生されるべきコンテキストについて
もっと掘り下げた議論をすべきだと言うのだな
ところで君はそういう文脈をソースに組みこむ必要があるかについては
どんな考えを持っているのかね?

382デフォルトの名無しさん2016/07/16(土) 21:41:47.94ID:LbU9Boej
ユーザーはうんこ機能なんか求めちゃいない。

383デフォルトの名無しさん2016/07/17(日) 01:46:14.62ID:MIDkP6ou
生成するUnkoオブジェクトのtasteフィールドが最大値になるだけ

384デフォルトの名無しさん2016/07/17(日) 05:00:03.09ID:nDXHZDmA
>>380
いやねーだろw その手のシステムで種ごとにクラスを分けるわけがない。
全部同じクラスだろ。

385デフォルトの名無しさん2016/07/17(日) 10:38:54.12ID:libZCVLZ
まあなんでも抽象化すればいいってもんではないわな。
物質は究極的にはクォークのセットだからって、そのまま実装したらそりゃ破綻するだろうし。

386デフォルトの名無しさん2016/07/17(日) 12:43:31.14ID:gClFyV8u
君それは細分化やないか
美少女のウンコふりかけ食わしたろか

387デフォルトの名無しさん2016/07/17(日) 13:29:48.60ID:okE8dWNU
同じ型のインスタンスの振る舞いをポリモーフィズムさせるのは、

・継承
・委譲
・switch文
・関数ポインタ、ラムダ式
・別途スクリプトなどを用意する

などの方法がある

388デフォルトの名無しさん2016/07/17(日) 13:57:59.74ID:PHnZw+de
ウンコって言いたい年頃なんだろうな

389デフォルトの名無しさん2016/07/17(日) 15:27:54.18ID:+aWd02nI
>>384
データはDB管理かもしれないしDBに沿った構成になるかもしれない
UIで必要であれば 380 の構成もありえるし
だから 380 は文脈と言ってるんだろうに

390デフォルトの名無しさん2016/07/17(日) 15:59:55.36ID:gClFyV8u
どんな文脈やねんw
肉屋の仕入れアプリでブタにダンスでもさせる気なんかw
そんなら俺はウンコを我慢する美少女の方がええわwww
何でも文脈言えばええっちゅーもんちゃうでホンマ

391デフォルトの名無しさん2016/07/17(日) 16:05:40.68ID:q7clyz/N
>>389
いや、当然RDBMSでデータ管理しているという前提だが?

392デフォルトの名無しさん2016/07/17(日) 21:43:01.45ID:SWVEU9WP
クソスレじゃねーか!

393デフォルトの名無しさん2016/07/20(水) 23:08:50.86ID:0oomM0jq
計算式が面倒になったら
またどうせオブジェクト指向になるんだろ

394デフォルトの名無しさん2016/07/20(水) 23:42:38.15ID:E+SEwayU
>>380
> 一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ

見たこと無いが「あり得る」という話なら、
C言語でgotoばっかり使うってのもあり得るよ。

C言語なのに、オレオレライブラリとマクロを使って
COBOLみたいに使うことだって有り得るよ。

お前の大好きな言語をクソみたいな使い方する方法だって有り得るよ。
有り得るかどうかを語るのって意味なくね?

クソみたいなコードを書くのは書いた人間が悪いのであって
言語の問題でもオブジェクト指向の問題でもない。

395デフォルトの名無しさん2016/07/21(木) 02:05:10.33ID:pVvcsTGR
>>393
というか、人間がプログラムをユニット単位に分けた時に
"こいつはこういうコマンドを与えれば勝手にそれをやる単位"って
分け方をすれば『人間がわかりやすい』だろう。ってのが
いまあたりまえのメソッド型オブジェクト指向なんで、
こうすれば"副作用"が出ない!って計算式の方はむしろ
問題が起きないように『機械の都合に人間が合わせる』流れで
たぶん遠からず下火になるわ、あれ。つかもうなった感じ。

むしろ、アルゴリズム解析みたいなのを開発環境がやって
こうすると副作用が最小になるっぽいですよ?って
AIがサジェスチョンするようになんじゃね?つか。

396デフォルトの名無しさん2016/07/21(木) 12:07:59.69ID:gJ3egAPE
それはどうかわからんよ
もともと機械の都合で生まれた静的型が
実は人間にも優しいってことで大人気だし
本来静的型じゃなくても動く筈の動的型言語も
どんどん静的型の機能を取り入れていくのが今のトレンドでしょ

それに、副作用の無い関数型は全然機械の都合じゃないし
あれは数学の理論とかから生まれたような理論先行のもので
コンピュータの動作原理を考えたら、むしろ副作用ありの方が
自然だと思う

副作用ありの静的型言語が一番機械の都合に合っていて
その金字塔がC言語であり、今でも使われ続けている
主にローレベルなことやOSの開発やドライバの開発などに
使われているのは、それだけ機械の都合にあっているから
昔の言語なのに破たんせずに使われ続けているのは
それだけコンピュータの動作原理を素直に表現していて
流行り廃りというものと無縁だから

397デフォルトの名無しさん2016/07/21(木) 16:36:54.23ID:KvWRwuEL
Cで書いたコードが速く動くようにCPUやOSが設計されているという面も
あるからぬ…だからって新世代の言語に合わせてCPUやOSを作り直すか?
といわれたらそんなことは起こりっこないと断言できるが

398デフォルトの名無しさん2016/07/21(木) 17:56:06.90ID:9dMGMxaj
おまいさんそれは逆ですぜ。
Cがアセンブラに馴染み易く出来てるんですぜ。
でも本来はintelの系統じゃ無くて、
モートローラとかミニコンから派生した石に馴染み易く出来てるんですがね。
まあ、Cが最初からintelの石用に作ってたら、
もう少し違った構文になってたかもね。

399デフォルトの名無しさん2016/07/21(木) 18:08:41.00ID:9dMGMxaj
アセンブラやってた連中が、構造化プログラミングを提唱して、
プログラムを小さな塊の組み合わせで作る様になったんで、
同時期に条文分岐やサブルーチンの扱いをマクロ処理を被せて
読み易くするのが流行ったんだよ。
それをもっと書き易くして行って出て来たのがコンパイラ言語
いわゆる高級言語だけど、簡単なアセンブラへの置き換えしかしてなかった。
今ではそこから更にそれら高級言語を分かり易く記述出来る高次な高級言語が流行ってるけどね。

400デフォルトの名無しさん2016/07/21(木) 18:19:01.28ID:9dMGMxaj
例えば、hoge+とかやれば自動的にインクリメントしてくれる仕様だって、そういうアセンブラ命令があったからなんだぜ。

401デフォルトの名無しさん2016/07/21(木) 18:38:56.73ID:fNq3MD0e
>>397
>Cで書いたコードが速く動くようにCPUやOSが設計されている
何を根拠に?

402デフォルトの名無しさん2016/07/21(木) 19:51:04.04ID:zfBmPUKU
>>399
時系列がぐちゃぐちゃじゃね?
最初の高級言語と呼べるものはFortranだけど、
数式を人間フレンドリーな形で記述できるのが売りだった。
Fortranはアセンブラの簡単な置き換えレベルではないでしょ。

構造化プログラミングはALGOLからだろうけど、
Fortranより後だし、Cのようなレベルに達するのはもっと先。

403デフォルトの名無しさん2016/07/21(木) 20:06:28.29ID:ZXk7cAfY
歴史しらないバカばっかw

404デフォルトの名無しさん2016/07/21(木) 20:28:04.90ID:IpsfD7Z7
自信を持って声を大きくして叫び続ければやがてそれが歴史となる

405デフォルトの名無しさん2016/07/21(木) 20:37:00.07ID:m+nIkrs4
後の人々はそれをこう呼んだ、すなわち黒歴史と……

406デフォルトの名無しさん2016/07/21(木) 21:20:03.86ID:gJ3egAPE
Cの何がすごいって、メモリに対する考え方がシンプルで凄い
構造体のメンバは単なる先頭からのオフセットだし
配列の添え字も先頭からのオフセットでしかない
しかも配列とポインタはある種の互換性がある
だから何だかよくわからないメモリブロックを
構造体にキャストしてアクセスできたり
同様に単なるメモリブロックを配列としてアクセスできたりする
メモリの扱いがとにかくシンプルでありつつ強力なアクセス方法があり応用が利く
こういうことができる言語はあまりない
C++ですらvtableが入ってたらもうオフセットずれるし

407デフォルトの名無しさん2016/07/21(木) 21:42:38.85ID:vaQfL518
>>406
言語の実装がシンプルなのと、その言語を
使ってアプリを実装するっていうのは別の話で
なんでも一つの機能で出来てしまう言語っていうのは、
冗長で意味代わりにくいコードになりがちなんだよ。

例えばシンプルと言うのならアセンブラが一番シンプル
条件判定命令と条件ジャンプ命令だけでループを表現できてしまう。

プログラム言語っていうのは、特定のパターンに対して
専用の命令を作ることでコードの可読性を高くしてきた。
これは圧縮の仕組みにも近い。特定のパターンに短い単語を当てはめて
簡潔に書くことができるようになる。

条件判定命令と条件ジャンプ命令さえあれば十分であっても
そこからforパターンやwhileパターンを見つけ、専用の単語に
割り当てることで可読性が高くなる。

408デフォルトの名無しさん2016/07/21(木) 22:34:35.81ID:9dMGMxaj
だからCだけが生き残ったんだろ?
大衆プログラマが望んだ形で変化した結果だからな。

409デフォルトの名無しさん2016/07/21(木) 23:16:46.30ID:vaQfL518
生き残ったっていうのは古い言語とくらべての話?
確かにFortlanとかPascalは消えた。
多くの優れた言語が生まれている中、今でも通用するのは
C言語ぐらいだと思うが。

410デフォルトの名無しさん2016/07/21(木) 23:17:21.89ID:zfBmPUKU
どちらも消えてねーだろw

411デフォルトの名無しさん2016/07/21(木) 23:21:30.21ID:vaQfL518
>>410
第三者の人が検証できるランキングとかある?
そりゃどこか目につかないところではあるかもしれないが、
例えばその言語で仕事したいと思ったとき
探せ出せないような言語は消えたと思っていいだろう。

412デフォルトの名無しさん2016/07/21(木) 23:39:22.80ID:zfBmPUKU
>>411
Intel Visual Fortran とかググッてみ。
リアルタイムで今も製品出てるのを消えたとは言わないでしょ。

413デフォルトの名無しさん2016/07/21(木) 23:45:13.87ID:vaQfL518
>>408
ということで、C以外も生き残ってるんだが?w

414デフォルトの名無しさん2016/07/21(木) 23:52:22.14ID:dNMEb7c5
問題は暗黙に行う言語の動きに対してどれだけ
コンセンサスがとりやすいかってことだ。
c++ はもうその意味でどっか行ってる。

415デフォルトの名無しさん2016/07/22(金) 01:30:33.86ID:znBq8w6k
>>407
俺の言いたいことはそういうことじゃなくて
ローレベルな世界ではその言語固有のオブジェクトになってない
単なるメモリブロック、データ、信号を扱わなきゃならない場面が多いんだよ
それはファイルから読み込まれるかもしれないし
ネットワーク越しにやってくるかもしれないし
ディバイスとのやり取りかもしれないし
ま、要するに単なるデータ
Cはメモリモデルがシンプルだからこういった単なるメモリブロックを扱うのに
長けているんだよ
構造体にキャストするだけでそのまま扱えるから
今でもC言語が現場で活躍しているのはこれができるから
もしこういったことが出来なかったとしたら、C言語なんかとっくに滅んでいたに違いない
メモリブロックをキャストして構造体や配列としてアクセスできないとしたら
そんなC言語に価値なんかあるか?
その一点がすごいんだよ、マジセンスある、もしくは運が良かった

416デフォルトの名無しさん2016/07/22(金) 01:46:19.31ID:znBq8w6k
そして多くの言語が見落としがちな部分でもあったんだよ
オブジェクトにしなきゃならないっつってvtable持たせたり
動的にしなきゃならないと、メンバをオフセットではなくハッシュにしたり
どんどん賢い機能を盛り込んでさ
その点C言語の構造体や配列はフラットでむちゃくちゃシンプルな作り
適当なメモリブロックをキャストしても何の問題も起きない
仕様もシンプルで分かりきってる

417デフォルトの名無しさん2016/07/22(金) 02:02:58.97ID:znBq8w6k
別に必ずしも偉い機能を盛り込むのがダメと言っているわけじゃないよ
ただ、Cが何故か生き残っていて今でも使われ続けている原因はソレということ
C言語の用途と、うまい具合にマッチしてて、いい感じに生き残っている

418デフォルトの名無しさん2016/07/22(金) 03:13:29.97ID:7iYsigKa
だからなんだよ?

419デフォルトの名無しさん2016/07/22(金) 07:29:28.61ID:cZVknNWP
構造体の先頭メンバ以外のオフセットは規定されていない
まぁ、オフセットなのでメンバアクセスでどうとでもなるわけで
構造体が定義されたままメモリ上に存在していると考えているアホ
一般的なコンパイラなら定義通りだろうけど規定されていない
規定されていない規定されていない

420デフォルトの名無しさん2016/07/22(金) 08:09:11.54ID:+awE6fq0
構造体のメンバ間のパディングは未規定だけど、オフセットが未規定って言うのは
順番も入れ替わるって言ってるの?

421デフォルトの名無しさん2016/07/22(金) 09:35:29.96ID:+Z+w/IAX
簡単に入れ替わるさ。
わざわざ入れ替えないでねと指定するレベル

422デフォルトの名無しさん2016/07/22(金) 10:31:03.00ID:znBq8w6k
構造体のメンバの順番が入れ替わらないのは仕様で決まっているよ
決まってないのは間に入る詰め物だけ
http://portable-c.jugem.jp/?eid=17
しかし、詰め物をどうするか、指定できるコンパイラがほとんどだから
実質的に詰め物も問題にならない
C言語プログラマーは自分の使っているコンパイラの仕様ぐらい分かって使っているからね
問題になるとすればエンディアンぐらい

423デフォルトの名無しさん2016/07/22(金) 12:25:18.70ID:TIRA9iEO
JIS規格だろそれ。。。

424デフォルトの名無しさん2016/07/22(金) 13:24:25.19ID:+Z+w/IAX
intのサイズがアーキ依存だから通信に構造体は使うなってのが常識だけどな。

425デフォルトの名無しさん2016/07/22(金) 13:25:41.52ID:+Z+w/IAX
ネイティヴアメリカンの件もあるしな。

426デフォルトの名無しさん2016/07/22(金) 19:29:05.65ID:5OURMCtc
cはメモリは意識するがレジスタは隠蔽するって落とし所がよかったんじゃない。

427デフォルトの名無しさん2016/07/22(金) 19:41:14.28ID:jv7yTJni
Cはパーサが複雑なのとゼロコストで導入できる便利機能が無いのを除けば悪くはない

428デフォルトの名無しさん2016/07/22(金) 22:14:58.88ID:Oi2oQZIZ
cの最大の失敗は波カッコ
ブロックのスコープがパイソン風だったら人類は1世紀以上先の進んでいた

429デフォルトの名無しさん2016/07/23(土) 00:49:12.76ID:KFsxU+fY
代入演算子=と比較演算子==だけは許されざるよ。
つうか、IDEのサジェスチョン機能実装前の
"タイプ数が減る云々"な言語はすべて滅ぶべし。

430デフォルトの名無しさん2016/07/23(土) 01:22:33.59ID:tWjtYIW6
C言語は特徴ある機能で生き残ることができた。
だけそのその特徴ある機能がなかったら生き残れないのか?というと
そうではない。現にその特徴ある機能がない言語ばかりだからだ。

ここから言えることは、なにもない言語は消え行く定めだが、
C言語の機能がなくとも、それに上回る機能があれば生き残るということだ。

431デフォルトの名無しさん2016/07/23(土) 01:27:50.24ID:tWjtYIW6
>>429
IDEを使うことでタイプ数が減る機能はどうでもいいんだよね。

どうでもいいというのは、タイプ数が多くても少なくても
さほど違いはないということ。

重要なのはタイプ数じゃなくて読む文字数だから。
ただしタイプした文字数=読む文字数ではないということ。

どういうことかというと、人間は文章を読むとき
読み飛ばしをするということ。

例えばJavaでいうimportやMainクラス定義なんかは
読み飛ばす部分。だからそんなところで読む数の違いは出てこない。
また型定義は読むところではあるが、型定義だけを読むことで
型を理解できると言うメリットが有る。

これは型が書かれていないコードから、型を解析する
作業よりも読む文字数は少なくなる。

432デフォルトの名無しさん2016/07/23(土) 18:21:41.45ID:6yKmk1QH
代入演算子は要らなかった

433デフォルトの名無しさん2016/07/23(土) 23:13:50.14ID:7iusE9pH
代入は文であって値を持つべきでないと?

434デフォルトの名無しさん2016/07/23(土) 23:53:23.87ID:zx6tBrAB
愚か者めが

435デフォルトの名無しさん2016/07/24(日) 07:03:52.43ID:L1GkLU8N
Cが生まれた時代はな
シンタクスハイライトどころか下手すると
スクリーンエディタ(キリッ カットアンドペースト(キリッ
すら高価な機能だったんやで

436デフォルトの名無しさん2016/07/26(火) 15:33:00.26ID:ka5+GTWz
テキストエディタが数万円してからな

437デフォルトの名無しさん2016/07/26(火) 16:33:02.33ID:dc6Ut+6F
Cが生まれた頃にはまだコピー&ペーストはなかったぞ。

438デフォルトの名無しさん2016/07/26(火) 16:39:32.99ID:qFADw225
最初のクリップボードはAltoかな
Cが1972年でAltoが1973年

439デフォルトの名無しさん2016/07/26(火) 16:42:33.79ID:P0pX8+u1
>>430
で、その、この先生きのこるのはどの言語!

440デフォルトの名無しさん2016/07/26(火) 17:29:32.48ID:XfeIwbpB
アセンブラ C Fortran Lisp の古代言語
Javascript COBOL Python
HTML PHP はなんだかんだ言って生き残るんだろな〜

あとは Java がどうなるかな

441デフォルトの名無しさん2016/07/26(火) 21:54:04.74ID:8mWO7mKy
言語じゃないというのはナンセンスか

442デフォルトの名無しさん2016/07/26(火) 22:19:28.08ID:3gO7Ljql
お前ら、テーマに戻れや。
なぜオブジェクト指向は愚かな考えなんだ?

443デフォルトの名無しさん2016/07/26(火) 22:55:12.03ID:wvFbwXsy
愚かな設計が蔓延してるってことだな

444デフォルトの名無しさん2016/07/26(火) 22:55:59.68ID:wvFbwXsy
>>4
これがすべてじゃないの?

445デフォルトの名無しさん2016/07/26(火) 23:00:24.73ID:wvFbwXsy
初期設計を少しでも間違えたり手抜きしたら
そのシステムの成長絶望的になり死ぬ

446デフォルトの名無しさん2016/07/27(水) 02:09:24.84ID:gQfYvWZ4
>>444
そして>>41-42で完全に解説完了
ジョークとしてわざとオブジェクト指向として間違ったプログラム例だしてるってのに
「この通りオブジェクト指向は直感に反して〜」じゃねぇっつのw

447デフォルトの名無しさん2016/07/27(水) 02:12:13.92ID:gQfYvWZ4
>>440
Javaは普及してるから残るだろうなぁ
なんか、いつものベストじゃないけど普及したから
ベターとして残るというプログラム史のいつもの展開というか。

448デフォルトの名無しさん2016/07/27(水) 06:54:54.29ID:cUWSkWnI
問題はそういうジョークを本気にする人が多すぎるってことだろうに。
つまりオブジェクト指向ってのは一般にコンセンサスをとりずらい概念なんだよ。

449デフォルトの名無しさん2016/07/27(水) 06:58:14.97ID:LCC7iz/I
おまえ等の好きそうなネタ見つけた

オブジェクト指向で料理を例える場合,chicken.cut()かchef.cut()か
https://teratail.com/questions/41875

450デフォルトの名無しさん2016/07/27(水) 07:29:08.70ID:mL4CmQKe
>>446
コーヒーの例は単純明快だからいいけど、美少女は実際に正しく設計できるやつが日本に何人いるかってレベルだろうな

451デフォルトの名無しさん2016/07/27(水) 07:30:19.55ID:+Qq3g4cQ
>>448
これをジョークだと思って実戦に挑む奴がデスマーチを引き起こす

452デフォルトの名無しさん2016/07/27(水) 07:32:08.18ID:iBdKVqyS
基底に近いほど修正しづらいのは事実

453デフォルトの名無しさん2016/07/27(水) 07:33:05.82ID:8lCNqFHq
>>451
ほんとこれ

454デフォルトの名無しさん2016/07/27(水) 09:54:15.05ID:8yC4YC1p
>>449
tokage.cut()

455デフォルトの名無しさん2016/07/27(水) 12:23:59.26ID:mW7SlT40
くだらん与太話はこれくらいにしてそろそろ全力でウンコ美少女問題に取り組むか

456デフォルトの名無しさん2016/07/27(水) 17:21:14.58ID:8Owc4Qqf
ウンコしない美少女は偶像
つまり人間からの派生ではない

457デフォルトの名無しさん2016/07/27(水) 17:58:49.99ID:CvwlEFOq
なんか、いっつも同じレベルの書き込みするから
自演になってないって自覚しとる?きみ。

458デフォルトの名無しさん2016/07/27(水) 19:55:41.64ID:9bIrtjQt
ユーザーはうんこなんて機能は求めて無いから削除しろよと

459デフォルトの名無しさん2016/07/27(水) 20:16:04.55ID:YbwWr11d
人間がウンコするのは、
ユーザーが求めているからなのか?

460デフォルトの名無しさん2016/07/27(水) 20:21:12.98ID:9bIrtjQt
ソフトの機能に不要な要素まで組み入れても誰も買わないだろ。
現実の要素を完全に網羅する必要は無いから

461デフォルトの名無しさん2016/07/27(水) 21:23:16.38ID:dkELqw5/
それは当たり前のことではあるな
必要な要素だけ実装すればよいからな
Humanクラスがどういった要素を持つかは案件によるし
もし人の持つすべての機能をHumanクラスに実装できるっていうんなら
そのHumanクラスにプログラムも書いてもらえばよい

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

462デフォルトの名無しさん2016/07/27(水) 21:50:52.30ID:eu5RKOJ4
要件で一言も触れてないのに「はぁ?○○はあって当然だろ」とか言い出す顧客しかいないから
想像できるものは全て詰め込んでおく必要がある。
ウンコだろうとゲロだろうと例外はない。

463デフォルトの名無しさん2016/07/27(水) 22:27:39.20ID:YbwWr11d
肝心なことを決めずに作り込んでいく。
美少女クラスのスーパークラスは人間クラスである。
排便メソッドは関係ないからそれでいい。
だが、ある時ユーザーからの要望で人間クラスに排便メソッドを作った。
人間だもの、当たり前だ。
それでいいと思った。その時がくるまでは。
ある時私は気がついた。
これだと美少女が排便すると www

464デフォルトの名無しさん2016/07/27(水) 22:41:58.99ID:60oYSks+
このスレ的にはgo言語とかD言語のダックタイピングってどうなん?

465デフォルトの名無しさん2016/07/27(水) 22:47:49.85ID:rlINsgdh
ダックタイピング

由来

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

466デフォルトの名無しさん2016/07/28(木) 00:19:19.54ID:c5ty+8F5
ダッチワイフィング

由来

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

467デフォルトの名無しさん2016/07/28(木) 00:47:19.73ID:6VZFO4sX
オブジェクト指向は幻想

468デフォルトの名無しさん2016/07/28(木) 00:48:34.40ID:/rI5OmsP
COBOLからJavaへの移行で「実際に」成功した案件は存在しない

469デフォルトの名無しさん2016/07/28(木) 00:49:15.93ID:LhM4XtYR
細胞から実装しろ

470デフォルトの名無しさん2016/07/28(木) 00:49:41.59ID:OYshXAPi
元素から実装しろ

471デフォルトの名無しさん2016/07/28(木) 01:51:28.53ID:y7xhJAs5
>>468
COBOLって単なる言語じゃなくて運用まで含めたシステムの総称だからな。かなうわけがない
とは言え、高賃金のCOBOLプログラマーもいずれ死に絶えるわけでなんとかしないといけないんだけどさ
Adaなんか勉強して損した

472デフォルトの名無しさん2016/07/29(金) 12:00:06.26ID:TRgFQe5b
Ocamlならあるいは

473デフォルトの名無しさん2016/07/29(金) 18:48:09.16ID:POEPtDrt
ないない
そもそもCが小文字の時点で語る資格なし

474デフォルトの名無しさん2016/07/30(土) 00:08:52.44ID:lNYXBi4+
ならScalaでスイス銀行の例もあるし?

475デフォルトの名無しさん2016/07/30(土) 00:35:24.99ID:gkAo/Cig
具体的に

476デフォルトの名無しさん2016/07/30(土) 15:22:29.13ID:OSfj7rnr
オブジェクト指向を考え出した人間もオブジェクト指向の解釈を誤っていたのではないか
クラスというのは人間が直感的に思い描く世界の事物をプログラムコードにマップする手段ではなくて、
プロセスという大きなチューリングマシンの中の小さなチューリングマシンを記述する手段にすぎなかった
(チューリング完全性の利用例の一つだった

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

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

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

478デフォルトの名無しさん2016/07/30(土) 18:44:13.74ID:TLvR+07H
だいたいプログラミング業界って、

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

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

479デフォルトの名無しさん2016/07/30(土) 19:01:15.21ID:TM2kAcv9
> 継承しかり例外しかり。
継承も例外も極力使わないようにしましょうなんて
誰も言ってないが?

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

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

480デフォルトの名無しさん2016/07/30(土) 19:38:58.24ID:XUUv9y4D
結局、人間クラスと美少女クラスは
どうすればいいんだ?

481デフォルトの名無しさん2016/07/30(土) 20:02:32.96ID:TLvR+07H
>>479
正しく使おうってのは常に真だから内容が無いのと同じだな。
できるだけ使わないようにって風潮はある。程度の差はあれgotoとかと同じ。

482デフォルトの名無しさん2016/07/30(土) 20:08:02.92ID:OEu/5F3U
javaはオラクルがVMを提供しなくなったら
廃れるだろ。

483デフォルトの名無しさん2016/07/30(土) 21:52:18.63ID:NYI5chEQ
>>479
結局、言語の問題よりも馬鹿を入れない事のが重要ってことだろ。
そういう意味じゃ linus のやり方は正しいってことになる。

484デフォルトの名無しさん2016/07/30(土) 22:13:41.04ID:TM2kAcv9
>>481
> できるだけ使わないようにって風潮はある。
無いよそんなのwww

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

485デフォルトの名無しさん2016/07/30(土) 22:18:10.45ID:OSfj7rnr
(定義が論理的に妥当でなかったりあいまいだったりするとお議論が紛糾する例

486デフォルトの名無しさん2016/07/30(土) 22:23:44.57ID:3WJAVcau
多少コピペが多くなっても継承をむやみに使ってはいけない場面ってのは想定しなきゃなぁ

487デフォルトの名無しさん2016/07/30(土) 22:38:52.82ID:TM2kAcv9
なんで継承をやめたらコピペが多くなるのかそれがわからんw

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

488デフォルトの名無しさん2016/07/30(土) 22:44:09.77ID:XUUv9y4D
委譲を使えばいいんだろ。
肛門クラスを作って、
人間クラスと美少女クラスのプロパティに肛門インスタンスを持てばいいんだ。
排便できる肛門と出来ない肛門と。

489デフォルトの名無しさん2016/07/30(土) 23:06:52.83ID:FiK/AfbE
コーデングテクニックでごまかすのはアカンね
そーゆーことするから所謂ひとつのスパゲッテイー的ソースコードが出来上がるんや
デザインの問題はデザインで解決出来な一生炎上商法プログラマーのまんまやで

490デフォルトの名無しさん2016/07/30(土) 23:38:21.39ID:3WJAVcau
>>487
ミックスインの手法が確立されてないってことは、継承が害悪になる場面ってのはあるんだよ。

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

491デフォルトの名無しさん2016/07/30(土) 23:41:35.20ID:3WJAVcau
そうするとインタフェースの定義が必要になってくるから、結局継承が楽だし、よほどのことじゃなければそれで済ませるんだけどね

492デフォルトの名無しさん2016/07/31(日) 00:01:52.81ID:VGavY/X3
if文ですべて解決できるんじゃね

493デフォルトの名無しさん2016/07/31(日) 00:35:50.52ID:UuqrLdJE
だから、委譲というか、
デリゲート使えっていうか。

494デフォルトの名無しさん2016/07/31(日) 01:44:59.39ID:LD4Pss8J
ほんと最近、is-a関係、has-a関係っていうの
軽視されてるよな。

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

495デフォルトの名無しさん2016/07/31(日) 03:56:26.93ID:Wl4/o5Bb
フリーザは美少女クラスのis-a関係

496デフォルトの名無しさん2016/07/31(日) 09:04:47.96ID:xuMLlix3
>>494
is-a関係は一般に存在しない
例外なのは同値関係と包含関係が数学的に定義できて無矛盾性が担保された
(=直接証明されたか、より一般的な体系の無矛盾性に帰着できる)ケースだけだが
そんなのはスゲーまれ
いっぱいあると感じるのは錯覚

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

497デフォルトの名無しさん2016/07/31(日) 09:09:00.42ID:xuMLlix3
その点ha-a関係はやりやすいなぜなら単なる集約であって分類が絡まないから
has-a関係の導入自体が矛盾を生じることは無いからだ

498デフォルトの名無しさん2016/07/31(日) 09:36:24.74ID:tLh0Iyun
is-a関係だと思っているものは全てhas-aとしても実装できる。

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

499デフォルトの名無しさん2016/07/31(日) 09:41:31.16ID:/E3bqgob
OO使わない場合に
フラグとかカウンタとかステータスってのをどう管理するのかを
単刀直入に知りたい。
関数型なんかでもこの辺がよくわからない
(消せるはずはないから何か別の概念などで整理・管理されるんだとは思うけど)

500デフォルトの名無しさん2016/07/31(日) 09:46:59.05ID:tLh0Iyun
>>499
普通の構造体でいいのでは?(Cでいうところの)

501デフォルトの名無しさん2016/07/31(日) 09:59:49.33ID:p/Oh4nGe
>>499
そこでクロージャですよ

502デフォルトの名無しさん2016/07/31(日) 10:00:24.80ID:P4D/j0eN
is-a だったらliskov置換原則の方が理解し易いし、コード書くときの指針になる。

503デフォルトの名無しさん2016/07/31(日) 10:09:28.04ID:xuMLlix3
ちなステータスというのは大概I/Oを通じて外界と繋がっている事物の結果を意味し、
実時間軸上でうつろうもの(mutableなブツ)なので厳密には関数型プログラミングに存在し得ない概念

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

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

504デフォルトの名無しさん2016/07/31(日) 11:53:00.79ID:LD4Pss8J
>>494
女は一般に存在しない
いっぱいあると感じるのは錯覚

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

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

505デフォルトの名無しさん2016/07/31(日) 13:06:04.94ID:xuMLlix3
>>504
is-a関係は一般には存在しないと書いたのじゃ
例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう
また、なんで女クラスの派生クラスが妻クラスではいけないのか?その根拠を目下人類は手にしていない
はい論破

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

506デフォルトの名無しさん2016/07/31(日) 15:57:24.63ID:Wl4/o5Bb
is-aかどうかなんて抽象的すぎて判断の材料になんないよな。

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

507デフォルトの名無しさん2016/07/31(日) 15:58:19.37ID:JthY0EmQ
>>505
そりゃ妻のような一時的な属性に過ぎないものををクラス化するのがそもそも間違ってる
同性婚以前に結婚離婚で既に破綻してるじゃないか
例が悪いので説明になってない、やり直し

508デフォルトの名無しさん2016/07/31(日) 16:07:11.65ID:Wl4/o5Bb
>>507
男も改造すれば女になりうるから、男クラスのインスタンスを作ると、参照を維持したまま女クラスに変身できない。

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

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

509デフォルトの名無しさん2016/07/31(日) 16:07:23.65ID:kxVM21o1
妻とか女とか、単なる属性をクラスにするからワケが分からなくなる。

510デフォルトの名無しさん2016/07/31(日) 16:27:16.51ID:iFqDH3lg
いいから、肛門クラスを作って
デリケートしろ!

511デフォルトの名無しさん2016/07/31(日) 16:35:53.61ID:Wl4/o5Bb
口に肛門つけてください。
しゃべれるしうんこできるし便利だと思うんです。

512デフォルトの名無しさん2016/07/31(日) 21:22:59.29ID:XDiDpvFC
話についていけない子が
必死で面白レスしようとするのが悲痛
人間の悲しみが透けて見える

513デフォルトの名無しさん2016/08/01(月) 00:44:08.60ID:E1waX2Jm
>>505
> 例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう

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

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

514デフォルトの名無しさん2016/08/01(月) 00:46:25.46ID:E1waX2Jm
普通は性別は属性だよなw

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

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

515デフォルトの名無しさん2016/08/01(月) 00:52:22.69ID:E1waX2Jm
is-a関係っていうのは必要条件であって十分条件じゃないんだがw
is-aになっていれば必ず継承関係にあるってことじゃない。
継承しようと思ったとき、is-a関係を満たしていなければいけないって話だ。

516デフォルトの名無しさん2016/08/01(月) 01:01:45.57ID:8BzY1j1Y
オブジェクト指向ってどこで間違ったんだろう
途中までは良い線行ってたと思うんだけど、どこからか使いものにならなくなったよね

517デフォルトの名無しさん2016/08/01(月) 01:04:20.06ID:E1waX2Jm
オブジェクト指向が使われてない
フレームワークなんて無いんだが?

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

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

518デフォルトの名無しさん2016/08/01(月) 01:06:05.40ID:fJ4xvUon
だから、継承捨てて委譲を使えっての!

519デフォルトの名無しさん2016/08/01(月) 01:41:20.92ID:C6PCKyxq
>>517 本当にオブジェクト指向が必要だから使っているのか、
抽象化の手段がオブジェクト指向しか無いから使わざるをえないのか

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

520デフォルトの名無しさん2016/08/01(月) 01:41:37.76ID:E1waX2Jm
継承捨てて委譲を使えっていうのは
マイクロソフト用語でコンポーネント指向っていうんだが、
これを意図的に取り入れたのが2000年前後に使われていたVB6なんだよな。

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

521デフォルトの名無しさん2016/08/01(月) 01:43:39.68ID:E1waX2Jm
>>519
オブジェクト指向は必要だから使うんじゃなくて
いくつもある手段の中から一番適切だから使うんだよ。

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

522デフォルトの名無しさん2016/08/01(月) 02:44:42.52ID:6ITirnPy
>>513
だからその設計はねーってこと言ってるんだろ。

日本語読めないの?

523デフォルトの名無しさん2016/08/01(月) 03:09:46.97ID:FN/zaXKS
>>516
>どこからか使いものにならなくなったよね
C++の奇形めいたオブジェクト指向は衰退して
別方面で進化してきたObjecive-CとJavaが本流として
いま街でみかける全てのスマホアプリを支えてるけどな。

524デフォルトの名無しさん2016/08/01(月) 03:31:24.59ID:cj2k2Gm/
今はObjrctive-CじゃなくてSwiftじゃね?

525デフォルトの名無しさん2016/08/01(月) 04:29:03.24ID:C6PCKyxq
>>521 適切だから使うというなら何故デザインパターンなんて出てきたのか?
デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
他の手段が使える言語なら間違いなく採用しない

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

526デフォルトの名無しさん2016/08/01(月) 06:27:47.87ID:c5RAbFYM
JavaはC++よりレガシーな言語になってしまったが…

527デフォルトの名無しさん2016/08/01(月) 09:36:21.09ID:E1waX2Jm
>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、

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

528デフォルトの名無しさん2016/08/01(月) 10:06:54.28ID:Q0J3uZmP
いや、デザパタはOOと関係無いから。
関係あるのはOOPの方

529デフォルトの名無しさん2016/08/01(月) 10:50:43.99ID:pyyhbxGP
【閲覧注意】戦闘に巻き込まれて頭部を切断された少女の遺体。これがリアルなシリア。
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
この少女がどうなったのかが気になる所ですが動画の説明には何も書かれていなかった・・・。

530デフォルトの名無しさん2016/08/01(月) 10:52:18.11ID:IZIdUKpU
ここまでLSPの話題なし

531デフォルトの名無しさん2016/08/01(月) 17:10:00.57ID:GD9lEFl6
>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、

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

532デフォルトの名無しさん2016/08/01(月) 18:06:20.18ID:99zq/hjd
smalltalk だと、人間クラスと美少女クラスの問題は
どう解決するの?

533デフォルトの名無しさん2016/08/01(月) 20:14:16.64ID:NIKdUbwx
Squeak Smalltalk だと、こんな感じか?

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

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

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

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

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

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

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

534デフォルトの名無しさん2016/08/01(月) 20:39:01.26ID:E1waX2Jm
>>531
> SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。

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

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

535デフォルトの名無しさん2016/08/02(火) 00:07:55.94ID:6KXXOitA
>>534
試しにウィキペの Decorator パターン
https://ja.m.wikipedia.org/wiki/Decorator_パターン

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

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

536デフォルトの名無しさん2016/08/02(火) 00:11:39.50ID:xLK/JaT/
シングルトンなんて言語に最初から組み込んでおけ(Scala信者並感)

537デフォルトの名無しさん2016/08/02(火) 00:40:29.48ID:Aujbapgh
>>532
そもそもきみは継承関係=オブジェクト指向でしか発想してないから
クソ邪魔くさい継承取っ払ってモジュール自由に組み外しできるタイプの
オブジェクト指向の話にまったくついてこれてないからずっと嗤われてるわけで。

538デフォルトの名無しさん2016/08/02(火) 00:44:39.63ID:flPsn8Jo
>>535
別にDecoratorじゃなくていいんだけどね。
圧倒的に簡潔かつ明瞭に記述できるっていってるから
そのコードを見たいだけ。

539デフォルトの名無しさん2016/08/02(火) 05:55:14.53ID:wOSsX6OQ
デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。
型が完全に動的なSmalltalkやSelfではデコレータパターン自体が不要。

540デフォルトの名無しさん2016/08/02(火) 10:26:45.37ID:KjBiyzhL
型が動的だと>>535の例のようなコードはどうなるの?

541デフォルトの名無しさん2016/08/02(火) 10:29:15.63ID:YMxtX/GD
そそ
例えばアセンブリや機械語は制約がないからデコレータパターンとか要らないでしょ
それと同じでSmalltalkには何も必要ないよ

542デフォルトの名無しさん2016/08/02(火) 13:11:20.31ID:KCBRtMku
全然違うのだが。デコレータもSmallTalkも理解してないとみた。

543デフォルトの名無しさん2016/08/02(火) 13:40:40.79ID:C0zGukRC
アセンブリというかC言語だとこんな感じか。出来るには出来るけどちょっとねえ
http://codepad.org/XgRtJlQb

544デフォルトの名無しさん2016/08/02(火) 15:34:07.46ID:lROFhaXh
なにも知らなくても語れる。
それが Smalltalk のいいところらしい。
人間の悲しさがほの見えるな・・・

545デフォルトの名無しさん2016/08/02(火) 16:01:47.58ID:wOSsX6OQ
>>540
Smalltalkはよくわからないけど、
DoublePriceとかWholesalePriceとかいうクラスを増やすより、
元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
SmalltalkのPluggableMVCとかもクロージャで柔軟な変換を実装しているし。

546デフォルトの名無しさん2016/08/02(火) 16:53:22.92ID:I0xQlCpI
>>545
> 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。

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

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

547デフォルトの名無しさん2016/08/02(火) 17:16:35.65ID:I0xQlCpI
>>543
これだと Java 版でいうところの getValue() する前に
毎回、二倍にして 利益80乗せて、また二倍にしてもう一度 利益200乗せて…とかって
いちいち書かないと 840を返せないから、結果は合っているけど要求仕様を満たしていないような気がする

548デフォルトの名無しさん2016/08/02(火) 18:25:05.78ID:lROFhaXh
いつになったら、
人間クラスと美少女クラスの問題に辿りつけるのかね?
悲しいの〜。

549デフォルトの名無しさん2016/08/02(火) 20:24:15.92ID:wOSsX6OQ
>>548
とっくに解けてるじゃん
ばか?

550デフォルトの名無しさん2016/08/02(火) 20:30:55.27ID:lROFhaXh
どう解けてるんだよ。
人間の肛門と天使の肛門にコンポーネントするのか?

551デフォルトの名無しさん2016/08/02(火) 20:41:47.88ID:UCo4tbLK
用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。

552デフォルトの名無しさん2016/08/02(火) 20:42:03.85ID:9rM4/wP9
美少女は偶像であり人間ではない

553デフォルトの名無しさん2016/08/02(火) 20:57:34.64ID:flPsn8Jo
もうそろそろいいかな?

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

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

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

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

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

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

554デフォルトの名無しさん2016/08/02(火) 21:16:53.04ID:LOKS06K+
>>553
なんでみんなより二歩も三歩も手前な意見を
そんな長文で書き込めるの?

555デフォルトの名無しさん2016/08/02(火) 21:20:29.76ID:flPsn8Jo
>>554
言いたいことはそれだけかw

556デフォルトの名無しさん2016/08/02(火) 21:22:05.73ID:LOKS06K+
ごめんね

557デフォルトの名無しさん2016/08/02(火) 21:24:18.11ID:e9gYPknx
Smalltalk の t を大文字で書くやつは無知か知ったかぶり

558デフォルトの名無しさん2016/08/02(火) 21:24:35.32ID:lROFhaXh
実は誰も Smalltalk なんて知らない www

559デフォルトの名無しさん2016/08/02(火) 21:27:22.36ID:flPsn8Jo
反論あるなら待ってるよw

560デフォルトの名無しさん2016/08/02(火) 21:32:29.72ID:LOKS06K+
>>557
ワロタw

561デフォルトの名無しさん2016/08/02(火) 21:38:39.55ID:UCo4tbLK
言語は関係無いと言う内容の話への反論が、言語名のミスプリントの指摘とか、レベル低過ぎだろw
小学生の負け惜しみかよw

562デフォルトの名無しさん2016/08/02(火) 21:39:26.48ID:flPsn8Jo
>>561
え?それ反論だと思ってたの?
反論はまだ一つも来てませんよw

563デフォルトの名無しさん2016/08/02(火) 21:40:28.47ID:UCo4tbLK
うゎw
保育園だなここはw

564デフォルトの名無しさん2016/08/02(火) 21:47:57.27ID:6KXXOitA
>>561
「プリント」とかまさに小並

565デフォルトの名無しさん2016/08/02(火) 22:08:58.16ID:e9gYPknx
>>553
>>538で「見たいだけ」って言ってるところをみると、これは反語で
>>546みたいに簡潔なのが出てくるとはこの時点では考えてなかったんじゃない?
だからデザパタは用語で実装じゃない、言語は関係ないって趣旨替えしたように読むのは穿ちすぎ?

566デフォルトの名無しさん2016/08/02(火) 22:14:56.76ID:flPsn8Jo
>>565
いやw
最初からこのために、
デコレータパターンをSmallTalkで書いたらどうなるの?って
話題を振って会話をさせたんだよ。

デコレータパターンという共通知識があり、
SmallTalkでそれを実装することができるという会話をね。

もし実装が決まっているものであれば、
SmallTalkでデコレータパターンを実装すれば
シンプルな形で実装できるんだっていう話はでてこない。

567デフォルトの名無しさん2016/08/02(火) 22:27:10.71ID:KCBRtMku
そもそもC++でデコレーターでもそんな難しくないでしょw
シングルトンの方がよっぽどややこしい。

568デフォルトの名無しさん2016/08/02(火) 22:30:18.68ID:flPsn8Jo
「シングルトン」だけで話が通じる所がデザインパターンの
便利なところだね。

さてシングルトンにもいろんな実装があるけど、
DIコンテナを使ってシングルトンに見せるっていう方法もあるよね。
これだと普通にクラスを作るだけで良くなる。

569デフォルトの名無しさん2016/08/02(火) 22:34:48.24ID:qU1dasmj
兄さん、そこでPythonですよ
ですしおすし

570デフォルトの名無しさん2016/08/02(火) 23:26:19.20ID:QqIbwu4d
Java8ならもっとHENTAIなコードが書けるぞ
http://ideone.com/DbIiD0

571デフォルトの名無しさん2016/08/02(火) 23:41:10.66ID:6KXXOitA

572デフォルトの名無しさん2016/08/02(火) 23:59:46.02ID:lROFhaXh
Smalltalk の最大の魅力は、
それが雑談に過ぎないということである。
by アラン・ケイ

573デフォルトの名無しさん2016/08/03(水) 00:45:18.40ID:qJ0ntPw4
>>570
new Price((120*2+80)*2+200) を作りたいわけではなくて
new Price(120) をデコって 840 を返させるのが Decorator
だからデコったあとに setValue(100) してから getValue() すると 760 が返るはず
http://ideone.com/Z24LFA
http://ideone.com/Diod1I
http://ideone.com/x2goNr
http://ideone.com/do6fT9

574デフォルトの名無しさん2016/08/03(水) 11:21:17.97ID:nNt8IZmK
>>566
まるでちがう。>>546はデコレータパターンじゃない。
Javaではデコレータパターンを使う問題を
デコレータパターンを使わずにより簡潔に記述した例。

575デフォルトの名無しさん2016/08/03(水) 12:45:10.82ID:XBNCNfrP
>>539
型が動的だと>>535の例のようなコードはどうなるの?

576デフォルトの名無しさん2016/08/03(水) 15:55:24.00ID:8J75MUHP
SmallTalkとか

577デフォルトの名無しさん2016/08/03(水) 17:09:10.94ID:R0iPm5qU
関数型インターフェースの方が簡潔になる
http://ideone.com/6MAwKM

>>573
setValue(100)してからgetValueしたら100返らなきゃバグってるだろ
setOriginalValueとかに修正するところだな

578デフォルトの名無しさん2016/08/03(水) 18:07:08.01ID:8J75MUHP
Wikipediaにある
> Decorator パターンの方針は、既存のオブジェクトを新しい Decorator オブジェクトでラップすることである。
がわかってない奴がいるな

579デフォルトの名無しさん2016/08/03(水) 18:17:54.35ID:qhbdc1zB
デザパタの目的とされがちであるが
常に失敗しているのが語彙の共有

いつでもつねに認識がバラバラw

580デフォルトの名無しさん2016/08/03(水) 18:21:38.71ID:8J75MUHP
>>579
ごく一部の人間が正しく理解できてないだけで、
> いつでもつねに認識がバラバラw
は言い過ぎ

581デフォルトの名無しさん2016/08/03(水) 18:45:37.19ID:9oohU77o
>>577
> 関数型インターフェースの方が簡潔になる

そんなんでいいなら Smalltalk でも簡潔に書けるけどね

http://ideone.com/RZHQ7P

582デフォルトの名無しさん2016/08/03(水) 19:57:46.85ID:N9MmOijn
Smalltalkに意味なんかないよ
登場してから30年とか40年とか経ってるのに
誰も現場で使ってない言語だからね
40年という歳月は結論を出すのに十分な時間だと思うよ
これから先もずっと使われないだろう
こんな言語についてあれこれ考えるのは時間の無駄だよ
御幣を恐れずに言うと、Smalltalkは間違っている、机上の空論
本当によくできていたなら、もうちょっとぐらい使われていてもおかしくない
少なくともRuby程度ぐらいには使われてないと話にならない
Smalltalkは実用にならないスジの悪い言語だということ

583デフォルトの名無しさん2016/08/03(水) 20:22:04.47ID:M+rE/wd/
Smalltalkは言語だけじゃダメで。
windows上では使い物にならないから仕方無い。

584デフォルトの名無しさん2016/08/03(水) 20:23:22.86ID:M+rE/wd/
要するに、windows自体がオブジェクト指向に向いてないんだよ。

585デフォルトの名無しさん2016/08/03(水) 20:29:26.00ID:1jcdD/Xi
結論。
誰も Smalltalk なんて知らない www

586デフォルトの名無しさん2016/08/03(水) 20:32:04.15ID:N9MmOijn
それは関係ない
なぜなら概念上の問題より運用上の問題のほうが大事だから
いくら概念的な素晴らしさを語ったところで
まともに運用できないならゴミ
使えない

587デフォルトの名無しさん2016/08/03(水) 20:45:27.46ID:YtpqVXv4
>>574
> Javaではデコレータパターンを使う問題を
> デコレータパターンを使わずにより簡潔に記述した例。

お前は勘違いしているな。

デコレータパターンを実装しなさいというお題なんだから
それがデコレータパターンなんだよ。

Javaならこういう実装でやるが、他の言語では
その実装方法が違うだけ。

588デフォルトの名無しさん2016/08/03(水) 21:24:23.35ID:TE6NppPB
>>582
まあ仮にSmalltalkが本当に誰も使ってなくて
処理系も失われたり、あるいは as-is で放置された言語だとしたら
そんなものに意味がないって意見は全くもって正しいよね

589デフォルトの名無しさん2016/08/03(水) 21:37:23.40ID:46yxFVyN
シングルトンやアイテレーターなどは時代が変わっても重要だろうけど、
デコレーターは継承関係への依存度が高いから微妙だな。

590デフォルトの名無しさん2016/08/03(水) 22:46:55.08ID:PwtoF+FA
>>583
Smalltalkは独自のGUIもそうだけれども、もうひとつ、通常のセルフホスティング
(自身で自身を記述)にとどまらず、処理系を構成する実行時オブジェクト群を
仮想イメージと呼ばれる、ある種のオブジェクトストアに永続化して次回起動時も
継続利用する運用スタイルも毛嫌いされるよね。個人的には示唆に富んでいて好きなんだけど

591デフォルトの名無しさん2016/08/04(木) 00:17:31.35ID:iDV12Qqy
>>587
いや?
クロージャで実装しているのだから、デコレータパターンによる実装ではないよ。
コード読めない子?

592デフォルトの名無しさん2016/08/04(木) 00:19:01.73ID:jTAWnEUa
> クロージャで実装しているのだから、

クロージャで "何を" 実装しているの?

593デフォルトの名無しさん2016/08/04(木) 00:24:24.39ID:ClPuKc3B
デコレータパターンを実装できてはいないんだよw

これでわかった?w

594デフォルトの名無しさん2016/08/04(木) 00:25:35.63ID:jTAWnEUa
いや、何を実装したのかを聞いたんだが?
実装したものは何?

595デフォルトの名無しさん2016/08/04(木) 00:30:18.03ID:ynLXOlFE
>>590
あのあたりはむしろメモリや記憶装置いくらでも使える現代向けというか
過去にオブジェクト指向の要素をちょっとだけ輸入してみた中途半端なオブジェクト指向言語が次々出ては滅びの興亡続けてたのは
"コンパイル後のサイズが大きいじゃないか"とかいまじゃヘソが茶を沸かすような理由がメインなわけだし。

596デフォルトの名無しさん2016/08/04(木) 00:31:24.04ID:w6fnMNqO
デコレータパターンと同等の機能をクロージャで実装した
じゃね?

同等の機能を持った違った実装があるのは当たり前じゃね?
デコレータパターンと同じような機能をもたらすけど
デコレータパターンじゃない実装は普通にあり得るんじゃね?

597デフォルトの名無しさん2016/08/04(木) 00:34:51.00ID:jTAWnEUa
>>595
パターンは機能じゃないよ。設計。
デコレータパターンという設計

この設計の実装はいろいろある。
決まっていない。

Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。

598デフォルトの名無しさん2016/08/04(木) 00:36:04.52ID:jTAWnEUa
wikipediaにすら書いてあるしw

https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)

デザインパターンは、よく使われる設計を一般化された形でまとめたものに過ぎない。
そのため、具体的な実装を提供するものではなく、
あくまでもコンセプトとして参照されることが意図されている。
つまり、サンプルコードは、実装例に過ぎない。

599デフォルトの名無しさん2016/08/04(木) 00:42:01.96ID:w6fnMNqO
>パターンは機能じゃないよ。設計。

それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ?
俺の言ってることと一緒だね

600デフォルトの名無しさん2016/08/04(木) 00:44:00.26ID:fESKb5E9
ID:jTAWnEUaを教育してあげる義務は我々には無い

601デフォルトの名無しさん2016/08/04(木) 00:45:06.02ID:jTAWnEUa
>>599
わざわざ複雑にしないでいいよw

やりたいことがある。
でも説明するのが面倒くさい。

じゃあ「デコレーターパターン」と呼びましょう。

これで話は通じてるじゃん。
だからこれだけの情報でコードを書くことができる。

そのデコレーターパターンを
クロージャーで実装したんでしょ?
そういえば良いんだよ。

602デフォルトの名無しさん2016/08/04(木) 00:48:34.94ID:jTAWnEUa
>>600
じゃあ一緒に勉強していきましょう(笑)

http://www.techscore.com/tech/DesignPattern/foundation/foundation1.html/#dp0-2

> 前章でも説明したとおり、デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」を
> まとめたものです。 デザインパターンを利用するメリットとして、最初にあげられるのが、
> 「再利用性の高い柔軟な設計ができる」という点です。各パターンには、多くの知恵が凝縮されています。
> これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
> 初心者でも先人たちが詰め込んだ「知恵」を利用した設計をすることが可能となります。
> また、先人たちの知恵を参考にすることで、設計力の向上も期待できます。
>
> 次のメリットは、「技術者どうしの意思疎通が容易になる」ことが挙げられます。
> デザインパターンを習得している技術者どうしであれば、設計について相談するとき
> 「Singleton パターンで行きましょう」とか「Strategy パターンが応用できるのではないでしょうか」と
> いうようにパターン名で設計の概要の合意を取ることが可能です。デザインパターンを
> 習得していない技術者には「こんなクラスを作って、このクラスはこんな役割を持っていて・・・。」と
> 延々と説明しなければなりません。このように、デザインパターンを学習しておくことで
> 開発者どうしの意思疎通がスムースになるのです。

あなたは何で勉強していますか?

603デフォルトの名無しさん2016/08/04(木) 01:13:23.05ID:w6fnMNqO
話をややこしくしているのはあなたです

>パターンは機能じゃないよ。設計。

↑これは君が言ったことだよね

その上で俺は、同等の機能を持った、違ったデザインなんじゃね?って言ってるわけ

機能が同じであっても、同じデザインパターンとは限らない
何故なら、デザインパターンは機能じゃないから、設計のパターンだから
↑君の言ってることと全く同じだよね

だから同じ機能だけど、違った設計パターンであり
同じデザインパターンに属さない設計は有る
ということを君は認めているということ

604デフォルトの名無しさん2016/08/04(木) 01:43:58.02ID:w6fnMNqO
デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの
ってのは正に君が自分で言ったことであって
それは俺も了承している

だから同じ機能であっても、それだけで同じデザインパターンとは言えないよね
と俺は言ってるわけ
なぜならデザインパターンは機能では無いから(君の言ったことだよね)

そもそも俺とお前とのやり取りに、何のとどこおりも無い
俺は、>>596で同等の機能を別の設計で実装したんじゃないか、と言い
お前は>>597でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている
合わせると、「同等の機能であっても同じデザインパターンであるとは限らない、設計で決まる」
という結論が得られる

605デフォルトの名無しさん2016/08/04(木) 01:56:34.90ID:tMKvO+zV
デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。

これと同じことが他のデザインパターンでもできるんじゃね?という主張だったと思うんだが。

Singletonは言語によって容易に達成できるものもあればそうでない言語もあるが、そう難しくは無いはず。
OCamlだったらmutable valueを持ったモジュール使えば同等のことが実現できる。
Adapterパターンも変更できない物がオブジェクトだったら関数1つで済むし、
モジュールだったらファンクタ使えば良い。

これを続けていけばデザインパターンがOOPの表現力の低さを解決する妥協案である、と示せる気がするが、
逆にOOPでデザパタ使うのが一番簡潔になる問題を探す方が難しいかもね。

606デフォルトの名無しさん2016/08/04(木) 03:16:53.36ID:jTAWnEUa
やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。

まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。

そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。

607デフォルトの名無しさん2016/08/04(木) 03:18:24.28ID:jTAWnEUa
OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。

C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。

608デフォルトの名無しさん2016/08/04(木) 06:27:25.67ID:iDV12Qqy
>>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。

JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。

609デフォルトの名無しさん2016/08/04(木) 09:14:32.03ID:jTAWnEUa
>>608
それはオレオレ定義ですよね。

610デフォルトの名無しさん2016/08/04(木) 09:31:36.26ID:0aO0sFCL
デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。


「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。

プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。

611デフォルトの名無しさん2016/08/04(木) 09:33:28.01ID:IwXa2U8x
内容を理解してないから例にある記述方法しか受け付けないんだよ。

612デフォルトの名無しさん2016/08/04(木) 09:33:48.07ID:jTAWnEUa
> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。

じゃあなんでこんな本が存在するんですか?w

Rubyによるデザインパターン-Russ-Olsen/
https://www.amazon.co.jp/dp/4894712857

JavaScriptデザインパターン
https://www.oreilly.co.jp/books/9784873116181/

The Design Patterns Smalltalk Companion
https://www.amazon.com/dp/0201184621

613デフォルトの名無しさん2016/08/04(木) 09:34:24.97ID:0aO0sFCL
>>610
あ。引用部分は自炊本の OCR のコピペなんで、タイポは脳内補完ねがいます。

614デフォルトの名無しさん2016/08/04(木) 09:35:44.09ID:0aO0sFCL
>>612
GoF も「Smalltalk では簡単に記述できるものもある」とは言っているけど、
ぜんぶがぜんぶとは言っていないよね。

615デフォルトの名無しさん2016/08/04(木) 09:35:54.66ID:IwXa2U8x
>>612
おまいみたいなバカに本を売り付ける為だろw

616デフォルトの名無しさん2016/08/04(木) 09:38:22.54ID:jTAWnEUa
>>615
え?捨て台詞?w

617デフォルトの名無しさん2016/08/04(木) 10:07:48.33ID:e/09ny1R
これはまさに捨て台詞で十分な一例。

618デフォルトの名無しさん2016/08/04(木) 10:14:03.24ID:0aO0sFCL
> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。

Smalltalkを好意的にとらえて持ち上げてくれるのは、狭い視野で意味なし認定しちゃう人たちよりは
ファンとしてはありがたいけど、これはさすがにオーバーエスティメートだし、
もうちょっとSmalltalkならではのアドバンテージを学んでから、適切な持ち上げ方をしてほしい…

619デフォルトの名無しさん2016/08/04(木) 10:47:43.12ID:iDV12Qqy
「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。

620デフォルトの名無しさん2016/08/04(木) 11:37:47.99ID:0aO0sFCL
>>619

もしそうだとしても、少なくとも>>591は「GoFの(デコレーター)」と明記すべきですよね

621デフォルトの名無しさん2016/08/04(木) 12:27:01.14ID:CY/jwgqy
smalltalkって簡単に色々できるんでしょ?
なんで現代でメジャーじゃないの?

622デフォルトの名無しさん2016/08/04(木) 12:30:59.74ID:IwXa2U8x
日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ?

623デフォルトの名無しさん2016/08/04(木) 12:31:27.57ID:79cTVfxr
MSがVisual Smalltalkをつくらなかったから

624デフォルトの名無しさん2016/08/04(木) 12:57:32.53ID:iDV12Qqy
>>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが?

625デフォルトの名無しさん2016/08/04(木) 13:05:00.50ID:rDDGHvQu
はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。

626デフォルトの名無しさん2016/08/04(木) 13:16:23.28ID:0aO0sFCL
>>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン(GoFの定義如何に関わらない)というのを提示してもらうことはできますか?
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。

そもそも Smalltalk ではデコレーターパターンが不要(なので、実装はナンセンス)とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。

627デフォルトの名無しさん2016/08/04(木) 14:01:27.52ID:gwNa+xfa
つか、>>546のruby版って一体何?
デコレータパターンのつもり?

628デフォルトの名無しさん2016/08/04(木) 14:13:24.61ID:0aO0sFCL
>>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満?

629デフォルトの名無しさん2016/08/04(木) 14:41:37.79ID:gwNa+xfa
>>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デフォルトの名無しさん2016/08/04(木) 14:42:24.41ID:gwNa+xfa
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デフォルトの名無しさん2016/08/04(木) 16:18:58.29ID:0aO0sFCL
>>629

これでいい?

http://ideone.com/WGTiOD

632デフォルトの名無しさん2016/08/04(木) 16:59:33.41ID:gwNa+xfa
>>631
なんか実装手段が違ってきてますが・・・。

>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。

633デフォルトの名無しさん2016/08/04(木) 17:09:10.90ID:0aO0sFCL
>>632
> なんか実装手段が違ってきてますが・・・。

本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので


> closureを使えばデコレータパターン同等のことができる

>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい

634デフォルトの名無しさん2016/08/04(木) 17:41:28.54ID:gwNa+xfa
>>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。

WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。

一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか?
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。

635デフォルトの名無しさん2016/08/04(木) 18:07:30.87ID:iDV12Qqy
>>626
だーかーらー、

デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装(当然、上記デコレータパターンの実装ではない)で実現できる。

という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる?

636デフォルトの名無しさん2016/08/04(木) 18:33:42.23ID:0aO0sFCL
>>634
> 一方、>>546のコードだとそうはいかない。

単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
http://ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。

637デフォルトの名無しさん2016/08/04(木) 18:57:12.60ID:0aO0sFCL
>>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。

638デフォルトの名無しさん2016/08/04(木) 18:59:34.21ID:iP1jJ0aF
>>610
iteratorはどっちが楽なの?

639デフォルトの名無しさん2016/08/04(木) 19:27:18.45ID:0aO0sFCL
>>638
Smalltalk と C++ との比較で? それならもちろん Smalltalk です。

(同書P.289より)
Smalltalkではiteratorを明示的に定義する必要はない。標準的なコレクションクラス(Bag、
Set、Dictionary、OrderedCollection、Stringなど)で、内部iteratorのメソッドdo:を定義してい
るからである。do:はブロック(つまり、closure)を引数としてとる。

(標準的なコレクションクラスの例になぜか名前がありませんが当然Arrayも含みます。念のため。)

640デフォルトの名無しさん2016/08/04(木) 19:40:49.06ID:HlIXxJdQ
>>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね?
別にSmalltalkが特別ってことにはならない。

641デフォルトの名無しさん2016/08/04(木) 20:21:25.52ID:jTAWnEUa
>>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、

修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。

642デフォルトの名無しさん2016/08/04(木) 20:23:12.92ID:jTAWnEUa
デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。

643デフォルトの名無しさん2016/08/04(木) 20:37:49.54ID:0aO0sFCL
>>640
Smalltalkが特別ってことにはならないという点については同意します。

ただ、クロージャーを引数にとる内部イテレーターはとても簡潔な記述を可能にするので
C++がSTLを介してイテレーターが組み込みであっても、記述の負担の軽さはSmalltalk方式の方が優位かとも

とはいえ、C++のコードがどんな感じになるかははずかしながら当方ちょっと予想が付きかねますので、
もし可能でしたら、C++のSTLを使って書いてSmalltalkのと比較をさせてもらうことはできますか?

あいにくウィキペにはIteratorの例はないので、こちらの比較的シンプルなJavaの例を

http://qiita.com/jonichonpa/items/208dc2361414f93efacf

Smalltalkで書いてみました

http://ideone.com/oplhQu

もちろんSmalltalk方式を採用した言語(たとえばRuby)なら、Smalltalkと同程度にシンプルに書くことはできます
そんなわけでRuby版も念のため

http://ideone.com/xlQZqc

644デフォルトの名無しさん2016/08/04(木) 20:41:57.05ID:jTAWnEUa
イテレーターパターンをSmalltalkで書いてみたわけね。

645デフォルトの名無しさん2016/08/04(木) 20:47:45.80ID:XSjm71+w
イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ

646デフォルトの名無しさん2016/08/04(木) 20:55:24.22ID:HlIXxJdQ
>>643
for each (range based for)でいいじゃん。

for (auto& item : collection)
{
// print an item
}

クロージャ風がいいなら、
std::for_each(collection.end(), collection.begin(), [](auto& item){ /* print */}

アイテレーターが登場するけど昔の名残みたいなもんで、
本質じゃないだろ?(範囲を指定してるだけ)

647デフォルトの名無しさん2016/08/04(木) 21:08:55.10ID:ILqHD9/M
>>642
クロージャを使ったらデコレータとは言わないのでは?
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。

無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。

言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。

648デフォルトの名無しさん2016/08/04(木) 21:15:46.97ID:jTAWnEUa
>>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。

649デフォルトの名無しさん2016/08/04(木) 21:21:02.95ID:CmNfOhbZ
>>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。

650デフォルトの名無しさん2016/08/04(木) 21:29:07.85ID:jTAWnEUa
Structureは日本語にしたら
構造って意味ですよw

651デフォルトの名無しさん2016/08/04(木) 21:30:27.36ID:CmNfOhbZ
>>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。

652デフォルトの名無しさん2016/08/04(木) 21:33:42.86ID:TDXgEb4R
継承してないと使えないとかじゃ困る。

653デフォルトの名無しさん2016/08/04(木) 21:34:27.18ID:jTAWnEUa
> そこが実質的な定義だと(俺様が)言ってるの。


知らんがなw

お前が何を言ったところで、
Structureは日本語にしたら構造
Definition(定義)じゃない。

まさか単語の意味を強弁するとは思わなかったなw

654デフォルトの名無しさん2016/08/04(木) 21:39:49.22ID:CmNfOhbZ
>>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。

655デフォルトの名無しさん2016/08/04(木) 21:51:04.78ID:jTAWnEUa
説得力0w

656デフォルトの名無しさん2016/08/04(木) 21:51:55.34ID:VNJ4iqic
この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。

657デフォルトの名無しさん2016/08/04(木) 22:03:13.75ID:jTAWnEUa
構造の一例ねw

658デフォルトの名無しさん2016/08/04(木) 22:10:23.67ID:CmNfOhbZ
デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。

659デフォルトの名無しさん2016/08/04(木) 22:12:49.41ID:jTAWnEUa
まさかデザインパターンがGoFの23個だけだと?
あれはパターン例だよ

660デフォルトの名無しさん2016/08/04(木) 22:14:24.41ID:CmNfOhbZ
>>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ?

661デフォルトの名無しさん2016/08/04(木) 22:20:23.44ID:jTAWnEUa
Structureは日本語にしたら構造
Definition(定義)じゃない。

国語と英語の問題なw

662デフォルトの名無しさん2016/08/04(木) 22:24:49.05ID:CmNfOhbZ
アホの一つ覚えとはこのこと

663デフォルトの名無しさん2016/08/04(木) 22:45:18.74ID:jTAWnEUa
効いてる効いてるw

664デフォルトの名無しさん2016/08/05(金) 05:47:03.48ID:Q5sCXOre
あるプログラム片の構造がパターンカタログのものと異なっていたら、
そのプログラム片はそのパターンの実装とは言えないな。

実際問題として、このスレで出ているRuby実装は、GoFに掲載されたデコレータパターンの実装ではない。
それを無視するなら、あなた (ID:jTAWnEUa) にはデザインパターンを使うための
最低限の素地が備わっていないということ。

665デフォルトの名無しさん2016/08/05(金) 07:23:44.09ID:TLRbqbFt
>>644
あまりにひどくて、なにをいっているかわからなかった。SmalltalkはともかくRubyのコードも読めないのかと。

内部イテレーターを使ったこの実装をイテレーターパターンだと言い切るのはどう考えても無理があるし、
同じ理屈でクロージャーを使った件の実装をデコレーターパターンだと言い張っているなら混乱するだけだからやめてほしい。

666デフォルトの名無しさん2016/08/05(金) 08:28:16.86ID:liZAD7d5
>>664-665
この二人は単に常識的な発言をしているだけだが
きっと相手には伝わらないだろうね

667デフォルトの名無しさん2016/08/05(金) 11:01:37.11ID:RHt058cj
結局オブジェクト志向が理解出来なくて管を巻いていたら
世間はプロトコル志向に移ってしまったでござるの巻
お前ら何周遅れたら走り出す気になるの?

668デフォルトの名無しさん2016/08/05(金) 12:54:45.79ID:Vwi1FrEy
Swiftのプロトコルも何周回目か遅れですよ?
ScalaやRustのトレイトとか知らないんですか?

669デフォルトの名無しさん2016/08/05(金) 13:11:37.22ID:ccW8btWE
イテレータをアイテレータって書いてる人がいるけど
どこの方言なの?
weblioさんの発音もイテレータなんだけど

670デフォルトの名無しさん2016/08/05(金) 14:20:51.80ID:1PWjv4l0
weblioワロタw もっとちゃんとした辞書持って来いよ。
Merriam Websterとかさ。和英辞書を引用して日本語論じたりしないだろ?

色々調べてみたけど、Wikitionaryのiterateでは二重母音の発音も載せてる。
その他の辞書では見つからなかった。

実際に英語ネイティブのアメリカ人が/ai/でも発音しているのを聴いたこともある。
伝統的には一般的な発音じゃなかったけど、IT界隈でよく使われているうちに、
発音変種が発生したんじゃないか? 英語発音学的にはどちらでも許容されそうだし。

671デフォルトの名無しさん2016/08/05(金) 14:53:55.08ID:1z/JWFxp
>>669
方言というより極度の経験不足なんだろ
イテレータについて人と語った事が無いから
間違いがずっと正されずにここまで来たんだろうな

672デフォルトの名無しさん2016/08/05(金) 15:20:22.46ID:Y7jgmn2a
>669
iとかitとかitrとかiterとかに略すから
アイ、イット、アイター、アイターとかって呼んでいるのでは
発音している本人に聞かないと真相はわからんがな

673デフォルトの名無しさん2016/08/05(金) 15:25:47.40ID:j/FnlCNZ
クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ

674デフォルトの名無しさん2016/08/05(金) 15:40:45.96ID:O4e+hfU+
クロージャーを使った実装はデコレーターパターン(GoFの)ではないという話なんだが

675デフォルトの名無しさん2016/08/05(金) 15:47:55.44ID:1PWjv4l0
>>673
別のパターンって言ってるだけでは?
覚えやすさや関連性からデコレーターの名前を関するのは自由だけど。

676デフォルトの名無しさん2016/08/05(金) 16:10:54.07ID:b8/AN42w
Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする

677デフォルトの名無しさん2016/08/05(金) 16:22:03.55ID:VlcB2rw7
デコレータパターンの機能を持っている設計を
全部デコレータパターンとしてしまっては
デザインパターンの意味がないからな

そりゃどんな方法でも同等の機能は実現するかもだが
ある程度を設計をパターン化して縛るのが目的でもあるからね
なんでもOKだったら意味ないよね

678デフォルトの名無しさん2016/08/05(金) 16:30:02.44ID:1z/JWFxp
カタログ化の価値を下げようとする連中は居るんだよ
広義のデザインパターンは〜とか
○○も××パターンの亜流と言えるだろう〜とか
拡大解釈と独自解釈でどんどん元の輪郭をぼやかしていくんだよ

679デフォルトの名無しさん2016/08/05(金) 18:48:03.79ID:zTXcoGD+
>>677
ケーキにホイップクリームのせるのもおちんぽにコンデンスミルクかけるのもデコレーションには違いないだろ実装が違うだけでやってることは完全に同じなのだから継承か委譲かクラスかクロージャかといった細かい違いを気にしなくていいからこその設計だと思うのだよ

680デフォルトの名無しさん2016/08/05(金) 18:50:15.99ID:zTXcoGD+
実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ

681デフォルトの名無しさん2016/08/05(金) 19:29:11.85ID:Q5sCXOre
>>680
そうか、おまえがいう「デザイン」「ソフトウェア設計」は実装を縛らないのか。
ずいぶんフリーダムなプログラマだなw

682デフォルトの名無しさん2016/08/05(金) 19:48:51.35ID:7blLYh/r
クラス図レベルがデザインパターン。
そこから実際にどう具体的な言語でコードに落とし込むかが実装。

クラス図レベルで全く違うものはパターンとして別物です。

683デフォルトの名無しさん2016/08/05(金) 20:06:03.26ID:i8crE51h
おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな?

684デフォルトの名無しさん2016/08/05(金) 20:28:42.82ID:1l5AtzWC
>>670
それ単に英語がなまっているだけだから

685デフォルトの名無しさん2016/08/06(土) 08:01:13.80ID:70rUJ/gH
>>684
なまってるんじゃなくて、発音が[i]の母音に強いアクセントがつくと[ai]に転じるのは普通。
iterateの第1母音は普通は[i]だが、iterateという語を特に強調する時には[ai]になることもある。

ちなみにweblioはUS出身のNLP研究者にも評価が高かったりするから、そう馬鹿にしたものでもない。

686デフォルトの名無しさん2016/08/06(土) 10:06:20.97ID:FhFbCTi8
>>685
だから英語の訛りでドイツ語やフランス語では起こらない
https://ja.wikipedia.org/wiki/%E5%A4%A7%E6%AF%8D%E9%9F%B3%E6%8E%A8%E7%A7%BB

687デフォルトの名無しさん2016/08/06(土) 10:13:18.00ID:BacY3CwA
だからどうしたんだって話

688デフォルトの名無しさん2016/08/06(土) 10:17:01.24ID:BZ9Nu5V3
アイテレータ君は頑張りどころを間違えてる

689デフォルトの名無しさん2016/08/06(土) 11:27:40.31ID:70rUJ/gH
>>686
Haben Sie gelesen, eine deutsche Übersetzung?

690デフォルトの名無しさん2016/08/06(土) 12:00:01.53ID:rJo5wxwi

691デフォルトの名無しさん2016/08/06(土) 12:02:23.29ID:rJo5wxwi
>>689
Was davon ist im Zusammenhang mit?

692デフォルトの名無しさん2016/08/06(土) 13:54:29.24ID:70rUJ/gH
>>691
Das ist meine Frage.

693デフォルトの名無しさん2016/08/06(土) 15:01:07.75ID:rJo5wxwi
Nein, es ist meine Frage

6946432016/08/06(土) 19:33:40.65ID:rdi0Pbkh
そんなアイレテーター君にヒントをもらった>>646 ですが、
週末の余暇を使って調べ調べ C++ で書いてみました。

http://ideone.com/aMHgqO

なるほど。このくらい抽象化して簡潔に書けるなら
今の C++ には35年ほど前の Smalltalk 同様イテレーターパターンは不要と言い切ってよさそうですね。

惜しむらくは逆順用の range-based for くらい用意しておけよ…、という不満は残りますが。^^;

695デフォルトの名無しさん2016/08/06(土) 20:05:53.09ID:OCZ+hMAU
そもそもbegin, endなどのモロモロが
既に(外部)イテレータ以外の何物でもないわけでw

内部イテレータ形式を欲しがるかどうかはともかく
range-based forとかはどうでもいいよねこの場合

696デフォルトの名無しさん2016/08/06(土) 20:24:55.16ID:fG7kY+EI
アメリカ英語なんて
英語の方言そのものだろ。w
トマトをトメイトゥとか、
ポテトをポテイトゥとか
馬鹿みたいな発音するんだぜ。
アイテレーターみたいな馬鹿っぽい発音が好きなのか?

697デフォルトの名無しさん2016/08/06(土) 21:29:05.67ID:rdi0Pbkh
>>695
おっしゃりたいことがよくわからなかったのですが
「イテレーター(内部なり外部なりの)が標準で提供されていればイテレーターパターン(GoFの)はいらない」
という主張(>>639,646)に対して「そもそも〜」はどういう反論で、
range-based forがなぜ「どうでもいい」という話になるのしょうか?

698デフォルトの名無しさん2016/08/06(土) 22:17:57.01ID:70rUJ/gH
>>693
おいおい、Neinに続いて肯定文とか、なんなんだその日本語みたいなドイツ語もどきはw

699デフォルトの名無しさん2016/08/06(土) 22:19:24.01ID:70rUJ/gH
>>696
はいはい、あなたは馬鹿ですよ。認めてあげましょう。

700デフォルトの名無しさん2016/08/06(土) 22:20:26.81ID:70rUJ/gH
>>695
>そもそもbegin, endなどのモロモロが
>既に(外部)イテレータ以外の何物でもないわけでw

だめだ、こいつは手の施しようがないw

701デフォルトの名無しさん2016/08/07(日) 00:32:53.21ID:Z9t6ZbaZ
>>697
ごめん
流れつかめて無かったわ

標準のコンテナにイテレータがあるんなら
それを使う限りはイテレータパターンの必要も無い
(内部イテレータ形式もrange-based forも無くてもいい)

それだけの話
スレの最初のほうに既に書かれてる話

702デフォルトの名無しさん2016/08/07(日) 00:34:17.18ID:JriZaYfU
もう少し正確に言えば、言語やライブラリが
イテレータパターンを実装しているから、
あとはそれに従うだけって感じかな。
意識せずにイテレータパターンを使っている。

703デフォルトの名無しさん2016/08/07(日) 00:40:31.89ID:fZ/XAaEO
>>702
そやね
その言い方は正しい

704デフォルトの名無しさん2016/08/07(日) 06:55:15.73ID:N62pNMnU
>>702
「意識せずにイテレータパターンを使っている」は大間違い。

7057032016/08/07(日) 08:03:17.31ID:vAScX9Az
>>704
そやね
そっちが正しい
パターンを使うのは設計者だからね

706デフォルトの名無しさん2016/08/08(月) 12:57:55.81ID:TCnmrmuR
おっすおらフリーダムプログラマ
日夜社畜プログラマと戦ってるだ

707デフォルトの名無しさん2016/08/08(月) 13:46:12.84ID:jSuSjrUB
>>702
> もう少し正確に言えば、言語やライブラリが
> イテレータパターンを実装しているから、

正確に言うなら、イテレータパターンというのは、
> コンテナオブジェクトの要素を列挙する手段を独立させることによって、コンテナの内部仕様に依存しない
> 反復子を提供することを目的とする
実装パターンのことで(Wikipediaより)、言語やライブラリがiterableな何かを提供しているからといって、
それらがイテレータパターンを実装しているとは限らない。

708デフォルトの名無しさん2016/08/08(月) 13:48:55.90ID:jSuSjrUB
>>680
> 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
発想が逆だね。
ある機能を実現するための実装パターンを分類・カタログ化したものが、GoFのデザインパターンだ。

709デフォルトの名無しさん2016/08/08(月) 21:13:01.03ID:BQ4UM/x3
まさしくその通りだね
そして同じ機能だったらどんな設計でもOKとしてしまっては
デザインパターンの意味がない
でもこの話題はもう終わりにしたいね

710デフォルトの名無しさん2016/08/08(月) 21:24:02.49ID:aqLNls7E
だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
だから積み木のおうちでも構わないんだよなぁ

711デフォルトの名無しさん2016/08/08(月) 21:38:41.07ID:dN7u7NbH
パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。

712デフォルトの名無しさん2016/08/08(月) 21:41:39.71ID:q4pU/gN8
>>709
とは言っても言語が違ってもデザインパターンは通用するわけで
実装がたった一つというわけじゃないのは確か

C言語でオブジェクト指向をすることだってあるし、
クラスがなかったES5時代のJavaScriptでもデザインパターンは作れた。

重要なのはデザインパターンの設計に出てくる登場人物があるかどうかではないだろうか?
例えば、Decoratorパターンだと、Component、ConcreteComponent、
Decoretor、ConcreteDecoratorという登場人物がある。

これはクラス図で書かれているだろうけど、別にクラスである必要はない。
例えばクロージャーを使って実装してもかまわない。
またインターフェースは明示的に継承していなくても、事実上特定の関数を実装していなければ
正しく動かないなら、それはインターフェースを使っていると言ってもいいだろう。

これと同じ登場人物が出てくるものは同じデザインパターンといっても良いだろう。

713デフォルトの名無しさん2016/08/08(月) 21:46:47.76ID:rabkqueT
そこまで行ったら別物だって。
クロージャーやら使ってクラス図レベルで逸脱してもいいという
宗派をひらきなよ。

714デフォルトの名無しさん2016/08/08(月) 21:57:23.36ID:q4pU/gN8
>>713
そうはいってもだね。
クラス図がないES5でもデザインパターンの
設計通りに作れるでしょ?

715デフォルトの名無しさん2016/08/09(火) 05:48:45.82ID:tGFAeOU0
>>712
ばーか

716デフォルトの名無しさん2016/08/09(火) 07:42:08.32ID:ttLAI02G
>>714
クラス、クラス図がないからデザパタにクラスは不要というのは、本末を転倒してますよ。

GoF も述べているように(>>610) クラスの無い言語では、クラスの役割りを「カプセル化」パターン、
「継承」パターン等で補ってから、その上でたとえばデコレーターパターンを実現しているというだけです。

717デフォルトの名無しさん2016/08/09(火) 09:40:43.48ID:zWs+JfAu
>>716
なるほど。言語仕様としてクラスの有無ではなく
継承パターンができていれば、その実装がクロージャーでも
かまわないということですね。

そして継承パターンと言うものには、何が何を継承している
という概念があるはずですから、その「何」が登場人物に
なるわけですか。

718デフォルトの名無しさん2016/08/09(火) 10:28:51.94ID:GFJow9Sf
登場人物という考え方がバカっぽくて無理

719デフォルトの名無しさん2016/08/09(火) 15:03:31.41ID:V7FsU68Q
「○○言語だともっと簡単に実装できる」君と
「クロージャを使えばもっと簡単に実装できる」君は
いい加減うざいよ?

720デフォルトの名無しさん2016/08/09(火) 16:26:29.88ID:tGFAeOU0
>>719
その通りだと思います。
まずはソフトウェア設計は実装ではないが、
実装を縛る規範であるということを
理解したらいいと思います。

それが理解できたら帰っておいで。

721デフォルトの名無しさん2016/08/09(火) 17:57:41.45ID:7qytW98y
デザインパターン
日本語で
設計見本でいいですか?

722デフォルトの名無しさん2016/08/09(火) 18:04:53.60ID:c6svxtGU
そんな日本語があるか

723デフォルトの名無しさん2016/08/09(火) 19:57:07.69ID:AUCg5/Tk
>>708
それは過程の話な結果として実装を示すならインプリメンテーションパターンと言っているだろうしかしデザインパターンと言っているから実装を抽象化したものだ具体的な実装を示すものではないってことさ

724デフォルトの名無しさん2016/08/09(火) 20:07:31.05ID:GFJow9Sf
その前に君の書き込みを日本語のパターンにしてください

725デフォルトの名無しさん2016/08/09(火) 20:08:56.33ID:AUCg5/Tk
>>681
設計が実装を具体的に決めてしまったら設計の意味がないと思うんだよおトイレとお風呂が一緒になってますってことと具体的な便器の形とは分けられると思うんですデザインパターンっていうのはいわばそういうものでお風呂とトイレを一緒にしたら便利だよってことさ

726デフォルトの名無しさん2016/08/09(火) 20:10:54.82ID:AUCg5/Tk
>>724
おだまり便器野郎

727デフォルトの名無しさん2016/08/09(火) 20:24:12.28ID:FqlEy475
どうせ計算式をクラスにするんだろ?

728デフォルトの名無しさん2016/08/11(木) 18:28:28.20ID:vQt/3MfO
濃厚電波、完飲。

729デフォルトの名無しさん2016/08/15(月) 00:10:10.82ID:NEOTEyUk
いい加減、オブジェクト指向 vs 関数型なんていう無意味な議論やめようよ
直交する概念じゃん
関数型言語でも「本物の」オブジェクト指向プログラミングは出来るし、
最近の流行りはオブジェクト指向言語に関数型的な機能を付けることだろう

730デフォルトの名無しさん2016/08/15(月) 01:36:24.27ID:Yh7//hE4
本当のオブジェクトプログラムは、メッセージ交換だから、関数型が入る余地なんか無いけどな。

731デフォルトの名無しさん2016/08/15(月) 02:08:53.20ID:6fraHMZW
お前ら、早く本論に入れ!
美少女クラスはなぜ人間クラスを継承出来ないのよ!!!

732デフォルトの名無しさん2016/08/15(月) 03:13:33.69ID:Y0Jnfl62
美少女はクラスじゃなくて人間クラスのインスタンスで
パラメータが特定の値のものなだけだよ。

プリンセスメーカーであれば「魅力」のパラメータが
高くて「年齢」が若ければ美少女なんじゃね?

733デフォルトの名無しさん2016/08/15(月) 11:57:12.25ID:P1EAyeII
排便メソッドはどうなるんだ!

734デフォルトの名無しさん2016/08/15(月) 13:00:28.85ID:TUIKyN4z
>>729
本物…

735デフォルトの名無しさん2016/08/15(月) 13:36:04.19ID:Yh7//hE4
>>732
まあそうだな。
人間クラスの女性属性で年齢属性が十代で、
あとはいろんなパラメータがバランス良く絶妙なバランスであるだけ。

736デフォルトの名無しさん2016/08/15(月) 13:43:17.25ID:Y0Jnfl62
>>733
排便性能とでもいうパラメータ作れば良いんじゃねーの?
美少女じゃなくても排便が困難な人っているからな。

737デフォルトの名無しさん2016/08/15(月) 15:37:08.19ID:Yh7//hE4
便秘気味な美少女かw

738デフォルトの名無しさん2016/08/15(月) 16:44:15.38ID:uCi+R87y
            | 
            |  彡 ⌒ ミ 
           \ (´・ω・`)またうんこの話してる... 
             (|   |):::: 
              (γ /::::::: 
               し \:::
                  \

739デフォルトの名無しさん2016/08/15(月) 16:45:21.70ID:P1EAyeII
オブジェクト指向は愚かな考え。
排便メソッドを実装した人間クラスから美少女クラスが作れない。

740デフォルトの名無しさん2016/08/15(月) 17:02:42.33ID:NHD7YcMK
アヒルががーがーなくのではなく、がーがー鳴けばそれがアヒルなのである
うんこができればそれは人間なのである

741デフォルトの名無しさん2016/08/15(月) 17:08:50.15ID:Y0Jnfl62
オウムがガーガーなけばそれはアヒルなのである?

742デフォルトの名無しさん2016/08/15(月) 19:19:30.08ID:ATo5mwbJ
>>738
「ウンコを覗くときウンコもまたおまえを覗いているのだ。」

もうこの子は脳の端までウンコになっちゃったんだよ…

743デフォルトの名無しさん2016/08/16(火) 12:32:47.23ID:nB+m5lHF
頬を紅潮させた少女のアナルは今にも決壊寸前のダムの如くヒクヒクと静かに脈打つのであった
そのアナルをまるで獲物を狙う蜥蜴の様な眼差しでジットリと凝視していたお前は…

744デフォルトの名無しさん2016/09/04(日) 22:44:30.10ID:AI4OMPbE
やはり、オブジェクト指向は愚かな考えなんでしょうか?
それはなぜですか?

745デフォルトの名無しさん2016/09/05(月) 23:26:30.97ID:2pvjX+vh
>>744
なんのメリットもないから

746デフォルトの名無しさん2016/09/10(土) 22:12:27.45ID:vL431mpn
クロージャという秘境

747デフォルトの名無しさん2016/09/11(日) 09:06:24.12ID:HdsNani4
オブジェクト指向にクロージャーが取り入れられてから、
オブジェクト指向は更に便利になった。

748デフォルトの名無しさん2016/09/11(日) 09:11:08.53ID:xTqWSUIJ
どうせなら理想のクロージャの構文はどんなものか議論しよう。
美少女のウンコの話はもういいから。

749デフォルトの名無しさん2016/09/11(日) 10:48:53.37ID:EVh79L2H
いや美少女うんこの方が重要だ

750デフォルトの名無しさん2016/09/11(日) 18:47:04.73ID:LruamEXh
間をとってクソージャ

751デフォルトの名無しさん2016/09/12(月) 10:17:01.19ID:WLe9OZIE
おあとがよろしいようで

752デフォルトの名無しさん2016/09/12(月) 11:18:07.22ID:DqPwyMnw
じゃあ質問
若い時は買ってでもするものな〜んじゃ?

753デフォルトの名無しさん2016/09/12(月) 11:24:36.38ID:R5hylYBo
コンビニでトイレだけ借りるのは気まずいので後で何か買って帰る

754デフォルトの名無しさん2016/09/12(月) 13:15:37.24ID:zvXoPKj/
美少女を買う

755デフォルトの名無しさん2016/09/12(月) 21:03:27.94ID:p0km3lhz
>>752
http://find-travel.jp/article/2123

シンガポール初 キッズクラブ

12歳までの子供が安全に遊べます。小さい子供連れのファミリに―にはうれしい施設です。
セントーサエキスプレスの終点ビーチ駅で下車、徒歩五分ほどです。
子供は有料ですが、付き添いの大人は、無料です。

756デフォルトの名無しさん2016/09/12(月) 21:04:17.88ID:p0km3lhz
http://www.dan-b.com/tp_luna/page1_1.html

ウェーブスターライド

すべり台

もくば館の電動木馬
自走式のジェットコースター。小さなお子様でも、
大人の付き添いがあれば乗れる。
付き添いの大人は無料にしてくれる心遣いがうれしい。

757デフォルトの名無しさん2016/09/17(土) 19:06:05.53ID:iND/Jut9
オブジェクト指向と計算式という対比がまずおかしいスレ

758デフォルトの名無しさん2016/10/11(火) 13:34:51.26ID:SPhMZv+b
>>757
その前に>> 1の脳みそがオカシイ。
議論以前の話

759デフォルトの名無しさん2016/11/14(月) 16:47:20.70ID:cBDVjyju
>>733
排便メソッドつくってうんち吐き出させれば良いじゃん…

760デフォルトの名無しさん2017/03/21(火) 23:51:29.32ID:RJ2XVIqX
できの悪いプログラマはこうやってくだらんことに執着した挙げ句道を外すからな

オブジェクト指向を禁ずるのは当然だが、プログラムも規制すべきだろ

761デフォルトの名無しさん2017/05/12(金) 17:45:37.79ID:4b98WttR
外に公開するインターフェイスだけオブジェクト指向で中身は手続きとかできないの?

762デフォルトの名無しさん2017/05/13(土) 00:36:36.42ID:1iFjjcJx
欲張りな事言うんじゃありません!

763デフォルトの名無しさん2017/05/13(土) 06:58:15.64ID:tunExteF
なんでもかんでもOOPしないといけないという強迫観念も新しい病気みたいなもんだ

764デフォルトの名無しさん2017/05/14(日) 02:14:38.21ID:92l7gqU0
OOPは自然な概念。
しようとしなくても自然にOOPで書いてしまう。

765デフォルトの名無しさん2017/05/14(日) 03:31:10.29ID:DFEPxXnF
んじゃ、Cでファイル読んで行毎に番号振るプログラムを自然にOOPで書いてくれ。

OOPな言語でも油断してると手続き的なコードになるのが実感。
手続き型言語や関数型言語のが自然と言えば自然。
OOPはどっちかと言うと手続き型言語の限界を超える苦肉の策。
有効ではあっても、自然ではない。

766デフォルトの名無しさん2017/05/14(日) 07:58:36.42ID:HpXv37Pf
手続き型の言語使ってるんだからそりゃ書き方は自然に手続き的になるわw

767デフォルトの名無しさん2017/05/14(日) 08:01:38.88ID:FpH7uWr+
>>765
とりまなんかのOOPLで「ファイル読んで行毎に番号振る」操作の“油断した”版をideone.comあたりで晒して見せてよ

768デフォルトの名無しさん2017/05/14(日) 09:35:08.29ID:Kxs5LDLR
>>765は愚かな考え

769デフォルトの名無しさん2017/05/15(月) 00:15:06.25ID:pPIG/Itw
>>765
> Cでファイル読んで行毎に番号振るプログラム
FILE構造体使うからOOPだな。

770デフォルトの名無しさん2017/05/15(月) 03:18:59.80ID:sMDSuUUf
後での取り回しのために動作分離してオブジェクトにするんであって
なんで"その中身をオブジェクト指向で書けるか?"なんて
頓珍漢な発想が出るのかの方が不思議だよ。

771デフォルトの名無しさん2017/05/15(月) 07:10:20.57ID:fipzejMn
まぁそうだよね。関数型だって関数の中味に手続き書くだろうし

772デフォルトの名無しさん2017/05/15(月) 07:18:26.21ID:Nl227Lk0
関数型言語で手続きは書けんですわ

773デフォルトの名無しさん2017/05/15(月) 09:31:45.07ID:OVQU3b0Y
んなこたーない何のためのモナドだよ

774デフォルトの名無しさん2017/05/15(月) 12:20:31.47ID:BOxxzUgK
>>771
関数型言語では手続きは書かない。
式か、式とパターンマッチやガードによる条件わけだけ。モナドもdo形式で書くと手続きっぽいけど、実際は大きな一つの式。

if/caseに似てるけど、文と式が入り乱れるのと違って全部式。
それで何が嬉しいかと言うと、正しい動作をすると言う証明が出来る。

775デフォルトの名無しさん2017/05/15(月) 12:31:36.20ID:ADjMf5zc
せやね関数型言語でも中身はモナド駆使して手続き的に書くのが自然やからね

…せやろか?

776デフォルトの名無しさん2017/05/16(火) 00:16:27.17ID:HWJ+4Z2c
>>767
import sys

for i, line in enumerate(open(sys.argv[1])):
____print i, line,

Python3だとprint i, line end = ' '

ついついこう書いちゃうだろ?
でも、出力先がGUIになった途端破綻する。
そう言うのを見越して汎用的にしとかんと。

777デフォルトの名無しさん2017/05/16(火) 06:05:49.63ID:TdUcLCGW
出力先を切り替えられるようにしたい、は別の要件でしょ

778デフォルトの名無しさん2017/05/16(火) 06:12:48.09ID:YL1OfOAE
>>776が全然破綻しとらん件

779デフォルトの名無しさん2017/05/19(金) 01:55:11.10ID:879cm/wV
CでOOPしてたやつって、なんかのGUIライブラリでなかったっけか?

780デフォルトの名無しさん2017/05/19(金) 10:49:17.61ID:sbMh7Sut
gtk

781デフォルトの名無しさん2017/05/22(月) 08:36:50.27ID:wGbbC49U
X

新着レスの表示
レスを投稿する