2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

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

1 :
2016/01/05(火) 02:10:25.72 ID: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/
2 :
2016/01/05(火) 02:40:11.66 ID:3cj4CitF
>>1 = ハゲ
>>3-1000
ゴミ


死ね
3 :
2016/01/05(火) 08:10:47.12 ID:WVEw1bNF
相変わらず気が狂ってるね
4 :
デフォルトの名無しさん
2016/01/05(火) 21:54:42.69 ID:8fihq/Cm
オブジェクト指向は直観に反するんだよな。
こいつを見てくれ。
http://pbs.twimg.com/media/CW4jn4jUkAAqIlA.jpg

Coffeeオブジェクトに振る舞いがある。これはオブジェクト指向的に完全に正しい。
しかし、現実にコーヒーを飲むのは人間だ。コーヒーは人間によってカップに注がれる存在だ。
これが思考を混乱させる。オブジェクト指向に従うとよくわからないソースコードのできあがりだ。
データに振る舞いを持たせるのは大失敗だと言わざるを得ない。
5 :
2016/01/05(火) 22:44:58.11 ID: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.22 ID:i0IFFoJB
コーヒーの属性定義が広範囲すぎる
量をのオブジェクトに突然、実態コーヒーを入れている
量のオブジェクトの範囲のクラスを作っる
コーヒークラスに量をコンポジションさせる
設計の間違え
7 :
2016/01/05(火) 22:51:39.37 ID:GCWuNCn0
>>4
単純。

コーヒーはただの量であり、人間オブジェクトの一変数だ。
いや、コーヒーはオブジェクトであり、生成からの時間により温度変数の値が変わる。
いや、コーヒー生成の時刻を保持するのは人間であり、コーヒーの温度を計算するのは人間である。
いや、コーヒーはコーヒーサーバーオブジェクトの変数であり、、、、
8 :
2016/01/05(火) 22:55:26.17 ID:i0IFFoJB
>>5
ま^、これでもいいがこれをオブジェクト指向と思っている時点で
何をやっても後が大変。
9 :
2016/01/05(火) 23:02:31.55 ID:zW6slUa6
>>8
目的次第としか言えんわ
直感的なコードが求められるなら>>5ってだけ
10 :
2016/01/05(火) 23:15:31.85 ID:i0IFFoJB
その直感が、直感的だと思う時点
斜め直感にしか見えん
11 :
デフォルトの名無しさん
2016/01/05(火) 23:33:07.12 ID:QVqdPGfo
すまん、自動で口にコーヒー注いでくれない前時代のコップ使ってる雑魚おる?
12 :
2016/01/06(水) 00:33:16.74 ID:73ZB/O6z
胃瘻はかなり前に技術だが
13 :
2016/01/06(水) 02:56:11.57 ID:MPHK5bs1
>>5
おまえはカップを飲むのかw
14 :
2016/01/06(水) 06:53:26.42 ID:UF966QGg
現実をそのままモデル化してOO否定って5周くらい遅れとるで
15 :
2016/01/06(水) 07:15:47.25 ID:QNndC4zW
形式主義ではコーヒーを椅子に置き換えても成り立つってことをいいたいんじゃないのか。
16 :
2016/01/06(水) 08:11:16.53 ID:xFxLYqzC
>>14
>>4は現実をそのままモデル化できていない。
大事なのは、そのままモデル化するのではなく、どうモデル化するかなのだ。
17 :
2016/01/06(水) 08:45:38.03 ID:/XlzX9bH
人間は現実を直接みてるわけじゃないからね
18 :
2016/01/06(水) 08:58:13.58 ID:9xF4ChVe
まー初心者(OOだけでなくプログラミング全般の初心者)向けのオブジェクト指向の解説とかでよくある説明だよね。
「オブジェクトとは日本語で物、対象物などという意味です」みたいなさ。とっかかりとしては平易なためによく使われているけど、
数学の定義のように後生大事にするべき、応用の効く、正しいイメージじゃない。
19 :
デフォルトの名無しさん
2016/01/06(水) 11:11:49.69 ID:wCEM/hYT
>>1
20 :
デフォルトの名無しさん
2016/01/06(水) 11:14:02.62 ID:Nukx80Um
クラスは原子陽子中性子くらいから完璧に継承すべき
21 :
デフォルトの名無しさん
2016/01/06(水) 11:15:12.81 ID:nQqbz+/u
メソッドに何かやらせるのはやめて全て物理演算で動作を決めるべき
22 :
デフォルトの名無しさん
2016/01/06(水) 11:19:28.24 ID:dAXQ+tnq
コンピュータ内でシミュレートするのではなく実際の分子原子を用いるべき
23 :
2016/01/06(水) 11:34:29.07 ID:KjcuT4OL
そんなことしたら分子原子の仕様変更で全てがひっくり返るぞ
24 :
デフォルトの名無しさん
2016/01/06(水) 11:54:24.95 ID:nQqbz+/u
メソッドコールのかわりにオブジェクトに対するフォースとトルクを搭載した言語を作ればいい
25 :
デフォルトの名無しさん
2016/01/06(水) 11:57:30.95 ID:nQqbz+/u
>>13
これ、どう表現すべきなのか?
26 :
2016/01/06(水) 12:01:41.51 ID:QNndC4zW
beDrank, beRefilledにかえればいいだけだろ。
27 :
2016/01/06(水) 12:26:10.76 ID:HvQ48C0N
>>25
drinkに渡すのはcup.contentsとかにする?
28 :
2016/01/06(水) 13:44:41.72 ID:ZUCJrGIg
>>4は一般的なコーヒーのモデル化じゃなくて
コーヒーの消費が常態化したマの皮肉じゃないの
最後にコメント付いてるし
29 :
デフォルトの名無しさん
2016/01/06(水) 21:55:30.95 ID:kAnzyWXR
オブジェクト指向は無理
30 :
デフォルトの名無しさん
2016/01/06(水) 21:55:58.83 ID:zRcw+KQb
まったく直感的ではないな
31 :
デフォルトの名無しさん
2016/01/06(水) 21:56:37.47 ID:fWGpYiip
こうしてクソみたいなソースコードが溢れた
32 :
デフォルトの名無しさん
2016/01/06(水) 21:57:33.23 ID:ljmmccCR
>>25-27
こんな議論になる時点でオブジェクト指向はヤバいだろ
33 :
デフォルトの名無しさん
2016/01/06(水) 21:58:49.59 ID:ljmmccCR
>>2
死ね
34 :
デフォルトの名無しさん
2016/01/06(水) 22:00:48.90 ID:vTtwKBx3
>>9
そこまでしてオブジェクト指向にこだわる意味がわからない。
そんなもんperlやrubyのワンライナーですませろよ
35 :
2016/01/07(木) 00:25:26.48 ID:idw/W9gn
オブジェクト指向も結局はコミュニケーションというか
メソッド(関数)指向という方が正しい。
結局はメソッド(関数)をどのように呼ばれるか、まとめられるかってことだから。
36 :
2016/01/07(木) 01:03:06.56 ID:Spe75WNW
メソッドは関数ではない
メソッドとは特定のオブジェクトにのみ適用可能な手続きであり、
関数とは特定のオブジェクトに依存しないものである
特に純粋関数は状態にも依存せず、参照等価性が成り立つものである

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

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

どちらが、現実世界の捨象に有用であるかということが問題なのである
37 :
2016/01/07(木) 01:15:30.61 ID:Spe75WNW
オブジェクト志向で実装可能なことは、原理的に関数型でも実装可能であり
関数型で実装可能なことは原理的にオブジェクト志向でも実装可能なはずである

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

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

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

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

オブジェクト志向での変数のカプセル化は容易ではあるが、本当に変数はカプセル化されるべきか
それが私の問いなのである
38 :
2016/01/07(木) 01:40:36.54 ID:6wDD5ILY
>>37
その問いにおける「変数」とは状態のことであるから、
それは構造化・カプセル化によってアクセス制限されるべきなのは明らか。
39 :
デフォルトの名無しさん
2016/01/07(木) 02:02:35.73 ID:EDvZlrKk
>>1>>4
結局のところ、この問題に誰もが納得するシンプルな回答を示せない奴が設計するからデスマーチになるんだろ。
40 :
2016/01/07(木) 03:17:27.43 ID:VBUUQOGk
自分も参加してるプロジェクトでデスマが起こるなら多分自分にも原因があるんだと思うよ
41 :
2016/01/07(木) 03:22:02.67 ID:Y5yasR7+
>>4
そもそもなんでコーヒーに命令するとコーヒーが自分で動作してんだよ。
そんなコーヒーがあるかw
いきなり設計段階から間違ってるじゃねーか

どう考えても最後の"//I am a software developer"って時点で
そういう設計をやらかす>>4みてぇなバカを揶揄したセルフパロじゃんかw
42 :
2016/01/07(木) 04:03:14.50 ID:Y5yasR7+
ああ、ジョークまで完全に見えた
>>4は「プログラマがコーヒーを飲む」じゃなくて
「コーヒーがプログラマに飲まれる」って逆転ジョークで
絶え間なくコーヒーが自動的にプログラマに注がれ続ける
おかしな逆転コードでプログラマジョークになってんだ。

「こいつをみてくれ」じゃねーよ!プププ
43 :
2016/01/07(木) 04:17:18.05 ID:boatvz1E
>>36-37 が大嘘であることはOCamlの存在が証明している
44 :
2016/01/07(木) 14:46:08.69 ID:Geoe+pHe
こういう根本的に理解できてないのが大量に居る時点で、オブジェクト指向は愚かな考えw
45 :
2016/01/07(木) 15:46:48.63 ID:bWvRU875
コーヒーはどうでもいいけど、
2.log() とか数に数学的関数計算をくっつけるってどうなのよ?
気持ち悪いったらありゃしねえ。
46 :
2016/01/07(木) 18:04:34.20 ID:nwSyjPdt
数学みたいにlog(2)でいいと思うが。
その()は何のためにあるんだと言いたい。
47 :
2016/01/07(木) 19:24:41.82 ID:bWvRU875
大分昔だけどフリー関数は気持ち悪くて、1.sin()とか1.cos()とか書けるのが本来の在り方だ、といった
痛い記事を読んだ記憶がある。Rubyがらみだったかなあ。
今ちょっと検索すると見つからないから俺の妄想なのかもしれん。
48 :
2016/01/07(木) 19:33:58.76 ID:LLMMv1AA
数字は計算をしないからそう書いちゃいかんのだけどな
49 :
2016/01/07(木) 19:53:48.55 ID:wknU54yj
+ 1 2
50 :
2016/01/07(木) 21:42:11.31 ID:a7kpSA/c
死ね括弧
51 :
2016/01/07(木) 21:57:00.05 ID:sG4YEGv+
(スズ)

拝承
52 :
2016/01/07(木) 22:18:47.33 ID:a7kpSA/c
>>46
> 何のため
関数そのものなのか、関数を呼び出した結果なのかを区別する括弧。
括弧がなければ関数そのもの、あれば関数呼び出しの結果。
括弧がなければlogという関数そのもの、あればlog(hoge)の計算結果。
かどうかは言語による。
53 :
デフォルトの名無しさん
2016/01/09(土) 14:00:07.10 ID:8eWGVEYX
>>45
こういう主語述語みたいなくだらない議論に陥るのがオブジェクト指向の最大の問題点だな
どっちでもいいからそのためのテストなりサンプルコードをがつがつ作ってくれれば問題ないんだが
糞みたいな議論ばっかりふっかける輩を生むところが最大の問題点だな。
54 :
デフォルトの名無しさん
2016/01/09(土) 14:37:25.60 ID:hdqMNonU
>>53
何も考えずに作業こなすだけの社畜 VS 議論ばかりやる頭でっかち ファイッ!!
55 :
デフォルトの名無しさん
2016/01/09(土) 16:12:34.83 ID:8eWGVEYX
>>54
極論煽るだけのカスも大概だけどな
56 :
2016/01/09(土) 17:15:53.50 ID:3kY/wzgi
>>53
ドット構文を変な風に使うバカの問題であってオブジェクト指向関係ないな。
57 :
2016/01/09(土) 18:23:24.86 ID:oGyr6/WF
主語述語っていうけど、オブジェクトは目的語だからね
58 :
2016/01/09(土) 19:25:35.83 ID:oGyr6/WF
昔ながらのfunc( obj ); 形式だと、オブジェクトを主語と考える人はいないだろうし
obj.func(); は↑が変形したものにすぎないから同じ理屈だよね
しかも時期C++ではfunc( obj )でもobj.func()でもどちらの形式でも呼び出せるようにするって
C++の超偉い人がやる気満々だし、見た目は最早重要ではないよね

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

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

現実世界に合わせて、主語をコンピュータ、オブジェクトを目的語、関数を述語、と捉えると
それで多態や継承が出来なくなるっつーんなら困るけど、そういうわけではないからね
だったら現実世界で起こっていることに合わせて考えたほうが自然だね
59 :
2016/01/09(土) 19:39:23.22 ID:OrUjMMRy
メッセージングのオブジェクト指向の言い方で言うと、
主語はメッセージのレシーバであり、文の残りはメッセージだ
60 :
2016/01/09(土) 23:40:46.34 ID:3kY/wzgi
>>58 チンパンジーのアイちゃんかな?
61 :
2016/01/09(土) 23:55:42.86 ID:CpCNnIMM
>>58
x.sin() では x がオブジェクトで、sinというメソッド(もしくはメッセージ?)を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。

どちらかの方がよりオブジェクト指向的だという序列なんかない。
数学関数それ自体をオブジェクトと認めようとしない思想(?)の根源は何なんだ?
62 :
デフォルトの名無しさん
2016/01/10(日) 00:13:34.71 ID:MD/fGeTk
ポーランド記法嫌いそう
63 :
2016/01/10(日) 00:21:12.30 ID:sdj7zt3O
演算子前置のポーランド記法は嫌いだなぁ
存在する意味がわからないレベルで嫌い。
演算子後置の逆ポーランドじゃないとね。
64 :
2016/01/10(日) 00:34:49.51 ID:0XznusY4
> 存在する意味がわからないレベルで嫌い。

なんで?

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

なんで?
65 :
2016/01/10(日) 00:40:13.45 ID:hoksOuY6
Add 3 to 5, then multiple it by 2.
66 :
2016/01/10(日) 01:09:07.40 ID:UgGJRpwk
逆ポーランドの方が実装しやすいと思う。
人それぞれの範疇だが。
67 :
デフォルトの名無しさん
2016/01/10(日) 01:11:54.59 ID:MiN6/z6v
>逆ポーランドの方が実装しやすいと思う。

意味がわからん。
構文木作るのに一番前と後でなんか変わるか?
AST作らずにそのまま逐次実行するならスタックに
積むだけでいい逆ポーランドの方がいいかもしれんが
68 :
2016/01/10(日) 01:16:08.27 ID:+l1yiqNW
x.sin() では x がオブジェクトで、sinというメソッド(もしくはメッセージ?)を処理していて、
sin(x) では sin がオブジェクトで、xという入力を処理している。

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

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

後者は明らかに関数的な考え方、動詞優位
69 :
デフォルトの名無しさん
2016/01/10(日) 01:27:11.07 ID:hZikTLMs
関数へのエイリアスのようなメソッドはドットで繋ぐのでなく、
別の文字にした方がいいよな。
70 :
2016/01/10(日) 01:29:17.31 ID:sdj7zt3O
釣りじゃなくて単に本当にあたまおかしいのかな?
Xはデータであって演算ではない。Xは演算しない。
Xをオブジェクトとして扱った場合、その操作として実装されるメソッドは
データのゲットセットなど内部状態を隠蔽するためのメソッドと
可変不変などのデータ状態をあらわすメソッド。

まだお前の脳内じゃおまえがコーヒーを飲むんじゃなくて
コーヒーが勝手に口に飛び込んで来てんのか。
71 :
2016/01/10(日) 01:29:19.21 ID:Ch7U5rc3
x.sin()は手続き言語的だと思うけどなあ
もちろんsin(x)も。
オブジェクト指向ならメッセージを送るような記述の方が自然では
72 :
デフォルトの名無しさん
2016/01/10(日) 01:52:12.61 ID:hZikTLMs
現実世界をオブジェクト指向に当てはめるやついるけど馬鹿だよなー

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

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

具体的な手続きによる具体的な文字通りのプログラムを書きたいなら
Cでかいてどうぞ
74 :
2016/01/10(日) 01:59:31.92 ID:+l1yiqNW
オブジェクト指向だろうと関数志向だろうとやってることは変わらない

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

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

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

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

数学ができない自称モデラーはプログラムを手続き的に書いたらいいんだよ
75 :
デフォルトの名無しさん
2016/01/10(日) 02:00:42.57 ID:hZikTLMs
特化させたいのに汎化する必要ある?
狭い世界で使うなら特化させていい。
広い世界で使うなら汎化させる。

それだけ。
76 :
デフォルトの名無しさん
2016/01/10(日) 02:03:41.63 ID:hZikTLMs
汎化と特化させるもんを決めるのが設計な
77 :
デフォルトの名無しさん
2016/01/10(日) 02:42:12.92 ID:JhCLPk/2
>>74
言ってることはわかるがコーヒーを主語に対象を汎化なら
coffee1.drunkBy(me);
coffee2.drunkBy(you);
だろ
78 :
デフォルトの名無しさん
2016/01/10(日) 03:01:38.69 ID:JhCLPk/2
>>72
普通モデリングなんて想定される実装の多さや効率の問題で変えるものだからね
感性にまかせる初心者ほど文脈や抽象に拘って依存性の上下を無視するよ
79 :
2016/01/10(日) 04:22:46.36 ID:sdj7zt3O
アクセル→エンジン→ギア→タイヤじゃなくて
タイヤ.回転で自動車設計してそうだなおまえら。
80 :
デフォルトの名無しさん
2016/01/10(日) 05:12:47.23 ID:JhCLPk/2
>>79
そうやって現実の構造を想定している時点でもう駄目なんだよ
81 :
デフォルトの名無しさん
2016/01/10(日) 05:20:12.43 ID:JhCLPk/2
ちうかこれオブジェクトが目的語とか言ってる人か?
英語とプログラミングのobject混同とかとてもまともとは思えないよ
82 :
2016/01/10(日) 05:34:14.40 ID:97NQyWJD
>>74
JavaScriptだと実際foo.barは第0番目の引数を指定するための糖衣構文でしか無い
オブジェクト指向は別にそんな大したものでも、手続き型と相容れないものでもない
指向とは言うが実際の所スタイルの一部だね
83 :
2016/01/10(日) 08:13:48.91 ID:86WjwACC
いいえ、自転車.操業で設計しています
84 :
2016/01/10(日) 08:49:55.36 ID:jS8+hJYw
>>82
そういう嘘をまき散らさないでもらいたいなあ。
毛の人といい、技術の普及は嘘との戦いだな。
オブジェクト指向は嘘つきが多すぎた。
85 :
2016/01/10(日) 09:36:41.30 ID:AcnVMiQc
>>68
いいえ。
sin(x) と書いたときのsinは十分オブジェクトに見えるでしょ。
xとsinは違う階層(空間)に属するモノだけど、後者の方が階層としては高い。
x.sin()と書くと、あるオブジェクトが自分より高い階層のオブジェクトを所有しているように見えてしまう。
これは俺にとっては不自然なので好きになれない。
86 :
デフォルトの名無しさん
2016/01/10(日) 09:42:21.66 ID:KeJgEHCD
オブジェクト指向は手続き型と直行する概念だと理解してないのが何人かいるな
87 :
2016/01/10(日) 09:44:41.71 ID:sdj7zt3O
>>80
"現実の構造を想定しちゃダメ"て
おまえの作るシステムはどんな現実離れした
脳内妄想ベースなんだよ。
88 :
デフォルトの名無しさん
2016/01/10(日) 09:52:56.57 ID:Itquv6VW
sinは関数だろね。
テーブルを持つためにクラスを使わなければならない言語があったとしても、
極力、ユーザーにとって関数に見えるように実装するべきじゃないのかな。
89 :
2016/01/10(日) 10:08:13.09 ID:jS8+hJYw
関数がオブジェクトじゃ何か困ることでも?
90 :
2016/01/10(日) 10:09:40.58 ID:jS8+hJYw
>>79
君が設計する自動車ではエンジンブレーキが効かないようだな。
91 :
デフォルトの名無しさん
2016/01/10(日) 10:29:26.64 ID:hZikTLMs
ブレーキなんてのは外部から
ベクトルの力を操作するんだから
後付けで全然構わないんだが。
92 :
2016/01/10(日) 10:41:27.70 ID:AcnVMiQc
関数を手続きだと思ってるならそれでいいけど、名前が関数ってだけで数学関数をそういうカテゴリーのものとするのは不適当でしょうね。
93 :
2016/01/10(日) 11:09:22.36 ID:hXY04te0
クロージャーって、関数なの?オブジェクトなの?
rubyだとProcのインスタンスでしかないよね
94 :
2016/01/10(日) 12:33:30.21 ID:jS8+hJYw
>>91
わからないなら無理に口を挟まないほうがいいよ。
95 :
デフォルトの名無しさん
2016/01/10(日) 13:26:28.06 ID:Itquv6VW
>>92
関数が状態を持つべきかどうか考えると自ずと答えが出るのではないだろうか。
96 :
2016/01/10(日) 13:37:48.58 ID:UyzGSaeg
sin(x)は関数の値であって関数ではないよな。 関数は∀x∈double.sin(x)のことだよな。
97 :
2016/01/10(日) 13:51:03.83 ID:ainPuYsM
>>85
実装がどうあれ、OOPではメソッドはオブジェクトに属するものとして考えるから、
x.sin(value)の表記は不自然じゃ無いだろ。sinはオブジェクトxに属している。
98 :
デフォルトの名無しさん
2016/01/10(日) 14:13:06.68 ID:Itquv6VW
>>97
それは不自然な考え方じゃないかな。
原点に立ち返ってみると、オブジェクト志向とはコード再利用に際して
コンポーネント化の要求から発生したもの。
現実に存在する物のように、ディスプレイ上のウィンドウに四角形を
描画しろとメッセージを送るというようなシンプルなものだ。
この場合、四角形自体がオブジェクトであることは問題が無いように感じる。
これは、四角形が状態を保持しているからかもしれない。
一方、数値に対してsinを要求するのは突拍子もないように感じる。
これは、数値を日常いたるところで使用していて、数値がメッセージを受け取る性質を
もたないと良く知ってるからではないだろうか。
あるいは計算機オブジェクトに対してsinを要求するなら不自然に感じないのかもしれない。
どうだろうか?
99 :
2016/01/10(日) 14:14:35.30 ID:CDx7UjTI
この種のくそ議論って恣意的な答えしかないんだから、
議論するだけ無駄なんだけどねぇ。
100 :
2016/01/10(日) 14:15:24.10 ID:AcnVMiQc
>>95
状態をもつかどうかは実装しだい。
関数を初期化するとき係数のセットを与えるとかあると思う。

