やっぱりオブジェクト指向は幻想でした。

このエントリーをはてなブックマークに追加
1 ：デフォルトの名無しさん：
オープンソースプロジェクトの成功率

C++を採用したプロジェクト→20.8%
JAVAを採用したプロジェクト→20.6%
Cを採用したプロジェクト→45.13%

はっきり言ってオブジェクト指向が生産性を
高めるなんて、幻想です。
みなさん、オブジェクト指向なんて浮ついたものに踊らされてないで
Cに回帰しましょう。

http://www.gyve.org/~jet/lang2.txt
2 ：デフォルトの名無しさん：01/10/23 14:46
マ板で相手にされないからってこっちくんなよ。

/***** 終了 *****/
3 ：デフォルトの名無しさん：01/10/23 14:48
どうぞ御勝手に。
------------終了---------------------------------
4 ：デフォルトの名無しさん：01/10/23 14:53
>>1
さっさと氏ね
------------終了---------------------------------
5 ：デフォルトの名無しさん：01/10/23 15:35
>>2-4
ﾜﾗﾀ
------------終了---------------------------------
6 ：デフォルトの名無しさん：01/10/23 15:44
終了処理は一回でいいぞ。
7 ：　：01/10/23 16:05
>>1
貴重な資料をありがとう。
これで堂々とOO厨を駆逐出来ます。
8 ：デフォルトの名無しさん：01/10/23 16:08
APL 1.0
Perl 0.5164
Tcl 0.465
C 0.4513

Cを勧めているとは、とても思えないけど、その資料によると
9 ：デフォルトの名無しさん：01/10/23 16:09
結論は関数言語ﾏﾝｾｰということでよろしく
10 ：デフォルトの名無しさん：01/10/23 16:24
>>8
APLやらC#はサンプルが少なくて、極端な結果になってると思う。
なんだかんだいっても、PerlやCのような泥臭い言語のほうが
多人数で開発する場合には、力を発揮しやすいんでしょう。
11 ：8：01/10/23 16:43
あー、なるほどね。
Objective-C＞C++は、まあ納得だけど、
Objective-C＞Lispとなっていて、あれ？
とか思う部分もあるし。
サンプル数が少なすぎて統計になってないってこったな
12 ：デフォルトの名無しさん：01/10/23 16:44
上流工程を担当している人間が無能なだけじゃないの？
13 ：デフォルトの名無しさん：01/10/23 16:49
オブジェト思考は、机上の空論
14 ：デフォルトの名無しさん：01/10/23 16:58
ワケわかんねぇ「幻想的な案件」が
自然とOO方面に逝くってﾀﾞｹじゃないの？
15 ：デフォルトの名無しさん：01/10/23 17:57
>>14
同意。
今どき流行の（よくわかってもいない）あれとこれとそれを
全部入れたりすれば潰れるのもやむなし。
16 ：デフォルトの名無しさん：01/10/23 19:14
Delphiが、成績悪いのが納得いかん。
17 ：デフォルトの名無しさん：01/10/23 21:28
「おまえ、オブジェクト指向言いたいだけちゃうんかと。」
18 ：デフォルトの名無しさん：01/10/23 21:49
>>1
がいしゅつです
http://slashdot.jp/article.pl?sid=01/09/22/109245&mode=thread&threshold=
19 ：デフォルトの名無しさん：01/10/23 21:51
ていうか、「freshmeatでアナウンスされたプロジェクト」って
正確にはどんなプロジェクトがアナウンスされるんだよ？
何か条件は無いのか？
「sourceforgeに登録されているプロジェクト」ってなんだ？
どういう手続きを踏んだプロジェクトなんだよ。

この作者自体理解しないまま計算してそうだな。
だいたい、分母が0の言語あるとか言ってる時点で怪しすぎる。
20 ：デフォルトの名無しさん：01/10/23 22:02
>>19
著者はわかってると思うぞ。
君が sourceforge や freshmeat を知らないだけで。
分母が 0 についてはちゃんと書いてあるし。
21 ：デフォルトの名無しさん：01/10/23 22:58
>>20
いや、いいかげんと言ってるところからも、著者はわかってないと思われ。
分母が0についても、あの説明の通りだとすると、sourceforgeになくて、
freshmeatにあるプロジェクトがあることになり、この二つを比べることに
意味が無くなってしまう。
22 ：デフォルトの名無しさん：01/10/24 00:21
>>21
別に意味なくなりはしないだろ。

最初からあくまでも目安みたいなもんだし、
その基準に sourceforge と freshmeat を使うのは
いいアイデアだと思うが。
23 ：デフォルトの名無しさん：01/10/24 01:34
sourceforgeとfreshmeatだとC勢優位で当然だよな。
C厨とジジイ大喜びだね。ふふ。

俺はUNIXでC++が好きだから複雑な気分だな。
24 ：名無しさん＠ＸＥｍａｃｓ：01/10/24 01:51
あっ俺sourceforgeにjavaと、C++のプロジェクト1つづつ
登録してるや。なんにもしてないし、始める気は全くない
から、分母から引いといてくれ。
25 ：デフォルトの名無しさん：01/10/24 02:26
>>22
どこがいい目安なんだよ。
言語によっては分母0なんてあるんだし。
めちゃめちゃ有利不利な条件があるってことを示してるだろ。
全く信用できんよ。
26 ：デフォルトの名無しさん：01/10/24 02:34
Windowsをサポートしてるプロジェクトだけ拾って統計とったらどうなる？
だれかやってみない？
#純粋に興味本位
27 ：デフォルトの名無しさん：01/10/24 02:35
age
28 ：22：01/10/24 03:11
>>25
「いい目安」なんて言ってませんよ。
「あくまでも目安」って言ったの。

この手のものを作ろうとしても、あまり元になるデータがない。
そこで sourceforge と freshmeat を使うってのは
いいアイデアだと思っただけ。

確かに
> プロジェクトを失敗に導くプログラミング言語
という意味では、信頼性はまったくないがな。
29 ：デフォルトの名無しさん：01/10/24 03:16
>>28
だから、いいアイデアとはとても思えんが。
30 ：デフォルトの名無しさん：01/10/24 03:16
目安にもならん。
31 ：デフォルトの名無しさん：01/10/24 03:18
単に上位にきている言語使いが擁護して
下位の言語使いが必死に批判してるだけじゃねーの？
32 ：デフォルトの名無しさん：01/10/24 04:32
統計は常に何らかの偏りがあって
完全に信用できる統計などあるはずがない

だが、このデータを否定するのなら
「何故信用できないのか」「代替として出せるデータがあるのか」
を語って欲しいものだ

つまり躍起になって否定するのも見苦しい
33 ：デフォルトの名無しさん：01/10/24 04:33
それ以前に 1 のリンク先の文書はジョークじゃないのか？
34 ：デフォルトの名無しさん：01/10/24 04:34
このスレまだやってんの？
35 ：デフォルトの名無しさん：01/10/24 04:54
Delphiのオープンソースプロジェクトってどんなのがあるのですか？
>1を見る限り、成功率は低いですが。
36 ：ノボリトの名無しさん：01/10/24 05:32
はなげつんつん
37 ：デフォルトの名無しさん：01/10/24 08:07
>>32
分母が0があるから信頼できないし、登録される条件が明確でないから
信頼できないと言ってるのに･･･
それでも信頼できるとのたまう姿が見苦しい。
38 ：デフォルトの名無しさん：01/10/24 08:33
>37
そういうことを言う奴は
どんなデータが出てきても
「統計の取り方がおかしい」
と文句言うんだろうな

オレが言いたいのは
どんなデータでもそれにはそれの意味合いがあるのだから
その意味合いを語ってくれということ
文句言うだけなら誰でもできるし
盲信することも誰でもできる

つまり、何故このようなデータが出てくるのか解説してくれということ
39 ：デフォルトの名無しさん：01/10/24 08:41
>>38
ていうか、明らかにおかしいじゃん。
このチームは0試合中10勝だとか言ってるようなもんだもの。
40 ：デフォルトの名無しさん：01/10/24 08:43
このデータには「統計の取り方がおかしい」という意味合いがあります。（ｗ
41 ：デフォルトの名無しさん：01/10/24 09:21
分母０ってのは、プロジェクトの開始を告知せずに
完成したときだけ告知したってプロジェクトがあるって事だろ。
別に、１の数字を全否定するほどのことじゃないと思うが？
42 ：デフォルトの名無しさん：01/10/24 09:27
そのデータには
「sourceforge に登録したが freshmeat でアナウンスされるほどに
できなかったユーザ、が多い言語」という意味合いがあります。

どちらかというと、言語自体よりもユーザ層の問題であると思われます。
43 ：42：01/10/24 09:30
そういう意味では、
現実的な思考をするユーザが多そうな言語、すなわち C, Perl などが
上位にくるのもうなずける気もします。
44 ：デフォルトの名無しさん：01/10/24 09:32
プロジェクトを成功させるのに言語はほとんど関係ない。重要なのは人だ。
だから成功させられる人ならCだろうがJAVAだろうが成功させるし、だめなやつは何使ったってだめだ。
この統計が示しているのは
・プロジェクトを成功させられないへたれはOOPLを開発言語に選ぶ可能性が高い
ってことだ。(登録して何もしないやつも含む)
45 ：42：01/10/24 09:33
というか C++ や Java のユーザはより困難なプロジュクトに
挑戦する傾向があるだけかもしれません。
46 ：44：01/10/24 09:35
かぶった…
47 ：42：01/10/24 09:38
困難なプロジュクトに挑戦しようとする人が
C++ や Java を選ぶのかもしれませんが。
48 ：デフォルトの名無しさん：01/10/24 09:42
>>41
そうじゃなくて、sourceforgeに登録していないのに、
freshmeatでアナウンスされるプロジェクトがあるってことだろ。
sourceforgeに登録された*中で*freshmeatでアナウンサされた
プロジェクトなら何かの意味があるかもしれないが、
>>1の数字はそれを無視しているので、
単なるfreshmeat / sourceforge という意味の無い数字。
49 ：デフォルトの名無しさん：01/10/24 09:45
> 意味の無い

いや、無くはないと思うが。(←しつこい)
50 ：　：01/10/24 10:16
この中でうなづけそうな感じなのは、
c,perlだな。
他のは、母集団の選択が不適切。
そう言うのは統計の仮面をかぶったある種の主張に成りかねない。
51 ：デフォルトの名無しさん：01/10/24 10:31
俺はVBの1%とDelphiの4%もすごくうなずける。

厨房外人がノリだけで何の計画性もなく
プロジェクトをバンバン立ち上げて、
99%は立ち消えになってる様は目に浮かぶようだ。
52 ：デフォルトの名無しさん：01/10/24 10:59
だーかーら、
"index of Unix and cross-platform open source software"
な freshmeat と、プラットフォーム不問の sourceforge を
比べてもしょうがないでしょ。
承知で言ってるんだろうけどさ。
53 ：デフォルトの名無しさん：01/10/24 13:04
オープンソースって書いてあるだろ。
よく読めや。
ここはアホな学生しかいないのか？
氏ねや。
54 ：デフォルトの名無しさん：01/10/24 13:12
つーか、>>1のリンク先はネタでしょ。出来の悪い。
55 ：デフォルトの名無しさん：01/10/24 13:13
(´-`).｡ｏＯ（53 は誰に言ってるんだろ？）
56 ：デフォルトの名無しさん：01/10/24 13:42
>>55

このスレにマジレスしてるやつ全員だよ。
57 ：デフォルトの名無しさん：01/10/24 18:10
>>42
全否定するほどの意味だよ。
だって、0.4と0.2の差なんてそうした、分子だけのプロジェクトの
有無だけで変わるから。
58 ：デフォルトの名無しさん：01/10/25 02:34
>>57
でも、ある言語に有利に働き、ある言語に不利に働くってわけでもないよね。
59 ：デフォルトの名無しさん：01/10/25 06:00
>>58
そうでもないだろ。分母が0のものがあるんだからな。
特定言語に有利に働いてる可能性がかなり高い。
それに、完全にランダムに働くとしても、分母が少なければ
誤差の大きいインチキ統計となる。
60 ：現実を直視しろ：01/10/25 19:31
気持ちはわかる。
せっかく身に付けたOOが実はなんの役にも立たない代物だった
なんて、認められないよな。
でも、世界中のプログラマが気づき始めてるよ。
ＯＯが、すたれゆく技術だってコトを。
61 ：デフォルトの名無しさん：01/10/25 20:03
俺もＯＯにはちと疑問。
でもＯＯ使えと言われりゃ使うよ。
そんなもんでしょ。
62 ：デフォルトの名無しさん：01/10/25 20:05
>>60
いや、お前こそ現実を直視しろよ。
とっくの昔に世界中のプログラマがＯＯが役に立つと
気付いてんだよ。（ｗ
わけのわからん馬鹿統計ですらよりどころにしたい気持ちは
わかるが。
63 ：デフォルトの名無しさん：01/10/25 20:08
今更オブジェクト指向がなんの役にも立たないと
主張するやつがいるなんて…
なんて低レベルなんだ。
64 ：デフォルトの名無しさん：01/10/25 20:25
>>60
せっかく身に付けた、という感じの技術者は減少傾向に
あると思われ。むしろ非OO言語で書けといわれると発狂
する奴の方が増えるのは自明。
65 ：デフォルトの名無しさん：01/10/25 20:30
>60
ｹﾞﾗｹﾞﾗ
66 ：名無しさん：01/10/25 20:34
ＯＯのあとには何がくる？
67 ：デフォルトの名無しさん：01/10/25 21:06
つうかＯＯってなんですか？
68 ：デフォルトの名無しさん：01/10/25 21:07
○○　→　エロ
69 ：デフォルトの名無しさん：01/10/25 21:10
これからはRubyの世の中になる。いや、マジで
70 ：デフォルトの名無しさん：01/10/25 21:13
OOが嫌いでたとえば構造化設計が良いと思ってもいいじゃないですか。
良質なモノが速くできるのならば。と思いますがなにか？
71 ：デフォルトの名無しさん：01/10/25 21:20
>>64
そりは、たぶんあなたの周囲の優秀な方たちだけでしょう。
オブジェクト指向が話題になりはじめてから、はや十数年。
それなのに「つうかＯＯってなんですか？ 」というPGは
世にあふれてます。
あと１０年たっても、オブジェクト指向言語で、
オブジェクト指向でないコードを書いてるプログラマは半分
以上の割合で存在してるものと思われます。
72 ：デフォルトの名無しさん：01/10/25 21:22
こんなスレが長持ちするなんてよっぽどネタも尽きたってことだな
73 ：デフォルトの名無しさん：01/10/25 21:37
>>71
そういう低レベルプログラマは収入も平均以下のまま。
つーか生き残り最低レベルもクリアできるかどうか。
消えてけ。
74 ：逝って良しの１：01/10/25 21:59
まだＯＯで革命ごっこですか？
往生際が悪いですな。
75 ：デフォルトの名無しさん：01/10/25 22:00
つーかオブジェクト指向だろうと構造化でもどっちでもいいけど
片方を必要以上に批判する奴は間違いなく厨房だね。
ＯＳ，言語を必要以上に批判する奴もね。
76 ：デフォルトの名無しさん：01/10/25 22:16
まともにオブジェクト指向で設計やプログラムできる
技術者は少ないってよく言われるね。
何が原因ですか？

教育環境が整備されてないから？
オブジェクト指向って多くの技術者には難しすぎるから？
77 ：デフォルトの名無しさん：01/10/25 22:22
真面目な話オブジェクト指向は設計者には合理的だが
実際にコーディングするにはちと向いていない気がする。
78 ：デフォルトの名無しさん：01/10/25 22:23
OOの次はOO7だろう。
79 ：デフォルトの名無しさん：01/10/25 22:45
>>59
まあ、APL とかサンプルの少ない言語はアレだけど
C や Java とかメジャーな言語は、数千のサンプルがあるんだし
どちらかに有利に働いてるとか無いと思うが。
80 ：デフォルトの名無しさん：01/10/25 23:18
>>79
アホか。母集団が違うだろが。
「Ｃプログラミング経験１０年以上」なんてごろごろいるが、
Ｊａｖａだとゼロだぞ？
81 ：デフォルトの名無しさん：01/10/25 23:22
へー、Ｊａｖａって習得するのに何年も掛かるんだ。
じゃ、採算合わないじゃん。
82 ：デフォルトの名無しさん：01/10/25 23:22
>>80
「C プログラミング経験10年以上」で
Java を使ってる人もごろごろいるかもよ。

つか、君の理論だと、このネタに関係なく
Java と C に差があるような感じだな。
83 ：デフォルトの名無しさん：01/10/25 23:24
>>80
つか、「母集団」の使い方が間違ってる。
84 ：デフォルトの名無しさん：01/10/25 23:26
>>82
いる「かも」知れんが同じ数じゃないだろう。
何コンマ何パーセントなんていう数字を比べるときに
そんないい加減な比べ方して何の意味がある？
85 ：デフォルトの名無しさん：01/10/25 23:29
>>1
の母でございます。
86 ：デフォルトの名無しさん：01/10/25 23:31
>>84
統計数字の見方を知らないだけ。
87 ：デフォルトの名無しさん：01/10/25 23:33
>>80 >>84
つまり、Java プログラマよりも C プログラマのほうが優秀な人が多いと?
88 ：デフォルトの名無しさん：01/10/25 23:34
数千のオープンソースプロジェクトを調べました。

Cのプロジェクトの成功率は約45%
C++,Javaのプロジェクトの成功率は約20%

(*´д`*)
89 ：デフォルトの名無しさん：01/10/25 23:37
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

万逝ってるよ。
90 ：デフォルトの名無しさん：01/10/25 23:43
>>87
あるいは言語の生産性の差か。
91 ：デフォルトの名無しさん：01/10/25 23:45
オプソやるのは窓際Cヲヤジが多いってだけだろ
92 ：デフォルトの名無しさん：01/10/25 23:47
窓際Ｃヲヤジの方が使えると言う事の証明という意味ですか？

ＪａｖａやＣ＋＋はもっとヲヤジだった説ですか？
93 ：デフォルトの名無しさん：01/10/25 23:52
というか、まあ、オブジェクト指向の設計が難しいだけな気もするな。
それを巧くやれる人が少ないっていう話。
94 ：デフォルトの名無しさん：01/10/25 23:57
難しくて成功率半分ですか。
95 ：デフォルトの名無しさん：01/10/26 00:01
まぁJavaプログラマよりＣプログラマの方が優秀な人が多いのは言うまでもないだろ
96 ：デフォルトの名無しさん：01/10/26 00:03
>>93
>「設計が難しいだけな」

難しくて、使いこなせる人が少ない。
↓
生産性を高める手法としては失敗してる。

