オブジェクト指向は戦場では必要なし６

1 ：あたたたた：02/08/14 12:51

　オブジェクト指向はより自然なモデルに即したものではあるが、クラス
を理解する労力が大きく、目的まで達成するのに時間がかかる。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまでちゃ
んと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よってオブジェクト指向は戦場では使いものになりません。

前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1011997945/
前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013266554/
前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013875413/
前前スレ http://pc3.2ch.net/test/read.cgi/tech/1021468476/
前スレ http://pc3.2ch.net/test/read.cgi/tech/1027983898/

　つい先日スレを立てたばかりなのに、あっという間にみなさんの
意見で前スレが終了してしまいました。やはりオブジェクト指向は
現場では使えないという説が真実であるがゆえにこれだけ反響が
大きいのではないかと思います。
　オブジェクト指向プログラマの方には大変受け入れるのに苦しい事実
だとは思いますが、やはりオブジェクト指向は戦場で使うには、リスクが
大きい、または使えない技術と認めざるを得ない事実なのです。

2 ：デフォルトの名無しさん：02/08/14 12:52

もういいだろう

OOが最高で。

3 ：デフォルトの名無しさん：02/08/14 13:25

2Chらしいスレだよね。
世間では相手にもされないのが、2chでは大多数の意見に見えるってな。

4 ：デフォルトの名無しさん：02/08/14 13:55

OO厨へのメッセージがある。
ttp://dempa.2ch.net/misc/R3_temp.swf?inputStr=%83I%83u%83W%83F%83N%83g%8Ew%8C%FC%82%CD%90%ED%8F%EA%82%C5%82%CD%95K%97v%82%C8%82%B5

5 ：デフォルトの名無しさん：02/08/14 14:34

>>4
もうルパンは飽きた。二度とやらないように。

6 ：デフォルトの名無しさん：02/08/14 14:38

>>5
それで本当にもう二度とやらなくなるぐらいなら
アンチ厨なんてもうとっくに絶滅してると思うが…

7 ：デフォルトの名無しさん：02/08/14 14:41

～　糸冬　了　～

で終わってるスレを見たことないのと同じだな

8 ：デフォルトの名無しさん：02/08/14 14:42

>>6
いやこんな技術板にくる族なんだから、案外それで止めると思うよ
ただ、次々伝染するように現れるだけで

9 ：デフォルトの名無しさん：02/08/14 14:59

書き込みの70%はOO厨で
この人達がスレを盛り上げています

10 ：いつでもどこでも名無しさん：02/08/14 15:00

ここを見て世間のレベルが低いと勘違いしてしまう罠。

11 ：デフォルトの名無しさん：02/08/14 16:04

>>10
誰が？

12 ：デフォルトの名無しさん：02/08/14 16:06

>>10
2ch ＝世間と思いこむ奴に勘違いされても一向に構わん。

13 ：デフォルトの名無しさん：02/08/14 19:50

すげー。このすれ part 6 まで進んだのか。

（とりあえず、手元ではスレごと透明アボーンしておこう）

14 ：逝って良しの１：02/08/14 20:28

サヨみたいなカキコだな。

２ＣＨの書きこみは情報操作されていない日本の生の声だ。
日経とは違うのだ。

15 ：逝って良しの１：02/08/14 20:37

真面目に議論を進めようとしてもＯＯ厨が妨害してくるんじゃねーか。

ＯＯに対する態度のタイプを分類すると

１）ＯＯは生産性が悪い。
２）ＯＯは生産性が良い。
３）生産性が良かろうが悪かろうがＯＯ厨。
４）ＯＯＰＬ勉強したけど組めなかった。
５）ＶＣ＋＋で挫折したヘタレがＪａｖａでＧＵＩを出せたのでＪａｖａ厨。
６）とりあえず金貰えるからいいんじゃない？俺は使わないけど。
７）ＯＯとクラス指向を混同しているＯＯ厨。

16 ：デフォルトの名無しさん：02/08/14 20:48

生産性じゃなくて保守性が良いじゃねーの？
おれはそのスタンスだが。

17 ：逝って良しの１：02/08/14 21:25

ここで言う生産性＝保守コスト含む

18 ：デフォルトの名無しさん：02/08/14 21:39

>>15
> ３）生産性が良かろうが悪かろうがＯＯ厨。
これは厨というよりも信者だと思う。

> ６）とりあえず金貰えるからいいんじゃない？俺は使わないけど。
このタイプは存在しても議論には参加しそうにないからいいんじゃないの？

19 ：デフォルトの名無しさん：02/08/14 21:52

俺はOO批判してる奴は
OOの事わかってない奴だと思うんだけど、
OOがわかってて、批判してる奴がいるなら
そいつの意見はしっかり聞きたいよ

20 ：デフォルトの名無しさん：02/08/14 21:54

OOって言いたいだけちゃうんかと。

21 ：デフォルトの名無しさん：02/08/14 22:07

私はOOは判らない。　この技術は扱いが難しく、そして積極的に使うものではないと思っていました。

あるとき、私はご宣託を受けました
　その宣託の内容を確かめる為に多くの２チャンネラーに聞きました
　そして、私はOOが判っているという人の多くの議論は浅く
　わたしごときに簡単に論破されるのです。

そして私はご宣託の真意を理解しました。　
OOが難しく、判らないという事を知っている点において
私が最もOOを理解していたという事を

22 ：デフォルトの名無しさん：02/08/14 22:09

OOを分かってる奴が設計してOOを分かってる奴がOOPLで
コーディングしたシステムは可読性、メンテナンス性、拡張性等の点で
従来の手法(C等の手続き指向とか)よりも高品質になるのは
誰もが認めるところだろう。システムの規模が大きければ大きくなるほどね。
小さなシステムだとOOの方が冗長になることもあるが
プログラムの可読性やメンテナンス性、拡張性を優先するならOOだろう。

ただ、これは開発陣がOOを分かっているという前提での話。
そしてOOをきちんと理解するには手続き指向よりも難しい。

しかしMicrosoftが.NETFrameworkでオブジェクト指向マンセーを
打ち出してきたため近い将来.NETがWin環境下での開発の
デファクトスタンダードになることが予想され、さらに
マルチプラットフォーム環境下での開発はJavaがデファクトスタンダードに
なりつつある現実を見るとOOの体得は必須になるだろう。

別にOOマンセーって言ってるわけじゃない。
現時点でソフトウェア開発の有力な手法のひとつなんだから
うまいこと利用しようよってだけ。
賛成とか反対とか低レベルなことで議論しないで
もっと前向きにいこうや。

23 ：デフォルトの名無しさん：02/08/14 22:12

>>22
それって前向きじゃなくて後ろ向きじゃないか？

24 ：デフォルトの名無しさん：02/08/14 22:15

うん。　出来合いのもの使う為になんて、まるで単なる労働者だね

25 ：逝って良しの１：02/08/14 22:31

19みたいに、過去に何度も書いているのにリセット技を使って
議論を撒き戻す卑怯者は無視。

>>22
再利用性、メンテナンス性、可読性、拡張性は言語に寄らず、
プログラマーの才能に寄る。
言語によらない。

26 ：g：02/08/14 22:32

-------風俗の総合商社・ＭＴＴどこでも-------

〇デートクラブ〇女性専用ホストクラブ〇
〇ハードＳＭ奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種！
●楽しく遊べます！　090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
　 http://www.mttdocomo.jp/
-----女性アルバイト随時募集・高収入（日払い）月100万円可能住み込み可
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
http://www.mttdocomo.jp/
------------------------------------------------

27 ：逝って良しの１：02/08/14 22:34

＞マルチプラットフォーム環境下での開発はJavaがデファクトスタンダードに
＞なりつつある現実を見ると

しまった、ネタだったか・・・。

28 ：逝って良しの１：02/08/14 22:42

８）頭の良い一発屋
　頭の良い一発屋はJava普及の初期までにセミナーやら本やらフレームワーク
　やらで適当に儲けて逃げちゃった

９）頭の悪い一発屋
　頭の悪い一発屋は詐欺るにもＯＯの習得に時間がかかってしまい、
　まだ勉強中。今さらブームを延命しようとする。

29 ：デフォルトの名無しさん：02/08/14 23:17

このスレ、一向に具体的な話しにならんな。

30 ：デフォルトの名無しさん：02/08/14 23:25

前スレでは、STLやVCL等の便利なライブラリがオブジェクト指向
を用いて作られていることが証明されました。
つまり、OOには利用しやすい便利なコードを作る能力があると
いうことです。
これは、オブジェクト指向の有用性を証明したものでしょう。

31 ：デフォルトの名無しさん：02/08/14 23:29

なんでSTLとVCLが同一ラインで語られてるんですか？

32 ：逝って良しの１：02/08/14 23:32

いくつかのＯＯ本に書いて有る事がデタラメなのは論を待つまでも無く
事実なので置いておく。

ＯＯが生産性でダメな証明
もし、ＯＯで生産性が上がるのなら、
ＯＯＰＬ採用会社は非採用会社より高い生産性を持っているはずだ。
そして市場原理によりＯＯＰＬ採用会社は非採用会社を駆逐していなければ
ならない。
現状でそのような事実は観測されていない。
よって
１）ＯＯＰＬは生産性の向上に寄与しない。
２）ソフトウエアは市場原理に従っていない。
のどちらか、あるいは両方である。

33 ：デフォルトの名無しさん：02/08/14 23:40

２）はこの業界の（以下略

34 ：デフォルトの名無しさん：02/08/14 23:47

このスレまだやってんのかよ…

35 ：デフォルトの名無しさん：02/08/15 00:02

>>31
アホだからだよ。

36 ：デフォルトの名無しさん：02/08/15 00:02

まあ、なんだな。
1はOOについていけなくて悔しいからOOを憎んでいるのは
痛いほど分かるんだが、痛すぎて見ているのが辛いよ。
そろそろスレ立てるのやめろや。

37 ：デフォルトの名無しさん：02/08/15 00:03

ＯＯＰＬ採用する前にＯＯＰＬマンセーのプログラマが必要。
だれでも分かることだと思うけど(藁

38 ：逝って良しの１：02/08/15 00:17

＞ＯＯＰＬマンセーのプログラマ

んなもんは掃いて捨てるほど居ます。

39 ：デフォルトの名無しさん：02/08/15 00:19

ＯＯＰＬマンセーのプログラマだけがいる会社は少ない。

40 ：デフォルトの名無しさん：02/08/15 00:20

で　OOPLを採用していない今時の開発ツールって何？

そりゃ4ビットマイコンじゃ使わないけど

41 ：逝って良しの１：02/08/15 00:33

ＯＯ派の質が急激に落ちております。

42 ：デフォルトの名無しさん：02/08/15 00:34

今市場では
OOPLを採用している会社ばかりです。

43 ：デフォルトの名無しさん：02/08/15 00:35

>>31
両方オブジェクト指向を使っているからです。

44 ：デフォルトの名無しさん：02/08/15 00:37

>>43
そんなこと言ってるからアホだからですとか言われちゃいます。

45 ：デフォルトの名無しさん：02/08/15 00:38

>>32
じゃあ例えば、ビジネスソフト市場見てみようか。
MFCやDelphiばかりだね。
よって、OOPL採用会社に非採用会社が駆逐されてるね。

46 ：デフォルトの名無しさん：02/08/15 00:38

>>44
いや、話の流れとしては何もおかしくない。

47 ：デフォルトの名無しさん：02/08/15 00:41

>>45
パッケージのアプリケーションがソフトウェア業界のどれくらいの割合を占めているか知っての発言か？

48 ：デフォルトの名無しさん：02/08/15 00:45

コネがすべて。

以上。

49 ：逝って良しの１：02/08/15 00:46

>>45
「ＭＦＣプログラマー＝ＯＯ使い」説が提示されました。

Delphi・・・・・・・・・・・・・・・・・・・・

50 ：デフォルトの名無しさん：02/08/15 00:47

>>48
なんかすがすがしかった。

51 ：逝って良しの１：02/08/15 00:48

つうかwinだと他に環境無いし、駆逐されたんじゃなく、最初から無いのでは？

52 ：逝って良しの１：02/08/15 00:49

じゃあ市場原理なんか働いてないんだから生産性なぞ関係無いんで、
言語なんかなんでもいいじゃん？

つう結論？

53 ：デフォルトの名無しさん：02/08/15 00:51

>>51
いや、WinだとVCでAPIバリバリ使ってCを使う手があるぞ。

54 ：デフォルトの名無しさん：02/08/15 00:52

>>51
VBがあります。

55 ：デフォルトの名無しさん：02/08/15 00:53

Delphi=「Object」 Pascal

56 ：逝って良しの１：02/08/15 01:05

>>54
そのとうりですた。つい・・・
>>53
殆どのＶＣ＋＋プログラマはそれでしょう。
特にＭＦＣプログラマは何で動いてるのか判ってなくても組めるし。
ＯＯ以前だし。
>>55
Delphiって実務で使われてるの？それともやっぱネタ？

57 ：デフォルトの名無しさん：02/08/15 01:23

MFCプログラマとDelphiプログラマは明らかにOOPLを使ってるが…
これをOOPLを使ってるといわないなら一体>>32のOOPLとは何を
指してるのか。

58 ：デフォルトの名無しさん：02/08/15 01:23

> Delphiって実務で使われてるの？それともやっぱネタ？

使ってるところあるよ。
ちなみに需要も少ないが供給はもっと少ないんで、
意外と仕事はあるらしい。

59 ：デフォルトの名無しさん：02/08/15 01:24

>>57
squike

60 ：デフォルトの名無しさん：02/08/15 01:26

>特にＭＦＣプログラマは何で動いてるのか判ってなくても組めるし。

何言ってんの？
MFCプログラマはAPIしか使えない奴の上位互換だよ :)
MFCでアプリくめるヤシは、API挙動もMFCの構造も
熟知している場合が殆ど。

61 ：デフォルトの名無しさん：02/08/15 01:27

Delphiは実務で使うよ、仕事もたまに来る。
勿論、コンシューマ向けじゃないけどね。

62 ：デフォルトの名無しさん：02/08/15 01:28

>>59
squeakはsqueakでOOPLで良いけども、C++やObjectPascalは一般的には
OOPLなわけで。
これを認めないと、>>32は非常に変なずれてる定義でしゃべってることになる。

63 ：デフォルトの名無しさん：02/08/15 02:08

>>62

逝って良しの１が変でずれてるのはいつもの事でしょ。

64 ：逝って良しの１：02/08/15 02:08

>>60
MFCプログラマから入った奴は他のシステムに移行出来ないっていう話
知らないの？

65 ：デフォルトの名無しさん：02/08/15 02:18

>>64
なんか話が変わってるが。
>>56でそんなこと言ってないじゃん

66 ：デフォルトの名無しさん：02/08/15 02:25

MFC使ったDLLを作る方法と、
そのDLLをCで作ったアプリから呼び出す方法教えて。

67 ：逝って良しの１：02/08/15 02:31

なんで動いてるのか理解しているなら、他のシステムへの移行も容易だって事。
移行出来ないのは判ってない証拠。

68 ：デフォルトの名無しさん：02/08/15 02:32

>>67
同意。

この処理系でSTLは使えないので私には開発できません。
とかほざく奴とか頭大丈夫かと思う。

69 ：デフォルトの名無しさん：02/08/15 02:33

>>66
普通にそのまま作れば良いじゃん？
何も特別なことは無いよ？

70 ：デフォルトの名無しさん：02/08/15 02:34

話がずれてます。移行の話はしてません。

71 ：デフォルトの名無しさん：02/08/15 02:35

>>67-68
普通に考えて、STLでもなんでも、それについて
知ってれば知ってるほど、他へ移行したくないものだ
と思うが。移行できないんじゃなくて。

72 ：デフォルトの名無しさん：02/08/15 02:36

>>69
普通って、どこの普通ですか？
作り方が解りません。
MFCアプリをそのままモジュール化してDLLにしたいんです。
つまりMFC使ってる部分を隔離したいんです。

73 ：デフォルトの名無しさん：02/08/15 02:37

>>72
新規プロジェクト→MFC(dll)で作れますが？

74 ：逝って良しの１：02/08/15 02:43

馬鹿は話の関連が掴めないから馬鹿なのです。

75 ：デフォルトの名無しさん：02/08/15 03:06

つまり逝ってよしの１ね

76 ：カイジ：02/08/15 03:19

ならお前がバカなんだ

77 ：デフォルトの名無しさん：02/08/15 03:42

バカと言うやつがバカ。

78 ：デフォルトの名無しさん：02/08/15 04:00

バカと言うやつがバカと言うやつが消防

79 ：デフォルトの名無しさん：02/08/15 04:12

バカと言うやつがバカと言うやつが消防が夏坊。
履歴：
>>76=バカ
>>77=消防
>>78=夏坊
以上！

80 ：デフォルトの名無しさん：02/08/15 04:51

>>79
頑張った君には厨房の称号をあげよう

81 ：デフォルトの名無しさん：02/08/15 09:52

>>67
つまり、OOPLに移行できない奴はわかってない奴ということか。
必ずしもそうとは言い切れないとは思うけどね。
扱ってる対象ドメインによってはOOPLじゃないほうがうまくいく場合もあるし、
OOPLわかっていてあえて移行しないやつもいる。

もっともアンチ厨でOOPLちゃんと理解した上でアンチしてる奴なんて見たことないけど。

82 ：デフォルトの名無しさん：02/08/15 10:20

>>72 C++の型保証用の名前の変形が働くので　隔離するには
extern "C" でラッパ関数を書いてゆく必要があるとは思います

そこらへん、DLLに型情報を早期に付けなかったMSの責任もあるのでしょうが　メンドクサイです

83 ：デフォルトの名無しさん：02/08/15 11:46

OOなんていらねーじゃん？違うか？

84 ：デフォルトの名無しさん：02/08/15 11:47

>>83
アホは黙ってな。

85 ：デフォルトの名無しさん：02/08/15 11:53

００って何？

86 ：デフォルトの名無しさん：02/08/15 11:57

OOPGに聞きたいけど非OOに比べてOOを使うメリットってあるのか？
マジで教えてくれ。

87 ：デフォルトの名無しさん：02/08/15 12:04

>>86
過去ログで気が遠くなる回数議論されているが。

88 ：デフォルトの名無しさん：02/08/15 12:08

>>86
ある。

89 ：デフォルトの名無しさん：02/08/15 12:15

>>88
その理由を教えてください。過去ログを読むとOO派も反OO派も
主観が強すぎてあまり参考にならないので、実際のところが知りたいのです。

90 ：デフォルトの名無しさん：02/08/15 12:16

>>89
それをわざわざ主観の強い両者に尋ねる頭の構造を疑うが。

91 ：デフォルトの名無しさん：02/08/15 12:16

>>82
MFCのdllはAFX DLLでしょ。
普通の非MFCアプリから使うのは普通は無理

92 ：デフォルトの名無しさん：02/08/15 12:46

>>86
　OOPGってなに？
　とりあえず、俺は戦場では必要無し派だけど、オブジェクト指向を習得しておく事は必要だと思うよ

理由は、
　１、他人とのコミュニケーション＝お話をする為には必要
　２、ドキュメントを読む時に必要
　３、他人のソースコードを読む為に必要
　４、コーデングの実現の為に選択肢を増やし、より効率的に仕事する為に必要

ただし、実務ではOOのオの字も言わないけどね

93 ：デフォルトの名無しさん：02/08/15 13:10

>>92
OOは戦場でも有効派の意見も聞きたいな

94 ：///：02/08/15 13:21

低レベルな職場では有効ではないって結論くらいはでてるだろ。

95 ：デフォルトの名無しさん：02/08/15 13:40

>低レベルな職場では有効ではないって結論くらいはでてるだろ。
OOは有用ではないということの裏返し意見のように読み取れるのは気のせい？

96 ：デフォルトの名無しさん：02/08/15 14:25

日本じゃ出番が無いところの方が多いってことじゃないのん？
アンチや古代人が啓蒙の妨害をするんで導入が難しいんで、
実績のあるところほど導入しづらい。

97 ：デフォルトの名無しさん：02/08/15 14:29

>>96
>アンチや古代人が啓蒙の妨害をするんで導入が難しいんで
OOが普及しない、または糞なのを人のせいにするのはヤメレ

98 ：デフォルトの名無しさん：02/08/15 15:04

思想は立派なんだけど実装が重いんだよ。

99 ：デフォルトの名無しさん：02/08/15 15:06

実装が重い？Javaの事か？

100 ：デフォルトの名無しさん：02/08/15 15:13

>>93
OOは銀の弾丸ではないよ。

戦場にしてしまうような糞SEと糞PGが集まった糞現場では
OOを使ったばかりに戦場を地獄にかえてしまうことが多い。
しかし、良質なSEと良質なPGが小数精鋭で継続的にやるんなら
とても有効な道具になる。

101 ：デフォルトの名無しさん：02/08/15 16:16

> しかし、良質なSEと良質なPGが小数精鋭で継続的にやるんなら
> とても有効な道具になる。
良質なSEと良質なPGねぇ。。。誰か突っ込んでやれよ。

102 ：デフォルトの名無しさん：02/08/15 16:18

>>101
取りあえず自分が無能だと自覚しなさいな。

103 ：デフォルトの名無しさん：02/08/15 16:23

そもそもさ、クラスライブラリ構築して　効率上げても自分が幸せになるわけじゃなし

104 ：デフォルトの名無しさん：02/08/15 16:26

>>97
頭の固い、要するに劣等民族である日本人には
OOは高尚なんだってこった。

105 ：デフォルトの名無しさん：02/08/15 16:31

他人数のプロジェクトになると、結局作ったソースは全部どっか別の会社のものになって
本人どころか自分の会社にも残らないなんだよね。

そうなると、せっかくクラスライブラリ構築して再利用性とか考えて、まったく無駄どころが
そのクラスライブラリと同じものを使う権利が自分らに無くなってしまう

106 ：デフォルトの名無しさん：02/08/15 17:12

>>102
OOというものはキミみたいな良質SE、良質PG
が使うものなんだね。でも良質じゃないSEやPGが
世の中の大多数って思うんだな。

107 ：デフォルトの名無しさん：02/08/15 17:13

>>106
嘆かわしい現状ですね。

だから中国やらインドに技術的にも負ける。

108 ：コギャルとHな出会い：02/08/15 17:18

http://kado7.ug.to/net/

朝までから騒ぎ！！
　　　小中高生
　コギャル～熟女まで
　　　メル友
　　i/j/PC/対応

女性の子もたくさん来てね
　　小中高生大歓迎です　　　　　　　　　　　　　　　　　
全国デ－トスポット情報も有ります。
全国エステ＆ネイル情報あります。

　　激安携帯情報あります。

109 ：逝って良しの１：02/08/15 19:31

>>105
それがあったか！
でも使いまわしてもバレないじゃん。

110 ：デフォルトの名無しさん：02/08/15 20:03

>>109　雪印を忘れたの？　

だいたい潰れかけの企業ばかりなんだから
これからそんな事やってりゃ不法行為だ
って、いつ膨大な賠償請求されるやら判らんぞ

111 ：逝って良しの１：02/08/15 20:21

名前とインターフェース変えりゃわからんだろ。

112 ：デフォルトの名無しさん：02/08/15 20:22

ていうか、最初から自社開発のライブラリを使うだろ。

113 ：デフォルトの名無しさん：02/08/15 20:32

>>112 そのライブラリの権利はどうなるの？

114 ：デフォルトの名無しさん：02/08/15 20:33

>>111 なんだ。インターフェース使ってるんじゃない

115 ：デフォルトの名無しさん：02/08/15 20:38

>>114
そういう中途半端な突っ込みはいかん。
どうせ「インターフェース使ってるからOOとは限らない」とか
返してくるんだから。もっと深くつっこめ。

116 ：逝って良しの１：02/08/15 20:38

いや、そのインターフェースじゃなくて・・・
情報のやりとり方法の規定。

117 ：デフォルトの名無しさん：02/08/15 20:41

>>116
> 情報のやりとり方法の規定。
それは普通プロトコルと言わないか？

118 ：デフォルトの名無しさん：02/08/15 20:42

>>113
そりゃ最初に決めるだろ。
ここからここまではうちの技術を使います、
ここからそっちはあんたの技術を使いますって

119 ：デフォルトの名無しさん：02/08/15 20:57

>>118　という事は、プロジェクトが終った時に自分の作ったライブラリはお持ち帰り可　って事？
　いいねえ

120 ：デフォルトの名無しさん：02/08/15 21:01

>>117
Java のインターフェイスの事を C++ ではプロトコルクラスという罠！

121 ：デフォルトの名無しさん：02/08/15 21:23

>>1
今からオブジェクト指向勉強しようとおもてるのに！

122 ：デフォルトの名無しさん：02/08/15 22:18

だから、OO使ってない職場なんて本当にそんなにあるの？
そういう職場では一体何使ってんのさ？
もしかしてVBが主流なの？

123 ：デフォルトの名無しさん：02/08/15 22:20

フリーで配布されてるライブラリ使えばいいだろ。
つうか、自分の作ったコードをフリーで配布しちまえば？

124 ：デフォルトの名無しさん：02/08/15 23:07

>>123 　普通の現場ではそれは立派な犯罪になると思うが

125 ：デフォルトの名無しさん：02/08/15 23:08

>>124の手にかかれば
システムの構築も犯罪です

126 ：デフォルトの名無しさん：02/08/15 23:09

>>122
”OO対応言語”は使ってるけどね

