オブジェクト指向を理解できんとが何で悪いとや？

1 ：仕様書無しさん：03/08/12 02:20

なんでですか？

2 ：クンクン(かじゅ猫係) ◆Yzu/FHch4w ：03/08/12 02:21

3 ：仕様書無しさん：03/08/12 02:21

なんとなく2ダ！

4 ：仕様書無しさん：03/08/12 02:24

九州人は理解しなくていいよ

5 ：仕様書無しさん：03/08/12 02:27

豚骨ラーメン食って寝ろ。

6 ：仕様書無しさん：03/08/12 02:27

となむ語り伝えたるとや

7 ：クンクン(かじゅ猫係) ◆Yzu/FHch4w ：03/08/12 02:29

あら。。。。
豚骨ﾗｰﾒﾝ好きよ。。。
ククーン。。。

8 ：仕様書無しさん：03/08/12 02:32

脂っこいのは嫌い。

9 ：クンクン(かじゅ猫係) ◆Yzu/FHch4w ：03/08/12 02:33

あら。。。
豚骨はさっぱりしてるわよ。。。
紅生姜が良いわね。。。

クキューン。。。
お腹が空いたわん。。。
クククのクン。。。

10 ：仕様書無しさん：03/08/12 02:35

OO、ポインタと並び厨が嬉々として寄ってくる話題

11 ：仕様書無しさん：03/08/12 02:40

オブジェクト思考
オブジェクト嗜好
　別にどうでもいいや

12 ：仕様書無しさん：03/08/12 02:44

オブジェクト指向だとどういうメリットがあるのかマジレスして下さい

13 ：仕様書無しさん：03/08/12 02:47

>>1
本場九州の豚骨ラーメンは
脂っこいのかそうでないのか?

話はそれからだ。

14 ：仕様書無しさん：03/08/12 02:51

単純に関数呼び出しの関係だと呼び元も扱われているデータについて把握していないといけないなど、厄介事が増える
クラスの関係をちゃんと作ってあれば拡張(バグfix)する時、呼出元に依存しないでOK

15 ：クンクン(かじゅ猫係) ◆Yzu/FHch4w ：03/08/12 02:53

本場九州の豚骨ラーメンはコッテリしてるみたい。。。

ククーン。。。食べたいわん。。。

16 ：仕様書無しさん：03/08/12 03:01

そんな事より替え玉について語れ

17 ：仕様書無しさん：03/08/12 03:03

九州出身の友人によると
東京のは豚骨ラーメンじゃないそうだ。

「あんなの豚骨じゃねーよ」

だって。

18 ：仕様書無しさん：03/08/12 03:05

あれ、ものすごい画期的なシステムですよね。
大盛りだと麺が伸び気味でイマイチな感じですが、替え玉ならそんなことないですものね。
替え玉、替えスープサイコー!

19 ：仕様書無しさん：03/08/12 03:08

ようするに麺を食い終わっても
新たに麺オブジェクトをnewすれば良いわけだ。

20 ：仕様書無しさん：03/08/12 03:17

いやこの場合、オヤジに頼んで麺オブジェクトを用意してもらうべき

21 ：仕様書無しさん：03/08/12 03:23

確かに。
オヤジオブジェクトに「替え玉ちょうだい」
メッセージを送る方が良いね。

22 ：仕様書無しさん：03/08/12 03:38

麺替え玉 = 親父.get替え玉();

替え玉の詳細な要素は知らなくても、ラーメンは食えるわけだ。
他の客の余り物をかき集めて出してるかもしれないし、
実は裏でベビースターラーメンゆでてるかもしれないが、
客としては替え玉が出てくれば問題ないわけで。

23 ：仕様書無しさん：03/08/12 08:02

１．カプセル化→グローバル変数を撲滅しやすい
２．継承、多態性→コードの再利用がいろいろな形でできる

大雑把に言うとこの２点に尽きると思うが

24 ：仕様書無しさん：03/08/12 08:22

>23 いつの時代の話だ？

25 ：仕様書無しさん：03/08/12 08:44

>>24
いや、いつの時代でも>23の言うことが正しかったことはない。

26 ：仕様書無しさん：03/08/12 09:08

君等もよく飽きないね
新参者が入れ替わり立ち代りレスしてるのかもしれんが

27 ：仕様書無しさん：03/08/12 09:14

>26 そういうあんたが一番飽きてないだろ。
書き込みしねーと気が狂いそうなのか？

28 ：仕様書無しさん：03/08/12 10:14

ところでアレの撮影場所って周遊館高校やねんな。

29 ：仕様書無しさん：03/08/12 20:58

結局、巨大なソフトウェアになってくると、どこで何してるかさっぱり解らないから
何人(何十人?)かのオブジェクト君に何か頼んでやってもらう、って単位で把握しようって計画

30 ：仕様書無しさん：03/08/14 21:15

>>22は創価学会員

31 ：(*￣д￣)y─┛～～：03/08/14 21:26

やっぱりオナニー
http://www.k-514.com/

32 ：仕様書無しさん：03/08/14 22:13

OOという名の順次手続き主義的設計・実装が主流だから大丈夫。
クラスっていうモジュールを細かくしたものと、メソッドと言う名の
関数呼び出しを覚えればOO知ってることになります。

33 ：仕様書無しさん：03/08/14 23:22

@@@@
OO-|
|ε__|
= ^^^^ =3
| |
U^^^U

34 ：仕様書無しさん：03/08/14 23:25

:@@@@
::OO-|3
::|ε__|
:::⊇^^ =3
::|----|
::U^^^U

35 ：クンクン（hanajan係）：03/08/15 03:51

クーン。。。
なるほどね～。。。

ここの板のクンクンさんは、ネタスレバスターとしての使命感を感じているのかしら。。。
そうだとすると、物体Ｘ屋の教練所に入所してからでないと難しいのよね。。。

クククククククーーーーーーーーーン。。。

36 ：仕様書なしさん：03/08/15 04:41

オブジェクト指向は糞！
漢なら手続き型言語だろ。
書いた事が書いたとおりにそのまま実行できるのは素晴らしい。

37 ：仕様書無しさん：03/08/15 06:53

オブジェクト指向だと、書いたのと違う動作になるの？

38 ：仕様書無しさん：03/08/15 13:56

クラス１０個くらいですむバッチにデザパタ使ってクラス数増やしてもしょうがない。

39 ：仕様書無しさん：03/08/15 19:15

九州人の気質は硬いので一枚岩のようなソースをよく書きます。

40 ：山崎渉：03/08/15 22:20

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

41 ：仕様書無しさん：03/08/15 22:26

バッチって、OOに向くと思うんだが。

42 ：山崎渉：03/08/15 22:27

43 ：仕様書無しさん：03/08/17 23:49

オブジェクト指向は、終わったんだってさ・・

ttp://www.atmarkit.co.jp/fdotnet/opinion/yoshimatsu/onepoint08.html

44 ：仕様書無しさん：03/08/17 23:51

>>1
高校大パニックのﾊﾟﾛだよな？
オヤジｗ

45 ：44：03/08/17 23:54

てか漏れもオヤジか。
浅野温子の乳首みれましたな。

46 ：仕様書無しさん：03/09/09 23:59

だいたいオブジェクト指向なんか必要ねえよ。
オブジェクト指向なんて継承が要らないクラスを設計できないような
馬鹿のための考え方だろｗ

47 ：●のテストカキコ中：03/09/10 00:03

http://ime.nu/ula2ch.muvc.net/

48 ：仕様書無しさん：03/09/10 13:13

普通に、オブジェクト指向言語を使うのに、オブジェクト指向の知識が必要でしょ。
オブジェクト指向を知らずに、動画関連とかフィルターとかどうやるん？
「ワタシにはオブジェクト指向が理解できないのでその仕事できません」
と断るつもりなの？

オブジェクト指向が必要でも無いのにオブジェクト指向を持ち出すべきかどうかについてなら
「知っておいた方がいい」
かな。
何から何までオブジェクト指向でやるとコード量が多くて死ぬが、部分的に適用するとものすごく楽になる。
何より、言語が提供する機能はすべて使うべきだ。機能を理解するために、大抵、オブジェクト指向の知識が必要になる。

49 ：仕様書無しさん：03/09/10 22:16

>48
それはそうだが>46は別にOO言語を使わないし
使う気もないだけの話だと思うが。

50 ：仕様書無しさん：03/09/11 01:14

>>49
いや、だから、
もし>>46に対して動画関連とかフィルターの仕事が回ってきたら
>>46はどう対処するのかってことを>>48は言ってるんだよね？
それにぜんぜんこたえてないじゃないか。

51 ：49：03/09/11 08:04

46や48=50の会社の状況は知らないが、
普通は本人が達成不可能な仕事はマネージャや
営業の方でそいつに回さないようにするもんじゃないの。

もちろんその結果「何の仕事も来ない」ように
なってなお改善の余地がなければ待っているのは
肩たたきだろうが、それを危惧する必要もない程に
46には非OOの仕事が普通に入っているんでしょ。

っていうか、別にJavaやC++プログラミング以外の
仕事も世の中にはいくらでもあるわけだが。

52 ：48!=50：03/09/11 12:38

まぁ「ＯＯ使った仕事は来ないようにする」ってのは判ったような判らないような。
時代はどんどん変化していく。交換機なんて磐石っぽかったし金のなる木だったけど、もう仕事無いし。

後半の方はどうなの？
設計段階で
「ここってこういうオブジェクト作っちゃえば皆んな楽でイイでしょ」
って話が出てきても
「俺はオブジェクト指向わからないからその設計パス」
とか言い出すの？

それはあんまりにも、痛いＳヨのスレのネタっぽくないかい？

53 ：仕様書無しさん：03/09/12 06:16

そろそろ具体例を出してくれないかな。
こっちはオブジェクト指向が分からないんだから、抽象的な言葉で説明されても理解出来る訳ないのよ。

54 ：仕様書無しさん：03/09/12 06:35

全ては　習うより慣れよ　だよ。

55 ：仕様書無しさん：03/09/12 06:54

>>50
何でそこまで動画とフィルタにこだわるんだい？
もしかして動画とフィルタはオブジェクト指向と密接なつながりがあって、
オブジェクト指向でなければ作れないと思っているのかい？

56 ：仕様書無しさん：03/09/12 08:11

ほんと低脳のばかばっかだな

>>1 悪くはないが頭わりぃなぁ

57 ：仕様書無しさん：03/09/12 12:56

オブジェクト指向＝カッチョイー！
どうだ、まいったか！
厨房どもよ、カッチョよくなりな。

58 ：仕様書無しさん：03/09/12 12:59

>>53
あんた、この仕事向いてないよ。

59 ：仕様書無しさん：03/09/12 13:27

>>1は佐賀人。
無理だよ。おまいには。

60 ：仕様書無しさん：03/09/12 13:29

九州の人なら教えてくれ >>1

長崎県に属する五島列島の島々は、分裂症など精神疾患の多発地帯である。
それは筆者の経験上、全国平均の１００倍に及ぶと推定される。

全国平均でおよそ130人に1人である事が知られているので、ほとんどの人が発病するという事か？

61 ：仕様書無しさん：03/09/12 15:16

オブジェクト指向言語を採用したオープンソースプロジェクトは
失敗率が高いというのは、知ってる人は知ってる事実。

62 ：仕様書無しさん：03/09/12 19:34

>>58
オブジェクト指向推進者はアフォですか？
抽象的な言葉しか使えないのですか？
説明する能力は無いのですか？
部下を使いこなす能力無さそうですね。
このオナニー野郎が。

63 ：仕様書無しさん：03/09/12 19:41

何が悪いかって？頭が悪い。

64 ：仕様書無しさん：03/09/12 20:29

↑性格が悪い。

65 ：仕様書無しさん：03/09/12 22:23

>>43
@ITには開発現場よりも転職業界やコンサルがスポンサーとしてかなりついてるので、
時代を先取りしすぎというか、現場で土台固めができてない新技術のコラムが
ときどき載るように思う

66 ：宮崎出身マン：03/09/12 22:36

>>1
は宮崎県人であると？

C++は面白かとよ。

67 ：宮崎出身マン：03/09/12 22:36

ああ・・なんか変だ。（ｗ

68 ：仕様書無しさん：03/09/12 22:37

>>1
俺も良くシラネ。
１３年くらい前にちょっと齧ったまま、ほったらかしにしてきた。
でも、さすがに勉強しとかないとやばそうな雰囲気やね。
めんどくさいけど時間を割いてみるべえ。

69 ：仕様書無しさん：03/09/12 22:37

>61
具体例聞かないと納得できないなー。

70 ：宮崎出身マン：03/09/12 22:39

なんかラーメンの話が出てるので
関係ないけど、横浜駅の地下レストラン街にある一風堂のラーメンはうまい！。
全部盛りがお勧め。

71 ：仕様書無しさん：03/09/12 22:48

漏れは普通に横浜家の角煮ラーメン。川崎なら天下一品に行く

72 ：仕様書無しさん：03/09/12 22:50

新横浜のラーメン館で全部喰う

喰って喰って喰いまくる

73 ：仕様書無しさん：03/09/12 23:05

ラーメン食べたい。
ククンのクーン。。。

74 ：仕様書無しさん：03/09/12 23:07

ラーメン食うなら、博多長浜たい！

75 ：仕様書無しさん：03/09/12 23:11

いつもいつも>>23みたいなのに対して>>24みたいなﾚｽしかない。
なんで？
結局分かってるふりしたいだけだから？

76 ：仕様書無しさん：03/09/12 23:17

六角屋ヽ(´ー｀)ノﾏﾝｾｰ

77 ：仕様書無しさん：03/09/12 23:43

>>76
うちのすんでる所の近くに六角屋ボヌールという菓子屋がある。
そこにはココ出身の力士「益荒雄」にちなんで
益荒男饅頭を売っている。

つまり言いたいことは、腹減った。

78 ：仕様書無しさん：03/09/13 07:28

コードの再利用なんてほんとにやってんの？
古いコードをだましだましメンテしながら使いまわしてるのが現状でしょう

79 ：仕様書無しさん：03/09/13 08:40

コードの再利用も、クラスの再利用もほとんど
ただの宣伝文句。
真にOOが再利用に貢献できるのは、パターンの
再利用であったりするんだけどね。

80 ：仕様書無しさん：03/09/13 10:46

ライブラリ化するのと何が違うのか具体例を上げて下さい。
誰か。

81 ：仕様書無しさん：03/09/13 10:51

比較的安全に機能拡張できる方がメリットを感じる。

>80
あなたにとっての「ライブラリ化」の定義を教えれ。

82 ：仕様書無しさん：03/09/13 11:25

再利用をOOのメリットと持ち上げるのは素人か
騙された香具師だけ。
まずはカプセル化をメリットと捉えるべきだろう。

その意味では実はObject-Orientedじゃなくて
Object-basedでも結構足りるのだが。

83 ：仕様書無しさん：03/09/13 11:51

カプセル化だけならCでも実現できるはなし。

84 ：仕様書無しさん：03/09/13 12:11

クラスの継承って必要？

あれいらなくても不自由しないと思うけどどうよ？

85 ：仕様書無しさん：03/09/13 12:15

>>84
　GUIクラスライブラリを使う方としてはあった方がいいね。

86 ：剛万太郎 ◆uuJAVAsys2 ：03/09/13 12:42

オブジェクト指向で組まないプログラミングは
手順を書いているだけだ

オブジェクト指向で書くと言うことは
仮想の世界を書くようなものだと思う

自分が神になり、必要な物を想像し、振る舞いを決定する
神の意志により支配された世界を作る
これがオブジェクト指向なのだ

87 ：仕様書無しさん：03/09/13 12:53

>>86
なんか違う。

88 ：仕様書無しさん：03/09/13 13:08

message("86").getAuthenticity();

89 ：仕様書無しさん：03/09/13 13:13

>>81
複数のソースで使用する汎用性のある関数やデータの集まり。

・・・つか、定義も何も、オブジェクト指向しない側にとっちゃ、上記の意味くらいしかないぞ。
早く具体例くれ。

>>86も神なら答えろよな。

90 ：Shady：03/09/13 13:13

○・.　　。○.・　　☆１０００万欲しい人必見♪　　.・　○　・　。
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
☆★☆現金１０００万円が当るチャンス！☆★☆
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
フルーツメール
************************************************************
【その他キャンペーン】
１０００万の他に毎回現金１００万円プレゼント!!!!
☆☆☆ 車プレゼントキャンペーン!!!!☆☆☆
豪華賞品がもらえる！ビンゴゲーム（毎週実施）メール受信、紹介で現金がすぐ貯まる！
毎日豪華賞品が当る☆毎日懸賞☆もちろん完全無料☆入会、退会いつでもできます
*************************************************
http://banana.fruitmail.net/cgi/introduce_jump2.cgi?1833866

91 ：剛万太郎 ◆uuJAVAsys2 ：03/09/13 13:43

>>89
クラスの記述はいわば遺伝子だね。我々オブジェクト指向プログラマ
のみが触れる事を許された神聖なものなのだ。

単なる関数やデータの集まりだなんて
なんて罰当たりな連中なんだろうねえ。ぷんぷん

92 ：仕様書無しさん：03/09/13 13:52

>>86
神になったつもりでも、実はコンピュータの奴隷としてこき使われている罠。
>>91
その遺伝子にもバグがある罠

93 ：仕様書無しさん：03/09/13 15:29