関数がグループとしてまとまって環をなすとか
101 :
2016/01/10(日) 14:17:25.96 ID:ainPuYsM
つか、sin(x)ってなんやねんw
引数無しのメソッドの話か? それならsinは例として不適当だ。

sinを例にするなら、x.sin(value) か、sin(x, value) だろ。
102 :
2016/01/10(日) 14:17:26.78 ID:AcnVMiQc
>>97
そりゃメソッドはオブジェクトに属するだろ。
メソッドとして位置付けるのが適切かどうかの議論をしてるんだよ。
103 :
デフォルトの名無しさん
2016/01/10(日) 14:17:31.05 ID:Itquv6VW
こういうシンプルな考えに基づくと、四角形と三角形は形状クラスから
派生すると思われる。
しかし、四角形オブジェクトと三角形オブジェクトの合成メソッドは、形状クラスあるいは
その派生クラスにあってはならないように感じる。
それは形状合成器クラスに、あるいは単純な関数であった方が良いように感じる。
104 :
デフォルトの名無しさん
2016/01/10(日) 14:21:04.23 ID:JhCLPk/2
>>87
物理的構造物とは違うんだよ
それすら理解できないならもう向いてないとしか
105 :
2016/01/10(日) 14:21:57.10 ID:UyzGSaeg
属すじゃなくて依存するだと思うが。
106 :
デフォルトの名無しさん
2016/01/10(日) 14:25:29.45 ID:JhCLPk/2
例えばゲームでキャラクターが特定のアイテムを使用するモデル
キャラ.使う(アイテム)はもらうアイテムによってメソッドの動作を変える必要があるが
設計としてはアイテム.適用(キャラ)のが遥かに取り回しやすい
なのにあえて前者のクソ設計を選ぶのが>>87のようなオバカさん
107 :
2016/01/10(日) 14:26:22.66 ID:ainPuYsM
>>102
それならOOPの議論じゃないな。

>>105
いや、属する/所有するという概念の方が適当だと思う。(実装は違うが)
実際クラスを書くときそう書くだろ。
108 :
2016/01/10(日) 14:44:22.50 ID:AcnVMiQc
>>101
現実の姿を模すという意味だとsinなどは連想配列であって、sin(x)という書き方はそのまんまだよね。
実装においては計算手続きだろうけど。
109 :
2016/01/10(日) 14:48:45.22 ID:jS8+hJYw
Smalltalkerが引き上げたらもう初心者しか残ってないのかよ
110 :
2016/01/10(日) 15:22:03.47 ID:yvIOv1as
そもそもクラスだってオブジェクト指向とは直接関係ない
>>84
嘘ではなく現実だ
111 :
2016/01/10(日) 15:23:27.70 ID:yvIOv1as
美少女が云々言うのも一般的なクラスベースは融通が効かないねという話であって
オブジェクト指向とは直接関係ないし
112 :
デフォルトの名無しさん
2016/01/10(日) 15:44:15.32 ID:KeJgEHCD
>>111
ほう、それならウンコをしない美少女をオブジェクト指向で設計して貰おうか
113 :
2016/01/10(日) 15:50:56.07 ID:AcnVMiQc
>>97
見逃したいたが、x.sin(value)の value って何だい?
114 :
2016/01/10(日) 16:06:27.16 ID:ainPuYsM
>>113
引数だよ。
クラスxのメソッドsinに渡す引数。
俺はそういう話をしてると思ったから。
115 :
デフォルトの名無しさん
2016/01/10(日) 16:18:07.80 ID:hZikTLMs
xって中身は例えばfloatのデータ自身だぞ?
だから、引数は必要ないんだぞ?
116 :
2016/01/10(日) 16:26:17.41 ID:ainPuYsM
>>115
理解した。
それなら、x.sin() なんて形が出てくる余地は無いよな。
117 :
2016/01/10(日) 16:29:21.43 ID:CDx7UjTI
一般に sin に必要な引数は、 pi/2 とかの実数(もしくは複素数) かな。
あとはいくつまでの級数和をとるとか何桁まで計算するとかが引数になるんじゃないかね。
その辺をあいまいなまま value とか x がクラスだの引数だの言ってることに何か意味があると思ってんのかね。
118 :
2016/01/10(日) 16:34:25.26 ID:ainPuYsM
>>117
いや、sinの引数がオブジェクトの場合はあるよ。
実数や10進型をクラスで表現したりするし、俺も実際やる。
xがそういうオブジェクトなら、sin(x)でいいし、x.sin()はおかしい。
まあ絶対におかしいとか無理ってわけじゃないけどなw
119 :
2016/01/10(日) 16:54:55.24 ID:yIre7PYR
新しいC++ではsin(x)でもx.sin()でも、どちらの方法でも統一的に呼び出せるようになる予定だから
こんな議論は全く意味ないんだよ?

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

どちらの方法でも呼び出せるんだから、喧嘩する必要ないし、気にする必要ないよね
120 :
2016/01/10(日) 16:57:47.72 ID:yIre7PYR
どちらの方法でも呼び出せるんだから
どちらの方が、よりオブジェクト指向的か、考えるのは意味がないんだよ
等しいわけ、等価と考えてよい
見た目が違うだけ
大した問題じゃない
121 :
2016/01/10(日) 17:00:24.30 ID:ainPuYsM
なんか違うような気がするなw
122 :
デフォルトの名無しさん
2016/01/10(日) 17:07:10.06 ID:fbwGqbCo
こんなにややこしいプログラムがオブジェクト指向を使って
こんなに簡潔になりましたって事例が欲しい
123 :
2016/01/10(日) 17:12:10.48 ID:1042xGua
>>112
思うんだけど、
うんkをしないというのが、
意思を持ってひたすら我慢して(人の目がある場所では)しないのか、
それとも腸内の美少女菌のおかげでする必要が無いのか、
もしくは他の何かなのかによってイメージが変わってくると思う。
でもしないにしろする必要がないにしろ、排便メソッド自体は備わっててもなんら問題ないと思う。
逆に、腸内やなんかの問題を解決せずに、排便メソッドだけ外して他を流用するということは、
オブジェクト指向的であろうがなかろうが不可能だと思う。
それこそ亞人として設計しなおして全ての手続やメソッドを別に用意することが妥当かもしれない。
だから結論を言うと、この例はそもそも良くないと思う。
124 :
2016/01/10(日) 17:51:06.88 ID: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.94 ID:fbwGqbCo
>>124
なるほどねー。
126 :
デフォルトの名無しさん
2016/01/10(日) 19:16:06.37 ID:fbwGqbCo
>>112
美少女はマーカーインターフェースであり、
美少女として扱うとき排便は隠蔽される。

interface 美少女 {
}

class おっさん implements 美少女 {
 void 排便() {
 }
}
127 :
2016/01/10(日) 20:20:59.69 ID:VQDMXfno
>>126
それは「何もしない」という排便メソッドを持つ
持たない,ではない
128 :
デフォルトの名無しさん
2016/01/10(日) 20:34:00.62 ID:fbwGqbCo
>>127
何を言うてんの?排便メソッドを持つのはおっさんだよ。
129 :
デフォルトの名無しさん
2016/01/10(日) 20:41:36.36 ID:KeJgEHCD
聖水メソッドもないのに美少女とか笑わせんなよw
130 :
2016/01/10(日) 21:17:46.16 ID:+l1yiqNW
オブジェクト志向の考えだと
大便ableインターフェースを実装するんだろ
131 :
2016/01/10(日) 21:57:06.57 ID:Hm2sxH4v
美少女クラスを欲する奴が美少女のウンコがついたぱんつを欲しがらないかと考えると
これは要件定義から間違っているような気がしてならない。
132 :
2016/01/10(日) 22:05:43.79 ID:zd2SpHtU
実装からメソッド設計を考えるより使い方から設計したほうが上手く行くと思う
つまり美少女がうんこ出来るのか、出来ないのかで考えるのでは無く美少女にうんこをさせたいのか、うんこさせたくないのかで考える
133 :
デフォルトの名無しさん
2016/01/10(日) 22:12:58.59 ID:hZikTLMs
肛門はコンポーネントとしてアタッチする。
美少女は肛門をインプリメントしていない
134 :
デフォルトの名無しさん
2016/01/11(月) 02:57:08.55 ID:87Jnvcw4
あのさ、どんな美少女もウンコするんだけど?
135 :
2016/01/11(月) 03:08:27.43 ID:Rwcs8mHW
真の美少女は実在しない
136 :
2016/01/11(月) 03:18:02.16 ID:4rCdY4Yq
137 :
2016/01/11(月) 04:26:03.17 ID:3eUcyomA
138 :
2016/01/11(月) 14:41:47.97 ID:GiqteBDS
関数型言語っていい点もあるけど、変更に弱過ぎない?
ちょっと動作を変えるのにかなり見直さないといけない
139 :
2016/01/11(月) 16:00:11.66 ID:Rwcs8mHW
作りようだね
140 :
デフォルトの名無しさん
2016/01/11(月) 17:41:31.97 ID:d9M93+6h
>>138
関数型言語を使えば完璧なプログラミングが可能なので後から変更する必要が無い。
141 :
2016/01/11(月) 17:50:34.21 ID:KkwWauMD
>>140
完璧なプログラミングは出来ても
将来の仕様の変化を完璧に予測することは出来ないでしょ?
142 :
2016/01/11(月) 17:53:14.36 ID:GiqteBDS
仕様変更できないって実用上ヤバくないですか
143 :
2016/01/11(月) 18:03:26.01 ID:RUBsLBHi
オブジェクト指向は細かい修正で済むと手を抜き続けた結果メチャクチャ悲惨なことになる
全て書き直すくらいがちょうどいい
144 :
2016/01/11(月) 18:08:52.97 ID:hbMmOduf
> メチャクチャ悲惨なこと

たとえば?
145 :
2016/01/11(月) 18:13:38.40 ID:rz35E4wE
>>144
全て書き直すはめになる
146 :
2016/01/11(月) 18:18:05.61 ID:V0AQQEoP
関数型言語は仕様変更のたびにめちゃくちゃ悲惨なことをしなければならないのか
147 :
2016/01/11(月) 18:31:28.27 ID:KoUNfQqa
言語の問題でなくて作ってる奴が馬鹿なだけでは?
148 :
2016/01/11(月) 18:59:27.70 ID:A5Rx7ofK
ただのリスト操作を関数型と呼んでいる可能性
149 :
デフォルトの名無しさん
2016/01/11(月) 19:14:51.77 ID:d9M93+6h
>>141
関数型なら完全に未来を予測できる。
150 :
2016/01/11(月) 19:37:40.52 ID:ugQF1NqL
そらすげーわ
151 :
2016/01/11(月) 19:38:18.20 ID:rz35E4wE
>>149
そういうのいいから
152 :
2016/01/11(月) 19:43:22.94 ID:XhrtL63c
関数型言語はコンパイルした瞬間全てが完了される。
153 :
デフォルトの名無しさん
2016/01/11(月) 19:46:13.85 ID:d9M93+6h
コンパイルが通ればバグが無いことを保証される。
154 :
2016/01/11(月) 19:47:17.32 ID:rz35E4wE
>>153
それもいいから
155 :
デフォルトの名無しさん
2016/01/11(月) 19:49:39.36 ID:d9M93+6h
>>154
お前関数型馬鹿にしてんの?
156 :
2016/01/11(月) 19:53:45.95 ID:XhrtL63c
関数型言語にとって型とはプログラムの設計図なのである。
157 :
2016/01/11(月) 19:55:09.91 ID:rz35E4wE
>>155
関数型じゃなくてお前を馬鹿にしてるんだよw
158 :
2016/01/11(月) 19:55:15.79 ID:eiYfk44d
1000近くなった雰囲気だな
159 :
デフォルトの名無しさん
2016/01/11(月) 20:02:18.58 ID:d9M93+6h
ヨハネの手紙にも関数型が登場する。
160 :
2016/01/11(月) 20:05:53.42 ID:eiYfk44d
鶏が鳴く前に三度、関数型など知らないと言う
161 :
デフォルトの名無しさん
2016/01/11(月) 20:09:36.09 ID:d9M93+6h
マタイの福音書、関数型が世界を平和に導く。
162 :
デフォルトの名無しさん
2016/01/11(月) 20:40:32.13 ID:d9M93+6h
>>157
ああそう、なら良いんだ。
関数型馬鹿にしたら唐沢弁護士に頼んで勝訴しちゃうからね?
163 :
デフォルトの名無しさん
2016/01/11(月) 22:15:27.49 ID:qSBpiVnS
関数型に不可能はない。関数型は神にのみ扱える至高の言語
関数型を疑ってはならない。汝の実力を疑え
164 :
2016/01/11(月) 22:48:28.28 ID:CMbhymom
毛の壁の臭いがするな。
165 :
2016/01/12(火) 01:32:19.38 ID:SYPJaqWI
広く使われてて実用的な言語は多かれ少なかれマルチパラダイム
関数型っていうのも結局は作者がそう言ってるかどうかの線引でしか無い
理想的な関数型gwンゴを想定してなにか言うのはあまり意味が無い
166 :
2016/01/12(火) 01:34:43.86 ID:uMvEa0J7
関数型ンゴwwwwwwwwwwwwwwwwwwwwwwwwwww
167 :
2016/01/12(火) 08:42:46.08 ID:V5bMIqIZ
関数型グワンゴ
168 :
2016/01/12(火) 09:12:48.84 ID:/ZqCERvo
今時は大学とかでも言語比較とか講義しているのかな。
169 :
2016/01/12(火) 19:38:37.49 ID:7kdSKUGZ
lisp は関数型ですか?
170 :
2016/01/12(火) 22:56:29.42 ID:uMvEa0J7
いいえ、変態型です
171 :
2016/01/14(木) 06:56:24.28 ID:/XPEQoow
172 :
2016/01/16(土) 23:50:44.88 ID:vrXiOUCa
美少女は天使クラスに属している。
排便しない。
173 :
2016/01/20(水) 11:46:14.76 ID:HskUHurd
「オブジェクト指向プログラミングの例を挙げましょう。2000年代には、オブジェクト指向プログラミングは、企業向けプログラミングにおける基盤的技術の地位を確立したと思われていました。
しかし今では、私を含めて多くの人が、この潮流は20年間に渡って本流から逸れていたものであり、そのほとんどが間違いだったと考えています。」

コーディングを学ぶこと、それはあなたが考えるよりも大変です
http://postd.cc/learn-to-code-its-harder-than-you-think/
174 :
2016/01/20(水) 12:33:48.74 ID:CF7z5V/R
>>173
記事のベースはイギリスのプログラマ教育のあり方と社会地位の話で
"大学で教えていることが現場で役に立たない"ことと
"高級技術者としてのプログラマの社会的地位の低さ"について
そして、前者関連の話で「教えるべき技術は次々と移り変わる」例として
オブジェクト指向を挙げてみてるが、筆者があまり理解してる感じではないなぁ…
20年前なら単語そのまま「構造化プログラミング」に置き換えて書かれた
単なる流行りワードの扱いだわな。
175 :
2016/01/20(水) 12:39:59.33 ID:CF7z5V/R
また、書かれている内容のとおりイギリスのプログラミング技術のほとんどが
学校教育ではなく「独学」で学ばねばならないもので、その上でガチで
『しかし今では、私を含めて多くの人が、この潮流は20年間に渡って
本流から逸れていたものであり、そのほとんどが間違いだったと考えています。』
と、思ってるとしたら本当にイギリスのプログラミング業界界隈の危機は
深刻なものだと考えざるをえない…
176 :
2016/01/20(水) 12:41:46.50 ID:uqyd4S+p
日本も似たようなもんじゃないの? 違うの?
177 :
2016/01/20(水) 12:58:06.53 ID:CF7z5V/R
>>176
>>173のリンクを読んだ感じではイギリスではどうも国を挙げて
学校や社会人教育で「無償で国民にプログラミングを学ばせる」事業をやってたっぽい
で、たぶん日本でやってもそうなるだろうけれど
みんな合格するようなレベルの簡単な内容なので
わざわざ教える意味がない的な事態になったっぽい?