127 ：デフォルトの名無しさん：02/08/15 23:15

システムの構築は犯罪じゃないだろね。
　普通のプロジェクトだと守秘義務契約を会社同士は結んでいるし
　大抵の会社は技術系の従業員に守秘義務を課している

　労働として自分の作ったコードは　まず自動的に会社のものになり
　大抵契約によって発注元のものになる

つまり自分の作ったコードといえども他人の物になるんだよ。
だからそれをフリーで公開すれば、それは即座に著作権違反

128 ：デフォルトの名無しさん：02/08/15 23:18

自分で作った物をフリーで公開して
それを使うって事じゃないの？
勿論労働の枠外で作った物。

129 ：デフォルトの名無しさん：02/08/15 23:28

>>128
　そんな奇特な奴が世の中どんだけいると思う？
　結婚して子供でも出来たらプログラマに自分の時間なんてまずないよ

130 ：逝って良しの１：02/08/15 23:32

ＯＯ厨はＯＯ用語としてのインターフェースしか知らないのな。
プロトコルと言ったら通信やデータフォーマットと紛らわしいだろが。
あの場合のインターフェースってのはやり取りする関数の形式が中心。

131 ：デフォルトの名無しさん：02/08/15 23:37

＞勿論労働の枠外で作ったかどうかは　発注先には判らない。

　というか自分の会社にさえ証明するのは簡単じゃない

132 ：デフォルトの名無しさん：02/08/15 23:40

>>130
あのさ、インターフェースを関数の形式だとしたら
　関数名は変えても　一発置換が可能だが
　その関数の形式を変えるのは簡単じゃないだろ

133 ：逝って良しの１：02/08/15 23:43

簡単じゃないから判りにくい。

134 ：承太郎：02/08/15 23:44

>>127
バレなきゃあ著作権違反じゃあないんだぜ

135 ：デフォルトの名無しさん：02/08/15 23:45

>>133
要するに逝って良しの>>1にとっては, って事だろ.
自分が無能だって認めろよ. 難解だから優れていないとは限らない.

それにOOなんて簡単じゃん. 確かに入りにくいかもしれんが,
慣れると学習効率いいよ.

136 ：デフォルトの名無しさん：02/08/15 23:51

なんかスゴイよなあ　OO派って

OO使う為に、給料貰わずに設計してライブラリ作ってくれて、しかもフリーで公開までしてくれるんだ
俺はOO派には絶対に入らないけど、OO派が増えてくれる事は祈るし
応援は惜しまないよ。

ガンバレ！

137 ：デフォルトの名無しさん：02/08/16 00:10

>>136
売り言葉に買い言葉で
電波な事言い出すのはいつもの事

138 ：逝って良しの１：02/08/16 00:51

>>135
文脈を捉えてから書け！
「有る会社に納めたプログラムのルーチンをインターフェースだけ変えて
　他の会社に納めるのは簡単じゃないが、再利用した事が判りにくい」
フルで書くとこうなる。

人を見下したいと思ってる愚か者は自らが望む幻を作り出してしまう。

139 ：デフォルトの名無しさん：02/08/16 00:54

OO派のOOって、なんの伏字なの？
もしかして、巨乳派と貧乳派でもめてるの？

140 ：デフォルトの名無しさん：02/08/16 00:57

>>139
いい加減、そのネタ秋田。

141 ：デフォルトの名無しさん：02/08/16 01:05

>>139
つぅか一通りOOに貧乳とか巨乳を代入して読破した上での狼藉なのだろうか？だとすれば笑える。

142 ：デフォルトの名無しさん：02/08/16 01:10

なんかスゴイよなあ　巨乳派って

巨乳使う為に、給料貰わずに設計してライブラリ作ってくれて、しかもフリーで公開までしてくれるんだ
俺は巨乳派には絶対に入らないけど、巨乳派が増えてくれる事は祈るし
応援は惜しまないよ。

ガンバレ！

143 ：デフォルトの名無しさん：02/08/16 01:11

巨乳対応言語って何だ。

144 ：デフォルトの名無しさん：02/08/16 01:13

>>143
乳揺れ。
持ち上げ。
たわわ。

などなど。

145 ：デフォルトの名無しさん：02/08/16 01:22

乳にこだわってる必死な奴がいるようだが、楽しいかね？

146 ：デフォルトの名無しさん：02/08/16 01:25

>>145
素ﾁﾝ、必死だな。

147 ：逝って良しの１：02/08/16 01:27

ＭＦＣのWindow系の生成関数見ててビックリ

Wnd::Create( クラス名,・・・・略　);

オブジェクトの参照やポインタ渡しではなく、なんで「クラス」渡してるんだ？

148 ：デフォルトの名無しさん：02/08/16 01:27

>>147
マクロなの？

149 ：デフォルトの名無しさん：02/08/16 01:28

>>147
実行時型情報(RTTI)って知ってる？

150 ：デフォルトの名無しさん：02/08/16 01:33

>>147
WndじゃなくてCWndね。
WNDCLASSも知らないようじゃ、あんたWin32SDKも使えんね。

151 ：デフォルトの名無しさん：02/08/16 01:33

>>149
IってIdentificationかと思ってた。

152 ：デフォルトの名無しさん：02/08/16 01:40

逝って良しの１がまた1つﾍﾀﾚ伝説をつくりました

153 ：逝って良しの１：02/08/16 01:46

>>149
んー？これRTTYとかなの？
オブジェクトのポインタとセットで渡してるのならそうかもしれないけど、
クラス名しか渡してないじゃん。

154 ：デフォルトの名無しさん：02/08/16 01:47

>>153
本人？

155 ：デフォルトの名無しさん：02/08/16 01:49

>>153
つぅかそれが出来たら非常に柔軟なプログラミングが出来るんだけどね。

156 ：デフォルトの名無しさん：02/08/16 01:55

クラス名渡すＡＰＩだもの。
つか、CreateWindowしらべれ。

157 ：逝って良しの１：02/08/16 02:01

ひょっとして設計者がクラスとオブジェクトを混同してるだけでは？

158 ：デフォルトの名無しさん：02/08/16 02:03

ひょっとしてウィンドウクラスの名前のこと？

159 ：デフォルトの名無しさん：02/08/16 02:04

アンチＯＯ厨はＯＯ用語としてのクラスしか知らないのな

160 ：逝って良しの１：02/08/16 02:07

うん。
普通ならオブジェクトの参照渡しすべきところで何故かクラス名渡ししてる。

161 ：デフォルトの名無しさん：02/08/16 02:07

>>157
馬鹿が利口に責任転嫁

ﾁｮｰｶｺｲｲ!!

162 ：デフォルトの名無しさん：02/08/16 03:28

>>127
だから、会社が業務としてオープンソースなライセンス付けて配布すればいいんでしょ？

163 ：デフォルトの名無しさん：02/08/16 07:08

戦場ってのは烏合の衆で溢れてる。
だからオブジェクト指向は戦場では必要なし、というか邪魔。

馬鹿が(指揮官の方に)混じると破綻する。それがオブジェクト指向。
逆に指揮官が常に優秀ならヘータイのレベルが低くても良い結果が出るんだけどね。

164 ：デフォルトの名無しさん：02/08/16 07:19

戦場＝デスマーチ
ですか？

165 ：デフォルトの名無しさん：02/08/16 08:04

>>162
　だぁら！　そんな会社どこにあるってぇの？　あるなら紹介してくれ！

業務として受注した仕事のソースを無償でオープンにする？
発注先金払わないでいいじゃん？　そりゃ発注先は幸せだわな

166 ：デフォルトの名無しさん：02/08/16 09:04

>>160
だからCreateWindowしらべれ、ついでにRegisterClassも。
MFCのじゃないぞ、WindowsのAPIだぞ。

167 ：デフォルトの名無しさん：02/08/16 09:39

一部上場企業のコンビニのシステムを
OOで開発している28歳プログラマでも
「文字列の後にはヌルを入れなきゃいけないんですか？！」
とか言ってたぞ。OO以前の問題だな。

168 ：デフォルトの名無しさん：02/08/16 09:42

基本だな。

169 ：デフォルトの名無しさん：02/08/16 09:48

>>167
>一部上場企業のコンビニのシステムを
>OOで開発している28歳プログラマでも

訂正
>一部上場企業「で」コンビニのシステムを
>OOで開発している28歳プログラマでも

170 ：デフォルトの名無しさん：02/08/16 09:51

>>169
知識バカって言う人種ですか。

171 ：デフォルトの名無しさん：02/08/16 09:51

>「文字列の後にはヌルを入れなきゃいけないんですか？！」
気絶しそうになった。

172 ：デフォルトの名無しさん：02/08/16 09:56

ヌルヌルの中に入れる

173 ：デフォルトの名無しさん：02/08/16 09:59

とりあえず>>1の言う「戦場」の定義を示してくれ。

174 ：デフォルトの名無しさん：02/08/16 10:02

>>173
２００２年、情報とコンピュータは国の存亡を左右するまでに肥大化しすぎた。
戦争にはもう対人兵器は要らない。いるのは対電子機器兵器と数台のコンピュータだけだ。

今、日本とチベットの第三次情報戦争が始まる・・・。

175 ：デフォルトの名無しさん：02/08/16 10:46

一番別環境への適応能力が無いのは
逝ってよしの１でした

176 ：デフォルトの名無しさん：02/08/16 11:16

>>165
ひょとして君って、オープンソースなコードはみんな個人がやってるんだと思った？
企業としてオープンソースやってる所なんて、たくさんあるでしょ。
例えば、RedHatもそうだな。Alan Coxは業務でLinuxのコード書いてるだろ。
俺も会社の仕事でオープンソースのコードをcontributeしたことあるし。

177 ：デフォルトの名無しさん：02/08/16 11:26

>>176 妄想ｸﾝ？

>（クライアントから）業務として受注した仕事のソースを（開発者が勝手に）無償でオープンにする？

178 ：デフォルトの名無しさん：02/08/16 11:33

>>177
クライアントから業務として受注した仕事のソースを
*クライアントとの合意の上で*オープンソースにcontributeしましたが、何か？

179 ：デフォルトの名無しさん：02/08/16 12:04

>>178　それは仕方なくじゃないの？
よくメーカーの開発ツールなんかでGNUのものを少し改良してなんて場合は仕方なく
その部分をそうしてるのを見る事はあるが

それ黙ってやれば逆に犯罪

180 ：デフォルトの名無しさん：02/08/16 12:16

GNUが訴えなければ罪にはならないだろ

181 ：デフォルトの名無しさん：02/08/16 12:17

>>179
別に仕方なくでもなかったけど。BSDライセンスだったし。
手を入れたコードを本流に返すことによるメリットをちゃんと説明すれば
同意してくれるクライアントもけっこういるよ。

182 ：デフォルトの名無しさん：02/08/16 12:29

>>181 つまりは　その部分が完全にはプロジェクトのものじゃないからって事でしょ？

話が外れてきてるから元に戻すけど
言いたい事は、

普通の業務開発で、業務に関する部分をオブジェクト指向分析して
クラス設計して、実装したとしても、　そのクラスの再利用の権利は普通は発注者
に移動してしまい、同じような案件があったからと受注者側が再利用する事は
日本の現状では出来ない。

　そりゃまあ大きな発注者に喰らいついてるか、大企業の分社開発部隊なら話
は別なんだろうけどさ

183 ：デフォルトの名無しさん：02/08/16 12:55

>>182
そんなことないでしょ。
最初の案件をかなり安く押えてそのかわり合意した範囲のクラスライブラリの権利は開発側に残すことにすれば、
あとはそれを軸に
「うちのライブラリ使えばこれだけの予算でできますよ。もちろんうちのライブラリの権利はそのままうちのものですが。」
という形で仕事取ってくるだけの話。
ある程度専門性のある開発部隊なら、そういう形のビジネスも成立してるよ。

184 ：デフォルトの名無しさん：02/08/16 13:02

＞最初の案件をかなり安く押えて

確かに、とにかくコストダウンを要求されているから、そんな理由を付けて応じるしかない事もあると
いうか、そんな案件ばかりだけどね。

ただ、とにかく人集めてドカドカっと作ってみたいな場面だと、お手製クラスライブラリは
やっぱり難しい。　コンポーネントのように設計時から動かしながらのスタイルは逆に非
常に効率があがるが、　いわゆるお手製クラスライブラリは難しいよ

185 ：デフォルトの名無しさん：02/08/16 13:23

>>184
まあ、鶏と卵だよね。
お手製クラスライブラリによるコンポーネントがあれば、
提案の段階から動かしながら話ができて、技術的には激しく有利になる。
でも武器にできるようなお手製クラスライブラリを構築するには最初の一歩が大変だな。
最初は小規模でも、継続してコツコツ育てていくしかないんだろうね。

186 ：デフォルトの名無しさん：02/08/16 13:24

>>185
OOの問題点の一つだね。
使うのは楽だが作るのは面倒。
それを作る時間をどうするか。
まぁ、リファクタリングとかはそれ用の考え方だね。

187 ：逝って良しの１：02/08/16 14:08

>>166
それじゃ説明になってない。

188 ：デフォルトの名無しさん：02/08/16 14:10

>>187
　おい、何代目かしらないが、失敗したネタに粘着してどうすんだよ。
　前の奴にかわれ

189 ：デフォルトの名無しさん：02/08/16 14:22

逝ってよしの１はWindowsプログラミングすら知らないのに
MFCを批判してた、と。

アンチってこんなヤツばっか？
レベルが低すぎる・・・

190 ：デフォルトの名無しさん：02/08/16 14:25

>>189
そうよ？アンチDel然りアンチOO然り。

出来ないから煽る。

191 ：デフォルトの名無しさん：02/08/16 14:32

>>188
破綻したコトをしゃべるために作られた共通コテハンだよ

192 ：逝って良しの１：02/08/16 14:58

暗記するだけで疑問を持たないのはヴァカの証拠です。

193 ：デフォルトの名無しさん：02/08/16 15:02

自分の間違いを認めようとしないのはヴァカの証拠です

194 ：デフォルトの名無しさん：02/08/16 15:04

>>186
リファクタリングは著しくライブラリの再利用性を阻むと思うけど。
XPのノリで汎用クラスライブラリのインタフェース弄繰り回されたら使う側は地獄だ。

195 ：逝って良しの１：02/08/16 15:05

荒らしにながされちゃったんで再度掲載

Wnd系クラス::Create( 文字列型　クラス名,・・・・略　);

ＶＣのWindow系の生成関数は
オブジェクトの参照やポインタ渡しではなく、なんで「クラス名」渡してるんだ？
これオブジェクト指向じゃないんじゃない？
（ＲＴＴＹならポインタも同時に渡してるはず）
（CreateWindowがそうだからというのは同じ問題を言い替えているに過ぎないので
　説明になっていない）

196 ：デフォルトの名無しさん：02/08/16 15:08

ようするに VCL なら　そのWindowsクラス名は自動的にクラス名になるのに
どしてMFCはクラス名をワザワザ渡すのですか？　って疑問ですか？

197 ：デフォルトの名無しさん：02/08/16 15:10

>>195
「クラス」の意味は一つじゃないよ。

198 ：デフォルトの名無しさん：02/08/16 15:17

>>195
おいおい、CreateWindowとRegisterClassを調べろといわれてもまだ調べてなかったのか？
それから、RTTYって何よ？
そろそろ、偽物はすっこんでください。

199 ：デフォルトの名無しさん：02/08/16 15:21

先代は、もう少し論理的だった。

200 ：デフォルトの名無しさん：02/08/16 15:22

>>194
俺は>>186じゃないが、
とりあえずクラスライブラリを再利用可能な形に練り上げていく過程では
リファクタリングは有効というか必要な事だと思うが。
それをリファクタリングと意識してやるかどうかは別として。

で、溜め込んだクラスライブラリを個々の案件にフィットさせていく過程でも
やはりリファクタリングは必要だろ。

201 ：デフォルトの名無しさん：02/08/16 15:24

>>199
若旦那の場合は、論理的かどうか以前の問題だと思われ。

202 ：デフォルトの名無しさん：02/08/16 15:25

>>201
まだいろいろなものが、はえそろっていない模様

203 ：いつでもどこでも名無しさん：02/08/16 15:33

アンチＯＯ厨には、ここで反論されてもＯＯの有用性は実感できない罠。

204 ：逝って良しの１：02/08/16 15:34

RTTY->RTTI
どれが反論？

205 ：デフォルトの名無しさん：02/08/16 15:38

>>204　いや反論の前に、何か疑問なのか、何が論旨かさえ　>>195を読んでも判りません

206 ：デフォルトの名無しさん：02/08/16 15:41

なんか　学校関係の仕事で

