16/01/05 02:40:11.66 3cj4CitF.net
>>1 = ハゲ
>>3-1000
ゴミ
死ね
3:デフォルトの名無しさん
16/01/05 08:10:47.12 WVEw1bNF.net
相変わらず気が狂ってるね
4:デフォルトの名無しさん
16/01/05 21:54:42.69 8fihq/Cm.net
オブジェクト指向は直観に反するんだよな。
こいつを見てくれ。
URLﾘﾝｸ(pbs.twimg.com)
Coffeeオブジェクトに振る舞いがある。これはオブジェクト指向的に完全に正しい。
しかし、現実にコーヒーを飲むのは人間だ。コーヒーは人間によってカップに注がれる存在だ。
これが思考を混乱させる。オブジェクト指向に従うとよくわからないソースコードのできあがりだ。
データに振る舞いを持たせるのは大失敗だと言わざるを得ない。
5:デフォルトの名無しさん
16/01/05 22:44:58.11 zW6slUa6.net
空かどうか判定するEmpty()を定義したCupクラスとLiquidクラスを継承したCoffeeクラスを作って、HumanクラスにRefill(Cup,Liquid),Drink(Cup)を定義すればいいだけだ
if(cup.Empty())
{
human.Refill(cup,coffee);
}
else
{
human.Drink(Cup);
}
6:デフォルトの名無しさん
16/01/05 22:47:52.22 i0IFFoJB.net
コーヒーの属性定義が広範囲すぎる
量をのオブジェクトに突然､実態コーヒーを入れている
量のオブジェクトの範囲のクラスを作っる
コーヒークラスに量をコンポジションさせる
設計の間違え
7:デフォルトの名無しさん
16/01/05 22:51:39.37 GCWuNCn0.net
>>4
単純。
コーヒーはただの量であり、人間オブジェクトの一変数だ。
いや、コーヒーはオブジェクトであり、生成からの時間により温度変数の値が変わる。
いや、コーヒー生成の時刻を保持するのは人間であり、コーヒーの温度を計算するのは人間である。
いや、コーヒーはコーヒーサーバーオブジェクトの変数であり、、、、
8:デフォルトの名無しさん
16/01/05 22:55:26.17 i0IFFoJB.net
>>5
ま^､これでもいいがこれをオブジェクト指向と思っている時点で
何をやっても後が大変｡
9:デフォルトの名無しさん
16/01/05 23:02:31.55 zW6slUa6.net
>>8
目的次第としか言えんわ
直感的なコードが求められるなら>>5ってだけ
10:デフォルトの名無しさん
16/01/05 23:15:31.85 i0IFFoJB.net
その直感が､直感的だと思う時点
斜め直感にしか見えん
11:デフォルトの名無しさん
16/01/05 23:33:07.12 QVqdPGfo.net
すまん、自動で口にコーヒー注いでくれない前時代のコップ使ってる雑魚おる？
12:デフォルトの名無しさん
16/01/06 00:33:16.74 73ZB/O6z.net
胃瘻はかなり前に技術だが
13:デフォルトの名無しさん
16/01/06 02:56:11.57 MPHK5bs1.net
>>5
おまえはカップを飲むのかw
14:デフォルトの名無しさん
16/01/06 06:53:26.42 UF966QGg.net
現実をそのままモデル化してOO否定って5周くらい遅れとるで
15:デフォルトの名無しさん
16/01/06 07:15:47.25 QNndC4zW.net
形式主義ではコーヒーを椅子に置き換えても成り立つってことをいいたいんじゃないのか。
16:デフォルトの名無しさん
16/01/06 08:11:16.53 xFxLYqzC.net
>>14
>>4は現実をそのままモデル化できていない。
大事なのは、そのままモデル化するのではなく、どうモデル化するかなのだ。
17:デフォルトの名無しさん
16/01/06 08:45:38.03 /XlzX9bH.net
人間は現実を直接みてるわけじゃないからね
18:デフォルトの名無しさん
16/01/06 08:58:13.58 9xF4ChVe.net
まー初心者(OOだけでなくプログラミング全般の初心者)向けのオブジェクト指向の解説とかでよくある説明だよね。
「オブジェクトとは日本語で物、対象物などという意味です」みたいなさ。とっかかりとしては平易なためによく使われているけど、
数学の定義のように後生大事にするべき、応用の効く、正しいイメージじゃない。
19:デフォルトの名無しさん
16/01/06 11:11:49.69 wCEM/hYT.net
>>1
乙
20:デフォルトの名無しさん
16/01/06 11:14:02.62 Nukx80Um.net
クラスは原子陽子中性子くらいから完璧に継承すべき
21:デフォルトの名無しさん
16/01/06 11:15:12.81 nQqbz+/u.net
メソッドに何かやらせるのはやめて全て物理演算で動作を決めるべき
22:デフォルトの名無しさん
16/01/06 11:19:28.24 dAXQ+tnq.net
コンピュータ内でシミュレートするのではなく実際の分子原子を用いるべき
23:デフォルトの名無しさん
16/01/06 11:34:29.07 KjcuT4OL.net
そんなことしたら分子原子の仕様変更で全てがひっくり返るぞ
24:デフォルトの名無しさん
16/01/06 11:54:24.95 nQqbz+/u.net
メソッドコールのかわりにオブジェクトに対するフォースとトルクを搭載した言語を作ればいい
25:デフォルトの名無しさん
16/01/06 11:57:30.95 nQqbz+/u.net
>>13
これ、どう表現すべきなのか？
26:デフォルトの名無しさん
16/01/06 12:01:41.51 QNndC4zW.net
beDrank, beRefilledにかえればいいだけだろ。
27:デフォルトの名無しさん
16/01/06 12:26:10.76 HvQ48C0N.net
>>25
drinkに渡すのはcup.contentsとかにする？
28:デフォルトの名無しさん
16/01/06 13:44:41.72 ZUCJrGIg.net
>>4は一般的なコーヒーのモデル化じゃなくて
コーヒーの消費が常態化したマの皮肉じゃないの
最後にコメント付いてるし
29:デフォルトの名無しさん
16/01/06 21:55:30.95 kAnzyWXR.net
オブジェクト指向は無理
30:デフォルトの名無しさん
16/01/06 21:55:58.83 zRcw+KQb.net
まったく直感的ではないな
31:デフォルトの名無しさん
16/01/06 21:56:37.47 fWGpYiip.net
こうしてクソみたいなソースコードが溢れた
32:デフォルトの名無しさん
16/01/06 21:57:33.23 ljmmccCR.net
>>25-27
こんな議論になる時点でオブジェクト指向はヤバいだろ
33:デフォルトの名無しさん
16/01/06 21:58:49.59 ljmmccCR.net
>>2
死ね
34:デフォルトの名無しさん
16/01/06 22:00:48.90 vTtwKBx3.net
>>9
そこまでしてオブジェクト指向にこだわる意味がわからない。
そんなもんperlやrubyのワンライナーですませろよ
35:デフォルトの名無しさん
16/01/07 00:25:26.48 idw/W9gn.net
オブジェクト指向も結局はコミュニケーションというか
メソッド(関数)指向という方が正しい。
結局はメソッド(関数)をどのように呼ばれるか、まとめられるかってことだから。
36:デフォルトの名無しさん
16/01/07 01:03:06.56 Spe75WNW.net
メソッドは関数ではない
メソッドとは特定のオブジェクトにのみ適用可能な手続きであり、
関数とは特定のオブジェクトに依存しないものである
特に純粋関数は状態にも依存せず、参照等価性が成り立つものである
ところでオブジェクトが状態を持たず、メソッドを持たなければ、
それは単なるデータ(例えばハッシュマップ)と同じである
従ってオブジェクトというものは状態、及びメソッドの存在を暗示している
オブジェクト志向とは全てのものを変更可能なデータ（言い換えればエンティティ）とメソッドで表そうという観念である
関数型はそれに反して極力多くのものを変更不可能なデータ（値）と関数で表そうとする
ここの話はいわゆるドメイン駆動設計にも絡んでいる
どちらが、現実世界の捨象に有用であるかということが問題なのである
37:デフォルトの名無しさん
16/01/07 01:15:30.61 Spe75WNW.net
オブジェクト志向で実装可能なことは、原理的に関数型でも実装可能であり
関数型で実装可能なことは原理的にオブジェクト志向でも実装可能なはずである
関数はオブジェクト志向においては、staticクラスを使えば実装できる
メソッドは関数型においては、第一引数によって動作を変更するポリモーフィズムとして実装できる
問題はどちらが汎化に適しているかということなのである
関数型にはオブジェクト指向では綺麗に実装できない麗としてマルチメソッドというものがある
これは第一引数及び第二引数＋・・・の型を持ってして動作を変更するという技であるが、
特定のオブジェクトに依存しているオブジェクトにおいてはこれはif文を内包したディスパッチをする他に実装する方法はないだろう
一方staticクラスによる関数のパッケージ化は煩雑である
必要な関数だけをインポートするには、その関数を内包したstaticクラスをインポートする必要がある
もしここで厳密なカプセル化を適用するならば、
1つの関数のために1つのクラスを使う必要がある、さもなくば利用可能でない関数も同時にインポートしてしまう
カプセル化もまた、オブジェクト志向の特権ではないのである
関数型は関数をカプセル化しているのである
そして変数のカプセル化もまたクロージャで実装できる
オブジェクト志向での変数のカプセル化は容易ではあるが、本当に変数はカプセル化されるべきか
それが私の問いなのである
38:デフォルトの名無しさん
16/01/07 01:40:36.54 6wDD5ILY.net
>>37
その問いにおける「変数」とは状態のことであるから、
それは構造化・カプセル化によってアクセス制限されるべきなのは明らか。
39:デフォルトの名無しさん
16/01/07 02:02:35.73 EDvZlrKk.net
>>1>>4
結局のところ、この問題に誰もが納得するシンプルな回答を示せない奴が設計するからデスマーチになるんだろ。
40:uy ◆Qawu9.2l1E
16/01/07 03:17:27.43 VBUUQOGk.net
自分も参加してるプロジェクトでデスマが起こるなら多分自分にも原因があるんだと思うよ
41:デフォルトの名無しさん
16/01/07 03:22:02.67 Y5yasR7+.net
>>4
そもそもなんでコーヒーに命令するとコーヒーが自分で動作してんだよ。
そんなコーヒーがあるかw
いきなり設計段階から間違ってるじゃねーか
どう考えても最後の"//I am a software developer"って時点で
そういう設計をやらかす>>4みてぇなバカを揶揄したセルフパロじゃんかw
42:デフォルトの名無しさん
16/01/07 04:03:14.50 Y5yasR7+.net
ああ、ジョークまで完全に見えた
>>4は「プログラマがコーヒーを飲む」じゃなくて
「コーヒーがプログラマに飲まれる」って逆転ジョークで
絶え間なくコーヒーが自動的にプログラマに注がれ続ける
おかしな逆転コードでプログラマジョークになってんだ。
「こいつをみてくれ」じゃねーよ！プププ
43:デフォルトの名無しさん
16/01/07 04:17:18.05 boatvz1E.net
>>36-37 が大嘘であることはOCamlの存在が証明している
44:デフォルトの名無しさん
16/01/07 14:46:08.69 Geoe+pHe.net
こういう根本的に理解できてないのが大量に居る時点で、オブジェクト指向は愚かな考えｗ
45:デフォルトの名無しさん
16/01/07 15:46:48.63 bWvRU875.net
コーヒーはどうでもいいけど、
2.log() とか数に数学的関数計算をくっつけるってどうなのよ？
気持ち悪いったらありゃしねえ。
46:デフォルトの名無しさん
16/01/07 18:04:34.20 nwSyjPdt.net
数学みたいにlog(2)でいいと思うが。
その()は何のためにあるんだと言いたい。
47:デフォルトの名無しさん
16/01/07 19:24:41.82 bWvRU875.net
大分昔だけどフリー関数は気持ち悪くて、1.sin()とか1.cos()とか書けるのが本来の在り方だ、といった
痛い記事を読んだ記憶がある。Rubyがらみだったかなあ。
今ちょっと検索すると見つからないから俺の妄想なのかもしれん。
48:デフォルトの名無しさん
16/01/07 19:33:58.76 LLMMv1AA.net
数字は計算をしないからそう書いちゃいかんのだけどな
49:デフォルトの名無しさん
16/01/07 19:53:48.55 wknU54yj.net
+ 1 2
50:デフォルトの名無しさん
16/01/07 21:42:11.31 a7kpSA/c.net
死ね括弧
51:デフォルトの名無しさん
16/01/07 21:57:00.05 sG4YEGv+.net
(スズ)
拝承
52:デフォルトの名無しさん
16/01/07 22:18:47.33 a7kpSA/c.net
>>46
> 何のため
関数そのものなのか、関数を呼び出した結果なのかを区別する括弧。
括弧がなければ関数そのもの、あれば関数呼び出しの結果。
括弧がなければlogという関数そのもの、あればlog(hoge)の計算結果。
かどうかは言語による。
53:デフォルトの名無しさん
16/01/09 14:00:07.10 8eWGVEYX.net
>>45
こういう主語述語みたいなくだらない議論に陥るのがオブジェクト指向の最大の問題点だな
どっちでもいいからそのためのテストなりサンプルコードをがつがつ作ってくれれば問題ないんだが
糞みたいな議論ばっかりふっかける輩を生むところが最大の問題点だな。
54:デフォルトの名無しさん
16/01/09 14:37:25.60 hdqMNonU.net
>>53
何も考えずに作業こなすだけの社畜 VS 議論ばかりやる頭でっかち ファイッ！！
55:デフォルトの名無しさん
16/01/09 16:12:34.83 8eWGVEYX.net
>>54
極論煽るだけのカスも大概だけどな
56:デフォルトの名無しさん
16/01/09 17:15:53.50 3kY/wzgi.net
>>53
ドット構文を変な風に使うバカの問題であってオブジェクト指向関係ないな。
57:デフォルトの名無しさん
16/01/09 18:23:24.86 oGyr6/WF.net
主語述語っていうけど、オブジェクトは目的語だからね
58:デフォルトの名無しさん
16/01/09 19:25:35.83 oGyr6/WF.net
昔ながらのfunc( obj ); 形式だと、オブジェクトを主語と考える人はいないだろうし
obj.func(); は↑が変形したものにすぎないから同じ理屈だよね
しかも時期C++ではfunc( obj )でもobj.func()でもどちらの形式でも呼び出せるようにするって
C++の超偉い人がやる気満々だし、見た目は最早重要ではないよね
普通に考えると、主語はコンピュータや処理系だね
プログラミングを全然知らない人でも、主語は誰？って聞いたらコンピュータって答えるだろうね
何するにしても、結局実行するのはコンピュータだからね
これが全く現実世界でおこっている物理現象なのに、あえてオブジェクトを主語という風に
ひねくれた別な観点で考え直す必要は無いね
現実世界に合わせて、主語をコンピュータ、オブジェクトを目的語、関数を述語、と捉えると
それで多態や継承が出来なくなるっつーんなら困るけど、そういうわけではないからね
だったら現実世界で起こっていることに合わせて考えたほうが自然だね
59:デフォルトの名無しさん
16/01/09 19:39:23.22 OrUjMMRy.net
メッセージングのオブジェクト指向の言い方で言うと、
主語はメッセージのレシーバであり、文の残りはメッセージだ
60:デフォルトの名無しさん
16/01/09 23:40:46.34 3kY/wzgi.net
>>58 チンパンジーのアイちゃんかな？
61:デフォルトの名無しさん
16/01/09 23:55:42.86 CpCNnIMM.net
>>58
x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。
どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想（？）の根源は何なんだ？
62:デフォルトの名無しさん
16/01/10 00:13:34.71 MD/fGeTk.net
ポーランド記法嫌いそう
63:デフォルトの名無しさん
16/01/10 00:21:12.30 sdj7zt3O.net
演算子前置のポーランド記法は嫌いだなぁ
存在する意味がわからないレベルで嫌い。
演算子後置の逆ポーランドじゃないとね。
64:デフォルトの名無しさん
16/01/10 00:34:49.51 0XznusY4.net
> 存在する意味がわからないレベルで嫌い。
なんで？
> 演算子後置の逆ポーランドじゃないとね。
なんで？
65:デフォルトの名無しさん
16/01/10 00:40:13.45 hoksOuY6.net
Add 3 to 5, then multiple it by 2.
66:デフォルトの名無しさん
16/01/10 01:09:07.40 UgGJRpwk.net
逆ポーランドの方が実装しやすいと思う。
人それぞれの範疇だが。
67:デフォルトの名無しさん
16/01/10 01:11:54.59 MiN6/z6v.net
>逆ポーランドの方が実装しやすいと思う。
意味がわからん。
構文木作るのに一番前と後でなんか変わるか？
AST作らずにそのまま逐次実行するならスタックに
積むだけでいい逆ポーランドの方がいいかもしれんが
68:デフォルトの名無しさん
16/01/10 01:16:08.27 +l1yiqNW.net
x.sin() では x がオブジェクトで、sinというメソッド（もしくはメッセージ？）を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。
どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想（？）の根源は何なんだ？
違うよな
どちらがオブジェクト志向的かといえばx.sin()でしょ
xというオブジェクトにsin()というメソッドが属しているという考えなんだから
sin()は関数に対してxというオブジェクト、あるいは単にデータを引き渡しているだけ
後者は明らかに関数的な考え方、動詞優位
69:デフォルトの名無しさん
16/01/10 01:27:11.07 hZikTLMs.net
関数へのエイリアスのようなメソッドはドットで繋ぐのでなく、
別の文字にした方がいいよな。
70:デフォルトの名無しさん
16/01/10 01:29:17.31 sdj7zt3O.net
釣りじゃなくて単に本当にあたまおかしいのかな？
Xはデータであって演算ではない。Xは演算しない。
Xをオブジェクトとして扱った場合、その操作として実装されるメソッドは
データのゲットセットなど内部状態を隠蔽するためのメソッドと
可変不変などのデータ状態をあらわすメソッド。
まだお前の脳内じゃおまえがコーヒーを飲むんじゃなくて
コーヒーが勝手に口に飛び込んで来てんのか。
71:デフォルトの名無しさん
16/01/10 01:29:19.21 Ch7U5rc3.net
x.sin()は手続き言語的だと思うけどなあ
もちろんsin(x)も。
オブジェクト指向ならメッセージを送るような記述の方が自然では
72:デフォルトの名無しさん
16/01/10 01:52:12.61 hZikTLMs.net
現実世界をオブジェクト指向に当てはめるやついるけど馬鹿だよなー
コーヒーが勝手に口まで運ばれてくる機能をコーヒにつけただけじゃんw
ついでにコーヒーがしゃべる機能もつけたよ。
問題がないからそういう設計にしたんですよ
73:デフォルトの名無しさん
16/01/10 01:53:23.52 +l1yiqNW.net
どちらがより汎化されているかではなく
具体例で語ろうとする人間は、プログラムを実装したことがないのでは？
具体的な手続きによる具体的な文字通りのプログラムを書きたいなら
Cでかいてどうぞ
74:デフォルトの名無しさん
16/01/10 01:59:31.92 +l1yiqNW.net
オブジェクト指向だろうと関数志向だろうとやってることは変わらない
オブジェクトはメソッドの第一引数でしかない
コーヒーを飲むという行為を書くためには手続き的に書くしか無い
コーヒーが俺の口の中にあるという結果を宣言的に書きたいのに
その手続きを丹念に描写したいならそうすればいい
I.drink(coffee)と書けばいいんだよ
I.drink(coffee)とyou.drink(coffee)は飲み方が違う！というのならそう実装すればよい
モデリングとは物事を単純化する行為、汎化する行為であって具象化する行為ではない
Iとyouの違いがモデルのキーポイントなら、Iとyouという（メソッドの第一引数）をパラメータに加えればいいし
そうでないなら含まないほうがモデルがシンプルに保たれる
数学ができない自称モデラーはプログラムを手続き的に書いたらいいんだよ
75:デフォルトの名無しさん
16/01/10 02:00:42.57 hZikTLMs.net
特化させたいのに汎化する必要ある？
狭い世界で使うなら特化させていい。
広い世界で使うなら汎化させる。
それだけ。
76:デフォルトの名無しさん
16/01/10 02:03:41.63 hZikTLMs.net
汎化と特化させるもんを決めるのが設計な
77:デフォルトの名無しさん
16/01/10 02:42:12.92 JhCLPk/2.net
>>74
言ってることはわかるがコーヒーを主語に対象を汎化なら
coffee1.drunkBy(me);
coffee2.drunkBy(you);
だろ
78:デフォルトの名無しさん
16/01/10 03:01:38.69 JhCLPk/2.net
>>72
普通モデリングなんて想定される実装の多さや効率の問題で変えるものだからね
感性にまかせる初心者ほど文脈や抽象に拘って依存性の上下を無視するよ
79:デフォルトの名無しさん
16/01/10 04:22:46.36 sdj7zt3O.net
アクセル→エンジン→ギア→タイヤじゃなくて
タイヤ.回転で自動車設計してそうだなおまえら。
80:デフォルトの名無しさん
16/01/10 05:12:47.23 JhCLPk/2.net
>>79
そうやって現実の構造を想定している時点でもう駄目なんだよ
81:デフォルトの名無しさん
16/01/10 05:20:12.43 JhCLPk/2.net
ちうかこれオブジェクトが目的語とか言ってる人か？
英語とプログラミングのobject混同とかとてもまともとは思えないよ
82:デフォルトの名無しさん
16/01/10 05:34:14.40 97NQyWJD.net
>>74
JavaScriptだと実際foo.barは第０番目の引数を指定するための糖衣構文でしか無い
オブジェクト指向は別にそんな大したものでも、手続き型と相容れないものでもない
指向とは言うが実際の所スタイルの一部だね
83:デフォルトの名無しさん
16/01/10 08:13:48.91 86WjwACC.net
いいえ、自転車.操業で設計しています
84:デフォルトの名無しさん
16/01/10 08:49:55.36 jS8+hJYw.net
>>82
そういう嘘をまき散らさないでもらいたいなあ。
毛の人といい、技術の普及は嘘との戦いだな。
オブジェクト指向は嘘つきが多すぎた。
85:デフォルトの名無しさん
16/01/10 09:36:41.30 AcnVMiQc.net
>>68
いいえ。
sin(x) と書いたときのsinは十分オブジェクトに見えるでしょ。
xとsinは違う階層（空間）に属するモノだけど、後者の方が階層としては高い。
x.sin()と書くと、あるオブジェクトが自分より高い階層のオブジェクトを所有しているように見えてしまう。
これは俺にとっては不自然なので好きになれない。
86:デフォルトの名無しさん
16/01/10 09:42:21.66 KeJgEHCD.net
オブジェクト指向は手続き型と直行する概念だと理解してないのが何人かいるな
87:デフォルトの名無しさん
16/01/10 09:44:41.71 sdj7zt3O.net
>>80
"現実の構造を想定しちゃダメ"て
おまえの作るシステムはどんな現実離れした
脳内妄想ベースなんだよ。
88:デフォルトの名無しさん
16/01/10 09:52:56.57 Itquv6VW.net
sinは関数だろね。
テーブルを持つためにクラスを使わなければならない言語があったとしても、
極力、ユーザーにとって関数に見えるように実装するべきじゃないのかな。
89:デフォルトの名無しさん
16/01/10 10:08:13.09 jS8+hJYw.net
関数がオブジェクトじゃ何か困ることでも？
90:デフォルトの名無しさん
16/01/10 10:09:40.58 jS8+hJYw.net
>>79
君が設計する自動車ではエンジンブレーキが効かないようだな。
91:デフォルトの名無しさん
16/01/10 10:29:26.64 hZikTLMs.net
ブレーキなんてのは外部から
ベクトルの力を操作するんだから
後付けで全然構わないんだが。
92:デフォルトの名無しさん
16/01/10 10:41:27.70 AcnVMiQc.net
関数を手続きだと思ってるならそれでいいけど、名前が関数ってだけで数学関数をそういうカテゴリーのものとするのは不適当でしょうね。
93:デフォルトの名無しさん
16/01/10 11:09:22.36 hXY04te0.net
クロージャーって、関数なの？オブジェクトなの？
rubyだとProcのインスタンスでしかないよね
94:デフォルトの名無しさん
16/01/10 12:33:30.21 jS8+hJYw.net
>>91
わからないなら無理に口を挟まないほうがいいよ。
95:デフォルトの名無しさん
16/01/10 13:26:28.06 Itquv6VW.net
>>92
関数が状態を持つべきかどうか考えると自ずと答えが出るのではないだろうか。
96:デフォルトの名無しさん
16/01/10 13:37:48.58 UyzGSaeg.net
sin(x)は関数の値であって関数ではないよな。 関数は∀x∈double.sin(x)のことだよな。
97:デフォルトの名無しさん
16/01/10 13:51:03.83 ainPuYsM.net
>>85
実装がどうあれ、OOPではメソッドはオブジェクトに属するものとして考えるから、
x.sin(value)の表記は不自然じゃ無いだろ。sinはオブジェクトxに属している。
98:デフォルトの名無しさん
16/01/10 14:13:06.68 Itquv6VW.net
>>97
それは不自然な考え方じゃないかな。
原点に立ち返ってみると、オブジェクト志向とはコード再利用に際して
コンポーネント化の要求から発生したもの。
現実に存在する物のように、ディスプレイ上のウィンドウに四角形を
描画しろとメッセージを送るというようなシンプルなものだ。
この場合、四角形自体がオブジェクトであることは問題が無いように感じる。
これは、四角形が状態を保持しているからかもしれない。
一方、数値に対してsinを要求するのは突拍子もないように感じる。
これは、数値を日常いたるところで使用していて、数値がメッセージを受け取る性質を
もたないと良く知ってるからではないだろうか。
あるいは計算機オブジェクトに対してsinを要求するなら不自然に感じないのかもしれない。
どうだろうか？
99:デフォルトの名無しさん
16/01/10 14:14:35.30 CDx7UjTI.net
この種のくそ議論って恣意的な答えしかないんだから、
議論するだけ無駄なんだけどねぇ。
100:デフォルトの名無しさん
16/01/10 14:15:24.10 AcnVMiQc.net
>>95
状態をもつかどうかは実装しだい。
関数を初期化するとき係数のセットを与えるとかあると思う。
関数がグループとしてまとまって環をなすとか
101:デフォルトの名無しさん
16/01/10 14:17:25.96 ainPuYsM.net
つか、sin(x)ってなんやねんw
引数無しのメソッドの話か？ それならsinは例として不適当だ。
sinを例にするなら、x.sin(value) か、sin(x, value) だろ。
102:デフォルトの名無しさん
16/01/10 14:17:26.78 AcnVMiQc.net
>>97
そりゃメソッドはオブジェクトに属するだろ。
メソッドとして位置付けるのが適切かどうかの議論をしてるんだよ。
103:デフォルトの名無しさん
16/01/10 14:17:31.05 Itquv6VW.net
こういうシンプルな考えに基づくと、四角形と三角形は形状クラスから
派生すると思われる。
しかし、四角形オブジェクトと三角形オブジェクトの合成メソッドは、形状クラスあるいは
その派生クラスにあってはならないように感じる。
それは形状合成器クラスに、あるいは単純な関数であった方が良いように感じる。
104:デフォルトの名無しさん
16/01/10 14:21:04.23 JhCLPk/2.net
>>87
物理的構造物とは違うんだよ
それすら理解できないならもう向いてないとしか
105:デフォルトの名無しさん
16/01/10 14:21:57.10 UyzGSaeg.net
属すじゃなくて依存するだと思うが。
106:デフォルトの名無しさん
16/01/10 14:25:29.45 JhCLPk/2.net
例えばゲームでキャラクターが特定のアイテムを使用するモデル
キャラ.使う(アイテム)はもらうアイテムによってメソッドの動作を変える必要があるが
設計としてはアイテム.適用(キャラ)のが遥かに取り回しやすい
なのにあえて前者のクソ設計を選ぶのが>>87のようなオバカさん
107:デフォルトの名無しさん
16/01/10 14:26:22.66 ainPuYsM.net
>>102
それならOOPの議論じゃないな。
>>105
いや、属する/所有するという概念の方が適当だと思う。（実装は違うが）
実際クラスを書くときそう書くだろ。
108:デフォルトの名無しさん
16/01/10 14:44:22.50 AcnVMiQc.net
>>101
現実の姿を模すという意味だとsinなどは連想配列であって、sin(x)という書き方はそのまんまだよね。
実装においては計算手続きだろうけど。
109:デフォルトの名無しさん
16/01/10 14:48:45.22 jS8+hJYw.net
Smalltalkerが引き上げたらもう初心者しか残ってないのかよ
110:デフォルトの名無しさん
16/01/10 15:22:03.47 yvIOv1as.net
そもそもクラスだってオブジェクト指向とは直接関係ない
>>84
嘘ではなく現実だ
111:デフォルトの名無しさん
16/01/10 15:23:27.70 yvIOv1as.net
美少女が云々言うのも一般的なクラスベースは融通が効かないねという話であって
オブジェクト指向とは直接関係ないし
112:デフォルトの名無しさん
16/01/10 15:44:15.32 KeJgEHCD.net
>>111
ほう、それならウンコをしない美少女をオブジェクト指向で設計して貰おうか
113:デフォルトの名無しさん
16/01/10 15:50:56.07 AcnVMiQc.net
>>97
見逃したいたが、x.sin(value)の value って何だい？
114:デフォルトの名無しさん
16/01/10 16:06:27.16 ainPuYsM.net
>>113
引数だよ。
クラスxのメソッドsinに渡す引数。
俺はそういう話をしてると思ったから。
115:デフォルトの名無しさん
16/01/10 16:18:07.80 hZikTLMs.net
xって中身は例えばfloatのデータ自身だぞ？
だから、引数は必要ないんだぞ？
116:デフォルトの名無しさん
16/01/10 16:26:17.41 ainPuYsM.net
>>115
理解した。
それなら、x.sin() なんて形が出てくる余地は無いよな。
117:デフォルトの名無しさん
16/01/10 16:29:21.43 CDx7UjTI.net
一般に sin に必要な引数は、 pi/2 とかの実数(もしくは複素数) かな。
あとはいくつまでの級数和をとるとか何桁まで計算するとかが引数になるんじゃないかね。
その辺をあいまいなまま value とか x がクラスだの引数だの言ってることに何か意味があると思ってんのかね。
118:デフォルトの名無しさん
16/01/10 16:34:25.26 ainPuYsM.net
>>117
いや、sinの引数がオブジェクトの場合はあるよ。
実数や10進型をクラスで表現したりするし、俺も実際やる。
xがそういうオブジェクトなら、sin(x)でいいし、x.sin()はおかしい。
まあ絶対におかしいとか無理ってわけじゃないけどなw
119:デフォルトの名無しさん
16/01/10 16:54:55.24 yIre7PYR.net
新しいC++ではsin(x)でもx.sin()でも、どちらの方法でも統一的に呼び出せるようになる予定だから
こんな議論は全く意味ないんだよ？
呼び出す側からしたら、sinがメンバ関数だろうが外部関数だろうが、何であれ、知ったことではないからね
気にしなければならないのは実装する側だけ
だからどちらの方法でも呼び出せるようになる、らしい
どちらの方法でも呼び出せるんだから、喧嘩する必要ないし、気にする必要ないよね
120:デフォルトの名無しさん
16/01/10 16:57:47.72 yIre7PYR.net
どちらの方法でも呼び出せるんだから
どちらの方が、よりオブジェクト指向的か、考えるのは意味がないんだよ
等しいわけ、等価と考えてよい
見た目が違うだけ
大した問題じゃない
121:デフォルトの名無しさん
16/01/10 17:00:24.30 ainPuYsM.net
なんか違うような気がするなw
122:デフォルトの名無しさん
16/01/10 17:07:10.06 fbwGqbCo.net
こんなにややこしいプログラムがオブジェクト指向を使って
こんなに簡潔になりましたって事例が欲しい
123:デフォルトの名無しさん
16/01/10 17:12:10.48 1042xGua.net
>>112
思うんだけど、
うんｋをしないというのが、
意思を持ってひたすら我慢して（人の目がある場所では）しないのか、
それとも腸内の美少女菌のおかげでする必要が無いのか、
もしくは他の何かなのかによってイメージが変わってくると思う。
でもしないにしろする必要がないにしろ、排便メソッド自体は備わっててもなんら問題ないと思う。
逆に、腸内やなんかの問題を解決せずに、排便メソッドだけ外して他を流用するということは、
オブジェクト指向的であろうがなかろうが不可能だと思う。
それこそ亞人として設計しなおして全ての手続やメソッドを別に用意することが妥当かもしれない。
だから結論を言うと、この例はそもそも良くないと思う。
124:デフォルトの名無しさん
16/01/10 17:51:06.88 QPFpTdMb.net
>>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:デフォルトの名無しさん
16/01/10 19:10:53.94 fbwGqbCo.net
>>124
なるほどねー。
126:デフォルトの名無しさん
16/01/10 19:16:06.37 fbwGqbCo.net
>>112
美少女はマーカーインターフェースであり、
美少女として扱うとき排便は隠蔽される。
interface 美少女 {
}
class おっさん implements 美少女 {
void 排便() {
}
}
127:デフォルトの名無しさん
16/01/10 20:20:59.69 VQDMXfno.net
>>126
それは「何もしない」という排便メソッドを持つ
持たない，ではない
128:デフォルトの名無しさん
16/01/10 20:34:00.62 fbwGqbCo.net
>>127
何を言うてんの？排便メソッドを持つのはおっさんだよ。
129:デフォルトの名無しさん
16/01/10 20:41:36.36 KeJgEHCD.net
聖水メソッドもないのに美少女とか笑わせんなよｗ
130:デフォルトの名無しさん
16/01/10 21:17:46.16 +l1yiqNW.net
オブジェクト志向の考えだと
大便ableインターフェースを実装するんだろ
131:デフォルトの名無しさん
16/01/10 21:57:06.57 Hm2sxH4v.net
美少女クラスを欲する奴が美少女のウンコがついたぱんつを欲しがらないかと考えると
これは要件定義から間違っているような気がしてならない。
132:デフォルトの名無しさん
16/01/10 22:05:43.79 zd2SpHtU.net
実装からメソッド設計を考えるより使い方から設計したほうが上手く行くと思う
つまり美少女がうんこ出来るのか、出来ないのかで考えるのでは無く美少女にうんこをさせたいのか、うんこさせたくないのかで考える
133:デフォルトの名無しさん
16/01/10 22:12:58.59 hZikTLMs.net
肛門はコンポーネントとしてアタッチする。
美少女は肛門をインプリメントしていない
134:デフォルトの名無しさん
16/01/11 02:57:08.55 87Jnvcw4.net
あのさ、どんな美少女もウンコするんだけど？
135:デフォルトの名無しさん
16/01/11 03:08:27.43 Rwcs8mHW.net
真の美少女は実在しない
136:デフォルトの名無しさん
16/01/11 03:18:02.16 4rCdY4Yq.net
>>134
URLﾘﾝｸ(youtu.be)
137:デフォルトの名無しさん
16/01/11 04:26:03.17 3eUcyomA.net
ｗ
138:デフォルトの名無しさん
16/01/11 14:41:47.97 GiqteBDS.net
関数型言語っていい点もあるけど、変更に弱過ぎない?
ちょっと動作を変えるのにかなり見直さないといけない
139:デフォルトの名無しさん
16/01/11 16:00:11.66 Rwcs8mHW.net
作りようだね
140:デフォルトの名無しさん
16/01/11 17:41:31.97 d9M93+6h.net
>>138
関数型言語を使えば完璧なプログラミングが可能なので後から変更する必要が無い。
141:デフォルトの名無しさん
16/01/11 17:50:34.21 KkwWauMD.net
>>140
完璧なプログラミングは出来ても
将来の仕様の変化を完璧に予測することは出来ないでしょ？
142:デフォルトの名無しさん
16/01/11 17:53:14.36 GiqteBDS.net
仕様変更できないって実用上ヤバくないですか
143:デフォルトの名無しさん
16/01/11 18:03:26.01 RUBsLBHi.net
オブジェクト指向は細かい修正で済むと手を抜き続けた結果メチャクチャ悲惨なことになる
全て書き直すくらいがちょうどいい
144:デフォルトの名無しさん
16/01/11 18:08:52.97 hbMmOduf.net
> メチャクチャ悲惨なこと
たとえば？
145:デフォルトの名無しさん
16/01/11 18:13:38.40 rz35E4wE.net
>>144
全て書き直すはめになる
146:デフォルトの名無しさん
16/01/11 18:18:05.61 V0AQQEoP.net
関数型言語は仕様変更のたびにめちゃくちゃ悲惨なことをしなければならないのか
147:デフォルトの名無しさん
16/01/11 18:31:28.27 KoUNfQqa.net
言語の問題でなくて作ってる奴が馬鹿なだけでは？
148:デフォルトの名無しさん
16/01/11 18:59:27.70 A5Rx7ofK.net
ただのリスト操作を関数型と呼んでいる可能性
149:デフォルトの名無しさん
16/01/11 19:14:51.77 d9M93+6h.net
>>141
関数型なら完全に未来を予測できる。
150:デフォルトの名無しさん
16/01/11 19:37:40.52 ugQF1NqL.net
そらすげーわ
151:デフォルトの名無しさん
16/01/11 19:38:18.20 rz35E4wE.net
>>149
そういうのいいから
152:デフォルトの名無しさん
16/01/11 19:43:22.94 XhrtL63c.net
関数型言語はコンパイルした瞬間全てが完了される。
153:デフォルトの名無しさん
16/01/11 19:46:13.85 d9M93+6h.net
コンパイルが通ればバグが無いことを保証される。
154:デフォルトの名無しさん
16/01/11 19:47:17.32 rz35E4wE.net
>>153
それもいいから
155:デフォルトの名無しさん
16/01/11 19:49:39.36 d9M93+6h.net
>>154
お前関数型馬鹿にしてんの？
156:デフォルトの名無しさん
16/01/11 19:53:45.95 XhrtL63c.net
関数型言語にとって型とはプログラムの設計図なのである。
157:デフォルトの名無しさん
16/01/11 19:55:09.91 rz35E4wE.net
>>155
関数型じゃなくてお前を馬鹿にしてるんだよｗ
158:デフォルトの名無しさん
16/01/11 19:55:15.79 eiYfk44d.net
1000近くなった雰囲気だな
159:デフォルトの名無しさん
16/01/11 20:02:18.58 d9M93+6h.net
ヨハネの手紙にも関数型が登場する。
160:デフォルトの名無しさん
16/01/11 20:05:53.42 eiYfk44d.net
鶏が鳴く前に三度、関数型など知らないと言う
161:デフォルトの名無しさん
16/01/11 20:09:36.09 d9M93+6h.net
マタイの福音書、関数型が世界を平和に導く。
162:デフォルトの名無しさん
16/01/11 20:40:32.13 d9M93+6h.net
>>157
ああそう、なら良いんだ。
関数型馬鹿にしたら唐沢弁護士に頼んで勝訴しちゃうからね？
163:デフォルトの名無しさん
16/01/11 22:15:27.49 qSBpiVnS.net
関数型に不可能はない。関数型は神にのみ扱える至高の言語
関数型を疑ってはならない。汝の実力を疑え
164:デフォルトの名無しさん
16/01/11 22:48:28.28 CMbhymom.net
毛の壁の臭いがするな。
165:デフォルトの名無しさん
16/01/12 01:32:19.38 SYPJaqWI.net
広く使われてて実用的な言語は多かれ少なかれマルチパラダイム
関数型っていうのも結局は作者がそう言ってるかどうかの線引でしか無い
理想的な関数型gwンゴを想定してなにか言うのはあまり意味が無い
166:デフォルトの名無しさん
16/01/12 01:34:43.86 uMvEa0J7.net
関数型ンゴwwwwwwwwwwwwwwwwwwwwwwwwwww
167:デフォルトの名無しさん
16/01/12 08:42:46.08 V5bMIqIZ.net
関数型グワンゴ
168:デフォルトの名無しさん
16/01/12 09:12:48.84 /ZqCERvo.net
今時は大学とかでも言語比較とか講義しているのかな。
169:デフォルトの名無しさん
16/01/12 19:38:37.49 7kdSKUGZ.net
lisp は関数型ですか？
170:デフォルトの名無しさん
16/01/12 22:56:29.42 uMvEa0J7.net
いいえ、変態型です
171:デフォルトの名無しさん
16/01/14 06:56:24.28 /XPEQoow.net
URLﾘﾝｸ(pc.rooter.link)
172:デフォルトの名無しさん
16/01/16 23:50:44.88 vrXiOUCa.net
美少女は天使クラスに属している。
排便しない。
173:デフォルトの名無しさん
16/01/20 11:46:14.76 HskUHurd.net
「オブジェクト指向プログラミングの例を挙げましょう。2000年代には、オブジェクト指向プログラミングは、企業向けプログラミングにおける基盤的技術の地位を確立したと思われていました。
しかし今では、私を含めて多くの人が、この潮流は20年間に渡って本流から逸れていたものであり、そのほとんどが間違いだったと考えています。」
コーディングを学ぶこと、それはあなたが考えるよりも大変です
URLﾘﾝｸ(postd.cc)
174:デフォルトの名無しさん
16/01/20 12:33:48.74 CF7z5V/R.net
>>173
記事のベースはイギリスのプログラマ教育のあり方と社会地位の話で
"大学で教えていることが現場で役に立たない"ことと
"高級技術者としてのプログラマの社会的地位の低さ"について
そして、前者関連の話で「教えるべき技術は次々と移り変わる」例として
オブジェクト指向を挙げてみてるが、筆者があまり理解してる感じではないなぁ…
20年前なら単語そのまま「構造化プログラミング」に置き換えて書かれた
単なる流行りワードの扱いだわな。
175:デフォルトの名無しさん
16/01/20 12:39:59.33 CF7z5V/R.net
また、書かれている内容のとおりイギリスのプログラミング技術のほとんどが
学校教育ではなく「独学」で学ばねばならないもので、その上でガチで
『しかし今では、私を含めて多くの人が、この潮流は20年間に渡って
本流から逸れていたものであり、そのほとんどが間違いだったと考えています。』
と、思ってるとしたら本当にイギリスのプログラミング業界界隈の危機は
深刻なものだと考えざるをえない…
176:デフォルトの名無しさん
16/01/20 12:41:46.50 uqyd4S+p.net
日本も似たようなもんじゃないの？ 違うの？
177:デフォルトの名無しさん
16/01/20 12:58:06.53 CF7z5V/R.net
>>176
>>173のリンクを読んだ感じではイギリスではどうも国を挙げて
学校や社会人教育で「無償で国民にプログラミングを学ばせる」事業をやってたっぽい
で、たぶん日本でやってもそうなるだろうけれど
みんな合格するようなレベルの簡単な内容なので
わざわざ教える意味がない的な事態になったっぽい？
大学の情報学科だったら日本でもまぁ直でコーディングの役には立たんが
逆に大学レベルの情報工学理論面を広く教えるから
オブジェクト指向なんて～って池沼はでないだろう(皮肉
178:デフォルトの名無しさん
16/01/20 21:59:54.59 ftWUH7Q0.net
オブジェクト指向は思考パターンを破壊されるよ
179:デフォルトの名無しさん
16/01/20 22:38:38.89 KK1TC/Qj.net
コードの奇麗さはなになに指向とかとはいつだって無相関だよ。
180:デフォルトの名無しさん
16/01/20 23:28:45.86 lyH/JRhU.net
>>179
その評価はとても健全
181:デフォルトの名無しさん
16/01/21 12:15:51.15 pkb4zgJk.net
>>179
「奇麗」なコードってどんなの？
182:デフォルトの名無しさん
16/01/21 16:38:21.88 OmENn3Ct.net
>>181
測定するツールがある。
183:デフォルトの名無しさん
16/01/22 08:41:08.27 jWLszG8x.net
それはツールに設定したルールを守ってるかの判別器でしか無いな。
本当に一般的に綺麗なコードとやらを図るには、
統計を集めて機械学習でもさせる必要があるだろう。
もしくは綺麗というのが、編集しやすいということなら
最低きちんとした理論と根拠を元に基準を決めるべき。
今の基準の多くはただ作者の信念だったり、狭い範囲での多数はを取っているだけ。
184:デフォルトの名無しさん
16/01/22 10:24:46.06 BOI0ua8w.net
>>183
コードコンプリートでもよんだら？
185:デフォルトの名無しさん
16/01/22 12:53:49.39 NE1Xg/XG.net
コードとは言語だから、綺麗な英語と置き換えてみればわかる。 学校で教えられるのは全部綺麗な英語だから実際の外人の喋ってることなんか一つも役に立たない。 汚いコードを書いてどんな汚いコードも読めるようになるのが大切。
186:デフォルトの名無しさん
16/01/22 13:21:50.19 p0qaIBjS.net
実際に効果があるかそっちのけで、主観的な綺麗さばっかり気にしてルールを
固定化しようとするやつなんなの？
どことなく自閉症的で気味が悪い。
187:デフォルトの名無しさん
16/01/22 13:23:33.14 p0qaIBjS.net
あ、このスレの発言のことじゃないです。リアルの話。
188:デフォルトの名無しさん
16/01/22 14:33:54.36 IejezU7v.net
コードコンプリートを書いたのはマイクロソフト()だぞ
林檎がビューティパーフェクトコードを書くまで待て
189:デフォルトの名無しさん
16/01/22 22:02:12.46 SlI41mNc.net
>>185
こういう人が職場にいたらきついお
190:デフォルトの名無しさん
16/01/22 22:17:23.23 jXHHn5ty.net
>>186
ルールなんて誰でもわかってると思うけどな。
・重複する処理はかかない。
・同じことに関する値を重複して定義しない。
・計算で求められるものは計算でだす。
・ある処理に関するコードは一箇所にまとめる。
・条件分岐を減らす。
・ループを減らす。
・設計とファイル名やディレクトリ構造を一致させる。
・役割毎に関数やクラスを分ける
・関数やクラスはなるべく短くする
・テストしにくい所を減らす
・適切な名前（グローバルに近いほど長く、ローカルに近いほど簡単な名前）をつける。
・十分にテストされた信頼性が高いライブラリを使用する。独自実装しない。
・コーディングスタイルに適合すること
・メトリクス（複雑度等）が悪いものは認めない
これらは主観じゃないので、このルールにしたがえば、
誰でも良い方がどちらかわかる。
191:デフォルトの名無しさん
16/01/22 23:23:12.65 p0qaIBjS.net
>>190
それらは効果があるとわかるものだから問題ないよ。
192:デフォルトの名無しさん
16/01/23 03:52:18.65 qPctTKOa.net
Smalltalker達がいなくなったら途端に初心者スレ化w
193:デフォルトの名無しさん
16/01/23 14:01:47.22 xYcOlVg1.net
Smalltalkの人はボコボコにされて
Smalltalkに自信を失って帰っちゃったからな
実際全然使われていない現実なわけだから
何を言っても説得力皆無だし机上の空論になるし
こいつマゾと思って皆で玩具にしたが
言うほどマゾじゃなかったのかもね
194:デフォルトの名無しさん
16/01/23 19:33:03.55 qHL6kF89.net
7 minutes of Pharo Smalltalk for Rubyists
URLﾘﾝｸ(www.youtube.com)
Pharo - Welcome to Pharo!
URLﾘﾝｸ(pharo.org)
195:デフォルトの名無しさん
16/01/23 19:36:10.46 qHL6kF89.net
URLﾘﾝｸ(github.com)
196:デフォルトの名無しさん
16/01/23 22:09:12.03 Sj7C6OsA.net
URLﾘﾝｸ(blogs.c.yimg.jp)
197:デフォルトの名無しさん
16/01/30 19:31:26.50 ZdxrrRsd.net
>>185
どんな汚いコードも読めることは大切だが
汚いコードは書くなよ…
まあその汚さをある程度許されるようになるオブジェクト指向は嫌いじゃない
198:デフォルトの名無しさん
16/02/02 15:15:07.68 Kj5oXuy8.net
>>197
いや、それでも人間クラスに
排便メソッドは必要だ。
199:デフォルトの名無しさん
16/02/02 21:15:38.34 7zvF4Jbc.net
刈羽 かりわ ＪＲ越後線
200:デフォルトの名無しさん
16/02/03 00:10:39.67 JLgoV6RT.net
>>198
そんな汚いコード書くと人間クラスを継承した美少女クラスで不都合が生じる
201:デフォルトの名無しさん
16/02/03 08:41:03.18 LaxmbkTJ.net
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...
202:デフォルトの名無しさん
16/02/03 08:41:21.38 LaxmbkTJ.net
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...
203:デフォルトの名無しさん
16/02/03 08:41:50.93 LaxmbkTJ.net
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...
204:デフォルトの名無しさん
16/02/03 08:42:43.86 v0iZc+aq.net
2回連投はよくみるけど3回は珍しいw
205:デフォルトの名無しさん
16/02/03 08:57:53.06 ffzzO4R/.net
あのさ…… どんな美少女もウンコするんだけど？
206:デフォルトの名無しさん
16/02/03 12:29:23.04 8IxY+gWE.net
人間クラスを継承せずに、
必要に応じて肛門を持たせればいいのでは？
この問題は、設計を誤ると修整が容易ではないと言ってるの？
論点は何？
207:デフォルトの名無しさん
16/02/03 23:54:09.81 NwkI7iYf.net
インスタンス化もせずにスレたてとな？
208:デフォルトの名無しさん
16/02/04 01:07:49.04 K1JlKV3Z.net
>>206
メンバーの種類を制限したり、メンバー間に何らかの制約を入れたクラスが欲しいときの
ベストプラクティスはっていう話かい？
言語によるけれど c++ のテンプレート使った方法が「Modern C++ Design」に書いてあった気はする。
有用かどうかは知らん。
209:デフォルトの名無しさん
16/02/04 21:35:19.21 RsO5DH3N.net
天使クラスを継承するともれなくおちんちんがついてくるぞ
210:デフォルトの名無しさん
16/02/04 23:19:55.12 NzupaiZw.net
滑ったな
どうすんのこれ
教えてよ
今すぐあんたが教えてよ
211:デフォルトの名無しさん
16/02/04 23:57:46.75 +xOonDYt.net
この板にいたなら知ってる人も多いだろうけど
このスレタイで建てる前に延々「オブジェクト指向は～」ってスレ建てては
毎回、議論についてけなくなると「美少女クラスはうんこしない」みたいなこと書いて
荒らし逃げしてんだよこいつは。
んで、またそれ始めたから知ってる人々がサーッと逃げた。
212:デフォルトの名無しさん
16/02/05 01:20:03.95 tLv00hAm.net
そんな糞みたいな議論に持ってがれる時点でオブジェクト指向って切り口は何か問題があるんだろう。
もう少しバズワードと距離とれるスタンスが必要だったんじゃないのかね。
213:デフォルトの名無しさん
16/02/05 10:03:42.67 BBqIJr5G.net
継承とオブジェクト指向は直行してるんだけれどね
214:デフォルトの名無しさん
16/02/05 11:35:17.23 oOuE6OCl.net
美少女の件は、キモオタクラスからは美少女の排便参照不可にすれば解決。
また、キモオタクラスからは他のどの処理を呼んだ場合にもキモ例外が発生することにすれば万全。
215:デフォルトの名無しさん
16/02/05 18:19:15.34 PpryQyj4.net
>>212
美少女クラスはうんこしない(議論)
216:デフォルトの名無しさん
16/02/05 18:21:10.60 iF+JFr5E.net
排便量を0に設定すればいいだけだろ
217:デフォルトの名無しさん
16/02/05 19:07:26.01 PpryQyj4.net
排便量を(オブジェクト指向について僕ができる最大の議論)
218:デフォルトの名無しさん
16/02/06 18:12:26.16 T0MFScki.net
>>216
排便メソッドの引数にいちいち排便量足すのかよ…
219:デフォルトの名無しさん
16/02/06 22:09:32.02 64Pydz+a.net
排便量は流石にインスタンス変数で管理するだろ
トイレに行って半分だけ出すとかいうマニアックな機能をつけたいならともかく
220:デフォルトの名無しさん
16/02/07 00:09:19.21 smcac5RE.net
get_unko を仮想関数にして美少女クラスは 0 を返すようにすればよい。
221:デフォルトの名無しさん
16/02/07 01:39:26.20 R4NvrNxp.net
便秘のババアもget_unko()が0を返す件
222:デフォルトの名無しさん
16/02/07 11:30:22.21 smcac5RE.net
では君は美少女に何を返して欲しいのかね？
223:デフォルトの名無しさん
16/02/07 12:40:45.65 Dv+rVFbe.net
ワンチャン便秘のババアクラスを継承しても美少女クラスは成り立つのではないだろうか
224:デフォルトの名無しさん
16/02/07 13:03:58.71 R4NvrNxp.net
コーラックが欠かせない美少女ｗ
225:デフォルトの名無しさん
16/02/07 13:35:31.74 fu54F6yL.net
美少女は便秘じゃない‥
226:デフォルトの名無しさん
16/02/07 15:37:37.70 TdnGwusc.net
日本の現場は永続化層が糞すぎてオブジェクトにマッピング出来ない
これじゃまともにOOPは出来ないから関数型でやらざるをえないんだね
別に関数型がOOPより優れてるという事ではなかったんだね
227:デフォルトの名無しさん
16/02/07 16:37:33.38 q/UCYgzT.net
>>226
Do you 意味?
228:デフォルトの名無しさん
16/02/07 17:52:18.95 TdnGwusc.net
>>227
OOPが愚かなのではなくDB設計者が愚かだったという事
229:デフォルトの名無しさん
16/02/07 18:21:09.45 smcac5RE.net
永続化層が糞でも関数型なら上手く行くならOOPより優れてるってことになるんでは？
230:デフォルトの名無しさん
16/02/07 18:38:59.78 AJ8T19vA.net
RDBにオブジェクトをそのまま永続化できないように、
RDBに関数を値として永続化できないんなら同じじゃん
231:デフォルトの名無しさん
16/02/07 19:08:05.31 v13MCL4I.net
永続化層に日本と海外で差があると？
232:デフォルトの名無しさん
16/02/07 19:24:56.69 TdnGwusc.net
>>229
うまくいくからやるというかそうせざるをえないからやる
そして一見うまくいっているように見えるが保守性も拡張性も悪い
製造が進むほど歪みが大きくなり破綻に近付く
OOPなら最後まで破綻しないが永続化層はOOPに譲歩して合わせなければならない
しかし日本ではDB中心のアプローチしか出来ない老害が支配的だからそれが出来ない
OOPが優れているのに足を引っ張る老害のせいでOOPはダメだという風評被害を受けている
233:デフォルトの名無しさん
16/02/07 19:35:10.05 R4NvrNxp.net
>>231
便秘が永続化するババアがいるのは日本だけだぞ？知らんかったんか？
234:デフォルトの名無しさん
16/02/12 08:39:25.91 NbTuOgvl.net
このスレもついに終わりか
235:デフォルトの名無しさん
16/02/12 11:27:46.75 3qOWj7pc.net
ウンコしない美少女のせい。
236:デフォルトの名無しさん
16/02/16 21:31:50.31 utvP1D7N.net
Mutableなオブジェクトは糞
237:デフォルトの名無しさん
16/02/16 21:34:55.97 utvP1D7N.net
DBには関係代数という理論的バックボーンが存在するからやり方の是非に真偽をつけられるが
Mutableなオブジェクトを許容するオブジェクト指向にはそれが無い
何でもできるかわりに何でもアリすぐる
238:デフォルトの名無しさん
16/02/17 01:36:09.44 quKaVBpr.net
>>237
日本語
239:デフォルトの名無しさん
16/02/17 02:04:23.05 zhj6/FLZ.net
美少女のこと語ろうよ。
240:デフォルトの名無しさん
16/02/17 07:33:48.75 UG2kvZqb.net
>>237は日本語としての意味はとらえやすいが
241:デフォルトの名無しさん
16/02/17 08:52:29.51 zhj6/FLZ.net
mutable なオブジェクトは糞。
美少女はウンコをしない。
オブジェクトの値が破壊的に変更出来てしまっては、
並列的な処理に容易に分割できないから、
マズイだろってな的話じゃないか？
242:デフォルトの名無しさん
16/02/17 20:12:53.87 sobQnjjW.net
例えばC++の入門書で必ずと言って良いほど載ってる複素数クラスComplexだけども、
たいてい代入演算詩（かコピーコンストラクタ）とか定義していやがる
藻前はa+2iに3+4iが代入されるのを見たことがあるのかっていうか、
Complexはもはや複素数ではない何か別の異形のものを表してしまっているのではないか、
243:デフォルトの名無しさん
16/02/17 20:14:41.29 sobQnjjW.net
ｽﾏﾝorz;
誤1：詩
正1：子
誤2: a+2i
正2: 1+2i
244:デフォルトの名無しさん
16/02/17 21:34:07.52 ZZNKbDIQ.net
1+2i + 3+4i = 4+6i
意外と便利かもしれないww
245:デフォルトの名無しさん
16/02/17 22:13:27.16 BpXyDkaJ.net
>>242
右辺値に対するoperator = をdeleteすればいいんでしょ？
246:デフォルトの名無しさん
16/02/17 22:14:08.77 xErgmETY.net
関数型とかいう産廃はイベントがないから使い物にならない
最近の大規模システムはみんなイベントがないと始まらない
247:デフォルトの名無しさん
16/02/18 12:36:55.18 9ZrwZ5jU.net
破壊的うんこが何だって？
248:デフォルトの名無しさん
16/02/18 15:25:24.63 eyX5WM+u.net
破壊的激臭は副作用を伴います。
249:デフォルトの名無しさん
16/02/19 14:34:33.73 hr949zjY.net
ちょっとだけ期待してスレひらいてみたら美少女のうんこ
λ計算すらないのかよ
250:デフォルトの名無しさん
16/02/19 23:39:47.24 Tb8XgjPy.net
良スレ、age！
251:デフォルトの名無しさん
16/02/20 12:33:38.85 njY71FFO.net
「美少女はうんこしない」という話を「美少女のうんこ」の話だと理解してしまうようなおっちょこちょいが
オブジェクト指向を理解出来るわけがない
252:デフォルトの名無しさん
16/02/21 00:15:17.53 Xn8BbX8n.net
unko.suru( bisyoujo );
253:デフォルトの名無しさん
16/02/21 13:27:24.70 82b/sWYC.net
うんこが美少女にナニをするのか
254:デフォルトの名無しさん
16/03/10 04:27:45.65 +d/NDXY7.net
依存型とか見てみると結局行き着く先は同じなんだなと思うけどどうよ
255:デフォルトの名無しさん
16/03/11 08:07:36.54 eLvrEEzR.net
どうしてハスケラってみんなキモいアニオタなの？
256:デフォルトの名無しさん
16/03/11 11:26:20.85 Kt9+s/wp.net
美少女はウンコするのかしないのか。
それでみんな行き詰まる。
257:デフォルトの名無しさん
16/03/27 21:21:44.90 N7IGtcj3.net
うんこをした時点で美少女ではない
しかし、うんこを我慢している美少女は萌えるのだ
258:デフォルトの名無しさん
16/03/27 23:58:39.00 9N4B8hjZ.net
うんこをしないのにうんこを我慢するわけないだろ
絶対にしないから美少女のうんこには底知れぬ価値があるのだ
259:デフォルトの名無しさん
16/03/28 00:59:02.52 oM2XJFW1.net
スコープだったり変数の生存期間を気にしたりってのは関数型だろうとオブジェクト指向だろうと
同じように気にする。
要はまとめ方ってだけの話。
260:デフォルトの名無しさん
16/03/28 02:53:49.59 T6p957gW.net
「野球もサッカーも球技だからおなじようなもの！」いただきましたw
261:デフォルトの名無しさん
16/03/28 04:13:13.96 soILvqz+.net
オブジェクト指向は役に立っている。
関数型言語はトイプログラムしか作れない。
262:デフォルトの名無しさん
16/03/28 10:46:29.30 U1rG/r8A.net
うんこの話題についてこれない人達が必死ですねｗ
263:デフォルトの名無しさん
16/03/28 10:53:32.07 Et7Dc3iM.net
うん、この話についてこれないよ
264:デフォルトの名無しさん
16/03/28 12:55:38.08 IcMNxByb.net
僕みたいな芸人とか人前に出る人は、多かれ少なかれちょっとした発言や態度がネットで炎上したり、
罵詈雑言を浴びせられたりします。けれど、僕はそんなのにまったく腹も立たないし、
むしろオブジェクト指向を“カチャカチャ”してる人のほうが可哀想やなあ、と思うんです。
エラい人たちは、オブジェクト指向で時間を使うことはないでしょう。
だから僕は子どもにも「金持ちやエラい人のマネせえ、幸せな人のマネをせえよ」と言うようにしています。
はい、ここで問題です。オブジェクト指向でカチャカチャしてる人とそうでない人、どっちが幸せですか？
そんなの100%、カチャカチャじゃないほうですよ。カチャカチャばっかしてたら不幸になることは、みんなわかってる。
「あの人幸せそう、エエ人やわ」と評判の20人のおばはんをモニタリングしてみてください。
ちゃんと挨拶して、言葉遣いも優しくて、お店でもエラそうな態度をとらない、とか共通項があるはずです。
逆に「あの人意地悪いわ、不幸やわ」と言われてる20人のおばはんを見ると、絶対カチャカチャみたいな行動をしてるはずです。
オブジェクト指向をカチャカチャして、クラスのインスタントを参照して「やったった感」を持ってるのかも
しれんけど、それでハッピーエンドの人生が待ってると思いますか？ それよりも、もっとお友だちと
おしゃべりするとか、勉強するとか自分が幸せになる方法を考えるのがいいんじゃないですか。
オブジェクト指向をカチャカチャするのは、自分から不幸になりに行ってるようなものですよ。
あまりに生産性がなさすぎる。それを考えると可哀想やなと思えてくるんです。
僕は「日本は沈没しかけとる。こりゃどエラい時代が来るぞ……」とゾッとしたもんですが、
今まさにそれが当たり前のどエラい時代になりましたね。
265:デフォルトの名無しさん
16/03/28 15:14:15.80 qcCtZJbO.net
関数型は「このわかりにくい書き方をすればある問題が絶対発生しない！」だからなぁ…
いや、わかりにくいって時点でダメじゃんっつか。
266:デフォルトの名無しさん
16/03/28 17:25:44.03 soILvqz+.net
>>265
問題が絶対に発生しないなんてあるわけねえだろ
Haskellだってランタイムエラー出るときは出るわ
267:デフォルトの名無しさん
16/03/29 08:53:21.35 69Hzy87b.net
○○は学習コストがーとかわかりにくいってよく聞くけど、仕事でやってる人なら誰でもすぐわかるような（もしくはわかったつもりになれるような）技術だけ使い続けるより安心じゃね？ 覚える価値があるなら特に。
268:デフォルトの名無しさん
16/03/29 12:04:28.51 4NQ/4meq.net
誰でもわかる
↓
コストがかからない
↓
人気がある
↓
衰退しない
269:デフォルトの名無しさん
16/03/29 12:45:16.60 mGK48Xag.net
誰でもわかる
↓
バカが混入する
↓
コードが荒れてプロジェクトが燃える
↓
マトモな技術者が新しい言語に逃げ出す
今、関数型言語界隈がstep 2のど真ん中w
270:デフォルトの名無しさん
16/05/01 09:43:39.37 tKi6j9CT.net
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
URLﾘﾝｸ(twitter.com)
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
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フォルトの名末ｳしさん
16/05/11 13:16:12.60 Knti35lY.net
オブジェクト指向って別に世の中の色んな事を記述するためのものじゃないよねw
pcの制御を記述するためのものじゃん
たぶん世の中 = pcって偏狭な人間が混乱してるだけなんじゃない？
272:デフォルトの名無しさん
16/05/11 14:16:15.77 1ZZ8JGEs.net
手続き型の一部に関数型っぽい書き方するのがカコイイという風潮が強くなってきて
熱心な子が意気込んで本格的なものに手を出してみるがわけわからなくて
酷い目に遭って帰ってきました、という感じじゃない？
273:デフォルトの名無しさん
16/05/11 15:35:01.38 l/Aku55r.net
誰でもわかる
↓
コストがかからない
↓
人を集めやすい一方、単価が下がる
↓
人気が減る
274:デフォルトの名無しさん
16/05/11 16:50:49.33 Knti35lY.net
関数型言語って狭義のプログラミング言語じゃない気がするよ
アルゴリズムをシステマティックに表現するスクリプトに近い
コンピュータが手続きの連鎖で動いている以上、普通は関数を中心に記述するのはオーバーヘッドが大きすぎる
アルゴリズムが最適化される事で最終的な手続きが減るほど複雑なロジックを組む人が使えばいいと思う
275:デフォルトの名無しさん
16/05/11 17:31:14.42 DbNWRsPF.net
言語はJavaでもC#でも良いけど、凡人はデータとロジックは分けて扱う方が良いと思う
デザインパターンも、多少スキルのある人に任せて、自分では手を出すべきではない
アホが好き勝手に弄った挙げ句トンズラこいた、巨大でインスタンス変数やstatic変数を弄りまくる分岐とループにまみれたクラスの継承元と継承先を飛び回るのは、とてもツラい
何をもって安心すれば良いのかわからない
仕事戻りたくない
276:デフォルトの名無しさん
16/05/11 19:14:51.96 1ZZ8JGEs.net
名前空間で分けられるOOの方が構造化プログラミングより安全だ
バカを隔離するためにクラスを作ると昔の人は言った
277:デフォルトの名無しさん
16/05/11 19:20:32.44 4+flospS.net
おお、そのとおりだよw
末端のクラスは融通の効かないバカに作る。
そうすると見通しがいい。
278:デフォルトの名無しさん
16/05/11 19:55:02.71 AR7pBoGw.net
「言われたことをちゃんとこなすように」が正解。
途中途中で権限委譲しておかないと
上流がすべての決定をしなきゃいけなくなるので破綻する。
279:デフォルトの名無しさん
16/05/11 19:56:37.14 PuRMzRqm.net
バカは2chに集めて隠蔽
280:デフォルトの名無しさん
16/05/21 10:17:37.52 ikuIjUYo.net
>>276
藻前の悩みは名前空間の汚染しかないのｶﾖ…
クラスにして良いのはふるまいに状態を持たせる覚悟のある奴だけ
281:デフォルトの名無しさん
16/05/21 10:19:56.73 ikuIjUYo.net
もしくはクロージャとかfunctorを作りたいときとかだが
C++で作るクロージャとかfunctorは
クロージャとかfunctorですよみたいな顔して状態を隠し持ちかねないところが恐ろしい…
282:デフォルトの名無しさん
16/05/23 09:30:38.46 KJgou+2q.net
c++のクロージャってレキシカルスコープ以外の状態を持つのか？
後 functorもクロージャって全然違わない？
283:デフォルトの名無しさん
16/05/23 13:11:00.57 WJyvxaEH.net
Objectから派生したものは、メンバ変数とメソッド、つまり状態と処理を持つ
クラス・ラムダ・クロージャ・無名関数・Functor・ブロック・Proc、
どういう名前を付けようと、First Class(第1級)オブジェクトである
第1級オブジェクトとはオブジェクトなので、newできて、
簡単に持ち運びできるし、カプセル化してアクセス制御もできる
関数の引数として渡せて、戻り値にもできる
284:デフォルトの名無しさん
16/05/23 20:08:36.17 amMcSQyA.net
>>283
なにその中学生がぐぐりながら書いたような文章
285:デフォルトの名無しさん
16/05/24 22:30:45.96 uzPl1U54.net
ポケモンってオブジェクト指向が出て来たら
これで効率よくやってそうだよな
286:デフォルトの名無しさん
16/05/24 22:33:07.23 CFKzRNjb.net
モンスターは物じゃない
物じゃないんだ、友達なんだ
287:デフォルトの名無しさん
16/05/24 22:40:40.32 TKpsNxtt.net
ゲームはオブジェクト指向が適しているだろうが、
それでもやっぱり思考ロジック部分はオブジェクト指向じゃないさ。
ロジックを固めるフレームワークに設計は適している。
288:デフォルトの名無しさん
16/05/24 23:09:50.90 2+VBUZih.net
>>287
なにその小学生がヤフりながら書いたような文章
289:デフォルトの名無しさん
16/05/24 23:11:07.38 TKpsNxtt.net
>>288
こっちへおいでｗ
オブジェクト指向システムの設計 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(tech板)
290:デフォルトの名無しさん
16/05/24 23:33:41.15 2+VBUZih.net
100レス位まで読んだけどクッソどうでもいい事をぎゃーぎゃー言い合ってるだけやんけ
291:デフォルトの名無しさん
16/05/25 23:21:16.29 fBBvLnfI.net
>>287
はっきり言ってゲームにオブジェクト指向なんて適してない
すべてのオブジェクトをエクセルの縦の列に並べて
すべてのパラメータを横の列にすべて書き出す
こういう感じでチェックできるプログラムにしないと完成しない
292:デフォルトの名無しさん
16/05/26 13:53:37.27 gY5ZvMkJ.net
オブジェクト指向なんて意味ないよな
スーパーマリオもテトリスもプレイに必要なのはエクセル
293:デフォルトの名無しさん
16/05/26 20:55:10.22 cAjDmLh7.net
ネタとしても面白くないなぁｗ
オブジェクト指向が使われてるのを
目の前にして適していないと言われてもねｗ
294:デフォルトの名無しさん
16/05/26 22:03:14.61 cgICe8ci.net
ここからオブジェクト指向を見た事がない人だけがオブジェクト指向を批判出来るスレになります
295:デフォルトの名無しさん
16/05/26 23:27:22.03 NlrO/xzC.net
オブジェクト指向は重複したメソッドが発生する。こういうのは無駄。
coffee.owner=human
coffee.drink()
human.drink(coffee)
296:デフォルトの名無しさん
16/05/27 00:14:26.80 miERtZSj.net
>coffee.owner=human
>coffee.drink()
いやいやいや
297:デフォルトの名無しさん
16/05/27 04:22:09.83 WrCIRuds.net
オブジェクト指向
「白痴の面倒までみれねーよww」
298:デフォルトの名無しさん
16/05/27 10:57:13.85 q3bsRKFz.net
オブジェクト指向が面倒を見なくても
白痴はオブジェクトらしきものをプロジェクトに残してくんだ･･･
299:デフォルトの名無しさん
16/05/27 11:13:57.69 y0JFsOhL.net
すべては名前
きちんとした､名前
名前､名前､名前
名前思考でお願いします
機能と名前が違うのがありすぎ
国語力の欠如した人のプログラムでは
反対語で書く奴もいるし
動詞を､名詞で隠す奴
300:デフォルトの名無しさん
16/05/27 12:19:19.41 bYLZABmN.net
正しくオブジェクト指向を使ったMacOSXは16年間で11回メジャーアップデートし
オブジェクト差し替えでiOSに派生しiPhoneやiPad、果てはAppleTVにも使われ
一方、間違ったオブジェクト指向を使ってしまったWindowsは
15年間で5回しかアップデートできない上に不具合オンパレードで阿鼻叫喚
ユーザが一つ前のバージョンしか信用しないので常に5年前のバージョンが大半
そして強硬策「いま入れますか、あとにしますか？」地獄へ。
後者をオブジェクト指向だと思ってる奴はそりゃ全力で否定せざる負えないわな。
301:デフォルトの名無しさん
16/05/27 12:22:01.29 IqC0GNPs.net
ここオブジェクト指向スレやで
国語力ないんかな
302:デフォルトの名無しさん
16/05/27 12:23:05.27 DRPbKmeh.net
iOSとかMacのメジャーアップデートって完全に人柱じゃないですかヤダー
303:デフォルトの名無しさん
16/05/27 12:53:43.63 sJ1qkk5q.net
最近推し激しいが今のiOSっていいのか？
まぁiOS使うくらいならLinux使うけどw
304:デフォルトの名無しさん
16/05/28 21:36:07.37 COiCoXN6.net
どうなんだろうか。
「お前のは本当のオブジェクト指向じゃない」だとか不毛な論争の火種にしか
なってない気はする。
もうちょっとコードベースのモジュール化やコードの隔離方法なんかを議論した方がよっぽど建設的。
305:デフォルトの名無しさん
16/05/29 05:26:16.06 uH1/jPAH.net
>>300
> 一方、間違ったオブジェクト指向を使ってしまったWindowsは
最近2週間で一回ぐらいのペースで、開発者版リリースが行われてる。
これはMSアカウントを作るだけで一般の人が入手できる。
これって正しくオブジェクト指向を使ったからだろうね。
306:デフォルトの名無しさん
16/05/29 08:08:38.53 1ogDAOAr.net
何とも言えんね
ぶっちゃけいまのmsのアップデートはデバッグをユーザに押し付けてるようにしか見えんし
よくわからない用語で煙に巻くって点がオブジェクト指向だね
307:デフォルトの名無しさん
16/05/29 12:54:56.46 uH1/jPAH.net
オブジェクト指向だから早くリリースしてるんでしょ？ｗ
308:デフォルトの名無しさん
16/05/29 13:01:06.42 1rU4/WXO.net
既存のクラスはなるべくいじらずそのまま静かに置いておく
オブジェ思考
309:デフォルトの名無しさん
16/05/29 13:23:11.98 1ogDAOAr.net
私のオブジェクト指向は54万です
310:デフォルトの名無しさん
16/05/29 14:34:58.16 aa6iTjg/.net
"クラスとは構造体に操作する関数がついたもの"と
"クラスはメッセージコマンドを受けて動く"の違い。
前者はプログラマが陥りがちなタイプ数が少ない暗号みたいなパーツの組み合わせと
責任の所在がわからない動作をぜひ作り込んでくれと言わんばかりのジャンクで
まさにそのとおりのジャンクができた。
311:デフォルトの名無しさん
16/05/29 14:40:26.75 EevS3JTU.net
>>310
クラスと（そのインスタンスとしての）オブジェクトとの区別がつかない人間は永久にROMってろ
312:デフォルトの名無しさん
16/05/29 15:26:41.75 aa6iTjg/.net
きみが棲んでるジャンク界隈がそういう仕様なのは知ってるけど
こっちはクラスにメッセージ送るとクラスがインスタンス作るんだ。
うん。
313:デフォルトの名無しさん
16/05/29 15:50:36.54 abg0RIhz.net
>>312
クラスと（そのインスタンスとしての）オブジェクトとの区別がつかない人間は永久にROMってろ
314:デフォルトの名無しさん
16/05/29 16:59:56.20 aa6iTjg/.net
高度すぎたか。
315:デフォルトの名無しさん
16/05/29 17:04:53.73 9gAtgMOC.net
いちいち()で囲まなくてもよくない？
無駄な仕事多くしてそう。(どうでもいいけど)
316:デフォルトの名無しさん
16/05/29 21:48:27.53 T+KHRUkH.net
クラス厨は害悪
317:デフォルトの名無しさん
16/07/08 22:17:20.19 gy2KRr8C.net
高度すぎたかｗｗｗｗｗｗうけるｗｗｗ
318:デフォルトの名無しさん
16/07/08 22:29:11.47 zZ/OP7I+.net
半年ORMれ
319:デフォルトの名無しさん
16/07/09 11:06:02.42 lXMMLrdi.net
オブジェクト指向とかクラスが分からないのは多分メモリ周りのことが全然わからないからなんだろうな。
アセンブラからやれとは言わんが、メモリアロケータくらい自作したらオブジェクト指向がいかに理に叶ったものかわかってくるんだけど。
320:デフォルトの名無しさん
16/07/09 11:22:11.07 3DBY5ZwO.net
メモリアロケータを自作しないと理解できないってのもなぁ（苦笑）
321:デフォルトの名無しさん
16/07/09 12:11:02.75 vM1Dv6Aj.net
オブジェクト指向がわからない人は関数型を勉強してないんだろうな
手続き型はオブジェクト指向のメリットを潰してしまうから手続き型の書き方しか知らないとオブジェクト指向は身に付かない
322:デフォルトの名無しさん
16/07/09 12:19:20.59 afhBOa0Z.net
データのカプセル化ができてれば手続き型でもオブジェクト指向でも関数型でもいい気がするが
323:デフォルトの名無しさん
16/07/09 12:19:29.29 EzNW6797.net
分からない人がいて欲しいという強い願望ｗ
324:デフォルトの名無しさん
16/07/09 13:53:33.65 dEWSYkKq.net
オブジェクト指向つっても当初の「継承で差分プログラミングうまー」
みたいなのは否定されてきたからな。
入門書だと哺乳類クラスから犬クラスと猫クラスとかやってるけど、
動物が沢山出てくるゲームや動物病院のカルテシステムを開発するとして、
いちいち動物種ごとにクラスを作ることはしないだろう。
インターフェイス以外の継承は最小限にというのを教えないと。
でも未だに入門書レベルだと著者が勘違いしている。
325:デフォルトの名無しさん
16/07/09 18:59:46.91 akOZxrcr.net
>>324
かといって、というか
継承ってのがどんなものなのか「だけ」を説明するのなら
やっぱ犬猫でもいいんでねえのって俺は今は思う
継承をどう使って設計していくかってのはまた先の話
親、子A、子Bという三者の関係「だけ」示すのが動物犬猫
326:デフォルトの名無しさん
16/07/09 19:23:57.17 dEWSYkKq.net
>>325
例自体は反対しないよ。
でもそれで継承というものがどういうものかは分かっても、
継承がどういうときに使うべき物なのかは分からない。
そこまで教えてる本ってあまりないね。
327:名無しさん＠そうだ選挙に行こう！ Go to vote!
16/07/10 18:09:32.57 RTWM7o1I.net
(HP)をプロパティで持った「キャラクター」クラスを作って
それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
これを再利用して、「武闘家」クラスを作れば
おなじ"たたかう"メソッドで武闘家はてつのつめで戦うようにできる。
さらには(MP)と"まほう"メソッドを追加で「魔法使い」クラスが…
ってこの辺りで便利さがわかると同時に
(MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって
継承の不便さが浮き彫りになってくるという。
全部独立パーツでそれを必要に応じて束ねて使っていればもっと取り回しが楽だったり
328:デフォルトの名無しさん
16/07/10 20:28:28.05 4zLRjbrA.net
実装の再利用は継承でやるよりtraitが便利
smalltalkで発表されて、PHPに輸入されて、後は知らないが
329:デフォルトの名無しさん
16/07/10 22:16:26.35 /17c9zmN.net
Scalaとかの静的型言語がただのmixinをあえてtraitsと呼ぶのは誤解を招くよなぁ…
330:デフォルトの名無しさん
16/07/10 22:21:00.81 SLnFWOAS.net
>>327
> それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
> これを再利用して、「武闘家」クラスを作れば
武闘家は戦士を継承していません。
331:デフォルトの名無しさん
16/07/10 22:46:02.92 YDU79Arx.net
そもそもオブジェクトの粒度が高すぎんだよ
アビリティクラス的なものを作るべき
332:デフォルトの名無しさん
16/07/10 23:04:09.88 tx16mOUk.net
> ってこの辺りで便利さがわかると同時に
> (MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって
全然混乱しないなｗ
どこにつけるかなんてシステム次第だが
ドラクエ方式であればMPプロパティはキャラクタークラスで
魔法メソッドなんていうのは、特技メソッドの表示名の違いでしか無い。
333:デフォルトの名無しさん
16/07/11 08:10:49.21 BGpqEWk7.net
継承ベースだと
キャラクター>戦士>武闘家というクラス階層で
90年代のバカみたいな継承信奉してると武闘家の後ろとかに
"魔法使い"作って泥沼に嵌まるんだよな。
継承=オブジェクト指向だから。
334:デフォルトの名無しさん
16/07/11 08:24:29.03 DT6nTI14.net
継承を使いこなせないのは要するに馬鹿なんだよ
オブジェクト指向も関係なくプログラミングの基礎が出来てないから
335:デフォルトの名無しさん
16/07/11 09:34:50.03 c813o9It.net
>>333
> キャラクター>戦士>武闘家というクラス階層で
それはどう考えても間違った継承だろ。
継承信奉以前の問題で、継承関係にないものを
継承しているのは、お前が馬鹿だからってだけなんだが。
336:デフォルトの名無しさん
16/07/11 10:06:35.54 BGpqEWk7.net
「よくバカな奴が"延々と"を"永遠と"って書いてたりするよねー」
「え、おまえ"延々と"を"永遠と"って書いてんの！？バカじゃね！
俺なんか絶対そんな間違いしないね！！おまえバカだろ！バーカwww」
「えっ？」
337:デフォルトの名無しさん
16/07/11 11:14:13.38 v8BjKTdy.net
戸惑いのバカｗｗｗ
338:デフォルトの名無しさん
16/07/11 14:14:51.31 BGpqEWk7.net
えっ？
339:デフォルトの名無しさん
16/07/11 21:41:33.01 K+QqD/bm.net
>>326
そやねぇ
あまりないというか、見たことが無いｗ
あともしそれを書いてる本があっても
入門者には意外と伝わらないと思う
それを必要とする状況まで陥ってないと
デザパタ本ですらろくに伝わってない
困って、考えて、本読むという順じゃないと多分ダメ
…多分だけど
340:デフォルトの名無しさん
16/07/11 22:00:34.80 DT6nTI14.net
目的に合わせて正しく抽象化出来れば継承関係は自然に導かれるはず
継承だけに着目して教える/教わるという考えがそもそもおかしい
341:デフォルトの名無しさん
16/07/11 22:37:59.77 NMj8cyvT.net
概念の継承関係とコードの継承関係を同じ目線で見ると失敗する
342:デフォルトの名無しさん
16/07/11 22:42:17.81 DT6nTI14.net
>>341
それ抽象化が間違ってるからやｗ
343:デフォルトの名無しさん
16/07/12 00:05:30.28 dw2VnrEM.net
>>342
過度な期待期に入った新人君かな
344:デフォルトの名無しさん
16/07/12 07:21:41.32 jrBRhCE1.net
自分のモデリングの間違いを言語機能のせいにする
な？要するに馬鹿なんだよ
345:デフォルトの名無しさん
16/07/12 08:27:37.68 URFMxuYq.net
オブジェクト指向もずいぶん枯れたわけだし、アンチパターンの確認から入るってのも悪くはない。
346:デフォルトの名無しさん
16/07/12 09:41:37.70 Q/mNeBI3.net
正しく抽象化できれば正しくできる、
って意味のないこと言ってどうすんの？
その正しく抽象化する方法が問題なんでしょ？
347:デフォルトの名無しさん
16/07/12 09:54:02.01 DvYXCZnM.net
>>328
その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入りしたのでは？
348:デフォルトの名無しさん
16/07/12 10:24:32.15 QmnH/+e2.net
たとえば魔法使いと魔法という概念が"新たに生まれた"場合
それは魔法を使える魔法使いのみが使うから魔法使いクラスの固有プロパティなのか。
それとも、使えないだけですべてのキャラクターが持つ基礎パラメータなのか。
すべての基底クラスにMPデータフィールドを追加していいのか。
運を消費して奇跡を起こす聖者、MPやHPを消費して治療を行う僧侶などが
あたらしく出てきた時はどこにパラメータをつけて相互管理すればいいのか。
現実でその時は"ただしい"と思った抽象化が根底から揺さぶられることはいくらでもあって
(固定価格に追加される消費税、新たに追加される福祉控除項目、すべてを一元化しようというマイナンバー…)
まず、そういう認識すら持たずに「ちゃんとちゅうしょうかしないからだよ
ぼくならなんでもただしくちゅうしょうかできるからきみたちよりえらいのさ！」とか
うそぶいている時点で君はいま指をさして静かに嗤われてるのを自覚した方がいい。
349:デフォルトの名無しさん
16/07/12 12:19:52.07 4cCOY98n.net
>>348
要するに正しく抽象化モデリング出来てないだけだなｗ
お前が馬鹿な理由にオブジェクト指向も継承も全く関係ないわｗ
350:デフォルトの名無しさん
16/07/12 12:27:09.89 7TrvIOou.net
>>347
> その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入り
それもありそうな話で笑えるけど、traitsに限ってはModule#mixという名前で同機構の導入が
検討されたものの、既存の機能との整合性で致命的な問題が見つかって結局断念したらしい。
www.rubyist.net/~matz/20100617.html
URLﾘﾝｸ(d.hatena.ne.jp)
351:デフォルトの名無しさん
16/07/12 13:18:23.38 +8oNQ71Y.net
振る舞いの抽象化なら型クラスやインターフェイスを使えばいいし、実装の再利用ならtraitのような仕組みを使えばいい
継承による型の階層構造なんて邪魔にしかならんわ
352:デフォルトの名無しさん
16/07/12 17:45:58.73 h4Vj1dwQ.net
モデリングに間違いがなくかつモデルが未来永劫変化しないならID:4cC坊やの言い分は正しいね
そんな世界がやってくるといいね
353:デフォルトの名無しさん
16/07/12 18:38:57.22 J7TxVIFH.net
とりあえず>>348で言われてることを具体的にイメージできないぐらい"疎い"ってのだけはわかるよね…
多くのクラスに関わるモデリングを変えなきゃいけないぐらい大きな変更の例が列挙されていて
オブジェクト指向の黎明期と違って、オブジェクト指向があたりまえの空気になった現代だからこそ
強力な束縛を持つ継承がシステム組み替えの際の足かせになってきてるって話の流れにまったくついていけてない。
354:デフォルトの名無しさん
16/07/12 18:53:29.94 jrBRhCE1.net
お前らのは抽象化でなく、ただのぼんやりしたイメージ
いわば妄想プログラミングだなw
お前らみたいな馬鹿がまともに設計出来ないから
言語が馬鹿を縛れるような進化が求められてるだけなんだぜ
ダメなのは言語ではないお前ら自身だ
355:デフォルトの名無しさん
16/07/12 20:11:55.18 IS6BTglq.net
キッズは夢を見るものさ
356:デフォルトの名無しさん
16/07/12 20:31:52.34 Vv72dLZO.net
継承にしろオブジェクト指向にしろ
コードを簡潔にしたり、仕様変更に強くするために利用すべき技術だから
「猫と犬は哺乳類クラスを継承する、なぜなら猫も犬も哺乳類だから」ってのは
熟練したプログラマの発想とはだいぶ離れているんだよね
熟練したプログラマは書かなければならないコードが頭に浮かんでいて
それを何処に書くかという整理整頓の意味で継承などの技術を使っているわけで
結局OOは整理整頓術で、どう整理したらプログラミングの効率が上がるかというだけの話
それ以上の意味はない
が、整理整頓は非常に奥が深い
357:デフォルトの名無しさん
16/07/12 23:27:20.00 4M8hLvVe.net
そもそも哺乳類と言うのが最初にあって
そこから猫や犬が生まれたわけじゃないからな。
最初に猫や犬があって、そこから共通する特徴を
もっているものを哺乳類と分類した。
どっちかと言ったら名前空間みたいなもので
継承関係じゃない。（だけど理解するのに役立つ）
で実際のプログラミングでは哺乳類がどうとかいう話とは関係なく、
継承構造は役に立つもの
358:デフォルトの名無しさん
16/07/12 23:28:32.23 4M8hLvVe.net
>>352
> モデリングに間違いがなくかつモデルが未来永劫変化しないなら
変化するからこそリファクタリングが重要なんだよね。
リファクタリングは汚いコードを修正することじゃなくて
過去の時点では正しかった設計を、
今の時点の変化に合わせて設計を変えることだから。
359:デフォルトの名無しさん
16/07/13 08:17:59.46 +CQztjRc.net
継承はそういう時に身動き取れなくなるから困る
360:デフォルトの名無しさん
16/07/13 09:38:03.87 NLZRxEVY.net
359 名前：デフォルトの名無しさん[sage] 投稿日：2016/07/13(水) 08:17:59.46 ID:+CQztjRc
継承はそういう時に身動き取れなくなるから困る
361:デフォルトの名無しさん
16/07/13 12:39:18.51 Fh2kjKhX.net
大事な事だから２回言いました
362:デフォルトの名無しさん
16/07/14 19:03:55.13 sG4kt79u.net
割とマジで「オブジェクト指向って継承って奴だろ」な人で
言われてることがまったくわからなくてパニクってるんじゃないかと。
363:デフォルトの名無しさん
16/07/14 20:00:26.88 05a8wJuJ.net
原始時代じゃあるまいしそんなプログラマがいるのか？
にわかに信じがたいな
364:デフォルトの名無しさん
16/07/14 22:29:42.85 mVH/XKPM.net
美少女が人間クラスから継承できない問題は
どうなったんだ？
それでオブジェクト指向は破綻したときいたが。
365:デフォルトの名無しさん
16/07/14 23:30:26.34 0cl6EhrX.net
ぱっと思いつくだけでも
Unkoオブジェクトに量の概念をもたせて量がゼロのうんこを作るかNullObject的な対処をする
うんこしないAngelクラスを継承する
排便の概念を抽象化したメソッドを用意してうんこ以外の可能性を見出す
などなど
なんとでもなるやろ
366:デフォルトの名無しさん
16/07/15 05:19:16.25 Md4pEzwy.net
UnkoのサブクラスとしてOhgonクラスを実装するんや！
367:デフォルトの名無しさん
16/07/15 12:49:22.15 L1jCNFuA.net
美少女はウンコをしない
この「しない」という所が美しいんじゃないか
汚れなき乙女を全うする意志の問題だ
これが「出来ない」という物理的構造に由来する問題に成り下がってしまったら
何の味わいもなくなるだろ
チンコ勃たんわ
368:デフォルトの名無しさん
16/07/15 14:40:06.76 d/Zl1fgq.net
頭の悪い人の悲しいところは
頭の悪い冗談を好んで言い続けるということだ
飽きもせずに繰り返し繰り返し何度も何度も…
369:デフォルトの名無しさん
16/07/15 22:04:56.17 iR/HdeCl.net
これは頭の良い冗談に期待w
370:デフォルトの名無しさん
16/07/15 22:47:24.35 ibKxDQPd.net
美少年にクラスチェンジすることで破綻せずにハッテン
371:デフォルトの名無しさん
16/07/15 23:49:57.52 80GKY2p2.net
リフレクションで解体して色々いじりたい
372:デフォルトの名無しさん
16/07/16 01:53:47.85 Bfovl8qZ.net
面白くないことに気づこうね
373:デフォルトの名無しさん
16/07/16 02:59:56.46 0ciAe/St.net
というか>>211で書かれてるとおりをまたワンパターンで始めただけだしな。
374:デフォルトの名無しさん
16/07/16 07:28:07.42 CNSBQzp5.net
美少女ウンコ問題は高度すぎて解決の糸口すら見つからないもんな
ついていけない奴の気持ちもわかる
375:デフォルトの名無しさん
16/07/16 09:09:49.16 DegzgE4N.net
ちょっとしたネタ書き込みにすら
知能やセンスがもろ出しになっちゃうから悲しいね
>>372
それ言っちゃうと今度は意地になってレスし続ける可能性
376:デフォルトの名無しさん
16/07/16 09:38:23.65 D3kHuod4.net
>>372
面白くない→顔が白くない→色白でない→実は美少女ではない→ウンコしても問題ない
なるほど要件の再定義によって解決か
377:デフォルトの名無しさん
16/07/16 10:06:22.50 BhIXbiPC.net
なんでよ褐色美少女最高じゃん
378:デフォルトの名無しさん
16/07/16 10:11:41.75 6YOlPtSF.net
ワンパターンっすなぁ
379:デフォルトの名無しさん
16/07/16 12:26:01.17 3oB/Pjks.net
解決しとらんのにワンパターンもくそもないだろ
根気のない奴だなあ
380:デフォルトの名無しさん
16/07/16 20:05:26.83 kkC3KqZT.net
解決できると思ってるのが間違いだと気付くといいよ
分類学的な階層を作っても「書いた人どう対象を捉えているか」というどうでもいいことしかソースに残せない
鳩クラスと鹿クラスが同じ親クラスを持ってて、ニワトリクラスとブタクラスが同じ親クラスを持ってて、
一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ
そういう情報を一切俎上に出さずにAはBの子クラスであるべきか否かなんて話すのは無意味
そういう文脈をソースに組み込む必要があるかもまず考えないといけない
381:デフォルトの名無しさん
16/07/16 21:15:33.39 CNSBQzp5.net
なるほど
現状の研究成果に比べると一風変わった意見だが私は興味深く聞かせてもらったよ
つまり君はウンコをしない美少女が人間クラスから派生されるべきコンテキストについて
もっと掘り下げた議論をすべきだと言うのだな
ところで君はそういう文脈をソースに組みこむ必要があるかについては
どんな考えを持っているのかね？
382:デフォルトの名無しさん
16/07/16 21:41:47.94 LbU9Boej.net
ユーザーはうんこ機能なんか求めちゃいない。
383:デフォルトの名無しさん
16/07/17 01:46:14.62 MIDkP6ou.net
生成するUnkoオブジェクトのtasteフィールドが最大値になるだけ
384:デフォルトの名無しさん
16/07/17 05:00:03.09 nDXHZDmA.net
>>380
いやねーだろｗ その手のシステムで種ごとにクラスを分けるわけがない。
全部同じクラスだろ。
385:デフォルトの名無しさん
16/07/17 10:38:54.12 libZCVLZ.net
まあなんでも抽象化すればいいってもんではないわな。
物質は究極的にはクォークのセットだからって、そのまま実装したらそりゃ破綻するだろうし。
386:デフォルトの名無しさん
16/07/17 12:43:31.14 gClFyV8u.net
君それは細分化やないか
美少女のウンコふりかけ食わしたろか
387:デフォルトの名無しさん
16/07/17 13:29:48.60 okE8dWNU.net
同じ型のインスタンスの振る舞いをポリモーフィズムさせるのは、
・継承
・委譲
・switch文
・関数ポインタ、ラムダ式
・別途スクリプトなどを用意する
などの方法がある
388:デフォルトの名無しさん
16/07/17 13:57:59.74 PHnZw+de.net
ウンコって言いたい年頃なんだろうな
389:デフォルトの名無しさん
16/07/17 15:27:54.18 +aWd02nI.net
>>384
データはDB管理かもしれないしDBに沿った構成になるかもしれない
UIで必要であれば 380 の構成もありえるし
だから 380 は文脈と言ってるんだろうに
390:デフォルトの名無しさん
16/07/17 15:59:55.36 gClFyV8u.net
どんな文脈やねんｗ
肉屋の仕入れアプリでブタにダンスでもさせる気なんかｗ
そんなら俺はウンコを我慢する美少女の方がええわｗｗｗ
何でも文脈言えばええっちゅーもんちゃうでホンマ
391:デフォルトの名無しさん
16/07/17 16:05:40.68 q7clyz/N.net
>>389
いや、当然RDBMSでデータ管理しているという前提だが？
392:デフォルトの名無しさん
16/07/17 21:43:01.45 SWVEU9WP.net
クソスレじゃねーか!
393:デフォルトの名無しさん
16/07/20 23:08:50.86 0oomM0jq.net
計算式が面倒になったら
またどうせオブジェクト指向になるんだろ
394:デフォルトの名無しさん
16/07/20 23:42:38.15 E+SEwayU.net
>>380
> 一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ
見たこと無いが「あり得る」という話なら、
C言語でgotoばっかり使うってのもあり得るよ。
C言語なのに、オレオレライブラリとマクロを使って
COBOLみたいに使うことだって有り得るよ。
お前の大好きな言語をクソみたいな使い方する方法だって有り得るよ。
有り得るかどうかを語るのって意味なくね？
クソみたいなコードを書くのは書いた人間が悪いのであって
言語の問題でもオブジェクト指向の問題でもない。
395:デフォルトの名無しさん
16/07/21 02:05:10.33 pVvcsTGR.net
>>393
というか、人間がプログラムをユニット単位に分けた時に
"こいつはこういうコマンドを与えれば勝手にそれをやる単位"って
分け方をすれば『人間がわかりやすい』だろう。ってのが
いまあたりまえのメソッド型オブジェクト指向なんで、
こうすれば"副作用"が出ない！って計算式の方はむしろ
問題が起きないように『機械の都合に人間が合わせる』流れで
たぶん遠からず下火になるわ、あれ。つかもうなった感じ。
むしろ、アルゴリズム解析みたいなのを開発環境がやって
こうすると副作用が最小になるっぽいですよ？って
AIがサジェスチョンするようになんじゃね？つか。
396:デフォルトの名無しさん
16/07/21 12:07:59.69 gJ3egAPE.net
それはどうかわからんよ
もともと機械の都合で生まれた静的型が
実は人間にも優しいってことで大人気だし
本来静的型じゃなくても動く筈の動的型言語も
どんどん静的型の機能を取り入れていくのが今のトレンドでしょ
それに、副作用の無い関数型は全然機械の都合じゃないし
あれは数学の理論とかから生まれたような理論先行のもので
コンピュータの動作原理を考えたら、むしろ副作用ありの方が
自然だと思う
副作用ありの静的型言語が一番機械の都合に合っていて
その金字塔がC言語であり、今でも使われ続けている
主にローレベルなことやOSの開発やドライバの開発などに
使われているのは、それだけ機械の都合にあっているから
昔の言語なのに破たんせずに使われ続けているのは
それだけコンピュータの動作原理を素直に表現していて
流行り廃りというものと無縁だから
397:デフォルトの名無しさん
16/07/21 16:36:54.23 KvWRwuEL.net
Cで書いたコードが速く動くようにCPUやOSが設計されているという面も
あるからぬ…だからって新世代の言語に合わせてCPUやOSを作り直すか？
といわれたらそんなことは起こりっこないと断言できるが
398:デフォルトの名無しさん
16/07/21 17:56:06.90 9dMGMxaj.net
おまいさんそれは逆ですぜ。
Cがアセンブラに馴染み易く出来てるんですぜ。
でも本来はintelの系統じゃ無くて、
モートローラとかミニコンから派生した石に馴染み易く出来てるんですがね。
まあ、Cが最初からintelの石用に作ってたら、
もう少し違った構文になってたかもね。
399:デフォルトの名無しさん
16/07/21 18:08:41.00 9dMGMxaj.net
アセンブラやってた連中が、構造化プログラミングを提唱して、
プログラムを小さな塊の組み合わせで作る様になったんで、
同時期に条文分岐やサブルーチンの扱いをマクロ処理を被せて
読み易くするのが流行ったんだよ。
それをもっと書き易くして行って出て来たのがコンパイラ言語
いわゆる高級言語だけど、簡単なアセンブラへの置き換えしかしてなかった。
今ではそこから更にそれら高級言語を分かり易く記述出来る高次な高級言語が流行ってるけどね。
400:デフォルトの名無しさん
16/07/21 18:19:01.28 9dMGMxaj.net
例えば、hoge+とかやれば自動的にインクリメントしてくれる仕様だって、そういうアセンブラ命令があったからなんだぜ。
401:デフォルトの名無しさん
16/07/21 18:38:56.73 fNq3MD0e.net
>>397
＞Cで書いたコードが速く動くようにCPUやOSが設計されている
何を根拠に？
402:デフォルトの名無しさん
16/07/21 19:51:04.04 zfBmPUKU.net
>>399
時系列がぐちゃぐちゃじゃね？
最初の高級言語と呼べるものはFortranだけど、
数式を人間フレンドリーな形で記述できるのが売りだった。
Fortranはアセンブラの簡単な置き換えレベルではないでしょ。
構造化プログラミングはALGOLからだろうけど、
Fortranより後だし、Cのようなレベルに達するのはもっと先。
403:デフォルトの名無しさん
16/07/21 20:06:28.29 ZXk7cAfY.net
歴史しらないバカばっかw
404:デフォルトの名無しさん
16/07/21 20:28:04.90 IpsfD7Z7.net
自信を持って声を大きくして叫び続ければやがてそれが歴史となる
405:デフォルトの名無しさん
16/07/21 20:37:00.07 m+nIkrs4.net
後の人々はそれをこう呼んだ、すなわち黒歴史と……
406:デフォルトの名無しさん
16/07/21 21:20:03.86 gJ3egAPE.net
Cの何がすごいって、メモリに対する考え方がシンプルで凄い
構造体のメンバは単なる先頭からのオフセットだし
配列の添え字も先頭からのオフセットでしかない
しかも配列とポインタはある種の互換性がある
だから何だかよくわからないメモリブロックを
構造体にキャストしてアクセスできたり
同様に単なるメモリブロックを配列としてアクセスできたりする
メモリの扱いがとにかくシンプルでありつつ強力なアクセス方法があり応用が利く
こういうことができる言語はあまりない
C++ですらvtableが入ってたらもうオフセットずれるし
407:デフォルトの名無しさん
16/07/21 21:42:38.85 vaQfL518.net
>>406
言語の実装がシンプルなのと、その言語を
使ってアプリを実装するっていうのは別の話で
なんでも一つの機能で出来てしまう言語っていうのは、
冗長で意味代わりにくいコードになりがちなんだよ。
例えばシンプルと言うのならアセンブラが一番シンプル
条件判定命令と条件ジャンプ命令だけでループを表現できてしまう。
プログラム言語っていうのは、特定のパターンに対して
専用の命令を作ることでコードの可読性を高くしてきた。
これは圧縮の仕組みにも近い。特定のパターンに短い単語を当てはめて
簡潔に書くことができるようになる。
条件判定命令と条件ジャンプ命令さえあれば十分であっても
そこからforパターンやwhileパターンを見つけ、専用の単語に
割り当てることで可読性が高くなる。
408:デフォルトの名無しさん
16/07/21 22:34:35.81 9dMGMxaj.net
だからCだけが生き残ったんだろ？
大衆プログラマが望んだ形で変化した結果だからな。
409:デフォルトの名無しさん
16/07/21 23:16:46.30 vaQfL518.net
生き残ったっていうのは古い言語とくらべての話？
確かにFortlanとかPascalは消えた。
多くの優れた言語が生まれている中、今でも通用するのは
C言語ぐらいだと思うが。
410:デフォルトの名無しさん
16/07/21 23:17:21.89 zfBmPUKU.net
どちらも消えてねーだろｗ
411:デフォルトの名無しさん
16/07/21 23:21:30.21 vaQfL518.net
>>410
第三者の人が検証できるランキングとかある？
そりゃどこか目につかないところではあるかもしれないが、
例えばその言語で仕事したいと思ったとき
探せ出せないような言語は消えたと思っていいだろう。
412:デフォルトの名無しさん
16/07/21 23:39:22.80 zfBmPUKU.net
>>411
Intel Visual Fortran とかググッてみ。
リアルタイムで今も製品出てるのを消えたとは言わないでしょ。
413:デフォルトの名無しさん
16/07/21 23:45:13.87 vaQfL518.net
>>408
ということで、C以外も生き残ってるんだが？ｗ
414:デフォルトの名無しさん
16/07/21 23:52:22.14 dNMEb7c5.net
問題は暗黙に行う言語の動きに対してどれだけ
コンセンサスがとりやすいかってことだ。
c++ はもうその意味でどっか行ってる。
415:デフォルトの名無しさん
16/07/22 01:30:33.86 znBq8w6k.net
>>407
俺の言いたいことはそういうことじゃなくて
ローレベルな世界ではその言語固有のオブジェクトになってない
単なるメモリブロック、データ、信号を扱わなきゃならない場面が多いんだよ
それはファイルから読み込まれるかもしれないし
ネットワーク越しにやってくるかもしれないし
ディバイスとのやり取りかもしれないし
ま、要するに単なるデータ
Cはメモリモデルがシンプルだからこういった単なるメモリブロックを扱うのに
長けているんだよ
構造体にキャストするだけでそのまま扱えるから
今でもC言語が現場で活躍しているのはこれができるから
もしこういったことが出来なかったとしたら、C言語なんかとっくに滅んでいたに違いない
メモリブロックをキャストして構造体や配列としてアクセスできないとしたら
そんなC言語に価値なんかあるか？
その一点がすごいんだよ、マジセンスある、もしくは運が良かった