大学の情報学科だったら日本でもまぁ直でコーディングの役には立たんが
逆に大学レベルの情報工学理論面を広く教えるから
オブジェクト指向なんて〜って池沼はでないだろう(皮肉
178 :
2016/01/20(水) 21:59:54.59 ID:ftWUH7Q0
オブジェクト指向は思考パターンを破壊されるよ
179 :
2016/01/20(水) 22:38:38.89 ID:KK1TC/Qj
コードの奇麗さはなになに指向とかとはいつだって無相関だよ。
180 :
2016/01/20(水) 23:28:45.86 ID:lyH/JRhU
>>179
その評価はとても健全
181 :
2016/01/21(木) 12:15:51.15 ID:pkb4zgJk
>>179
「奇麗」なコードってどんなの?
182 :
2016/01/21(木) 16:38:21.88 ID:OmENn3Ct
>>181
測定するツールがある。
183 :
2016/01/22(金) 08:41:08.27 ID:jWLszG8x
それはツールに設定したルールを守ってるかの判別器でしか無いな。
本当に一般的に綺麗なコードとやらを図るには、
統計を集めて機械学習でもさせる必要があるだろう。

もしくは綺麗というのが、編集しやすいということなら
最低きちんとした理論と根拠を元に基準を決めるべき。
今の基準の多くはただ作者の信念だったり、狭い範囲での多数はを取っているだけ。
184 :
2016/01/22(金) 10:24:46.06 ID:BOI0ua8w
>>183
コードコンプリートでもよんだら?
185 :
2016/01/22(金) 12:53:49.39 ID:NE1Xg/XG
コードとは言語だから、綺麗な英語と置き換えてみればわかる。 学校で教えられるのは全部綺麗な英語だから実際の外人の喋ってることなんか一つも役に立たない。 汚いコードを書いてどんな汚いコードも読めるようになるのが大切。
186 :
2016/01/22(金) 13:21:50.19 ID:p0qaIBjS
実際に効果があるかそっちのけで、主観的な綺麗さばっかり気にしてルールを
固定化しようとするやつなんなの?
どことなく自閉症的で気味が悪い。
187 :
2016/01/22(金) 13:23:33.14 ID:p0qaIBjS
あ、このスレの発言のことじゃないです。リアルの話。
188 :
2016/01/22(金) 14:33:54.36 ID:IejezU7v
コードコンプリートを書いたのはマイクロソフト()だぞ
林檎がビューティパーフェクトコードを書くまで待て
189 :
2016/01/22(金) 22:02:12.46 ID:SlI41mNc
>>185
こういう人が職場にいたらきついお
190 :
2016/01/22(金) 22:17:23.23 ID:jXHHn5ty
>>186
ルールなんて誰でもわかってると思うけどな。

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

これらは主観じゃないので、このルールにしたがえば、
誰でも良い方がどちらかわかる。
191 :
2016/01/22(金) 23:23:12.65 ID:p0qaIBjS
>>190
それらは効果があるとわかるものだから問題ないよ。
192 :
2016/01/23(土) 03:52:18.65 ID:qPctTKOa
Smalltalker達がいなくなったら途端に初心者スレ化w
193 :
2016/01/23(土) 14:01:47.22 ID:xYcOlVg1
Smalltalkの人はボコボコにされて
Smalltalkに自信を失って帰っちゃったからな

実際全然使われていない現実なわけだから
何を言っても説得力皆無だし机上の空論になるし
こいつマゾと思って皆で玩具にしたが
言うほどマゾじゃなかったのかもね
194 :
2016/01/23(土) 19:33:03.55 ID: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.46 ID:qHL6kF89
196 :
2016/01/23(土) 22:09:12.03 ID:Sj7C6OsA
197 :
2016/01/30(土) 19:31:26.50 ID:ZdxrrRsd
>>185
どんな汚いコードも読めることは大切だが
汚いコードは書くなよ…

まあその汚さをある程度許されるようになるオブジェクト指向は嫌いじゃない
198 :
2016/02/02(火) 15:15:07.68 ID:Kj5oXuy8
>>197
いや、それでも人間クラスに
排便メソッドは必要だ。
199 :
2016/02/02(火) 21:15:38.34 ID:7zvF4Jbc
刈羽 かりわ JR越後線
200 :
2016/02/03(水) 00:10:39.67 ID:JLgoV6RT
>>198
そんな汚いコード書くと人間クラスを継承した美少女クラスで不都合が生じる
201 :
2016/02/03(水) 08:41:03.18 ID:LaxmbkTJ
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...
202 :
2016/02/03(水) 08:41:21.38 ID:LaxmbkTJ
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...
203 :
2016/02/03(水) 08:41:50.93 ID:LaxmbkTJ
>>200
だから美少女クラスは天使クラスを継承するのだと何度説明すれば...
204 :
2016/02/03(水) 08:42:43.86 ID:v0iZc+aq
2回連投はよくみるけど3回は珍しいw
205 :
デフォルトの名無しさん
2016/02/03(水) 08:57:53.06 ID:ffzzO4R/
あのさ…… どんな美少女もウンコするんだけど?
206 :
2016/02/03(水) 12:29:23.04 ID:8IxY+gWE
人間クラスを継承せずに、
必要に応じて肛門を持たせればいいのでは?

この問題は、設計を誤ると修整が容易ではないと言ってるの?
論点は何?
207 :
2016/02/03(水) 23:54:09.81 ID:NwkI7iYf
インスタンス化もせずにスレたてとな?
208 :
2016/02/04(木) 01:07:49.04 ID:K1JlKV3Z
>>206
メンバーの種類を制限したり、メンバー間に何らかの制約を入れたクラスが欲しいときの
ベストプラクティスはっていう話かい?
言語によるけれど c++ のテンプレート使った方法が「Modern C++ Design」に書いてあった気はする。
有用かどうかは知らん。
209 :
2016/02/04(木) 21:35:19.21 ID:RsO5DH3N
天使クラスを継承するともれなくおちんちんがついてくるぞ
210 :
2016/02/04(木) 23:19:55.12 ID:NzupaiZw
滑ったな
どうすんのこれ

教えてよ
今すぐあんたが教えてよ
211 :
2016/02/04(木) 23:57:46.75 ID:+xOonDYt
この板にいたなら知ってる人も多いだろうけど
このスレタイで建てる前に延々「オブジェクト指向は〜」ってスレ建てては
毎回、議論についてけなくなると「美少女クラスはうんこしない」みたいなこと書いて
荒らし逃げしてんだよこいつは。
んで、またそれ始めたから知ってる人々がサーッと逃げた。
212 :
2016/02/05(金) 01:20:03.95 ID:tLv00hAm
そんな糞みたいな議論に持ってがれる時点でオブジェクト指向って切り口は何か問題があるんだろう。
もう少しバズワードと距離とれるスタンスが必要だったんじゃないのかね。
213 :
2016/02/05(金) 10:03:42.67 ID:BBqIJr5G
継承とオブジェクト指向は直行してるんだけれどね
214 :
2016/02/05(金) 11:35:17.23 ID:oOuE6OCl
美少女の件は、キモオタクラスからは美少女の排便参照不可にすれば解決。
また、キモオタクラスからは他のどの処理を呼んだ場合にもキモ例外が発生することにすれば万全。
215 :
2016/02/05(金) 18:19:15.34 ID:PpryQyj4
>>212
美少女クラスはうんこしない(議論)
216 :
2016/02/05(金) 18:21:10.60 ID:iF+JFr5E
排便量を0に設定すればいいだけだろ
217 :
2016/02/05(金) 19:07:26.01 ID:PpryQyj4
排便量を(オブジェクト指向について僕ができる最大の議論)
218 :
2016/02/06(土) 18:12:26.16 ID:T0MFScki
>>216
排便メソッドの引数にいちいち排便量足すのかよ…
219 :
デフォルトの名無しさん
2016/02/06(土) 22:09:32.02 ID:64Pydz+a
排便量は流石にインスタンス変数で管理するだろ
トイレに行って半分だけ出すとかいうマニアックな機能をつけたいならともかく
220 :
2016/02/07(日) 00:09:19.21 ID:smcac5RE
get_unko を仮想関数にして美少女クラスは 0 を返すようにすればよい。
221 :
デフォルトの名無しさん
2016/02/07(日) 01:39:26.20 ID:R4NvrNxp
便秘のババアもget_unko()が0を返す件
222 :
2016/02/07(日) 11:30:22.21 ID:smcac5RE
では君は美少女に何を返して欲しいのかね?
223 :
2016/02/07(日) 12:40:45.65 ID:Dv+rVFbe
ワンチャン便秘のババアクラスを継承しても美少女クラスは成り立つのではないだろうか
224 :
デフォルトの名無しさん
2016/02/07(日) 13:03:58.71 ID:R4NvrNxp
コーラックが欠かせない美少女w
225 :
2016/02/07(日) 13:35:31.74 ID:fu54F6yL
美少女は便秘じゃない‥
226 :
2016/02/07(日) 15:37:37.70 ID:TdnGwusc
日本の現場は永続化層が糞すぎてオブジェクトにマッピング出来ない
これじゃまともにOOPは出来ないから関数型でやらざるをえないんだね
別に関数型がOOPより優れてるという事ではなかったんだね
227 :
2016/02/07(日) 16:37:33.38 ID:q/UCYgzT
>>226
Do you 意味?
228 :
2016/02/07(日) 17:52:18.95 ID:TdnGwusc
>>227
OOPが愚かなのではなくDB設計者が愚かだったという事
229 :
2016/02/07(日) 18:21:09.45 ID:smcac5RE
永続化層が糞でも関数型なら上手く行くならOOPより優れてるってことになるんでは?
230 :
2016/02/07(日) 18:38:59.78 ID:AJ8T19vA
RDBにオブジェクトをそのまま永続化できないように、
RDBに関数を値として永続化できないんなら同じじゃん
231 :
2016/02/07(日) 19:08:05.31 ID:v13MCL4I
永続化層に日本と海外で差があると?
232 :
2016/02/07(日) 19:24:56.69 ID:TdnGwusc
>>229
うまくいくからやるというかそうせざるをえないからやる
そして一見うまくいっているように見えるが保守性も拡張性も悪い
製造が進むほど歪みが大きくなり破綻に近付く
OOPなら最後まで破綻しないが永続化層はOOPに譲歩して合わせなければならない
しかし日本ではDB中心のアプローチしか出来ない老害が支配的だからそれが出来ない
OOPが優れているのに足を引っ張る老害のせいでOOPはダメだという風評被害を受けている
233 :
デフォルトの名無しさん
2016/02/07(日) 19:35:10.05 ID:R4NvrNxp
>>231
便秘が永続化するババアがいるのは日本だけだぞ?知らんかったんか?
234 :
デフォルトの名無しさん
2016/02/12(金) 08:39:25.91 ID:NbTuOgvl
このスレもついに終わりか
235 :
2016/02/12(金) 11:27:46.75 ID:3qOWj7pc
ウンコしない美少女のせい。
236 :
2016/02/16(火) 21:31:50.31 ID:utvP1D7N
Mutableなオブジェクトは糞
237 :
2016/02/16(火) 21:34:55.97 ID:utvP1D7N
DBには関係代数という理論的バックボーンが存在するからやり方の是非に真偽をつけられるが
Mutableなオブジェクトを許容するオブジェクト指向にはそれが無い
何でもできるかわりに何でもアリすぐる
238 :
2016/02/17(水) 01:36:09.44 ID:quKaVBpr
>>237
日本語
239 :
2016/02/17(水) 02:04:23.05 ID:zhj6/FLZ
美少女のこと語ろうよ。
240 :
2016/02/17(水) 07:33:48.75 ID:UG2kvZqb
>>237は日本語としての意味はとらえやすいが
241 :
2016/02/17(水) 08:52:29.51 ID:zhj6/FLZ
mutable なオブジェクトは糞。
美少女はウンコをしない。

オブジェクトの値が破壊的に変更出来てしまっては、
並列的な処理に容易に分割できないから、
マズイだろってな的話じゃないか?
242 :
2016/02/17(水) 20:12:53.87 ID:sobQnjjW
例えばC++の入門書で必ずと言って良いほど載ってる複素数クラスComplexだけども、
たいてい代入演算詩(かコピーコンストラクタ)とか定義していやがる

藻前はa+2iに3+4iが代入されるのを見たことがあるのかっていうか、
Complexはもはや複素数ではない何か別の異形のものを表してしまっているのではないか、
243 :
2016/02/17(水) 20:14:41.29 ID:sobQnjjW
スマンorz;
誤1:詩
正1:子

誤2: a+2i
正2: 1+2i
244 :
2016/02/17(水) 21:34:07.52 ID:ZZNKbDIQ
1+2i + 3+4i = 4+6i

意外と便利かもしれないww
245 :
2016/02/17(水) 22:13:27.16 ID:BpXyDkaJ
>>242
右辺値に対するoperator = をdeleteすればいいんでしょ?
246 :
2016/02/17(水) 22:14:08.77 ID:xErgmETY
関数型とかいう産廃はイベントがないから使い物にならない
最近の大規模システムはみんなイベントがないと始まらない
247 :
2016/02/18(木) 12:36:55.18 ID:9ZrwZ5jU
破壊的うんこが何だって?
248 :
2016/02/18(木) 15:25:24.63 ID:eyX5WM+u
破壊的激臭は副作用を伴います。
249 :
2016/02/19(金) 14:34:33.73 ID:hr949zjY
ちょっとだけ期待してスレひらいてみたら美少女のうんこ
λ計算すらないのかよ
250 :
デフォルトの名無しさん
2016/02/19(金) 23:39:47.24 ID:Tb8XgjPy
良スレ、age!
251 :
デフォルトの名無しさん
2016/02/20(土) 12:33:38.85 ID:njY71FFO
「美少女はうんこしない」という話を「美少女のうんこ」の話だと理解してしまうようなおっちょこちょいが
オブジェクト指向を理解出来るわけがない
252 :
2016/02/21(日) 00:15:17.53 ID:Xn8BbX8n
unko.suru( bisyoujo );
253 :
2016/02/21(日) 13:27:24.70 ID:82b/sWYC
うんこが美少女にナニをするのか
254 :
2016/03/10(木) 04:27:45.65 ID:+d/NDXY7
依存型とか見てみると結局行き着く先は同じなんだなと思うけどどうよ
255 :
2016/03/11(金) 08:07:36.54 ID:eLvrEEzR
どうしてハスケラってみんなキモいアニオタなの?
256 :
2016/03/11(金) 11:26:20.85 ID:Kt9+s/wp
美少女はウンコするのかしないのか。
それでみんな行き詰まる。
257 :
2016/03/27(日) 21:21:44.90 ID:N7IGtcj3
うんこをした時点で美少女ではない
しかし、うんこを我慢している美少女は萌えるのだ
258 :
デフォルトの名無しさん
2016/03/27(日) 23:58:39.00 ID:9N4B8hjZ
うんこをしないのにうんこを我慢するわけないだろ
絶対にしないから美少女のうんこには底知れぬ価値があるのだ
259 :
2016/03/28(月) 00:59:02.52 ID:oM2XJFW1
スコープだったり変数の生存期間を気にしたりってのは関数型だろうとオブジェクト指向だろうと
同じように気にする。
要はまとめ方ってだけの話。
260 :
2016/03/28(月) 02:53:49.59 ID:T6p957gW
「野球もサッカーも球技だからおなじようなもの!」いただきましたw
261 :
2016/03/28(月) 04:13:13.96 ID:soILvqz+
オブジェクト指向は役に立っている。
関数型言語はトイプログラムしか作れない。
262 :
デフォルトの名無しさん
2016/03/28(月) 10:46:29.30 ID:U1rG/r8A
うんこの話題についてこれない人達が必死ですねw
263 :
2016/03/28(月) 10:53:32.07 ID:Et7Dc3iM
うん、この話についてこれないよ
264 :
デフォルトの名無しさん
2016/03/28(月) 12:55:38.08 ID:IcMNxByb
 僕みたいな芸人とか人前に出る人は、多かれ少なかれちょっとした発言や態度がネットで炎上したり、
罵詈雑言を浴びせられたりします。けれど、僕はそんなのにまったく腹も立たないし、
むしろオブジェクト指向を“カチャカチャ”してる人のほうが可哀想やなあ、と思うんです。

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

はい、ここで問題です。オブジェクト指向でカチャカチャしてる人とそうでない人、どっちが幸せですか? 
そんなの100%、カチャカチャじゃないほうですよ。カチャカチャばっかしてたら不幸になることは、みんなわかってる。
 
「あの人幸せそう、エエ人やわ」と評判の20人のおばはんをモニタリングしてみてください。
ちゃんと挨拶して、言葉遣いも優しくて、お店でもエラそうな態度をとらない、とか共通項があるはずです。
逆に「あの人意地悪いわ、不幸やわ」と言われてる20人のおばはんを見ると、絶対カチャカチャみたいな行動をしてるはずです。
 
オブジェクト指向をカチャカチャして、クラスのインスタントを参照して「やったった感」を持ってるのかも
しれんけど、それでハッピーエンドの人生が待ってると思いますか? それよりも、もっとお友だちと
おしゃべりするとか、勉強するとか自分が幸せになる方法を考えるのがいいんじゃないですか。
 
オブジェクト指向をカチャカチャするのは、自分から不幸になりに行ってるようなものですよ。
あまりに生産性がなさすぎる。それを考えると可哀想やなと思えてくるんです。
僕は「日本は沈没しかけとる。こりゃどエラい時代が来るぞ……」とゾッとしたもんですが、
今まさにそれが当たり前のどエラい時代になりましたね。
265 :
2016/03/28(月) 15:14:15.80 ID:qcCtZJbO
関数型は「このわかりにくい書き方をすればある問題が絶対発生しない!」だからなぁ…
いや、わかりにくいって時点でダメじゃんっつか。
266 :
2016/03/28(月) 17:25:44.03 ID:soILvqz+
>>265
問題が絶対に発生しないなんてあるわけねえだろ
Haskellだってランタイムエラー出るときは出るわ
267 :
2016/03/29(火) 08:53:21.35 ID:69Hzy87b
○○は学習コストがーとかわかりにくいってよく聞くけど、仕事でやってる人なら誰でもすぐわかるような(もしくはわかったつもりになれるような)技術だけ使い続けるより安心じゃね? 覚える価値があるなら特に。
268 :
2016/03/29(火) 12:04:28.51 ID:4NQ/4meq
誰でもわかる

コストがかからない

人気がある

衰退しない
269 :
2016/03/29(火) 12:45:16.60 ID:mGK48Xag
誰でもわかる

バカが混入する

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

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

今、関数型言語界隈がstep 2のど真ん中w
270 :
デフォルトの名無しさん
2016/05/01(日) 09:43:39.37 ID: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.60 ID:Knti35lY
オブジェクト指向って別に世の中の色んな事を記述するためのものじゃないよねw
pcの制御を記述するためのものじゃん

たぶん世の中 = pcって偏狭な人間が混乱してるだけなんじゃない?
272 :
2016/05/11(水) 14:16:15.77 ID:1ZZ8JGEs
手続き型の一部に関数型っぽい書き方するのがカコイイという風潮が強くなってきて
熱心な子が意気込んで本格的なものに手を出してみるがわけわからなくて
酷い目に遭って帰ってきました、という感じじゃない?
273 :
2016/05/11(水) 15:35:01.38 ID:l/Aku55r
誰でもわかる

コストがかからない

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

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

アホが好き勝手に弄った挙げ句トンズラこいた、巨大でインスタンス変数やstatic変数を弄りまくる分岐とループにまみれたクラスの継承元と継承先を飛び回るのは、とてもツラい
何をもって安心すれば良いのかわからない
仕事戻りたくない
276 :
2016/05/11(水) 19:14:51.96 ID:1ZZ8JGEs
名前空間で分けられるOOの方が構造化プログラミングより安全だ
バカを隔離するためにクラスを作ると昔の人は言った
277 :
2016/05/11(水) 19:20:32.44 ID:4+flospS
おお、そのとおりだよw
末端のクラスは融通の効かないバカに作る。
そうすると見通しがいい。
278 :
2016/05/11(水) 19:55:02.71 ID:AR7pBoGw
「言われたことをちゃんとこなすように」が正解。
途中途中で権限委譲しておかないと
上流がすべての決定をしなきゃいけなくなるので破綻する。
279 :
2016/05/11(水) 19:56:37.14 ID:PuRMzRqm
バカは2chに集めて隠蔽
280 :
2016/05/21(土) 10:17:37.52 ID:ikuIjUYo
>>276
藻前の悩みは名前空間の汚染しかないのカヨ…
クラスにして良いのはふるまいに状態を持たせる覚悟のある奴だけ
281 :
2016/05/21(土) 10:19:56.73 ID:ikuIjUYo
もしくはクロージャとかfunctorを作りたいときとかだが
C++で作るクロージャとかfunctorは
クロージャとかfunctorですよみたいな顔して状態を隠し持ちかねないところが恐ろしい…
282 :
デフォルトの名無しさん
2016/05/23(月) 09:30:38.46 ID:KJgou+2q
c++のクロージャってレキシカルスコープ以外の状態を持つのか?
後 functorもクロージャって全然違わない?
283 :
2016/05/23(月) 13:11:00.57 ID:WJyvxaEH
Objectから派生したものは、メンバ変数とメソッド、つまり状態と処理を持つ

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

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

関数の引数として渡せて、戻り値にもできる
284 :
2016/05/23(月) 20:08:36.17 ID:amMcSQyA
>>283
なにその中学生がぐぐりながら書いたような文章
285 :
デフォルトの名無しさん
2016/05/24(火) 22:30:45.96 ID:uzPl1U54
ポケモンってオブジェクト指向が出て来たら
これで効率よくやってそうだよな
286 :
2016/05/24(火) 22:33:07.23 ID:CFKzRNjb
モンスターは物じゃない
物じゃないんだ、友達なんだ
287 :
2016/05/24(火) 22:40:40.32 ID:TKpsNxtt
ゲームはオブジェクト指向が適しているだろうが、
それでもやっぱり思考ロジック部分はオブジェクト指向じゃないさ。
ロジックを固めるフレームワークに設計は適している。
288 :
2016/05/24(火) 23:09:50.90 ID:2+VBUZih
>>287
なにその小学生がヤフりながら書いたような文章
289 :
2016/05/24(火) 23:11:07.38 ID:TKpsNxtt
>>288
こっちへおいでw

オブジェクト指向システムの設計 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1463663267/
290 :
2016/05/24(火) 23:33:41.15 ID:2+VBUZih
100レス位まで読んだけどクッソどうでもいい事をぎゃーぎゃー言い合ってるだけやんけ
291 :
2016/05/25(水) 23:21:16.29 ID:fBBvLnfI
>>287
はっきり言ってゲームにオブジェクト指向なんて適してない
すべてのオブジェクトをエクセルの縦の列に並べて
すべてのパラメータを横の列にすべて書き出す
こういう感じでチェックできるプログラムにしないと完成しない
292 :
2016/05/26(木) 13:53:37.27 ID:gY5ZvMkJ
オブジェクト指向なんて意味ないよな
スーパーマリオもテトリスもプレイに必要なのはエクセル
293 :
2016/05/26(木) 20:55:10.22 ID:cAjDmLh7
ネタとしても面白くないなぁw
オブジェクト指向が使われてるのを
目の前にして適していないと言われてもねw
294 :
デフォルトの名無しさん
2016/05/26(木) 22:03:14.61 ID:cgICe8ci
ここからオブジェクト指向を見た事がない人だけがオブジェクト指向を批判出来るスレになります
295 :
2016/05/26(木) 23:27:22.03 ID:NlrO/xzC
オブジェクト指向は重複したメソッドが発生する。こういうのは無駄。

coffee.owner=human
coffee.drink()
human.drink(coffee)
296 :
2016/05/27(金) 00:14:26.80 ID:miERtZSj
>coffee.owner=human
>coffee.drink()
いやいやいや
297 :
2016/05/27(金) 04:22:09.83 ID:WrCIRuds
オブジェクト指向
「白痴の面倒までみれねーよww」
298 :
2016/05/27(金) 10:57:13.85 ID:q3bsRKFz
オブジェクト指向が面倒を見なくても
白痴はオブジェクトらしきものをプロジェクトに残してくんだ・・・
299 :
2016/05/27(金) 11:13:57.69 ID:y0JFsOhL
すべては名前
きちんとした、名前
名前、名前、名前
名前思考でお願いします
機能と名前が違うのがありすぎ
国語力の欠如した人のプログラムでは
反対語で書く奴もいるし
動詞を、名詞で隠す奴
300 :
2016/05/27(金) 12:19:19.41 ID:bYLZABmN
正しくオブジェクト指向を使ったMacOSXは16年間で11回メジャーアップデートし
オブジェクト差し替えでiOSに派生しiPhoneやiPad、果てはAppleTVにも使われ

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

後者をオブジェクト指向だと思ってる奴はそりゃ全力で否定せざる負えないわな。
301 :
デフォルトの名無しさん
2016/05/27(金) 12:22:01.29 ID:IqC0GNPs
ここオブジェクト指向スレやで
国語力ないんかな
302 :
2016/05/27(金) 12:23:05.27 ID:DRPbKmeh
iOSとかMacのメジャーアップデートって完全に人柱じゃないですかヤダー
303 :
2016/05/27(金) 12:53:43.63 ID:sJ1qkk5q
最近推し激しいが今のiOSっていいのか?
まぁiOS使うくらいならLinux使うけどw
304 :
2016/05/28(土) 21:36:07.37 ID:COiCoXN6
どうなんだろうか。
「お前のは本当のオブジェクト指向じゃない」だとか不毛な論争の火種にしか
なってない気はする。

もうちょっとコードベースのモジュール化やコードの隔離方法なんかを議論した方がよっぽど建設的。
305 :
2016/05/29(日) 05:26:16.06 ID:uH1/jPAH
>>300
> 一方、間違ったオブジェクト指向を使ってしまったWindowsは

最近2週間で一回ぐらいのペースで、開発者版リリースが行われてる。
これはMSアカウントを作るだけで一般の人が入手できる。
これって正しくオブジェクト指向を使ったからだろうね。
306 :
2016/05/29(日) 08:08:38.53 ID:1ogDAOAr
何とも言えんね
ぶっちゃけいまのmsのアップデートはデバッグをユーザに押し付けてるようにしか見えんし
よくわからない用語で煙に巻くって点がオブジェクト指向だね
307 :
2016/05/29(日) 12:54:56.46 ID:uH1/jPAH
オブジェクト指向だから早くリリースしてるんでしょ?w
308 :
2016/05/29(日) 13:01:06.42 ID:1rU4/WXO
既存のクラスはなるべくいじらずそのまま静かに置いておく
オブジェ思考
309 :
2016/05/29(日) 13:23:11.98 ID:1ogDAOAr
私のオブジェクト指向は54万です
310 :
2016/05/29(日) 14:34:58.16 ID:aa6iTjg/
"クラスとは構造体に操作する関数がついたもの"と
"クラスはメッセージコマンドを受けて動く"の違い。
前者はプログラマが陥りがちなタイプ数が少ない暗号みたいなパーツの組み合わせと
責任の所在がわからない動作をぜひ作り込んでくれと言わんばかりのジャンクで
まさにそのとおりのジャンクができた。
311 :
2016/05/29(日) 14:40:26.75 ID:EevS3JTU
>>310
クラスと(そのインスタンスとしての)オブジェクトとの区別がつかない人間は永久にROMってろ
312 :
2016/05/29(日) 15:26:41.75 ID:aa6iTjg/
きみが棲んでるジャンク界隈がそういう仕様なのは知ってるけど
こっちはクラスにメッセージ送るとクラスがインスタンス作るんだ。
うん。
313 :
デフォルトの名無しさん
2016/05/29(日) 15:50:36.54 ID:abg0RIhz
>>312
クラスと(そのインスタンスとしての)オブジェクトとの区別がつかない人間は永久にROMってろ
314 :
2016/05/29(日) 16:59:56.20 ID:aa6iTjg/
高度すぎたか。
315 :
2016/05/29(日) 17:04:53.73 ID:9gAtgMOC
いちいち()で囲まなくてもよくない?
無駄な仕事多くしてそう。(どうでもいいけど)
316 :
2016/05/29(日) 21:48:27.53 ID:T+KHRUkH
クラス厨は害悪
317 :
デフォルトの名無しさん
2016/07/08(金) 22:17:20.19 ID:gy2KRr8C
高度すぎたかwwwwwwうけるwww
318 :
2016/07/08(金) 22:29:11.47 ID:zZ/OP7I+
半年ORMれ
319 :
2016/07/09(土) 11:06:02.42 ID:lXMMLrdi
オブジェクト指向とかクラスが分からないのは多分メモリ周りのことが全然わからないからなんだろうな。
アセンブラからやれとは言わんが、メモリアロケータくらい自作したらオブジェクト指向がいかに理に叶ったものかわかってくるんだけど。
320 :
2016/07/09(土) 11:22:11.07 ID:3DBY5ZwO
メモリアロケータを自作しないと理解できないってのもなぁ(苦笑)
321 :
2016/07/09(土) 12:11:02.75 ID:vM1Dv6Aj
オブジェクト指向がわからない人は関数型を勉強してないんだろうな
手続き型はオブジェクト指向のメリットを潰してしまうから手続き型の書き方しか知らないとオブジェクト指向は身に付かない
322 :
2016/07/09(土) 12:19:20.59 ID:afhBOa0Z
データのカプセル化ができてれば手続き型でもオブジェクト指向でも関数型でもいい気がするが
323 :
デフォルトの名無しさん
2016/07/09(土) 12:19:29.29 ID:EzNW6797
分からない人がいて欲しいという強い願望w
324 :
2016/07/09(土) 13:53:33.65 ID:dEWSYkKq
オブジェクト指向つっても当初の「継承で差分プログラミングうまー」
みたいなのは否定されてきたからな。

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

インターフェイス以外の継承は最小限にというのを教えないと。
でも未だに入門書レベルだと著者が勘違いしている。
325 :
2016/07/09(土) 18:59:46.91 ID:akOZxrcr
>>324
かといって、というか
継承ってのがどんなものなのか「だけ」を説明するのなら
やっぱ犬猫でもいいんでねえのって俺は今は思う

継承をどう使って設計していくかってのはまた先の話
親、子A、子Bという三者の関係「だけ」示すのが動物犬猫
326 :
2016/07/09(土) 19:23:57.17 ID:dEWSYkKq
>>325
例自体は反対しないよ。
でもそれで継承というものがどういうものかは分かっても、
継承がどういうときに使うべき物なのかは分からない。
そこまで教えてる本ってあまりないね。
327 :
2016/07/10(日) 18:09:32.57 ID:RTWM7o1I
(HP)をプロパティで持った「キャラクター」クラスを作って
それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
これを再利用して、「武闘家」クラスを作れば
おなじ"たたかう"メソッドで武闘家はてつのつめで戦うようにできる。
さらには(MP)と"まほう"メソッドを追加で「魔法使い」クラスが…

ってこの辺りで便利さがわかると同時に
(MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって
継承の不便さが浮き彫りになってくるという。
全部独立パーツでそれを必要に応じて束ねて使っていればもっと取り回しが楽だったり
328 :
2016/07/10(日) 20:28:28.05 ID:4zLRjbrA
実装の再利用は継承でやるよりtraitが便利
smalltalkで発表されて、PHPに輸入されて、後は知らないが
329 :
2016/07/10(日) 22:16:26.35 ID:/17c9zmN
Scalaとかの静的型言語がただのmixinをあえてtraitsと呼ぶのは誤解を招くよなぁ…
330 :
2016/07/10(日) 22:21:00.81 ID:SLnFWOAS
>>327
> それを継承した「戦士」クラスは"たたかう"、"ぼうぎょ"、"にげる"などのメソッドを持つ
> これを再利用して、「武闘家」クラスを作れば

武闘家は戦士を継承していません。
331 :
2016/07/10(日) 22:46:02.92 ID:YDU79Arx
そもそもオブジェクトの粒度が高すぎんだよ
アビリティクラス的なものを作るべき
332 :
2016/07/10(日) 23:04:09.88 ID:tx16mOUk
> ってこの辺りで便利さがわかると同時に
> (MP)プロパティや"まほう"メソッドをどこにつけるかで混乱が始まって

全然混乱しないなw

どこにつけるかなんてシステム次第だが
ドラクエ方式であればMPプロパティはキャラクタークラスで
魔法メソッドなんていうのは、特技メソッドの表示名の違いでしか無い。
333 :
2016/07/11(月) 08:10:49.21 ID:BGpqEWk7
継承ベースだと
キャラクター>戦士>武闘家というクラス階層で
90年代のバカみたいな継承信奉してると武闘家の後ろとかに
"魔法使い"作って泥沼に嵌まるんだよな。
継承=オブジェクト指向だから。
334 :
2016/07/11(月) 08:24:29.03 ID:DT6nTI14
継承を使いこなせないのは要するに馬鹿なんだよ
オブジェクト指向も関係なくプログラミングの基礎が出来てないから
335 :
2016/07/11(月) 09:34:50.03 ID:c813o9It
>>333
> キャラクター>戦士>武闘家というクラス階層で
それはどう考えても間違った継承だろ。

継承信奉以前の問題で、継承関係にないものを
継承しているのは、お前が馬鹿だからってだけなんだが。
336 :
2016/07/11(月) 10:06:35.54 ID:BGpqEWk7
「よくバカな奴が"延々と"を"永遠と"って書いてたりするよねー」
「え、おまえ"延々と"を"永遠と"って書いてんの!?バカじゃね!
俺なんか絶対そんな間違いしないね!!おまえバカだろ!バーカwww」
「えっ?」
337 :
デフォルトの名無しさん
2016/07/11(月) 11:14:13.38 ID:v8BjKTdy
戸惑いのバカwww
338 :
2016/07/11(月) 14:14:51.31 ID:BGpqEWk7
えっ?
339 :
2016/07/11(月) 21:41:33.01 ID:K+QqD/bm
>>326
そやねぇ
あまりないというか、見たことが無いw

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

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

困って、考えて、本読むという順じゃないと多分ダメ
…多分だけど
340 :
デフォルトの名無しさん
2016/07/11(月) 22:00:34.80 ID:DT6nTI14
目的に合わせて正しく抽象化出来れば継承関係は自然に導かれるはず
継承だけに着目して教える/教わるという考えがそもそもおかしい
341 :
2016/07/11(月) 22:37:59.77 ID:NMj8cyvT
概念の継承関係とコードの継承関係を同じ目線で見ると失敗する
342 :
デフォルトの名無しさん
2016/07/11(月) 22:42:17.81 ID:DT6nTI14
>>341
それ抽象化が間違ってるからやw
343 :
2016/07/12(火) 00:05:30.28 ID:dw2VnrEM
>>342
過度な期待期に入った新人君かな
344 :
デフォルトの名無しさん
2016/07/12(火) 07:21:41.32 ID:jrBRhCE1
自分のモデリングの間違いを言語機能のせいにする
な?要するに馬鹿なんだよ
345 :
2016/07/12(火) 08:27:37.68 ID:URFMxuYq
オブジェクト指向もずいぶん枯れたわけだし、アンチパターンの確認から入るってのも悪くはない。
346 :
2016/07/12(火) 09:41:37.70 ID:Q/mNeBI3
正しく抽象化できれば正しくできる、
って意味のないこと言ってどうすんの?

その正しく抽象化する方法が問題なんでしょ?
347 :
2016/07/12(火) 09:54:02.01 ID:DvYXCZnM
>>328
その後は、rubyにパチモンが作られて「Rubyの偉大な発明」の仲間入りしたのでは?
348 :
2016/07/12(火) 10:24:32.15 ID:QmnH/+e2
たとえば魔法使いと魔法という概念が"新たに生まれた"場合
それは魔法を使える魔法使いのみが使うから魔法使いクラスの固有プロパティなのか。
それとも、使えないだけですべてのキャラクターが持つ基礎パラメータなのか。
すべての基底クラスにMPデータフィールドを追加していいのか。
運を消費して奇跡を起こす聖者、MPやHPを消費して治療を行う僧侶などが
あたらしく出てきた時はどこにパラメータをつけて相互管理すればいいのか。

現実でその時は"ただしい"と思った抽象化が根底から揺さぶられることはいくらでもあって
(固定価格に追加される消費税、新たに追加される福祉控除項目、すべてを一元化しようというマイナンバー…)
まず、そういう認識すら持たずに「ちゃんとちゅうしょうかしないからだよ
ぼくならなんでもただしくちゅうしょうかできるからきみたちよりえらいのさ!」とか
うそぶいている時点で君はいま指をさして静かに嗤われてるのを自覚した方がいい。
349 :
デフォルトの名無しさん
2016/07/12(火) 12:19:52.07 ID:4cCOY98n
>>348
要するに正しく抽象化モデリング出来てないだけだなw
お前が馬鹿な理由にオブジェクト指向も継承も全く関係ないわw
350 :
2016/07/12(火) 12:27:09.89 ID: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.38 ID:+8oNQ71Y
振る舞いの抽象化なら型クラスやインターフェイスを使えばいいし、実装の再利用ならtraitのような仕組みを使えばいい
継承による型の階層構造なんて邪魔にしかならんわ
352 :
2016/07/12(火) 17:45:58.73 ID:h4Vj1dwQ
モデリングに間違いがなくかつモデルが未来永劫変化しないならID:4cC坊やの言い分は正しいね
そんな世界がやってくるといいね
353 :
2016/07/12(火) 18:38:57.22 ID:J7TxVIFH
とりあえず>>348で言われてることを具体的にイメージできないぐらい"疎い"ってのだけはわかるよね…
多くのクラスに関わるモデリングを変えなきゃいけないぐらい大きな変更の例が列挙されていて
オブジェクト指向の黎明期と違って、オブジェクト指向があたりまえの空気になった現代だからこそ
強力な束縛を持つ継承がシステム組み替えの際の足かせになってきてるって話の流れにまったくついていけてない。
354 :
デフォルトの名無しさん
2016/07/12(火) 18:53:29.94 ID:jrBRhCE1
お前らのは抽象化でなく、ただのぼんやりしたイメージ
いわば妄想プログラミングだなw
お前らみたいな馬鹿がまともに設計出来ないから
言語が馬鹿を縛れるような進化が求められてるだけなんだぜ
ダメなのは言語ではないお前ら自身だ
355 :
2016/07/12(火) 20:11:55.18 ID:IS6BTglq
キッズは夢を見るものさ
356 :
2016/07/12(火) 20:31:52.34 ID:Vv72dLZO
継承にしろオブジェクト指向にしろ
コードを簡潔にしたり、仕様変更に強くするために利用すべき技術だから
「猫と犬は哺乳類クラスを継承する、なぜなら猫も犬も哺乳類だから」ってのは
熟練したプログラマの発想とはだいぶ離れているんだよね
熟練したプログラマは書かなければならないコードが頭に浮かんでいて
それを何処に書くかという整理整頓の意味で継承などの技術を使っているわけで
結局OOは整理整頓術で、どう整理したらプログラミングの効率が上がるかというだけの話
それ以上の意味はない
が、整理整頓は非常に奥が深い
357 :
2016/07/12(火) 23:27:20.00 ID:4M8hLvVe
そもそも哺乳類と言うのが最初にあって
そこから猫や犬が生まれたわけじゃないからな。

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

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

で実際のプログラミングでは哺乳類がどうとかいう話とは関係なく、
継承構造は役に立つもの
358 :
2016/07/12(火) 23:28:32.23 ID:4M8hLvVe
>>352
> モデリングに間違いがなくかつモデルが未来永劫変化しないなら

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

リファクタリングは汚いコードを修正することじゃなくて
過去の時点では正しかった設計を、
今の時点の変化に合わせて設計を変えることだから。
359 :
2016/07/13(水) 08:17:59.46 ID:+CQztjRc
継承はそういう時に身動き取れなくなるから困る
360 :
2016/07/13(水) 09:38:03.87 ID:NLZRxEVY
359 名前:デフォルトの名無しさん[sage] 投稿日:2016/07/13(水) 08:17:59.46 ID:+CQztjRc
継承はそういう時に身動き取れなくなるから困る
361 :
2016/07/13(水) 12:39:18.51 ID:Fh2kjKhX
大事な事だから2回言いました
362 :
2016/07/14(木) 19:03:55.13 ID:sG4kt79u
割とマジで「オブジェクト指向って継承って奴だろ」な人で
言われてることがまったくわからなくてパニクってるんじゃないかと。
363 :
2016/07/14(木) 20:00:26.88 ID:05a8wJuJ
原始時代じゃあるまいしそんなプログラマがいるのか?
にわかに信じがたいな
364 :
2016/07/14(木) 22:29:42.85 ID:mVH/XKPM
美少女が人間クラスから継承できない問題は
どうなったんだ?
それでオブジェクト指向は破綻したときいたが。
365 :
2016/07/14(木) 23:30:26.34 ID:0cl6EhrX
ぱっと思いつくだけでも

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

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

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

などなど
なんとでもなるやろ
366 :
2016/07/15(金) 05:19:16.25 ID:Md4pEzwy
UnkoのサブクラスとしてOhgonクラスを実装するんや!
367 :
デフォルトの名無しさん
2016/07/15(金) 12:49:22.15 ID:L1jCNFuA
美少女はウンコをしない
この「しない」という所が美しいんじゃないか
汚れなき乙女を全うする意志の問題だ
これが「出来ない」という物理的構造に由来する問題に成り下がってしまったら
何の味わいもなくなるだろ
チンコ勃たんわ
368 :
2016/07/15(金) 14:40:06.76 ID:d/Zl1fgq
頭の悪い人の悲しいところは
頭の悪い冗談を好んで言い続けるということだ
飽きもせずに繰り返し繰り返し何度も何度も…
369 :
デフォルトの名無しさん
2016/07/15(金) 22:04:56.17 ID:iR/HdeCl
これは頭の良い冗談に期待w
370 :
2016/07/15(金) 22:47:24.35 ID:ibKxDQPd
美少年にクラスチェンジすることで破綻せずにハッテン
371 :
2016/07/15(金) 23:49:57.52 ID:80GKY2p2
リフレクションで解体して色々いじりたい
372 :
2016/07/16(土) 01:53:47.85 ID:Bfovl8qZ
面白くないことに気づこうね
373 :
2016/07/16(土) 02:59:56.46 ID:0ciAe/St
というか>>211で書かれてるとおりをまたワンパターンで始めただけだしな。
374 :
デフォルトの名無しさん
2016/07/16(土) 07:28:07.42 ID:CNSBQzp5
美少女ウンコ問題は高度すぎて解決の糸口すら見つからないもんな
ついていけない奴の気持ちもわかる
375 :
2016/07/16(土) 09:09:49.16 ID:DegzgE4N
ちょっとしたネタ書き込みにすら
知能やセンスがもろ出しになっちゃうから悲しいね

>>372
それ言っちゃうと今度は意地になってレスし続ける可能性
376 :
2016/07/16(土) 09:38:23.65 ID:D3kHuod4
>>372
面白くない→顔が白くない→色白でない→実は美少女ではない→ウンコしても問題ない

なるほど要件の再定義によって解決か
377 :
2016/07/16(土) 10:06:22.50 ID:BhIXbiPC
なんでよ褐色美少女最高じゃん
378 :
2016/07/16(土) 10:11:41.75 ID:6YOlPtSF
ワンパターンっすなぁ
379 :
デフォルトの名無しさん
2016/07/16(土) 12:26:01.17 ID:3oB/Pjks
解決しとらんのにワンパターンもくそもないだろ
根気のない奴だなあ
380 :
2016/07/16(土) 20:05:26.83 ID:kkC3KqZT
解決できると思ってるのが間違いだと気付くといいよ

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

そういう情報を一切俎上に出さずにAはBの子クラスであるべきか否かなんて話すのは無意味
そういう文脈をソースに組み込む必要があるかもまず考えないといけない
381 :
デフォルトの名無しさん
2016/07/16(土) 21:15:33.39 ID:CNSBQzp5
なるほど
現状の研究成果に比べると一風変わった意見だが私は興味深く聞かせてもらったよ
つまり君はウンコをしない美少女が人間クラスから派生されるべきコンテキストについて
もっと掘り下げた議論をすべきだと言うのだな
ところで君はそういう文脈をソースに組みこむ必要があるかについては
どんな考えを持っているのかね?
382 :
デフォルトの名無しさん
2016/07/16(土) 21:41:47.94 ID:LbU9Boej
ユーザーはうんこ機能なんか求めちゃいない。
383 :
2016/07/17(日) 01:46:14.62 ID:MIDkP6ou
生成するUnkoオブジェクトのtasteフィールドが最大値になるだけ
384 :
2016/07/17(日) 05:00:03.09 ID:nDXHZDmA
>>380
いやねーだろw その手のシステムで種ごとにクラスを分けるわけがない。
全部同じクラスだろ。
385 :
2016/07/17(日) 10:38:54.12 ID:libZCVLZ
まあなんでも抽象化すればいいってもんではないわな。
物質は究極的にはクォークのセットだからって、そのまま実装したらそりゃ破綻するだろうし。
386 :
デフォルトの名無しさん
2016/07/17(日) 12:43:31.14 ID:gClFyV8u
君それは細分化やないか
美少女のウンコふりかけ食わしたろか
387 :
2016/07/17(日) 13:29:48.60 ID:okE8dWNU
同じ型のインスタンスの振る舞いをポリモーフィズムさせるのは、

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

などの方法がある
388 :
2016/07/17(日) 13:57:59.74 ID:PHnZw+de
ウンコって言いたい年頃なんだろうな
389 :
2016/07/17(日) 15:27:54.18 ID:+aWd02nI
>>384
データはDB管理かもしれないしDBに沿った構成になるかもしれない
UIで必要であれば 380 の構成もありえるし
だから 380 は文脈と言ってるんだろうに
390 :
デフォルトの名無しさん
2016/07/17(日) 15:59:55.36 ID:gClFyV8u
どんな文脈やねんw
肉屋の仕入れアプリでブタにダンスでもさせる気なんかw
そんなら俺はウンコを我慢する美少女の方がええわwww
何でも文脈言えばええっちゅーもんちゃうでホンマ
391 :
2016/07/17(日) 16:05:40.68 ID:q7clyz/N
>>389
いや、当然RDBMSでデータ管理しているという前提だが?
392 :
2016/07/17(日) 21:43:01.45 ID:SWVEU9WP
クソスレじゃねーか!
393 :
2016/07/20(水) 23:08:50.86 ID:0oomM0jq
計算式が面倒になったら
またどうせオブジェクト指向になるんだろ
394 :
2016/07/20(水) 23:42:38.15 ID:E+SEwayU
>>380
> 一体どうしてと思ったらジビエと畜産肉で分けてたとか、食肉加工業者の仕入れ管理ソフトだったらあり得るよ

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

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

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

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

むしろ、アルゴリズム解析みたいなのを開発環境がやって
こうすると副作用が最小になるっぽいですよ?って
AIがサジェスチョンするようになんじゃね?つか。
396 :
2016/07/21(木) 12:07:59.69 ID:gJ3egAPE
それはどうかわからんよ
もともと機械の都合で生まれた静的型が
実は人間にも優しいってことで大人気だし
本来静的型じゃなくても動く筈の動的型言語も
どんどん静的型の機能を取り入れていくのが今のトレンドでしょ

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

副作用ありの静的型言語が一番機械の都合に合っていて
その金字塔がC言語であり、今でも使われ続けている
主にローレベルなことやOSの開発やドライバの開発などに
使われているのは、それだけ機械の都合にあっているから
昔の言語なのに破たんせずに使われ続けているのは
それだけコンピュータの動作原理を素直に表現していて
流行り廃りというものと無縁だから
397 :
2016/07/21(木) 16:36:54.23 ID:KvWRwuEL
Cで書いたコードが速く動くようにCPUやOSが設計されているという面も
あるからぬ…だからって新世代の言語に合わせてCPUやOSを作り直すか?
といわれたらそんなことは起こりっこないと断言できるが
398 :
デフォルトの名無しさん
2016/07/21(木) 17:56:06.90 ID:9dMGMxaj
おまいさんそれは逆ですぜ。
Cがアセンブラに馴染み易く出来てるんですぜ。
でも本来はintelの系統じゃ無くて、
モートローラとかミニコンから派生した石に馴染み易く出来てるんですがね。
まあ、Cが最初からintelの石用に作ってたら、
もう少し違った構文になってたかもね。
399 :
デフォルトの名無しさん
2016/07/21(木) 18:08:41.00 ID:9dMGMxaj
アセンブラやってた連中が、構造化プログラミングを提唱して、
プログラムを小さな塊の組み合わせで作る様になったんで、
同時期に条文分岐やサブルーチンの扱いをマクロ処理を被せて
読み易くするのが流行ったんだよ。
それをもっと書き易くして行って出て来たのがコンパイラ言語
いわゆる高級言語だけど、簡単なアセンブラへの置き換えしかしてなかった。
今ではそこから更にそれら高級言語を分かり易く記述出来る高次な高級言語が流行ってるけどね。
400 :
デフォルトの名無しさん
2016/07/21(木) 18:19:01.28 ID:9dMGMxaj
例えば、hoge+とかやれば自動的にインクリメントしてくれる仕様だって、そういうアセンブラ命令があったからなんだぜ。
401 :
2016/07/21(木) 18:38:56.73 ID:fNq3MD0e
>>397
>Cで書いたコードが速く動くようにCPUやOSが設計されている
何を根拠に?
402 :
2016/07/21(木) 19:51:04.04 ID:zfBmPUKU
>>399
時系列がぐちゃぐちゃじゃね?
最初の高級言語と呼べるものはFortranだけど、
数式を人間フレンドリーな形で記述できるのが売りだった。
Fortranはアセンブラの簡単な置き換えレベルではないでしょ。

構造化プログラミングはALGOLからだろうけど、
Fortranより後だし、Cのようなレベルに達するのはもっと先。
403 :
2016/07/21(木) 20:06:28.29 ID:ZXk7cAfY
歴史しらないバカばっかw
404 :
2016/07/21(木) 20:28:04.90 ID:IpsfD7Z7
自信を持って声を大きくして叫び続ければやがてそれが歴史となる
405 :
2016/07/21(木) 20:37:00.07 ID:m+nIkrs4
後の人々はそれをこう呼んだ、すなわち黒歴史と……
406 :
2016/07/21(木) 21:20:03.86 ID:gJ3egAPE
Cの何がすごいって、メモリに対する考え方がシンプルで凄い
構造体のメンバは単なる先頭からのオフセットだし
配列の添え字も先頭からのオフセットでしかない
しかも配列とポインタはある種の互換性がある
だから何だかよくわからないメモリブロックを
構造体にキャストしてアクセスできたり
同様に単なるメモリブロックを配列としてアクセスできたりする
メモリの扱いがとにかくシンプルでありつつ強力なアクセス方法があり応用が利く
こういうことができる言語はあまりない
C++ですらvtableが入ってたらもうオフセットずれるし
407 :
2016/07/21(木) 21:42:38.85 ID:vaQfL518
>>406
言語の実装がシンプルなのと、その言語を
使ってアプリを実装するっていうのは別の話で
なんでも一つの機能で出来てしまう言語っていうのは、
冗長で意味代わりにくいコードになりがちなんだよ。

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

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

条件判定命令と条件ジャンプ命令さえあれば十分であっても
そこからforパターンやwhileパターンを見つけ、専用の単語に
割り当てることで可読性が高くなる。
408 :
2016/07/21(木) 22:34:35.81 ID:9dMGMxaj
だからCだけが生き残ったんだろ?
大衆プログラマが望んだ形で変化した結果だからな。
409 :
2016/07/21(木) 23:16:46.30 ID:vaQfL518
生き残ったっていうのは古い言語とくらべての話?
確かにFortlanとかPascalは消えた。
多くの優れた言語が生まれている中、今でも通用するのは
C言語ぐらいだと思うが。
410 :
2016/07/21(木) 23:17:21.89 ID:zfBmPUKU
どちらも消えてねーだろw
411 :
2016/07/21(木) 23:21:30.21 ID:vaQfL518
>>410
第三者の人が検証できるランキングとかある?
そりゃどこか目につかないところではあるかもしれないが、
例えばその言語で仕事したいと思ったとき
探せ出せないような言語は消えたと思っていいだろう。
412 :
2016/07/21(木) 23:39:22.80 ID:zfBmPUKU
>>411
Intel Visual Fortran とかググッてみ。
リアルタイムで今も製品出てるのを消えたとは言わないでしょ。
413 :
2016/07/21(木) 23:45:13.87 ID:vaQfL518
>>408
ということで、C以外も生き残ってるんだが?w
414 :
2016/07/21(木) 23:52:22.14 ID:dNMEb7c5
問題は暗黙に行う言語の動きに対してどれだけ
コンセンサスがとりやすいかってことだ。
c++ はもうその意味でどっか行ってる。
415 :
2016/07/22(金) 01:30:33.86 ID:znBq8w6k
>>407
俺の言いたいことはそういうことじゃなくて
ローレベルな世界ではその言語固有のオブジェクトになってない
単なるメモリブロック、データ、信号を扱わなきゃならない場面が多いんだよ
それはファイルから読み込まれるかもしれないし
ネットワーク越しにやってくるかもしれないし
ディバイスとのやり取りかもしれないし
ま、要するに単なるデータ
Cはメモリモデルがシンプルだからこういった単なるメモリブロックを扱うのに
長けているんだよ
構造体にキャストするだけでそのまま扱えるから
今でもC言語が現場で活躍しているのはこれができるから
もしこういったことが出来なかったとしたら、C言語なんかとっくに滅んでいたに違いない
メモリブロックをキャストして構造体や配列としてアクセスできないとしたら
そんなC言語に価値なんかあるか?
その一点がすごいんだよ、マジセンスある、もしくは運が良かった
416 :
2016/07/22(金) 01:46:19.31 ID:znBq8w6k
そして多くの言語が見落としがちな部分でもあったんだよ
オブジェクトにしなきゃならないっつってvtable持たせたり
動的にしなきゃならないと、メンバをオフセットではなくハッシュにしたり
どんどん賢い機能を盛り込んでさ
その点C言語の構造体や配列はフラットでむちゃくちゃシンプルな作り
適当なメモリブロックをキャストしても何の問題も起きない
仕様もシンプルで分かりきってる
417 :
2016/07/22(金) 02:02:58.97 ID:znBq8w6k
別に必ずしも偉い機能を盛り込むのがダメと言っているわけじゃないよ
ただ、Cが何故か生き残っていて今でも使われ続けている原因はソレということ
C言語の用途と、うまい具合にマッチしてて、いい感じに生き残っている
418 :
2016/07/22(金) 03:13:29.97 ID:7iYsigKa
だからなんだよ?
419 :
2016/07/22(金) 07:29:28.61 ID:cZVknNWP
構造体の先頭メンバ以外のオフセットは規定されていない
まぁ、オフセットなのでメンバアクセスでどうとでもなるわけで
構造体が定義されたままメモリ上に存在していると考えているアホ
一般的なコンパイラなら定義通りだろうけど規定されていない
規定されていない規定されていない
420 :
2016/07/22(金) 08:09:11.54 ID:+awE6fq0
構造体のメンバ間のパディングは未規定だけど、オフセットが未規定って言うのは
順番も入れ替わるって言ってるの?
421 :
デフォルトの名無しさん
2016/07/22(金) 09:35:29.96 ID:+Z+w/IAX
簡単に入れ替わるさ。
わざわざ入れ替えないでねと指定するレベル
422 :
2016/07/22(金) 10:31:03.00 ID:znBq8w6k
構造体のメンバの順番が入れ替わらないのは仕様で決まっているよ
決まってないのは間に入る詰め物だけ
http://portable-c.jugem.jp/?eid=17
しかし、詰め物をどうするか、指定できるコンパイラがほとんどだから
実質的に詰め物も問題にならない
C言語プログラマーは自分の使っているコンパイラの仕様ぐらい分かって使っているからね
問題になるとすればエンディアンぐらい
423 :
デフォルトの名無しさん
2016/07/22(金) 12:25:18.70 ID:TIRA9iEO
JIS規格だろそれ。。。
424 :
デフォルトの名無しさん
2016/07/22(金) 13:24:25.19 ID:+Z+w/IAX
intのサイズがアーキ依存だから通信に構造体は使うなってのが常識だけどな。
425 :
デフォルトの名無しさん
2016/07/22(金) 13:25:41.52 ID:+Z+w/IAX
ネイティヴアメリカンの件もあるしな。
426 :
2016/07/22(金) 19:29:05.65 ID:5OURMCtc
cはメモリは意識するがレジスタは隠蔽するって落とし所がよかったんじゃない。
427 :
2016/07/22(金) 19:41:14.28 ID:jv7yTJni
Cはパーサが複雑なのとゼロコストで導入できる便利機能が無いのを除けば悪くはない
428 :
2016/07/22(金) 22:14:58.88 ID:Oi2oQZIZ
cの最大の失敗は波カッコ
ブロックのスコープがパイソン風だったら人類は1世紀以上先の進んでいた
429 :
2016/07/23(土) 00:49:12.76 ID:KFsxU+fY
代入演算子=と比較演算子==だけは許されざるよ。
つうか、IDEのサジェスチョン機能実装前の
"タイプ数が減る云々"な言語はすべて滅ぶべし。
430 :
2016/07/23(土) 01:22:33.59 ID:tWjtYIW6
C言語は特徴ある機能で生き残ることができた。
だけそのその特徴ある機能がなかったら生き残れないのか?というと
そうではない。現にその特徴ある機能がない言語ばかりだからだ。

ここから言えることは、なにもない言語は消え行く定めだが、
C言語の機能がなくとも、それに上回る機能があれば生き残るということだ。
431 :
2016/07/23(土) 01:27:50.24 ID:tWjtYIW6
>>429
IDEを使うことでタイプ数が減る機能はどうでもいいんだよね。

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

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

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

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

これは型が書かれていないコードから、型を解析する
作業よりも読む文字数は少なくなる。
432 :
2016/07/23(土) 18:21:41.45 ID:6yKmk1QH
代入演算子は要らなかった
433 :
2016/07/23(土) 23:13:50.14 ID:7iusE9pH
代入は文であって値を持つべきでないと?
434 :
デフォルトの名無しさん
2016/07/23(土) 23:53:23.87 ID:zx6tBrAB
愚か者めが
435 :
2016/07/24(日) 07:03:52.43 ID:L1GkLU8N
Cが生まれた時代はな
シンタクスハイライトどころか下手すると
スクリーンエディタ(キリッ カットアンドペースト(キリッ
すら高価な機能だったんやで
436 :
デフォルトの名無しさん
2016/07/26(火) 15:33:00.26 ID:ka5+GTWz
テキストエディタが数万円してからな
437 :
2016/07/26(火) 16:33:02.33 ID:dc6Ut+6F
Cが生まれた頃にはまだコピー&ペーストはなかったぞ。
438 :
2016/07/26(火) 16:39:32.99 ID:qFADw225
最初のクリップボードはAltoかな
Cが1972年でAltoが1973年
439 :
2016/07/26(火) 16:42:33.79 ID:P0pX8+u1
>>430
で、その、この先生きのこるのはどの言語!
440 :
2016/07/26(火) 17:29:32.48 ID:XfeIwbpB
アセンブラ C Fortran Lisp の古代言語
Javascript COBOL Python
HTML PHP はなんだかんだ言って生き残るんだろな〜

あとは Java がどうなるかな
441 :
2016/07/26(火) 21:54:04.74 ID:8mWO7mKy
言語じゃないというのはナンセンスか
442 :
2016/07/26(火) 22:19:28.08 ID:3gO7Ljql
お前ら、テーマに戻れや。
なぜオブジェクト指向は愚かな考えなんだ?
443 :
デフォルトの名無しさん
2016/07/26(火) 22:55:12.03 ID:wvFbwXsy
愚かな設計が蔓延してるってことだな
444 :
デフォルトの名無しさん
2016/07/26(火) 22:55:59.68 ID:wvFbwXsy
>>4
これがすべてじゃないの?
445 :
デフォルトの名無しさん
2016/07/26(火) 23:00:24.73 ID:wvFbwXsy
初期設計を少しでも間違えたり手抜きしたら
そのシステムの成長絶望的になり死ぬ
446 :
2016/07/27(水) 02:09:24.84 ID:gQfYvWZ4
>>444
そして>>41-42で完全に解説完了
ジョークとしてわざとオブジェクト指向として間違ったプログラム例だしてるってのに
「この通りオブジェクト指向は直感に反して〜」じゃねぇっつのw
447 :
2016/07/27(水) 02:12:13.92 ID:gQfYvWZ4
>>440
Javaは普及してるから残るだろうなぁ
なんか、いつものベストじゃないけど普及したから
ベターとして残るというプログラム史のいつもの展開というか。
448 :
2016/07/27(水) 06:54:54.29 ID:cUWSkWnI
問題はそういうジョークを本気にする人が多すぎるってことだろうに。
つまりオブジェクト指向ってのは一般にコンセンサスをとりずらい概念なんだよ。
449 :
2016/07/27(水) 06:58:14.97 ID:LCC7iz/I
おまえ等の好きそうなネタ見つけた

オブジェクト指向で料理を例える場合,chicken.cut()かchef.cut()か
https://teratail.com/questions/41875
450 :
2016/07/27(水) 07:29:08.70 ID:mL4CmQKe
>>446
コーヒーの例は単純明快だからいいけど、美少女は実際に正しく設計できるやつが日本に何人いるかってレベルだろうな
451 :
2016/07/27(水) 07:30:19.55 ID:+Qq3g4cQ
>>448
これをジョークだと思って実戦に挑む奴がデスマーチを引き起こす
452 :
2016/07/27(水) 07:32:08.18 ID:iBdKVqyS
基底に近いほど修正しづらいのは事実
453 :
デフォルトの名無しさん
2016/07/27(水) 07:33:05.82 ID:8lCNqFHq
>>451
ほんとこれ
454 :
2016/07/27(水) 09:54:15.05 ID:8yC4YC1p
>>449
tokage.cut()
455 :
デフォルトの名無しさん
2016/07/27(水) 12:23:59.26 ID:mW7SlT40
くだらん与太話はこれくらいにしてそろそろ全力でウンコ美少女問題に取り組むか
456 :
デフォルトの名無しさん
2016/07/27(水) 17:21:14.58 ID:8Owc4Qqf
ウンコしない美少女は偶像
つまり人間からの派生ではない
457 :
2016/07/27(水) 17:58:49.99 ID:CvwlEFOq
なんか、いっつも同じレベルの書き込みするから
自演になってないって自覚しとる?きみ。
458 :
デフォルトの名無しさん
2016/07/27(水) 19:55:41.64 ID:9bIrtjQt
ユーザーはうんこなんて機能は求めて無いから削除しろよと
459 :
2016/07/27(水) 20:16:04.55 ID:YbwWr11d
人間がウンコするのは、
ユーザーが求めているからなのか?
460 :
デフォルトの名無しさん
2016/07/27(水) 20:21:12.98 ID:9bIrtjQt
ソフトの機能に不要な要素まで組み入れても誰も買わないだろ。
現実の要素を完全に網羅する必要は無いから
461 :
2016/07/27(水) 21:23:16.38 ID:dkELqw5/
それは当たり前のことではあるな
必要な要素だけ実装すればよいからな
Humanクラスがどういった要素を持つかは案件によるし
もし人の持つすべての機能をHumanクラスに実装できるっていうんなら
そのHumanクラスにプログラムも書いてもらえばよい

よって現実の人間がうんこをするからと言って
必ずしもHumanクラスにうんこをする機能が必要かどうかはわからないし
必要な案件に出会ってから美少女クラスのうんこの扱いについて考えればよい
462 :
2016/07/27(水) 21:50:52.30 ID:eu5RKOJ4
要件で一言も触れてないのに「はぁ?○○はあって当然だろ」とか言い出す顧客しかいないから
想像できるものは全て詰め込んでおく必要がある。
ウンコだろうとゲロだろうと例外はない。
463 :
2016/07/27(水) 22:27:39.20 ID:YbwWr11d
肝心なことを決めずに作り込んでいく。
美少女クラスのスーパークラスは人間クラスである。
排便メソッドは関係ないからそれでいい。
だが、ある時ユーザーからの要望で人間クラスに排便メソッドを作った。
人間だもの、当たり前だ。
それでいいと思った。その時がくるまでは。
ある時私は気がついた。
これだと美少女が排便すると www
464 :
デフォルトの名無しさん
2016/07/27(水) 22:41:58.99 ID:60oYSks+
このスレ的にはgo言語とかD言語のダックタイピングってどうなん?
465 :
2016/07/27(水) 22:47:49.85 ID:rlINsgdh
ダックタイピング

由来

アヒルのの鳴きマネをする人間はアヒルに違いない
466 :
デフォルトの名無しさん
2016/07/28(木) 00:19:19.54 ID:c5ty+8F5
ダッチワイフィング

由来

オランダの人妻はエロいに違いない
467 :
デフォルトの名無しさん
2016/07/28(木) 00:47:19.73 ID:6VZFO4sX
オブジェクト指向は幻想
468 :
デフォルトの名無しさん
2016/07/28(木) 00:48:34.40 ID:/rI5OmsP
COBOLからJavaへの移行で「実際に」成功した案件は存在しない
469 :
デフォルトの名無しさん
2016/07/28(木) 00:49:15.93 ID:LhM4XtYR
細胞から実装しろ
470 :
デフォルトの名無しさん
2016/07/28(木) 00:49:41.59 ID:OYshXAPi
元素から実装しろ
471 :
2016/07/28(木) 01:51:28.53 ID:y7xhJAs5
>>468
COBOLって単なる言語じゃなくて運用まで含めたシステムの総称だからな。かなうわけがない
とは言え、高賃金のCOBOLプログラマーもいずれ死に絶えるわけでなんとかしないといけないんだけどさ
Adaなんか勉強して損した
472 :
デフォルトの名無しさん
2016/07/29(金) 12:00:06.26 ID:TRgFQe5b
Ocamlならあるいは
473 :
2016/07/29(金) 18:48:09.16 ID:POEPtDrt
ないない
そもそもCが小文字の時点で語る資格なし
474 :
デフォルトの名無しさん
2016/07/30(土) 00:08:52.44 ID:lNYXBi4+
ならScalaでスイス銀行の例もあるし?
475 :
2016/07/30(土) 00:35:24.99 ID:gkAo/Cig
具体的に
476 :
2016/07/30(土) 15:22:29.13 ID:OSfj7rnr
オブジェクト指向を考え出した人間もオブジェクト指向の解釈を誤っていたのではないか
クラスというのは人間が直感的に思い描く世界の事物をプログラムコードにマップする手段ではなくて、
プロセスという大きなチューリングマシンの中の小さなチューリングマシンを記述する手段にすぎなかった
(チューリング完全性の利用例の一つだった

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

状態(mutableなデータ)を含むから関数型プログラミングとは似て非なるものだし、
数学的にカタをつけるにはチューリングマシンの一変種で無限長の磁気テープをクラスで小分けにしたもの、
としか言い様が無い
477 :
2016/07/30(土) 15:46:36.80 ID:OSfj7rnr
こう考えると継承のしくみを使ったプログラミングが
ごく一部のデザインパターンにおいてしか成功しないことも理解できる
継承というしくみのは人間が「こうだったらイイなあ…」と思い描いて作っただけで、
>>476な解釈からは必然性が出てこない
つまり継承というしくみは論理的妥当性を欠いており、
継承を下手に使ったらあちこちで矛盾が生じて話が発散していく傾向なのも仕方が無い
478 :
2016/07/30(土) 18:44:13.74 ID:TLvR+07H
だいたいプログラミング業界って、

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

の繰り返しだからな。継承しかり例外しかり。
最近はテンプレート使いすぎなんじゃねーのって思うけど。
479 :
2016/07/30(土) 19:01:15.21 ID:TM2kAcv9
> 継承しかり例外しかり。
継承も例外も極力使わないようにしましょうなんて
誰も言ってないが?

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

っていう結論ならばいつもそうなっている。
継承しかり例外しかり。
480 :
2016/07/30(土) 19:38:58.24 ID:XUUv9y4D
結局、人間クラスと美少女クラスは
どうすればいいんだ?
481 :
2016/07/30(土) 20:02:32.96 ID:TLvR+07H
>>479
正しく使おうってのは常に真だから内容が無いのと同じだな。
できるだけ使わないようにって風潮はある。程度の差はあれgotoとかと同じ。
482 :
2016/07/30(土) 20:08:02.92 ID:OEu/5F3U
javaはオラクルがVMを提供しなくなったら
廃れるだろ。
483 :
2016/07/30(土) 21:52:18.63 ID:NYI5chEQ
>>479
結局、言語の問題よりも馬鹿を入れない事のが重要ってことだろ。
そういう意味じゃ linus のやり方は正しいってことになる。
484 :
2016/07/30(土) 22:13:41.04 ID:TM2kAcv9
>>481
> できるだけ使わないようにって風潮はある。
無いよそんなのwww

アルアル言っていても、
嘘がホントになったりしないアルよ〜w
485 :
2016/07/30(土) 22:18:10.45 ID:OSfj7rnr
(定義が論理的に妥当でなかったりあいまいだったりするとお議論が紛糾する例
486 :
2016/07/30(土) 22:23:44.57 ID:3WJAVcau
多少コピペが多くなっても継承をむやみに使ってはいけない場面ってのは想定しなきゃなぁ
487 :
2016/07/30(土) 22:38:52.82 ID:TM2kAcv9
なんで継承をやめたらコピペが多くなるのかそれがわからんw

正しく継承使うといういうのは、
継承以外の方法を使うべきときに、違う方法を使うという意味であって、
ならばその違う方法で、コピペを回避すれば良いんだよ。
488 :
2016/07/30(土) 22:44:09.77 ID:XUUv9y4D
委譲を使えばいいんだろ。
肛門クラスを作って、
人間クラスと美少女クラスのプロパティに肛門インスタンスを持てばいいんだ。
排便できる肛門と出来ない肛門と。
489 :
デフォルトの名無しさん
2016/07/30(土) 23:06:52.83 ID:FiK/AfbE
コーデングテクニックでごまかすのはアカンね
そーゆーことするから所謂ひとつのスパゲッテイー的ソースコードが出来上がるんや
デザインの問題はデザインで解決出来な一生炎上商法プログラマーのまんまやで
490 :
2016/07/30(土) 23:38:21.39 ID:3WJAVcau
>>487
ミックスインの手法が確立されてないってことは、継承が害悪になる場面ってのはあるんだよ。

そういう場合は、下に書かれてる通り、コンポーネント的な設計が必要。
そういう時に、コンストラクタでコピペが必要ってこと。
491 :
2016/07/30(土) 23:41:35.20 ID:3WJAVcau
そうするとインタフェースの定義が必要になってくるから、結局継承が楽だし、よほどのことじゃなければそれで済ませるんだけどね
492 :
2016/07/31(日) 00:01:52.81 ID:VGavY/X3
if文ですべて解決できるんじゃね
493 :
2016/07/31(日) 00:35:50.52 ID:UuqrLdJE
だから、委譲というか、
デリゲート使えっていうか。
494 :
2016/07/31(日) 01:44:59.39 ID:LD4Pss8J
ほんと最近、is-a関係、has-a関係っていうの
軽視されてるよな。

is-aのときに継承すれば良いんだって
昔から言われてるんだが。
これは古い概念じゃないぞw
495 :
2016/07/31(日) 03:56:26.93 ID:Wl4/o5Bb
フリーザは美少女クラスのis-a関係
496 :
2016/07/31(日) 09:04:47.96 ID:xuMLlix3
>>494
is-a関係は一般に存在しない
例外なのは同値関係と包含関係が数学的に定義できて無矛盾性が担保された
(=直接証明されたか、より一般的な体系の無矛盾性に帰着できる)ケースだけだが
そんなのはスゲーまれ
いっぱいあると感じるのは錯覚

不用意にis-a関係を導入することでクラス分けにあいまいさが紛れ込み、
プログラムの設計とか簡単に壊滅する
497 :
2016/07/31(日) 09:09:00.42 ID:xuMLlix3
その点ha-a関係はやりやすいなぜなら単なる集約であって分類が絡まないから
has-a関係の導入自体が矛盾を生じることは無いからだ
498 :
2016/07/31(日) 09:36:24.74 ID:tLh0Iyun
is-a関係だと思っているものは全てhas-aとしても実装できる。

概念系統が複数ある場合、is-aでは多重継承もしくは、
全ての組み合わせの派生クラスを定義することが必要だが、
has-aではそういう問題は無く柔軟に設計できる。
499 :
デフォルトの名無しさん
2016/07/31(日) 09:41:31.16 ID:/E3bqgob
OO使わない場合に
フラグとかカウンタとかステータスってのをどう管理するのかを
単刀直入に知りたい。
関数型なんかでもこの辺がよくわからない
(消せるはずはないから何か別の概念などで整理・管理されるんだとは思うけど)
500 :
2016/07/31(日) 09:46:59.05 ID:tLh0Iyun
>>499
普通の構造体でいいのでは?(Cでいうところの)
501 :
2016/07/31(日) 09:59:49.33 ID:p/Oh4nGe
>>499
そこでクロージャですよ
502 :
2016/07/31(日) 10:00:24.80 ID:P4D/j0eN
is-a だったらliskov置換原則の方が理解し易いし、コード書くときの指針になる。
503 :
2016/07/31(日) 10:09:28.04 ID:xuMLlix3
ちなステータスというのは大概I/Oを通じて外界と繋がっている事物の結果を意味し、
実時間軸上でうつろうもの(mutableなブツ)なので厳密には関数型プログラミングに存在し得ない概念

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

例えばHDDのエラーステータスとか、昨日のステータスに対し今日のステータスが変化した、と捉えるのではなしに、
「HDDの昨日のステータス」を返す関数と、ステータスの適切な処理に対応する何がしかを返す関数とから
「HDDの今日のステータス」に対する処理に対応する何がしかを返す関数を生成する
ことでHDDの今日のステータスを処理する
504 :
2016/07/31(日) 11:53:00.79 ID:LD4Pss8J
>>494
女は一般に存在しない
いっぱいあると感じるのは錯覚

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

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

ちな、有限集合に関しては無矛盾性は常に証明できるから別に
 女クラス←妻クラス
でも
 妻クラス←女クラス
でも良いが、有限のケースしか想定しないんならswitch文で良いやという話で
オブジェクト指向の出る必然性がかなり減る
あくまで無限集合としてのクラスXを今数学的に正しく定義付けできるか?(X=妻 or 女 or so on)というのが問題
506 :
2016/07/31(日) 15:57:24.63 ID:Wl4/o5Bb
is-aかどうかなんて抽象的すぎて判断の材料になんないよな。

何を持ってしてis-aとするかが大事なんだけど、そこをきちんと答えられる人は少ない。
507 :
2016/07/31(日) 15:58:19.37 ID:JthY0EmQ
>>505
そりゃ妻のような一時的な属性に過ぎないものををクラス化するのがそもそも間違ってる
同性婚以前に結婚離婚で既に破綻してるじゃないか
例が悪いので説明になってない、やり直し
508 :
2016/07/31(日) 16:07:11.65 ID:Wl4/o5Bb
>>507
男も改造すれば女になりうるから、男クラスのインスタンスを作ると、参照を維持したまま女クラスに変身できない。

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

契約をしてないのにis-aなんて言いきれる訳ない。
509 :
デフォルトの名無しさん
2016/07/31(日) 16:07:23.65 ID:kxVM21o1
妻とか女とか、単なる属性をクラスにするからワケが分からなくなる。
510 :
2016/07/31(日) 16:27:16.51 ID:iFqDH3lg
いいから、肛門クラスを作って
デリケートしろ!
511 :
2016/07/31(日) 16:35:53.61 ID:Wl4/o5Bb
口に肛門つけてください。
しゃべれるしうんこできるし便利だと思うんです。
512 :
2016/07/31(日) 21:22:59.29 ID:XDiDpvFC
話についていけない子が
必死で面白レスしようとするのが悲痛
人間の悲しみが透けて見える
513 :
2016/08/01(月) 00:44:08.60 ID:E1waX2Jm
>>505
> 例えば妻クラスを女クラスの派生クラスにしたりしたら、同姓婚が合法化されたときプログラムは作り直しになるであろう

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

妻をクラスするって発想がそもそも
キチガイじみてる。
514 :
2016/08/01(月) 00:46:25.46 ID:E1waX2Jm
普通は性別は属性だよなw

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

そのうち佐藤クラスを作るとか言いそうだwwww
515 :
2016/08/01(月) 00:52:22.69 ID:E1waX2Jm
is-a関係っていうのは必要条件であって十分条件じゃないんだがw
is-aになっていれば必ず継承関係にあるってことじゃない。
継承しようと思ったとき、is-a関係を満たしていなければいけないって話だ。
516 :
2016/08/01(月) 01:01:45.57 ID:8BzY1j1Y
オブジェクト指向ってどこで間違ったんだろう
途中までは良い線行ってたと思うんだけど、どこからか使いものにならなくなったよね
517 :
2016/08/01(月) 01:04:20.06 ID:E1waX2Jm
オブジェクト指向が使われてない
フレームワークなんて無いんだが?

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

まあ「使い物にならなくなった」と言い続けることで
他の人に事実だと錯覚させようとする手段ニダ?w
518 :
2016/08/01(月) 01:06:05.40 ID:fJ4xvUon
だから、継承捨てて委譲を使えっての!
519 :
2016/08/01(月) 01:41:20.92 ID:C6PCKyxq
>>517 本当にオブジェクト指向が必要だから使っているのか、
抽象化の手段がオブジェクト指向しか無いから使わざるをえないのか

昨今の言語なら継承以外の方法で抽象化とか再利用とかできたりする
OOは本当に最小限にして、late bindingやメッセージパッシングの妙を際立たせるとより効果的
Real World OCamlだとヘテロな型を持つ木構造を探索するのに使ってたりしたな
520 :
2016/08/01(月) 01:41:37.76 ID:E1waX2Jm
継承捨てて委譲を使えっていうのは
マイクロソフト用語でコンポーネント指向っていうんだが、
これを意図的に取り入れたのが2000年前後に使われていたVB6なんだよな。

そのVB6も.NETになってから継承をサポートしたし、
コンポーネント指向だけではだめだということだろう。
521 :
2016/08/01(月) 01:43:39.68 ID:E1waX2Jm
>>519
オブジェクト指向は必要だから使うんじゃなくて
いくつもある手段の中から一番適切だから使うんだよ。

お前が例示する使い方は、単にオブジェクト指向じゃないほうが
適切だってだけ。そしてオブジェクト指向が適切だから
ほとんどのフレームワークでオブジェクト指向が使われている。
他に代替技術があるにもかかわらずだ。
522 :
2016/08/01(月) 02:44:42.52 ID:6ITirnPy
>>513
だからその設計はねーってこと言ってるんだろ。

日本語読めないの?
523 :
2016/08/01(月) 03:09:46.97 ID:FN/zaXKS
>>516
>どこからか使いものにならなくなったよね
C++の奇形めいたオブジェクト指向は衰退して
別方面で進化してきたObjecive-CとJavaが本流として
いま街でみかける全てのスマホアプリを支えてるけどな。
524 :
2016/08/01(月) 03:31:24.59 ID:cj2k2Gm/
今はObjrctive-CじゃなくてSwiftじゃね?
525 :
2016/08/01(月) 04:29:03.24 ID:C6PCKyxq
>>521 適切だから使うというなら何故デザインパターンなんて出てきたのか?
デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、
他の手段が使える言語なら間違いなく採用しない

他にもExpression ProblemをJavaで解決しているのとOCamlで解決しているのを比較してみるといい
OOだと論文書けるくらいには面倒な方法があるけど、OCamlのVariant使った方法と比べて圧倒的に可読性と簡潔さに劣っている
526 :
2016/08/01(月) 06:27:47.87 ID:c5RAbFYM
JavaはC++よりレガシーな言語になってしまったが…
527 :
2016/08/01(月) 09:36:21.09 ID:E1waX2Jm
>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、

違う。OO便利だなーって使っているうちに
設計のアルゴリズムが確立されていって、
それをまとめたのがデザパタ
528 :
デフォルトの名無しさん
2016/08/01(月) 10:06:54.28 ID:Q0J3uZmP
いや、デザパタはOOと関係無いから。
関係あるのはOOPの方
529 :
デフォルトの名無しさん
2016/08/01(月) 10:50:43.99 ID: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.11 ID:IZIdUKpU
ここまでLSPの話題なし
531 :
2016/08/01(月) 17:10:00.57 ID:GD9lEFl6
>>525
> デザパタの大部分がOOに適さない問題を無理矢理OOで解決するためのもので、

おしい。
デザパタはJavaやC++に適さない問題を無理やりJavaやC++で解決するためのもので、
SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。
532 :
2016/08/01(月) 18:06:20.18 ID:99zq/hjd
smalltalk だと、人間クラスと美少女クラスの問題は
どう解決するの?
533 :
2016/08/01(月) 20:14:16.64 ID: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.26 ID:E1waX2Jm
>>531
> SmalltalkやSelfで書けば圧倒的に簡潔かつ明瞭に記述できる。

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

考えるのが面倒なら俺が出題しても良い?
Singletonは個人的につまらないので
そうだね、DecoratorはSmalltalkやSelfで書いたらどうなる?
535 :
2016/08/02(火) 00:07:55.94 ID:6KXXOitA
>>534
試しにウィキペの Decorator パターン
https://ja.m.wikipedia.org/wiki/Decorator_パターン

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

けど、圧倒的に簡潔になった感じはしないな
>>531 ならどんなふうに書く?
536 :
デフォルトの名無しさん
2016/08/02(火) 00:11:39.50 ID:xLK/JaT/
シングルトンなんて言語に最初から組み込んでおけ(Scala信者並感)
537 :
2016/08/02(火) 00:40:29.48 ID:Aujbapgh
>>532
そもそもきみは継承関係=オブジェクト指向でしか発想してないから
クソ邪魔くさい継承取っ払ってモジュール自由に組み外しできるタイプの
オブジェクト指向の話にまったくついてこれてないからずっと嗤われてるわけで。
538 :
2016/08/02(火) 00:44:39.63 ID:flPsn8Jo
>>535
別にDecoratorじゃなくていいんだけどね。
圧倒的に簡潔かつ明瞭に記述できるっていってるから
そのコードを見たいだけ。
539 :
2016/08/02(火) 05:55:14.53 ID:wOSsX6OQ
デコレータパターンはそもそも静的に型がつけられることからくるクラス階層への制約を誤魔化すための小手先の技術でしかない。
型が完全に動的なSmalltalkやSelfではデコレータパターン自体が不要。
540 :
2016/08/02(火) 10:26:45.37 ID:KjBiyzhL
型が動的だと>>535の例のようなコードはどうなるの?
541 :
2016/08/02(火) 10:29:15.63 ID:YMxtX/GD
そそ
例えばアセンブリや機械語は制約がないからデコレータパターンとか要らないでしょ
それと同じでSmalltalkには何も必要ないよ
542 :
2016/08/02(火) 13:11:20.31 ID:KCBRtMku
全然違うのだが。デコレータもSmallTalkも理解してないとみた。
543 :
2016/08/02(火) 13:40:40.79 ID:C0zGukRC
アセンブリというかC言語だとこんな感じか。出来るには出来るけどちょっとねえ
http://codepad.org/XgRtJlQb
544 :
2016/08/02(火) 15:34:07.46 ID:lROFhaXh
なにも知らなくても語れる。
それが Smalltalk のいいところらしい。
人間の悲しさがほの見えるな・・・
545 :
2016/08/02(火) 16:01:47.58 ID:wOSsX6OQ
>>540
Smalltalkはよくわからないけど、
DoublePriceとかWholesalePriceとかいうクラスを増やすより、
元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。
SmalltalkのPluggableMVCとかもクロージャで柔軟な変換を実装しているし。
546 :
2016/08/02(火) 16:53:22.92 ID:I0xQlCpI
>>545
> 元値から実売価格を計算するクロージャを持たせるんじゃないかなあ。

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

ついでにRuby版も書いてみた
http://ideone.com/WW8gva
547 :
2016/08/02(火) 17:16:35.65 ID:I0xQlCpI
>>543
これだと Java 版でいうところの getValue() する前に
毎回、二倍にして 利益80乗せて、また二倍にしてもう一度 利益200乗せて…とかって
いちいち書かないと 840を返せないから、結果は合っているけど要求仕様を満たしていないような気がする
548 :
2016/08/02(火) 18:25:05.78 ID:lROFhaXh
いつになったら、
人間クラスと美少女クラスの問題に辿りつけるのかね?
悲しいの〜。
549 :
2016/08/02(火) 20:24:15.92 ID:wOSsX6OQ
>>548
とっくに解けてるじゃん
ばか?
550 :
2016/08/02(火) 20:30:55.27 ID:lROFhaXh
どう解けてるんだよ。
人間の肛門と天使の肛門にコンポーネントするのか?
551 :
デフォルトの名無しさん
2016/08/02(火) 20:41:47.88 ID:UCo4tbLK
用途も分からず闇雲に現実世界をクラス化して行ったら、一生掛かっても終わらないから無駄な事すんな。
552 :
2016/08/02(火) 20:42:03.85 ID:9rM4/wP9
美少女は偶像であり人間ではない
553 :
2016/08/02(火) 20:57:34.64 ID:flPsn8Jo
もうそろそろいいかな?

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

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

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

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

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

SmallTalkであってもデコレーターパターンっていうのは存在する。
だからこそSmallTalkでデコレータパターンをシンプルに書くことができる!と
主張できる。
554 :
2016/08/02(火) 21:16:53.04 ID:LOKS06K+
>>553
なんでみんなより二歩も三歩も手前な意見を
そんな長文で書き込めるの?
555 :
2016/08/02(火) 21:20:29.76 ID:flPsn8Jo
>>554
言いたいことはそれだけかw
556 :
2016/08/02(火) 21:22:05.73 ID:LOKS06K+
ごめんね
557 :
2016/08/02(火) 21:24:18.11 ID:e9gYPknx
Smalltalk の t を大文字で書くやつは無知か知ったかぶり
558 :
2016/08/02(火) 21:24:35.32 ID:lROFhaXh
実は誰も Smalltalk なんて知らない www
559 :
2016/08/02(火) 21:27:22.36 ID:flPsn8Jo
反論あるなら待ってるよw
560 :
2016/08/02(火) 21:32:29.72 ID:LOKS06K+
>>557
ワロタw
561 :
デフォルトの名無しさん
2016/08/02(火) 21:38:39.55 ID:UCo4tbLK
言語は関係無いと言う内容の話への反論が、言語名のミスプリントの指摘とか、レベル低過ぎだろw
小学生の負け惜しみかよw
562 :
2016/08/02(火) 21:39:26.48 ID:flPsn8Jo
>>561
え?それ反論だと思ってたの?
反論はまだ一つも来てませんよw
563 :
デフォルトの名無しさん
2016/08/02(火) 21:40:28.47 ID:UCo4tbLK
うゎw
保育園だなここはw
564 :
2016/08/02(火) 21:47:57.27 ID:6KXXOitA
>>561
「プリント」とかまさに小並
565 :
2016/08/02(火) 22:08:58.16 ID:e9gYPknx
>>553
>>538で「見たいだけ」って言ってるところをみると、これは反語で
>>546みたいに簡潔なのが出てくるとはこの時点では考えてなかったんじゃない?
だからデザパタは用語で実装じゃない、言語は関係ないって趣旨替えしたように読むのは穿ちすぎ?
566 :
2016/08/02(火) 22:14:56.76 ID:flPsn8Jo
>>565
いやw
最初からこのために、
デコレータパターンをSmallTalkで書いたらどうなるの?って
話題を振って会話をさせたんだよ。

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

もし実装が決まっているものであれば、
SmallTalkでデコレータパターンを実装すれば
シンプルな形で実装できるんだっていう話はでてこない。
567 :
2016/08/02(火) 22:27:10.71 ID:KCBRtMku
そもそもC++でデコレーターでもそんな難しくないでしょw
シングルトンの方がよっぽどややこしい。
568 :
2016/08/02(火) 22:30:18.68 ID:flPsn8Jo
「シングルトン」だけで話が通じる所がデザインパターンの
便利なところだね。

さてシングルトンにもいろんな実装があるけど、
DIコンテナを使ってシングルトンに見せるっていう方法もあるよね。
これだと普通にクラスを作るだけで良くなる。
569 :
2016/08/02(火) 22:34:48.24 ID:qU1dasmj
兄さん、そこでPythonですよ
ですしおすし
570 :
2016/08/02(火) 23:26:19.20 ID:QqIbwu4d
Java8ならもっとHENTAIなコードが書けるぞ
http://ideone.com/DbIiD0
571 :
2016/08/02(火) 23:41:10.66 ID:6KXXOitA
572 :
2016/08/02(火) 23:59:46.02 ID:lROFhaXh
Smalltalk の最大の魅力は、
それが雑談に過ぎないということである。
by アラン・ケイ
573 :
2016/08/03(水) 00:45:18.40 ID: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.97 ID:nNt8IZmK
>>566
まるでちがう。>>546はデコレータパターンじゃない。
Javaではデコレータパターンを使う問題を
デコレータパターンを使わずにより簡潔に記述した例。
575 :
2016/08/03(水) 12:45:10.82 ID:XBNCNfrP
>>539
型が動的だと>>535の例のようなコードはどうなるの?
576 :
2016/08/03(水) 15:55:24.00 ID:8J75MUHP
SmallTalkとか
577 :
2016/08/03(水) 17:09:10.94 ID:R0iPm5qU
関数型インターフェースの方が簡潔になる
http://ideone.com/6MAwKM

>>573
setValue(100)してからgetValueしたら100返らなきゃバグってるだろ
setOriginalValueとかに修正するところだな
578 :
2016/08/03(水) 18:07:08.01 ID:8J75MUHP
Wikipediaにある
> Decorator パターンの方針は、既存のオブジェクトを新しい Decorator オブジェクトでラップすることである。
がわかってない奴がいるな
579 :
2016/08/03(水) 18:17:54.35 ID:qhbdc1zB
デザパタの目的とされがちであるが
常に失敗しているのが語彙の共有

いつでもつねに認識がバラバラw
580 :
2016/08/03(水) 18:21:38.71 ID:8J75MUHP
>>579
ごく一部の人間が正しく理解できてないだけで、
> いつでもつねに認識がバラバラw
は言い過ぎ
581 :
2016/08/03(水) 18:45:37.19 ID:9oohU77o
>>577
> 関数型インターフェースの方が簡潔になる

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

http://ideone.com/RZHQ7P
582 :
2016/08/03(水) 19:57:46.85 ID:N9MmOijn
Smalltalkに意味なんかないよ
登場してから30年とか40年とか経ってるのに
誰も現場で使ってない言語だからね
40年という歳月は結論を出すのに十分な時間だと思うよ
これから先もずっと使われないだろう
こんな言語についてあれこれ考えるのは時間の無駄だよ
御幣を恐れずに言うと、Smalltalkは間違っている、机上の空論
本当によくできていたなら、もうちょっとぐらい使われていてもおかしくない
少なくともRuby程度ぐらいには使われてないと話にならない
Smalltalkは実用にならないスジの悪い言語だということ
583 :
デフォルトの名無しさん
2016/08/03(水) 20:22:04.47 ID:M+rE/wd/
Smalltalkは言語だけじゃダメで。
windows上では使い物にならないから仕方無い。
584 :
デフォルトの名無しさん
2016/08/03(水) 20:23:22.86 ID:M+rE/wd/
要するに、windows自体がオブジェクト指向に向いてないんだよ。
585 :
2016/08/03(水) 20:29:26.00 ID:1jcdD/Xi
結論。
誰も Smalltalk なんて知らない www
586 :
2016/08/03(水) 20:32:04.15 ID:N9MmOijn
それは関係ない
なぜなら概念上の問題より運用上の問題のほうが大事だから
いくら概念的な素晴らしさを語ったところで
まともに運用できないならゴミ
使えない
587 :
2016/08/03(水) 20:45:27.46 ID:YtpqVXv4
>>574
> Javaではデコレータパターンを使う問題を
> デコレータパターンを使わずにより簡潔に記述した例。

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

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

Javaならこういう実装でやるが、他の言語では
その実装方法が違うだけ。
588 :
2016/08/03(水) 21:24:23.35 ID:TE6NppPB
>>582
まあ仮にSmalltalkが本当に誰も使ってなくて
処理系も失われたり、あるいは as-is で放置された言語だとしたら
そんなものに意味がないって意見は全くもって正しいよね
589 :
2016/08/03(水) 21:37:23.40 ID:46yxFVyN
シングルトンやアイテレーターなどは時代が変わっても重要だろうけど、
デコレーターは継承関係への依存度が高いから微妙だな。
590 :
2016/08/03(水) 22:46:55.08 ID:PwtoF+FA
>>583
Smalltalkは独自のGUIもそうだけれども、もうひとつ、通常のセルフホスティング
(自身で自身を記述)にとどまらず、処理系を構成する実行時オブジェクト群を
仮想イメージと呼ばれる、ある種のオブジェクトストアに永続化して次回起動時も
継続利用する運用スタイルも毛嫌いされるよね。個人的には示唆に富んでいて好きなんだけど
591 :
2016/08/04(木) 00:17:31.35 ID:iDV12Qqy
>>587
いや?
クロージャで実装しているのだから、デコレータパターンによる実装ではないよ。
コード読めない子?
592 :
2016/08/04(木) 00:19:01.73 ID:jTAWnEUa
> クロージャで実装しているのだから、

クロージャで "何を" 実装しているの?
593 :
2016/08/04(木) 00:24:24.39 ID:ClPuKc3B
デコレータパターンを実装できてはいないんだよw

これでわかった?w
594 :
2016/08/04(木) 00:25:35.63 ID:jTAWnEUa
いや、何を実装したのかを聞いたんだが?
実装したものは何?
595 :
2016/08/04(木) 00:30:18.03 ID:ynLXOlFE
>>590
あのあたりはむしろメモリや記憶装置いくらでも使える現代向けというか
過去にオブジェクト指向の要素をちょっとだけ輸入してみた中途半端なオブジェクト指向言語が次々出ては滅びの興亡続けてたのは
"コンパイル後のサイズが大きいじゃないか"とかいまじゃヘソが茶を沸かすような理由がメインなわけだし。
596 :
2016/08/04(木) 00:31:24.04 ID:w6fnMNqO
デコレータパターンと同等の機能をクロージャで実装した
じゃね?

同等の機能を持った違った実装があるのは当たり前じゃね?
デコレータパターンと同じような機能をもたらすけど
デコレータパターンじゃない実装は普通にあり得るんじゃね?
597 :
2016/08/04(木) 00:34:51.00 ID:jTAWnEUa
>>595
パターンは機能じゃないよ。設計。
デコレータパターンという設計

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

Javaだったらクラスで実装し
クロージャーでも実装できるってだけの話。
598 :
2016/08/04(木) 00:36:04.52 ID: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.96 ID:w6fnMNqO
>パターンは機能じゃないよ。設計。

それで、その設計パターンとは合致しないけど
同等の機能や目的を満たす他の設計はあり得る
ってことでしょ?
俺の言ってることと一緒だね
600 :
2016/08/04(木) 00:44:00.26 ID:fESKb5E9
ID:jTAWnEUaを教育してあげる義務は我々には無い
601 :
2016/08/04(木) 00:45:06.02 ID:jTAWnEUa
>>599
わざわざ複雑にしないでいいよw

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

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

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

そのデコレーターパターンを
クロージャーで実装したんでしょ?
そういえば良いんだよ。
602 :
2016/08/04(木) 00:48:34.94 ID:jTAWnEUa
>>600
じゃあ一緒に勉強していきましょう(笑)

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

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

あなたは何で勉強していますか?
603 :
2016/08/04(木) 01:13:23.05 ID:w6fnMNqO
話をややこしくしているのはあなたです

>パターンは機能じゃないよ。設計。

↑これは君が言ったことだよね

その上で俺は、同等の機能を持った、違ったデザインなんじゃね?って言ってるわけ

機能が同じであっても、同じデザインパターンとは限らない
何故なら、デザインパターンは機能じゃないから、設計のパターンだから
↑君の言ってることと全く同じだよね

だから同じ機能だけど、違った設計パターンであり
同じデザインパターンに属さない設計は有る
ということを君は認めているということ
604 :
2016/08/04(木) 01:43:58.02 ID:w6fnMNqO
デザインパターンは機能では無く、よくある設計パターンに名前を付けたもの
ってのは正に君が自分で言ったことであって
それは俺も了承している

だから同じ機能であっても、それだけで同じデザインパターンとは言えないよね
と俺は言ってるわけ
なぜならデザインパターンは機能では無いから(君の言ったことだよね)

そもそも俺とお前とのやり取りに、何のとどこおりも無い
俺は、>>596で同等の機能を別の設計で実装したんじゃないか、と言い
お前は>>597でデザインパターンの分類は機能で決まるものではなく設計で決まる、と言っている
合わせると、「同等の機能であっても同じデザインパターンであるとは限らない、設計で決まる」
という結論が得られる
605 :
2016/08/04(木) 01:56:34.90 ID:tMKvO+zV
デコレータパターンの解決できる問題領域は他の(オブジェクト指向でない)方法でもっと簡潔に書ける、のはいいだろうか。

これと同じことが他のデザインパターンでもできるんじゃね?という主張だったと思うんだが。

Singletonは言語によって容易に達成できるものもあればそうでない言語もあるが、そう難しくは無いはず。
OCamlだったらmutable valueを持ったモジュール使えば同等のことが実現できる。
Adapterパターンも変更できない物がオブジェクトだったら関数1つで済むし、
モジュールだったらファンクタ使えば良い。

これを続けていけばデザインパターンがOOPの表現力の低さを解決する妥協案である、と示せる気がするが、
逆にOOPでデザパタ使うのが一番簡潔になる問題を探す方が難しいかもね。
606 :
2016/08/04(木) 03:16:53.36 ID:jTAWnEUa
やっぱりデザインパターンを
実装パターンと勘違いしているとしか思えないな。

まず大前提としてデザインパターンに言語は関係ない。
だから言語は関係なく設計の話、
オブジェクト指向での設計の話を考える。

そうするとそこにデザインパターンが出てくる
ここまでで言語の話は出てこないから
当然実装の話もでてこないんだよ。
607 :
2016/08/04(木) 03:18:24.28 ID:jTAWnEUa
OOPじゃなくてC言語でも当てはまる話だよね。
シングルトンやデコレータなどは。

C言語であってもオブジェクト指向で設計していれば
自然とデザインパターンは出てくる。
608 :
2016/08/04(木) 06:27:25.67 ID:iDV12Qqy
>>605
だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
JavaやC++の表現力で解決する妥協案を集めたものなの。

JavaやC++の表現能力や抽象度が低いことを勝手にOOPの表現能力の低さにすり替えるな。
609 :
2016/08/04(木) 09:14:32.03 ID:jTAWnEUa
>>608
それはオレオレ定義ですよね。
610 :
2016/08/04(木) 09:31:36.26 ID:0aO0sFCL
デザパタの実装はいろいろあっていいし、言語によって簡単に書けたりそもそも必要なかったりもする。


「オブジェクト指向における再利用のためのデザインパターン」←GoFのデザパタ提唱本ね。念のため。

プログラミング言語の選択は重要である。なぜなら、どの言語を使うかによってどのような観点でデ
ザインパターンをまとめるかが違ってくるからである。我々のパターンはSmalltalk/C+十レベルの言
語形態を想定している。その選択によって、容易に実現できることとできないことが決まる。たとえば、
もし、我々が手続き型言語を想定していれば、Inheritance(継承)、Encapsuladon(カプセル化)、
Polymorphism(ポリモルフィズム)といったデザインパターンを組み入れたであろう。また、我々のパタ
ーンの中には、あまリー般的でない言語によって直接サポートされているものもある。たとえば、CLOS
はマルチメソッドを有しているので、Visitorパターン(P.53)のようなパターンは必要性がなくなるの
である。実際のところ、SmalltalkとC十+の間にも違いがあり、どちらの言語を使うとより簡単に表現
できるかは、パターンによっても違ってくる(例としては、Iteratorパターン(P.275)を参照)。
611 :
デフォルトの名無しさん
2016/08/04(木) 09:33:28.01 ID:IwXa2U8x
内容を理解してないから例にある記述方法しか受け付けないんだよ。
612 :
2016/08/04(木) 09:33:48.07 ID: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.97 ID:0aO0sFCL
>>610
あ。引用部分は自炊本の OCR のコピペなんで、タイポは脳内補完ねがいます。
614 :
2016/08/04(木) 09:35:44.09 ID:0aO0sFCL
>>612
GoF も「Smalltalk では簡単に記述できるものもある」とは言っているけど、
ぜんぶがぜんぶとは言っていないよね。
615 :
デフォルトの名無しさん
2016/08/04(木) 09:35:54.66 ID:IwXa2U8x
>>612
おまいみたいなバカに本を売り付ける為だろw
616 :
2016/08/04(木) 09:38:22.54 ID:jTAWnEUa
>>615
え?捨て台詞?w
617 :
2016/08/04(木) 10:07:48.33 ID:e/09ny1R
これはまさに捨て台詞で十分な一例。
618 :
2016/08/04(木) 10:14:03.24 ID:0aO0sFCL
> だから、GoFはSmalltalkなら簡単に記述できる構造や機能を
> JavaやC++の表現力で解決する妥協案を集めたものなの。

Smalltalkを好意的にとらえて持ち上げてくれるのは、狭い視野で意味なし認定しちゃう人たちよりは
ファンとしてはありがたいけど、これはさすがにオーバーエスティメートだし、
もうちょっとSmalltalkならではのアドバンテージを学んでから、適切な持ち上げ方をしてほしい…
619 :
2016/08/04(木) 10:47:43.12 ID:iDV12Qqy
「GoFは、」と、「デザインパターンは、」の区別がつかない人たちと技術を語るのは非常に困難である。
620 :
2016/08/04(木) 11:37:47.99 ID:0aO0sFCL
>>619

もしそうだとしても、少なくとも>>591は「GoFの(デコレーター)」と明記すべきですよね
621 :
2016/08/04(木) 12:27:01.14 ID:CY/jwgqy
smalltalkって簡単に色々できるんでしょ?
なんで現代でメジャーじゃないの?
622 :
デフォルトの名無しさん
2016/08/04(木) 12:30:59.74 ID:IwXa2U8x
日本語の方が優れてるのに、世界じゃ日本人しか使ってないだろ?
623 :
2016/08/04(木) 12:31:27.57 ID:79cTVfxr
MSがVisual Smalltalkをつくらなかったから
624 :
2016/08/04(木) 12:57:32.53 ID:iDV12Qqy
>>620
GoFの定義如何に関わらず、>>546はデコレータパターンの実装ではないのだが?
625 :
2016/08/04(木) 13:05:00.50 ID:rDDGHvQu
はやく、
人間クラスと美少女クラスの問題に
たどり着いてくれよ。
626 :
2016/08/04(木) 13:16:23.28 ID:0aO0sFCL
>>624
だとするとちょっと分からないのですが、
あなたの言う「Smalltalkなら簡単に記述できる構造や機能」で実現された
デコレーターパターン(GoFの定義如何に関わらない)というのを提示してもらうことはできますか?
Smalltalk は書けないということでしたら、端的に方針だけ示してもらえればこちらで書きますので。

そもそも Smalltalk ではデコレーターパターンが不要(なので、実装はナンセンス)とのお考えでしたら
代替として Smalltalk 組み込みのどういう構造や機能を使うかを示してもらえればさいわいです。
627 :
2016/08/04(木) 14:01:27.52 ID:gwNa+xfa
つか、>>546のruby版って一体何?
デコレータパターンのつもり?
628 :
2016/08/04(木) 14:13:24.61 ID:0aO0sFCL
>>627
自分にはウィキペのデコレーターにあるJavaの例の要求仕様は満たしているように見えるけど。
具体的にはどこが不満?
629 :
2016/08/04(木) 14:41:37.79 ID: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.41 ID: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.29 ID:0aO0sFCL
>>629

これでいい?

http://ideone.com/WGTiOD
632 :
2016/08/04(木) 16:59:33.41 ID:gwNa+xfa
>>631
なんか実装手段が違ってきてますが・・・。

>>546のruby版はいったいどういう意図なのかが知りたいんだけど。
「rubyでclosureを使えばデコレータパターン同等のことができる」とか、そういう「意図」。
633 :
2016/08/04(木) 17:09:10.90 ID:0aO0sFCL
>>632
> なんか実装手段が違ってきてますが・・・。

本質部分は変えてないでしょ
変えたのも、クラスを直にいじるか、モジュールをprependするかくらいなもので


> closureを使えばデコレータパターン同等のことができる

>>540,545,546 の流れで、件のコードにそれ以外の意図を思いつくなら逆に聞きたい
634 :
2016/08/04(木) 17:41:28.54 ID:gwNa+xfa
>>633
うまく説明できないので、最後まで残っている違和感だけを説明して終わる。

WikipediaのDoublePriceクラスで、何か振る舞いを変えようと思えばDoublePriceクラスのみを変更すればいい。
DecoratorTestクラスの変更もしなくていい。

一方、>>546のコードだとそうはいかない。
これを「デコレータパターンを実装している」といっていいのか?
というのが俺の違和感。
まあ、それが本質なのか本質じゃないのかはわからんが。
635 :
2016/08/04(木) 18:07:30.87 ID:iDV12Qqy
>>626
だーかーらー、

デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、というバッドノウハウは静的型OOPLのためのものにすぎなくて、
同等の機能はSmalltalkでクロージャを使った実装(当然、上記デコレータパターンの実装ではない)で実現できる。

という主張に、どうして「じゃあSmalltalkで実装したデコレータパターンはどうなんだよ」がどれだけ的外れか理解できてる?
636 :
2016/08/04(木) 18:33:42.23 ID:0aO0sFCL
>>634
> 一方、>>546のコードだとそうはいかない。

単純に、ideone.com/WW8gva はデコレートをテストにハードコードしているからそうなるってだけで
http://ideone.com/HOkUN1 というふうに書いておけば、デコレーターの振る舞いを変えたければ
それを定義した decorate_price.rb だけを変えれば、decorate_price_test.rb は変更不要でしょう。
637 :
2016/08/04(木) 18:57:12.60 ID:0aO0sFCL
>>635
なるほど。たしかにおっしゃるとおりです。的外れなことを言ってすみません。
638 :
2016/08/04(木) 18:59:34.21 ID:iP1jJ0aF
>>610
iteratorはどっちが楽なの?
639 :
2016/08/04(木) 19:27:18.45 ID: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.06 ID:HlIXxJdQ
>>639
それでいうと今のC++もSTLでイテレーターが実装されてるから、
必要ないって言ってるようなもんじゃね?
別にSmalltalkが特別ってことにはならない。
641 :
2016/08/04(木) 20:21:25.52 ID:jTAWnEUa
>>635
> デコレータパターンという、修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで型に互換性を持たせる、

修飾オブジェクトで被修飾オブジェクトでラップしてっていうのは
Javaでの実装であって、Rubyのデコレーターパターンには必須ではないよ。
642 :
2016/08/04(木) 20:23:12.92 ID:jTAWnEUa
デコレータパターンは言語によっていろんな実装が有って
Javaでは修飾オブジェクトで被修飾オブジェクトでラップして、両者を同じ基底クラスから派生させることで
型に互換性を持たせる、というバッドノウハウが静的型OOPLだから必要になるけど、
デコレーターパターンはSmalltalkでクロージャを使った実装で実現できる。
643 :
2016/08/04(木) 20:37:49.54 ID: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.05 ID:jTAWnEUa
イテレーターパターンをSmalltalkで書いてみたわけね。
645 :
2016/08/04(木) 20:47:45.80 ID:XSjm71+w
イテレータパターンを使わずとも
既にあるイテレータを使った、でしょ
646 :
2016/08/04(木) 20:55:24.22 ID: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.10 ID:ILqHD9/M
>>642
クロージャを使ったらデコレータとは言わないのでは?
デコレータは継承による多態性を用いたものに限定すべき。
同じ事をやる方法なんていくらでもあるから、
そこは継承によるものと限定しておかないと意味分からなくなる。

無論、今のC++やJava、C#だってクロージャもしくは
それに類似した機能を使って同じ様なことはできるし、
Smalltalkだって継承を使ったデコレーターはできる。

言語によってできることできないことと、
各言語の流儀みたいなものは切り分けて考えるべき。
648 :
2016/08/04(木) 21:15:46.97 ID:jTAWnEUa
>>647
デコレータの説明として、インターフェイスを同一視して
動的に機能を拡張していくとは書いてあるが
継承を用いることとは書いていない。
649 :
2016/08/04(木) 21:21:02.95 ID:CmNfOhbZ
>>648
それは定義じゃないだろ。GoF本では定義はStructureのところだ。
650 :
2016/08/04(木) 21:29:07.85 ID:jTAWnEUa
Structureは日本語にしたら
構造って意味ですよw
651 :
2016/08/04(木) 21:30:27.36 ID:CmNfOhbZ
>>650
んなことは分かってるだろ。そこが実質的な定義だと言ってるの。
そのあとにImplementationが来て、その構造の実装法やアレンジを述べる流れ。
652 :
2016/08/04(木) 21:33:42.86 ID:TDXgEb4R
継承してないと使えないとかじゃ困る。
653 :
2016/08/04(木) 21:34:27.18 ID:jTAWnEUa
> そこが実質的な定義だと(俺様が)言ってるの。


知らんがなw

お前が何を言ったところで、
Structureは日本語にしたら構造
Definition(定義)じゃない。

まさか単語の意味を強弁するとは思わなかったなw
654 :
2016/08/04(木) 21:39:49.22 ID:CmNfOhbZ
>>653
暗黙の定義ってやつだ。プログラミングしてるなら分かれ。
655 :
2016/08/04(木) 21:51:04.78 ID:jTAWnEUa
説得力0w
656 :
2016/08/04(木) 21:51:55.34 ID:VNJ4iqic
この場合、構造、だとしても問題無い件。
パターンの構造はこうであると定めてる。
657 :
2016/08/04(木) 22:03:13.75 ID:jTAWnEUa
構造の一例ねw
658 :
2016/08/04(木) 22:10:23.67 ID:CmNfOhbZ
デザインパターンなんだから特定の構造を集めたものだからな。
同じ事ができるならなんでもいいならパターンとはいわない。
まあ馬鹿は無視して議論続けてくれ。
659 :
2016/08/04(木) 22:12:49.41 ID:jTAWnEUa
まさかデザインパターンがGoFの23個だけだと?
あれはパターン例だよ
660 :
2016/08/04(木) 22:14:24.41 ID:CmNfOhbZ
>>659
それこそ誰もそんな話はしていないわけだが。
国語のテストとか悪かったでしょ?
661 :
2016/08/04(木) 22:20:23.44 ID:jTAWnEUa
Structureは日本語にしたら構造
Definition(定義)じゃない。

国語と英語の問題なw
662 :
2016/08/04(木) 22:24:49.05 ID:CmNfOhbZ
アホの一つ覚えとはこのこと
663 :
2016/08/04(木) 22:45:18.74 ID:jTAWnEUa
効いてる効いてるw
664 :
2016/08/05(金) 05:47:03.48 ID:Q5sCXOre
あるプログラム片の構造がパターンカタログのものと異なっていたら、
そのプログラム片はそのパターンの実装とは言えないな。

実際問題として、このスレで出ているRuby実装は、GoFに掲載されたデコレータパターンの実装ではない。
それを無視するなら、あなた (ID:jTAWnEUa) にはデザインパターンを使うための
最低限の素地が備わっていないということ。
665 :
2016/08/05(金) 07:23:44.09 ID:TLRbqbFt
>>644
あまりにひどくて、なにをいっているかわからなかった。SmalltalkはともかくRubyのコードも読めないのかと。

内部イテレーターを使ったこの実装をイテレーターパターンだと言い切るのはどう考えても無理があるし、
同じ理屈でクロージャーを使った件の実装をデコレーターパターンだと言い張っているなら混乱するだけだからやめてほしい。
666 :
2016/08/05(金) 08:28:16.86 ID:liZAD7d5
>>664-665
この二人は単に常識的な発言をしているだけだが
きっと相手には伝わらないだろうね
667 :
2016/08/05(金) 11:01:37.11 ID:RHt058cj
結局オブジェクト志向が理解出来なくて管を巻いていたら
世間はプロトコル志向に移ってしまったでござるの巻
お前ら何周遅れたら走り出す気になるの?
668 :
2016/08/05(金) 12:54:45.79 ID:Vwi1FrEy
Swiftのプロトコルも何周回目か遅れですよ?
ScalaやRustのトレイトとか知らないんですか?
669 :
2016/08/05(金) 13:11:37.22 ID:ccW8btWE
イテレータをアイテレータって書いてる人がいるけど
どこの方言なの?
weblioさんの発音もイテレータなんだけど
670 :
2016/08/05(金) 14:20:51.80 ID:1PWjv4l0
weblioワロタw もっとちゃんとした辞書持って来いよ。
Merriam Websterとかさ。和英辞書を引用して日本語論じたりしないだろ?

色々調べてみたけど、Wikitionaryのiterateでは二重母音の発音も載せてる。
その他の辞書では見つからなかった。

実際に英語ネイティブのアメリカ人が/ai/でも発音しているのを聴いたこともある。
伝統的には一般的な発音じゃなかったけど、IT界隈でよく使われているうちに、
発音変種が発生したんじゃないか? 英語発音学的にはどちらでも許容されそうだし。
671 :
2016/08/05(金) 14:53:55.08 ID:1z/JWFxp
>>669
方言というより極度の経験不足なんだろ
イテレータについて人と語った事が無いから
間違いがずっと正されずにここまで来たんだろうな
672 :
2016/08/05(金) 15:20:22.46 ID:Y7jgmn2a
>669
iとかitとかitrとかiterとかに略すから
アイ、イット、アイター、アイターとかって呼んでいるのでは
発音している本人に聞かないと真相はわからんがな
673 :
デフォルトの名無しさん
2016/08/05(金) 15:25:47.40 ID:j/FnlCNZ
クロージャはデコレータじゃないとかPythonに全面的に喧嘩売りすぎだろ
674 :
2016/08/05(金) 15:40:45.96 ID:O4e+hfU+
クロージャーを使った実装はデコレーターパターン(GoFの)ではないという話なんだが
675 :
2016/08/05(金) 15:47:55.44 ID:1PWjv4l0
>>673
別のパターンって言ってるだけでは?
覚えやすさや関連性からデコレーターの名前を関するのは自由だけど。
676 :
2016/08/05(金) 16:10:54.07 ID:b8/AN42w
Rubyのprependを使った例はDecoratorとしてもいい気がするが、単なるクロージャをDecoratorとは呼べない気がする
677 :
2016/08/05(金) 16:22:03.55 ID:VlcB2rw7
デコレータパターンの機能を持っている設計を
全部デコレータパターンとしてしまっては
デザインパターンの意味がないからな

そりゃどんな方法でも同等の機能は実現するかもだが
ある程度を設計をパターン化して縛るのが目的でもあるからね
なんでもOKだったら意味ないよね
678 :
2016/08/05(金) 16:30:02.44 ID:1z/JWFxp
カタログ化の価値を下げようとする連中は居るんだよ
広義のデザインパターンは〜とか
○○も××パターンの亜流と言えるだろう〜とか
拡大解釈と独自解釈でどんどん元の輪郭をぼやかしていくんだよ
679 :
2016/08/05(金) 18:48:03.79 ID:zTXcoGD+
>>677
ケーキにホイップクリームのせるのもおちんぽにコンデンスミルクかけるのもデコレーションには違いないだろ実装が違うだけでやってることは完全に同じなのだから継承か委譲かクラスかクロージャかといった細かい違いを気にしなくていいからこその設計だと思うのだよ
680 :
2016/08/05(金) 18:50:15.99 ID:zTXcoGD+
実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
681 :
2016/08/05(金) 19:29:11.85 ID:Q5sCXOre
>>680
そうか、おまえがいう「デザイン」「ソフトウェア設計」は実装を縛らないのか。
ずいぶんフリーダムなプログラマだなw
682 :
2016/08/05(金) 19:48:51.35 ID:7blLYh/r
クラス図レベルがデザインパターン。
そこから実際にどう具体的な言語でコードに落とし込むかが実装。

クラス図レベルで全く違うものはパターンとして別物です。
683 :
2016/08/05(金) 20:06:03.26 ID:i8crE51h
おまいら、自動翻訳で日本語をえいごにして、出た英語を自動翻訳で日本語にして、元の日本語と違うってモンクいってるんだよな?
684 :
2016/08/05(金) 20:28:42.82 ID:1l5AtzWC
>>670
それ単に英語がなまっているだけだから
685 :
2016/08/06(土) 08:01:13.80 ID:70rUJ/gH
>>684
なまってるんじゃなくて、発音が[i]の母音に強いアクセントがつくと[ai]に転じるのは普通。
iterateの第1母音は普通は[i]だが、iterateという語を特に強調する時には[ai]になることもある。

ちなみにweblioはUS出身のNLP研究者にも評価が高かったりするから、そう馬鹿にしたものでもない。
686 :
2016/08/06(土) 10:06:20.97 ID: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.00 ID:BacY3CwA
だからどうしたんだって話
688 :
2016/08/06(土) 10:17:01.24 ID:BZ9Nu5V3
アイテレータ君は頑張りどころを間違えてる
689 :
2016/08/06(土) 11:27:40.31 ID:70rUJ/gH
>>686
Haben Sie gelesen, eine deutsche Übersetzung?
690 :
2016/08/06(土) 12:00:01.53 ID:rJo5wxwi
691 :
2016/08/06(土) 12:02:23.29 ID:rJo5wxwi
>>689
Was davon ist im Zusammenhang mit?
692 :
2016/08/06(土) 13:54:29.24 ID:70rUJ/gH
>>691
Das ist meine Frage.
693 :
2016/08/06(土) 15:01:07.75 ID:rJo5wxwi
Nein, es ist meine Frage
694 :
2016/08/06(土) 19:33:40.65 ID:rdi0Pbkh
そんなアイレテーター君にヒントをもらった>>646 ですが、
週末の余暇を使って調べ調べ C++ で書いてみました。

http://ideone.com/aMHgqO

なるほど。このくらい抽象化して簡潔に書けるなら
今の C++ には35年ほど前の Smalltalk 同様イテレーターパターンは不要と言い切ってよさそうですね。

惜しむらくは逆順用の range-based for くらい用意しておけよ…、という不満は残りますが。^^;
695 :
2016/08/06(土) 20:05:53.09 ID:OCZ+hMAU
そもそもbegin, endなどのモロモロが
既に(外部)イテレータ以外の何物でもないわけでw

内部イテレータ形式を欲しがるかどうかはともかく
range-based forとかはどうでもいいよねこの場合
696 :
2016/08/06(土) 20:24:55.16 ID:fG7kY+EI
アメリカ英語なんて
英語の方言そのものだろ。w
トマトをトメイトゥとか、
ポテトをポテイトゥとか
馬鹿みたいな発音するんだぜ。
アイテレーターみたいな馬鹿っぽい発音が好きなのか?
697 :
2016/08/06(土) 21:29:05.67 ID:rdi0Pbkh
>>695
おっしゃりたいことがよくわからなかったのですが
「イテレーター(内部なり外部なりの)が標準で提供されていればイテレーターパターン(GoFの)はいらない」
という主張(>>639,646)に対して「そもそも〜」はどういう反論で、
range-based forがなぜ「どうでもいい」という話になるのしょうか?
698 :
2016/08/06(土) 22:17:57.01 ID:70rUJ/gH
>>693
おいおい、Neinに続いて肯定文とか、なんなんだその日本語みたいなドイツ語もどきはw
699 :
2016/08/06(土) 22:19:24.01 ID:70rUJ/gH
>>696
はいはい、あなたは馬鹿ですよ。認めてあげましょう。
700 :
2016/08/06(土) 22:20:26.81 ID:70rUJ/gH
>>695
>そもそもbegin, endなどのモロモロが
>既に(外部)イテレータ以外の何物でもないわけでw

だめだ、こいつは手の施しようがないw
701 :
2016/08/07(日) 00:32:53.21 ID:Z9t6ZbaZ
>>697
ごめん
流れつかめて無かったわ

標準のコンテナにイテレータがあるんなら
それを使う限りはイテレータパターンの必要も無い
(内部イテレータ形式もrange-based forも無くてもいい)

それだけの話
スレの最初のほうに既に書かれてる話
702 :
2016/08/07(日) 00:34:17.18 ID:JriZaYfU
もう少し正確に言えば、言語やライブラリが
イテレータパターンを実装しているから、
あとはそれに従うだけって感じかな。
意識せずにイテレータパターンを使っている。
703 :
2016/08/07(日) 00:40:31.89 ID:fZ/XAaEO
>>702
そやね
その言い方は正しい
704 :
2016/08/07(日) 06:55:15.73 ID:N62pNMnU
>>702
「意識せずにイテレータパターンを使っている」は大間違い。
705 :
2016/08/07(日) 08:03:17.31 ID:vAScX9Az
>>704
そやね
そっちが正しい
パターンを使うのは設計者だからね
706 :
2016/08/08(月) 12:57:55.81 ID:TCnmrmuR
おっすおらフリーダムプログラマ
日夜社畜プログラマと戦ってるだ
707 :
2016/08/08(月) 13:46:12.84 ID:jSuSjrUB
>>702
> もう少し正確に言えば、言語やライブラリが
> イテレータパターンを実装しているから、

正確に言うなら、イテレータパターンというのは、
> コンテナオブジェクトの要素を列挙する手段を独立させることによって、コンテナの内部仕様に依存しない
> 反復子を提供することを目的とする
実装パターンのことで(Wikipediaより)、言語やライブラリがiterableな何かを提供しているからといって、
それらがイテレータパターンを実装しているとは限らない。
708 :
2016/08/08(月) 13:48:55.90 ID:jSuSjrUB
>>680
> 実装まで縛るならデザインパターンじゃなくてインプリメンテーションパターンだ
発想が逆だね。
ある機能を実現するための実装パターンを分類・カタログ化したものが、GoFのデザインパターンだ。
709 :
2016/08/08(月) 21:13:01.03 ID:BQ4UM/x3
まさしくその通りだね
そして同じ機能だったらどんな設計でもOKとしてしまっては
デザインパターンの意味がない
でもこの話題はもう終わりにしたいね
710 :
2016/08/08(月) 21:24:02.49 ID:aqLNls7E
だからデザパタなんか、屋根を屋根といってるだけで、トタンなのか瓦なのか藁葺きなのか何も定義してないって言っただろ。
だから積み木のおうちでも構わないんだよなぁ
711 :
2016/08/08(月) 21:38:41.07 ID:dN7u7NbH
パンピーは屋根には天井がセットでついてくると本気で思ってそうだから怖い。
712 :
2016/08/08(月) 21:41:39.71 ID:q4pU/gN8
>>709
とは言っても言語が違ってもデザインパターンは通用するわけで
実装がたった一つというわけじゃないのは確か

C言語でオブジェクト指向をすることだってあるし、
クラスがなかったES5時代のJavaScriptでもデザインパターンは作れた。

重要なのはデザインパターンの設計に出てくる登場人物があるかどうかではないだろうか?
例えば、Decoratorパターンだと、Component、ConcreteComponent、
Decoretor、ConcreteDecoratorという登場人物がある。

これはクラス図で書かれているだろうけど、別にクラスである必要はない。
例えばクロージャーを使って実装してもかまわない。
またインターフェースは明示的に継承していなくても、事実上特定の関数を実装していなければ
正しく動かないなら、それはインターフェースを使っていると言ってもいいだろう。

これと同じ登場人物が出てくるものは同じデザインパターンといっても良いだろう。
713 :
2016/08/08(月) 21:46:47.76 ID:rabkqueT
そこまで行ったら別物だって。
クロージャーやら使ってクラス図レベルで逸脱してもいいという
宗派をひらきなよ。
714 :
2016/08/08(月) 21:57:23.36 ID:q4pU/gN8
>>713
そうはいってもだね。
クラス図がないES5でもデザインパターンの
設計通りに作れるでしょ?
715 :
2016/08/09(火) 05:48:45.82 ID:tGFAeOU0
>>712
ばーか
716 :
2016/08/09(火) 07:42:08.32 ID:ttLAI02G
>>714
クラス、クラス図がないからデザパタにクラスは不要というのは、本末を転倒してますよ。

GoF も述べているように(>>610) クラスの無い言語では、クラスの役割りを「カプセル化」パターン、
「継承」パターン等で補ってから、その上でたとえばデコレーターパターンを実現しているというだけです。
717 :
2016/08/09(火) 09:40:43.48 ID:zWs+JfAu
>>716
なるほど。言語仕様としてクラスの有無ではなく
継承パターンができていれば、その実装がクロージャーでも
かまわないということですね。

そして継承パターンと言うものには、何が何を継承している
という概念があるはずですから、その「何」が登場人物に
なるわけですか。
718 :
2016/08/09(火) 10:28:51.94 ID:GFJow9Sf
登場人物という考え方がバカっぽくて無理
719 :
2016/08/09(火) 15:03:31.41 ID:V7FsU68Q
「○○言語だともっと簡単に実装できる」君と
「クロージャを使えばもっと簡単に実装できる」君は
いい加減うざいよ?
720 :
2016/08/09(火) 16:26:29.88 ID:tGFAeOU0
>>719
その通りだと思います。
まずはソフトウェア設計は実装ではないが、
実装を縛る規範であるということを
理解したらいいと思います。

それが理解できたら帰っておいで。
721 :
2016/08/09(火) 17:57:41.45 ID:7qytW98y
デザインパターン
日本語で
設計見本でいいですか?
722 :
2016/08/09(火) 18:04:53.60 ID:c6svxtGU
そんな日本語があるか
723 :
2016/08/09(火) 19:57:07.69 ID:AUCg5/Tk
>>708
それは過程の話な結果として実装を示すならインプリメンテーションパターンと言っているだろうしかしデザインパターンと言っているから実装を抽象化したものだ具体的な実装を示すものではないってことさ
724 :
2016/08/09(火) 20:07:31.05 ID:GFJow9Sf
その前に君の書き込みを日本語のパターンにしてください
725 :
2016/08/09(火) 20:08:56.33 ID:AUCg5/Tk
>>681
設計が実装を具体的に決めてしまったら設計の意味がないと思うんだよおトイレとお風呂が一緒になってますってことと具体的な便器の形とは分けられると思うんですデザインパターンっていうのはいわばそういうものでお風呂とトイレを一緒にしたら便利だよってことさ
726 :
2016/08/09(火) 20:10:54.82 ID:AUCg5/Tk
>>724
おだまり便器野郎
727 :
2016/08/09(火) 20:24:12.28 ID:FqlEy475
どうせ計算式をクラスにするんだろ?
728 :
2016/08/11(木) 18:28:28.20 ID:vQt/3MfO
濃厚電波、完飲。
729 :
2016/08/15(月) 00:10:10.82 ID:NEOTEyUk
いい加減、オブジェクト指向 vs 関数型なんていう無意味な議論やめようよ
直交する概念じゃん
関数型言語でも「本物の」オブジェクト指向プログラミングは出来るし、
最近の流行りはオブジェクト指向言語に関数型的な機能を付けることだろう
730 :
2016/08/15(月) 01:36:24.27 ID:Yh7//hE4
本当のオブジェクトプログラムは、メッセージ交換だから、関数型が入る余地なんか無いけどな。
731 :
2016/08/15(月) 02:08:53.20 ID:6fraHMZW
お前ら、早く本論に入れ!
美少女クラスはなぜ人間クラスを継承出来ないのよ!!!
732 :
2016/08/15(月) 03:13:33.69 ID:Y0Jnfl62
美少女はクラスじゃなくて人間クラスのインスタンスで
パラメータが特定の値のものなだけだよ。

プリンセスメーカーであれば「魅力」のパラメータが
高くて「年齢」が若ければ美少女なんじゃね?
733 :
2016/08/15(月) 11:57:12.25 ID:P1EAyeII
排便メソッドはどうなるんだ!
734 :
2016/08/15(月) 13:00:28.85 ID:TUIKyN4z
>>729
本物…
735 :
2016/08/15(月) 13:36:04.19 ID:Yh7//hE4
>>732
まあそうだな。
人間クラスの女性属性で年齢属性が十代で、
あとはいろんなパラメータがバランス良く絶妙なバランスであるだけ。
736 :
2016/08/15(月) 13:43:17.25 ID:Y0Jnfl62
>>733
排便性能とでもいうパラメータ作れば良いんじゃねーの?
美少女じゃなくても排便が困難な人っているからな。
737 :
2016/08/15(月) 15:37:08.19 ID:Yh7//hE4
便秘気味な美少女かw
738 :
2016/08/15(月) 16:44:15.38 ID:uCi+R87y
            | 
            |  彡 ⌒ ミ 
           \ (´・ω・`)またうんこの話してる... 
             (|   |):::: 
              (γ /::::::: 
               し \:::
                  \
739 :
2016/08/15(月) 16:45:21.70 ID:P1EAyeII
オブジェクト指向は愚かな考え。
排便メソッドを実装した人間クラスから美少女クラスが作れない。
740 :
2016/08/15(月) 17:02:42.33 ID:NHD7YcMK
アヒルががーがーなくのではなく、がーがー鳴けばそれがアヒルなのである
うんこができればそれは人間なのである
741 :
2016/08/15(月) 17:08:50.15 ID:Y0Jnfl62
オウムがガーガーなけばそれはアヒルなのである?
742 :
2016/08/15(月) 19:19:30.08 ID:ATo5mwbJ
>>738
「ウンコを覗くときウンコもまたおまえを覗いているのだ。」

もうこの子は脳の端までウンコになっちゃったんだよ…
743 :
デフォルトの名無しさん
2016/08/16(火) 12:32:47.23 ID:nB+m5lHF
頬を紅潮させた少女のアナルは今にも決壊寸前のダムの如くヒクヒクと静かに脈打つのであった
そのアナルをまるで獲物を狙う蜥蜴の様な眼差しでジットリと凝視していたお前は…
744 :
2016/09/04(日) 22:44:30.10 ID:AI4OMPbE
やはり、オブジェクト指向は愚かな考えなんでしょうか?
それはなぜですか?
745 :
2016/09/05(月) 23:26:30.97 ID:2pvjX+vh
>>744
なんのメリットもないから
746 :
2016/09/10(土) 22:12:27.45 ID:vL431mpn
クロージャという秘境
747 :
2016/09/11(日) 09:06:24.12 ID:HdsNani4
オブジェクト指向にクロージャーが取り入れられてから、
オブジェクト指向は更に便利になった。
748 :
デフォルトの名無しさん
2016/09/11(日) 09:11:08.53 ID:xTqWSUIJ
どうせなら理想のクロージャの構文はどんなものか議論しよう。
美少女のウンコの話はもういいから。
749 :
デフォルトの名無しさん
2016/09/11(日) 10:48:53.37 ID:EVh79L2H
いや美少女うんこの方が重要だ
750 :
2016/09/11(日) 18:47:04.73 ID:LruamEXh
間をとってクソージャ
751 :
2016/09/12(月) 10:17:01.19 ID:WLe9OZIE
おあとがよろしいようで
752 :
2016/09/12(月) 11:18:07.22 ID:DqPwyMnw
じゃあ質問
若い時は買ってでもするものな〜んじゃ?
753 :
2016/09/12(月) 11:24:36.38 ID:R5hylYBo
コンビニでトイレだけ借りるのは気まずいので後で何か買って帰る
754 :
デフォルトの名無しさん
2016/09/12(月) 13:15:37.24 ID:zvXoPKj/
美少女を買う
755 :
2016/09/12(月) 21:03:27.94 ID:p0km3lhz
>>752
http://find-travel.jp/article/2123

シンガポール初 キッズクラブ

12歳までの子供が安全に遊べます。小さい子供連れのファミリに―にはうれしい施設です。
セントーサエキスプレスの終点ビーチ駅で下車、徒歩五分ほどです。
子供は有料ですが、付き添いの大人は、無料です。
756 :
2016/09/12(月) 21:04:17.88 ID:p0km3lhz
http://www.dan-b.com/tp_luna/page1_1.html

ウェーブスターライド

すべり台

もくば館の電動木馬
自走式のジェットコースター。小さなお子様でも、
大人の付き添いがあれば乗れる。
付き添いの大人は無料にしてくれる心遣いがうれしい。
757 :
2016/09/17(土) 19:06:05.53 ID:iND/Jut9
オブジェクト指向と計算式という対比がまずおかしいスレ
758 :
2016/10/11(火) 13:34:51.26 ID:SPhMZv+b
>>757
その前に>> 1の脳みそがオカシイ。
議論以前の話
759 :
2016/11/14(月) 16:47:20.70 ID:cBDVjyju
>>733
排便メソッドつくってうんち吐き出させれば良いじゃん…
760 :
2017/03/21(火) 23:51:29.32 ID:RJ2XVIqX
できの悪いプログラマはこうやってくだらんことに執着した挙げ句道を外すからな

オブジェクト指向を禁ずるのは当然だが、プログラムも規制すべきだろ
260KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: