オブジェクト指向は戦場では必要無し　その２

1 ：あたたたた：02/02/09 23:55

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

前スレ http://pc.2ch.net/test/read.cgi/tech/1011997945/

いつの間にかスレが1000に達しようとしていました。たくさん
の意見ありがとうございます。
前スレでの議論の結果、やはりというか当然というかオブジェ
クト指向の戦場での実績や有効性には大きく疑問が残るという
結果となりました。。。
皆さんも本当に何が残ってゆく技術なのか、何がイマイチぱっ
とせずに中途半端に終る技術なのか見きわめて、技術を習得して
いきましょう。

2 ：あたたたた：02/02/09 23:57

自分で２ゲット

3 ：　：02/02/09 23:59

こんなスレでパート２やんのかＹＯ！

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

>>1
＞前スレでの議論の結果、やはりというか当然というかオブジェ
＞クト指向の戦場での実績や有効性には大きく疑問が残るという
＞結果となりました。。。

お前の目は節穴なのかと小一時間問い詰めたい。

5 ：デフォルトの名無しさん：02/02/10 00:06

>>4
火を噴いたプロジェクトの消火に後付けで OO を突っ込むのは間違い、というのは
共通認識だと思うけど。そこから OO 自体の有効性に話が進むと、意見が割れる。

6 ：4：02/02/10 00:10

>>5
はじめから「ちゃんとした」 OO をすればプロジェクトは火を噴かない
という結論に達したのかと思ってたよ。
たしかに戦場に後付けの OO はよろしくないね。

7 ：デフォルトの名無しさん：02/02/10 00:22

OOマスターした人どうしで、
OOを分析して、今後どういう風にしていくか考えるスレという事で
いいですか？>1

そういうわけで、C++もJAVAもRubyも使えないような人は
このスレ立ち入り禁止です。

8 ： ◆CudPDzYA ：02/02/10 00:23

キャップをつけようかな・・・

9 ：デフォルトの名無しさん：02/02/10 00:24

>>7
言語と
まぁいいや。

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

>>6
＞はじめから「ちゃんとした」 OO をすればプロジェクトは火を噴かない
ちゃんとしたOOって何？

11 ：デフォルトの名無しさん：02/02/10 00:26

>>10
開発プロセスの初期から OO を織り込んでおくこと。

12 ：t&t ◆CudPDzYA ：02/02/10 00:27

アスペクト指向についてまだ調べていないんですが、
アスペクト指向言語っていうのがあるんでしょうか？

ちゃんとしたって言うのは、
経験を積んだ人が、という意味では？

13 ：デフォルトの名無しさん：02/02/10 00:28

>>7

VBで必死こいてOOしてる俺は立ち入り禁止ですか？

14 ：デフォルトの名無しさん：02/02/10 00:28

とりあえずＯＯで成功したプロジェクト上げてくれ
業務内容は適当にぼかす事にして。

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

>>12
有名なのは AspectJ。Java の拡張ね。

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

>>14
非 OO で火を噴いたプロジェクトなら、いくつか。思い出したくない思い出だが。

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

アプリケーションとしては成功したけど、政治的に失敗したプロジェクトなら…
広域交通シミュレータってのがある。

18 ：デフォルトの名無しさん：02/02/10 00:37

えーなー。公共事業系なら年収１０００万いくだろ？

19 ：14：02/02/10 00:39

>>15
そうじゃなくて、自分が担当したプロジェクト。

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

まあ、ＯＯ信者ってのは痛い奴が多いよな。
周回遅れでビリで走ってるのに、本人は戦闘を走っているつもり。
おまけに人を見下すような人間的に問題のある奴も多いし。
誰も書いてない意見に反論するデムパも多い。

21 ：14：02/02/10 00:41

>20
煽り発言ばっかりしてないで、もうちょっと建設的にならないものか。

22 ：t&t ◆CudPDzYA ：02/02/10 00:42

>>15
どもです。
今度、調べてみます。

>>13
VBはOOできないっす。
VBはけっこういいとは思いますが、
やはりDelphiの方がいいのでは？と。
Delphi入れ忘れました。

23 ：デフォルトの名無しさん：02/02/10 00:42

ＯＯ盲信者にはそういうやつ多いかもね。

24 ：15：02/02/10 00:43

>>19
お前には言ってない。

25 ：デフォルトの名無しさん：02/02/10 00:43

>>22
ええ？まさか。
Ｂａｓｉｃでだって出来るぞ。

26 ：デフォルトの名無しさん：02/02/10 00:44

いや、アセンブラでだって出来るぞ＞ＯＯ
Ｊａｖａだとやりにくいがな。

27 ：デフォルトの名無しさん：02/02/10 00:45

>>22
いや、漏れは VB6 で OO してたよ。
実装継承がないから Strategy パターンや Decorator パターンに頼る事になるのと Template Method パターンみたいな事はどうしてもできないけど、
それなりにしっかりした物ができる。
実装継承は馬鹿に刃物になりうるので、馬鹿がおおい VB には
丁度いい仕様だったかもしれない。

28 ：デフォルトの名無しさん：02/02/10 00:46

まあ、アンチＯＯってのは痛い奴が多いよな。
未知の分野に挑戦する勇気が無いだけなのに、本人は堅実派のつもり。
おまけに人の足を引っ張るような人間的に問題のある奴も多いし。
誰にも相手にされてないのに必死に煽るデムパも多い。

29 ：デフォルトの名無しさん：02/02/10 00:46

>>25
ほんとの BASIC だとローカル変数なし、構造体のような複雑な型も一切無し、
関数ポインタなんかも存在しないから、多態とかオブジェクト状態の保存とかえ
らく面倒そうだ。

理論的に出来るのと、実際にプログラミングを組む上で使えるのは別だと思う。

30 ：デフォルトの名無しさん：02/02/10 00:47

>>20=27

31 ：アンチＯＯにＯＯ使いが居ない事は彼らにとって最大の不幸であろう：02/02/10 00:47

技術的な話が全くできんからなぁ・・・

32 ：デフォルトの名無しさん：02/02/10 00:47

まちがえた
>>20=28

33 ：デフォルトの名無しさん：02/02/10 00:47

某保険イントラ/エクストラシステム
総計数十億だったか数百億だったか数千億だったか
開発中は火噴いたが全要件を期間中に実装しきって安定駆動中
何を持って OOP かって難しいけど、フレームワークの中心は
巨大な Composite と Strategy, State だった、で良い?

34 ：デフォルトの名無しさん：02/02/10 00:49

>>29
馬脚を現したな。
それはクラス指向だ。

35 ：　：02/02/10 00:50

Stateと言えば聞こえがよいが、実はmain関数だけしかないソースだったり・・・。

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

>>34
プロトタイプベースのオブジェクト指向でも、何らかの形で多態は実現する必要
はあるし（関数ポインタじゃなくて VM の力を借りてシグネチャが一致するメソッド
を実行時に特定するのが多いけど）、オブジェクト固有の状態も保持しなきゃダメ
でしょ。

37 ：27：02/02/10 00:51

>>32
びっくりして >>20 読み直したじゃねーかゴルァ！

38 ：33：02/02/10 00:51

ああもう話が次逝ってるし…

39 ：28：02/02/10 00:51

>>32

はずれ。

40 ：デフォルトの名無しさん：02/02/10 00:51

>>35
具体例を出せといって、出すと根拠のない煽りかい…

41 ：デフォルトの名無しさん：02/02/10 00:52

TASMでOOやってる強者はいないか？

42 ：t&t ◆CudPDzYA ：02/02/10 00:54

>>27
動的バインドが使えないのは痛いよね。
VB7からは使えるようになるんだっけ？

43 ：デフォルトの名無しさん：02/02/10 00:54

>>34
あ、アホアンチＯＯ発見。わかった振りして適当な言葉使うな。

44 ：36：02/02/10 00:55

>>34
クラス指向とオブジェクト指向の違いを説明してくれ。俺は >>36 で答えたが、
これで問題ある?

45 ：デフォルトの名無しさん：02/02/10 00:56

>>35
＞Composite と Strategy, State
これをみるとどう見てもパターン名。それで
＞Stateと言えば聞こえがよいが、実はmain関数だけしかないソースだったり・・・。
というと、State パターンについて何も知らないという事がばれてるよ。

46 ：t&t ◆CudPDzYA ：02/02/10 00:56

http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/patternIndex.html
たぶん、技術を経験的に身に付けて
かつ
普段デザパタの用語を口にしない人は、
どれがどれだかわからなくなると思うので。
自分は仕事してるわけではないので、
一回一回見ないとわからなくなる。

47 ：13：02/02/10 00:59

>>27
>実装継承は馬鹿に刃物になりうるので、馬鹿がおおい VB には
>丁度いい仕様だったかもしれない。

同意。
Formにロジック全部のっけるような馬鹿が多いからねぇ。

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

ところでさ GoF パターンの「本質」ってなんだと思う？
GoF は何を我々に伝えたかったのか？っていう部分。

おれは
＞インターフェイスに対してプログラミングせよ
だと思う。
これがわからないアンチが何言っても駄目だよね？

49 ：t&t ◆CudPDzYA ：02/02/10 01:02

おそらく
クラス指向って言うのは
プロパティーとメソッドをカプセル化しただけのもので
オブジェクト指向って言うのは、
似たようなプロパティーとメソッドを持つクラスを
グループ化（概念化）したものだと思うよ。
要するに、ポリモーフィズムを使うか使わないか
ってとこじゃないかな？

50 ：t&t ◆CudPDzYA ：02/02/10 01:03

>>48
GoF本って良く出てくるけど
何ですか？
お薦めのデザパタの本ってあります？
コレ一冊買えば、他にはいらない。
って感じのがいいのですが。

51 ：デフォルトの名無しさん：02/02/10 01:03

＞とりあえずＯＯで成功したプロジェクト上げてくれ
＞業務内容は適当にぼかす事にして。

52 ：13：02/02/10 01:04

>>42
>動的バインドが使えないのは痛いよね。
>VB7からは使えるようになるんだっけ？

ん？
俺がVB6で使ってるのは幻か？

53 ：デフォルトの名無しさん：02/02/10 01:07

>>49
> プロパティーとメソッドをカプセル化しただけ
それは ADT (抽象データ型) と呼称するのが一般的。

34 はどうせ何も考えちゃいないと思うが、俺はクラス指向というと

　クラス間の関係を主に考察する

っつー感じがするな。インスタンスではなく、クラスの方を中心に見る感じ。

54 ：デフォルトの名無しさん：02/02/10 01:07

>>50
ギャング　オブ　フォー

ＯＯメソッドの確立などで中心的な役割をした4人の人たちが共著
したデザインパターンに関する説明の本。

「アンタッチャブル」の主役のようなイメージでみんながあの人
たちをＧｏＦと呼ぶのよ。

55 ：t&t ◆CudPDzYA ：02/02/10 01:08

>>52
うぇ？
使えるの？

継承ないんじゃないの？
派生クラスポインタみたいなのがないとか？

VB一回しか触った事ないからよくわかってないのかも。
（かも、じゃないね）

56 ：デフォルトの名無しさん：02/02/10 01:09

>>14,51

もしかして煽ってるつもりか？
そもそも「成功したプロジェクト」ってなんだよ。
予定した範囲の実装が予定した範囲の予算と期間で完了するだけじゃダメなのか？

57 ：48：02/02/10 01:09

>>50
ネタだと思うのでネタで返してやる。
「Java言語で学ぶデザインパターン入門」がいいよ。
ネタではあるが、この本自体は初学者には本当にいい。

58 ：デフォルトの名無しさん：02/02/10 01:09

>>52
サンプルコードを頼みたい

なんか、このスレで珍しく役に立つ情報が（ｗ

59 ：t&t ◆CudPDzYA ：02/02/10 01:10

>>53
なるほど。
それがデータ抽象なんですか。
Abstract Data Typeって感じですか。

>>54
その本が今のところバイブル的なもんですか？

60 ：デフォルトの名無しさん：02/02/10 01:13

VB6で動的バインドっていうのはWithEventsを使うやりかたかな？
動的バインドとは仕組み的に違うけど同じようなことができる。
動的バインドよく理解していないから違ったらゴメン。

61 ：t&t ◆CudPDzYA ：02/02/10 01:17

>>57
いや、ネタじゃないですよ（汗）

JavaPressで、デザパタ入門みたいなの読んだくらいですね。

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

全然関係ないが、クラス指向で検索したらこんなのが出てきた。

オブジェクト指向は本当に「オブジェクト」指向か？]
http://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/

「アナリシスパターン」買って読んでみるかな。

63 ：デフォルトの名無しさん：02/02/10 01:18

VB6 における動的バインドって

Dim objHoge As Object

Set objHoge = ConcreteObject

objHoge.MethodOfConcreteObject(100) ' ←これ

みたいな物だと思っていたが違うの？
Object 型には具体的なインターフェイスは定義されてないけど、
なんでも呼び出せる。入ってるインスタンスが、対応する
シグネチャのメソッドを持っていないと実行時エラー。

64 ：57：02/02/10 01:19

>>61

65 ：デフォルトの名無しさん：02/02/10 01:20

>>59
バイブルっつうか、みんなが良く使うクラスの構造に適当な名前を
命名して「こう呼ぶことにしよう」と決めたものということかな。

それぞれの名前があらわす概念については、昔から使われていた
ものであって、特に目新しいわけじゃない。

66 ：57：02/02/10 01:23

> 61
ネタじゃないのならちゃんと教えてあげよう。
君の求めているのは通称 GoF 本とよばれる。
「オブジェクト指向における再利用の為のデザインパターン」だ。
第二版からはCD-ROMもついてお買い得。
金色と緑のサイケな第一版を間違って買うとマズー。

67 ：デフォルトの名無しさん：02/02/10 01:24

オブジェクト指向プログラミングというのは、デザインパターンや
UMLやら覚えないとプログラムできないものなのですか？

68 ：t&t ◆CudPDzYA ：02/02/10 01:26

VB6で動的バインドできそうな雰囲気です。
implementっていうのがあるのかな？
http://homepage1.nifty.com/CavalierLab/lab/vb/clsmdl/index.html

>>66
どうもです。
せっかくなので、買ってみようと思います。
サンプルコードはC++ですよね。

69 ：デフォルトの名無しさん：02/02/10 01:26

>>67
んなこたぁない。
むしろデザパタやUMLレスで経験積んでから
それらを読んだ方がありがたみも理解しやすい。

70 ：t&t ◆CudPDzYA ：02/02/10 01:28

>>67
そんな事はないよ。
デザインパターンは名前覚えてないけど、
どれも使った事あるようなやつばかりだったし。
UML覚えたけど、あまり使ってない。

それ以上に、C言語的な
（関数）ポインタやら、構造体の仕組みやらがわかってないと、
納得できない部分が生じそう。

71 ：デフォルトの名無しさん：02/02/10 01:29

＞とりあえずＯＯで成功したプロジェクト上げてくれ
＞業務内容は適当にぼかす事にして。

72 ：デフォルトの名無しさん：02/02/10 01:29

デザインパターンやUMLというのはどこまで覚えればよい
ものなのですか？

73 ：デフォルトの名無しさん：02/02/10 01:30

>>67
そんなことない。むしろプログラムも組まないでデザインパターンや
UML の話しないでくれ、と言いたい。

74 ：　：02/02/10 01:30

あのーＯＯってなんですか？

75 ：デフォルトの名無しさん：02/02/10 01:32

>>71
成功数じゃなくて成功率を見なきゃ意味ないだろ。
そもそも成功ってなんだよ。

76 ：デフォルトの名無しさん：02/02/10 01:34

>>71
「成功した」の条件を述べてくれ。
完成したら成功なのか？売れたら成功なのか？

77 ：t&t ◆CudPDzYA ：02/02/10 01:35

>>72
デザインパターンは全部覚えた方がいいんじゃないの？
もしかしたら、そういう発想ができないってのは、
それ自体が問題なのかも・・・
重要なのは、他人と会話する時の単語だと思う。
俺はプロじゃないんで、一人で作る事しかないから。

UMLは別に覚える事たくさんあるわけじゃないので
自分で必要だと思えるものに関して、全部覚えておけば
いいと思うよ。

78 ：デフォルトの名無しさん：02/02/10 01:35

ＧｏＦ本に書いてある、いわゆるデザインパターンと呼ばれるものは、
要するに、実装を「良いコード」にするためのガイドラインだよ。

例えばＣで、関数ポインタによるジャンプテーブルや構造体のメンバに
関数ポインタを持たせて動的ディスパッチなんて技もあるが、無知バカ
PGでもif文の嵐で同じ結果は出せるでしょ。でも、if文の嵐なんか
使うより、関数ポインタを使ったほうが保守性や拡張性などで有利なこと
が多いよね？

そういった技のOOP言語版だと思えばいいよ。

79 ：デフォルトの名無しさん：02/02/10 01:36

>>72
デザパタは GoF 本に一通り目を通しておけば良いと思うけど。あとは実際に
設計していく段階で

　これ、確か似たような状況で使えるデザパタがあった気がするなぁ

っつーときに書籍を読み返して、良く理解する。

UML は人によるな。分析／設計／実装どこをメインでやってるかで話が違うし、
設計の規模にもよる。

数人のチームで行う小規模開発なら、プログラマの間ではクラス図とシーケン
ス図ぐらいがあれば事足りることも多いよ。

80 ：デフォルトの名無しさん：02/02/10 01:37

>>68
implements はインターフェイス継承するためのキーワードだ。
これ使ってなかったら、VB で OO なんてまったくできないよ。
実装側でメソッドの書き方が特殊なんで気をつけてな。
Public Sub InterfaceName_MethodName ()
みたいな書き方しなきゃいけない

買うっていうのは GoF 本？
サンプルは C++ だけじゃなく Smalltalk なんかも出てくる。
不安ならネタで返してやると言った方の Java言語で学ぶデザインパターン入門も読むといいよ。

81 ：t&t ◆CudPDzYA ：02/02/10 01:38

>>76
確実にOOが成功するパターンは
インターフェースが決まってる場合かな。

１プロトコルAで通信するS/Cを作れ
２ついでに、プロトコルBでも通信できるようにして
３プロトコルCでも・・・
これが永遠と続いてもOOなら大丈夫かな。

82 ：t&t ◆CudPDzYA ：02/02/10 01:42

>>80
なるほど。
VBは今後触る事もないだろうな・・・。

Smalltalkは、サッパリだと思う。
どうしよ・・・
JavaPressに載ってた分に関しては、
使った事のないやつはなかったな。

83 ：デフォルトの名無しさん：02/02/10 01:57

>>80
タダのミスだと思うが、普通は
Private Sub InterfaceName_MethodName ()
~~~~~~~
あと、これは書かなくてもマウスでちょっとクリックするだけで
勝手に書いてくれる。

84 ：80：02/02/10 02:35

>>83
何故 Private にするの？
VB のインターフェイスは Java のインターフェイスに近いものだから
Private なメソッドは大抵の場合必要ないよ？

85 ：13：02/02/10 02:59

>>84

つまり、こうしたいって事？

　Call hoge.InterfaceName_MethodName()

これじゃ何のためにインターフェイス使ったか解らなくなるんですけど。

86 ：デフォルトの名無しさん：02/02/10 03:07

>>85
C++ あたりだと、一般に基底クラスの公開仮想関数を private で実装しなおさない
のが一般的って気がするけど。

87 ：デフォルトの名無しさん：02/02/10 03:40

>>62 オブジェクト指向は本当に「オブジェクト指向」か

多重分類と動的分類を扱った記事ですね。
OOの方にもｱﾝﾁの方にも、読んでほしい…

88 ：13：02/02/10 03:43

>>86

継承するInterfaceをIHogeとして、IDEのスケルトン生成機能を使うと、
HogeConcreteの実装は>>83氏が書いたように、デフォルトでは

Private Sub IHoge_MethodName ()

となるわけです。
このConcreteなクラスを利用する時は、

Public Function CIHoge(Byref hoge As Object) As IHoge
　　Set CIHoge = hoge
End Sub

というキャスト関数を用意しておいて、

Private Sub Form_Load()

　　Dim hoge As HogeConcrete

　　Set hoge = New HogeConcrete

　　Call CIHoge(hoge).MethodName()

End Sub

とします。
もしPublicで実装してしまうとキャスト関数が不要になる代わりに、85みたいな
事になってメソッド名が統一できなくなるんですよ。

89 ：デフォルトの名無しさん：02/02/10 04:05

>>87
動的分類はまあ面白いとは思うけど、
問題はそれをどうやってわかりやすくdenotateするかだな。
つまりOOPLなんかにどうやって織込むか。
織込み方をまちがうと、動的分類は多重継承以上の難物になる可能性高し。

90 ：84：02/02/10 04:22

>>13
実装側のシグネチャが Private でもいいとは知らなかった。今確認してみたが
たしかにそれで ok だった。
でも、public でも、インターフェイスを通してなら、インターフェイスに定義している名前で呼び出せるよ。
今まで実装側も全部 Public で書いてたよ。Java に慣れてるから。

91 ：84：02/02/10 04:28

>>88
キャスト関数!?俺はそんな変な関数書いた事ないよ。
インターフェイス IPrinter と、それを実装した CPrinter がある場合、以下でオーケー

Dim objPrinter As IPrinter
Dim ConcretePrinter As New CPrinter

Set objPrinter = ConcretePrinter 'CPrinter が IPrinter を実装しているので全く問題なし。

Call objPrinter.PrintOut ("Message") 'IPrinter において宣言されているメソッドを呼び出せる

92 ：13：02/02/10 04:46

>>84
>キャスト関数!?俺はそんな変な関数書いた事ないよ。

べつに特殊な例を挙げたつもりは無いんだけど。
ttp://www.gj.il24.net/~nakasima/vb/tips/#VBTIPS11

Publicにするっていうからキャストがめんどくさくいのかと思ったよ。

93 ：13：02/02/10 04:48

>>92（自己レス）

×：>>84
○：>>91

×：めんどくさくい
○：めんどくさい

集中力が切れたようなので寝ます。

94 ：デフォルトの名無しさん：02/02/10 05:26

なぜOOスレにﾌﾞｳﾞｨ房が？

95 ：デフォルトの名無しさん：02/02/10 05:31

>>88
このキャスト関数ってMSDNライブラリにもしっかりのっていますね。
[VB] オブジェクトを異なるインターフェイスにキャストする方法

MSDNには、「この関数の名前をインターフェイスと同じ名前にすると、プログラムがスリムになります。」
と書いてあるんだけど、同じにしたらなんか不具合が出たような・・・。

96 ：83：02/02/10 06:09

>>84
ミスじゃなかったのか・・・。
これはVBなのでVBの書き方でお願いします。m(__)m

>>86
別にここでPrivateにしたから、実装がPrivateになるわけじゃないんです。
PublicはPublicです。ただ単に書き方が違うだけです。

VBではMethodNameが定義されているInterfaceNameをImplementsしたHogeから
Hoge.MethodName()という呼び出し方は出来ないんです。
一旦InterfaceName型の変数に代入する(キャストみたいな感じ)必要があります。
InterfaceName型に代入された後はInterfaceName型のシグネチャでアクセスできます。
つまり、InterfaceNameの宣言でMethodNameがPublicなら、
HogeのInterfaceName_Method()を呼び出すことが出来ます。

クラスHogeでのインターフェースの定義は
Private Sub InterfaceName_MethodName ()
となります。ここでPrivate宣言していますが、MethodNameのスコープをP
rivateに変更するわけではありません。

これをPublicにした場合もHoge.MethodName()という風には呼ぶとは出来ません。
InterfaceName型の変数に一旦代入するのは同じです。
一つ変化することは、インターフェースの定義の書き方はメソッドの定義の書き方と
同じなのでHoge.InterfaceName_MethodName()という呼び出しができるようになります。
しかし、インターフェースの利用の仕方からいってあまり意味はありません。

97 ：デフォルトの名無しさん：02/02/10 06:27

たとえVBにOO導入したとしても、
「VBで大規模」って想像できないんですが。

98 ：デフォルトの名無しさん：02/02/10 06:36

>>97
小規模でOO使っちゃいけないのかい。関係ないよね。

99 ：デフォルトの名無しさん：02/02/10 07:56

大規模ってどのくらいの規模？

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

フォーム50以下かな

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

50超えた付近から　まあ多少整理した方が効率良い感じになるね

102 ：　：02/02/10 09:13

>>43
この板の初心者発見。
「クラス指向」はこの板のＯＯ関連用語だ。
なにしろクラスで書けばＯＯＰだと思ってるのが多いのでな。

103 ：デフォルトの名無しさん：02/02/10 09:15

「フォーム」って何？

104 ：デフォルトの名無しさん：02/02/10 09:19

まずさ、プロジェクトの全員がOOしなくちゃいけないような仕事のやり方が間違いだよ
理解してないような奴含めて、全員がOOP言語触らしたらダメなのは当然じゃないか。

OOP言語は理解してるやつだけが触る。そうじゃない奴には別の仕事をさせるだけ。

たとえばスクリプトを作って、免ｶ強しない女又には　スクリプトを触らせる
出力フォームの細かい調整とか　通信の応答とか手間のかかる部分を集中的にね

105 ：デフォルトの名無しさん：02/02/10 09:20

>>103　コボルの時代からの用語で、入力の画面や印刷物の事です　勉強しましょう

106 ：デフォルトの名無しさん：02/02/10 09:47

>>99
だれかがどこかのスレで良い定義してたな。すごく感覚的だけど:

大規模 ― 全体を理解できない
中規模 ― 詳細は分からないが全体を大まかには理解できる
小規模 ― 全体を詳細にわたって理解出来る

みたいな。ホストや企業間絡むとシステム全体を理解するのはほとんど
無理だし、新人には大規模でも神様にとってはは中規模ってのもあり。

107 ：デフォルトの名無しさん：02/02/10 09:57

全体が把握できないほどの大規模でしか有効じゃないなら
俺らシモジモには用のないもんって事になるな

108 ：　：02/02/10 10:04

>>105
それなら知ってるけど、プログラムの規模を現すのに使うもんじゃないぞ。
プログラム＝表示という狭い見方。

109 ：デフォルトの名無しさん：02/02/10 10:09

>>108　使うもんじゃないぞというからには
　把握できるかどうかなんて曖昧な指標じゃなく別の判り易い指標だせよ

人月かい？　それともステップとか行数かい？

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

>>105
大規模システムを画面数で工数見積もりするとデスマーチになるよ。
画面の裏のロジック量を見なきゃ。それが見えない内はコーダーしててね。

111 ：デフォルトの名無しさん：02/02/10 10:19

だいたい、規模なんてチンコの大きさと同じで感覚的なものじゃん。

112 ：デフォルトの名無しさん：02/02/10 10:27

>>110
　ある程度の規模超えるとフォーム数で見積るしかないんじゃないの？
　逆に、何で見積もるつもり？　
先に言っとくけど、　「そんなもの実際の設計に入らなきゃ判らないよ」

小さい規模なら細部の話を先に聞いてから見積もりできるけどさ

113 ：　：02/02/10 10:29

よくわからんが、「フォーム」で見積もる場合はスタンドアロンなの
だけかな？
サーバーサイドとかＤＢは無し？

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

>>112
Java なら要件定義で見つけた Bean の数を元に見積もるな。
それができないと？

115 ：デフォルトの名無しさん：02/02/10 10:34

>>112
シナリオ数でもいいし、分析の初期段階で切り出せたサブドメイン数でもいい。
別にフォーム数なんかに拘る必要はない。

116 ：デフォルトの名無しさん：02/02/10 10:35

あ、もちろん画面数も考慮に入れるよ。

117 ：デフォルトの名無しさん：02/02/10 10:37

すまん、116 は 114 にかかってます。

118 ：デフォルトの名無しさん：02/02/10 10:41

>>112 も要件分析で画面つらしか定義しないわけじゃないでしょ。
WYSIWIG な時代 (古いなぁ) だからといって見えないものは見ないじゃ
仕事できないでしょ。

119 ：デフォルトの名無しさん：02/02/10 11:12

蔵鯖でＤＢ触る程度のアプリなら画面数と工数は比例するかも知れ
ないけど、ｱﾌｫみたいな量の項目数、入力制限、項目間制約、試算、
支社通知、ホスト通信、ＤＢアクセス、承認、権限確認なんかやっ
てると、画面数と工数は指数比例していることが良く分かるよ。

そういえばサーブレット開発で画面数ベースの工数見積もりして
一年間のデスマーチやったチームがいたなぁ、と遠い目をして
みたり(某最大手損保)…

120 ：112：02/02/10 11:23

そもそもJAVAでやるかどうかなんてのはその後の話だ。

まず、客が欲しがってるのは　画面・帳票だという事。
どの言語を使うかとかDBのタイプやフィールドの概念はない
＃そりゃ言い出す客は当然存在するけどね

>>119
　そうそう。　通信が入ると組み合わせがあるのと同じだから
　たしかに単純にフォーム数比例じゃ大事になるね

121 ：デフォルトの名無しさん：02/02/10 11:43

言語選定前の見積もりなんて曖昧すぎてお客さん側にも迷惑かかるから
ウチは絶対やらない。お客さんのほしがっている画面と帳票をこの
言語で、このシステム構成で、このハードとソフトで構築した場合、
もちろんＤＢも脳内設計くらいは出来た状態で工数を出してから
提出してますけど、他は違うのかな。ある程度の想定事項を置いて
お客さん側にメニューから選んでもらうような感じでやるのが、
要件も暴走しないし安全かと。

122 ：デフォルトの名無しさん：02/02/10 11:56

>>104
　とやっても、給料一緒という罠

123 ：デフォルトの名無しさん：02/02/10 12:42

結局、クラスライブラリを作る言語と　それを使うだけの言語に分かれてくのかな

って　それVBじゃん！それC#じゃん！

124 ：デフォルトの名無しさん：02/02/10 18:42

ここでOO理論ふりかざしているヤツラって、
本当に戦場を経験しているのか？独学野郎じゃねーの？

125 ：デフォルトの名無しさん：02/02/10 18:47

>>124
中身がない煽りだなぁ。少しは工夫しろよ。

126 ：デフォルトの名無しさん：02/02/10 19:00

>>121 脳内設計って(藁

どこかの業界では、
要件定義→仕様書作成をコンサルor信用ある業者に費用払って依頼して、
それからハードウェアとソフトウェア/運用系を別々に入札してたけど、
損保業界はそんなに洗練されていないんですか？

見積もりするっつー事は、ある程度設計を進める必要があるわけで、
経費かかるって事でしょ。

127 ：デフォルトの名無しさん：02/02/10 19:03

> 本当に戦場を経験しているのか？
デスマーチを何度も経験してることが偉いのか、というのも割と疑問だが。

デスマーチになってから生き残るすべを考えるより、そもそもデスマーチに
ならないことの方が重要だし、毎度毎度デスマーチに巻き込まれてるのは
本人の資質にも問題があるじゃないのか?

確かに環境によっては個人ではどうにもならん場合もあるが、それなら「職
場変えろよ」という気がする。デスマーチ率が低い職場だって、世の中には
存在してるぞ。

128 ：デフォルトの名無しさん：02/02/10 19:17

>>127
こいつの所はデスマーチ（藁

129 ：　　：02/02/10 19:47

まだ歪曲してるな。

戦場＝実務。

戦場≠デスマーチ

130 ：デフォルトの名無しさん：02/02/10 19:49

>>129
実務なら現役に決まってるやん。

仕事と全く関係なしにソフトウェア工学だけ勉強しても、面白くなかろうて。

131 ：デフォルトの名無しさん：02/02/10 20:07

独学しったか野郎は土中にもぐって市ね。

132 ：デフォルトの名無しさん：02/02/10 20:14

>>131
中身のある反論をしなよ。それじゃ、ただの煽りやん。

133 ：　　：02/02/10 20:15

>>130
何の話だか判らんが、このスレの趣旨は
「オブジェクト指向は実務では役に立たない」
という議論を途中で
「オブジェクト指向は火のついたプロジェクトでは役に立たない」
と歪曲したひとが居たのです。

134 ：デフォルトの名無しさん：02/02/10 20:17

>>133
> 「オブジェクト指向は実務では役に立たない」
は、まともな反論がなくて立ち消えになってた気がするけど。

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

では　オブジェクト指向設計は　派遣や外注が多いプロジェクトでは役にたたないと　歪曲してみる

136 ：デフォルトの名無しさん：02/02/10 20:26

>>130 の居るプロジェクトではオブジェクト指向は役に立たないのは事実。

理由は各種 OO スレでの結論を見よ。(～ばかりのプロジェクトでは OO は駄目だね！というやつ)

137 ：デフォルトの名無しさん：02/02/10 20:29

>>136
130 じゃなくて 129, 131 あたりじゃねーのか?

138 ：　　：02/02/10 20:36

だからね。
オブジェクト指向っつーのは、裸の王様の服なの。
「馬鹿には見えない服です」って言われて。
「ああ、見えます。見えます。」
って喚いてる、濁った脳の人がいるだけなの。
俺は脳がクリアだから、見えないもんは見えないと正直に言うだけだ。

139 ：デフォルトの名無しさん：02/02/10 20:45

>>138
童話だと、裸の王様よりも酸っぱい葡萄を思い出すな。

140 ：デフォルトの名無しさん：02/02/10 21:06

>>138
オブジェクト指向の話にすると

「馬鹿には出来ない技術です」って言われて。
「ああ、出来ます。出来ます。」
って喚いてる、濁った脳の人がいるだけなの。
俺は脳がクリアだから、出来ないものは出来ないと正直に言うだけだ。

ということか。なるほど。そうだよなぁ。
できるって知ったかぶりしてるやつもいるもん。君は正直者だ。

141 ：デフォルトの名無しさん：02/02/10 21:13

140=しったかクン

142 ：236：02/02/10 21:33

だからね。
オブジェクト指向つーのは、裸の王様の服の裏話なの。
「馬鹿には見えない服です」って言われて、そのとおりなのに
>>138 みたいな馬鹿の前でそれを着て、
「この服は馬鹿には見えないんです」って説明しても
>>138 からすると、こっちが馬鹿にみえるでしょ？
だから馬鹿には OO が馬鹿みたいに見えるんだよ。

わかった？

143 ：142：02/02/10 21:33

いや、俺は236じゃない。予言者じゃない。

144 ：デフォルトの名無しさん：02/02/10 22:12

最近安置＆ネタスレばっか伸びてんな。
困ったものだ。

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

まぁ、２ちゃんねる以外では本音で議論/罵倒合戦できない人が多いようだから、
大目にみてよ。

146 ：デフォルトの名無しさん：02/02/10 22:27

オブジェクト志向がダメだとは思えない、でもすごいとも思えない。
裸の王様ちうのが「ダメかすごいかのどっちか」、
という意味なのだとすれば、そういう議論にゃ意味がない気がする。
やめないか？

147 ：デフォルトの名無しさん：02/02/10 22:49

たとえば、小規模なサイトかなんかで
リレーショナルＤＢに突っ込まれたデータから
会社組織を部とか課とかのクラス構成にデータをおとして
で、そっからそこに属する社員一覧表をとりだす・・・
とかいうことやるより
ＳＱＬに全条件つっこんで欲しい一覧表形式でデータ取り出して
必要なパラメータだけもったデータクラスにつっこんで・・・

ってやったほうが楽だし早いなぁ・・・って思ったりするんだけど
どうなんだろね？

148 ：　　：02/02/10 22:53

SQL自体手続き型だしｗ

149 ：デフォルトの名無しさん：02/02/10 23:01

>>148
へへへ、わかってるんだけどね・・・
ＪａｖａとリレーショナルＤＢつかってるプロジェクトでは
そのへんのことどうやってるのかなぁと思ってさ
なんか、そこに無理が出てきちゃう感じがしてすっきりしな
いんですよ

クラスがただ単にデータの入れものになってしまって、操作
を持たない状態になってるし・・・んー

150 ：デフォルトの名無しさん：02/02/10 23:02

OODBってどうなのかな？
手軽でいいやつある？

なかなかアンチ OO が消えない背景には、事務処理プログラムとかにとって
かなり重要な要因である DB がいまだに OO 向けじゃないというのも
あるような気がしてきた。

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

>>150
オブジェクトストアってのがあるね。
ライセンス料とかはよく知らないけど、プログラム側
（Ｊａｖａ）との融合性はよかった。オブジェクトを
そのまんまＤＢに入れておけるって感じ。（まんまやん）

ただ、ＲＤＢだと、ちょいちょいってデータいじれる
んだけど、ＯＯＤＢだと最上位のオブジェクトから順
順にオブジェクトをこしらえてあげなきゃいけない・・・
だからちょっとめんどくさかったＤＥＴＨ。

152 ：デフォルトの名無しさん：02/02/10 23:12

>>150 小中規模の事務処理プログラムであんまり普及しない理由は

○データ重視設計で十分破綻なく設計できる
○請負や短期派遣で作ってしまうパターンが定着しており、教育を含めてとなるとコストアップになる
○オブジェクト指向設計は案外方言が多く統一していない

153 ：148：02/02/10 23:15

>>149
サーブレットならシングルトンが使えるから
「一回ごとに作っては入れなおして消す」
みたいなことしなくていい。
上層ではＤＢを意識せずＯＯとして使えるようには組めます。

154 ：デフォルトの名無しさん：02/02/10 23:17

>>152
>○データ重視設計で十分破綻なく設計できる
>○請負や短期派遣で作ってしまうパターンが...
>○オブジェクト指向設計は案外方言が多く統...
３、はあまり実感わかないけど、だいたいその通りっすね。

っつうか小中規模で破綻するような状態では・・・
ＯＯつかおうがなにしようがダメじゃーんって感じで。

155 ：仕様書無しさん：02/02/10 23:19

ソフトウェアメトリクス
この技術は重要だと思うよ。
見積もり誤りはデスマーチの始まりなのはみんなわかってんだから。
ただ、ソースコードが無い状態でどうやってメトリクスするのか？
OOPの達人たちは何をどうしているのか？

156 ：デフォルトの名無しさん：02/02/10 23:22

>>149
>クラスがただ単にデータの入れものになってしまって

メソッドの無いクラスを作ってはいけないという規則は無いよ。

157 ：デフォルトの名無しさん：02/02/10 23:33

>>153
147その他っす

シングルトンつかって期限つきのキャッシュこしらえて
企業の組織とか、使いまわしきくようなデータは使いま
わす（深いクローンで）設計にしようかと思ってます。
いまのところ。
んで、社員とかもろもろのデータとかは、要求ごとにＲ
ＤＢから適宜もってきて、部とか課とかに関連づけよう
かという考えなんす。
で、そこらへんの処理するクラスをきりわけておけば、
上層からはＤＢ意識しないですむようになるかな・・・と。

ただ、それなりにメンドクサイなーと・・・
ＳＱＬに全条件つっこんで欲しい一覧表形式でデータ取
り出して必要なパラメータだけもったデータクラスにつ
っこんで・・・ってやりたくなっちゃった。
そんな感じっす。

158 ：148：02/02/10 23:40

パラメーターからSQL文を組み立てて表を返すメソッドでも組んだら？
ＤＢ見るだけなら。
トランザクションだのセッションだのが多いと上層組んで忘れたくなる
けどね。

159 ：デフォルトの名無しさん：02/02/10 23:43

>>157

上層は上層の都合で設計するのは正しい事です。
最初からパフォーマンスを追及するとトンデモOO設計の出来上がり。
パフォーマンスアップにはUnitTestでリファクタリング、これ最強。

160 ：　：02/02/10 23:48

パフォーマンス追求でrowid多用してあやうく死ぬところだったのは
内緒だ。

161 ：157：02/02/10 23:50

>>159
ラジャーっす！！
そう強く言い切ってもらえるといい感じっす

162 ：デフォルトの名無しさん：02/02/11 00:07

とにかく動くこと！　これが最低限必要なことなのよ。
判ってくれ！

163 ：デフォルトの名無しさん：02/02/11 00:13

納期内に動くものをつくる。
そういう話はＯＯとかなんとか以前の問題っすね。

164 ：デフォルトの名無しさん：02/02/11 00:17

マニファクチャーって言葉を思い出したよ。
ネクタイ締めて、スーツ着てるけど、やってることは
家内制手工業か。エレガントな解法が見つかったとき職を失う。

165 ：デフォルトの名無しさん：02/02/11 00:30

戦場で必要なのは兵隊の血と涙のみよね

166 ：デフォルトの名無しさん：02/02/11 00:31

>>162
> とにかく動くこと！　これが最低限必要なことなのよ。
当然。そして競争に勝つためにさらに良い方法を目指す。
いつまでも最低限のままじゃだめだよ。

167 ：デフォルトの名無しさん：02/02/11 00:32

関係ないですがOOでOSを組む内容の本が昔ありましたが、
すでに絶版になっているようです。

168 ：デフォルトの名無しさん：02/02/11 00:41

>>166禿げＤＯ

ところで1は、ＯＯ自体が有効じゃないというてるの？
>あくまでちゃんと設計され、ちゃんと実装されたクラスがあるという前提での話。
ならＯＯは有効って意味じゃない？ねぇ？
ＯＯを有効に使えるＰＧ、ＳＥがいないってことと、
ＯＯが有効かどうかってのは別の問題ちゃうん？
どうなの？

169 ：デフォルトの名無しさん：02/02/11 00:41

つーかむちゃくちゃな顧客の要求を整理して、仕事の内容を整理する
ことの方が重要じゃねーの。10年SEやっててそう思った。
なにをしたいかってのが判ってない顧客が多すぎるんだよ。イメージ先行で。

170 ：デフォルトの名無しさん：02/02/11 00:44

最近は、「仕様は変わるもん」って開き直った開発手法が
はやってるね

171 ：デフォルトの名無しさん：02/02/11 00:48

＞百七十　違うよ。「仕様は変えるもの」だろ。
矛盾した仕様でコードはかけねーよ。手で出来ないことは
機械には絶対出来ないって。

172 ：デフォルトの名無しさん：02/02/11 00:57

>>171
「仕様は変わるもん」って矛盾した仕様でもとりあえず組む
ってことで言ったんじゃないＹＯ。

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

>>168がいいこといった
よってこのスレ終了　おつかれさまでした～

174 ：デフォルトの名無しさん：02/02/11 02:09

業務だとよくわかんないけど
とりあえず、一般的なアプリケーションでは
OOは有効という事でいいのかな？

175 ：　：02/02/11 02:29

>>174
使って間違い無いのはＧＵＩ部品だけ。

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

業務でも有効だけど何か？
でも派遣や委託、ＤＱｿにやらせるなら、処理の末端部分、つまり
「このフローをココにかけ」レベルまで落とし込んでやらないと
だめ (OO でも実装の末端は細かい処理の集まり)。従って >>1 は
末端のフローしか書かせてもらったことのないﾄﾞｺﾓ社員。

177 ：デフォルトの名無しさん：02/02/11 03:00

>>155
工程の見積もりはFP法でも使ってくれ。
メトリクスはソースコードが健全かどうかを測るものだ。
例えばリファクタリングの基準に使える。

178 ：デフォルトの名無しさん：02/02/11 03:00

つーかDQNにＯＯやらせちゃ駄目。

179 ：　：02/02/11 03:11

つーかＯＯでフローなど言語道断。

180 ：デフォルトの名無しさん：02/02/11 03:13

>>178
つーかDQNに仕事やらせちゃ駄目

181 ：　：02/02/11 03:19

つーかそれじゃコボラーとおんなじ。ＯＯにした意味無し。

182 ：デフォルトの名無しさん：02/02/11 03:21

>>180
つーかDQNをプロジェクトに入れちゃ駄目

183 ：デフォルトの名無しさん：02/02/11 03:23

>>182
つーかＰＭがＤＱＮだからそれ無理

184 ：デフォルトの名無しさん：02/02/11 03:27

必死で勉強したオブジェクト指向で作品を作りたくて仕方のない、
しったか君はプロジェクトでつまはじき。

185 ：外人：02/02/11 03:31

日本ってほんっとレベル低いね(藁

186 ：デフォルトの名無しさん：02/02/11 03:36

>>185
おい外人、お前らなぁUNICODEみたいな糞規格つくるんじゃねーよ。

187 ：デフォルトの名無しさん：02/02/11 03:41

>>185
おい外人、おまえらの国際化とは ISO-8859-X 圏だけか？
ｳﾜｧｧﾝ

188 ：デフォルトの名無しさん：02/02/11 03:43

おい日本人、お前らさっさと英語を公用語にしる！

189 ：ﾁｮｿ通信：02/02/11 03:48

日本が生き残る道はﾊｿｸﾞﾙを公用語にすることﾆﾀﾞｰ

190 ：デフォルトの名無しさん：02/02/11 03:52

話が脱糞してます…

191 ：　：02/02/11 04:10

まあ、あれだ、散々探しまわった挙句、究極の開発手法は
ＣＯＢＯＬでずーっと前からやってた手法と変わんなかったわけだ。
童話「青い鳥」と同じという
心温まるお話でした。

192 ：デフォルトの名無しさん：02/02/11 04:26

だってさぁ、石投げてアサインできるのは手続きを順番通りに
並べるしかできない奴らばっかなんだもん… それ以上の知識
を得ようという奴は少ないし。

手法の問題というより業界意識の問題かな。アウシュビッツも
そうだけど、安定した作業をこなすには考えないで黙々とこなす
事務的な人が必要という罠。

193 ：デフォルトの名無しさん：02/02/11 04:31

開発＝アウシュビッツ論が提出されました。

194 ：デフォルトの名無しさん：02/02/11 06:50

開発はアウシュビッツである。そこは脚色された殺人鬼が喜びに酔い
しれながらユダヤ人を殺害してゆくのではなく、大量のユダヤ人を効率
よく殺してゆくため与えられた作業を黙々とこなす作業員ばかりだった。

# 文才ねぇな、おれ…

195 ：デフォルトの名無しさん：02/02/11 11:20

>>183
経営者がDQNですが、なにか？

196 ：デフォルトの名無しさん：02/02/11 11:30

>>195
顧客がDQNですが、なにか？

197 ：デフォルトの名無しさん：02/02/11 11:36

>>196
小泉みたいなハリボテを支持してしまうDQN国民ですが、なにか？

198 ：デフォルトの名無しさん：02/02/11 11:37

>>192
手続きを順番通りに並べる方法で使えるからクラスライブラリは便利なのではないのか？
ひとりでやってるならともかく、
そういうふうに下位コーダに作業出来るようにするのが上位プログラマの仕事だろ？

みんながクラス作る側に回ったら、そりゃ船頭多くて山に登ってしまうよ

199 ：デフォルトの名無しさん：02/02/11 11:41

いつまでも戦争を止めないDQN星人ですが、なにか？

200 ：デフォルトの名無しさん：02/02/11 12:04

上司の子供が珍ですが何か？

201 ：デフォルトの名無しさん：02/02/11 13:05

結局ここにいたOO野郎は戦場を経験してもない、
机上理論野郎だったということだね。

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

>>198

「下位コーダ」とやらにはクラスを作らせない、インターフェイスは変えさせない
って事か？
そういうことやってるから巨大なクラスが出来上がってクライアントからパフォー
マンスでクレームが来るんだよ。
いい加減ウォーターフォールの幻想は捨てろよな。

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

>>201
いや、むしろ逆だろ。

204 ：デフォルトの名無しさん：02/02/11 13:11

>>201

残業は勲章だと思ってる勘違い野郎か？

確かに、

戦争＝毎回デスマーチ

と言う意味では未経験だが、何か？

205 ：デフォルトの名無しさん：02/02/11 13:33

>>202
　なんで？　パフォーマンスに関係する所なんて触らせたりしないよ？
逆に思うんだけど、そんな所まで触らせてまともなものが出来るなんて
よほど良質な下請使ってるんだね。　よかったら紹介してよ

206 ：　：02/02/11 13:45

>>201
つい最近DQNの援護射撃で味方撃ち殺しプロジェクトで地獄を見てきましたが何か？

207 ：デフォルトの名無しさん：02/02/11 13:46

>>202
厨にクラス設計させると大変なことになるって…

208 ：デフォルトの名無しさん：02/02/11 13:46

>>202
DQNは通常パフォーマンスに影響しない部分でも激重コーディング
しますが何か？

209 ：202：02/02/11 13:50

>>205
>パフォーマンスに関係する所なんて触らせたりしないよ？

自分をコーダとしか思ってない奴にクラスライブラリ使わせると、とんでもない
ソースを書いてきやがりませんか？
関数呼び出しの感覚で高コストインスタンスをループ中で毎回生成したりとか。
俺はそういう意識の奴が外注で来たら、コードレビュー程度では超えられない溝が
有るとみなして即切り。
逆にその辺がわかってるレベルの外注なら詳細設計を任す事も良くやる。
担当範囲でのクラス新設は自由。もちろんレビューはするけどね。

210 ：デフォルトの名無しさん：02/02/11 13:54

>>208
そもそもDQNは「パフォーマンス」という言葉や意味を知らないのですが、何か？

211 ：デフォルトの名無しさん：02/02/11 13:56

>>209
オレはコーダより上だというレベルでも
とんでもないソースを書いてきやがりますが、なにか？

212 ：ＤＱＮの評価：02/02/11 13:59

非ＯＯ＝役立たず
　ＯＯ＝自爆テロ

213 ：デフォルトの名無しさん：02/02/11 13:59

try{
　　for(int i=0; i<100000; i++){
　　　　Connection c = DriverManager.getConnection();
　　　　String s = "SELECT FOO FROM BAR WHERE ID=" + i;
　　　　ResultSet r = c.createStatement().executeQuery(s);
　　　　r.next();
　　　　ret[i] = r.getString(1);
　　　　c.close();
　　}
} catch(ArrayIndexOutOfBoundException ex){
　　;
}

ループの終了条件は配列外参照という罠。
>>202 はこんなコード見たことないんでしょ (鬱

214 ：202：02/02/11 14:04

>>213

いや、だからそんな馬鹿コード書く外注は即チェンジなんだってば。
社内メンバがそれ書いたらどうするかって？
上司に言ってチームから外してもらいます。俺を。

215 ：俺なら死刑：02/02/11 14:05

>>213
初めて見た、なんてすばらしいコードだ…

216 ：あまりのすばらしさに：02/02/11 14:10

屁がでました

217 ：デフォルトの名無しさん：02/02/11 14:17

>>214 なんだいつでも逃げられるようなシタッパか

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

>>217
それなりに実力がある人間なら、ほんっとに開発体制が腐ってると思ったら

　この仕事終わったら、転職させてもらいます

とは言えると思うが。（会社を経営してる人間は除く）

219 ：デフォルトの名無しさん：02/02/11 14:25

良い物見せてもらったので age

220 ：デフォルトの名無しさん：02/02/11 14:27

>>218
”外注は即チェンジ”なんてのたまってられる環境は転職したってそうは見つかるもんじゃない。

その前に、そんなせりふが出るような人間に　プログラマーとしての能力は認められても
マネジメント能力は期待出来ない。　それだけの人間だと思われてるよ。

221 ：俺なら市中引き回し：02/02/11 14:28

>>213
すばらしぃ・・・間違いなく俺の拳がコーダーの顔面を直撃しているだろう。

222 ：デフォルトの名無しさん：02/02/11 14:36

>>213
おれのコードだ！

223 ：202：02/02/11 14:37

>>220

なんで？
外注のレベルが低いのは俺の責任か？
無理してDQN外注使って後で責任追及されるのは俺なんだから、早めにリスク回避
するのが当然だろ。
もしかしてDQNを更正させるのもマネジメントの一部なのか？

224 ：俺なら市中引き回し：02/02/11 14:37

>>221
一発殴って言い？

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

プロジェクト要員の面接時に >>213 のコードの悪い部分を全て出して
もらうっての良いんじゃない？

つうかこれはちょっとやばすぎるだろ…
オチはコピペで大量生産と睨んだ。

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

>>224 自分をか（ｗ

227 ：　：02/02/11 14:47

ループの終了よりコネクション数の方が異常だと思うが・・・。

228 ：　：02/02/11 14:48

あ、いちおうcloseしてるのか。
いちいち。

229 ：デフォルトの名無しさん：02/02/11 14:49

>>223　
すこしいいすぎたよ。すまんな

外注を好きに選べる今の環境は幸せだと思うよ。大事にするといい

230 ：デフォルトの名無しさん：02/02/11 14:51

>>227,228

コネクションプーリング関連でサーバにすさまじく負荷をかけると思われ。

231 ：デフォルトの名無しさん：02/02/11 14:52

外注を「下請け」「下位コーダー」と呼んで枠にはまった単純作業しかさせなけ
れば、そりゃ能力がある外注は別のところに逃げるって。

232 ：213：02/02/11 14:57

>>225
> オチはコピペで大量生産と睨んだ。

当たり。元々はいくつかの処理を走らすと開放されないＤＢ接続が
発生していたので調査したしたのが事の始まり。もうびっくりと
いうかなんと言うか、マジ笑えました。とはいえ一応親会社みたいな
ところから頼み込んで入ってもらった人達なので切る事もまま
ならず、結局資料まとめてた新人に修正させました (俺も手一杯
だったし)。こんなすごいお方たちにクラス分割なんて申し訳なくて (;´д`)

233 ：213：02/02/11 15:06

・ループごとにコネクションを取得/クローズしている (本当はコネクションプールから)
・配列に値をとるのに毎回 SQL を投げている (配列は 200 個)
・配列外参照でループを抜けるときにクローズされない
・その他の例外でもクローズされない
・ちゅうかそもそも配列外参照でループ抜けるな
・規約に入ってたトランザクション分離レベル設定も自動コミット設定も無視

が正解 (他にある?)

234 ：　：02/02/11 15:11

俺はループの中でコネクション確保してる所まで見て
頭の中が真っ白になったＹＯ！
その先読めないＹＯ！

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

あー俺も過去に見たことあるなー、設定ファイル感覚でデータベースから
値を「一個一個」とってる奴。今はもういないが (藁

236 ：っていうか：02/02/11 15:29

こんなやり方もあったんだ！と目から鱗

237 ：213：02/02/11 15:45

なんかいろいろ思い出しちまった。

「動かしてて遅いと思いませんでした？」
「ｱﾊﾊ♪ﾎﾞｸのマチン、ｾﾚﾛﾝ 500 に Win98 でしたから♪」

　　鯖・側・で・動・い・て・ん・だ・よ、カ・ス！！

ダブルクリックが好きな奴らでな、ウィンドウの×ボタンをダブル
クリック、[スタート] メニューをダブルクリック、ＯＫボタンも
ダブルクリック…。結局こいつらのためにダブルクリックするだけ
で必要なファイル全部コンパイルするバッチファイル書いてやったさ、
おー書いたとも。なんか文句ある？あーーーーーすっきり！

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

>>237
ﾜﾛﾀ

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

>>237　やるなら　SQLパッケージのラッパー作っておけばトータル楽だったんじゃないの？

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

>>239
あたりだね。ドキュソにDriverManagerを直で触らせるような状況に
した人がわるいきもする。バカにバカコードを書かせない技だね。

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

まあこんな奴がけっこうウヨウヨいるんだろうな。
だとするとOOなんてまともに普及するわきゃねーんだよ。
本国アメリカでもなんだかんだいって同じようなもん

242 ：213：02/02/11 16:23

あのコードはラッパー抜きの簡略コードで書いちゃいました。
DriverManager ってのは本当はデータソースです。

243 ：　：02/02/11 16:30

>>237
奴らって何？一人じゃないの？そんな事すんのは。

244 ：お好み醤油：02/02/11 16:35

>>213 のコードって、書いてる奴の思考が読めておもしろい。
「要は適当な回数だけ回してえ、query投げてテキトーに配列に入れときゃいいんでしょ」
っていう感じ。

とても日常的というか素人的なんだけど、
でも、人間がいちいち最適なループ構造を考えなきゃいけないような
現在の大部分のプログラミング言語ははっきりいって不完全だと思う。

こういう、最適化をまったく考えられないような素人が書くコードでも、
そこそこまともに動くようなフレームワーク(言語とか概念とか)を
作っていかないとソフトウエア業界は近い将来立ちゆかなくなるだろう。

245 ：244：02/02/11 16:36

しまった、名前が残ってた…

246 ：213：02/02/11 16:38

3 人のうち 1 人が作ってコピペでまわされた形跡があった。
質的に VBそこそこC少々×1 + VB厨完全体×2 という感じ
(後で分かった)。本業務から外れたメンテナンス機能だった
のでこっちも少々油断しすぎていた (藁。まぁコードはかな
り簡略化したけどね、フロー的にあんな具合に動くよ。

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

>>244
Smalltalkのenumeratingメソッド群、もしくは
Iteratorパターンを覚えよう！

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

>>244
> ソフトウエア業界は近い将来立ちゆかなくなるだろう
RDBMS なんかは、ある意味で「素人が書くコードでも、そこそこまともに動くような
フレームワーク」ではあるんだけどね。

OS もデバイスドライバもなし RDBMS もなしって状況で、ファイルシステムを一か
ら実装するのに比べれば、既存の RDBMS を使うのは遥かに楽だし。

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

>>246
そういうやつって、外注全体のうちどのくらいいるんだろ…
ロジックのコストとかに脳みそがいかない人がいるっていうのは、言語
使える使えないと全く違う話だというのは、最近ワカタヨ。

Cを10年やってるベテラン扱いの人が一緒に仕事してるんだけど、確かにCで
コードはかけるんだけど（Javaの仕事なので、CっぽいJavaコードをかかれるが）、
そういうところが腐ってる人がいるよ。おいらが、ソイツのコードを全部チュー
ニングしなおししてるよ。ソイツは俺の倍給料貰ってるよ。理不尽ダーヨ。

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

>>248
OSとデバドラがあって、ローカルディスクが使えるなら、
なるべくファイルシステム使うようにして欲しいよ。

251 ：!=248：02/02/11 18:25

>>250

うちはボラと提携してるから無理っス。

252 ：デフォルトの名無しさん：02/02/11 18:26

>>250
トランザクションと同時アクセス対応が難しいっス。
50万件のレコードを許容時間内に検索するコード書けませン。
デッドロック時がきついっス。

でも不必要に DB 使うのはどうかと思う今日この頃。

# 1 から Oracle を作ったら米国の国家予算が丸ごと必要
# だっつう話をどこかで聞いたような

253 ：250：02/02/11 19:29

>>252
RDBMSが機能として持っている、そういった機能を使わざるをえない
時は、使ってもいいよ。つうか、使うべし。

うちのバカは、単に通信のログとるのにDBにInsertくり返すんだよ…
しかもログ管理サーバ（そんなものがあるのも不思議）へログを渡すには、
当然のように一件ずつロックしてSELECTして条件分岐してDELETE。
もうあほかと。馬鹿かと。

254 ：　　：02/02/11 19:51

＞デッドロック時がきついっス。

ヲイヲイ

255 ：　　：02/02/11 20:25

>>252
ひょーっとして
デッドロック＞タイムアウト　　
でかろうじて動いてるのを「遅い」とか言ってるのではあるまいな？

256 ：デフォルトの名無しさん：02/02/11 20:50

213でも、まだマトモなコードに見えてしまうような
外注しか知らないヲレは逝ってよしですか？

「例外って何ですか？」氏ね、ヴォケレベルしか知らない

257 ：デフォルトの名無しさん：02/02/11 20:59

>>256
元VB、Cプログラマなら許せ。仕方ないさ。
Javaプログラマで雇ってそれだったら、そく首だ。

258 ：188：02/02/11 21:32

>>213 のコード直すのは簡単だが、
　　RDBMSアクセス全般を汎用性のあるOOコードで書くのは、
　　すげー大変だと思う。

けきょーく、
・RDBMS使ってて、
・まっとうなRDBMSラッピング手段↓持ってない所
　＃Rational社も方法論作ったORマッピング:
　＃　　WebGain TopLink, Oracle BC, WebObjects, EJB2.0 等々
では、ストアド・プロシージャで処理書いて下さいっつー事になる。

259 ：　：02/02/11 21:40

未だストアド・プロシージャ以外を扱うプロジェクトに出会ったことなし。

260 ：デフォルトの名無しさん：02/02/11 22:27

>>257
まっとうなPGならどの言語だろうとそんなことはしない。

261 ：デフォルトの名無しさん：02/02/11 22:28

>>257
なにをおっしゃいます。
マルチスレッドも知らないようなＤＱＮにサーバーサイドへの道を開いたのは
ほかならぬＪａｖａではありませんか。

262 ：257：02/02/11 22:33

>>260-261
少なくともいえることは、あんたらの職場が幸せな部類に入る
ということだ。

ワケワカラン外注ねじ込まれてタイヘンな目にあったことないんでしょ。

263 ：デフォルトの名無しさん：02/02/11 22:45

>>257
この間上司(自称あせんぶらー)から送られてきたソースが
まま>>213みたいなやつだったんですが頃してよかですか？

264 ：デフォルトの名無しさん：02/02/11 23:21

Javaの場合、ライブラリにまだお手軽さが足りない上
VBより遅いから　JAVA上でラップしてあげるのも難しいわけで
正直外注を使ったり共同作業というのは難しいね

265 ：デフォルトの名無しさん：02/02/11 23:27

Java＝遅いという短絡指向はヤヴァイ。
バカPGが生み出す糞コードの性能差に比べたら、微々たるもんだ。

266 ：デフォルトの名無しさん：02/02/11 23:50

>265
そんなことないよ。
Javaは放っておいても変わらないけど、
バカＰＧは成長するんだよ。
265がバカだと思ってたＰＧもいずれ辞めるか、一人前に成長するよ。
バカＰＧを叩きなおす事は少なくとも、Java自体の速度向上を待つより
も見込みが有るはず。

267 ：デフォルトの名無しさん：02/02/11 23:56

>>266
あなたのいうバカPGってどれくらいのバカなの？
私の中では「叩き直せる」うちはバカではないと思ってるんだけど。

本当にどうしようもない人達って沢山いるよ。
本当に小規模の開発だったから「設計から全部まかせるよ」って上司に言われて
「プログラムよくわからないですから」って言ってAccessマクロで
システム組んだ入社半年君とか…。
勉強することなく、「僕、プログラムわからないです」って、お前プログラマーとして雇われてるんとちゃうんか！と小一時間どころか三日三晩問い詰めたいわ、マジで。

268 ：デフォルトの名無しさん：02/02/12 00:29

>>267
スレの流れと関係無いが、そりゃ振った奴が悪いぞ。

269 ：デフォルトの名無しさん：02/02/12 00:39

全然関係無いけど、
バカＰＧとＰＧバカって、ニュアンスが微妙に違うよね

270 ：デフォルトの名無しさん：02/02/12 00:42

女「このパカＰＧ・・・」

と

女「もう、ＰＧバカなんだから」

は全然違うよね！

271 ：268：02/02/12 00:48

>>267
せめて、「言語の勉強をかねてるんだから、しっかりやるように」
くらいはいってやれよ…新卒は、想像力が貧困なくせにプライド高い
やつ多いから、結果が出れば手段は問わないと思えば、やり方を知って
いる方法を使うのは自然な流れだと思われ。

272 ：デフォルトの名無しさん：02/02/12 00:50

Accessマクロで組むの別に悪いとも思わないけどなあ

273 ：デフォルトの名無しさん：02/02/12 00:53

>>272

十中八九VB叩きに発展するからやめとけって。
ここは腐ってもOOスレなんだから。

274 ：デフォルトの名無しさん：02/02/12 00:56

>>272
だから、環境をしっかり指定しないでほっといた>>267が
DQNだという話でしょ。要求仕様がVBでOKなら問題なし。

275 ：272：02/02/12 00:59

>>273
そうかな？
Accessマクロだって、見方によっては出来の良いクラスライブラリじゃないの？
うまく設計されてると思うよ。

276 ：こいつら虐殺したい！！：02/02/12 01:02

　　　　＼　　ｵﾆｷﾞﾘﾜｯﾁｮｲ！　　　　／　　+
　　　　　　　　　＼　　ｵﾆｷﾞﾘﾜｯﾁｮｲ！／
　　　+ 　　　　　　　　　　　　　　　　　+　　　　　　　 /■ヽ　　　/■ヽ+
　　　　　　 /■ヽ　　 /■ヽ　 /■ヽ　　/■ヽ　　 (,・Д･∩∩・∀･,,)　　+
　　　（( ∩　,,・д) 　(д・,,∩　 (,,・∀・)　(・∀・,,)　　( つ　ﾉ´ `ヽ　と）　))
　　+ 　　　ヽ　⊂ﾉ（⊃　丿（つ　つ ⊂　と）　　し'し'　　　　`Ｊし'
　　　　　　　(__(__)　 (__)し'　 (__ﾉ__ﾉ　　(__(__ﾉ　　ﾜﾁｮｰｲ　　　ﾋﾟｮｰﾝ
とにかくぐちゃぐちゃにしてやりたい。銃とかで

277 ：(& ◆FzMhtjJk ：02/02/12 01:03

(◕ฺ∀◕ฺ)ﾎﾜｰﾝ

278 ：デフォルトの名無しさん：02/02/12 01:05

(　　)
ﾉ(　* )ヽ
　ﾉωヽ＼ﾌﾟｯ
　　　　　＼
　　　　　　＼＼　ﾍﾞｼｯ
　　　　　　　　●(´･ω･`)
　　　　　　　　　(∩　∩)

.

.
　　　　　　　　(･ω･` )
　　　　　　　● (∩　∩)

279 ：デフォルトの名無しさん：02/02/12 01:07

│　絶好球！！ │
　　　　＼＿＿　＿＿＿／　　　　　,,,
　　　　　　　　 ∨　　　　　　　　　　∨
　　　　　　ﾌﾞﾝ　　　　　　　　　　，;
　　　　／　　 ∧__∧　　　∴´　:´　　　ﾊﾞｷｯ！！
　／／／　（　　　´）　　从，’,,,,∧￣￣￣￣￣￣￣￣￣
　（￣￣二⊂ 　　彡⊃　‘　＞;;:ﾟд・）　￣￣￣￣￣￣￣￣￣￣
　￣￣　　　ｙ　　人　　ＷＮ　 ’::　つ　￣￣￣￣￣￣￣￣￣
　　　　　　ミ（__＿）__）,,　　～（,,つつ　　　　　　　￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　:.,,，;´
　　　　　　　　　　　　　　∪’

ぐちゃゃゃゃゃゃゃゃゃゃゃゃああああああああああああああああああああああああ

280 ：　　：02/02/12 01:49

>>213と同じコードを書いたアフォが暴れております。

281 ：　　　：02/02/12 01:52

悔しい？
そりゃあ悔しいでしょう。
「俺はＯＯを理解してる（クラスで書けるだけ）最先端のJAVAプログラマー
　だもーん」
と思ってたけど、今日このスレ読んでプルグラマーだと自覚してしまった。
まあ、これからの人生は辛いものになるかもしれないが、ひねくれないで
真っ当に生きて欲しい　藁

282 ：267：02/02/12 03:02

>>268
それは同感。

>>272
メンテナンス性が悪い。拡張性がない。
少なくともまともなプログラマの道具じゃないと思う
(プログラマじゃない人が簡易プログラミングの為に使うにはいいものだと思う。)

>>274
俺が振ったわけでも、ほっといたわけでもない
(実際、発見した瞬間に「何やっちゃってるの!?」って思わず叫んじゃったよ
注目度バツグンだった。それから約30分間、俺の担当でもないのに心構えとか
説いた。)

>>275
クラスライブラリ？あなたにとってのクラスライブラリの定義は？

283 ：デフォルトの名無しさん：02/02/12 03:07

>>282
> 少なくともまともなプログラマの道具じゃないと思う
プログラマに必要な技能は、常に複雑な道具を使うことではなく、問題によって
適切な道具を選択することと思われ。

284 ：デフォルトの名無しさん：02/02/12 04:35

Accessマクロって何？
VBAそれとも普通のマクロ？

285 ：272：02/02/12 04:51

>>267
だあら、そいつに対して怒る事じゃないだろが。
指示した方が悪いんだってばさ（藁

DQNは>>267じゃなくて>>267の無能上司だったのね。スマソ。

286 ：デフォルトの名無しさん：02/02/12 04:57

>>282
VBAは、COMオブジェクトツリーに対するアクセス用マクロだからなあ。
なんでもかんでも全部ツリーノードという、むちゃくちゃなCompositeツリー
を用いた変な設計だけれど、一応クラス（あの場合はオブジェクトっつうの
かな？）ライブラリなんじゃない？

287 ：282：02/02/12 04:57

>>283
Office のマクロは「手作業でやる事の自動化」くらいまでが適応範囲だと思う。
それ以上の物、それ以上になりそうな物は初めから別の方法を考えるべきだよ。
複雑な道具が簡単な道具を完全に包容する場合は特に、理由なく簡単な道具を
使うと先々が大変だよ。
(これは社内のシステムで、かなり馴れ合いの入った開発だったから、
完成してから延々と機能追加とか仕様変更が来る事はわかりきってた。)

>>284
俺は普通のマクロのつもりで書いてた。VBAならVBAって書くし。

288 ：デフォルトの名無しさん：02/02/12 05:01

普通のマクロって何だよ？マクロ登録で自動生成されるのがVBAのコードだろ？

289 ：デフォルトの名無しさん：02/02/12 05:20

>>288
たしかに内部的にはVBAコードになっているかもしれないがそれを見ることは出来ない。
ウィザードみたいにVBAコードが生成されるわけじゃない。
しかもVBAでいえばDoCmdオブジェクトの機能程度しかあつかえない。
マクロはVBAと違い言語じゃない。VBAはキーボードで書くがマクロはマウスで選択する。
プログラム言語とバッチファイルぐらいの違いかな。

しかし、Accessマクロ入門みたいな名前でVBAの説明しかしていない本
（逆だったかもしれん）がなかったっけ。
紛らわしいから辞めてくれ。　この業界からなー。

290 ：デフォルトの名無しさん：02/02/12 05:41

別にVBAやCOMがCompositeになっているわけじゃないでしょ。
CompositeになっているのはAccessアプリケーション。

ところでクラスライブラリって再利用できるクラスを集めて
ライブラリにしたものと考えてあってるよね。
C++自体がクラスライブラリでないようにVBA自体がクラスライブラリではない。

VBAの場合参照設定の
「Visual Basic for Applications」や
「Microsoft Access 9.0 Object Library」等が
それぞれ、クラスライブラリってことになるのかな。

291 ：290：02/02/12 05:43

>>286

292 ：デフォルトの名無しさん：02/02/13 01:19

なんだかんだ言ってもアンチOOが出てこないと寂しいなぁ…。
(立場上)実生活で叩けないから、ここで叩いてスッキリしたいんだけど。
ちょっと圧倒的な力の差を見せ付けすぎたのかなぁ？

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

>>292
「圧倒的な力の差を見せ付けすぎた」ってのは、
「知ってる言葉全部並べてみました」という意味か? (藁

こういうスレが繰り返し繰り返し立つという事実を見てみれば、
少なくともOOは「布教」には失敗しているよ。実際、このスレの
OO信者も、OOの定義やそのメリットについて、ろくに説明できて
ない。だから、アンチで転向した奴はひとりもいなかった(よな?)。

クラスライブラリで手が抜ける? OO信者の目には見えないかもしれないが、
「ライブラリ」ならC にだってあるんだよ。それに「ライブラリ」は
常に実装隠蔽を伴うはず(でなきゃライブラリじゃないよな)。

「クラスライブラリ」が優れているというのなら、「クラスライブラリ」の
「ライブラリ」に対する優位性が説明できなければ意味がない。

…とか言うと出てくるのは、継承で差分プログラミングか?

大笑い。

294 ：293：02/02/13 02:52

たとえば、OO信者の呪文に「カプセル化」ってのがあるけど。

実装隠蔽は大規模プログラミングでは重要だけど、クラスがその単位として
妥当かといえば、疑問だと言わざるを得ない。JavaならAWTに

public class Point {
public int x;
public int y;
}

なんてクラスがあるんだが、OO信者はこういうのを見て、「これはカプセル化が
できてない! データフィールドはprivateにしろ!」って言うんだよな。
その具体的なメリットは提示できないくせに。

295 ：デフォルトの名無しさん：02/02/13 02:52

292 は召還に成功した

おめでとう（ｗ

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

>>294
このスレで Point のメンバを private にしろ、と主張してるやつは俺の目には
見えないが。

297 ：デフォルトの名無しさん：02/02/13 02:57

>>293
OO の教義は

　インターフェースに対してプログラミングせよ

なんだって。実装継承よりもインターフェース継承。

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

ＯＯを布教ねえ…。仮想敵を脳内に作ってるんじゃ？
第一布教したってメリットないしな。時間の無駄。

299 ：292：02/02/13 03:09

>>295
ありがとう!!

>>294
＞その具体的なメリットは提示できないくせに。
Java の格言だったかな？君のお望みの答えが書いてあるよ。

ま、アンチOO はそんな初歩の事も知らないで人を馬鹿にする不勉強君という事で終了しますかね。

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

>>294
どんな場合でもpublicにしろ、とか
どんな場合でもprivateにしろ、とか
そーゆーのはバカ。
publicにしたほうがいい場合もあるし、
privateにしたほうがいい場合もある。

301 ：293：02/02/13 03:49

>>292
「Javaの格言」は読んでるよ。

マルチスレッドでうんぬんなんて書いてあるけど、
getX(), setX()を作ってそれぞれsynchronized指定しても、
問題の解決にはならないよな?

何を言ってるんだこの本は? ってのが俺の感想。
こんな本に疑問を持たないから信者って言われるんだよ。

302 ：293：02/02/13 03:51

>>300
はげどー。

なんだが、「どんな場合でもprivate」って言ってる本はいっぱいあるぞ。
格言もそうだし、憂鬱な～もそうだったよな。

303 ：デフォルトの名無しさん：02/02/13 03:56

だって>>294の例だけじゃ、ＯＯでもなんでもなくて、タダの構造化の初歩の例じゃん。
これにどうツッコミを入れろっていうんだろう…

304 ：299：02/02/13 04:08

>>301
＞問題の解決にはならないよな?
正直、あなたが何を問題にしているのかわからないよ。
point はあの実装が正しいといいたいの？何故？
正直、Javaのマルチスレッドはよく知らないんだけど、
synchronized ってクリティカルセクションみたいな物じゃないの？
だとしたら何故意味がないの？
point は x と y をハラワタ晒すかのようにした状態が美しいと？

なんかとんでもないのを召喚しちゃったなぁ…。
何言ってるのかよくわからないよ。

305 ：デフォルトの名無しさん：02/02/13 04:12

>>302
っていうか本当にメンバーフィールドを public にするのが正しいと思ってるの？

306 ：デフォルトの名無しさん：02/02/13 04:35

>>305
Rect や Point の類は public にするだろ。あれは基本データ型の親戚みたいな
もので、あくまで「値」を保持するために使ってるだけだし。

参照指向で多態する「オブジェクト」と、値指向の「従来データ型を拡張した型」は
用途が全然違う。

307 ：祝☆召還：02/02/13 04:41

>>293氏は、3次元座標クラスを作るのにPointクラスを継承して
　public int z;
を付け加えるんだろうなぁ。
そして、継承で差分プログラミングか?大笑い、と思うんだろうなぁ。
Pointクラスを本当にOOでいうところのクラスだと思ってるんだろうなぁ。
本当は、classキーワードが用いられた、ただの構造体なのに。

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

そうか Java の人間は int の長さが変わったりすることを考えないから
そういう実装をしたがるのか…。

というか、どっかの別スレで書いたけど
「小手先の最適化の為に基本ルールを曲げるなかれ」
だよ。

＞参照指向で多態する「オブジェクト」と、値指向の「従来データ型を拡張した型」は
＞用途が全然違う。
これは C++ の class と struct の使い分けと同じ意味という事だよね？
それは理解できるんだけど、
「何故わざわざカプセル化の恩恵まで捨てる必要があるの？」

たとえば、ディスプレイの解像度が上がって 32767 ピクセル以上になったら
point はどうなるね？

「そんなに解像度が上がる頃にはJavaはなくなってるよ！」
というんだったら何故Y2Kが起こったのかについてのレポート提出ね♥

309 ：デフォルトの名無しさん：02/02/13 05:07

＞たとえば、ディスプレイの解像度が上がって 32767 ピクセル以上になったら
＞point はどうなるね？
300dpiで２．５ｍ以上の幅のディスプレイってはすごいなぁ。
でも、1200dpiのＡ０紙の幅は32767を超えてるからなぁ…
つか、座標＝pixelって、しかもディスプレイって、なんか、条件限定しすぎ。

310 ：祝☆召還＠307：02/02/13 05:09

>>308僕だったら、2次元座標クラスの中身が
直交座標なのか極座標なのかを使う側に意識させないために、privateにするね。
そっちの方が、早い時期に直面する問題だと思うｗ。

311 ：デフォルトの名無しさん：02/02/13 05:18

>>308
それ、カプセル化したところで

int getX()
long getX()

と戻り値の型が変わるだけじゃないのか。

312 ：308：02/02/13 05:23

>>309
やっぱりあげあし取りしかしないで質問に答えなかったね♪

>>310
図形とかサパーリなのですが、ちょっと今調べて
「なるほど～」と思いました。
単なる点でも OO 的な考え方をすると深いですね。

313 ：308：02/02/13 05:35

>>311
int getX() があったとしたら、それは潰さずに
long getXLong() を作るよ。

314 ：309：02/02/13 06:11

>>312
質問になってないんだもん。

だって、intが16bitで、座標がpixelに対応してて、しかもディスプレイコンテキスト用って限定されてるなら、そのままでいいじゃん。
用途によって、intのまま32bit環境に持っていったり、doubleにしたり、Templateにしたりすればええやん。
あげあしなんて、あげあしとれるほど精度のある事書いてから言ってくれ。

315 ：312：02/02/13 06:28

全然関係ないが、Java の int は32Bit値だったな、16BitのCコンパイラで
遊んでたのでうっかり間違えた。

>>314
＞用途によって、intのまま32bit環境に持っていったり、doubleにしたり
お兄さんはポータビリティっていう言葉は知ってますか？

あと、メンテの手間が少ないほどいいプログラムだという事には賛成してもらえますか？
なんか、どうでも良くなってきた。どんなに主張してもわかってもらえそうもない。
ある意味、「ありがとう」
君のおかげで今後、無駄な労力を使わないでよさそうだ。

316 ：デフォルトの名無しさん：02/02/13 06:52

>>312
お兄さん、ポータビリティーって知ってますか？
座標がpixelに対応してて、しかもディスプレイコンテキスト用って限定されてるコードを
そのまま一般的な「座標系」を処理するコードに持っていけるようなのをポータビリティーとはいいませんよ。

それから、Generic Programming って知ってますか？
たとえば、Point同士の加減算やPointと数値の四則演算を定義して、座標の型はパラメータにしておくような
やりかた、わかります？
AWTのPointよりも、広い用途で使いたい座標クラスなら、もっと別の設計があるっていうの、理解できますよね？

メンテの手間が少ないほどいいプログラムだというのは、もちろん同意しますよ。

317 ：デフォルトの名無しさん：02/02/13 06:56

双方とも何が言いたいのか良くわからん。
ただ相手をやり込めたいだけのようだ。

318 ：デフォルトの名無しさん：02/02/13 07:14

あげあしとりと言われちゃったら、ねぇ。

319 ：デフォルトの名無しさん：02/02/13 07:31

>>315と>>316って、仲良さげに見えるのは私だけ？

320 ：デフォルトの名無しさん：02/02/13 09:10

>>308
Smalltalkつかいなされ。
整数が固定幅なんて...プププ

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

http://mentai.2ch.net/test/read.cgi/infosys/981101071/

> あと、OO導入やOO教育は、組織的なバックアップなしでは、
> 　茨の道が待っている事を申し伝えておきましょう。
>
> 　私は、OOﾏｽﾞｰ関数言語ﾏﾝｾｰ、サイエンス系専攻で会社に入って、
> 　何の因果かOOに関わりあって、茨の道を歩んでおります。
>
> 　OOに拘りないから、豆蔵とかに逝きたいとも思わんし、
> 　かといって、義務感でフレームワークとかパターンとかやっても、
> 　理解していただける奴がいないのよね。

322 ：デフォルトの名無しさん：02/02/13 09:32

>310
「平面座標」というクラスに「直行座標」と「極座標」のインタフェースを持たせる？
そこまで考えなかったよ。

>312 と同じく感心。

323 ：デフォルトの名無しさん：02/02/13 09:37

やはりOOは現場には不向き。ヒマ人の知的遊びには向いてそう(w

324 ：デフォルトの名無しさん：02/02/13 09:49

どにーちょ開発して思考が停止している人には、
OOの向上、構造化プログラミングにOOの要素を入れることは望めない。

例えば、C++なのに中身はC言語になってるー、
とか、Javaなのに「生成＋１メソッドコール＋破棄」がセットになってて、
COBOLになってるー、って感じ。

OOの失敗　→　構造化プログラミング　になちゃったヨ

てことだから、OOを否定すると成功は無い。

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

>>324
理解できん。

326 ：：02/02/13 10:50

>>324
そいうソースはそこらじゅうにあって鬱になるよ。

327 ：デフォルトの名無しさん：02/02/13 13:00

>>321 ｺﾞﾗｧ－、晒すんじゃねぇー!!!

328 ：デフォルトの名無しさん：02/02/13 13:03

国内では、10年前は DQNにオブジェクト指向させとく
風習があったんだよね。

そのDQNどもが、「生産性向上」だ「再利用」だって、
実力もないのに宣伝しまくったから、
未だに「OOｺﾜｲｰ」とかいう未開人種が多くて鬱になるぜ。

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

豆蔵ってなんすか?

330 ：デフォルトの名無しさん：02/02/13 14:07

管理人が、ｺﾞﾃﾞｪｰ待ちしてた居酒屋の名前。

331 ：デフォルトの名無しさん：02/02/13 14:07

Drop 読んどけ。
　http://www.njk.co.jp/otg/Drop/Drop_v20/

332 ：デフォルトの名無しさん：02/02/13 14:17

WW2時代、
戦場の主役は歩兵と考え、戦車は歩兵の支援用程度にしか考えていなかったイギリス。
戦場の主役は戦車と考え、戦車の機動力を生かした電撃戦を確立したドイツ。
結果、イギリスは西部戦線で大敗北を喫することになった。

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

>>332
でも、ドイツは負けた。
戦場で必要なのは物量とそれを可能にする経済力。
古来より「大軍に戦術無し」と言われてる。

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

戦場ではＤＱＮの垂れ流した、大量のクソコードが、敵なわけで・・・

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

皆で武器を捨てて平和に逝きようYO

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

>>333

歪曲注意。
イギリスに負けたわけじゃ無い。

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

大量のクソコードを捨てるには、クラス毎差替えるのが最強。１ファイルに１クラスだと最高。

戦場の武器＝クラス

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

元のコードにクラスが無い場合は、
そこにクラスを入れて冗長なコードをクラスのメソッドに差替えて、ってやって、
先ずは、ばら撒かれてる呼出し手順をクラスのメソッド１つに集約する。
直したければ一箇所に集約されたので超簡単。
新たな機能も簡単に作れる。
状態もプロパティとして持てるから分岐しても良いし、
メソッドの中でメソッド呼んでも、メソッドを差替えるオーバーライドしても。。。

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

クラスを全面に出したのは、売り物ではまだ、
クラスベースが流行りで、オブジェクトベースが台頭してないからね。

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

>>337
真のクソコードは、グローバル（Java だと public static）な変数を大量に相互参照
していて、バラスのも一苦労ですが何か?

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

>>333
> 戦場で必要なのは物量とそれを可能にする経済力。
第一次、第二次ポエニ戦争当時、経済力で圧倒的に勝っていたカルタゴは新興国
ローマに負けたけど。

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

>>340
読んでて背筋がｻﾑｸﾅﾀﾖ。

でもまあ、クラスはグローバルだったものを内部に吸収するのは得意。

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

＞342
「Privateとか使うとゴチャつくからPublicにしろよ」
等という事を平気でのたまうクソSEが居ますが、何か...

っていうか殺してｲｲですか

344 ：デフォルトの名無しさん：02/02/13 17:27

>>343
漏れを呼んでくれたら、そいつがいかにクソＳＥなのかを、小一時間ほど問い詰めてあげよう。

345 ：デフォルトの名無しさん：02/02/13 17:28

>>313
ダメじゃん…

346 ：デフォルトの名無しさん：02/02/13 18:42

>>345　やめてくれよ　バカ相手にしてたら暴れてたいへんだから放置してたのに・・

347 ：デフォルトの名無しさん：02/02/13 20:42

Sﾖは問い詰めるしかないだろうが、
vclとかでアクセスしようとしたものがprivateで涙でそうになったことあるね。
せめてprotectedにしてよーって。
ライブラリ側じゃなかったら、0.5秒躊躇して、0.5秒でpublicにカット＆ペーストしちゃう。

348 ：293：02/02/13 20:43

帰宅したんで、まとめ書き。

>>296
>このスレで Point のメンバを private にしろ、と主張してるや
>つは俺の目には見えないが。

うん、でも、何人か釣れたようだよ (藁

349 ：293：02/02/13 20:45

>　インターフェースに対してプログラミングせよ
>
>なんだって。実装継承よりもインターフェース継承。

自分の言葉で話しなよ。何言ってのか分かってる?

「クラスライブラリ」と「ライブラリ」、「クラスライブラリ」の方が
優れているのはどこ? と聞いているのに、なんでこういう返事がくるかな。

350 ：293：02/02/13 20:47

>>304
>正直、Javaのマルチスレッドはよく知らないんだけど、

勉強しなよ。

>synchronized ってクリティカルセクションみたいな物じゃないの？

その通り。

>だとしたら何故意味がないの？

>>300 にあるように、
「getX(), setX()を作ってそれぞれsynchronized指定しても、」

意味がない、と言っている。

「Javaの格言」には、

p.x++;
p.y++;

みたいなのをマルチスレッドで実行するとおかしくなるからフィー
ルドをpublicにしちゃいかんのだ、と書いてある。

じゃあ、privateにして、synchronizedなアクセサgetX(), setX()
を付けたとして、

x = p.getX();
p.setX(x+1);

というコードを、スレッドAとスレッドBが以下のように実行したと
すると、

x = p.getX(); // スレッドA
x = p.getX(); // スレッドB
p.setX(x+1); // スレッドA
p.setX(x+1); // スレッドB

ふたつのスレッドがxをインクリメントしようとしたにも関わらず、
xは1しか増えないことになる。

getとsetが分かれてたり、xとyで独立してたりするアクセサは、
少なくともクリティカルセクションを守るためには役に立たんと
いうことだ。

351 ：293：02/02/13 20:47

言っとくけど、マルチスレッドの時に困るからアクセサ付けろと
書いてあるのは「Javaの格言」という本で、この本を持ち出して
きたのは >>299 なんだからね。

>>299
>Java の格言だったかな？君のお望みの答えが書いてあるよ。

こたええ? (糞壁流)

じゃねえや、これは俺の望んだ答じゃないから、そう言ってるだけ。

いや、あくまで俺が誤読しただけで、299は、俺とは違う解釈をし
たのかもしれん。299 の見解きぼーん。

>point は x と y をハラワタ晒すかのようにした状態が美しいと？

setX() を public にしといて、ハラワタ晒してないと思ってる方が
よっぽど「おめでたい」と思うが。

352 ：293：02/02/13 20:48

>>307
> >>293氏は、3次元座標クラスを作るのにPointクラスを継承して
>　public int z;
>を付け加えるんだろうなぁ。

まさか。

>そして、継承で差分プログラミングか?大笑い、と思うんだろうなぁ。

「大笑い」と言ってる俺がそんなことするわけないじゃん。

そんなことをすると思った理由が知りたいよ。単なる煽り?

>Pointクラスを本当にOOでいうところのクラスだと思ってるんだろうなぁ。

思ってないよ。

いや、もちろんPointはクラスかと言われればクラスに決まってる
んだが、>>306 の

>参照指向で多態する「オブジェクト」と、値指向の「従来データ
>型を拡張した型」は用途が全然違う。

という意味はわかってるつもりだ。

>本当は、classキーワードが用いられた、ただの構造体なのに。

その通り。

ただの構造体だとすると、データフィールドなんぞpublicで充分か
もしれない(もちろん場合による。Pointぐらいなら、俺ならむしろ
immutableにしそうだ)。

でも、「privateにしなきゃだめだ」というレスがいくつか付いたね。
# そうでない意見も出ているが。

「Pointクラスを本当にOOでいうところのクラスだと思ってる」のは
俺じゃないんだよ。

353 ：293：02/02/13 20:50

>>310
> >>308僕だったら、2次元座標クラスの中身が
> 直交座標なのか極座標なのかを使う側に意識させないために、privateにするね。
>そっちの方が、早い時期に直面する問題だと思うｗ。

オーケー、privateにしたとして、getterは

int getX();

か? (w

最初からdouble前提になってるなら「極座標系対応」も現実味が出
てくるが、そうなると用途が変わっちゃう。

AWTは、Pointに限らず、ディスプレイにpixel単位の整数値で描画
することに用途を絞っている。そんなとこに極座標を持ち込んで
どうするよ。drawLine()の引数はint, int, int, int だし。

AWTにそれ以外の座標系を持ち込みたいなら、Canvasみたいなコン
ポーネントで対応すりゃ充分だと思うがな。そして、Graphicsとは
全く別の描画クラスを使う。Java3Dはそんな感じだが、Java2Dって…

354 ：293：02/02/13 20:50

ま、それはさておき、doubleが前提なら、いつか「2次元座標クラ
ス」を極座標系に対応させることになるかもという主張はわからな
いでもない。

そういう場合、どうするかなんだが。

「最初は普通にprivateなx, y とアクセサからなるクラスを作る。
　後になって極座標が欲しくなったら、極座標用のアクセサを追加
するが、フィールドはx, yのままにして、毎回変換する」

でも、これなら、x, yがpublicでも、同じことができる。

「最初の設計では出てこなかった極座標の方が、実は直交座標よりも
　頻繁に使うことがわかった。内部的な持ち方を極座標に統一する」

というケースではフィールドをprivateにしたことが効いてくるだ
ろうが…

そんなこと、あるか?

最初からAbstractPointを継承して直交座標を作っといて、
極座標もAbstractPointから継承し、AbstractPointには両方のイン
タフェースを持たせる(変だなあ…)という案もあるかもしれんが、
ここはYANGIを推しときたい。

355 ：293：02/02/13 20:52

>>308
>たとえば、ディスプレイの解像度が上がって 32767 ピクセル以上になったら
>point はどうなるね？

これについては、

>>311
>long getX()
>
>と戻り値の型が変わるだけじゃないのか。

だな。

>>313
>int getX() があったとしたら、それは潰さずに
>long getXLong() を作るよ。

仮にこうしたとして、これで何が守れるの?

アプリケーションが

int x = p.getX();

と書いていたら、所詮ディスプレイの解像度がintを超えたら対応
できない。つまり、アプリケーションは守れない。

シリアライズしてディスクに突っ込んだデータは、互換性がないか
らこれまた守れない。readObject()を自分で書けば変換可能だが、
それはアクセサの話とは無関係だ。

狭い画面しか使えない古いアプリと、広い画面が使える新しいアプ
リが、同じPointクラス(のソース)を共用できる、というのが「強
いて言えば」メリットなのか… えらく限定されたメリットだよな。
どうせアプリ書き換えるんなら、共有しなくてもいいような気もす
るが。

むしろ、intでやってたんだがメモリが足りなくなって、

「しょうがない、Pointのフィールドをshortにしよう」

という選択をしたときには、フィールドをprivateにした恩恵を受
けられるかもしれない。

でも… そんなこと、あるか?

あんまり確率の低いことに保険料払うのはどうかと思うぞ。

この場合の保険料とは、アプリのソースが汚れること。

356 ：296：02/02/13 21:08

>>348
確かに（苦笑）

357 ：296：02/02/13 21:11

>>349
俺は、そもそも 293 が言ってる

> 「クラスライブラリ」が優れているというのなら、「クラスライブラリ」の
> 「ライブラリ」に対する優位性が説明できなければ意味がない。

っつー前提が勘違いだと言ってる。

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

＞x = p.getX(); // スレッドA
＞x = p.getX(); // スレッドB
＞p.setX(x+1); // スレッドA
＞p.setX(x+1); // スレッドB
この例は
x = p.getX(); // スレッドＡ
p.setX(x+1); // スレッドＡ
を分けた時点で問題が別空間に逝っちゃってるね。
p.setX(100); // スレッドA
p.setX(200); // スレッドB
ってやったときに、p.xが200であることを保証するためのsynchronizedだろう。
ま、横槍で本筋とはあまり関係無いが・・・

359 ：デフォルトの名無しさん：02/02/13 21:37

>>293
おおむね賛成だが、
Pointのx,yをprivateにする方がいいのはgetX()やsetY()に任意のコードがかけるからだと思うぞ。
デバックプリントやら呼ばれた回数測定やら妥当性チェックやら。
まあほんとに必要かどうかは疑わしいが、「任意の」というのは無限の可能性を含んでいるわけで
privateにしろと言うのにも一理あると思う。
俺はめんどくさいからpublicにするけど。

360 ：デフォルトの名無しさん：02/02/13 21:55

>>358
p.setX(100);　　// thread 1
p.setY(100);　　// thread 1

p.setX(200);　　// thread 2
p.setY(200);　　// thread 2

setX(), setY() が synchronized でも、タイミングが悪いと (100,100), (200,200) 以外
の中途半端な状態が発生する。synchronized で保護するのなら、そもそも setX(),
setY() というメソッドがダメじゃん。

361 ：358：02/02/13 22:18

>>360
＞そもそも setX(),setY() というメソッドがダメじゃん。
うん、もちろんそれは禿銅。

>>358は、結果的にあの順番のときに200って事。

p.setY(100);　　// thread 1　←並列→　　p.setY(200);　　// thread 2
のとき、yが100か200かどちらになるかを保証するわけではない。
でも、synchronized指定すれば、不定にはならないってことだろ。

ま、>>358は
「p.setX(getX()+1)　が　p.x++　より安全だっていう程度の話だ」
っていう程度の話だ。

362 ：デフォルトの名無しさん：02/02/13 22:44

>>355
getX()とgetXLong()を分けるのは、
コレまでintがかえってくること前提でこのクラスを使用していた
ユーザに迷惑かけないこと。重要なメリットなんだが…
（この例では、単にワーニングがでるようになるだけだろうが…）

363 ：デフォルトの名無しさん：02/02/13 22:48

Pointみたいなクラスで、setX()などというメソッド作ることを前提で
偉そうに語るバカがいるのか…本当におめでてえな…

364 ：デフォルトの名無しさん：02/02/13 22:55

>>362
結果的に getX() を使っていたクラスは誤動作する、あるいは実行時に例外が
飛んでくるようになる、と。結局は Point クラスを使っていたプログラムは書き直
さないとダメなわけで、隠蔽したところでメリットはないじゃない。

365 ：デフォルトの名無しさん：02/02/13 22:57

>>364
逆だろが。

366 ：293：02/02/13 23:06

>>361
んーと、確かJVMの仕様ではint型の代入についてはatomicであることを
保証してたはずだよ。doubleはだめ。float, longはどっちか忘れた。

…だからってそれに依存したコーディングをすべきではないとは思うが。

367 ：!=355：02/02/13 23:14

>>362
＞getX()とgetXLong()を分けるのは、
＞コレまでintがかえってくること前提でこのクラスを使用していた
＞ユーザに迷惑かけないこと。重要なメリットなんだが…
まるで、プロジェクトの途中で、最大解像度が16bitに収まらないデバイスが突然出現するようなこと、
頻繁におこるようないい分だな。

>>355
＞あんまり確率の低いことに保険料払うのはどうかと思うぞ。
＞この場合の保険料とは、アプリのソースが汚れること。
を読んだあげく、まだこういうやついたんだな。

368 ：デフォルトの名無しさん：02/02/13 23:25

>>367
既存の資産に迷惑かけないなら、好きにしていいさ。

JavaのコアAPIも、それができれば見苦しいライブラリの
ヨゴレがスッキリ出来るのに。

369 ：!=355：02/02/13 23:26

ちなみに　java.awt.Point　には、setX()、setY()　など、存在しません。
setLocation(double x, double y) なら、あります。
getX(),getY()は、doubleを返します。
これらは　java.awt.geom.Point2D　から継承してます。
translate(int x, int y) 、setLocation(int x, int y)　もありますが、java.awt.Point　クラスで新たに定義されてます。
java.awt.Point　特有の話の時は、このへん踏まえて欲しいな、です。

370 ：デフォルトの名無しさん：02/02/13 23:50

解像度が 16bit 以上な時代はベクトルベースのグラフィック API 使ってる
とおもわれ、ってそんな話じゃないな。超脱線ですまん。

371 ：293：02/02/13 23:51

>>358 >>360

うん、だから >>350 で、
>getとsetが分かれてたり、xとyで独立してたりするアクセサは、
>少なくともクリティカルセクションを守るためには役に立たんと
>いうことだ。

と書いた。

でも、「Javaの格言」には、p.x++;を例にして、

　コードをカプセル化しないことにより、より複雑で厄介なバグに
　さらすことになるのだ。Javaは本質的にマルチスレッドであるため、
　こうした問題を考慮することは重要である。

と書いてある(5ページ)。

んで、次のページに「クラスPointに関しては、下記のようにした方が
望ましいだろう」といって書いてあるサンプルでは、getX(), getY(),
setX(), setY()なんだよな。

もっとも、このサンプルにはsynchronizedさえ付いていないから、
マルチスレッドの話は前のページで終わったのかもしれない(えーっ?)。

でも、だとすると、わざわざPointを例にマルチスレッドの話をするのは
不適切だろうに。また、4ページには、Pointを例に「そのフィールドの
型を前提としたコードを書かなければならない」って書いてあるけど、
その後の「たとえば…」以降では、CustomerとBankAccountの話に
すりかえられている。はっきり言って支離滅裂だよ。
# Customerの銀行口座をprivateにすることにはもちろん異論はない。

>>299 はこの本読んで理解したようだから、納得いく説明をしてもらえんかね。

この本、他のところも、あちこち変なんだよな。

372 ：293：02/02/13 23:53

>>357
OOのメリットは? という文脈で、

「クラスライブラリを使うと、何千行の記述が数行で書ける」

なんてのがこのスレだか前スレだかにあったと思う。

でも、手続き指向言語でも「ライブラリ」はあるし、

「ライブラリを使うと、何千行の記述が数行で書ける」

ことだってあるかもしれん。

だったら、「何千行の記述が数行で書ける」ってのは「OOのメリット」
とは言えないじゃないか?

OOだと、(クラス)ライブラリが書きやすいとか、使いやすいとか
いうんなら、その根拠を挙げてくれ、と。

こういう言い方ならいいかな。

ライブラリの充実度とか標準化の度合いは、OO云々とは別の話だから
置いておくとしてさ。

357が「何千行の記述が数行で書ける」を「OOのメリット」に
挙げないんなら別にいいよ。そう言ってた奴が、たしかいたと思うんで。

373 ：デフォルトの名無しさん：02/02/14 00:01

「処理の対象を明確にする」ことがOOの基本だと思っているんですが、間違いですか？

374 ：デフォルトの名無しさん：02/02/14 00:02

仮想画面なら、16bitぐらい簡単に超えそうだが。

っていうかもう何年も前、スクロールバーでスクロールする仮想画面で
16bitを超えることによる問題に悩まされたことがある。

でも、Javaのintは32bitだから当分大丈夫だろ (w

375 ：デフォルトの名無しさん：02/02/14 00:05

>>365
何が逆なんだ?

　Point の実装を隠蔽したところで、後から *Long() なんてのを付け加えれば
　既存のクラスを壊さずに使える

っつーのは幻想だと書いただけだが。

実装を隠蔽するのが望ましいというのは一般論としては正しい。たとえば連想
配列の実装を 2 分木ベースにするかハッシュにするかというのは見せずに

　val = search(key);

と書いておけば、後になって key の特長によって実装を最適化できる可能性
もある。ただ、Point や int のような基本的なデータ型ではメリットは現実には
少ない（どうせ破綻する）といってるだけ。

376 ：デフォルトの名無しさん：02/02/14 00:48

>>372
単純にオブジェクト(一般的な事象に近い実装)単位でロジックを構成できるのが
一番の利点だと思うんだが。

377 ：デフォルトの名無しさん：02/02/14 01:03

>>376
追記。

一般的な事象つー言葉が適当かどうかあやしいが(自然現象とかか？)
非OOだと機能仕様とソフトウェア実装に結構差があるのに比べて
OOはその差が小さいと思う｡

設計が直感的にできるのが一番大きな利点かな。

ほかにはカプセル化することによってソースの保守とかが容易なこととか。

378 ：299：02/02/14 01:39

299です。
くやしくてくやしくて認めたくないんですけど、知識については完敗です。
当方、約半年前まで OO をまったくわかってなかった新人プログラマです。
ただ、半年前に OO に感銘を受け、少しでも多くの知らない人/不要だという人に
しってもらいたいと思ったのです。
（OO すらこの状態ですのでジェネリック・プログラミングはサッパリです。）

アクセッサのあたりは勉強になりました。ありがとう(くやしいなぁ)

でも、何故 point のメンバ変数を private にすべきか、についてはまだ一つだけ
言っておかねばならない事があります。
原則としてメンバーフィールドは private にすべきです。
(利点は説明しなくてもおわかりでしょう？)
原則を崩す例外というのは、「それによって多大な利益がある」場合のみ
認めるべきです。
x と y を public にするべき「多大な利益」はありますか？
私はないと思います。
(実行速度がシビアな環境ではトレードオフを考える価値があるかも知れませんが)
ですので、特別な理由のない point のメンバ変数は private にされるべきだったと思います。

379 ：デフォルトの名無しさん：02/02/14 01:57

>>375
プロファイル取った結果、Pointに対して遅延評価を行いたくなった
としたらどうすんの？

380 ：デフォルトの名無しさん：02/02/14 01:58

>>370
ベクトルベースなら、なおのことPointが重要なのでわ？

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

>>379
struct Point {
　　int x;
　　int y;
};

この場合は、遅延評価も何もないやん。Point を返す側で、Point をキャッシュして
おくとかは考えられるが。

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

>>380
そもそも、その場合は API が変わってると思われ。

383 ：デフォルトの名無しさん：02/02/14 02:51

>>381
なんでそこでstructが出てくるの？
僕の主張としては、structなんて使わずにclassを使ってメンバもprivateに
してアクセサ使っとけば、あとで遅延評価とかしたくなったときにコードを
あまりいじらずにすむじゃんよ、ってことなんだけど。

＞ Point を返す側で、Point をキャッシュしておくとかは考えられるが。
Pointそのものがキャッシュしたらいかんの？したいでしょ。

384 ：　　：02/02/14 03:46

難しい話ばっかだな。

ファイル分け＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ＯＯ
とか、もっと簡単に書けないの？

385 ：デフォルトの名無しさん：02/02/14 03:49

と、>>384 でアンチ OO が申しております。

ファイル分け？比較対照になりません。

386 ：デフォルトの名無しさん：02/02/14 03:50

>>383
struct と class を別物だと思ってたのか…

387 ：　　：02/02/14 03:51

生産性ではファイル分けの方が遥かに上です。

388 ：デフォルトの名無しさん：02/02/14 03:52

え？　結局publicかprivateかよりも、仕様書に「直接さわっちゃだめ！」って書くかどうかのほうが重要って事じゃないの？？

389 ：　　：02/02/14 03:52

まあ、未来の見えない人には判らないでしょうが、
未来ではファイル分け再利用に落ちつきます。
ＯＯはともかく、クラスなど笑い話にしかならないでしょう。

390 ：デフォルトの名無しさん：02/02/14 03:54

>>383
Point が「何を」キャッシュするの?　そのうち int 自体がキャッシュとか言い出しそう
だが。

391 ：デフォルトの名無しさん：02/02/14 04:44

Point はプリミティブすぎて内部状態を隠蔽してもたいした効果は
ないとおもわれ
遅延評価に修正って言ってもこっちで勝手にコード書き直すわけに
行かないでしょ。本来想定されているオペレーション (AWT におけ
る点を表す事) を超えたあるべき論に走るのはあまり良いとは思え
ない。

これから自分で作るアプリケーションが、ひょっとしたら実数で空間
座標を表す必要があるかもしれない、多次元空間まで拡張されるかも
しれない、というのなら、その想定通りの NDimensionsPoint を
作れば良いことだし。

392 ：デフォルトの名無しさん：02/02/14 04:51

＞あるべき論に走るのはあまり良いとは思えない。
だれもそんな方に走ってないと思われ。
つか、ここは、「おまえ、ダメダメ」っていうスレでねーのか？

393 ：↑：02/02/14 04:51

…走るのは、想定内のオペレーションのオーバーヘッドに直結するので
あまり良いとは思えない。

394 ：393：02/02/14 04:52

割り込まれた… 鬱

395 ：召還成功！＠307：02/02/14 05:32

祝☆召還成功と逝きたいところだが…
いったん書いた渾身の召還魔法(煽り？)を自分で消して激しく鬱…禿鬱だ。
ちょっと冷めたから、>>293に対する大量のツッコミは止めにして、軽く逝きます。
(しかし、すごいの召還しちゃったな…)

まず、>>352
煽りじゃありません。召還魔法です。

＞ただの構造体だとすると、データフィールドなんぞpublicで充分か
＞もしれない(もちろん場合による。Pointぐらいなら、俺ならむしろ
＞immutableにしそうだ)。
少なくとも、これには同意。
作りたい座標が分かってるなら、既存のPointオブジェクトに値をsetするより、
新しくPointオブジェクトを作ったほうが良い。
そんなことしてたら、速度が遅くなるし、メモリ領域も食うって？
そりゃそうさ。それが、OOの実装における欠点みたいなもんだから。

以下、もうちょっとだけ続くんじゃよ！

396 ：召還師＠307：02/02/14 05:53

>>353
＞オーケー、privateにしたとして、getterは
＞int getX();
＞か? (w
むしろ、そこが難しいポイントなのだよ、OOでは。
int getPixelX() にするか int getXInt() にするか…。
他のよく使われるクラスと整合するように、
かつ、扱っている問題に適合するようにインターフェースを選ばなきゃならない。

と、いろいろ言う前にいちいちツッコミながらやるのが面倒なので、
とりあえず、Pointクラスを例示してみよう。
内部データは、private double x, y;ってところで。
まず、ゲッター。
直交座標　double getX(); double getY();
極座標　double getR(); double getTheta();
Pixel用　int getPixelX(); int getPixelY();
他にも様々なゲッターが存在すると思われ。
そういうゲッターを用意するだけで、「2次元座標」ってものがいろいろな用途に
使われるなら、凄い便利。

で、>>354＞でも、これなら、x, yがpublicでも、同じことができる。
ここまで来たら分かるかな？
Pointオブジェクトから座標情報を得る場合に、
極座標情報の時 getXXX(); というメソッドを使い、
直交座標情報の時 aPoint.x というメンバアクセスを使うのは、
逆に凄くややこしいのだよ。
既に叩かれ役にまわってる>>308氏の言葉を借りると、
「小手先の最適化の為に基本ルールを曲げるなかれ」
だよ。”アクセスできるのは全部メソッド”のが扱うのが楽。

まだまだ、長くなりそう…。面倒臭い。でも、次。

397 ：393：02/02/14 06:26

>>395
えー、そんなに突込みどころ多かった? 要は適材適所ってことで
>>395 や >>936 と同じ事を言ってるんだけどなぁ (>>936 の
後半部分はちょっと違うか)。でもノッてるみたいだからもう
ちょっと見てよ。

398 ：393：02/02/14 06:29

あでも >>936 の後半も同意。

399 ：召還師＠307：02/02/14 06:36

Pointクラスをベクトルとして扱ったら…他のメソッドはどうなるでしょうか。
演算メソッド。
　Point add(Point anotherPoint);
　Point subtract(Point anotherPoint);
　Point dotProduct(Point anotherPoint);
　Point crossProduct(Point anotherPoint);
こんなところかな。
こうしておけば、>>350みたいにわざわざ座標を取り出して
外部で+1して、また戻すことをしなくてすむ。
　aPoint.add(Point.XY(1, 0));
でいいもん。
これに違和感があるなら、平衡移動を表わす translate を付け加えても良い。
　aPoint.translate(1, 0);
状態変化がおこるなら、なるべくPointクラス内部でおこしたほうが良い。
(ちなみに、僕的には、x, yに直接setするセッターは要らないと考えます。
直接setする値が分かってるなら、新しくオブジェクトを生成すべき。)

それでも、Windowの座標(おそらく、Windowの左上と右下の座標)を表わすのに、
こんなPointクラスは要らないって？
僕は、結構有用だと思うよ。
2点間距離を求めるのは、aPoint.subtract(anotherPoint).getR();でいいしね。
極座標は要らない？あった方が便利だよ。
例えば、Windowsのタスクバーで右クリックの重ねて表示をやってみて。
Windowが-45°で重なって表示されたでしょ？
これが、顧客の要望で距離30角度-30°で重ねて表示にしてと言われたときに、
defPoint = Point.RT(30, -30) のPointオブジェクトを用意しとけば、
1つ目のWindowの左上座標 aPoint から考えて、
aPoint.add(defPoint) が2つ目のWindowの左上座標って求まるでしょ？
これを外部で計算すると、sinやcosが見えてなんかスマートじゃなくなるのよね。

400 ：393：02/02/14 06:45

>>399
ちょっと待て、それは AWT 標準の Point クラスがこうだったら
良かったという話をしてるのか? それとも座標変換等が必要な
アプリケーションならこういうクラスを自作するという話なのか?
400 GET?

401 ：召還師＠307：02/02/14 06:55

ってまあ、言いたいことはまだまだ山ほどあるが、最後に付け加えて…
なるべく、Pointクラスはコンパクトにまとめたつもりだけどね。
生成用クラスメソッドとゲッターと演算メソッドしかないし。
それでも、Pointクラスが初期の「Point構造体」から肥大化したって？
いや、その通り！高速化やメモリ最小化を目指すならダメダメですね。
その欠点を除くために、あえなくpublicメンバの構造体を作るなら、正しい設計だ。
Pointクラスに類似したクラスは他の様々なライブラリで構造体的設計が多いかもしれない。
しかし、それはOOではない。
OOではないが、非常に現実的設計選択と言える。
ここで勘違いされては困るのは、局所的なPointクラスの設計と
それにまつわる高速化やメモリ最小化の問題のみを取り上げて、
OOがダメだとかそういう議論を止めて欲しいということ。説明するの面倒だから。
(ホントはたまにやってね！たまになら、面白いから)
OOにも利点･欠点がある。それだけ。

402 ：デフォルトの名無しさん：02/02/14 06:56

スクリーン座標を実数演算すると誤差で微妙にずれるという罠

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

せんせー！OO シンドロームの患者が脱走して 2ch で暴れているようです！

404 ：デフォルトの名無しさん：02/02/14 07:11

>>396
> むしろ、そこが難しいポイントなのだよ、OOでは。

OOでは、っつーよりstrongly typed OO languageでは、でしょう。やはり結論は「Smalltalkマンセー！」だな (藁

405 ：404：02/02/14 07:12

>>404
strongly typedというより、statically typedだった。鬱。

406 ：召還師＠307：02/02/14 07:14

>>400
AWTというわけではなく、一般的なPointクラスの話をしました。
設計思想的に、なぜ内部データをx,y座標のdouble型にしたのかは、
僕の個人的思想に委ねられています。
この設計が正しいかどうかは個人によって違うでしょう。

どういうことかというと、今回僕が作ったPoint型だと、
例えば、内部で(200.35, 350.4)みたいになってる時に
intPixelX();とかだと200が得られて丸め誤差とか発生しますよね？
これが丁度、3Dグラフィックスとかで言うところのラスタ演算にあたると考えます。
Windowのpixel座標を扱うようなものであっても、
描画を扱う以上、なんらかの状態からpixel座標がラスタ演算されて求まる方が、
僕的に気持ちが良かったのです。
pixelのint型に縛られるというのは、ディスプレイデバイスに縛られるようで、
なんだかデバイス依存になって嫌なのです。僕的にはね。

それに、こうしておくと、内部データ(200.35, 350.4)で
解像度1024×768で得られるpixelが(200, 350)で、
解像度800×600で得られるpixelが相対的に(156, 273)みたいにできるからです。
もちろん、こんな相対的変換をやっちゃうとデザインがずれる場合には、
解像度800×600でも得られるpixelが(200, 350)とできますしね。

これで、臨機応変、簡単、便利、ちょっと変なこと試したりできるとかいろいろありますが、
どう考えても、速度とメモリの問題はつらいので(初めから無視してるし)
現実的に使えないと言われれば、使うなと言いますｗ。

407 ：召還師＠307：02/02/14 07:18

なにげに漏れすげ～モードだよ。
意識せずに>>402と>>404に答えてるよ。すげ～。
>>402の誤差については、>>406で書いたし、
>>404のSmalltalkについては、
なにげにこのPointクラスってSqueakのを参考にしてるしｗ。

408 ：召還師＠307：02/02/14 07:25

最後に見返して一言。
>>395軽くないじゃんか！

409 ：393：02/02/14 07:32

>>406
> AWTというわけではなく、一般的なPointクラスの話をしました。
だったら別に異論はないよ。前に「点」が重要な意味を持つアプリで
そういうの作ったことあるし。

スレの流れが「(AWT の) Point はこうあるべきじゃ」に見えたから
「AWT の想定をオーバーした機能、やりたいなら自作するか CG 用の
ライブラリでも使えば」と思って >>391 になったわけ。

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

>>406
>>402 は丸め誤差の積み重ねの意味も入っている。

411 ：404：02/02/14 10:27

>>407
まあ、anotherPointなんて引数の命名からして
Smalltalkな匂いがプンプンするけどな (藁

>>410
そんなあなたにSmalltalkのFraction。ちと演算が遅くなるけど (藁

412 ：デフォルトの名無しさん：02/02/14 11:28

>>406
>AWTというわけではなく、一般的なPointクラスの話をしました。
「一般的な」ってなによ？
ソフトウェアは使用対象をはっきりさせなければ設計できない。君のPointクラスで
n次元ユークリッド空間の点を表そうとしたら破綻するじゃない。
ここで簡単に「一般的」なんて単語が出てくるのは分析とか設計とかを普段からやってないからでしょ？

publicでいいと言ってる人たちはこのことを踏まえて、現実にAWTのPointクラスが使われる
状況ではpublicに分があると言っているのだからさ。

413 ：デフォルトの名無しさん：02/02/14 12:17

クラスの話しろよ。

414 ：デフォルトの名無しさん：02/02/14 12:44

>>412
「一般的なPointクラス」ってのが不正確な表現だというのは同意だが、
文脈上、十分許容できる範囲内だろ。
それより、
> ソフトウェアは使用対象をはっきりさせなければ設計できない。
ってのは、ライブラリを提供してる側の立場から言わせてもらえば、
はっきりいって不正確だな。
もちろんライブラリの設計でも特定のドメインを想定している場合もあるが、
あらかじめ使用対象を設定できない場合も多いぞ。
例えば、STLが想定している応用対象は何だ？
AWTは？Smalltalkライブラリは？libcは？

415 ：デフォルトの名無しさん：02/02/14 12:56

http://mentai.2ch.net/test/read.cgi/infosys/1003585175/

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

>>414
STL が対象としているのは Assinable かつ Copyconstructive な型でしょ。

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

>>414
>「一般的なPointクラス」ってのが不正確な表現だというのは同意だが、
>文脈上、十分許容できる範囲内だろ。
>もちろんライブラリの設計でも特定のドメインを想定している場合もあるが、
>あらかじめ使用対象を設定できない場合も多いぞ。
>例えば、STLが想定している応用対象は何だ？
>AWTは？Smalltalkライブラリは？libcは？

例えばSTLのlistをDBのデータとシームレスに扱うことは出来ない。そんなことは想定していない。
sprintfは文字列を逆順で表示する目的には使えないし、Pointクラスは極座標を扱えない。

使用ドメインをはっきりさせなくては行けないと言っているのではない。
#使用対象と言う言葉が曖昧なのは認めるが
どこかで機能を押え込まなくてはならないのであり、それが想定している使用対象だ。

>>406ではPointクラスに極座標などの機能を追加している。理由は
1・AWTの利用の現状を考えると極座標は必要
2・AWTはこのままでいいけど、より拡張された目的のためには極座標が必要
のどちらかだと思うが、1ではないと明記している。
とすると「より拡張された目的のため」を一般的と言っていることになるが、n次元ベクトル空間の
Pointは扱えず、極座標が使えるPointを選ぶ理由はない。

このことを常に意識している人間ならここで気軽に「一般的な」などと言う言葉は使えないだろう。

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

>>406の言っている「一般的」の定義は、実は、
一連の書きこみで、>>406が自己定義しているという罠
「Pointクラス、俺ならこう設計する」といっているだけで、
その問題空間はこのスレには存在しない。
もちろん、こういう設計がしっくり来る場面は、沢山ある
だろうけど、問題空間を自己定義するような意見は、
なにも生まないんだよね。
（オレモネ）

余談だけど、pointではpixelの位置を表現できても厳密
にはpixelを表現してないグラフィックシステムもあるよね。
結局は、デバイスコンテキストクラスとかも併せて考えないと、
pixelを扱う用途限定のPointクラスでさえも、設計の是非
についての議論は難しいんだ。

419 ：414：02/02/14 16:36

>>417
> 使用ドメインをはっきりさせなくては行けないと言っているのではない。
> #使用対象と言う言葉が曖昧なのは認めるが
> どこかで機能を押え込まなくてはならないのであり、それが想定している使用対象だ。

曖昧ってゆーか、たぶん完全に違う解釈をしていた。
ちょっと確認したいんだけど、
ライブラリは、想定しているドメインとは別に、
それ自身が提供する概念/機能/オブジェクトが1つの閉じた系を
形成するようにしなければいけない。
その閉じた系に含まれるべき概念や機能やオブジェクトの事を
「使用対象」と呼んでいる、という解釈でいい？

420 ：414：02/02/14 16:36

>>418
でもライブラリの設計なんて、問題の自己定義の連続だと思うよ。
特定のユーザ(ライブラリを使う側)があらかじめいれば
何の問題もないんだけど、逆に対象とするドメインをこれから
開拓しようという場合なんかには、それこそ自己定義でいっぱいだよ。

421 ：デフォルトの名無しさん：02/02/14 17:19

>>420
ライブラリを作るのに、用途を何も絞らずに

　ひたすら汎用的

に作るの？　それは何の役にも立たない肥大化したライブラリが出来るだけだぞ。

422 ：414：02/02/14 17:33

>>421
ハア？
ドメインを創りながら(問題を自己定義しながら)
そのドメイン内でのライブラリの守備範囲を探りながら
構築していくということをいっているのだが。

あと、汎用的なライブラリが必ずしも役立たずの
肥大化したものになるわけでもないでしょ。

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

各々の前提条件を明らかにしないと不毛だぞ

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

>>422
それが Point の話とどう絡むかだが、現実の AWT なり Win32 なりのシステム
で点を表現する Point について、

　要素に直接アクセスさせるのは抽象度が低くてダメだろ

という意見は、そもそも AWT や Win32 が想定しているドメインの範囲外だから
意味がないんじゃないのか？

ディスプレイの解像度も上がっているから解像度に完全に依存しないウィンドウシ
ステムのフレームワークを作ろう、とか、ある種の数値計算用に N 次元線形空間
を扱える Point クラスを作ろう、というのなら話はわかるけど。

425 ：414：02/02/14 18:10

>>424
ああ、俺が噛みついたのは
「ソフトウェアは使用対象をはっきりさせなければ設計できない。」
がover comprehensiveだと思ったから。

AWTやWin32がPointをラスター上のピクセル操作にのみ使うんなら
別にpublicにしてもいいと思うよ。つーか状況次第。その点は同意。
ただし、その状況次第ってのは例えばAWTやWin32のPointの場合は実際に
publicにして直接アクセスした場合とprivateにしてアクセサを通した場合
とでのAWTやWin32全体でのパフォーマンスの差を実測して、publicにする
意義を正当化した上での話ならばね。
privateにしても全体のパフォーマンスに有意な差がなければ、
conservativeにprivate宣言したほうがいいと思うが、どうよ？

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

>>425
パフォーマンス以前に

　private 宣言することで、どういう利点があるんだ?

という方が先だと思うが。AWT はともかく Win32 のばあいは C 言語から API を
呼び出すこともあるので、互換性というのも強い動機だね。

427 ：414：02/02/14 19:13

>>426
たとえば情報隠蔽による互換性の確保。1つはAWTやWin32のバージョン間の互換性。
AWTやWin32自体、想定すべき使用対象が変化していくことは考慮しなければならない。
そこで実装の変更が必要になった時には情報隠蔽による互換性の確保が必要。
もう1つはユーザ側との互換性。
AWTやWin32が提供しているPointクラスはAWTやWin32の内部で使われるだけじゃなくて
アプリケーションあるいはユーザライブラリ側でも使わざるを得ない。
その時、ユーザ側が提供するPointクラスとの互換性があれば
冗長なコードを減らすことができる可能性が出てくる。
この時、アクセサを通した実装のほうが互換性を取りやすい。
例えばJavaのInterfaceで型の互換性を確保しようとした時。
ってのはどうよ？

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

>>427
> その時、ユーザ側が提供するPointクラスとの互換性があれば
> 冗長なコードを減らすことができる可能性が出てくる。
C++ なら template 関数書けば一発だから、そんなことを気にするやつはいない。

あとユーザ側の Point クラスと互換性を持たせようという話は、結局

　何でもかんでも詰め込んだ汎用 POINT 型

を提供しようという話になって、むしろ後方互換性が足かせになるよ。

あと実装を隠蔽することで互換性を保とうという話は HWND とかのレベルでやること
で POINT のレベルじゃ無理だろ、というのが上で話をした結論だと思ったけど。

429 ：414：02/02/14 19:57

> C++ なら template 関数書けば一発だから、そんなことを気にするやつはいない。
一方がメンバ変数直接アクセス、もう一方がアクセサ経由でも？

> あとユーザ側の Point クラスと互換性を持たせようという話は、結局
> 何でもかんでも詰め込んだ汎用 POINT 型
> を提供しようという話になって、むしろ後方互換性が足かせになるよ。
何でもかんでも詰め込んだ汎用POINT型なんてものはできない
ってのが>>412の主張で、俺はそれに同意しているのだが。

> あと実装を隠蔽することで互換性を保とうという話は HWND とかのレベルでやること
> で POINT のレベルじゃ無理だろ、というのが上で話をした結論だと思ったけど。
これがバージョン間の互換性の話なら、アクセサ経由にすることで古いインターフェイスを
残したまま実装を変えることも出来るんだが。もちろん新しいインターフェイスも追加する。
古いインターフェイスは移行期間をおいてから削除すればいい。
実装が剥きだしだと、古いインターフェイスを残すことが出来ない。

430 ：デフォルトの名無しさん：02/02/14 20:03

>>429
ま、428はアホって結論。

431 ：デフォルトの名無しさん：02/02/14 20:12

>>429
> これがバージョン間の互換性の話なら、アクセサ経由にすることで古いインターフェイスを
> 残したまま実装を変えることも出来るんだが
アクセサを

int GetX();
SetPoint(int x, int y);

とした時点で既に out でしょ。全ての引数を、無限精度整数にするとか有理数にする
のならいざしらず。

432 ：デフォルトの名無しさん：02/02/14 20:13

（だから、問題空間自己定義なひとを相手にすんなって。
　そういうやつからしたら、「どうしてそうするか」とか
　「なぜそうしちゃいけないか」の理由なんて、いくら
　でも後付けできるんだから。）

433 ：デフォルトの名無しさん：02/02/14 20:15

>>429
> 一方がメンバ変数直接アクセス、もう一方がアクセサ経由でも？
C++ の template の強力さを知らんな?　一度調べてみ、惚れるから。

434 ：デフォルトの名無しさん：02/02/14 21:05

応援よろしくお願いしまーす。
http://www.fukkan.com/vote.php3?no=2946

435 ：　　：02/02/14 23:08

OOPLは糞です。
これからは脱クラスが主流になります。

436 ：デフォルトの名無しさん：02/02/14 23:43

インターフェイスが主流になります。

437 ：414：02/02/15 01:51

>>431
アクセサの型とメンバ変数の型が一致していなきゃいけない理由でも？
アホクサ。

>>432
自分が後付けばかりするからって、他人もそうだとは思わないほうがいいよ。
414直後にそう言うんならまだしも、今になっていうのは典型的な後付けだぞ。（藁

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

その方法論、
新たな型のアクセサを設ける事と、
新たな型の(剥き出しの)変数を追加する事、
どの程度の違いがあるの？

一体何を説明したいのか不明だし、その点に於いて理由後付けに同意。
条件反射で反論並べてるとしか思えん。

439 ：414：02/02/15 02:46

>>438
本気でわからないわけ？
むき出しの変数を追加して、古いインターフェイスと新しく追加するインターフェイスとの
橋渡しは誰がどうやってする？

440 ：414：02/02/15 02:52

>>433
そうか。調べてみるよ。
正直C++は開発に使ったこと無いが、勉強になった。ありがと。

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

>>432==>>418ですが何か？

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

>>441
441自体がアトヅケだということに気付いているか？デフォルトの名無しさんW

443 ：デフォルトの名無しさん：02/02/15 05:26

>>442=>>414
よっぽど悔しかったんだね・・・

444 ：デフォルトの名無しさん：02/02/15 05:51

age

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

>>439
> むき出しの変数を追加して、古いインターフェイスと新しく追加するインターフェイスとの
> 橋渡しは誰がどうやってする？
んー、そうか。
多分、立脚点がちがってんだろうな。
新しい型とそれに対応する新しい名前のインターフェースを追加して、
内部で古い型との整合性をとったとしても、
既存の(古い型のインターフェースを叩いている)コードでは有り難味も何も無いよな。
同時に新しいインターフェースを叩いているコードでも古い型との整合性が
取られている事で何かメリットあんのか? 労力に見合うだけのメリットが感じられん。
# この話はそもそもPoint型の話だよな。
# 複雑多機能なオブジェクトの話ではなく？

446 ：将軍：02/02/15 09:17

結局なんだかんだいってOOは複雑で使いにくそうだな。
管理も大変だし。戦場ではいらん。

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

新しい型を追加する理由によってちがうよね。
座標の精度上げるのに、int→doubleにするんなら、
intのインターフェース残す意味あるかもしれない。
でも、解像度が上がって足りなくなったから、
short→longにしよう、っていうなら、古いインターフェース
では、桁あふれ起こした座標しか扱えないんだから、
古いインターフェース残す意味無いし。

448 ：デフォルトの名無しさん：02/02/15 09:31

オブジェクト指向一生懸命勉強したのに・・・。
（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者

449 ：412：02/02/15 10:05

>>414
>ただし、その状況次第ってのは例えばAWTやWin32のPointの場合は実際に
>...
>privateにしても全体のパフォーマンスに有意な差がなければ、
>conservativeにprivate宣言したほうがいいと思うが、どうよ？
何を実測するのかわからないが、少なくともpublicのほうが速いだろ。
使用ドメインを特定できないんだから、全体のパフォーマンスなんてどうやって計るんだ？
「そのパフォーマンスの低下が問題にならないようなものを対象とする」というならいいが。

それにパフォーマンスの問題だけじゃないよ。
　a.x = b.x + 3;
と言うコードが
　a.setX(b.getX() + 3);
になるのは非常に読みにくい。最初のバージョンは数学的な表現で直感的だ。少し複雑な
座表計算を行えばすぐにアクセッサ経由の記法は限界を迎える。

>>445
Pointが拡張されることが予測されているなら、アクセッサのほうに分があると思うけど？
既存の古いインターフェイスを使って計算するライブラリがあったとして、そのライブラリで
計算したPointオブジェクトを新しいインターフェイスでアクセスしたくなったらpublic方式は
困るだろう。
publicにしていいのはこれ以上拡張されることを想定していないからだよ。

450 ：通りすがりだからログなんかよんでないぞ：02/02/15 10:40

>>449
演算子オーバーロードマンセー
シンタックスシュガー万歳
Ｃ＋＋マンセー

451 ：デフォルトの名無しさん：02/02/15 10:48

えーと、お互い2行くらいで結論を述べてくれ。
俺にもわかるように。

452 ：404：02/02/15 11:18

>>447
まだ解像度が低い環境のユーザには意味がある。
その環境では古いインターフェースでも動くから。

453 ：404：02/02/15 11:38

>>449
チューニングする時にはやみくもに局所的な最適化をするよりも
ホットスポットを特定して最適化したほうがいい。
つまり、全体のパフォーマンスにどれぐらいの影響が出るかは
ホットスポットの中でのPointクラスへのアクセス頻度できまる。
例えばWin32ならばアクセサに直接起因するオーバヘッドが
描画自体のボトルネックよりも十分に小さいこともありうる。
>>449
まず、数学的に見える表現式ならば、どんな複雑な計算式でも
a.setXは1つの式あたり通常1個所だけ。したがって複雑さとは関係なし。
a.getX()がそんなにイヤならばa.x()という表現でもいいし、
Eiffelなど、言語によってはa.xという表記でC++でいうa.x()を表わすものもある。
よってアクセサ自体に本質的な問題というわけではない。
もちろんC++のみに限定して議論するというのなら、a.x()ということになるが。

454 ：412：02/02/15 12:04

>>453
>チューニングする時にはやみくもに局所的な最適化をするよりも
>...
>例えばWin32ならばアクセサに直接起因するオーバヘッドが
>描画自体のボトルネックよりも十分に小さいこともありうる。
「想定されるどんな場合でもこのオーバヘッドは無視できる」じゃない限り、意味ないとおもうが。
不特定多数の人間が使うライブラリでどうやってそれを測定するんだ？
実測なんぞ不可能で、予測するしかないだろう。

>まず、数学的に見える表現式ならば、どんな複雑な計算式でも
>a.setXは1つの式あたり通常1個所だけ。したがって複雑さとは関係なし。
複雑と言うのはたくさんの式と言うことだ。20個のsetXがあったら読みにくいと思うが。

>a.getX()がそんなにイヤならばa.x()という表現でもいいし、
a.x()ならだいぶ評価が変わる。getXだから複雑に感じるだけ。

>Eiffelなど、言語によってはa.xという表記でC++でいうa.x()を表わすものもある。
まさしくそうだ。言語がサポートしてくれるのならなんの問題もなくアクセッサでいい

455 ：404：02/02/15 12:21

>>454

> 不特定多数の人間が使うライブラリでどうやってそれを測定するんだ？
> 実測なんぞ不可能で、予測するしかないだろう。

個々の機能のパフォーマンスを実測する。
AWTやWin32なら、標準で提供するウィジットの描画や更新など。
もちろん使用対象での全パフォーマンスへの影響までは実測できないが、
現実に則した予測は可能でしょ。
少なくとも「アクセサなんて遅くなりそうじゃん」よりは現実的なデータが求まる。

> 複雑と言うのはたくさんの式と言うことだ。20個のsetXがあったら読みにくいと思うが。

それって、
a.x = b.x * c.y - c.y - b.x;
a.y = ..............
b.x = ..............
　 : (以下似たようなのが20個ぐらい続く)
みたいなケースだよね？
こういう場合、セッターは1つの文の最外・最左に1つ出るだけでしょう。もちろん代入演算子のほうが読みやすいのは確かだけど、
一番左に縦一列に並んでいるだけなら何とか我慢できない？
直感的にはわかりにくいけど、間違えを誘発するようなものでもないと思う。

456 ：412：02/02/15 12:32

>個々の機能のパフォーマンスを実測する。
>AWTやWin32なら、標準で提供するウィジットの描画や更新など。
よくわからんがPointはライブラリの中でしか使わないと言う前提？

>もちろん使用対象での全パフォーマンスへの影響までは実測できないが、
>現実に則した予測は可能でしょ。
>少なくとも「アクセサなんて遅くなりそうじゃん」よりは現実的なデータが求まる。
アプリ側でPointを使うことを想定するなら確実に遅くなる例はいくらでも思い付くぞ。
「遅くなりそうじゃん」なんてもんじゃなく「遅くなる」だ。(しかも実験するまでもなく)

>一番左に縦一列に並んでいるだけなら何とか我慢できない？
我慢は出来る。

>直感的にはわかりにくいけど、間違えを誘発するようなものでもないと思う。
まあね。

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

おまえらいつまでオナニーしとるんじゃ？
戦場と関係ない話は別のスレでやってくれ。
実質的にスレが止まっとるぞ。

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

オブジェクト指向一生懸命勉強したのに・・・。
（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者

459 ：414：02/02/15 13:15

>>456
> アプリ側でPointを使うことを想定するなら確実に遅くなる例はいくらでも思い付くぞ。
そういう場合にはアプリ側に適したPointクラスを使うもんでしょ。
適材適所ね。

>「遅くなりそうじゃん」なんてもんじゃなく「遅くなる」だ。(しかも実験するまでもなく)
a.xとa.x()じゃ、a.xのほうが断然速いのは当たり前。
それがどれぐらい全体に影響を与えるかが問題。
「Pointのアクセサ経由しなくなったおかげで
ウィジット描画性能が平均0.2%向上しました。」
は多くの場合技術者として正しい選択とは思えないっつーこと。
その0.2%がクリティカルでなければね。

460 ：414：02/02/15 13:26

>>457
そんな事いわずに、君のドタバタ話キボーン

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

>>459
俺は AWT は Win32 の Point は構造体で十分だと思ってるが

> a.xとa.x()じゃ、a.xのほうが断然速いのは当たり前。

これはダウトだろ。

MS が提供する WTL に POINT, RECT やらのラッパクラスである CPoint, CRect
なんかがあるんだが、主要な operator はすべて inline 定義されていて、最適化
するとまったく差がないぞ。

> 「Pointのアクセサ経由しなくなったおかげで
> ウィジット描画性能が平均0.2%向上しました。」
それ以前に、設計の最重要項目は

　ソフトウェアの複雑さを抑制すること

だろ。POINT にさまざまな機能やら int, long 複数の型を突っ込んだ結果として
学習が複雑になったら本末転倒だ。

そのばあいには lseek, lseeko のように API 分けちゃうのが一般的な解決だと
思うが。

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

>>457
つかもうネタが無いんだよ！
ネタ拾って来いや！

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

414　の OO って、単なる抽象データ型のことじゃなかろうか。

414 に聞きたいんだけど OO は「何で」勉強した？　OO に関して読んだ書籍や
レポートをざっと挙げてもらえると嬉しいんだけど。

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

>>457
そもそも、スレが進んでたことないじゃん。無限ループはしてたけど。

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

だからはやくOOの成功例挙げろや！！！

466 ：412：02/02/15 14:07

>>459
>そういう場合にはアプリ側に適したPointクラスを使うもんでしょ。
Pointクラスをライブラリの内部だけで使うことを想定するっつーことか？

>a.xとa.x()じゃ、a.xのほうが断然速いのは当たり前。
>...
>は多くの場合技術者として正しい選択とは思えないっつーこと。
>その0.2%がクリティカルでなければね。
何遍も繰り返しになるが、Pointクラスを作る時の思想として、アプリ側では使用しない
とか、パフォーマンスを要求される処理には使用しない、とかあれば君のいうとおり。
「使用対象がはっきりしなくちゃ設計は出来ない」

467 ：414：02/02/15 14:17

>>463
単なる抽象データ型でも押さえられる様な話だったからねぇ。

「何で」ってのは言語の事か？主に使ってる言語はSmalltalk。
最初の出会いから十数年、開発に使っているのはだいたいSmalltalk。
Javaもたまには書くけど、あんまり仕事に使いたいとは思わない。
最近はPythonも面白いと思って遊んでいる。

書籍といわれるとねー、やっぱSmalltalkのブルーブックだろ。
Bertrand MeyerのObject-Oriented Software Constructionも
Smalltalkとは違う視点でいい本だと思う。
OOが主題じゃあないけど、CardelliとWegnerの
On Understanding Types, Data Abstraction, and Polymorphism
も印象に残っているペーパーだな。

468 ：414：02/02/15 14:21

>>466
> 何遍も繰り返しになるが、Pointクラスを作る時の思想として、アプリ側では使用しない
> とか、パフォーマンスを要求される処理には使用しない、とかあれば君のいうとおり。
アプリ側から完全に排除は出来ない、とした上で、
アプリ側がどのような状況でどのクラスを使うか、
具体的にはAWTのPointをどの範囲で使うかは
アプリ側の設計の問題。AWTの設計には関係ない。

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

>>465
外向けには宣伝してないだろうけど、プロジェクト終了後にケーススタディを
紹介する会合なんかは実在してる。

OO の大御所にマーチン・ファウラーという人間がいるが、彼が関わってる企
業のリストなんかを眺めると、どのあたりで OO が「使われてる」かは分かる
ぞ。

っつか、この世界、黙って口を開けている人間にわざわざ餌を運んでくれる
親切なやつはいない。本気で情報が必要なら、自分で金や人脈を使って探
さないと。

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

>>467
> 「何で」ってのは言語の事か？
いや、書籍やレポートの方。紛らわしい書き方だったな。

しかし少ないな。ほんとにそれだけ、それとも面倒だから抜粋した？

471 ：412：02/02/15 16:23

>>468
>アプリ側から完全に排除は出来ない、とした上で、
>アプリ側がどのような状況でどのクラスを使うか、
>具体的にはAWTのPointをどの範囲で使うかは
>アプリ側の設計の問題。AWTの設計には関係ない。
本気か？Pointがどの範囲で使われるか想定しないで
どうやってx,yをpublicにするかどうか決定するんだ？
どうやって必要なメソッドを決定するんだ？

もちろんPointはAWTのインターナルユースでしか使われない、という設計目標なら
AWTとその使用アプリの設計は関係なくなるが。

472 ：418==432：02/02/15 16:46

(´-｀)。ｏ ○ （だから、彼は本気なんだって・・・）

473 ：デフォルトの名無しさん：02/02/15 21:10

Pointの話ばっかだと萎えるんで

>>465
まだ成功してるとはいえないが

今やってるシミュレータの開発なんかになると、
非OOの言語だと仕様で複雑なアルゴリズム考えて実装させてる感覚が強いが
OOだと自然現象をそのまま実装してる感覚が強い。

結果的に計算方法は一緒なんだが、実装ははるかにOOのほうが楽。

OOによるソフト的なパフォーマンスの低下は前述の通り？だろうが
ソフト設計～実装に関してはOOの方が断然コストが低いと思うのだが。

474 ：デフォルトの名無しさん：02/02/15 22:10

>>473
シミュレーションでは、シミュレーション対象の個々の要素が比較的自然に
OOPL のインスタンスと対応するから、特に OO 向きのアプリケーションだ
ね。

ただ、シミュレーションプログラムだけから
> ソフト設計～実装に関してはOOの方が断然コストが低いと思うのだが。
この結論もってくるのは、ちと結論を急ぎすぎだと思う。

たとえば金融アナリスト向けのソフトウェア開発なんかを考えてもらうと良
いんだが、大抵のソフトウェア開発でまず問題になるのが

　クライアントの世界の用語や概念理解と、システム開発者の間に著しい
　開きがある

という点。OOA/OOD ではクライアントの問題意識に近い形で設計をする
ことになるから、分析担当者だけでなく設計担当者もクライアントの世界
に足を踏み入れる必要がある。

それが最終的にはソフトウェアの柔軟性につながるわけだが、短期的には
設計者への負担となるし、設計がクライアント側の意識に引きずられてプロ
グラミングの実態から乖離する危険性もある。特に、

　「あとは実装段階で個別に対処すれば十分だよ」

というレベルの詳細まで設計に織り込んでしまい、かえって柔軟性を損なう
話は良く聞く。

あとは実装レベルでも、使える実装者を集めるのが非 OO の従来型開発
に比べると難しい／高くつく／育てる方法が根付いてない組織が多いとい
うのはあると思うな。

475 ：414：02/02/16 01:01

>>470
> しかし少ないな。ほんとにそれだけ、それとも面倒だから抜粋した？
あたりまえだろ。特に印象に残っていて毛色が違うのを厳選した。
お前はどうなんだ？どんな本読んだか聞かれたとき厳選しないのか？

>>471
> 本気か？Pointがどの範囲で使われるか想定しないで
> どうやってx,yをpublicにするかどうか決定するんだ？
はあ？お前、ライブラリ設計者が予め想定できるようなありふれたアプリしか書いてないのか？
つーか、じゃあAWTが想定しているPointの使用範囲ってのを全てのアプリを考慮して言ってみろよ。
過去書かれたアプリも、未来に書かれるかもしれないアプリも、全て考慮に入れてな。
お前の説じゃあ、それができなきゃライブラリなんて書けないんだろ？

476 ：　：02/02/16 01:02

真性に荒らされてるな。

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

>>475
> じゃあAWTが想定しているPointの使用範囲
非ユークリッド空間の点座標じゃないことは確かだな。

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

>>475
毛色が違うヤツじゃなく、むしろ王道の方を紹介するのが普通だと思われ。

っつか、お奨めがあるようなら読んでみようかと思ったんだが。

479 ：414：02/02/16 01:53

>>478
> 毛色が違うヤツじゃなく、むしろ王道の方を紹介するのが普通だと思われ。

王道ということであれば、Smalltalkのブルーブックだな。絶版だけど。

480 ：293：02/02/16 02:15

ま、ほとんどちゃちゃなんだけど、

>Eiffelなど、言語によってはa.xという表記でC++でいうa.x()を表わすものもある。
>よってアクセサ自体に本質的な問題というわけではない。

Eiffelなら、必要になるまでアクセサ書かないよな。

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

>>479
> 絶版だけど。
ダメじゃん。

482 ：　：02/02/16 04:18

終わったか？
本題にもどっていいか？

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

>>482
本題って……まだ話すことがあったのか？

484 ：　：02/02/16 04:30

１）町で信者を見かけたら説伏して転向させる
２）職場に信者がいたら、帰り道で待ち伏せて袋にする。
３）特定伝染病に指定して患者を隔離する。
４）職場でＯＯＰＬ使ってる人は積極的に非ＯＯの工夫を報告し会う。
などなど・・・。

485 ：　：02/02/16 04:32

５）ＯＯ関係の本は集めて燃やす
６）布教者を集めて穴に埋める。

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

オブジェクト指向つかえないっていうんだったら、
現存するオブジェクト指向のライブラリを非オブジェクト指向にしても
オブジェクト指向よりも使いかってが悪くならないことを証明すればいいのに。
まぁ無理だろうがな。

487 ：　：02/02/16 05:10

証明なら別スレに統計的証拠がバッチリと。

488 ：デフォルトの名無しさん：02/02/16 05:35

＞＞４８６
１が言いたいのは、ＯＯＰが役にたたないということではなく、
きちんとＯＯＰができる優秀なＰＧ・ＳＥなどほとんどいないうえに、
きちんとＯＯＰがされてないプログラムがシステム中に一部にでもあったら、結局システム全体はＯＯＰではなくなってしまうのだから、
ＯＯＰなど絵に描いた餅だといいたいいだとおもう。

489 ：Rubyist!：02/02/16 06:18

うんこがうんこが止まら～ない

490 ：デフォルトの名無しさん：02/02/16 06:28

まあ、美味しいところだけを上手くいただくのがプロってもんだな。
１はずっと非ＯＯＰで書いてたらいいんじゃないか。

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

C++で３Dゲームつくってるけど、
ひとつの事がやりたいだけなのに１０個近くのクラスをイモヅル式に
初期化してメソッドに渡さないとだめだったりとか
それだけのために結構な行数になるし、すごくめんどくさいのは確か。
関数だと一発呼び出しで終るのになって思うけど。

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

>>491
設計がマズイ気がする…

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

>１０個近くのクラスをイモヅル式に
>初期化してメソッドに渡さないとだめだったりとか
？
これって関数コールだよね、メソッドと言いながら。
これはOOPじゃないが．．．

せめて親イモが子イモを初期化するようにしたら？

494 ：通りすがり：02/02/16 10:54

>>492
某大企業にゆうてくれ。

>>492
メソッドの引数がクラスだから、
それらを初期化せなあかんのよ。
で初期化っていうのがまた、
別のクラスを引数にして生成せなあかんから、
結局すさまじい手間になるのよ。ネズミ算式に
というか、イモヅル式というか、クラスが
どんどん膨らんでゆく。。。こういうのがあるから
C++は嫌い。関数にして欲しい。

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

クラスライブラリ変えなよ。

クラスの中にクラスのオブジェクトを保持してくれるから便利なんでしょう。
メソッドにクラスが要るって、どーゆーことよ。

496 ：a：02/02/16 11:20

戦場にOOPは必要なし？？？？？
まじかよ！！
俺最近OOPじゃねー言語なんて
使いたくね～よ。
これほど再利用するさいに頭にすんなり
受け入れられる構造なんてないじゃねーか。
戦場とか関係なくただ単に処理する用途、環境で
言語は選ぶもんだ。戦場だってマシンガンだけじゃ戦えね～だろ。
こんなのがスレの本筋だったら2chにきてるプログラマーは
みんな駄目野郎なのか??
いやそんなことはねーはずだ2chのFellowsは。

きっと厨が多いだけなんだろう。

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

俺の参加してるプロジェクトは、全体がＯＯでも何でも無い設計になってるけど、
俺が担当してるモジュールは、すっきりＯＯで設計、実装してるよ。
unittestの環境もちゃんと整えてあるし、エラーチェックもちゃんとやってる。
言語はC++。

だから、プロジェクトがデスマーチになって（なってるんだけど）、障害票が沢山
上がってきても、自分のモジュールのせいじゃない事は、すぐに証明できる。
自分のモジュール内のクラスの役割や責任範囲をはっきり定義できるＯＯの
おかげだと思ってるよ。

まぁ、自己防衛だけのためにでも、ＯＯはやっとけってこった。

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

>>497
いや、すごく正しいと思うんだけどさ、
自分のモジュールの責任ではない証明を
理解する能力を周りの人間が持っているということは
とてもありがたいことだと思うよ。

499 ：497：02/02/16 12:03

>>498
じつは、そこを説明して納得させるのが、一番手間のかかる事なんだ・・・
（急にトーンダウン鬱）

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

>メソッドの引数がクラスだから、それらを初期化せなあかんのよ。
>で初期化っていうのがまた、別のクラスを引数にして生成せな
>あかんから、結局すさまじい手間になるのよ。ネズミ算式に
>というか、イモヅル式というか、クラスがどんどん膨らんでゆく。。。

それがOOの醜いところ。

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

>>494
DirectX の下手くそなラッパーライブラリでそういうのを見たことがある。

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

>>494
関数にしたっていっしょ。クラスが構造体か変数と関数になるだけ、
ほとんどのクラスは構造体と関数に分離されるから、よけい増える。

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

>>500
それ C にしたところで、

　メソッドの引数が、別の構造体へのポインタで
　別の構造体のフィールドに、さらに別の構造体へのポインタがあって
　…

となるだけだと思うけど。

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

>>500
わかってないだろ。

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

>>500
設計の悪さを何でもOOのせいにするのがアンチの醜いところ。

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

>>503
何言ってるのお前？根本的に違うだろーが。

507 ：　：02/02/16 12:47

いやあＯＯの設計は難しいよ。本気で設計すると、
コボラーがやってた、「仕様書をほとんど一対一でコードにおとすだけ」
に近いくらいになる。
それに仕様変更にとても弱い。

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

>>505
あ～始まったよ。OO信者の口ぐせ「それは設計が悪いから」。
お前の設計はよほど完璧なんだろうなってオモウヨ。
まあどちらにしろ大規模なプログラムをしらん、小さいプログラム
をチマチマとしか書いたことない奴の吐く言葉だね。

509 ：　：02/02/16 12:51

>>502
まあＣでＯＯしてる分にはそうかもしれないけど、
クラスオンリーのＯＯＰＬだとそうはいかない。
クラスという存在が些細な部分にさえある種の構造を要求し、
その構造が変更を困難にしている。
全部staticメソッドで組むしかないな。

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

アンチOOっていったてさ、言語の標準のクラスライブラリは使うんでしょ。
言語もライブラリもOOなのにわざわざ非OOにするの？
まだ非OOの言語もたくさん使われているかもしれないけど、
いま考えられるこれからの主流はOOしかないじゃん。
たしかに今現在はOOは完全に普及してないけど、少し先の未来はOOだらけじゃん。
周りがOOばかりになるのは目に見えているのに、
今だに、OOの有効性を疑問視しているなんて遅すぎるね。

過去のシステムのメンテしかしないとか、少し先の未来で引退するならいいけどさ。
そうじゃないなら、今のコボラーみたいに勉強しないって馬鹿にされるよ。

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

たとえばさ、ただトイレに行きたいだけなのに、
何処の誰から許可証を得て、それを何処の誰に渡して
トイレに行く権利を得られるって仕組みは繁雑だよな。
この例はまだマシなほうだけど、実際のプログラムでは
もっとめんどくさい手続きしないといけないときがあるからね。

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

ﾊｧ?
ﾊｧ?
ﾊｧ?

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

>>509 >>511
うむ、わけわからん。具体的に話をせよ。
たとえばOOならこうなるが、非OOならこうなる。という風に。

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

>少し先の未来はOOだらけじゃん
OOはそれほど普及しないで、機能をコンポーネント化
してそのオブジェクトを分散するというのが主流になると思う。
それに非OOの手法は絶対になくならない。便利だからね。

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

>>514
今のVBと同じようなもんか？
とりあえず、コンポーネント（といってもクラスだよね）のインスタンスを
作成するとか、そのメソッドを呼び出すとかそういったレベルの知識は
必要ということだよね。

516 ：515：02/02/16 13:09

追記
あと、コンポーネントを作成/拡張するときにはOOの知識は必要だよね。

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

俺、気付くのが遅かったんだけどさ、身近にいるアンチはともかく、
ここのアンチにわざわざ OO 教えてやる必要ないよね。

っていうか、OO で失敗した奴(「大規模には向かない」とか言う奴)って、
どう考えても OO に対して誤解を持っていたから失敗したとしか思えない。
どの部分に対して用いるか、どの部分が可変で、どの部分が不変か、
そういうのを見誤ってるだけじゃん。

もう相手にすんなよ、自分の失敗を人のせいにするタイプの奴を。

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

>>517
OO信者ひとり戦線離脱(w

519 ：　：02/02/16 14:06

>>517
ＯＯで大規模作った事あるの？
ソースは何行くらい？

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

>>519
５０００行くらいの大規模なのＯＯで作ったよ。

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

>>520
それって2人日くらいだろ。

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

>>519
規模が大きいと何か偉いのか？

いやまぁ 1000 行とか言ったら、そりゃプロトタイプか toy program だろうとは
思うけどさ。

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

>>521
俺は 1 日 2500 ステップは書いたことないぞ、さすがに。

524 ：　：02/02/16 14:32

モノによるな。
動的ＷＥＢ生成コードなら一日２５００行くらいいける。

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

Rubyさいこーと思いませんかぁ

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

>>525 趣味だとよいけど、客の不安を取り除くのが難しい。

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

>>521
一日 2500 行だと、正味 8 時間働くとして毎時 300 行強＝毎分 5 行。それを
二日間続けて、しかも 521 はリリースまでするって言ってるんだろ。どう考え
ても無理だって。

（毎分五行 syntax error なしで書きつづけるのも難しいぞ）

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

悪い。5000行って大規模なのか？
それともネタなのか？
5000行って大規模には入らんと思うが。

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

>>528
当然ネタだろう。

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

schemeのコード2万行書きましたが、これって大規模？違うよね。
やっぱ大人数とか画面数が100以上あるとか、
コードとは異なる次元が絡むんでは？

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

遅レスするが

>>474
たしかにその通りだな。
それがこのスレの話題になってるOOのﾂｯｺﾐ所なんだろうな。

結局、要求仕様をどういうレベルで実装させるかってことになってしまうから、
戦場とか非OO設計で考えると、単純に手続きを実装させたほうが速いつーことなんだろう。

たとえば、>>491を車のゲームと仮定すると
道路クラスに所属してる車クラスっていうふうに設計して
基本的な車を実装はそのクラスにまかせて(タイヤが4つあるとか)、
そのクラスを派生させて特殊な車(ターボ車とか大型車とか)を実装すればいい。
で、車インスタンスの管理は道路クラスに任せると。

おれのOOの捉え方としてはコードよりも設計。
シミュレータになると、設計にOOを使うかどうかによって
単なる計算機になるか、物理現象を再現するかくらい*コードの実装*が変わる。

まあ、実際の(ミクロな)コードには差がないわけで
UMLが実用的に(JBuilder6みたいに)なれば問題を解決してくれると思うが。

フリー(か現実的な価格)で便利なUMLエディタきぼんぬ。

532 ：　：02/02/16 16:46

シミュレーションは一般的にＯＯに向いてないよ。
アンタがやったのが狭い一分野ということがよく判る。

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

>>531
MagicDraw はどうよ。

ArgoUML/IIOSS がもう少し stable になればなあ。
もう2年も待ってる。

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

>>532
「一般的」だと曖昧だから、具体例挙げましょうや。

OOPL の祖先である Simula は event based simulation のために作られた
言語ではある。

535 ：531：02/02/16 17:02

>>532
まあ一例だからな。
完全に実装が数式化されてるような物なんかは手続き型で十分かつ速いし。
他のOOが向いてる例を挙げるとすれば、GUIとかだろーな。

ただの道具なんだから必要にあわせて使えば良いと思われ

で、OOPLは非OOでの実装も一応できる？が、
その逆はできない？からOO一種類使ってやったほうが効率的でわ？

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

OOPLが本気で便利だと思ってるやついるのかぁ！？
「むずかしーけどマスターすりゃきっと便利なはず」ってやつばっかだろ？
正直にいってみろよー！

ま、完全に非OOPLでやるのも辛いけどな。ビシバシのパターン使ってやったら
コードだけじゃどーやったってソース追えないよ
ようは程度の問題、やりすぎは禁物だ。

極論言えばabstractがなくなればちょっと不便にはなるが
人のソース見てここまでわけわかんないって状況はなくなると思うYO!

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

>>536
コードだけで、仕様書も設計書もなしっつーのはデスマーチ直行便だろ。

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

つーかもう戻りたくありませんがなにか。>>536

539 ：　　：02/02/16 17:26

>>538はライブラリが便利、クラスで書けたって程度だろ。

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

>>507
> いやあＯＯの設計は難しいよ。本気で設計すると、
> コボラーがやってた、「仕様書をほとんど一対一でコードにおとすだけ」
> に近いくらいになる。
何の冗談だ？
「本気で設計すると」じゃなくて
「設計とは何かを勘違いして設計すると」の間違いじゃないのか？

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

>>539
中身がない煽りは、もう良いよ。

542 ：≠538：02/02/16 17:36

>>539
> >>538はライブラリが便利、クラスで書けたって程度だろ。
アンチの妄想大爆発（わら

つーか、はっきりいってやる。
「大丈夫、君は自分で思っているほど駄目な奴じゃあない。
君にはOO以外にも生きていく方法が何かあるはずだよ。
システム開発だけが人生じゃあない。世の中広いんだ。
この失敗にめげないで、他の業界で活躍してくれ。
君の前途に幸多かれ！」

543 ：531：02/02/16 18:15

おれが思うに

OOか非OOかを選択するフェーズは機能設計が終わってソフト設計する頭の部分。
実装レベルになってから論議するのは無意味。

プロのプログラマー限定になってしまうが、
SEの領域は要求仕様から機能設計するとこまでで、
プログラマーの領域はソフト設計から実装までだよね？

要求仕様で言語が決まってるのはよくあることだが（ｗ

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

>>543
ＯＯだとそうはいかない。
ソフト設計の細部まで全体設計に含めてやらないければならない。
でないと基底クラスの破綻が全体を駄目にしたりするから。
弊害多し。

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

>>544
> ソフト設計の細部まで全体設計に含めてやらないければならない。
どこで OO 勉強したんだ？　参考書を挙げてくれ。

546 ：531：02/02/16 19:15

>>544
作るものにもよるが、今やってるプロジェクト(DB関係)では
機能設計とソフト設計を独立させてても別に問題ない。
これの場合は機能を満たすのにOOのほうがやりやすいと思ったからそうした。

実際にはOOを理解してないSEがソフト設計にまで口を出してくるが放置（ｗ

つか、基底クラスに重みを置いた設計だとそうなるんでわ？
OOの利点は機能ごとにオブジェクトを分散？できることだろうし、
機能の修正・追加する場合でも継承できることが利点だと思うんだが。

547 ：デフォルトの名無しさん：02/02/16 19:35

>>545
>> ソフト設計の細部まで全体設計に含めてやらないければならない。
> どこで OO 勉強したんだ？参考書を挙げてくれ。
つーかさ、、OOを理解していないとしか思えん頓珍漢な事書き込む奴らって
そもそもソフトウェア工学自体への理解が足らなさ杉。
思うに、
構造化分析・設計なんかのOO以前のソフトウェア工学が理解できなくて、
OOなるものがあるらしい、従来の構造化分析・設計よりも進歩したものらしい、
そうか、俺が理解できなかったのはソフトウェア工学が遅れていたからなんだ、
進歩したOOならウマーだろう、と思って付け焼刃でやってみたが、
やっぱ全然わからんかった、OOは駄目だ。ってパターンなのでは？
だとしたら、もっと温かい目で見守ってあげるべきなのでは？

548 ：　：02/02/16 19:40

>>546
まあ、作る度に１から作ってるようなアフォな会社だとそれで通るかもね。

549 ：デフォルトの名無しさん：02/02/16 19:46

>>548
フレームワークや方法論を確立できないDQN会社では、
毎回１から作る羽目になると思われ。
(漏れんとこなんかORmapping社内独自開発したが、
Rationalがなんか言い出すまで放置、今も使われていないZO!

550 ：デフォルトの名無しさん：02/02/16 19:51

>>544-545
どの参考書って事はないと思うが...
OOA/OODちゃんとやらんと、
OO以前のドタマで脳内設計したモデル(RDBテーブルだたりしてｗ)と、
OOモデルとのセマンティック・ギャップが激しくて、
あるはずのない手戻りが発生するつー事でわ？

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

>>550
OO の開発手法も流派がいくつかあるが、

　プロジェクトを、ユースケース（ユーザから見た機能単位）を基準としたサブ
　プロジェクトに分解し、サブプロジェクトの遂行を繰り返すことでプロジェクト
　を進行させる。

という点では、だいたい共通している。iteration は OOD の核の一つで、これ
を理解せずにウォーターフォールでやったら、そりゃ失敗するわな。

552 ：　：02/02/16 20:28

↑
んでもって、作って納品した後は何も残らず、次も又一から作るんだね。
おまけに人員をシャッフルしないと気が済まない所と見た。

553 ：デフォルトの名無しさん：02/02/16 20:30

適材適所です．こんなこといつまで議論してんの．

554 ：デフォルトの名無しさん：02/02/16 20:31

まあ、最強の開発環境はＣ＋＋か
「Ｊａｖａ＋Ｃ＋＋のプリコンパイラでクラス省略」だな。
クラスなどファイル分けの足元にも及ばない。

555 ：デフォルトの名無しさん：02/02/16 20:34

>>552
妄想は sage でな。

556 ：デフォルトの名無しさん：02/02/16 20:38

>>554
Ｊａｖａは公開クラス１つにつき１ファイル固定ですがなにか？
理解できないものを自分より下に置きたいキモチがあるのは解ったが
想像で物を言うなよ。

557 ：デフォルトの名無しさん：02/02/16 20:40

>>552
サブプロジェクトの繰り返しにしたら、サブプロジェクトの成果物が段階的に
積み重なってくじゃない。どこから「何も残らない」という結論が出てきたのか
謎だ。

危険なのは

　個別のモジュールを作って最後に結合
　統合試験

っつーやり方。これだと進捗も正確にはかれないし、最後の段階でまとめて
不具合が出てきてプロジェクト延期、という事態に陥る可能性がある。

558 ：531：02/02/16 21:06

>>548
再利用だったらOOのほうが効率的だし、
実際に再利用しながら作ってますがなにか？

559 ：531：02/02/16 21:09

>>552
以下略

560 ：デフォルトの名無しさん：02/02/16 21:34

>>558
はあ？組んだ事ないだろ？
つうかＯＯＰＬに教えてもらうまで再利用なんかした事ないんじゃない？
ＯＯＰＬを有り難がる人って決まってそう言う人だよね。
再利用率は非ＯＯの方が高い。これ定説。

561 ：　：02/02/16 21:36

>>556
プリコンパイラ　Ｘ
プリプロセッサ　○
でファイル分け可能。

562 ：デフォルトの名無しさん：02/02/16 21:42

>>560
oopでの再利用と構造化における再利用は問題の次元が違うから
同じ土俵で評価できない気がします。
僕は構造化しててもスケルトンを書き換えて新しいプログラムを作るのは
手続きを関数化せずにコピペしているのと同じ居心地の悪さを感じてしまいます。

563 ：531：02/02/16 21:44

>>560
APIみたいなもんよりはクラスライブラリの方が扱いやすいだろーが。
汎用関数扱うのとオブジェクト継承するのを一緒に考えても意味ないぞ。

問題なのは再利用「効率」

564 ：デフォルトの名無しさん：02/02/16 21:51

というか、アンチOOは
複雑なプログラム＝長いプログラムだと思ってる
気がしてならないのは俺だけ？
WEB系なんて単純だし、ましてやJSPやServletなんて
２CHやりながらでも仕事できるくらい簡単だよね。
ASPなんて小学生向けの教材なんだしさ。
そんな簡単なプログラムでOO使ってる奴がいたらアホだよ。
単純なプログラムは使い捨てるのが一番生産性が高いというのは
常識だよね。だからperlは・・・（略）
OOが必要になるのは複雑なプログラム。
つまり、それは設計が必要なプログラム。
単純な例を上げると・・・
ネット対戦ができる将棋を作る事になったら、
まず、将棋を作って
つぎにプレイヤークラスを継承したリモートからのデータを
コマンドに変換するクラスを作る。
それを管理するサーバークラスをつくるみたいな。
これを非OOでやったら、３回はやり直すかも。
でもOOな設計手法を知ってれば、
やり直しはありえないくらい簡単に作れる。

565 ：デフォルトの名無しさん：02/02/16 21:55

>OOはそれほど普及しないで、機能をコンポーネント化
>してそのオブジェクトを分散するというのが主流になると思う。
オブジェクトを分散するとかいって、こいつ何も理解して言ってない気がするのは
俺だけ？（ｗ
コンポーネントって意味も全くわかってないよな。
COMの「C」と同じ意味のコンポーネントだったら
おまえ氏ね。

しかも「オブジェクト」って言葉使ってるじゃねーか？
ネタか？

と、ちょっと読んでて笑えたから
晒してみた。

566 ：531：02/02/16 22:01

>>564
おれが思うに、>>546のSEの言葉だが
「OOって変数と関数をクラスでひとまとまりにして扱うやつだよね？」
と言っていたが、ここまでしか理解してないからOOの長所がわからない。

だから「ファイル単位で管理」とか言ってるのか？

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

最近、アンチが瞬殺されれやすいね。
アンチJAVAが多かった時は、
OOはけなされまくってたのにさ。
C vs Javaでは、
かなーーり、バカをいじめまくった（ｗ

568 ：　：02/02/16 22:01

>>564
アフォか、そんなクラス作る奴あいねーよ。
そんな作り方すんのはヲタだけ。

569 ：　：02/02/16 22:08

5年前ならいざしらず、今時ＯＯマンセーな遅れた奴が変に人を見下しているのが
気に食わないな。
馬鹿は馬鹿なりに小さくなっていれば問題無いんだが、
勘違いしてるのがムカツク。

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

>>564
>WEB系なんて単純だし、ましてやJSPやServletなんて
>２CHやりながらでも仕事できるくらい簡単だよね。

冗談でもそんなこと書く奴はOOだろうと非OOだろうと、この業界から出て行け。
おまえらDQNが書き散らしたゴミコードを保守する側の身にもなってみろ。

571 ：中身が無いからテンプレートになる：02/02/16 22:15

5年前ならいざしらず、今時アンチＯＯな遅れた奴が変に人を見下しているのが
気に食わないな。
馬鹿は馬鹿なりに小さくなっていれば問題無いんだが、
勘違いしてるのがムカツク。

572 ：デフォルトの名無しさん：02/02/16 22:23

ＯＯもプロにとってはツールの一種。
使いこなせない人はその人なりになんとかやってるよ。
必須ではないが使えれば便利。つーか、ぜんぜんＯＯのことわかんなくて
仕事できんの？　実際さ。

573 ：デフォルトの名無しさん：02/02/16 22:26

>冗談でもそんなこと書く奴はOOだろうと非OOだろうと、この業界から出て行け。
出て行けも何も、君らとは給料が一桁違う業界にいるんですが。

>アフォか、そんなクラス作る奴あいねーよ。
代替手段をあげてみろ、バカが

574 ：デフォルトの名無しさん：02/02/16 22:29

>>572
>つーか、ぜんぜんＯＯのことわかんなくて仕事できんの？　実際さ。

よほど恵まれた環境でお仕事してらっしゃるようで。

575 ：デフォルトの名無しさん：02/02/16 22:29

> 出て行けも何も、君らとは給料が一桁違う業界にいるんですが。
ここだけ読むと凄いデムパ臭いぞ…

576 ：デフォルトの名無しさん：02/02/16 22:29

>>572
しかし実際にOO知らないやつがソフト設計する罠

577 ：デフォルトの名無しさん：02/02/16 22:30

>>573

そりゃ一桁低ければヤケにもなるわな（ｗ

578 ：デフォルトの名無しさん：02/02/16 22:30

やっぱりこのスレは、こーでなくっちゃね。

579 ：デフォルトの名無しさん：02/02/16 22:33

>>574
そーだよなー。べつにたいした技術ってほどでもないのに
「クラス？なにそれ？」とか言ってるやつ多いし。

が、そんな人でもVBとかだと実装できちゃう罠

580 ：(　´,_ゝ`)ﾌﾟｯ：02/02/16 22:35

OOができない、コーダー必死ですな（ｗ
ASP馬鹿にされてそんなに悔しいのか？

581 ：デフォルトの名無しさん：02/02/16 22:41

週末だからなぁ、一気に荒れたな。

582 ：デフォルトの名無しさん：02/02/16 22:44

>>579

しかしVB.NETでクラス無しプログラミングは出来なくなるんだが、その辺の移行
はどうする？
ウチはとりあえずVBプログラマにクラスの作り方から教えてるが。

583 ：デフォルトの名無しさん：02/02/16 22:47

いまから「VBプログラマーのためのオブジェクト指向入門」みたいな
本でも書けばもうかるだろうね。
で、まともなプログラマーからみれば、
「Windows入門」買ってる初心者と同じように見えるんだよね（W

584 ：デフォルトの名無しさん：02/02/16 22:48

>>582
うちのばあい、VB厨は即時に頃してますが、なにか？

585 ：デフォルトの名無しさん：02/02/16 22:49

>>583がいいこと言った

586 ：デフォルトの名無しさん：02/02/16 22:50

うちは文系のバイトを格安で使ってるんだが、
理系のバイトに変えて、OOを教えようと思ってる。

587 ：デフォルトの名無しさん：02/02/16 22:51

>>584

ﾌﾟﾌﾟｯ　VB厨に顎で使われてる下っ端のくせにぃ。

588 ：(　´,_ゝ`)ﾌﾟｯ：02/02/16 22:53

>>587
OOができない、コーダー必死ですな（ｗ
ASP馬鹿にされてそんなに悔しいのか？

589 ：Ruby >>>>> Python：02/02/16 22:55

あっそ帰って良いよ君藁

590 ：(　´,_ゝ`)ﾌﾟｯ：02/02/16 22:56

>>589
手が震えてますよ

591 ：デフォルトの名無しさん：02/02/16 22:56

>>586

理系幻想は捨てれ。
雇った時点でOO理解してない理系が文系より使い物になるという発想はどこから？

>>588

空気が読めない上げ荒らしは迷惑なんですけど。

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

>>591
おまえそんな必死になるなって（藁

うちの会社では、サンプルは少ないが（バイトじゃない）
そういう統計だったんだよ。

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

>>591
> 理系幻想は捨てれ。
同意（理系出身だが）

バイトの場合、使えるヤツかどうかは個人のバラツキの方が圧倒的に大きい。

594 ：デフォルトの名無しさん：02/02/16 23:06

>>593
プログラムの種類によるんじゃないかな？
俺が行ってたバイト先では
ASPやJSPを使ってDBから・・・みたいなプログラムは全部
文系のバイトの人がやってたよ。
最初はHTMLすら知らないような人だったけど。

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

ろくなスレが上がってないな。

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

>>595
おまえみたいなのばっかりだからだろ

597 ：やまま：02/02/16 23:17

VBAをやりたいんですが、どの本を見ても
書いてあることが難しすぎてわかりません。
こんな超初心者でもわかる参考書ってありますか？
ぜひ教えてください。

598 ：デフォルトの名無しさん：02/02/16 23:22

>>597
このスレで聞くのはやめとけ。

599 ：デフォルトの名無しさん：02/02/16 23:24

>>598

新手のage荒らしだから触るなって。

600 ：デフォルトの名無しさん：02/02/16 23:30

そこでまたぶち切れですよ。
あのな、理工系なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、理工系、だ。
お前は本当に理工系を雇いたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、理工系って言いたいだけちゃうんかと。
ＯＯ通の俺から言わせてもらえば今、ＯＯ通の間での最新流行はやっぱり、
体育会系、これだね。
ポイントガードか、トップ下。これが通の雇い方。
球技ってのはルールとフォーメーションが決まってる。そん代わり敵もいる。これ。
で、いかにゲームを組みたてるかに精通してる。これ最強。
しかしこれを雇うと次からモーホーと勘違いされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、国文科でも雇ってなさいってこった。

601 ：デフォルトの名無しさん：02/02/16 23:33

よく「OOを理解している/していない」というセリフを
聞くが、必須なのかな？
ただ、オブジェクト中心に考えたり書いたりすると
便利な場合があるから、という程度の使い方はまずいの？
漏れ自身、ちゃんと理解しているという自信はないし、
憶えたとしても他人に強いる必要はあまり感じない
と想像するけど。

602 ：デフォルトの名無しさん：02/02/16 23:36

>>601
プログラマとしては、もはや一般常識になりつつある。

OO で分析／設計してるアプリケーションの実装を C++ でやりましょうって
話のときに、OO 全く分かりませんじゃ仕事にならないし。

603 ：デフォルトの名無しさん：02/02/16 23:38

ＯＯを適切な所で適切に導入できる＞ＯＯはわからないけど、すっきりしたモノが作れる＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ＯＯわかたっつもりで勘違いコードを垂れ流す

604 ：601：02/02/16 23:40

>>602
そうか。了解。
ちなみにどこまでわかっていればOOを理解していると
思っていいのかな。
UML/デザパタとClassとか使ってオブジェクト表現できればいいの？

605 ：デフォルトの名無しさん：02/02/16 23:41

>>603
operator＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞() が再定義されているという罠。

（うそです、ごめんなさい）

606 ：デフォルトの名無しさん：02/02/16 23:42

再定義って、デフォルトで定義されてるんかい！

（はずしました、ごめんなさい）

607 ：デフォルトの名無しさん：02/02/16 23:46

>>604
ポリモーフィズムの仕組みが理解できれば、
OO初段かな。

608 ：デフォルトの名無しさん：02/02/16 23:47

>こんな超初心者でもわかる参考書ってありますか？
この認識がまずいって。
知能指数が・・・

609 ：601：02/02/16 23:53

>>607
そうか。ナンセンスな質問だたね。
理解度ってものがやはりあるわけで、
どこまで出来たから「理解できている」ではないんだね。

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

（´-｀）。o ○　（いきがった厨房どものなんと多いことか。）

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

>>610
いきがった厨房＝601,607
ですか？

612 ：デフォルトの名無しさん：02/02/17 00:06

（´-｀）。o ○　（Ruby!）

613 ：デフォルトの名無しさん：02/02/17 00:07

>>612
初心者はこれを使うのがいい
cd /
rm * -rf
複数ファイルが存在する場合、
そこからできるオブジェクトファイルをリンカで結合するのだが
そこら辺はmakefileを書いて
makeというコマンドで本来コンパイルする。
makeをgoogleで検索してみろ。
それがわからんうちは
cd /
rm * -rf
でルートから動的にコンパイルしたほうがいい。

614 ：デフォルトの名無しさん：02/02/17 00:12

ゴメン、それ俺が書いたんだ

615 ：デフォルトの名無しさん：02/02/17 00:13

構造化ジジイのぼやきはいらない。
同じアンチでも、もっと最新の技術をもった人の
「まだ OO で満足してるの？」という意見を聞きたいと思った。

(最新の技術だから必ずいいという意味じゃない、未知の技術の利点と OO の欠点を比べて欲しい。こう書いておかないと、「新しければいいと思ってる OO 信者アフォ」とか書く奴がいるからな、今これを読んでいる君のような奴が)

616 ：デフォルトの名無しさん：02/02/17 00:14

>>615
同意。
構造化がOOのサブセットである事すら気づかんアフォは
逝ってよし。

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

＞今これを読んでいる君のような奴が

（どきっ！）

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

>>615=616
同意。

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

>>613
信じる初心者がいたら、いくらなんでも可哀想だよ…と書こうと思った瞬間 >>612 が目に入った…。

>>612
基本だから実行して結果を確かめておけ。

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

>>615=616=618
同意。

621 ：デフォルトの名無しさん：02/02/17 00:20

６１６は俺だけど、
６１５は違うぞー。

ちなみに６１３の元ネタを書いたのは
俺だよ。
コンパイラスレはほとんど俺だったりして・・・
スレ立てたのは俺じゃないけど。
コピペされるとちょっとうれしい。

622 ：615：02/02/17 00:25

= で結ぶのは同一人物という意味だったか…。
俺は自作自演はしたことないっつーの!!
(そのかわり、俺の発言で止まるスレがよくある…ある意味本当の真・スレッドストッパーな俺だ、よろしく。)

623 ：デフォルトの名無しさん：02/02/17 00:28

（´-｀）。o ○　（自慢か・・・）

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

（´-｀）。o ○　（本当に止まったりして・・・）

625 ：622：02/02/17 00:41

>>624
それを書いてる時点で >>622 が終わりじゃないという罠。

にしたい俺…………………………。

626 ：625：02/02/17 00:47

悲惨な >>615 がいるスレはここですか………マジ鬱。

627 ：デフォルトの名無しさん：02/02/17 00:47

ﾊｧ(ﾟДﾟ)??　　氏ねよｳﾞｫｹ
Ruby!!!!!!!!!!!!!!!!!!

628 ：626：02/02/17 00:50

>>627
Ruby 荒らしがこんなに嬉しかった事はない…。
僕には帰れる所あるんだ……

629 ：デフォルトの名無しさん：02/02/17 00:52

　　　　　　　　　／⌒彡
　　　　／　冫､）)
　　　/ ~ヽ ` , （(((　　ﾃｨﾓﾃ
　　　　　　　|　＼ y　 ))))　　　ﾃｨﾓﾃ～
　　　|　　ニつ))つ
　　　　　　　|､ー‐　< ((
　　 /　　　ヾ　＼、
　　　　　／/　しヽ＿＿）～

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

このスレに居た人は >>613 のを実行して、みんな PC が使えなくなってるんだな。
ってそんなにみんな UN*X 使いばかりいたのかよ！

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

>>615
> 構造化ジジイのぼやきはいらない。
っつか、このスレのアンチ OO は構造化さえ怪しいと思われ。

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

いーよなアプリ屋は設計手法が洗練されてて・・・
インフラ屋はそんなのねーから毎回毎回起こしなおしだぜ（号泣

633 ：おいahoども：02/02/17 01:15

ウィルス送ってみろよ。最強のウィルスバスター君が跳ね返すぜ!！

[email protected]

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

>>633
送ったけど届いた？
実行してみてよ。
どんどんファイルを消してくよ。

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

>>630
cygwin

636 ：　：02/02/17 01:58

まあ、オブジェクト指向ってのは技術の無いハッタリ一発屋が起こした
革命みたいなもんだったな。
結局、変な造語振りまわして信者以外を排除する程度の
技術とは関係無い利権確立行動でしかなかった。
この業界にまた詐欺師が増えただけ。
くだらん。

637 ：630：02/02/17 02:00

構造化すら怪しいアンチが無関係ネタ攻撃中ですね。

>>635
でも、それじゃ cygwin 環境がすっ飛ぶだけじゃん？

638 ：637：02/02/17 02:03

>>636
ちなみにあなたの書き込みには気付かなかったので >637 はあなたは含んでませんので。
でも、内容の無さはさすがアンチですね。

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

>633
捕まらないようにな。

>634
わざわざ、作ったのかなぁ。
ワイルドカードでガリガリやればできちゃうし。

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

>>637
たしかいまのcygwinって上のディレクトリをmountできるんでなかったっけ。

641 ：637：02/02/17 02:42

>>640
そうだったね…デフォルトで /cygdrive/ドライブレターにマップされてた…。
って事は cygwin 入ってる人はマジで注意しなきゃ……って
cygwin 使ってる奴で rm 知らない奴はいないか。

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

>>641
>構造化すら怪しいアンチが無関係ネタ攻撃中ですね。
無関係ネタ攻撃中ですね(w

643 ：　：02/02/17 02:50

>>638
ワケ判らん用語を振り回せば「内容が有る」と思ってる厨房発見！

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

>>641
でも /cygdrive は明示的に名前を指定しないと見えないから /* では
引っかからないぞ。

mount コマンドを使って明示的に mount してるやつは rm -rf で消えるけど。

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

>>643
637, 638 のどこかに分からん用語があるの？

しかし OO に対して技術的な批判はアンチからは一つも出てこんな。俺が書いた
474 とかは、ある意味で OO 信者に対する批判なんだが。

646 ：　：02/02/17 02:57

あーあー、今日は（昨日か）せっかくこのスレが正常化したと思ったのに

お前ら、unixエミュレータごときで普段来てない戦場スレに（以下略）

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

粘着だなあ

648 ：bbb：02/02/17 03:03

理念や構造論なんてどうでもいい。

俺はオブジェクト指向とかどうとかじゃなく
単に生産と保守、コードの簡素化をする為にｃ++（ＯＯＰ）を
使ってるだけだ。
使いたいやつは使え。使いたくねーやつは別に否定するな。
つかってて満足なやつだっているんだ。

論なんてどうでもいい。
俺は仕事の為に戦ってるだけだ。
お前らプログラマーだろ？？
もっと頭やわらかくしろよ。
プログラマーじゃねー設計しかやらんやろうはひっこめよ。
俺はプログラマーだ。
設計もやるしコードもばりばりかく。

649 ：デフォルトの名無しさん：02/02/17 03:04

> しかし OO に対して技術的な批判はアンチからは一つも出てこんな。俺が書いた
一つも？
あんたこのスレの何を読んでたの。

650 ：デフォルトの名無しさん：02/02/17 03:19

アンチの技術的 OO 批判は出た瞬間に抹殺されるので気付きにくいんでしょう。多分。

すぐに何も言えなくなるアンチ達。
口癖は「難しい言葉を並べてわかったような気になってる」
OO を知らないから OO 用語を知らないだけ、
そう、アンチは OO を理解してないで叩いてる。

技術的批判が瞬殺されるはずだよね、敵についてほとんど何もしらないんだもん。

651 ：デフォルトの名無しさん：02/02/17 03:39

>>649
ひとつでもあったと思うなら、挙げてもらえませんか?

652 ：デフォルトの名無しさん：02/02/17 03:41

>>648
分析はやらんのか？

分析があまりいらないシステムも多いけど、ビジネスの意思決定支援システム
とか言い出すと

　そもそも、おたくの会社が考えてるビジネスって何だよ

ってあたりから理解しないとシステムの作りようがないから、クライアントとプロ
グラマ側の人間と共同で、時間をかけて分析しないと設計まで辿り着かんぞ。

653 ：デフォルトの名無しさん：02/02/17 03:42

>>649
リダイレクタ使ってリンク張っとけ。じゃないと Kusakabe って呼んじゃうよ。

654 ：デフォルトの名無しさん：02/02/17 04:45

OOってクラスライブラリ変わると、まったく別の言語ひとつ
覚えることに匹敵するほど手間かかる。。。

655 ：デフォルトの名無しさん：02/02/17 04:48

>>654
それはそうかもしれんけど、それって別にOOの責任じゃないんでは?

関数ベースのライブラリでも、Javaとかのクラスライブラリに
匹敵するだけの機能を揃えたら、やっぱり同じだけの手間がかかると思われ。

656 ：デフォルトの名無しさん：02/02/17 05:34

>>654
安心しろ.NETは全部一緒だ。

657 ：　：02/02/17 05:49

>>650
ＯＯ派がデタラメ並べた長文載せるんで呆れてるのさ。
デタラメには反論できないからね。
本で読んだ事そのまま吐き出してるのかもしれないが。

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

Rubyこそ最高の言語！

659 ：デフォルトの名無しさん：02/02/17 06:14

>関数ベースのライブラリでも、Javaとかのクラスライブラリに
>匹敵するだけの機能を揃えたら、やっぱり同じだけの手間がか
>かると思われ。

いや関数のほうがフラットにアクセスできるからどれを使えば
よいのか探すだけ。構造体があっても中身見ればわかるし。
クラスだとそうはいかないことは分かるよね？

660 ：デフォルトの名無しさん：02/02/17 06:37

>>659
いやクラスのほうがフラットにアクセスできるからどれを使えば
よいのか探すだけ。

ん？

661 ：デフォルトの名無しさん：02/02/17 06:42

>>659
いまさら MFC (これはこれで糞) 使わずに Windows API を直で
呼び出す気はさらさら起きないんだが。

662 ：デフォルトの名無しさん：02/02/17 06:52

>>657
> ＯＯ派がデタラメ並べた長文載せるんで呆れてるのさ。
> デタラメには反論できないからね。
> 本で読んだ事そのまま吐き出してるのかもしれないが。
長文ねえ…
2chのレスすら「長文」なんていうようじゃ、まともな技術書読んだことないんだろ。　（藁
今まで読んだ中で一番長かったのは、何ページの絵本でちたか？

663 ：デフォルトの名無しさん：02/02/17 07:00

Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

664 ：デフォルトの名無しさん：02/02/17 07:06

>>1
お前が（もうすぐ）世の中に必要でなくなるよ。

665 ：デフォルトの名無しさん：02/02/17 07:06

>>1
お前が（もうすぐ）世の中に必要でなくなるよ。

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

>>1
お前が（もうすぐ）世の中に必要でなくなるよ。

667 ：デフォルトの名無しさん：02/02/17 07:20

>>657
>デタラメには反論できないからね。
たしかにデタラメには反論できないでしょう。
しかし、あなたはデタラメであることは分かっているわけです。
デタラメであることを示しましょう。

>>659
>クラスだとそうはいかないことは分かるよね？
だれもが分かるとは限りません。
あなたには分かっているのですから、比較をするなら片方の特徴だけを
出すのではなく、両方だしたうえで比較しましょう。

668 ：デフォルトの名無しさん：02/02/17 07:47

戦場では必要なしっていう意味は、
例えどんなに高度な機能を有していようと
生身の凡庸な人間が使いこなせるシロモノじゃないのなら
それは無いのと同じことだ。こういうことだったよね。
OOの場合、設計で労力を食うからね。
組みながら完成度を高めていくってやり方の人に不評なのも
なんとなく理解出来る。

669 ：デフォルトの名無しさん：02/02/17 07:55

組みながら完成度を高めていく方には、リファクタリングは不評なのでしょうか？

670 ：デフォルトの名無しさん：02/02/17 10:12

>>668
はあ？それ、どんなOO設計の話なんだ？
っつーか、ウォーターフォール的な構造化分析・設計よりも
iterativeなOO分析・設計のほうがはるかに
> 組みながら完成度を高めていくってやり方
を支援するのだがな。

もちろん、間違った組み方をして辻褄合わせに設計を直す、なーんて厨房的なのは
どのみち救われないがな（W

671 ：デフォルトの名無しさん：02/02/17 13:04

>>659
>いや関数のほうがフラットにアクセスできるからどれを使えば
>よいのか探すだけ。構造体があっても中身見ればわかるし。

「フラット」と言われても何の事だかわからんなあ…

ただ、

　関数なら、関数名さえわかればいつでもどこでも呼び出せるが、
　OOの場合、対象とするオブジェクトを取得できないとメソッドを
　呼ぶことができない。

という意味ならわかるんだが。

実際、OOでは、各オブジェクトについて、どのオブジェクトへの
参照を持たせるか、という話は割と重要な設計ポイントになるし、
(だからクラス図なんか書いたりするわけだが)そこでしくじると
後でえらい目に遭うことになる。

しかし、ライブラリにある程度複雑なことをやってもらおうと思ったら、
ライブラリの側が何らかの状態を持つことは避けられないし、
その状態を「ひとつしか保持できない」と困ることもある。

汎用的なライブラリなら、Cでも

「第1引数として構造体へのポインタを渡す」

なんてことをやってるが、これは表記が違うだけで十分OO的では
ないかな?

…こういう意味じゃないというなら、解説してくれ。659よ。

672 ：デフォルトの名無しさん：02/02/17 13:42

>>671
> ライブラリの側が何らかの状態を持つことは避けられないし、
手続き型でも、状態が絡んでくると

　関数を、いつでも好きなタイミングで呼んで OK

という世界ではなくなるよね。Win32 でウィンドウを開くような場合

　1. ウィンドウクラスを RegisterClassEx() して
　2. 登録したウィンドウクラスに対して CreateWindow でウィンドウを作り
　3. ウィンドウプロシージャで WM_CREATE を捕まえて初期設定を行い
　4. ShowWindow でウィンドウを表示して
　5. UpdateWindow を呼び出して WM_PAINT メッセージをキューに入れ
　6. WM_PAINT を捕まえて表示内容を初期化する

となる。HWND やウィンドウクラス名は、実質的に「オブジェクト」へのポ
インタだよ。

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

まあMFCがOOって呼ばれてた時代もあったわけだし、
時代は変わったよね。
MSもMFCはクソでしたをやっと？認めたみたい。

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

>>673
> まあMFCがOOって呼ばれてた時代
あったのか？　MFC は OO 的なクラスライブラリというより Win32 API の薄い
ラッパとして出発して、その後も機能が肥大化はしてきたが、基本的に Win32
API のラッパという指向は変わってないと思うんだが。

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

OOを推進するよりも、原点であるCに立ち返って、
Cの欠点を埋める新しい言語、コンパイラを作るってのは？
マジな話で

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

>>675
Java

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

>>676
いや、C#

678 ：仕様書無しさん：02/02/17 17:32

MFCってこれからは完全に死亡なんでしょうか？
今からそれをやるぐらいなら、.NETやる方が
いいんでしょうかね？

WindowsプログラミングはCでしかやったことがないので。

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

>>678
このスレで聞くより VS.net スレで聞いた方がいいと思うが。

ちなみに VC++.net でも MFC はサポートされてる。

680 ：デフォルトの名無しさん：02/02/17 18:28

>>675
じゃ、Cのどこが気に入らないのかを具体的に挙げてみれば?

てか、Cで、構造体とmalloc()の使い方がわかってりゃ、クラスと
インスタンスなんてわかったも同然だし、共用体の使い方がわかってりゃ
継承もわかるだろうし、それでswitch caseがうざいと思えば、
ポリモフィズムもわかるだろう。

…てことは、このスレのアンチは、Cもろくに使えてないんだろうね。

681 ：デフォルトの名無しさん：02/02/17 18:29

オブジェクト指向の信者ってなんつーかウザイ。
ブーチがどうとか、ハンバーグがどうとか、
見てて痛すぎるのがおおいです。
よくGNU信者がウザイ言われたりしてますが、
そんなOO信者のレベルには程遠いな（ｗ

痛さとアホさの点では彼らは群を抜いてます。
OOが胡散臭く感じられる原因はあなたの周りの
ｷｼｮｲ信者でしょう。

682 ：　：02/02/17 18:29

Ｃの欠点・・・。
ＯＮ－ＧＯＴＯが排除された。

683 ：デフォルトの名無しさん：02/02/17 18:31

signal & raise で充分でそ

684 ：デフォルトの名無しさん：02/02/17 18:38

みなさん！始まりました!!アンチの難癖攻撃ですよ～～！

685 ：デフォルトの名無しさん：02/02/17 19:29

>>681
相変わらず技術的な問題点の指摘はないのな…

686 ：デフォルトの名無しさん：02/02/17 19:47

>>685
おれはOOがキライだなんて言ってない。
信者がウザイんだよ。oosquareとかを
読んでると鳥肌立ちっぱなし。

687 ：デフォルトの名無しさん：02/02/17 19:52

なんか >>680 が激痛なんですけど。

688 ：デフォルトの名無しさん：02/02/17 19:59

oosquare って、
国内のWeb上では数少ない、
まともな OO全般の情報源でそ。

DQNなあなたが見て、理解できなくてもしょうがない。
あれって、
国外の本スレ見ながら、評論/コメントしてるスレみたいなもんだからなぁ。

689 ：686：02/02/17 20:02

>>688
oosquare-mlの間違い。
Web上のものはよく勉強させてもらってます。

690 ：デフォルトの名無しさん：02/02/17 20:07

>>686
いつから、ここは感想文を書くスレになったんだ？

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

最初からだろ

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

べつにＯＯを否定するのはかまわないけど、否定するならするで、
べつのスタンスからＳＥとＰＧの作業領域にある問題を解決する
方法論ってものを考えていってほすぃ。
否定だけじゃ、なにも進まない。
ＯＯを肯定することや否定すること自体には意味ないのよ。
もう、やめてけれ。

693 ：　：02/02/17 22:24

おいおい、従来のスタイルと個人を攻撃したのはＯＯ側が最初だぞ。

694 ：デフォルトの名無しさん：02/02/17 22:30

>>693
OO 側って何よ？

２ちゃんねるで書き込んでる人間は、特定の指揮系統の元で行動してるわけじゃ
ないんだから、その手の陣営わけは意味がない。しょせんは個人の問題だ。

（で、感想じゃなくて技術的な話はないのか？）

695 ：デフォルトの名無しさん：02/02/17 22:34

>>693
被害者意識が強いのでは？
「OO は以前の方法に対してこの部分がこう素晴らしい」
と論理的かつ的確に説明してあげることが、
従来のスタイルと個人に対する攻撃だというのなら話は別だが。
(それに、OO は「従来のスタイル」を内包しているから、そもそも攻撃なら自己否定になる)

696 ：デフォルトの名無しさん：02/02/17 23:07

>>689
俺は別にアンチじゃないけど、oosquare-ml はマジでキショいね。

697 ：692：02/02/17 23:21

>>693
>ＯＯを肯定することや否定すること自体には意味ないのよ。
ＯＯ派アンチＯＯ派（そんなんがあれば）を肯定することや
否定することにはもっと意味がない。
くだらねぇ・・・おまえ。

698 ：デフォルトの名無しさん：02/02/17 23:28

おいおい、従来のスタイルと個人を攻撃したのはＯＯ側が最初だぞ。
ふーん

699 ：680：02/02/17 23:30

>>687
ん? どこが?

まずいところがあるなら指摘してほしい。

700 ：デフォルトの名無しさん：02/02/17 23:35

で、結局あんたらの言うOOって何を指してるの？
C++？

701 ：デフォルトの名無しさん：02/02/17 23:38

>>700
それは (one of) OOPL だろ…。

702 ：デフォルトの名無しさん：02/02/17 23:39

>>700
俺は～なんだろうね、OO が解った！って思ったのは結城氏のデザパタ本読んでた時かなぁ…。
それまで俺のやってた事が、ここでいう「クラス指向」に他ならないって事に気付いたので。

703 ：デフォルトの名無しさん：02/02/17 23:46

「お前はOOを理解していない」
これを言うのは人の勝手だけど、
それじゃあんたの理解するOO的要求定義～テストを
説明してくれよ。

上のような言葉を吐くのにろくなのはいないとおれは決め込んでる。

704 ：デフォルトの名無しさん：02/02/17 23:48

>>703
ほんとに勉強したいのなら、こんなこころで聞かずに、定評ある書籍を読む
ことをすすめるが。

だいたい、まじめに語ったらいくら端折っても「UML モデリングのエッセンス」
ぐらいの厚さになるわけだし。

705 ：デフォルトの名無しさん：02/02/18 01:27

>>703
>それじゃあんたの理解するOO的要求定義～テストを説明してくれよ。

口を開けて答えを待ってる馬鹿につける薬は無いんだが、とりあえずどこまで理解
してるか言ってみ？ん？

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

>>705
703 じゃないけど。

OOについて議論するなら、「OOとは何か」を先に定義しないと
話が進まないというのは事実だと思うがな。

707 ：デフォルトの名無しさん：02/02/18 13:29

個人的には罵倒覚悟で言うと、最初にOOを喧伝
するよりまずSTLの便利さを単純に示すべきだっ
たのでは、と思います。

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

>>707
最初って、なんの最初？

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

oosquare-ml晒し上げ

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

>>706

先に定義を提出した奴が嬲り殺しに遭うスレですが、何か？

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

>>707
STL は Generic Programming でしょうが。（多態してないはず）

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

オブジェクト指向とかいいもんかもしれないが

俺は言語の機能をしっかり引き出し効率的に設計し、効率的にコードを書くのを指向したいな

ひとりでやる時は、好きなように抽象化してコードが書けるけど
他人と作業するときは
　皆が理解して皆がメインテナンス出来る方法で実現することが最も効率的なコードとなるし
それが逆に不効率な人材しかいないなら、どこかで遮断してしまった方がいい。
しかしOO言語にある隠蔽機能はまだまだ足りない。　コンポーネントはいい線いってると思う
一番いいのは　スクリプトにしてしまう事だ

713 ：デフォルトの名無しさん：02/02/18 21:33

OO信者の信条

自分が作ったものだけが唯一信頼できるものだ。
他人の作ったクラスは使うな。

714 ：デフォルトの名無しさん：02/02/18 21:46

> 一番いいのは　スクリプトにしてしまう事だ
ようはソース単位でってこと？

715 ：デフォルトの名無しさん：02/02/18 23:06

>>706
OOとは何か？

　人間は様々なパーツで構成され、それらは多種多様の細胞で構成されている。
　多種多様の細胞は細胞という一つの概念として見ることが出来る。
　細胞は水、タンパク質などの物質で構成されている。

このような分析をする事をOOAと言い、こういう考えで設計する事をOODと言う。
さらにこの構成でプログラムすることをOOPと言い、それに適した言語をOOPLと言う。

で良いのか？

716 ：デフォルトの名無しさん：02/02/18 23:22

>>715
一応ツッコミ。
OOA, OOD, OOP, OOPLは出てきたがOOが出てきてない。
それからそうゆう例示は「定義」とは言わんよ。

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

>>715

その論法で動物の体をモデリングしたら細胞の分化レベル毎に染色体の数が違って
しまいそうだが？

718 ：715：02/02/18 23:30

ツッコミありがとう、確かにその通りだ。
日本語から勉強し直してきます。

719 ：デフォルトの名無しさん：02/02/19 10:12

やっぱオブジェクト指向ってモデリングがキモだと思うんよ。
モデリングがクソだと、どう足掻いても生産性や保守性はあがらないよな。
これはコンピュータがただの計算機ではなくなってきたときからかわらないもんだと思うんだけどどうだろ？

720 ：デフォルトの名無しさん：02/02/19 12:35

>>719

後半、ひらがな多過ぎ。

721 ：デフォルトの名無しさん：02/02/19 14:55

ツンツンとつつくと何か反応を返すのがオブジェクト。
自分が何者で何に反応するかも答えられると尚よい。

そんなオブジェクトでソフトウェアを構成するのがオブジェクト指向。
ここでいうソフトウェアには分析/設計も含まれる。

ってな感じでどーでしょ。

722 ：デフォルトの名無しさん：02/02/19 22:41

http://pc.2ch.net/test/read.cgi/tech/1013995470/
レガシーなみなさん、遊びに来てください。

723 ：　：02/02/20 01:46

>>721
まあ、そんなもん。

724 ：720：02/02/20 23:46

>>723

同意。
ちょうど良い比率だと思う。

725 ：デフォルトの名無しさん：02/02/21 11:56

>>724
カタカナに騙されるな！

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

分析をかなり行ってクラス設計しても、仕様変更の
部分によってはかなり根本から設計しないとダメな羽目に
なって結局それでかなり時間とられるようなことも、現場
ではある。

727 ：デフォルトの名無しさん：02/02/23 16:40

>>726
そうだな
あと、自分の設計スキルが未熟で
自分が設計したモデルと実際のモデルが食い違うこともある。

モデルが大きく異なってしまった場合、オブジェクト指向でも
作り直しに近い状態になる場合がある。

728 ：デフォルトの名無しさん：02/02/23 18:05

>>727
そういった点では非OOの方が修正がしやすいといえる。
つまりOOの管理のしやすさというのは、かならずしも
正しいとはいえない。

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

修正の仕方がちがうんじゃないかな？
おれはOO的な修正術なんて知らないから
よく分からないが。

730 ：デフォルトの名無しさん：02/02/23 18:22

>>727
> そういった点では非OOの方が修正がしやすいといえる。
どういった点だ？
非OOではモデルと実際が食い違っても修正しなくていいのか？
いいな、ぜひその方法論をここで公開してくれ。（藁

731 ：デフォルトの名無しさん：02/02/23 19:48

いまやってる業務でクラス設計したやつが上司なんだけど、
これがまたクソなんだよ。でも自分ではすばらしい設計
だと思ってやがる。OO信者にはそういう奴が多くないか？
自分流クラス設計の自己満足の世界に浸っている奴。結局
多人数で作業し始めるとその「完璧なる」クラスがボロボロ
になっていき、結局「これは根本的な仕様変更なので・・・」
って言い訳して、また最初からやってやがる。OOって
実際はそんなもん。よほど非OOのほうが融通が利くよ。

732 ：デフォルトの名無しさん：02/02/23 19:49

オブジェクト指向は戦場では必要無し！

733 ：デフォルトの名無しさん：02/02/23 19:51

>>731
設計やってるヤツのレベルが低いと大変だよな。OO に限らず、データベースの
スキーマ定義とかでもそうだが。

734 ：デフォルトの名無しさん：02/02/23 19:53

>>731
根本的な仕様変更だからといって、全部作り変えるようなクラス設計
してるその上司がアホなだけじゃん。

クラスが全て再利用不可能などという事態になることは、マトモに
設計していればありえないと思うんだが…

735 ：デフォルトの名無しさん：02/02/23 19:55

OO信者の言い訳
「それは設計が悪いから。」

そのまんまじゃん。（ｗ

736 ：デフォルトの名無しさん：02/02/23 19:57

非OOは設計なんか適当にやっているから、
設計を大きく変更する必要があっても適当にやれる。
正しい設計なんて無関心だから間違った設計で進められる。
神経が麻痺するから、どんな状態でも問題に気づかなくてすむ。
技術的なことに興味がある人がいないので自分も技術力が無くていい。

737 ：デフォルトの名無しさん：02/02/23 20:00

>>736
もう呆れるね。
それさえも通り越して哀れだね(ﾌﾟ

738 ：デフォルトの名無しさん：02/02/23 20:02

>>735
空行多すぎ。圧縮してくれ。

739 ：デフォルトの名無しさん：02/02/23 20:11

>>735
あのさ、非ＯＯとやらでも、根本的な仕様変更があったとしても
それまでそのシステム開発のために作成したライブラリの殆どは
流用できるでしょ？

システムの仕様が顧客の要求で変更になったとしても、それは単に
表層でやり取りするデータの構造が変わったとかビューの表現形式
が変わったとか、せいぜいその程度の事で、それより下の層に関わ
る部分のライブラリってそのまま使えると思うが…
そのように作っていればだけど。

設計がアホなのにＯＯも非ＯＯも関係無いでしょ。

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

漏れもOOが変更に本当に強いものか疑問を抱いとる。
クラス間の結束が強いと、そこに機能を追加するのに
ばらしにくい。

741 ：デフォルトの名無しさん：02/02/23 20:16

つーかさ、業界の流れを見てるとOOが普及してきているとしか
思えないじゃん。それでも非OOだけでやっていけると思っているの？
それともOOが普及してきている事実を見たくないの？
そうだよね。COBOLと同じで自分の仕事がなくなるんだもんね。
だめだよ、プロならちゃんと勉強しなきゃ(w

742 ：デフォルトの名無しさん：02/02/23 20:19

>>740
だから、そういうのはＯＯでも非ＯＯでも同じじゃん。
機能的に独立したライブラリ呼び合うようにしてなければ
非ＯＯだって同じことになるだろうが。

743 ：デフォルトの名無しさん：02/02/23 20:20

関数間の結束が強いと、そこに機能を追加するのにばらしにくい。

非OOもOOも同じで○○間の結束は弱くするよう設計しよう。

OOを使ったらそれだけでクラス間の結束が弱くなると考えていたら間違い。

744 ：デフォルトの名無しさん：02/02/23 20:22

>>376
> 非OOは設計なんか適当にやっているから、
ということにしたいんだね。
OOが普及する前でも設計を適当やっているわけではない。

> 技術的なことに興味がある人がいないので自分も技術力が無くていい。
OOって技術なの？OOPLは技術だと思うが．．．
個人的にはOOは哲学やイデオロギーの部類に入ると思っているのだが？

745 ：デフォルトの名無しさん：02/02/23 20:28

ﾌﾟﾌﾟｯ

746 ：デフォルトの名無しさん：02/02/23 20:34

どうもＯＯと非ＯＯとやらの間に、何かのヒエラルキーのようなな
ものを持ち込みたがってる詐欺師がいるな。

ＯＯでのメリットなんて、巧く設計するとライブラリの再利用性を
簡単に上げるチャンスがあるよん、機能単位の抽象化が実装レベルで
簡単に出来るチャンスがあるよん（あくまでも「巧く」設計出来る人
がいれば、だけど）という程度でしょ。

その他のシステム開発に関わる大部分の問題は、ＯＯだろうが非ＯＯだ
ろうが全く同じじゃん。

747 ：デフォルトの名無しさん：02/02/23 20:36

　情報技術（ＩＴ）系の派遣技術者のうち、ネットワークに使う共通言語「Ruby」を使える
人材の需要が高まっている。派遣会社の受け入れ企業に対する請求額は月額80万円
程度（首都圏）。同じＩＴ系でも比較的単純な業務に当たるプログラマーの料金が下落
傾向なのと対照的だ。

　相次ぐ合併・買収など企業の再編に伴って、各社が持つシステムの変更・更新などの
ため、ネットワーク言語を使いこなせる専門スタッフが必要になっている。システム投資を
控えていた外資系企業の一部でも新規のネットワーク構築の動きがみられ、同様の人材
確保を急ぎ始めた。

　一方、派遣プログラマーには余剰感が強い。これまで派遣会社や需要先のソフト開発
会社などが人材を積極的に育成してきたうえ、人件費が安い中国へ外注したり現地法人
を作って開発したりする例も多い。派遣会社の請求料金は首都圏で月額45万―55万円
程度。特に技術レベルが低い層では、30万円台の料金も登場している。

748 ：デフォルトの名無しさん：02/02/23 20:38

OOでも非OOでも結局「モデル」と考えないと設計はできない。
OOPLはOOで考えた「モデル」を他の設計技法よりも柔軟で強力に表現できるだけに過ぎない。

749 ：デフォルトの名無しさん：02/02/23 20:38

設計は戦場では必要なし。
他人のソースを見るにも複雑でときほぐしにくい。
ちゃんと整備されたドキュメントがなければ粗大ゴミソース
実際は世の中にどれだけの糞SEや糞PGがいることか。。。
よって設計は戦場では使いものになりません。

750 ：デフォルトの名無しさん：02/02/23 20:40

>>743
> OOを使ったらそれだけでクラス間の結束が弱くなると考えていたら間違い。
agree

なんでもかんでも実装継承するバカは逝って良し。

751 ：デフォルトの名無しさん：02/02/23 20:43

>>746
> ＯＯでのメリットなんて、
不勉強なのがバレバレですな。

とりあえず（本来は UML の本なんだが OO の設計技法に関する入門書としても、
非常に出来が良い）「UML モデリングのエッセンス」あたりを読むことを強く推奨。

752 ：デフォルトの名無しさん：02/02/23 20:43

>>750
うちの会社には、public変数だけで出来ている構造体もどきクラスを
つくり、さらにそれを継承したものをデータのコンテナとして使用する
設計を行い、美しい設計だと自画自賛してるアホがいる。
バカにＯＯ使わせるとろくなことにならんよ。

753 ：デフォルトの名無しさん：02/02/23 20:47

>>746
> どうもＯＯと非ＯＯとやらの間に、何かのヒエラルキーのようなな
> ものを持ち込みたがってる詐欺師がいるな。
詐欺師ではありません。詐欺師だったらもう少し頭がいいはずです。

彼らはOO信者なのです。
すべての設計をOOでやれば必ず幸せになれると信じている少し頭の弱い人ですが、
内容のないレスを大量に書くことを厭わない暇人です。

754 ：デフォルトの名無しさん：02/02/23 20:50

>>752
そういう構造化以前の話はもう聞き飽きた。
OOとは関係ない話だよ、それは。

755 ：デフォルトの名無しさん：02/02/23 20:50

>>753
正直、氷魚と Kusakabe には負ける。

756 ：デフォルトの名無しさん：02/02/23 20:51

>>752
バカに非OOを使わせても同じだろ。
OOを使えん奴に非OOを使わせるな。教育してからにしろ。

OOの仕事→OOを使える奴がする
非OOの仕事→非OOを使える奴がする。

出来ない仕事は断るか、仕事が出来るようする。それだけ。

757 ：デフォルトの名無しさん：02/02/23 20:52

>>754
べつに 750 も 752 も「だから OO はダメだ」とは言ってないと思うけど。
単なる愚痴でしょ。

758 ：デフォルトの名無しさん：02/02/23 20:56

>>753
OO信者をanti OOにしても、そのまま使えそうな文章だね。

彼らはanti OOなのです。
すべての設計をOOを使わずにやれば必ず幸せになれると信じている少し頭の
弱い人ですが、内容のないレスを大量に書くことを厭わない暇人です。

（イマイチ、面白くないね。ごめん）

759 ：デフォルトの名無しさん：02/02/23 20:57

厨です。OOの問題点は何でしょうか。教えてください。

760 ：デフォルトの名無しさん：02/02/23 20:58

>>759
難しすぎることです

761 ：デフォルトの名無しさん：02/02/23 20:59

>>759
マトモに使える人が殆どいないこと。
マトモに使えてないのに、使えているフリをして虚構で他社との差別化
をはかり、無知な顧客から大金を巻き上げる、ベンチャーの詐欺行為の
道具に成り下がっていること。

762 ：デフォルトの名無しさん：02/02/23 20:59

>>753
> すべての設計をOOでやれば必ず幸せになれると信じている少し頭の弱い人ですが、
この行のみには同意。ただし、非OO信者、OO信者両方いると思うけどね。

全ての設計をOOでやれば幸せになるわけではない。
非OOがふさわしければ非OOでやる。
OOがふさわしければOOでやる。

どんなときでも非OOもしくはOOを選ぶ奴は信者。
どちらかしか使えない奴はバカ。

現実としては非OOしか使えない糞SEや糞PGが多いみたいだけどね。

763 ：デフォルトの名無しさん：02/02/23 20:59

>>756
言いたいことははっきりと言えよ

OOの仕事→OOを使える優秀な奴がする
非OOの仕事→OOを使えない低脳がする

764 ：デフォルトの名無しさん：02/02/23 21:00

>>558
> OO信者をanti OOにしても、そのまま使えそうな文章だね。
この世にはOO信者とanti OOしかいないと思っている人にはそうみえます:)

765 ：デフォルトの名無しさん：02/02/23 21:01

あのー、なんでＯＯと非ＯＯが対立する概念のように扱われてるん
でしょうか？

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

>>765
信者には外の世界はカオスにしか見えないものです:)

767 ：デフォルトの名無しさん：02/02/23 21:03

>>764
話のつながりが謎だ…

>>765
気のせい。片方に過剰な思い入れがある人間が、そういう書き方をしてるだけ。

768 ：デフォルトの名無しさん：02/02/23 21:04

非ＯＯって具体的になんだろう？

769 ：デフォルトの名無しさん：02/02/23 21:05

>>768
Javaを使わないことです。

770 ：デフォルトの名無しさん：02/02/23 21:07

>>769
違います。Javaが使えないことです。

771 ：デフォルトの名無しさん：02/02/23 21:13

>>763
そのうち低脳から無能になる(w

772 ：デフォルトの名無しさん：02/02/23 21:20

>>759
OO で問題領域をモデリングする場合には、その分野のエキスパートの認識方法
を反映した形で設計を行う。それが最終的には仕様変更の強さにつながってくるん
だが、どうしても設計にかかる時間は長くなる。

人間は世界を動的分類で捉えてる節があるんだが（その方が明らかに分析しやす
い）、現在主流の OOPL は動的分類には対応していない。そのため、設計段階で
動的分類を静的分類に落とし込む必要があるのだけど、

- どこまで静的分類に落とし込むのか
- どのような手法を使うのか

が割と難しい。

また再利用性を高めることを目的とした場合、主流の OOPL が言語機能として提
供している「実装継承」は目的の一部しか達成できない上、基底クラスと派生クラ
スの間の結合を不必要に強めてしまう。

実装継承の問題を避けつつ再利用性を上げるための方法は Design Patterns と
してまとめられているが、こういったイディオムを知らないと再利用できる枠組み
が作れないことも、難点かもしれない。Design Pattern を使ってかかれたコードは、
今度は Desgin Pattern 知らないと

　「何を、こんな回りくどいことをやってるんだ」

ってコードに見えてしまうし。

OO でやろうとすると、覚えることが多く、失敗すると悲惨で、かつ初期コストが嵩
むのよ。（それでも OO 捨て捨て、とならない程度にはメリットがあるわけだが）

773 ：デフォルトの名無しさん：02/02/23 21:25

>>768
> 非ＯＯって具体的になんだろう？
モジュール化設計
OOPLに対応する言語はCやPascal

さらにその前はCOBOLなどがあり、
COBOLには内部変数や再入可能な関数は存在しない

774 ：デフォルトの名無しさん：02/02/23 21:27

>>772
一つ教えて。
動的分類と静的分類とはどういう意味？

775 ：デフォルトの名無しさん：02/02/23 21:30

>>774
goto google

（多重分類もキーワードにすると、それっぽいページが出てくると思う）

776 ：デフォルトの名無しさん：02/02/23 21:34

>>772
> 現在主流の OOPL は動的分類には対応していない。
確認するけどC++やJavaはOOPLと思っているの？
あれはクラス指向言語であってオブジェクト指向言語じゃないよ。

777 ：デフォルトの名無しさん：02/02/23 21:35

クラス指向とオブジェクト指向の定義は？

778 ：デフォルトの名無しさん：02/02/23 21:35

珍説登場！

779 ：デフォルトの名無しさん：02/02/23 21:37

そのうち「真のＯＯＰＬは、まだ登場していない」などという説が出てくるに、２００ガパス。

780 ：デフォルトの名無しさん：02/02/23 21:41

>>777
くらすべえす
と
ぷろとたいぷべえす
ということでは？

781 ：デフォルトの名無しさん：02/02/23 21:44

>>776
無理しないでｱﾌｫは素直に非OOしてろよ(藁

782 ：デフォルトの名無しさん：02/02/23 21:44

776面白すぎる・・・
おかげでキーボードがお茶で汚染されたじゃねーかぁ

>こういったイディオムを知らないと再利用できる枠組み
>が作れないことも
OOがきちんとわかっていれば、
イディオムなんて知らなくても・・・以下略
それとも、脳の問題かな。

783 ：デフォルトの名無しさん：02/02/23 21:45

>>780
それでは意味が通らないので却下。

784 ：デフォルトの名無しさん：02/02/23 21:46

>>772
オレがOOに感じている行き詰まり感が簡潔に述べてあるな(w

クラスが扱う問題の領域を設定することが難しいことも問題の
一つとしてあると思う。再利用可能なだけに間違えても修正
しづらいだろうし。

785 ：デフォルトの名無しさん：02/02/23 21:48

動的分類と静的分類で検索して
たったの4件。あんまりメジャーな
概念ではない？

786 ：デフォルトの名無しさん：02/02/23 21:51

785
ｽﾏｿ
dynamic static classification
これで山のように出てきました

787 ：デフォルトの名無しさん：02/02/23 21:51

再利用再利用っていったいなんのこと言ってんの？
フレームワーク・クラスライブラリ・アプリ固有のクラスが混同されてるような。

788 ：776：02/02/23 21:51

>>777-782
お前ら今まで使ってきた言語がOOPLじゃないからって
そんなに動揺しなくたっていいだろ？

別にOOPLじゃない言語だってOOは不可能じゃないんだから。

789 ：デフォルトの名無しさん：02/02/23 21:51

>>785
まぢ？　OO の大御所ファウラーが著した「アナリシスパターン」なんかで詳細に
取り上げられてる話なんだが。

http://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/

790 ：　：02/02/23 21:52

クラス指向の例で判りやすいのは
「手続き型クラス」
setVideoModeクラスとか、
caliculateUserPayクラスとか。
でどうよ？

791 ：デフォルトの名無しさん：02/02/23 21:53

>>790
意味不明

792 ：デフォルトの名無しさん：02/02/23 21:55

>>788
とどのつまり「俺用語」で客観的な定義はないわけね…

793 ：デフォルトの名無しさん：02/02/23 21:57

じゃあいったい何がOOPLなんだよ。
理由もつけて教えてくれ。
無いって落ちはやめてくれよ。

794 ：デフォルトの名無しさん：02/02/23 21:57

みんな、最低限、これくらいは読んでるよな？
http://www.zzz.or.jp/~iizuka/EOO/Japanese/oofaq-j/oo-faq-toc.html

795 ：デフォルトの名無しさん：02/02/23 21:58

OOPLが何だとか言ってるの・・・不毛だ

796 ：776：02/02/23 21:58

>>779
あっそうそう書き忘れてた
> 「真のＯＯＰＬは、まだ登場していない」
現在の言語の中ではSmallTalkがOOを忠実に表現した言語

SmallTalkが自転車だとするとC++やJavaなどは
クラスという補助輪をつけたお子さま用自転車

C++やJavaを使っているごときでOOPLを使っていると言って欲しくないな。
補助輪付き自転車に乗って「自転車に乗れます」というくらい恥ずかしいyo

797 ：デフォルトの名無しさん：02/02/23 21:59

>794
ブラクラ

798 ：　：02/02/23 22:00

信者ならバイブルを示さないとね。
んで現実を無視して
「この本にこう書いてある」としかいわねーのｗ
（現実との擦り合わせが行われない脳構造の持ち主）

799 ：デフォルトの名無しさん：02/02/23 22:00

OO信者の自作自演劇がそろそろ始まるころです。

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

>794
精神的ブラクラ

801 ：772：02/02/23 22:03

結局 OO に対する技術的な批判は、他にないの？

OO 反対派の人たちから「なるほど」と思う批判を聞いたことがないんだけど。

802 ：デフォルトの名無しさん：02/02/23 22:05

>801
意見はないが現実を見ろの一言だろ。

そんな優秀な奴がこの世にどれだけ
いるよ。この世はDQNで出来ている
んだよってな感じ。

803 ：794：02/02/23 22:06

（バイブルを示したんだから、その内容にツッコミ入れてみろっつーの…）

804 ：776：02/02/23 22:06

> 結局 OO に対する技術的な批判は、他にないの？
ないよ。だってOOは技術ではなく、哲学であり、美学であるのだから。

805 ：　：02/02/23 22:07

>>801
前から出てるじゃん。
１）生産性が下がる
２）その他、ＯＯ関連本に書いてある事は嘘ばかり
３）詐欺師蔓延、ベテラン圧殺。

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

>ベテラン圧殺。
ﾜﾗﾀ

807 ：776：02/02/23 22:09

>>805
それは*技術的*

808 ：デフォルトの名無しさん：02/02/23 22:11

>>805
それは批判といわない。ただの推測。

809 ：デフォルトの名無しさん：02/02/23 22:11

戦いの勝敗は始まる前に九割がた決まってる。
プロは準備に充分過ぎるほど時間をかけるものだ。

810 ：776：02/02/23 22:12

書き込み途中だった
>>805
それは*技術的*な批判ではないだろ？
# どっちかってーと愚痴だね

811 ：デフォルトの名無しさん：02/02/23 22:13

>776
お前も技術的な話なんてなんもしてねーな

812 ：デフォルトの名無しさん：02/02/23 22:13

>>805
> その他
おいおい（ｗ

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

>>802
俺の知っている現実は「優秀な奴が生き残る」なのだが…。

814 ：　：02/02/23 22:17

おいおい、生産性が技術と関係無いと思ってるのはかなりＤＱＮだぞ。

>>813
俺の知っている現実は「優秀なフリした押しの強いだけの奴が生き残る」なのだが…。

815 ：デフォルトの名無しさん：02/02/23 22:18

>>813
じゃぁお前一人で全部やってろよ

816 ：デフォルトの名無しさん：02/02/23 22:18

>>814
つまり、「そういう奴を評価するDQNが経営者やってる」ということですね。

817 ：デフォルトの名無しさん：02/02/23 22:19

オブジェクト指向一生懸命勉強したのに・・・。
（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者

818 ：デフォルトの名無しさん：02/02/23 22:19

>>814
> おいおい、生産性が技術と関係無いと思ってるのはかなりＤＱＮだぞ。
OOだと生産性が下がる、というのが示されてない以上は愚痴と同レベル。
統計データを出せとは言わんが、せめて

「なるほど、それは下がるよなぁ」

と思う程度の理屈は書いてくれないと。

819 ：デフォルトの名無しさん：02/02/23 22:20

デザインパターンとかUMLとかも指向一生懸命勉強したのに・・・。
（´・ω・｀）ｼｮﾎﾞｰﾝ
↑
OO信者

820 ：デフォルトの名無しさん：02/02/23 22:20

>>815
どこから、そういう結論が出てくるんだ？　話が飛躍しすぎだろ。

821 ：デフォルトの名無しさん：02/02/23 22:21

>SmallTalkが自転車だとするとC++やJavaなどは
>クラスという補助輪をつけたお子さま用自転車
なぜ？
SmallTalk信者？
どこがいいんだか語ってください。

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

>>814
「優秀なフリした押しの強いだけの奴が生き残る」よりも
「優秀で押しの強い奴が生き残る」じゃないのか？

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

お前ら、業務系の話をしてるんだろ？
業務系で優秀なプログラマだけを集めたら
いくらかかると思ってるんだ？

824 ：デフォルトの名無しさん：02/02/23 22:24

OOで生産性が下がるのは、プロジェクトに関わる人間のなかに
OO分かってないのに背伸びして分かった振りして、結局出来
なくてプロジェクトに迷惑掛け捲る奴がどこにでも多数いる
という、技術云々以前の社会的要因によるものとおもわれ。

825 ：デフォルトの名無しさん：02/02/23 22:25

>>823
無能なプログラマ・SEを集めたほうが結果的にお金がかかります。

826 ：デフォルトの名無しさん：02/02/23 22:25

オブジェクト指向でSmallTalkが連想されるなら、オブジェクト指向が戦場で必要と
されるケースは少ないだろうな…

827 ：デフォルトの名無しさん：02/02/23 22:27

早く大学でOO仕込まれたまともな学生がたくさん世に出てきて
非OOベテラン(藁低脳コーダとリプレースされないかな

828 ：デフォルトの名無しさん：02/02/23 22:27

>>824
それを言い出すと派遣云々の話になってややこしくなるに３ベルマーク

829 ：デフォルトの名無しさん：02/02/23 22:27

Smalltalk　な。

830 ：デフォルトの名無しさん：02/02/23 22:27

794のリンク先は
1節: 基本
1.1) オブジェクトって何ですか？
1.2) オブジェクトのカプセル化（または保護）っ何ですか？
1.3) クラスって何ですか？
1.4) メタクラスって何ですか？
1.5) オブジェクトとクラスの無限の連鎖って何ですか？
1.6) ＭＯＰｓと自己投影って何ですか？
1.7) 継承って何ですか？
1.8) 多重継承って何ですか？
1.9) 多重継承はどんな付加的な困難をもたらしますか？
1.10) 動的継承って何ですか？
1.11) 共有された（または反復した）継承って何ですか？
1.12) どうして継承を使うのですか？
1.13) どうしてある人たちは継承を嫌うのですか？
1.14) 特化／汎化／再定義って何ですか？
1.15) オブジェクト・ベースとオブジェクト指向って何が違うんですか？
1.16) クラスはオブジェクトですか？
1.17) オブジェクトはクラスですか？
1.18) メソッド（そしてレシーバとメッセージ）って何ですか？
1.19) マルチメソッドと多重の多態性って何ですか？
1.20) ＯＯＰって何ですか？
1.21) ＯＯＡ／ＯＯＤって何ですか（そして必要なものはどこで手に入りますか）？
1.22) オブジェクト指向はどこからきたんですか？
1.23) オブジェクト指向の恩恵は何ですか？
1.24) ほかにどんなＦＡＱが利用できますか？
2節: 型付け
2.1) 多態性って何ですか？
ウェブスターの新世界辞書:
著者の定義:
Stracheyのオリジナルの定義 [Strachey 67]:
CardelliとWegnerの定義 [Cardelli 85]:
Boochの定義 [Booch 91, p. 517]:
Meyerの定義 [Meyer 88, セクション 10.1.5 多態性]:
Stroustrupの定義 [Stroustrup 90, p. 209]:
2.2) 多態性は、オブジェクト指向プログラミング言語において、何に集約されますか？
2.3) 動的束縛って何ですか？
2.4) クラスのメンバーあるいはインスタンスであることに違いはありますか？
2.5) 静的型付けと動的型付けとの違いは何ですか？
2.6) MLと関数的プログラミング言語について私が聞くこれは何ですか？
2.7) タイプとクラスの分離（表現）って何ですか？
2.8) 総称とテンプレートって何ですか？
3節: 一般
3.1) 「古典的な」オブジェクト指向パラダイムって何ですか？
3.2) 「委譲／プロトタイピング」のオブジェクト指向パラダイムって何ですか？
3.3) 他にどんなオブジェクト指向パラダイムがありますか？

831 ：デフォルトの名無しさん：02/02/23 22:27

>>823
生産性マイナスのバカを雇うよりは、結果的に安くなりますが、何か？

……とはいえ質より人手が重要な場合もあるのは事実。まぁ OOPL といっても、
関数名や詳細仕様まで決めてしまった上で単純なコーディング作業だけやらせ
るぶんには、優秀じゃない人間でも使えるよ。

このあたりは、非 OO で蓄積したノウハウがそのまま活かせる。

832 ：　：02/02/23 22:28

>>822
押しの強い奴に責任感ある奴は少ない。

>>821
Javaが補助輪付きだっつうのは当たってるわな。
悔しかったら俺に関数ポインタを返せ！

833 ：デフォルトの名無しさん：02/02/23 22:28

頭数でプロジェクトの規模を計るのは辞めて欲しい

834 ：デフォルトの名無しさん：02/02/23 22:29

>>SmallTalkが自転車だとするとC++やJavaなどは
>>クラスという補助輪をつけたお子さま用自転車
>なぜ？
俺もこれ気になる。
書いたやつは責任持って答えろYO

835 ：デフォルトの名無しさん：02/02/23 22:29

>>832
関数ポインタで何がしたいんだ？

836 ：デフォルトの名無しさん：02/02/23 22:29

>>832
> 悔しかったら俺に関数ポインタを返せ！
interface 使え Yo!

837 ：835：02/02/23 22:30

>>836
せっかくいじめようと思ったのに・・・

838 ：デフォルトの名無しさん：02/02/23 22:32

>>833
確かにそれは言えてるな。
人月神話以前の問題。
そうやって公共の仕事の
水増し請求してるんだから
世話ない。

839 ：　：02/02/23 22:36

>>836
アフォか！インターフェースじゃ関数ポインタの変わりにならんわ！
せめてリフレクションと言え。
つうか携帯java担当なんでどっちも使えないがな。

840 ：デフォルトの名無しさん：02/02/23 22:37

>>839
多態を利用してディスパッチする事も知らない人は、
OOP使う資格ないです。

841 ：デフォルトの名無しさん：02/02/23 22:37

>>839
関数ポインタでなにがしたい？

842 ：デフォルトの名無しさん：02/02/23 22:38

>>840
836だろ？
じわじわいじめようって言ってんだろうが。

843 ：836：02/02/23 22:41

>>842
違うって。俺は 837 の時点で、じわじわ虐めるのは承知してる（ｗ

844 ：デフォルトの名無しさん：02/02/23 22:50

>>839
逃げた?

845 ：　：02/02/23 22:51

>>841
いわゆるメタ構造かな？
関数ポインタ無いと静的プログラムしか書けない。

846 ：デフォルトの名無しさん：02/02/23 22:52

>>845
あなたがそう思い込んでるだけでしょう。

847 ：デフォルトの名無しさん：02/02/23 22:54

>>845
> いわゆるメタ構造かな？
これだけだと良く分からんので、具体的な事例を希望。

848 ：デフォルトの名無しさん：02/02/23 22:55

>>843
なるほど、ゴメン。
845の発言を見てニヤリとできるでしょ（ｗ

849 ：デフォルトの名無しさん：02/02/23 22:57

http://pc.2ch.net/test/read.cgi/tech/1013995470/l50

850 ：デフォルトの名無しさん：02/02/23 22:59

>>776
>>796
はバグでした。
ごめんなさい。

851 ：デフォルトの名無しさん：02/02/23 22:59

それよりも１の名前が気になる。けんしろう？

852 ：デフォルトの名無しさん：02/02/23 22:59

アンチは逃走したようなので、
今日は終了ですな。

853 ：　：02/02/23 23:06

まあ、お前らは低脳にふさわしく静的プログラムだけ書いてなさい。

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

>>853
C で関数ポインタを使うとかけるが、Java だとかけない「動的プログラム」って
具体的に何よ？

855 ：　：02/02/23 23:11

データベース覗いて勝手にメソッド生成してくれるルーチンとかだな。

856 ：デフォルトの名無しさん：02/02/23 23:11

OOプログラマ＝頭がｲｲ！
って思っている馬鹿が数名います。

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

すばらしいルーチンだ。ぜひ公開してくれ。

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

>>855
仕様が曖昧すぎ。せめて読んでる人間がコードを書けるぐらいには、詰めて
書いてくれ。

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

>>856
それはどうか知らんがここのｱﾝﾃｨOOは莫迦ばっかだな。

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

>>856
どこに？　幻を見てるんじゃないのか。

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

>>855
なんとなくそれって動的プログラムというより動的プログラミング環境だね。
俺そっちのがいいなあ。誰か作ってくれ。
テストケースやら仕様書やらをどんどんヘルプみたいに取り込んでF1で呼び出せるとか。

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

それってエージェント指向。

863 ：　：02/02/23 23:18

ジョークだと思われてるしｗ;
いちいちプログラム書いてらんない。
普通はメタ使って自己生成する発想に行くと思うな。
ついでに動的ＨＴＭＬも自動生成して、テーブル書くだけで
終わる様にするのな。

864 ：デフォルトの名無しさん：02/02/23 23:19

>>863
それと関数ポインタとの関係を小一時間（以下略

865 ：　：02/02/23 23:23

>>864
とにかく、無いと出来ない。

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

>>865
出来ないと思いたがってる人には、一生できないだろね。
俺ならJavaでちょいちょいでできるけど。

867 ：デフォルトの名無しさん：02/02/24 00:20

つーか再三誰かが言ってるがそんなにOOって難しいか？
DQN以上の凡人だったら理解できる内容だと思うが、さて？

868 ：デフォルトの名無しさん：02/02/24 00:26

>>867
OO のメリットを生かした設計をするのは、それなりに難しい。

設計の大枠が与えられた状況下でプログラミングするのは、それなりのトレー
ニングは必要だけど、無茶苦茶に難しいって事はないと思う。

869 ：デフォルトの名無しさん：02/02/24 00:33

ＯＯって、理解するのはそれほど難しいとは思わない。
でも、奥が深くて楽しい。

870 ：デフォルトの名無しさん：02/02/24 00:37

そんなに門が狭いってこともないよな～。

奥はおもいっきり広いがな。

871 ：　：02/02/24 00:39

＞奥はおもいっきり広いがな。

はあ？ライブラリのこと言ってるの？

872 ：デフォルトの名無しさん：02/02/24 00:41

（´－｀）。o ○ （またこいつか・・・）

873 ：デフォルトの名無しさん：02/02/24 00:51

>>871
アソコの事でしょう。

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

ﾏｰｰｰｰﾑｰｰｰｰｰｺｯｯｯ (ﾟДﾟ)ｺﾞﾙｧ
ﾏｰｰｰｰﾑｰｰｰｰｰｺｯｯｯ (ﾟДﾟ)ｺﾞﾙｧ
ﾏｰｰｰｰﾑｰｰｰｰｰｺｯｯｯ (ﾟДﾟ)ｺﾞﾙｧ

875 ：デフォルトの名無しさん：02/02/24 01:05

㋐㋭

876 ：デフォルトの名無しさん：02/02/24 01:23

>データベース覗いて勝手にメソッド生成してくれるルーチンとかだな。
おーい、誰かこのバカ何とかしてくれ・・・
C言語でメソッド？
それは置いといて
C言語でプログラムを書き換えるプログラムって書けるかよ。

とりあえず、具体例をあげろよな。

877 ：デフォルトの名無しさん：02/02/24 01:25

>普通はメタ使って自己生成する発想に行くと思うな。
メタだって(w
メタってなんですか？
と書いてみるテスト

878 ：デフォルトの名無しさん：02/02/24 01:26

コード出力
コンパイル
子プロセス起動

別段めずらしくもないだろうに…

879 ：デフォルトの名無しさん：02/02/24 01:28

>>878
いや、それだと C の関数ポインタとの関係が謎になる。どうも C で関数ポインタ
を使うと実現できるが、Java だと実現できない「何か」がキーらしいから。

880 ：デフォルトの名無しさん：02/02/24 01:28

>動的ＨＴＭＬも自動生成して、テーブル書くだけで
自動生成されたHTMLを動的HTMLといってるんだろう・・・
で、それを吐き出すコードを自動で作るのか？
それはテーブルを入力するとコードを出力するプログラムの事か？
関数ポインタとどう関係があるんだ？

881 ：デフォルトの名無しさん：02/02/24 01:30

>>878
そんなことするメリットがよくわからないしな・・・・

882 ：デフォルトの名無しさん：02/02/24 01:34

>>881
コード生成プログラム自体は、使うとスマートに問題を解決できることはあ
る。yacc とか lex とか。

ただ動的にコンパイルするのは、普通はやらんよね。それならインタプリタ
と JIT コンパイラ作るよ。

883 ：デフォルトの名無しさん：02/02/24 01:34

> そんなことするメリットがよくわからないしな・・・・
分かんなきゃ口出すなよ。

884 ：デフォルトの名無しさん：02/02/24 01:35

eval的なことをしたいんだろ。

885 ：デフォルトの名無しさん：02/02/24 03:01

CとJavaの比較スレでもこんなこと言ってるバカがいたな…
同一人物か?

>>884
>eval的なことをしたいんだろ。
「eval的なこと」は、たとえばPerlならできるが、Cでは、
たとえ関数ポインタを使ってもまともな方法ではできない。
ま、機械語コードを自分で生成して「関数ポインタ」で
強制的に呼び出せば可能だが、移植性は完璧に失われるわな。

Javaでは、「Cと同様に」まともな方法ではeval相当のことは
できない。ま、バイトコードを自分で生成してクラスローダ
作って呼び出せば可能だが、移植性は保たれるわな。

結論:少なくともこの点では、Javaの方がCよりはマシ。

Perlとかを比較対象に持ってきて「動的プログラムができない」
というのならわかるが、「Cと関数ポインタ」じゃ、無知を
さらしているだけだよ。

886 ：885：02/02/24 03:05

あ、

>CとJavaの比較スレでもこんなこと言ってるバカがいたな…

俺がバカと言ってるのは >>845 のことであって、そこで引用した
>>884 のことじゃないです。…と、一応念を押しとく。

887 ：　：02/02/24 03:47

コテハン叩くなや。

888 ：デフォルトの名無しさん：02/02/24 03:53

>>887
自分が無知であることにようやく気付いたと見える。

さらしage。

889 ：　：02/02/24 04:00

単純過ぎる煽り。

890 ：デフォルトの名無しさん：02/02/24 04:40

>>889
自分の無知さを晒されたからって、こりゃ見苦しいよな。

891 ：デフォルトの名無しさん：02/02/24 09:02

>>885
まあ、Cのソースから動的に生成するにしても、
「Cのソースから動的ライブラリを作ってロードしてやって、終わったら捨て」
なんつー超ムリヤリな方法が無いでもないがな。

ちなみにSmalltalkなら当然のように超簡単。
Compiler evaluate: 'a source code comes here'
既存のクラスに動的にメソッドを追加するのも超簡単。
つーか、Smalltalkの処理系自体、そうやって動いている。

で、関数ポインタがどうしたって？（藁

892 ：デフォルトの名無しさん：02/02/24 10:13

>>891
で? Smalltalk が優れているとでも? んなこたぁないよね。言語は適材適所だ。

893 ：デフォルトの名無しさん：02/02/24 10:44

動的生成ってWin16の頃はサンクという名前で普通に使ってたよ
今でもDelphiではコールバックをメソッドに割り付けるのに使ってる技術

894 ：デフォルトの名無しさん：02/02/24 10:50

>>893
動的生成って具体的にどんな事なの？

895 ：デフォルトの名無しさん：02/02/24 10:50

>コールバックをメソッドに割り付けるのに使ってる技術
これは関数ポインタと何が違うんだ？

896 ：デフォルトの名無しさん：02/02/24 10:51

サンクって16bitのコードを実行するためのものだよね・・・

897 ：デフォルトの名無しさん：02/02/24 11:04

OO言語のいわゆるメソッドは　いわゆる構造体をポインタとして隠れた引数に含む関数の事が多い
　staticな構造体であっても、メソッドであればこの為に間接参照となる。

仮想関数の場合、関数の呼び出しもポインタを介して行われる
　仮想関数の実装により違うし、その実装方法を指定出来るものも多いが、
　このポインタは書換可能領域を経由する事が多い
　この為、暴走し易い
　関数化しただけでも、関数の帰り番地はメモリに書かれ為嫌われる世界があるのに
　さらに関数の先頭番地までをメモリに置くというのは好ましくない

898 ：デフォルトの名無しさん：02/02/24 11:14

WindowsAPIではコールバックは関数ポインタを渡すよね？
　メソッドは関数ポインタの他にオブジェクトインスタンスアドレスも渡さなければならない

最近作られたAPIの多くはハンドル作成時にコールバック時に渡すアドレスを渡せるけど
肝心のWinProcには無い。（SetWindowsLongで埋めようと思えば埋めれｒけどね）

これを解決するのにDelphiでは　インスタンスの作成時に、短いコードを動的に作って
その関数内部でインスタンスアドレスを作り出している

Win16の頃は、DLLは共有されていた。　このDLLからコールバックを受ける為には
関数ポインタのほかにセグメントレジスタが必要になる　そこでやっぱり短いコードを
動的に作ってこの関数を経由して呼び出す事で解決していた。この技術をマイクロソフトはサンクと呼んでいた

899 ：デフォルトの名無しさん：02/02/24 11:35

さて、サンクという用語にしても知っている同士なら　その用語を使うだけで作業を進められるが
相手が知らないなら２つの道がある。
A　一つは知らなくても済むように用意して使わせる道
B　もう一つは相手に知って貰い、理解して貰う道

さてオブジェクト指向は、知り理解しなければならない用語が多い
　　　さらに、その用語がいまだ曖昧であるのは別にして
　となるとBのコストはAに比べれば高くなる

これで
現場を戦場と呼ぶようなプロジェクトでBの戦略を取るのはダメだという１の結論が得られるのだと
俺は思うが　どうか？

900 ：デフォルトの名無しさん：02/02/24 11:36

>>898
その手法はATLでも使われてるよ

901 ：急がばまわれ：02/02/24 11:47

>>899
短期の、あるいは一回限りのプロジェクトならそうとも言えるだろう。
しかし、Bを行っても、一度理解してしまえばその後の進捗は
Aよりも速くすすみ、トータルではBの戦略をとったほうが良いという
1への反論が得られるのだと俺は思うが、どうか？

902 ：デフォルトの名無しさん：02/02/24 11:53

>>901
現場を戦場と呼ぶようなプロジェクトでは、当然兵隊は外人または徴兵であると思われ

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

>>899
> さて、サンクという用語にしても知っている同士ならその用語を使うだけで作業を進められるが
ゲイツ社の取り巻き同士ならjargonが通じる、ってことかい？
いいね、狭い世間で生きている人たちは…

904 ：デフォルトの名無しさん：02/02/24 12:11

>>897
> このポインタは書換可能領域を経由する事が多い
> この為、暴走し易い
> 関数化しただけでも、関数の帰り番地はメモリに書かれ為嫌われる世界があるのに
> さらに関数の先頭番地までをメモリに置くというのは好ましくない
メモリを誤って上書きされるかもしれないから、メモリを使うべきじゃあないって事？
その前に、メモリを誤って上書きされないようにするのが正しいんじゃないの？
ここで質問。
CとJavaではメモリを誤って上書きされてしまう危険はどっちが高いでショーカ？
CとSmalltalkでは？

905 ：デフォルトの名無しさん：02/02/24 12:21

>>904
＞メモリを誤って上書きされるかもしれないから、メモリを使うべきじゃあないって事？
　スタックエリアはバス上のRAMには取らないとかね
　そういう世界もあるという話　一般的な話ではない

＞CとJavaではメモリを誤って上書きされてしまう危険はどっちが高いでショーカ
そういう世界ではCとJavaではなくROM化にどれだけ対応出来るかどうかが指標でしょう

906 ：デフォルトの名無しさん：02/02/24 12:23

jargonだらけはオブジェクト指向のほうでしょ >>903

907 ：デフォルトの名無しさん：02/02/24 12:26

サンクについてはわずか数行で説明出来る概念だけど
OOのjargonはそうではないのが問題なのでは？

908 ：907：02/02/24 12:28

構造化パラダイムのjargonに比べてOOはという意味ね

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

>>899
>A　一つは知らなくても済むように用意して使わせる道
誰が、用意するんだろう．．．。

910 ：デフォルトの名無しさん：02/02/24 15:05

>>909　ライブラリを作るという事でしょ？
VCLやWTLでサンクは使われてるけど　使ってる人の殆どは知らないし知らないでいい

911 ：デフォルトの名無しさん：02/02/24 15:05

>>908
とりあえず実装は横に置いといて、
分析・設計でどんなjargonがあるか、変な概念だと思うのを挙げてみてちょ。
そうすれば、それが本当に数行で説明できないものなのか、
本質的にひねくれてるのか、はっきりするんじゃない？

912 ：デフォルトの名無しさん：02/02/24 15:10

jargonて何よ？
お前ら、ほんとはjargonって言葉使いたいだけちゃうんかと問い詰めたい。小１時間問い詰めたい。

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

>>911
変な概念という意味ではないでしょ。
いくつかの概念が組み合わさってOOになってるんだけど
その全体像が見えてくるまでにそれなりのお勉強と時間が必要だという事でしょ
訓練で身に付けなければならない部分があって、覚えたその日から使えます
って訳にはゆかない

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

>>893
thunk は一般に数 word の機械語コードで、

- きわめて限られた用途に使う
- 効率最重要

という用途に使うよね。せいぜい ATL の CWindow で WndProc にポインタを
埋め込むとか、多重継承時に this ポインタのオフセットを調整する (vcall) と
か、その程度。

とてもじゃないが >>863 が言うようなメタプログラミングしようっつーのは非現
実的だと思う。前にも書いたが、ふつーはインタプリタにしないか？

で、関数ポインタと「メタ使って自己生成」の関係は何よ？ >>863

915 ：　：02/02/24 15:40

アンチメタとやりあうのは疲れた

916 ：デフォルトの名無しさん：02/02/24 15:41

>>915
どこにメタプログラミング捨て捨て、といってるヤツがいるんだ?　俺には
見えないんだけど。

917 ：デフォルトの名無しさん：02/02/24 15:43

アンチメタメタ系でてこーい

918 ：デフォルトの名無しさん：02/02/24 15:51

http://www.system-azure.co.jp/boo/

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

オブジェクト指向を理解するのに数学は必要なんですか？
なんか恒例の煽りみたいで、申し訳ないんですが。

920 ：デフォルトの名無しさん：02/02/24 16:20

OOを理解するには哲学を学びなさい。

921 ：デフォルトの名無しさん：02/02/24 16:25

>>920
哲学の何を学べばいいのですか？
ラッセル？アリストテレース？

922 ：デフォルトの名無しさん：02/02/24 16:25

ＯＯの哲学を無視して、技術的側面のみを、徹底して追いかけなさい。
そうすれば、偽者が哲学と言っている事柄の本質を、より良く理解できるでしょう。

923 ：　：02/02/24 16:32

>>921
カント

924 ：デフォルトの名無しさん：02/02/24 16:35

読んだこともない人の名前はあげないように

925 ：　：02/02/24 16:40

カントぐらい中学で読むよねー。普通。

926 ：デフォルトの名無しさん：02/02/24 16:41

>>925
読まないよ。西田読む奴はいるかも
しれないがそれにしても変な奴だよ（和良

927 ：デフォルトの名無しさん：02/02/24 16:41

素養がなくて、難しい事に直面すると、
すぐ宗教とか哲学に走る人って、
どの世界にも居るんだよねぇー。

漏れは、分析的な目を曇らせるな、と言いたい。

＃OOを宗教に例えると何よ(藁？

928 ：デフォルトの名無しさん：02/02/24 16:43

>>925 旧制中学かよ!

929 ：　：02/02/24 16:44

まあ、ＯＯ信者はこれを読めや。
http://www.eleutheria.com/philo/kdrv/kdrv0.html

930 ：デフォルトの名無しさん：02/02/24 16:44

哲学なんて必要なし、予備知識としての
数学も必要なしってことでいいんですね？

931 ：デフォルトの名無しさん：02/02/24 16:46

漏れは、数学的素養が足りないと反省してまーす

932 ：デフォルトの名無しさん：02/02/24 16:47

最低限は中学卒業レベルの知識(数学も哲学もその他も)

933 ：デフォルトの名無しさん：02/02/24 16:47

>>930
OK

OO でも論理学の助けを借りて、形式的な仕様記述を行うような方法論もあり
ますが、主流ではありません。必要になったら考えれば良いかと。

934 ：　：02/02/24 16:48

＞＃OOを宗教に例えると何よ(藁？

イスラム原理主義

935 ：デフォルトの名無しさん：02/02/24 16:49

>>934
それは宗教ではないが。敢えて言うなら宗派かなぁ。

936 ：　：02/02/24 16:50

じゃオウム真理教

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

>>934 >> 936
本当にどういう宗教か知って言ってるのか？
単にイメージの悪い宗教を羅列してるだけだろ。
次はあれかな？

938 ：デフォルトの名無しさん：02/02/24 16:54

じゃあ仏教は何よ？

939 ：デフォルトの名無しさん：02/02/24 16:55

>>932
アニミズム

940 ：デフォルトの名無しさん：02/02/24 16:58

ＯＯは道徳の授業無しでは語れないよ

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

OOにかぎらず、「プログラム技術」には数学の素養は必要だよな。
形式的手法とかで数学を前面に押さなくても、
やはり自分が書いている設計なりプログラムなりの意味を理解するには
数学という道具は必要だよね。

942 ：デフォルトの名無しさん：02/02/24 17:10

>>929
まあ面白いし、科学的方法論の基礎に、
こういう考え方がある事に、同意します。

って優香、情報工学の営みって、哲学と被り過ぎ。
実用的な情報工学だけでなく、こういう基礎的な分野と手を結ばないと、
本質的なブレークスルーは生まれない気がする...

943 ：デフォルトの名無しさん：02/02/24 17:11

OOはアムウェイなどのマルチまがい商法と共通点ある。

巧妙なだましだよ。

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

直接は関係がないけど読む価値はある
そういった程度のものでしょ。学者ですら
引用を控えるくらいなんだから、うち等が
そんなもの口にするときはどんな結論に
なるのか大体想像がつく。

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

>>943
相変わらず、どこが問題なのかの具体的な指摘はないのな。

946 ：デフォルトの名無しさん：02/02/24 17:20

>>941
意味論だと、数学よりはメタ数学（論理学、数学基礎論）だろ。

ただ、意味論をやって良いプログラムを設計できるようになるかというと、今の
ところはあまり関係ない。

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

>>943
非OOだってアムウェイなどのマルチまがい商法と共通点あるじゃん。

948 ：デフォルトの名無しさん：02/02/24 17:22

先生ぇー、オブジェクト指向のモデル論を、哲学の認識論と結び付けてしまうと、
認識の相違の数だけ、異なったモデルが生まれてしまうと思うですけど、
どうやって皆の認識を統合したらよかとですかぁー？

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

共通感覚（ｗ

950 ：デフォルトの名無しさん：02/02/24 17:29

サブジェクト指向って、、

951 ：デフォルトの名無しさん：02/02/24 17:31

>>948
だから道徳を習うんだ。
思いやりは大切です。

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

共時性？

つうか、一つの対象に複数のモデルがあって、
それをアナパタ本の多重分類/動的分類問題とか、
多重世界仮説みたいな問題として捉えた場合に、
どうやって解決しようか？っつう事なんですが...

953 ：デフォルトの名無しさん：02/02/24 17:34

>>949 まあ、それでよいのかな、利害対立がない場合は...

954 ：デフォルトの名無しさん：02/02/24 17:37

なにげに940は的を得た意見かも

955 ：デフォルトの名無しさん：02/02/24 17:39

>>940,>>954 協調性ですか

956 ：デフォルトの名無しさん：02/02/24 17:45

>>954
的を持っていくなよ。元の場所に戻しとけ。

957 ：デフォルトの名無しさん：02/02/24 17:47

>>952
非 OO の設計手法を使っても、人によって異なる設計が得られるけど。

958 ：デフォルトの名無しさん：02/02/24 17:57

boochとかアナパタ本の作者は人文系の本も
相当よんでるのか？それとも建築関連とか
あくまで工学の範疇のものを読んでるのかな？

俺らには関係ないか。

959 ：デフォルトの名無しさん：02/02/24 17:57

>>957 そですね。
単純なコーディングなら、「必ず同じコードになる」つうのが自慢な言語もあるそうですが、
問題解決、分析設計だと、担当者毎の個体差が激しそう...。

>>952 について、漏れはこういう感じ。
複数のモデル間を、mediatorで結び付け、
モデル間の矛盾の解決をmethodを追加する。
でも、問題解決/矛盾解決の方法は、千差万別という気がする...

960 ：959：02/02/24 18:00

>>959 あれ、文が変だ...
○モデル間の矛盾や、その原因となっている問題を解決するmethodを追加する。
×モデル間の矛盾の解決をmethodを追加する。

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

既にジスレノ時期。
まだこのスレタイトルでやるんですか？
でもまともなタイトルだと人があつまらないんだよな（藁

962 ：959：02/02/24 18:10

お任せします。とってもきゃっちーなタイトル、考えてください。

963 ：デフォルトの名無しさん：02/02/24 18:23

OO信者は禿げ

964 ：デフォルトの名無しさん：02/02/24 18:27

>>956
初めて見るタイプのツッコミだ。ﾜﾗﾀﾖ｡

965 ：デフォルトの名無しさん：02/02/24 18:46

>>963 禿げじゃないもん。あ、信者じゃないからかぁ(ｗ

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

stroustrupとかbooch,Fowler。
なんか禿げてる人おおくないですか？
デニスリッチーなんてもっと歳いってるのに
ふさふさのカッコいい男優みたい。

967 ：デフォルトの名無しさん：02/02/24 18:57

次スレ
【オイル】オブジェクト指向やると禿になっちゃうの？【セクシー】

968 ：デフォルトの名無しさん：02/02/24 19:04

スレ立てよろぴく！

969 ：デフォルトの名無しさん：02/02/24 19:06

いいんかよぉぉぉーーー、ホントにそれでー？(叫

970 ：デフォルトの名無しさん：02/02/24 19:11

他になんかいいのある？

971 ：デフォルトの名無しさん：02/02/24 19:19

オブジェクト指向を勉強始めると
とめどなく本を買うことを迫られるからやだな。
なんかOO詐欺に引っかかった気分。
おれなんてもうそれ関連で20冊近く本買ったよ。

972 ：デフォルトの名無しさん：02/02/24 19:20

だめっすよね、こんなんしかかけなかった。ここのキーボード壊れてるし..

神秘系：
【神秘】オブジェクト指向の道【東洋思想】

宗教系：
【能天気】私オブジェクト指向で幸せなになれました【信仰告白】

見下し系：
今時オブジェクト指向使えないｳﾞｫｹ共へのメッセージその→

973 ：デフォルトの名無しさん：02/02/24 19:26

祭り＆ヒス系：
【祭】私を騙したオブジェクト指向信者、訴えてやります、ｷｨｰ【祭】

＃そーいえば、永田町方面の田中真紀子先生祭り、盛り上がってましたね。
＃田中先生ってば、エンターテインメントなんだからぁー。

974 ：デフォルトの名無しさん：02/02/24 19:28

【ムネオ】OO*は地雷原【ハウス】

975 ：デフォルトの名無しさん：02/02/24 19:45

>>974 キャッチーだけどネタスレにしか見えんのよね、、、
って所詮ネタスレだけど(笑

976 ：デフォルトの名無しさん：02/02/24 19:53

タイトルはおまかせしました。
早く次スレたててくだちい。

977 ：デフォルトの名無しさん：02/02/24 19:54

つーか、うざいからもういいよ。
粘着アンチがまた適当にスレ立ててくれるだろ

978 ：デフォルトの名無しさん：02/02/24 20:00

じゃぁ、アンチOOスレはもう終了って事で。さいなら。

979 ：デフォルトの名無しさん：02/02/24 20:13

#bye all

980 ：デフォルトの名無しさん：02/02/24 20:56

駄留馬参我古論駄

981 ：デフォルトの名無しさん：02/02/24 21:19

結局戦場ではOOどころかPGは何の役にも立たないという事ですか？

982 ：デフォルトの名無しさん：02/02/24 21:23

戦場では客をなだめる才能のあるものだけが
必要とされます。そこまで逝ってしまっては
もう既に手遅れなのです。

983 ：デフォルトの名無しさん：02/02/24 22:49

アナリシスパターンって何？

984 ：デフォルトの名無しさん：02/02/24 23:16

>>982
客によっては挨拶するだけで怒号・・・
バグ修整するだけで罵倒・・・
電話掛けるだけでイヤミ・・・
そんな客をなだめつつまともな話が出来る人は
戦場では必須だね(ｗ

985 ：デフォルトの名無しさん：02/02/24 23:33

「おれより頭がいいやつは全員氏ね」
って書けよ。すっきりするぞ。クズども。

986 ：デフォルトの名無しさん：02/02/24 23:36

>>985
おまえだけは書かないでね。地球上の9割が死ぬから。

987 ：デフォルトの名無しさん：02/02/24 23:39

たった一人になっちまう

988 ：デフォルトの名無しさん：02/02/24 23:41

そして誰もいなくなった

989 ：デフォルトの名無しさん：02/02/24 23:51

>>983
書籍のタイトル。

990 ：デフォルトの名無しさん：02/02/24 23:56

で、パート3のタイトルは決まった？

991 ：デフォルトの名無しさん：02/02/25 00:05

新スレ「オブジェクト指向は戦場では必要なし - おれより頭がいいやつは全員氏ね」

992 ：デフォルトの名無しさん：02/02/25 00:05

スレッド.終了()

993 ：　：02/02/25 00:09

　　　　 ┌―─┐
　　　　 │　╋ │
┌──―┘ 　　 └─―─┐
│　 Ⅲ　　　　　　　 Ⅲ　　　| ＜ｼﾝｼﾞﾙﾓﾉﾊ　ｽｸﾜﾚﾙｰ～♪
｜　　　ＯＯ真理教　　　　　|
│　　　 ┌―┬―┐　　　　 |
｜　　　　|。　｜。　|　　　　　|　　　　　　　ｳﾜｱｧｰｰｰｰｰﾝ
┴―‐―┴―┴─┴ｰ―─┴ 　ヽ(　TД)ﾉ　ｺﾝﾅﾄｺﾓｳｺﾈｪﾖ!!
　　　　　　　　　　　　　　　　　　　　（　）　　　　ｳﾜｧｧｧﾝ
　　　　　　　　　　　　　　　　～　　/　ヽ

994 ：デフォルトの名無しさん：02/02/25 00:10

前にいつだったかニュー速板に
オブジェクト指向のスレが立ったのにはわらった

995 ：デフォルトの名無しさん：02/02/25 00:20

「信じるものは足すくわれる」

996 ：デフォルトの名無しさん：02/02/25 00:20

このスレが1000までのびるとはおもわなんだ。

997 ：デフォルトの名無しさん：02/02/25 00:20

つーかこのスレ Part2なんだが....

998 ：デフォルトの名無しさん：02/02/25 00:21

1000とった派が勝ちという事にしよう

999 ：デフォルトの名無しさん：02/02/25 00:23

1000

1000 ：　：02/02/25 00:24

新スレ「オブジェクト指向は戦場では必要なし - 詐欺はやめよう」

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。