オブジェクト指向のメリットはプログラムをクラスとして定義したこと。
それによりプログラムを構造化(細分化）しやすくなった。
大規模なプロジェクトがやりやすくなったのと
JDKみたいなくそでかいライブラリを作るときに威力を発揮する

94 ：仕様書無しさん：03/09/13 16:46

>>93
それだ

95 ：仕様書無しさん：03/09/13 16:52

>>93
その前のモジュールとかユニットとかの違いは？

96 ：仕様書無しさん：03/09/13 18:08

オブジェクトが便利だってのは分かるよ
カプセル化ってかメンバやメソッドの隠蔽はありがたいと思うよ。
でもオブジェクト指向はやり杉って感じがしないか？

97 ：仕様書無しさん：03/09/13 18:51

>>96
バカと鋏はつかいよう

98 ：仕様書無しさん：03/09/14 09:44

>>96
そうか？流行り杉って事は必要以上に使われているって事だよな。
じゃ、オブジェクト指向に頼らずに済む時ってどういう時？

99 ：仕様書無しさん：03/09/14 10:15

>>98
もちけつ
96 は、「オブジェクト指向は、やりすぎ」といっているわけで、
「オブジェクト指向、流行りすぎ」と言ってるわけじゃないと思うぞ

漏れは、オブジェクト指向に依存しまくりなわけだけどな

100 ：89：03/09/14 13:13

>>91
単に、”明確に閉じた領域にコードが書ける”くらいにしか読み取れねーよ。
オブジェクト指向と関係ないじゃないか！

オナニー野郎が。

>>93
だからそれだけではオブジェクト指向とはいえんだろ。
単に分けただけ。Cでもソース分けて隠蔽したいのをstatic宣言するだけで同じような事は出来る。

具体例をかけない奴はオブジェクト指向ﾏﾝｾｰなどと抜かすなオナニー野郎が。

101 ：仕様書無しさん：03/09/14 13:37

漏れに言わせればOOのメリットは抽象クラスを
作成できること、に尽きるんだが。

102 ：仕様書無しさん：03/09/14 13:59

＞抽象クラスを作成できること

そうすっとなんかいいことあんの？

103 ：仕様書無しさん：03/09/14 14:08

運がいいと効率的に再利用できるw

104 ：仕様書無しさん：03/09/14 14:14

再利用の快感を知ってしまうともう後戻りできないわよｳﾌｯ

105 ：仕様書無しさん：03/09/14 14:24

>>103
運かよｗ

106 ：仕様書無しさん：03/09/14 14:28

>>105
ウン

107 ：仕様書無しさん：03/09/14 15:13

>>102
いいか、こういう風に作るんだぞ。こういう風にだ。
って、にだにだ説明しなくても済むかも。

108 ：仕様書無しさん：03/09/14 15:16

ニダニダ言う奴は(ry

￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧
　<=(´∀｀)
　（　　　　）
　｜｜　|
　〈_＿ﾌ＿ﾌ

109 ：仕様書無しさん：03/09/14 15:25

>>96
純粋なOOは確かにやりすぎだ。だからC++みたいな言語が出てきた
しかしコンピュータの処理能力が上がってOOでごり押しできるようになったから
基本的にはOOでプログラム組んだほうが効率がいい。

つーかIntelは１０GHzのCPUまでは作れるって言ってるんだから
もっとリソースふんだんに使った効率的な開発手法がでてきてもいいとおもうぞ

110 ：仕様書無しさん：03/09/14 15:47

っていうか1THzぐらいまで作って俺らを楽にしてくれ。
1Tあれば、構造のみに固執できる。無限ループにも気づかない。

111 ：仕様書無しさん：03/09/14 15:49

>無限ループにも気づかない。
気づくだろｗ

112 ：仕様書無しさん：03/09/14 16:17

>>100
似たようなデータ型(クラス)A，Bから、ともにデータ型Cが生成できるとする。
(OOの方は、A,Bはmethod()を持つXを拡張しているとする。)

OOなら、
X p;
X q;
・・・(ここでp←型Aobj，q←型Bobjが起こるか、上の宣言が引数となっている)
c = p.method();
c = q.method();

非OOなら
A p;
B q;
・・・
c = funcA(p);
c = funcB(q);
（左辺は必ずリターンコードにしろ、などという議論は置いておいて）

「c =」をする側が多くの情報を必要としているのは、どちらか？

超ミクロな話だと、キャスト時に継承関係をチェックして、
絶対にありえないキャストは実行時例外ではなくて、コンパイルエラーにできる
という利点もある。

あと、
93>>JDKみたいなくそでかいライブラリを作るときに威力を発揮する
は大正解だと思う。非OOでアレを書くのはつらすぎ。

113 ：仕様書無しさん：03/09/14 17:23

オブジェクト脳のつくり方

これ嫁。１，２，３章だけでお腹いっぱい。他の章は能書きだから見なくて良い。

114 ：：03/09/14 17:36

Ｃでプログラムを組みまくれ。

もっと楽な方法ないのかよ! と思った時にオブジェクト指向は宿る。

115 ：仕様書無しさん：03/09/14 17:40

>>114
いや、JAVAで手続き指向無理やり使ってたら
そのうちオブジェクト指向が使いたくて使いたくてたまらなくなってくるぞ

116 ：仕様書無しさん：03/09/14 18:01

今のプロジェクトのソース、$ head -200 hoge.java してもprivateフィールドしか抽出できない。
メソッドは1000～2000行が当たり前。ヘッダのコメント見ると既に「共通関数」とか書いてあるし。
更に、OOPは継承が全てだと思い込んでるみたい。５～１０階層当たり前。更に更にメソッドの引数は１０～２０当たり前。

117 ：仕様書無しさん：03/09/14 18:11

>>114
そうそう。最近オブジェクト指向をやっと理解してきて
それまで冬眠状態だったちょっと規模の大きいゲームの製作が突然息を吹き返した。
慣れると氏ぬほど分かりやすいんだわ、オブジェクト指向って。
CじゃなくてVB6なんだが。(w
無理やり継承も使ってるが改めてVBはｳﾝｺと思うようにもなった。

118 ：仕様書無しさん：03/09/14 18:12

>100
＞だからそれだけではオブジェクト指向とはいえんだろ。
＞単に分けただけ。
＞Cでもソース分けて隠蔽したいのを
＞static宣言するだけで同じような事は出来る。

カプセル化が簡単にできるのがメリットなんだよ。

何だか、こういう反論を聞くときりがないな。
「便利である」ということに聞く耳を持たない奴っていうか。

Internet Explorerを使ってる奴にタブブラウザを勧めて
「何でそんなもんいるんだ？」
と反論されるようなもので、
「便利である」ことを説明するのは難しいのかな？

119 ：仕様書無しさん：03/09/14 18:21

>116
悪いが、それはどう見ても「ダメなOO（と称した）
設計実装」の例であって、OO自体を否定する論拠
にはならんよ。ダメな設計ではメリットは出ないって
のは当たり前。
そんなプロジェクトに関わってるのには同情するけどな。

良いOOの例が欲しいというなら、Squeakのカーネルの
ソースでも読んだらどうだ？勉強になるぞ。

120 ：仕様書無しさん：03/09/14 18:24

つーかstatic宣言だけだと隠蔽しか実現できん。
これをクラスと比べるなぞ片腹痛い

121 ：仕様書無しさん：03/09/14 19:34

すべてfinalで逝け！

122 ：89：03/09/14 19:39

>>112
まだ抽象的だな。
非OO例といいつつクラス使ってるし。
まあメソッドコールと関数コールの違いを書きたかったんだろうが。
つーか、これだと形式的な違いしか分からん。
もっと突っ込んでくれ。
あと、型チェック云々言ってるが、言いたい本質的な点(OO)はこれとは違うよな？

>>118,120
だから具体例挙げろよ。オナニー野郎が。
OOでないと致命的にダメだという具体例無いのか？
>>118の書いた＞Internet Explorerを使ってる奴にタブブラウザを勧めて
なんて、言わせてもらうと「OOなんてそれくらいのメリットしかないのですか？」
だよ。ばか。

オマエラOOﾏﾝｾｰなんていいつつ、使いこなせてないだろ？
図星？

123 ：仕様書無しさん：03/09/14 19:47

>>122
ごめんなさい。
フルーツクラスからバナナ・りんご・みかんクラスを継承
させて喜んでました。
もうしません。

124 ：仕様書無しさん：03/09/14 19:47

OOじゃなきゃ駄目なものなんて、多分ほとんど無い。
手段の一部。
だけど、>>89の思っている方法も手段の一部に過ぎない。
自分の知らない手段を提示されたからって、けなす理由にはならない。

125 ：仕様書無しさん：03/09/14 19:51

>>122
抽象的な概念でプログラムを説明できるってのがOOのいいところなんだが・・・
具体的な例の一つとして>>101が書いてあるし
だめな例は>>116で書いてあるだろ

126 ：89：03/09/14 19:52

>>124
別に貶してないけど。
OOﾏﾝｾｰという輩に対して、何のどういう部分がﾏﾝｾｰなのか、抽象的なのじゃなくて
具体的例を挙げてくれというのが始まり。

そういうのが無いから理解出来ないんだよ。というこのスレ名に合わせた問題提起。

127 ：89：03/09/14 19:56

>>125
その程度の説明で本当に理解出来るなら、誰も困らないと思うが。

128 ：仕様書無しさん：03/09/14 20:00

>>89は偉くなったつもりなのか？
>>89が説明すればいい話では？
それとも説明できないのに偉そうにしてるの？

129 ：89：03/09/14 20:03

>>128
理解出来ない人に説明を求めるバカな>>128が存在するスレはここですね？

130 ：仕様書無しさん：03/09/14 20:05

89は自分から積極的に理解しようとしているようには全然見えないのだが。

131 ：仕様書無しさん：03/09/14 20:12

具体的に、て言われてもなぁ。。。

「今までぼくたちは、

しゃぶる；
剥く；
食べる；

こんなプログラムを、かいてきました。これだと、なんだかえっちですよね。
なのでこれからは、もっとわかりやすいプログラムを、かけるようにしました。

りんごをしゃぶる；
りんごを剥く；
りんごを食べる；

わかりやすくなりましたね。こんなふうに、りかいするのが
むつかしかったり、ごかいされやすいプログラムを
わかりやすくするのが、おぶじぇくと指向です」

これでどうよ？>>89

132 ：116：03/09/14 20:17

>119
誰がOOを否定してるんだよ。OO勉強中なんだって。
あんたの反応みると、モデリングがすごく下手な奴に思える。

133 ：89：03/09/14 20:21

抽象野郎が多いな。

概念が分かってても、実戦では使いこなせないって言えば分かるか？
オブジェクト指向が理解出来ない奴のほとんどがそうじゃないか？

>>130 見えないだけです。
>>131 バカですね？

>>112みたいにお長居しますよ。

134 ：仕様書無しさん：03/09/14 20:25

ていうか。。。
オブジェクト指向を使いたくない＝Ｃ++が肌に合わない
じゃないのか？

オブジェクト指向そのものの好き嫌いとは別じゃないの？

135 ：仕様書無しさん：03/09/14 20:27

なんだ結局、89はOOが分かってないし、何よりも
分かろうとしないだけじゃん。あほくさ。

分かっている人がその良さを利用して実際に使って
いるものを、分かってない側の人間が「そんな物は
役に立たん」って決めつけようとしている構図って
ものすごーく滑稽なんだが。

136 ：89：03/09/14 20:27

別に嫌いではないんだけどね。

137 ：仕様書無しさん：03/09/14 20:29

役に立ちそうだから教えてと言わない限り>>89に的確な答えを提供する奴は現れない。

138 ：89：03/09/14 20:30

>>135
誰が役に立たないといったのか？
それを具体的に説明してみろって言ってるに過ぎないのだが。
ほとんどの奴が抽象的な事しか言わないからオナニー野郎ですか？っていってるのだよ。
もはや能無しですか？

139 ：89：03/09/14 20:31

>>137
別にいいよ。いつまでも抽象オナニーしてなさい。

140 ：89：03/09/14 20:32

とゆーか、説明できるほど理解してるヤツはいねーのが真実なんじゃないの？

141 ：仕様書無しさん：03/09/14 20:33

いっぱい釣れたね、くす。>89

142 ：仕様書無しさん：03/09/14 20:33

世の中すべてのものが具体的だと思うな。
具体的なものは、他のものに応用ができないのだ。
いろいろなことをOOであらわせると考えるなら、
OO自体は抽象的で、そのものにあわせていろいろ変化できると考えるのが妥当。

143 ：89：03/09/14 20:38

>>141
くす。

>>142
なんか勘違いしてるな。
”具体例”って分かります？

＞OO自体は抽象的で、そのものにあわせていろいろ変化できると考えるのが妥当。

例を挙げてみてって言ってるのよ。

”OOを具体的に説明しなさい”が問いなのでは無い。

144 ：仕様書無しさん：03/09/14 20:39

いや>>89の質問が抽象的なのも
答える側としてはつらいものがあるよ。

もうちょっと状況を絞ってくれないかな。

分野、言語、開発環境、プラットフォームをハッキリさせれば
実際に役に立った事例が具体的に得られると思うよ>>89

145 ：仕様書無しさん：03/09/14 20:41

なんだなんだ、面白い>89がいるなあ。
ここはプログラマ板の筈だが、まさか
抽象の重要性が分からないのにプログラマを
名乗っている奴がいるのか？

89よ、お前は「1+1」「1+2」…を全部無限に
例示して貰わなきゃ「足し算」を理解できないのか？
違うだろ。それが「抽象」ってこった。
分かってるか。

抽象を抽象のまま記述できることが優れた
考え方だというのが理解できないなら、
オブジェクト指向はおろか、プログラマの
適性もないから、止めた方がいいぞ。

146 ：仕様書無しさん：03/09/14 20:45

>>143
具体例を示されているのに、
そんなの具体例じゃないと言い張っているだけに見える。
具体例の意味が解っていないのは>>89
OO以前に日本語を学べ。

147 ：仕様書無しさん：03/09/14 20:49

俺はVBからJAVAに転向したやつだが、
そもそも短いプログラムでオブジェクト指向の特性を
理解させるってのは不可能だと思う。
きれいに書いたソースをどっかから引っ張ってくるしかないよ。
>>89を納得させるには。

148 ：89：03/09/14 20:50

>>144
言ってることはわかるけど、OO自体が抽象的概念しか理解ないからなぁ・・・

じゃ、誰もが触った事があると思われる・・・ATM端末のプログラム
（入出金・振込・借り入れ・口座開設など）をC/C++のそれぞれで作る場合は
どう違ってくるか・・・でいい？

・・・良くない気がする。

149 ：89：03/09/14 20:55

>>145
もはや押し付けですか？
あるルーチンのOO例と非OO例・・・OO推進者なら提示出来るものだろ？
人に説明出来ない抽象オナニーもほどほどに。

>>146
先と同じだが、あるルーチンのOO例と非OO例・・・これを提示してこそ
差が分かりやすい訳で。今までどこにそんな具体例が書かれてましたか？

>>147
それでもいいよ。
いままで、それすら無かった訳ですが。

皆々様、
オブジェクト指向が理解出来ない人に対する説明方法をもちっと考えて下され。
アフォな部下が出来た時に、どうやって教育してるの？
サジ投げるのは簡単だがね。

150 ：仕様書無しさん：03/09/14 20:58

>>148
そういう状況ならOOが良かろうが悪かろうが
ミドルウェア選定の時点でOOを採用せざるを得ないでしょ。

OOは僕らエンドユーザ開発者にとってメリットが
あまりないものかもしれないけれど、
DBアクセス、データ通信、ネットワーク透過なコードの実行のための
フレームワークを作っている人には便利なのではないかな。

151 ：仕様書無しさん：03/09/14 21:01

自分に必要ないものなんて理解できないよ。
超的確な説明でないと理解できないと言うのなら、
>>89はすべてのことが他人任せの無責任な人間。

152 ：145：03/09/14 21:04

>149
>あるルーチンのOO例と非OO例・・・OO推進者
>なら提示出来るものだろ？

おいおい、漏れはお前の求める「抽象というものの
考え方の重要性を具体的に説明」した例を145で
ちゃんと提示しているんだぜ？
式がなけりゃ説明されていると気がつかない
ならただの馬鹿だよ、おまえさん。

もう一度ちゃんと読め。そして自分の
馬鹿さ加減を自覚しなさい。

153 ：89：03/09/14 21:18

>>150
概念さえ分かっていれば良しって訳ですか？
言語の差は実装のやり易さの差しかないから、C/C++ではこういう違いがある
というのは本来提示出来るものでは無いと？
（そういうものかも知れないという気はしてきた。）

>>151
それを部下にも言ってるのですか。無責任ですね。

>>152
「抽象というものの考え方の重要性を具体的に説明」した例・・・って、
あの程度にえらく大層なタイトルを付けるのですね。
今までのどこに「抽象」の意味を説明しろと書いていたのか・・・あんた
こそ過去レスよく読みなさい。

本来から、あるルーチンのOO例と非OO例しか求めてませんが、何か？
出来ないなら出来ないと言って帰って下さい。

154 ：仕様書無しさん：03/09/14 21:21

継承を利用した非常に単純な例

import java.applet.Applet;

class HogeApplet extends Applet
{
paint(Graphics g)
{
g.drawString("hoge",100,100);
}
}

155 ：仕様書無しさん：03/09/14 21:22

訂正

import java.applet.Applet;

class HogeApplet extends Applet
{
public void paint(Graphics g)
{
g.drawString("hoge",100,100);
}
}

156 ：仕様書無しさん：03/09/14 21:23

>それを部下にも言ってるのですか。無責任ですね。

言ってる。
仕事とはそういうものだ。金をもらう。
金を払って客として行く学校とは違う。

157 ：仕様書無しさん：03/09/14 21:26

どうやら89様はルーチンを２つ並べない限り
まったく理解しようとする気はないようなんだが、
もしかして、89って人工無能なんじゃねーの（w

158 ：仕様書無しさん：03/09/14 21:28

>それを部下にも言ってるのですか。無責任ですね。

新しいテクノロジーを理解できないのを、
他人の説明の仕方が悪いせいにするほうが無責任。

159 ：仕様書無しさん：03/09/14 21:29

俺が上司なら、>>89の首を切って、やる気のある奴と交換する。
それが上司の責任。

160 ：仕様書無しさん：03/09/14 21:34

>156
少なくとも理解できない部下新人が89みたいな
態度を取ったら、そいつは社会人失格だわな。

分からないことが問題なんじゃないんだよねー。
どこまでを理解していて、どこが分からないのかを
説明することは普通は本人に要求されるものだし、
少なくとも「この方法で説明してくれんとオレには
理解できん」なんて言ってしかも居高々にしている
こと自体が信じられんよ、正直。

161 ：仕様書無しさん：03/09/14 21:39

>>155
Javaは知らないので特別な意味が隠されているのならスマンですが、
単にライブラリに格納されているdrawStringをコールするのと違いは
あるのですかい？

>>156
別に教育しろと強制しないが、、、他力本願ですね。
能力がある奴が入って来ないと苦労しますな。

>>157
要求に応えられない場合はこういうレスが帰ってくるというのは予想済み。

162 ：仕様書無しさん：03/09/14 21:42

>>158-160
少なくともここは会社でもないし、お前らの部下でもない。
OOﾏﾝｾｰというなら俺の要求に応えてみろ。能力あるなら出来るだろ？と言ってるんだよ。

別にお願いじゃねーんだよ。

163 ：仕様書無しさん：03/09/14 21:43

>>153
>概念さえ分かっていれば良しって訳ですか？
ぼくはぶっちゃけそう思っています。
そこから先の利を得るためのハードルが高すぎますし。。。

>言語の差は実装のやり易さの差しかないから、C/C++ではこういう違いがある
>というのは本来提示出来るものでは無いと？
"フレームワーク"　と呼ばれる　"作りかけのアプリ" を提供しなければ
ならない人たちには明確なメリットがありますよね？再利用とか、抽象化とか。
だからこそ、>>89さんはOOにハッキリとした利点を見出せないのではないのでしょうか。
そちらに有益な例は沢山>>98さんも見てきたはずです。

164 ：仕様書無しさん：03/09/14 21:43

OOﾏﾝｾｰなんて誰か言ったっけ？

165 ：仕様書無しさん：03/09/14 21:44

休日に>89と遊んでいるのもいいけど、そろそろ、
みんな放置したら？
別に>89がOOの良さを納得しようがしまいが、
いいじゃねーか。どう見ても本人は今さら頭など
下げられないだろうから「ルーチンを並べない
限り納得しない」の一点張りだろうし、154-155
さんみたいなご苦労様な例を出そうが「それでは
例として不十分」とケチをつけるに決まっているよ。

166 ：仕様書無しさん：03/09/14 21:44

>他力本願ですね。

即戦力の中途入社がどんどん入ってくるのに暢気なもんだな。
転職先なんて無いぞ。

167 ：仕様書無しさん：03/09/14 21:48

正直、いまJavaやC++の仕事をするなら、
それが良いものであろうが悪いものであろうが
OOの考え方を理解しなければ質の高い仕事は
できない。それだけのことだ。

だからそれらの言語をプログラマとしてやるなら
石にかじりついてでも自分で理解せにゃならん
わけで、89みたいな態度ははなから論外。

だけど、89がJavaやC++なんて一生知らんで
良いというなら（それは可能でもあろう）、
好きにしていればいいさ。誰も強制はせんよ。

168 ：仕様書無しさん：03/09/14 21:50

だいたい中学生でも理解できるもの本業が理解できないのは救いようのない馬鹿。
その頭脳の存在自体が悪。氏ね。

という気分です。

169 ：155：03/09/14 21:51

>>161
>単にライブラリに格納されているdrawStringをコールするのと違いは
>あるのですかい？
そう、そこがキモだ。
このプログラムには一切の初期化処理が書いてないだろ?
本来グラフィックライブラリを使おうとするとライブラリの初期化を
ダラダラ書かないといけないが、親クラスのAppletを継承することによって
最低限のことを書くだけで文字を書くことができる

170 ：89：03/09/14 21:59

>>161-162=89

>>163
構ってくれてありがとうです。

>ぼくはぶっちゃけそう思っています。
そうですか。
C++の本を読んでいても「Cならこういう組み方でOKだよな」とかはよく思ってますた。
もちろん、Cならではの注意を払わなければいけない点は沢山ありますが。
C++の方が実装が簡単なのは認めます。

>"フレームワーク"　と呼ばれる　"作りかけのアプリ" を提供しなければ
>ならない人たちには明確なメリットがありますよね？再利用とか、抽象化とか。
>だからこそ、>>89さんはOOにハッキリとした利点を見出せないのではないのでしょうか。
たしかに、言語的にC++の方が楽出来る部分が大きいとは思います。
でも、OOって楽するとかそういう意味で考えられたものではないかなと思って
もっとはっきりした意見が欲しいなと思いました。

>>164
言ってなければ出て来なくていいよ。

171 ：仕様書無しさん：03/09/14 22:03

なんだ、ただの構ってくんかよ89…

172 ：仕様書無しさん：03/09/14 22:08

>たしかに、言語的にC++の方が楽出来る部分が大きいとは思います。

どうしてそう思うのか説明してください。
誰にでもわかるように。

173 ：89：03/09/14 22:13

>>165
既にレス済みだったんだが、名無しになってしまってたね。ごめんね。
これでいいかい？

>>166
中途入社しか採らないのかよ。

>>167
態度悪い？
俺は２ちゃんスタイルにあわせてるだけ（釣り気味のつもり）
態度が気に入らないだけ？

>>168
説明出来ない人ほどそういうね。

>>169
言語レベルでそれの実現が出来るのは楽ですな。
俺がCで組んでいる時は、そういう初期処理等を一纏めにしたラッパールーチン
作ってライブラリ化している。
面倒臭いけどちまちまと作業しているが、まあその処理の仕組みが理解出来る
という利点はあるかと思いながらやってる。

OO話、他にありますか？

174 ：89：03/09/14 22:16

>>171
知らなかったのか。

>>172
>>173の>>169宛レスでいいですか？

175 ：仕様書無しさん：03/09/14 22:19

>>174
君と同じ判断基準で言わせてもらえば

駄目

こんな言い方で、新入社員が理解できるとでも思ってるのか？

176 ：仕様書無しさん：03/09/14 22:31

>>170
>でも、OOって楽するとかそういう意味で考えられたものではないかなと思って
>もっとはっきりした意見が欲しいなと思いました。
これは私の主観交じりな発言なので、
一般論とは捕らえてほしくないのですが。。。

OOが生まれた経緯にまず、データ構造に制御構造をまとめ
わかりやすさを重視する、という目的があったように思われます。
子供にもプログラムが書けるように、って奴です。

Lispマシンがハードウェアにconsセルの処理機能を持ったように、
Smalltalkはハードウェアにデータ構造に含まれる制御構造を
"メッセージの送信" という形で含めようと試みました。

私はOOを"たまたま" 構造化プログラミングの後継に指名され
おおっぴらに利用される様になっただけで、元々は
今までのやり方と違う切り口でプログラムを作ろうじゃないか
という考えの結果でしかない、と捕らえています。

どうでしょうか？OOはCやPascalでアプリケーションを作る今までのやり方の
延長線として考案された物でなく、元々山師の発明品であったわけで
つまり>>89さんの仕事を楽にするために生まれた物ではないわけです。

177 ：仕様書無しさん：03/09/14 22:39

機械語からアセンブラ、アセンブラから高級言語に
移行した時も、89みたいな人間は存在していたよ。
それだけのことだ。

178 ：仕様書無しさん：03/09/15 00:33

きょうび、OOPが理解できてない奴、または口に出して「OOPわからねぇ」とか
言ってる奴は、心の中で鼻で笑われてるに違いない。

179 ：仕様書無しさん：03/09/15 00:48

OOPって何？

180 ：仕様書無しさん：03/09/15 01:18

Object Oriented Programming

181 ：仕様書無しさん：03/09/15 01:20

あれ、もうラーメンの話しないのかよ。
スレのはじめの方で、ラーメンの話が出てたから、わざわざラーメンネタ仕入れて
書き込みしようと思ったのにさ。。

じゃあ、ラーメンをネタにオブジェクト指向を教えてやるよ。

まず、客がラーメン親父オブジェクトを生成すると。
オブジェクト名は、ラーメン親父でいい。
そうだな、生成するときに呼び出すコンストラクタには、
"頑固"と"こだわり"っていうのを引数で渡せばいい。
（このとき、ラーメン親父クラスは、親父クラスを拡張していること。）

そして、できたラーメン親父オブジェクトを使って、
客からの注文を聞いてもらったりするわけよ。
たとえば、こんなふうに使う。

ラーメン親父.注文を受ける("スープ濃いめ","麺硬","脂多め");

注意点として、このとき、かならず、このメソッドをtry節で囲むこと。
なぜなら、ラーメン親父オブジェクトを生成するときに、引数に
"頑固"っていうのを指定して、生成していたら、ごくたまに
キレルExceptionってのが発生するのよ。（やっぱ、味にこだわりが
あると客の言動によって、突然、怒っちゃったりするのよ。）
そのキレルExceptionが発生したら、それをキャッチしないとプログラムが
止まってしまうから、忘れずに、chach節でキレルExceptionを受け取った
後の処理を記述すること。

・・・とまあ、ここまで書いたところで疲れたので、シャワー浴びるな。

182 ：仕様書無しさん：03/09/15 01:21

熱いなあ九州人のスレはｗ

183 ：仕様書無しさん：03/09/15 01:36

本当はアーカイブライブラリなんか作るときにポリモリフィズムが役に立つんだがな・・・
統合アーカイバプロジェクトのDLLはオブジェクト指向なんぞ意識しないで作られているのが悲しいところ。

184 ：仕様書無しさん：03/09/15 02:38

とりあえず、181の手順で、客はラーメン親父が何をしてるかわからなくても、
ラーメン親父はちゃんと注文したラーメンを作ってくれるのよ。
ラーメン親父クラスでは、フィールドとメソッドが定義されているが、
(豚骨などの材料を)入れるタイミング、麺のゆで時間、塩加減などの
フィールドは、すべてprivate、客と接する機会のある機能(メソッド)には、
public修飾子を指定しておくとよい。
このあたりの話は、カプセル化について学んだらわかると思う。
ちなみに、ラーメン親父クラスには、取材を受ける()メソッドがある。
このメソッドをラーメン親父の信用がないうちに、
呼び出すと、帰れ帰れお断りだExceptionが発生するので、注意な。

185 ：仕様書無しさん：03/09/15 02:39

あと、オブジェクトを生成するときに、
たとえば、引数に"頑固"と"愛想のいい"を組み合わせて、
オブジェクトを生成するとコンパイルエラーな。
つまり、引数同士が矛盾しているとだめだってことだな。
これは、メソッドの修飾子に、abstract(定義が完了していない意)と
final(定義が完了している意)を一緒に使うと、コンパイルエラーに
なるということからも、理解できると思う。

186 ：仕様書無しさん：03/09/15 02:50

まだ、客の目の前にラーメンはない。
ラーメン親父が作ったラーメンは、一旦、ラーメンクラスに格納されるわけ。
このクラスは、できたラーメンを保持するクラス。
注文を受ける()メソッドを実行したとき、ラーメンクラスオブジェクトが
戻り値として、戻ってくる。このオブジェクトを使って、getラーメン()する。
客が一番嬉しいときだ。これで客の目の前に、ラーメンがある状態になる。
さらにこのオブジェクトを使って、お好みで、setコショウ()やsetおろしニンニク()
などのメソッドを適時、呼び出せばいい。

187 ：仕様書無しさん：03/09/15 05:18

setやくみ("コショウ")、setやくみ("おろしニンニク")でも
よかね？

188 ：仕様書無しさん：03/09/15 06:12

>>181
よく分かんね。
関数の入れ子ができるって事か？

189 ：仕様書無しさん：03/09/15 06:20

>>181-
奇麗に整理設計されているだけで、それをOOと呼ぶにはまだコショウが足りない気がするな。

190 ：仕様書無しさん：03/09/15 08:54

あいうえお

191 ：仕様書無しさん：03/09/15 09:36

まあね、
オレの言葉でオブジェクト指向を説明すると
「アプリを組む時に『クラスをどう設計するか』という観点で
設計ができる」
ということだけなんだが。

アプリを組む時に100個の関数を考えるより、
10個のクラスを考える方が楽だし、
全体構造を設計しやすいと思う。
で、まずカプセル化という恩恵を受ける。

そして、、、
オレに言わせれば継承や多態はオマケみたいなもんだから。
上手く継承や多態がはまる時はいいんだけど、
いつもそうじゃないからね。

192 ：仕様書無しさん：03/09/15 09:39

ソニーがCDを開発してレコード会社に持ち込んだ時、
「みんなレコードを普通に聞いてるのに、何でそんなもんがいるんだ？」
と言われたらしい。
世の中そんなもんだね。

ただし、
CDがレコードより便利なのはほぼ誰の目から見ても明らかだが
オブジェクト指向が何故便利であるかは説明が難しい。
それが違うと言えば違うけどね。

193 ：仕様書無しさん：03/09/15 09:43

重要なのは継承や多態をはめた結果を得ること自体ではなく、
継承や多態をはめることを考えながらクラスや構造の設計を
洗練化できることであると言えるのではないだろうか。

もともと完璧な設計なんてあり得ないし、あるとしても
「その時点での」完璧な設計にしかすぎんしな。

194 ：仕様書無しさん：03/09/15 11:13

っていうかほんとにわかんないの？

195 ：仕様書無しさん：03/09/15 12:58

判ろうとすればするほど判らなくなる。

判ったという奴に聞いても、そいつの言う事はまったく低次元な判り方だ。
それはわかっていない以前の話なのだ。

もしかすると、自分が判っていないという事を知っている程度に判っている奴が実は一番判っている奴なのかもしれないな。

・・・・無知の知より

196 ：仕様書無しさん：03/09/15 13:01

>195
しかし少なくとも89が「一番分かっている」ことに
なるわけではないのは明らかなのだが。

197 ：仕様書無しさん：03/09/15 14:16

オブジェクト指向について折れが言える事は、
ソフトウェア開発・保守におけるパラダイムシフトである
と言うことだ。
クーンの「科学革命の構造」に見るように、
パラダイムシフトはやたら時間がかかる。
例示すると「相対性理論はもう理解されているのか？」だ。
折れは「完全に理解していると言う輩」の発言は信じない。
195の「無知の知」やソクラテスに学び、
「自分が判っていない」ということを知るべきだ。

198 ：仕様書無しさん：03/09/15 15:29

俺でも理解できるから、オブジェクト指向は簡単。
一度やってみなよ。あの便利は癖になること間違いなし。
そして、モジュール影響範囲云々とほざいてるPMを潰せ。

199 ：仕様書無しさん：03/09/15 15:30

しかし「相対性理論は間違っている」と題した
本はほぼ全部、著者の無知や間違いを強引に
正当化しようとしているだけのトンデモ本だぜ（藁

「オブジェクト指向を完全に理解している」なんて
言う奴がいたら（いるのか？）うさんくさいのは
事実だし否定しないが、相対論の結果がすでに
現在の科学や電子工学の基礎になっているのと同様、
オブジェクト指向の利点をプログラムやシステム設定の
基礎に置くのは間違ってはいないと思うわけだが。

200 ：仕様書無しさん：03/09/15 15:46

>>198
あ、やっぱモジュールの影響範囲も過去のものになってるか。
基本情報の勉強していて必要性に疑問を持ってたけど

201 ：197：03/09/15 16:36

>199
システム設定というのが何を意味しているのか知らないから
システム設定についてはコメントしない。
「オブジェクト指向の利点をプログラムの基礎に置くこと」
についてコメントすると、
オブジェクト指向の利点を十分に得るためにはOOPだけでは駄目だ。
OOD、OOAは言うにおよばず開発プロセス自体も変革しなければならない。
具体的に書く。
クラス設計を進めていくとその完成度は時間の経過と共に順調に上がっていくか？
決して線形を思わせるようにはあがっていかない。下がったり上がったりしながら
徐々に完成に近づく。
この現実は、ｏｏが従来のwaterFall型の開発モデルでは対応しきれない新たな
開発手法であることを示している。
換言すると、「従来の手法／手順を踏襲して、俗に言う製造工程だけに
ＯＯ（ｏｏｐ）を
適用してもｏｏの利点は充分には得られない。」と折れは言いたい。
だーかーらー、ｏｏはパラダイムシフトなんだよ。

202 ：197：03/09/15 17:10

>1
回答が後回しになってすまん。
別に悪くは無いよ。
（相対性理論の伝でいくと）ニュートン力学の世界の中だけで
あなたの技術者人生をまっとうできる環境にいるならば。

203 ：仕様書無しさん：03/09/15 18:08

>>202
エンジニアリングの世界ではニュートン力学さえマスターすれば十分です。
GPSのように相対論の影響が出る応用分野もありますが、それも補正項と捉えるだけで問題ありません。

逆に言えば相対論は綺麗な理論ですが、エンジニアリングに応用出来る理論ではないのです。

204 ：仕様書無しさん：03/09/15 18:19

>>201
世の中にはプログラミング適性が異常にある人もいます。
そういう人達は、設計・開発プロセスを自力で構築出来る人達です。
ただ、どうやったかというのを説明できないという点で学問にならないのですが・・・

彼らは彫刻家が、いちいち図面をひかず、ただノミをふるうのみで
既にあるものを切り出すように、設計せずに開発してるかのように見えます。
彼らにとっては設計＝開発というだけなのでしょう。

こういう人達を見ると、開発手法・設計手法が必要なのは　
たんに自分たちに才能が無いからに過ぎないという事を自覚させられます。

205 ：仕様書無しさん：03/09/15 18:43

＞204
＞こういう人達を見ると、開発手法・設計手法が必要なのは　
＞たんに自分たちに才能が無いからに過ぎないという事を自覚させられます。

スケジュール帳を使うのは
スケジュールを全て覚える記憶力のないバカですか？

自転車に乗るのは
マラソンランナー並の体力のないひ弱な人ですか？

206 ：仕様書無しさん：03/09/15 18:47

>>1
オブジェクト指向ぐらい理解できんと、悪かとよ。

207 ：仕様書無しさん：03/09/15 18:56

頭がわるいとー

208 ：仕様書無しさん：03/09/15 18:58

まあ、勉強しないで遊んでたバカオヤジプログラマどもは揃って首釣れと...
あんたら、会社のお荷物なんだよ。

209 ：仕様書無しさん：03/09/15 19:05

>>208
ホントにキミより勉強してないのかな？

210 ：仕様書無しさん：03/09/15 19:09

OOPがどうこう言ってる場合じゃないよな。

これからはマルチパラダイムデザインの時代なんだろ？
一つのプログラムの中で
object-oriented programming
functional programming
generic programming
generative programming
meta programming
aspect-oriented programming
等々の考え方を交差させながら作らなきゃいかんわけだ。

難儀な話だぜ。

211 ：197：03/09/15 19:40

>>204
「プログラミング適性」ではない。「設計スキル」（曖昧？）だ。
「才能が無い」のではない。「経験と努力と思弁の不足」だ。
学問ではないことは確かだ。彫刻家や画家になるための学問など存在しない。
これは「技芸」なのだから。

212 ：仕様書無しさん：03/09/15 19:55

言っておくが、時代は常に進歩しているのだよ。
その堅苦しいアタマをハンマーで壊したくなるわ。

213 ：仕様書無しさん：03/09/15 20:00

今日ごちゃごちゃとつまらんいちゃもんを
つけているのは昨日の89なのか？

214 ：仕様書無しさん：03/09/15 20:02

アタマ古くなった人間を廃棄処分するシステムの導入を！

215 ：仕様書無しさん：03/09/15 20:04

構造体に関数が書けるようになっただけのこと。
それをなぜ理解しようとしない！オナニーのしすぎじゃないの？

216 ：仕様書無しさん：03/09/15 20:33

>>215
winnyのせいでｵﾅﾆーが止められないんです・・

217 ：仕様書無しさん：03/09/15 20:35

関数ポインタで十分です。

218 ：125：03/09/15 20:37

>>212
折れのことか？
誰のことでもいいけど、「堅苦しい頭を壊したくなった」のなら、
その理由も書いてくれ。
そうでないと、単なる個人攻撃の罵詈雑言だと判断する。

219 ：197：03/09/15 20:40

125番の人、すまん。
名前を書き間違えた。
218の名前は正しくは197だ。

220 ：仕様書無しさん：03/09/16 02:06

>>215
すまんが、そういう低レベルのことでOO使える等と言わないでくれ。
低レベルなOO使いが多数存在するから89みたいなのが出現するんだよ。

221 ：仕様書無しさん：03/09/16 02:15

別にOO使える等言ってないし、OOすら理解できない馬鹿用にOOがどんなものかを
かなりの情報省いて親しみやすく書いただけだと思うが…

222 ：仕様書無しさん：03/09/16 10:25

なんでクラス==OOの説明なんだよ。
親しみやすいも何も説明になってないだろ。キチガイめ。

223 ：1：03/09/16 12:18

オブジェクト指向プログラミングが出来ない奴は、見ていてイライラする。

224 ：223：03/09/16 12:19

>>223
どッかの >>1 ってことです。
このスレの >>1 じゃないです。

225 ：仕様書無しさん：03/09/16 14:45

感情的に書きなぐるから、説明になってないし、相手を納得させられないのでは？
人に説明する、という事は。
自分にとって、曖昧にしていた部分がはっきりとわかる。
から、非常に面白い試みだと思うけどね。
実際、OOがいいと説明してる人のなかにも、OO判ってなさそうな人も多いじゃない。

自分がOO使って「これ便利だなー」と思ったのは(本質的じゃない事は判ってますが
敢えて書き込みます)……

・コンストラクタ・デストラクタ・operator演算子の存在
メモリの初期化漏れ、開放漏れが無いってのは、素晴らしいことだと思うけどね。
また、コピーにoperator = を実装する事で、間違いが無くなる。

（具体例）
後輩が作ったプログラム、後輩が鬱病になったので、プロジェクトも違うというのに
俺が借り出されて、プログラムの修正。
修正点はすごく簡単。プログラム起動時に、カレントディレクトリにあるファイルの
情報を構造体に保存するんだけど、そのパラメータを１つ増やせ、という事だった。
(続く)

226 ：仕様書無しさん：03/09/16 14:53

開発言語はC++だというのに、その後輩はデータの入れ物に構造体を使っていた。
こんな感じ。

typedef struct FileData
{
char Data1[MAX];
char Data2[MAX];
}

で、そのデータを初期化するのはメインプログラムの起動時に以下の関数を呼び出していた。

void XXXXXX::InitFileData(void)
{
FILE *fd = fopen( "XXXX.ini", "r" );

/* XXXXXXクラスのメンバに FileData型の構造体があって、それに値入れてる */

fclose(fd);
}

で、このデータを引き出そうとする場面で全て

FileData dst;

memcpy( &dst.Data1, XXXXXX::filedata.Data1, sizeof(dst.Data1) );
memcpy( &dst.Data2, XXXXXX::filedata.Data2, sizeof(dst.Data2) );

とかやってるんだよ。

227 ：仕様書無しさん：03/09/16 14:56

メモリコピーのたびにこんな事してるので、このデータを扱う時のソースコードはmemcpyの山。
(まぁ参照だけのデータのはずなのになぜわざわざメモリをコピーしていたのかっていうツッコミも。)

当然、operator = を実装していれば、こんな事にはならなかったはず。

memcpy()やってる場所は(とりあえず本当にmemcpy()なのか？ってのはおいておく)
全部operator=内に実装してしまえばいい。

そうすれば、
CFileData dst;
dst = XXXXXX::filedata;
の１行でメモリのコピーは全て出来たはずだ。

228 ：仕様書無しさん：03/09/16 14:59

さらに言えば、最初に書いたように、俺の仕事は
「パラメータを１つ増やす事」
だった。
だから、既存のmemcpy()を使ってる部分全てをgrepで検索して、
全部のソースに対して新しいmemcpy()を追加してやらなくてはならなかった。

当然、ここもoperator = で実装してればoperator =　の中身だけいじってれば
よかったはずだ。

そもそもそのプロジェクトは
「初期化漏れ・開放漏れはイヤなのでクラス化できる部分は全部クラス化し、
構造体はなるべく使わない」
という規約があった筈なんだけど、後輩はそれに従ってなかった。

229 ：仕様書無しさん：03/09/16 15:06

というワケで、クラス化してあればわずか数行で済んだハズの修正が、
クラス化してなかったせいで何十行、そしていくつものファイルを修正
しなければならなかった。
(ファイルの修正報告書や変更書などたくさんの書類をかかなくては
ならなかった)

いじるソースが多ければ多いほど、バグを作りやすくなる。

だから、クラス化しててほしかった。

わかりやすく、低レベルな話をしてみた。
こういう低レベルな積み重ねで、高いレベルの話になると思うんだがどうでしょか。

230 ：仕様書無しさん：03/09/16 16:20

一つだけ言っておく。
オブジェクト指向は、柔軟なアタマの持ち主でないと理解できない。
なんでも決め付けてとっかかるアタマの堅い連中には到底理解できない。

231 ：仕様書無しさん：03/09/16 16:28

たしかに>>230みたいに決め付けて得意げな顔してる香具師には理解できないだろうね（わら

232 ：仕様書無しさん：03/09/16 16:30

だからさ、なんで理解できないの？
>>230の言うようにお硬く考えてるのかな？
難しく考えるなよ

233 ：仕様書無しさん：03/09/16 16:46

>operator = で実装してればoperator =　の中身だけいじってれば
これの詳細解説をｷﾎﾞﾝ

234 ：仕様書無しさん：03/09/16 16:57

こんなバカどもに教えたところで何の価値も生み出さないと思われ

235 ：仕様書無しさん：03/09/16 16:58

てか本買えや

236 ：仕様書無しさん：03/09/16 17:01

説明出来ない能無しは黙ってろ（わら

237 ：225-229：03/09/16 17:02

えーっと……詳細といわれても……

今、コンパイル環境がなくて確認できずに申し訳ないけどさ。

typedef struct A {
　String strA;
　String strB;
};　

とする。
A a,b;
と宣言して、aにbの中身をコピーするには

a.strA = b.strA;
a.strB = b.strB;

と、２行(というかパラメータの数だけ)、コピーのための
手続きをしなくちゃならない。

238 ：225-229：03/09/16 17:08

ところが、これがクラスを使うと全然楽で。

class C {
　String strA;
　String strB;

　C(){};
　~C(){};
　&C operator = ( C& c ){
　　strA = c.StrA;
　　strB = c.StrB;
　};
};

とすれば、
C a,b;
でbの値をaにコピーする時は
a=b;
で済むわけだ。
クラスにパラメータが増えたとしても、直す場所はoperator = の中だけ。
というかクラスを作成してる人と、そのパラメータを触る人だけが知ってればいい。

更に言えば、リストやキューなんかの「デッドコピーしちゃいけないデータ」なんかも
クラスやテンプレートとoperator = を組み合わせれば、難しい使い方をしなくて
済むんだけど、まぁこれは難しいから置いとこうかな（汗）

239 ：仕様書無しさん：03/09/16 17:08

あ、わかった。
オブジェクト指向を理解できない奴って他人の気持ちになって物事考えられない想像力0のDQNなんだ。
もしくはまったくもって経験不足か。

240 ：225-229：03/09/16 17:10

既に書いたけどコンパイル環境ないので通らなかったらごめんなさい。
あと const 付けた方がいいとは思ったけど、説明する場合かえってジャマっぽいので
敢えてつけてません。

241 ：仕様書無しさん：03/09/16 17:11

>>237
それはStringにoperator=()が定義されてれば、a=b; でいいんじゃね?

242 ：225-229：03/09/16 17:16

>>241
まぁまぁ、判りやすい例として書いたので……
どっちにしろoperator=()の実装はｲｲ!という結論になりますよね。
それとシャドーコピーは、コンパイル環境によってアテにならないのです。特にVC++とか。

もっと判りやすく、コンストラクタがあるから初期化要らない！とかにしとけばよかったかな。
自分でも、２ｃｈでoo語るなんて「身の程知らず」かなと思ってます。

243 ：仕様書無しさん：03/09/16 17:46

>>239 それはどちらにも言える事だろうね（はぁと

244 ：仕様書無しさん：03/09/16 18:20

>>237
> と、２行(というかパラメータの数だけ)、コピーのための
> 手続きをしなくちゃならない。

C 言語と C++ 言語なら通りますよ。a = b で。浅いコピーでいいなら。

245 ：仕様書無しさん：03/09/16 18:22

>>225
operator のオーバーロードは OO じゃないです。
C++ の言語仕様です。ふつうの OOPL では、hoge.assign(foo) とかやります。

246 ：仕様書無しさん：03/09/16 18:23

>>212
ゴールデンハンマーでつか？

247 ：(・∀・)ﾆﾔﾆﾔ：03/09/16 18:24

|дﾟ)
|дﾟ).｡ｏO(10.220.135.85)
|）彡ｻｯ

248 ：仕様書無しさん：03/09/16 18:27

>>226
> memcpy( &dst.Data1, XXXXXX::filedata.Data1, sizeof(dst.Data1) );
C でも C++ でも memcpy なんか使わすに

dest.Data1 = XXXXXX::filedata.Data1;

で OK だよ。
なんか知らないけど、C で構造体のコピーに memcpy を使う人がいる。
素直に = を使えってか～んじ。

249 ：仕様書無しさん：03/09/16 18:31

>>228
OO の利点とは別なこと。
operator=() にしてなくても、FileDataCopy(FileData& dest, const FileData& src) って
関数を定義しておけば OO じゃなくても修正箇所は 1 か所になる。
OO ならその関数をメンバにすればいい。operator=() じゃなくても OK。
ってか、operator=() をのっとるのは C++ しかできないから、OO の本質でもなんでもない。

250 ：仕様書無しさん：03/09/16 18:34

ｳｰﾊﾟｰε(ﾟдﾟ)зﾙｰﾊﾟｰ

ｳｰﾊﾟｰε(ﾟдﾟ)з

ε(ﾟдﾟ)зﾙﾊﾟｯ!

251 ：仕様書無しさん：03/09/16 18:37

>>238
テンプレートのどこが OO でつか？
list のコピーとテンプレートは関係ないです。

252 ：仕様書無しさん：03/09/16 19:00

な？
２ちゃんレベルでは否定厨しかいないんだよ。
OOを説明出来る香具師は皆無。

253 ：仕様書無しさん：03/09/16 19:10

「1+1が何故2になるかを説明せよ」と言われても困る。
同じように「OOを説明せよ」と言われても困る。

OOを理解できないと開き直られるのが一番困るけどな。

254 ：仕様書無しさん：03/09/16 19:12

>>253
おまえはちっとも理解できてないだろ。ﾌﾟ

255 ：仕様書無しさん：03/09/16 19:15

なんでそんなに必死なの？
こんなのプログラマなら知ってて当たり前のことじゃないか？

256 ：仕様書無しさん：03/09/16 19:16

>>255
当たり前のことを理解できていないやつが大多数だって知らないの？
たとえばお前とか。

257 ：仕様書無しさん：03/09/16 19:17

>>253
世に出まわってるOO解説本は何だというのだ。

>>255
世間知らずですね。
ｵﾚﾓﾅｰ

258 ：仕様書無しさん：03/09/16 19:22

> 当たり前のことを理解できていないやつが大多数だって知らないの？
新卒SEとかを派遣する詐欺会社では大多数だろうな。

259 ：仕様書無しさん：03/09/16 19:27

オブジェクト指向なんて気にしているのは一部のヲタだけ

260 ：仕様書無しさん：03/09/16 19:54

>>253
> 「1+1が何故2になるかを説明せよ」と言われても困る。

数学の本を読め。加算の定義によりそうするように決めてある。それだけだ。

261 ：仕様書無しさん：03/09/16 21:26

事件は会議室でおきてるんぢゃない
現場でおきてｒ（ｒｙ
ってことで使える範囲で勉強汁
学者じゃねーんだからよ

262 ：DELL ユーザ：03/09/16 22:16

構造化すら理解できていない人がいらっしゃいます。

このｽﾚに限った事でなく、業界にも少なからず存在しますけどね。

263 ：仕様書無しさん：03/09/16 22:17

知らないより知ってる方がいいに決まってる。
わかんないからって否定しないで勉強しろよ。

264 ：仕様書無しさん：03/09/16 22:23

>>259
そのとおり。2:6:2 の法則というのがある。
2 割の人は本を読んで勉強して自分で実力を高める。
6 割の人は本を読んでためになったなあと思うけど何もしない。
最後の 2 割の人は本すら読まない。

だから、ちゃんとした技術を持っているのは最初の 2 割の人だけ。

265 ：仕様書無しさん：03/09/16 23:50

結論から言わせてもらうと、COBOLerにオブジェクト指向は理解不能だということですね？

266 ：仕様書無しさん：03/09/16 23:52

>>265
癌

267 ：仕様書無しさん：03/09/17 00:03

>266
意味が

268 ：仕様書無しさん：03/09/17 00:04

>>267
わからなかった？

269 ：仕様書無しさん：03/09/17 00:10

なるほど。>>268が痔で苦しんでるってことか。

270 ：仕様書無しさん：03/09/17 00:13

惜しい実に惜しい

正解は「寿ｵﾒ」

271 ：仕様書無しさん：03/09/17 00:29

>270
meanが

272 ：仕様書無しさん：03/09/17 00:30

>>271
understandできなかった？

273 ：仕様書無しさん：03/09/17 00:36

わかっちゃえば使わなきゃ当たり前な概念になっちゃうんだけどな

274 ：仕様書無しさん：03/09/17 00:47

オブジェクト指向なんてかまえちゃーだめだよ。

275 ：仕様書無しさん：03/09/17 01:30

俺、COBOLerにオブジェクト指向教えようとしたけど
そもそも再利用という考え方自体がなくて説明できんかった

276 ：仕様書無しさん：03/09/17 02:00

>>275
COBOLerって毎回いちいち最初から作るんか？？

277 ：仕様書無しさん：03/09/17 02:19

似通った処理のプログラムをリネームして書き換えるんだよ。
大抵、使ってない変数とかゴロゴロしてるね。

278 ：225-229：03/09/17 09:33

みなさん、煽らないでいきましょう。

テンプレートとooが関係ない、
operator=とooが関係ない、
という話ですが、自分は「充分に関係ある」と思います。

これからそれを説明します。

279 ：225-229：03/09/17 09:36

まず、多く出ている「シャドーコピーでいいじゃないか」という意見です。
（つまり
A a,b;
の時に
a = b;）

それは間違いです。
先にも述べましたが、ＶＣ＋＋環境ではシャドーコピーは信頼性が低いです。

更に言うなら、どんな環境でもC++である限り、シャドーコピーが使えない
場合があります。
それがリストです。

280 ：225-229：03/09/17 09:41

たとえば、次のようなリスト構造体を用意します。

typedef struct LISTbl {
　Listbl *next;
　void *pData;
　int length;
};
typedef struct LIST {
LISTbl *start;
LISTbl *end;
};

LISTはLISTblを管理します。

この場合、たとえばLISTが３つのLISTblを管理しているとすると

LIST A;
LISTbl Abl,Bbl,Cbl;

A.start = &Abl;
A.end = &Cbl;
Abl.next = &Bbl;
Bbl.next = &Cbl;
Cbl.next = NULL;

となります。

281 ：225-229：03/09/17 09:44

ここで
LIST B;
を用意して、Ａの内容をシャドーコピーでコピーしてしまうと……

B = A;
こうなると、B.start は &Abl　だし、 B.end は &Cbl　になってしまいます。

ここで、Aの最初の要素が要らなくなったので破棄してしまいます。
すると、
A.start = &Bbl;
A.end = &Cbl;
一見よさそうですが、Bの方が破綻しています。

B.start = &Abl; // Ablのデータはすでに開放済み

よって、このLISTという構造体はコピー用の関数が必要だという事は
お分かりになっていただけると思います。

282 ：225-229：03/09/17 09:48

さて、operator =()と同義の関数を用意すればいい、という話もありましたが、
それがいかに無駄な事であるかを説明します。

たとえば、LISTをコピーする関数
void CopyLIST( LIST &src, LIST &dst);
を作ったとします。

ここで、次のような構造体を作るとします。

typedef struct hoge {
　int ID;
　LIST list;
};

listをシャドーコピーするわけにはいかないのは前述のとおりです。
このhogeをコピーしようと思ったら、hogeのコピー専用関数も作らないと
いけません。

283 ：225-229：03/09/17 09:51

多分
void CopyHoge( hoge &src, hoge &dst );
みたいになるんじゃないかと思います。

operator=()を作らない場合、
このように「LISTを含んだ構造体」は全てにおいてコピー関数を
作る羽目になります。

また、LISTで扱うデータがLISTという話もよくある話です。
コンパイラや文章解析などでは当たり前の構造だと思います。
(mapかも知れませんが)

その場合、コピー関数を作る事は熾烈を極めます。
この場合も、operator=()をLISTに実装しておけば済むだけの話です。

284 ：225-229：03/09/17 09:53

これらの話は、ooの「モリポーフィズム」に則っていると、自分は考えます。
「データを扱う時、コピーは全て=で済ませる事ができる」
とする事で、全体のコーディング量を減らし、結果、作業量、バグを減らすというわけです。

少なくとも、リストを扱う場合はoperator=()を使うべきであり、コピー関数を用意するのは
馬鹿げた話だという事は理解していただけたと思います。

285 ：225-229：03/09/17 09:59

テンプレートがooじゃないという話にも反論したいと思います。

mapです。
これはlistのような線形分岐とは違い、二木分岐方式で複数のデータを管理します。
ここで使われるデータ検索キーは、以下の条件を揃えれば、何を使ってもいいのです。

(1)==で比較が出来る
(2)>で比較が出来る
(3)=でコピーが出来る

これは、かなり便利な事です。
operatorで実装してしまえば、自作のクラスでもキーとして使う事が出来るからです。
文字列でも数値でもです。

286 ：225-229：03/09/17 10:04

これも、モリポーフィズムの考えがなくては絶対に生まれなかったものだと考えます。

これを手続き型で行おうとすれば、検索キーの種類を変えるたびに
型を定義しなおし、コピー・比較関数も作らなくてはなりません。

テンプレートはooの作り出した武器だと思います。

キーを「比較する事が出来るオブジェクト」としてとらえ、
扱うデータも「扱われるオブジェクト」としてしかとらえないから、
このように「論理の使い回し」が出来る、というわけです。

世の中にモリポーフィズムが無ければ、テンプレートの実装は不可能です。
テンプレート使わないとooじゃないよね、などとは決して言いませんが
テンプレートとooは本質的に密接な関係にあるわけです。

287 ：225-229：03/09/17 10:10

あ、ひとつ書き忘れてしました。

operator=()を使う利点はもう一つあります。
それは、「シャドーコピーがあるから」です。

前述のとおり、LISTのコピーは専用の関数を使わないといけませんが、
それを全てチェックする事はできますか？
自分の担当だけならチェックする事は可能でしょう。でも、他人のは？
まず、無理ですね。
なぜなら、コンパイルエラーではじかないから。
LISTという構造体をどのような名前で宣言してもいいから。

operator=()を実装しない事で出てくる弊害は山のように考えられますです。

288 ：225-229：03/09/17 10:18

というワケですので、
「テンプレート実装してない言語はoo言語じゃない」
なんて事、全然言ってないという事もご理解下さい＞C++以外のoo言語マスターの方々

operator=の実装って、
オブジェクト指向が無くちゃ生まれなかったものだと思うんですよね。
オブジェクトはあくまで自分の意思で振舞うもので、
オブジェクトを使う側は使い方と管理に気を使えばいい。
コピーの仕方とかを周りが気にする必要はなくて、
=ってされたらオブジェクト自らがコピーの動作をすべき、という事です。

それによりコード量が恐ろしく減るという事は上記で実例を挙げてます。

289 ：仕様書無しさん：03/09/17 10:46

初心者の方がいたら、>>279-288 を信じないように。まるででたらめです。
そしたら List や Map は Java や Smalltalk や Ruby では実装できないことになります。
合っているのはせいぜい浅いコピーと深いコピーとの違いを気をつけよう、ぐらいです。
（それもなんかはずれてるけど。）
ちゃんと勉強できるところがありますので、そちらへどうぞ。

cppll ML: επιστημηさんの ML
http://www.freeml.com/ctrl/html/MLInfoForm/[email protected]

XP-JP ML
http://objectclub.esm.co.jp/eXtremeProgramming/

オブジェクトの広場 ML
http://www.ogis-ri.co.jp/otc/hiroba/index.html

デザインパターン ML: 結城浩さんの ML
http://www.hyuki.com/dp/dpml.html

290 ：仕様書無しさん：03/09/17 11:04

なんか覚えたててはしゃいでるんだろうか
痛々しいな

291 ：仕様書無しさん：03/09/17 11:27

>>289
根本的には正しいだろう。
Operator=の話に囚われすぎだぞ。
本当に日本語が読めない連中ばかりだな。

Operator=の話だと考えるから
> List や Map は Java や Smalltalk や Ruby では実装できないことになります
こんな言葉が出てくる。

>>279-288
これは C++の例だが、
Javaでは clone()とかで実装する。
そしてその根底にある思想は
>オブジェクトはあくまで自分の意思で振舞うもので、
>オブジェクトを使う側は使い方と管理に気を使えばいい。
まさにこれだろ。

別口でCopy関数を作る場合は、使う側が、使うもののCopy挙動と内容に気を配る必要がある。
この部分を排除できるのは、単なる構造化ではあり得ないだろ。

292 ：仕様書無しさん：03/09/17 11:31

モリポーフィズムって響きがいいね。

　 ∧＿∧
　（　´∀｀）　＜もりぽ

293 ：仕様書無しさん：03/09/17 11:33

>>291
> Javaでは clone()とかで実装する。

> このhogeをコピーしようと思ったら、hogeのコピー専用関数も作らないと
> いけません。
とか書くから突っ込まれるんだろ、コイツは

294 ：仕様書無しさん：03/09/17 12:03

shallow copyとdeep copyの違いが分かってれば十分じゃない？

295 ：仕様書無しさん：03/09/17 13:03

>>292
うん、いい響きだね。自分も時々やっちゃうけど・・・。
また今まで物凄い勘違いをしてたのかと思ってスゲー焦った。

296 ：仕様書無しさん：03/09/17 13:46

>>293
スマン
Ｃならコピー関数作らないといけないんじゃないの？

297 ：仕様書無しさん：03/09/17 14:01

>>296
CでもC++でもJavaでもコピー関数は「実装」しなければならない。
ただ、C++の場合、コピー関数の名前をOperator=と付けることが出来るし、
Javaの場合、clone()と付けることが出来るだけ。

298 ：仕様書無しさん：03/09/17 14:26

>>297
スマン
やっぱりよく判らない。

>>293 の言う「ツッコミ」どころがわからんのです

=で実装できれば、225-229の言ってるように
少ないコーディングで済むしコピー関数の呼び出しを意識しなくてもいい
からいいんじゃないの？

299 ：仕様書無しさん：03/09/17 14:47

このスレ「何で悪い」を書かないからよーわからんよ

300 ：仕様書無しさん：03/09/17 15:08

バカだから悪い。

301 ：仕様書無しさん：03/09/17 15:15

>>298
コーディング量は変わらないだろよ。

302 ：仕様書無しさん：03/09/17 15:39

>>301
スマン
そこがわからない

上記の例にならうと

LIST A,B;
COPYLIST( &A,&B);

って感じでLISTのコピー関数を実装すると

typedef struct STRUCT{
　LIST A;
　int i;
};

STRUCT C,D;
C=D; // ←コレやっちゃダメ！

// ↓この関数使ってコピー汁！
void COPYSTRUCT( STRUCT &D, STRUCT &C )
{
　COPYLIST( C.A, D.A );
　C.i = D.i;
}

と、LISTの部分にCOPYLIST()呼び出さないといけないから
結果的にLISTを含んだstructには全部コピー関数作らなきゃいけなくて、
コーディング量は増えるでしょ？

303 ：仕様書無しさん：03/09/17 16:03

>>302
class list
{
...
public:
　　list& operator=(const list& obj) { ... }
};

したら、

class STRUCT
{
private:
　　int i;
　　list lis;
public:
　　STRUCT& operator=(const STRUCT& obj)
　　{
　　　　i = obj.i;
　　　　lis.operator=(obj.lis);
　　}
};

結局コーディング量も気をつけなきゃいけないことも同じことでしょ。

てか、operator=() を実装しなきゃならない場合は通常コピー・コンストラクタも
実装しなきゃならないから、operator=() もコピー・コンストラクタも private に
して隠しておいて、assign() とか clone() とかでコピーした方が明示的で安心
というのはあります。

304 ：仕様書無しさん：03/09/17 16:06

STRUCT クラス（変な名前にしちゃったけど）のように、list クラスをメンバに持つ
クラスを作った場合、operator=() にしろ assign() や clone() にしろ、コピー関数を
クラスの数だけ作る必要があるということで。

305 ：仕様書無しさん：03/09/17 16:13

>>285
> テンプレートがooじゃないという話にも反論したいと思います。

> (1)==で比較が出来る
> (2)>で比較が出来る
> (3)=でコピーが出来る
>
> これは、かなり便利な事です。
> operatorで実装してしまえば、自作のクラスでもキーとして使う事が出来るからです。
> 文字列でも数値でもです。

たまたま STL のライブラリがそうなっているから仕方なく演算子をオーバーロード
するのだけれども、別に

(1) equals() で比較が出来る
(2) lessThan() で比較が出来る
(3) clone() でコピーが出来る

抽象クラスを作って、それに対して操作するライブラリであってもいいわけだ。
テンプレートで OO はできるけど、テンプレートは OO じゃない。

306 ：仕様書無しさん：03/09/17 16:14

>>303
は？
シャドーコピーに任せりゃ、STRUCT の operator=()は要らないでしょ？

STRUCT A,B;
A=B;
とすれば、STRUCTの各パラメータのoperator=()が呼ばれる。

だから実装が必要なのはLISTのoperator=()だけ。
STRUCTのoperator=()は必要ない。

307 ：仕様書無しさん：03/09/17 16:16

>>305
よく読め。
>テンプレートで OO はできるけど、テンプレートは OO じゃない。
285も同じ事書いてる。

308 ：仕様書無しさん：03/09/17 16:17

便利だったらtry/catchもOOということにしていいんですか？

309 ：仕様書無しさん：03/09/17 16:19

>>285

C++ が STL で演算子のオーバーロードを利用しているのは、C 言語との互換性の
ために残された OO じゃない型（プリミティブ型）のコーディング・スタイルと
見た目を一緒にするため。
あたりまえだけど、int や char には clone() や lessThan() が実装されていないから、
プリミティブ型とクラス型と両方で使えるライブラリにするには、演算子を
オーバーロードするのが手間がなくていい。
演算子のオーバーロードは OO から生まれたのではなくて、非 OO との互換性を
保つために仕方なく実装した。
ちなみに、STL はコードの見た目が同じなら継承されたメソッドでなくても呼び出し
可能だから、OO ではない。

310 ：仕様書無しさん：03/09/17 16:21

>>306
そういうあいまいなところが C++ っぽくて危険なコードでもある。

311 ：仕様書無しさん：03/09/17 16:22

>>309
そういう「そもそも論」をする場だろうか
ooが理解できない連中にoo教えるスレでそこにこだわる理由は無いよな

312 ：仕様書無しさん：03/09/17 16:24

>>311
そもそもだろうといまさらだろうと、STL は OO じゃないんだよ。

313 ：仕様書無しさん：03/09/17 16:25

>>307
書いてないよ。

314 ：仕様書無しさん：03/09/17 16:25

>>309みたいなのが職場にいたら「オブジェクト指向を理解できんとが何で悪いとや？」とも言いたくなるかも知れない

あと、無意味にageてるのは何で？

315 ：仕様書無しさん：03/09/17 16:25

>>311
そもそもじゃなくても、現にテンプレートは OO じゃないですが、それが何？

316 ：仕様書無しさん：03/09/17 16:26

結局
>>293
は
>>306
を知らなかった厨房って事でファイナルアンサー？

317 ：仕様書無しさん：03/09/17 16:27

>>314
テンプレートは OO じゃないから、テンプレートが理解できなくてもオブジェクト指向を
理解していないことにはならない。
てか、OO の話題にテンプレートは出て来ないから。

318 ：仕様書無しさん：03/09/17 16:29

>>316
そうだな。忘れてた。

319 ：仕様書無しさん：03/09/17 16:30

>>305
それだと、

>(1) equals() で比較が出来る
>(2) lessThan() で比較が出来る
>(3) clone() でコピーが出来る
>抽象クラスを作って、それに対して操作するライブラリであってもいいわけだ。

そのクラスを継承するクラスを作るわけか？
何か本末転倒な気が……

取得するデータは取得するデータとして扱いたいわけで、
そのデータが元々リストで管理されていたとかマップで管理されてたとか
意識するのはooじゃないよなー

320 ：仕様書無しさん：03/09/17 16:34

>>313
うむ、よく読んだら逆の事が書いてあるな。
失礼

321 ：仕様書無しさん：03/09/17 16:34

>>319
> 取得するデータは取得するデータとして扱いたいわけで、
> そのデータが元々リストで管理されていたとかマップで管理されてたとか
> 意識するのはooじゃないよなー
Iteratorパターンを使え。意識せずに済むぞ。

322 ：仕様書無しさん：03/09/17 16:40

>>321
IteratorはあくまでIterator。
たとえばhogeってクラスをstd:listで管理して、
hogeを取り出して云々ってやる場合、
取り出したデータをいつまでもlist<hoge>::Iterator型で管理するかどうかというと
フツー、んな事ぁしねぇ。

323 ：仕様書無しさん：03/09/17 16:48

>>319
C++ とは違って、たいていの OOPL では、完全に独立したスーパー・クラスというものが
ないから、そうやるのが合理的。

324 ：仕様書無しさん：03/09/17 16:52

>>323
thx

325 ：225-229：03/09/17 16:54

案の定、荒れちゃったな～
いろいろすいませんでした。
荒らしちゃったので、消えます。では。

326 ：仕様書無しさん：03/09/17 17:27

>>325
生㌔

327 ：仕様書無しさん：03/09/18 00:46

困った・・・。
「モリポーフィズム」が頭から抜けない。
仕事にならん。

328 ：仕様書無しさん：03/09/18 01:47

　 ∧＿∧
　（　´∀｀）　＜もりぽ

329 ：仕様書無しさん：03/09/18 02:31

　　∧＿∧
　（　・∀・）　　　|　|　
　と　　　　）　　 |　|
　　Ｙ　/ノ　　　人ｶﾞｯ
　　　 /　）　　 < 　>__Λ∩
　＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　　　/ 　←>>328

330 ：仕様書無しさん：03/09/18 09:41

興味深い論議ではあったよ。
Operator=()がオブジェクトがオブジェクトらしく動くための仕組みだってのは
今まで気が付かなかったけど、悪くない考え方と思うんだけど。

無下に否定してる連中がよく判らないんだが、何か別の言語厨房なの？

331 ：仕様書無しさん：03/09/18 09:49

ボクも頭の中が「モリポーフィズム」でオーバーライドされてしまった。
恐るべきスーパークラスを継承してしまったものだ。
いやゴッド(神)クラスというべきか！

332 ：仕様書無しさん：03/09/18 17:32

低脳な煽りばっかしだな……

333 ：仕様書無しさん：03/09/18 18:04

　　　(ﾟ∀ﾟ ) (ﾟ∀ﾟ ) (ﾟ∀ﾟ )　(ﾟ∀ﾟ) ( ﾟ∀ﾟ)( ﾟ∀ﾟ)( ﾟ∀ﾟ)＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
　　　(ﾟ∀ﾟ　)(ﾟ∀ﾟ　)(ﾟ∀ﾟ　)( ﾟ∀ﾟ ) (　ﾟ∀ﾟ)(　ﾟ∀ﾟ)(　ﾟ∀ﾟ)＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
　　( ﾟ∀ﾟ　)(ﾟ∀ﾟ　) (ﾟ∀ﾟ　) ( ﾟ∀ﾟ ) (　ﾟ∀ﾟ) (　ﾟ∀ﾟ) (　ﾟ∀ﾟ)＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
　　( ﾟ∀ﾟ　)(ﾟ∀ﾟ　) (ﾟ∀ﾟ　) ( ﾟ∀ﾟ )　(　ﾟ∀ﾟ)　(　ﾟ∀ﾟ)　(　ﾟ∀ﾟ)＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
　( ﾟ∀ﾟ　) (ﾟ∀ﾟ　) (ﾟ∀ﾟ　)　( ﾟ∀ﾟ )　 (　ﾟ∀ﾟ)　(　ﾟ∀ﾟ) 　(　ﾟ∀ﾟ )＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
　( ﾟ∀ﾟ　)(ﾟ∀ﾟ　)　(ﾟ∀ﾟ　)　( ﾟ∀ﾟ )　 (　ﾟ∀ﾟ)　　(　ﾟ∀ﾟ) 　(　ﾟ∀ﾟ )＜ﾎﾟｰﾌｨｽﾞﾑ！
( ﾟ∀ ﾟ　)(ﾟ∀ﾟ　)　(ﾟ∀ﾟ　)　( ﾟ ∀ ﾟ )　　(　ﾟ∀ﾟ)　　(　ﾟ∀ﾟ)　　(　ﾟ∀ﾟ )＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
( ﾟ∀ ﾟ　)( ﾟ∀ﾟ　) ( ﾟ∀ﾟ　)　( ﾟ ∀ ﾟ )　　(　ﾟ∀ﾟ )　　(　ﾟ∀ﾟ )　　(　ﾟ ∀ﾟ )＜ﾓﾘﾎﾟｰﾌｨｽﾞﾑ！
つ」7=（つ」7=∩（つ」7=∩（つ」7=∩-（つ」7=∩-　（つ」7=∩　（つ」7=∩
|　　　j　|　　　j　　|　　　j 　 |　　　j 　　 |　　　j 　　|　　　j　　.|　　　j
し'⌒Ｕ　し'⌒Ｕ　　し'⌒Ｕ　　し'⌒Ｕ　　し'⌒Ｕ　　し'⌒Ｕ.　　.し'⌒Ｕ
ｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯｻﾞｯ

334 ：仕様書無しさん：03/09/19 00:37

ﾓﾘﾎﾟｰ!!

335 ：仕様書無しさん：03/09/19 01:00

ﾓﾘﾎﾟ流行らせようとしてｲｲ気になるな。情けない。

336 ：仕様書無しさん：03/09/19 09:53

こうして煽りを続けるのはひょっとして……

> 結局
>　>>293
> は
> >>306
> を知らなかった厨房って事でファイナルアンサー？

これがよっぽど悔しかったのかな？これぐらいしか該当するレス無いしなー。

337 ：仕様書無しさん：03/09/20 00:31

　　　　　　　∧＿∧
　　　　　　　（　´∀｀）＜　もりぽ
　　　　　　　/, 　　つ
　　　　　　（_（＿,　）
　　　　　　　　しし'

久々に見た大型勘違いなんで、是非流行って欲しいんだが。
もりぽ。

338 ：仕様書無しさん：03/09/20 13:40

>>337
ほかに言ってることが、わりとまともなだけにな。(w

339 ：仕様書無しさん：03/09/24 02:32

　 ∧＿∧
　（　´∀｀）　＜もりぽ

340 ：仕様書無しさん：03/09/24 09:09

　　Λ＿Λ　　＼＼
　（　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　　 |　|
　　Ｙ　/ノ　　　人
　　　 /　）　　 < 　>__Λ∩
　＿/し'　／／. Ｖ´∀｀）/ ←>>1-339の間で「もりぽ」と言ったﾔｼ
　（＿フ彡　　　　　　　/

341 ：仕様書無しさん：03/09/24 12:53

電磁波にやられている大根オヤジプログラマどもは勉強してもムダ

342 ：仕様書無しさん：03/09/24 14:16

何でオブジェクト指向の良さを教えたりする方向にならないのかな……

343 ：仕様書無しさん：03/09/24 15:13

そりゃ、オブジェクト指向なプログラミングが出来る言語を使ってはいるが、
オブジェクト指向なプログラミングはしていないから説明出来ないということだろ。
ｵﾏｴｶﾞﾅｰ

344 ：342：03/09/24 17:44

>>343
じゃ、ここに
＞オブジェクト指向なプログラミング
をしてるやつは居ない、と。

納得できるよーな、そうでないよーな。

結局、どいつもこいつも>>1と大差無いって事か。

345 ：仕様書無しさん：03/09/24 21:31

>>342 いや、最初のうちはその努力の跡が見られ(ru

346 ：仕様書無しさん：03/09/25 00:19

なんでも部下に訊いてんじゃねーぞ　バーカ

ちったー自分で調べろや　ﾎﾞｹ社長殿

347 ：仕様書無しさん：03/09/25 00:35

clone()は
不変クラスには不要なのだが。

といってもこのスレでわかる奴は限られているな

348 ：仕様書無しさん：03/09/25 00:38

質問ですが VB.Netで　VB6と同じように
普通にPG組んでいますがやばいですか?
ちなみに、クラスとかよく分かりません
誰か教えてください

349 ：仕様書無しさん：03/09/25 00:40

>>347
「不変」クラスなら、thisを返してみるのも一興かと。
混乱の元かもしれないけどさ。

350 ：名無し＠沢村：03/09/25 01:56

手続き型言語を理解できて、オブジェクト指向を理解できんというのはおかしいぞ。
というのは、手続き型言語よりもオブジェクト指向のほうが、人間の脳にとって自然に受け入れられると本に書いてあったからだ。

351 ：名無し＠沢村：03/09/25 01:58

352 ：仕様書無しさん：03/09/25 02:00

>手続き型言語を理解できて、オブジェクト指向を理解できん
要するに、「手続き型言語」もたいして深く理解していなかっただけ。

関数ポインタがちゃんと使える人間なら、CやJavaのクラスがいったい
なにやっているかなんて、直ぐ分かるよねえ。ソレがどうありがたい
のかは、多少勉強せんといかんかもしれんが。
インスタンスメソッドなんて、要するにthisポインタを暗黙に渡して
いるだけだし。

353 ：仕様書無しさん：03/09/25 02:15

>>342にお応えして漏れの思うOOの良さをageてみる
（と、言っても漏れC++とJavaとCしか知らんからその範囲内で。
かつ、なるべくOO用語を書かないように注意してみる。）

一番大きいのは、C++/JavaはCと比べて表現能力が多彩であること。

Cは、構造体というシンタックスによりデータ抽象を表現できる。
ただし、構造体のシンタックスが自然に表現するものは、
「あるデータはあるデータを持つ」という「関係」である
（例：FILE構造体はファイルディスクリプタというデータを持つ）

C++/Javaはclass（とInterface)というシンタックスにより、同じくデータ抽象を表現できる。
ただし、classのシンタックスは「あるデータはあるデータを持つ」に加えて
「あるデータはあるデータの一種である」という「関係」を自然に表現できる。

354 ：仕様書無しさん：03/09/25 02:16

この関係を表現できるとどううれしいのか、最初はピンと来ないと思う。
が、ピンと来てみるとこの表現の応用範囲が広いことが分かってくる。
これを使うとスマートに表現できることを、
Cでは回りくどい表現しかできないことが分かってくる。
（Cでこれを表現するには、例えばあるポリシーに従って
関数ポインタメンバを持つ構造体とその構築、破棄関数を書き、
関数ポインタのテーブルを用意して、
実行時に適切な関数ポインタを探すコードを書く。
つまりC++が暗黙のうちに生成しているコードを自分で書く必要がある。）

このアドバンテージは、構造化された関数というシンタックスを持つ言語が
構造化されていない言語に対してもつアドバンテージに匹敵する。
これがOOを身に付けたほうがよい理由である。

355 ：仕様書無しさん：03/09/25 02:58

>>354
オレはＣ＋＋覚えるのが面倒＆Ｃ言語しか使えない環境があるという建前で
自分で実装しちゃったわけだが。　やっぱ覚えた方が便利だよな。
あー、もっとスマートな言語にとってかわらんかな。

356 ：仕様書無しさん：03/09/25 03:06

>>354 そして、再び++のつかない素の「C」に回帰するんだろ。
MFCの呪縛からのがれるために。

357 ：仕様書無しさん：03/09/25 07:54

>>352
＞ソレがどうありがたいのかは、多少勉強せんといかんかもしれんが。
まさにこれがキモだろうな。
煽るOO厨がこれを理解してるのか疑問だ。
非OO厨もクラスの書き方くらいすぐに分かってるだろ。有効性が分からないだけで。

世の中のマでC++使ってOO厨を名乗る香具師、単にCプログラムにクラス乗っけてるだけで
天狗になってる奴大杉。

358 ：仕様書無しさん：03/09/25 07:54

>>356
かったるくて C なんてやってられるかよ。

359 ：仕様書無しさん：03/09/25 07:57

店員: オブジェクト指向でよろしかったでしょうか。
お客: 知るかヨ！

360 ：仕様書無しさん：03/09/25 07:58

>>357
> 単にCプログラムにクラス乗っけてるだけ

MFC ってそういうクラス・ライブラリだよね。

361 ：仕様書無しさん：03/09/25 14:54

俺は最初OOなんてクソ食らえって思っていたけど
OOのソースを見たら一瞬でそのすばらしさがわかったよ

362 ：名無し＠沢村：03/09/25 19:43

>>48
＞オブジェクト指向を知らずに、動画関連とかフィルターとかどうやるん？

一枚岩のプログラムで書くんだよ。

363 ：仕様書無しさん：03/09/25 19:57

SSCLIなんてただのCだよ。クリティカルなところを
ゴリゴリと書いてはデバッグってやるにはCだよ。
MSがC++を推奨してたのはアプリケーションプログラマに対して
だけだよ。

364 ：仕様書無しさん：03/09/25 23:25

>>13
>>1じゃないけど、脂っこいよ。
ちょっと古い店は店内がギトギト。

365 ：仕様書無しさん：03/09/25 23:27

>1
周りがオブジェクト指向プログラミングやってて、
貴様だけが構造化プログラミングやってるとしたら、
そりゃあ、理解できないのが悪いに決まってる。

世の中には２種類の批判が存在することをよく頭に叩き込んでおけ。
１．理解した上で批判する。
２．理解できないので批判する。

後者は、言うまでもなく理解者と議論する余地がない。

366 ：仕様書無しさん：03/09/25 23:30

>>365
>>1は批判してるんじゃ無くて、開き直ってるように思えるんだけどな。

367 ：仕様書無しさん：03/09/26 00:16

>>366
そうかも知れんが、>>365の分類に従うなら、2になるだろ？

368 ：仕様書無しさん：03/09/26 00:24

>>367
だから>>365は批判の分類だろ？
批判してない奴に適用するのは変じゃないか？

369 ：ネムタイよう：03/09/26 01:07

VB.NETでもWEBアプリケーションでしょ？
JAVAとVB.NETの違いは、教えてくり★

VB.NETは、オブジェクト指向は含まれてないの？

教えてくり★

370 ：ネムタイよう：03/09/26 01:09

348 ：仕様書無しさん：03/09/25 00:38
質問ですが VB.Netで　VB6と同じように
普通にPG組んでいますがやばいですか?
ちなみに、クラスとかよく分かりません
誰か教えてください

の質問も誰か答えて★
かもーん★

371 ：仕様書無しさん：03/09/26 01:29

>>369,370

>VB.NETでもWEBアプリケーションでしょ？
う～ん。きっとそうなんじゃない？

>JAVAとVB.NETの違いは、教えてくり★
絶対違うと思うよ。角度とか。

>VB.NETは、オブジェクト指向は含まれてないの？
含まれてる。

>質問ですが VB.Netで　VB6と同じように
>普通にPG組んでいますがやばいですか?
本当に「普通に」組んでるならやばくないけど、十中八九君はやばい

372 ：仕様書無しさん：03/09/26 09:09

Object-Orientedを理解できない奴って本当にいるのかなあって思う。
うまく使いこなせないということはあるかもしれんが、
まったくもって自然な考えなんだが。

373 ：仕様書無しさん：03/09/26 15:47

VBとかやってると苦労するよ。
Javaに移行した当初もVB流で無理やり書いていた
型の概念が希薄だから静的型と動的型を2回宣言してるのがなぜだかわからなかった。
クラスに分けたりするのが合理的なことだということはすぐにわかったけど
具体的にどんな風に分けていくのかがわからんかった。
今思えばデザインパターンの本を読むのが1番だったと思う。

向き不向きがあって必ずしもOOが必要な環境にいない人もいる
オブジェクト指向はスクリプトを書くにはまどろっこしいし
(そういう意味でRuby,Pyは皮肉な言語だと思う。）
poorなハードウェアには向いていないから何でもかんでもオブジェクト指向
ってわけにはいかんと思う

大学はいまだに4年間C言語とBASICとかざらだから
プログラムは組めるがオブジェクト指向はわからんってやつはたくさんいる。

374 ：仕様書無しさん：03/09/29 17:08

前に他のプログラマーともめた事。
とあるデータがAかBかCか、分類を返すという判定関数。

オレは「このデータがAかBかCか判ればいいんだから、わざわざクラス実体化させる必要ないでしょ、staticメソッドにして」と主張した。
そのクラスはリソースを多く取得するので、なるべく実体化させたくなかったのだ。
相手はしかし、わざわざ判定するのにオブジェクトを実体化させる必要があるという。プログラム上、staticにもできるのに、クラスを実体化してくれ、というのだ。
理由を聞くと
「クラスというものは、一度になるべく沢山の引数を指定するように設計すべきなんですよ、それがオブジェクト指向です」
と、すごい回答が返ってきた。

つーか回答じゃねぇし……

結局、オレの案が通った。当たり前だ。

375 ：仕様書無しさん：03/09/29 20:25

>>374
ﾜﾗﾀ

> 「クラスというものは、一度になるべく沢山の引数を指定するように設計すべきなんですよ、
>　　それがオブジェクト指向です」

一体何をどう勘違いしたら、
こういう考えが出てくるんだろう…(w

376 ：仕様書無しさん：03/09/30 00:42

クラスフィールド、クラスメソッドを動的アクセスする馬鹿って結構居るもんだよ。
そういうの見ると、メンテ中に嘔吐しそうになる。

377 ：仕様書無しさん：03/09/30 00:51

構造化指向言語「Java」

378 ：仕様書無しさん：03/09/30 00:54

時代はやっぱり「構造化プログラミング」！

379 ：仕様書無しさん：03/09/30 02:47

クラスフィールドのダイナミック関数ってDelphiあたりのエキスポートから
よく見受けられるが、Delphiは、namespaceないからしょうがないんだろうね。

380 ：仕様書無しさん：03/09/30 05:55

言語は関数型言語にどんどん近づいてきてる。
それは何故か？
既存のオブジェクト指向言語ではオブジェクト指向の
利点と欠点を天秤に比べると割に合わないからだ。
オブジェクト指向の利点は保守性、統一性、再利用性などだが、
そんな事は既存のオブジェクト指向言語を使わなくても出来る事だ。
逆に現在のオブジェクト指向言語では関数型言語に比べ、肥大化しすぎて
生産性が著しく損なわれているのが現状だ。

詳しくは下記を参照の事。
http://www.shiro.dreamhost.com/scheme/trans/icad-j.html

381 ：仕様書無しさん：03/09/30 06:03

近い将来オブジェクト指向という幻想的、宗教的な言葉はなくなるだろう。
Javaなど肥大化した言語もも能力のある人間は使わなくなるだろう。
能力のある人間の中で残るのは、
保守性、統一性、再利用性という現実的かつ実効性のあるノウハウだけだ。

382 ：仕様書無しさん：03/09/30 06:14

>>381
あなたは一生Haskellだけで開発を続けてください

383 ：仕様書無しさん：03/09/30 07:26

クラスライブラリを暗記って大変ではありませんか？

384 ：仕様書無しさん：03/09/30 07:53

>>383
脳じゃない！　体で覚えろ！

385 ：仕様書無しさん：03/09/30 08:17

>>383
君は日本語が使えるようだが、
国語辞書を暗記するのはさぞ大変だっただろうね。

386 ：仕様書無しさん：03/09/30 09:37

>>385
383を批判したい気持ちはわかるが
自然言語とプログラミング言語を同列に語るのは乱暴すぎやしないか？
このあたりの脳の仕組みが解明されるのに，もうちょっと時間がかかるはず。

387 ：仕様書無しさん：03/09/30 10:24

>>385
めちゃくちゃ大変だったよ。広辞苑一冊丸暗記するのに 10 日もかかった。

388 ：仕様書無しさん：03/09/30 11:54

ライブラリの暗記をするのかしないのかっていうと、しないワケなので……
クラスライブラリは、使う時は該当クラスだけ調べればいいのでライブラリより楽かも

389 ：名無し＠沢村：03/09/30 12:44

オブジェクト指向を理解して使いこなすためには、最低でも５８程度の偏差値が必要だろうね。
大学でいえば成城大、芝浦工大、電通大以上だ。このレベルではちょっときついが、頑張れは何とかなる。
６１以上になると、手続き型言語を覚えるのと同程度の労力でオブジェクト指向もマスターできる。
日本女子大、学習院、青学以上だ。
５４以下ではまず不可能だろうね。
国際大、金沢工大、熊本学園大などだ。
もちろん偏差値が高いのにランクが低い大学にいってるやつとかは、この限りではないよ。

390 ：名無し＠沢村：03/09/30 12:47

２ちゃんねらーの平均偏差値は５４～５６の間とおれは見てるから、オブジェクト指向を理解して使いこなすためには、ちょっと足りないものがあるね。
だから２ちゃんねらーには手続き型言語が合っている。
もちろん頑張れば不可能ではないから、やってみることだ。

391 ：仕様書無しさん：03/09/30 12:57

沢村の偏差値はいくつですか？

392 ：仕様書無しさん：03/09/30 13:00

オブジェクト指向っていうのは単なるノウハウに過ぎんから
中学生でも分かるだろ。
まあ偏差値が低いのは中学の頃から馬鹿なので分からないかも知れんが、
俺はそんな世界は知らないから何とも言えない。

393 ：仕様書無しさん：03/09/30 13:01

　　　ちょっと、入港しますよ。　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　.／=S=/
　　　　　　　　　　　　　　　　／/＿＿＿＿,───ヽ　　　　　　　　　＿＿＿／＿＿/_
　　　　　　　　　　　　斤┬二二二二二二二二￣￣￣￣￣￣ヽ＿/＿＿＿＿＿＿＿＼＿_
　　　　　　　　　　　　ｴ￣＿＿＿＿＿＿＿＿＿＿/二二二二/　」」」」」」」　」」」」」　　　」」」＼＿＿＿
　　　　　　　　　　　　/　　　ﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛﾛ　　　　　　」」」」」ヽ二二ｴ二二ｴ二二二ヽ＼　　　＼＿＿＿＿
ヽ────────　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　￣￣￣　　　　　　|＿＿
　＼　　　　万景峰　　　＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝　　朝鮮民主主義人民共和国　∈≡≡≡≡　　　|
　　＼　ψ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|
　　　丿⌒ﾐヾヽ丶　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ノﾐヾ
　⌒"ヾゞゞ∽～～⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒

394 ：仕様書無しさん：03/09/30 20:25

>>383
暗記って言うか、知っておくべきことは
・そのクラスライブラリで出来ること/出来ないこと（自力で組まないといけないこと）
・どのクラス（あるいは名前空間）が、どんな機能を持つか。その概要。

ぐらいでいいんじゃないか？とネタにマジレスしてみる。

395 ：仕様書無しさん：03/09/30 23:57

>>372
C厨やVB厨、COBOLerには理解できない奴が多い

396 ：仕様書無しさん：03/10/01 00:29

>395
結局、Javaからプログラミング始めた奴が勝ち組みってことか。

397 ：仕様書無しさん：03/10/01 00:31

>>396
ネタを信じるならな（ｗ

398 ：仕様書無しさん：03/10/01 17:22

事実だろ。だから俺は初心者にC言語やVBはすすめない

399 ：395：03/10/02 11:14

>>397
C言語くらいは薦めろ

C + Java
これは最低限必要だ

400 ：仕様書無しさん：03/10/02 11:40

Javaから始めた奴なんて二等兵がいいとこだな

401 ：仕様書無しさん：03/10/02 11:55

そうだC → Java　→　J2EE
なら元帥(エンタープライズアーキテクト)になれる可能性も広がる。

Javaからはじめても
Java　→　J2EE → C
Java　→　J2EE
Java　→　C → J2EE

とかいけばC → Java　→　J2EEの類と結局同じなんだけどな。

402 ：仕様書無しさん：03/10/02 13:41

「オブジェクトって何か？」から説明したほうがいいのか？

403 ：仕様書無しさん：03/10/02 14:01

科学はこの世の多くの問題を解決したのは事実だが、
科学がこの世の全ての問題を解決できない。

オブジェクト指向で多くの問題を解決できるかも知れないが、、
オブジェクト指向で全ての問題を解決できると信じてはいけない。

404 ：仕様書無しさん：03/10/02 15:31

オブジェクト指向ってさ、プログラミングとは別に発生したの？

どーもオブジェクト指向＝オブジェクト指向プログラミングと
言われてるような気がして。

405 ：参考になれば：03/10/02 16:43

OOP が解らないというのは、解っていないのに解ったように思うよりましです。
私も最初は OOP を理解できませんでした。OOP を理解することは悟るような
側面があります。

OOP:Object Oriented Programming（あえて訳せは「本質指向プログラミン
グ」）のような哲学用語を使って解りにくくしています。こんな言葉遊びに
惑わされないで下さい。

MFC のような OOP にもなっていないようなライブラリが、未だに広く使われ
ています。MFC を使っていて腹を立てないプログラマーは OOP を理解してい
ないと断言できます。MFC が広く使われていることは、OOP を理解していない
プログラマーが多数派であることを示していると考えます。

私が OOP を悟ったと思ったのは中村正三郎さんの「OOP は DOS の copy コマ
ンドで解る。同じ、copy コマンドで、ファイルにも、プリンタにも RS232C
ポートにもデータを送れる。対象に合わせて、自動的に異なる copy 手続きが
実行される」という内容の一文でした。参考になれば幸いです。

406 ：仕様書無しさん：03/10/02 17:12

ＯＯとは下請け丸投げ。

407 ：仕様書無しさん：03/10/02 17:13

つまりゼネコンはオブジェクト指向。

408 ：仕様書無しさん：03/10/02 17:15

オブジェクト指向で泣かされるのは常に下請け。

409 ：仕様書無しさん：03/10/02 17:26

オブジェクト指向なんて貴族の論理。富豪の理屈。

410 ：仕様書無しさん：03/10/02 17:39

オブジェクト指向では、あなたが「パンを食べたい」と思ったらあなたが
買いに行ってはいけないのである。

貴族を思い浮かべればいい。
「わらわはパンを食べたいのじゃ」とメッセージを投げれば使用人
（オブジェクト）が駆けずり回って（お金がなければ強盗でもして）
パンを手に入れて渡してくれるのである。

411 ：仕様書無しさん：03/10/02 17:41

つまり貧乏人には理解できない。

412 ：仕様書無しさん：03/10/02 19:49

JavaやるならCとC++とUNIXは出来ないとただの小兵に過ぎん。
鯖のカーネルいじれないでWedアプリ作ろうなんて１００年早い。
あと当然perlも必須な。１行スクリプト腐るほど使うからな。
JavaだけでいいとかCとJavaだけでいいという奴はレベルが低すぎる。
こいつらは、多分最近前Win房だったんだろう。
こいつらではまともなWebアプリは作れないと断言できるね。

413 ：仕様書無しさん：03/10/02 20:03

Wedアプリなんて作りたくない。

414 ：仕様書無しさん：03/10/02 20:19

>>412
プログラマ志望なの？

415 ：仕様書無しさん：03/10/02 20:21

>>414
???

416 ：仕様書無しさん：03/10/02 20:27

>>412
>JavaやるならCとC++とUNIXは出来ないとただの小兵に過ぎん。
これには同意。既存資産の流用と言う意味でもうまく扱えた方がいいと思う。

>鯖のカーネルいじれないでWedアプリ作ろうなんて１００年早い。
鯖のカーネルいじれるまで100年かかるとは思えない。その都度覚えればいいんじゃね？

>あと当然perlも必須な。
これがわからん。今までWeb組んでいてPerlが「必須」になった場面はない。

417 ：仕様書無しさん：03/10/02 20:32

>>416
お前UNIXまともに使った事ないだろ。

>今までWeb組んでいてPerlが「必須」になった場面はない。

この発想からしてまともなUNIX使いではないと断定できる。

418 ：仕様書無しさん：03/10/02 20:33

正直、>412の井の中の蛙ぶりが痛い。
自分の関わっている所がWebアプリの
すべてだとでも思ってるんか？

419 ：仕様書無しさん：03/10/02 20:35

sedやawkで十分。
Perl使うまでもない場合が多いな。

420 ：仕様書無しさん：03/10/02 20:38

>>418
圧倒的にサーバーサイドで使う言語を使いこなすのに
鯖が使いこなせないなら小兵だと言う事は事実だろ。
お前が使いこなせないからと言って嫉妬するなよ。

421 ：416：03/10/02 20:38

>>417
まあ、ふつーに仕事で使うぐらいですが、別にUNIX使いではないです。
別に今まで組んだ中にもPerlを全く使わないWinオンリーのwebアプリとかあるし、
別にPerlは「なくてはならないもの」ではないだろう？(狭義の意味で)

422 ：仕様書無しさん：03/10/02 20:51

>>419
ワンライナー使わないUNIX使いも珍しいな。
効率考えてほうがいいぞ。
>>421
Webアプリでもチョロイ物作るのには最適だぞ。
税金だと思って覚えておけ。
多言語で基礎が出来ていれば
言語習得には２週間あれば十分だ。

423 ：仕様書無しさん：03/10/02 20:55

>>412
うちの会社には入社できないと思うけど、がんばってね。

424 ：416：03/10/02 20:57

>>422
いや、Web組んでいる人間でPerl(言語)を知らないのは詐欺でしょうｗ
一応習得しているつもりです。Perlﾊｶｰではないですけど。

425 ：419：03/10/02 20:58

ワンライナーはsed,awkが王道。
perlはシステムによってverが違ったりするので気を使う。
運用しらん開発者か？

426 ：仕様書無しさん：03/10/02 21:00

ふ～ん、詐欺なんでつか。
Ｗｅｂ系３年やってるけど、使ったためしなし。

427 ：仕様書無しさん：03/10/02 21:03

>426
Webアプリでもチョロイ物作るのには最適だぞ。
税金だと思って覚えておけ。
多言語で基礎が出来ていれば
言語習得には２週間あれば十分だ。

428 ：仕様書無しさん：03/10/02 21:06

言語を知らなくても設計できるのがオブジェクト指向

429 ：仕様書無しさん：03/10/02 21:06

>>425
sedじゃ大したことできないだろ。
perl出来ればいろいろ使えて便利だぞ。
習得はすぐ出来るから勉強してみろ。

430 ：419：03/10/02 21:08

ワンライナーだから大したことしなくて、いいんだってば。

431 ：仕様書無しさん：03/10/02 21:13

>>403　資源。じゃなかった
「至言」。
COBOLが出来た時、TSSが出来た時、仮想記憶が出来た時、構造化が出たとき、Win95が出たとき、etc...
全ての問題は解決する。って言う奴が沢山いた。解決したかというと周知のとおり。
こんなにやさしく表現してくれているのに、なぜ誰も反応しない。
これは「オブジェクト指向を理解しなくていい」って言っているわけではないよ。
「オブジェクト指向も万能ではない」＆
「オブジェクト指向が万能と思うことは危険なことだ」って言っているんだ。

432 ：ちか：03/10/02 21:18

かなりおすすめの無料着メロサイト♪
ゲームとか画像UP掲示板とかもあって面白そうだったよ～♪
ほんとだまされたと思って行って下さい☆
絶対満足するから～♪

http://yokozuna.tv/m.php?i=21

433 ：　：03/10/02 21:19

>>431
雑誌の作るブームに翻弄される部長さんとかじゃないんだから、
万能だなんて思ってる奴はいないだろ。

434 ：仕様書無しさん：03/10/02 21:21

>>431
> なぜ誰も反応しない。
夢を抱かせて金を巻き上げようとするヤツと、
夢を抱いて金だけ巻き上げられるヤツが居るから。

で、「万能じゃないよ」と説教すると、マーケ・消費者の
双方から煙たがられる罠。

435 ：仕様書無しさん：03/10/02 21:34

オブジェクト指向は勉強しておいて損はないぞ。
３日もあればオブジェクト指向がどういう物か分かる。
１週間程度勉強すれば十分使えるようになる。

436 ：仕様書無しさん：03/10/02 21:36

とにかく現状に満足せず、どんどん勉強する事だ。
選択肢が増えればいろいろ役に立つ。

437 ：仕様書無しさん：03/10/02 21:47

おまえら今日Perlを勉強し始めた奴につられ杉

438 ：仕様書無しさん：03/10/02 21:52

>>437
!#/usr/local/bin/perl
だったっけ？
!#/usr/bin/perl -speedy
だっけ？
正解はどっち？

439 ：仕様書無しさん：03/10/02 21:55

オブジェクト指向設計は俺には無理ぽ

440 ：仕様書無しさん：03/10/02 21:57

>>438
!#/usr/local/bin/parl

441 ：431：03/10/02 21:57

>>434
強烈に「醒めて」いる方ですね。
揶揄するつもりは全く無いのですが「期待していた以上のレス」でした。

442 ：仕様書無しさん：03/10/02 21:59

>>440
プププ
正解は
!#/usr/bin/ｐerl

443 ：仕様書無しさん：03/10/02 22:01

激しくすれ違いだったような。

444 ：仕様書無しさん：03/10/02 22:08

オブジェクト指向は家電で例えると
昔の「ファジー」現在の「マイナスイオン」効果ぐらいは期待できる。

445 ：仕様書無しさん：03/10/02 22:12

>444
信じられんことを言うヤツだな。
オブジェクト指向はすべての構成要素が説明可能な
単なる基本技術でしかないわけだが、その程度の
ことも理解してないのか？

別に過大評価する必要も何もないし、別に知りたく
なければ避けて通るのも不可能ではないが、そんな
インチキ商品と一緒にすんなよ。

446 ：仕様書無しさん：03/10/02 22:16

>>444
素人にはそれ以上には期待できるぞ。
どんな言語でも他人に
分かりやすく、再利用を考えながら
書くのは素人にはなかなか難しいものだ。
きちんと頭の整理が出来ないとすぐにソースが
スパゲッテイになる。
オブジェクト指向は素人でもある程度までは綺麗にかけるというか
書かされるから素人にお勧めだな。

447 ：仕様書無しさん：03/10/02 22:18

>>446
それは幻想。構造化言語のほうがまし。

448 ：仕様書無しさん：03/10/02 22:23

>>447
そうでもない。
お前も初心者の頃はぐちゃぐちゃなソース書いてただろ？
思い出してみろ。あの頃を。

449 ：仕様書無しさん：03/10/02 22:27

>>448
OOPではオブジェクトの寿命という時間軸的なスパゲッティが、
構造的なスパゲッティに絡んで、構造化言語よりも理解不能な
コードになる可能性がある。
「プログラミング初心者」ということであればなおさらそうだろう。

450 ：　：03/10/02 22:40

>>444
「インバータくらい」の間違いじゃありませんか？

>>448
ソースがぐちゃぐちゃなのは解決できないと思う。

>>449
継承関係の管理の方が問題なような気がする。

451 ：仕様書無しさん：03/10/02 22:41

>>449
同意。実務でそれを経験した身としては同意せざるを得ない。
初心者に作らせるからそうなる。という開発時の現実の構造的な欠陥を正さなければ、この新たなスパゲッティは増殖するばかりだ。
c++の事情は知らないが、javaはこのままではポストCOBOLとなる。
「負債にも関わらず資産とみなされる」という意味で。

452 ：仕様書無しさん：03/10/02 22:51

OOはちゃんとクラスが定義できるレベルの分析設計が
できる人間が使えばとても有益なものでありその限りに
おいては決してインチキの類でもないのだが、単なる
素人のOOPだけじゃ駄目駄目だよん、なんてのはもう
20年近く前からSmalltalkやらを使っている人間には
常識なんで、正直、今さらの話題なんだが。

453 ：仕様書無しさん：03/10/02 22:58

Smalltalk厨登場の巻き。

454 ：仕様書無しさん：03/10/02 23:16

>>452
> ちゃんとクラスが定義できるレベルの分析設計
を習得するのに役立った書籍/資料を教えてほしいナリ。

455 ：仕様書無しさん：03/10/02 23:30

ばかめ。

オブジェクト指向なんてのはな、オブジェクト指向が役に立つ
程度のシステムを作るのに有効なだけだよ。

456 ：仕様書無しさん：03/10/02 23:32

まぁ、時代はＣ＃のようなコンポーネント指向に
なりつつあるわけだが

457 ：454：03/10/02 23:33

荒れてレスが流されてしまいそうな悪寒

458 ：仕様書無しさん：03/10/02 23:38

>>454
推薦図書/必読書のためのスレッド PART 12
http://pc2.2ch.net/test/read.cgi/tech/1060693125/

459 ：仕様書無しさん：03/10/02 23:41

＞455
オブジェクト指向に向いていないシステムが
あるなんて、それこそ当たり前の話じゃないか。
（ちなみに「程度」とかいう言い方をしているが、
大きいシステムの方が役に立つことが多いぞ）

すべてオブジェクト指向でやるべし、なんていう
痛いことを言っているヤツでもいたか？

460 ：454：03/10/02 23:43

>>458サンクス。逝ってくる。

461 ：仕様書無しさん：03/10/03 00:11

オブジェクト指向を理解できない奴と
ポインタを理解できない奴は
５０歩１００歩。

462 ：仕様書無しさん：03/10/03 00:18

オブジェクト指向も理解できないでソフトウェア技術者として恥ずかしくないのだろうか？
そういう漏れの職場でもようやくオブジェクト指向が根付きつつあるというレベルだけど…。
若い連中は多胎とかデザパタとか飲み込みが早くて助かる。
なかなか飲み込めなかったジジイ連中も、最近ようやく理解できてきた。
一度理解できればこれほど便利な道具は無いと誰もが気づくらしいね。
最初は批判的・懐疑的だった奴らも、今ではすっかりオブジェクト指向信者になってしまった。

463 ：仕様書無しさん：03/10/03 00:30

COBOLも理解できないでソフトウェア技術者として恥ずかしくないのだろうか？
そういう漏れの職場でもようやくCOBOLが根付きつつあるというレベルだけど…。
若い連中は多胎とかグローバル変数とか飲み込みが早くて助かる。
なかなか飲み込めなかったジジイ連中も、最近ようやく理解できてきた。
一度理解できればこれほど便利な道具は無いと誰もが気づくらしいね。
最初は批判的・懐疑的だった奴らも、今ではすっかりCOBOL信者になってしまった。

464 ：仕様書無しさん：03/10/03 00:34

最近OOわかり始めた者ですがＶＢでは味わえない「設計」技術というの非常に面白い
プログラムに対する考え方変わりますよ。

465 ：仕様書無しさん：03/10/03 00:34

COBOLプログラマと呼ばれる人種
VBプログラマと呼ばれる人種

466 ：仕様書無しさん：03/10/03 00:38

オブジェクト指向の核といったらインターフェース継承による多態だろうな。
VBでも出来ちゃうわけなんだけど。

467 ：仕様書無しさん：03/10/03 00:40

>>412は旗本

468 ：仕様書無しさん：03/10/03 00:40

>>464
ちゃんと言語に関係なく設計しろよ。
設計はオブジェクト指向の特権じゃない。
お前みたいな奴がいるから、
アセンブラやCなら設計しなくても良いとか
勘違いする奴が出てくるんだ。
ようするに言語じゃなくてお前が未熟なのさ。

469 ：仕様書無しさん：03/10/03 00:41

>お前も初心者の頃はぐちゃぐちゃなソース書いてただろ？
>思い出してみろ。あの頃を。
それが嫌でオブジェクト指向を利用し始めたわけだが...
わかっているのだろうか？

470 ：仕様書無しさん：03/10/03 00:42

>>459

【程度】
(1)他の物と比べたときの高低・強弱・多少・優劣などの度合。ほどあい。
「生活の―が上がる」「補償額は破損の―による」
(2)上に基準などを示す語を伴って、物事の段階がほぼそのあたりであることを表す。
「焦げない―に焼く」「一時間―見ておけば十分だ」
(3)ちょうど適当と考えられる度合。
「いくら人がいいといっても―がある」

三省堂提供「大辞林第二版」より

471 ：仕様書無しさん：03/10/03 00:44

オブジェクト指向だけがきれいなソースを書く手段じゃないってこと
わかっているのだろうか？

472 ：仕様書無しさん：03/10/03 00:48

>>468
別に自分完璧なんて書いて無いんですけど。
脱ＶＢ厨な自分を叩き落すようなことしないでください

473 ：仕様書無しさん：03/10/03 00:50

誰も自分完璧なんて書いてないんですけど？（ｗ

474 ：仕様書無しさん：03/10/03 00:52

>>472
やっぱりわかってないね。
設計というのは言語を指向なんて関係なく、
どれを選ぼうが多少の違いはあれ、やるものなの。
まだまだなのはわかっているが間違った方向にすすまないように。

475 ：仕様書無しさん：03/10/03 00:58

＞473まあまあ

＞472はオブジェクト指向というとこから設計の重要性を理解し始めんでしょ
それがＶＢじゃできないみたいな事書いてるからだめなんでしょうけどね

476 ：仕様書無しさん：03/10/03 00:58

×言語を指向なんて
○言語や指向なんて

477 ：仕様書無しさん：03/10/03 01:17

お前等がＯＯを利用しない理由として、基底クラスを勝手に改訂されると
ややこしくなるからだろ？

478 ：仕様書無しさん：03/10/03 01:21

そのためにリファクタリングがあるのですが何か？

479 ：仕様書無しさん：03/10/03 01:22

>>404
オブジェクト指向は古代ギリシャ時代にプラトンが考え出した

480 ：仕様書無しさん：03/10/03 01:23

>>403
> 科学はこの世の多くの問題を解決したのは事実だが、
> 科学がこの世の全ての問題を解決できない。
>
> オブジェクト指向で多くの問題を解決できるかも知れないが、、
> オブジェクト指向で全ての問題を解決できると信じてはいけない。
わかりきったことをほざく前にオブジェクト指向プログラミングを実践して
ソースコードをリンクで見せびらかしてからものをいえ

481 ：仕様書無しさん：03/10/03 01:24

いわゆる、プロセスの受け渡しの『パイプ』部分はＯＯでなくてもいいと思う。
自分が担当する内部のプロセスについては、別にＯＯで組んでも構わないと。
自分が得すればそれでいいのだと。

482 ：仕様書無しさん：03/10/03 01:25

>>480
> ソースコードをリンクで見せびらかしてからものをいえ
まずお前がやってからだ。口だけじゃ説得力がないぞ。

483 ：仕様書無しさん：03/10/03 01:26

しかし、ＯＯが理解できないバカと仕事すると疲れる。

484 ：仕様書無しさん：03/10/03 01:26

>>417
> >>416
> お前UNIXまともに使った事ないだろ。
> >今までWeb組んでいてPerlが「必須」になった場面はない。
> この発想からしてまともなUNIX使いではないと断定できる。
ばか者よ。perlはお前にとっては過去の栄光といえそうだな。
perlの代わりにtcshを使っていたものからすればアホかとしか言いようが無い。

485 ：仕様書無しさん：03/10/03 01:27

俺：なんでここ、static_cast　じゃなくて reinterpret_cast にしているの？
奴：なんか、かっこいいから
俺：…

486 ：仕様書無しさん：03/10/03 01:28

>>424
いまどきperlマンセーも変わっとる。web作るならせいぜいPHPにしとけと。
シェルだけで文字列処理やりたきゃawkで十分。

487 ：仕様書無しさん：03/10/03 01:30

>>428
> 言語を知らなくても設計できるのがオブジェクト指向
それはあまりにも甘い。標準クラスライブラリのクラスのソースコードを読み
クラスの仕組みを知って挙動を性格に知ってから設計するのが
賢いオブジェクト指向プログラマ

488 ：仕様書無しさん：03/10/03 01:33

>>431
> これは「オブジェクト指向を理解しなくていい」って言っているわけではないよ。
> 「オブジェクト指向も万能ではない」＆
> 「オブジェクト指向が万能と思うことは危険なことだ」って言っているんだ。
いちいちそんなことを逝って回らんでもいい。

オブジェクト指向言語を使いこなしている者はそんなことを百も承知で
開発をしている。

そういうオブジェクト指向に否定的なことを言えば
言うほど「オブジェクト指向なんて勉強しなくてもいい」
と思い込む馬鹿が繁殖するから迷惑だ。

489 ：仕様書無しさん：03/10/03 01:36

>>442
> >>440
> プププ
> 正解は
> !#/usr/bin/ｐerl
おいカス坊パル厨。管理者によっては>>440にインストールしてる奴もおるぞ。

>>446はデザインパターンについてもっと勉強してから発言しろ

490 ：仕様書無しさん：03/10/03 01:37

オブジェクト指向に肯定的なことを言えば
言うほど「オブジェクト指向が万能」
と思い込む馬鹿が繁殖するから迷惑だ。

491 ：仕様書無しさん：03/10/03 01:38

>>451
> c++の事情は知らないが、javaはこのままではポストCOBOLとなる。

XPやRUPが普及している今、いまどきここまでいう奴も珍しい。

492 ：仕様書無しさん：03/10/03 01:39

>>490
そうやって否定的になってスパゲティコードを書く奴はこの業界から消えて欲しい。

493 ：仕様書無しさん：03/10/03 01:40

> XPやRUPが普及している今、
普及していません。

494 ：仕様書無しさん：03/10/03 01:41

>>451
> c++の事情は知らないが、javaはこのままではポストCOBOLとなる。

むしろ、C++のほうが悪い意味でポストCOBOLになる可能性は高い。
とくに、C++もCOBOLもどちらもグローバル変数を使っているのは
いかにもポストCOBOL臭いではないか(w

JavaがポストCOBOLになるとは、良い意味では、今まで
COBOLが支配していた市場をJavaが覆すと言うことだな。

495 ：仕様書無しさん：03/10/03 01:41

>>493
お前が怠け者だから普及できない。

496 ：仕様書無しさん：03/10/03 01:41

> > 「オブジェクト指向が万能と思うことは危険なことだ」って言っているんだ。
> いちいちそんなことを逝って回らんでもいい。
>
> オブジェクト指向言語を使いこなしている者はそんなことを百も承知で
> 開発をしている。

>>492
わかっているんじゃなかったんですか？（ｗ

497 ：仕様書無しさん：03/10/03 01:43

>>495
> お前が怠け者だから普及できない。
そう。すべては俺にかかっている。
俺がやらない。そして周りがやらないから普及しない。
俺がいない会社でも当然普及してないだろう。

498 ：仕様書無しさん：03/10/03 01:43

>>456
コンポーネント指向はVB厨やDel厨のおもちゃ。
C#もそんなおもちゃレベルと同等に扱われるとはM$も哀れだな。
C#の利点はアスペクト指向要素をもっていることだろうに。

499 ：仕様書無しさん：03/10/03 01:44

C++はポストアセンブラ、ポストＣだろ。
Cobolでゲームやドライバを作る会社はない。

500 ：仕様書無しさん：03/10/03 01:45

>>461
> オブジェクト指向を理解できない奴と
> ポインタを理解できない奴は
> ５０歩１００歩。
きみはC/C++のやりすぎでそんな考えをもっているようだｄが
オブジェクト指向はポインタを理解できなければ使いこなすことはできない。
Javaがまさにそうだ。

501 ：仕様書無しさん：03/10/03 01:46

Javaでもゲームやドライバを作る会社がないところをみると
Javaはポストなになんだろうな？

502 ：仕様書無しさん：03/10/03 01:47

>>499
> C++はポストアセンブラ、ポストＣだろ。
> Cobolでゲームやドライバを作る会社はない。
ソースコードをわざと読みづらくすることで保守的になろうとする輩を
作りやすいところからC++はポストCOBOL臭いといえる。

ドライバも、そのうち、UPnPやJiniに取って代わるときがやってくるだろう。

C++に残された役目は、VMを改善すること、OSを作ることだ。

503 ：仕様書無しさん：03/10/03 01:48

＞オブジェクト指向はポインタを理解できなければ使いこなすことはできない。

なんでそうなるのか・・・

504 ：仕様書無しさん：03/10/03 01:50

> OSを作ることだ。
OSといっても狭義のOSだな。
メモリ管理とかファイル管理とかプロセス管理とか。
それ以外のところは他のものにとって代わるだろう。

505 ：仕様書無しさん：03/10/03 01:52

>>501
汎用プログラミング言語という観点では
JavaはポストC++

サーバサイドプログラミングという観点では
Javaはポストperl、ポストCGI

エンタープライズという観点では
JavaはポストCOBOL

組み込み系では
JavaはポストC/C++, ポストWindowsCE

C#がポストJavaであるかのように見えたが
D言語がポストJavaであるかもしれない。
C#はJavaにとってｍ逆にポストC#なる立場に追い込まれるかもしれない。

理想はSmalltalkの良いところがポストJavaであって欲しい。

506 ：仕様書無しさん：03/10/03 01:53

>>503
Javaにはポインタはある。
ないのはC/C++のポインタ演算のみ

507 ：仕様書無しさん：03/10/03 01:53

>>504
他の部分では、どんな言語がお勧めだろう。

508 ：仕様書無しさん：03/10/03 01:54

>>463
> COBOLも理解できないでソフトウェア技術者として恥ずかしくないのだろうか？

COBOLerはCMMレベルが低い。

以上

509 ：仕様書無しさん：03/10/03 01:56

>>506
Ｊａｖａってポインタ意識しないでプログラミング出来るようになってるんじゃないの？

510 ：仕様書無しさん：03/10/03 01:57

多態とか内部でポインタを使っているからね。

511 ：仕様書無しさん：03/10/03 01:57

>>471
> オブジェクト指向だけがきれいなソースを書く手段じゃないってこと
> わかっているのだろうか？
ではアスペクト指向について語ってくれ

512 ：仕様書無しさん：03/10/03 01:58

>>494
>COBOLが支配していた市場をJavaが覆す
ないない、絶対ありえない（ｷｯﾊﾟﾘ）

513 ：仕様書無しさん：03/10/03 01:58

>>509
> >>506
> Ｊａｖａってポインタ意識しないでプログラミング出来るようになってるんじゃないの？
あんたは危なすぎる！

オブジェクトのcloneについて理解したほうがいい。
値型と参照型の違いを理解したほうがいい。

あんたにJavaを使わせるとチームがひどい目に遭いそうだ。

514 ：仕様書無しさん：03/10/03 02:00

>>512
> >>494
> >COBOLが支配していた市場をJavaが覆す
> ないない、絶対ありえない（ｷｯﾊﾟﾘ）
今はな。

では

COBOLが支配していた市場を.NETが覆すということはありえるかな？
COBOLを使っていたJR東日本が.NETを使い出した。どう思うかね？

515 ：仕様書無しさん：03/10/03 02:01

>>509
ポインタは意識する必要があるがポインタ演算やメモリアドレスについては意識しなくて良い。

516 ：仕様書無しさん：03/10/03 02:03

>>477
>>478のリファクタリングに加え、
CVSでソースコードを管理だ。

M$のように頻繁に勝手にスーパークラスを変えるような輩は設計というものをなめている。

517 ：仕様書無しさん：03/10/03 02:06

>>511
> ではアスペクト指向について語ってくれ
アスペクト指向は良く知りません。さてそれがどうかしましたか？

518 ：仕様書無しさん：03/10/03 02:07

>>514
.NETは言語じゃないからね。COBOLも.NETで動くし。

519 ：仕様書無しさん：03/10/03 02:09

>>516
実際に変わったスーパークラスって何？

520 ：仕様書無しさん：03/10/03 02:09

>>514
さぁ？ただ、使い出しから「覆し」までに要する時間は
気が遠くなるほどだろうなってのはすぐ思いついた。

521 ：仕様書無しさん：03/10/03 02:12

サーバの寿命が尽きる頃になってやっとCOBOLからJavaへ

522 ：仕様書無しさん：03/10/03 02:13

>>519
Win32 API →　.NET framework

523 ：仕様書無しさん：03/10/03 02:16

>>522
それスーパークラスっていわないし。

524 ：仕様書無しさん：03/10/03 03:41

>>511
アスペクト指向っつーのは「hogeな時はhuga」ってことだ。
あえてCで表現するなら
#define fclose(f) { fclose(f); f = NULL; }
みたいなことをヘッダなりソースの頭でするようなもんだ。
この場合は「fcloseする時はファイルハンドルをNULLにする」だな。
アスペクト指向言語なんかではもっといろんな場面で使えるようだが。

でも、AspectJのコードはかなり気持悪いな。書いてない動作するし。
読む時は最初にアスペクト定義を読んどかないと混乱は必至だ。

525 ：仕様書無しさん：03/10/03 10:46

>>519
M$ではないし、スーパクラスでもないんだが、
JavaのDictionary, awtのイベント関連、Threadクラスの一部のメソッドなどが
「推奨されない」と書かれている。
つまり、これらの設計は「間違っていた」ということを認めたわけで
これを利用しているプログラムを修正する必要がある。

再利用することは上記のようなリスクもある。
ま、コピペのリスクよりは被害は小さいが、被害は無いわけではない。

526 ：451：03/10/03 11:10

>>491
ある意味で、同意。RUPのことは不勉強でよく知らんけど、
XPのプラクティス群のうちののペアプログラミンが「新スパゲッティ増殖」を防止することは確かに期待できる。
でもこれは、プログラミングモデルの変化ではなく、開発モデルの変化に属することだ。
「開発モデルの変化」に成功している組織はあまり無い。ほとんどが旧態以前のWaterFallだ。
あなたの属する組織が「開発モデルの変化に成功している」のなら「おめでとう。うらやましい」と心底から思う。
>>493
っていうことで間違っていませんよね。

527 ：仕様書無しさん：03/10/03 11:18

成功している組織があまりないってどうしてわかるんでしょう？

528 ：仕様書無しさん：03/10/03 11:41

>>527
そう思いたいのさ。

529 ：仕様書無しさん：03/10/03 11:53

>527
大手でも、管理職はXP=WindowsXPとしか認識していないから。

530 ：仕様書無しさん：03/10/03 11:59

>529
そんなヤツが権限を持っているような所は、
どっちにせよオブジェクト指向なんて導入
しようと思わないだろうから、はっきり
言ってどうでもいいような気がするんだが…。

何っつーか、どこもかしこもがオブジェクト
指向やXPを導入しない限りは、それらは
無価値だとでも言いたいのか？馬鹿馬鹿しい。

そんなの、オブジェクト指向やXPを万能の処方箋
とでも思っているのと同レベルの痛さなんだが。
「銀の弾丸」なんてないんだけど。

531 ：仕様書無しさん：03/10/03 12:17

価値うんぬんじゃなくて、組織が多いか少ないかっていう話じゃないの？

532 ：428：03/10/03 12:28

>> 言語を知らなくても設計できるのがオブジェクト指向
>それはあまりにも甘い。標準クラスライブラリのクラスのソースコードを読み
>クラスの仕組みを知って挙動を性格に知ってから設計するのが
>賢いオブジェクト指向プログラマ

そんなことはプログラマにまかせておくのがオブジェクト指向

533 ：451：03/10/03 12:29

>>530
同意。おれは>>431と同一人物だが
>>431で言いたかったことはあなたの発言と同じだ。

ただ「No Silver Bullet」を持ち出しても、本当に理解出来る奴がどれだけいるかがちと不安。

534 ：仕様書無しさん：03/10/03 12:33

http://village.infoweb.ne.jp/~fwgf2942/LectureManager/MG.dangan.html

535 ：428：03/10/03 12:36

臭いものに蓋をするのがオブジェクト指向

536 ：仕様書無しさん：03/10/03 12:40

馬鹿の一つ覚えのようにオブジェクト指向といってるのは
VB上がりかJavaしかできないレベルの低い厨房だろ。
慣れれば別にどうって事ないし、
そんなに大したものじゃない。

537 ：428：03/10/03 12:42

別にどうって事ないのがオブジェクト指向

538 ：428：03/10/03 14:04

方法論ではあるが解決策ではないのがオブジェクト指向

539 ：428：03/10/03 14:08

理解したからといって彼女が出来る訳ではないのがオブジェクト指向

540 ：428：03/10/03 14:21

理解したら給料上がることもあるかもしれないのがオブジェクト指向

541 ：428：03/10/03 14:32

オブジェクト指向では解決しないのがオブジェクト指向プログラミング

542 ：仕様書無しさん：03/10/03 18:36

難しいことに価値があるわけじゃないからねえ。
オブジェクト指向な考えは簡単だから価値がある。

543 ：仕様書無しさん：03/10/03 20:25

>>536
厨房っていって切り捨てられればいいんだけど、そいつは顧客なんだ。

544 ：仕様書無しさん：03/10/03 22:03

489 ：仕様書無しさん：03/10/03 01:36
>>442
> >>440
> プププ
> 正解は
> !#/usr/bin/ｐerl
おいカス坊パル厨。管理者によっては>>440にインストールしてる奴もおるぞ。

>>446はデザインパターンについてもっと勉強してから発言しろ

こいつ相当に馬鹿だな。
まんまと釣られてるよ。
Java房なら
!#/usr/bin/ｐerl
これで動くんだろうな（プププ

545 ：仕様書無しさん：03/10/03 22:03

>>543 そんな顧客切り捨てて、楽になろうぜ♪

546 ：仕様書無しさん：03/10/03 22:06

継承とか使うとJump命令が余分に増えるんですけど。

547 ：仕様書無しさん：03/10/03 22:08

!#/usr/bin/env perl
だろ？

548 ：仕様書無しさん：03/10/03 22:12

↑引っ張りすぎ

549 ：仕様書無しさん：03/10/03 22:13

>>546
yes

550 ：仕様書無しさん：03/10/03 22:15

!#
を書いてる奴らに。
もうやめれ。見苦しい。

551 ：仕様書無しさん：03/10/03 22:17

！＃
これならいい？

552 ：仕様書無しさん：03/10/03 22:20

っと思ったけど詰まらんから辞める。

553 ：仕様書無しさん：03/10/04 00:14

C++は全ての頂点に君臨汁！汁！

554 ：仕様書無しさん：03/10/04 09:06

この調子だと構造化プログラミングが理解できてない香具師もいるかもしれねーなー。

555 ：仕様書無しさん：03/10/04 11:07

(1) OOとOOPの違いを教えてください
(2) >>210の1個1個がよくわかりません

皆さんちゃんと言葉にして答えを言える(書ける)のでしょうか？
全ての項目を説明できる人ってどれ位いるんだろ？
(ある程度のスキルを持つ人になら)誰でも理解できるような言葉で説明できたら、その人すごいね

556 ：仕様書無しさん：03/10/04 11:18

オブジェクト指向がわからないというのは

単に「オブジェクト指向」という「言葉」の意味が分からないだけである

に全部。

557 ：仕様書無しさん：03/10/04 11:24

>>555
　　　　　　　　　　　　／　　＿＿＼＼)ノ/ﾘ
　　　　　　　　　　／　　　 <＿＿　＼　＼／ノ
　　　　　　　　　/　　　／<＿＿　＼　＼　ﾍ /⌒/　　あなたさぁ．．．
　　　　　　　　 /　　〆　　└--、ヽ、＼　-　＼　|
　　　　　　　／ﾚ＼　=ミ=、__/丶　　-　　　　　〉なんてゆうか．．．
　　　　　　　/ ﾝ/　　（- =、 >　<( ＼　　　　　　 |
　　　　　　　し/　ﾐ　 'ｰ--ヘ/　＼ﾐiヽ　　　　　{ 　人に聞く前に検索ぐらいしなさいよ
　　　　　　ﾘ/ 　 /　　ン　/("ﾐ、、ﾍ　　　　　 > 、
　　　　　　　| 　　　／<.o　ｲ　'ｰヾ /　>、　　∠／ヽﾍ　これは基礎知識レベルの事だから
　　　　 ,.-／| 　　-=、_/　"|　　　_∠／　＼(⌒)　　ﾉ　＼
　　／ |　＼ヽ　　ヽ,-＼}　　 ∠ノ　　　　　ヾ、　／　　　＼もうちょっと勉強しなさい
￣<　　 !　　`＼　　　　　　／＿＿＿　　　　＼／＼(
＿＼　 !　　　 > ー-- イ　＼_　　　￣￣＼_＼　　　　(　
!　￣￣　ヽ　／{　　)＼　|　　　∠　　　　　　ノ）ヽ、
　　　　　　＼　/⌒＼　〉　　￣　/　　　　　　 /　>＼
　　　　　　　＼　い　/　　　　 /　　　　　　 /／ノ
　　　　　　　　　＼　/　　　　 /　　　　　　 / ／￣

558 ：仕様書無しさん：03/10/04 11:30

人に聞くのは良くない　まず自分で調べろ

つまり、自分で全てを知れということなので
本もダメ
開発者や提案者に聞くのもダメ
検索もダメ

ということだ。

スタックダンプなどはそのアプリケーションの開発者でないと
数字の羅列を見ても何がどう載っているのかまったくわからないが、
これも自分で解決しろということ。
もちろんソースなどない、リバースエンジニアリングは一切なし
見て瞬時に解れということ

そのわりにみんな高校や大学や本で習わないと何もできないのは永遠の謎

559 ：仕様書無しさん：03/10/04 12:26

>>496
何年も前からJavaはCOBOLに取って代わるように
言われているが、はっきりいって無理！
COBOL & 汎用機のパワーの前にはJava & (Unix | Windows)では
かなわないものが確かにある。
基幹系システムでCOBOL&汎用機に勝とうなんてあと１０年は不可能
なんじゃないか？

560 ：仕様書無しさん：03/10/04 13:32

何を根拠に？

561 ：仕様書無しさん：03/10/04 13:43

>1
別にキミがシステムの設計・開発・運用にかかわらないんなら、
理解できなくったって問題なし！

562 ：仕様書無しさん：03/10/04 13:53

説明が面倒になったら

内部で小分けにされてるから一部だけ抜き出して修正することも可能になる

とだけ言えばヨシ。

んなもんはCでも何でもできるわけだが
とりあえずCというと何でも「Cインクリメント」のことだと思うのをやめろ！

563 ：仕様書無しさん：03/10/04 13:56

つまり主題が定まっていないのと無駄な行間は何か意味があるのか？
って事だ。

564 ：仕様書無しさん：03/10/04 13:58

その行間に補足を入れることも可能になる

565 ：仕様書無しさん：03/10/04 21:18

Javaがダメなんじゃなくて、SunFireがダメなんだよ。
すくなくとも世間ではそう思われている。Java自体も
もう少し仕様が枯れる必要があるけど、その前にSunが
枯れそうだな。

566 ：仕様書無しさん：03/10/04 21:31

>>559
はい、はい、わかりましたよ、社長さん。

おいらは、社長に５５９と同じ事いわれたので、
次の日は会社には行かず、辞めました。

７、８年前ですが、まだこういう人いるのか。
ちなみにその会社はなくなりました。

567 ：仕様書無しさん：03/10/04 21:53

>>558
>人に聞くのは良くない　まず自分で調べろ

>つまり、自分で全てを知れということなので
>本もダメ
>開発者や提案者に聞くのもダメ
>検索もダメ

>ということだ。
おいおい、自分で調べるのはOKっていってるだろ…

568 ：仕様書無しさん：03/10/04 21:59

自分で調べるに当たって人に聞くのは不可
本で調べるのも「人に聞くこと」に他ならず
開発者や提案者は人だから聞いちゃならん

でも先生に教えてもらうのは可
理解しがたい

569 ：559です：03/10/04 22:45

>>566
はずれです。
現在２８歳、就職６年目でつ。
この間までJ2EEで開発やってて、今度はCOBOLと汎用機を使った
開発にまわされました。
他にもVBを使ったクラサバの開発とかやったけど、EJBなんぞでは
汎用機ベースの開発に敵わんと判断しました。
十二分に枯れた技術こそが信頼されるのだと思うです。
J2EEや.NETには基幹業務のような堅牢性重視なシステムを
任せるわけにはいかんと思うです。

570 ：仕様書無しさん：03/10/04 22:52

てか、それ以前にCOBOLよりも事務計算処理に向いた言語なんて有る？

571 ：仕様書無しさん：03/10/04 22:56

>>569
いいよ？その堅牢性を信用して基幹システムはまかせるわ。

ただ、Web部分はJavaでやらせてくれよな。CORBAで分散化させるんで
インターフェイス部分はきちんとしておいてくれよ？

とまあ、今はこういう時代の流れなんじゃないの？

572 ：仕様書無しさん：03/10/04 23:25

>>570
事務処理はCOBOL、これ最強。
でもCOBOLよりJavaが好きなんですけど。

>>571
禿げしく同感。
そういう手法が多いんじゃないかな？
ユーザに近い側がJava、基幹側はCOBOL。

しかし端末エミュレータをＰＣにインストールして･･･
Javaの出番がないという罠。

573 ：仕様書無しさん：03/10/04 23:47

>>530
> そんなの、オブジェクト指向やXPを万能の処方箋
> とでも思っているのと同レベルの痛さなんだが。
> 「銀の弾丸」なんてないんだけど。
おまえさあ、C++スレでなんども同じこと連呼してるけど
だれが勝手に銀の弾丸だと思い込んでいるんだ？
このスレやC++関連すれでもではそれらしき発言をしているレスは見当たらないぞ。

574 ：仕様書無しさん：03/10/04 23:49

>>536
> VB上がりかJavaしかできないレベルの低い厨房だろ。
こいつも同じことをしつこくくりかえしているよ。
そういう脳内妄想はいい加減にやめないか？

575 ：仕様書無しさん：03/10/04 23:54

>>569
> >>566
> はずれです。
> 現在２８歳、就職６年目でつ。
若い癖にCOBOLマンセーとはジジ臭い奴だな。

UMLを使って設計しろと言われても
「オブジェクト指向は銀の弾丸ではないから接待に使っちゃいけません！」
とかアホなこといってるんだろ

576 ：仕様書無しさん：03/10/04 23:55

>>572
> そういう手法が多いんじゃないかな？
> ユーザに近い側がJava、基幹側はCOBOL。
いや、ユーザに近い側はPHP、COBOLからJavaに置き換えられることが
可能だとわかるものは手当たり次第に置き換え。
どうしても置き換えるわけにはいかないものにはCOBOL

577 ：571：03/10/05 00:04

>>576
手当たり次第か・・・。良い顧客を抱えとるなぁ。
俺の担当顧客は必要最小限しか置き換えようとしない罠。不景気だし・・・。

うちの地域(名古屋)ではPHP率は低いよ。やはりJavaがメインとなっている。
しかしASP.NETとかも増えてきた感あり。

578 ：仕様書無しさん：03/10/05 05:26

ぷっ、PHPだってさ。
ぷっ、CGIだってさ。
ぷっ、Perlだってさ。

こんなもん使うシステムなんかやってんじゃねーよ。ぼヶ。

579 ：仕様書無しさん：03/10/05 08:31

>573-575
時間や口調から見る限り同一人物のようだが、
何でそんなに必死なんだ？

第一、お前どう見てもこれらを読む限りでは
「銀の弾丸」の意味を正しく理解してないよ。
この論文は、まさにお前が>575で挙げている
「銀の弾丸でないから使えない」というアホな
ことを言うヤツを戒めるためのものなんで、その
考えを批判している人間が自分で使うわきゃねー
じゃん。引用されていたURLくらい読めよー。
第一、>573で実在を否定して>575でその実在を
主張しているっていう滑稽さを自覚してる？

悪いけど笑っちゃうぜ。もう来るなよ。

580 ：仕様書無しさん：03/10/05 13:04

>>578 零細企業の必須技術をバカにするな。
いや、おれはバカにしていよ。

581 ：仕様書無しさん：03/10/05 14:40

>>578
でもYahoo!がPHP使ってたりする
PHPでもあれだけのトラフィックを捌けるらしい

（と、いうよりわざわざPHPを選ぶんだから
PHPであることが合理的なんだろうな
どう合理的なのか理解できんけど）

582 ：571：03/10/05 14:44

Yahooの技術者が行ったプレゼンの資料
ttp://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
一応ここに全部書いてある罠。いろんな言語と比較している。

583 ：仕様書無しさん：03/10/05 14:55

>582
面白いけど、Javaを選択しなかったのはFreeBSDのスレッドサポートが
クソだっていう本質的でない理由なのだな。
ちなみに、最近のFreeBSD5系列では改善されてるはず。

584 ：仕様書無しさん：03/10/05 15:00

>>579
ﾌﾟ必死すぎw

585 ：仕様書無しさん：03/10/05 15:20

オブジェクト指向を理解できないヤシは、この先生きていくだけで
一苦労だと早いところ自覚してください。
以上//

586 ：仕様書無しさん：03/10/05 15:22

>>582
面白い資料だね。
LinuxのJavaスレッドは粗末だって話は聞くね。
FreeBSDのportでもそうだったのか。

どう変わったのだろう？

587 ：583：03/10/05 15:33

>586
そもそもFreeBSDではカーネルスレッドが無かった。
Linuxはインチキな実装だけど、パフォーマンス的には満足の行くような
カーネルスレッドを持ってる。

588 ：仕様書無しさん：03/10/05 16:40

LinusはJava嫌いだけど
*BSD使いももJava嫌い多いな。
なんでだろうね？

589 ：仕様書無しさん：03/10/05 16:51

スレッドなしで熟成されてきたシステムだからでしょ。
その点では、OS/2やNTの方が･･･(略)

590 ：仕様書無しさん：03/10/05 16:57

そうだよな。
あれはどっちがいいんだろう。

OracleもWin32は1プロセスマルチスレッドで、Unixはマルチプロセスだしな。

591 ：仕様書無しさん：03/10/05 17:43

Javaってオマケってカンジがするんだよ。
グリコのオマケ。

592 ：仕様書無しさん：03/10/05 17:52

まあ、オマケが目当てだったりするわけだが。

593 ：仕様書無しさん：03/10/05 17:57

Javaは飲み物です。
Pythonは食べm(ry

594 ：名無し＠沢村：03/10/05 18:21

おまいらよ、おまいらはPGだろ？ならオブジェクト指向は当たり前じゃないか？
そもそもおまいらはオタクだから一般職であるPGになったんだろ？
オタクでないまともなやつは、総合職に就いてバリバリやろうとするのがふつーだからな。
おまいらはオタクだから一般職であるPGになった。オタクだからしょうがないよな。オタクはまともなやつと違って技術を身につけてそれを高めていくしか世渡りの術がないからな。
だったらおまいらよ、オブジェクト指向を身につけろよ！！
おまいらよ、プログラミングでオブジェクト指向以外に技術といえるものは少ないぞ。
制御系の知識に長けていればそれも技術だ。ＯＳや言語理論に長けていればそれも技術だ。
だがおまいらは、ＯＳやコンパイラをつくることはあまりなく、ほとんどがアプリケーションばかりだろ？
ならオブジェクト指向以外に技術ってまず考えられないぞ！！
技術を身につけるしか世渡りの術がないおまいらが、技術を避けていてどうするんだよ？
おまいらよ、断っとくが、手続き型言語は技術ではないからな。
それはコンビニのバイトや宅配の運ちゃんや倉庫の仕分け作業員が最初に仕事の手順を覚えるのと同じくだらないことだからな。
まさかおまいらよ、手続き型言語を技術だとは思ってないよな？

595 ：仕様書無しさん：03/10/05 18:22

沢村氏に限らず、長文はうざいです。

596 ：仕様書無しさん：03/10/05 18:28

>>594
そうだよ、沢村。オブジェクト指向は当たり前だよ。
最近はテストとリファクタリングでオブジェクトを成長させていく
手法がデファクトだよ。

597 ：仕様書無しさん：03/10/05 18:48

沢村の言ってる事は逆に捉えると正しい。
昔から定説ですな。

598 ：仕様書無しさん：03/10/05 19:21

>591
最近のオマケ付きお菓子はあからさまにオマケが主役になってきている
という事を言いたいのでしょうか？

599 ：仕様書無しさん：03/10/05 19:28

Java厨一箱大人買いですか？

600 ：仕様書無しさん：03/10/05 19:41

宝くじ１ユニット大人買い！

601 ：仕様書無しさん：03/10/05 19:47

大人買いの意味を取り違えている予感。

602 ：仕様書無しさん：03/10/05 22:50

手続き型言語を操るのは技術ではない？
なら何なのだ？

603 ：仕様書無しさん：03/10/05 23:03

>>594＝＝沢村はオブジェクト指向をよくわかっていないので要注意

604 ：仕様書無しさん：03/10/05 23:04

>>579
おまえ、自分が銀の弾丸だと思い込んでいるだろ

605 ：仕様書無しさん：03/10/05 23:05

沢村のエサをなんだと心得る！

606 ：仕様書無しさん：03/10/05 23:06

>>598
人のやりたいことによってはJavaがおまけにみえることもあるんではと

607 ：仕様書無しさん：03/10/05 23:07

>>605
マ板の過去ログをミロや。

沢村がポリモーフィズムをよく理解していないレスが
多数見当たるぞ。

608 ：仕様書無しさん：03/10/05 23:09

>>607
は？

609 ：仕様書無しさん：03/10/05 23:11

そもそも沢村って何者だ？
いつもピントがボケた長文書くけど鬱陶しすぎ。

610 ：名無し＠沢村：03/10/05 23:18

>>602
＞手続き型言語を操るのは技術ではない？
なら何なのだ？

コンビニのバイトが最初にレジの扱い方を覚える程度のくだらないことだ！！

611 ：仕様書無しさん：03/10/05 23:23

>>609
沢村は
管理職らしいw
本名は本田学らしいw
量子指向言語ニューとラムというのを作っているらしい。
BASICで足し算ゲーム作ってプログラミングコンテストで優勝したことがあるとかw
3Dでチェンリーを作るのが夢らしいw
VC++を使っているらしい、がオブジェクト指向の知識は生半可。
大学院博士課程を修了し、量子力学を専攻していたらしい。(本当かw
とにかく、学者タイプであるらしいｗ

612 ：仕様書無しさん：03/10/05 23:23

沢村よ、妻乱なぁ。

613 ：仕様書無しさん：03/10/05 23:27

>>610
じゃあコンビニのバイトがやる仕事の中で最も難しい仕事は何だよ。

614 ：仕様書無しさん：03/10/05 23:35

奥様のハートをキャッチすること。

615 ：名無し＠沢村：03/10/05 23:37

>>613
それは万引きの取り押えと強盗の撃退だな。
しかしコンビニでも店長となると、ルチングワークしかやらんPGより格調高いぞ。
なにしろ学校や企業の誘致も仕事に含まれるから、格調高さ無限大だ。
ただ「ザ：コンビニ」では誘致も店長の仕事だったけど、実際の話店長が誘致まで手がけた話は聞かんな…

616 ：仕様書無しさん：03/10/05 23:40

エサは…ヤツにレスすることかな。

617 ：仕様書無しさん：03/10/05 23:44

>614
万引きした若奥様を捕獲したら、その後どうすれば良いですか？

618 ：仕様書無しさん：03/10/05 23:49

ﾊｧﾊｧ ♥
続きは？

619 ：名無し＠沢村：03/10/05 23:52

>>617
相棒のバイトに警察に電話をかけさせ、警察は来るまでの間、寝業で力いっぱい床に押さえこんどくんだ。
体を密着させてね。合法的に触り放題だぞ。

620 ：仕様書無しさん：03/10/06 00:02

>>611が語る沢村と、2ch用語で長文書いてる沢村が同一人物とは思えない。

621 ：仕様書無しさん：03/10/06 00:12

>>617-619
万引きした女子中学生、万引きした女子高校生、万引きした女子大学生、
万引きしたＯＬ、万引きした看護婦、万引きした女王様、万引きした婦警
想像力が貧困なので、この程度しか列挙できませんでした。
万引きした若奥様でﾊｧﾊｧ出来ない方は、お好きな対象に差し替えてﾊｧﾊｧしてください。

622 ：仕様書無しさん：03/10/06 00:24

万引きした女子小（ry

623 ：仕様書無しさん：03/10/06 04:07

万引きした沢村を捕獲。

624 ：仕様書無しさん：03/10/06 19:24

万引きしたウィノナ・ライダー

625 ：仕様書無しさん：03/10/06 19:59

小学生が万引きしたらどうすんだ？

626 ：仕様書無しさん：03/10/08 20:01

マン引きという言葉の響きだけでﾎﾞｯｷｱｹﾞ

627 ：仕様書無しさん：03/10/08 20:05

>>626
そんなことでageないでほしい。

628 ：仕様書無しさん：03/10/09 20:04

>>623
藁

629 ：仕様書無しさん：03/10/10 04:50

ここには解かってる人達と、"まだ"解かってない人達と
解かってる事に気付いていない人達しかいない予感。。。

オブジェクト指向ってのは概念なんだよね。
という事は、それを実践していながらオブジェクト指向
って何？等と尋ねている人が混じっている事ってない？

630 ：仕様書無しさん：03/10/10 10:37

>>629
前半。違うな。
充分には分かっていないけど、充分には分かっていないことを分かっている人達
充分には分かっていないけど、充分に分かっていると思っている人達
全然分かっていないけど、充分に分かっていると思っている人達
の三種だよ。
おそらく充分に分かっている人はここにはこないと思うよ。
道教思想みたいだけど、
「オブジェクト指向というのは言葉では理解できない概念なのかもしれない」と思う。
俺自身は一番目かな。

後半。ない。理由は上記。
つまり、「分かっているのなら言葉での説明など求めない」ということさ。

追伸
ここで話されていることは、
「オブジェクト指向プログラミングについて」であって
「オブジェクト指向について」ではないんだ。

631 ：仕様書無しさん：03/10/10 13:01

>>630
オブジェクトってのは概念であるがオブジェクト指向は開発手法。
オブジェクト指向プログラミングってのはプログラムがオブジェクトになるように
実践してプログラミングをしろってこと

632 ：仕様書無しさん：03/10/10 20:56

>>1-631
いやあ、なんとなく class って書いてあればオブジェクト指向なんだよ。
クラスがなくてオブジェクトしかない OOPL もあるにはあるけど。

633 ：仕様書無しさん：03/10/10 21:38

>>631
それはただ単なるクラス指向。
OOってのはいろんな技術を集めた複合的な技術だから
どれか一つ取り出せってのは無理。
てかほんとにそんなOOPLってあんのか？
例をあげろ

634 ：633：03/10/10 21:39

訂正
>>632

635 ：仕様書無しさん：03/10/10 21:50

オブジェクト指向ってサ、処理重くなったりしないの？

636 ：仕様書無しさん：03/10/10 21:57

>>633
「プロトタイプベースオブジェクト指向」
でぐぐれば、色々出てくるよん。

637 ：仕様書無しさん：03/10/10 22:00

>>633
浅学ながら。
これはObject Basedというカテゴリに分類される言語で、
Adaが該当例です。

638 ：仕様書無しさん：03/10/10 22:04

>637
あのさ、OOってのがObject-Orientedのことだって
分かってる？
Object-BasedはOOじゃないぞ。

639 ：633：03/10/10 22:09

なるほど、クラスって設計書くらいにしか考えていなかったから
他のオブジェクトも存在するとは思っていたけど
プロトタイプベースっていうのか。

ただ、オブジェクト指向の度合いってのはあると思うから
クラスだけとかオブジェクトだけとか取り出しても
それは疑問符が付くけど。

そこがSmalltalkerとC++erが争うところだけど

640 ：仕様書無しさん：03/10/10 22:13

>>635
もともとオブジェクト指向はpoorな環境で動かすために作られたものではありません
最強の高級言語を目指しているわけだから純粋OOはそんなこと無視です

641 ：仕様書無しさん：03/10/10 22:18

>>640
っつーことは、ｺﾝﾋﾟｭｰﾀに使われるのではなく、ｺﾝﾋﾟｭｰﾀを使ってやるっていう考えなのかな。
お前らもっと人間に合わせて働け、って感じか。

642 ：仕様書無しさん：03/10/10 22:22

>>641
そこら辺を妥協して比較的高速に動くC++は
純粋OOerから非難轟々、宗教戦争となって今に至る

643 ：仕様書無しさん：03/10/10 22:25

>>640
はい。Smalltalkが普及しなかった一番の原因は「遅い」でした。

644 ：仕様書無しさん：03/10/10 22:27

Squeakは１GHzのマシンで動かしても
３D描画をさせると落ちかけます
Winnyﾖﾘｵﾓｶｯﾀ･･･

645 ：仕様書無しさん：03/10/10 22:28

それじゃ、そろそろオブジェクト指向用の新しいＯＳが必要だな。

646 ：仕様書無しさん：03/10/10 22:31

とりあえずObjective-CでDOSを作ってくれ

647 ：仕様書無しさん：03/10/10 23:50

>>640
相変わらず簡潔な記述は難しいが、細かい指定も出来ない。
馬鹿からも賢者からも見放されるってな事にならん？

648 ：仕様書無しさん：03/10/11 00:03

オブジェクト指向を使いこなせないからって荒れてる奴はバカ。

649 ：仕様書無しさん：03/10/11 00:06

オブジェクト指向設計とオブジェクト指向分析

これは違いとは何か？

語れ！

650 ：仕様書無しさん：03/10/11 00:07

>>648
> オブジェクト指向を使いこなせないからって荒れてる奴はバカ。
激しく同意。
マ板にいる奴はどいつもこいつも頭が古い奴ばかり

651 ：仕様書無しさん：03/10/11 00:09

オブジェクト指向から逃げている厨

C厨
VB厨
COBOLer
LISP厨

オブジェクト指向言語ではあるがこれも怪しい。
大半のC++厨(実際にはC厨), Perl厨, PHP厨

652 ：仕様書無しさん：03/10/11 00:26

オブジェクト指向を理解したつもりになっている厨

Java厨
Ruby厨

過剰なﾏﾝｾｰはｺﾝﾌﾟﾚｯｸｽの裏返しである。

653 ：仕様書無しさん：03/10/11 00:47

>>652 OO理解して使える言語だろ。

654 ：仕様書無しさん：03/10/11 01:03

>>652
まあ少なくともCOBOLerなどよりはオブジェクト指向を理解しているわけで…

655 ：仕様書無しさん：03/10/11 06:52

>>651
Mathematica＝Objective LISP
だよ

656 ：仕様書無しさん：03/10/11 08:15

>>652
C++厨がぬけてるぞ。

本当に理解できている人はオブジェクト指向言語を一つ以上と
Smalltalkを勉強として習得した人だけかと。

657 ：仕様書無しさん：03/10/11 10:27

他人の作ったクラスに全幅の信頼を置き、
ソースを見ずに使えるようになったら合格。

みんながんばってね。

658 ：仕様書無しさん：03/10/11 10:48

バグが無いと保証されたオブジェクト群が降臨した時、
オブジェクト指向の真価が発揮される。

気長に待て。

659 ：仕様書無しさん：03/10/11 11:28

LisperはまっさきにOOに移行した人達だと思われ

660 ：仕様書無しさん：03/10/11 11:50

>>658
自分の作ったクラスが全幅の信頼を置かれ、
ソース見られないでも使ってもらえるようになったら、ってのもあるかも

661 ：仕様書無しさん：03/10/11 12:03

あっちのバグが出たからって、あっちが遅いからって。

662 ：仕様書無しさん：03/10/11 12:09

何が信用できないかって、自分の作ったクラスライブラリなわけで....

663 ：仕様書無しさん：03/10/11 12:11

＞660
たしかに。
夢が無いと仕事もつまらんし。

664 ：仕様書無しさん：03/10/12 09:09

クラスの粒度はどのくらい？
これが再利用性を評価するのに最重要事項だと思うから聞くんだけど

665 ：仕様書無しさん：03/10/12 09:16

俺は思う。オブジェクト指向における再利用とはクラスライブラリを作ることではなく
マルチプルインスタンスみたいにコードの中でなんどもクラスが呼び出されることを指すのではないだろうか?

666 ：最凶VB厨房：03/10/12 09:18

>>651
VBはオブジェクト指向言語です。

667 ：仕様書無しさん：03/10/12 09:22

オブジェクト指向ができるかどうかは問題ではない。
オブジェクト指向がやりやすいかどうかが問題だ。
.NETで改善されたがVB6は論外。

668 ：仕様書無しさん：03/10/12 13:32

日本の業界で、オブジェクト指向がなかなか正しく理解されないのは、
低学歴が多いと言う致命的な弱点があるから。
人間を総取り替えしないかぎり、日本の情報産業は低レベルなままだ。

669 ：仕様書無しさん：03/10/12 13:37

>>668
何言ってんだか。
日本ほどｦﾀｸ並に OO にこだわってる国もない。
アンタが低レベルなだけ。

670 ：仕様書無しさん：03/10/12 13:43

>>668
世界的に言えば低学歴は非常に少ない。
文系馬鹿が多いような気がする。あくまで気がするだけだが。

671 ：仕様書無しさん：03/10/12 13:53

>日本の業界で、オブジェクト指向がなかなか正しく理解されないのは、
>低学歴が多いと言う致命的な弱点があるから。

ﾁｶﾞｳと思う。日本の高級教育は、本で読んだだけで全てを理解した気
になるという得意技を持つ、口ばっかり野郎を生み出しやすい土壌が
あるんじゃないのかね。

んで現場のマジョリティなひとたちは、OOの良し悪し以前に、こうい
った口ばっかり野郎の共感不能な脳内妄想に付き合わされて、なんだ
か分からないがどうも宗教臭いとか、ヤバイから近寄るのをやめよう
とか、そういうノリになるのでは。

OOって難しいことを簡単にしてくれる、俺みたいな忘れっぽい馬鹿に
優しい仕組みだと思うんだがな。

672 ：仕様書無しさん：03/10/12 14:18

COBOL・FORTRANしかやらなかった時代の専門卒の低学歴が猿まねOO気取って
得意になってまつー。

673 ：仕様書無しさん：03/10/12 14:22

OOって大きなプログラムをできるだけ小さく分割しようって技術で、
小さな子供にでもわかる教育用に作られたはずなんだが

世の中には頭の堅い低脳があふれかえっていることに
アラン・ケイ博士もびっくりです

674 ：671：03/10/12 14:24

OOのやりかたなんてのは、本読めば分かる罠。受験ベンキョで
詰め込みになれている人間なら簡単。

「なんでOOだと良いのか」をきちんと説明し、保守的な先達を
説得するのは、そんな連中じゃ無理。借りてきた言葉と乏しい
経験では説得力がない。

そんなヤツラの言動を聞いていると、どうも「自分でもなんで
良いのか分かってない」ようだ。

675 ：仕様書無しさん：03/10/12 14:28

>>673
>OOって大きなプログラムをできるだけ小さく分割しようって技術で、

また、変なこと言っている人がいるよｗ

676 ：仕様書無しさん：03/10/12 14:31

> OOのやりかたなんてのは、本読めば分かる罠。受験ベンキョで詰め込みになれている人間なら簡単。

うーん、そういう頭でっかちに設計やらすと破綻すっぞ。

677 ：仕様書無しさん：03/10/12 14:33

>>675
673 ではないが、外してはないだろう。

678 ：675：03/10/12 14:34

>大きなプログラムをできるだけ小さく分割しよう
開発の動機のひとつだぞ

679 ：673=677：03/10/12 15:57

ごめん、675じゃないわ

680 ：仕様書無しさん：03/10/12 16:20

>OOって大きなプログラムをできるだけ小さく分割しようって技術で、

賛成。
資源の再利用に有利なはず。たぶん。

681 ：仕様書無しさん：03/10/12 16:25

たぶん「できるだけ小さく」というあたりが
ハァ？な所なんだと思う。
小さ過ぎても良いことではないから。

682 ：673：03/10/12 16:34

>>681
そこがOOのキモなんだよ。あまり小さく分割しすぎても使い勝手が悪い。
じゃあどんな感じに分ければいいの?って話になってくるところで
初めてバナナとかリンゴとかフルーツなどにたとえる
抽象的な比喩(アクターモデル）が出てくる。

いきなり初心者にバナナとかリンゴの話をしたってわかるわけがない。

683 ：仕様書無しさん：03/10/12 17:15

>682

> いきなり初心者にバナナとかリンゴの話をしたってわかるわけがない。
俺は理解した

684 ：仕様書無しさん：03/10/12 17:30

>>683
（ ´_ゝ｀）ﾌｰﾝ

685 ：673：03/10/12 17:34

俺が言いたいのは抽象論ってのは所詮抽象論なんだよ
物事の全体像を語るときには有効な手法ではあるが
一つ一つの機能を説明するには具体論で話すしかない。

そこを理解していないでOOの全体像しか話さない人がなんと多いことか･･･

686 ：仕様書無しさん：03/10/12 17:38

>>685
そんな抽象的な独り言はもういいから、具体的に解説でもしたまえ。

687 ：仕様書無しさん：03/10/12 17:44

ま、OO言語使って得意げになってる奴は、OOな組み方は出来ていない罠

688 ：仕様書無しさん：03/10/12 17:59

>687
無味無臭

689 ：673 ◆Lnp6yh4GGU ：03/10/12 18:02

とりあえずトリップは付けておくか。答えるかどうか知らんけど
Smalltalk使いではないからいまいちメッセージとメソッドの違いがわかんね

690 ：仕様書無しさん：03/10/12 18:05

なにはりきってんだか（藁

691 ：仕様書無しさん：03/10/12 18:07

>>689
メッセージ　＝　接続詞
メソッド　＝　動詞

692 ：仕様書無しさん：03/10/12 18:11

>>689
おまえは、マルチプルインスタンスから勉強したほうがいいみたいだな

693 ： ◆Lnp6yh4GGU ：03/10/12 18:16

マルチプルインスタンスはわかってる
OSの機能だったプログラムの読み込みをプログラムから
できるようにしただけだろ

694 ：仕様書無しさん：03/10/12 18:27

>>693
つまらん

695 ：仕様書無しさん：03/10/12 18:42

「小さい」というのは語弊ある言い方だな。
「一度に制御すべき情報量が少ない」くらいが妥当かと。

「あるところに、おじいさんとおばあさんがいました」
　ここで指されているおじいちゃんやおばあちゃんは、
　みんなが理解可能だが誰も名前や顔などを知らない。

「アプリケーションコンフィグから max.foo.count の値を利用する」
　ここで刺されているコンフィグの利用方法は知っているが、
　その値の格納元がRDBなのかフラットファイルなのか起動引数なのかは知らない。

オブジェクト指向な手法は、
「分からないときは適切なデフォルト値を設定してとりあえず置いておく」という
脳にとって自然な認知方法を自然に実現できる。

696 ：仕様書無しさん：03/10/12 18:55

675もまるで判ってないＣ＋＋厨かよ。ワラウ。

697 ： ◆Lnp6yh4GGU ：03/10/12 18:58

いや、それは違う。
オブジェクト指向がプログラムを小さくできるってのは
おじいさんクラスを作っておじいさんクラスが大きくなりすぎたときに
人間クラスを継承した男クラスをさらに継承して作ったり
人間クラス自体にはじめから肉体クラス、精神クラスをはじめから
has-a関係で放り込んで分割することにある

698 ： ◆Lnp6yh4GGU ：03/10/12 18:59

日本語おかしかった･･･

699 ：仕様書無しさん：03/10/12 19:07

>>697
おまいにはﾔｺﾌﾞｿﾝをおすすめておくよ
古いけど考え方&表現力に幅ができるはずさ

700 ： ◆Lnp6yh4GGU ：03/10/12 19:11

ttp://www.amazon.co.jp/exec/obidos/search-handle-url/index%3Dbooks-jp%26field-author%3D%E3%83%A4%E3%82%B3%E3%83%96%E3%82%BD%E3%83%B3%2C%E3%82%A4%E3%83%B4%E3%82%A1%E3%83%BC/250-7338741-9828243

↑これか？

701 ：仕様書無しさん：03/10/12 19:19

>>700
OOSEの頃の奴なんだけどもう絶版になってたよｽﾏｿ
粒度とかドメインの概念とかuse-caseとか載ってたんだけどな

702 ：仕様書無しさん：03/10/12 19:20

人が制御できる範囲の大きさに分割する手法の一つ、ってとこかしらん。

703 ：675：03/10/12 19:25

OOPに限った話はしてないんだけど…。

自分の視点をどこに置いて、物事をどのレベルに捉えるか。
これによってモデルの粒度は全然違ってくるだろ。

>>697 は単なるリファクタリング作業に過ぎないよ。
classify するってことは、クラス間の差異を求めること。
どのくらいまで差異をつければよいかは、実際の作業対象に依存する。

宇宙、銀河系、太陽系をモデル化する場合。
自分を宇宙の外に置いたとすると、太陽系なんてほぼ無視できる存在になる。
自分を太陽系内の地球に置いたとすると、宇宙はあまりに巨大すぎて影響範囲の違いは現れない。

704 ： ◆Lnp6yh4GGU ：03/10/12 19:25

>>701
いえいえ、ありがとうございます

>>702
それ＋分割したプログラムを便利に使う方法って感じ

705 ： ◆Lnp6yh4GGU ：03/10/12 19:42

>>703
設計の段階でプログラムがどれくらいの大きさになるかわかればいいのだが
実際にはコーディングするときまでわからない場合が多い

だからこそ機能ごとに分割してやって何度でも設計しなおすことの優位があるわけだ。

現実世界での宇宙、銀河系、太陽系の大きさのちがいと
プログラムの大きさは違うからな。

706 ：仕様書無しさん：03/10/12 19:52

>>705
うーん漏れは>>703ではないが、それは違うと思うよ

宇宙の例えは、分割やモジュール化等の話ではなく、
抽象化の話なのではないかな

あるプログラムでは、人一人の情報は
名前と住所と電話番号かもしれないし
脈拍と血圧だけかもしれない
そういった事象の捉え方をしなきゃだめだよ、って話だよ

だから>>703はOOに限ったことではない、と言っているのだろうね

707 ：仕様書無しさん：03/10/12 20:06

>>706 ﾃﾞﾑﾊﾟ

708 ： ◆Lnp6yh4GGU ：03/10/12 20:07

>>706
いや、言ってることはわかるんだが・・・
結局OOってのはこのやり方でプログラムを
設計・開発・コーディングをすれば分割された
すっきりとしたプログラムを作れますよって物だと思う。

体系化された手法・知識の一つだから分割だけがOOではないと思うが
メリットを強調するときには分割が効率的にできますよっていうのがいちばんかと。

709 ：706：03/10/12 20:20

>>708
納得&同意です
余計な茶々失礼しますた

710 ：仕様書無しさん：03/10/12 21:09

>>708
きみって構造化プログラミングパラダイムの説明も、まったく同じ説明を
するんでしょ？

711 ： ◆Lnp6yh4GGU ：03/10/12 21:13

>>710
いいえ、不勉強なので構造化プログラミングの説明はできません
が、構造化プログラミングは体系化をあまりされていないものだから
同じ説明はできないと思います

712 ：仕様書無しさん：03/10/12 21:18

>>711
いや「分割」というキーワードこそが、構造化プログラミングの御旗だったわけだが。

713 ： ◆Lnp6yh4GGU ：03/10/12 21:29

OOが構造化プログラミングの上位の概念であると思ってるからな
わからんがおんなじ感じになると思う。

714 ：仕様書無しさん：03/10/12 21:34

>>713
いや「分割」がOOのメリットだと強調することはおかしいという話をしてるんだが。

715 ： ◆Lnp6yh4GGU ：03/10/12 21:48

では何がOOのメリットだと思う?
構造化プログラミングよりも優れた分割ができると思うし
他の機能もそれを補佐するためにあるものだと思うが?

716 ：仕様書無しさん：03/10/12 21:57

>>713
違う。
「OOPは構造化プログラミングを包含する」が正しい。
だから「構造化プログラミングの説明が出来ないのにOOPの説明が出来る」
ってのは矛盾しているぞ。

717 ： ◆Lnp6yh4GGU ：03/10/12 22:02

分割ってのは構造化プログラミングだけの専売特許ではないわけで
アクターモデル（擬人化）による思想・設計段階から統一的かつ
クラスという単位を定めたことによる再利用性の高い分割を
OOはできるようにしてくれたということだ。

むしろ構造化プログラミングの分割とOOの分割を比較することにって
よりOOのメリットが強調されると思う。

718 ：仕様書無しさん：03/10/12 22:04

>>715
そう聞かれると困るなぁ。
一時期は、拡張容易性がメリットだと言われてた時期もあったが、
それはまやかしだとわかったし。

設計・実装・テスト・メンテナンスの見通しのよさ、工数削減がメリットか？

719 ： ◆Lnp6yh4GGU ：03/10/12 22:05

>>716
俺の場合、OOを勉強したときにそこに
構造化プログラミングがあったことを気づかずに
通り過ぎてしまっただけだろう

720 ：仕様書無しさん：03/10/12 22:06

>>717
どの粒度で分割の話をしてるか良くわからんけど、なんかあんたの話は
ずれてる気がする。ホントにプログラマなの？

721 ： ◆Lnp6yh4GGU ：03/10/12 22:09

ちなみに俺は>>93でもOOによる分割のメリットを語っています

722 ：仕様書無しさん：03/10/12 22:14

OOのメリットは責任範囲を明確化できることです。
それを分割というなら分割ですな。

723 ：仕様書無しさん：03/10/12 22:17

構造化のメリットは責任範囲を明確化できることです。
それを分割というなら分割ですな。

724 ： ◆Lnp6yh4GGU ：03/10/12 22:21

>>720
このさい粒度は関係ないでしょ。
クラスによる分割が最大のメリットであるといってるのだから。
その副産物として>>722とか>>718があるのではないかといてるわけ

725 ：仕様書無しさん：03/10/12 22:29

>>724
うーん、何かが違うんだよなー。
設計時にはクラスは分割するものではなくて抽出するものだと俺は思う。
分割というキーワードは、リファクタリングの時にしか使わないような気がする。

それに、クラスは分割できるからすばらしいのではなくて、クラスはクラス
だからこそすばらしい。うまく説明できん・・・

726 ： ◆Lnp6yh4GGU ：03/10/12 22:30

>>723
ところが構造化プログラミングだけでは責任範囲の明確化ができないわけで。
グローバル変数の問題があるからな。
そこにクラスとアクターモデルを付けたらOOになると思う。

727 ：仕様書無しさん：03/10/12 22:37

つーか、アクターモデルなんか普通言わないし。
普通言わない単語を使って、これがOOですって説明が怪しげなんですけど。

728 ：仕様書無しさん：03/10/12 22:40

>>726
君は構造化プログラミングのモジュール内でグローバル変数使うの！？

729 ：仕様書無しさん：03/10/12 22:41

OOのスーパークラスが構造化プログラミングみたいな。
構造化プログラミングの意味はOOの意味より、更に抽象的みたいな。そんな感じ。

730 ： ◆Lnp6yh4GGU ：03/10/12 22:44

いや、アクターモデルってものがなければOOAとかOODが説明できないわけで。

アクターモデルってのはSmalltalkにはあるけどC++とかJavaではそぎ落とされた機能のこと

多分>>725は設計はやったことはあるがオブジェクト指向設計はやったことがないということでしょ

731 ：仕様書無しさん：03/10/12 22:49

オブジェクト指向でもグローバル変数みたいなことはできるし

732 ：仕様書無しさん：03/10/12 22:50

>>730
>いや、アクターモデルってものがなければOOAとかOODが説明できないわけで。
ハァ?

733 ：725：03/10/12 22:53

>>730
つーか、君のアクターモデルの定義を述べて味噌。
君こそOODやったことないんじゃないの？
「じゃークラス分割をやりましょう」なんて言ったらワラワレルゾ。

734 ：725：03/10/12 22:55

っていうか、それクラスじゃなくて、ドメインじゃないの？

735 ： ◆Lnp6yh4GGU ：03/10/12 22:58

アクターモデル＝擬人化じゃねーの？
オブジェクトが俳優のように振舞うように考えるってこと

736 ：仕様書無しさん：03/10/12 23:04

俳優っていうか意味的には役割。

737 ：仕様書無しさん：03/10/12 23:05

>>735
なんだそりゃ（ｗ

738 ：725：03/10/12 23:08

>>725
おいおい、君はSmalltalk知らなくて、メッセージとメソッドの違いもわからないんだろ？
それなのに、アクターモデルが無いとOOAやOODが説明できない？

わけわからん。

739 ：725：03/10/12 23:08

>>735の間違い、ﾃﾍ

740 ： ◆Lnp6yh4GGU ：03/10/12 23:10

正確にはアクターモデルレベルのOOA/OODまでしか理解できていないってことだ。

741 ：725：03/10/12 23:14

>>740
誰が？君が？

742 ：725：03/10/12 23:15

あー、返答はいいや。
君と話しても利益がなさそうだから、もういい。

743 ：仕様書無しさん：03/10/12 23:18

ここは>>725が取り仕切るスレになりました…。

744 ：630：03/10/13 01:00

100レス位、経ったけど、自説が裏付けられているような。

745 ：最凶VB厨房：03/10/13 01:24

まとめると変数に関数がついたものがオブジェクトということでよろしいか？

746 ：仕様書無しさん：03/10/13 01:33

>>745
まず概念モデル、仕様モデル、実装モデルと言う区別を覚えよう

747 ：仕様書無しさん：03/10/13 02:30

>>745
抽象化という概念も覚えよう。

>>745は「馬鹿」という抽象で捉えられる。ちなみに>>1も馬鹿だ。
>>745も>>1も馬鹿ということだ。つまり、二人とも馬鹿というで一緒くたに扱える。
馬鹿の特徴を言ってみよう。まあ、俺の偏見だが、こういうことにしておいてくれ。

・鼻水を垂らしている　　・馬鹿にすると怒る　　・口をあんぐり開けている　　・ショタ
・オブジェクト指向を理解できない　　・飛んだりはねたりしている　　・セックスしたい

これを言い換えれば、つまり、>>745も>>1も馬鹿だから、
鼻水垂らしていたり口をあんぐり開けていたり飛んだりはねたりしているということになる。
もちろんこの世の中には他にも馬鹿がいると思う。例えば俺だ。俺も馬鹿だ。
だから俺も鼻水垂らしていたり、上記のような特徴を兼ね備えている。
ちなみにここで注意しておきたいのは、鼻水を垂らしているからといって、
決して馬鹿だということではない。馬鹿 → 鼻水を垂らすということだ。

748 ：仕様書無しさん：03/10/13 02:39

さて、馬鹿は馬鹿でも色んな馬鹿がいるに違いない。「具体的」に言ってみよう。

まあ、俺の偏見だが>>745は猿のようにオナニーをしてしまう馬鹿だ。
>>745はVBしかできない馬鹿だ。>>745は救いようのない馬鹿だ。
>>745は一本グソしか出さない。>>745は、もうだめぽ。
こんなところだ。ちなみに俺は、チャック全開に気づかず街を闊歩する馬鹿だ。

こうしてみると、同じ馬鹿でも違うのがわかるだろう？しかし、俺と>>745と>>1は、
それぞれ違う馬鹿といえども、やっぱり馬鹿なんだ。これが抽象化というやつだ。

例えば、ヒットラーが三千年の眠りから醒めて、独裁政治を始めたとしよう。
そして高らかにこう宣言する。「馬鹿は始末せよ。」と。どう馬鹿を区別するかは知らないが
（さっきも言ったように別に鼻水を垂らしているからといって馬鹿とは限らない）、
馬鹿は始末するらしい。つまり、少なくとも>>1と>>745と俺は始末されちゃうだろう。
馬鹿とひとくくりにされて始末されちゃうだろう。

さようなら、みんな。

749 ： ◆Lnp6yh4GGU ：03/10/13 05:54

>>745
それは違う。変数ってのはそのコンピュータのレジスタで直接指定できるものしか表さない
それに対して構造体みたいな入れ物を用意してアルゴリズムとデータを放り込んで
いろいろな機能を追加したものがクラス。

関数ってのは一つの実装しか指さないけど
メソッドってのは名前は同じだけど起動するときの引数によって
起動する関数を切り替える機能をもってる

一つのメソッドが複数の関数を指している事があるわけだ。

750 ：最凶VB厨房：03/10/13 06:10

（（（（（（（゜Д゜;）））））））ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>749
構造体も変数ではないか？構造体変数という言葉があるぐらいだ。
アルゴリズムとデータ→関数と変数だろ。

ひとつのメソッドは複数の関数を指すと言っているわけだが、
関数は関数だろ。関数が複数。それだけだろ。

変数に関数がついたものがオブジェクトってのを
なんの否定もしていないように見えるが？

751 ： ◆Lnp6yh4GGU ：03/10/13 06:37

その考え方でいいと思う。
メモリ上に展開されたものがオブジェクト。プログラムをクラス。
ただ、オブジェクト指向ってのはそこに機能・思想を追加して
体系化したものだということも忘れないでくれ。

752 ： ◆Lnp6yh4GGU ：03/10/13 07:20

つまり
オブジェクトは変数に関数が付いたもの（＋α）
とはいるけど
変数に関数が付いたもの（全て）がオブジェクト

とはいえない微妙なニュアンスをわかってくれ。

753 ：最凶VB厨房：03/10/13 07:44

つまりオブジェクト指向とは従来型と
微妙なニュアンスの違いでしかないということで
いいですね？

754 ： ◆Lnp6yh4GGU ：03/10/13 07:53

そういうこと。知識的には微妙な差しかない。
ただし体系的な考え方を覚えることに意義があるということ。

755 ：最凶VB厨房：03/10/13 07:58

ではこのスレタイトル
「オブジェクト指向を理解できんとが何で悪いとや？」
の答えは、
「何も悪くない。」
でいいですね？

756 ： ◆Lnp6yh4GGU ：03/10/13 08:05

いや、それは違う。
オブジェクト指向を実践しようと思ったら
そのプロジェクトに参加する人全員がオブジェクト指向を理解していないと
オブジェクト指向のメリットが享受できないからだめだ。

オブジェクト指向がわからない人がわかる人の足を引っ張ってしまう。
だからわからない人は叩かれる

知識的にあまり差がない≠重要度が低い
ということだ

757 ：最凶VB厨房：03/10/13 08:27

メリット？どんなメリット？
微妙なニュアンスの違いでしかないのに、
大きな利益をもたらしてくれるような言い方ですが。

758 ： ◆Lnp6yh4GGU ：03/10/13 08:33

本来OOとはそのようなもの。子供にもわかるように作られている。
だから俺はせめてクラスによる分割という
最大のメリットがあるということを覚えてくれといっている。

759 ：最凶VB厨房：03/10/13 08:35

では子供にもわかるように言ってもらおう。
クラスによる分割がどんなメリットを生むのか。
頼みますよ。

760 ： ◆Lnp6yh4GGU ：03/10/13 08:51

>>718、722からの引用になるが

実装・テスト→クラス分割による開発サイクルの短縮・スパイラルモデルの導入
→何回もやり直すことによる質の向上

メンテナンスの見通しのよさ
→クラス分割による一度に扱う情報量の削減

工数削減→クラス分割による経験・コードの再利用

責任範囲の明確化→クラス分割による一人当たりのコード量の削減・明確化

761 ：最凶VB厨房：03/10/13 09:42

それは構造化プログラミングではできないと？
スパイラルモデルの導入などは正直わかりませんが。

コードの再利用？
どれくらい再利用されてますかー？
実際のことは知りませんが、
実務を行っている人がそれを感じていますか？？

責任範囲の明確化だって具体的にどうなるわけです？

そして一人で作る分にはオブジェクト指向は全く必要ないと言いたげですが、
この点についてはどうです？

762 ：仕様書無しさん：03/10/13 09:43

>>760
元発言は俺だけど、責任範囲の明確化というのはきみのいってるような
意味じゃないよ。

763 ：仕様書無しさん：03/10/13 09:44

>>761
多分、相手して楽しんでるんだろうけど・・・
だよね？

764 ：最凶VB厨房：03/10/13 09:49

>>763
俺はいかなる時も本気である。

765 ： ◆Lnp6yh4GGU ：03/10/13 10:01

>それは構造化プログラミングではできないと？
多分できる。しかしオブジェクト指向を勉強することでそれを
全て自然に実行することができるようになる
最悪の場合構造化プログラミングを極めたと思ったら
それはすでにオブジェクト指向で言われていることだったという可能性もある

>責任範囲の明確化
>>762と捕らえ方が違うらしいけど、俺はもっとライトに考えてる。
単純に誰がどのクラスを担当するのか決められるから責任も明確になると･･･
逆に言えば分割して無作為に割り振っても大丈夫な仕組みがOOにはあると。

>そして一人で作る分にはオブジェクト指向は全く必要ないと言いたげですが、
まったくではないがそのとおり。
しかしJDKのように精度が比較的高いライブラリを
使えば一人の場合でもメリットは享受できる。
OO的なデザインパターンによる経験の再利用もできる

766 ：762：03/10/13 10:29

捕らえ方が違うという問題じゃなくて、コンテキストが違うんですが。
OOA/OODで「責任」といえば、CRCの"R"を指すのが普通です。
（検索の手間を省くために書いておくと、CRCはClass Responsibility Collaboration）

つまりあなたはOOをやってる人間が使うようなコンテキストで
その用語を使わないから、OOがわかってないんじゃないのと
言われてるんです。

class responsibilityがわかってないんじゃ、アクターモデルもへったくれも
ないと思うんですがね。

767 ：最凶VB厨房：03/10/13 10:35

はっきりというと
構造化プログラミング≒オブジェクト指向プログラミングといってしまっていいですね？

単純に誰がどのクラスを担当するのか決められるから責任も明確になると･･･
のクラスを「機能」や「関数」と言い換えても全く問題ないようですが、どうです？

コードの再利用に関して反論がなかった点と、
クラスライブラリのメリットをあげられた点を合わせて考えると、
コードの再利用性は既存のクラスライブラリの出来に著しく依存していて、
オブジェクト指向といってもコードの再利用性があがるわけではない。
ということでよろしいか？
ライブラリに関しては汎用ライブラリというものが構造化プログラミングの時代にも
ありましたね？それに対するクラスライブラリの優位性とはいかなるもんです？

768 ：仕様書無しさん：03/10/13 10:39

つーか、お前ら>>692-693の時点で、こいつがネタかDQNかのどちらかだっつーことに気づけよ（藁

769 ：最凶VB厨房：03/10/13 10:50

>>768
俺はいかなるネタ,DQN相手でも本気である。

770 ：仕様書無しさん：03/10/13 11:58

>>767
まあ、分かってて遊んでいるだけなんだろうけど…

>構造化プログラミング≒オブジェクト指向プログラミング
VB みたいな構造化プログラミング言語にオブジェクト指向っぽい機能を追加した
言語におけるオブジェクト指向プログラミングは、それでいいんじゃない？

構造化プログラミングというのは、構造化理論に基づいたプログラミングで
「人間の思考ロジックは、逐次処理、判断、繰り返しの３要素で記述可能」
というドグマに従う手法。

オブジェクト指向は、はじめに「オブジェクト」ありきでできた概念で、
オブジェクトが、自身が内包するメソッド（関数）を起動する様子を、
メッセージの受信とそれへの反応という生物的な挙動に見立てて、これを
問題解決時の表現手法に用いられないか、もっと発展させて、
それのみですべてを表現できないかということを模索する過程で体系化された。
Smalltalkではその実践としてOSモドキまで作ってしまった。

したがって、オブジェクト指向プログラミングは本来、「オブジェクトに
対するメッセージ送信」のみで実践されるべきなんだけど、それではあまりに
効率が悪いので、メッセージ送信メタファは設計時のみに留めて、実装は
従来の構造化プログラミング手法との（文法、実装、理論、メタファなどなど
いろいろな局面での）折衷案が現在、主流になっているわけ。メソッドと
メッセージの区別が付かない人が多いのもこれが原因。

たとえば有名な話では、3 + 4 もオブジェクト「3」に対して「+ 4」という
メッセージ送信と考えてそう実装することも可能だし、構造化における
「判断」や「繰り返し」も同様に“オブジェクト指向”する、つまり
オブジェクトに対するメッセージ送信として記述したり実装できるけど、
SmalltalkやSelfを除けば、特にALGOL系の文法に慣れた人間は、記述する
にも実装としても効率が悪いので誰もそんなことを好んではしない、と。

771 ：仕様書無しさん：03/10/13 12:06

ちなみにSmalltalkですら、条件分岐は効率を重んじて内部では構造化以前の
表現方法（つまりgoto文）で実装されているのはこれまた有名な話。
なお、3 + 4のほうはちゃんと内部的にもオブジェクト指向しているｗ。

構造化とオブジェクト指向は本来、直交する概念なんだけど、
アスペクト指向とオブジェクト指向と同様に、組み合わせて使うのが
便利でそうする機会が多いから、結局、内包しているかのように
錯覚したり、そう説明される機会が増えている、と。

長文すまん。

772 ：仕様書無しさん：03/10/13 12:09

>>767
ﾈﾀにﾏｼﾞﾚｽ。

関数やモジュール(=手続き型)とクラス(=オブジェクト指向)とでは、
設計時の視点がまったく異なる。

関数には「(プログラムは)この関数で何を行うか」を設計する。
設計者は、関数のコンテキスト、すなわちプログラムやシステム全体の情報を把握している必要がある。

クラスには「このクラスは何を行うか」を設計する。
要件や分析結果をもとにしたオブジェクト指向設計でクラスを抽出する。
ただしクラスが持つメソッドを設計する際には関数設計時のような視点にたち、
メソッドのコンテキストであるクラス全体の情報を把握している必要がある。

オブジェクト指向パラダイムで保守性が上がるとされる理由はこんなところ。
一部の変更はコンテキスト全体に影響を及ぼすが、
そのコンテキストの範囲がクラスでは著しく制約されており、凝集性が高い。
大規模になればなるほど、このメリットは重要になってくる。

構造化プログラミングは、関数やメソッドの設計時に適用することがある技法だ。
ライブラリについては、それが関数であればライブラリ関数と呼ばれ、
クラスであればクラスライブラリと呼ばれるだけの話。
少々乱暴に言えばライブラリ、コンポーネント、フレームワーク、アーキテクチャの区別をつけるための言葉だ。

773 ： ◆Lnp6yh4GGU ：03/10/13 12:23

構造化プログラミングの中にオブジェクト指向プログラミングがあるといっていいでしょ
「機能」や「関数」と言い換えても問題はないが、
それらの用語をOOの用語や概念で統一することに意義があるのでは。

クラスの再利用に関してはOOPだけではあまり高まりません
そこら辺をOOA/OODで高めるようになっているとおもっている

ただし、クラスを使うようにしないとOOA/OODが適用できないから
まずはそこのところを強調すべきではないかと指摘している

Class Responsibility Collaborationは知らんかったけど
これだけの説明をするのに必要ないのでは
というよりもそこまで指摘するならスレの本題である
なんで理解できないと悪いかについても言及すべきではないでしょうか?

774 ：仕様書無しさん：03/10/13 12:24

再利用っていう言葉もどうかなーと思う今日この頃。
拡張性って言ったほうが伝わりやすいような気が。

775 ：仕様書無しさん：03/10/13 12:28

最近は「拡張性」=ソースコードレベルの再利用より、
バイナリレベルの再利用性が注目されているんじゃ

776 ：仕様書無しさん：03/10/13 12:28

>>769
あと、カプセル化、継承、多態性などはオブジェクト指向プログラミングの
真髄とか必須要素みたいに語られるけど、これらは「オブジェクト指向」
というよりも言ってみれば「オブジェクト指向するのに適したクラスひいては
オブジェクトの設計をどんなふうにしたらいいか皆で一緒に考えよう指向」みたいな
もんで、経験積んだり、イデオム、パターンみたいなものに頼ったりして処理系
依存的に身につければいい実はあんまり「オブジェクト指向」するには本質的な
ものではなかったりする。ここに立脚してオブジェクト指向の一般化を試みたり、
その談義をしようとするとお定まりの宗教論争が勃発する。この20年はその繰り返し。

777 ：仕様書無しさん：03/10/13 12:28

>>773
CRCも知らずにOOを語っていたとは。

778 ：仕様書無しさん：03/10/13 12:33

スレタイが悪かったな・・・
OOなのかOOPなのか

779 ： ◆Lnp6yh4GGU ：03/10/13 12:39

>>774-776
そう、そういうレスがほしかったのよ

780 ：仕様書無しさん：03/10/13 12:41

正直、 ◆Lnp6yh4GGU は分かってない。
1メガ歩譲って分かっていたとしても、それを説明する能力に欠けている。

781 ：仕様書無しさん：03/10/13 12:49

Publicなメンバ変数をsetter, getterで代入すれば
オブジェクト指向のできあがり。

782 ：最凶VB厨房：03/10/13 13:00

>>781
Privateなメンバ変数でなくて？

それはさておき感想を・・

>>770-771は非常にわかりやすく、
あぁなるほどと思わせる。ためになった。
>>772抽象的でわかりにくい。
>>773
オブジェクト指向プログラミングが構造化プログラミングよりも
優位であるのかという疑問に対して全く答えていない。

783 ：仕様書無しさん：03/10/13 13:11

>>782
最凶さんは、>>772のどこが分かりにくいのかなあ。
>>770-771 も分かりやすいし、>>772 もよく抽象されていて分かりやすいけど。

784 ：仕様書無しさん：03/10/13 13:20

>>782は、責務っていう考え方が解ってないんだろう。
プログラマはシステムの全てを知っていなければならないという古い考え方の持ち主なんじゃないの。

785 ：仕様書無しさん：03/10/13 13:35

>>780
NGワードに入れれば？俺は入れたよ。余計な時間を食わなくてすむ。

786 ： ◆Lnp6yh4GGU ：03/10/13 14:14

>>782
>それらの用語をOOの用語や概念で統一することに意義があるのでは。
でいちおう言ってるんだけどな･･･
それ＋

クラスって言うアルゴリズムとデータを入れる入れ物ができて、
マルチプルインスタンスが使えるようになった。
OOA/OODを活用してクラスを作ると作った本人以外でもコードが読みやすくなる
メンバ変数がprivateを推奨されていることによるカプセル化

くらいかなあ・・・

787 ：最凶VB厨房：03/10/13 14:42

何がわからないかといえば、
具体論としてほんとにそうなのか？というのがわからないわけだ。
前者（手続き型）ではシステム全体の情報を把握している必要がある。
後者（OO)ではクラス全体の情報を把握している必要がある。
となっており、単純に考えてシステムとクラス１個のどちらがでかいかは明白なわけだから。
保守性があがるという意味はわかる。という意味だよね？

勘違いしているのかもしれないが、
構造化プログラミングにサブシステムという考えがあるよね？
サブシステムでわければ、サブシステム全体の情報を把握する必要だけですむのでは？
サブシステムがでかけりゃ、サブサブシステムを作ればいい。

と考えると、手続き型とOOの明確な違いがわからないわけです。
>>784
責務は知りませんでしたが、
プログラマはシステムの全てを知っていなければならないという考えはもっていません。

788 ：最凶VB厨房：03/10/13 14:55

>>786
その用語と概念を統一してどううれしいことがあるのかと聞いている。
>マルチプルインスタンス
単純に関数つき変数ということでよろしいですな？
>OOA/OODを活用してクラスを作ると作った本人以外でもコードが読みやすくなる
構造化だと読みにくいと？
>メンバ変数がprivateを推奨されていることによるカプセル化
意味不明。いや本末転倒というべきか？

789 ：仕様書無しさん：03/10/13 15:01

>>785
俺も入れたよ。NGワードの存在を忘れてた。
なんかこいつの発言を読むと
「それは違うんだ～」
「なに言ってんだおまえ～」
って絶叫したくなるんだよね（ｗ

790 ：仕様書無しさん：03/10/13 16:20

つか、OOって工学や自然科学のシステムに向いているんだろ？
事務処理やらせるのにOOのような概念を持ち込むのはナンセンス。
事務処理システムというものは、きっちり、ピッタリとした
「有機化合物」でなければならない。

791 ：仕様書無しさん：03/10/13 16:25

昔、機械語から高級言語になったときは、高級言語の方がバカにされたもんだ。
より手抜きできる方（ＯＯ）をバカにするのが技術屋としての正しい在り方。

792 ：仕様書無しさん：03/10/13 16:30

>>788
VBのクラスとオブジェクトのインスタンス
http://homepage1.nifty.com/CavalierLab/lab/vb/clsmdl/instance.html

793 ：仕様書無しさん：03/10/13 16:59

>>792
たのむっ。俺の「オブジェクト指向」が汚染されてゆくから、
やめてくれ～っ、てな感じですな。これで OO している and/or
せなあかん VB 厨には申し訳ないけど…。悪いこといわんから、
OO は別の言語で勉強しなさい…。
ttp://homepage1.nifty.com/CavalierLab/lab/vb/clsmdl/object_type.html

794 ：仕様書無しさん：03/10/13 17:03

OOはPerl6で勉強するのがいいみたい。

795 ：仕様書無しさん：03/10/13 17:05

>>790
有機の実験室、臭すぎ。

796 ：仕様書無しさん：03/10/13 17:13

>>792
それはVB6の構文なんでないの？

797 ：仕様書無しさん：03/10/13 17:42

>>793
書き直すのがめんどい。
あとVC++とか買う金もない。鬱だ。_|￣|○

798 ：仕様書無しさん：03/10/13 17:55

>>657
テストケースクラスのソースくらいみさせてもらわんと
本番クラスのコードの信頼性を確認できないだろ。

799 ： ◆Lnp6yh4GGU ：03/10/13 19:36

>>787-788
>サブシステムとの違い
そこで初めて継承（インヘリタンス）と多態（ポリモーフィズム）が出てくるんですよ。
これらの機能がクラスには備わっているのが
構造化プログラミングのサブシステムとの違い。

>>OOA/OODを活用してクラスを作ると作った本人以外でもコードが読みやすくなる
>構造化だと読みにくいと？
えっと何も考えずに作ったら構造化と大して変わらんと思う。
「オブジェクト指向プログラミング」ってのは
アクターモデルのようにプログラム自体を人間に見立ててくださいとか
プログラムの作り方を指定されていて、いかにその作り方に忠実にあてはめて
プログラムを組み立てていくかってことだと思う。
作り方が指定されてるから他の人がなんでそのコードを書いたのかすぐにわかる
（それを狙っている）わけ。

>>メンバ変数がprivateを推奨されていることによるカプセル化
>意味不明。いや本末転倒というべきか？
これはうまく「オブジェクト指向プログラミング」ができたときに
初めてわかる領域だから無視していいよ。

800 ：仕様書無しさん：03/10/13 20:55

>>703
Java3Dで宇宙をつくったことある？

801 ：仕様書無しさん：03/10/13 21:38

>>798
他から持ってきたクラスのバグを、
そこは漏れがつくったんじゃないから知らんといえるようになったら一人前
NIH症候群を脱却せよ

802 ：仕様書無しさん：03/10/13 21:38

>>666
VB6以前まではオブジェクト指向ではない。
VB.NETのみがオブジェクト指向言語だ。

803 ：仕様書無しさん：03/10/13 21:44

>>787
OOのクラス設計は、モジュール分割、段階的詳細化のようなトップダウンの視点じゃない。
ボトムアップだけでもない。

つうか、OOの利点として、そもそも抽象データ型っていうのが大事なんでしょ。
インターフェースと事前条件、事後条件だけ知ってりゃいいんだ。

804 ：仕様書無しさん：03/10/13 21:50

面白いから ◆Lnp6yh4GGU は泳がしておこう

805 ： ◆Lnp6yh4GGU ：03/10/14 07:29

結局OOはOOPだけを見ても構造化プログラミングに毛が生えた程度でしかないんだよ。
本質はOOA/OODとあわせたプログラミングの意志統合にあると思う。
OOP自体はその手段に過ぎない（しかし手段だからこそ覚えておく必要はある）
だから多態や継承なんか後回しにしてサブクラスとしてクラスを教えて
その次に一番基本的なOOA/OODとしてアクターモデルを使って
実践的に個々の機能をあてはめて使うようにしていく
そういう風な教え方はできないのか？と思っている

本なんかを見ていても「機能」の方をとりあげて意志統合のところをうまく説明できてる物は少ない
（オブジェクト指向を目的指向などと訳しているのにはびっくりした）

Squeakプロジェクトはそういう風な風潮に業を煮やしてもう一度本当の意味でのOOを復活させたのかな？
と思っている（だから教育的だといってるのではないか?）

806 ：仕様書無しさん：03/10/14 10:29

>>805
ほとんどのOO入門書ではそういう風な教え方をしているのだが、
それがわかりづらいから問題なのでは？

807 ：仕様書無しさん：03/10/14 10:30

>>794
その理由はいかなるものか？
それがperl6の布教活動による宣伝でなければ
科学的根拠をもってして実証して欲しい。

808 ：197：03/10/14 10:31

>>805 元気だね。
開発モデルについても言及してくれないか。

809 ：仕様書無しさん：03/10/14 10:32

>>797
いちいちVC++買うのもアフォ。
C++ならg++があるだろが。
ほかにオブジェクト指向を理解できる言語としてJavaやSmalltalkがあるだろが。

IDEがないとなにもできないならフリーやオープンソースのIDEを使え。
Eclipseがお勧めだ。

810 ：仕様書無しさん：03/10/14 10:41

>>801
開発効率を気にしているんだったら
ユニットテストくらい知ってるだろ。
信頼性の確認なんだよ。

eXtreme Programmingやってるならそれくらい知ってるだろ。

本番のソースコードを読ませろとはだれも言わない。
テストコードのソースコードくらいは公開されても特に問題ないだろ。

811 ：仕様書無しさん：03/10/14 10:43

ケントベックの作ったIDEはEclipseによって見事に引き継がれている。
eXtreme ProgrammingはSmalltalkから生まれたようなものだろう？ >>805

812 ：仕様書無しさん：03/10/14 10:45

オブジェクト指向を理解せず、使いこなせないものはリスク管理が苦手なのだろう。
万が一に備えた地震対策もせずにいると大規模化で泣きを見る。

813 ：仕様書無しさん：03/10/14 10:54

構造化手法は
各関数に対する相互作用の数の多さ、依存関係による副作用から
君主政治

それ以前の手法は効率の悪さから専制政治

オブジェクト指向は共和政治。本格的に理解し使いこなせば民主主義。

乱立する処理系に依存しすぎの機械語は無政府状態。

VBはなにをやって努力しても言語の性質上実力が反映されずVB厨よばわりされて単価が安いので共産主義。

そして、

　　！！！！！！！いまだ見ない未知なる究極の開発手法はサイバー民主主義！！！！！！！

けれどもそれはアスペクト指向云々とか関数型言語とかでもない。

814 ：仕様書無しさん：03/10/14 11:01

C++は一時は優秀な人材によって支えられたものの、
後には官僚の汚職が多く退廃してゆく古代ローマ帝国の共和政治。

C#はかろうじて民主主義を手に入れたが、市民の意見が正確に反映されない。

Java, Smalltalkはアメリカ的な本格的な民主主義。
現在、もっとも効率の良い最高の政治形態とされるが、まだまだ改善すべき事態は残されている。

815 ：仕様書無しさん：03/10/14 11:32

政治のことなんか何も知らん馬鹿がなにかわめくスレ？

816 ：仕様書無しさん：03/10/14 11:48

なんか別の意味でぐだぐだになったな。

なんでコンピュータ言語を政治と関係させるんだ。
政治形態と経済体制が同列に置かれてるし。
つーか的を射た項目が一個も見当たらん

817 ：仕様書無しさん：03/10/14 11:53

>>815-816
あげてるところからみるにあからさまな釣りでしょ

818 ： ◆Lnp6yh4GGU ：03/10/14 15:04

>>806
一番の原因は手続き指向とか従来の手法との違いを
ソースコードで示していないからだと思う。
別にその手法自体には問題がない。
>>808
開発手法としてのOOを見たときの一番のメリットは繰り返すがプログラミングの意思統合だ。
設計思想から実装時の個人の癖の部分までアクターモデルのような手法で統一することにある。
アクターモデルもまた一つの手法に過ぎない。
それ以外の手法が存在することはオブジェクト指向以外の言語を習得しているものには直感的にわかる事だ。
ただし,それでも合わせることに意義があるものだと思う
>>811
同意です。おれ自身Eclipseをうまく使いこなしてはいないのですが…
XPは最近のOOA/OODを見直す動きをさらに発展させたものだと思います

819 ：仕様書無しさん：03/10/14 17:07

「かっちょ良く例え話しをしてヒーローになろうとした」に３オブジェ。
そして別の意味でヒーローになった。

820 ：797：03/10/14 18:03

>>809
OOPは勉強だけじゃなくて実践目的でもあるんだよね。
今ゲーム作っててソースコードが結構な量になってる。
もちろんVBじゃ不満たらたらだけど
C++でGUI設計のプロセスもいまいち把握しきれてないし
ゲームが形になってからゆっくりC++に移行するつもり。
てかEclipceはC++でも使えるのか。Javaだけだと思ってた。

821 ：仕様書無しさん：03/10/14 19:49

手法云々する前に、ここにいるやつらの作ったものを見てみたい。
初心者の作ったマクロ程度の事も出来ないんじゃないのか？ｗ

822 ：197：03/10/14 22:09

>>818
アクターモデルってのは並列計算モデルのひとつで、
並列オブジェクト指向の説明／理解に使われるモデルのことだろ。
手法じゃないぜ。
開発モデルについて言及して欲しいと書いたが、
メッセージパッシングに失敗しているみたいだな。
開発モデルという言葉を知らないことが明白だもん。

あのさあ、俺は自分の理解していることしか書きこみはしない様にしているけど
そうでない人もいるって事がわかったよ。
>>804　の意味もね。

823 ：仕様書無しさん：03/10/14 23:37

「プログラミングの意思統合」って何？

824 ：仕様書無しさん：03/10/14 23:45

プログラミングとは意思決定の積み重ねであって、
「ここで漏れはこう判断したのじゃ」と
設計上・コード上で、ある程度意思を明らかに残しておけるのが
OOの利点のひとつだと思うが

意思統合ってのは何だろう??

825 ：仕様書無しさん：03/10/15 00:10

なんかよく分からんけどオブジェクトって微生物？

826 ：仕様書無しさん：03/10/15 00:38

>>825
精子のようなもの。
発射時はインターフェースにより、実装は見えない。女性は受け入れるか否かを判断する。
受け入れてみて初めて、階層構造が見える。オーバーライドしまくってるかもしれん。
産んで２週間後、継承による拡張ではなく、委譲も行わなければ使い物にならない
ことに気付く妻であった・・・・・・・つづく。

827 ：仕様書無しさん：03/10/15 00:42

「プログラミングの意思統合」は本当に意味が分からない。
いつ、どのような状況で、誰の、何に対する、どのような意思を統合することを指すのだろうか。

828 ：仕様書無しさん：03/10/15 00:53

すべての時間(とき)において
まばゆい光に包まれながら
神の
人類に対する
無限の愛の意思を統合するのです・・・

とか言い出しそうな雰囲気

829 ：仕様書無しさん：03/10/15 00:56

>>827
女が腐ったような言いぐさで夜中に揚げ足取り続けるほど暇なのか？
本当にわからないのならば、寝れよ。

知　恵　遅　れ　さ　ん　。

830 ：仕様書無しさん：03/10/15 01:05

>>829
きみと、書いた本人以外は誰もわかってないと思われるが。

831 ：仕様書無しさん：03/10/15 09:05

◆Lnp6yh4GGU へ
悪口雑言のつもりは無いのだ良く読んでくれ。あんたは精神的な疾患にかかっている。
周りの人間に二人きりでいるときにそれを確認してみてくれ。完全否定の回答が無かったら、相当する医者にいけ。
面白がって泳がしている人もいるが、新しいこと事を学びたいと思って読んでいる人間にとっては「なじりあいより悪いあれかた」なんだ。

832 ：仕様書無しさん：03/10/15 11:10

「プログラミングの意思統合」まだぁ？

833 ：名無し＠沢村：03/10/15 11:22

つまりおまいらのレベルは、
オブジェクト指向→理解できない
手続型言語→理解できる
ポインタ→理解できない
配列→理解できる
ＭＦＣ→理解できない
ＳＤＫ→理解できる

ってことでよろしいか？
つまりおまいらの偏差値は５２！！！

834 ：仕様書無しさん：03/10/15 11:25

○|￣|_=3　ﾌﾟｯ

835 ：仕様書無しさん：03/10/15 12:19

頭のおかしい人が集結しつつあります。

836 ：仕様書無しさん：03/10/15 17:20

◆Lnp6yh4GGU は
一般に知られている言葉と同じ言葉を使って
まったく別の体系を組み立てているんじゃないかと妄想してみた。
(彼/彼女の頭の中では)その体系は矛盾なく構築されているんだ。

残り150余りのレスの間にはたしてその謎が解けるだろうか…

837 ：仕様書無しさん：03/10/15 23:20

>>832
ttp://www-6.ibm.com/jp/developerworks/java/021018/j_j-xp0813.html
の「共通の用語」ってことではないかと思うが、いかがか？

838 ：仕様書無しさん：03/10/16 08:06

違うでしょ。

839 ：仕様書無しさん：03/10/17 01:46

オブジェクト指向を否定する者、変化を拒む者。

すなわち抵抗勢力

<オブジェクト指向使用命令>
！！！！！！！！！！変化ヲ擁護セヨ！！！！！！！！！！

840 ：仕様書無しさん：03/10/17 01:52

人間は、変化によって何かを失うかもしれない時、激しく抵抗する。
一方、変化によって何かを得られるかもしれなくても、それを動機に
上記の抵抗に引き合うほどの熱意で変化させようとする人間は少ない。

日本人は特にそうだな。

841 ：仕様書無しさん：03/10/17 02:03

>>839
変化を抱擁せよ
って訳もあったぞ。

842 ：仕様書無しさん：03/10/17 02:45

>>840
だからこそ変化しなければならない。
いまこそ、忌々しいウォータフォールモデルを投げ捨て
XP、RUPでアージャイルな開発を使用ではないか！

いつまでも頑固に古典的な古い考え方にとらわれるわけにはいかない。
いまこそアージャイル開発を先導すべきだ！

843 ：仕様書無しさん：03/10/17 02:48

アージャイルな開発手法を普及させるには
まずオブジェクト指向を普及させなければならない。
オブジェクト指向を普及させるには
UMLの普及が手助けになる。

オブジェクト指向の普及にはJava言語/Smalltalk言語の習得も手助けになる。

アージャイルな開発手法を普及させるには
Eclipseを使わせることがもっとも効率が良い。

844 ： ◆Lnp6yh4GGU ：03/10/17 03:42

本来グローバル変数とアルゴリズムの入れ物であるサブシステムでしかない「クラス」は個々のメソッドをどのクラスに作るかは自由だった。
どのようなクラスに設計していくかは個人の自由だった。
（これはOOではないクラスと見比べればすぐわかると思う。）
ところが「現実のものにたとえさせる」こと・クラスを現実のものと仮定して「設計」
させることによってなんでそのメソッドとか変数がそのクラスにあるかを自然に理解できるようになった。
そのトリックに気が付いたとき初めてOOってものわかるんじゃねーのってこと。

・・・が確かに疲れてたね。
意図しない説明とかが結構飛び出してるし上のことを意志統合って言ったのはまずかった。
（XPのあたりは完全に間違ってる）
けど実際OOってなんだって言われたらこれしかないと思う。

つーか消えるよﾉｼ

845 ：仕様書無しさん：03/10/17 05:04

間違っててもあってるなりに役に立つってのは
本職でない俺にとってはありがたい話だなぁ。。。

846 ：仕様書無しさん：03/10/17 06:49

ようするにＯＯＰ出来ない奴はアフォ。
それだけの話しなのな。

847 ：仕様書無しさん：03/10/17 08:52

>>843
オブジェクト指向とUMLは、本質的には関係無いよ。

848 ：仕様書無しさん：03/10/17 09:44

アージャイルの"ー"が気に入らない。
どこにもない音を捏造している。

おそらく、中身のないことを恥ずかしげもなく話せる人間性の持ち主なのだろう。

849 ：仕様書無しさん：03/10/17 11:42

アジャイル云々を語るなら、まずはアジャコングを倒してからだ！

850 ：仕様書無しさん：03/10/17 12:39

>>848
ﾌﾟ
agileの発音は少なくとも二種類あるぞ。
アージル( ae d 3 e l )、アージャイル( ae d 3 a I l )

聞いてみな。
アジャイルと発音するのは棒読みしかできない日本人だけだとな。

貴様はcosのことをコーサインと発音することをためらうのか。

851 ：仕様書無しさん：03/10/17 12:41

>>847
> >>843
> オブジェクト指向とUMLは、本質的には関係無いよ。
そんなことはどうでもいい。
とにかくUMLはオブジェクト指向の普及の手助けを
できることが重要だ。

852 ：仕様書無しさん：03/10/17 14:51

>>848 >>850
外国語のカタカナ表記で論争するのはやめようよ。
明治時代からそうだけど、最初はどうしても「ゆれる」んだ。
同じ事物を指示していることがわかればいいと思うんだ。そのうちに統一されていくから。
#アジルと呼ぶ奴もいるし。

853 ：名無し＠沢村：03/10/17 18:54

手続き型言語は理解できるが、オブジェクト指向は理解できない。
算数は理解できるが、数学は理解できない。
変数は理解できるが、ポインタは理解できない。
どうやらこれらの理解できるできないの水準は同じレベルにありそうだな。
この水準を仮に５０とすると、５０以上のやつを頭がいいやつ、５０以下のやつを頭が悪いやつというんだろうな。
また、人間誰しも頭の良さはそう変わらないといわれるが、それは簡単なことを考える力は頭のいいやつも悪いやつもそう変わらないということだろうな。
いやむしろ、簡単なことを考える力は頭の悪いやつのほうが頭のいいやつよりも上だったりすることもあるよな。
簡単なことを考える力はね…人間誰しも変わらないものだ♪

854 ：最凶VB厨房：03/10/17 19:10

発音記号を読めないというのは恥ずかしいね。

855 ：名無し＠沢村：03/10/17 20:18

頭の悪いやつ「おれは難しいことを考える力はないが、簡単なことを考える力なら誰にも負けないぞ！」

856 ：名無し＠沢村：03/10/17 20:21

2chプログラマ「おれは難しいプログラミングをする力はないが、簡単なプログラミングをきちんとする力なら誰にも負けないぞ！」

857 ：名無し＠沢村：03/10/17 20:24

2chプログラマ「おれは高度なプログラム技術を使う力はないが、初歩的なプログラミングテクニックを駆使して高度なソフトをつくる力なら誰にも負けないぞ！」

858 ：仕様書無しさん：03/10/17 20:25

>>856
まぁ、あなたは他人が理解に苦しむことを書くのは負けないですね

859 ：名無し＠沢村：03/10/17 20:26

頭の悪いやつ「おれは難しいことを考える力はないが、簡単なことの中で難しいことを考える力なら誰にも負けないぞ！」

860 ：名無し＠沢村：03/10/17 20:29

頭の悪いやつ「ホントに頭がいいやつというのは、難しいことを考えるやつのことではない。
ホントに頭がいいやつというのは、簡単なことの中で難しいことを考えることができるやつのことだ。
だから東大生は馬鹿だ。おれが一番頭がいい」

861 ：名無し＠沢村：03/10/17 20:34

2chプログラマ「ホントにできるＰＧというのは、難しいプログラムを組むＰＧのことではない。
ホントにできるＰＧというのは、手続き型のような簡単なやりかたで高度なソフトをつくる力を持ったやつのことだ。
だから高度なＰＧは馬鹿だ。おれが一番頭がいい。おれはまだ高度なソフトをつくったことはないが、おれが一番頭がいい」

862 ：名無し＠沢村：03/10/17 20:37

頭の悪いやつ「数学なんて必要ないよ！ホントに頭がいいやつというのは、足し算、引き算レベルの発想だけで難しいことを考えるやつだよ。
数学なんてするやつは馬鹿だよ。おれは足し算、引き算レベルの発想なら誰にも負けないよ。東大生は馬鹿だ！」

863 ：仕様書無しさん：03/10/17 20:38

>>名無し＠沢村
あんた暇そうだな･･･学生か？いたるところにおまえさんのHNを見かけるのだが･･･

864 ：仕様書無しさん：03/10/17 20:54

>>844
お前なぁ、そんな意味で「意志統合」なんて言ったって
誰も理解できねーっての。お前はOOPがどうのこうの言う前に、
コミュニケーション能力とか表現能力に難がありすぎ。
トリックも何も、お前の言ってるようなことはオブジェクト
指向の入門書の1ページめに書いてあるようなことだ。基本的
なプログラミングパラダイムを理解しているかどうかって
話だし、「意志」とは何の関係もない。
デザパタなんかと併用することで、プログラマ間の意識を
統一のするとか、そういう話かと思っていた。844は程度が
低すぎだな。

865 ：仕様書無しさん：03/10/18 03:20

>>864
できないよりできたほうが良いに決まってる。
今の環境がオブジェクト指向だったとしたら拒む理由はどこにある？
長い物には巻かれろ。巻かれてみて意見汁。
仕事でやってるのならば、拒み続けることは怠け者以外の何者でもない。給料泥棒か？
知的欲求を失った者は技術者失格の烙印を俺が押してやる。

866 ：仕様書無しさん：03/10/18 03:23

「意思」なんてものは、プログラム同士がお互いを監視するような
AIじみたものでもない限りありえないんだよ。

867 ：ニコパチ推進委員会：03/10/18 06:52

Ｇ)、∧＿ ∧ 　ヽ(≧∀＜）ニコパチ! 　　　＼　 ○）　　　　｀l⌒人　　　　（＿） J　　　

868 ：仕様書無しさん：03/10/18 09:10

>>865
( ﾟдﾟ)ﾎﾟｶｰﾝ

なぜ脈絡の無い話で864に噛み付いてるんだろう・・・？

869 ：仕様書無しさん：03/10/18 10:03

ひたいに烙印をおしてやりたい

870 ：仕様書無しさん：03/10/18 10:18

「肉」とか「米」とか「中」とか・・・

871 ：仕様書無しさん：03/10/18 12:23

>>865
誤爆か？それとも真性のKittyか？864のどこを見たら俺がOOP
を拒否してるように見えるんだ？10年以上前からC++してるし、
Javaは黎明期から使ってる。巻かれるという意味なら巻かれ
まくってるし、むしろ俺が巻いてる方でもあるわけだが。

872 ：仕様書無しさん：03/10/18 12:51

(藤本)美貴はキティちゃんが大好きなので「ミキティ」と呼んで欲しいそうな・・・。

873 ：仕様書無しさん：03/10/18 13:43

キティガイ

874 ：仕様書無しさん：03/10/18 15:55

ミキティガイ

875 ：仕様書無しさん：03/10/18 18:50

藤本美貴のブリブリな唄声がどうも耳に馴染めません。

876 ：仕様書無しさん：03/10/18 18:54

>>871
できないよりできたほうが良いに決まってる。
今の環境がオブジェクト指向だったとしたら拒む理由はどこにある？
長い物には巻かれろ。巻かれてみて意見汁。
仕事でやってるのならば、拒み続けることは怠け者以外の何者でもない。給料泥棒か？
知的欲求を失った者は技術者失格の烙印を俺が押してやる。

877 ：仕様書無しさん：03/10/18 20:16

真性ｷﾃｨだったようだな(笑)

878 ：仕様書無しさん：03/10/18 22:40

>>877
できないよりできたほうが良いに決まってる。
今の環境がオブジェクト指向だったとしたら拒む理由はどこにある？
長い物には巻かれろ。巻かれてみて意見汁。
仕事でやってるのならば、拒み続けることは怠け者以外の何者でもない。給料泥棒か？
知的欲求を失った者は技術者失格の烙印を俺が押してやる。

879 ：仕様書無しさん：03/10/19 06:47

δζδ
　 ∇ ＜ハ～ゲ！

880 ：仕様書無しさん：03/10/19 06:47

δζδ
∇ ＜ハ～ゲ！

881 ：仕様書無しさん：03/10/19 06:48

δζδ
. ∇ ＜ハ～ゲ！

882 ：仕様書無しさん：03/10/19 06:49

δζδ
..∇ ＜ハ～ゲ！ハ～ゲ！

883 ：仕様書無しさん：03/10/19 11:17

情報処理試験の午前終了。オブジェクト指向関連の問題がやけに多かった。差がつかないから困るね。

884 ：仕様書無しさん：03/10/19 13:31

>>883
そうか。今日は情報処理試験だったな。俺は今期も寝過ごした。と。

885 ：仕様書無しさん：03/10/20 09:33

これから初めてプログラミングするんです～ってな
状態じゃなければなんとでもなりそうな気がする。

886 ：仕様書無しさん：03/10/20 10:23

>>885　うーん。ｃで書いてもｃ++処理系はokだからなあ。
まあ最初の内は、クラス設計はわかっている人にやってもらったほうがいいよ。
具体例の理解から始めるんだ。
「具象の理解」を「抽象の理解」に昇華できるかな？

887 ：ｵﾌﾞｼﾞｪｸﾄ指向：03/10/21 16:15

http://www.geocities.jp/dizzy_milkyhysterics/
こんなサイト見つけた～
どうかな？対話形式って新しい？
つくりかけみたいだが　ご意見キボン

888 ：仕様書無しさん：03/10/21 17:53

>>887
「C++のコーダ」を速成するには適切かな。
「いかにしてクラス設計するか」が欠落しているよ。

889 ：仕様書無しさん：03/10/21 23:37

>>887
継承の概念が省略されている。

890 ：仕様書無しさん：03/10/21 23:54

>>887
基本的なHTMLも書けない奴に説得力は無いな。

891 ：仕様書無しさん：03/10/22 00:11

C#でデリゲートやイベントをバリバリ使ってるソース見たけど
あれはオブジェクト指向とは言えんしな

892 ：仕様書無しさん：03/10/22 22:29

RPGゲームで活躍するモンスターを作るとします。
モンスターは味方キャラにも敵キャラにもなります。
OOPと非OOPではそれぞれモンスターはどんな風に作られますか？

893 ：仕様書無しさん：03/10/22 22:36

>>892
非OOPなら「モンスター」は作らない。

894 ：仕様書無しさん：03/10/22 22:46

>>891
オブジェクト指向と言えない理由がないなぁｗ

895 ：仕様書無しさん：03/10/22 22:47

>>891
イベントはJavaにもあるし、
デリゲートは関数オブジェクト。
これぞ真のオブジェクト指向。

896 ：仕様書無しさん：03/10/22 22:54

>>893
ギャフン！
あるとしたら表だけか。。。
上手い例が思いつかん。
出なおしてきます。

897 ：仕様書無しさん：03/10/22 23:38

バッチ処理こそオブジェクト指向に向くなあと、つくづく思います。

898 ：仕様書無しさん：03/10/24 00:28

>>897 オブジェクト指向がインタラクティブシステムに向かないのは、
オブジェクト指向のセイではない。
人がオブジェクト指向な動作をしないのがいけない。

オブジェクト指向は絶対的な美で正義であり真実である。
仮に不都合、不道徳な面を感じたとしても、
それは人の不完全さを鏡に映しているにすぎない。
呪いはオブジェクト指向ではなく、
人として生まれたがための宿命に向けられるべきである。

最近は、システムを受注すると、システム操作の教育コースの
費用を見積に含めるのが普通になってきているようだが....

899 ：897：03/10/24 01:08

まったく同意しない。

オブジェクト指向パラダイムが全能と考えるなよ。
人間は、もっとエレガントにいろんなことを無視して物事を考えられる。

900 ：仕様書無しさん：03/10/24 08:54

やっぱり宗教だな・・・

901 ：仕様書無しさん：03/10/24 09:07

概念共有して仕事し易くも目指しているはずなんだが…

902 ：仕様書無しさん：03/10/24 22:50

プログラミングは神との対話なのだ
(神の定義は人による)

903 ：仕様書無しさん：03/10/25 00:08

大昔は紙との対話だったそうな・・・。

904 ：仕様書無しさん：03/10/25 00:28

お客様は神様である。
お客さまは、「いろんなことを無視して物事を考え」た
要求をだしてくる。
プログラマがそれを理解できないのがいけない。

お客様の要求は絶対的な美で正義であり真実である。
仮に不都合、不道徳な面を感じたとしても、
それはプログラマの無能さを鏡に映しているにすぎない。
呪いはお客様の審美眼にではなく、
プログラマとしてメシをくわざるをえない己が宿命に
向けられるべきである。

905 ：仕様書無しさん：03/10/25 22:07

まったく同意しない。

顧客指向パラダイムが全能と考えるなよ。
プログラマは、もっとエレガントに顧客を無視して物事を考えられる。

という突っ込みが必要かと...

906 ：仕様書無しさん：03/10/26 00:15

客なんか最終的に喜ばしてやりゃ、要求なんて一つも呑まなくたってかまわない。

907 ：仕様書無しさん：03/10/26 03:27

>>897 そう思う理由を教えて。

最近はあまり啓蒙書を読まないので、最新動向には不案内なんだけど、
バッチシステムよりは対話型システムの開発にOOは適している
と喧伝されてなかった？

908 ：仕様書無しさん：03/10/26 09:12

バカ対策としてオブジェクト指向否定派に喝を入れよう。
こいつらがバグの温床になっている。
しっかりとオブジェクト指向教育でしごいてやらねばならん！

ﾋﾞｼｯ! ﾊﾞｼｯ!

とくにCOBOLerやVB厨、C厨にはしっかり教育してやらねばならん！！！！
しかしC++厨の大半はオブジェクト指向を理解せず使いこなしていない、化けの皮を
はがすとただのC厨程度のレベルの低脳しかいないケースが多すぎる。
C++ができるといえば周りが高く評価されると思い込んで背伸びをしているC厨が多すぎる。
こいつらこそ抵抗勢力だ！　こいつらがもっともタチが悪い！

いまこそ

　　C++厨に

　　　　喝　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　　ー　ー　！！！！！！！

909 ：仕様書無しさん：03/10/26 14:08

>>908
こらタケシ！こんなところで油売ってないで早くウチの仕事手伝うんだよ！

910 ：仕様書無しさん：03/10/26 14:40

>907
俺は897じゃないけど...

ファイルフォーマット　→　クラス
ファイル　→　インスタンス
バッチのスクリプトやプログラム　→　メソッド

という風に考えればバッチシステムをOOなシステムと捉え直すこともできる。

911 ：仕様書無しさん：03/10/26 15:57

>>910は自分がOOを全く理解していない事を自ら暴露してしまった。

912 ：910：03/10/26 16:08

>911
そう思うならもっと有意義な批判を書いてくれよ。

913 ：仕様書無しさん：03/10/26 16:39

>910 データと処理が分かれちゃったらオブジェクトじゃないじゃん・・・

914 ：仕様書無しさん：03/10/27 13:19

>>912
ただの釣りだろ。
こういう椰子は事実はどうであれ
キチッとした説明なんて出来やしない。
ハナクソ見たいな情報しか持ってないくせに
人をいたずらに混乱させるだけだから
適当に無視しとけ。

915 ：仕様書無しさん：03/11/01 15:30

Javaの哲学嫁

916 ：仕様書無しさん：03/11/01 17:15

読むなあんなの

917 ：仕様書無しさん：03/11/01 19:46

YO!!YO!! ２ｃｈではえらそーなこと言っているが YO!!
現実はgrep一発で継承したコード探せなくて
ぶち切れてるんだろ。お前ら。 YO!!

918 ：仕様書無しさん：03/11/01 22:35

Java Philosophical Wife

919 ：仕様書無しさん：03/11/05 08:00

>>911
誤爆か？それとも真性のKittyか？910のどこを見たら俺がOOP
を理解してないように見えるんだ？10年以上前からC++してるし、
Javaは20年前から使ってる。巻かれるという意味なら巻かれ
まくってるし、むしろ俺が巻いてる方でもあるわけだが。

920 ：仕様書無しさん：03/11/05 09:32

>>919
誤爆か？それとも真性のKittyか？910のどこを見たらあんたがOOP
を理解しているように見えるんだ？Javaが20年前からあるだって？
正気か？そろそろあんた自身の現実と戦ったほうがいいぞ！

921 ：仕様書無しさん：03/11/05 14:58

>>920
仕事の合間のティータイムに「ＪＡＶＡティーを愛飲してるゾ」という話かも？

922 ：名無し＠沢村：03/11/05 19:52

プログラマーの英語力はどれくらいですか？
ポインタってそんなに難しいの？
オブジェクト指向を理解できんとが何で悪いとや？

おまいらよ、おまいらにとって、英語、ポインタ、オブジェクト指向は、鬼門らしいな。
まあ英語はＰＧだけでなく、日本人全体にとっての鬼門だけどな…。
日本人は、英語を覚えられないだけでなく、ひとつの分野で一人前になるための鬼門を超えることができないということだな。

923 ：仕様書無しさん：03/11/05 20:54

>>920
うちのじいちゃんは６０年前にJAVAで戦ってましたがなにか？

924 ：仕様書無しさん：03/11/05 21:06

>>919
第二種頭のおかしい人認定
20年前にJavaはない

925 ：仕様書無しさん：03/11/05 21:21

>>923
背後から味方に撃たれて戦死したって奴か？

926 ：仕様書無しさん：03/11/05 21:55

カウントダウン開始age

927 ：仕様書無しさん：03/11/05 22:18

910です。
わかる人だけ共感するなり失笑するなりしてくれればいいですよ。
他にも、

コピペはプロトタイプベースのオブジェクト指向

なんてネタもあるっす。

928 ：仕様書無しさん：03/11/05 23:07

１００歩くらいゆずって >>910 はいいとして、
>> 927 はかなり間違ってるぞ。
コピペはほぼ完全な複製だが、プロトタイプベースは名前にもあるように
複製は最小限にとどめてあとは委譲でそれに代えるのがミソだ。
昔あった発行と引用（publish-subscribe）、あるいは
ファイルシステムがらみならシンボリックリンクとかなら分からんでもないが…。
こりゃ、>>910 も推して知るべしだな…。

929 ：仕様書無しさん：03/11/05 23:08

旧石器時代の地層からFortranの参考書が発掘されました

930 ：仕様書無しさん：03/11/05 23:25

再び910です。
>928 わかってる人からの突っ込みだ

実際にコードの複製をやっちゃうから台無しなわけですが、そこを無視して
差分だけ実装してるとイメージしてみると、そういう捉え方も可能かなという妄想ですよ。

931 ：910：03/11/05 23:35

いや、やっぱりプロトタイプベースを持ち出したのはズレてるな。撤回します。

要は、オブジェクト指向言語とかの機構ってのは、普段力技でやっている
テクニックを論理的にサポートしているのかもしれんなぁ、というこってす。

932 ：仕様書無しさん：03/11/05 23:53

まず>910のヨタを反省しろよ

933 ：910：03/11/06 00:02

ヨタかもしれんが、間違っているとも思わん。

934 ：仕様書無しさん：03/11/06 01:46

>>930
なんだ、“コード片の”コピペか…。それなら分からんでもない。

935 ：仕様書無しさん：03/11/06 02:00

>>934 ベースをコピーしてくるか、ベースに追加するかの違いはあるけど、
大昔話題になった「差分的プログラミング」ってやつの発想に近いかもね。

936 ：OOPビギナ：03/11/07 14:35

>>931
>>935
確認事項有り。それって「継承」のことですよね。

937 ：仕様書無しさん：03/11/16 02:07

ＵＭＬモデリングツールのの研修（２日間）に行って操作を習いました。
そしたら、今度、オブジェクト指向設計について説明せよと業務命令がくだりました。
どーも、ツールを使えばオブジェクト設計になると勘違いしてるようです。
必死で、「研修は某製品の使い方を教えてもらっただけなの」と言っても理解してもらえません。
おいらは、派遣なのですが、そろそろ、脱出計画をたてるべきでしょうか。
上流工程は思いっきりデータ指向設計をしてるみたいですが。

938 ：仕様書無しさん：03/11/16 02:24

IT業界にアージャイル開発とデザインパターンを広めよう！

C言語を使ってかなり苦労したので
その苦労を最小限におさえるために
アージャイル開発、デザインパターンを
多くのプログラマに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

デザインパターンを使うこと、アージャイル開発することが
プログラマの習慣、常識になってほしい。

なんとか、デザインパターン文化、アージャイル開発文化を押し広げられたら・・・。

IT業界の将来はオブジェクト指向とアージャイル開発が握っています！

939 ：仕様書無しさん：03/11/16 02:28

>>887
HTMLソースに文字コード指定が無いっ！
　ちゃんとEUC-jpとかけ

940 ：仕様書無しさん：03/11/16 10:04

>>937
「説明できません」だけでは納得しないって事か。
少なくとも下から
・UMLだけ
・設計方法論（OOD）とUML
・プロセス方法論とUML
の三種の導入レベルがあると説明しても駄目か。
これを判るように説明したら（まともな組織なら）評価が上がるぞ。

941 ：オブジェクト指向促進運動：03/11/16 15:05

942 ：いなむらきよし：03/11/16 16:29

キケー！

943 ：仕様書無しさん：03/11/30 04:33

ごりゃー、もまいら（ＳＥ四人）、画面の設計しかせんくせに、
おいらに、クラス設計をしろだと（ＰＧ一人）。あほぅですか。

また、デスマが生まれつつあります。

おまけに、派遣会社は約束の報酬満額払ってくれません。
とりあえず、来週は業務中止して、ごねます。

944 ：仕様書無しさん：03/11/30 13:26

ぜいたくなやつだな。
画面の設計すらしないＳＥもいるってのに

945 ：仕様書無しさん：03/11/30 13:50

>>943
指示するアホゥに、指示されるアホゥ。
同じアホゥなら、ヨ～イヨ～イヨ～イヨ～イっと。

946 ：仕様書無しさん：03/11/30 20:13

オブジェクト指向を理解できないなら、退社しろ、馬鹿上司。
おまえの言ってることは、何から何までデータ指向だ。ぼヶ。
それで、俺の年収の４倍か。もうだめぽ、、、、、

947 ：仕様書無しさん：03/11/30 20:25

うめるということ

５年４組　坂崎竜太

ぼくはうめるということが大好きです
いらなくなったスレとかをうめます
スレっていうのはスレッドのことです
他にもいらなくなったものはうめることにしています
スレッドじゃないものは土にうめます
スレッドの他にうめたのはノートとかブロッコリーとか
いもうととかです
土をほるのが楽しいです
ほった穴にうめるものを投げるのが楽しいです
入れたものに土をかぶせるのが楽しいです
うめ終わった後はぼくしか知らないヒミツが
できたみたいでわくわくします
これからもいろんなものをうめたいと思います

おわり

948 ：ok：03/11/30 20:32

◎７２５４最新情報◎
http://homepage3.nifty.com/hot-hot/7254.html

949 ：仕様書無しさん：03/11/30 20:54

埋め

950 ：仕様書無しさん：03/11/30 21:13

>>947
大変良く出来ました。
おばあさんやおじいさんも動けなくなっていたらうめましょう。
いもうとは、うめる前に先生のところに連れてきてほしかったです。
おねえさんがいたらうめる前に先生のところに連れてきてください。

951 ：オブジェクト指向普及活動！：03/12/07 13:01

どこかの日本人が欧米人に劣ってオブジェクト指向に弱い理由はこれだっ！

http://homepage3.nifty.com/Aransk/contents1.html
日本人は哲学的思考、論理学に弱い。
物事を関連付けするのが苦手で、全て同じレベルで並列共存
させる。そこで実は「哲学的思考と論理性に秀でたFSHISOの
皆さん方」にプログラム言語の仕組みを理解して頂いたら、これは
鬼に金棒ではないか！・・・とまあ「愚考」した訳ですよぉ。
どこが愚考か胸に手を置いて考えて頂ければすぐお分かり
ですよね。敢えて指摘は致しません。（笑い）

だが、かといって日本人だからオブジェクト指向は理解しなくてもいいと言って怠けることは
絶対に許されないことだぞ！！

オブジェクト指向を理解できない愚か者を教育しろ！
理解できるまで教育しろ！
理解しようとせずオブジェクト指向に批判的なものに対しては戦え！
戦って勝利を勝ち取ってでもオブジェクト指向教育を与えろ！
オブジェクト指向を普及させるデモ行進をしろ！

オブジェクト指向を普及させろっ！　オブジェクト指向を普及させろっ！

952 ：仕様書無しさん：03/12/07 16:27

>>951
>ガーベージコレクションなんて
>不要です。本来メモリー管理はプログラマーの責任です。

この一文で読む気なくした

953 ：仕様書無しさん：03/12/07 16:36

>>1
アージャイル開発もできない愚か者には死を！
http://pc.2ch.net/test/read.cgi/prog/1070781553/

954 ：仕様書無しさん：03/12/07 16:37

オブジェクト指向を理解できないと、会社が潰れる罠

955 ：仕様書無しさん：03/12/07 16:38

おれは全く関係ないがな

956 ：仕様書無しさん：03/12/07 16:41

>>952
やさしいんだな。

俺は怒りに震えたぞ。

957 ：仕様書無しさん：03/12/07 16:50

>>952
ガベコレ無いと嫌な人って何やってプログラム組んでるの？
俺の場合newと対応したdeleteは必ず同じクラスに置くから。
単純な書き忘れならメモリリークの警告がでるし、ガベコレなんかなくてもこまらねーよ？

958 ：C++忠 ◆IvraPLuPLU ：03/12/07 16:55

>>957
C++にはコンストラクタとデストラクタの
連携があるのでさほどGCを必要と感じないんでしょうね。

いちばんベストなのはオプショナルにGCの使用を選べる事だと思うのですが。

959 ：仕様書無しさん：03/12/07 16:57

>>957
お前が難しいモデルを実装した経験がないだけ。
なんならガベコレ無しでしっかりメモリ管理ができる
Lisp を実装してみろ。

960 ：仕様書無しさん：03/12/07 16:59

GCよりGCの間接的な利点である不正なメモリへの読み書きが
防げる方がもっと重要だよ。

ライブラリでエセGCを実現しているC++は不正なメモリへの
読み書きが出来てしまうからだめだね。

961 ：仕様書無しさん：03/12/07 17:03

>>958-959
Windowsのソフトしか組んだこと無いからメモリ管理なんか気にしたことないんだけど。
少なくともあんまり特殊なソフトを作らない限りそんなものっていらないよね？
結局、メモリの管理もしてくれない駄目なＯＳがのってる環境だとガベコレが必要になるわけ？

962 ：仕様書無しさん：03/12/07 17:06

>>961
お前、mallocって知っているか？ newって知っているか？
動的にメモリ確保すること知っているか？

963 ：仕様書無しさん：03/12/07 17:09

ガベゴレをつくらなくてはいけないのは、ガベゴレがヘタクソにできあがっている
処理系とか、セグメントアクセスを考慮にいれなきゃいけないデバイスの作成とか
かね。　いまのところ必要ねぇけど。

964 ：961=957：03/12/07 17:10

>>962
いえ、ですから、newでクラス作ってdeleteで消すだけですよ。
基本的にnewで作ったクラスで必ずdeleteするという規則で
プログラムを組んでいます。
現状これでこと足りるわけですよ。
環境がWindowsなので。

965 ：C++忠 ◆IvraPLuPLU ：03/12/07 17:10

>>961
Windowsでもメモリ管理は重要ですよ。プロセス内部でどうメモリを使うかの問題なので
あまりOSは関係ないと思います。
GCがあるといいなと思うのは>>959さんの言うように複雑な物(循環参照や解放の責任が点々とするようなもの)を
作らなければならないときですね。
ただGCありの言語だとメモリ以外のリソースへの関心が薄れてしまわないかが心配です。

966 ：仕様書無しさん：03/12/07 17:12

>>964
だからね。ここでメモリ管理と言っているのは
newの話も含めているの。
あんた、一つレベルがずれてるよ。

967 ：仕様書無しさん：03/12/07 17:13

そんなに破棄が気になるんなら、
std::auto_ptr<class*> object(new class)
でいいやん。

968 ：仕様書無しさん：03/12/07 17:13

>>963
こいつはもっとずれてる。まず話に追いついてくれ。

969 ：仕様書無しさん：03/12/07 17:14

{
std::auto_ptr<class> object(new class)
object->x = pppp ;
}

970 ：仕様書無しさん：03/12/07 17:14

>>962
何も知らない初心者なんだろ。

メモリ管理ごときに人間様が神経を使う必要はひとかけらも無い。

>>961は早く気付いて周りに迷惑かけないようにしろよ。

971 ：仕様書無しさん：03/12/07 17:14

＞Windowsのソフトしか組んだこと無いからメモリ管理なんか気にしたことないんだけど。

Windowsだからこそおおいに気にしないとまずいと思う。

972 ：仕様書無しさん：03/12/07 17:16

>>967
それも一種のGC。GCが不要といっている奴はそれも不要なんだろうね。
ただそれは言語に統合されてないから、不正なメモリアクセスは出来ちゃうし、
それを使うのを忘れれば、やっぱりメモリリークしちゃう。
結局注意しなければいけないわけでプログラマの負担は完全になくならない。

973 ：仕様書無しさん：03/12/07 17:17

>>957 が作れるような単純なモデルのアプリなら、確かにいらないかも知れない。
だからといって、
「ガベコレ無いと嫌な人って何やってプログラム組んでるの？」
と言い張るのは世間知らずといって笑われるだけだ。

たとえば、足し算・引き算しかしないプログラムしか作ったことのない奴が
「動的なメモリ確保ができないと嫌な人って何やってプログラム組んでるの？」
って言っていたら、お前どう思う？

974 ：仕様書無しさん：03/12/07 17:18

じゃ、new と delete のオペレータをオーバーライドして、
allocator<T> もついでに書き換えればいいじゃないか。

975 ：仕様書無しさん：03/12/07 17:21

new と delete を性的な領域に置き換えればいいじゃないか。

976 ：仕様書無しさん：03/12/07 17:22

>>965
>あまりOSは関係ないと思います。
でも、私の環境の物理メモリは512MBしかないんですけど、
何故か1250MBまで使えます。
これってやっぱりＯＳがメモリを管理してるってことですよね？
一気に自分で確保してもやっぱりWindowsが管理してる（管理してくれてる）わけですよね？
（まとめてとっているようにみえるが実はＯＳがそのように見せているだけ）
私はWindowsがメモリをどのように管理しているのかそもそも知らないので
この状態で自分でどうこうやるってのはそもそも無駄だと思っています。
し、それを詳しく知っている人にあったことがないのでこういう状態です。

>複雑な物(循環参照や解放の責任が点々とするようなもの)を作らなければならないときですね。
これは当たったことがないので当たってみないとわかりませんね。

977 ：仕様書無しさん：03/12/07 17:23

>>973
本当に複雑でなければならないプログラムは少ない。
複雑になっているのは設計がクソなだけな場合が多い。

978 ：仕様書無しさん：03/12/07 17:24

>>976

＞物理メモリは512MBしかないんですけど、
＞何故か1250MBまで使えます。

仮想記憶って概念を知っているか？
ちょっとイタすぎるぞ

979 ：仕様書無しさん：03/12/07 17:26

>>976
ＦＭ－ＴＯＷＮＳの時代までタイムマシーンですっ飛んでいけば可能かと。

980 ：仕様書無しさん：03/12/07 17:26

>>976
は
Ｖ
Ｂ
房

981 ：仕様書無しさん：03/12/07 17:27

ＦＭ－ＴＯＷＮＳ　は、ＲＡＭ－ＤＩＳＫはあるけど、ＤＩＳＫ－ＲＡＭは
たしかなかったはずだ。

982 ：C++忠 ◆IvraPLuPLU ：03/12/07 17:27

>>976
あまりお話の意図が伝わってこないのですが、
MPUやOSが管理してくれているメモリのレベルと
各プロセスが自分の為に割り当てられたメモリをどう管理するかというのは
基本的に別次元の話ですね。
昨今の環境ならば別プロセスのメモリは保護されているのが普通ですので、なおさらです。

983 ：976：03/12/07 17:29

>>978
>仮想記憶
知らないです。
これって掻い摘んでいうとどうなってるわけですか？

984 ：仕様書無しさん：03/12/07 17:31

知らないのか･･･　足りないメモリのために、セグメントをディスク上に展開することを言うのだよ。

985 ：仕様書無しさん：03/12/07 17:32

>>983
>知らないです。
そういう態度は恥ずかしいことだとまず知りましょう。

>これって掻い摘んでいうとどうなってるわけですか？
まずはここからね。

http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=%E4%BB%AE%E6%83%B3%E8%A8%98%E6%86%B6

986 ：仕様書無しさん：03/12/07 17:35

ちなみに、セグメントを多岐に展開しているＯＳをマルチセグメントモデルという。
32ビットモデルで最大４Tバイトの仮想記憶空間を利用できるのだよ。

987 ：976：03/12/07 17:38

>>982
>各プロセスが自分の為に割り当てられたメモリをどう管理するかというのは
>基本的に別次元の話ですね。
>昨今の環境ならば別プロセスのメモリは保護されているのが普通ですので、なおさらです。
各プロセスってなんですか？
割り当てられたメモリっていうことはアプリケーションごと使えるメモリって決まってるってことですか？

>>984
>足りないメモリのために、セグメントをディスク上に展開することを言うのだよ。
そーの辺はなんとなくわかるのですが、問題はその構造です。
足りないメモリのために一度ディスク上におくという動作ってやっぱり
物理メモリとハードディスクにおいてあるメモリといっしょに管理しますよね。
その全権を握っているのがＯＳだと考えてるわけですが違うのでしょうか？
物理メモリ上で連続した領域とアプリケーションから見える連続した領域って
同じものなのでしょうか？

988 ：C++忠 ◆IvraPLuPLU ：03/12/07 17:44

>>987
プロセスはおおまかに言うと一つのアプリケーションみたいなものです。
普通のOSはプロセス単位でメモリを管理します。

ぶつ切りの物理メモリを連続したメモリに見せかけたりしてくれる仕事は
MPUがしてくれます。

申し訳ないのですが、多分ここで逐一説明してもきりがないです。
興味があるのなら本やウェブで調べた方が身になると思います。

989 ：仕様書無しさん：03/12/07 17:45

物理メモリの効率を良くしたいなら、メモリを大量に積んで、ＯＳの仮想メモリ
を０バイトにすれば、うまく行くんじゃないだろうか？

990 ：仕様書無しさん：03/12/07 17:49

>>959
GCなかったごときで難しいモデルとは笑い門だな(嘲笑激藁ファック

991 ：仕様書無しさん：03/12/07 17:50

>>988
大変ためになりました。
ありがとうございました。
個々で知ったキーワードなどを元に自分でも調べてみます>ALL

>>989
それはとんでもなく時間がかかるのでは？

992 ：仕様書無しさん：03/12/07 17:51

ときどき、GCのおかげでJavaではメモリ開放を手動でできないと
勘違いしている馬鹿がいることにウンザリ

993 ：仕様書無しさん：03/12/07 18:05

道具は便利になる(=進化する)べきだよな。

GCがあれば解放の心配しなくてすむわけだし。
ただ、GC処理を作る人にとってはメモリ解放のタイミングが難しいだろうけども。

994 ：仕様書無しさん：03/12/07 18:14

>>990
GCなかったごときで難しいモデルとは笑い門だな(嘲笑激藁ファック

すまん、誰かこれを日本語に翻訳してくれ。

995 ：仕様書無しさん：03/12/07 18:18

>992
一般プログラマのレベルではSystem.gc や finalize が宛にならないと知っているだけで充分だろう
手動でメモリ管理されたほうが迷惑

996 ：仕様書無しさん：03/12/07 18:34

>>994
よし！　俺様は日本語に訳してやるっ！

GCなかったごときで難しいモデルとは笑い者だな(嘲笑激藁ファック

997 ：仕様書無しさん：03/12/07 18:35

>>993
> 道具は便利になる(=進化する)べきだよな。
>
> GCがあれば解放の心配しなくてすむわけだし。
> ただ、GC処理を作る人にとってはメモリ解放のタイミングが難しいだろうけども。
意味わかっていってんの？
Javaでの手動によるメモリ開放方法は
java.lang.ref.Referenceをつかうんだよ。

998 ：仕様書無しさん：03/12/07 18:37

ニンテンドーゲームキューブがないごとき難しい型式とは笑い者だな(嘲笑激笑性交

999 ：仕様書無しさん：03/12/07 18:38

で次スレは？

1000 ：１０００：03/12/07 18:38

やったーまんこーひーらいたー！

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。