消えてなくなれよ >オブジェクト指向

消えてなくなれよ >オブジェクト指向 at TECH

1:デフォルトの名無しさん
07/12/28 15:13:40
closure で十分じゃんよ

2:デフォルトの名無しさん
07/12/28 15:17:54
>>1
クローじゃーってなあに？

3:デフォルトの名無しさん
07/12/28 17:43:05
オブジェクト指向⊃クロージャ

4:デフォルトの名無しさん
07/12/28 18:42:39
TMで十分、コンビネータで十分と言ってるのと変わらん。

なんでもできるのはいいことじゃない。
人はときには縛ってあげないと間違った道を選んでしまうんじゃよ。

5:デフォルトの名無しさん
07/12/28 18:50:39
てｓｔ

6:デフォルトの名無しさん
07/12/30 04:03:01
そんな貴方にアスペルガー指向プログラミング。

7:デフォルトの名無しさん
07/12/30 15:50:00
クロージャでクラスを模す事は出来るけど、一々それをコーディング
するのは面倒だし、出来たコードはコンパイラの支援も受けられず
非効率的。事前にクラスシステムをクロージャで用意しておくので
あれば、それはオブジェクト指向言語と変わらん。

8:デフォルトの名無しさん
08/01/04 02:08:24
OOスレ7 なぜオブジェクト指向は普及しないのか
ｽﾚﾘﾝｸ(prog板)

9:デフォルトの名無しさん
08/01/04 20:02:42
>>1はオブジェクト指向がコーディングスタイルの一種だと
勘違いしている。

10:デフォルトの名無しさん
08/01/04 20:50:42
>>1 ではないが >>9
> オブジェクト指向がコーディングスタイルの一種
ではない理由を説明してくれ。

11:デフォルトの名無しさん
08/01/04 23:17:25
>>9ではないが、
コーディングスタイルは言語仕様が確定された上で、どのように表現するかの問題で、
オブジェクト指向は言語仕様の中にあるものだから、明確にコーディングスタイルとは異なる。

12:デフォルトの名無しさん
08/01/05 00:27:51
単なるコーディングスタイルならOOPLなんて言葉存在しとらんだろしな

場面を絞れば制約のための工夫／広義のコーディングスタイルでも十分な設計できる事もあるからな
OOP慣れたらOOPLでなくてもカプセル化や似非private表現したりとかデザパタどこまでそれっぽく表現できるかとかやり始める馬鹿もいるし。いるっていうか、お

13:デフォルトの名無しさん
08/01/05 01:18:17
>>9 じゃないけど
Lisp系の言語にとってはOOなんて只のコーディングスタイル
の問題なんだが…

14:デフォルトの名無しさん
08/01/05 01:19:29
アンカー間違えた >>10

15:デフォルトの名無しさん
08/01/05 04:59:22
まあ C++ もコーディングスタイルの問題に済ませることもできるな。

でも、オブジェクト指向を仮定するといろいろな手法が導けるので、
コーディングというレベルでなくて、システム設計とかのレベルで考えるとメリット、デメリットがあるよな。
要するにチーム全員がオブジェクト指向を理解できるという仮定でシステム設計をするメリット。

ただ逆に、オブジェクト指向を理解できないプログラマというのが存在することを
考慮できるか否かが問題だとおもう。
構造型プログラミングの理解できないプログラマは排除できるのだが、オブジェクト指向を理解できない
プログラマを排除できないのが今の世の中。

16:デフォルトの名無しさん
08/01/05 11:12:00
>>13
それこそまさに>>12が
> OOP慣れたらOOPLでなくてもカプセル化や似非private表現したりとかデザパタどこまでそれっぽく表現できるかとかやり始める
の典型例と思われ。

17:デフォルトの名無しさん
08/01/19 14:02:19
そう言えばさ、オブジェクト指向って現場で役に立ってる？
オレオレオブジェクトまかり通ってて実質的には足枷になってる
ケースの方多い気がするんだけど…

つか、思ったことない？
「アフォはクラス設計するんじゃねぇ！！！」

18:デフォルトの名無しさん
08/01/19 14:05:48
>>17
> 「アフォはクラス設計するんじゃねぇ！！！」

このセリフには、本来オブジェクト指向は現場で役に立つという前提があるように思えるのだが。

19:デフォルトの名無しさん
08/01/19 14:07:03
JavaだろうがC#だろうが全然オブジェクト指向じゃないコードは書けるよ
ていうか書く人がいる

20:デフォルトの名無しさん
08/01/19 14:20:19
>>18
「そのように考えていたときが俺にもありました」って、過去形な

21:デフォルトの名無しさん
08/01/19 14:24:18
>>20
ならば、「アフォはクラス設計するんじゃねえ！！！」のかわりに
「クラス設計するんじゃねえ！！！」と言うべきじゃないかな。

22:デフォルトの名無しさん
08/01/19 18:20:46
効率の良いクラス設計の方法論って無いの？

23:デフォルトの名無しさん
08/01/19 18:24:36
>>19
いるねー。ほとんどのメソッドがstaticな人とか。

24:デフォルトの名無しさん
08/01/19 18:31:12
万能クラスを作ってしまうってのが一番多いな

25:デフォルトの名無しさん
08/01/19 18:32:47
>>24
本当に万能なクラスなら、ぜひソース公開してほすいｗ

26:デフォルトの名無しさん
08/01/19 18:48:03
かなり万能ですよ
ただし必要に応じて中にコードを追加するので成長し続けます

27:デフォルトの名無しさん
08/01/19 19:31:34
ときどき癌化するんだよな

28:デフォルトの名無しさん
08/01/21 01:20:57
Ｃプログラマ必須テキストです！

URLﾘﾝｸ(mori.eco.to)

29:デフォルトの名無しさん
08/01/21 02:44:58
>>25
神様クラスのことだろ
クラスは全部これを継承しろっていう

30:デフォルトの名無しさん
08/01/22 23:54:26
しかし、その神々しさに畏怖して誰も使わない罠。

31:デフォルトの名無しさん
08/01/23 02:46:53
万能クラスと万能ネギはどっちがより万能ですか？

32:デフォルトの名無しさん
08/01/24 18:06:17
概念的には万能クラスの方が万能だが、
それで飯をジェネレートできねーなら俺は万能ネギとりますねぇ。
あ、でも万能クラス一個あれば仕事全部やってくれんのかな。

揺らぐなぁ。

33:デフォルトの名無しさん
08/01/28 14:17:49
××があればほとんど全ての問題は解決する。

というキャッチフレーズに乗せられた人の如何に多いことか。
さあ、君も××に当てはめる言葉を考えて遊んでみよう！

34:デフォルトの名無しさん
08/01/28 14:35:06
お金があればほとんど全ての問題は解決する。

35:デフォルトの名無しさん
08/01/30 00:27:48
時間があればほとんど全ての問題は解決する。

36:デフォルトの名無しさん
08/01/30 00:31:18
真実の愛があればほとんど全ての問題は解決する。

37:デフォルトの名無しさん
08/02/03 06:28:58
愛＞金
飯＞愛
金＞飯

38:デフォルトの名無しさん
08/02/03 13:26:31
推移律が定義できないので順序構造が成り立たない件

39:デフォルトの名無しさん
08/02/04 01:23:23
・飯は食べないと何もできなくなるし病気とか治らない
　ただし大金を掛ける必要はない。
・お金があればほとんど全ての問題は解決する。
・時間があればほとんど全ての問題は解決する。
　だが効率が悪ければ十分な金は得られない。
　効率良く真実の愛を得る方法もない。
・真実の愛があればほとんど全ての問題は解決する。
・お金があれば、ほとんどの真実の愛についての問題は解決する。
　ただし、金で買えない愛もある。
　また、効率を重視し過ぎると真実の愛と立ち向かえない。

以上の過程から重み付けを線形に評価すると、
金≦真実の愛（妥協含む）＞時間＞飯（ただし必須であることには変わりがない）

試みとしてはこんな程度だろうか。当然まだtransitibityを網羅できてる訳じゃなく、要素考察の礎に過ぎないが。

40:デフォルトの名無しさん
08/02/04 18:54:55
>>39
グラフ構造にしたほうがよくないか？

41:デフォルトの名無しさん
08/03/07 21:23:50
>>34, 35
無限大の金と時間があれば, 物理法則に抵触しない限り
何だって解決出来ると思うんだよもん
# 心の問題は別かもしれんが...

42:デフォルトの名無しさん
08/03/07 21:50:54
無限の性能を持った仮想のマシンを使って
無限の時間をかけて計算するってことなら
昔の数学者がやってたが
どうせなら無限の金より無限の才能が欲しい気がしなくも無い

43:デフォルトの名無しさん
08/03/07 21:54:46
「消えてなくなれ」というフレーズがジャンプの漫画みたいで恥ずかしい

44:デフォルトの名無しさん
08/03/08 00:27:21
　　　　　　ﾊ,,ﾊ
　　　　　（ﾟωﾟ )　　男割します
　　　　／　　　＼
　 ((⊂ 　）　ﾉ＼つ))
　　　　　（＿⌒ヽ
　　　　　　ヽ　ﾍ　}
　ε≡Ξ　ﾉノ｀J

45:デフォルトの名無しさん
08/03/10 23:12:45
ごめん聞いていい？
javascriptってオブジェクト指向？

46:デフォルトの名無しさん
08/03/10 23:33:56
>>45
クラスは無いけどオブジェクト指向だよ。

47:番組の途中ですが名無しです
08/03/11 02:11:52
なんでこんな糞スレがいつまでも残ってんだよ。

オブジェクト指向そのものについては、ここ読んどけ。
URLﾘﾝｸ(d.hatena.ne.jp)

48:デフォルトの名無しさん
08/03/11 08:04:06
var HogeClass={
fuga:function(){
},
hage:function(){
}
};
constructor/destructorが使えるのかどうかは不明
ああこれはstaticmethodだけか

49:デフォルトの名無しさん
08/03/26 02:52:02
var hoge = {};
と
var hoge = new Object();
が等価
function が関数オブジェクトで引数を取れ、クラス代わりに使える
var hogeclass = function(a, b) {
this.a = a;
this.b = b;
};
var c = "hoge", d;
var hogeobj = new hogeclass(c, d);
//alert(hogeobj.a); //=> "hoge"

>>48
> ああこれはstaticmethodだけか

ちと違うような。

50:デフォルトの名無しさん
08/04/19 23:08:10
OO = クラスが無限増殖するだけの糞手法

51:デフォルトの名無しさん
08/04/22 16:16:29
フロー制御やコーディング手法というのは、構造化プログラミングの話だろ
オブジェクト指向は、ライブラリ構築手法だと思うんだが

それはともかく>>4が、マゾであることは、火を見るより明らかなんだ
なんせ、縛って欲しい人なんだぜ

52:デフォルトの名無しさん
08/04/28 07:24:57
>>48はクラスとグローバルオブジェクトの違いがわかっていないアフォ

53:デフォルトの名無しさん
08/06/24 02:04:15
オブジェクト指向的に美しいプログラムとか、
オブジェクト指向的に正しい記法とか、

それで生産効率が下がったら目も当てられないよなぁ

54:デフォルトの名無しさん
08/06/24 05:47:52
>>53
下がった例なんてあるの？

55:デフォルトの名無しさん
08/06/24 18:52:13
OCPとかLSPとかを忠実に守ると、
爆発的にクラスは増えるし、ウザいことこの上ないな
適度にグローバル変数とか使ったほうが、生産効率上がることが多い

56:デフォルトの名無しさん
08/06/26 11:03:14
釣るなよ

57:デフォルトの名無しさん
08/07/11 10:43:53
オブジェクト指向って、プログラマの半分は理解してないでしょ？

58:デフォルトの名無しさん
08/07/12 14:12:44
理解していない奴？
95～98%くらいだと思うけど。

59:デフォルトの名無しさん
08/07/12 18:12:04
なんだその程度か

60:デフォルトの名無しさん
08/07/19 01:03:57
理解できてる人間なんて世界中に100人も居るだろうか?
って最近思うよ。

俺はもちろん理解できていないが、他人が理解できているかどうかは分かるつもり。
OOという言葉と概念を知って20年近く経つけど、
「この人はＯＯが理解できている」なんて思わせる人間には一度もあったことないよ。

61:デフォルトの名無しさん
08/07/19 08:47:47
>>60
まずは、近所のコンビニまで出かけることに挑戦しよう。
そしたら次は駅前まで買い物だ。
こうやって順に慣らしていくことで君もヒキコモリを卒業できる。

62:デフォルトの名無しさん
08/07/19 09:52:21
>>60
少し違う。ＯＯ自体には宗派(笑)が少なくとも三つある。教祖が三人以上いるつうことだ．
そしてそれぞれの宗派の理解度は層を成して存在する。
当然ながら、それぞれの最上位の理解者は教祖様（笑）だよ。

宗派は何ですか？

63:デフォルトの名無しさん
08/07/19 23:24:01
＞宗派は何ですか？
えーと、スンニ派（多数派）はどれなんでしょうか？

64:デフォルトの名無しさん
08/07/20 23:23:52
いったいどの宗派を信じればメシアが救ってくれるのだろう。
エッ、自力本願だから自分で努力するしかないの？そんなあ・・・(w

65:デフォルトの名無しさん
08/07/21 13:56:57
禅宗系だと、OO知れば知るほど何も判らなくなっていくんだろうな
色即是空
空即是色
一生悩み続ける運命

66:デフォルトの名無しさん
08/07/22 08:09:49
>>65
で、頓悟するわけですよ。「OOとは結局、糞コンサルと糞教祖の金脈でしかないのだ」とね。

67:デフォルトの名無しさん
08/07/22 11:22:32
>>62
三系統の“オブジェクト指向”を「北斗の拳」に例えてみる
URLﾘﾝｸ(d.hatena.ne.jp)

68:デフォルトの名無しさん
08/07/23 00:02:31
迷えるプログラマ達よ。あなたはOOを信じますか？

69:デフォルトの名無しさん
08/07/23 04:21:53
OOは宗教か技術かと問われれば、俺は宗教だと答えるね。

70:デフォルトの名無しさん
08/07/23 04:42:51
OOは企業の陰謀だよ
企業の陰謀にちょうどよかったから利用されたのさ

71:デフォルトの名無しさん
08/07/24 10:34:43
オブジェクト指向は必要ないと？　　　　んなー

72:デフォルトの名無しさん
08/07/24 12:39:49
必要なところだけ使えばいい。

73:デフォルトの名無しさん
08/07/24 18:47:21
OOはどの経典を読んでもわかるようでわからない。
いくら説明されても空の意味がわからないのと同じようなものかもしれない。
しかし、空の意味がわからないと悟れないのでわかるしかない。
同じようにOOがわからないとプログラマは救われないのである。
修行するぞ、修行するぞ・・・・・・・・

74:デフォルトの名無しさん
08/07/24 22:47:01
経典やら宗派によって概念が違うみたいだからね。

75:デフォルトの名無しさん
08/07/27 14:37:41
言葉では説明できない。だから本読んだだけでは駄目。
OOは教えることはなく、各人がOOを学び得ることを目的とする。
・・・やはり宗教だね。

76:デフォルトの名無しさん
08/07/27 18:04:02
>>75
まさに自分で修行して悟らなければいけない小乗仏教の世界だなあ？
すると創始者のアラン・ケイは釈迦か？(w
じゃあ、また写経（サンプルプログラムを打ち込む）でも始めるか？
心が落ち着くなあ・・・・落ちつかねえよ(w

77:デフォルトの名無しさん
08/07/28 08:49:06
なんかまたSmallTalkの本が出てたけど、変わりばえしないね。
あいかわらず宗教臭いし著者が出してるライブラリの宣伝っぽい。
立ち読みだけでパスした。

78:デフォルトの名無しさん
08/07/28 14:36:02
ぶっちゃけ、そんなに難しくはない

79:デフォルトの名無しさん
08/07/28 14:58:49
良かったね。で、それを周りの人間全員に教えることは出来るのかい？。

80:デフォルトの名無しさん
08/07/30 09:30:14
たこ焼きの鉄板を使って、
材料を入れて
たこ焼きを作る

こんな感じ

つまり、鉄板をクラスで作り引数材料を加工してたこ焼きインスタンスの出来上がりだよね。

こんな感じの説明する人いるけど、混乱するでしょ。　はあ？　って。

81:デフォルトの名無しさん
08/07/30 11:28:20
>>80
その説明でよくわかるぞ。

たこ焼きの作り方が・・・(w

82:デフォルトの名無しさん
08/07/31 02:05:41
タイ焼きで説明した例は目にしたことあるよ

重要なのはオブジェクト指向の設計であって
オブジェクト指向のコーディングじゃないよ

オブジェクト指向のコーディングをオブジェクト指向の設計だと
勘違いしてる人をたまに見かけるけど最悪だよね

83:デフォルトの名無しさん
08/07/31 05:54:02
形にばかりこだわって本質に目を向けないものは真の悟りを得られないと　φ(・＿・”）ﾒﾓﾒﾓ
えーと・・・・・どこの宗派かな？

84:デフォルトの名無しさん
08/07/31 09:16:15
オブジェクト指向をキッチリ理解していないと、
オブジェクト指向のコーディングなんてできん。

ってことですよ

85:デフォルトの名無しさん
08/07/31 14:30:57
オブジェクト指向って、オブジェクト指向の設計を肉付けしながら、
コーディングしてるから、コーディングも設計も同時進行なのであった。

86:デフォルトの名無しさん
08/07/31 18:18:15
オブジェクト指向言語の文法をしっかり記憶してオブジェクト指向を理解した気になる。
長いこと記憶重視の受験勉強していればそういうことになるよな。
だれか「試験にでるオブジェクト指向」とか「ここだけ押さえれば大丈夫。オブジェクト指向の傾向と対策」とかいう
本をだしてやってくれ（笑）

87:デフォルトの名無しさん
08/07/31 19:55:54
>>85
それは・・・オブジェクト指向の目標の一つであったかと思うが。
本当にそれが実現しているのかい？
「自分だけ」という状況でも立派なもんだが。

88:デフォルトの名無しさん
08/08/01 01:13:26
利用する側から作るので、クラスやプロパティやメソッドが先に列挙され、インプリメントが後から埋まるよ
前者を設計、後者をコーディングと呼んでるよ

名前も重要だよね
IOPtrって何を担当するクラス？想像しやすいネーミングにしようよ

89:デフォルトの名無しさん
08/08/01 20:40:31
>>77
黒くて厚い本？スモールトークの真髄というわりにはライブラリを使った話ばかり。
文章もなんだか無理に分量を稼いでるかんじだし。同じぐらいの厚さのスクイークの
白い本のほうがいいと思った。

90:デフォルトの名無しさん
08/08/09 17:10:58
消えて無くなれ？
魔法か何かで本当にオブジェクト指向消すことができたらどうなるのかなあ？
オブジェクト指向が無くなればオブジェクト指向で開発したプログラムは存在しなくなるから
世の大半のプログラムは無くなるなあ？
そりゃあえらいこっちゃ・・・・・・・

91:デフォルトの名無しさん
08/08/09 18:08:20
>>90
> 世の大半のプログラムは無くなるなあ？

組み込み舐めんなVC++厨。

92:デフォルトの名無しさん
08/08/13 00:22:36
組み込みって、スイッチのオンオフに毛が生えた程度でしょ？

93:デフォルトの名無しさん
08/08/14 20:51:59
毛がボーボーで元のスイッチが見えません

94:デフォルトの名無しさん
08/08/15 02:43:09
エーンベデッド
エンベーデッド
エンーベデッドおおー

95:デフォルトの名無しさん
08/08/28 02:19:08
スイッチのオンオフに毛が生えていないノイマン型コンピューターは全滅した！

「ぐふふ、これで勝ったと思うなよ。ぐふっ」
いんてる　の　しにがお　は　やすらか　だった……。

96:デフォルトの名無しさん
08/08/29 09:12:55
>>95
組み込みってノイマン型なん？

97:デフォルトの名無しさん
08/08/29 09:16:32
あ、ノイマン型ではないってことか。　もめん。

98:デフォルトの名無しさん
08/08/29 22:53:22
消えてなくなれよ>オブジェクト指向わからない奴

99:デフォルトの名無しさん
08/11/09 18:24:28
>>98
激しく同意！　（←セリフ古いなｗ）

オブジェクト指向のメリットとして重要なものに、SE/PGテロの撲滅がある。
意図的に難読化、スパゲッティ化したプログラムで利権維持と工数水増しを図ろうとする
部落団体に支援されている派遣請負SE/PGの追放。
これは、クライアント企業の担当者や経営幹部、更には派遣元会社にも設計ドキュメントや
ソースコードが理解困難になる仕組みを悪用して寄生し、正規社員も苦虫を噛むテロ行為。

オブジェクト指向による高度な抽象化を行えば、上流から下流へは粒度だけの違いになり、
役員や幹部にも判りやすい記述になるので、従来のSE/PGのテロ行為が無力になるという
とても大きなメリットがある。

100:デフォルトの名無しさん
08/11/09 19:55:27
>>99
おまいマじゃないな。

101:デフォルトの名無しさん
08/11/09 20:56:24
まあ俺みたいな天才じゃないとオブジェクト指向を使うのは難しい

102:デフォルトの名無しさん
08/11/09 21:05:10
>>99
お前マじゃないし、しかもかなりできの悪い人間と見た。
底辺より悪いんじゃないか？

103:デフォルトの名無しさん
08/11/09 21:06:34
先生、ネタにそういう反応は無粋です

104:デフォルトの名無しさん
08/11/09 21:08:55
>>99
作為的にソースを理解困難にする事とオブジェクト指向とは何の関係もないよ
ソースにコメントを記述するだけで実際動作しているコードが読みにくくなるだろ

105:デフォルトの名無しさん
08/11/09 21:22:48
>>104
はははｗ、確かに偽コメントは「マ」にとって最高のオナニーだし威力あるだろうなｗ
ソースを保存し終えた途端に不敵な笑みを浮かべ、「グフフ・・・」と笑ってる「マ」の
姿は不気味で異様ｗ　他人事として見るなら面白い。

106:デフォルトの名無しさん
08/11/09 21:36:47
OOで実装するのはいいと思うが、
OOで設計するのはどうかと思う。
レベルが低い奴にやらせると、抽象化が不十分なモデルを組んできて、
しかも仕事の流れ上、それに逆らえなくなってしまう…。

107:デフォルトの名無しさん
08/11/09 22:41:22
なんか手順が違うな
要件が不足してるから不十分なモノができるんだろ？

108:デフォルトの名無しさん
08/11/10 07:43:14
>>106
そうそう。「実現不可能な実装のやりかけ」を設計と称して押しつけてくるw

109:デフォルトの名無しさん
08/11/10 09:08:03
オブジェクト指向は悪の枢軸

110:デフォルトの名無しさん
08/11/10 09:14:06
マルチパラダイム言語で使用可能な道具の一つ
って程度でいいよ
無くなれとまでは言わんけどOOが全てっていうのはちょっと

111:デフォルトの名無しさん
08/11/10 22:11:29
わざわざクラスにしなくていいものまで
クラスにしなければいけないキモさが嫌だ
かといってオブジェクト指向コードとそうでないコードが
混在してるのも読みづらくて仕方ない
つまりオブジェクト指向そのものが生理的に受け付けない

112:デフォルトの名無しさん
08/11/10 22:54:15
>>111
おまえオブジェクト指向理解してないだろ

113:デフォルトの名無しさん
08/11/11 16:44:38
C++で構造体の配列をつかわず、
クラスのvectorつかうって普通？

114:デフォルトの名無しさん
08/11/11 17:07:03
C++では配列は要素数固定なので
それで困る場合は　vector　使うのが当然だろう。

115:デフォルトの名無しさん
08/11/11 21:50:06
Javaみたいな"融通の効かない"OOPLだと
デリゲートがなくてちょっとした亜種でも派生する必要がある
無駄なクラス増殖はいずれDRY原則の破綻を招く

プログラミングの入り口がJavaの人って、どんな言語でも無駄にクラス作りまくる傾向があってウザい
JavaのOO思想をOOのあるべき姿として布教されてるうちは「OOは生産的」論には賛同しねえ

よく見るJavaOO脳のミス
・安易に継承しまくってクラス増殖→仕様変更に弱くなる(熟練でもよくある)
・特殊な状況でも無理矢理デザパタを馬鹿正直にあてはめる(慣れてきた人によくある)

116:デフォルトの名無しさん
08/11/11 23:47:05
>>115
過剰継承もオープンプロテクトの一技法なんですね、わかります。

117:デフォルトの名無しさん
08/11/12 04:56:25
オブジェクト指向って元々は、基本的に同じ性質を持つ複数の実体を個別に扱う
ことを容易にするという発想から発展してきたんだけどなー。多数の個人情報とか
多数の契約書とか、多数の図形とか。。。
クラス定義はそのオブジェクト指向を表記するための便宜上の概念なんだけど、
オブジェクト指向の情報源は真っ先にクラス、継承などから説明して混乱を与えて
いるよな。

118:デフォルトの名無しさん
08/11/12 08:46:01
>>116
お前の世界だけの造語使われても意味がわからん…

119:デフォルトの名無しさん
08/11/12 11:51:43
>>115
>JavaのOO思想をOOのあるべき姿として布教
そんなこと言ってる脳足りんがいるんですか？

120:デフォルトの名無しさん
08/11/12 12:40:31
>>119
いくらでもいるだろ…
新人教育やってる奴に目を向けてみろ

121:デフォルトの名無しさん
08/11/12 12:42:50
C++やOcaml的な使える所だけOOというのがあるべき姿…と

122:デフォルトの名無しさん
08/11/12 20:54:26
>>121
どこにそんなことが書いてあるのか小一時間(ry

123:デフォルトの名無しさん
08/11/12 21:01:34
小一時間お茶しますか?

124:デフォルトの名無しさん
08/11/12 21:10:37
OOって結局コンパイラ様に重要なことを任せて
思考停止してるだけだよな

125:デフォルトの名無しさん
08/11/12 21:30:08
マクロって結局コンパイラ様に重要なことを任せて
思考停止してるだけだよな

126:デフォルトの名無しさん
08/11/12 22:24:31
マクロの挙動は定義を見れば分かるが、
テンプレートだの多重継承だの多用した結果
コンパイラ様が出すコードを想像するなど変態の技だ
だいたい、STLをまともにコンパイルできるコンパイラ
なんてないんじゃね？（笑）

127:デフォルトの名無しさん
08/11/12 22:34:58
>>123
可愛い女の子なら

128:デフォルトの名無しさん
08/11/13 01:32:13
STLやるぐらいなら
自分で言語作るわ

129:デフォルトの名無しさん
08/11/13 07:18:59
STLとオブジェクト指向の関係って？

130:デフォルトの名無しさん
08/11/13 11:09:13
OOPLとしても使用可能なC++の標準ライブラリの、さらに一部。

…関係ないと言えよう。

131:デフォルトの名無しさん
08/12/28 21:04:22
もうC++はOOPもできるテンプレート志向言語とか公言して良いんじゃないか

132:デフォルトの名無しさん
09/02/17 15:37:47
リレー回路はオブジェクト指向だよね

133:デフォルトの名無しさん
09/02/17 17:17:47
全然。

134:デフォルトの名無しさん
09/02/23 18:01:14
>>133
メッセージを伝えたら、バルブの開け閉めやら、過電流保護やら、照明やらしてくれるんだぞ

135:デフォルトの名無しさん
09/02/25 11:32:29
ハードウェアすべてが該当する件について

136:デフォルトの名無しさん
09/02/25 15:13:27
要はfacadeとかinterfaceというものなんだろうけど
それってOOPなの？

137:デフォルトの名無しさん
09/02/25 19:20:27
>>135
テレビの電源スイッチは、テレビの電源スイッチとしてしか使えない
分解して取り出せば別の用途に使えるが、取り外されたスイッチは既にテレビの電源スイッチじゃない

リレー回路のスイッチは、ポンプだろうがバルブだろうが関係ないONとOFFを制御するだけ

138:デフォルトの名無しさん
09/02/25 19:25:04
なんというgenericity…

139:デフォルトの名無しさん
09/02/26 10:45:19
>>137
>テレビの電源スイッチは、テレビの電源スイッチとしてしか使えない
ラジオの電源スイッチにも使えますね。

140:デフォルトの名無しさん
09/02/26 12:02:04
>>139
それは、ラジオの電源スイッチで、テレビの電源スイッチじゃない
仮に、テレビとラジオの機能を持った機械のスイッチだとすれば、それは、テレビの電源スイッチとは言えない
ラジオ機能付きテレビ(もしくは、テレビ機能付きラジオ)の電源スイッチだ

141:デフォルトの名無しさん
09/02/26 20:46:40
リモコンそのものはインスタンス。
Sharpのテレビを買ってきたら、付属するリモコンはその機種にしか使えない。
Sonyのコンポを買ってきたら、それに付属のリモコンはそれにしか使えない。

リモコンという抽象があって、リモコン付きの機械という抽象がある。
こういう考え方はどうでしょう？

142:デフォルトの名無しさん
09/02/26 21:53:16
>>141
抽象度が甘い気がする

むしろ、アンプやスピーカーなどバラバラに買ってくるコンポとか
AVシステムの方がオブジェクト指向だよね

143:デフォルトの名無しさん
09/02/26 21:58:55
現実の物引っ張ってきてオブジェクト指向だって言い張るのと、
それをオブジェクトモデルとして捉える(捉えられる)ことは違うんじゃないかな

144:デフォルトの名無しさん
09/02/26 22:09:08
リモコンはユーザインターフェースだけにインタフェースだね(そのまんま

ところで甘いっていうのはどういう程度を指すの
論理学の言葉を使えば弱いとか強いとかあるよね
ベン図で考えると狭い、広いとも言える

さて抽象度が甘いというのは
1.適用できる範囲が広すぎる
2.さらに汎化できる余地がある
どちらを指すのでしょうか？

145:デフォルトの名無しさん
09/02/26 22:49:56
>>144
2.だよ

146:デフォルトの名無しさん
09/02/26 23:08:19
リレー回路は、インターフェイスを継承して新しいインターフェイスも作れるし
動作内容も変更できるよ
そもそも、ハードワイヤードなプログラムだから

147:デフォルトの名無しさん
09/02/27 00:03:40
>>142
それはコンポーネント指向っていうんだお

148:デフォルトの名無しさん
09/02/27 00:17:35
>>137
あのな, on/off を伝えるメッセージ発信源としてかんがえるんだ
つか、オブジェクト指向ってハード屋がやってきたことの

＊＊＊＊＊劣化コピー＊＊＊＊＊

以外の何者でもない！！！

149:デフォルトの名無しさん
09/02/27 00:33:33
オブジェクト指向の利点は仕様をそのままクラスに反映できるってただそんだけだと思うな
ひねった抽象化したりしたらその時点で詭弁を使いだすイカレタ同僚と変わらないわけで
抽象化すればするほど利点が消えていくと思う

情報の共有化っていうの？
自分は他の誰かと仕事してるって感覚を身につけないと
一生わからんままテンプレート弄ってるＣ＋＋厨房と同じ道たどると思う

150:デフォルトの名無しさん
09/02/27 00:39:51
すっぽすっぽ先生の論文読んでから出直してください

151:デフォルトの名無しさん
09/02/27 12:06:45
あれだ、100％理解しないといけないと思ってるやつが駄目だ。

152:デフォルトの名無しさん
09/02/27 18:44:55
なんかへん

153:デフォルトの名無しさん
09/02/27 18:58:47
OO原理主義というか、シミュレーション主義なやつらがクソ。
現実世界をコード化、みたいなことに固執するやつら。

すなおにOOPしてればいいのに。

154:デフォルトの名無しさん
09/02/27 20:11:49
>>148
つ Software IC

155:デフォルトの名無しさん
09/02/28 02:26:55
現実世界はどうでもいいから
仕様書とクラスが１対１になっていればいいよ
サブのクラスはサブでコメント書いておきゃいいけど
とりあえず仕様書とプログラムがまったく一致してないような設計はダメだ
仕様書に書いてある物体ぐらいはオブジェクトにしてないと
オブジェクト指向の意味がまったくない

156:デフォルトの名無しさん
09/02/28 02:59:49
ようは入力の受付窓口と出力の出口の形を明確にする方法だろ？
と入門2ヶ月の俺が知ったかぶってみる

157:デフォルトの名無しさん
09/02/28 05:42:15
>>1
csosureたててんじゃねーぞ

158:デフォルトの名無しさん
09/02/28 05:44:11
オブジェクト指向を徹底すると可読性が著しく下がる件

159:デフォルトの名無しさん
09/02/28 06:03:08
>>158
それは君がヘッポコだから

160:デフォルトの名無しさん
09/02/28 10:47:55
オブジェクト指向の最大の功績は・・・
素人をプログラミングから遠ざけたこと。

OOPLだと、思いつくまま適当に書けばそれなりに動くプログラムが書きにくい。
だから、昔だったら自分でプログラムしたであろうような事でも
プロに依頼して、金を恵んでくれる。

そう考えると、シェルスクリプトで何でもかんでもできてしまう
UNIX/Linuxは職業プログラマの敵なのだ。

161:デフォルトの名無しさん
09/02/28 11:34:06
自称オブジェクト指向マスターって
引数中心で考えることを避ける人が多いような感じがする
しかもそういう人は「そこで発生させるべきでない副作用」をあちこちに散りばめる

162:デフォルトの名無しさん
09/02/28 11:45:41
副作用はCの文化だろｗ

163:デフォルトの名無しさん
09/02/28 12:13:47
ミスリード工作乙

164:デフォルトの名無しさん
09/02/28 14:50:40
>>161
それ、ただ単にOOが体得できてない「自称」OOマスターでしょ。

165:デフォルトの名無しさん
09/02/28 15:34:45
オブジェクト指向をもう少し機能や適用を限定させればいいんじゃないかな。
なんでもかんでもクラスにしないでこれはクラスにしなければダメだというものだけクラスにする。

166:デフォルトの名無しさん
09/02/28 16:11:49
おもしろいよね。
一人でプログラム組んでるときはC++の何でもできるってすごくうれしいのに
チームでプログラム組むことになるとマルチパラダイムの弊害が猛烈な勢いで襲い掛かってくる。

167:デフォルトの名無しさん
09/02/28 22:41:43
>>166
あのさ、class ってのが良くない
他人が作った class はドキュメントさえしっかりしてれば一応使えるけど,
現実には, ドキュメントはないわ, 抽象はでたらめだわ… で, どうしろとorz
Unix 系の C ライブラリの方が遥かにかわええわ!!!

168:デフォルトの名無しさん
09/02/28 23:14:39
「ええわ」でなく、「かわええわ」なのがふいんき(なry)でてる
70点

169:デフォルトの名無しさん
09/02/28 23:50:56
>>164
検討違いなツッコミどうも。
その自称オブジェクト指向マスターを沢山産んだのはオブジェクト指向自身なんだよ
カプセル化を言い訳に利用者の意図しない副作用を埋め込む奴多すぎ
本来意図されていた意味と違うとはいえ、カプセル化という言葉を広めてしまったオブジェクト指向の罪は重い
TDDがBDDに生まれ変わったように、オブジェクト指向も新しい何かに生まれ変わるべきだろう

170:デフォルトの名無しさん
09/03/01 00:07:07
>>169
> カプセル化を言い訳に利用者の意図しない副作用を埋め込む奴多すぎ

んだんだ！！！

オブジェクト内変数は呈の良いグローバル変数以外の何者でもない
get* とか set* の * にオブジェクト内変数名が使われているような
メソッドを大量に書く奴は、クラスを抽象化する時点で敗北してる

オブジェクトを現実世界のメタファーとして抽象する奴等は
*死* *ね* *ば* *い* *い* と思うよ

171:デフォルトの名無しさん
09/03/01 05:23:51
なるほど、そのへっぽこって君のことだったわけか。そりゃ見当が外れてた。

余計な副作用を残すのって、OO初心者がよくやる間違いだよね。
それを称してOOの罪というところがマヌケっつーか、、、、アホ？

172:デフォルトの名無しさん
09/03/01 05:24:42
>>170
で、そのオブジェクトはグローバルに参照できるの？www

173:デフォルトの名無しさん
09/03/01 10:53:10
>>170の適切な突っ込みにホッとした。

174:173
09/03/01 10:53:50
×>>170の適切な突っ込みにホッとした。
○>>172の適切な突っ込みにホッとした。

175:デフォルトの名無しさん
09/03/01 13:27:21
>>172
>>170ではないけど

>で、そのオブジェクトはグローバルに参照できるの？www
それはできないけど
メンバを大量に作るとグローバル変数と変わらない動作をするってのは俺はわかる
１クラスが異常にでかいソースにあたったときに苦労した

void setEdit()
{
　　transXXUnkoUnko(m_Bom);
}

void setEdit(int bom)
{
　　transXXUnkoUnko(bom);
}

単純に書くとこんな違いになるんだけど前者は追えるけど
後者はまったく追うことができない

176:デフォルトの名無しさん
09/03/01 14:07:15
>>175
しかし参照による相互作用はオブジェクト内におさまるよね？
プログラム全体がグローバル変数でガチガチに結合されるのと、
一応はオブジェクト単位に分離できるのとで、どっちがマシだと思う？

177:デフォルトの名無しさん
09/03/01 14:09:32
>>175
> void setEdit()

セッターがこのシグネチャってのは全く理解できないんですが。

> void setEdit(int bom）

1つのセッターで1つのメンバ変数にアクセスすることのどこが「大量」なのかサパーリ。

178:デフォルトの名無しさん
09/03/01 14:25:08
>>172
グローバルに参照したいから get* とか set* なんてアクセッサ作ってるんだろ
じっさいに名前空間切り替えることもせずに無節操にアクセスしてるしwW

179:デフォルトの名無しさん
09/03/01 15:52:53
おっとまた>>178が頓珍漢な返答を！

180:デフォルトの名無しさん
09/03/01 17:09:12
>>176
そりゃたしかにグローバルにしてしまうよりはいい
でも、そういうダメなものとどっちが・・・って議論をしたいんじゃなくて
そもそもこれってどーなのよ？
って言いたい

181:デフォルトの名無しさん
09/03/01 17:35:03
>>180
これ、とは？

182:デフォルトの名無しさん
09/03/01 17:45:53
昔、4つか5つの処理があれば何でもできると聞いたが、
オブジェクトはなんでこんなにややこしいの？

183:デフォルトの名無しさん
09/03/01 17:57:46
>>182
オブジェクトがややこしいんじゃなくて、
君の脳細胞が未分化なだけ。

184:デフォルトの名無しさん
09/03/01 17:58:33
>>180
それがわかれば、あとはオブジェクトの粒度を適切に設定すればいいんだ、ということに気付くはずだが？

185:デフォルトの名無しさん
09/03/01 18:11:03
つぶどってなんなんだぜ

186:デフォルトの名無しさん
09/03/01 18:13:37
>>184
粒度の問題なのか？と問いたい
だったらグローバル変数・関数だって小さいうちはアクセスしやすいし便利なだけだろ？
ただ、そのプロジェクトでの増加量を誰も予測できないから
やっぱりおかしくなってしまうわけで

俺がどう考えてるかというと
基本的にはメンバ変数ってのはダメなんだと思う

187:デフォルトの名無しさん
09/03/01 18:17:48
！？

188:デフォルトの名無しさん
09/03/01 18:18:55
クラスとインスタンスの違いが分かってない子の気配。

189:デフォルトの名無しさん
09/03/01 18:41:36
>>171
一人でコード書いてりゃいいニートと一緒にしないでくれよ
仕事でプログラム組む時は複数人でやるのが当たり前
お前の理想は現実とはかけはなれてる。そこわかってる？

190:デフォルトの名無しさん
09/03/01 18:49:31
>>184
他人が書いたコードも君は全て責任持って修正できる？

191:デフォルトの名無しさん
09/03/01 19:14:34
>>184
そこに明確な基準は無いよね
重要な部分を個々の考えに任せる時点でダメ

192:デフォルトの名無しさん
09/03/01 21:39:13
メンバ変数が追えないというヤツは関数内やファイルスコープ内の静的変数にもハマるだろう。

193:デフォルトの名無しさん
09/03/01 22:52:03
>>186
メンバ変数とグローバル変数とは全然違うぞ...

クラス内では、まるでグローバル変数のように見えるけどな

194:デフォルトの名無しさん
09/03/01 23:13:36
オブジェクトがたった一つなら、名前空間内のグローバル変数だけど、複数あったら事情が違うが。

195:デフォルトの名無しさん
09/03/02 00:04:59
>>191
個々の考えと言ってるうちは、何も理解してない
ということになってしまう。

196:デフォルトの名無しさん
09/03/02 00:07:54
だけど実際はクラスは大きくなってしまうわけで
そうなるとグローバル変数と変わらない動きをする
グローバル変数も管理できていれば問題はおきないってのは一緒なんだよね

でかいだけじゃなくて、１つのクラスを３つぐらいの使い方ができたり、
呼ぶ場所によって挙動を変えてるようなのもかなり複雑でまずい

197:デフォルトの名無しさん
09/03/02 00:16:27
>>196
int a, b;
としたとき、aとbの数値は連動するの?
a = 1;
としたら、bも1になってるの?

巨大化するクラスは、何かがおかしいと思うの...
俺みたいなニートなプログラマが気まぐれで作っているならともかく、プロが仕事で作っているのに1つのクラスが巨大化したら駄目でしょう

198:デフォルトの名無しさん
09/03/02 00:34:12
>>195
明文化された明確な基準のソースを示した人でなきゃそのセリフは吐けないはずだけど…
そうでないのに何コレ

199:デフォルトの名無しさん
09/03/02 00:38:36
グローバル変数と変わらないって言ってる意味が全く分からん
アクセサ経由でメンバ変数にどこからでも参照できるから、みたいなアホな意見？

200:デフォルトの名無しさん
09/03/02 00:42:03
staticか非staticかに関わらず複数メソッドから直接見える変数が存在することがダメって話…かと思いきや
違うのか
ちがわなければ同意

201:デフォルトの名無しさん
09/03/02 00:42:50
>>199
違うんだよ
１つのクラス内の関数同士の話

202:デフォルトの名無しさん
09/03/02 00:43:41
>>199
メイン関数まで内包してるような
超巨大クラスを想像しろ
メソッド同士が呼び出しあって動作する

203:デフォルトの名無しさん
09/03/02 01:03:54
>>201-202
怖い、怖いです...
冬なんですから怪談話は止めてください

204:デフォルトの名無しさん
09/03/02 01:08:53
ローカル変数もスコープ内のどこでも使えるから一緒ですか分かりません

205:デフォルトの名無しさん
09/03/02 01:11:38
オブジェクト指向を知らないまま、オブジェクト指向した末の惨劇ですね

206:デフォルトの名無しさん
09/03/02 01:48:54
信者共はあえてアホレスのみを捕まえて袋叩きにしたあと、
痛いとこついてるレスまでついでにまとめて
理解できない奴が悪いで済ませようとしてるけど

それでオブジェクト指向の暗黒面が消え去るわけじゃないだろ…

207:デフォルトの名無しさん
09/03/02 01:58:39
>>204
同じようになるよ
超長い関数で一番上でまとめて宣言されると
どこで使ってるかマジで不明

使う場所で適切に用意→破棄してくれと言いたい
でもＣ言語だとダメなんだっけ？

っていうかその前に長い関数作るなよと言いたい

208:デフォルトの名無しさん
09/03/02 03:36:46
ラッパークラスなんか超長い関数と同じ
生成期間も無駄に長い

209:デフォルトの名無しさん
09/03/02 05:41:58
ループカウンタとかどこで定義しようが何も問題無いだろ

210:デフォルトの名無しさん
09/03/02 05:49:46
忘れっぽいからさ。
使うところの近所で定義してもらわないと型とかあっさり忘れるんだわ。
老化が始まると全部関数の頭で定義なんてマジしんどい。

211:デフォルトの名無しさん
09/03/02 07:38:46
結局、メンバ変数を叩いてる人は、自分がプログラミング初心者ですと告白している、ということでFA？

212:デフォルトの名無しさん
09/03/02 09:07:23
>>211
とりあえずFPやってみろ

213:デフォルトの名無しさん
09/03/02 09:12:52
>>212
俺はMiranda, Gofer, SML, HaskellとFPやってきたが、>>211に同意だ。
OOを叩いている側の人間に明らかな技量不足が見える。

214:デフォルトの名無しさん
09/03/02 09:15:29
毎回アンチをひとまとめにして叩いてるあなたが言っても
自演にしか見えにゃーど

215:デフォルトの名無しさん
09/03/02 09:19:39
>>213
自由変数&mutableベッタベタだったのか…

216:デフォルトの名無しさん
09/03/02 09:23:18
>>214
技量不足以前に妄想性人格障害か。お大事に。

217:デフォルトの名無しさん
09/03/02 09:26:28
気軽にOOPを持ち込もうとして混乱する者どもの存在は分かった。

218:デフォルトの名無しさん
09/03/02 09:27:28
>>215
へー、Mirandaでどうやってmutableを実現するのか、説明してよwww

219:デフォルトの名無しさん
09/03/02 09:28:44
このスレには
他人のクラスの粒度どころかライセンス的に修正不可なソースまで修正できる自称スーパープログラマ(笑)
が沢山いるみたいだな
BREWとかどうすんのマジで

220:デフォルトの名無しさん
09/03/02 09:33:25
>>218
できないから移行(挫折)したんだろ？w

221:デフォルトの名無しさん
09/03/02 09:34:43
メンバ変数ってまでに広げたら、それこそ状態量を持つオブジェクトすべて指すようになってしまうな
流石にそれは極論だと思うので、もう少し範囲を狭めて考えてみる。
「グローバル変数と同じ」という性質を「何処で誰が触っているかわからない」ということだと仮定すれば
恐らくパブリックフィールドの事を叩いてたんじゃないかなと考えている。

222:デフォルトの名無しさん
09/03/02 09:38:08
>>221
だとしても、そのオブジェクト自体がグローバルに参照されていなければ
メンバ自体がpublicでも「何処で誰が触っているかわからない」状態にはならないよね。

223:デフォルトの名無しさん
09/03/02 09:39:49
>>221
> 恐らくパブリックフィールドの事を叩いてたんじゃないかなと考えている。

じゃなくて、もっとひどい。

>>201
> １つのクラス内の関数同士の話

↑このように、クラス、という静的な単位で困っている様子。

食べることが悪いんじゃない。
食べ過ぎることが悪いんだ。

メンバ変数が悪いんじゃない。
メンバ変数が多すぎたり、
クラス内の関数が多すぎたりでかすぎたりするのが悪いんだ。

224:デフォルトの名無しさん
09/03/02 09:55:22
そうか、全然読めてなかったよ

折角クラス内だけにスコープを止めても、そのクラス内がカオスだったら
人間が把握できない程度に複雑になる可能性があるという点ではグローバル変数と同じ
と解釈した

「とりあえずクラスにすりゃなんとかなるじゃんｗ」っていうような安直なOOPに対する批判なのかな？

225:デフォルトの名無しさん
09/03/02 10:02:21
逆にアンチOOPに訊きたいのは、

プログラム全体が1つのクラスになってしまうような巨大クラスは問題だ、という主張なんだよな？
まあ、それはそれでいいけど、

(1) そもそもクラスにしないで関数や手続きとして実装しても同じ問題になるし、
関数や手続きとして実装してうまくいくのなら、それをそのままクラスにしても、
それなりにうまくいくのでは？

(2) その巨大クラスのインスタンスは何個できるの？
もしインスタンスが多数できるのなら、参照関係の複雑さも多少は整理されているのでは？

ぜひ答えてほしい。

226:デフォルトの名無しさん
09/03/02 10:17:48
多少複雑さが軽減されるからといって、
把握できないぐらいのものが把握できないぐらいのものに変わっても意味ないよね。
OOPを使って複雑なものを人間が把握できる程度まで落し込めるような使い方じゃないと、
同じどころかOOAのコストの分だけ損になると思うよ。
こんな考え方でもアンチOOPになるんですか？

227:デフォルトの名無しさん
09/03/02 10:18:09
アンチはしらんが、どっちで実装しても同じならわざわざ手間のかかる
手段をとらなくていいのでは？

228:デフォルトの名無しさん
09/03/02 10:47:09
>>227
手間かけていないから巨大クラスになるんじゃねーの？

229:デフォルトの名無しさん
09/03/02 17:57:38
巨大クラスを作るってのは、オブジェクト指向が必要だとか不要だとか言う前に
構造化プログラムとは何かから始めないと駄目だと思うの

230:デフォルトの名無しさん
09/03/02 22:37:31
>>229
> 構造化プログラム
以前の問題で、
「自分が何をしなければならないか？」
の、分析ができてないんとちゃうん？

「作らんとあかん物の分析をやってない」
としか思えんのよ

231:デフォルトの名無しさん
09/03/02 22:55:58
つまりほとんどのプログラマはOO以前に構造化すら満足に出来てないと。

232:デフォルトの名無しさん
09/03/02 23:03:21
やはり構造化よりオブジェクト指向の方が頼りにされていたクライアんトとの戦いで
おれは納期に遅れてしまったんだがちょうどマネージャがわきはじめたみたいでなんとか耐えているみたいだった
おれは家にいたので急いだところがアワレにもCプログラマがくずれそうになっているっぽいのが携帯で叫んでいた
どうやらプログラマがたよりないらしく「はやくきて～はやくきて～」と泣き叫んでいるチームメンバーのために俺はオブジェクト指向を使って普通ならまだ出来ない時間できょうきょプログラミングすると
「もう出来たのか！」「はやい！」「きた！オブジェクトきた！」「メインプログラマきた！」「これで勝つる！」と大歓迎状態だった

次ページ