　なんとか::Create( ”2年1組",...略);

　なんでクラス名を文字列で渡してるんですか？みたいなノリの質問？

207 ：デフォルトの名無しさん：02/08/16 15:45

>>206
識別するためだわさ。
リフレクション使える言語ならこの必要はなさそうだけど。

208 ：逝って良しの１：02/08/16 15:47

>>196
名前だけじゃなく、そのクラス名のクラスからインスタンスを内部で生成
してるみたい。

209 ：デフォルトの名無しさん：02/08/16 15:49

>>207 じゃあ名前空間はどうなりますか？

210 ：デフォルトの名無しさん：02/08/16 15:50

>>208
ねぇねぇ、もしかして高度なネタ？
ウインドウクラス（非CWnd）とは、
ウインドウプロシージャやスタイル、付加情報等のプロパティをまとめた
データのWindows内部での識別名で、言語でサポートされてるクラスとは別物なんだが。

211 ：194：02/08/16 15:56

>>200
別に不要とか厳禁と言うつもりは無いよ。
開発中・メジャーバージョンアップ時にはもちろん必要。

ただ既に公開してしまったクラスライブラリは
アプリ専用クラスよりもリファクタリングに
慎重であるべきだから「それ用の考え方」というほど
相性が良くは無いだろう。と言いたかっただけ。

>溜め込んだクラスライブラリを個々の案件にフィットさせていく過程でも
ソースを直接編集してしまうようなケースは
クラスライブラリの議論からは外れているような。

212 ：デフォルトの名無しさん：02/08/16 15:59

>>211
／＊
ただ既に公開してしまったクラスライブラリは
アプリ専用クラスよりもリファクタリングに
慎重であるべきだから
＊／

もちろんです。

そのお仕事に特化したクラスを再利用しやすくなるべく汎用的にすすための
リファクタリングです。

と、いうスタンスで。

213 ：デフォルトの名無しさん：02/08/16 16:00

公開しちゃったのは obsolete てことでとっとくでしょ。
新しいのと一緒に公開。

214 ：デフォルトの名無しさん：02/08/16 16:01

純粋小手先指向技術なVBやMFCネタはスレ違いだろ。

215 ：逝って良しの１：02/08/16 16:03

>>210
なるほど。

216 ：デフォルトの名無しさん：02/08/16 16:32

>>194
リファクタリングは、「インターフェイスを変えずにコードを改善する」手法なんだが。

217 ：デフォルトの名無しさん：02/08/16 16:53

>>216　単に全スレから続いてるネタでしょ

　--------------こんなネタ---------------------------
634 名前：デフォルトの名無しさん投稿日：02/08/12 08:36
>>632
そして継承してソースをコピって変更するんだろ。
やっぱリファクタリングだな。
コンポーネント厨には高度すぎる。

639 名前：デフォルトの名無しさん投稿日：02/08/12 08:39
>>638
継承してるからだろ。
継承しなけりゃリファクタリング。
でも、やってることは同じ。

642 名前：デフォルトの名無しさん投稿日：02/08/12 08:43
>>641
用語なんてどうでもいい。
コンポーネント指向の本質より、
リファクタリングの本質に近いと言うことだ。
あとは自分で考えろ。

218 ： ◆.....XD. ：02/08/16 16:59

>>216
メソッド名を短くするとか言うのもリファクタリングじゃないの？

219 ：デフォルトの名無しさん：02/08/16 17:05

ロジックを変えずにコードを改善が正しかったかも。
リファクタリングカタログにはメリット・デメリットが併記してある。
デメリットが大きいならやらなくていい。

220 ：デフォルトの名無しさん：02/08/16 21:25

> Wnd系クラス::Create( 文字列型　クラス名,・・・・略　);

俺、Java厨なんでVCのことは知らないが、
Class.forName(String)
みたいなもん？
VCじゃどうだか知らないが、Javaじゃ設定ファイルから
どの機能を組み込むか決めるようなシチュエーションで重宝しまくりなんだが。

221 ：デフォルトの名無しさん：02/08/16 21:35

全然違う

222 ：デフォルトの名無しさん：02/08/16 21:44

>>219
>ロジックを変えずにコードを改善
はぁ？

223 ：デフォルトの名無しさん：02/08/16 21:47

>>222
インデントを見やすくしたり、変数名を分かりやすくしたり
Warningを取ったり、コメントをきちんと書いたりすることです。

224 ：デフォルトの名無しさん：02/08/16 21:47

>>222
この書き方って楽だよな。
相手の出方を見て攻撃すれば良いんだから。
敢えて後手に回るやり方だ。

225 ：デフォルトの名無しさん：02/08/16 21:48

>>223
＞Warningを取ったり
これは当たり前では・・・？

226 ：デフォルトの名無しさん：02/08/17 00:05

>>225
なんでそこだけピックアップ？
上にあげた４つは、すべて当然すべきことです。

227 ：デフォルトの名無しさん：02/08/17 00:18

age

228 ：デフォルトの名無しさん：02/08/17 00:31

理論より実感。

229 ：デフォルトの名無しさん：02/08/17 00:39

>メソッド名を短くするとか言うのもリファクタリングじゃないの？
プライベートなメソッドはいいんじゃない？
あと、短くじゃなくて「わかりやすく」ね

230 ：デフォルトの名無しさん：02/08/17 00:41

copyをcpにしたり、
removeをrmにしたり？

231 ：デフォルトの名無しさん：02/08/17 01:06

見やすく
分かりやすく
きちんと

あいまいだなぁ・・・
オブジェクト指向開発ではコーディング規約とかは
必要とされてないの？

232 ：デフォルトの名無しさん：02/08/17 01:08

Java coding standardとか
C++ coding standardとかあるけど

233 ：デフォルトの名無しさん：02/08/17 01:12

OOってすげぇあいまいな言葉だよね！
でさ、そのあいまいな言葉を使って
あおりあいするのって凄く無意味なことだと思うんだよね！
ちがうかな！？

234 ：逝って良しの１：02/08/17 01:40

俺は煽ってないぞ。
一方的に煽られてるだけ。
正論吐くつもりならハンドルくらいつけてね。

235 ：デフォルトの名無しさん：02/08/17 01:41

>>234
釣られるなよ・・・

236 ：デフォルトの名無しさん：02/08/17 01:48

ファイル毎管理すればOOはいらないよ。

237 ：逝って良しの１：02/08/17 02:03

うん、ファイル分けなら単位も自由自在だし、ＯＯ要らないね。

238 ：デフォルトの名無しさん：02/08/17 02:09

>>236
再利用もコピペでいいしね。

239 ：デフォルトの名無しさん：02/08/17 02:17

>>223
それだけじゃpretty printと思われてしまうけど、

まあリファクタリングのうち再利用性に直接関係する主だったところを挙げれば
・各クラスの責任分担の見直し(インスタンス変数やメソッドの移動など)
・メソッドの可塑性の向上(一時変数の導入やメソッドの分割など)
・クラス階層の見直し(inheritance -> composition, composition -> inheritance)
あたりかな。

240 ：デフォルトの名無しさん：02/08/17 14:37

>>237
そうそう。関数もmain()だけで十分だし。

241 ：デフォルトの名無しさん：02/08/17 14:47

ひぇ～・・

242 ：逝って良しの１：02/08/17 14:48

大体、それぞれが最適である場合、再利用の単位と動作の単位が一致する事
は非常に少ないはず。
クラスとは別に再利用の機構を考えるべき。

つうか、考えた時点でＯＯの負けだけどね。

243 ：デフォルトの名無しさん：02/08/17 15:15

>>242
はあ、クラスとは別の再利用の機構なら、

例えばクラスより大きな粒度ならば、
Javaならpackage、VisualWorks Smalltalkならばparcel、Squeakならばprojectなんかがありますが。
ほかの言語/処理系にも同じような機構は大抵あるんじゃない？

クラスより小さな粒度ならば、メソッド単位で再利用してもいいし、
別角度から見て、インスタンス単位で再利用してもいい。

どうでもいいけど、君が知ってるOOPL言ってみてよ。
批判する以上、実際に使った経験がある言語ぐらいあるんでしょ？

244 ：デフォルトの名無しさん：02/08/17 16:34

再利用するだけならDLLやsoみたいな単位でも十分な気が。
クラスとかだと言語限定になるのはどうよ？（COM使えとか言うなよ）

245 ：デフォルトの名無しさん：02/08/17 16:35

>>244
COMつかえよ。

246 ：デフォルトの名無しさん：02/08/17 16:37

>>244
もちろんDLLやsoのような単位で再利用できるOOPLの処理系もあるわけですが、何か？
クラス単位の再利用にこだわっているのは>>242をはじめとするアンチだわな。

247 ：244：02/08/17 16:54

>>245
COMなんか使うか、ホゲ！

248 ： ◆.....XD. ：02/08/17 16:56

>>247
みんな理解してない技術や技法を食べず嫌いでバカにするのってどうかと思います。
まぁ、バカなんだろうけど。

249 ：244：02/08/17 17:07

COMなんてWindowsでだけしか適用できないじゃんかよ。

250 ： ◆.....XD. ：02/08/17 17:08

>>249
LinuxのsoがWindowsで動いたりDLLがMACで動くような言いぐさですな。

251 ：デフォルトの名無しさん：02/08/17 17:16

どうでもいいが話が逸れすぎてるぞ。
オブジェクト指向言語でクラス以外の再利用の単位があるかどうかじゃないのか？
で、>>243-244や>>246はあると言ってるわけだ。

252 ：デフォルトの名無しさん：02/08/17 17:32

>>249
COMじゃなくてもXPCOMだってあるじゃねーか
これはマルチプラットフォームだぞ

253 ：逝って良しの１：02/08/17 18:55

つうか、言語構造以外の手段で再利用が可能で、さらにそっちのほうが
使えるとなると、ＯＯＰＬは自己否定してるようなもんなのだが。

254 ：デフォルトの名無しさん：02/08/17 19:18

XPCOMは構造化言語で再利用が可能でも
やたら煩雑な手順を踏むことになるんで、とても使えるとは言えないと思うが。

255 ：デフォルトの名無しさん：02/08/17 20:54

>253
ゆってることはわかるけど、再利用だけですべてを否定するのはどうでしょうか？
仕様変更に強いとか。もあると思う

256 ：デフォルトの名無しさん：02/08/17 20:55

>>255
強いの？

257 ：デフォルトの名無しさん：02/08/17 20:58

ちゃんと設計してあればの話

258 ：デフォルトの名無しさん：02/08/17 21:03

>>257
だよねぇ。

259 ：244：02/08/17 21:06

>>250
DLLやsoは仕組みがほぼ同じなんだけど・・。
windowsと*nix両方で使えるモジュール作るのは簡単。
（バイナリレベルという意味ではないよ）

260 ：デフォルトの名無しさん：02/08/17 21:08

>>259
＞（バイナリレベルという意味ではないよ）
スマソ、じゃあ何レベル？

261 ：デフォルトの名無しさん：02/08/17 21:10

COMだってコンポーネントフレームワークを用意すれば、
他プラットフォームで動くな。
MSだって元はそれをねらって設計してたんだしさ。

262 ：デフォルトの名無しさん：02/08/17 21:11

>>260 ソースレベルだろ

263 ：デフォルトの名無しさん：02/08/17 21:12

>>262
APIとシステムコールは違うと思うけど。
どうやるの？
限りなく桁数の大きいPIを求めるとかそう言うの？

264 ：デフォルトの名無しさん：02/08/17 21:13

>>263 #ifdef

265 ：デフォルトの名無しさん：02/08/17 21:15

>>264
なーんだ・・・。

266 ：244：02/08/17 21:17

なーんだ、ってあたりまえじゃん・・

267 ：244：02/08/17 21:19

>>261
COMはどうやるの？レジストリとか。
機構作るだけでかなりの工数掛かる気がするけど。
その「できる」が現実的じゃないと意味ないよ・・・。

268 ：デフォルトの名無しさん：02/08/17 21:20

処理の本質はシステムコール呼び出しより
そのほかのロジックであることが多いんだから、
ラッパーを解したり#ifdefで選択するのは悪いことではないが。

というか、複数の環境で動かすプログラムは
大抵#ifdefが入ってるじゃん。

269 ：デフォルトの名無しさん：02/08/17 21:22

>>267
結局MSはそれをやらなかったわけで、個人がやるのは現実的じゃないな。
でも、COMの思想自体は悪い物では無いだろ。泥臭いけど。

で、類似品にMozillaのXPCOMはLinuxだろうがWinだろうが動くな。

270 ：逝って良しの１：02/08/18 01:06

>>255
変更に強い構造に出来る度合いはＯＯＰＬも非ＯＯＰＬも同じ。

ヘタレが組めば弱いし、上手い奴が組めば強いのが出来る。
その難易度や変更強さはＯＯＰＬでも非ＯＯＰＬでも差は感じない。

強いて挙げるなら、ＯＯの本読んで初めてそういうの知ったようなのが
そういう組み方をした場合にそうなるというぐらいか。
（本読んでもヘタレなコードしか書けないのが９割だし、会社のコーディング
　規則でヘタレコードしか書いちゃいけないという話も別スレに一杯有る）

271 ：デフォルトの名無しさん：02/08/18 01:12

>>270
上手い奴が効率よくコーディングするのには、OOPLが役に立つんだよな。

272 ：デフォルトの名無しさん：02/08/18 01:14

>>270
それはさ、非OOPL で OO しろって事でしょ？
素直じゃないな。OO するなら OOPL の方がいいに決まってる。

> 会社のコーディング規則でヘタレコードしか書いちゃいけないという話も別スレに一杯有る
俺も既にあるヘタレコードを使うように強要された時とかは泣きたくなるね
OO わかってないやつのソースとかさ、酷いよホント。

273 ：デフォルトの名無しさん：02/08/18 01:19

>>272 OO わかってないやつのソースとかさ、酷いよホント。

こういう事言う奴も結局OO分かってないんだよな。
大体本質はOO出来るかどうかじゃなくて、
問題の切り分けを正しくやっているかどうかだろうが。

274 ：デフォルトの名無しさん：02/08/18 01:19

>>270
あんたOOダメっていうけど、
たとえばファイル操作のライブラリをあんたが設計するとしたら、
どんな形態にするよ？

275 ：272：02/08/18 01:26

>>273
あんた継承が正しく行われてないライブラリを使わなきゃいけない状態になった事あるか？

泣くぞ？泣きながら徹夜するぞ？

276 ：デフォルトの名無しさん：02/08/18 01:32

正しい継承って何よ？
唯一絶対なんてOOには存在しないだろ

277 ：デフォルトの名無しさん：02/08/18 01:39

OO言語みたいなのはコストがかかるだけだよ。やめときな。

278 ：逝って良しの１：02/08/18 02:05

>>274
file_read( char *file_name, void *buf );

279 ：デフォルトの名無しさん：02/08/18 02:48

>>278
高々読み込みなのに、いちいちファイル名を指定するのか？
ホントにｲｯﾃﾖｼだな。

280 ：デフォルトの名無しさん：02/08/18 04:07

>>278
毎回開き直すのか…スゲー

281 ：デフォルトの名無しさん：02/08/18 04:11

>>253
再利用について、言語仕様によって支援されている部分と
言語仕様外によって支援されている部分がある。
どちらが欠けても不十分。それだけの話だろ。

282 ：逝って良しの１：02/08/18 04:13

C++はね。

283 ：デフォルトの名無しさん：02/08/18 04:36

>>278
せめて最大サイズぐらい渡せよ。
bufを確保する時にファイルサイズをチェックするんだろうけど、
その時のファイルサイズと今のファイルサイズが同じなんて保障はどこにもないわな。
簡単にバッファオーバーランするぞ。呆らかに欠陥品だ。

284 ：デフォルトの名無しさん：02/08/18 04:47

void* buf　だから、いくら読んでもポインタは進まないのさ。

285 ：デフォルトの名無しさん：02/08/18 04:49

>>284
でもvoid*の配列は作れるよね。

286 ：デフォルトの名無しさん：02/08/18 04:50

つーか、マジレスしてるやつアホだろ？

287 ：逝って良しの１：02/08/18 05:13

しょーがないなー
>>279-280
ファイルハンドラを抱えて右往左往するようなルーチンを考えているなら
上位層ではファイルハンドラなんか気にすべきではないので間違い。
>>283
オーバーラン上等！
>>284
中でbyte型に変換します。どんな型のデータでも読み込めます。

288 ：デフォルトの名無しさん：02/08/18 05:39

ファイルハンドラよりもファイル名のほうが抽象されてると思ってるヤシがいる(呆

289 ：デフォルトの名無しさん：02/08/18 05:41

> オーバーラン上等！
こういうアフォがいるから現場が荒れるんだよな…
つーか、
どうも若旦那の言動はオブジェクト指向の是非以前の問題なんだよな…

290 ：デフォルトの名無しさん：02/08/18 05:44

>>278
ふーん、Smalltalkでは
"file.dat" asFilename readStream contents
なーんて書き方もできるけど、どう思うよ？

291 ：デフォルトの名無しさん：02/08/18 05:59

すっげー笑えたよ。
ってことで晒し上げ(笑)

------------------------------------------------
274 ：デフォルトの名無しさん：02/08/18 01:19
>>270
あんたOOダメっていうけど、
たとえばファイル操作のライブラリをあんたが設計するとしたら、
どんな形態にするよ？

278 ：逝って良しの１：02/08/18 02:05
>>274
file_read( char *file_name, void *buf );

279 ：デフォルトの名無しさん：02/08/18 02:48
>>278
高々読み込みなのに、いちいちファイル名を指定するのか？
ホントにｲｯﾃﾖｼだな。

280 ：デフォルトの名無しさん：02/08/18 04:07
>>278
毎回開き直すのか…スゲー

283 ：デフォルトの名無しさん：02/08/18 04:36
>>278
せめて最大サイズぐらい渡せよ。
bufを確保する時にファイルサイズをチェックするんだろうけど、
その時のファイルサイズと今のファイルサイズが同じなんて保障はどこにもないわな。
簡単にバッファオーバーランするぞ。呆らかに欠陥品だ。

284 ：デフォルトの名無しさん：02/08/18 04:47
void* buf　だから、いくら読んでもポインタは進まないのさ。

287 ：逝って良しの１：02/08/18 05:13
しょーがないなー
>>279-280
ファイルハンドラを抱えて右往左往するようなルーチンを考えているなら
上位層ではファイルハンドラなんか気にすべきではないので間違い。
>>283
オーバーラン上等！
>>284
中でbyte型に変換します。どんな型のデータでも読み込めます。
------------------------------------------------------------

292 ：デフォルトの名無しさん：02/08/18 08:50

Delphiなら
　function ReadFileStrAll(fileName:string):string;
　なんて関数は作って、実際よく使うけどな
Delphiのstringは255文字の制限もないし、サイズ付でバイナリも保存出来るし

293 ：デフォルトの名無しさん：02/08/18 12:34

オブジェクト指向が戦場では有効か有効でないかは議論が分かれる所だが、
「逝って良しの1は戦場では必要なし」という点では、かなりの割合で同意がとれると思うが、どうよ？

294 ：デフォルトの名無しさん：02/08/18 12:36

>>292
Delphiはよく知らんが、
ShiftJISなファイルをそれで読んだ場合、サイズはどうなる？

295 ：デフォルトの名無しさん：02/08/18 12:36

>>293
どうでもいい。

296 ：デフォルトの名無しさん：02/08/18 12:57

結局Cのfopen系と似たような設計になると思ったから聞いたんだがな。
これだって一応非OO言語でOOしてるんだし。

しかし、それ以前の問題だったのか

297 ：デフォルトの名無しさん：02/08/18 12:59

>>296
要はメンバとなるデータを持った構造体を作ってその構造体へのポインタを取るメソッド代わりの関数群を用意する。
と。

これだけ書くとあんまりやりたくない感じ。

298 ：デフォルトの名無しさん：02/08/18 13:14

すみませんが、お尋ねします。
このたびDelphiを勉強してるのですが、オブジェクト指向というのが
いまいちよく分からなくて、うまくDelphi的なプログラムが組めません。
オブジェクト指向が身に付く、為になる参考書等ありませんでしょうか？
一応CとVBは書けます。

299 ：デフォルトの名無しさん：02/08/18 13:16

>>298
オブジェクト指向関係なさすぎな経歴にワラタ。
コンポーネント作ったりJavaとかやれば何となくわかってくると思うけど。

300 ：298：02/08/18 13:20

>>299
そうですかやっぱりJavaですか。
というか、Delphiの参考書自体数が少ないですよね。
一応Javaも基本的な事項は勉強しましたが、なんせ
起動が遅いし使いにくいしGUI書くのめんどうだしで、
結局つかわずにいます・・・

301 ：デフォルトの名無しさん：02/08/18 13:31

>>297
勘違いしてるぞ
構造体じゃなくファイルスコープを利用する

302 ：デフォルトの名無しさん：02/08/18 13:32

>>297
じゃなくて、普通のfopen/fclose/fread/fwrite/fseekみたくなるはずって事だろ。
まあ、逝って良しの1もそれを意識してあえてFILE *を外そうとしたんだろうが、
最大サイズを考えてなかった時点でもうダメダメだな。
はっきりいって、Cでもマトモな関数が書けるとは思えんセンスだ。

303 ：デフォルトの名無しさん：02/08/18 13:34

>>301
何を隠蔽して何を公開する？

304 ：デフォルトの名無しさん：02/08/18 13:36

>>303
自分でわかるだろ

305 ：デフォルトの名無しさん：02/08/18 13:40

http://javaco.org/pages/song04.htm

これ聞いてマターリする！

306 ：デフォルトの名無しさん：02/08/18 13:40

>>302
297は間違ったことを言ってないと思うが。

307 ：デフォルトの名無しさん：02/08/18 13:46

>>294 DelphiのstringはVBのような16bit文字列じゃなく AnsiStringの略で、バイト列になっている
　　だからShiftJisでもファイルサイズと一致する
　WideStringといって16bit文字列を扱える型も持っている。
　これにAnsiStringを代入すれば文字コード変換は勝手にされる

308 ：デフォルトの名無しさん：02/08/18 13:48

Windows限定なら、いっそファイルをバイト配列にマッピングするのも面白いかも

309 ：デフォルトの名無しさん：02/08/18 13:49

>>308
メモリマップドファイルですか。
メモリ共有以外ではいまいち出番のないあいつですな。

310 ：逝って良しの１：02/08/18 13:58

最大サイズなしー＞システム止まる
最大サイズ指定ー＞やっぱりシステム止まる

どっちも同じ

311 ：デフォルトの名無しさん：02/08/18 14:04

>>309
メモリマップドファイルって出番ないか？
普通のRead/Writeよりよほど頻繁に使うんだが。

312 ：デフォルトの名無しさん：02/08/18 14:07

>>311
ストリーム嫌いな人（俺とかｗ）には良い感じかと。
テキストファイルはStringList的な物に放り込んで使うことが多いなぁ。

313 ：デフォルトの名無しさん：02/08/18 14:08

ストリームが嫌いというか、
でかいファイルを扱うときにバッファ間のコピーコストが気になるな。

314 ：デフォルトの名無しさん：02/08/18 14:08

>>310　どうせ言い訳するなら

void * で渡したのはポインタのポインタで
void * mem = SuperMemoryManegerCreate();　と作成しておいて
ReadFile( "file" , mem);　//実際のアロケートはこの内部で行う

サイズが必要なら
SuperMemoryManegersGetSize(mem);
　とやるんだとかさ

315 ：デフォルトの名無しさん：02/08/18 14:09

>>310
もうあんたは要らないって
そろそろ前の人に変われよ

316 ：デフォルトの名無しさん：02/08/18 14:10

>>314
その例じゃ無理

317 ：デフォルトの名無しさん：02/08/18 14:14

>>316　どうして？

こんな感じでやったらだめ？
struct { int size;int used; void *membuf;} MemArray[66];
void *SuperMemoryManegerCreate(){
　・・・　略　・・・
return & MemArray[n];
}

int SuperMemoryManegersGetSize(void *p)
{
return *(int *)p;
}

318 ：デフォルトの名無しさん：02/08/18 14:26

最近、逝ってよしの１が理論的じゃなくなったね。
先代の方が良かったな。

319 ：デフォルトの名無しさん：02/08/18 14:28

今の逝ってよしの１は逝ってよしな１に改名してくれ

320 ：デフォルトの名無しさん：02/08/18 14:31

>>319
と、言うか素直に逝ってもらうのがベストでは？

321 ：デフォルトの名無しさん：02/08/18 14:31

>>320　それはそれで寂しくなるなあ

322 ：デフォルトの名無しさん：02/08/18 14:36

>>317
読み始めてから読み終わるまでファイルサイズが不変であることを保障できればいいがな。
実際にはそういうわけにはいかんだろ。

323 ：デフォルトの名無しさん：02/08/18 14:39

>>322 それを言い出したら　中身の内容だって誰かに書き換えられないとも限らないという話になるぞ

324 ：デフォルトの名無しさん：02/08/18 14:40

>>317
つーか、そのSuperMemoryManagerがよくわかんないんだけど。
特に66ってあたり。

ひょっしてmalloc()の再発明？

325 ：デフォルトの名無しさん：02/08/18 14:41

>>323
それはそうだが、オーバーランされるより百万倍マシ。

326 ：デフォルトの名無しさん：02/08/18 14:46

>>324 違うよ mallocのトレイ
ReadFile("File" , mem); 関数内部で
　ファイルサイズ調べて必要な量だけmallocして返したら　不可能じゃないよという　【だけ】の意味ね

327 ：デフォルトの名無しさん：02/08/18 14:56

>>326
じゃ、そんな変な構造体や関数使わなくても、
void **を渡せばそれで十分じゃん。
なんでわざわざ変な構造体を66個も作るわけ？
例えば
void *buff;
....
FileRead("file.dat", &buff);
...
で何か不都合でも？

328 ：デフォルトの名無しさん：02/08/18 15:10

>>327　つまり ReadFile内部で　mallocをして buffにサイズとかを返すわけね
別にそれでいいんじゃない？

　ただ　管理する時変な構造体の配列を作った方が
　後で解放忘れのチェックとか現在の状況をストリームに吐き出して中断とかが
　楽だから　俺は良く使うだけでさ

329 ：デフォルトの名無しさん：02/08/18 15:11

なんか、前提としてる背景が違いすぎて議論になってない…

のは、２ｃｈの通例か。

330 ：デフォルトの名無しさん：02/08/18 15:17

オブジェクト指向を理解しないまま仕事をしたら…
－効率が悪くて当然
－ソースが複雑になって当然

理解した人がちゃんと設計してつくれば
効率も良くなるし、ソースもきれいになる。

ってことで、

理解してから使ってください

331 ：デフォルトの名無しさん：02/08/18 15:18

>>330
あのー、
効率よく書くのに激しく参考になるような本ないですか？
デザインパターン？

332 ：デフォルトの名無しさん：02/08/18 15:28

>>331
何を理解したいのですか？
あるいは、何を効率よくおこないたいのですか？

333 ：逝って良しの１：02/08/18 15:28

>>331
本ではなく才能

334 ：デフォルトの名無しさん：02/08/18 15:29

>>331 効率よく書くためには　本を参考にするより　コード読む。そして読むより書く経験。
習得より体得

335 ：デフォルトの名無しさん：02/08/18 15:30

>>328
どこをどう読めばbuffにサイズを返すことになるのか…
それに、66という数字の意味がまだサパーリわからんのですが。

336 ：デフォルトの名無しさん：02/08/18 15:30

>>334
基礎無い物は死ぬのみ。
基礎は本で身に付けるべし。

337 ：デフォルトの名無しさん：02/08/18 15:36

>>336　基礎段階で効率など追求しちゃいかん

338 ：デフォルトの名無しさん：02/08/18 15:42

>>335
　え？

int ReadFile (void ** mem)
{ int size;
　・・・略・・・
　*mem = malloc(size);　
　・・・略・・・
return size;
}
　みたいにやるのかな？　

ああ、66ね、　66は俺が好きだから
　実行してみて必要サイズは調整すればいいという考えだけど
　そのサイズをdefineしたりするのは嫌い。
　ループとかでは　sizeof を使って配列サイズ取ればいいじゃん

339 ：デフォルトの名無しさん：02/08/18 15:50

> 278 名前：逝って良しの１本日の投稿：02/08/18 02:05
> >>274
> file_read( char *file_name, void *buf );
>
>
> 279 名前：デフォルトの名無しさん本日の投稿：02/08/18 02:48
> >>278
> 高々読み込みなのに、いちいちファイル名を指定するのか？
> ホントにｲｯﾃﾖｼだな。
>

>>279
ちょっと聞きたいけどファイル名指定しないでどうやってファイル読み込むの？

340 ：デフォルトの名無しさん：02/08/18 15:50

>>338
> ああ、66ね、　66は俺が好きだから
> 実行してみて必要サイズは調整すればいいという考えだけど
> そのサイズをdefineしたりするのは嫌い。
頭痛くなってきた。
好きとか嫌いもいいけど、どうみてもバグの元だぞ、直値66は。

> ループとかでは　sizeof を使って配列サイズ取ればいいじゃん
意味不明です。
MemArrayはautoじゃないんだから、ループの中とか外とか関係ないでしょ。
それとも関数のネストを許す言語での話？

341 ：デフォルトの名無しさん：02/08/18 15:55

>>339
通常はopen操作とread操作を別にしておくんですがね。

まあ読み込む対象が通常のファイルで一回で全て読み込んでしまうのであれば
openとreadを一緒にしてファイル名指定でもいいんだけど、
実際には開く対象が有限サイズとは限らないから問題ありだな。

例えば開く対象がFIFOだったらどうする？

342 ：デフォルトの名無しさん：02/08/18 15:59

>>340
　え？　例えば直値で配列のサイズを書いても
　 for(i=0;i< (sizeof MemArray) / (sizeof MemArray[0]);i++){・・・}
　みたいにそのサイズを利用すればいいわけで
　リスト中に66をばらまく訳じゃないよ

　サイズを #define MemArraySize 66　とか定義して
　 MemArraySizeをばらまく方法だと　醜い

343 ：デフォルトの名無しさん：02/08/18 16:00

>>332
>>333
>>334
>>336
ｻﾝｸｽｺ。
一応一通りDelphi書けるんだけど、オブジェクト指向ってのが
いまいち身に付かなくて、一回実際にコード書いてから
カプセル化や継承でコードを短くしたり効率化を図ってるんだけど、
なんかいわゆる「定石」みたいなのがあるといいなと激しく思っているので。
そんな本ないですか？

344 ：デフォルトの名無しさん：02/08/18 16:01

>>341
　FIFOでも開く都度　Openしたって問題じゃないでしょ
　Openが非常に重い処理だというなら　内部でキャッシュすればいいんだし

345 ：デフォルトの名無しさん：02/08/18 16:01

>>343
デザインパターンはなるべく読まん方がいい気もする。

346 ：デフォルトの名無しさん：02/08/18 16:15

>>345
ななななんで～
本屋逝っても、デザインパターンくらいしかオブジェクト指向の定石本
みたいなのは見つからないんだけど・・・
まぁCの定石に慣れすぎたおかげでオブジェクト指向が理解できない
みたいな弊害があるのかもしれんが。

347 ：デフォルトの名無しさん：02/08/18 16:16

>>342
まあ、君が自分用の俺プログラムを作るぶんにはどうでもいいが、
他人といっしょに仕事で書く時には、そういうワケワカラン直値はやめといたほうがいいよ。

348 ：342：02/08/18 16:19

つまりさ、 void * を渡すのは　徹底的に相手に実装を見せない為でしょ？
だから .h ファイルには関数名しか置かない
そして　Cソースファイル中に　構造体とか配列の情報は埋め込んでしまう
　って手法を使ってるわけ

ヘッダファイルに構造体を置いたり、配列のサイズ情報を入れたりはしない

349 ：デフォルトの名無しさん：02/08/18 16:26

逝って良しの１が世代交代してから
他の奴らのレベルまで下がってるな

350 ：デフォルトの名無しさん：02/08/18 16:26

>>344
内部でキャッシュは別に良いんだけど、
読み込み要求があるたびにファイル名からディスクリプタとか検索するわけ？

351 ：デフォルトの名無しさん：02/08/18 16:28

>>349
まぁ類は友をなんとやら、ですわ。

…ｵﾚﾓﾅｰ

352 ：デフォルトの名無しさん：02/08/18 16:30

>>345
デザパタ本読んで
「よーし、俺もこれからデザパタでプログラミングするぞぉ！」
とかはダメダメだが、
過去自分が書いたプログラムを読み返しながら、
「ここはこのパターンを使ったらどうなるだろう？」
という疑問を持ち、実際にプログラムし直しながら読み解いていくのなら
有害ではないと思うよ。

つまり、生兵法にならんように気をつけな、って事 >> 346
逆に言うと、デザパタは生兵法になりやすいから注意。

353 ：デフォルトの名無しさん：02/08/18 16:31

>>350　
　だってFIFOでファイルOPEN処理が問題になるくらい重いんだろ？
　ならファイル名から2分検索したって問題になるまい

354 ：デフォルトの名無しさん：02/08/18 16:32

>>348
それと、直値の埋め込みとどういう関係が？
つーか、ヘッダファイル以外では#defineは使わないという趣味をお持ち？

355 ：デフォルトの名無しさん：02/08/18 16:34

>>353
だから、FIFOから次の値を取りにいく度に
文字列からデスクリプタ探さにゃならんわけ？

356 ：デフォルトの名無しさん：02/08/18 16:35

ファイルオープンが重いのは、FATのようなシステムではファイル名を検索するのに
全検索する必要があったから。　同じディレクトリにファイルが1万もあれば
一つ Openするのに秒単位の時間がかかったりしたもの　（Win95なら実際にそうだった)

OS/2から採用されたファイルシステムではB木のような構造が採用されており
この問題はほぼ解決されている

357 ：デフォルトの名無しさん：02/08/18 16:37

>>355
　だから探さなければならないけど、何が問題なのさ？
　既に開いているファイルが10個程度なら対した問題じゃないでしょ？
　逆に、ファイルを１００も千も開いてるとしたら、そっちが問題じゃないの？

358 ：342：02/08/18 16:38

>>354 配列のサイズについてはね

359 ：デフォルトの名無しさん：02/08/18 16:38

ファイル名じゃなくてディスクリプタへのポインタを返せば
いちいち検索しなくて良いし、排他制御とか付加情報を持たせたりも出来るようになるじゃん

360 ：デフォルトの名無しさん：02/08/18 16:42

　　先　代　の　逝　っ　て　よ　し　の　１　は　ま　だ　で　す　か

361 ：逝って良しの１：02/08/18 16:44

信ぢられん！
ファイルヂスクリプタ抱えて右往左往するようなプログラムなんか
可読性悪いだろ。
追うとき「今ＸＸをオープンしてて～」とか全部頭に入れながら追うのか？
ファイル名渡したらバッファデーター以外全て忘れるのが吉。

362 ：逝って良しの１：02/08/18 16:44

先代も何も同一人物ですが何か？

363 ：デフォルトの名無しさん：02/08/18 16:45

>>357
開いているファイルの数が問題なんじゃないんだって。

通常、1つのFIFOからは何度もread操作を繰り返さなきゃいけないでしょ？
つまり、1回のfopenとn回のfreadで済む話を、
何で毎回fopen+freadを繰り返さにゃならんわけ？
たとえファイル名からディスクリプタをある程度高速に検索できたとしても
操作自体はディスクリプタを直接与えてfreadするよりも
ずっと複雑かつ高価になるでしょ？

って話なんだけど。

364 ：逝って良しの１：02/08/18 16:47

んなもんはメモリ上でやれ。

365 ：デフォルトの名無しさん：02/08/18 16:48

>>361
で、それとオブジェクト指向とどういう関係が？

例えばSmalltalkではファイル名から一括して内容を読み出すこともできるし
( buff ← "file.dat" asFilename readStream contents )

何回かに分割して読む事もできますが。
( stream ← "file.dat" asFilename readStream.
[ stream atEnd] whileFalse: [ char ← stream next. .... ] )

366 ：デフォルトの名無しさん：02/08/18 16:52

>>363
　　確かに多少は複雑だけど、別にそんな大きな問題じゃない
　　そもそも文字列はポインタで与えるんだから　大抵はポインタ比較
　　で一致すればOKでしょ

367 ：デフォルトの名無しさん：02/08/18 16:55

>>366
で、その多少は複雑になるような実装をあえて選択する理由を聞いているんだけど。
ファイルディスクリプタを使い回すかわりにファイル名を使い回す事で
何がどれくらい嬉しい事になるわけ？

368 ：逝って良しの１：02/08/18 16:57

>>365
ＯＯ以前の　構造化以前の　サブルーチンの組み方から議論してます。

369 ：デフォルトの名無しさん：02/08/18 17:00

>>368
で、君のサブルーチンの組み方はセンス極悪だということがわかったわけだが。

370 ：逝って良しの１：02/08/18 17:05

んでもってFactoryMethodの実装の話に移ると>>369は破綻する。

371 ：デフォルトの名無しさん：02/08/18 17:06

>>362
んじゃ、先々代と代わってくれたまえ

372 ：デフォルトの名無しさん：02/08/18 17:07

>>336
strcpy(dst, src);
read(dst, buf);

これは違う実体を指すんですな？

373 ：デフォルトの名無しさん：02/08/18 17:07

>>.367
　あえて選択する理由って　じゃコードを試しに書いてみてよ
char const PIPENAME="\\MyPC\pipe\PBUF";
　だとして

　片方は
　　int size=ReadFIFO(PIPENAME,void *buf);

　とあちこち好きなように書くだけ。　Open/Closeは勝手にしてくれる

片方は PopeHandle をあちこちで使って、かつOPEN処理/CLose処理を明示しなければいけない

どっちが楽？

374 ：デフォルトの名無しさん：02/08/18 17:09

>>370
ハァ？
ん？

375 ：デフォルトの名無しさん：02/08/18 17:10

>>372
　開いているリソースを頻繁に再度開くような事が多いなら
　ポインタで比較して一致すれば　OK でなければ文字列比較とすれば？
　逆に　滅多に一致しないなら　文字列比較だけでやればいいんだし

376 ：デフォルトの名無しさん：02/08/18 17:13

type fd = open_and_lock(PIPENAME);
int size = bufsize;
size = read(fd, buf, size);
close_and_unlock(fd);

排他制御出来なきゃ使い物にならねーだろ。
それから、open/closeのおまじないを１度ずつ呼び出すだけで、
検索による時間ロスが解消できる。

PIPENAMEを取り回す手間と、fdを取り回す手間も全くかわらん。

377 ：デフォルトの名無しさん：02/08/18 17:14

>>373
君はそれを「あちこち好きなように」書くのか？
普通、そういう外部とのやりとりは一箇所にまとめておくものだぞ。
ループの前と後にそれぞれfopenとfcloseを書くのをサボるためだけに
ループの内部でopen処理とclose処理をするのか…驚愕というか凶悪だぞ、それは。

378 ：デフォルトの名無しさん：02/08/18 17:20

>>376
　それはだからReadFIFOの実装じゃないか
　それの３つをライブラリとして提供するより　一つの方が楽だろいう事

>>377
　外部との通信をまとめておくよ。　だからそのモジュールとのインターフェースは
　一つの方がいいんじゃないの？

　逆に >>376 のようなのをあちこちバラ撒くよりよいだろ？

379 ：デフォルトの名無しさん：02/08/18 17:24

つまりは、ハイレベルかローレベルかって問題の話をしてるのか？

380 ：デフォルトの名無しさん：02/08/18 17:24

>>378
全然話が通じてない (苦笑

open();
while ... {
　read();
　...
}
close();
と、
while ... {
　open_and_read();
　...
}
で、どれだけの違いがあるというんだ？
open();とclose();だけだろ？
たったそれだけのために、毎回openとcloseを繰り返すのか？
上記のように1つの関数にまとめたとしても、やってる事は
while ... {
　open();
　read();
　close();
　...
}
と同じだぞ？

381 ：デフォルトの名無しさん：02/08/18 17:28

ハイレベルでも名前で管理はしないだろ

382 ：380：02/08/18 17:28

すまそ、ちょっと舌足らずだった。

> で、どれだけの違いがあるというんだ？
> open();とclose();だけだろ？
> たったそれだけのために、毎回openとcloseを繰り返すのか？

は、

で、どれだけの違いがあるというんだ？
open()とclose()を書く手間を省略できるというだけだろ？
たったそれだけのために、read()するたびにopen()やclose()を繰り返すのか？

に読み替えてくれい。

383 ：デフォルトの名無しさん：02/08/18 17:29

>>378
排他制御はどうするんだ？って聞いてるんだが。
いちいちOpen/Closeしてたらその隙に割り込まれる

384 ：逝って良しの１：02/08/18 17:30

エラー処理やらないでwhileかＹＯ！

385 ：デフォルトの名無しさん：02/08/18 17:30

ハイレベルでも、
外部からの入力について現状まで読み込むのたびにopenとcloseを繰り返すのは糞。

386 ：デフォルトの名無しさん：02/08/18 17:31

>>384
外部からの入力について現状まで読み込むのたびにopenとcloseとopenに伴うエラー処理を繰り返すのは糞。

387 ：デフォルトの名無しさん：02/08/18 17:32

>>382
　だから、Readするたびに OpenやCloseするのがどれだけ重いというの？
　そりゃReadってのが１件のReadなら別だけどさ
　FIFOを使うって事は他のプロセスもその間動くわけだろ？

　たとえば、メールを読む関数を提供するのに、いちいちOpenしてRead
　してCloseするようにさせる？

　単に MailRead("メールサーバ名", &MailData) の方が喜ばれるだろ？

388 ：デフォルトの名無しさん：02/08/18 17:33

>>384
エラー処理も考えるのなら、ますますopen操作とread操作は分けたほうが便利だね。

389 ：デフォルトの名無しさん：02/08/18 17:37

判った！
　片方は ReadFIFO だったり MailReadの話をしてる
　片方はどうやら read/writeの話をしているんだ

だから噛み合わない？

390 ：デフォルトの名無しさん：02/08/18 17:37

>>387
さすがお客様の事を第一に考えるＳヨは違いますねぇ…。
そうやって無茶や矛盾を孕んだ設計を PG に降ろして
結局お客様の利益と PG のはかない命を奪い去るのがあなたの仕事なんですねぇ…。

391 ：デフォルトの名無しさん：02/08/18 17:39

>>387
POPサーバからメールを100件取得する時、1件ごとにコネクション張り直す？
特にsshなどによるport forwardingも一緒にする場合なんかも？
普通は一回コネクション張ったら、それを使い回すわな。

392 ：デフォルトの名無しさん：02/08/18 17:39

>>390
>さすがお客様の事を第一に考えるＳヨは違いますねぇ…。
じゃーPGの事を考えて、ReadするたびにOpen/Close呼ぶの？それこそ本末転倒だろ。
俺はPGだし、馬鹿Sヨに苦しめられることもあるけど、けどその論点は間違ってると思うYO!!

393 ：デフォルトの名無しさん：02/08/18 17:40

>>391
　判ったよ。ミスを認めて
MailRead("メールサーバ名", &MailArrayData)

と修正するよ

394 ：デフォルトの名無しさん：02/08/18 17:41

>>387
メールだったらなおさらopenしてコネクションを保持しないとダメだろ

395 ：デフォルトの名無しさん：02/08/18 17:44

>>393
だから、FIFOなんかの場合にはそうやって一括でデータを取ってこれる場合ばかりではないという話なんだが。

396 ：デフォルトの名無しさん：02/08/18 17:44

>>392
なんでReadするたびにOpen/Closeするんだ？
そんなんならあんたの設計でも問題ないが、
普通Openしたら保持しておくだろ。

>>393
取得するメッセージを選択出来ないのか？

397 ：デフォルトの名無しさん：02/08/18 17:46

>>387
readがブロックされてる間はともかく、
openやcloseしてる間は実CPU時間をモロに消費するだろ。
つまり、その分、通信相手のプロセスも遅くなっちまうぞ。

398 ：392：02/08/18 17:46

>>396
>じゃーPGの事を考えて、ReadするたびにOpen/Close呼ぶの？それこそ本末転倒だろ。
…だ、よく読めよ(汗)。俺はOpen/CloseをReadするたびによぶのは反対だ。

399 ：逝って良しの１：02/08/18 17:47

最近の設計ではＯｐｅｎしたらすぐ閉じます。

400 ：397：02/08/18 17:48

すまそ、

> つまり、その分、通信相手のプロセスも遅くなっちまうぞ。

は、

つまり、通信相手のプロセスが進んだからといって、問題なしというわけではない。

に読み替えちくり

401 ：デフォルトの名無しさん：02/08/18 17:48

>>396
　我侭だねえじゃあ第３引数として
MailRead("メールサーバ名", &MailArrayData , mdReadTitle)

MailRead("メールサーバ名", &MailArrayData , mdSelectRead)

402 ：390：02/08/18 17:49

>>393
MailArrayData = MailServerObject.getMail(FilterObject);

なら許す。

403 ：デフォルトの名無しさん：02/08/18 17:53

>>401
んじゃー、削除フラグはどうすんの？
勝手に削除しちゃうとか全く削除出来ないとか？

404 ：デフォルトの名無しさん：02/08/18 17:53

>>401
で、全件取ってくるのは別の関数で実装するのか？
しかも、そのMailRead自体の実装はread(type, hostname, port, buff)で可能なのか？
俺には到底可能とは思えん。

405 ：デフォルトの名無しさん：02/08/18 17:56

>>403
　判ったよ

struct _MailData {
　enum MailAction action; //mdNoOpe mdDelete mdRead mdReadAndDownLoad
・・略・・
}

406 ：デフォルトの名無しさん：02/08/18 17:57

>>404
　もう
MailRead("メールサーバ名", &MailArrayData , mdAllRead)

407 ：390：02/08/18 17:59

>>405
なんで定数とか列挙値とか使うかね。

メールを取って来る基準を設定したオブジェクトを渡せば美しいだろ？

408 ：デフォルトの名無しさん：02/08/18 18:00

>>405
取得と削除同時に出来ないのね。
２度接続するの？

俺の使ってるDTIのpopサーバーだと
接続後すぐログインすると、認証時に数十秒待機させられるんだけど、
その方式だとパフォーマンスに深刻な影響が出るね

409 ：デフォルトの名無しさん：02/08/18 18:01

>>407
さらに言うと、メールを取って来る基準を設定したオブジェクトなり構造体は
取ってきたメールのデータとは別なほうが美しいな。

410 ：デフォルトの名無しさん：02/08/18 18:02

>>408
　なら別のスレッドで実行してくれ

411 ：デフォルトの名無しさん：02/08/18 18:02

>>408
そもそも認証そのものが逝ってよし風の毎回open/closeするread関数では不可能な罠。

412 ：デフォルトの名無しさん：02/08/18 18:05

>>551 英語は必要だから触れておく必要有　

小説は色んな他人の人生を追体験しておくのはやっぱり必要だから

413 ：412：02/08/18 18:06

おっとミス

414 ：デフォルトの名無しさん：02/08/18 18:07

>>352
同意。
どう有効か、どう使えばいいかもわからずに闇雲に叫んでるバカはどうかと思う。

415 ：デフォルトの名無しさん：02/08/18 18:08

>>410
認証側にすごく負担になると思われ。
それに、同一アカウントでは同時に複数ログインできないpopサーバってのも考慮しないと。

416 ：デフォルトの名無しさん：02/08/18 18:09

>>412
どこのスレと間違えたのかしらんが…
(実話ベース以外の)小説で他人の人生の追体験しちゃうのはどうだろう？

それって「ぼくわウルトラマンだど～」と同レベルぽ…。

417 ：デフォルトの名無しさん：02/08/18 18:09

>>405
　もうしょうがない。　じゃあこうだ

MailRead("メールサーバ名", CallBackProc , mdCallBack);

enum MailAction CallBackProc( CMailData & data );

418 ：デフォルトの名無しさん：02/08/18 18:13

>>414
GoF本など、大抵のデザパタ本には、まずパターン名に続いて適用すべき状況と長所と短所を記述してある。
そこをちゃんと理解せずに構造などばかりを読んでいる奴がいかに多いことか。

419 ：逝って良しの１：02/08/18 18:14

ん？なんでネット上のデータの話になってるの？

420 ：デフォルトの名無しさん：02/08/18 18:14

>>417
勝手にコネクション破棄しちゃうの？
リモートメールボックスとかIMAP4の用にコネクション維持したい場合はどうするの？

421 ：デフォルトの名無しさん：02/08/18 18:17

>>420
　そういう場合はこうだ

MailRead("メールサーバ名", CallBackProc , mdCallBack |　mdContinue);

　最後は

MailRead("メールサーバ名", CallBackProc , mdCallBack );

か、プロセス終了時に解放

422 ：デフォルトの名無しさん：02/08/18 18:17

>>420
俺に予想させてくれ。
ズバリ、コネクション維持してる間にしたい事をコールバックで呼び出すと見た！
どう？ >>417

423 ：421：02/08/18 18:19

チ、遅かったか。鬱だ。

424 ：デフォルトの名無しさん：02/08/18 18:20

>>419
ネット上なんて関係ない。
open closeで無視できない負荷がかかる・パフォーマンスに影響が出る例として上げてるだけだろ

425 ：417：02/08/18 18:20

ああ、 CallBackの帰り値のアクションが nop 以外なら
　そのアクションを実行してから呼び返される仕様ね
　nopなら次のデータを受信するまで待つと

426 ：423：02/08/18 18:20

間違った。俺は421じゃなくて422だ。もっと鬱になってきた

427 ：デフォルトの名無しさん：02/08/18 18:30

構造化厨は自分で設計もできずに人の言いなりになる人種だという事が判明しました。

言いなりにすらなれない COBOLer あがりよりはマシだから安心しなさい。

428 ：デフォルトの名無しさん：02/08/18 18:41

まとめ

MailRead("メールサーバ名", &MailArrayData , mdAllRead) 　で全件取得
MailRead("メールサーバ名", &MailArrayData , mdReadTitle|mdContinue) でタイトル取得
その後、
MailRead("メールサーバ名", &MailArrayData , mdExecAction) 読/削除/して解放

コネクションを貼りつづけたい場合は別スレッドで
MailRead("メールサーバ名", CallBackProc , mdCallBack|mdContinue);
　とすれば1件毎にCallBackされる

ふう。　どうだ！

429 ：デフォルトの名無しさん：02/08/18 18:47

>>428
＞別スレッドで

ハン！エレガントさに欠けるな。

430 ：デフォルトの名無しさん：02/08/18 18:57

>>429 じゃ OOで設計すると　これだけ効率的で再利用可能なのが出来るってのを魅せてくれ

431 ：デフォルトの名無しさん：02/08/18 19:16

そろそろできたかな～。
きたいあげ♪

432 ：デフォルトの名無しさん：02/08/18 19:24

CMailer mailer = new OpenPOP("鯖名");

int cnt=mailer->getSubjCount();
for(int i=0 ;i<cnt;i++){
CString subj =　mailer->GetSubject(i);
　・・・略・・・
}

433 ：逝って良しの１：02/08/18 19:44

public class AccessPool{
　private　Bool 　Open( FILE *fd );
　private　Bool Close( FILE *fd );
　private　int　Read( FILE *fd );
　public　　int ReadFile( char *file_name,void *buf );
}

434 ：逝って良しの１：02/08/18 19:51

訂正
private　int　Read( FILE *fd,byte *buf );

435 ：デフォルトの名無しさん：02/08/18 19:55

>>433
　それは　何？　って聞かないと始まらないんだけどさ

　なんかもう頭痛いんだけど・・・・・

436 ：デフォルトの名無しさん：02/08/18 19:57

s/AccessPool/AccessThwarter/

437 ：逝って良しの１：02/08/18 20:01

//一度アクセスしたファイルヂスクリプタを保持し、使いまわすクラス
//ヂスクリプタを抱えて右往左往する負担から解放されるれ。

438 ：デフォルトの名無しさん：02/08/18 20:04

>>437
馬鹿じゃないの。

439 ：デフォルトの名無しさん：02/08/18 20:04

なんつーか…
File file = new File("name");
file.read(buf);
の方がよっぽどスマートだが。

440 ：デフォルトの名無しさん：02/08/18 20:05

ネタじゃなかったのかよ。

441 ：逝って良しの１：02/08/18 20:05

過去ログみちくれ。

442 ：デフォルトの名無しさん：02/08/18 20:06

もぅこのシリーズもおしまいのにおい

443 ：終了：02/08/18 20:08

逝って良しの１は病気になった。

444 ：＝＝再利用＝＝：02/08/18 20:12

＝＝再利用＝＝

445 ：デフォルトの名無しさん：02/08/18 20:15

　こうだろ
struct{　・・略・・} FilePoo[66];

int findFilePool(char *fname); //既にプールされてたらその配列番号を　でなければ負数を
int newFilePool(char *fname); //プールの空番地を　なければ一番古いプールを消せ

446 ：逝って良しの１：02/08/18 20:18

関数は一個にまとめたほうが美しいな。

447 ：デフォルトの名無しさん：02/08/18 20:18

やっぱり66なのか。

448 ：逝って良しの１：02/08/18 20:51

右往左往厨はネタかと思ったけど、必死に貶してるところを見ると本気か？

そういうハンドラとかシステム寄り/ハード寄りのものは下層に封印して
上層は人間が把握しやすい様に作るべきなのだよ。

449 ：デフォルトの名無しさん：02/08/18 21:37

せめてこうだろといいたいんだろ？

class {
char fname[_MAXFILESIZE];
FILE *fd;
　Bool 　Open( );
　Bool　 Close( );
　　int　　Read( void *buf );
　public　　int ReadFile( char *file_name,void *buf );
}

450 ：逝って良しの１：02/08/18 21:46

どうなんだろ？
煽ってるヤシは無知を晒すのを怖がって理由も書かないし・・・

451 ：デフォルトの名無しさん：02/08/18 21:53

> 無知を晒すのを怖がって理由も書かないし

そりゃ君を見てれば自身満々に間違った事書いてたら恥かしいなって
誰だって考えるようになるよ。

452 ：デフォルトの名無しさん：02/08/18 21:57

C++ライブラリの三大？？？の1つ、
ストリームを知らんのか？ここにタムロしてる衆は！

453 ：デフォルトの名無しさん：02/08/18 21:58

それとも、ファイル・システムを題材にした？？？なパターン本をﾈﾀにしてるとか？

454 ：デフォルトの名無しさん：02/08/18 22:02

>>452
アホか。

455 ：逝って良しの１：02/08/18 22:04

↓これが発端です。

274 ：デフォルトの名無しさん：02/08/18 01:19
>>270
あんたOOダメっていうけど、
たとえばファイル操作のライブラリをあんたが設計するとしたら、
どんな形態にするよ？

456 ：デフォルトの名無しさん：02/08/18 22:06

>>455
そうだよな。
FILE使わないと同時に開けるファイルは1つだけになりそうだな。
ああ、ファイルIDとか。でも、IDもオブジェクトの識別子になりうるしなぁ。

457 ：デフォルトの名無しさん：02/08/18 22:07

んなん、mmapしてメモリ読み書きするOODB的解の方がよかろうよ
＃根拠なし

458 ：デフォルトの名無しさん：02/08/18 22:09

mmapって、ファイルの末尾追加的な意味の
バッファオーバーライトって、してもいいの？

459 ：デフォルトの名無しさん：02/08/18 22:59

>448
> そういうハンドラとかシステム寄り/ハード寄りのものは下層に封印して
> 上層は人間が把握しやすい様に作るべきなのだよ。

それがやりやすいのがオブジェクト指向ではないですか？

460 ：逝って良しの１：02/08/19 00:18

そういう決め付けは良く無いと思います。

461 ：デフォルトの名無しさん：02/08/19 00:27

問題点を局所化できるのがオブジェクト指向なのでは・・・？

462 ：デフォルトの名無しさん：02/08/19 00:30

>>459
俺も思った。

例えば１チップマイコンの１ビットのメモリをラップするクラスを作る（効率悪いのは承知）。
それを継承させてメモリマップドIOクラス、さらにタイマークラスなどの周辺機器クラスを実装する。
他のマシンに移植する場合はもっとも規定のクラスを差し替えるだけでいい。みたいな。

463 ：デフォルトの名無しさん：02/08/19 00:32

思うのはいくらでもできますしねぇ

464 ：デフォルトの名無しさん：02/08/19 00:38

>>463
出来ない理由ってある？
資源さえ豊富にあれば出来ると思うけど。

465 ：デフォルトの名無しさん：02/08/19 00:39

>>463
ここの意見の半分が「思ってる」ことだと思うのは気のせいか？

466 ：デフォルトの名無しさん：02/08/19 00:47

世の中「絶対」は無いよ

467 ：デフォルトの名無しさん：02/08/19 01:17

>>462
昔キミの言っていたような実装に関する書籍を見たことがある。
またOSをOOで実装することに関する書物も見たことがある。
そのどちらの書籍も今では絶版となっている。

468 ：デフォルトの名無しさん：02/08/19 01:21

>>467
良い考えだと思ったんだけどね。ｗ

まぁ、青色ダイオードの例もあるんで研究がてら個人的に試してみますわ。

469 ：デフォルトの名無しさん：02/08/19 02:13

じゃあ問題

オブジェクト指向の定義を述べよ。

470 ：デフォルトの名無しさん：02/08/19 02:20

継承
多態
カプセル化

471 ：デフォルトの名無しさん：02/08/19 02:28

>>461
それは「うまくクラス分けできれば」という重要な条件が付くけどな。

472 ：デフォルトの名無しさん：02/08/19 02:30

>>471
それは非オブジェクト指向でも同じだろう。
「うまく設計できれば」オブジェクト指向なんかよりもイイってことになる。
っていうか「うまくクラス分けができない」場合なんて考えてたら議論にならないじゃん。
PGの技術によるんだし(もちろん、クラス分けが非常に困難だというなら議論の余地はある)。
水掛け論だと思うよ、それは。

473 ：デフォルトの名無しさん：02/08/19 02:35

>>472
ほう。非オブジェクト指向で「クラス分け」なんてのがあるのか。
というか、そもそもクラス分けをお前のところではPGにやらすのか？
まぁ凄腕のPGならまかせられるが、そのレベルだと年俸1000万は
普通に超えてるレベルだよな。

474 ：デフォルトの名無しさん：02/08/19 02:37

(´･ω･`)オブジェクト指向とかUMLとか一生懸命勉強したのに・・・。ｼｮﾎﾞｰﾝ

475 ：デフォルトの名無しさん：02/08/19 02:41

年俸が関係あるのかなあ・・

476 ：デフォルトの名無しさん：02/08/19 03:30

>>433
君さ、
> 　private　Bool 　Open( FILE *fd );
って… openするのに FILE *渡してどーすんだよ！
マジでこいつセンス以前の問題だ。

477 ：デフォルトの名無しさん：02/08/19 03:33

>>469
メッセージを受けることで動作するオブジェクトを中心にして
分析/設計/実装における記述を行なう事。

478 ：デフォルトの名無しさん：02/08/19 03:38

>>477

訂正しときます。

メッセージを受けることで動作するオブジェクトを中心にして
”自己満足的”な分析/設計/実装における記述を行なう事。

479 ：デフォルトの名無しさん：02/08/19 03:52

>>478
うわ、アンチのオナニー現場を見てしまった！
きもちわりぃ～

480 ：デフォルトの名無しさん：02/08/19 04:18

>>473
OOを有効に実行しようとしたら、PGだのSEだの分業したりしないだろ。
PGが分析/設計に参画するのが当然だ。

481 ：デフォルトの名無しさん：02/08/19 04:20

>>449
MAXFILESIZE？なんじゃそりゃ、ファイルサイズとは関係ねーだろ。
せめてMAX_NUM_FILE_DESCRIPTORぐらいにしとけ。

482 ：デフォルトの名無しさん：02/08/19 04:23

>>428
それらの関数を、逝ってよし流のreadするたびにopen&closeするRead関数で実装してみてくださいな。

483 ：デフォルトの名無しさん：02/08/19 04:43

おまいらがOOにあたって使用してる分析手法って何ですか？

484 ：デフォルトの名無しさん：02/08/19 06:24

>>483
直感、オブジェクト指向的直感。

485 ：逝って良しの１：02/08/19 06:37

>>476
細かい事は気にしない様に。
大意さえ伝われば良い。

486 ：デフォルトの名無しさん：02/08/19 06:56

>>485 最初から>>449で　ひとつだけ間違ってるなら大意も伝わるが・・・

487 ：逝って良しの１：02/08/19 07:03

ちょっと違う。
同時にopen可能にして状態を記録しておく（Pool）つもりだった。

488 ：逝って良しの１：02/08/19 07:09

デザパタ用語使ってやったのに通じないじゃん。
誰だよ用語使えば意志疎通がスムーズになるとか言ってた奴は。

489 ：デフォルトの名無しさん：02/08/19 07:24

>>488
相手がその用語を知らなければ意思疎通できないのは
デザパタに限った話ではあるまいに。

490 ：デフォルトの名無しさん：02/08/19 07:36

先　々　代　の　逝　っ　て　よ　し　の　１　は　ま　だ　で　す　か　？
　　　　　　　　正　直　、　話　に　な　り　ま　せ　ん　。

491 ：デフォルトの名無しさん：02/08/19 09:55

>>488
あの用語自体が意思疎通が難しいように設定されている。
FlyWeightなんぞあれ見るまで聞くこと無かった。
アーケードは近所の寂れた商店街しか想像できん。

492 ：デフォルトの名無しさん：02/08/19 10:12

>>487　それならなおさら駄目だろ
class {
char fname[_MAXFILESIZE];
FILE *fd;
　Bool 　SaveHandle(char *fname,CFileHandle handle );
　Bool 　FindHandle(char *fname,CFileHandle & handle );
　public　　int ReadFile( char *file_name,void *buf );
}

493 ：デフォルトの名無しさん：02/08/19 11:58

>>448
用語以前の問題なんだけど

494 ：デフォルトの名無しさん：02/08/19 12:18

>>493
必死だな。

495 ：デフォルトの名無しさん：02/08/19 12:56

OOが戦場で必要かって？
必要なわけないだろ！
以前J社のシステムをOOで開発したことあって
クラス設計がよくされてはいたのだが、
それでも冗談かと思うくらい複雑だった。鬱になったよ。
結局あれ以来フラットな設計の方が分かりやすいし、
戦場では有効な手法だというのがよく分かった。
結局はOOなんて小さいプログラムをチマチマ設計して
自己満足しているPGのためのものだよ。

496 ：デフォルトの名無しさん：02/08/19 13:05

>>495
才能のない人はみんなそう言うよ

497 ：デフォルトの名無しさん：02/08/19 13:09

>>495
こういうのは土方逝き決定ですな。
ついでに、分析手法もよく分かってないくせにデザインパターンと
連呼するヤシは土方にも使えんからな。逝ってよし。

498 ：デフォルトの名無しさん：02/08/19 13:37

>>496 >>497
理論武装はしても現実が見えてない人が数名います。

499 ：デフォルトの名無しさん：02/08/19 13:39

>>498も該当。

500 ：デフォルトの名無しさん：02/08/19 13:49

>>495
分かってないﾔｼに限って「複雑」っていうんだよ。
ちゃんとクラス図見た？

501 ：デフォルトの名無しさん：02/08/19 13:57

まだやってるのかよ？
パート２くらいでOOは戦場では使えないって結論でたんじゃないのか？
よほどOO厨房がムキになってるんだな。ﾌﾟ

502 ：デフォルトの名無しさん：02/08/19 13:59

にわかSEにはOO勧められないな。

503 ：デフォルトの名無しさん：02/08/19 14:23

どうやらアンチは逝ってよしAPIがお好みのようで。
ま、その時点で、OOがどうとかデザパタ用語がどうとか
そういう次元じゃないですな。

504 ：デフォルトの名無しさん：02/08/19 14:26

＞どうやらアンチは逝ってよしAPIがお好みのようで
じゃあOSつかうなや。と。

OO厨だが普通にむかついた。

505 ：デフォルトの名無しさん：02/08/19 14:34

>>504
お前の使っているWindowsはOOで開発されていることを忘れるな。

506 ：デフォルトの名無しさん：02/08/19 15:01

>>504
君も、readするたびに毎回read関数内でopen&closeさせたいわけ？

つーか、君がどんなOS使ってるのか知らんが、
普通のOSはopenやcloseとreadは別に用意されていると思うが。
少なくともreadするたびに内部でopen&closeするようなOSを使いたいとは思わん。
だって、そんなんじゃnetwork上での双方向通信すらマトモにできないじゃん。
コネクション張ってHELLOを受けたらいきなり切断しちまったら困るんだよ(藁

507 ：デフォルトの名無しさん：02/08/19 15:14

>>1 - >>506
んで、結論はなんなのよ？
オブジェクト指向は戦場で効率よく開発できるの？　できないの？

508 ：デフォルトの名無しさん：02/08/19 15:16

>>507
優れた設計者と優れたプログラマが使えば効率よく開発できる。

509 ：デフォルトの名無しさん：02/08/19 15:17

>>506
その後、ファイルディスクリプタをキャッシュして
毎回open&closeするわけじゃないとかいう弁解らしきものをしてたがな。

で、キャッシュされたファイルディスクリプタをファイル名で引くらしいが、
まずOSレベルでそれやるのはアフォだし、
ユーザライブラリでやるにしても、同一ファイルを複数のスレッドが読んだりしたら
ちゃんとファイルディスクリプタで区別してやらないと滅茶苦茶になるわな。

それに、ソケット使うときはどうすんだ？
同じホストの同じポートにコネクション張りにいったら全部同じコネクション共有することになっちまうだろ。

やはり逝ってよしAPIはタコということで。

510 ：デフォルトの名無しさん：02/08/19 15:18

>>507
素人が使うとめちゃくちゃになる。
プロが使うと効率よく開発できる。

511 ：デフォルトの名無しさん：02/08/19 15:21

俺、戦場こそＯＯが発揮できると思う。
いきなり戦場でＯＯを使って設計するバカはいないだろうが。

ＯＯっていうのは資産なんだよ。
んなん、わずか数個のプロジェクトでＯＯが発揮できるかと言うと
無理に決まってる。

バカとＯＯは使いようっていうではないか？
効率を考えるなら使わない手は無いね。

512 ：デフォルトの名無しさん：02/08/19 15:25

>>509
ここだけ読んで話のスジが読めてないのでズレるかもしれんが、

>で、キャッシュされたファイルディスクリプタをファイル名で引くらしいが、

こういうのはポインタで管理したりしてないの？

513 ：デフォルトの名無しさん：02/08/19 15:27

>>512
ポインタだと同じになることあるし

514 ：デフォルトの名無しさん：02/08/19 15:28

>>510
この回答は本当に飽きたよ。
プロが使えばっていう前提の答えは、”逃げ”としか見えない。

515 ：デフォルトの名無しさん：02/08/19 15:29

>>513
ﾊ?

516 ：デフォルトの名無しさん：02/08/19 15:33

話の流れを追えないバカ>>473

「クラス分け」が年棒1000万円に値する高等技術だと思っている時点で終わってる。コイツのまわりもバカばっかりなんだろうな。

517 ：デフォルトの名無しさん：02/08/19 15:36

>>516
お前よりは賢いと思うけどね。

518 ：デフォルトの名無しさん：02/08/19 15:36

>>512
まあ、ポインタでも文字列比較でもいいんだけどさ、そんな面倒な事するぐらいなら
どう考えてもread関数にはファイルディスクリプタ渡してやったほうがいいわな。
ファイル名とファイルの実体は1対1対応ではないし、
1つのファイルについて複数のディスクリプタ使うことだってあるし。

519 ：デフォルトの名無しさん：02/08/19 15:38

>>514
逃げ？真実だと思うよ。
道具ってのはプロが使ってはじめてその真価が発揮されるってものさ。
技術力が低いものが高度な道具を使っても使いこなせるわけがない。

520 ：デフォルトの名無しさん：02/08/19 15:40

>>516
つーか、生兵法なクラスの切り方と、熟練者の仕事はちゃんと区別しないとな。
本当の熟練者であれば年棒1000万ぐらい取っても何の不思議もない。

521 ：デフォルトの名無しさん：02/08/19 15:41

ほとんどのOOプログラマを名乗ってる奴は、何も考えずに
メンバとメソッドを固めてクラス作るだけの奴が多くないか？
それ以上の設計の話となると、ほとんどの奴が俺様流の解釈
でやってるし、ある程度の規模以上で継承やらからんでくると
になると異常に複雑になったり、結局OOというものは導入すると
コストがかかると思うよ。

522 ：デフォルトの名無しさん：02/08/19 15:44

けーしょーって戦場では必要なくない？

523 ：デフォルトの名無しさん：02/08/19 15:45

>>521
典型的な生兵法ですなあ

524 ：デフォルトの名無しさん：02/08/19 15:47

>>522
本気でそう思っているのなら、eiffelをお勧めする。
flatコマンドで全ての継承関係をなくし、全てのクラスをフラットにできる。

525 ：デフォルトの名無しさん：02/08/19 15:47

OOのプロジェクト成功への格言

「　失　敗　し　な　け　れ　ば、　成　功　す　る　」

以上

526 ：デフォルトの名無しさん：02/08/19 15:49

>>525
OO以外でも同じ事をOOだけであるような言い方はやめなされ。

527 ：デフォルトの名無しさん：02/08/19 15:51

>>524
すごい！
いや委譲の方が戦場向きかなって思っただけです。

528 ：デフォルトの名無しさん：02/08/19 15:52

>>526
そう？
下のような意見もOO以外の話でも当たり前だろって突っ込みたいけどね。

> ：デフォルトの名無しさん本日の投稿：02/08/19 15:16
> >>507
> 優れた設計者と優れたプログラマが使えば効率よく開発できる。

> 510 名前：デフォルトの名無しさん本日の投稿：02/08/19 15:18
> >>507
> 素人が使うとめちゃくちゃになる。
> プロが使うと効率よく開発できる。

529 ：デフォルトの名無しさん：02/08/19 15:54

>>528
そうだよ。OOでもOO以外でも当たり前。そしてOOでもOO以外でも正しい。

530 ：デフォルトの名無しさん：02/08/19 16:07

>>529
同意だな。
結局、その辺の議論は定量的にやらないと意味ないんだが、
こんな所ではそれは無理な注文だな (藁

531 ：デフォルトの名無しさん：02/08/19 16:08

　　　　　 ∧＿∧　 ∩　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　´Д｀）／/　　＜　先生！
　　　　　／　　　ノ　　　　｜　ＨＳＰは戦場で使えますか？
　＿＿ | .|　　　 |　＿_ 　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　＼　￣￣￣￣￣　　＼
　　||＼　　　　　　　　　　　＼
　　||＼||￣￣￣￣￣￣￣||￣
　　 .　 ||￣￣￣￣￣￣￣||

532 ：デフォルトの名無しさん：02/08/19 16:10

>>531
・・・何言ってんの？

533 ：デフォルトの名無しさん：02/08/19 16:13

>>531のようなﾔｼにOOやらせるのと非OOやらせるのと
どちらが効率がいいだろうか・

534 ：デフォルトの名無しさん：02/08/19 16:14

>>533
切るのが一番効率よさそうだな…

535 ：デフォルトの名無しさん：02/08/19 16:16

>>534
同意。

536 ：デフォルトの名無しさん：02/08/19 16:17

>>531 HSP は超高級言語の仲間だね

一般的に戦場で有効なのは
　　オブジェクト指向のような同じ言語で低レベル処理から高レベルまで書くより
　　言語を別けてしまう手段の方が有効だね

　だから、HSPも使うのは良い手段だと思う

537 ：デフォルトの名無しさん：02/08/19 16:19

超高級言語ってなんだよ？

538 ：デフォルトの名無しさん：02/08/19 16:21

>>537
マシン語とは逆方向、の意

539 ：デフォルトの名無しさん：02/08/19 16:21

開発と言うより、開発に必要なツールを作るくらいなら使って見てもいいかもね。>HSP

540 ：デフォルトの名無しさん：02/08/19 16:23

>>538
高級言語というだけでいいだろ(笑)
度合いを表す言葉じゃないし。

541 ：デフォルトの名無しさん：02/08/19 16:23

低水準言語　　ASM C/C++/Delphi
　高級言語　　C/C++/LISP/Delphi
超高級言語　HSP/VB/Perl.Ruby

542 ：デフォルトの名無しさん：02/08/19 16:25

>>541
かぶってるぞ。

543 ：デフォルトの名無しさん：02/08/19 16:26

Very High Level Language
Perlの本で始めてみたけど、向こうでは一般的に使われてるんじゃない？

544 ：デフォルトの名無しさん：02/08/19 16:28

こうだろ

低レベル記述可能言語 ASM C C++ Delphi
高レベル記述可能言語 C++ Delphi LISP
高レベルのみ記述言語　HSP VB Perl Ruby

545 ：デフォルトの名無しさん：02/08/19 16:28

>>544
かぶってるぞ

546 ：デフォルトの名無しさん：02/08/19 16:29

JavaやC#も加えてくれ。

547 ：デフォルトの名無しさん：02/08/19 16:32

>.>545
　いいんだよ。
　　そもそも C++ とかは　低レベルから高レベルまで記述出来るのがコンセプトなんだろ？

548 ：デフォルトの名無しさん：02/08/19 16:33

>>547
何でも出来るようにしようとして破綻した言語。

549 ：デフォルトの名無しさん：02/08/19 16:34

>>548 じゃDelphiは？　第２世代から第４世代までカバーと盛りだくさんだぞ？

550 ：デフォルトの名無しさん：02/08/19 16:35

>>549
の割にはまとまっている言語。しかし、融通の利かない局面多し。
良くも悪くもC++になれなかった言語。

551 ：デフォルトの名無しさん：02/08/19 16:37

>>550
Pascalと違ってDelphi言語は　融通利きまくりだが？
　どんな面が融通利かないと？

552 ：デフォルトの名無しさん：02/08/19 16:38

>>551
メリットばっかり言い過ぎるとDel厨としてまともな意見として扱われなくなるんでねｗ

553 ：デフォルトの名無しさん：02/08/19 17:03

そろそろ ObjectHSP が発表されるんだけどそれはどう思う？

ObjectPerl みたいなもんだよね？それってRubyじゃん？
つまりそれなりにきちんとした（しかも敵の多い）言語になるのかな？

554 ：デフォルトの名無しさん：02/08/19 17:03

でお前ら宿題はやったのか？

555 ：デフォルトの名無しさん：02/08/19 17:05

>>554
7月のうちに全部終わらせたよ！ｴｯﾍﾝ

556 ：デフォルトの名無しさん：02/08/19 18:15

オブジェクトといっても、関数よりは大きく、プロセスよりは
小さい粒度の単位を導入しただけで、何でもオブジェクトに
しようとすれば破綻を来すのは明らか。
小さいtrivialなデータをクラスにしても、関数書く手間が
増えるだけで、生産性が上がる訳が無いのに。
その意味で、JavaのVectorだのwrapper classなんてのは反面教師で。
もっと粒度の小さい、generic programmingでアプローチするところ。
その方がお手軽高速かつ安全。その割に、クラスより大きいはずの
モジュールをMathみたいなクラスにしてるんだよなあ。

557 ：デフォルトの名無しさん：02/08/19 18:15

>>556
Mathはアホだと思った。

558 ：デフォルトの名無しさん：02/08/19 18:16

http://www.gassan.co.jp/s.es.tasiro/

参考までに

559 ：デフォルトの名無しさん：02/08/19 18:43

>>556
これで「JavaとCとC++を知ってる」と言い張れる、その度胸が気に入ったッ！

560 ：デフォルトの名無しさん：02/08/19 19:19

要は戦術などどうでもよいのだ。
OOだろうが、非OOだろうが、
ちゃんとした戦略に乗っ取って
それにそった戦術を選択すればいいだけなのだ。

語れ

561 ：デフォルトの名無しさん：02/08/19 19:19

>>1は俺の友達です。

562 ：デフォルトの名無しさん：02/08/19 21:15

OOと非OOの実用例語り合ったらどうよ.

563 ：デフォルトの名無しさん：02/08/19 21:15

>>562
さぁ、どうぞ。

564 ：デフォルトの名無しさん：02/08/19 21:17

散々OOをこけにしてきたが、実用例はないなぁ
すまねぇ。

565 ：デフォルトの名無しさん：02/08/19 21:31

>>562
じゃあWebシステムは題材としてどうよ？

566 ：デフォルトの名無しさん：02/08/19 21:32

>>565
まぁた広いお題を。

567 ：デフォルトの名無しさん：02/08/19 21:34

俺が悪かったって言ってるだろ？
確かに俺はオブジェクト指向なんぞこれっぽちもしらねぇし、
VB厨だしC厨だ。
デザパタだって少しかじったばっかりだ。
でもこんな俺でもオブジェクト指向の凄さに触れたいんだ。
悪かった！って！煽ったのはちょっとだけだろ？許せーよ。

568 ：デフォルトの名無しさん：02/08/19 21:39

>>567
VBやCでオブジェクト指向してますが何か？

569 ：デフォルトの名無しさん：02/08/19 21:40

>>567=逝って良しの1

570 ：逝って良しの１：02/08/19 21:41

>>492
ダメ。上の二つはReadFile()ルーチンの最初の方に持って行くべき。

571 ：デフォルトの名無しさん：02/08/19 21:44

>>541
低水準言語　　ASM C/C++/Delphi
　高級言語　　C/C++/LISP/Delphi/VB
超高級言語　Perl/Ruby/Python
　　　　糞言語　HSP/ひまわり/TTS/Uva

572 ：デフォルトの名無しさん：02/08/19 21:46

>>571
だからJavaとC#を入れてくれよ。

573 ：デフォルトの名無しさん：02/08/19 21:47

>>572
低水準言語　　ASM C/C++/Delphi
　高級言語　　C/C++/LISP/Delphi/VB
超高級言語　Perl/Ruby/Python/Java/C#
　　　　糞言語　HSP/ひまわり/TTS/Uva
超超高級言語　 Ocaml/Haskell/StandardML

574 ：デフォルトの名無しさん：02/08/19 21:48

悪かった！ほんとすまねぇ。
おまえらもう低脳な争いやめようぜ。
だってよ。ほんとはおまえらがうらやましかったんだ。
OOを理解しつくしてるおまえらが。
俺は低脳だからどうしても理解できんのだ。すまねぇな。
だからおまえら休んでください

575 ：デフォルトの名無しさん：02/08/19 21:51

>>571
それ間違ってる。TTSが糞言語に入ってるのは違うね。これを見てくれ。
http://pc3.2ch.net/test/read.cgi/tech/1015170837/390

TTSは超高級言語だぞ！

　　　　　　　　　　　　　　　　　　　　　　　　色んな意味でな。

576 ：デフォルトの名無しさん：02/08/19 21:52

>>573
あとは理由があれば完璧だな。

577 ：デフォルトの名無しさん：02/08/19 21:55

だからもうおまえらもうやめてくれよもう。
不毛な争い楽しいかって！
悪かったって言ってるだろ？
デザパタのクラス図見てもさっぱりわからんし、
実際プログラム自体ほとんど書いてねぇよ。童貞だしな。
もうやめてくれぽ

578 ：デフォルトの名無しさん：02/08/19 21:59

>>577
ん？お前だれ？

579 ：デフォルトの名無しさん：02/08/19 22:05

プラグらむんむんｷﾞｬﾊ-
http://pc3.2ch.net/test/read.cgi/tech/1029320804/
の1でございますが、何か？

580 ：デフォルトの名無しさん：02/08/19 22:38

　俺がOOマニア野郎が嫌いな点はさ、
　結局さ
　なんかさ、
　　OOすればプログラムが自然に作れる　かのような言動に尽きるんだよ

　一昔前は、やっぱり構造化マニアみたいなのがいて同じような感じだった
　が、OOマニアは【お勉強】してるだけタチが悪い

581 ：デフォルトの名無しさん：02/08/19 22:46

>>580
そんなバカはほっといて自分でちゃんとOOを身に付けろ。

582 ：8 ◆wMOjCT4s ：02/08/19 22:57

OO 知らなきゃ、複雑なプログラミングはできない。

けど、OO 知らなくても出来ることもある。
データベース読み書きするだけの単純なアプリケーションとかさ。

OO マニヤでも意味の無いところでクラスを定義したりはしないもんだよ。

俺にとっての問題は、そんなプログラミングが退屈でたまらんことだ。

583 ：デフォルトの名無しさん：02/08/19 23:00

もうやめてくれ。俺の奪い合いなんて！
やだ！あなたったらぁ！
そこはだめぽですわよ～ん♪

584 ：デフォルトの名無しさん：02/08/19 23:02

>OO 知らなきゃ、複雑なプログラミングはできない。
できるよ、より一層複雑なのが。そうやって無理矢理作られたCOBOLのシステムをメンテするのが苦痛だ。
うちの社でやった仕事の半分ほどはC++とかに書きなおしたけど、まだ動いてるのも半分ほど…。

585 ：デフォルトの名無しさん：02/08/19 23:06

>>556
何でもオブジェクトにしようとして破綻するのはOO厨(w

586 ：デフォルトの名無しさん：02/08/19 23:15

何でもオブジェクトにするだけの蓄積(OO以外も当然含むよん)持ってないﾔｼはただの厨。

＃つうかOOって、俳句の季語とか、ｵﾔｼﾞｷﾞｬｸﾞみたいに、高度に形骸化した形式持ってる所がｳｻﾞｲ。
＃OO以外の広い知識をもって考えて、最後にOOでモジュール化 or コンポーネント化しる。

587 ：585：02/08/19 23:17

真のOOプログラマは全てをオブジェクトにしても破綻しない。

588 ：デフォルトの名無しさん：02/08/19 23:24

>>586

確かに。
再利用可能なモジュールなんてのは、OOとその作ろうとしているモジュールの分野を極めた者が作るべきものだ。

589 ：デフォルトの名無しさん：02/08/19 23:25

恥ずべき白い汚れは私の黒い陰茎に蓄積します。食べるとき、それがかなりおいしかったので、娘のランチは静かに耐えるために作られました。恩赦は適用されますか、も、そのような、私が逮捕されます?

590 ：デフォルトの名無しさん：02/08/19 23:27

もうやめようよぅ。どうして争うの。。。
なぜなんでどうして？？

591 ：デフォルトの名無しさん：02/08/19 23:28

>>589,>>590 ﾃﾞﾑﾊﾟ様、お帰りはこちらから
http://pc3.2ch.net/test/read.cgi/tech/1029320804/

592 ：デフォルトの名無しさん：02/08/19 23:58

>>591
バカ、誘導先が違うダロ！

>>589-590
電波・お花畑
http://natto.2ch.net/denpa/
へGO!

593 ：591：02/08/20 00:09

>>592
おー、すまなんだ。悪りぃね、手間かけて。

594 ：デフォルトの名無しさん：02/08/20 00:11

>>590
ﾋﾏだから。

それくらい分かってくれよ・・・

595 ：デフォルトの名無しさん：02/08/20 01:45

早く宿題しなきゃ夏休みが終わっちゃうよ！

596 ：デフォルトの名無しさん：02/08/20 07:12

ぷっ

597 ：デフォルトの名無しさん：02/08/20 08:16

>>586
たとえば、どんな所が形骸化してると思うんだろ？

598 ：デフォルトの名無しさん：02/08/20 08:44

>>586
「形骸化している」と自分で判断できるなら、
そんな形式には従わなければよいのではないですか？
あ、人のソース見るときの話かな。
どっかのサイトや本から、理由も知らずに貼り付けたりしてるコードとか？

599 ：デフォルトの名無しさん：02/08/20 17:08

変数はstaticでｸﾞﾛｰﾊﾞﾙで2万行を気合いで管理できる人
尊敬しますが、私の上司でなくなってよかったです

600 ：逝って良しの１：02/08/20 21:07

class {
char fname[_MAXFILESIZE];
FILE *fd;
　private FILE 　*CreateHandle(char *fname )
　private FILE 　*FindHandle(char *fname )
　public　　int ReadFile( char *file_name,void *buf ){
　　　if( (fd = Find Handle(fname)) ==NULL ){
　　　　fd = CreateHandle(fname);
　　　}
　　　...
　}
だろが。

601 ：逝って良しの１：02/08/20 21:11

char fname[_MAXFILESIZE];
は見なかったことにするように。

602 ：デフォルトの名無しさん：02/08/20 21:38

オブジェクト指向分析設計の特徴は、モデリングと実装の分離(あるいは適度に分離できる事)。

実装が変わる度に、要求の充足度合いやモデリングが大きく変化するのを防ぎたい
って場合には向いてる。

逆に、実装＝モデルでいいとか、モデリングできるほど対象の性質がわかっていないとか、
オブジェクト指向ランタイムコードのオーバーヘッドが問題になる程粒度の小さな対象には、
オブジェクトとかコンポーネントって向いていない罠。

OO厨のｲﾀｲ所は、OO適用に都合の良い分野に、自分の仕事の範囲を狭めてるってﾄｺ。
＃昔だとGUIプログラミング～DB～業務系プログラミングとか、
＃最近だとリアルタイム制御とか(Ö)

603 ：逝って良しの１：02/08/20 23:06

オブジェクト指向はもうすぐ死にます。
次はＸＭＬだそうです。
もちろん反対です。

ＭＩＳ→知らない→ＡＩ→マルチメディア→インターネット
→オブジェクト指向→ＸＭＬ

604 ：逝って良しの１：02/08/20 23:07

ＭＩＳ→知らない→ＡＩ→マルチメディア→ＩＴ→オブジェクト指向→ＸＭＬ

と書くべきか

605 ：デフォルトの名無しさん：02/08/20 23:17

>>603
UNICODEを忘れてるよ！

606 ：逝って良しの１：02/08/20 23:24

コピペしてその場所に自分で入れておくれ。

607 ：デフォルトの名無しさん：02/08/20 23:56

>>603
＞オブジェクト指向はもうすぐ死にます。
＞次はＸＭＬだそうです。

XMLでプログラミング！
案外出来そうだから怖いな・・・。

<function name="hoge">
<argment>
<int name="a">
<char name="b">
</argment>
<implement>
a = 30;
<IF dat="a < 30">
print(a);
</IF>
</implement>
</function>

608 ：デフォルトの名無しさん：02/08/21 02:35

>>607
XMLでソース入出力する処理系なんて、とっくに存在しますが。

609 ：デフォルトの名無しさん：02/08/21 18:32

結局Ooが糞といわれるのは、プログラムというよりも
その周辺的な方法論という要素が強いからでなかろうか

610 ：デフォルトの名無しさん：02/08/21 18:35

>>609
使いこなしてないときの出来上がりがひどいからだろ。

611 ：デフォルトの名無しさん：02/08/21 18:49

このスレのOO厨のソースみせてくれよ。
相当ご立派なものをお書上げになってることだろーな。ﾌﾟ

612 ：デフォルトの名無しさん：02/08/21 19:04

>>610
MFC...

613 ：デフォルトの名無しさん：02/08/21 19:06

>>611
どんなのなら立派だと思うんだろうね。OOじゃなくてもいいからさ。(w

614 ：デフォルトの名無しさん：02/08/21 19:29

>>613
またそうやってごまかす(ww

615 ：デフォルトの名無しさん：02/08/21 19:31

アンチのレベルはお粗末だったね（ｗ

616 ：デフォルトの名無しさん：02/08/21 19:41

>>614
誤魔化さないで自分が立派だと思うソースをだせよ。
それと同じくらいのソースなら出してやるから。

617 ：デフォルトの名無しさん：02/08/21 19:42

>>616
リーナスの書いたprintfはすっげーかっこよかった。

618 ：デフォルトの名無しさん：02/08/21 19:51

>>611
見せたら不利になるから絶対に見せられないyo！

619 ：デフォルトの名無しさん：02/08/21 19:57

>>611
なにを見たいのかぜんぜんわからんな。
立派なアルゴリズムなのか、立派なパターンなのか、立派なアプリケーションなのか
立派なif文や立派な継承だったら大笑いだが。

620 ：デフォルトの名無しさん：02/08/21 20:09

>>619
ソースと言っているのに読解力がないのかな？
まぁ、こんな間抜けのソースなど見るだけ無駄だけどね。

621 ：デフォルトの名無しさん：02/08/21 20:11

>>620
ソースの何を見て立派だと判断するんだよ？
立派と判断する基準を言え。

622 ：デフォルトの名無しさん：02/08/21 20:17

ここのOO信者の粗末なソースみてもな・・・。

623 ：デフォルトの名無しさん：02/08/21 20:19

>>622
そんなことは>>611に言ってくれ。

624 ：デフォルトの名無しさん：02/08/21 20:24

>>621
全部。少なくともソースがあれば
> 立派なアルゴリズムなのか、立派なパターンなのか、立派なアプリケーションなのか
> 立派なif文や立派な継承
これらの判断はつく。

でも君のソースはいらない。
判断基準も教えてもらわないと解らない厨房ソースなど
荒らしのコピペと大して変わらない

625 ：デフォルトの名無しさん：02/08/21 20:29

立派なソースってのは悪い所が無いソース。
つまり普通のソースってことだ。

普通のソースよりも良いソースが立派なソース？
そんなこと言われてもその基準は人によってまちまちだから
普通のソースじゃんっていわれるのがおち。

626 ：デフォルトの名無しさん：02/08/21 20:30

OOというのは自分なりの方法で分析して設計するものだから
他人のソース見てもあまり参考にならないと思うよ。>アンチOO

627 ：デフォルトの名無しさん：02/08/21 20:31

>>626
OOにかぎらない。

628 ：デフォルトの名無しさん：02/08/21 20:39

このスレのアンチOO厨のソースみせてくれよ。
相当ご立派なものをお書上げになってることだろーな。ﾌﾟ

629 ：デフォルトの名無しさん：02/08/21 20:40

ふーん、OO厨って
「自分のソースは酷いので他人に見せられない」
っていうのは自覚してるんだね。
また、人並みの羞恥心も存在するんだね。

なのになんでOO厨って態度でかいの？

630 ：デフォルトの名無しさん：02/08/21 20:41

ふーん、アンチOO厨って
「自分のソースは酷いので他人に見せられない」
っていうのは自覚してるんだね。
また、人並みの羞恥心も存在するんだね。

なのになんでアンチOO厨って態度でかいの？

631 ：デフォルトの名無しさん：02/08/21 20:43

>>629
でもアンチOO厨もソース見せられないんだろ。同じじゃん。
言い訳はいーからソース見せてから言ってね～。

632 ：デフォルトの名無しさん：02/08/21 20:47

定義聞いてその場をごまかすのってネットニュースの嵐が使う手じゃん（ｗ

633 ：デフォルトの名無しさん：02/08/21 20:49

> OOというのは自分なりの方法で分析して設計するものだから
でもレスは全然「自分なりの方法」ではないね(w
>>629-630 みたいに

634 ：デフォルトの名無しさん：02/08/21 20:52

>>633
知らないかもしれないから念のために言っておくけどOOとレスは全然違うよ。

635 ：デフォルトの名無しさん：02/08/21 20:56

ソースソースっていうけどソース１つじゃ
判断できなくない？OOもアンチも。。。
まとまった処理をするための
すべてのソースをみせるべき？

636 ：デフォルトの名無しさん：02/08/21 20:59

>>631
はい

ギコBASIC
http://www.geocities.co.jp/SiliconValley-Oakland/8522/data/ugikoscr.txt

で、これをOOで書くとどうなるの？

637 ：デフォルトの名無しさん：02/08/21 21:06

>>636
ふーん。他人が書いたやつでもいいのか。
なんかネタを探して「これを非OOで書くとどうなるの？」って言うだけでいい？

638 ：デフォルトの名無しさん：02/08/21 21:08

>>637
> なんかネタを探して「これを非OOで書くとどうなるの？」って言うだけでいい？
いいよ、でもまずは>>636をOOで書いてからな。

639 ：デフォルトの名無しさん：02/08/21 21:13

>>638
その前にギコBASICを完全に非OOにしてね。

640 ：デフォルトの名無しさん：02/08/21 21:14

OO厨は素直に>>1の言うように、OOはクソだと
認めればいいのに、あーたらこーたら未練がましく
反論するから、じゃあお前の素晴らしきソースを
見せろって言ってるんだろ？

641 ：デフォルトの名無しさん：02/08/21 21:15

>>636
　そのサイズを　OOで書くとそうなるんじゃ？

642 ：デフォルトの名無しさん：02/08/21 21:17

>>640
だから非OOがOOより素晴らしいならお前の素晴らしきソースを見せろって言ってるんだろ？

643 ：OO厨：02/08/21 21:18

も　う　降　参　で　す　（　泣　）　。

644 ：デフォルトの名無しさん：02/08/21 21:19

>>643
アンチOO厨必死だな(藁

645 ：デフォルトの名無しさん：02/08/21 21:19

>>639
> その前にギコBASICを完全に非OOにしてね。
君の定義する非OOって何？
OOでないもの＝非OOじゃ無いの？

646 ：アンチOO厨：02/08/21 21:19

>>644
うるさい。氏ね

647 ：デフォルトの名無しさん：02/08/21 21:20

ギコBASIC は元のはコンポーネントで特殊な継承をしてグラフィック型コンポーネントになってたような・・・

648 ：デフォルトの名無しさん：02/08/21 21:20

そもそもここのOO厨のレベルってカスだからな。

649 ：デフォルトの名無しさん：02/08/21 21:22

>>645
OOの部分を完全に無くしてってことだよ。クラスとかな。

650 ：デフォルトの名無しさん：02/08/21 21:23

>>648
そうかもね。ここのOO厨のレベルってカスかもね。断定はしないけど。
だからOOが素晴らしいのはここにいるだけじゃわからないかもね。

651 ：611：02/08/21 21:25

なんだかOO派を煽ってしまった形になったようだな。
もういいよ。ソース見せなくても。少なくとも俺にはね。

652 ：デフォルトの名無しさん：02/08/21 21:28

OO厨珍説：OOでも非OOでもないソースが存在する

OO厨いくら必死でもそれはないだろ？

653 ：中立くん：02/08/21 21:28

素朴な疑問。

アンチOOの人って仕事や独学で
実際に作ってみてクソだって判断したのか
雑誌とかの情報でクソだと思ったのか
どっち？

654 ：デフォルトの名無しさん：02/08/21 21:29

ソースだよ。
http://www.bulldog.co.jp/syouhin/image/shouhin34.jpg

655 ：デフォルトの名無しさん：02/08/21 21:32

>>652
なにｱﾌｫ晒してるんだよ。

656 ：デフォルトの名無しさん：02/08/21 21:33

>>653
MFC...

657 ：デフォルトの名無しさん：02/08/21 21:33

>>653
実際に使ってみて理解できなかったらクソだと判断しています。

658 ：デフォルトの名無しさん：02/08/21 21:35

>>657はOO厨の自作自演。これ常識。

659 ：逝って良しの１：02/08/21 21:36

>>653
両方。

660 ：デフォルトの名無しさん：02/08/21 21:38

ｱﾝﾁOOのｲﾀｲ所は、その存在意義が、
今時滅多に居ないｲﾀｲOO厨
に依存している事。

661 ：デフォルトの名無しさん：02/08/21 21:39

>>656
OO厨もダメって言ってるMFCを出して否定してもしょうがないでしょ。
もっと違う例で否定したほうがいいよ。

662 ：デフォルトの名無しさん：02/08/21 21:39

OO 野郎が作ったコードは行き着くところ、大抵似たような設計になる。
OO に一度慣れると Java や Ruby のコードはすぐに理解できるようになる。

663 ：デフォルトの名無しさん：02/08/21 21:39

まあ少なくとも俺はコンポーネントがあればOOは医らネー。

664 ：デフォルトの名無しさん：02/08/21 21:41

ｱﾝﾁOO厨のｲﾀｲ所:その弐

ｱﾝﾁである理由なり、OOの問題点を、
他人に判る言葉で説明できない事。
＃不機嫌な家畜並ですな

665 ：デフォルトの名無しさん：02/08/21 21:42

OO厨のｲﾀｲ所:その壱

信者である理由なり、OOの利点を、
他人に判る言葉で説明できない事。
＃不機嫌な家畜並ですな

666 ：デフォルトの名無しさん：02/08/21 21:43

>>660
> 今時滅多に居ないｲﾀｲOO厨
例えばギコBASICをOOで書けない奴とかな。

667 ：(´･ω･`)ｼｮﾎﾞｰﾝ：02/08/21 21:44

オブジェクト指向一生懸命勉強したのに
クソだったなんて認めたくないよ・・・。

668 ：デフォルトの名無しさん：02/08/21 21:44

>>666
ずいぶん無理したレスですね(w

669 ：デフォルトの名無しさん：02/08/21 21:45

>>667はアンチOO厨の自作自演。これ常識。

670 ：デフォルトの名無しさん：02/08/21 21:49

でさ、OO厨に聞きたいけど、
OOの利点ってなんなんだよ？
かなり前からこの質問聞いてるんだけどさ、
まともな答えが返ってこないんだよね。
まともに答えるとOOの欠点が暴露するのが
怖いの？

671 ：デフォルトの名無しさん：02/08/21 21:49

>>666
めんどくさくて書かない＝OOはクソ、なの？？？

672 ：デフォルトの名無しさん：02/08/21 21:51

>>670
まともな意見はでてると思うけどね。
ないと思い込んでいると目の前にあるものも見えないって言うし。
あるのを認めるのが怖いの？

673 ：デフォルトの名無しさん：02/08/21 21:54

>>672
> まともな意見はでてると思うけどね。
> ないと思い込んでいると目の前にあるものも見えないって言うし。
そうだね
・OOはある一定以下の規模の場合、生産性が低い
・OOでは表現しにくいものがあり、常にOOを選択する奴はアホ

674 ：デフォルトの名無しさん：02/08/21 21:57

>>673
そうそう。それに当てはまらない場合はOOに利点があるってわけだ。

675 ：デフォルトの名無しさん：02/08/21 21:58

だからOOの利点は
・クラスをソフトウェア部品とできるので再利用性に優れている。
・多様性により効率が高くなる。
・UMLを使えば多人数のPGが共通の開発規約で効率よくプログラムできる。
以上の理由からOOで開発の効率を高めることができ、コストも低くすることが
できる。

676 ：デフォルトの名無しさん：02/08/21 22:01

>>675
ﾌﾟ

誰か突っ込まないのか？

677 ： ◆RGHBywaQ ：02/08/21 22:01

そうかも、。

678 ：デフォルトの名無しさん：02/08/21 22:02

>>676がつっこめば？

679 ：>>676：02/08/21 22:04

>>678
俺が突っ込んでもいいけど、
>>675の意見がOO厨の総意ということでいいのか？
他には意見はないのか？

680 ：デフォルトの名無しさん：02/08/21 22:06

>>675
必ずしも効率が高くなるとは限らないがなる効率が高くなる場合もある。

681 ：680：02/08/21 22:07

余計な「なる」は消してくれ。

682 ：デフォルトの名無しさん：02/08/21 22:11

>>680は典型的なOO厨レスだな(w

683 ：デフォルトの名無しさん：02/08/21 22:12

>>680
OSみたいなシステムをOOで作ると効率が高いのかニャ？

684 ：683：02/08/21 22:13

s/みたいなシステム//

685 ：デフォルトの名無しさん：02/08/21 22:14

ソフトウェアはデータ＋アルゴリズムで
アルゴリズムよりはデータ構造の方が圧倒的に変化しにくい
だからデータを中心に据えようってのがデータ主導設計で
OOはそこから自然発生しただけ.
OOの利点は所詮データ主導設計の利点程度のものだ

686 ：デフォルトの名無しさん：02/08/21 22:14

>>682
じゃあどっちの答えがいい？
1.効率は絶対低くなる。
2.効率は絶対高くなる。
どちらも間違いだと思うが。

あなたは自分が知らないものを認めたくないために真実が見えなくなった人みたいだね。

687 ：アマンダ：02/08/21 22:16

>>685
じゃあソースファイル毎管理すればOOはイラネーナ

688 ：デフォルトの名無しさん：02/08/21 22:16

>>685
あなたの結論としては利点があるわけね。

689 ：デフォルトの名無しさん：02/08/21 22:17

>>687
無知ですね。

690 ：デフォルトの名無しさん：02/08/21 22:18

>>675 ・クラスをソフトウェア部品とできるので再利用性に優れている。
COBOLerとおぼしきグループが書いた、Webアプリ(って単なるIIS ASP糞コード)を見てしまった事あるんですが、
ありゃー、この世の地獄のようなコードでしたね。

1つのアプリケーション内で、何度も認証画面が出てくるんです。

で、その認証画面のロジックがおかしいのか、と思って調べたら、
モジュール毎に全部別々の認証呼び出しコード書いてあるんです。

認証呼び出しコード位共通ライブラリにしとけよ、と思ってよく調べてみると、
モジュール毎に別々の認証ロジック、認証用ユーザ・テーブル持ってて、
それを無理矢理繋ぎ合わせてあるんです。

きっと、共通部品とか、共通ライブラリとか、調整する暇もなく、
ロクな設計もせずにコード書かせて、最後につなぎ合わせたか、
あるいは設計者が「認証」というものを設計書に書かなかったんでしょうが。
ｱﾌｫ設計者を抱えたウォーターフォールの弊害が、これほどひどいもんだとは思いませんでした。

691 ：デフォルトの名無しさん：02/08/21 22:21

>>690
ｱﾌｫ設計者というか、根本的に設計者がいなかったのでは？

692 ：OO厨：02/08/21 22:26

オブジェクト指向一生懸命勉強したのに
クソだったなんて認めたくないよ・・・。 (´･ω･`)ｼｮﾎﾞｰﾝ

693 ：デフォルトの名無しさん：02/08/21 22:27

>>688
そう。結局データ主導の時代からきちんとやってた人たちからみると
今のOOは胡散臭さに満ち溢れている
・UMLとか
・OOAとか
・デザインパターンとか
こういった技術は役に立つこともあるが､やらなきゃ駄目ってレベルのものではない.
俺はこの意味においてアンチOOだ

逆にデータ主導を知らずにいきなりOOを知った若者はデータ中心主義以前
のプログラミングパラダイムとOOを比べて「OOサイコー」となってる気がする
この意味なら俺はOO厨だ

694 ：デフォルトの名無しさん：02/08/21 22:29

>>692
今度は>>667をちょっと変更したみたいですね。
自作自演をばれないようにしたつもりですかアンチOO厨さん。

695 ：デフォルトの名無しさん：02/08/21 22:30

　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ
☆ ﾁﾝ　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀｰ　　　　　　　　　　　　
　　　　　 ☆　ﾁﾝ　　〃　 ∧＿∧ 　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）＜ >>676のﾂｯｺﾐまだー？
　　　　　　　＼＿／⊂　⊂＿)＿　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　／￣￣￣￣￣￣￣／|
　　　　　　　　l￣￣￣￣￣￣￣￣|　.|
　　　　　　　　|　　○ みかん ○　 |／

696 ：デフォルトの名無しさん：02/08/21 22:34

＞今のOOは胡散臭さに満ち溢れている
＞・UMLとか
＞・OOAとか
＞・デザインパターンとか
＞
80年代～90年代にｶﾞﾑﾊﾞってOOないしｺﾝﾋﾟｭｰﾀｻｲｴﾝｽ志した者にとっては、
至極自然な流れでしたが、何か？

＃例えばデザパタ。
＃1987年当時、Smalltalk のMVCフレームワークとか、OOのクラス相互作用の妙を見て、
＃「こりゃむずいわ、どうしてこーゆー設計をきちんと言葉で説明した文書ないのよ？」
＃と思ってたら、Gammaﾀﾝは1987年当時から OOLAでデザパタ主張してたってんだよねぇー。

697 ：デフォルトの名無しさん：02/08/21 22:35

いま C++ 勉強中なんだけど、
オブジェクト指向自体は優れた方法だと思うけど、
C++ は複雑すぎ。なんかむちゃくちゃ無計画につくられてないか、この言語。
そもそもこれほど大きな言語なのに C を元にしようとした時点で誤りだったような
気がするんですが。

698 ：デフォルトの名無しさん：02/08/21 22:37

オブジェクト指向もC言語と同じように30年以上の歴史がある
技術なんだけどね。

699 ：デフォルトの名無しさん：02/08/21 22:38

>>697
だからJavaっていう便利言語があるんじゃん。

700 ：デフォルトの名無しさん：02/08/21 22:38

>>697
どの辺が複雑ですか？

701 ：デフォルトの名無しさん：02/08/21 22:40

>>697
違います。無計画に拡張されまくったのです。

702 ：デフォルトの名無しさん：02/08/21 22:40

>>700
Effective C++、More Effective C++あたり。

703 ：690：02/08/21 22:41

>>691
普通のセンスの人なら、そーゆーﾔﾏﾀﾉｦﾛﾁみたいなコード見たら、
後からでも認証統合コードを書き直すよね？

糞SE上がりのプロマネって、
リファクタリングの意義もわからず、
「動いてるコードに余分な手を入れるな」とかいって、
デスマーチ地獄で永遠の炎に焼かれ続けるんだ…

704 ：デフォルトの名無しさん：02/08/21 22:42

>>702
WindowsでVC使えばいいじゃないか。

705 ：デフォルトの名無しさん：02/08/21 22:43

>>702
背後のシンプルなモデルが見えていない人間には、
表層の複雑さばかり気になるって感じ。

706 ：デフォルトの名無しさん：02/08/21 22:43

>>704
？

707 ：デフォルトの名無しさん：02/08/21 22:44

>>705
やはり表層は複雑なのか。

708 ：デフォルトの名無しさん：02/08/21 22:44

>>700
C++標準化＆仕様拡張は、
時間の浪費以外の何者でもなかーた

709 ：デフォルトの名無しさん：02/08/21 22:44

697 ではないが、C++ の無節操な拡張は見ての通りだとおもうが・・・
まっ時代の要請だよね C が基礎でなくてもよいかもしれないが
C が基礎でなければメジャーにはなれなかっただろう。

710 ：デフォルトの名無しさん：02/08/21 22:45

>>702
んだからさぁ理解できないｱﾌｫはOO使うなって。
理解できる漢だけが使えばいいんだよ。
俺達OOプログラマだけが生き残ればいいんだよ。

711 ：704：02/08/21 22:45

レスした後に気づく駄レスかな　

712 ：デフォルトの名無しさん：02/08/21 22:46

>>707
背後のシンプルなモデルって何かわかーて言ってる？

713 ：デフォルトの名無しさん：02/08/21 22:46

>>611
で、結局誰もソース公開しなかったのか？
もうOO厨の机上の空論には呆れるね。

714 ：デフォルトの名無しさん：02/08/21 22:48

ん？XSLTスレでも探してもらえば、漏れ様コード公開してるけど。

715 ：デフォルトの名無しさん：02/08/21 22:50

>>712
そりゃあんたにしか通じない言葉を使ってるんだからあんたにしかわからんって。
シンプルなモデルが何かを言ってからそれがどう表層の複雑さに結びつくのか言ってね。

716 ：デフォルトの名無しさん：02/08/21 22:51

>>710
お得意の自作OOのソースｷﾎﾞﾝ

717 ：とりあえずコピペしとくか：02/08/21 22:53

718 ：デフォルトの名無しさん：02/08/21 22:55

>>717
いいいいわけだな。

719 ：デフォルトの名無しさん：02/08/21 22:56

>>718
だが真実である。

720 ：デフォルトの名無しさん：02/08/21 22:57

で、OSをOOで設計すると開発効率がいいのか？

721 ：デフォルトの名無しさん：02/08/21 22:58

>>720
もっと身近な例にしてくれ。

722 ：逝って良しの１：02/08/21 22:58

ＯＯでマトモに設計・実装できるのはＯＯＰＧの５％くらい。
残りは自分でＯＯやってると勘違いしている厨房。

723 ：デフォルトの名無しさん：02/08/21 22:58

COM相当のからくり作らないと。

724 ：デフォルトの名無しさん：02/08/21 22:59

>>717
普通でもいいですよ
OOをうまく使いこなしてるソースであれば。

725 ：デフォルトの名無しさん：02/08/21 22:59

>>721
OOは効率悪いって白状しちまえよ。楽になるぜ。

726 ：デフォルトの名無しさん：02/08/21 23:00

>>722
それは非OOでも同じ。

727 ：デフォルトの名無しさん：02/08/21 23:01

しかしC++からOOをとってしまうと
つのを取られたカブトムシみたいでｶｺﾜﾙｲ

728 ：デフォルトの名無しさん：02/08/21 23:01

>>725
OOはOS開発に効率悪いって白状しちまえよ。楽になるぜ。

の間違いだろ。もとネタがOSって限定してんだから。

729 ：デフォルトの名無しさん：02/08/21 23:02

>>727
？

730 ：デフォルトの名無しさん：02/08/21 23:03

ところで、非OO派のデファクトスタンダードな言語はCで良いんですか？
これからもCを使い続けていくつもりなのですか。

新言語開発スレでもOOをは実装しないって話は一度も出なかったんですがどう思いますか？
やはり非OOとしては遺憾なことなのでしょうか？

731 ：デフォルトの名無しさん：02/08/21 23:03

>>728
少なくともOOはOSのようなものの開発には
効率が良くないと認めるわけですね。

732 ：デフォルトの名無しさん：02/08/21 23:05

>>731
はい。その通りです。

733 ：デフォルトの名無しさん：02/08/21 23:06

>>731
認めないよ。OSをOOで作ったこと無いもん。
アンチOOは自分の知らないものは否定するという考えがあるみたいですね。

734 ：デフォルトの名無しさん：02/08/21 23:08

OOでOS作れないことはないと思うけど、
コストがすごくかかると思うよ。いろいろな面で。

735 ：デフォルトの名無しさん：02/08/21 23:08

>>730
俺は非OO派だけどC++がメインです。

736 ：デフォルトの名無しさん：02/08/21 23:10

>>735
クラスは断じて使わない？

737 ：デフォルトの名無しさん：02/08/21 23:11

BeOSは商業的には失敗したけど技術的には優れてる。

738 ：デフォルトの名無しさん：02/08/21 23:13

>>737
ドライバのないOSなんてただのバイト列ですよ。

739 ：デフォルトの名無しさん：02/08/21 23:13

C言語でもOOはできる。
OOで作られていない(取り入れられていない)OSってあるのか？

740 ：デフォルトの名無しさん：02/08/21 23:14

>>725＝蚊系

741 ：735：02/08/21 23:14

>>736
そうです。

742 ：デフォルトの名無しさん：02/08/21 23:15

>>738
それが反論？(藁

743 ：デフォルトの名無しさん：02/08/21 23:15

>>741
あくまでベターＣですな。少々男らしさを感じました。同調はしませんがｗ

744 ：デフォルトの名無しさん：02/08/21 23:15

>>739
Mach2.5とか、NT4.0とか。

745 ：デフォルトの名無しさん：02/08/21 23:15

>>741
どんなもん作ってんの？

746 ：デフォルトの名無しさん：02/08/21 23:16

>>744
Windowsの各種ハンドルってOOな概念では？

747 ：デフォルトの名無しさん：02/08/21 23:16

>>734
つーか、OS書いててC++使いたいと思うことはよくあるな。
だけどnewとか実装するのバカバカしいからやめた。
思想だけ借りる。

748 ：744：>>739じゃなく>>738の間違い：02/08/21 23:16

>>738
Mach2.5とか、NT4.0とか。

749 ：744：02/08/21 23:18

>>746
>>744は間違いという事で。
ところで、RDBのunique keyもOOですか(

750 ：デフォルトの名無しさん：02/08/21 23:18

>>735
おお、おれもOO派じゃないけど C++ メイン
ちなみに template 万歳 JAVA 逝ってよし

751 ：デフォルトの名無しさん：02/08/21 23:19

>>749
それ中心に各種処理が行われるならそうなのでは？と思った。

752 ：デフォルトの名無しさん：02/08/21 23:20

>>749
RDBはそもそもOOじゃないんじゃ･･･。

753 ：デフォルトの名無しさん：02/08/21 23:21

>>750
テンプレートとクラスを切り離すと非常にしょぼい処理しか出来ない気がするんですが。
コンテナのデータ格納要のあくまで安全な(void *)として？

754 ：デフォルトの名無しさん：02/08/21 23:22

>>753
結局テンプレートも適材適所ということで・・・。

755 ：デフォルトの名無しさん：02/08/21 23:23

>>753
それは抽象化能力が足りないから
STL みてどうやってあれを発想したか想像つかんだろ

756 ：デフォルトの名無しさん：02/08/21 23:24

ﾊﾟﾗﾒﾀﾗｲｽﾞﾄﾞｸﾗｽ

757 ：デフォルトの名無しさん：02/08/21 23:24

>>755
クラスばりばりですな、STL。

758 ：デフォルトの名無しさん：02/08/21 23:29

で、戦場知らずの自己流OOプログラマたちよ。
夏休みの宿題は終わったのか？
早くクソして寝なさい。

759 ：デフォルトの名無しさん：02/08/21 23:30

>>758
負け惜しみにしては低レベルです。

760 ：デフォルトの名無しさん：02/08/21 23:34

じゃあ、非OOな人が GUI ツールキット作ろうとしたら、
どんな設計になってでてくるんだろうか。

761 ：デフォルトの名無しさん：02/08/21 23:35

>>758
寝る前にクソするか？普通。

762 ：デフォルトの名無しさん：02/08/21 23:36

結局OOの利点をOOプログラマに聞いても
「～の場合は」
「～である場合」
「～ならば」
って条件付きで、OOの利点をはっきりと
提示できてないんだよね。これじゃ、アンチOO
も納得しないよ。

763 ：デフォルトの名無しさん：02/08/21 23:36

>>761
俺は必ずしますよ。

764 ：デフォルトの名無しさん：02/08/21 23:36

>>760
誰に聞いてるのか、教えれ

765 ：デフォルトの名無しさん：02/08/21 23:37

>>760
クリックされた場所によって処理を変える

766 ：デフォルトの名無しさん：02/08/21 23:37

>>760
一つのウインドウ一つのタイトルバー一つのボタンに一つのテキストボックス。
とか？

論点がずれてきているので「OOの何をするのがダメか？」を明確にして議論すべき。

767 ：デフォルトの名無しさん：02/08/21 23:38

>>762
非OOプログラマに聞いてもそれは同じ

768 ：デフォルトの名無しさん：02/08/21 23:38

>>760
非 OO 派のオレでも GUI みたいなてき面に機能する部分は OO でつくる。
わざわざ苦労する必要はない。
それ以外は OO では作らん、大概機能しないからな。

769 ：デフォルトの名無しさん：02/08/21 23:39

結局ｱﾝﾁOOの主張をｱﾝﾁOO厨に聞いても、
「どんな場合でも通用する万能理論ﾖｺｾｰ」
とか子供のような事言ってるので、
話を合わせてあげる余地すらありませんですた。

770 ：デフォルトの名無しさん：02/08/21 23:39

>>767
だから論点をずらすなよ。
典型的なOO信者のレスだな（藁

771 ：デフォルトの名無しさん：02/08/21 23:41

>>762
なぜならそれが真実だから。
アンチOOも「～の場合は」のように条件付でしか否定できてない。

772 ：デフォルトの名無しさん：02/08/21 23:41

TCP/IPをOOで実装するのは無謀ですか？

773 ：デフォルトの名無しさん：02/08/21 23:42

>>772
socketまで逝くとOOって感じだけどね。

774 ：デフォルトの名無しさん：02/08/21 23:43

>>773
何が？

775 ：デフォルトの名無しさん：02/08/21 23:48

意味不明なOO厨がいるな(藁

776 ：デフォルトの名無しさん：02/08/21 23:54

>>773
socketでオブジェクトのインスタンスを渡すあたりの実装がOO

777 ：デフォルトの名無しさん：02/08/21 23:56

FileDescriptor全般に通用しそうな程度の比喩っすね。
漏れは、socketの状態遷移をstateパターン＝OOって勘違いしてるんかと思ーた。

778 ：デフォルトの名無しさん：02/08/21 23:58

ここは〇〇のなかに小粋な２文字を当てはめる訓練をするスレですか？

779 ：デフォルトの名無しさん：02/08/22 00:00

OO＝目を見開くほどﾋﾞｯｸﾘｼﾀーってフェイスマークです。

780 ：デフォルトの名無しさん：02/08/22 00:01

>>777
まあどちらにせよ複雑になりそうなﾖｶｰﾝ

781 ：デフォルトの名無しさん：02/08/22 00:02

　　　　　　　　　　　　　　歯垢は必要無し！

782 ：デフォルトの名無しさん：02/08/22 00:02

>>773
OOじゃムリムリ。

783 ：デフォルトの名無しさん：02/08/22 00:02

　　　　　　　　　　　　　　歯垢は洗浄では必要なし！

784 ：ｱﾝﾁ歯糞厨：02/08/22 00:04

電動ﾊﾌﾞﾗｼ使えよ

785 ：デフォルトの名無しさん：02/08/22 00:05

恥垢はどうですかね

786 ：デフォルトの名無しさん：02/08/22 00:07

OO一生懸命勉強したのにね～。お気の毒に(´･∀･`)
でもまあ趣味として小さいプログラム作るに使う分にはいいんじゃないかな？(´･∀･`)

787 ：デフォルトの名無しさん：02/08/22 00:10

>>786
アンチOOはいつも何の脈絡もなくでてくるな(w

788 ：OO命：02/08/22 00:13

>>786
オブジェクト指向プログラミングもC++もSTLもUMLも一生懸命勉強したのに・・・。
(´･ω･`)ｼｮﾎﾞｰﾝ

789 ：デフォルトの名無しさん：02/08/22 00:13

なんでまだこのスレつづいてんだろ

790 ：デフォルトの名無しさん：02/08/22 00:13

>>786
JavaでWebアプリつくる案件がきたら
どうする？ことわる？非OOで作る？

791 ：デフォルトの名無しさん：02/08/22 00:14

>>789
オブジェクト指向が過渡期だからかなー
今後隆盛するにしても廃れるにしても。

792 ：アンチOO：02/08/22 00:14

>>790
ことわります。

793 ：デフォルトの名無しさん：02/08/22 00:15

>>790
ことわります。

794 ：デフォルトの名無しさん：02/08/22 00:16

>>790
Webアプリは小さいプロジェクトの部類だと思うけどね。

795 ：デフォルトの名無しさん：02/08/22 00:18

WebアプリだったらFlashMXに注目してます。

796 ：デフォルトの名無しさん：02/08/22 00:18

>>794
物によるんじゃないの？
大規模な生産管理システムだってどこかにWeb使えばある意味Webアプリであるわけで。

797 ：デフォルトの名無しさん：02/08/22 00:18

じゃあJava、C++、Delphi、C#、VB.NET、OOCOBOL等の
オブジェクト指向言語を使用する案件がきたらどうする？

798 ：アンチOO：02/08/22 00:19

>>797
ことわります。

799 ：デフォルトの名無しさん：02/08/22 00:19

>>797
仕事と主義は別だと思われ。by OO派。

800 ：デフォルトの名無しさん：02/08/22 00:21

>>799
ｲｲ

801 ：デフォルトの名無しさん：02/08/22 00:22

このスレ読んでて思うけど、
使いこなせないどころか使う気のないﾔｼにOOやらせようったって無理なわけで、
使いこなせるﾔｼが自由自在に構築すればいいだけで、
まぁ結局それだけの話じゃねぇのか、と。

802 ：デフォルトの名無しさん：02/08/22 00:22

>>797
設計をするということとは別のような気が。

803 ：デフォルトの名無しさん：02/08/22 00:22

>>798
そんなことやってたら仕事なくなるぞ。

804 ：デフォルトの名無しさん：02/08/22 00:23

>>801
それじゃあ議論にならねぇだろ、かえったかえった。

805 ：アンチOO：02/08/22 00:23

>>803
OOで仕事をするくらいなら氏を選びます。

806 ：デフォルトの名無しさん：02/08/22 00:25

>>803
そんなにオブジェクトの仕事こないよ。

807 ：デフォルトの名無しさん：02/08/22 00:25

>>801
アンチOOにOOを使わせようという意図でレスしてたのか？
アンチOOはOOは使えないと主張しているだけ。それに対しOO派
はそれをはっきりと反論できずにいるという図式。

808 ：デフォルトの名無しさん：02/08/22 00:26

>>807
OO派は反論はしているアンチOOがそれを見ようとしていないだけ。

809 ：デフォルトの名無しさん：02/08/22 00:29

>>808
だから（以下略）

810 ：デフォルトの名無しさん：02/08/22 00:29

>>808
ちゃんと見てますぞ。

811 ：デフォルトの名無しさん：02/08/22 00:30

>>807
どちらも決定打がないんですな。

812 ：デフォルトの名無しさん：02/08/22 00:30

みんながんばれ

813 ：デフォルトの名無しさん：02/08/22 00:31

OOってアンチパターン系の本多いよね。

814 ：デフォルトの名無しさん：02/08/22 00:34

このスレでOO派が立証しなければならないのは、
OOが使えるかどうかではなく、
無能な兵隊の多い戦場でOOが使えるかどうかってことではないかと思われる。

815 ：デフォルトの名無しさん：02/08/22 00:34

>>813
今のOOはあくまで構造化言語をベースにしてるのが多いからそのレベルから否定すると偉いことになる。
あんたも関数型言語とか推論型言語でアプリ組みたいとは思わんでしょう。

816 ：デフォルトの名無しさん：02/08/22 00:34

OOが使えるのは実証されてるしね。

817 ：デフォルトの名無しさん：02/08/22 00:36

強いものが生き残り弱いものは死ぬ。それが戦場というものだ。

818 ：デフォルトの名無しさん：02/08/22 00:39

＞オブジェクト指向はより自然なモデルに即したものではあるが、クラス
を理解する労力が大きく、目的まで達成するのに時間がかかる。
＞他人のソースを見るにも複雑でときほぐしにくい。

俺が非OOな理由はこの２つです。

819 ：デフォルトの名無しさん：02/08/22 00:40

>>814
OO派だけど、それは立証できない。
OOに否定的な兵隊とともに部隊を組んだら
戦に負けるだろうな（品質低下orプロジェクト破綻）。
でもそれは隊長の人選ミスになるかもしれない。

820 ：デフォルトの名無しさん：02/08/22 00:41

アンチOOを一番排除できる言語はやっぱりObjectPascalですか？
他にいい言語あります？
C++だと、アンチOOなのかOOをよく分かってないだけか知らんけど、
何も考えずにダラダラ書くｱﾌｫがいるから困るんですけど、これって
防ぐ方法ないですか？（ｸﾋﾞ以外で）

821 ：デフォルトの名無しさん：02/08/22 00:41

>>818
同じ物を非OOでやった場合にOOよりも良くなるというのを実証してください。

822 ：デフォルトの名無しさん：02/08/22 00:42

1自身、OOは否定していない。
ただ、戦場では使えないと主張しているだけ。

無能な兵隊がOOを駆使して戦う戦場は、
無能な兵隊が非OOを駆使して戦う戦場より惨い状況となる、
それは正しいと思うな。

823 ：デフォルトの名無しさん：02/08/22 00:42

別の板からの「ほんの一部」の引用だけど、OO厨にこれを読んで現実を知ってほしいものだ。

>た。両者とも、有名どころの研修を受けコンサルをいれたけれども結果としては、オブ
>ジェクト指向開発ができているといえるような成果はでておらず、オブジェクト指向を
>学んだだけになってしまっているようです。

>ある知り合いの技術者に聞いたところ、受託開発でオブジェクト指向開発をうまくでき
>ている所はとても少なく、うまくいっているところは一つの製品を拘りながら作りこん
>でいく必要があるパッケージソフト開発をしているところであるということも聞きました。

>いきなりプロジェクトにオブジェクト指向を導入するのは凄い
>危険だと思うなー。多分失敗してトラウマになる。

>俺の会社は見事に失敗しました。
>対外的にはオブジェクト指向開発をしているといっているけど、ただJavaを
>使っているだけ。
>設計とは画面設計とＤＢの設計だけだ。あとは、WebLogic上にゴリゴリと
>作っている。Web系でオブジェクト指向開発は、時間ばかり掛かり、結局
>やらなくなった。
>Webアプリを開発している会社ってそんなもんじゃないでしょうか？
>うちはちゃんとやっているゾ！という所があれば教えてください。
>どの程度やっているのかとても知りたい。

>このレスいつも続かないので、きっとオブジェクト開発やっている
>人はすくないと思うな。

>組織的に利用するには、ちょっと難しすぎると思う。

824 ：デフォルトの名無しさん：02/08/22 00:43

>>821
観点によりけりだと思いますよ。
非OOにもOOにも、それぞれ他より良い点があるわけでしょ。
片方が必ずもう片方より良いっていうわけではないでしょ。
それを考えずに言い合ってても、不毛な議論です。

825 ：デフォルトの名無しさん：02/08/22 00:45

OO一生懸命勉強したのにね～。お気の毒に(´･∀･`)
でもまあ趣味として小さいプログラム作るに使う分にはいいんじゃないかな？(´･∀･`)

826 ：デフォルトの名無しさん：02/08/22 00:45

>>822
いい順番から

有能な兵隊がOOを駆使する
有能な兵隊が非OOを駆使する
無能な兵隊が非OOを駆使する
無能な兵隊がOOを駆使する

ですね。

827 ：デフォルトの名無しさん：02/08/22 00:47

>>824
だから必ずしもOOがダメというわけじゃないって事だろ。わかってるよ。

828 ：デフォルトの名無しさん：02/08/22 00:47

>>826
同意。　by OO派。

結構諸刃の剣的なところあるよ。

829 ：デフォルトの名無しさん：02/08/22 00:48

>>824
＞片方が必ずもう片方より良いっていうわけではないでしょ。

みんなそのことは理解していてそれをふまえて自分の趣味を闘わせてるんだよ。
いわば武道。スポーツだよ。

830 ：デフォルトの名無しさん：02/08/22 00:48

>>823
現実を知ったOO厨
↓
(´･ω･`)ｼｮﾎﾞｰﾝ
オブジェクト指向プログラミングもC++もSTLもUMLも一生懸命勉強したのに・・・。

831 ：デフォルトの名無しさん：02/08/22 00:50

>>830はスポーツマンシップにのっとってないな～

832 ：デフォルトの名無しさん：02/08/22 00:51

>>826
兵隊の観点からそんな順序つけても無駄だろ。
それなら、OOを使う基準を考えて、それに照らし合わせて
OOを使うようにすればいいんじゃないか？

基準案
・第一バージョンの開発に時間をかけられる
・第二バージョン以降は開発に時間をかけたくない
・第五バージョンくらいで開発を打ち切る
・継続的な保守が必要

ほかにある？

833 ：デフォルトの名無しさん：02/08/22 00:53

>他人のソースを見るにも複雑でときほぐしにくい。

戦場で使うにはこの欠点は大きすぎる。

834 ：デフォルトの名無しさん：02/08/22 00:53

OO派＝ OOと非OOのどちらが良いかは場合による。効率よく使え。
アンチOO派＝ OOはどんなときも絶対にダメ。
アンチOO派がOO派が考えていることの誤解＝ OOがどんなときも絶対に良い。

835 ：デフォルトの名無しさん：02/08/22 00:54

>>833
同じ物を非OOで作るとその問題はさらに大きくなる(ことが多い)

836 ：823：02/08/22 00:55

>>823
OO厨は現実は見えないのか？
見えないフリをせざるを得ないのか？

837 ：逝って良しの１：02/08/22 00:55

誤解じゃなく、ＯＯの入門書に書いてあるけど。

838 ：デフォルトの名無しさん：02/08/22 00:55

どちらかというとOO派だが
>>835
理由は？

839 ：デフォルトの名無しさん：02/08/22 00:57

>>834
アンチOO派は「戦場では使えない」といっているのです。

840 ：デフォルトの名無しさん：02/08/22 00:58

>>833
そもそも、他人のソースを見る時点でそれはOOから反れてると思うけど。
OOで参照すべきは、他人のソースじゃなくて、クラスのドキュメントだろ。

841 ：デフォルトの名無しさん：02/08/22 00:59

>>839
OOは戦場で使える。
無能は兵隊のみがいる戦場は別。

842 ：デフォルトの名無しさん：02/08/22 01:00

>>840
戦場のような現場でドキュメントがあるという妄想。
だから頼むから>>823を読んでOOの現実を知ってくれ。

843 ：デフォルトの名無しさん：02/08/22 01:01

>>833
OOであれ非OOであれ、有能な兵隊ならすっきりしたソースを吐き出すよ。

ただ、
非OOのすっきりしたソースはほぼ全員がすっきりしてると認識できるが、
OOのすっきりしたソースは、
OOを理解する兵隊だけがすっきりしてると認識し、
OOを理解していない兵隊はほとんど読解できない。

844 ：デフォルトの名無しさん：02/08/22 01:01

>>842
>いきなりプロジェクトにオブジェクト指向を導入するのは凄い
>危険だと思うなー。多分失敗してトラウマになる。

いきなり、というのがミソだと思うが。
手馴れた会社、手馴れたチーム、が使えば問題ない。

845 ：デフォルトの名無しさん：02/08/22 01:01

>>842
OOの現実じゃなくて無能の現実だろ。
無能の戦場にはドキュメントはなさそうだしな。

846 ：デフォルトの名無しさん：02/08/22 01:03

>>843
現実では無能な兵士が大半占めてる。

847 ：デフォルトの名無しさん：02/08/22 01:04

>>844
>手馴れた会社、手馴れたチーム、が使えば問題ない。
だ～か～ら～（以下略）

848 ：デフォルトの名無しさん：02/08/22 01:04

>>846
それが大前提なら>>1の主張に賛同します。

849 ：デフォルトの名無しさん：02/08/22 01:05

>>842
そのような低レベルの戦場でOOなんて使ったら必ず失敗してしまいますね。
あなたのところでOO導入するのはやめたほうがいいです。
というか、ドキュメントすら作れないってのはどういう状況なんですか？
多国籍で英語がマトモに使えない人間がまじってるとか？

850 ：デフォルトの名無しさん：02/08/22 01:05

>>846
無能な兵隊は遅かれ早かれ戦争に負ける。
それとも無能な兵隊を擁護する気ですか。

851 ：デフォルトの名無しさん：02/08/22 01:07

>>850
自分以外は無能なPGだと思ってないか？
お得意のソース見せろ要求していいかい？

852 ：逝って良しの１：02/08/22 01:08

ＯＯ賛同者の方のＨＰ（再掲）
http://www.intership.ne.jp/~hiroshit/object.html

853 ：デフォルトの名無しさん：02/08/22 01:09

「OO＝クソ」には反対だけど
「OO使える＝有能」
「非OOしかダメ＝無能」
ってのはちょっと違うと思うな

854 ：デフォルトの名無しさん：02/08/22 01:09

>>851
あぁ俺は少なくとも今は無能だよ。だが無能な兵隊が負けるのは真実。
俺はそのうち有能な兵隊になってやるさ。負けたくないからな。
お前らは勝手に負けてろ。

855 ：デフォルトの名無しさん：02/08/22 01:09

>>849
その低レベルな戦場が現実なんですよ。

856 ：デフォルトの名無しさん：02/08/22 01:10

OO派で、『無能な兵隊が紛れ込んだ戦場でもOOは有効だ』という猛者がいなければ、
このスレを、アンチOOの憩いの場として開放してあげてはいかがでしょうか？

857 ：デフォルトの名無しさん：02/08/22 01:10

>>854
キミがOOをマスタした頃にはOOは過去の技術という罠

858 ：デフォルトの名無しさん：02/08/22 01:11

>>853
OOが使える有能とOOが使えない有能では差がある。

859 ：デフォルトの名無しさん：02/08/22 01:11

>>856
ﾊｹﾞﾄﾞｳ

860 ：デフォルトの名無しさん：02/08/22 01:12

>>855
じゃあ戦場で勝利するのは簡単そうですね。

861 ：デフォルトの名無しさん：02/08/22 01:12

>>852
そのサイトは反則。ハラがいてーよ。

862 ：デフォルトの名無しさん：02/08/22 01:13

>>852
なぜOO派までもが否定しているものしかだすことが出来ないのですか？

863 ：デフォルトの名無しさん：02/08/22 01:14

>>826
結論がでたね、
OO は上と下のみ、非OOは真ん中二つ
要するに OO はリスキー

864 ：デフォルトの名無しさん：02/08/22 01:15

憩いスレの予感・・・

865 ：デフォルトの名無しさん：02/08/22 01:16

>>858
その通り。時代を勝ちぬけていけるのはOOが使える有能のみ。
もはやOOが使えない有能では役に立たないに等しい。

866 ：デフォルトの名無しさん：02/08/22 01:17

>>863
結論としては非OOでは最善にはならないってことですね。

867 ：デフォルトの名無しさん：02/08/22 01:18

>>823で現実を突きつけられたOO厨。必死だな。ﾌﾟ

868 ：デフォルトの名無しさん：02/08/22 01:19

なんかこのスレ、OOって言葉が多発してるけど、
OpenOfficeなんかそんなに議論することあるんですか？
どう考えたってMS Officeが最高なんじゃないですか？

869 ：デフォルトの名無しさん：02/08/22 01:20

>>868
3点

870 ：デフォルトの名無しさん：02/08/22 01:20

>>867 ﾌﾟ

871 ：デフォルトの名無しさん：02/08/22 01:21

>>869
いや、OpenOfficeのSetupファイル名にはOOって書いてあるんだよね。

872 ：デフォルトの名無しさん：02/08/22 01:21

＞オブジェクト指向はより自然なモデルに即したものではあるが、クラス
を理解する労力が大きく、目的まで達成するのに時間がかかる。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース。
またオブジェクト指向が○○に優れているとかいう話も、あくまでちゃ
んと設計され、ちゃんと実装されたクラスがあるという前提での話。
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よってオブジェクト指向は戦場では使いものになりません。

873 ：デフォルトの名無しさん：02/08/22 01:22

なんか現実現実ってうるさい奴が要るけど
今の現実は未来では過去なんですよ。
未来を見ましょう。

874 ：デフォルトの名無しさん：02/08/22 01:23

　有能な兵隊がOOを駆使すれば非OOを駆使するよりも良い物ができる可能性がある(要・使い分け)
　有能な兵隊は非OOでも良い物が作れる
　無能な兵隊がOOを使えば非OO使うよりもぁゃιぃ物ができあがる

　加えて、現実には無能な兵隊が多い

　∴OOは戦場では役に立たない、という>>1の結論は正しい
　　但し、OOを駆使できる有能な兵隊が使えばOOは武器になりえる、と。

こういう結論でよろしいか？

# あ、ちなみに俺はOO派です。キレイな設計を見た時/できた時は
# やっぱり惚々するし、メンテもしやすいと思うから。

875 ：デフォルトの名無しさん：02/08/22 01:23

>>873
現実＝戦場
未来＝妄想

876 ：デフォルトの名無しさん：02/08/22 01:23

>>873
それは夢想という。

877 ：デフォルトの名無しさん：02/08/22 01:25

>>874
それでいいんじゃない

878 ：デフォルトの名無しさん：02/08/22 01:25

ほんと無能な兵隊ばっか(藁

879 ：デフォルトの名無しさん：02/08/22 01:26

>>878
オマエモナー

880 ：822：02/08/22 01:27

>>874
じゃそういうことで、あとはアンチOOの憩いの場ということで。
おやすみなさい。

881 ：デフォルトの名無しさん：02/08/22 01:27

有能な兵隊が多い戦場　→　OO
無能な兵隊が多い戦場　→　非OO

で、２極分化ということでいいんでない？

882 ：デフォルトの名無しさん：02/08/22 01:28

>>874
>有能な兵隊は非OOでも良い物が作れる
とあるプロジェクトで、サイズの都合Cで組むことになったんですが
javaではまあそこそこ組めまして、有能とは言われてたんです。

が・・・

struct でよせばいいのに class もどき作って malloc 使ってメモリーリークさせて・・・
それはもう悲惨でした。

そういうケースもあるもんです。

883 ：デフォルトの名無しさん：02/08/22 01:28

やっと結論がでましたね。
結論が出るスレっていうのはほとんどないですから
そういう意味ではかなりいいスレだったと思います。

884 ：デフォルトの名無しさん：02/08/22 01:31

OO → 鉄砲隊
非OO → 騎馬隊

885 ：デフォルトの名無しさん：02/08/22 01:32

>有能な兵隊が多い戦場　→　OO
>無能な兵隊が多い戦場　→　非OO
>で、２極分化ということでいいんでない？

で、ここにいるOO厨は有能なのか？
有能なOOプログラマは全プログラマ中の何％なんだ？

886 ：デフォルトの名無しさん：02/08/22 01:33

「無能」という言葉は適切ではないと思います。
場合によっては差別用語として扱われ、放送禁止です。
もっと他に適切なことばがあるでしょう？

887 ：デフォルトの名無しさん：02/08/22 01:33

給料泥棒

888 ：デフォルトの名無しさん：02/08/22 01:36

>>886
OOに向いてないPG
頭の固いPG
定年が近いPG
前世代のPG
窓際に限りなく近いPG
転職間近のPG

こんなところ？

889 ：デフォルトの名無しさん：02/08/22 01:36

>>887
また、そういう言い方を（ｗ
ここはケンカスレではなく憩いスレですよ。
もうスッキリしたし。

890 ：デフォルトの名無しさん：02/08/22 01:36

昔、C++がクソだという説があったが、
マイクロソフトがC++を採用していたということもあり
その説は一蹴された。しかし数年たった今、C++も
昔ほど重要に思われなくなってきた。あと数年、
オブジェクト指向も同様になると思われる。

891 ：デフォルトの名無しさん：02/08/22 01:37

>>887
能力に比べコストが高いPG

でいいんでないか？

892 ：デフォルトの名無しさん：02/08/22 01:38

>>890
重要視されなくても、中核技術として地位を確立してる可能性はある。

893 ：887：02/08/22 01:40

>>891
勉強になったよ。

894 ：デフォルトの名無しさん：02/08/22 01:41

>>890
C++が重要でなくなったのはそれを踏まえたより良い物が出てきたからだね。
オブジェクト指向もそれを踏まえてより良い物になるだろうね。
オブジェクト指向もC++同様否定されることは無いね。

895 ：デフォルトの名無しさん：02/08/22 01:41

>>890
>昔、C++がクソだという説があったが、
>マイクロソフトがC++を採用していたということもあり
>その説は一蹴された。
マイクロソフトがクソだったという罠

896 ：デフォルトの名無しさん：02/08/22 01:44

まあ>>823を読む限り現実に世の中には能力が高いPGは少ないから
OOは普及しないで、コンポーネントを使用してのプログラムという局面が
多くなるだろうね。

897 ：デフォルトの名無しさん：02/08/22 01:45

>>896
う～んそうだね～。
で、コンポーネントを作るのは有能なPG、っと。

898 ：デフォルトの名無しさん：02/08/22 01:46

アンチOOはコンポーネントは認めているのか？
コンポーネントもOOとかなり似ていると思うが。

899 ：デフォルトの名無しさん：02/08/22 01:49

つーか、ここにいるOO厨は自分は有能なPGだと思ってるわけ？
そういった妄想で自尊心を満たしてるの？　ｺﾞﾒｿ、ちょっとｷﾓｲかも・・・。

900 ：デフォルトの名無しさん：02/08/22 01:50

>>897
コンポーネントはＯＳ屋が作って以上終了になるとおもふ
アプリケーションウイザードとの組みあわせになると
ＧＵＩプログラムの重要度は減って、インターフェイスよりアプリ本来の機能の実装部を
有利に組める方法論が幅を利かせてくるとおもふ
それはＯＯではないような気もする

901 ：デフォルトの名無しさん：02/08/22 01:51

>>899
OOが使えるかどうかとは関係ない話だね。話をはぐらかしてる？

902 ：デフォルトの名無しさん：02/08/22 01:54

例えばデルでWebアプリ作ったときは
ほとんどOOの事考えなくてもいいように開発ができた。
もうほとんどツール化されてるからね。
※このスレは７は逝くのかな？

903 ：デフォルトの名無しさん：02/08/22 01:58

まぁ結論出たんだから良かったじゃん。こんなスレめったにないさ…煽り合いは止めようや。
次スレは立てないんだよね？

904 ：デフォルトの名無しさん：02/08/22 01:59

>>903
立てません。>>1的にも満足なはず。

905 ：デフォルトの名無しさん：02/08/22 02:07

－－－－－－－－－－－－－－－－－－－－－－－－－－
俺様用しおり
　 ∧＿∧ 　　
　（　・∀・）＜　今日はここまで読んだ　　　　　　
－－－－－－－－－－－－－－－－－－－－－－－－－－

906 ：デフォルトの名無しさん：02/08/22 02:33

結論まとめてくれ↓

907 ：デフォルトの名無しさん：02/08/22 02:35

無能な兵隊は死ぬ

908 ：デフォルトの名無しさん：02/08/22 02:40

ついにこのスレ結論が出た、と思ったら>>1が最初から主張してきたことに
帰結しただけじゃないかー。
ま、とりあえずOOについて論議するスレということで次スレ逝ってもいいんじゃない？

909 ：デフォルトの名無しさん：02/08/22 02:50

結論、結論って飽きた証拠だろ
やめて素直に雑談スレ逝けよ暇人ﾄﾞﾓ

910 ：デフォルトの名無しさん：02/08/22 02:51

もう不毛な争いは止めようやw お互い宗教戦争みたいなもんで決着付かんだろ。
次スレ立てるんならスレタイ変えて、純粋にOOについて議論するスレにするほうがいいと思われ。

>>906
>>874
過去ログ読まない奴って無能な兵隊でいいのかね。

911 ：デフォルトの名無しさん：02/08/22 02:53

>>910
決着のつかない不毛な言い争いこそ2chにふさわしいだろ。

912 ：デフォルトの名無しさん：02/08/22 02:54

>>911
う、うわーw

913 ：デフォルトの名無しさん：02/08/22 03:06

オブジェクト指向が使えないのは糞SEや糞PGばかりで
ドキュメントが無いのが前提と>>1が言っています。
こんなめちゃくちゃな前提が当たり前なんですね。この業界は。

914 ：デフォルトの名無しさん：02/08/22 03:14

>>913
働いた事あるならわかりそうなもんだが…

915 ：デフォルトの名無しさん：02/08/22 03:22

プログラミング言語自体が人間が作ったものだから・・・
他人を理解するのが難しいように、プログラムも難しいかと・・・

で、極めて優秀な方たちがぶつかると俺の方が・・・俺の方が・・・
となって、不毛な混沌へと落ちていくのでは・・と、思ったり。

916 ：デフォルトの名無しさん：02/08/22 03:24

>>914
麻痺してますね。

917 ：デフォルトの名無しさん：02/08/22 03:50

よくみると>>1は別にOOが使えないといっているわけじゃないね。
あくまで糞SEや糞PGばかりだからOOを使いこなせる奴がいないと言っているだけ。
つまり、OO派が言っているOOを使えない奴が使えばOOは役に立たないが
OOを使える奴が使えばOOは使えるという意見と同じというわけだ。

どうやら「オブジェクト指向は戦場では使いものになりません。」という言い方が誤解を生んでいるようだね。
「オブジェクト指向は糞ばかりの戦場では使いものになりません。」という言い方に変えるべきだ。

糞ばかりの戦場がいつまでも続くといいね＞アンチOO

918 ：デフォルトの名無しさん：02/08/22 12:55

結局、「戦場」にこだわっている所から、アンチの素性がうかがえるんだよね。

納期3日前、あるモジュールが丸々動かないことが判明、
とにかく1晩でそのモジュールを実装しなければならない。
で、無理矢理作っちゃう。おかげで残業ばかりためっていく。
そんな「戦場」で無理な残業してる分、自分はすごく仕事していると思い込み、
その分ぐらい普段は休養して当然と思っている。
つまり、せっぱつまってない時にはほとんど仕事らしい仕事をしない。
普段からじっくり作り上げていくという習慣がない。

ってーのが、自分が今まで色々な現場で目にしてきたアンチOOの姿だ。

OOでもモジュールを一晩で一気にでっち上げることもできるけど、
それも普段からの蓄積があっての事。
普段から蓄積していく習慣がない「戦場の常連」達には
OOは到底お勧めできない。
つーか、OOは使えないのどうのと言う前に、
自分達の仕事の仕方や生活習慣を更めるべきだと思うぞ。

919 ：デフォルトの名無しさん：02/08/22 13:09

>>918
また出てきたかゴキブリ並にしつこい馬鹿だな。

OO厨はスキルは大したこと無いのに口と態度はでかいんだね。
さっさとギコBASICのOOで書いたソースを見せて見ろ。

920 ：デフォルトの名無しさん：02/08/22 13:15

すみません、 00 って何ですか。。。？

921 ：デフォルトの名無しさん：02/08/22 13:20

OOを使う人は２種類の人がいます
新しい設計手法として使う人と
自分が優れていること示すための道具として使う人です

後者はOO厨と呼ばれます

922 ：デフォルトの名無しさん：02/08/22 13:20

>>920
00じゃなくてOOだっつーの！
OpenOfficeって分かるか？

923 ：920：02/08/22 13:32

OpenOffice の略っすか！
調べてみまっす（汗
ども！

924 ：デフォルトの名無しさん：02/08/22 14:23

OOage

925 ：デフォルトの名無しさん：02/08/22 14:26

>>922
一見さんを追い払ってくれてどうもありがとう。

926 ：デフォルトの名無しさん：02/08/22 14:39

まだ続いてんだ･･･
>>908
1が立てた議題について『その通りですね』という感じで結論がでたんだからそれでいいんじゃないの？
この議題について言えば、結論はそもそも『その通りですね』『いや違いますね』のふたつしかないだろ。
何が不満よ。このスレを続ける必要はないと思うな。
このスレを続けるのであれば、だれかが『OOは戦場でも有効だ』という主張をする必要がある。
あなたがそう主張するの？

不毛なのはOO厨とアンチOOの煽りあいであって、議論そのものが不毛だったわけじゃないと思うよ。
（あと、現場がいかに不毛かってことは明らかになったが･･･）

『そもそもOOは有効か』という議論や『アンチOOは○○』『OO厨は○○』ってのがしたいのであれば、
別スレが適当ではないかしらん？（後者２つは別板が適当）

927 ：デフォルトの名無しさん：02/08/22 16:48

結論

OOはOOを使える兵士だけの戦場では有効
OOはOOを使えない兵士だけの戦場では無効
OOを使える兵士とOOを使えない兵士が戦えばOOを使えない兵士は負けもしくは引き分けである。

OOを使える兵士とOOを使えない兵士を混ぜた時
OOを使う場合、OOを使えない兵士は足を引っ張る
OOを使わない場合、OOを使える兵士は足を引っ張ることはない。

これは>>1が立てた議題に反しない。
問題点は戦場は今もこれからも完全にOOが使えない兵士だけであるかということ。
もしそうなら戦場では今もこれからもOOは使えないだろう。
逆にそうでないのならOOが使えない兵士はOOを使える兵士に倒されていくだろう。
OOが使える兵士、使えない兵士。あなたがどちらになるのを選ぶかはあなたの自由である。

928 ：デフォルトの名無しさん：02/08/22 17:29

>>927
上記の過程は人数が同じの場合だよね？
OOを使える兵士を育てるには金と時間がかかり、大軍を編成することは難しい。

929 ：デフォルトの名無しさん：02/08/22 17:48

アンチOO必死だな。ﾌﾟ

930 ：デフォルトの名無しさん：02/08/22 17:54

また、ゴキブリが出現した。
OO厨って何でこんなにキモイの？

931 ：デフォルトの名無しさん：02/08/22 17:59

>>928
それは非OOを使える兵士をOOを使える兵士にする場合だよね。
始めからOOを使える兵士を育てれば、非OOを使える兵士にするのに比べて
金と時間がかかることは無い。

932 ：デフォルトの名無しさん：02/08/22 18:00

>>930
アンチOO＝煽るだけ

933 ：デフォルトの名無しさん：02/08/22 18:07

OO使えない香具師にはそれなりの部分をまわせば済む話じゃないの？
COBOLer以外にCOBOL実装部分を回すのは既知害だろ。

934 ：デフォルトの名無しさん：02/08/22 18:22

XMLと同じでこれからOO使えない奴は路頭に迷うことになるね。ﾌﾟ

935 ：デフォルトの名無しさん：02/08/22 18:22

>>933
その通り。
・OO使える奴にはOO部分をまわす。
・非OO使える奴には非OO部分をまわす。
・OOと非OOを使える奴にはOO部分と非OO部分をまわす。
それだけ。どれがいいと思うかは人それぞれかもしれないけどね。

936 ：デフォルトの名無しさん：02/08/22 18:29

>>1を含めてOO使えない糞SE、糞PGは
無理してOO使うことないんだよー(´･∀･`)
キミたち以外のSE、PGはこれから皆OOを
駆使してプログラムしていくからさ。

937 ：デフォルトの名無しさん：02/08/22 18:34

>>936
はいはい、勝手にOO使う仕事だけしといてね～。
もう非OOの仕事はしなくていいからね～。
えり好みして仕事見つからなくても知らないからね～。

938 ：デフォルトの名無しさん：02/08/22 18:34

ま、非OO中は永遠に兵卒のままのわけだが。

一生地獄の前線を彷徨っててください（ﾜﾗ

939 ：デフォルトの名無しさん：02/08/22 18:36

> OO使えない糞SE、糞PGは
具体的にはギコBASICをOOで書けないヘタレね。

940 ：デフォルトの名無しさん：02/08/22 18:37

>>939
そうそう、書けないヘタレね。書かないじゃなくてね。

941 ：デフォルトの名無しさん：02/08/22 18:39

> 一生地獄の前線を彷徨っててください（ﾜﾗ
OOができると勘違いしてるOOできない奴＝OO厨のこと？

942 ：デフォルトの名無しさん：02/08/22 18:41

煽る暇があるのに書かない奴って自分のソースに自信がないの？
自信がないから自分より下を見つけて安心したいの？

943 ：デフォルトの名無しさん：02/08/22 18:42

>>942
どっち向けのメッセージ？

944 ：デフォルトの名無しさん：02/08/22 18:43

>>941
OOが本当に使える奴じゃない奴のことね。

945 ：デフォルトの名無しさん：02/08/22 18:44

>>943
自分(>>942)向けのメッセージ

946 ：デフォルトの名無しさん：02/08/22 18:44

OO厨って感じ悪いよね～。
OOなんて普及率悪いことして、俺は他人と違うと思い込んでいる奴は
こうなっちゃうんだなって。

947 ：デフォルトの名無しさん：02/08/22 18:45

アンチOO＝煽るだけ
>>930 >>946

948 ：デフォルトの名無しさん：02/08/22 18:47

>>946
でも、出来なくて挫折してる奴よりは良いんじゃないの？

949 ：デフォルトの名無しさん：02/08/22 18:51

>>948
無知の知って知ってる？

950 ：デフォルトの名無しさん：02/08/22 18:53

>>949
こっちの台詞♪

951 ：デフォルトの名無しさん：02/08/22 19:00

全く夏休みですな。

952 ：デフォルトの名無しさん：02/08/22 19:06

>>949
たぶんこいつは無知の知の意味を勘違いしている。

953 ：デフォルトの名無しさん：02/08/22 19:08

>>952

自分のことがバカだと気付いていない者はバカである。
よって>>949はバカである。

954 ：デフォルトの名無しさん：02/08/22 19:10

>>949
OOはどうせ酸っぱいに決まってるよね（ｗ

955 ：デフォルトの名無しさん：02/08/22 19:23

>>953
他人を罵る奴もあんまり知性は高くないけどね。

956 ：デフォルトの名無しさん：02/08/22 19:24

>>954
グリム童話「すっぱい武道」

957 ：デフォルトの名無しさん：02/08/22 19:30

イソップだろ

958 ：デフォルトの名無しさん：02/08/22 19:31

ウソップだろ

959 ：デフォルトの名無しさん：02/08/22 19:32

ヤコッブだって。

960 ：デフォルトの名無しさん：02/08/22 20:07

（　´,_ゝ｀）ﾌﾟｯ

961 ：デフォルトの名無しさん：02/08/22 20:57

>>915
お、数値計算と証明プログラミングが得意そうな人ﾊｹｰﾝ

962 ：デフォルトの名無しさん：02/08/22 21:20

業界大手の開発でもオブジェクト指向のプロジェクトは少ないよ。

963 ：デフォルトの名無しさん：02/08/22 21:29

結局の所、OOできない業界大手は、
屑みたいな人材しか集められなくなって、
大手じゃなくなるってこった。

964 ：デフォルトの名無しさん：02/08/22 21:36

>>962
＞業界大手
どこよ？

965 ：デフォルトの名無しさん：02/08/22 21:37

だからOOなんて簡単だって。本さえ読めば誰でも分かる。
アルゴリズム中心の考え方・設計の方が特殊な才能がいるよ。

966 ：デフォルトの名無しさん：02/08/22 21:38

>>965
> だからOOなんて簡単だって。本さえ読めば誰でも分かる。
じゃあ誰でもわかるように簡単に説明してくれない？

967 ：デフォルトの名無しさん：02/08/22 21:40

>>966
掲示板のレス程度で説明できるなら本は出版されない。

968 ：デフォルトの名無しさん：02/08/22 21:42

>>967
概要だけでも説明してよ。

969 ：デフォルトの名無しさん：02/08/22 21:44

>>966
そこまで簡単だとは言ってないよ(w
でも数学的な頭は必要ないから勉強さえすれば誰でも分かるって言いたいだけ。

970 ：デフォルトの名無しさん：02/08/22 21:44

>>968
概要だけじゃ中身はたいして理解できないが。

971 ：デフォルトの名無しさん：02/08/22 21:45

アンチは本を読むことができんほどレベルが低いのか！？

972 ：デフォルトの名無しさん：02/08/22 21:47

>>971
うふふ。

973 ：デフォルトの名無しさん：02/08/22 21:48

概要説明できないなら一応聞くけど、やっぱ状態遷移図描いたほうがいいの？

974 ：デフォルトの名無しさん：02/08/22 21:51

>>973に追加。
OOの場合と非OOの場合の両方の答えをお願いします。

975 ：デフォルトの名無しさん：02/08/22 21:57

　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ
☆ ﾁﾝ　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀｰ　　　　　　　　　　　　
　　　　　 ☆　ﾁﾝ　　〃　 ∧＿∧ 　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）＜ OO厨のソースまだー？
　　　　　　　＼＿／⊂　⊂＿)＿　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　／￣￣￣￣￣￣￣／|
　　　　　　　　l￣￣￣￣￣￣￣￣|　.|
　　　　　　　　|　　○ みかん ○　 |／

976 ：デフォルトの名無しさん：02/08/22 21:58

結論もまとまらないことだし
そろそろ次スレいきますか？

977 ：デフォルトの名無しさん：02/08/22 21:59

978 ：ネタニマジレス：02/08/22 22:13

>>968
●データ構造とそれに対する処理（メソッドと呼ぶ）を一まとめにしてオブジェクトと呼ぶ事にする。

●処理はオブジェクトが互いにメソッドの起動要求（←メッセージ）をやり取りして進む。
（アクターモデルという）
互いに相手のオブジェクトのデータ構造には触れないのがルール
（メッセージ送信を直接関数呼出ですましてしまう手抜き言語も多い）

●オブジェクトの仕様書をクラスとよぶ。
オブジェクト指向言語とは大抵クラスを定義できる言語のことである。
（クラスのかわりに見本のオブジェクトを作ってそれをコピーして使うのもあるらしい、
使った事無いので良く知らん）

●他のクラスをちょっぱってきて改造部分だけ記述する
継承という手抜き技もある。
これを応用すると似たオブジェクトを
十羽ひとからげでまとめて扱えたりもする。
（ファイルとソケットとＣＯＭポートとか、
ラベルとボタンとテキストフィールドとか、、）

●使う側からすれば完全なクラス定義などなくても
メソッドの外部仕様だけあれば用は足りる。
クラスの外部仕様書をインターフェースとしてサポートする言語もある。
Ｃで喩えるとプロトタイプ宣言がつまったヘッダファイルのように使える。

、、な、カンタンだろ？

979 ：デフォルトの名無しさん：02/08/22 22:16

>>978
これは概要だから本を読めばちゃんと理解できるんだよね。

980 ：デフォルトの名無しさん：02/08/22 22:16

>>978
取りあえず恥さらすのはやめとけ。

981 ：デフォルトの名無しさん：02/08/22 22:19

>>978
ガンバッタナー。たとえ>>968が納得したとしても
ほかのアンチがあらゆる論理で対抗してくるよ。
結論出てるのにもかかわらず
次のスレもたつだろうし時間の無駄だよ。
ほかの板いくなりテレビみるなり
勉強するなりしたほうがいい（オレモナー）

982 ：ネタニマジレス：02/08/22 22:29

>>981
仕事で煮詰まってたから
良い気分転換になったよ
さあ仕事もどっか！

983 ：デフォルトの名無しさん：02/08/22 23:15

>978
ねたですか?

984 ：デフォルトの名無しさん：02/08/22 23:30

>>978
698だけど、うーんなんていうか、漏れの課にいるSEで、性格がきちんとしてる
せいかどうかはしらないけど、君が書いた説明みたいなのを客先に出す仕様書
の頭のほうに書きたがるヤシがいてね、気が短い客だと、そこ見ただけで
不機嫌そうな顔に変わっちゃったりするわけ。
分かった？

んで、状態遷移図については誰も書かないの？

985 ：逝って良しの１：02/08/22 23:30

ＯＯ厨　＝　こんな時間まで仕事しながら煽り。
アンチ　＝　定時に上がって自宅からカキコ

986 ：デフォルトの名無しさん：02/08/22 23:31

>>984
て優香、698って誰だよ（ｗ
968の間違いですｽﾏｿ。

987 ：デフォルトの名無しさん：02/08/22 23:31

>>985
証拠を出してね。

988 ：デフォルトの名無しさん：02/08/22 23:32

>>984
少なくともOO派もアンチOO派も状態遷移図についてなにも言ってないね。

989 ：デフォルトの名無しさん：02/08/22 23:45

>>977
>OOを使わない場合、OOを使える兵士は足を引っ張ることはない。
これには反例があるみたいだぞ >>882

990 ：デフォルトの名無しさん：02/08/22 23:54

>>989
そいつを有能と言っている奴が無能なんだろ。

991 ：デフォルトの名無しさん：02/08/22 23:56

>>989
OOをつかうこととそのひとが有能かどうかには関連性がないねん。
非OOがみんな無能ってわけじゃないようにね。

たこでもJavaでコードちょっとくみゃOOできますって言うねん、
ってか882はOOを本当につかえるかどうかわかんねぇじゃん。
外注の履歴書なんてうそばっかだっちゅうに…

882の例は、無能な奴はいらんってありふれた例にすぎん、
OOがどうかにはあまり関係なしね。

992 ：デフォルトの名無しさん：02/08/22 23:58

>>984 >>988
勘弁してくれ、状態転移図ってのは構造化プログラミング系のころから
あっただろ？　～法とかでさ。
おまえら本当に両方やった上で議論してるんだろうな？

993 ：デフォルトの名無しさん：02/08/23 00:01

>>991
タコより厨がヤバイ、なんでもかんでもＯＯしようとする
時と場所を選ばん奴がおるんよ

994 ：デフォルトの名無しさん：02/08/23 00:02

>>992
そりゃ昔からあるだろ。別にOOみたいに目新しい技術じゃないし。
んで、OOに状態遷移図使ってるの？
ついてに、使ってるとしたら、構造化～の時と同じ手法？それとも別のヤツ？
てか、構造化～の頃に状態遷移図使ってた？

995 ：デフォルトの名無しさん：02/08/23 00:04

さぁ1000げと大会のはじまりだ
集え若人

996 ：デフォルトの名無しさん：02/08/23 00:05

次スレは？
もうおしまい？

997 ：デフォルトの名無しさん：02/08/23 00:05

金