トップページ⇒tech
961コメント289KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさんNGNG
オープンソースプロジェクトの成功率

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

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

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

/***** 終了 *****/
0003デフォルトの名無しさんNGNG
どうぞ御勝手に。
------------終了---------------------------------
0004デフォルトの名無しさんNGNG
>>1
さっさと氏ね
------------終了---------------------------------
0005デフォルトの名無しさんNGNG
>>2-4
ﾜﾗﾀ
------------終了---------------------------------
0006デフォルトの名無しさんNGNG
終了処理は一回でいいぞ。
0007　NGNG
>>1
貴重な資料をありがとう。
これで堂々とOO厨を駆逐出来ます。
0008デフォルトの名無しさんNGNG
APL 1.0
Perl 0.5164
Tcl 0.465
C 0.4513

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(*´д`*)
0089デフォルトの名無しさんNGNG
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

万逝ってるよ。
0090デフォルトの名無しさんNGNG
>>87
あるいは言語の生産性の差か。
0091デフォルトの名無しさんNGNG
オプソやるのは窓際Cヲヤジが多いってだけだろ
0092デフォルトの名無しさんNGNG
窓際Ｃヲヤジの方が使えると言う事の証明という意味ですか？

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

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

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

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

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

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

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

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

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

:
:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オブジェクト指向は生産性重視より、開発スピード重視
なんじゃないかな。
0231デフォルトの名無しさんNGNG
>生産性重視より、開発スピード重視
意味わかりません
0232デフォルトの名無しさんNGNG
そのまんまの意味だけど、日本語わかる？
0233デフォルトの名無しさんNGNG
生産性高い = 開発スピード早。じゃないの？
0234デフォルトの名無しさんNGNG
生産性には再利用のしやすさなんかが含まれるような。

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

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

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

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

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

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

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

あなたが作る独自のクラスは再利用可能でしょうか？
OOはライブラリが便利、としか解釈できないですよ。それをりようする
あなたのソースが腐っていたら、OOでもなんでもないですよ。
0254248NGNG
>>251
>ＣによるＯＯ的システム設計・開発
こんなことしているなんて一言も言ってません。
0255２４１NGNG
なんか不快な揚げ足取り合戦になってきたな（藁
ま、2ｃｈだしね
0256デフォルトの名無しさんNGNG
暇だしね。
0257デフォルトの名無しさんNGNG
つか、OO使ったって、結局コードの再利用は職人技。
(コンテナクラスのように独立性のたかい物は別にしてな)
0258デフォルトの名無しさんNGNG
>>257
ただ、再利用しやすい作り方の定石集がある。でざぱた。
また、再利用する（再利用可能に変化させていく）技法もある。りふぁくたりんぐ。
0259デフォルトの名無しさんNGNG
デザイン・パターン便利すね〜
昔、苦労して編み出したつもりのやり方が、片っ端からのってる。
今までの苦労は何だったんだ（苦笑）？
0260デフォルトの名無しさんNGNG
>>253
OOのライブラリが便利っていうのは、オブジェクト指向で設計した
クラスライブラリの再利用性が高い証拠だから、OOのアドバンテージ
と考えていいと思うんだけど。
0261デフォルトの名無しさんNGNG
>>259
デザイン･パターンの正式名称を教えてください。お願いします。
0262デフォルトの名無しさんNGNG
>>261
まんま、デザイン・パターンが正式名称です(^^;
0263デフォルトの名無しさんNGNG
>>261
http://books.softbank.co.jp/bm_detail.asp?sku=4797311126
0264デフォルトの名無しさんNGNG
これですか？
http://www.rational.co.jp/products/books/bk_12.html
0265デフォルトの名無しさんNGNG
>>263
ありがとうございました。是非買ってみます。
0266　NGNG
デザインパターン
アナルパターン
アンティパターン
プロセスパターン
他には？
0267デフォルトの名無しさんNGNG
>>265
その本は熟練プログラマじゃないとわからないから、まずこっちから読め。
http://books.softbank.co.jp/bm_detail.asp?sku=4797316462
0268デフォルトの名無しさんNGNG
今日の金曜ロードショーはCORBAだってさ。
0269デフォルトの名無しさんNGNG
なんでやねん
0270デフォルトの名無しさんNGNG
>>260
馬鹿ですか？
ＡＮＳＩライブラリも再利用性高い事になりますが？
0271デフォルトの名無しさんNGNG
クソ映画だな＞CORBA
0272デフォルトの名無しさんNGNG
>>270
なんだそのANSIライブラリってのは？
0273デフォルトの名無しさんNGNG
こんなとこで糞議論してる暇があったら、1本でも多くプログラム組め。そうすりゃ真実がわかる。
0274デフォルトの名無しさんNGNG
数組みゃ分かるなら、ジジイCOBOLプログラマは神様になってるよ…
0275デフォルトの名無しさんNGNG
別にＯＯ知らなくても食っていけるからいいや
0276デフォルトの名無しさんNGNG
スキルが高い人だったらCで書いても自然と
OO的な設計になると思うんだけどなあ。
0277デフォルトの名無しさんNGNG
>1
あふぉ発見
0278デフォルトの名無しさんNGNG
>276 FILE構造体やXawみたいのとかな。
じーっとソースコード睨んでるとクラスやインスタンスが見えてくる
ことはある。
0279仕様書無しさんNGNG
にゅーそく板にスレたてたの１？
0280デフォルトの名無しさんNGNG
まぁいいじゃねーか。ＯＯだろうが構造化だろうが。
結局スキルのない奴がプロジェクトの足を引っ張るのに変わりはない(藁
0281デフォルトの名無しさんNGNG
ＯＯ使おうが使うまいが、プログラマーという時点でダメだろ
02821NGNG
>>279
ちがーうｗ
0283プロジェクトが成功するか失敗するかはＰＭにかかっている！NGNG
と思うのは俺だけ？
全てを言語やＰＧに押しつけるのは間違っていると思うな。
0284デフォルトの名無しさんNGNG
最近の携帯電話の回収騒ぎで「これからはＯＯだ！！」とかトップに言われて、
過去を否定されたエンジニアがＯＯ的アプローチに挑戦しているそうだが、
次々にプロジェクトがデスマーチと化しているそうだ。この分野で結果が判るんじゃねーの？
0285デフォルトの名無しさんNGNG
>>284
浦島太郎にいきなりOOやらせて成功するわけないだろう。
0286ＯＯはちゃんと設計しないと必ず失敗するNGNG
文句言う前に設計はちゃんとしろ！
0287デフォルトの名無しさんNGNG
ＯＯなんかより在来言語での蓄積の方が何倍も効率的という事さ。　
0288デフォルトの名無しさんNGNG
>>286
だがね、いくらちゃんと設計していても、仕様変更は設計者の想像を
超える量、質でやってくるのだよ。
0289デフォルトの名無しさんNGNG
iアプリのＣ言語導入激しくｷﾎﾞﾝﾇ。
0290デフォルトの名無しさんNGNG
>>285
そーなんだよ、やつら最初はデザパタがどーの、なんちゃらのゴールド
一発で取ったのと言っていて、デスマーチだから笑っちゃうよな。
0291デフォルトの名無しさんNGNG
>>288
抽象化が足りない証拠。
特に変更が多いデータに対する抽象化は徹底すべき。
0292デフォルトの名無しさんNGNG
ＰＧの能力はゴールドかブロンズかにはよらないのです。
体内のコスモの燃焼を高める事でブロンズでもゴールドを
超える事が出来るのです。
0293デフォルトの名無しさんNGNG
しつもーん。携帯でOOするときって言語は何を使うんですか？
0294デフォルトの名無しさんNGNG
これからはXXXXだ！
なんてゆう奴はクズばっかりだよ。
実は自己顕示欲に突き動かされているだけだもの。
0295デフォルトの名無しさんNGNG
>>293
じゃう゛ぁじゃないの？
0296能力？NGNG
ＰＧの能力＝体力
ＳＥの能力＝口八丁
ＰＭの能力＝政治力
0297デフォルトの名無しさんNGNG
>>291
信心が足りないからじゃ。
とか言ってる教祖さまみたい。
0298デフォルトの名無しさんNGNG
>>296
その現場は生存者０です。
0299デフォルトの名無しさんNGNG
>>297
教典を読んで理解すれば、君にもその素晴らしさがわかる。
それでも入信しないのは、教典が理解できない馬鹿だけだ。
0300デフォルトの名無しさんNGNG
>>298
どの現場も、そんなもんだと思うが。
0301デフォルトの名無しさんNGNG
>>295
じゃばってリエントラントの問題って結構簡単に解決できるんですか？
組み込みってマルチタスクが普通なんですよね。経験ないから良く判りません。
C++とかでもどうやっているんだろう？
0302デフォルトの名無しさんNGNG
>>301
スレ違い。くみこに聞いて来い。
0303デフォルトの名無しさんNGNG
>>301
マルチタスク入れるとメモリ食うから只の割りこみ。
0304デフォルトの名無しさんNGNG
既に一部機能がiアプリになっているという
無謀な端末もあるようだな。
0305デフォルトの名無しさんNGNG
あge
0306デフォルトの名無しさんNGNG
>>301
関数内の変数はスタックに積まれます。
だからいくら再入しても平気。
0307デフォルトの名無しさんNGNG
>>306
再帰と再入を混同してない？
0308デフォルトの名無しさんNGNG
同じじゃないの？
0309デフォルトの名無しさんNGNG
>>308
同じじゃないけど無関係でもない。
0310デフォルトの名無しさんNGNG
>>309
無関係でしょ。

>>308
リエントラントで検索すれ。
0311デフォルトの名無しさんNGNG
1に言いたい。

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

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

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

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

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

オレの職場は、プロトタイピングが必須なんで、
OOPなしでは耐えられないな。
0320デフォルトの名無しさんNGNG
>>318
ﾊｧ?
0321デフォルトの名無しさんNGNG
>>316-317
多態は？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

javaがそこそこはやっているのはOOベースの言語だからではない、と思うがどうか？
0372デフォルトの名無しさんNGNG
>>371
GCのある、BASICじゃない言語だからと思われ。
0373364NGNG
1でも何でもない。
只のsageだ。

rubyはしらん。
delphiもしらん。
javaもしらん。
0374デフォルトの名無しさんNGNG
>OOをやらなくても

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

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

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

「OOできません」と言う奴と「OOできます」という奴
どちらを企業は採用する？
0375デフォルトの名無しさんNGNG
>>374
> 「OOできません」と言う奴と「OOできます」という奴
> どちらを企業は採用する？
企業による。たぶん 364 がいる企業は「ＯＯできません」というやつを採用して、ＯＯできません組が
一大勢力になってるんだろう。……合掌。
0376デフォルトの名無しさんNGNG
「おーおーできます」
っていうの？
0377デフォルトの名無しさんNGNG
Ｒｕｂｙ］つかえないやつらのひがみですか？あ
0378正確にはNGNG
「うーうーできます」
です
0379デフォルトの名無しさんNGNG
Ｒｕｂｙつかえないようなやつはくびにしろ！
そいうがくびをくくるまでおいつめろ！
0380デフォルトの名無しさんNGNG
>>379
それって、プログラマの9割以上がくびになるな…
0381デフォルトの名無しさんNGNG
おーおーぴー
できます
のほうがあたまよくみられない？
0382デフォルトの名無しさんNGNG
何だか急にレベルが下がったな
0383デフォルトの名無しさんNGNG
>>379
ごめん。おれ Java, C++, Perl あたりは使えるが ruby はダメだわ。
0384デフォルトの名無しさんNGNG
9割8分7厘クビになるな
0385デフォルトの名無しさんNGNG
OSやDB書いてるプログラマたちも9割5分はクビだろう。
0386デフォルトの名無しさんNGNG
お願いです、これ以上 ruby 厨に餌をやらないでください。
0387デフォルトの名無しさんNGNG
>>382、>>389
ごめん、たぶん俺の所為だ、、、
Ruby厨回収の為に、注意書き書いてくる、、、
ああ、やっぱこっちに、>>1の資料の信頼の無さを示す為に、
Ruby 0.44
と言うことを、指摘しておけば良かった。
まあ、既に誰もあの資料なんか信頼してないけどね。（藁
0388デフォルトの名無しさんNGNG
>>372
Lispがありまふ。（お願い流行ってぇ
あと、Javaはその実行環境も合わせてのJavaでしょ。
でも、言語としてのJavaに高い評価つけている場合は、大抵その理由の一つに「OOPLである」
があるようですが。
0389デフォルトの名無しさんNGNG
>>360
んー。単品ならともかく、サンプル数多ければ平均化されるだろ。
0390デフォルトの名無しさんNGNG
>>360
それから生産性が低い＝期限内にできなかった、から失敗した
と考えるのが妥当。
0391デフォルトの名無しさんNGNG
OOでなくても期限内にできてないのが常態化しているのは逝ってよしですか？
0392デフォルトの名無しさんNGNG
>>389
平均化というか、ガウス分布のような連続した分布になると思う。
成功と失敗の境界でいきなり１０倍の断層ができるなんて、ちょっと考えられない。
0393デフォルトの名無しさんNGNG
>>1の数字は
JAVA,C++の生産性分布とＣ言語の生産性分布を重ねて
ある場所で切ってみたら左側の面積が２５：５０になりました。
ということだろう。
ガウス分布に従うとして、生産性比の計算誰かやってくれ。
俺には無視だ。
0394デフォルトの名無しさんNGNG
OOP理解してない人がOOPしても生産性が上がらないのはあたりまえ。
0395デフォルトの名無しさんNGNG
OOPLだとプロジェクトが失敗するんじゃなくて
失敗したプロジェクトはOOPLの割合が大きいだけだろ。
相関関係はあると思うが因果関係が逆。
OO厨の存在を如実にあらわしてると思う
0396デフォルトの名無しさんNGNG
まだあの統計が信じられると思ってるやつがいるよ･･･
総理の支持率だって、テレビ局、新聞社、その他の機関でかなり違う。
厳密にやった統計でもあまり信用できないと言うのに。
0397デフォルトの名無しさんNGNG
視聴率みたいないいかげんなもんに金を積むスポンサーと同じだな。
0398デフォルトの名無しさんNGNG
1の統計よりは支持率や視聴率のほうがはるかに正確だよ。
0399デフォルトの名無しさんNGNG
ＯＯ思想に従って出来もしない再利用を目指すから、生産性が悪くなる。
どんなに工数をかけても結局再利用できないのだから、何のメリットもない。
ＯＯが理解できない馬鹿は、こんな事はしない。
ＯＯを鵜呑みにして、自分自身では消化吸収できていない馬鹿が、これをやる。
0400デフォルトの名無しさんNGNG
>ＯＯを鵜呑みにして、自分自身では消化吸収できていない馬鹿
これはOOを使えない奴ってことです。

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

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

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

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

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

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

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

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

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

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

>>416
するどいです。

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

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

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

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

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

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

　保守で儲けなきゃどこで儲ける
0450デフォルトの名無しさんNGNG
>>444

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

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

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

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

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

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

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

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

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

いつも通りの妄想爆発でバレバレ
0467デフォルトの名無しさんNGNG
なんか>>463て実はデザインパターン読んでなさそう。
0468デフォルトの名無しさんNGNG
>>465
いってることが理解できてないよ。

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

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

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

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

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

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

これが非常におろかなことだと言うことぐらい、いい加減
気付かないかね？
0501デフォルトの名無しさんNGNG
>>495
スレ妄想中
0502デフォルトの名無しさんNGNG
>>500

> これが非常におろかなことだと言うことぐらい、いい加減
> 気付かないかね？
自分自身に問いかけよ
0503デフォルトの名無しさんNGNG
>>502
おいおい。（ｗ
0504デフォルトの名無しさんNGNG
>>501-502
オブジェクト指向とデザパタに対する批判（難癖ではなくて技術的な観点からの、まっとうな批判）
はないの？
0505デフォルトの名無しさんNGNG
デザパタと同じ設計ならOOだという主張に対する
反論は無いの？
0506デフォルトの名無しさんNGNG
デザパタってOO前提じゃん…
0507デフォルトの名無しさんNGNG
>>503-505
1人で大変だね
ガンバレ!
0508デフォルトの名無しさんNGNG
不毛だ...
0509503NGNG
>>507
一人じゃねぇよ。（ｗ
0510デフォルトの名無しさんNGNG
これに関しては批判派の大敗だね…
0511仕様書無しさんNGNG
>>507
一人なのはお前なんじゃないのか？
0512デフォルトの名無しさんNGNG
>>510
くだらない人間･･･
0513デフォルトの名無しさんNGNG
なんてﾚﾍﾞﾙの低いｽﾚなんだ
0514デフォルトの名無しさんNGNG
スレ迷走中
スレ瞑想中
スレ名僧中
0515デフォルトの名無しさんNGNG
>>505
それは、主張が変。

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

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

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

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

OOを非OO言語でエミュレートする以外にだよ、もちろん。
0517デフォルトの名無しさんNGNG
>>504
難しすぎる。他には……なんだろう。
0518デフォルトの名無しさんNGNG
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;
:
:
}

ファクトリーメソッド、、、、ごめん、なんでも無い。
0519デフォルトの名無しさんNGNG
確かに、一部はオブジェクト指向でなくても実現できるかも
しれないが、デザパタはオブジェクト指向を前提としているので
オブジェクト指向で無いといけないものも多い。
だから、デザパタなどオブジェクト指向の利点ではないという
説の根拠にはなりえない。
0520デフォルトの名無しさんNGNG
sngletonパターンなどは、オブジェクトに対するパターンという
時点で、OOだね。
0521518NGNG
/*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;
}
0522デフォルトの名無しさんNGNG
>>521
それはオブジェクト指向言語ではない言語で実装した
オブジェクト指向だろ。
0523521NGNG
そうだよ。別に反論してる訳じゃない。
デザパタがOOの利点だ、という事に反論するなら
Alexanderだかなんだか、って名前の建築家出すだ
けで十分だろうし。別に俺、OO嫌いじゃないし。
つまり深い意味は無い。
0524デフォルトの名無しさんNGNG
>>518
うん。で、FactoryMethodをオーバーライドする
新たなクラスを加えるときはどうすんの?
既存部分を書き直す？（藁）

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

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

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

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

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

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

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

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

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

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

まあ普通は525の言うように、staticな変数使ってモジュール
化する方が多いだろうな。その方法だと複数実体が持てないが、
必要になったら構造体を引数に渡すようなのにすればいい。
0538デフォルトの名無しさんNGNG
>>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に利点が無いといってるわけではない。こういったことを楽に出来ると思う。
0539デフォルトの名無しさんNGNG
>>534
多態でメソッド一つ呼ぶのに、関数のテーブル作るな
んて、今どきやりたくないっス。
あるインターフェースのセットがメソッド一つなんて
あり得ないし、むしろひとつのオブジェクトに複数の
インターフェースのセットを持たせたい場合のほうが
多い。非OOPLでオブジェクト指向的なことができる
事には異論はないけど、ご苦労さん、としか言えない。
なんだか、その昔、BASICで構造化プログラミングを
やるためのテクニックを雑誌で紹介してた人を思い出
してしまったよ。素直にCを使えよって当時思ったけど
それと似たような感覚です。素直にOOPLつかおよって。
0540528NGNG
>>530
別に敵対してるわけでも煽ってるわけでもないよ。
デザインパターンはGoF以前にもあったという事実を提示しただけ。

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

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

>>539

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

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

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

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

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

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

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

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

============================終=======了============================
0559デフォルトの名無しさんNGNG
難しい宗教用語は説明つけて欲しい。アブストラクトファクトリーとか。
0560デフォルトの名無しさんNGNG
んでもって生産性の問題は放置ですか？

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

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

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

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

>>570

まぁいいけど
0576デフォルトの名無しさんNGNG
チェインオブレスポンシビリティー
0577デフォルトの名無しさんNGNG
>>571
その質問、

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

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

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

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

ＤｏｒａｅｍｏｎＰｏｃｋｅｔ
0581デフォルトの名無しさんNGNG
ふらいうぇいとぉ
0582５６７NGNG

>>579

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

パターンの内容の事ね
0583デフォルトの名無しさんNGNG
またまた発明しました。どうぞ使ってください。

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

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

……いや、ホントに。日本発のソフトウェア設計技法が世界を席巻するのを見てみたいよ。
0587デフォルトの名無しさんNGNG
んじゃドキュメント・ビューアーキテクチャ。
0588デフォルトの名無しさんNGNG
それはアンチ・デザインパターン
0589デフォルトの名無しさんNGNG
なぜアンチに分類される？
0590デフォルトの名無しさんNGNG

>>585,586

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

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

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

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

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

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

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

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

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

>>623
同感
0626デフォルトの名無しさんNGNG

ここで話してる、オブジェクト指向って何ですか？誰か定義してください
0627デフォルトの名無しさんNGNG
>>623 >>625

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マギレのある言葉を使うより、普通の言葉で語るのが一番だと思うよ。
0642637NGNG
>>641
本当にわからないのか。
だったら書くけど。

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

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

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

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

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

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

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

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

>副作用のある関数

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

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

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

それが俺の主張。

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

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

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

なぜマシになったと思うの？
副作用とか実装依存とかは、どうからんでくるの？
0656636NGNG
漏れへのレスが元らしいので。

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

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

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

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

ということでしょ？
でもそれってOOと何の関係もないと思うんだけど。
0658656NGNG
>>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派の俺がいっても釈迦に説法だろうが。
0659デフォルトの名無しさんNGNG
>>658
同意。

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

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

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

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

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

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

インターフェイスと実装が区別されているから。
インターフェイスは責任を表明しており、
将来的にも不変であると期待できる。
実装は変化する可能性が予約されており、
実装に依存したコードを呼び出し側が持つことは、
呼び出し側が契約違反をしたと見ることができる。
0662デフォルトの名無しさんNGNG
>>652
定義だから仕方が無い。
この際おぼえておこう。
0663656NGNG
>>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);
とやった方がいい時はそうすりゃいい。
理論上はもちろんこの判断がいつも正しく可能、
という訳では無いが、現実問題としては、他に
いろいろ問題がある事の方が多い、と思う。
0664デフォルトの名無しさんNGNG
>>663
ＯＯを使っても、あまりに具体的で抽象化の必要がない
（利益がない）データはもちろんあるよね。Javaだと
PointとかRectangleとか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

module M
def foo
print "foo"
end
end

class C; end

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

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

問題の本質がわかってないYO!
0717デフォルトの名無しさんNGNG
>>716
本質とは？
0718デフォルトの名無しさんNGNG
>712
704 も言ってるけど、継承そのものにメリットはないのでは？
目的ではなく手段なのだから、当たり前といえば当たり前だけど
0719デフォルトの名無しさんNGNG
>>718
有効な手段なら、それをメリットと言わない？
0720デフォルトの名無しさんNGNG
704は、ただ困難だと言い放ってるだけで何も説得力が無いな･･･
0721デフォルトの名無しさんNGNG
>719
言わないと思う
有効な手段によって得られた物がメリットでしょ
結局、手段は変わってもよいわけで
0722デフォルトの名無しさんNGNG
>>721
アホか。言葉遊びやってるんじゃないんだから。（ｗ
0723デフォルトの名無しさんNGNG
ていうか継承のメリットについて話がでた直後ではなかったか？
0724デフォルトの名無しさんNGNG
>>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
0725デフォルトの名無しさんNGNG
現実の設計開発レベルまで達してないのがまだ多いな
0726デフォルトの名無しさんNGNG
>>720
実装出せとは言わんが、せめて「こんな感じ」って実感できるサンプル／仕様概要ぐらいは
出してもらわんと、妄想と区別がつかんわな。
0727デフォルトの名無しさんNGNG
>>721
継承の代替になるものなんて有る？それはなに？
0728デフォルトの名無しさんNGNG
プロトタイプベースのオブジェクト指向の方が良いと言いたいんだろうか？
でもそれが言いたいからって、継承にメリットが無いといきなり主張するのは
誤解を招くだろ。
〜に比べてメリットが無いという言い方しないと。
0729702NGNG
>>724
サンクス。
安心して多重継承を使えそうですね………。
0730sageNGNG
とりあえずC++ならメンバ関数へのポインタを持たせれば済みそう。

だがそれはあまりOOとは関係ないな
0731デフォルトの名無しさんNGNG
>>730

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

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

まあね
でも言語仕様に、指向が左右されなくても良いでしょ
指向を適切に表現できる言語は欲しいけど
0738724NGNG
>>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)?
0739デフォルトの名無しさんNGNG
>>736
技術論(藁
0740デフォルトの名無しさんNGNG
> 735
おまえのかーチャンが、逃げで使っているか、デベソかはしらん。しかし言ってることは真実である。
0741デフォルトの名無しさんNGNG
信者は移動してください
http://pc.2ch.net/test/read.cgi/tech/1002523282/l50
0742デフォルトの名無しさんNGNG
>>738
いい気にならないで下さい
スレ違いです
http://pc.2ch.net/test/read.cgi/tech/1002523282/l50
0743738NGNG
>>742
>スレ違いです
そのとおりです。すみません。
0744デフォルトの名無しさんNGNG
ＯＯ信者も反ＯＯ派も、ＯＯって事でスレ統一すべきでは？
0745デフォルトの名無しさん NGNG
御部塾徒至高の内縁、外苑、族生ってどういう意味ですか？
0746ＯＯ神NGNG
信者に告げる････このスレを聖地とせよ
0747デフォルトの名無しさんNGNG
ビエーン、OOなんて良く分からないし、キライだ〜い。
ぼくのおうちから出てってよ〜！
0748デフォルトの名無しさんNGNG
ＯＯ神様のお告げは絶対です。
全てはＯＯ神様の御心のままに。
0749デフォルトの名無しさんNGNG
正直OOPの話は飽き飽きしたから、
業務分析でのOO話を聞きたいな。
アナリシスパターン、前に似た
ようなスレで薦められたけど、
高くてまだ読んでないｗ
0750デフォルトの名無しさんNGNG
>>749
開発−クラス設計−詳細設計−基本設計−要件定義−業務分析と、
人数はピラミッド型になっている。
最初は数人で業務分析を始め、フェーズが進むにつれ増員していく。
つまり、業務分析経験者は非常に少ない。
当然だが、業務分析には業務の知識が必要。
設計の知識だけでは、どうにもならない。
0751749NGNG
>つまり、業務分析経験者は非常に少ない
基本的にこの辺をやっている人が
少ないから話題にならないのか・・・

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

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

その考え方自体がだめだめですね（ｗ
0754デフォルトの名無しさんNGNG
>>753
何が良くて何がダメかは、一概には言えない。
理論で良くても、実践してみたらダメと言うこともある。
演繹と帰納を繰り返して、グレーな落としどころを決めるのが、
プロの仕事だと思う。
0755749NGNG
>>754
理論と実践は両輪、どのレベルでもそういうものですかね。
今度アナリシスパターンやビジネスモデリングの
本でも読んでみます。そうでないとあなたとの話も続かないｗ
0756738NGNG
>>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)?
スレ違いですみません。
0757デフォルトの名無しさんNGNG
これからはrubyだね。
0758デフォルトの名無しさんNGNG
>>756
安心しろ、既にこのスレはＯＯ肯定派が占拠した。
0759デフォルトの名無しさんNGNG
rubyの指輪
眠いよママ
0760デフォルトの名無しさんNGNG
一晩たったら、死ぬほどつまらなくなってた。
無駄かも知れないけど、巻き直すかな。

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

Cから構造体をなくそう、とかいう奴いる？
0761671NGNG
>>760

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どこの製品使ってる？

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

--------------------終了--------------------
0823デフォルトの名無しさんNGNG
0.3秒で透明あぼ〜んの刑
0824デフォルトの名無しさんNGNG
>>822
ﾜﾗﾀ
0825デフォルトの名無しさんNGNG
WindowsのDLLとかって、何の言語でコンパイルしたかが重要なの？
0826デフォルトの名無しさんNGNG
COMはオブジェクト指向を支える技術の一つだ。

それをオブジェクトとして使うか、ただのライブラリとして使うかは
使用者の問題だ。
クラスライブラリと同じだろ？
0827デフォルトの名無しさんNGNG
>>806
よりによって、吉田弘一郎かい（ｗ
0828デフォルトの名無しさんNGNG
Eiffelのスレが無くなってるんですけど誰か捨てたりしませんでしたか？
0829デフォルトの名無しさんNGNG
>>826
見かけがオブジェクト指向風のライブラリとしてしか使えません。
0830デフォルトの名無しさんNGNG
いろんな言語から呼べるクラスライブラリだ。
低調に扱ってくれ
0831デフォルトの名無しさん NGNG
で、やっぱりEiffelスレは亞骨されたのか？
0832デフォルトの名無しさんNGNG
このスレって面白いか？
低俗なだけの糞スレだろ
0833デフォルトの名無しさんNGNG
>>832
ゴキブリホイホイ、あるいは隔離病棟としての機能は果たしているでしょう。
0834デフォルトの名無しさんNGNG
>>829-834
ひかかったゴキブリかよ。
0835デフォルトの名無しさん NGNG
ゴキブルにも自意識はあるんですね
0836デフォルトの名無しさんNGNG
そうそう、Ｒｕｂｙって最高ですね。
0837デフォルトの名無しさんNGNG
やっぱLispでしょ。
0838sageNGNG
いま、このスレッド一気に読みました。
ぼくの立場はCはわかっていて、C++もわかっていて、
最近「憂鬱本」を読んだ程度ですが、

やっぱりOOは理想論

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

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

さあ、思いっきり吐き出しなさい。このスレに！
0848デフォルトの名無しさんNGNG
>>847
既に充分吐き出してるって(ほとんど汚物入れ)
0849デフォルトの名無しさんNGNG
>>828 >>831
Eiffelスレ立てる?
Eiffel好きな人ってどれくらいいるの?
0850デフォルトの名無しさんNGNG
>>847
あのお>>1でストレス吐き出してるのはOOでやってけない
周回遅れプログラマなんですけど？
つまりここはそーゆースレです。
ささ、どうぞ続けて。
0851デフォルトの名無しさんNGNG
Perlでオブジェト指向やってます。
0852デフォルトの名無しさんNGNG
>>851
ある意味、最強。
0853デフォルトの名無しさんNGNG
みなさん、sageでいきましょ。
0854デフォルトの名無しさんNGNG
1 も 850 も目くそ鼻くそ
0855デフォルトの名無しさんNGNG
OOやってるのって、トップランナーのつもりで、わき道にそれてるプログラマ。
コース間違えてるかな？とうすうす感づきながらも、いまさら引き返せなく
なってる。
0856デフォルトの名無しさんNGNG
>>847
何言ってるか判らん。矛盾した文章だ。
自分は認められていないという事はＯＯマンセーでないということになるが、
ＯＯ知っていて、ＯＯマンセーで無いとしたら、
そもそもマンセーで無いものを学んだ人と言う事になり、全然優秀では
無いと言う事になる。
0857デフォルトの名無しさんNGNG
>>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/
ここから辿れる場所で勉強したいと思います。
0858デフォルトの名無しさんNGNG
>>855
真のトップランナーか勘違いかは別にして、優秀だというプライドは高いのに、
社会ではクズ扱いされているのは、このスレの愚痴を見ると明らか。
0859デフォルトの名無しさんNGNG
ＯＯを語れるあんたたちは漏れとちがって優秀だ。
人類の未来の為に頑張ってくだちゃい
0860デフォルトの名無しさんNGNG
>>850
周回遅れはＯＯ信者の方です。
私は１０年以上前、新米プログラマーの時にプログラム始めてすぐに
ＯＯに等しい手法を単独で発見しました。
出来るプログラマーの人の話を聞くと、皆同じで、大抵自分で発見して
います。
もちろん、今のＯＯのように珍語を発明したりはしませんでしたが、
ＯＯ的手法など通過点に過ぎません。
その後、もっとマシな方法を編み出してそっちに移っています。
（いました。最近は言語改変ブームに巻きこまれて止まってる・・・。）
0861デフォルトの名無しさんNGNG
>>858
仕事で実際にＯＯ使ってるやつもいるように見受けられるが。
0862デフォルトの名無しさんNGNG
>>860
で、具体的には？
0863デフォルトの名無しさんNGNG
時代についていけない化石プログラマも
口ばっかりで実績なしのOOプログラ
マも、

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

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

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

http://freezone.kakiko.com/jiten/
0886デフォルトの名無しさんNGNG
社会にごみ扱いされてるってのはどっから来る考察か知らんが、
俺は理系の学生の人とかも多いじゃないの？
0887通訳NGNG
>>886
俺は「理系の学生の人とかも、多いんじゃないか？」と思う。
0888別訳NGNG
「俺は理系の学生！」の人とかも多いんじゃないの？
0889デフォルトの名無しさんNGNG
ﾜﾗﾀ
くだらね〜
0890JoJoNGNG
次にお前は、
「俺は理系の学生の人とかも多いじゃないの？」
と言う。
0891デフォルトの名無しさんNGNG
>>888
情報系を除いては、大学でデザパタを教えてるところは少ないと思われ。むしろ情報系でも
少ないんじゃないの？
0892自動翻訳NGNG
俺による理系についての学生は、人とかも多いでしょう。
0893デフォルトの名無しさんNGNG
>>891
教えて無くても自分で学んでる人が結構いるかもしれないよ。
0894デフォルトの名無しさん NGNG
属性文法ってなんですか？
0895デフォルトの名無しさんNGNG
>>882
Eiffel#は多重継承できないのですか？
多重継承できない Eiffelってなんかしっくりこない。
CLRを使用する以上しかたないけど。
0896デフォルトの名無しさん NGNG
>>895
中間言語のバージョンアップ！
これこそマイクロソフトらしい
いっそのことでぶでぶの仕様にして
ほしい
0897デフォルトの名無しさんNGNG
>>894
文脈自由文法などの素の文法に属性をつけたもの。
0898デフォルトの名無しさんNGNG
>>894
それは、こっちで聞いたほうがいい。

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

設計手法のありがたみって、数万行規模のコードを書かないと実感が湧かない気がする
んだけど。
0908デフォルトの名無しさん NGNG
>>907
同感。何か一つでいいからでかいものを作るのがいいかもね
0909デフォルトの名無しさんNGNG
>>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/

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

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

Leeﾏﾝｾｰ!!!!!!
0912デフォルトの名無しさんNGNG
>>911
そんな事無いよ。バグが少なくて早くできるほうが産業的だ。
0913デフォルトの名無しさんNGNG
>>912
911 は Lyee の元サイトからのコピペ。っつーか >>911 もコピペだと分かるように明記するか
リンク張っとけよ。
0914デフォルトの名無しさんNGNG
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ﾏﾝｾｰ!!!!!!
0915デフォルトの名無しさんNGNG
Lyee はこのスレとは関係ないと思うが、どうか？

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

だからそれはブレーキだって。
0926 NGNG
1000
0927デフォルトの名無しさんNGNG
ｻｰｼｬたんﾊｧﾊｧ
0928デフォルトの名無しさんNGNG
新スレでーす。
http://pc.2ch.net/test/read.cgi/tech/1004578255/l50
0929デフォルトの名無しさんNGNG
マ板でやってください。
0930デフォルトの名無しさんNGNG
別に板の主旨には外れとらんやろ。
ていどひくいスレを追い出そうというのは感心しないな。
0931デフォルトの名無しさんNGNG
「マ」板って「プログラマ板」だね？今分かった。「マンガ」板だと思ってた。
0932デフォルトの名無しさんNGNG
程度低い奴が隔離されるのは実によいことだ。
0933デフォルトの名無しさん NGNG
よし、もう誰もいないな

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

ＯＯの明日はどっちだ！？
0936デフォルトの名無しさんNGNG
OOの難しさ < Win32の難しさ < C/C++でのCOM作成の難しさ

COMに明日は無い。
0937デフォルトの名無しさんNGNG
ババンババンバンバン♪
GoF 読んだか〜？
0938デフォルトの名無しさんNGNG
>>933 Russel の型理論てなに？
　　　　Risselのぎゃくりならならったが。
　　　　
0939デフォルトの名無しさんNGNG
Principia Mathematica とか読まないと、OOしちゃいけないのか？おぃおぃ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と、よく見たら、あーたもアンチＯＯだったりして...
0960デフォルトの名無しさんNGNG

sage
0961デフォルトの名無しさんNGNG
sage
レス数が950を超えています。1000を超えると書き込みができなくなります。