オブジェクト指向破綻説に一票。
97 ：デフォルトの名無しさん：01/10/26 00:04
>>95
その論法で逝くとPerlプログラマのほうがCプログラマよりも
優秀というわけだな。(w
98 ：デフォルトの名無しさん：01/10/26 00:04
>片方を必要以上に批判する奴は間違いなく厨房だね。

構造化とOOはキリスト教とイスラム教の関係だ。
イスラム教でもキリストは「ムハンマドの1つ前のバージョンの」史上2位の預言者
としてあがめられているぞ。

構造化をさらに(ルーチンだけじゃなくデータだけでもなく両方の統合という形で)
徹底させた最終バージョン、それがOOだ！

注：ムハンマドが「最終バージョン」である、という主張は、あくまでイスラム教のもの。
数百年後に更に次を名乗る宗教が出るかも知れない。いや、明日にでも。

というわけでOOに文句の有る奴は、OOを"取りこんで"、更に先をいく方法論を、作りなさい。
99 ：デフォルトの名無しさん：01/10/26 00:08
なんかいっぱいオチコボレが釣れてるね。
何を作ったか、が議論されてないんだからネタだがや。
100 ：デフォルトの名無しさん：01/10/26 00:10
>>99
ＯＯ信者の脳はその程度ですか？
さらしあげ。
101 ：デフォルトの名無しさん：01/10/26 00:14
ttp://www.os-omicron.org/~takano/private/trans/bongo-bong_j.html
102 ：デフォルトの名無しさん：01/10/26 00:15
ＯＯ信者の脳の中では階級図が出来あがっているようです。
もちろん自分が上位ｗ
オウム信者が抜けたがらないのと同じねｗｗ
103 ：デフォルトの名無しさん：01/10/26 00:17
>>101
何かの罠らしい。開いちゃ駄目。
104 ：デフォルトの名無しさん：01/10/26 00:18
例の化石のようなおっさんのレスばかり……。
105 ：俺もなー(*´Д`*)：01/10/26 00:23
>>104
こういう一行レスも多いな。
106 ：デフォルトの名無しさん：01/10/26 00:28
>>103
>>101はブラクラじゃなかったけど、
『Unixをもう少しマシなものにしよう』
↑なんだコリャ？
107 ：デフォルトの名無しさん：01/10/26 00:28
ていうか、オブジェクト指向がどういうものか多少理解してるなら
オブジェクト指向が役に立たないなんて言い出す可能性は限りなく０に
近いと思うが。
108 ：デフォルトの名無しさん：01/10/26 00:30
役に立たないとは言わないが、成功率を半分にするという事は
肝に銘じておけ。
109 ：デフォルトの名無しさん：01/10/26 00:30
>>107
はげしくどうい

でも、やっぱり設計は難しい…。
110 ：103：01/10/26 00:31
>>106
現在ウイルススキャン中なり。
111 ：デフォルトの名無しさん：01/10/26 00:33
「OO信者」とか「生産性」とかNGワード連発ですぅ。
このタームを使うのはアノ人ですね……。
112 ：デフォルトの名無しさん：01/10/26 00:41
>>101
w3mで見る限り立派な文章だけど？
C-Dogはしっかり読めって感じの。
[訳4]とかイイね。
なお、おれはUNIX屋です。
113 ：112：01/10/26 00:47
>>112
パイプとCしかしらないオッサンは

>人々は Microsoft を「大きくなりすぎたモノリシックアプリケーショ
>ン」を生産する理由で批判することが好きである

:
:

>今，再び Microsoft の「大きくなりすぎたモノリシックアプリケーション」
>である「Internet Explorer」を見てみよう．
>
>Internet Explorer はあなたが考えるかもしれないように単一の実行可能モ
>ュールではない．

のあたりを良く読め的。
114 ：デフォルトの名無しさん：01/10/26 00:54
>>107
そういう物言いが、信者とからかわれる原因だと思われ。
115 ：デフォルトの名無しさん：01/10/26 00:56
>>104
まあそう言うな若造よｗ
何時の時代でも飛びついた新思想が実はインチキだったなんて事が
あるのさ。
まあ、引っかかるのはアホな若造だけであって若いの全部が引っかかる
わけではないがなｗ
116 ：デフォルトの名無しさん：01/10/26 00:56
>>112
てゆーかIEでも問題ないよ

>>106
なんじゃって言われてもなあ、GNOME作った人の文章だからねえ。

Unixの「部品化方式の古さ(Pipes In GUI's ね)」や「拡張の指標となるメタモデルの不在
(だからみんながばらばらに作業しちゃう。バザールという免罪符の下で)」を嘆いたからこそ、
そういうGNOMEを作ったし、あーいう文章も書いたし、つまりそういうこと。

なお原文がNotFoundなのは、GNOMEまんせー会社のHelixCode社が
倒産してしまったから、だと思われ(苦笑
きっとどっかにミラーが有るよ。頑張って探すよろし。
117 ：デフォルトの名無しさん：01/10/26 00:56
おいおい、fleshmeatはクロスプラットフォームだろ･･･
互換性の問題から、Cがクロスプラットフォームに偏るのは当然だろ。
それにC#が0％なのは当たり前だろ。
118 ：デフォルトの名無しさん：01/10/26 00:58
>>115
で、結局OO覚えたのか？おっさんよ
119 ：デフォルトの名無しさん：01/10/26 01:00
>>115
まあ、わからないものに対して妄想を膨らませるのは結構だけどさ、
ちょっとは内容みてから判断しようね。
120 ：デフォルトの名無しさん：01/10/26 01:03
たしかに、SourceForgeとfleshmeatの条件の違いを無視してる時点で
インチキだな。
121 ：デフォルトの名無しさん：01/10/26 01:05
>>115
今どきOOを流行りものとか新しいと感じるのはコボちゃんぐらいじゃないのか？
若造じゃなくてもほとんどのプログラマにとっては構造化プログラミングも
構造化設計もOOA/OOD/OOPも同じくらい古くて当たり前の技術なんだが？
122 ：デフォルトの名無しさん：01/10/26 01:06
難しい言語は、少数の人しか使えないから、どちらかというと
個人使用されていて、それゆえに小粒なプログラムが多く、
fleshmeatでいちいちアナウンスメントされないって説はどうよ？
Cは一番使える人が多いから、多人数でやるビッグプロジェクトに都合がいい。
123 ：112：01/10/26 01:06
つまんねえ議論だなぁ。
ジジイ無理にひっぱりあげてもパイが減るだけだ。放置しようぜ。ほんと。
124 ：デフォルトの名無しさん：01/10/26 01:09
>ほとんどのプログラマにとっては
>OOA/OOD/OOPも同じくらい古くて当たり前の技術なんだが？
この板見てるととてもそうは思えないが...
125 ：デフォルトの名無しさん：01/10/26 01:09
>>121
それって本当ですか？
会社の取引先の東芝の社員はOOできないっぽいっすよ。
その部署全員が。
126 ：デフォルトの名無しさん：01/10/26 01:11
んなもん2chを基準に語るなよ。
127 ：デフォルトの名無しさん：01/10/26 01:12
俺の出向先でも理解している奴見たことないぜ
128 ：112：01/10/26 01:14
ウオッシュレット愛好者とソレ未経験者の議論のようだな。
べつにソレ未経験者をどうこうする気はないが、ついてない
便所でクソしたくない。あくまで俺はな。

#戻れない、ってのはどんな世界にもあるのよ。
129 ：デフォルトの名無しさん：01/10/26 01:14
俺の勤務先には少なくとも５人いた。
一人は周りがアフォすぎて辞めた。
130 ：デフォルトの名無しさん：01/10/26 01:14
あえて使ってないのを「理解してない」と罵る信者ウザイ。
131 ：デフォルトの名無しさん：01/10/26 01:14
ＯＯのできる技術者が少ないって話も良く聞くね。
Javaでコーディングはできても、ぜんぜんオブジェクト指向じゃ
ないとか。
132 ：デフォルトの名無しさん：01/10/26 01:15
いいえ、あえて理解しようとしてないのです。
133 ：デフォルトの名無しさん：01/10/26 01:15
あえて
あえて
あえて
あえて
あえて
あえて
あえて
ﾌﾟﾌﾟﾌﾟｯ
134 ：デフォルトの名無しさん：01/10/26 01:16
まあ、あれじゃん？
ようするに、「素人にはお勧めできない」って一言に尽きると思うんだよね。
使いこなせると強力な武器になるが、使える人は少ない。
135 ：デフォルトの名無しさん：01/10/26 01:17
こうしてプログラマの格差が広がっていくだけなのであった。
136 ：デフォルトの名無しさん：01/10/26 01:18
>>131
ＯＯにして効率上がりそうなネタはそうそう見つかるものではないのです。
137 ：デフォルトの名無しさん：01/10/26 01:18
ＯＯできるプログラマ寄りのＳＥが一人でもいれば
あとはなんとかなるもんさ。
プログラマの自由度は減るかもしれんがな。
138 ：112：01/10/26 01:19
>>132
声出して笑った。
139 ：デフォルトの名無しさん：01/10/26 01:19
そして信者は自分が上だという幻想に浸るのであった。
その宗教の中でしか通用しない階級であることを自覚せよ。
140 ：神：01/10/26 01:19
>>136
お前に、「デザインパターン」という言葉を授けよう。
今すぐデザインパターンの本を読め。それがお前の義務だ。
141 ：OO否定教教祖：01/10/26 01:21
>>139
おぬしこそオブジェクト指向否定宗教の信者であることを自覚せよ。
142 ：デフォルトの名無しさん：01/10/26 01:21
>>140
なんで俺が教義読まなきゃならんのだ？
143 ：ＯＯ技術者不足：01/10/26 01:21
http://www.asahi-net.or.jp/~ki4s-nkmr/wabijo46.html

>　Javaの開発者はいますごく不足しています。少なくとも東京近辺ではという
>か、ぼく近辺では。それから、ちゃんとオブジェクト指向で分析設計できる人
>も不足しています。
144 ：デフォルトの名無しさん：01/10/26 01:22
>>142
やっぱり理解しないまま批判してるんだな･･･
145 ：デフォルトの名無しさん：01/10/26 01:22
日本の技術レベルはチンカス
146 ：デフォルトの名無しさん：01/10/26 01:23
>>143
へぇ。じゃあ、今JavaとOOを覚えたらウハウハじゃん？
147 ：デフォルトの名無しさん：01/10/26 01:24
あたりめーだ、ＯＯで設計してたら時間がいくらあっても足りないし
仕様変更の事考慮したら使えねえじゃん。
148 ：デフォルトの名無しさん：01/10/26 01:24
なんつーか、レベル低う。
いや確かに、「構造化プログラミング」の良さをなかなか
理解できなかった人もいたらしいが…
149 ：デフォルトの名無しさん：01/10/26 01:24
>>145
結論
150 ：デフォルトの名無しさん：01/10/26 01:24
>>140
「デザインパターン」もまた普及しにくい技術なんだよね。

厳しい修行に耐えた信者しか使えないオブジェクト指向
151 ：デフォルトの名無しさん：01/10/26 01:26
まさにRubyの置かれた状況
152 ：デフォルトの名無しさん：01/10/26 01:26
結局のところ、上手く使えない奴の言い訳。
153 ：デフォルトの名無しさん：01/10/26 01:27
>>150
や、でもちょっと大規模なプロジェクト経験者なら
デザパタ読めば「うんうん、そうそう！」「なるほど納得！」でしょ。
一読しただけで、便利な本だとすぐわかる。
154 ：デフォルトの名無しさん：01/10/26 01:27
結論は、ＯＯに現世利益(生産性)を求めてはいけないってことで。
155 ：デフォルトの名無しさん：01/10/26 01:28
>>150
とても素晴らしい考え方なんだけどねぇ。
156 ：デフォルトの名無しさん：01/10/26 01:29
来世（保守コスト）で救いがあるのですか？
157 ：デフォルトの名無しさん：01/10/26 01:30
ええっ。みんなホントーにＯＯ使ってないの？
ネタじゃなかったの？

信じられん・・・
158 ：デフォルトの名無しさん：01/10/26 01:31
>>157
どうやらネタじゃないらしい。
OOの良さを理解出来ない人ってのは結構いるらしいな。
思ってたより人間は馬鹿なようだ。
159 ：デフォルトの名無しさん：01/10/26 01:32
いや、いるんだよそういう人々。
新しいものに触れることもなく
ただただいつもどおりの日常を送りつづけた人々が・・

たのむ、そのままでもいいけど人に迷惑をかけんでくれ。
160 ：デフォルトの名無しさん：01/10/26 01:33
いや部分的に使うよ。
でも変更が重なる度に崩れて行く・・・。
そして最後は糞コードの集大成を納品の現実。
161 ：デフォルトの名無しさん：01/10/26 01:34
夢の無い話ですが、ソフト開発は一部の「できる人」に頼る
時代はとうの昔に終わってます。
いくら性能が良くても、普及させるのが難しい道具では、
現場で使えません。

２ちゃんねるの方々は、現状を憂いつつ、自分のＯＯ技術が
生かせるハイレベルな職場でがんばってください。
(といいつつ私はＶＢのアイコンをクリックする)
162 ：デフォルトの名無しさん：01/10/26 01:35
>>160
それはおそらく使えてないな･･･
163 ：デフォルトの名無しさん：01/10/26 01:35
>>158
なにが良いか判らんが、成功率半分じゃねえ・・・。
趣味でやるなら良いけど。
164 ：デフォルトの名無しさん：01/10/26 01:36
まあ、小学生からプログラミングを教える時代。
これからはちょっとはレベル上がるだろ。
165 ：デフォルトの名無しさん：01/10/26 01:36
>>163
成功率半分ってまだ言ってたの？（藁
166 ：デフォルトの名無しさん：01/10/26 01:36
なぁ、OOを前提に作られていない仕様を無理矢理OOで実装するのはやめようよ...
167 ：デフォルトの名無しさん：01/10/26 01:37
道具は使い方が分からなければ役には立たない。
168 ：デフォルトの名無しさん：01/10/26 01:38
日本のレベルが低いって>>1の統計はアメリカのじゃないの？
169 ：デフォルトの名無しさん：01/10/26 01:39
ここのレスへのレスだろ。
170 ：デフォルトの名無しさん：01/10/26 01:39
OO理解してるやつが理解してない奴を細かく制御するのがベストなんだが、
理解してないのは(年功序列的に)扱いにくいジジイどもだったりするから
うまくいかないんだよな。ヒヒ。
171 ：デフォルトの名無しさん：01/10/26 01:39
>>168
>>1の統計は関係ないだろ。
しかも問題が散々指摘されてるし。
172 ：デフォルトの名無しさん：01/10/26 01:41
「俺は仕事が出来る」「俺はＯＯを理解してる」と自分で思ってる
人が集まって成功率半分だったということだな。
悲惨だな。
173 ：デフォルトの名無しさん：01/10/26 01:41
>>170
全員が理解してないと、どうしようも無いと思うが。
174 ：デフォルトの名無しさん：01/10/26 01:42
デザインパターンも５年前のもはや古い部類の技術だというのに・・
175 ：デフォルトの名無しさん：01/10/26 01:43
>>171
あんな素人丸出しの指摘じゃ、だれも納得せんよ。。。
176 ：デフォルトの名無しさん：01/10/26 01:44
少なくともコーダーは構造化程度の理解でいい。
重要な部分は設計で全部洗い出してしまえば。
177 ：デフォルトの名無しさん：01/10/26 01:44
>>172
おだい死に
178 ：デフォルトの名無しさん：01/10/26 01:46
>>176
うわ、ウォーターフォール時代の発想。
コーダーだってさ。
179 ：デフォルトの名無しさん：01/10/26 01:48
>>176
「完璧な設計が可能」という幻想をまだ持ってる？
だったらＯＯが理解できなくても無理はない。
氏の行進を続けてくださいな。
180 ：デフォルトの名無しさん：01/10/26 01:47
>>174
いや、昔からある技術なのに、普及しないのがオブジェクト指向の
ダメさ加減をあらわしてるんじゃないかってのが話の流れ。
181 ：デフォルトの名無しさん：01/10/26 01:48
>>175
いや、俺は納得したぞ。納得できない奴なんているの？
182 ：デフォルトの名無しさん：01/10/26 01:49
>>178
欲を言えば物理領域の設計もプログラマがやったほうが
いいんだがそこまで人が揃わんのだ｡
183 ：デフォルトの名無しさん：01/10/26 01:50
>>180
その理論はおかしいよ。飛行機を操縦できる人は
いまだに少ないかもしれないけど、飛行機が車より速いのは
自明。
184 ：デフォルトの名無しさん：01/10/26 01:50
>>182
XP
185 ：デフォルトの名無しさん：01/10/26 01:51
旧ソ連が崩壊したのも生産性がネックになってたから。
事の重大性を認識すべし。
言葉の遊びやってる場合じゃないんだよ。

ＯＯが巻き返すのなんか簡単。
実際に生産性上げて競合他社よりＸ割安い値段で仕事取りまくれば良い。
これを実行したら誰もＯＯに異論なんか唱えないよ。
186 ：デフォルトの名無しさん：01/10/26 01:51
Sorceforgeとfleshmeatでは条件が違うんじゃ、>>1の統計も
的外れだわな。
187 ：デフォルトの名無しさん：01/10/26 01:52
>>183
PC以前はプログラムの大半がCOBOLで書かれてたんだよ。
構造化言語ができてから何十年たっても。
それと同じだろう。まあいずれ普及するさ。
188 ：デフォルトの名無しさん：01/10/26 01:53
>>185
それでも異論唱えてる奴がいるんだよなあ。このスレに。(w
189 ：デフォルトの名無しさん：01/10/26 01:53
>>182
それは止めてくれ。
ハードは素人のソフト屋が口出して巧く行くもんじゃない。
190 ：デフォルトの名無しさん：01/10/26 01:53
日本のソフトがアメリカやインドに
勝てないのはＯＯ知らないからじゃねーの？
191 ：デフォルトの名無しさん：01/10/26 01:55
>>188
実行してたのかー。
192 ：デフォルトの名無しさん：01/10/26 01:55
>>190
まあ、たしかにアメリカで「OOは良くない」っていったら
爆笑されるかクビになるかだろうな‥
193 ：デフォルトの名無しさん：01/10/26 01:55
>>183
ＯＯが飛行機のパイロットなみに難しかったら、
それはＯＯが破綻してる証拠。
194 ：デフォルトの名無しさん：01/10/26 01:56
>>193
飛行機産業は破綻してませんよ？
195 ：デフォルトの名無しさん：01/10/26 01:56
>>192
本当か？信者がいるのは日本だけじゃない？
日経もセミナーもないし。
196 ：デフォルトの名無しさん：01/10/26 01:57
>>184
どういう意味？
コーダを２倍にしろと？
197 ：デフォルトの名無しさん：01/10/26 01:58
>>194
現在リストラの嵐ですが何か？
198 ：デフォルトの名無しさん：01/10/26 01:59
>>196
冗談だろ。
MSのソフトがOO使わずに書かれてると思うのか？
モジラやStarOfficeでさえあれだけ使ってるのに。
199 ：デフォルトの名無しさん：01/10/26 02:00
>>189
コーダーとＳＥの意思疎通が重要になってくる。
・・ＳＥがハードに詳しいならＳＥが組んだほうがいいのは確かだ。
逆もまた
200 ：198：01/10/26 02:00
>>196 じゃなくて >>195 の間違い。
201 ：デフォルトの名無しさん：01/10/26 02:00
>>185
ＯＯがメジャーになって十何年たってるのに、そうなってない。
おかしいと思わないんか？
そろそろ目を覚ましなさい。
202 ：デフォルトの名無しさん：01/10/26 02:00
>>197
例え話もわからないアフォ。
いるんだよな、例え話の本質を理解できなくて話の本筋を見失う奴。（ｗ
203 ：デフォルトの名無しさん：01/10/26 02:02
>>196
おいおい。XPっつたらペアプログラミングかよ。
204 ：デフォルトの名無しさん：01/10/26 02:02
>>194
パイロットは少数でいいけど、コンピュータ技術者は大勢いる。
大勢の技術者をパイロット並みのコストをかけて育成いないと
ＯＯって使えないってことになる。
あんたのたとえだと。
205 ：デフォルトの名無しさん：01/10/26 02:03
>>201
そうなってるじゃん。製品はほとんどVC++かDelphiでしょ。
206 ：デフォルトの名無しさん：01/10/26 02:04
>>204
いや、パイロット並みのコストをかけるほど価値があるってことになるだろ。
207 ：デフォルトの名無しさん：01/10/26 02:05
ココロ終わったし寝るよ
208 ：デフォルトの名無しさん：01/10/26 02:05
>>201
十何年てどういう数え方？（藁
PCのメジャーな環境で使えるようになってから何年？
209 ：デフォルトの名無しさん：01/10/26 02:05
>>202
こっちも喩え話だよーん。
(ﾟДﾟ)y─┛~~
210 ：デフォルトの名無しさん：01/10/26 02:05
>>205
パソコンアプリなんて、コンピュータ産業のごくごく一部。
211 ：デフォルトの名無しさん：01/10/26 02:06
>>190
一理在り．

かれらは OOにたどり着いたが、日本は OOで何ができるかになってる．
212 ：デフォルトの名無しさん：01/10/26 02:07
さっきまで「３０年前からある」と言ってた奴が居たのに
都合が悪くなったら「まだ何年」かい！
213 ：デフォルトの名無しさん：01/10/26 02:07
>>207
激しく板違い
214 ：デフォルトの名無しさん：01/10/26 02:08
>PCのメジャーな環境で使えるようになってから何年？
Turbo Pascal 6.0 for PC98のマニュアル初版が1990だから
俺的にはほぼ10年だな
215 ：デフォルトの名無しさん：01/10/26 02:08
>>210
金額ベースでは違うんじゃない？
216 ：デフォルトの名無しさん：01/10/26 02:11
>>206
そんな高価な技術なんてつかえねぇよ。
217 ：デフォルトの名無しさん：01/10/26 02:13
>>206
飛行機じゃなくて馬車の間違いじゃない？
218 ：デフォルトの名無しさん：01/10/26 02:14
>>216
だから、凡人には使えないけど、使えれば多大な利益を生むって事。
駄目ってことにはならないでしょ。
219 ：デフォルトの名無しさん：01/10/26 02:16
＞使えれば多大な利益を生むって事。

おまへにはインド人並の給料をあげよう。
220 ：デフォルトの名無しさん：01/10/26 02:16
>>217
まあ、馬車でも良いと思うよ。
大げさな例えが丸くなっただけだから。
221 ：デフォルトの名無しさん：01/10/26 02:17
専門あたりできっちり仕込んでくれると
普及するんだろうけどな。
222 ：デフォルトの名無しさん：01/10/26 02:18
>>221
東大生はJava仕込まれるんだけど、東大生が仕込まれたところで
普及しないんだよな。
223 ：デフォルトの名無しさん：01/10/26 02:21
>>222
灯台に限らず大学の情報系出たらOOくらい覚える。
でもそういうやつは「コーダー」（ってほんとに今でも呼ぶようなところ）
には逝かない（藁
224 ：デフォルトの名無しさん：01/10/26 02:22
ではスローガンは
「社会の底辺から構造改革」
でよろしいか？
225 ：デフォルトの名無しさん：01/10/26 02:23
>>221
専門生じゃ、ついて来れないんじゃ。。。
226 ：デフォルトの名無しさん：01/10/26 02:26
今日の祭りはここですか?
227 ：デフォルトの名無しさん：01/10/26 02:29
いまさらCなんて使いたくない
228 ：デフォルトの名無しさん：01/10/26 09:36
生産性問題の深刻さが理解出来ないようだな。
またいつものようにキーワード発明して乗りきろうとしてんのか？
229 ：デフォルトの名無しさん：01/10/26 09:39
もちろんOfficeXPの事さ！
230 ：デフォルトの名無しさん：01/10/26 10:39
憂鬱なプログラマ・・・って本読んでからも（理解して）、
オブジェクト指向を批判してる人っている？

オブジェクト指向は生産性重視より、開発スピード重視
なんじゃないかな。
231 ：デフォルトの名無しさん：01/10/26 10:41
>生産性重視より、開発スピード重視
意味わかりません
232 ：デフォルトの名無しさん：01/10/26 10:44
そのまんまの意味だけど、日本語わかる？
233 ：デフォルトの名無しさん：01/10/26 10:53
生産性高い = 開発スピード早。じゃないの？
234 ：デフォルトの名無しさん：01/10/26 10:57
生産性には再利用のしやすさなんかが含まれるような。

つーか、
オブジェクト指向は開発スピードより、生産性重視
なんじゃないかな。
235 ：デフォルトの名無しさん：01/10/26 11:03
ああ、わかった
オブジェクト指向は似たような奴とか使いにくい奴を高スピードで開発できるけど、
価値の高いすぐれたソフトは作れないってことね。納得納得
236 ：デフォルトの名無しさん：01/10/26 11:07
生産性と開発スピードって別物なのか？
開発スピード遅いプロジェクトは生産高いって言わないだろ。
237 ：デフォルトの名無しさん：01/10/26 11:10
生産性＝生産物（質）／時間

短期的なスピードはどう考えてもゴリ押しのほうが速い。
238 ：>>237：01/10/26 11:17
ゴリ押しのが速そうだけど、後からいろいろ付け加えるのに
オブジェクト指向のが便利なわけで。
239 ：defo名無し：01/10/26 11:26
できるにこしたこたぁない
240 ：デフォルトの名無しさん：01/10/26 11:27
>>238
だから長期的にはオブジェクト指向が有利。
ゴリ押しは長期的には破綻する。作り直し。
241 ：デフォルトの名無しさん：01/10/26 11:35
>>240
けど、今後、新しい言語が主流になったり新しいＯＳが席巻したら
やっぱり（ソースコードを打ち直すという意味だとしても）作り
直しじゃん？
人間には基本的に、白紙から新たなモノを作ろうという欲望がある。
少なくともオブジェクト指向がもたらす「再利用性」という恩恵は
人間の本能に反するものだと思うがどうだ？
242 ：電波発信中：01/10/26 11:42
どんな理論にも適用限界はある。
かつて構造化がそうだったように。
限界が問題になってくればまた新しい開発手法が考え出されることでしょう。
科学は人間の脳の学習方式に沿った合理的な考え方だとは思いませんか？
243 ：デフォルトの名無しさん：01/10/26 11:47
>>241
240じゃあないけどさ、
本当に新たなモノならいいけどね。
前に苦労して作ったものを、最初から作り直すのはイヤなもんだよ。
面倒なことは繰り返したくないだろ？
楽したいってのも本能に則してるっていえるよな。
設計をしっかりして、後は楽をする。
俺はこっちの方がいい。
244 ：デフォルトの名無しさん：01/10/26 11:49
>241
折れは「再利用性」よりは「拡張性」のほうに恩恵を感じる。
グローバル変数でガンジガラメ状態には戻りたくないよ。
245 ：デフォルトの名無しさん：01/10/26 11:58
>>244
そんな組み方しているほうが悪い。
根本的に考え方が腐っている。
246 ：デフォルトの名無しさん：01/10/26 12:04
>>245
>244 は比喩的に書いたんじゃないの? 知らんけど。

オブジェクト指向禁止って言われるのは
確かにローカル変数禁止っていわれるのに似た感じがするな。
247 ：２４１：01/10/26 12:14
>>243
>前に苦労して作ったものを、最初から作り直すのはイヤなもんだよ。

というのも確かにそうだね。
卑近な話だが、UNIXのC言語が長かった漏れとしては、
javaのjava.util.StringTokenizerクラスが用意され
ているのを見て、嬉しくなったもんなー

すごく主観的で漠然とした表現で恐縮だがオブジェクト指向の
恩恵を受けようと思うと、人間的に「大人」にならなければい
けない、ような気がする。同じこと思った人いない？
248 ：245：01/10/26 12:19
>246
オブジェクト指向 = JAVAの構文、C++の構文を使用すること、
ではないと思います。 OOする = OOするのに便利な言語を使用すること、
で議論する人が多く見られますが、これって正しいことでしょうか？ (マジ疑問)

漏れは もっぱら C + Win32 ですが、C++でろくに OOしていないソース書く
連中よりも生産性、効率は上だと思っています。
特に きちんとドキュメント化されていない C++のソースは他人がメンテ
できないですよ。C++に限っていうと、機能追加で基本的なクラスに
手を入れること多く、再利用性って何？これが OO？って疑問です。

なんちゃって技術者が多いこの世の中、OOもどきは すべてをぶち壊します。
249 ：デフォルトの名無しさん：01/10/26 12:21
大人じゃないひとは「OOバージン」かしらん？
250 ：デフォルトの名無しさん：01/10/26 12:24
C++はプログラマのスキルをアテにしすぎ。
つーか注意すべき点が多すぎて
OOのによる利点より赤字だ。
251 ：２４１：01/10/26 12:25
>>248
たとえば、ＣだけでＯＯしているコードを書くときに
248 さんが設けている規約は何ですか？
つまり、248の頭の中が全く見えていない他人に　248さんの
ＣによるＯＯ的システム設計・開発を伝授するときに、
どのようなチェックポイントがあるのですか？
（煽りのツッコミではなく、純粋な興味による質問です）
252 ：デフォルトの名無しさん：01/10/26 12:25
>オブジェクト指向 = JAVAの構文、C++の構文を使用すること、
>ではないと思います。 OOする = OOするのに便利な言語を使用すること、
>で議論する人が多く見られますが、これって正しいことでしょうか？ (マジ疑問)
正しくないが、どっからそんな疑問が湧いて出るんだ？
ハサミを髭剃りに使う奴は居ないかもしれないが出来ない事はないわけで。
253 ：245：01/10/26 12:26
>>247
あなたの言っている OOの恩恵って、ライブラリが便利って
ことなんでしょうか？

あなたが作る独自のクラスは再利用可能でしょうか？
OOはライブラリが便利、としか解釈できないですよ。それをりようする
あなたのソースが腐っていたら、OOでもなんでもないですよ。
254 ：248：01/10/26 12:27
>>251
>ＣによるＯＯ的システム設計・開発
こんなことしているなんて一言も言ってません。
255 ：２４１：01/10/26 12:33
なんか不快な揚げ足取り合戦になってきたな（藁
ま、2ｃｈだしね
256 ：デフォルトの名無しさん：01/10/26 12:38
暇だしね。
257 ：デフォルトの名無しさん：01/10/26 12:44
つか、OO使ったって、結局コードの再利用は職人技。
(コンテナクラスのように独立性のたかい物は別にしてな)
258 ：デフォルトの名無しさん：01/10/26 15:00
>>257
ただ、再利用しやすい作り方の定石集がある。でざぱた。
また、再利用する（再利用可能に変化させていく）技法もある。りふぁくたりんぐ。
259 ：デフォルトの名無しさん：01/10/26 15:14
デザイン・パターン便利すね〜
昔、苦労して編み出したつもりのやり方が、片っ端からのってる。
今までの苦労は何だったんだ（苦笑）？
260 ：デフォルトの名無しさん：01/10/26 15:52
>>253
OOのライブラリが便利っていうのは、オブジェクト指向で設計した
クラスライブラリの再利用性が高い証拠だから、OOのアドバンテージ
と考えていいと思うんだけど。
261 ：デフォルトの名無しさん：01/10/26 16:04
>>259
デザイン･パターンの正式名称を教えてください。お願いします。
262 ：デフォルトの名無しさん：01/10/26 16:06
>>261
まんま、デザイン・パターンが正式名称です(^^;
263 ：デフォルトの名無しさん：01/10/26 16:09
>>261
http://books.softbank.co.jp/bm_detail.asp?sku=4797311126
264 ：デフォルトの名無しさん：01/10/26 16:10
これですか？
http://www.rational.co.jp/products/books/bk_12.html
265 ：デフォルトの名無しさん：01/10/26 16:11
>>263
ありがとうございました。是非買ってみます。
266 ：　：01/10/26 17:15
デザインパターン
アナルパターン
アンティパターン
プロセスパターン
他には？
267 ：デフォルトの名無しさん：01/10/26 19:57
>>265
その本は熟練プログラマじゃないとわからないから、まずこっちから読め。
http://books.softbank.co.jp/bm_detail.asp?sku=4797316462
268 ：デフォルトの名無しさん：01/10/26 20:29
今日の金曜ロードショーはCORBAだってさ。
269 ：デフォルトの名無しさん：01/10/26 21:17
なんでやねん
270 ：デフォルトの名無しさん：01/10/26 21:53
>>260
馬鹿ですか？
ＡＮＳＩライブラリも再利用性高い事になりますが？
271 ：デフォルトの名無しさん：01/10/26 22:11
クソ映画だな＞CORBA
272 ：デフォルトの名無しさん：01/10/26 22:44
>>270
なんだそのANSIライブラリってのは？
273 ：デフォルトの名無しさん：01/10/26 23:24
こんなとこで糞議論してる暇があったら、1本でも多くプログラム組め。そうすりゃ真実がわかる。
274 ：デフォルトの名無しさん：01/10/26 23:43
数組みゃ分かるなら、ジジイCOBOLプログラマは神様になってるよ…
275 ：デフォルトの名無しさん：01/10/26 23:55
別にＯＯ知らなくても食っていけるからいいや
276 ：デフォルトの名無しさん：01/10/27 00:06
スキルが高い人だったらCで書いても自然と
OO的な設計になると思うんだけどなあ。
277 ：デフォルトの名無しさん：01/10/27 00:13
>1
あふぉ発見
278 ：デフォルトの名無しさん：01/10/27 00:16
>276 FILE構造体やXawみたいのとかな。
じーっとソースコード睨んでるとクラスやインスタンスが見えてくる
ことはある。
279 ：仕様書無しさん：01/10/27 00:16
にゅーそく板にスレたてたの１？
280 ：デフォルトの名無しさん：01/10/27 00:17
まぁいいじゃねーか。ＯＯだろうが構造化だろうが。
結局スキルのない奴がプロジェクトの足を引っ張るのに変わりはない(藁
281 ：デフォルトの名無しさん：01/10/27 00:18
ＯＯ使おうが使うまいが、プログラマーという時点でダメだろ
282 ：1：01/10/27 00:19
>>279
ちがーうｗ
283 ：プロジェクトが成功するか失敗するかはＰＭにかかっている！：01/10/27 00:23
と思うのは俺だけ？
全てを言語やＰＧに押しつけるのは間違っていると思うな。
284 ：デフォルトの名無しさん：01/10/27 00:34
最近の携帯電話の回収騒ぎで「これからはＯＯだ！！」とかトップに言われて、
過去を否定されたエンジニアがＯＯ的アプローチに挑戦しているそうだが、
次々にプロジェクトがデスマーチと化しているそうだ。この分野で結果が判るんじゃねーの？
285 ：デフォルトの名無しさん：01/10/27 00:41
>>284
浦島太郎にいきなりOOやらせて成功するわけないだろう。
286 ：ＯＯはちゃんと設計しないと必ず失敗する：01/10/27 00:44
文句言う前に設計はちゃんとしろ！
287 ：デフォルトの名無しさん：01/10/27 00:48
ＯＯなんかより在来言語での蓄積の方が何倍も効率的という事さ。　
288 ：デフォルトの名無しさん：01/10/27 00:48
>>286
だがね、いくらちゃんと設計していても、仕様変更は設計者の想像を
超える量、質でやってくるのだよ。
289 ：デフォルトの名無しさん：01/10/27 00:49
iアプリのＣ言語導入激しくｷﾎﾞﾝﾇ。
290 ：デフォルトの名無しさん：01/10/27 00:52
>>285
そーなんだよ、やつら最初はデザパタがどーの、なんちゃらのゴールド
一発で取ったのと言っていて、デスマーチだから笑っちゃうよな。
291 ：デフォルトの名無しさん：01/10/27 00:55
>>288
抽象化が足りない証拠。
特に変更が多いデータに対する抽象化は徹底すべき。
292 ：デフォルトの名無しさん：01/10/27 00:57
ＰＧの能力はゴールドかブロンズかにはよらないのです。
体内のコスモの燃焼を高める事でブロンズでもゴールドを
超える事が出来るのです。
293 ：デフォルトの名無しさん：01/10/27 01:00
しつもーん。携帯でOOするときって言語は何を使うんですか？
294 ：デフォルトの名無しさん：01/10/27 01:00
これからはXXXXだ！
なんてゆう奴はクズばっかりだよ。
実は自己顕示欲に突き動かされているだけだもの。
295 ：デフォルトの名無しさん：01/10/27 01:02
>>293
じゃう゛ぁじゃないの？
296 ：能力？：01/10/27 01:05
ＰＧの能力＝体力
ＳＥの能力＝口八丁
ＰＭの能力＝政治力
297 ：デフォルトの名無しさん：01/10/27 01:06
>>291
信心が足りないからじゃ。
とか言ってる教祖さまみたい。
298 ：デフォルトの名無しさん：01/10/27 01:09
>>296
その現場は生存者０です。
299 ：デフォルトの名無しさん：01/10/27 01:12
>>297
教典を読んで理解すれば、君にもその素晴らしさがわかる。
それでも入信しないのは、教典が理解できない馬鹿だけだ。
300 ：デフォルトの名無しさん：01/10/27 01:14
>>298
どの現場も、そんなもんだと思うが。
301 ：デフォルトの名無しさん：01/10/27 01:18
>>295
じゃばってリエントラントの問題って結構簡単に解決できるんですか？
組み込みってマルチタスクが普通なんですよね。経験ないから良く判りません。
C++とかでもどうやっているんだろう？
302 ：デフォルトの名無しさん：01/10/27 01:21
>>301
スレ違い。くみこに聞いて来い。
303 ：デフォルトの名無しさん：01/10/27 01:34
>>301
マルチタスク入れるとメモリ食うから只の割りこみ。
304 ：デフォルトの名無しさん：01/10/27 03:51
既に一部機能がiアプリになっているという
無謀な端末もあるようだな。
305 ：デフォルトの名無しさん：01/10/28 01:50
あge
306 ：デフォルトの名無しさん：01/10/28 02:51
>>301
関数内の変数はスタックに積まれます。
だからいくら再入しても平気。
307 ：デフォルトの名無しさん：01/10/28 02:57
>>306
再帰と再入を混同してない？
308 ：デフォルトの名無しさん：01/10/28 03:10
同じじゃないの？
309 ：デフォルトの名無しさん：01/10/28 03:15
>>308
同じじゃないけど無関係でもない。
310 ：デフォルトの名無しさん：01/10/28 03:44
>>309
無関係でしょ。

>>308
リエントラントで検索すれ。
311 ：デフォルトの名無しさん：01/10/28 04:33
1に言いたい。

UNIXはプログラミング言語環境の進化を妨げるお荷物だ!
312 ：デフォルトの名無しさん：01/10/28 04:40
>>310
無関係でもないと思うが。
スレッドローカルな資源しか使わなければreentrantだが、
特にCやC++で(その下の関数も含めて)
autoしか使わないなら自動的にreentrantだろ。

で、再帰でもglobalな資源のアクセスには同じような制約が付く。
313 ：デフォルトの名無しさん：01/10/28 04:54
再帰はプログラミングによるコントロールを前提としているので
static な変数を使っても問題ないし、返値でレジスタをつぶしても良い
でも再入は割り込み処理を想定したルーチン…
314 ：デフォルトの名無しさん：01/10/28 04:55
>>312
> で、再帰でもglobalな資源のアクセスには同じような制約が付く。
単一スレッドなら実行タイミングが完全に確定できるが、複数スレッドで同一資源をアクセスする場合に
実行タイミングを事前に確定できずに、排他制御（それにともなってスレッドの sleep, wakeup などの制
御)が必要になることが多い。

分けて考えたほうが良いと思われ。
315 ：デフォルトの名無しさん：01/10/28 04:58
でも、クラスによる機能の部品化は管理が楽だよ。オブジェクト指向は存在するべきだ。
316 ：デフォルトの名無しさん：01/10/28 11:48
クラスのある言語使う前は部品化してなかったってことかな？
317 ：デフォルトの名無しさん：01/10/28 12:03
しっかりモジュール化という概念があってそれなりに部品化はされていた。
その点に関しては言語仕様としての隠蔽がやりやすくなっただけだ。
318 ：デフォルトの名無しさん：01/10/28 12:06
いや、せっかく部品化したクラスの
基底クラスが変更になったときに継承先も修正しなければいけない
すべてチェックしなければいけないから再利用性は高くないよ。
319 ：デフォルトの名無しさん：01/10/28 12:13
うーん、考えてみたんだけど、
いつも同じようなプログラムばかり書いている人の場合、
OOPはいらないかも。
使い込んだライブラリがあれば、それで十分みたいな。

OOPがうれしいのって、
スパイラルな開発工程を導入できるってことじゃない？
コンピュータに不慣れなクライアントを相手に、
プロトタイプを見せながら開発するんだったら、
OOPがないとどうしようもない。
でも、コンピュータに慣れているクライアントを相手に、
最初にきちっと仕様書を作って開発するなら、
OOPはいらねーな。

そういう仕事環境が影響してるんじゃないの。

オレの職場は、プロトタイピングが必須なんで、
OOPなしでは耐えられないな。
320 ：デフォルトの名無しさん：01/10/28 12:22
>>318
ﾊｧ?
321 ：デフォルトの名無しさん：01/10/28 12:28
>>316-317
多態は？

>>318
基底を変更した時に継承先も変更しなきゃならないのは
アンタがバカだから。
322 ：317：01/10/28 12:48
>>315-317の流れで読んでくれ。
323 ：デフォルトの名無しさん：01/10/28 12:52
>>321
いいかげんマ板に帰れよ。
ム板には厨房を引き受ける保育所は用意されてません。
324 ：デフォルトの名無しさん：01/10/28 13:20
やれやれ、なんでＯＯの煽りやる馬鹿が寄ってくるんだろか？
321とか323とか。

「ＯＯは全て正しい。巧くいかないのは使う人が馬鹿だから」
こればっかし。

信者なのか、信者のふりした荒らしなのか。
325 ：デフォルトの名無しさん：01/10/28 13:30
>>324
323 は典型的な煽りだが 321 は妥当な意見だと思うがね。ＯＯだと適切に設計しておけば、変更箇所は
局所化されることが多いよ。

もちろんＯＯ以外の設計手法を使っても変更箇所を局所化することは可能だが、そのために関数ポイン
タを多用したり継承構造を自前でエミュレートする必要があって、手間がかかる（だから、ふつーはやら
ない）。それが「楽」なのがＯＯ言語。
326 ：デフォルトの名無しさん：01/10/28 14:06
んじゃなんでＯＯＰＬの開発速度がＣの半分になったりするの？
327 ：デフォルトの名無しさん：01/10/28 14:11
>>325

その意見はちょっとかたよってると思うぞ。
324のいってる事の方が普通だと思う。
まあ324のいってるように単なる煽りだと俺も思うが。
悪い=たぶん使いこなしていない
といってる奴はどうかと思う。
まずは相手の実力を探る事から始めようや。
OO嫌いでもGoFやリファクタリング程度は普通は読んでるし、
既存のフレームワーク等も勉強程度(or 使った事ある)は
してる奴は結構いるはず。もちろん全然使った事無いけど、
Cですごいベテラン、とかもいるだろうし。
328 ：デフォルトの名無しさん：01/10/28 14:37
>>327
＞ OO嫌いでもGoFやリファクタリング程度は普通は読んでるし、
＞ 既存のフレームワーク等も勉強程度(or 使った事ある)は
＞ してる奴は結構いるはず。
そんなやついるのか？
それなら「OOは生産性悪い」とかいう検証不可能で
自分のご近所しか知ら無さそーな意見以外に、
もう少し真っ当な批判が出てきそうなもんだが。
329 ：デフォルトの名無しさん：01/10/28 14:51
>OO嫌いでもGoFやリファクタリング程度は普通は読んでるし、

日本でGoFの発行部数なんて、せいぜい数万程度だろ。
読んでるのはソフトウェア産業に従事してる人間の1%以下
なんじゃねーの？
330 ：デフォルトの名無しさん：01/10/28 14:53
本当に嫌いになるのにもしっかり勉強しないとね｡
331 ：デフォルトの名無しさん：01/10/28 15:01
>>327
>まずは相手の実力を探る事から始めようや。

それは激しく不毛なやりとり。
そいつがどんな実力を持ってるかどうかなんて関係ないでしょ。
アホなこと書く奴はアホ。
スゲーこと書く奴はスゲー。
これだけでしょ。
332 ：327：01/10/28 15:02
ごめん、俺が悪かった。
333 ：デフォルトの名無しさん：01/10/28 15:07
よくC++,は言語仕様が複雑すぎる、敷居が高すぎるとかって
批判があるけど、そもそもOO自体が敷居が高すぎる。

現場のダメエンジニアに、GoFやらリファクタリングやらを
読破させるのは、至難のわざ。
334 ：デフォルトの名無しさん：01/10/28 15:10
>>333
ライブラリやフレームワークのエンドユーザとしてのプログラミング
だったら、そんなに難しくはないと思うけど。
335 ：あらら論理破綻：01/10/28 15:16
>>328
ＯＯの生産性が悪いのは>>1の資料から「も」明らか。
それからこの一文

＞「それなら「OOは生産性悪い」とかいう検証不可能で」

つうのは「ＯＯで生産性が上がる」という当初の触れ込みも
検証不可能な主張だったということになります。
336 ：デフォルトの名無しさん：01/10/28 15:26
まだ>>1なんか持ち出すアフォがいる。
OOの生産性？ Webでサーチしてみろや。山のように出てくるわ。
337 ：デフォルトの名無しさん：01/10/28 15:26
>>335
> ＯＯの生産性が悪いのは>>1の資料から「も」明らか。
どこが？　統計的な処理をしていない数値を並べられたところで、話にならん。
338 ：デフォルトの名無しさん：01/10/28 15:27
このスレ読んでたら
OO信者＝オウム信者＝イスラム原理主義過激派
の図式が明確になりました。
歪んだ自己正当性を屁理屈で構築して耽溺、ですかねぇ。

でも、あんまり苛め過ぎちゃダメですよ〜
逆ギレしてトンデモな事しでかすカモ（ｺﾜ
339 ：デフォルトの名無しさん：01/10/28 15:28
>>335 = >>338

>>1を持ち出した時点でチミの知性の判断がついた。
ＯＯの良し悪しを論ずる資格なし。
340 ：デフォルトの名無しさん：01/10/28 15:40
338は別の人。
>>337
統計的な処理って・・・。
25％、50％という数字の意味は難しいけど、
JavaやC++とCのプロジェクト達成数比が１：２というのは
これ以上どんな統計処理が必要なん？
341 ：デフォルトの名無しさん：01/10/28 15:43
統計はどうでもういいや。
論理破綻の方を小一時間問い詰めたい。
342 ：デフォルトの名無しさん：01/10/28 15:51
>>340
統計／検定あたりをキーワードにして google 逝け。数字に騙されるぞ。
343 ：デフォルトの名無しさん：01/10/28 16:08
統計にはウソが多いって、むやみに疑うのも、素人が多い。
344 ：デフォルトの名無しさん：01/10/28 16:20
>>343
一般論はどうでも良いよ。俺は >>1 のリンク先の資料に関して「ＯＯの生産性が悪いのは明らか」
という結論は出せないと言ってるだけ。
345 ：デフォルトの名無しさん：01/10/28 16:26
だいたい成功率と生産性とどういう関係があるんだ？
346 ：デフォルトの名無しさん：01/10/28 16:31
>>345
逝って良し。
347 ：デフォルトの名無しさん：01/10/28 16:37
統計が取れる確かな例のひとつ、
OOPできるようなツールやコンパイラは、OOでないもので作ってる。
大概の伝統的なものはOOでない｡
348 ：デフォルトの名無しさん：01/10/28 16:38
結論：Rubyが最高の言語
349 ：デフォルトの名無しさん：01/10/28 16:39
まぁとにかく、喧嘩してる相手が会社の上司だったりしねーかと
ビクビクしてる奴は俺だけじゃないだろ?ってこった。
350 ：デフォルトの名無しさん：01/10/28 16:41
>>354
普通、失敗や中止した場合は何も生産されなかったと見なされます。
351 ：デフォルトの名無しさん：01/10/28 16:43
>>349
私の場合は面接でオブジェクト指向への疑問を素直に述べて採用に
なったんで問題ないのです。
352 ：デフォルトの名無しさん：01/10/28 16:47
ウチの会社の上司はＯＯ厨ではないから大丈夫だ。
353 ：デフォルトの名無しさん：01/10/28 16:49
ウチの会社は１名を除いてはOOマンセーだ。有難い。
354 ：デフォルトの名無しさん：01/10/28 16:52
二名しかＰＧ居ないとか？
355 ：デフォルトの名無しさん：01/10/28 16:52
>>347
そうか？　C++ コンパイラや UML のモデリングツールは OOPL で書かれたものも多いと思うが。

少なくとも UML モデリングツールの Together Control Center, MagicDraw あたりは Java で書か
れてるし、コンパイラだと SGI の Pro64 は C++ だったはず。
356 ：デフォルトの名無しさん：01/10/28 16:52
9名だわ。
357 ：デフォルトの名無しさん：01/10/28 16:58
OOPS!!
358 ：デフォルトの名無しさん：01/10/28 17:10
おひおひ,Java出していいのか？
359 ：デフォルトの名無しさん：01/10/28 17:14
>>358
もちろん。というか、なんでマズイと思う？
360 ：デフォルトの名無しさん：01/10/28 17:38
>>350
それで、成功率が低いと仮定したとして、
なんで生産性が低いことになるんだ？
成功した場合の生産性が１０倍だったら？
361 ：デフォルトの名無しさん：01/10/28 18:10
マ板での受け入れ先がきまりました。
各位よろしくおねがいいたします。

今思ふ　　今の時代言語は何でも言いと・・・
http://pc.2ch.net/test/read.cgi?bbs=prog&key=1003835137
362 ：デフォルトの名無しさん：01/10/28 19:00
生産性10倍は言い過ぎだと思われ
363 ：デフォルトの名無しさん：01/10/28 19:06
>>362
例えばの話だよ。
何倍か分からないのに成功率だけで
トータルの生産性はわかんないだろ？
364 ：デフォルトの名無しさん：01/10/28 19:16
学生だと仮定して話すけど

プロの世界では「OOにして生産性が落ちるリスク」なんか、誰も背負いたくないのよ。
成功すれば生産性が上がるなんて言えるのは、
アマチュアか、予算が湯水のように使える研究職くらいなもんなの。

で、生産性についてだけど
今までOOやってなかったプログラマは設計者が、いきなりOOなんて持ち出して
プロジェクトをこねくりまわして、あげくメンテの仕方がよくわかんなくなっちゃって
元の構造化プログラミングにリファクタリングし直しちゃう現場とかあったりしてね、
もう、証明されちゃってるのよ。

プロジェクトに加わる全員がOOについて深い知識と経験を持ってるなんてことは
ほとんどないよ。

いやもう、学生だったら知らないのも仕方ないけどね。
365 ：デフォルトの名無しさん：01/10/28 19:30
>>364
で、何についての「深い知識と経験」を持ってるの？
このスレ読んでるとプログラマの大半は無能なんじゃないかと思えてくる。
366 ：デフォルトの名無しさん：01/10/28 19:36
オブジェクト指向というのはたんなる道具だよね。それを巧く使いこなすかどうかがその人のスキルだと思う。オブジェクト指向を批判するのもいいが、使いこなせないのはスキルのない証拠だよね。
>>364
大半はプログラムの事しかわかってないからしょうがないんじゃない？
考えてる範囲が狭いからね。
367 ：デフォルトの名無しさん：01/10/28 19:37
>>365
学生じゃないけど…
ＯＯ知ってる世代がどんどん増えてるでしょ？
ＯＯに無知な上司がみんな消えるまではダメかなあ…
368 ：364：01/10/28 19:46
>>365
おれが？
あちこちのＯＯスレで糞レス書いてるよ。

10年ほど前に拾って以来大切にしてきたこの魔法の杖が、実は実社会では何の役にも立たない
棒きれだったんじゃないかと思うことがあってね。
369 ：デフォルトの名無しさん：01/10/28 19:48
>>368
もしかして 逝って良しの１ ？
370 ：デフォルトの名無しさん：01/10/28 19:49
もしかしてRuby厨の人？
371 ：デフォルトの名無しさん：01/10/28 19:49
>>367
OOをやらなくても技術屋として十分食っていける時代だからね。

なにかそれで、飛び抜けた成果を出すか、継続的に高い効果を出していかないと
広く認められはしないとおもわれる。

javaがそこそこはやっているのはOOベースの言語だからではない、と思うがどうか？
372 ：デフォルトの名無しさん：01/10/28 19:51
>>371
GCのある、BASICじゃない言語だからと思われ。
373 ：364：01/10/28 19:51
1でも何でもない。
只のsageだ。

rubyはしらん。
delphiもしらん。
javaもしらん。
374 ：デフォルトの名無しさん：01/10/28 19:54
>OOをやらなくても

技術屋として白い目でみられるだけではないか？

>飛び抜けた成果を出すか、継続的に高い効果

その前に、OO出来ないと使えない奴扱いだと思うが。

「OOできません」と言う奴と「OOできます」という奴
どちらを企業は採用する？
375 ：デフォルトの名無しさん：01/10/28 19:55
>>374
> 「OOできません」と言う奴と「OOできます」という奴
> どちらを企業は採用する？
企業による。たぶん 364 がいる企業は「ＯＯできません」というやつを採用して、ＯＯできません組が
一大勢力になってるんだろう。……合掌。
376 ：デフォルトの名無しさん：01/10/28 19:58
「おーおーできます」
っていうの？
377 ：デフォルトの名無しさん：01/10/28 20:00
Ｒｕｂｙ］つかえないやつらのひがみですか？あ
378 ：正確には：01/10/28 20:00
「うーうーできます」
です
379 ：デフォルトの名無しさん：01/10/28 20:05
Ｒｕｂｙつかえないようなやつはくびにしろ！
そいうがくびをくくるまでおいつめろ！
380 ：デフォルトの名無しさん：01/10/28 20:07
>>379
それって、プログラマの9割以上がくびになるな…
381 ：デフォルトの名無しさん：01/10/28 20:07
おーおーぴー
できます
のほうがあたまよくみられない？
382 ：デフォルトの名無しさん：01/10/28 20:08
何だか急にレベルが下がったな
383 ：デフォルトの名無しさん：01/10/28 20:08
>>379
ごめん。おれ Java, C++, Perl あたりは使えるが ruby はダメだわ。
384 ：デフォルトの名無しさん：01/10/28 20:08
9割8分7厘クビになるな
385 ：デフォルトの名無しさん：01/10/28 20:09
OSやDB書いてるプログラマたちも9割5分はクビだろう。
386 ：デフォルトの名無しさん：01/10/28 20:12
お願いです、これ以上 ruby 厨に餌をやらないでください。
387 ：デフォルトの名無しさん：01/10/28 20:40
>>382、>>389
ごめん、たぶん俺の所為だ、、、
Ruby厨回収の為に、注意書き書いてくる、、、
ああ、やっぱこっちに、>>1の資料の信頼の無さを示す為に、
Ruby 0.44
と言うことを、指摘しておけば良かった。
まあ、既に誰もあの資料なんか信頼してないけどね。（藁
388 ：デフォルトの名無しさん：01/10/28 21:38
>>372
Lispがありまふ。（お願い流行ってぇ
あと、Javaはその実行環境も合わせてのJavaでしょ。
でも、言語としてのJavaに高い評価つけている場合は、大抵その理由の一つに「OOPLである」
があるようですが。
389 ：デフォルトの名無しさん：01/10/28 22:36
>>360
んー。単品ならともかく、サンプル数多ければ平均化されるだろ。
390 ：デフォルトの名無しさん：01/10/28 22:37
>>360
それから生産性が低い＝期限内にできなかった、から失敗した
と考えるのが妥当。
391 ：デフォルトの名無しさん：01/10/28 22:40
OOでなくても期限内にできてないのが常態化しているのは逝ってよしですか？
392 ：デフォルトの名無しさん：01/10/28 22:43
>>389
平均化というか、ガウス分布のような連続した分布になると思う。
成功と失敗の境界でいきなり１０倍の断層ができるなんて、ちょっと考えられない。
393 ：デフォルトの名無しさん：01/10/28 22:52
>>1の数字は
JAVA,C++の生産性分布とＣ言語の生産性分布を重ねて
ある場所で切ってみたら左側の面積が２５：５０になりました。
ということだろう。
ガウス分布に従うとして、生産性比の計算誰かやってくれ。
俺には無視だ。
394 ：デフォルトの名無しさん：01/10/28 23:41
OOP理解してない人がOOPしても生産性が上がらないのはあたりまえ。
395 ：デフォルトの名無しさん：01/10/28 23:43
OOPLだとプロジェクトが失敗するんじゃなくて
失敗したプロジェクトはOOPLの割合が大きいだけだろ。
相関関係はあると思うが因果関係が逆。
OO厨の存在を如実にあらわしてると思う
396 ：デフォルトの名無しさん：01/10/28 23:51
まだあの統計が信じられると思ってるやつがいるよ･･･
総理の支持率だって、テレビ局、新聞社、その他の機関でかなり違う。
厳密にやった統計でもあまり信用できないと言うのに。
397 ：デフォルトの名無しさん：01/10/28 23:52
視聴率みたいないいかげんなもんに金を積むスポンサーと同じだな。
398 ：デフォルトの名無しさん：01/10/29 00:06
1の統計よりは支持率や視聴率のほうがはるかに正確だよ。
399 ：デフォルトの名無しさん：01/10/29 00:07
ＯＯ思想に従って出来もしない再利用を目指すから、生産性が悪くなる。
どんなに工数をかけても結局再利用できないのだから、何のメリットもない。
ＯＯが理解できない馬鹿は、こんな事はしない。
ＯＯを鵜呑みにして、自分自身では消化吸収できていない馬鹿が、これをやる。
400 ：デフォルトの名無しさん：01/10/29 00:12
>ＯＯを鵜呑みにして、自分自身では消化吸収できていない馬鹿
これはOOを使えない奴ってことです。

馬鹿はOOでひどい目にあって非OOしか使えないﾋｷｺﾓﾘになるのです。
401 ：デフォルトの名無しさん：01/10/29 00:14
>>400
馬鹿は学習能力無いから、ずっとＯＯを使い続ける。
自分がＯＯ使えてないなんて、理解できる知能もない。
402 ：デフォルトの名無しさん：01/10/29 00:17
ＯＯＰＬの生産性が低いのは再利用性が低いせいだろうか？
それともＯＯＰＬのコーディングコストが高いせいだろうか？
403 ：デフォルトの名無しさん：01/10/29 00:18
それともデバッグしにくいせいだろうか？
404 ：デフォルトの名無しさん：01/10/29 00:20
再利用を目指すと、設計・開発・テスト、全てに時間がかかる。
それで再利用できればいいが、結局は再利用できない。
405 ：デフォルトの名無しさん：01/10/29 00:24
再利用性はOOの利点ではないというのが通説では？
406 ：通りすがりのプログラマ：01/10/29 00:24
どちらかというと、手抜き翻訳と方法論とも呼べない中途半端な知識による啓蒙を行い、
混乱を煽って飯のタネにしたライターの功罪を問いたい。小一時間問い詰めたい。

OOの方法論を分かりやすく解説した本が出てきたのは、ここ数年。
レベル・職能別にお勧めできる書籍は少しづつ充実してきてる。
「大規模C++クラスデザイン」を読むと、ある規模以上のプロジェクトでは
OOの方が生産効率が上がるような話もある(うろ覚えｽﾏｿ)。
1の資料はコスト、締切、立案者のレベル、規模などを一切無視して
使用言語というたった一つのパラメータを見てるだけで、何の参考にもならない。

個人的には、開発規模とチームのレベルによって、どの程度OOするか決めるでよろしいのでは。
ただ、これからの設計は、ある程度OOして、変更･拡張に柔軟に対応できるようにしないと
過去からなにかを学びましたとはとてもいえなくなるでしょう。
407 ：デフォルトの名無しさん：01/10/29 00:27
>>403
特定分野ではデバッグしにくい為でもあると思う。
UMLの最大の欠点はマルチタスク環境での事象を表現する手段がない、
また同様にテストするツールが無い為と言われ始めて久しい。
OOPLがシステム分野、組み込み分野で伸びない理由はここら辺にもあると･･･
組み込みURLとか策定されてきているけれど、まだ現場で戦力になるような
レベルじゃないしね。
組み込み分野で
408 ：デフォルトの名無しさん：01/10/29 00:27
モジュールとして作れば再利用できる。
メソッドに順序性があると再利用は困難。
409 ：407：01/10/29 00:28
ゲ、ボロボロ。スマソ。
410 ：デフォルトの名無しさん：01/10/29 00:29
単なるモジュール化なら従来の手法で必要十分だね。
411 ：デフォルトの名無しさん：01/10/29 00:32
>>408
再利用性や生産性よりも保守性が向上すると思うけどね。
設計からやり直さない限りは修正は非OOよりも容易。
ユニットテストをきちんとやっていれば影響を受けるクラスがすぐわかるし。
412 ：デフォルトの名無しさん：01/10/29 00:40
>>411
保守性が本当に向上すれば、トータルの生産性も上がる。
しかし実際には、差分プログラミングの恩恵よりも、
継承の副作用の方が大きく、保守性は悪化する。

逆に考えると、継承の恩恵は多態位なのだから、
継承抜きで多態出来ないことに問題があるともいえる。
413 ：デフォルトの名無しさん：01/10/29 00:47
>>412
インターフェースだけ継承して、実装継承しなきゃ良い。
414 ：デフォルトの名無しさん：01/10/29 00:50
Ruby >>>>>>>>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>>> C++ <<<<<<<<< Python
415 ：デフォルトの名無しさん：01/10/29 00:50
>>413
実装継承は最悪だが、インターフェイス継承も良くはない。
416 ：デフォルトの名無しさん：01/10/29 00:52
>>406
規模が大きくなるとＯＯの有効性が失われるって書いてるのもいたぞｗ

規模が大きいと駄目なのか小さいと駄目なのか、どっちにしても
境界条件をある程度示してないから有罪。
使ってみて巧くいかなかった人に対してして「それは規模が小さすぎるから」
ですましてた日にゃあ誰もＯＯ信用しなくなる。
第一、組みこみＪａｖａの立場はどうなる？

417 ：デフォルトの名無しさん：01/10/29 00:52
>>415
ふむ、副作用の例を挙げてみて。
418 ：デフォルトの名無しさん：01/10/29 00:55
>>417
人に物を頼むのに、偉そうだな。
419 ：デフォルトの名無しさん：01/10/29 00:57
>>412
何段にもなったクラスツリーを追っていくと萎えるのは確かだが。
継承の副作用が出るとしても単純継承なら親クラスを追うだけで済む。当たりも付け易いし。
Cで呼ばれる関数全部追うよりは楽かも。

>>413
まず単純にコーディング量が増えるんだよね。
それとインスタンス変数を使いまわせないからきちんと設計しないとダメだし。
420 ：デフォルトの名無しさん：01/10/29 00:57
>>406
>>1の資料は規模の点で無作為だろうから、規模が大きいと生産性が上がる
というのなら、規模が小さいと、規模が大きい場合に得られる生産性の
上昇分をはるかに上回る生産性の低下を引き起こすということではないか？
421 ：デフォルトの名無しさん：01/10/29 01:05
>>420
ＯＯは大規模では収拾がつかなくなり、小規模では手間の割に恩恵が少ない。
中規模に向いていると思われる。
422 ：デフォルトの名無しさん：01/10/29 01:06
>>419
> まず単純にコーディング量が増えるんだよね。
確かに。現在主流のプログラミング言語では、継承はサポートしていても、委譲や集約はサポートし
てないものが多いから、単調なコードを書く羽目になりますね（C+ だと template を使えば、多少は
マシになるけど）。
423 ：デフォルトの名無しさん：01/10/29 01:12
幻想だったとまでは言わんけど、
期待されてたほどは役にたってねぇんじゃねぇの？
424 ：デフォルトの名無しさん：01/10/29 01:15
>>423
銀の弾丸を期待していたのなら、そだね。

しかし、いまさらＯＯ前夜まで戻りたくないのも事実。
425 ：デフォルトの名無しさん：01/10/29 01:15
>>423
というより、効能もあるが副作用もきつい薬のようなものだと思う。
426 ：デフォルトの名無しさん：01/10/29 01:21
>>425
オブジェクト指向はサリドマイドみたいなもんだね！
427 ：デフォルトの名無しさん：01/10/29 01:25
>>426
サリドマイドのハンセン病に対する効能ほど、有効ではないと思うが。
428 ：デフォルトの名無しさん：01/10/29 01:30
>>426
サリドマイドはある種の病気には非常に効果的ですね。昨今だとエイズの治療薬としても注目を集め
てたり。

……で、ＯＯはサリドマイド並に強力だと言いたいの？　（天然なのか計算づくなのか、微妙なラインだ）
429 ：デフォルトの名無しさん：01/10/29 02:39
>>405
オブジェクト指向は再利用性を突詰めた結果では？
再利用性が高いから、変更箇所が少なくなって保守性が向上する。
430 ：デフォルトの名無しさん：01/10/29 03:03
>>429
どのくらいのレベルでの再利用性を言ってる？
・あるソフトのライフサイクル内
・あるソフトで作成したクラスを他のソフトで再利用というプログラマレベルで
431 ：デフォルトの名無しさん：01/10/29 03:17
>>422
だから C# の delegate はちょっと面白い。
これから現れる言語は貪欲にデザインパターンなどの成果を取り入れていくんだろうね。
センスがあったらそういう言語を作ってみたいところだ。
432 ：デフォルトの名無しさん：01/10/29 04:38
>>431
C#のdelegateって委譲と関係あるの？
ただのメソッドへのポインタに、
またMSが独自の名前をつけただけだと思った。
433 ：デフォルトの名無しさん：01/10/29 05:32
>>411-412
いい意見がちらほら。2chはこれだからいいな。

OOは再利用性による生産性は期待できないけど
保守性による生産性は期待できると思われ。

>>416
するどいです。

>>419
>まず単純にコーディング量が増えるんだよね。
ですね。ﾌﾟﾛｸﾞﾗﾏ的に嫌になりそうですが
そこは構造化を意識して継承クラスの同じメソッドを
呼び出してみたり。

>>429
違うでしょう。
人の作った個人レベルの巨大ｸﾗｽﾗｲﾌﾞﾗﾘなどとても使えたものではない。
OOで再利用性の高いものを作る事は非常に困難な作業。

そもそもOOって並列処理を効率よく行うために
考案されたのではなかったですか？
434 ：デフォルトの名無しさん：01/10/29 06:06
OO && XP
435 ：デフォルトの名無しさん：01/10/29 09:10
>432
委譲のときに便利ってことを（MSが）強調してるってことでは。
J++のころからdelegateってあったね。
436 ：デフォルトの名無しさん：01/10/29 13:15
http://www.atmarkit.co.jp/fdotnet/opinion/kawamata/2001_10.html
ここにもオブジェクト指向に別れを告げた人がいます。
437 ：デフォルトの名無しさん：01/10/29 13:26
>>435
委譲の時にどう便利なの？ 関係ないように思うが…
438 ：デフォルトの名無しさん：01/10/29 13:28
>>436
小規模なコードを書く分には、設計も要らないしカプセル化しなくても全体を把握できる、
と言ってるだけですな。それは反対しないけど。
439 ：デフォルトの名無しさん：01/10/29 13:35
少し具体的な話をしよう。

コードとデータをまとめて１つにし、インターフェースを決める。
こうすると、組み替えの自由度が高まり、再利用が容易になる。
また、インターフェースが限定されるので、保守も容易になる。

ＯＯ言語を用いていなくても、こういうＯＯ的な発想で作られた
ものは数多くある。例えばUnixやWindowsのデバイスドライバ。
同じＦＳコードを、いろんなデバイスに対して再利用できる。
例えばＧＵＩ部品。基本的な描画プロトコルはすべての部品に
対して共通だ。（ＧＵＩはもともとＯＯ言語で開発されたわけ
だけど…。ＸやＭａｃやＷｉｎのウインドウシステムでは、
ＣやＰａｓｃａｌでＯＯ的な機能を実現しようといろいろ
工夫している。）
440 ：デフォルトの名無しさん：01/10/29 13:44
C#もJ++も知らないんですが、delegateってもしかして
委譲のコードを書かなくてもメンバ変数へのメソッド呼び出しを
したりできます？
そんな言語を使ってみたひ。
441 ：揚げ足取り君：01/10/29 13:55
メンバ変数へのメソッド呼出はどんな言語でも不可能と思う。
442 ：デフォルトの名無しさん：01/10/29 13:57
>>440
良く言ってることが分からないが、
Cの「関数へのポインタ」と基本的に同じだよ。
delegateとdelegateを足し算するとか言う変なおまけ機能もあるが。
443 ：デフォルトの名無しさん：01/10/29 16:03
>>432
実情は関数ポインタだけど、
構文レベルでデザパタの概念が利用されているのがいい（なんともMS流解釈なのはアレだが）。
幻想が実在になってきてるじゃんってこと。
444 ：デフォルトの名無しさん：01/10/29 16:23
開発スピードだけにこだわるのは厨。
変更保守作業を考えて仕事にあたれて半人前。
半人前等を引き連れて結果が残せて一人前。

OOは道具の一つ、使いこなして職人。
職人のタマゴが道具を語るは片腹痛い。
445 ：デフォルトの名無しさん：01/10/29 16:48
プログラマがいつまでも職人だから生産性あがらないと思うね。
446 ：デフォルトの名無しさん：01/10/29 16:53
>>444
生産性＝開発スピードじゃないよ。
開発スピード（だけ）にこだわるのは厨だが、
生産性にこだわらないのは、趣味のプログラマ。
447 ：デフォルトの名無しさん：01/10/29 16:57
仕事ってのは、芸術的プログラムを作って、自己満足するためにやるんじゃない。
利益を上げるためにやるんだ。
早く作って、保守は最小限で、クライアントを満足させる。
これが、生産性が高いということだ。
448 ： ◆GLfLgroI ：01/10/29 16:58
test
449 ：デフォルトの名無しさん：01/10/29 17:03
いやいや、もう限界まで廉くしてるよ。

　保守で儲けなきゃどこで儲ける
450 ：デフォルトの名無しさん：01/10/29 17:04
>>444

リアル厨房発見。
451 ：デフォルトの名無しさん：01/10/29 17:05
最近のオブジェクト指向の流れは、データ部分を汎用的にしようとしてるけど、
これって先祖帰りじゃない？
特定のデータだけのメソッド(関数)は、やっぱり使い回ししづらかったって事
でしょ？
452 ：デフォルトの名無しさん：01/10/29 17:07
>>451
古より、その流れで来てると思ったが。
断絶ってあったか？
453 ：デフォルトの名無しさん：01/10/29 17:09
何となく見えてきた。
生活がかかってる人間と、
かかってない人間の差だな。

電気代節約しろといっても、
親が電気代払ってるうちは、
本気にはなれない。
454 ：デフォルトの名無しさん：01/10/29 17:15
>>452
元々、特定のデータと、その処理関数をセットにするのが、オブジェクト指向
でしょ。
メソッドを他のオブジェクトに付け替えたり、汎用的なデータが扱えるなら、
ただの共通関数じゃん。
455 ：デフォルトの名無しさん：01/10/29 17:18
>>439
>>少し具体的な話をしよう。

>>コードとデータをまとめて１つにし、インターフェースを決める。
>>こうすると、組み替えの自由度が高まり、再利用が容易になる。
>>また、インターフェースが限定されるので、保守も容易になる。

無茶苦茶抽象的じゃん(藁)
456 ：デフォルトの名無しさん：01/10/29 17:21
>>454
>メソッドを他のオブジェクトに付け替えたり、汎用的なデータが扱えるなら、
>ただの共通関数じゃん。

滅茶苦茶OO的じゃん（藁）
457 ：デフォルトの名無しさん：01/10/29 17:23
オブジェクト指向の、レゴブロック的再利用は、スターウォーズ計画みたいなもの。出来たらすごいけど、技術的・コスト的に時期尚早。
458 ：デフォルトの名無しさん：01/10/29 17:25
>>456
過去の経緯を知らなすぎ･･･じゃん。
459 ：デフォルトの名無しさん：01/10/29 17:25
>>455
interface万能主義にはちょい懐疑的。
俺がアフォなだけかもしれんが。
460 ：デフォルトの名無しさん：01/10/29 17:30
>>457
同意
今やると会社つぶれそう・・・・・・
461 ：デフォルトの名無しさん：01/10/29 17:37
>>449
それはまた、別のはなし。契約にもよるし。
わざとバグ仕込んで、メンテを発生させたほうがいい？
462 ：デフォルトの名無しさん：01/10/29 17:42
1. デスマーチ状態
2. 新しい開発手法を勉強する／試験的に小さなプロジェクトで試してみる時間がない
3. 旧来の手法で力づくで開発
4. 仕様変更が入ってプロジェクトに火がつく
5. goto 1

抜け出せない。。。
463 ：デフォルトの名無しさん：01/10/29 17:55
デザパタで喜んでるのって、アルゴリズム辞典で喜んでるのと同レベルだね。
今まで知識が足りなかっただけで、OO云々とは関係ないよ
あの程度なら、OO的じゃなくても出来るし、現にやってきたよ
低レベルSEの、啓蒙にはいいかもしれないねどね。
464 ：デフォルトの名無しさん：01/10/29 17:55
>>433
>人の作った個人レベルの巨大ｸﾗｽﾗｲﾌﾞﾗﾘなどとても使えたものではない。
>OOで再利用性の高いものを作る事は非常に困難な作業。

そんなの使い方を理解していないだけだろう。
クラスライブラリだからこそ再利用できると思うんだが？
だいたい、OOでもないものは理解したところで、その場しのぎの
関数、特定の型に特化した関数などにならざるを得ず、
OOに比べて再利用が効かないことが多い。

その点、OOは委譲、継承、多態性などを使い再利用性が向上する
ものだと思う。
465 ：デフォルトの名無しさん：01/10/29 17:57
>>463
良い例えだな。アルゴリズム辞典が非常に役立つように、
デザパタも役立つ。
あの程度をやってきたと豪語するのはアルゴリズムなど全部
自分で発見したと豪語するに等しい。（ｗ
466 ：デフォルトの名無しさん：01/10/29 17:58
>462

明らかにオブジェクト指向信者の自作自演

いつも通りの妄想爆発でバレバレ
467 ：デフォルトの名無しさん：01/10/29 17:58
なんか>>463て実はデザインパターン読んでなさそう。
468 ：デフォルトの名無しさん：01/10/29 18:01
>>465
いってることが理解できてないよ。

>>あの程度をやってきたと豪語するのはアルゴリズムなど全部
>>自分で発見したと豪語するに等しい。（ｗ

そんな天才じゃない。
OOやデザパタ以前から、本読んで勉強してたって事
469 ：デフォルトの名無しさん：01/10/29 18:04
まともなSEが、アルゴリズム辞典最高って声高に言ってたら、やっぱ馬鹿っぽいよ
470 ：デフォルトの名無しさん：01/10/29 18:06
>>464
自己矛盾してる
471 ：デフォルトの名無しさん：01/10/29 18:07
>>468
え？OO以前にデザパタが学べた本ってどういう本？
題名は？
472 ：デフォルトの名無しさん：01/10/29 18:07
>>470
どこが？
473 ：デフォルトの名無しさん：01/10/29 18:08
>>471
デザパタじゃないよ
システム設計の本。
あんた痴呆？
つきあってられないよ
474 ：デフォルトの名無しさん：01/10/29 18:10
デザインパターンがOO以前から出来たなんてほざいてるやつは
なに考えてるんだ。
デザインパターンを待ったく知らないとしか思えん。
475 ：デフォルトの名無しさん：01/10/29 18:12
>>473
発端となった発言は、デザパタをOO的じゃなくても出来るし、
現にやってきたと言っている。
>あの程度なら、OO的じゃなくても出来るし、現にやってきたよ
476 ：デフォルトの名無しさん：01/10/29 18:14
読んでないほうに２０００ペリカ
477 ：デフォルトの名無しさん：01/10/29 18:14
474のオブジェクト信者思考デザインパターン

デザパタの前にパターン無し、デザパタの後にパターン無し。
デザパタこそ、唯一無二のパターン書。
デザパタ読んだ奴なら、誰でもわかる。
（読んでも理解できないバカはのぞく。）
478 ：デフォルトの名無しさん：01/10/29 18:15
そんなことは誰も言ってないYO
479 ：デフォルトの名無しさん：01/10/29 18:17
読んでないほうへ50万ﾍﾟｿ
480 ：デフォルトの名無しさん：01/10/29 18:18
＞475
＞デザパタをOO的じゃなくても出来るし、
デザパタじゃなくて同レベルのシステム開発ってことでしょ、たぶん
481 ：デフォルトの名無しさん：01/10/29 18:18
>>477
そんなこと誰も言っていないし、デザパタがOOでないという
意見に反対してるだけだと思うけど。
482 ：デフォルトの名無しさん：01/10/29 18:18
>>466
OOとは一言も書いてないと思うが？（ｗ
483 ：デフォルトの名無しさん：01/10/29 18:19
>>480
デザパタと同レベルって何？
そこをちゃんと定義してよ。
デザパタと同じ設計ならOOでしょ。
484 ：デフォルトの名無しさん：01/10/29 18:20
ﾔﾊﾟｰﾘ読んでない。。。
485 ：デフォルトの名無しさん：01/10/29 18:21
また始まった
読んでない 理解してない 理解できないバカ････
しかも根拠がない
否定すれば 勝手に妄想で人物像作成･･･
読んでれば否定するはずないという信者思想
鬱なｽﾚだ･･･
486 ：デフォルトの名無しさん：01/10/29 18:22
>>485
おいおい、根拠も何も、この状況を見れば
読んでないことは明らかだろ。（ﾜﾗﾜﾗ
それか、わざと知らない振りしたネタかもな。
487 ：デフォルトの名無しさん：01/10/29 18:22
おまえら、マ板でグローバル変数がどうとか言ってた奴らだろ。
488 ：デフォルトの名無しさん：01/10/29 18:25

不毛な議論はやめたらどうでしょう？
なんでそんなに熱くなっているのでしょうか？
489 ：デフォルトの名無しさん：01/10/29 18:26
>>488
面白いからだと思われ。
490 ：デフォルトの名無しさん：01/10/29 18:26
おまえら、デザパタ読んでるとか読んでないとか、くだらないＹＯ！
だいたい、決めつけ以外でどうやって証明するの？
491 ：デフォルトの名無しさん：01/10/29 18:29
>>474のオブジェクト信者思考デザインパターン
（藁（藁（藁
492 ：デフォルトの名無しさん：01/10/29 18:31
>>474は正論。デザインパターンを知ってれば明らか。
493 ：デフォルトの名無しさん：01/10/29 18:32
スレ迷走中
494 ：デフォルトの名無しさん：01/10/29 18:32
>>490
知ったかぶりして間違ったこと言ってれば、読んでない
とわかるよ。
495 ：デフォルトの名無しさん：01/10/29 18:32
>>485
まったく。

自分が知らないことは素直に「知らない」と言えば良いのに、そこで「俺が知らない知識はクズ」と
言いがかりをつけるから話がこじれる。新しい知識を吸収するのが嫌だって人間には、プログラマ
は向いてない。本人のためにも周囲の人間のためにも、速やかな転職を勧める。
496 ：327=332：01/10/29 18:33
>>485

そういうスレなんだから、諦めよう。
497 ：デフォルトの名無しさん：01/10/29 18:33
>>492
信者の正論＝世間の非常識
498 ：デフォルトの名無しさん：01/10/29 18:35
>>497
宗教について語る時、その宗教を知っている人間だけが正論を言える。
499 ：デフォルトの名無しさん：01/10/29 18:35
オブジェクト指向が普及しない最大の原因は、
オブジェクト指向を愛する信者がいるせいかも
なんとなくそう思った
500 ：デフォルトの名無しさん：01/10/29 18:37
だいたい、何も知らないくせに批判するのは愚の骨頂だろ。
で、間違ってると指摘されると「この信者め」とキレる。

これが非常におろかなことだと言うことぐらい、いい加減
気付かないかね？
501 ：デフォルトの名無しさん：01/10/29 18:38
>>495
スレ妄想中
502 ：デフォルトの名無しさん：01/10/29 18:39
>>500

> これが非常におろかなことだと言うことぐらい、いい加減
> 気付かないかね？
自分自身に問いかけよ
503 ：デフォルトの名無しさん：01/10/29 18:40
>>502
おいおい。（ｗ
504 ：デフォルトの名無しさん：01/10/29 18:41
>>501-502
オブジェクト指向とデザパタに対する批判（難癖ではなくて技術的な観点からの、まっとうな批判）
はないの？
505 ：デフォルトの名無しさん：01/10/29 18:43
デザパタと同じ設計ならOOだという主張に対する
反論は無いの？
506 ：デフォルトの名無しさん：01/10/29 18:45
デザパタってOO前提じゃん…
507 ：デフォルトの名無しさん：01/10/29 18:45
>>503-505
1人で大変だね
ガンバレ!
508 ：デフォルトの名無しさん：01/10/29 18:46
不毛だ...
509 ：503：01/10/29 18:46
>>507
一人じゃねぇよ。（ｗ
510 ：デフォルトの名無しさん：01/10/29 18:47
これに関しては批判派の大敗だね…
511 ：仕様書無しさん：01/10/29 18:49
>>507
一人なのはお前なんじゃないのか？
512 ：デフォルトの名無しさん：01/10/29 18:49
>>510
くだらない人間･･･
513 ：デフォルトの名無しさん：01/10/29 18:50
なんてﾚﾍﾞﾙの低いｽﾚなんだ
514 ：デフォルトの名無しさん：01/10/29 18:52
スレ迷走中
スレ瞑想中
スレ名僧中
515 ：デフォルトの名無しさん：01/10/29 18:55
>>505
それは、主張が変。

GoF の書籍のタイトルは「オブジェクト指向における再利用のためのデザインパターン」なんだが、
タイトルのとおり、ここで示されているデザインパターンは

1 オブジェクト指向を前提とした上で
2 その中で繰り返し現れる問題に対する解決策

をカタログ化したもの。もちろん、そこで提示されるデザインパターンのいくつかは、非オブジェクト
指向の設計でも使うことができるし、実際に使われてきたものをオブジェクト指向用にまとめなおし
たものもある（と、個人的に思ってる）。

GoF の慧眼は、解決策を再利用可能な形で抽出し、カタログ化したところにある。うまい形で抽出
できたのは、オブジェクト指向設計との相乗効果もあると思うけど。
516 ：デフォルトの名無しさん：01/10/29 18:59
具体的に（藁）聞いてみようよ。
FactoryMethodパターンを、OOを使わずに実現するにはどうやる?
TemplateMethodパターンは?
Commandパターンは?

OOを非OO言語でエミュレートする以外にだよ、もちろん。
517 ：デフォルトの名無しさん：01/10/29 19:00
>>504
難しすぎる。他には……なんだろう。
518 ：デフォルトの名無しさん：01/10/29 19:02
struct obj{
int type;
:
:
};
struct obj1{
int type;
:
:
};
struct obj2{
int type;
:
:
};

struct functable[OBJ_NUM] ={
obj1_func1,
obj2_func1,
obj3_func1
};

void func(struct obj *arg,...){
(*functable[arg->type])(arg,...);
};

多態。

struct obj *fuctory(int type){
struct obj *temp;
switch(type){
case OBJ1:
temp = (struct obj*)malloc(sizeof(struct obj1));
temp->type = OBJ1;
(*init_table[temp->type])(temp);
return temp;
case OBJ2:
temp = (struct obj*)malloc(sizeof(struct obj2));
temp->type = OBJ2;
(*init_table[temp->type])(temp);
return temp;
:
:
}

ファクトリーメソッド、、、、ごめん、なんでも無い。
519 ：デフォルトの名無しさん：01/10/29 19:16
確かに、一部はオブジェクト指向でなくても実現できるかも
しれないが、デザパタはオブジェクト指向を前提としているので
オブジェクト指向で無いといけないものも多い。
だから、デザパタなどオブジェクト指向の利点ではないという
説の根拠にはなりえない。
520 ：デフォルトの名無しさん：01/10/29 19:18
sngletonパターンなどは、オブジェクトに対するパターンという
時点で、OOだね。
521 ：518：01/10/29 19:25
/*singleton.h*/

struct singleton_obj *CreateObj();

/* singleton.c*/

static singleton_obj object;
static int first_tiem = 1;

struct singleton_obj *CreateObj(){
  if(first_time){
    init_singleton_obj(&object);
    first_time = 0;  
  }
  return &object;
}
522 ：デフォルトの名無しさん：01/10/29 19:27
>>521
それはオブジェクト指向言語ではない言語で実装した
オブジェクト指向だろ。
523 ：521：01/10/29 19:30
そうだよ。別に反論してる訳じゃない。
デザパタがOOの利点だ、という事に反論するなら
Alexanderだかなんだか、って名前の建築家出すだ
けで十分だろうし。別に俺、OO嫌いじゃないし。
つまり深い意味は無い。
524 ：デフォルトの名無しさん：01/10/29 19:32
>>518
うん。で、FactoryMethodをオーバーライドする
新たなクラスを加えるときはどうすんの?
既存部分を書き直す？（藁）

次はCommandパターンきぼーん。
525 ：デフォルトの名無しさん：01/10/29 19:34
>>522
ネタでしょ。ふつーは C 言語で書くなら、単に static 変数を状態を確保するのに使って、関数をいくつか
公開して終わりだと思う。

------------------
// singleton 用の static 変数いくつか
static int nCount = 0;
...

void singleton_func1()
{
　　// ファイルスコープ内有効な static 変数を操作する
}

void singleton_func2()
{
　　// ファイルスコープ内有効な static 変数を操作する
}

...
------------------

こういうコードは C でコーディングするときには良く書きます、はい。
526 ：デフォルトの名無しさん：01/10/29 19:51
nCountなんて変数がグローバルにあるのは怖いねぇ。
でも、短いプログラムなら何の問題も無いんだろうね。
527 ：518：01/10/29 19:53
あー、なんでC書くだけでからんでくるのか、と思ったら、、、
ごめん、
>>516
読んでなかった。
間が悪かった訳ね。すまぬ。
528 ：デフォルトの名無しさん：01/10/29 19:59
http://www.amazon.com/exec/obidos/ASIN/0195019199/sr=8-1/qid=1004352948/102-2131554-8216925
529 ：デフォルトの名無しさん：01/10/29 20:00
>>526
モジュール内の static 変数が怖いと言うのは、メンバ変数が怖いと言うのと同義だけど？
もちろんモジュールは小さい単位で分割しておくことが前提ね。

ってＯＯと関係ない話になりつつあるな。sage
530 ：デフォルトの名無しさん：01/10/29 20:05
>>528
もしかして「デザインパターン」はＯＯ以前からあったという実例として、建築でのデザインパターンを挙げてる？
531 ：デフォルトの名無しさん：01/10/29 20:06
>>529
モジュールよりはメンバ変数の方が小さい空間にまとまってると
思うけど。
確かに細かい単位でファイルを分割しておくと怖さは格段に
減るけどね。
532 ：518：01/10/29 20:09
>>530

おれは528じゃないが、なんでそんなにすぐ敵対したがるんだ？
別に敵と味方にわけなくても。
533 ：デフォルトの名無しさん：01/10/29 20:15
>>532
516までの流れを読めば、528が敵対だと取られてもおかしくないと思うが。
534 ：デフォルトの名無しさん：01/10/29 20:16
>>518をみるにつけ、ああ、OOPLてべんりやなぁ、
と思うのは漏れだけ？
535 ：デフォルトの名無しさん：01/10/29 20:17
>>532
真意が良く分からなかったので、聞いてみただけですって。
536 ：デフォルトの名無しさん：01/10/29 20:18
オレなんかGoFがデザインパターンなんて言う前から、
Cでビル作ってたぜっ！！
537 ：532：01/10/29 20:25
>>533

>>523で俺が520だけ読んで、Alexanderの名前を
あやまって出してしまってる。
これから考えれば別にただ参照を書いただけ、と俺は思ったんだが。

>>534
まあ俺のコードは少しおおげさだからなぁ。
関数のポインタと配列使って多態、は結構どのCプログラマも
やるとは思う。確かにちと面倒だが、単純な仕組みでいろいろ
出来る(ただし言語の支援は少ないが)、というのがCらしさだし。

まあ普通は525の言うように、staticな変数使ってモジュール
化する方が多いだろうな。その方法だと複数実体が持てないが、
必要になったら構造体を引数に渡すようなのにすればいい。
538 ：デフォルトの名無しさん：01/10/29 20:35
>>516
みんな只のコールバック関数だ。

>FactoryMethodパターンを、OOを使わずに実現するにはどうやる?
・FactoryMethod のコールバック関数は新たに確保した構造体のポインタを返す。
WINDOW* CreateMyWindow(){
　WINDOW *win = malloc();
　...
　return win;
}
registerCreator(CreateMyWindow);

>TemplateMethodパターンは?
・TemplateMethod は関数群を登録する
typedef int (*FucntionType_I_I)(int);
struct Charactor {
　char name[16];
　FucntionType_I_I fpInit;
　FucntionType_I_I fpPreAction;
　FucntionType_I_I fpPostAction;
};
CreateNewCharactor("giko", InitGiko, NULL, PostGiko);

>Commandパターンは?
・構造体に関数ポインタもたせるだけだが。
struct Command {
　char name[6];
　FucntionType_I_I fpCommand;
};

#OOPLに利点が無いといってるわけではない。こういったことを楽に出来ると思う。
539 ：デフォルトの名無しさん：01/10/29 20:47
>>534
多態でメソッド一つ呼ぶのに、関数のテーブル作るな
んて、今どきやりたくないっス。
あるインターフェースのセットがメソッド一つなんて
あり得ないし、むしろひとつのオブジェクトに複数の
インターフェースのセットを持たせたい場合のほうが
多い。非OOPLでオブジェクト指向的なことができる
事には異論はないけど、ご苦労さん、としか言えない。
なんだか、その昔、BASICで構造化プログラミングを
やるためのテクニックを雑誌で紹介してた人を思い出
してしまったよ。素直にCを使えよって当時思ったけど
それと似たような感覚です。素直にOOPLつかおよって。
540 ：528：01/10/29 21:00
>>530
別に敵対してるわけでも煽ってるわけでもないよ。
デザインパターンはGoF以前にもあったという事実を提示しただけ。

http://www.hyuki.com/dp/dpfaq.html
http://www-6.ibm.com/jp/developerworks/web/001201/j_lessons.html
541 ：528：01/10/29 21:06
あと（URLがわからなくなってしまったけど）PLoPを見ても、パターンはOOに
限った話というわけでもないことがわかるよ。
542 ：デフォルトの名無しさん：01/10/29 21:07
>>540
GoF のデザインパターンと言った場合には Abstract Factory, Builder, Proxy, Iterator, ... など
例のデザパタ本で提示されたデザインパターンを指すと考えて頂きたく。
（ここで話が噛み合ってなかったのかもしれない）
543 ：528：01/10/29 21:10
>>542
うん、それはそうなんだけど。
パターン→OO、GoF
だから、GoFの○○パターンをOOPL以外の言語で書けるのか？
っているのは、ちょっと変と思ったまで。
544 ：デフォルトの名無しさん：01/10/29 21:13
ていうかデザインパターンはカタログなんだから、そこに
集められているパターンの元が以前からあったのは当たり前。
ただし、オブジェクト指向で開発する上で起こる問題への解決
策というところに焦点があって、非OOPLでオブジェクト指向
するためのテクニックという意味でのパターンじゃないよ。
だから、いくらCでオブジェクト指向的なことをするためのコー
ドを示してみてもあまり意味はないと思われ。
カプセル化とは逆の方向へいってるし。(w
545 ：デフォルトの名無しさん：01/10/29 21:18
要するにGoFのデザインパターンがこの世に初めて出た概念だと
勘違いした厨房が、煽ってはみたものの、自爆したってことですな。
546 ：544：01/10/29 21:19
>>544
GoFのね。
547 ：デフォルトの名無しさん：01/10/29 21:23
>>545
見事に的を外しきった要約にﾜﾗﾀ
548 ：デフォルトの名無しさん：01/10/29 21:27
>>542

うーむ、パターン、というと、普通にスレッド等で
出てくるボス-ワーカーとかああいうのもパターンだと思うが。
パターンが優れてる、だと、抽出して名前をつけて共通の知識
にした所が優れてる(俺はGoF等はここが画期的だと思う)のか、
特定のパターンの集まりが優れているのか、どっちなのかあまり自明
じゃないと思うが。
少なくともGoF見て、あれでやってる事を知らなかった、
と思わない人は結構いると思う。委譲と継承(及びその結果としての多態)
の具体例がダラダラのってるだけに過ぎない。
名前を付けて共通の語彙にした所が偉いと思う。

>>539

そこはアブストラクトファクトリー使って一回の呼び出しで
関数テーブルを要素にもった構造体を保持すればいいんだよ(嘘)
549 ：デフォルトの名無しさん：01/10/29 21:36
>>545
そうじゃなくってGoFのデザインパターンは『オブジェクト指向で』
の種々の問題の解決法をまとめたものなのに、CでGoFのパターンをやって
たとエラソーに称する厨房がいたから紛糾したんだよ。
自動車の運転術の書かれた本の話をしていたら、
『バイクでも走れるぜ！』って会話に割り込んできたDQNみたいなもので
問題の焦点が違うから同じ次元で話せないっつうの。
ちなみにGoFのパターンはCで無理矢理オブジェクト指向したコードから
抽出したんじゃなくて、SmallTalkのライブラリなんかで使われてた
パターンを抽出したもんじゃないの？
550 ：デフォルトの名無しさん：01/10/29 21:36
すいません、初心者質問です。

クラスＡおよびそれを派生させたＢとＣというクラスをもつ
ライブラリを作りました。

このライブラリを使って新たなプログラムを組むときに
Ａの持つメンバの一部だけを継承させたいＤが発生したため
Ａの一部をＡbaseというクラスにして、ＡはＡbaseを派生させる
ことにしました。
Ｂ，Ｃは今までどおりＡから派生し、ＤはＡbaseから派生する
ことになります。

という状況はＯＯの再利用的にはもう失敗ですか？
551 ：デフォルトの名無しさん：01/10/29 21:41
>>548
> そこはアブストラクトファクトリー使って一回の呼び出しで
> 関数テーブルを要素にもった構造体を保持すればいいんだよ(嘘)
結局自前でテーブル管理する事にはかわりないし。C++使います。
552 ：548：01/10/29 21:44
>>551

俺もC++使う。
553 ：デフォルトの名無しさん：01/10/29 21:45
>>551
ネタだって。548 は計算づくですよ、角度とか。
554 ：デフォルトの名無しさん：01/10/29 21:47
そうそう、角度が重要でした。
逝ってきます。
555 ：デフォルトの名無しさん：01/10/29 21:54
>>550
ライブラリのドメイン依存性（ある特定の問題領域の解決にどの程度特化しているか）や
粒度の大きさ（抽象度と言い換えてもいい）を再確認しよう。
依存性が高いか、粒度が小さいならば再利用が難しいのは明らか。

二つの戦略がある。（粒度の使い方が適当でないかも）
・再利用性を高めるためにドメイン依存をなくし、粒度を大きめにとる
・生産性を高めるためにドメインに特化し、粒度も適当に小さくする
はっきり言って前者は相当しんどい。
標準クラスライブラリ並みの作りこみが必要だし、
どうしたってドメインに依存せざるを得ない
（比較的依存しない部分は標準クラスライブラリでほとんど賄われているわけだし）。

だからデザインパターン（作り方・設計）を（再）利用して、
実際に作るのは後者でいいやんというのが現状。

実装の継承による差分プログラミングが有効なのは
もちろん親子直系のクラスツリーを作るときだけだよな。
それって結構範囲が狭い。
556 ：デフォルトの名無しさん：01/10/29 22:03
できれば日本語で話して欲しいな。
557 ：デフォルトの名無しさん：01/10/29 22:05
>>556
コメント先を明記したほうが良いと思われ。
558 ：sage：01/10/29 22:07
結論： ＯＯは必要不可欠。ＯＯＰＬ使わずとも良いが、ＯＯＰＬを無様に
まねる不要な苦労を背負い込むだけ。

============================終=======了============================
559 ：デフォルトの名無しさん：01/10/29 22:09
難しい宗教用語は説明つけて欲しい。アブストラクトファクトリーとか。
560 ：デフォルトの名無しさん：01/10/29 22:10
んでもって生産性の問題は放置ですか？

========================再＝＝＝＝＝開===============================
561 ：デフォルトの名無しさん：01/10/29 22:10
>>558
OOPLの機能を非OOPLで実現するみたいな話に
聞こえるかもしれないけど、元々の話の趣旨は違うよ。
562 ：デフォルトの名無しさん：01/10/29 22:11
>>559
デザパタ読んでないですか?
563 ：518：01/10/29 22:12
俺のは別にOOがいらない、とか、Cで全部出来るぜっ!とか、
そういう話のつもりじゃなくて、たんなる小ネタだったん
だが。どうも話を曲げてしまったようで。
気にせず続けてくれ。
564 ：デフォルトの名無しさん：01/10/29 22:13
>>559
いつも、デザパタ読んでないと言われている私ですが、
あなたは本当に読んでませんね。
565 ：デフォルトの名無しさん：01/10/29 22:13
>>559
なんで、そう喧嘩腰でくるかなぁ。

とりあえず google で検索してみましょう。このスレッドで出てきた代表的なパターンに関しては
一通り解説が見つかるはずです。もちろん、デザパタ本を読んでも良いですけど。
566 ：デフォルトの名無しさん：01/10/29 22:18
>>560
ネタを振らないと、続かんぞ。
567 ：デフォルトの名無しさん：01/10/29 22:18

デザパタでスゲーってのは初心者の可能性が高いが

アルゴリズム辞典でスゲーってのは普通だと思うぞ
568 ：デフォルトの名無しさん：01/10/29 22:20
>>560
デザパタが使えればそれなりに生産性があがる。
以上
569 ：デフォルトの名無しさん：01/10/29 22:21
終わった……。
570 ：デフォルトの名無しさん：01/10/29 22:22
>>567
熟練者がデザパタを絶賛しています。
571 ：デフォルトの名無しさん：01/10/29 22:22
>>568
デザパタそのものはどこで手に入りますか？アブストラクトファクトリーとか。
572 ：デフォルトの名無しさん：01/10/29 22:24
>>567
みんな、初めての時の感動を忘れてるんだよ。
573 ：デフォルトの名無しさん：01/10/29 22:24
>>571
角度を計算しましょう。
574 ：デフォルトの名無しさん：01/10/29 22:24
>>571
インターネットや書籍で手に入ります。（ﾌﾟ
575 ：５６７：01/10/29 22:25

>>570

まぁいいけど
576 ：デフォルトの名無しさん：01/10/29 22:26
チェインオブレスポンシビリティー
577 ：デフォルトの名無しさん：01/10/29 22:27
>>571
その質問、

　アルゴリズムそのものはどこで手に入りますか？　クイックソートとか。

と近いものがあるが。意味が良く分からん。

知識を仕入れたいなら「オブジェクト指向における再利用のためのデザインパターン」という本を買って
きて読むのが確実。実装が欲しいなら、それは自分で書くもの。
578 ：デフォルトの名無しさん：01/10/29 22:28
ttp://wiki.cs.uiuc.edu/PatternStories/DesignPatterns
まあ一応有名所、という事で。
579 ：デフォルトの名無しさん：01/10/29 22:28
デザパタの凄さわからない？
方法論のテンプレートを作り上げたことで、共通認識
が出来、パターンに関する情報交換が容易になった。
頭の中できちんと分類して整理できるようになった。

例えば、「数字」がなければ数学は発展しなかった。
580 ：デフォルトの名無しさん：01/10/29 22:28
私もデザパタを発明しました。皆さんで使ってください。

ＤｏｒａｅｍｏｎＰｏｃｋｅｔ
581 ：デフォルトの名無しさん：01/10/29 22:29
ふらいうぇいとぉ
582 ：５６７：01/10/29 22:30

>>579

パターン化は功績だけどさ

パターンの内容の事ね
583 ：デフォルトの名無しさん：01/10/29 22:31
またまた発明しました。どうぞ使ってください。

ＤｏｋｏｄｅｍｏＤｏｏｒ
584 ：デフォルトの名無しさん：01/10/29 22:35
テム、プレートメソッドッ
585 ：デフォルトの名無しさん：01/10/29 22:35
>>582
かなりのエキスパートでも十分役に立つ内容だと思う。
その証拠に、「オブジェクト指向による再利用のための
デザインパターン」のまえがきで、Grady Boochですら、
多くを学んだと言っている。
最初は著者達も全てを理解していなかったと書いてある。
586 ：デフォルトの名無しさん：01/10/29 22:41
>>582
ほんとうに GoF のデザインパターンのすべてを自分で考えていたのなら、それは天才と呼ぶに
値します。

それだけ優秀な人間なら、今でも GoF が見落としている有用なデザインパターンや、デザインパ
ターンとは別の切り口からソフトウェア設計に寄与する考察をお持ちでしょうから、ぜひとも本を
執筆して世に広めて頂きたく思います。

……いや、ホントに。日本発のソフトウェア設計技法が世界を席巻するのを見てみたいよ。
587 ：デフォルトの名無しさん：01/10/29 22:58
んじゃドキュメント・ビューアーキテクチャ。
588 ：デフォルトの名無しさん：01/10/29 22:59
それはアンチ・デザインパターン
589 ：デフォルトの名無しさん：01/10/29 23:02
なぜアンチに分類される？
590 ：デフォルトの名無しさん：01/10/29 23:10

>>585,586

あれ読んだ時ってあるあるとかつかわねーとかそんなかんじ

というかアルゴリズムスゲーだろっていいたかっただけ
591 ：デフォルトの名無しさん：01/10/29 23:13
ＧＵＩパーツだとホントに巧くいくんだよなー。
それ以外は芳しくない。
592 ：デフォルトの名無しさん：01/10/29 23:16
誰か相手してやれよ。なんか哀れになってきたよ
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=333&forum=7&start=30&36
593 ：デフォルトの名無しさん：01/10/29 23:21
オブジェクト指向を学べば学ぶほど生産性（つうかコード書く効率）
が落ち行くんですが祟りでしょうか？
594 ：デフォルトの名無しさん：01/10/29 23:23
Exceptional C++読んでからコードを書く速度が落ちた。

たたられてる
595 ：デフォルトの名無しさん：01/10/29 23:39
>日本発のソフトウェア設計技法が世界を席巻するのを
リ、Lyee……
596 ：デフォルトの名無しさん：01/10/29 23:39
>>593
デザパタぐらい読んでから出直しましょう。
597 ：デフォルトの名無しさん：01/10/29 23:41
>>594
ああ、それは私も祟られてる。逆にいうと、それまで書いてたコードがアレなんだけど。

>>595
Lyee とシグマは禁句とさせて頂きます。
598 ：デフォルトの名無しさん：01/10/29 23:42
誰かBASIC(素の)でOOやデザパタをやってみてくれ。
599 ：デフォルトの名無しさん：01/10/29 23:43
こんなんもあるね
http://www.atmarkit.co.jp/fdotnet/opinion/kawamata/2001_10.html
600 ：デフォルトの名無しさん：01/10/29 23:48
設計するときは、廃棄コストのことも考えましょう
601 ：デフォルトの名無しさん：01/10/29 23:50
>>599
厨房は年取っても厨房って事だね…
こいつが公開してるソフトもcygwin入れればすむようなのばっか。
602 ：デフォルトの名無しさん：01/10/29 23:51
>>599
それは >>436 で既出。しかも >>438 で一蹴されて終わってる。
603 ：デフォルトの名無しさん：01/10/30 00:21
プロジェクトのアーキテクトレベルの人たちに、早くデザパタの知識を
吸収して欲しい。
本を読むと、システムアナリストみたいな職種の人たちがいるみたいだけど、
日本にもいるの？
大企業にはいるのかなー？
俺の周りには、一人もいねー。
604 ：デフォルトの名無しさん：01/10/30 00:26
>603
大企業にはいないと思われます。

>600
ホントだよ
再利用のことしか考えてないやつは終わってる
捨てるときのことも考えてくれ
605 ：デフォルトの名無しさん：01/10/30 01:35
再利用しやすいコードはコードのコピーの依存が少ない
から廃棄もしやすいと思うが。
606 ：デフォルトの名無しさん：01/10/30 02:07
つうか、あんなデザパタそんな使う場面ないぞ。
うう、Ｃ＋＋に戻りたい。戻ってクラス使ったり使わなかったり
関数の直近に配列並べて（クラスだと離れるんで遅くなる）書きたい。
607 ：デフォルトの名無しさん：01/10/30 02:07
炊飯器の制御でデザパタ使いたいんですがどうしたら良いのでしょうか？
608 ：デフォルトの名無しさん：01/10/30 02:12
あとエッチゲームスクリプトも是非デザパタならではの凄い技術で
イカしたいんですけど
609 ：デフォルトの名無しさん：01/10/30 02:18
>>606
設計からコーディングまでデザパタ使いまくりですが、何か？
610 ：デフォルトの名無しさん：01/10/30 02:21
>>609
>>606 あんなデザパタ
あんなが指すのが何かちと不明だったね。スマソ。
GoF は良く使ってる。それ以外はあまり使わないな。
611 ：デフォルトの名無しさん：01/10/30 02:57
オブジェクト指向スレは、いつ見ても2chらしいぞゴルァ
612 ：デフォルトの名無しさん：01/10/30 03:05
こんなに盛り上がるほどオブジェクト指向は複雑なのか、日曜PGの
漏れは近づかないでおこう…
613 ：デフォルトの名無しさん：01/10/30 03:15
>>612
むしろ、サンデープログラマ向きかも。
大人数での開発は、難しい処理を、いかに簡単に記述するかに気を配る。
必要ない再利用のために、簡単な処理を複雑にしたりはしない。
１人で全部開発するなら、気のすむまでコードをこねくり回せる。
614 ：デフォルトの名無しさん：01/10/30 04:05
>>613
だからデザパタは「パターンを言語化した」つまり
大人数で「ああ、あのパターンね」で話が通じるようにした
から偉大だというに…

読んでから言えって。
615 ：デフォルトの名無しさん：01/10/30 04:11
>>612
OOPはオブジェクトを組み合わせてプログラムする。
構造化は関数を組み合わせてプログラムする。
それだけのこと。
616 ：デフォルトの名無しさん：01/10/30 04:15
>>615
センセ〜、うちの構造化COBOLには関数がありましぇん！
617 ：デフォルトの名無しさん：01/10/30 04:21
>>614

何を主張しているのか良くわからないのですが。
パターン化したことがOOの優位性なのですか？
他の手法でもパターン化していると思いますが。
それともOOのデザパタが有名になったから、
OOは偉大だと言いたいのでしょうか？

613がデザパタを読んでいるのかは知りませんが、
読んでいないとわかるのはリーディング能力ですか？
618 ：デフォルトの名無しさん：01/10/30 04:27
>>615 ツッコミ処がありすぎる(藁)
619 ：デフォルトの名無しさん：01/10/30 04:40
うちの会社では、スケルトンと呼ばれるパターンが、２００程ある。
カスタマイズできるように記述された、仕様書つきのソースの事ね。
もちろん、スケルトン部分のテストは完了している。
620 ：デフォルトの名無しさん：01/10/30 04:49
>>619
そういうテンプレートライブラリみたいのをパターンと呼んじゃうのか。

デザイン・パターンはもう少し抽象度が上だ。ライブラリ化はできない。
（Observerみたいな単純なのを除けば。）ライブラリ化してもしょうが
ない。読めば分かるはずだが…
621 ：デフォルトの名無しさん：01/10/30 04:55
613=ＯＯを理解できぬまま一線を引いた川俣晶
622 ：デフォルトの名無しさん：01/10/30 05:01
>>620
アーキテクチャレベルのもあるが、実装臭いのもある。
623 ：デフォルトの名無しさん：01/10/30 05:08
たしかに、デザパタの有効性の話は、オブジェクト指向の本質とは関連が薄いかな。
624 ：デフォルトの名無しさん：01/10/30 05:11
夜更かしはシワの元
625 ：デフォルトの名無しさん：01/10/30 05:14
早起きは三文の得

>>623
同感
626 ：デフォルトの名無しさん：01/10/30 05:16

ここで話してる、オブジェクト指向って何ですか？誰か定義してください
627 ：デフォルトの名無しさん：01/10/30 05:20
>>623 >>625

おれも同感
628 ：デフォルトの名無しさん：01/10/30 05:25
> 626
何でしょうねぇ。よく構造化と比較してる人がいるけど、
構造化のほとんどは、OOに含まれてるし
629 ：　：01/10/30 05:47
オブジェクト指向＝オナニー
630 ：デフォルトの名無しさん：01/10/30 05:58
クラス化されたソース、見にくい、つーか醜い。醜さgoto乱発型並。

本当にクラス化って使いやすい（再利用しやすい）の？ねえ？
ウチのとこ、クラス化（パッケ化）されているソースより、Ｃの単発関数ｲﾊﾟｰｲ
の方が再使用率高いんだけど。
最初はみんな躍起になってクラス化したさ。でも、結局辿り着いたのが、関数単位
での再利用だったなぁ・・・

Ｃマンセー
631 ：デフォルトの名無しさん：01/10/30 06:04
>>630
再利用の定義を述べよ
632 ：デフォルトの名無しさん：01/10/30 06:45
オブジェクト指向の定義だ？
識別出来る、データを持つ、自律的振舞いをする、の3つ
の性質持つ物をオブジェクトとして、そのオブジェクト
の組み合わせで何かをする事が定義なんじゃないの？
633 ：デフォルトの名無しさん：01/10/30 06:52
>>632
このスレで議論されているオブジェクト指向は、
少なくともそんなものではないとおもわれ
そんな定義されてもこまる
634 ：雑魚：01/10/30 07:42
こういうスレが立つ原因は

・構造化＝OOと勘違いした奴。
・classという予約名を利用しただけのクラス

にあると思われる。
635 ：デフォルトの名無しさん：01/10/30 08:58
>>630
ある関数の定義を変更することになったとして、その影響がどのプログラムの
どこに現れるか、予想できる？

一群の関数が互いの実装に依存し合っているようなとき、
ドキュメントに不備があったら保守できなくなると思うが。
636 ：デフォルトの名無しさん：01/10/30 09:31
>>635

パブリックな関数で無ければどうって事無いし、
パブリックな関数の変更も、インターフェース
がかわらなければ問題は無い事多いし。
ヘッダファイルに公開されてる関数の実装に依存
しあうコードがあったら、その時点で問題あり
だと思うが。別に俺は630じゃないが。
637 ：デフォルトの名無しさん：01/10/30 13:10
>>636
>パブリックな関数で無ければどうって事無いし、

grepで済むと言えば言える。
でも、副作用がある関数の場合、実装依存のコードが
呼び出し側にあるかどうかは自明ではないよね。

>パブリックな関数の変更も、インターフェース
>がかわらなければ問題は無い事多いし。

同上。問題がないことが保証されていないことが問題なのです。

>ヘッダファイルに公開されてる関数の実装に依存
>しあうコードがあったら、その時点で問題あり
>だと思うが。

副作用のない関数であればそうだけどね。
638 ：デフォルトの名無しさん：01/10/30 13:21
>>637
「副作用」とか「実装依存」の言葉の意味わかって使ってる？
639 ：デフォルトの名無しさん：01/10/30 13:38
>>636
>ヘッダファイルに公開されてる関数の実装に依存
>しあうコードがあったら、その時点で問題あり

理想はそうだが、現実はそうはいかない。
業務アプリケーションで無理に凝集度を高めようとすると
クラスが肥大してしまう。
640 ：637：01/10/30 13:56
>>638
わかっていますが、それがなにか？

>>640
異論はありませんが、僕は非OOでいいじゃん、という人に反論しているのですが？
641 ：デフォルトの名無しさん：01/10/30 14:11
>>640
「副作用」も「実装依存」も、ある特定の文脈でよく使われる言葉。
それ以外の文脈で使われても意味が良く分からない（俺も>>637が
何をいわんとしているのか読み取れない）。

マギレのある言葉を使うより、普通の言葉で語るのが一番だと思うよ。
642 ：637：01/10/30 14:44
>>641
本当にわからないのか。
だったら書くけど。

たとえばC言語の場合、あるポインタで参照されるオブジェクトを
任意のビットイメージとしてアクセスすることは可能なので、
プログラムの複数の個所からそのオブジェクトを読み書きすることが
可能となる。
ある関数を実行すると、
そのオブジェクトにある特定の操作が行われる実装であるということを、
関数を利用する側が知っているとして、その実装に依存したコードを
呼び出し側で書いてしまうことは皆無とは言えない（たとえば、その
関数を呼び出すと、そのオブジェクトの初期化「も」やってくれると
「わかっている」ので、
（その関数本来の目的ではなく）オブジェクトの初期化のために
その関数を利用するというようなケース）。

要するに、副作用のある関数について、どこまでが契約範囲かが明瞭
ではないということ。ドキュメントに書かれていないことは仕様ではない、
という作業上のルールを作っても、
アンドキュメントな部分を根絶することは現実的にはまず無理だし、
ソースコードにアクセスできる奴は、
アンドキュメントな部分を利用する危険があるわけだよ。
643 ：デフォルトの名無しさん：01/10/30 15:34
>>642
>たとえばC言語の場合、あるポインタで参照されるオブジェクトを
>任意のビットイメージとしてアクセスすることは可能なので、
これはC++でも同じだろ。キャストできちゃうのがいかんといってるだけじゃん

>プログラムの複数の個所からそのオブジェクトを読み書きすることが可能となる。
どんな言語だってそうだろうが。(除く関数型）

>ある関数を実行すると、
>そのオブジェクトにある特定の操作が行われる実装であるということを、
>…
これはOOとは関係ない。たとえばデータベースのテーブルを現すシングルトンクラスで
instance()呼び出しが毎回データベースにアクセスして最新の情報をもってくることを
想定したプログラムはいとも感単にかけてしまうぞ

>要するに、副作用のある関数について、どこまでが契約範囲かが明瞭
>ではないということ。
激しく同意するが、非OOだからというわけじゃないだろ。MeyerのいうようにASSERTをいれ
まくればすむことだ。

>アンドキュメントな部分を根絶することは現実的にはまず無理だし、
>ソースコードにアクセスできる奴は、
>アンドキュメントな部分を利用する危険があるわけだよ。
そのとおり。だからpublicな関数とファイル内の関数を使い分けてるのでは
644 ：デフォルトの名無しさん：01/10/30 16:50
>>634
構造化＝OOと勘違いした奴もいるが、それよりはるかに、
構造化＝OOと全く違う(または対立する)概念と勘違いした奴の方が多い。
たぶんきみ。
645 ：デフォルトの名無しさん：01/10/30 17:21
>>630
関数の再利用だけを考えてるなら、クラスという縛りが存在する
ことが余計に思えるかも知れないけど、部品としての再利用を考え
るとオブジェクト指向の方が楽だと思うけどね。
部品そのものが再利用できるケースなんてそうそうないと、言いた
いのだろうと思うんだけど、それは部品の継承図の中にすべての
実装を書いちゃうのが問題なので、オブジェクトの振る舞いに注目
して再利用出来そうなインターフェースを抽出して継承図の外側に
放り出してクラスをかけば、関数レベルでのライブラリ以上の柔軟
性が出ると思うのだけど。
次に部品を作る時は、良くある振る舞いに関しては、インターフェース
継承して委譲。これ最強。
646 ：デフォルトの名無しさん：01/10/30 17:27
＞＞６４５
Ｃ＋＋だとめんどい。
647 ：デフォルトの名無しさん：01/10/30 17:36
>>642
本当にしらないようだから書くけど。

>そのオブジェクトにある特定の操作が行われる実装であるということを、
>関数を利用する側が知っているとして、その実装に依存した

そういうのは"実装依存"とは表現しない。

>副作用のある関数

似たようなカンジだけど、やっぱりその文脈で"副作用"はおかしい。
648 ：デフォルトの名無しさん：01/10/30 17:41
>>647
いや、副作用のほうはそれでいいかと。
俺もその文脈では使わないけど、言われればわかる。
649 ：637：01/10/30 17:46
関数の処理において、引数をもとに戻り値を算出する以外の処理を
「副作用」side effect
っていうんだよ。

関数型言語とか学べばわかる。
650 ：デフォルトの名無しさん：01/10/30 17:52
うーん、結局637は何を主張したいわけ？
ちゃんとドキュメントを書けという主張？
「副作用」もドキュメントに書けば「副作用」ではなくなるのかな？
651 ：デフォルトの名無しさん：01/10/30 17:55
>>650
ん？
副作用、ってのはset!とかの事。
ドキュメントに書こうとなんだろうと副作用だぞ。
俺は637じゃないし、どうでもいいが。
652 ：デフォルトの名無しさん：01/10/30 17:59
副作用って、呼び出し側の状態を変えることを言うんじゃないの？
>>649の定義は広すぎる気がする。
653 ：637：01/10/30 18:03
俺の言いたいことは、
ソースコードを読めば、そのクラスなりメソッドなりが
何に責任を持っているか明確であるべきだっていうこと。

OOでも十分ではないが、構造化プログラミング時代の
サブルーチンによる再利用よりはマシになったと思う。

それが俺の主張。

個人的には強い型付けを持った関数型言語に期待を抱いているが、
OOすら理解できないプログラマが少ないということらしいから、
なかなか普及しないだろうな、とか思ったり。
654 ：なんだかね：01/10/30 18:07
「ドキュメントに副作用をかいておかないと混乱する」
なんて主張を読んだ時点で「おぃおぃ」と思う人間が多数。
655 ：デフォルトの名無しさん：01/10/30 18:08
>>653
>ソースコードを読めば、そのクラスなりメソッドなりが
>何に責任を持っているか明確であるべきだっていうこと。

べきもなにも、ソースを読めば明確になるでしょ、OOに限らず。

>OOでも十分ではないが、構造化プログラミング時代の
>サブルーチンによる再利用よりはマシになったと思う。

なぜマシになったと思うの？
副作用とか実装依存とかは、どうからんでくるの？
656 ：636：01/10/30 18:23
漏れへのレスが元らしいので。

＞でも、副作用がある関数の場合、実装依存のコードが
＞呼び出し側にあるかどうかは自明ではないよね。

まあそうだが。
でも参照渡しな引数いじっちゃうと外に影響与えちゃう、
というのはC++等にも同じ問題があるな。ゲッタ等のアク
セサを適切に作ればだいぶマシ、というのはわかるが。
Cでもコーディング規約というかスタイルとして、直接
引数の構造体に触ったりせずに、公開関数の引数に渡す、
という方法のみで触るようにする、という感じならC++と
大差無い程度の被害にはおさえられると思うがどう？
まあ保証はされないからC++よりも弱いけどな。
規約、というのは、コードの一部見てもわからんで、
実際に使われてる所みないとわからんからね。
でも自分一人で書く場合は保証は出来るが。共同作業じゃ
出来ないな。
657 ：デフォルトの名無しさん：01/10/30 18:35
あー、やっとわかった。

・アンドキュメントな処理がある関数がある。
・誰かがそのソースを調べて、その副作用を知った。
・その処理を行わせるのが目的でその関数を呼んだ。

一方、呼び出される方の関数を変更しようとした場合に、
・アンドキュメントな部分に依存している「呼び出し側」が存在するかもしれない
・なので、アンドキュメントな部分を変更したときに、影響範囲がわからない

ということでしょ？
でもそれってOOと何の関係もないと思うんだけど。
658 ：656：01/10/30 18:58
>>657
637がどういう意図かは637にきかないと本当の所はわからんが、
おそらく文章の流れでいけば、複数実体を持つ、というような
事に関しての俺の考え(っていうかC流)の穴をついてるんだろ。

つまり

/* some_file.h */

char *get_result(); /* strcpyして使う事 */

/* some_file.c */

static char result[256];

char *get_result(){
return result;
}

としたresultを直接さわる馬鹿がいるのは防げない。
で、複数の所からこのモジュール使う場合、
どうしても内部構造を一瞬はさらけ出すからな、Cは。
文字列、程度ならいいけど、構造体、とかを返す場合、
その構造体の内部に依存した変更、ってのの被害は
でかい。

C++なら、
class some_class{
public:
void print();
void set_char(int index,int char);
:
:
private:
char result[256];
};

みたいなクラスのインスタンスを「それぞれ」が保持す
れば、resultみたいなの触らずとも複数実体が持てるし、
公開部分以外の変更には強い、って事だろう。
実際に触るのは上のabstractな関数のみのクラスのイン
スタンスをファクトリーメソッドあたりの後で隠す事に
なるだろうから、触るのは違反だし(キャストとか、コ
ンパイラの吐くフィールドのオフセット依存な事とか
をやられると困るが、Cよりはずっとマシ)

ちなみに一つのみしか実体が無いでも問題無い、という
場合なら、return resultなどやらずにresultへのアク
セサだけを公開してやるで十分だろう。
どちらかといえば抽象データ型の話だな。まあOO好きな
皆様にC派の俺がいっても釈迦に説法だろうが。
659 ：デフォルトの名無しさん：01/10/30 19:22
>>658
同意。

Cでも抽象データ型を使って「インターフェースへプログラミングする」
書き方は可能だ。その場合、デザインパターンの恩恵を受けられる事も
多い。（継承を利用するのは面倒だが、コンポジションに基づくパターン
なら。）

しかし、「オブジェクト指向だとコード書くのが面倒くさい」と言ってる
人は、そうやってインターフェースをきちんと定義する事じたいを面倒く
さがってるんだろ？ 中身が丸見えの、アクセスを全く制限しないコード
の方が「保守性が高い」と言い張ってるんだよね？
660 ：637：01/10/30 19:34
>>658、>>659
まとめてくれてthanx.

ちなみにC++をOO側の代表格にする傾向があるけど、
OO派はC++を評価してないよね。
だからC++では駄目、だからOOは駄目、
という論法はいかがなものかと。
ここでの議論でも明らかになったように、
油断していると実装の抽象化が弱くなってしまう弱点が
C++にはあるよな（他にもたくさん弱点はある）。

アンチOOな方々はEiffelとかSmalltalkとかをどう評価
してるのかな。今更Eiffelを学ぶより、その学習時間を
Cでコーディングするのにあてる方が生産性が高いって
意見は否定しないけど。
661 ：637：01/10/30 19:45
>>655
>>ソースコードを読めば、そのクラスなりメソッドなりが
>>何に責任を持っているか明確であるべきだっていうこと。
>
>べきもなにも、ソースを読めば明確になるでしょ、OOに限らず。

いや、わからない。
ある責任を果たそうとして、
結果としてそのような実装になってしまったのか、
副作用も含めて責任のつもりなのか、
それはコードを見ても自明ではない。
責任がないつもりの部分の実装は将来的に変更され得るが、
コードを利用した側と責任範囲の理解が一致するとは限らない。

>>OOでも十分ではないが、構造化プログラミング時代の
>>サブルーチンによる再利用よりはマシになったと思う。
>
>なぜマシになったと思うの？
>副作用とか実装依存とかは、どうからんでくるの？

インターフェイスと実装が区別されているから。
インターフェイスは責任を表明しており、
将来的にも不変であると期待できる。
実装は変化する可能性が予約されており、
実装に依存したコードを呼び出し側が持つことは、
呼び出し側が契約違反をしたと見ることができる。
662 ：デフォルトの名無しさん：01/10/30 20:08
>>652
定義だから仕方が無い。
この際おぼえておこう。
663 ：656：01/10/30 20:30
>>659
>しかし、「オブジェクト指向だとコード書くのが面倒くさい」と言ってる
>人は、そうやってインターフェースをきちんと定義する事じたいを面倒く
>さがってるんだろ？中身が丸見えの、アクセスを全く制限しないコード

そうでも無い奴もいるだろ。いろんな奴がいると思う。
俺はきちっとしたOOで書くのは面倒だ、と思う。
必要な所だけしっかりと隠せば、他は結構ルーズでも
いい場合も多いのでは無いか、と。
/* somefile.h*/

struct rect{
int x;
int y;
};

struct rect *get_rect();

/*other_file.c*/

struct rect *r;
r = get_rect();
r->x = 1;
r->y = 2;

とやってもいい時はそうやりゃいいし、
set_x(r,1);
set_y(r,2);
とやった方がいい時はそうすりゃいい。
理論上はもちろんこの判断がいつも正しく可能、
という訳では無いが、現実問題としては、他に
いろいろ問題がある事の方が多い、と思う。
664 ：デフォルトの名無しさん：01/10/30 20:37
>>663
ＯＯを使っても、あまりに具体的で抽象化の必要がない
（利益がない）データはもちろんあるよね。Javaだと
PointとかRectangleとか。

しかし「短いほどよい」と主張する川俣某のようなのは
抽象化の利点を全く認めていないらしい。
まあ、こういうのは論外だと思うが。

データ抽象化の延長（の１つ）にＯＯがあるわけだから、
ＯＯ否定派全般に問いたいのは「データ抽象化も否定する
のか」という事だな。
665 ：デフォルトの名無しさん：01/10/30 20:39
>>664
次に問い詰めたいのは「もしデータ抽象を否定するなら、
抽象化全般を否定するのか否か」。
666 ：デフォルトの名無しさん：01/10/30 20:57
>>653
> OOでも十分ではないが、構造化プログラミング時代の
> サブルーチンによる再利用よりはマシになったと思う。
クラスによる縛りが何をもたらすのか、自分自身の中で整理してから発言した方が良いと思うぞ。
自分で分かってると思うが、引数の問題程度なら、C++ならOO的設計じゃなくてもconstで十分だしな。
667 ：デフォルトの名無しさん：01/10/30 21:08
>>666
メガ10
668 ：デフォルトの名無しさん：01/10/30 21:21
>>659
> しかし、「オブジェクト指向だとコード書くのが面倒くさい」と言ってる
面倒というより、不要なメソッドを書くのはムダといってるだけ。
必要なら書けばいい。
さらに、クラス化しなくていいものは、関数で書けばよい。

> 人は、そうやってインターフェースをきちんと定義する事じたいを面倒く
> さがってるんだろ？
ＯＯ以外はインターフェイスが重要じゃないとでも？

> 中身が丸見えの、アクセスを全く制限しないコード
> の方が「保守性が高い」と言い張ってるんだよね？
たぶんわざとだろうが、曲解しすぎ。
クラス化することの利点を、君自身が把握しきれていないのが、
話がややこしくなった原因。
669 ：デフォルトの名無しさん：01/10/30 21:27
ともかく、いらねぇものなんだよ、きっと、オブジェ恥垢
670 ：デフォルトの名無しさん：01/10/30 21:37
>>668
クラスかすることの利点ってナニ？
671 ：664：01/10/30 21:54
>>664
>ＯＯを使っても、あまりに具体的で抽象化の必要がない
>（利益がない）データはもちろんあるよね。Javaだと

まあそうだな。そしてOOを使いたい時、使った方が楽な時、
OOで達成出来る程の拡張性が欲しい時もあるだろう。
別にレジスタやスタック触りたい時や、高階関数使い
たい時もあるだろうが。

全般的(過半数以上)にオブジェクトを使う方がいいか、
要所だけでいいのか、という感じになるとは思う。
俺はGUI回りとかはOO向きな事もあると思うが、
いつでも再利用性がそんなに高い、とは思わない。

少なくともGeckoのhtmlレンダリング部だけ取り出し
て何かやったり、とかは俺には出来ん。
レンダリング部分は、かなり上の層のアブストラクトファクトリー
取り出して描画オブジェクト保持して、それで描画していく
んだが、それと同じ物を用意しよう、と思い、
アブストラクトファクトリーの中から、辞書追って実際の
ファクトリーオブジェクトに辿りつく、というのもとても面倒だし、
その結果作られるファクトリーが作るオブジェクトもさらに遠いい。
描画部分を使うには、使われるのと同じような方法で
全ての部品揃えなきゃいけない。決して一つ下のインターフェース
を揃えれば良い、という感じにはならない。スレッド等からどう使わ
れるのか、とか追うのも大変だ。
Mediatorもちゃんと準備してやらなきゃいけない。他にも準備しな
きゃいけない物はたくさんだ。理屈の上ではネットワークなんて
準備しなくてもローカルのファイル表示、位は出来るはずだが、
やってみるとレンダラーがJavaScript等に依存したり、そいつが
ネットワークに依存してたり。
あれのレンダラーを継承したりコンポジットしたりして拡張して、
別のアプリで使う、なんてやれるもんならやってみて欲しい。
レンダリング担当のオブジェクトだけ使って、描画先の方は自分で
(ファクトリーメソッドとか使わずに、スレッド等も使わずに)用意、
とかは俺には出来ない。
まあ作りの問題、と言われればそうなのかもしれんが。
あれの移植性はアブストラクトファクトリーのおかげで、
上の方気にせずにピアーとなるファクトリー生成回り
作れば出来る、というのはわかるが、再利用はそのまんま使う、
とかじゃないとむずかしいだろう。
Cならもっとマシか、はわからんが。

ファサードの奥には触るな、という事なら、やっぱOOは好きには
なれん。
大規模アプリ用の考えのはずなのに、大規模になりすぎると
いまいちに思える。Cもいまいちだが、他にいい物を知らん。
672 ：663：01/10/30 22:04
ごめん、上の671の書き込み、名前は663だ。
673 ：デフォルトの名無しさん：01/10/30 22:19
>>671
各種バージョンのHTMLに柔軟に対応しつつ、
将来的な拡張にも備えるなんてHTMLレンダラは、
そりゃあ複雑になるわなあ。
どんな仕様が必要か分析・設計するだけで気が遠くなる。
っていうか、オレにはそこまで理解できるかどうか自信がないな。
663=671さんは、HTMLレンダラに求められる仕様や
分析・設計を理解した上でその部品が使いにくいって言ってるの？
674 ：デフォルトの名無しさん：01/10/30 22:24
COMつかって
IEコンポ利用すれば？
675 ：デフォルトの名無しさん：01/10/30 22:26
>>671
Cで、デザインパターンを使わずに書いた方が
良いものになった？
676 ：671：01/10/30 22:28
>>673
自信を持っては言えないが、ある程度は理解してるつもりだ。
実際にああなるのがしょうがない、ってのはわかる。
そしてHTMLレンダラに限らず、大規模アプリはああなるだろう。
そしてそれはCなら簡単、という訳でも無い。

で、大規模アプリでも大差なく俺の目には見えて、小さな
アプリなら利点はあんまし生きない、っていう気が少し
する。まあ大差無い、といってしまえる程違いが小さいか
はCで同レベルの奴が同種のアプリ組まないとわからんけど。
汎用的にやってああしちゃうより、もっと必要な機能と
多少の拡張性程度で我慢して、一定期間たったらソース捨て
るなりリファクタリングするなり、って方が好みだ。

>>674
モジラもXPCOMってのはある。
これもインターフェースのみのプログラミングをサポートする。
ただ細かい事が出来ない。
ちょいとレンダリング回りだけ使って、他のパースとかは全部自前
で用意、とかはちときつい。
IEのCOMはどう？もうちょっと綺麗に部品化されてるの？
677 ：671：01/10/30 22:30
>で、大規模アプリでも大差なく俺の目には見えて、小さな

差は小さい、というのはOOと非OOの保守性、
及び柔軟性ね。移植性は優れている気がするが。
678 ：デフォルトの名無しさん：01/10/30 22:43
ＯＯＰＬにはコーディング速度が落ちていても、上がってると錯覚させる
麻薬的効果があります。
679 ：デフォルトの名無しさん：01/10/30 22:55
俺的には、OOの方がプログラムの正しさ（堅牢さ）を検証しやすく感じる。
あと、分析・設計工程が非OOのときには職人芸的になりやすいのに対して、
OOの方が普遍的・体系的にできる感触があるな。

一方でコーディング量が増えるってのはあるかも。
XP的には「機能は必要になってから追加しろ」だけど、
ついつい「使いそうな機能」を片端から実装しそうになる。
まったく利用されないメソッドを書いてしまったことが
ないかどうか検証したことはないけれど、
きっとあるんじゃないかって気がする。

OOの方が高品質・高価格な高級車（凡庸だけど、間違いがない）、
よく書かれた非OOは無駄を省いてスピード命なカスタムカーって気がするな。
680 ：デフォルトの名無しさん：01/10/30 22:58
コーディング速度＝生産性な方々が羨ましい...
681 ：デフォルトの名無しさん：01/10/30 23:39
ＯＯＰＬを使用しない場合でも、
関数をまたがるような共通情報へのアクセスは、
アクセス関数を通して行うのが常套手段。
共通情報の変更に対応しやすくなるし、
アクセス関数以外からはデータは保護される。
参照型のアクセス関数を使用している限り、
データが更新されないことが保証される。

で、ＯＯＰＬを使用してこれをクラス化すると、
記述がすっきりする。
これが、クラス化する最大のメリット。
682 ：デフォルトの名無しさん：01/10/30 23:40
>>637
OO肯定派です。
Eiffelは好きな言語です。
C++はきらいです。
683 ：デフォルトの名無しさん：01/10/30 23:53
せっかくよぉ、がんばって憶えたんだからよぉ
幻想なんてゆうなよぉ
ちゃんとつかえるんだしよぉ
684 ：デフォルトの名無しさん：01/10/31 00:10
>>681
クラス化すれば、継承できるし、多態が実現できる。
そういうメリットもある。
685 ：デフォルトの名無しさん：01/10/31 00:12
道具の説明書を読んで、機能と使い方を理解しても、
道具がうまく使えるようになるわけではない。
実際に何度も使ってみて、その道具に向いた部分はどこか、
他の道具の方がよい部分はどこかがわかってくる。

うまく使いさえすれば、いつでもどこでも使える道具など、
存在するわけがない。
686 ：デフォルトの名無しさん：01/10/31 00:12
クラス化しなければ学級崩壊もないYO!
687 ：デフォルトの名無しさん：01/10/31 00:14
>>684
多態はメリットであるが、継承はデメリットである。
更に言えば、クラスと多態に直接的な因果関係はない。
688 ：デフォルトの名無しさん：01/10/31 00:22
継承がデメリットなの？
689 ：デフォルトの名無しさん：01/10/31 00:23
単純に継承をデメリットというのは語弊があるかも。
単一継承をベースに抽象クラスを用いた設計から、
インターフェース継承を主軸において、委譲ベースの
設計へ移行しよう、って言ってるのだと思う。
690 ：デフォルトの名無しさん：01/10/31 00:28
なんだJava信者の意見か。
691 ：デフォルトの名無しさん：01/10/31 00:29
>>689
それは否定しないが Mixin もしくは実装継承があると、便利な場面も多い。使い方間違えると
末代まで呪われるけど。
692 ：デフォルトの名無しさん：01/10/31 00:32
>>689
現状ではそうだが、少し違う。

継承を全廃し、インターフェイスの別実装により
多態を行い、メソッドの動的入れ替えにより
差分プログラミングを行う、なんてのが良いかなと
空想している。
693 ：デフォルトの名無しさん：01/10/31 00:35
>>692
面白そうなんで、サンプルコードっぽい何かを希望。
694 ：デフォルトの名無しさん：01/10/31 00:35
>>690
Java の予約語の interface とインターフェイスとを区別しようね。
695 ：689：01/10/31 00:36
Java使いじゃないです。C++使いでもないです。
むしろMixinマンセー。(謎
696 ：デフォルトの名無しさん：01/10/31 00:36
>>693
いや、そういう言語が出来ないと、既存言語では記述が大変だ。
697 ：デフォルトの名無しさん：01/10/31 00:36
>>687
Eiffelみたい表明があれば継承のデメリットはなくなる。(ほとんど)
Sather, Oberon にもあると思う。
JAVAはiContactがある。
698 ：デフォルトの名無しさん：01/10/31 00:37
プロトタイプベース？
699 ：デフォルトの名無しさん：01/10/31 00:40
>>696
「そういう言語」で書いたサンプル出せば良いのでは？　既存の言語の話してるわけじゃないから、
意味がとおれば何でも良いでしょ。
700 ：デフォルトの名無しさん：01/10/31 00:40
>>698は>>692に対してです、はい。
701 ：デフォルトの名無しさん：01/10/31 00:42
>>699
空想の段階なので、記述までは考えていない。
702 ：デフォルトの名無しさん：01/10/31 00:46
Eiffelはrenameしちゃえるんでしたっけ？
CLOSとかはどんなもんですか？
詳しい方、解説きぼんぬ。
703 ：デフォルトの名無しさん：01/10/31 00:47
>>692
Rubyコードだけどこんなん？

module M
def foo
print "foo"
end
end

class C; end

obj = C.new
obj.extend(M)
obj.foo #=> foo
704 ：デフォルトの名無しさん：01/10/31 00:47
実装継承は、使う方にはカスタマイズ等できて便利だが、
実装継承した物を、テスト・メンテナンス・再利用するのは困難だ。
大規模開発では致命傷になりかねない。
要は、多態や差分プログラミングの利点を、継承無しで得られればよい。
705 ：デフォルトの名無しさん：01/10/31 00:48
理想論だが、
こういう言語を作る系の話題には、
ぜひLISPコードでやりとりしてもらいたいもんだ。
仕様を詰める作業も、実際に動くモノがあると効率が違ってくる。
Ｓ式が透過していないのが残念。
706 ：デフォルトの名無しさん：01/10/31 00:50
>>703
特異メソッドだっけ？
オーソドックスなオブジェクト指向に慣れた人は、
「それ反則っ！」て叫んじゃいそうな機能だよね‥‥。
707 ：デフォルトの名無しさん：01/10/31 00:52
>>706
もっと直接的にはこうだね。
たまに使うと便利な局面がある。

def obj.foo
print "特異めそど"
end
708 ：デフォルトの名無しさん：01/10/31 00:53
>>704
Mixin継承とかは再利用性高いと思ってるんだけどねぇ。
どんなもん？
709 ：デフォルトの名無しさん：01/10/31 00:54
オブジェクト指向反対！
コーディング効率を昔に戻そう！
デザパタ帰れ！
710 ：デフォルトの名無しさん：01/10/31 00:56
>>707
クラスに対してもインスタンスに対しても特異メソッドを
加えられるんだったよね？たしか。
初めて仕様を読んだ時、「何でもありかよっ！」て
思ったものだ‥‥。
711 ：デフォルトの名無しさん：01/10/31 00:59
そのまま実装を継承するのが嫌なら
オーバーライドすればいいじゃん。
普通virtualつけとくでしょ？
712 ：デフォルトの名無しさん：01/10/31 01:01
結局、継承には使い方を間違えればデメリットな点もあるけど、
メリットも多いので存在価値があるということで、終了ですか？
713 ：デフォルトの名無しさん：01/10/31 01:03
>>710
クラスもインスタンスもオブジェクトだからね。
組み込みクラスのメソッドも再定義できるし、
eval 系メソッドでカプセル化壊せるしで、
何でもありというか放任主義的というか。
ま、Ruby 自体の話は関係ないのでsage。
714 ：デフォルトの名無しさん：01/10/31 01:04
　ｱﾋｬｱﾋｬｱﾋｬ　ココは批判スレじゃ　　　　　　　　　　　　,,从.ノ巛ミ　　　 彡ミ彡）ミ彡ミ彡ミ彡）ミ彡)''"
　　＿＿＿　　　　　　　　　　　　　　　　　　　　　 人ノﾞ　⌒ヽ　　　　　　　　　彡ミ彡）ミ彡）ミ彡)'
　/ｏ＿☆⊥　　　　　　　　　　　　　　,,..､;;:〜''"ﾞﾞ　　　　　　 ）　　从　　　　ミ彡ミ彡）ミ彡,,）
∠=√ﾟ∀ﾟ ）　　　　　_,,..､;;:〜-:''"ﾞ⌒ﾞ　　　　　　　　　　彡　,,　　　　 ⌒ヽ　　　　　　彡"
|　（:::..､===m==<|::::::ﾞ:ﾞ　　　　　　　現実　　　　　　　　　　　'"ﾞ　　　　　　　　　 ミ彡）彡OO信者
|_=|:::. |::.　| '　　　　｀`ﾞ⌒｀ﾞ"''〜-､:;;,_　　　　　　　　　　　　　　）　　 彡,,ノ彡〜''"　　　　　　彡
　（＿_）＿）　　　　　　　　　　　　　　ﾞ⌒｀ﾞ"''〜-､,,　　　　 ,,彡⌒''〜''"人　ヽﾉ　从.　从　人人
　　　　　　　　　　　　　　　　　　　　　　　　　　　　"⌒''〜"　　　　　　し（_＿）　⊂⌒~⊃｡Д｡）⊃
715 ：デフォルトの名無しさん：01/10/31 01:05
だって、型が無いので、コンパイル時に決定する必要が無いから、
動的に何でもできる。なんでもあり言うならLisp系の言語の方が
なんでもありでしょう。
ま、そのかわり、コンパイル時の検証は犠牲になる。
716 ：デフォルトの名無しさん：01/10/31 01:06
>>711

問題の本質がわかってないYO!
717 ：デフォルトの名無しさん：01/10/31 01:07
>>716
本質とは？
718 ：デフォルトの名無しさん：01/10/31 01:09
>712
704 も言ってるけど、継承そのものにメリットはないのでは？
目的ではなく手段なのだから、当たり前といえば当たり前だけど
719 ：デフォルトの名無しさん：01/10/31 01:10
>>718
有効な手段なら、それをメリットと言わない？
720 ：デフォルトの名無しさん：01/10/31 01:11
704は、ただ困難だと言い放ってるだけで何も説得力が無いな･･･
721 ：デフォルトの名無しさん：01/10/31 01:12
>719
言わないと思う
有効な手段によって得られた物がメリットでしょ
結局、手段は変わってもよいわけで
722 ：デフォルトの名無しさん：01/10/31 01:13
>>721
アホか。言葉遊びやってるんじゃないんだから。（ｗ
723 ：デフォルトの名無しさん：01/10/31 01:13
ていうか継承のメリットについて話がでた直後ではなかったか？
724 ：デフォルトの名無しさん：01/10/31 01:13
>>702
class A feature
　　r is do ... end　　　-- *1
end

class B feature
　　r is do ... end　　　-- *2
end

class C inherit
　　A rename r as r1 end
　　B rename r as r2 end
feature
　　r is do ... end　　　-- *3
end

a: A ; create a　　-- コンストラクタ
a. r 　　-- *1

c: C ; create c
c. r1　　-- *1

a := c
a. r 　　-- *1
725 ：デフォルトの名無しさん：01/10/31 01:13
現実の設計開発レベルまで達してないのがまだ多いな
726 ：デフォルトの名無しさん：01/10/31 01:14
>>720
実装出せとは言わんが、せめて「こんな感じ」って実感できるサンプル／仕様概要ぐらいは
出してもらわんと、妄想と区別がつかんわな。
727 ：デフォルトの名無しさん：01/10/31 01:14
>>721
継承の代替になるものなんて有る？それはなに？
728 ：デフォルトの名無しさん：01/10/31 01:16
プロトタイプベースのオブジェクト指向の方が良いと言いたいんだろうか？
でもそれが言いたいからって、継承にメリットが無いといきなり主張するのは
誤解を招くだろ。
〜に比べてメリットが無いという言い方しないと。
729 ：702：01/10/31 01:17
>>724
サンクス。
安心して多重継承を使えそうですね………。
730 ：sage：01/10/31 01:21
とりあえずC++ならメンバ関数へのポインタを持たせれば済みそう。

だがそれはあまりOOとは関係ないな
731 ：デフォルトの名無しさん：01/10/31 01:25
>>730

OOはCだと実装できないとか、そういうのはないと思われる
つまるところ、言語の記述方法の問題じゃない?
732 ：デフォルトの名無しさん：01/10/31 01:35
自分が継承したいのと、他人に継承させたくないのの、違いだな。
部下の作ったプログラムを、結合テストしてみれば、分かると思うが。
実際やったことのない事を想像するのは、不可能な話だが。
733 ：デフォルトの名無しさん：01/10/31 01:36
>>731
ま、たしかに初期のC++コンパイラはCへのトランスレータ
（プリプロセッサ）だったが…

人間がプリプロセッサがわりやるのも切ないっしょ？
734 ：デフォルトの名無しさん：01/10/31 01:46
>>732
何の話だ？
735 ：デフォルトの名無しさん：01/10/31 01:46
>>732
うちのかーチャンは、
「おまえも親になれば、親の気持ちがわかる。」
って言いますが、これは逃げですか？
736 ：デフォルトの名無しさん：01/10/31 01:49
>>734-735
放置しといてやれよ。技術論でついていけなくなったから、話題を摩り替えただけだろ。
737 ：デフォルトの名無しさん：01/10/31 01:56
>>733

まあね
でも言語仕様に、指向が左右されなくても良いでしょ
指向を適切に表現できる言語は欲しいけど
738 ：724：01/10/31 01:57
>>702　　参考になればうれしいです。
class A feature
　　r is do ... end　　　-- *1
end

class B inherit A redefine r end
feature
　　r is do ... end　　　-- *2
end

class C inherit A redefine r end
feature
　　r is do ... end　　　-- *3
end

class D inherit
　　　　　　A rename r as r1 end
　　　　　　B rename r as r2 select r2 end
feature
　　r is do ... end　　　-- *4
end

d: D ;　create d　　-- コンストラクタ
a := d
a. r 　　-- *2　　select r2　　(r1 or r2)?
739 ：デフォルトの名無しさん：01/10/31 01:58
>>736
技術論(藁
740 ：デフォルトの名無しさん：01/10/31 02:04
> 735
おまえのかーチャンが、逃げで使っているか、デベソかはしらん。しかし言ってることは真実である。
741 ：デフォルトの名無しさん：01/10/31 02:07
信者は移動してください
http://pc.2ch.net/test/read.cgi/tech/1002523282/l50
742 ：デフォルトの名無しさん：01/10/31 02:14
>>738
いい気にならないで下さい
スレ違いです
http://pc.2ch.net/test/read.cgi/tech/1002523282/l50
743 ：738：01/10/31 02:20
>>742
>スレ違いです
そのとおりです。すみません。
744 ：デフォルトの名無しさん：01/10/31 02:23
ＯＯ信者も反ＯＯ派も、ＯＯって事でスレ統一すべきでは？
745 ：デフォルトの名無しさん ：01/10/31 02:34
御部塾徒至高の内縁、外苑、族生ってどういう意味ですか？
746 ：ＯＯ神：01/10/31 02:44
信者に告げる････このスレを聖地とせよ
747 ：デフォルトの名無しさん：01/10/31 02:48
ビエーン、OOなんて良く分からないし、キライだ〜い。
ぼくのおうちから出てってよ〜！
748 ：デフォルトの名無しさん：01/10/31 02:57
ＯＯ神様のお告げは絶対です。
全てはＯＯ神様の御心のままに。
749 ：デフォルトの名無しさん：01/10/31 03:12
正直OOPの話は飽き飽きしたから、
業務分析でのOO話を聞きたいな。
アナリシスパターン、前に似た
ようなスレで薦められたけど、
高くてまだ読んでないｗ
750 ：デフォルトの名無しさん：01/10/31 03:28
>>749
開発−クラス設計−詳細設計−基本設計−要件定義−業務分析と、
人数はピラミッド型になっている。
最初は数人で業務分析を始め、フェーズが進むにつれ増員していく。
つまり、業務分析経験者は非常に少ない。
当然だが、業務分析には業務の知識が必要。
設計の知識だけでは、どうにもならない。
751 ：749：01/10/31 03:41
>つまり、業務分析経験者は非常に少ない
基本的にこの辺をやっている人が
少ないから話題にならないのか・・・

>−要件定義−業務分析
この辺りの現状把握から課題の発見にどうOO的な
ものが生かされるのかなって思ってました。
板違いとは思うけど情報システム板はあれだしで、
もっとここでそういった作業についての話もありかな
と思う次第です。
752 ：デフォルトの名無しさん：01/10/31 03:59
業務分析を行う人は、大抵その特定の業種に特化している。
（大学でその分野を専攻していたとか、一時その業界にいた等。）
これは、業務知識の吸収に、非常に時間がかかるため。
違う業種の人間どうしで、話がかみ合うかは疑問だ。
753 ：749：01/10/31 04:19
>>752
なるほどね。こういったことを真面目に
議論しだすと時間を無駄に過ごすことになりそう。
やっぱり実装屋はおとなしく自分のテリトリーだけを
考えているのがいいだろうね。

XMLのスキーマ定義にしても業界別に独自に実装して
たりしてなんか無駄なことをしてるように見えてました。
最大公約数的なものがあればそれを規定して、
業界固有のものはその上に実装すればいいのにな、と。

その考え方自体がだめだめですね（ｗ
754 ：デフォルトの名無しさん：01/10/31 04:33
>>753
何が良くて何がダメかは、一概には言えない。
理論で良くても、実践してみたらダメと言うこともある。
演繹と帰納を繰り返して、グレーな落としどころを決めるのが、
プロの仕事だと思う。
755 ：749：01/10/31 04:58
>>754
理論と実践は両輪、どのレベルでもそういうものですかね。
今度アナリシスパターンやビジネスモデリングの
本でも読んでみます。そうでないとあなたとの話も続かないｗ
756 ：738：01/10/31 05:39
>>702　　>>738の訂正
class D inherit
　　　　　　B rename r as r1 end
　　　　　　C rename r as r2 select r2 end
feature
　　r is do ... end　　　-- *4
end

d: D ;　create d　　-- コンストラクタ
a: A
a := d
a. r 　　-- *3　　select r2　　(r1 or r2)?
スレ違いですみません。
757 ：デフォルトの名無しさん：01/10/31 05:43
これからはrubyだね。
758 ：デフォルトの名無しさん：01/10/31 05:54
>>756
安心しろ、既にこのスレはＯＯ肯定派が占拠した。
759 ：デフォルトの名無しさん：01/10/31 06:02
rubyの指輪
眠いよママ
760 ：デフォルトの名無しさん：01/10/31 08:17
一晩たったら、死ぬほどつまらなくなってた。
無駄かも知れないけど、巻き直すかな。

抽象データ型の有用性は否定されてないよね？

Cから構造体をなくそう、とかいう奴いる？
761 ：671：01/10/31 08:24
>>760

いや、もう終わった、という方向で...
762 ：デフォルトの名無しさん：01/10/31 08:33
>1
オブジェクト指向の何が嫌かって、やってるヤツの大半がキチガイだってこと。
オブジェクト指向自体は悪くないと思うが・・・
キチガイがプロジェクト組む、人間関係崩壊->オブジェクト指向は幻想
これが実態なんじゃねえの？
763 ：デフォルトの名無しさん：01/10/31 08:58
抽象化って何? Cプログラマだからわかんない。
764 ：デフォルトの名無しさん：01/10/31 09:03
バリアントだろ（ﾜら
765 ：デフォルトの名無しさん：01/10/31 09:08
オブジェクト指向でプログラミングできるプログラマは１０人に一人。
オブジェクト指向で設計できるＳＥは３０人に一人。
これ定説です。
Ｊａｖａを採用してるプロジェクトでも、オブジェクト指向らしい設計やコードは、ほとんど見られません。
これも定説です。
766 ：デフォルトの名無しさん ：01/10/31 09:22
Subject-Orientedってないの？
とおもって検索したら山のように出てきた
http://www.research.ibm.com/sop/　こんなのとか

これはいかに？
767 ：デフォルトの名無しさん：01/10/31 09:28
大量に糞話題並べても、ＯＯで生産性が下がる現実は変わりません。
信者ども必死だな　藁
768 ：デフォルトの名無しさん：01/10/31 09:29
オブジェクト指向らしいってどういうこと？
おバカＣプログラマだからわかんない。
769 ：デフォルトの名無しさん：01/10/31 09:36
関数呼び出しではなく、オブジェクトにメッセージを送って
動かすのでないとオブジェクト指向らしいとは言わないのです。
770 ：デフォルトの名無しさん：01/10/31 09:36
オブジェクト指向の破綻は明らかです。
オブジェクト指向では世界は救えません。
そろそろ新しい方法論を探す時期でしょう。
771 ：デフォルトの名無しさん：01/10/31 09:38
生産性ってのが、
仕様どおりのプログラムを実装するスピードのことを指しているのなら、
OOに利はないよね。

OOの価値は再利用性にもあるけれど、再利用できる部品を作るのはOOで
あっても難しい。だから再利用性を主目的にOOを導入するとがっかりす
る。

むしろ、拡張性とか保守性とか堅牢さとかに注目すると、OOっていいな
あって思うと思うよ。仕様書どおりにコーディングするだけのプログラ
マには、OOなんかうざいだけかも知れないけどね。
772 ：デフォルトの名無しさん：01/10/31 09:41
＞仕様書どおりにコーディングするだけのプログラマには、OOなんかうざいだけかも知れないけどね。

だからそう言ってるじゃん。
773 ：デフォルトの名無しさん：01/10/31 09:54
>>771
>あって思うと思うよ。仕様書どおりにコーディングするだけのプログラ
>マには、OOなんかうざいだけかも知れないけどね。

ＰＧって仕様書どおりに作るのが普通だろ。
「この仕様書だせえ」とか言って、勝手に作るＰＧはむしろ馬鹿。
774 ：デフォルトの名無しさん：01/10/31 09:59
>ＰＧって仕様書どおりに作るのが普通だろ。
>「この仕様書だせえ」とか言って、勝手に作るＰＧはむしろ馬鹿。

これは、ＳＥ−ＰＧという日本の請負会社の形態。
あなたの会社はいずれ干上がるでしょう。
775 ：デフォルトの名無しさん：01/10/31 10:08
海外でも仕様書を勝手に変えちゃうＰＧなんていません。
776 ：デフォルトの名無しさん：01/10/31 10:12
>海外でも仕様書を勝手に変えちゃうＰＧなんていません。

馬鹿なやつぅ。
海外ではＰＧ（Software Engineer。ＳＥではない）が仕様決めるんだＹＯ！
777 ：デフォルトの名無しさん：01/10/31 10:15
ようするに学習曲線の立上りがなだらか過ぎるのが問題なんだろ?

数学も理科も英語も何年も何年も学校で勉強したところでろくに理解できない
程度の才能なのに、一朝一夕でOO習得できるようなつもりでいるのが勘違い。

ま、OOに限らないけどね。習得に時間がかかるものすべてにあてはまる。
高度なアルゴリズムとか。
778 ：デフォルトの名無しさん：01/10/31 10:18
付け加えると、日本のＳＥ−ＰＧという形態に問題があるんでは。>>777

ＰＧだとどんな言語でも有無を言えずＯＪＴ習得するが、
ＳＥだとＣ言語知ってるだけでスキルらしいからねぇ。
779 ：デフォルトの名無しさん：01/10/31 10:23
ＰＧがＯＯＰすると、クラスがそのまんま仕様書になるから、便利。
ＳＥが作る仕様書なんてお絵かき。文献にもなってなくて日本のソフトウェアに影響を全く与えた無い。

再利用が難しいって、難しいと思う人が居るかもしれんが、
ＰＧは何も言わずクラスライブラリ派生してプログラミングしてるぞ。
だから、ウィンドウ開くのも数行で出来るが、それ使わなきゃあ、Win環境ではウィンドウ一枚開くにも１ＫＳｔｅｐかかるよ。
780 ：デフォルトの名無しさん：01/10/31 10:30
ある現実にあるもの（オブジェクト）を想定して、
その構造体とアクセス関数郡を作るのはコード上に現れてないものを常に意識しているので非常にストレスがかかる。コメントも必要。

ＯＯＰだと、あるものを○○クラスとして記述し、それが行うこと（業務）を
○○メソッドとして書いておくと、あっという間に塗り絵の枠（フレームワーク）が完成する。
その塗り絵の枠の中身を埋めるのは簡単なので、初心者にも精神的に楽だＺＯ！
781 ：デフォルトの名無しさん：01/10/31 10:31
ＰＧ上がりのＳＥには優秀な人もいるけどね。
ＰＧ経験の無いＳＥだとまずもってＯＯは望めないから悲惨。
782 ：デフォルトの名無しさん：01/10/31 10:40
なんか見えてきましたね。
ウォーターフォール型の開発で何の問題もないって話なら、
OOPはいらないよね。それで納品先は満足してるの？
追加仕様に対してリーズナブルな価格を設定できています？
仕様を追加したくても、高価すぎて我慢するクライアントっていませんか？

プログラマの都合でクライアントを泣かせてたら、
クライアントも発注しなくなるよね。

クライアントも未来を予知できるわけじゃないから、
どういう機能が必要か、前もって完璧に知ることはできない
（クライアントをとりまく環境は刻々と変化しているから）。

なんつーか、SEの言いなりになって仕事をしていれば食べられる
というプログラマって人種が、いつまで残っているか、危機感ないの？
って感じですな。
783 ：デフォルトの名無しさん：01/10/31 10:43
>>775
馬鹿なやつぅ（ｗ
784 ：デフォルトの名無しさん：01/10/31 10:47
ＳＥ−ＰＧっていう形態は日本だけなの？
785 ：デフォルトの名無しさん：01/10/31 10:56
役割の名称が違うってだけ。
むしろ海外のほうが役割が細分化されてる。
ＰＧが仕様を決めるなんていってるのは、大規模開発を知らないDQN。
786 ：デフォルトの名無しさん：01/10/31 11:00
>>785
詳細きぼんぬ
787 ：デフォルトの名無しさん：01/10/31 11:04
ちょう、ダメダメ君ですねぇ。

>役割の名称が違うってだけ。

System Engineerに該当するものは無い。てゆうかなんでSEがEngineeerなの？

>ＰＧが仕様を決めるなんていってるのは、大規模開発を知らないDQN。

大規模開発マンセー（ＳＥ）が日本のソフトウェア産業をダメにしたんだよ。
基本ソフト（OS,Compiler,DB,Web環境，，，）は全部海外製品。
日本の”大規模開発やりましたＳＥ”が海外行ってみろ、
「コード読めないのに仕様書書きたいって？コード書く気無いって、あんた誰？」状態だＹＯ！
788 ：デフォルトの名無しさん：01/10/31 11:07
理屈で考えてもそうだろ、
コードが読めないＳヨが、OO言語コンパイラ開発のプロジェクトリーダできるか？
不要なんだよ、ふよう！
このスレに日本のＳＥが出てくることがおかしいＹＯ！
789 ：デフォルトの名無しさん：01/10/31 11:12
まぁアメリカにおける技術者に対する評価、待遇は日本に比べて格段に上だわな
790 ：デフォルトの名無しさん：01/10/31 11:13
>>787
それが現実
791 ：デフォルトの名無しさん：01/10/31 11:21
分析も設計もコーディングも出来ない人のことをなんでSEというのですか？
792 ：デフォルトの名無しさん：01/10/31 11:24
そもそもシステム板のダメッぷりが日本のソフトウェア業界を
よく表していると思います。べつにここの板が格段に優れている
わけじゃないですが。
793 ：デフォルトの名無しさん：01/10/31 11:37
>分析も設計もコーディングも出来ない人のことをなんでSEというのですか？

お茶汲みを社長秘書と呼ぶでＳＹＯ！
794 ：デフォルトの名無しさん：01/10/31 11:40
大規模開発が日本のソフトをだめにしたってのも、なんか一面的な
見方だよな。
795 ：デフォルトの名無しさん：01/10/31 11:44
なんか、アメリカまんせーなヤツが多いな。
まあ、日本にいて目立つ部分ばっかり見てるとそうなるのも
無理はないかな。
796 ：デフォルトの名無しさん：01/10/31 11:45
わかったよ。
本当に技術力があるやつの給料が低いっていうのと、
本来頭のいいやつが楽して生きようとすることが問題。
いいかこれで?
797 ：デフォルトの名無しさん：01/10/31 11:51
>大規模開発が日本のソフトをだめにしたってのも、なんか一面的な

ＳＥの得意な読み替えですね。
大規模開発がじゃなく、ＳＥが日本のソフト産業をダメにしたですが。

>なんか、アメリカまんせーなヤツが多いな。
>まあ、日本にいて目立つ部分ばっかり見てるとそうなるのも

どこの製品使ってる？

>本当に技術力があるやつの給料が低いっていうのと、
>本来頭のいいやつが楽して生きようとすることが問題。

スレに関係無いやん。
798 ：デフォルトの名無しさん：01/10/31 11:55
>本来頭のいいやつが楽して生きようとすることが問題。
破綻（デスマーチ）招いてる時点で頭悪いんだけどね・・
799 ：デフォルトの名無しさん：01/10/31 12:00
>大規模開発マンセーＳＥが日本のソフトウェア産業をダメにした

汎用機−ＣＯＢＯＬ開発、が主流でそれに膨大な人材が使われた時代があった。
例えば、汎用機（か激安マシン）−独自で生産性がＣＯＢＯＬより上言語、ってのをその時代に作っとけば、
日本の言語やマシンが主流になってたかもしれない。
だが、日本のＳＥは海外製品に慣らされる豚で、進捗管理だけやってた。本人は満足。

同じように、ＯＯ当たり前の時代に、時代遅れな意見を逝ってると、歴史を繰り返すだけだＺＯ！
800 ：デフォルトの名無しさん：01/10/31 12:31
昼休みカキコ
もし神がプログラミングするなら、OOは使わないだろうな。
どんなに巨大なプログラムでも全体から詳細まで把握してプログラムできるなら、
OOで無駄なポインタのやり取りなどせず書いたほうが効率がいいだろう。
でも自分は人間だから、脳内スタックがすぐ足りなくなるのでどうしても
OOに頼らざるを得ない。
801 ：デフォルトの名無しさん：01/10/31 12:36
>>800
OOも使えないボケプログラマは死刑でよろしいですか？
802 ：デフォルトの名無しさん：01/10/31 12:59
>>801
スタックが足りてるならいーんじゃない。
803 ：デフォルトの名無しさん：01/10/31 13:08
>>801
了承する。

>>802
OOが使えない時点でスタックは足りてない。
804 ：デフォルトの名無しさん：01/10/31 13:16
>>800「神は数学を必要としない」って誰の言葉だっけ？
モトネタだとOOが数学なんじゃなかったっけ？
805 ：デフォルトの名無しさん：01/10/31 13:27
>>801
多分、プログラマと名乗ってるブビ坊だろう。
いっしょにＳヨもシマツしてくれよＮＡ！
806 ：デフォルトの名無しさん：01/10/31 14:21
＜記事に関する補足または反論＞

> http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20001025/1/
の記事では再利用性が高くない原因としてＳＥの技術力にだけ言及してます
が、違う理由もあるというのが私の意見です。

１．まず吉田弘一郎氏が「極めるJava」という本で述べておりますが
「クラスライブラリは排他的である」ということです。C++とJavaのクラス
ライブラリは互換性がありませんし、C++でもプラットホームが違えば
（少なくともバイナリレベルの）互換性はありませんし、同一言語でもMFCと
OWLは互換性がありません、同じ開発環境でもバージョンが違うと互換性が
ないこともあります。

２．また、仮に同一プラットホーム同一開発環境でのシステム開発があった
としても、一方では例えばどこかの会社の顧客管理システムで他方では例えば
どこかのＨＰの伝言板ＣＧＩの開発だったりした場合、どんなにうまく設計
しても再利用できるクラスはかなり限定されることでしょう。

つまり記事に出てるように高い再利用性を実現するためには（ＪＡＶＡを除いては）
必ず同一プラットホームで、なるべく同一の言語で、なるべく同一の開発環境
で、なるべく開発環境は同一バージョンで、なるべく似たようなソフト開発の
プロジェクトに限られてくると思われます。特に受託系ソフト会社においてはこんなのは
レアケースです。きっと世の中にはUNIX用のＣ言語の汎用ライブラリを作った
と思ったら会社の方針でWin用VBにメイン開発環境が移り、VB用の汎用ライブラリ
を作ったと思ったら会社の方針でJAVAにメイン開発環境が移ったなんて人もいると思います。

決して記事にあるような
>「できるエンジニアが少ない」
という原因分析を否定する訳ではありませんが、（気持ちとしてはしたいけど）
原因の比率としては上記のような「クラスライブラリの互換性のなさ」の方が
はるかに大きいというのが私の意見です。いかがでしょうか。

記事にあるような高い再利用性を実現するためにはプラットホーム間、言語間の
（バイナリレベルでの）高い互換性を実現すべきだと思ってますが、その可能性が
あるのは現在のところオブジェクト指向という「手法」ではなくＪＡＶＡという
「実行環境」だけなのです。（あぁ！ここで「ＪＡＶＡに言語間の互換性なんてないじゃん」
と突っ込みの返信を返そうと思ったあなた！（っているの？）まずはこちらをご覧下さい。

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

こーゆーのもあるんです。使ったことはないんで、これに関する質問は投げないで下さい。）

> わざわざサブクラス化して使うように設計することによって、密接に関連した
> 部分を「近い場所」に集めることができて、設計内容の見通しが良くなるとい
> うのが、本当のねらいではないでしょうか。
しかし、オブジェクト指向を推進する学者の方々の当初のねらいとしては継承による「生産性の高さ」
を謳っていたと思います。しかし、結果としてオブジェクト指向は「生産性が高かった」というより
「保守性が高かった」というのが事実だったというのが私の意見です。

長文失礼しました。
807 ：デフォルトの名無しさん：01/10/31 14:23
ageておこう
808 ：デフォルトの名無しさん：01/10/31 14:28
吉田弘一郎出されても・・・
809 ：デフォルトの名無しさん：01/10/31 14:30
>>806
>記事にあるような高い再利用性を実現するためにはプラットホーム間、言語間の
>（バイナリレベルでの）高い互換性を実現すべきだと思ってますが、その可能性が
>あるのは現在のところオブジェクト指向という「手法」ではなくＪＡＶＡという
>「実行環境」だけなのです。

CORBAは？
可能性どころか、現に動いていると思うが？
810 ：デフォルトの名無しさん：01/10/31 14:30
COMは？
811 ：デフォルトの名無しさん：01/10/31 14:32
「極めるJava」って有名なトンデモ本じゃんよ
812 ：デフォルトの名無しさん：01/10/31 14:32
>１．まず吉田弘一郎氏が「極めるJava」という本で述べておりますが
>「クラスライブラリは排他的である」ということです。C++とJavaのクラス
>ライブラリは互換性がありませんし、
パスカルコードをCコンパイラ通してみろ。

>C++でもプラットホームが違えば（少なくともバイナリレベルの）互換性はありませんし、
WinアプリをUNIXで実行してみろ。

>同一言語でもMFCとOWLは互換性がありません、同じ開発環境でもバージョンが違うと互換性が
COBOL85コードをCOBOL2でコンパイルしろＹＯ！
813 ：デフォルトの名無しさん：01/10/31 14:34
>２．また、仮に同一プラットホーム同一開発環境でのシステム開発があった
>としても、一方では例えばどこかの会社の顧客管理システムで他方では例えば
>どこかのＨＰの伝言板ＣＧＩの開発だったりした場合、どんなにうまく設計
>しても再利用できるクラスはかなり限定されることでしょう。

これを可能にするのが分散オブジェクト技術。
　　　　　　　　　　　　^^^^^^^^^^^
814 ：デフォルトの名無しさん：01/10/31 14:36
>>806は以下のコピペだった。ちくしょー。
ttp://java-house.etl.go.jp/ml/archive/j-h-b/038232.html
815 ：デフォルトの名無しさん：01/10/31 14:39
>しかし、オブジェクト指向を推進する学者の方々の当初のねらいとしては
>継承による「生産性の高さ」を謳っていたと思います。
>しかし、結果としてオブジェクト指向は「生産性が高かった」というより
>「保守性が高かった」というのが事実だったというのが私の意見です。

↑キティ
●現実認識間違い・・・継承学者はオブジェクト指向の中核とは見てない
学者はクラスベースのＯＯＰ（継承）を否定してオブジェクトベースマンセーだろうが！
●内容変・・・継承により、「生産性が高かった」というより「保守性が高かった」
コード量が減れば生産性高いだろう。保守性を出すことによって生産性を否定すんなＹＯ！
816 ：デフォルトの名無しさん：01/10/31 14:54
CORBAやCOMがオブジェクト指向の成果なのか…
オブジェクト指向業界は、うまく一般大衆をごましてるよな。
817 ：デフォルトの名無しさん：01/10/31 14:57
>CORBAやCOMがオブジェクト指向の成果なのか…
>816

変なこと書いて、議論をズラスなよ。
「VB-COM」図式は、オブジェクト指向じゃないだろ。MSも認めてる。
VBこそoopに破れた側だよ。
818 ：デフォルトの名無しさん：01/10/31 15:03
結局、Ｃの勝ちってことでよろしいでしょうか？
819 ：デフォルトの名無しさん：01/10/31 15:05
>806
コピペならソースも貼っとけ、ハゲ。
820 ：デフォルトの名無しさん：01/10/31 15:06
>>818
そういうことでよろしいです。
この糞スレが終るなら。（ﾌﾟ
821 ：デフォルトの名無しさん：01/10/31 15:12
そういえばそろそろ次スレの季節だな。
822 ：デフォルトの名無しさん：01/10/31 15:20
あーははっは、うひひゃーっはっはっはっはっは
プ、ひひひひひゃははははははは！
この、、この、、このスレッドおもしろす・・・ププぷひゃーっはっはっはひひひひ・・・
だ、だめだ、笑って話せなくくくくく・・・ぶわーはっはっはっはっは
この、、このスレッドつ、作った・・・くけけけ・・・ひ、人さ、最高にぶぶぶ文才・・・
ぶぶぶぶひゃーひゃっひゃっひゃっひゃーーーーー
ひーひーひー、は、腹痛え・・・腹が・・・腹が・・・は・・・はーっはっははー！
こ、こんなこんなおもしろいすすすスレッドって他に、、他に・・・ぷっ・・・ぷびゃーびびびび！
な、ない・・・あー、も、、もう勘弁して・・・氏んじゃ・・・あーっはっはっは！
や、やばい、明日電車の中、中でわらわら、、笑っちゃいそ・・・そーっそっそっそっそーーー！
とまらねえ、とと、とまらねえ・・・くくくくきゃーきっきっきっきーーー！

--------------------終了--------------------
823 ：デフォルトの名無しさん：01/10/31 15:27
0.3秒で透明あぼ〜んの刑
824 ：デフォルトの名無しさん：01/10/31 15:37
>>822
ﾜﾗﾀ
825 ：デフォルトの名無しさん：01/10/31 18:19
WindowsのDLLとかって、何の言語でコンパイルしたかが重要なの？
826 ：デフォルトの名無しさん：01/10/31 19:41
COMはオブジェクト指向を支える技術の一つだ。

それをオブジェクトとして使うか、ただのライブラリとして使うかは
使用者の問題だ。
クラスライブラリと同じだろ？
827 ：デフォルトの名無しさん：01/10/31 20:43
>>806
よりによって、吉田弘一郎かい（ｗ
828 ：デフォルトの名無しさん：01/10/31 22:43
Eiffelのスレが無くなってるんですけど誰か捨てたりしませんでしたか？
829 ：デフォルトの名無しさん：01/10/31 22:48
>>826
見かけがオブジェクト指向風のライブラリとしてしか使えません。
830 ：デフォルトの名無しさん：01/10/31 23:06
いろんな言語から呼べるクラスライブラリだ。
低調に扱ってくれ
831 ：デフォルトの名無しさん ：01/10/31 23:08
で、やっぱりEiffelスレは亞骨されたのか？
832 ：デフォルトの名無しさん：01/10/31 23:22
このスレって面白いか？
低俗なだけの糞スレだろ
833 ：デフォルトの名無しさん：01/10/31 23:23
>>832
ゴキブリホイホイ、あるいは隔離病棟としての機能は果たしているでしょう。
834 ：デフォルトの名無しさん：01/10/31 23:29
>>829-834
ひかかったゴキブリかよ。
835 ：デフォルトの名無しさん ：01/10/31 23:31
ゴキブルにも自意識はあるんですね
836 ：デフォルトの名無しさん：01/10/31 23:33
そうそう、Ｒｕｂｙって最高ですね。
837 ：デフォルトの名無しさん：01/10/31 23:35
やっぱLispでしょ。
838 ：sage：01/10/31 23:36
いま、このスレッド一気に読みました。
ぼくの立場はCはわかっていて、C++もわかっていて、
最近「憂鬱本」を読んだ程度ですが、

やっぱりOOは理想論

に落ち着きました。「エスペラントを使えば万人が話せていいよね」ぐらい。
結局は「英語（であるところのC）」が使われてるわけですが。

#少なくともC++はCより遅いだろう。
#プログラマの開発効率考えて、プログラムの実行速度が遅くなるのって、
#プログラマとしてカッコ悪くない？アセンブラは使えないけど。
839 ：デフォルトの名無しさん ：01/10/31 23:36
で、Eiffelスレはどこいった？
840 ：デフォルトの名無しさん：01/10/31 23:37
いや、末尾再帰展開があるScheme
841 ：デフォルトの名無しさん：01/10/31 23:38
過去ログに無かったんなら倉庫だよ >>839
842 ：デフォルトの名無しさん：01/10/31 23:38
>>838
君、１０年は遅れてるよ。
843 ：デフォルトの名無しさん：01/10/31 23:41
やっぱOCamlだろ？
型推論マンセー。
844 ：デフォルトの名無しさん：01/10/31 23:41
>>842
君は、１年遅れてる。
845 ：デフォルトの名無しさん：01/10/31 23:41
http://piza.2ch.net/tech/kako/984/984829772.html
846 ：デフォルトの名無しさん：01/10/31 23:45
>>845
典型的なクソスレだな（ｗ裸
847 ：デフォルトの名無しさん：01/10/31 23:48
なんか、ＯＯマンセーな方って、実社会で認められてないのね。あんな
ＯＯも知らないバカが良いおもいして、俺みたいな優秀な人間が認めら
れない。不公平だよね。ストレスたまるよね。社会が悪いよね。

さあ、思いっきり吐き出しなさい。このスレに！
848 ：デフォルトの名無しさん：01/10/31 23:54
>>847
既に充分吐き出してるって(ほとんど汚物入れ)
849 ：デフォルトの名無しさん：01/10/31 23:55
>>828 >>831
Eiffelスレ立てる?
Eiffel好きな人ってどれくらいいるの?
850 ：デフォルトの名無しさん：01/10/31 23:55
>>847
あのお>>1でストレス吐き出してるのはOOでやってけない
周回遅れプログラマなんですけど？
つまりここはそーゆースレです。
ささ、どうぞ続けて。
851 ：デフォルトの名無しさん：01/10/31 23:55
Perlでオブジェト指向やってます。
852 ：デフォルトの名無しさん：01/10/31 23:57
>>851
ある意味、最強。
853 ：デフォルトの名無しさん：01/10/31 23:58
みなさん、sageでいきましょ。
854 ：デフォルトの名無しさん：01/10/31 23:59
1 も 850 も目くそ鼻くそ
855 ：デフォルトの名無しさん：01/11/01 00:00
OOやってるのって、トップランナーのつもりで、わき道にそれてるプログラマ。
コース間違えてるかな？とうすうす感づきながらも、いまさら引き返せなく
なってる。
856 ：デフォルトの名無しさん：01/11/01 00:01
>>847
何言ってるか判らん。矛盾した文章だ。
自分は認められていないという事はＯＯマンセーでないということになるが、
ＯＯ知っていて、ＯＯマンセーで無いとしたら、
そもそもマンセーで無いものを学んだ人と言う事になり、全然優秀では
無いと言う事になる。
857 ：デフォルトの名無しさん：01/11/01 00:02
>>849
Meyer自身が.NETに入れ込んでいるらしいので、興味を持ちました。
http://www.eiffel.com/announcements/2000/pdc/

Ver5.0落としました。30日使えるそうです。
　URL → http://www.eiffel.com

だけどおれはド素人なので知ってる人がいないと
まともなスレにはなりそうもないです。
ごめんなさい、、、

http://www.geocities.co.jp/SiliconValley/8632/
ここから辿れる場所で勉強したいと思います。
858 ：デフォルトの名無しさん：01/11/01 00:05
>>855
真のトップランナーか勘違いかは別にして、優秀だというプライドは高いのに、
社会ではクズ扱いされているのは、このスレの愚痴を見ると明らか。
859 ：デフォルトの名無しさん：01/11/01 00:06
ＯＯを語れるあんたたちは漏れとちがって優秀だ。
人類の未来の為に頑張ってくだちゃい
860 ：デフォルトの名無しさん：01/11/01 00:09
>>850
周回遅れはＯＯ信者の方です。
私は１０年以上前、新米プログラマーの時にプログラム始めてすぐに
ＯＯに等しい手法を単独で発見しました。
出来るプログラマーの人の話を聞くと、皆同じで、大抵自分で発見して
います。
もちろん、今のＯＯのように珍語を発明したりはしませんでしたが、
ＯＯ的手法など通過点に過ぎません。
その後、もっとマシな方法を編み出してそっちに移っています。
（いました。最近は言語改変ブームに巻きこまれて止まってる・・・。）
861 ：デフォルトの名無しさん：01/11/01 00:10
>>858
仕事で実際にＯＯ使ってるやつもいるように見受けられるが。
862 ：デフォルトの名無しさん：01/11/01 00:10
>>860
で、具体的には？
863 ：デフォルトの名無しさん：01/11/01 00:12
時代についていけない化石プログラマも
口ばっかりで実績なしのOOプログラ
マも、

みんな仲良くやりましょう
864 ：デフォルトの名無しさん：01/11/01 00:12
900踏んだやつは、ちゃんと新スレ作れよ。
865 ：デフォルトの名無しさん：01/11/01 00:14
>>864
いらん、いらん（藁
866 ：デフォルトの名無しさん：01/11/01 00:17
>>862
秘密です。
こんな権威主義や論拠主義者のすくつで説明しても、理解されないで
煽られるデメリットと何もメリットないことを考えれば言えませんよ。
でもまあ、そのうち何かの権威をもって近い概念が語られる時が
来るでしょう。
867 ：デフォルトの名無しさん：01/11/01 00:18
>>857
Eiffel#はEiffelのサブセットです。
http://www.microsoft.com/JAPAN/developer/net/multilang/pdc_eiffel.asp
868 ：デフォルトの名無しさん：01/11/01 00:21
>>866
すくつって...
年寄りにしちゃ、言葉知らんね。もしかして中学生？
869 ：デフォルトの名無しさん：01/11/01 00:23
>>868
もしかして非２ＣＨねらー？ｗ
870 ：デフォルトの名無しさん：01/11/01 00:24
オブジェクト指向を批判しながら
"スレッド"を立てている>>1
871 ：デフォルトの名無しさん：01/11/01 00:24
>>866
もしかして Lyee ですか？（藁

何にせよ一般に流布されないのでは、
どんなに素晴らしくても我流止まりだな。
ISO や IEEE や OMG に TR 出そう。
872 ：デフォルトの名無しさん：01/11/01 00:24
OO原理主義で行くかしばらく迷って
結局グローバル関数を２つ追加した今日の俺。うむ、健全だ。
873 ：デフォルトの名無しさん：01/11/01 00:25
>>869
がいしゅつとかのたぐいね。
なんか文章が幼稚だったから。
874 ：デフォルトの名無しさん：01/11/01 00:25
>>866
ネタ決定。さようなら。
875 ：デフォルトの名無しさん：01/11/01 00:26
>>872
グローバル関数…Delphi 使い？
876 ：デフォルトの名無しさん：01/11/01 00:26
みんな心配するな。
>>860の発見というのは計算され尽くした角度のことだ。
877 ：デフォルトの名無しさん：01/11/01 00:26
すくつ。
>>866は、35年間生きてきて、初めて自分の間違いに気づきました。
878 ：850：01/11/01 00:28
ｲﾊﾟｰｲﾂﾚﾏﾁﾀ・・・
879 ：デフォルトの名無しさん：01/11/01 00:30
すくつ知らないのはインスタンス知らないのより恥ずかしいかもｗ
880 ：デフォルトの名無しさん：01/11/01 00:31
>>879
そんな話題で age るなよ。
881 ：すくつ、知らんかった：01/11/01 00:32
>>879
マジかよ。
この板でかずかすのバトルを繰り広げてきたけど、
初めて負けた気がした。
882 ：デフォルトの名無しさん ：01/11/01 00:38
>>867
ありがとうございます。
とりあえず、動くものが「30日だけ」使えるEiffel＃で
いろいろとやってみます。それからスレ立てます。そのときは
よろしくお願いします。
883 ：デフォルトの名無しさん：01/11/01 00:39
>>881
アニメの主人公の美少女の親友でクラスメートのメガネの女の子の名前を知らなかったってのと同じくらい恥ずかしいことだ
884 ：デフォルトの名無しさん ：01/11/01 00:45
さーて、そろそろ寝るかな。今日は楽しかったYO：)
おこちゃまの相手ももう飽きたし。
885 ：2典より：01/11/01 00:45
すくつ【すくつ】［名］
「巣窟（そうくつ）」の読み間違い。意味は巣窟と同じ。

使用例：「ココはドキュンのすくつだね」

http://freezone.kakiko.com/jiten/
886 ：デフォルトの名無しさん：01/11/01 00:54
社会にごみ扱いされてるってのはどっから来る考察か知らんが、
俺は理系の学生の人とかも多いじゃないの？
887 ：通訳：01/11/01 01:02
>>886
俺は「理系の学生の人とかも、多いんじゃないか？」と思う。
888 ：別訳：01/11/01 01:06
「俺は理系の学生！」の人とかも多いんじゃないの？
889 ：デフォルトの名無しさん：01/11/01 01:07
ﾜﾗﾀ
くだらね〜
890 ：JoJo：01/11/01 01:08
次にお前は、
「俺は理系の学生の人とかも多いじゃないの？」
と言う。
891 ：デフォルトの名無しさん：01/11/01 01:09
>>888
情報系を除いては、大学でデザパタを教えてるところは少ないと思われ。むしろ情報系でも
少ないんじゃないの？
892 ：自動翻訳：01/11/01 01:10
俺による理系についての学生は、人とかも多いでしょう。
893 ：デフォルトの名無しさん：01/11/01 01:10
>>891
教えて無くても自分で学んでる人が結構いるかもしれないよ。
894 ：デフォルトの名無しさん ：01/11/01 01:11
属性文法ってなんですか？
895 ：デフォルトの名無しさん：01/11/01 01:11
>>882
Eiffel#は多重継承できないのですか？
多重継承できない Eiffelってなんかしっくりこない。
CLRを使用する以上しかたないけど。
896 ：デフォルトの名無しさん ：01/11/01 01:12
>>895
中間言語のバージョンアップ！
これこそマイクロソフトらしい
いっそのことでぶでぶの仕様にして
ほしい
897 ：デフォルトの名無しさん：01/11/01 01:16
>>894
文脈自由文法などの素の文法に属性をつけたもの。
898 ：デフォルトの名無しさん：01/11/01 01:17
>>894
それは、こっちで聞いたほうがいい。

【コンパイラ・スクリプトエンジン】相談室
http://pc.2ch.net/test/read.cgi/tech/981672957/
899 ：デフォルトの名無しさん ：01/11/01 01:18
>>897 >>898
どうもありがとうございまーす
900 ：デフォルトの名無しさん：01/11/01 01:19
単語の意味を問うような質問は検索エンジン使えよ。
901 ：デフォルトの名無しさん：01/11/01 01:19
900get
902 ：デフォルトの名無しさん：01/11/01 01:20
>>901
残念。（ﾜﾗ
903 ：デフォルトの名無しさん：01/11/01 01:26
構造化アプローチだろーと、ＤＯＡだろーと、オブジェクト指向だろーと、Ｌｙｅｅだろーと
ドキュソがやるプロジェクトは失敗する。
できるやつは、なに使っても成功する。（Ｌｙｅｅ以外）
#Ｌｙｅｅ批判スレじゃないって？スマソ
904 ：888：01/11/01 01:29
>>891
そやね。俺は私立大修士だけど、
OO 関係は学部のときに Java による OOP の授業があったくらい。
修士なってからは UML、CORBA、ML があった。
今は CMM とか PSP など
最近の開発プロセスとその周辺についての授業だな。
905 ：デフォルトの名無しさん：01/11/01 01:29
またカレーかよ！
906 ：デフォルトの名無しさん ：01/11/01 01:34
Leeﾏﾝｾｰ!!!!!!
907 ：デフォルトの名無しさん：01/11/01 01:34
>>904
ちなみに、コードはどのぐらい書いてます？

設計手法のありがたみって、数万行規模のコードを書かないと実感が湧かない気がする
んだけど。
908 ：デフォルトの名無しさん ：01/11/01 01:35
>>907
同感。何か一つでいいからでかいものを作るのがいいかもね
909 ：デフォルトの名無しさん：01/11/01 01:38
>>906
Lyee のタイプミスか？　2ch で話題になったところだと、

　プロのプログラマのプログラム教えて（パート2）
　http://pc.2ch.net/test/read.cgi/prog/1000532199/

これの 123 以降とか

　カテナの開発手法Lyee その4
　http://mentai.2ch.net/test/read.cgi/infosys/998843224/

あたりかな。ネタとしては面白い（ぉぃ
910 ：デフォルトの名無しさん：01/11/01 01:48
Leeには、放熱を無視して30倍にオーバークロックした物がある。
さらに、増強ソースを装着すれば40倍相当にまでパワーアップする。
911 ：デフォルトの名無しさん ：01/11/01 01:54
ソフトは現象的に現実世界を捉える手段に帰結するが、
其の本質性は物理的構造物よりもより強く利用者並びに
開発者の意図と結ばれて成立している。これはソフトが
より高度な形而上学的世界に於いて捉えざるを得ない
性質を有する存在物である事を物語る。

簡明に言えば、ソフトには其の様な世界で成立する
見方（理論）が不可欠となる事である。更に言えば、
これ迄ソフトは現実的な数理工学者の知識体系の
基で扱われて来たが、これら分野が認識の公共化を
目的とする限りに於いて、ソフトの本質とは共生しにくい
部分がある事を直視しなければならない。即ち、
ソフトの本質は其れら知識体系が創り出す抽象概念を
越えて更に高度な形而上学的世界で求めなければ
ならない見方を必要とする分野なのである。難しいと
言えば難しい世界である。しかし、ソフトの開発技術に
起因して生じる問題はこの課題を克服しなければ
解決する事が出来ない。

Leeﾏﾝｾｰ!!!!!!
912 ：デフォルトの名無しさん：01/11/01 02:01
>>911
そんな事無いよ。バグが少なくて早くできるほうが産業的だ。
913 ：デフォルトの名無しさん：01/11/01 02:04
>>912
911 は Lyee の元サイトからのコピペ。っつーか >>911 もコピペだと分かるように明記するか
リンク張っとけよ。
914 ：デフォルトの名無しさん：01/11/01 02:04
http://www.catena.co.jp/topics/2001/20010917.htm
http://www.lyee.co.jp/webapp/jp/kozo/index.htm
http://www.catena.co.jp/lyee/index.htm

Leeﾏﾝｾｰ!!!!!!
915 ：デフォルトの名無しさん：01/11/01 02:07
Lyee はこのスレとは関係ないと思うが、どうか？

もっとも、このスレッド自体がプログラム技術板の隔離スレなので、いまさら痛い話題が一つぐらい
増えても俺は気にしないけど。
916 ：デフォルトの名無しさん ：01/11/01 02:10
いったん経験主義的なものの見方を確立するのは
いいけど、それからどうやってコミュニケーション
できるような理論を組み立てているのか興味深いな
917 ：デフォルトの名無しさん：01/11/01 02:10
Leeによるプログラミングは、大脳深皮質に強烈な刺激を与え、
パンチドランカー効果によりＯＯの抽象化を加速させる。
918 ：デフォルトの名無しさん：01/11/01 02:10
>>907
研究の評価用プログラムが Java で数千行程度かな。
趣味のプログラムは C でこれも数千行。
Perl や Rubyのプログラムだと長くて千行。
今のところ何万行規模のプログラム作る必要がないなあ。
919 ：デフォルトの名無しさん：01/11/01 02:17
>>918
これからの時代コーディングなんて手工業は必要ありません。
狙来ｾﾝｾｰのモデルが森羅万象を意思疎通の階層におうじて
自由に生成することができます。間違った理論は悲惨な現実を
招くだけです。直ちにLeeを学びましょう!!!
920 ：デフォルトの名無しさん：01/11/01 02:30
ちなみに>>860はLyeeではないです。
あんな判りにくい方法ではない。
設計から違う。
もっと簡単。
簡単すぎて馬鹿にされる可能性もあるｗ
921 ：デフォルトの名無しさん：01/11/01 02:59
>>920
ネタは sage でな。
922 ：白馬童子：01/11/01 07:48
>>920
すごい興味がある。
ぜひ内容をいくらかでも教えてはもらえぬか。
923 ：デフォルトの名無しさん：01/11/01 08:43
おもしれーやついるなあ。ははははは >>860
Effiel和訳本が1990年, BYTE Smalltalk 特集は84年じゃなかったか？
BYTE はともかくとして、Effiel和訳本はでたころに少しでも興味あったやつは
みんな買ってたぞ。
知ってて当然、使えて当然のアクセル踏む程度の基本技術に時代遅れも
なにもねーべ。
sageとこ
924 ：デフォルトの名無しさん：01/11/01 08:44
なんちうつづりしてるだ＞わし。はははは
s/Effiell/Eiffel/
な。スマソ
925 ：デフォルトの名無しさん：01/11/01 09:31
＞アクセル踏む程度の

だからそれはブレーキだって。
926 ： ：01/11/01 10:03
1000
927 ：デフォルトの名無しさん：01/11/01 10:25
ｻｰｼｬたんﾊｧﾊｧ
928 ：デフォルトの名無しさん：01/11/01 10:31
新スレでーす。
http://pc.2ch.net/test/read.cgi/tech/1004578255/l50
929 ：デフォルトの名無しさん：01/11/01 10:39
マ板でやってください。
930 ：デフォルトの名無しさん：01/11/01 12:25
別に板の主旨には外れとらんやろ。
ていどひくいスレを追い出そうというのは感心しないな。
931 ：デフォルトの名無しさん：01/11/01 13:00
「マ」板って「プログラマ板」だね？今分かった。「マンガ」板だと思ってた。
932 ：デフォルトの名無しさん：01/11/01 13:34
程度低い奴が隔離されるのは実によいことだ。
933 ：デフォルトの名無しさん ：01/12/06 03:39
よし、もう誰もいないな

お前ら全員バーカ！
OOとか言い出す前にラッセルの型理論ぐらい勉強しろ
934 ：デフォルトの名無しさん：01/12/09 01:37
型理論はネットで少し調べたことがあるけど
難しくて出した手を引っ込めちゃったよ。
良い本ある？
935 ：ちなみにＯＯ支持者：01/12/18 14:43
資本主義･･･いろいろ問題あるが、多くの人に受け入れられる。何だかんだで
走り続けている自転車操業。
共産主義･･･資本主義の問題点をカバーしながらも一部の思想の人しか受け入れられない。
自転車コケまくり。口ぐせは「思想は間違っていない。使う人が･･･」

ＯＯの明日はどっちだ！？
936 ：デフォルトの名無しさん：01/12/18 14:46
OOの難しさ < Win32の難しさ < C/C++でのCOM作成の難しさ

COMに明日は無い。
937 ：デフォルトの名無しさん：01/12/18 15:32
ババンババンバンバン♪
GoF 読んだか〜？
938 ：デフォルトの名無しさん：01/12/18 17:00
>>933 Russel の型理論てなに？
　　　　Risselのぎゃくりならならったが。
　　　　
939 ：デフォルトの名無しさん：01/12/18 17:04
Principia Mathematica とか読まないと、OOしちゃいけないのか？おぃおぃ。

ttp://www3.justnet.ne.jp/~e00859/R4HOME.HTM
940 ：デフォルトの名無しさん：01/12/18 17:17
つーか結果としてライブラリーの多いルーチンをいっぱい持っているツールが
オブジェクト指向だったらオブジェクト指向で組めばいいし、
多くの人がプロジェクトで有用なソースをCで作ればC使えばいいし
コンパイラが最適化できなかったり期間限定で高速化が必要ならば
アセンブラ使えばいいし
アセンブラがコードに対応していなければマシン語直うちじゃない。

別にできのいい人なら関係ないでしょ。
構造化プログラムうんぬんだって、できのいい人には無用なはず

要は結果だとおもうんだけどね。
OOの宗教的要素は無能ものの幻想だと思うけれど
それなりに残ったものも使えるものもあるからよいと思うけどね、
941 ：デフォルトの名無しさん：01/12/18 17:36
>>940
＞構造化プログラムうんぬんだって、できのいい人には無用なはず
確かに記憶力が無限大ならば構造化も
ローカル変数もカプセル化も無用だろうけどさ。
そんな奴いるか？
942 ：デフォルトの名無しさん：01/12/18 17:40
>>940
えらく思考停止的ないけんですが。

>別にできのいい人なら関係ないでしょ。
>構造化プログラムうんぬんだって、できのいい人には無用なはず

そういう意味で「できの良い」人がもてはやされる時代は
ふた昔か、それ以上前に終わってますね。
943 ：デフォルトの名無しさん：01/12/18 22:26
もうすぐ1000になっちゃうから、別スレで話したほうがいいみたいよ。

http://pc.2ch.net/test/read.cgi/tech/1004578255/l50

とかいいつつ。
941に禿同。
オブジェクト指向する隠れた意義に
「俺は楽をするためならどんな苦労もするっ！」
っていう部分があると思う。
これって元をただせばコンピュータを使う意義にまでさかのぼれると思うし、
こういう考え方できないヤツはプログラマとか、作る側にはいないで欲しい。
944 ：デフォルトの名無しさん：01/12/19 22:35
Real Programerのお話やね‥‥
http://www.geocities.co.jp/Milkyway-Orion/3324/prog/realprog.html
945 ：デフォルトの名無しさん：01/12/29 20:41
質問です。
オブジェクト指向で実行実体とか実行主体とかいう単語ってでてきますよね。
ずばり、実行実体とは???と言う質問に皆さんはどう答えますか???
946 ：デフォルトの名無しさん：01/12/30 00:09
>>943に逝け
947 ：デフォルトの名無しさん：02/01/22 12:35
>>806
＜発言に対する補足または反論＞

> 原因の比率としては上記のような「クラスライブラリの互換性のなさ」の方が
> はるかに大きいというのが私の意見です。いかがでしょうか。

　ＳＥとは、
プロジェクト（システム）に対して必要な
開発のライフサイクル、保守性、汎用性、etc...
（これらに関連して、ＯＯが必要なのかも選定するわけだが）
を考慮してシステムを設計することをさす。

そのＳＥが考えたシステム設計が要求を満たせばＳＥとして合格なんだっ！
「クラスライブラリの互換性のなさ」がその「システムにとって致命的」なら問題ですがね？
948 ：1000：02/01/22 13:09
1000
949 ：デフォルトの名無しさん：02/01/22 19:39
OOで生産性が上がるとも下がるとも思えない。
趣味の問題。
950 ：デフォルトの名無しさん：02/01/26 15:28
それならば、何故、ＯＯで生産性上がるって言った人や、
見苦しいフォロワーが出てきたんだろう？

対象のモデリング＆問題分割の方法として、
優れている面があったのではないか？
951 ：デフォルトの名無しさん：02/01/26 15:30
>>950
> それならば、何故
よく判らずに聞きかじっただけの奴だからでしょう。
952 ：デフォルトの名無しさん：02/01/26 16:02
生産性の差は明らかだと思うが、具体的数値が欲しいだけ。
953 ：949：02/01/27 00:39
生産性を数値化するのは難しい。
学習効率、開発効率、設計効率、デバッグ効率、変化対応力などなど…。
例えば、再利用性などの問題ひとつとっても難しい。
コード遺産再利用性、構造再利用性、知識・経験再利用性…。
C言語を使い続ける事は、言語知識の再利用。

ある意味、最もわかりやすいのが、
単位ステップ数あたりの平均収入とかかも。
むしろ、一番知りたい。
954 ：デフォルトの名無しさん：02/01/27 00:47
ふん。
生産性うんぬん、だから切り返るべきだと宣伝してたのはＯＯ側の奴らじゃんか。
それを今更「生産性を数値化するのは難しい」で逃げられると思ってるのか？
その論法だと、ＯＯは最初からインチキだったと認めてるようなもんだ。
955 ：デフォルトの名無しさん：02/01/27 18:36
ＸＸＸ手法とりいれれば生産性あがる云々、
とかいうストーリーに辟易しているだけ。

生産性向上実績出ないから、
新技術対応しないというレガシー野郎の組織的排除を検討しているだけ。
956 ：デフォルトの名無しさん：02/01/27 18:37
>>949 前半同意です。正直いって、パラメータが多すぎて、
　実践も統計も、とても難しい。だが、不可能ではない、と思う。
957 ：デフォルトの名無しさん：02/01/28 09:52
/****************************************************************/
/*************　このスレはとっくに終了しています。　*************/
/****************************************************************/

アンチOOの皆さんは、OO信者の居なくなったスレでしか
OO 批判をできないクズですか？違うならさっさと↓に逝って下さい。

やはりオブジェクト指向は幻想でした。 【２】
http://pc.2ch.net/test/read.cgi/tech/1004578255/l50

/****************************************************************/
/*************　このスレはとっくに終了しています。　*************/
/****************************************************************/
958 ：デフォルトの名無しさん：02/01/28 10:51
>>957 アンチOOではないけど、何か？
　ﾁｮﾄ新スレで語るのはﾅﾝありな話題なので旧ｽﾚ使わせて頂きました。
959 ：デフォルトの名無しさん：02/01/28 23:37
>>957
＞アンチOOの皆さんは、OO信者の居なくなったスレでしか
＞OO 批判をできないクズですか？違うならさっさと↓に逝って下さい。

と、よく見たら、あーたもアンチＯＯだったりして...
960 ：デフォルトの名無しさん：02/02/10 00:23

sage
961 ：デフォルトの名無しさん：
sage