やはりオブジェクト指向は幻想でした。 【２】

オブジェクト指向は裸の王様だったのか！？
オブジェクト指向の欺瞞を鋭く指摘し、各界に大きな波紋を呼んだ前スレ。
好評につき第２弾です。

----
オープンソースプロジェクトの成功率

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

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

ソース
http://www.gyve.org/~jet/lang2.txt

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

関連スレ
http://pc.2ch.net/test/read.cgi/tech/1003850943/

で？オブジェクト指向を追い出したい奴はどういう立場の奴らなの？

ていうか、OO スレ盛り上がりすぎ。

>>3

１、
マニュアル見ろ
仕様書を見ろ
ソースを見ろ
でカタがつかないから。
XX vs, YY が盛り上がるのと一緒

２、
オブジェクト指向はいまほとんどの分野で嫌でも忍び寄ってきているから

＃いままでVB厨だったのにJavaやらされているとか
＃COBOLラーで安泰とおもてたらイキナリCORBAプロジェクトに突っ込まれたとか

>>4
あーあ、COBOL以外の仕事やりてぇな。

てゆうか、１で決着付いたじゃん。http://pc.2ch.net/test/read.cgi/tech/1003815855/773-799
新スレ作ったやつ、ネタ振れＹＯ！

世の中自分みたいなｳﾞｧｶばっかりだと思う奴はVBでもやっとけよ(ﾌﾟ

ブビ坊は自分でも出来た、VBで良いじゃん、って自分が賢いつもりだＹＯ！>>7

>>8
ふむ、君はもう少し国語を勉強して他人にもわかりやすい文章を書くべきだな。

その必要は無いＹＯ！ブビ坊は.Netで絶滅するから。>>9

オブジェクト指向を取り入れたプロジェクトの失敗例。

「日本IBMが九大病院の大型SIで苦戦
オブジェクト指向技術者不足が原因 」
http://www3.nikkeibp.co.jp/WAT2/970516/970516trein01.html

OO信者は、OOが浸透すれば技術者不足は解消されると
楽観的だけど、OOの技術者不足が解消されることは
永遠にないでしょう。

構造化の時(コーディングレベルでは)は、それこそ、あっという間に
日本中に広まったのに、OOは、一般に名前が知られるようになってから
１０年以上たつのにこの体たらく。(しかもIBMでも)

オブジェクト指向は、平均的なコンピュータ技術者にはむずかしすぎるんです。
これがOOの本質的な欠点。
いくらOOを使えない技術者を馬鹿呼ばわりしても解決しません。

もうこのネタ飽きた。

>>11
それはオブジェクト指向じゃなくてmallTalk採用が原因だろ。お前もその記事も頭悪いな

いつの記事だよ　おいっ

>>13
構造化の時あっというまに広まったというのは嘘だろ。
構造化プログラミングが提唱されたのは1960年代だぞ？

>>11 だった。

>オブジェクト指向は、平均的なコンピュータ技術者にはむずかしすぎるんです。

ブビ坊には難しすぎるだろ。ブビ坊は技術者じゃないＹＯ！
今、OOじゃない言語って、VBとCOBOL（OO-COBOLを出すのは気が引けるんで）だけだろ！

だって、ブビ坊って、「VB以外は難しい、VBで良いジャン」、
ってどうしようもないもん。

OOじゃない言語って何なんだろうねぇ・・・
OO出来ない言語のこと？

>>19
よくわからんが、PL/IやFortranは含まれるらしい。

てことは、このスレで推奨する言語は以下の通りか？
・COBOL,PL/I
・Fortran
・VB

C言語はダメね、だって、誰かがコソーリC++コード混ぜるもん。

>>21
C言語はXlibとかみたいにがんばってOOしてる例もあるしな

17みたいな馬鹿もふくめて人材の有効活用をそろそろみんなで考える必要があるってことだな。

たとえば、義務教育にOO入れるとかな。

てゆうか、今、プログラミングて言ったら、言語にOOが入ちゃってるＹＯ！>>23

はァ？
APLやりゃいいんだろ？

>>24
クラスがあるのとOOは違うだろ
Object Oriented は概念の問題。

だれか>>17を何とかしてくれ。
プログラマが全部あいつみたいな奴だと思われたら迷惑だぞ。

>クラスがあるのとOOは違うだろ Object Oriented は概念の問題

馬鹿な学生は出なくて良いＹＯ！クラスベースのOOPだって「OO」が入ってる。

>>21
ObjectCobolってなかったっけ？

>プログラマが全部あいつみたいな奴だと思われたら迷惑だぞ。

　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜ ２ちゃんでは、ブビ坊叩きはが普通だＺＯ!!
　（　　　　）　 ＼＿＿＿＿＿＿＿＿＿＿
　｜ ｜ ｜
　（＿_）＿）

Object COBOLじゃなくて、OO-COBOLだＹＯ！>>29

INVOKE指令が追加されてるだけ、って強調されてる。（どういう心か知らんが）

>>28
だーかーらー
OOP = Object Oriented Programming
オブジェクト指向'で'プログラムをすること。
わからん？

何か話がおもしろくない。下らん>>32

壮絶だな・・

しかし飽きもせず長続きするね、議論が・・・（議論か？）
OOが浸透しようがしまいが、俺はどっちでもイーよ。
浸透してもフォローできるし、浸透しなくても仕事あるし。

浸透してないところってどこにあるんだろう？
OSだってC++化してるし。

意外に、元コボラーがやるサーバJavaが、クラスを全て関数イメージに隠蔽してたりして。

>>36
Unix + Cな環境では、浸透していない。

UNIXのC++プリコンパイラは相当昔からあたよ>>37
StroustrupもUNIXまわりの人じゃないの？知らないけど。

>>17は OOPL を使ってるだけで、
OO してる気になってる厨房であるに三十八票。

下らねー>>39

煽られたら、名前の17を消すだけＳＡ！

>>40
じゃぁ、消せよ

>>38
処理系が存在するのと、浸透してるのは違う。

あと、プリコンパイラって何だ？
トランスレータのことか？

>>36
OSってC++化してるの？

プリコンパイラじゃなかった、プリプロセッサ（C++→C）>>42

WinNTからC++混じってるそうだＹＯ！>>43

>>43
BeはAPIがC++だよな。
ほかは・・・知らん

>>44
そうだよって、そんないいかげんな話をもっともらしく語るなよ

>OOPL を使ってるだけで、OO してる気になってる厨房

こういう意見てどういうところから出てくるんだろう？
OOPLを使うと、講義や本を読むだけよりも、劇的にOOPに対する理解が深まるに決まってるのに。
だって、プログラミング中って、どうやったら楽して書けるかって考えるでＳＹＯ！

てことは、39はブビ坊？

> OOPLを使うと、講義や本を読むだけよりも、劇的にOOPに対する理解が深まるに決まってるのに
それは絶対にない。OOP

それは絶対にない。OOP の本質は設計で、
実装とはまた別の話。
コーディングする暇があったら設計してろ。

>それは絶対にない。OOP の本質は設計で、実装とはまた別の話。
>コーディングする暇があったら設計してろ。

すごいレスです。
OOPのPがプログラミング（実装）と知らない人みたいです。

>>17
知らんことに口出しするな（UNIX環境）

え”ー。知らんのはお前だＹＯ！>>50

だって自分は使ったもん。プリプロセッサを知らんのだろー>>50

>>51
42の最初の一文読んだ？

>処理系が存在するのと、浸透してるのは違う。
>あと、プリコンパイラって何だ？トランスレータのことか？
↑
ま、どっちにしても、知らなさそうなやつの言葉。断言もしてないし。

おれの実感だと、OOの仕事は２割ぐらいかのぉ
おれの実感だと、浸透してるとは思いがたいのぉ
おれの実感だと、主流になるのにあと１０年はいるかのぉ
まぁそれでも困らない人がほとんどだから。

趣味でやる分にはいいけど、
仕事でやるのに考えないといけないことが増えるのはいやだねー

>>48
OOA/OOD/OOP を細かく分けるのが通の開発の仕方

>>仕事でやるのに考えないといけないことが増えるのはいやだねー

だから、今の時代、OO言語しか無いじゃん。ブビ坊は今まで怠慢だっただけＹＯ！

>>46
VB はもってないです。

俺は C++ 使えますし、
C++ の勉強したことで OO に理解が深まったといえば
そうなのですが、OO を使いこなしてるって感じではないです。
まだまだ勉強不足っす。
とりあえずデザパタや UML 勉強しなきゃならんです。

それと
> OO してる
ってのは表現が曖昧でした。すんまそん。

多分、>>48 はＳヨっていう滅びつつある人種だね。
基礎も知らないんだから。

俺はプリプロセッサだのプリコンパイラだのの発言の人じゃねーけど。

>だって自分は使ったもん。プリプロセッサを知らんのだろー>>50

オマエが使えばUNIXでOOが浸透しているということになるのか？
知らんことに口出しするんじゃねぇよ。

ひつこいＹＯ！>>60

60みたいなのを口出しという。

で、UNIX上でCでシェルから使うちっちゃいプログラム
組んで
「UNIXにはOOは浸透してないY0」って言うんでしょうか？
RubyやPythonやPerlは？

>>62
絶対人口の少ないRuby/Pythonはともかく、
PerlやっててOOPしてるって言うのもねぇ・・・

あ、一応機能はあるからOOPしてることになるのか。

UNIX でも OO は浸透してるだろう。
でも、UNIX で OO な仕事は、少ないのだろ。

GNOMEはOOじゃないの？

SolarisはOOじゃないの？
お仕事系のUNIXのメジャー環境だと思うが。
Solaris+Oracle+JavaってのがUNIX系のお仕事環境のメジャーかと思うが、
ここにはOOPの波は来ていないとでも？

>>63
OOPL 使うことと、OOP してることを一緒にするのはどうかと。

>>67
17の理論ってやつですよ

http://www.jp.freebsd.org/www.FreeBSD.org/ja/ports/index.html
FreeBSD Ports

オブジェクト指向言語で書かれたものもけっこうあるけど、
まだ割合としてはかなり少ないね。

>OOPL 使うことと、OOP してることを一緒にするのはどうかと。

そこまで厳密さは要らないＹＯ！
OOPL使ってんだから、「やはりオブジェクト指向は現実でした。」てことで。

アホクサ。
17はUnix+Cなプロジェクトが現在においても圧倒的多数を占めていることを
知らないらしい。

投げやりになってきたね。罵倒か。>>71
ま、あなたは、UNIX/Cマンセーで一生終わって下さいってことＳＡ！

>>71
フリーソフトはソースを配布してコンパイルしてもらう関係で
C言語が主流なんだよ。GNUはその理由でCでGNUソフトウェアを
書くことを推奨しているんであって、OOPが使い物にならないと
主張しているわけじゃない。

UnixがいくらCの母国と言っても、
ソースを公開しないプロジェクトでは、
とっくにC++、Java、Perl、Pythonが主流だよ。

>>72
何か勘違いしてるようだが。
俺は17の現状認識が誤っていることを指摘しているだけ。

>ま、あなたは、UNIX/Cマンセーで一生終わって下さいってことＳＡ！

そんなこと主張してないが。

>>73
>とっくにC++、Java、Perl、Pythonが主流だよ。

Java、Perlは同意するが、C++、Pythonには同意しない。
C++を使うような場面では、いまだにCが主流。

>>76
Solarisでの開発もCで書いてるの？ C++だろ？

>俺は17の現状認識が誤っていることを指摘しているだけ。

超程度の低い人ですね。
17（あ、自分か）の認識が誤ってるかどうか、根拠無いわけでしょ。
17を誤って認識してるかもしれない。

さらにそんなこと↑どうでも良くて、17は、きちんとスレに沿った話題となってるＹＯ！

日本ではともかく、欧米ではPythonもポピュラーだよ。
日本ではRubyだけどね。
Unix上でWWWアプリケーションやデータベースアプリケーションを
書いて飯を食っている開発者も多いと思うが、
そいつらは基本的にJava、Perl、PHP、Python、Rubyのいずれかだろ。
PHPは知らんけど、他はOOPLだな。

Unixのクローズドがとっくにオブジェクト指向に移行してるって人は
何を根拠に言ってるんだろ。
２ちゃんだから、言ったもの勝ちかなのかな？

>>Unixのクローズドがとっくにオブジェクト指向に移行してるって人は

で、どのレス？

>>80

>>73の
>ソースを公開しないプロジェクトでは、
>とっくにC++、Java、Perl、Pythonが主流だよ。

Perlはすでにオブジェクト指向言語。
1の統計ではPerl＞Cのようだが？

>>77
そもそも17が「OOが浸透しているところなんてあるのか？」
と言ったので、俺は、
>Unix + Cな環境では、浸透していない。
と言ったまで。

今読み返すと
>Unix + Cな環境では、浸透していない。
は、変な表現だけどね。

Solarisの事情は良く知らない。
うちの会社のSolarisのプロジェクトは、未だにCが多いね。よそは知らない。

誤）OOが浸透しているところなんてあるのか

正）OOが浸透していないところなんてあるのか

>>79
ちなみに俺の場合も、NTT、IBM、NRI、富士通の人間が同期にいて、
そいつらに話を聞いただけに過ぎないので、根拠はない。

だが、もともと「Unix+C」な環境で、C++がはやってるという話も聞かないから、
それほどずれてるとも思わない。

どうとでも書けるのがPerlの良い所。
Perlに関するデータは何の意味もないだろ。

>>78
Freashmeat なり Sourceforge を見てると
結構 Perl や Python ベースのが多いよね。
Webアプリはテキスト処理が多いからニッチに合っているんだろうな。

>>85
NTT データの友人は Java 使ってる。
部署によるだろうが大体は OOPL に移行しているようだ。
OO な開発しているかどうかは知らんが。
この場合は 汎用機 +　COBOL が UNIX + Java に移行したケース。

>>88
>部署によるだろうが大体は OOPL に移行しているようだ。

マジすか。
Unix+Cでやってたとこも、C++やOOな他言語に移行したんですか？

>>82
Perlをオブジェクト指向言語として使ってる人間なんて
この世にいません。(断言)

>>90
すげえな、あんた。

>>90
D・コンウェイさんは使ってるようですが。（ﾜﾗ
http://www.mmjp.or.jp/pearsoned/washo/prog/wa_pro41-j.html

>>91
君もスゴイよ。

17が何を主張したいのかは知らんけど、
OOPLは浸透してるといえるかもね。
=OOPが浸透してる、な訳はないけど。

>>92
そのページはネタページです。注意しましょう。

Perlを開発してる人達がPerlをオブジェクト指向化してるよね。
その人達が、テスト用にオブジェクト指向Perlコード書いてるよね。
この世の人じゃないってことか？>>90

IBMに出向してるうちの兄はPL/I使ってる。
回りの事はよくしらんが、多くが移行してる、
ってのは信じられんな。

つーか、ごく普通に考えれば、OOが浸透していないところなんて、
山ほどあるはずだろ。
どこもかしこもOOが浸透しているなんて考えるほうがおかしい。

Perlのオブジェクト思考系の機能はめんどくさすぎ。
あんなもん日常的に使うのは人間には無理。
>>92
そいつは、きっとインベーダーだよ(断言)

>17が何を主張したいのかは知らんけど、

>>36 を見てごらんよ。17の方がずっと賢いこと書いてるじゃん。

>>96
そういう人たちが書くコードは、OOPerlのテストのためのコードでしょ
OOPerlで何かを作ってるわけじゃない

>つーか、ごく普通に考えれば、OOが浸透していないところなんて、山ほどあるはずだろ。
↑
この例を出すのにみんな困窮してるんだ。だったら提示しろＹＯ！

>>100
いや、妄言にしかみえんけど…

>>102

>>69で、一例が出てるよ。

17の主張したいことがOOPLの浸透ならそれなりに浸透はしてるってことで問題ないんじゃ？

FreeBSD/X11のこと？>>104

XってOOだって言い張ってるよね。C言語だけど。

オブジェクト指向はかつてのパソコンと同じようなもんだよ。
使い方がわからなければ使えないし、効率を落とす。
パソコンが浸透してない職場なんて山ほどあっただろ？
あ、今でもか。

OOじゃない現場は今後もなくならんだろ。
でも、だからといってOOは浸透してない証拠にはならんだろ。

>>102
>この例を出すのにみんな困窮してるんだ。だったら提示しろＹＯ！

もう出てるじゃん。
UnixでCな環境だったところは移行してないって。

でさ、こんな例いくら出しても検証不能なわけ。
だから、普通に考えようぜって話。

俺のほうが逆に聞きたいくらいだよ。
なんでOOが浸透していないところなどない、なんて考えるのか。

>>108
まったくその通り。
17が「浸透していない所など無い」という妄想をすてれば良いだけなんだが。

OOが浸透してないところはあるけど、それが何なの？
浸透してないところがあるから、OOが幻想って結論にはならんでしょ。
浸透してないところがあるかという議論は無意味だと思うけどね。

>>88の言うように、大体は移行している、という程移行してるかどうか、
という問題じゃないのか？

>>111
>OOが浸透してないところはあるけど、それが何なの？

特に意味は無い。
が、妄想をそのまま垂れ流しにさせておいて良いわけでもない。

>>111
前スレから繰り返し>>11のような主張が出てるんで、
その流れで、OOの普及率の話になってるんじゃないかな？
(オレも拾い読みしかしてないんで、勘違いしてるかもしれんけど)

OOPが今の構造化プログラミングぐらいに浸透したとして、
OOPの方が効率が良い/悪いと考える人はそれぞれ理由をよろ。
効率が良/悪くなるのにどんな条件があると考えるかもよろ。

>>115
効率の定義は？

>>112
そういう問題じゃない。

>>36
>浸透してないところってどこにあるんだろう？
>OSだってC++化してるし。

と17が発言したので、そこかしこにあると言いたいだけ。
それを17が納得しない上に、妄想を垂れ流しているので、ここまできただけの話。

あ、決して浸透しないと考える人がいたらその理由でも。

>特に意味は無い。が、妄想をそのまま垂れ流しにさせておいて良いわけでもない。
↑
偏執者っていうか妄想家だね。
「浸透してないところは無い」って文章出してみなＹＯ！

17が出てこなくなったので、俺は消える。
スレ汚してすまんかった。
では。

「浸透してないところってどこにあるんだろう？ 」が妄想なんだ、すごい感覚だね！

「ＵＮＩＸでＣな環境」って言葉を何度も使えるのもすごいけど。
「ＵＮＩＸでＣな環境」でもＸはOOだって自慢してんじゃん。

スマソ
s/効率/生産性/
ってことで。でもって帰る。

>>121
だから、「UnixでCな環境」では浸透していない。
反論は無いんだな。
じゃ、終了。

一言いってからじゃなく終了しろ。そうじゃないと終わらん。

>だから、「UnixでCな環境」では浸透していない。
>反論は無いんだな。

ちゃんと読め。「UnixでCな環境でさえ、XはOOだ」だＹＯ！
それから、「UNIXでCな環境」てのは卑怯すぎる。

うんうん、俺が全部間違っていた。
「UNIXでCな環境」という表現も変だし、浸透していないという俺の認識も誤りだ。
悪かったな、17よ。

反論
「UNIXでCな環境」で、相当昔からプリプロセッサC++が発生している。

くだらん。

>>127
おっしゃる通りで御座います。
全て私の認識不足でした。

厨房が一人紛れ込むと、ここまでスレが迷走するという、見本スレだな。

どっちにしろ、検証不能だわな。
こういうのは、総研とかに金を払えば調査してくれるのだろうか？

ごめんね、書きすぎたよ。>>129

何か、２ちゃんで謝られると、後味悪いね。

>>120
17でまくってるじゃん。
わざわざYO!とかつけて分かりやすく

OOPL の普及率なのか
OOP の普及率なのか
OOA/OOD を用いた OO 開発の普及率なのか

これに限らず、前提をはっきりさせずに言いたいこと言い合ってるので不毛になる

>>132
つーか、ネタだろ。真に受けやがって（藁

参加して無い多数の人は、どっちが勝ちか、
なんてどうでもよくて、ただくだらないから
早く終わらないかなぁ、と思ってる。
という事で、どんな終わり方でも、相手が
勝ち誇っていようと、相手の勝利、などと
当人以外は誰も思わんから安心して終わらせてくれ。

>>127
UNIXでOOが普及してるってことの根拠にそれは無いだろと思うが…。

>>136
ごめん、俺が悪かった（マジ）。
もう消える（マジ）。

>>134
禿堂

>>136
誰からみてもオレの勝利だＹＯ

>>140
勝利って何だよ
厨房臭さを撒き散らして周りが引いただけじゃん

ちょっとねたふり。俺のOOの定義はこう

OOPLはclass(それに類する)キーワードを持つ言語
#まんせー

OOPは情報隠蔽・カプセル化・継承・ポリモを使用すること
#まんせー。ただし場合によってはただのグローバル関数が役に立つこともある
#その意味で俺はOOP原理主義否定派

OODはOOPでプログラムする前提で設計すること
#そもそもプログラミングは設計と区別できるようなものではないからOOD自体よく分からん

OOAはドメインをモデリングするときにOOという言葉に関係のある方法論を使うこと
#モデリングが方法論でうまく行くとは思わない。モデリングはソフトウェアだけではなく
#科学的思考を要求するすべての分野で必要とされていることであり、人間の「知性」に
#あたることなのだから、うまく行く方法論があるなら歴史的発見だ。

OOは使う人・文脈によってころころ意味が変わる。ただのイメージ。

こら、「140」は偽者だＹＯ！

俺の定義はこうってんなら、あ、そうだけど。>>142

多くの人は順番的には逆だとしてるよ。OOからOOA/D/Pが派生したと。
後、老婆心から言っとくと、「クラス」って出すと、
２ちゃんではオブジェクトベース知らないやつ、って突っ込む学生が出るＹＯ！

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

>>142
いまさら用語定義はつまらんＹＯ！

>>142

ネタふりに反応。
オブジェクトってのは俺としては、

1、なんらかの形で保持出来て、他者と自分を識別出来る
2、ある方法で指定された事に大して自身が反応する事が出来る
3、別々、と識別された物は別々の状態を保持する事が可能

という感じか。
オブジェクト指向ってのはこれを中心に何かをする事、かな。
Cのstatic変数等で隠してファイル毎にモジュール化する方法は、
1でひっかかる。

146は「ＹＯ！」を使ってるけど17じゃないＹＯ！
もう、これ以降は「ＹＯ！」で判断しないでね。
（関係無いレスごめんなさい。火種になると困るので）

>>147
とりあえず、用語定義は、これに異論がある奴がやってくれＹＯ！
http://www.zzz.or.jp/~iizuka/EOO/Japanese/oofaq-j/oo-faq-toc.html

OOPL使えば、OOPしているなんておめでてーな
ベテランのCOBOLerの集まっているとこなんか
Javaのメソッドや変数にすべて
public static
つけてるってーじゃねーか

>>149
了解。特に異論は無い。

>>150
このスレには
OOCOBOL を使って
「自分は OO を駆使する優秀なソフトウェア技術者だ」
と思ってる人しかいませんが何か?

このスレを読んで、
オブジェクト指向について語る人間には
近づかない方が利口であることを学びました。

駄スレもたまには役に立つという一例でした。完。

OO-COBOLのリストみたけど、さっぱり分からんかった。
難解さではC++の１０倍はあるね。(断言)

>>150
逆にGNOMEみたいにC言語でOOPしているプロジェクトもあるよね。

モチーフもそうだな。

このまま下がっていきますように。

こんな馬鹿スレはひさびさに見たよ。
板を間違えたかと思ったぐらいだ。

違うな。ＯＯを理解したつもりになってるＶＢ房かＶＣ房だろ。

俺学生なんだけど、オブジェクト指向の良さごときが理解出来
ないで暴れてる人が多いことに危機感を感じる。
もしもオブジェクト指向技術を磨いてプログラマになったら、
貴重だから、いい思いできるのかな？それとも逆で、まわりに
足引っ張られるのかなって不安。
まあ、プログラマになんかならないのが一番良いかもね。
まあ、社会に出るまでは当面一人でオブジェクト指向使ってようかな。

>>160
>俺学生なんだけど、オブジェクト指向の良さごときが理解出来
>ないで暴れてる人が多いことに危機感を感じる。

君が何をどう感じようと、誰も気にする人もいないし、何も変わらないんだけど。
当面なんて言わずに一生一人で引きこもってなちゃい。

はたして
学生ごときがオブジェクト指向の良さを語れるか、どうか。

> 俺学生なんだけど、オブジェクト指向の良さごときが理解出来
> ないで暴れてる人が多いことに危機感を感じる。
悪さごときを理解できないで、盲信してるのもいる。

> もしもオブジェクト指向技術を磨いてプログラマになったら、
> 貴重だから、いい思いできるのかな？それとも逆で、まわりに
希少価値がつくほど少なくもない。

> 足引っ張られるのかなって不安。
郷に入りては郷に従え。
空気が読めないとコミュニケーション出来なくなる。

> まあ、プログラマになんかならないのが一番良いかもね。
その通り。

> まあ、社会に出るまでは当面一人でオブジェクト指向使ってようかな。
好きなことは仕事にせず、趣味でやるのが幸せ。

オブジェクト指向の悪さも良さも理解したなら、良さの方が
多くの場面で上回ることに気づくだろう。
ただ、ドキュソにあわせなくちゃいけないってのは残念な
状況だね。

>>160
学生の質も落ちたな

今どきの大学なら、オブジェクト指向は常識として学ぶだろう。
現場のレベルの低さにがっかりするかも知れないが、いずれ
常識知らずがちゃんと淘汰される。

>>163
> 好きなことは仕事にせず、趣味でやるのが幸せ。

これは違うだろ。

> 多くの場面で上回ることに気づくだろう。
50% を超えると断言できる根拠は？

>>168
「構造化プログラミングが良い」と感じる正常な感覚を持った人間なら
当然「オブジェクト指向が良い」と感じる。

これはセンスというか向き不向きの問題。感じない人はプログラマに
向かない。

>>168
構造化プログラミングが良さを発揮する場面が50％を超えると
断言できる根拠は？
言えないだろ？
でも感覚から明らか。

>>168
そういう検証不能なこと質問して楽しい？

>>169-170
センスだの感覚だの、さすが抽象的だね。

>>172
それで？抽象的だから間違いだとか？（ﾜﾗ

>>173
書いても無意味だって事。

OOPを否定してる人はOOPの何が嫌なの？

>>160
たぶん君のような優秀な（ぷぷ）人が現場にはいると
浮きまくるであろう。よくいるよ、現場の人間を
小馬鹿にして浮きまくっている自称天才くんが

>>174
元の質問の無意味さを指摘する意味はあるよ。

>>175
いろんな意見があります。
スレを読んでください。

>>175
多くの場合、理解出来ないだけ。
やろうとして挫折したとか、慣れてないから
面倒だと感じたとか。
>>176
結局176のようなドキュソ人間が大半なので
低レベルな現場にはいかない方が良い。

>>177
センス的に(感覚的に)正しいから、質問は無意味だといえば、相手は納得する？

>>175
共通しているのはオブジェクト指向の利点が理解できないということです。

>>180
センスで感じていることに対して、根拠を要求するのは
普通間違ってると思うけど？

>>180
プログラムが正しいことも一般に証明は不可能だが
プログラミングができる相手なら分かってくれる。

それと同じ。これが分からないならプログラマやめた
方が良い。マジで。

　　　　　　　／￣￣￣￣￣＼
　　　　　　　|　　おまえらも　|
　 ∩_∩　　|　　　　　　　　　　|
　（´ー`）　<　　暇な奴ら　　　|
　（　　　）　 |　　　　　　　　　　|
　 |　|　|　　 |　　だなぁ　　　　|
　（___）__）　 ＼＿＿＿＿＿／

>>179
>低レベルな現場にはいかない方が良い。

大手と呼ばれてるところの大部分がレベル低いから悩むかもね。
部署によってはレベル高いところもあるんだろうけど。

>>184
オマエモナー

最近、あんまり的はずれな意見だと、相手にする気力が無くなってきてる。
このスレでの暇つぶしにも、飽きてきたんだろうな。

>>185
大企業はたいがいソフト丸投げだろ。作ってるのは孫請の、マンション
のワンルームにあるようなソフトハウスのドキュソか学生バイト。

学生バイトの方が平均すると質が良かったり（ｗ

しつこく上げてるの誰だよ？
楽しいのか？

と言っている179もドキュソだな

楽しいよ>>189

>>185
大手の場合は、入社したときは優秀なんだけど
だんだん社内競争で、要領のいいのが残るという
消去法により、レベルの低いのしか残らなくなる

>>178
質問を変えます。
OOPLのどんなところが嫌ですか？

>>185
名詞を良くみて見ろ。
総務部とか書いてないか(藁

2chって年配の人が結構多いと感じるね。
男尊女卑だとか、韓国人差別だとか、オブジェクト
指向が新しいだとかの化石的な意見を良く聞く。

>>194
つーか、知らないの？
大手でも○投げせずに実際に開発してる部署があって、
レベルの低いやつらが多いことを。
学歴は高いんだけどね。

>>195
それを年齢差別って言うんだよ。
イジメで自殺させても、遊んでたって言うんだろ？

>>195
前二つは十代が多いと思われる。

プログラマーの学生バイトなんているのか？
学生のうちから働けるほど知識がある人なんているのかい？

>>195
ていうか結構、古い価値観のひとが
集まってるよ。で、それは年齢には
関係なく、親から洗脳されてるわけだ

そろそろ誰かPart3立てとけ。

>>196
それって昔は「△△総研」「××中研」「◎◎基礎研」とか言ってたのが
ご時世で開発部署になって、元研究者の人達がソフト書いてるような部署
でわ...

まぁまぁ、差別や年齢はOOと関係ない。批判目的で利用するのはやめようや。

>>196
ちゃうよ。
俺が知ってるのはNとFとH。

>>199
漏れは学生の頃バイトしてたよ。まわりにもイハ°ーイいた。
１件受けると月３０万くらいだね。３件くらい掛け持つと
月９０万くらい行く。夏休みとか。院生の先輩は「就職すると
収入激減」と言ってた。

あんたが使ってる外注にもきっといる（藁
メールには反応するが、会社に電話してもあまりいない。
ソフトはまともだが、打ち合わせにはあまり出てこない。
そういうのはたいてい大学院生。

Nxxデータは、低レベルなのが多い。
Nxxからの出向とか左遷とかが特に。

>>206
xTTからxTTデータへは左遷といわないんでわ

HPはレベルが高いという噂だが、知ってる人いる？

DATAの社員に聞くと、xtxでとって、いらないのはDATAへまわすってのが手口らしい。

このスレ、見る度にレベルが落ちていく気がするんだが。

>>210

俺には >>1 がいちばんレベルが低く見えるが。

>>210
最初の方がレベル低かったぞ。17とか。（ｗ

>>210
いや、ずっと最低レベルのまま、微動だにしない。

>>213
これが正解だろ

>>205
いいねえ。
俺は院生だけど、知り合いと組んで　SOHO 的に小規模 Web サイトの構築やってる。
だいたい単価が10万くらいか。
絵心ないのにロゴとかも描かなくちゃいけないのが辛い。
（たまにデザイナに投げるけど利益でなくなる）
CGI や PHP のコードだけ書きたいもんだ。

part1は一時期まともだった時期があるけど、オブジェクト指向派が占拠
したときだったな。
それ以外は低レベルな煽り合い。

>>215
あー、その分野も２〜３年前はかなり吹っ掛けることが可能だった
らしい。学生だけで作った会社もかなり調子良くやってたよな。
○ン・ザ・エッ○とか（藁。

でも参入障壁低いからねえ。個人営業でもできちゃうから。今は
おいしくないでしょ。

>>216
ＯＯ派が生産性の話題を無視するからじゃん。

>>217
どの業種も同じだが、短期的には新しい物に飛びつけば利益が
出る。中長期的には先見性や経営戦略が必要になる。

>>219
私の友人に新しい物を追い続けて自転車操業な人がいますが
貧乏学生みたいな生活してます

そろそろＯＯに戻しましょう。17 さん出番です。

>>218
生産性の話題は無視してないだろ。
煽りやアホ統計は無視してるかもしれないが。

オブジェクト指向は好きだけど C++ は嫌い。

ネタふり。
OOというと、生存期間がわかりにくくなりがちなので、
GCなんかと併用される事が多い気がするんだが、
GCってどう？俺は嫌い。不自然だから。

何が不自然？

こう、参照辿る所が。
リファレンスカウントは嫌いじゃないんだが、
他の方式はどうも。

Cで実装する時に、スタック内無理矢理覗いて参照され
てるかどうか確認、とかなんか裏技っぽくて好きになれん。
いちいちリストにぶらさげる、とかはもっと不自然、
というか面倒だし。

☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆
☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆是非うんこを☆

gcは参照が無くなったobjectを自動的に消すってだけ。
消されるタイミングが重要ならfinally呼ぶ。

>>226
でもXtとかMotifとか、「どっちがfreeする」問題で
間違えたりしない? GNOMEは知らないけど。

>>229
する。
だから、どっちの方法も好きになれんからOOっていま
いち好みに合わないんだが。それを言ったらconsセル
も使えなくなっちゃうけど。

そこらへんはOOシンパの人はどうなのかなぁ、と思ったから。
ってこのスレじゃ無駄か？

ここは、OOシンパじゃなくてOOシンジャのスレです。似て非なる物。

>>230
いや俺はGCマンセーだから。

>>232
そうか。
まあそれが時代に合った、正しい考え方だろうな。

でもじゃあ、せめてアーキテクチャが型情報提供しても良くない？
x86で無理してやるのってなんか嫌なんだが。
ってx86使わなきゃいいだけだろうが。

こう、向いて無い物の上で無理してるような感じが
ちょっと嫌なんだよなぁ。
Cは駄目な所たくさんだけど、x86の上に載せるには
自然な気がする。
まあx86が古い、って事で終了なんだろうが、RISC
系も型情報は提供しないよね。
あんまり詳しく無いけど。

>>233
いや、むしろRISCの方が「Cマシン」として最適化されてると思う。
キャリーフラグがなかったり、rotate命令がなかったり、Cで使わな
いものは省かれてる。

x86は…PL/MXマシン？（藁

型情報をサポートする高級言語マシンというのは、RISCの「平均的に
は高性能」なアーキテクチャに敗れ、RISCはx86の物量の前に敗れ(か
けて)...

C#やJavaが流行れば、どのアーキテクチャにもGC用命令(ってどんなだ
ろ?)がついてもおかしくないね。

>>234
そうだな。
RISCは命令が減ってるし(ってあたりまえだが)。

ハードはこれからはOOをサポートする方向で変わって行くのかな。
今の所OOPLというのは、たくさんのキャッシュにヒットさせていく
という現行のハードの方向性とは合わない物が多い気がするんだが。
C等で書いて、それをOOPLから呼び出し、とかはおそらく
シンパの好みでは無いと思うんだが、どう考えてるのかな？そこらへんは。
ハードは過渡期でこれからOO向けになる、とか思うのか、
現在の路線に合わない使い方でも十分早いからいいか、
とか。ちょっと考えがききたい。
VM(及びGC)嫌いなOO使い、とかはいないのかな？

>>223
同じく

>>226
C や C++ での GC は不自然な感じがしないでもないが
最初から GC がある言語だと、あんまり思わない。

>>235
> ハードはこれからはOOをサポートする方向で変わって行くのかな。
そういえば、むかしは Lisp マシンってありましたね。

ないよ

>>235
>今の所OOPLというのは、たくさんのキャッシュにヒットさせていく
>という現行のハードの方向性とは合わない物が多い気がするんだが。

静的型付けの OOPL はキャッシュ使わない。

>>238
はァ?
Lispマシンあったよ、少なくとも3社から売ってた。

>>239
ネタか?

ソフト的なメソッドキャッシュじゃなくてプロセッサの
キャッシュの話だよ?

>>240
メソッドキャッシュのことかと思った。
いままで OOPLがプロセッサのキャッシュにどういう影響あたえるか
考えたことなかった。大切な問題だなあ。

>>234もネタ。

>>241
OOPLだと間接参照が多くなるだろうね。局所性は悪化しそう。
gcに関しては、cache conscious(キャッシュに優しい?) gc
という言葉を聞いたことがあるよ。どういうのか知らないが。

うまく説明できないけど、クラスへのアドレスを直接持つかわりに
クラスへのアドレスのテーブルをつくれば局所性はよくなると思う。

通はプリミティブ配列。素人にはお勧めできない。

>>1
ばーか

このスレは元々ネタスレなんだからさあ、
トンデモな理由でOOPを拒絶する書き込みが命だよね。
絶妙なトンデモ具合で書き込むとカッコイイ。
でも、思い付かない俺はOOP中毒。

あ、そういうことか。それがわからなくて楽しめなかった>>247

やっぱ、クラスより、構造体に関数ポインタの方が良いよね。
だって、オブジェクトベースのOOPではクラス階層無いんだから。
．．．みたいな感じか？

その昔ＭＳ−ＤＯＳと共にやって来た Ｃ言語（構造化プログラミング）
処理、分岐、繰り返し、だけを使ってＧＯＴＯ文を排除すれば　すばらしい
プログラミングが出来ると云われていた。

しかしＧＯＴＯ文を使ってＣで書く人ってたくさんいました
構造化プログラミングの恩恵は実はローカル変数です
ソースが大きくなると使用する変数の数も当然多くなってきますので、変数名の
衝突は重要な問題でしたこの問題を解決してくれたのがローカル変数です
Ｃで経験を積んだ技術者がいまさらローカル変数が使えない言語を使いたいとは
思わないでしょう

数年前Ｗｉｎｄｏｗｓと共にやって来たＣ＋＋（オブジェクト指向）
隠蔽、継承、多態、を使って再利用性を高めれば、生産性が飛躍的に高まると
云われています

しかし継承も多態も使わずにＣ＋＋で書く人ってたくさんいます
オブジェクト指向の恩恵は実はクラスです、includeするライブラリが多くなると
使用する関数も当然多くなってきますので関数名衝突は重要な問題です
この問題を解決してくれたのがクラスです
Ｃ＋＋で経験を積んだ技術者がいまさらクラスが使えない言語を使いたいとは
思わないでしょう

つまんな〜い。

>>249
かなり核心をついてるのでage

>>249
激しく同意。
いいこと言うNE。

つーか、ネタはマ板でやれよ。

>>249
関数名の衝突だけなら、namespaceでいいのでは。クラス要らんよ。

そもそも衝突するような名前を作ってる奴がｱﾌｫ
名前衝突のみでクラスを使うﾊﾞｶは、コーデックを知らん痴呆

>>254
でも、カプセル化は（たまに）使いたい。
から、やっぱりクラス。

＞しかし継承も多態も使わずにＣ＋＋で書く人ってたくさんいます

これはほめてんのかな? 継承を使ってないクラスライブラリ
はテンプレートライブラリ以外珍しいと思うが、ライブラリ
無しなら相当生産性低そうだな

>>257
Cのライブラリを使うのです

>>255 のような人間は、これ
ttp://www.javaopen.org/jfriends/cforjava/を見てもC言語の貧弱さに笑いがこみ上げたりはしないんだろうな。

さいしょギャグかと思ったよ俺は。JavaPressの記事らしいね。

なんかネタなのか、本気なのか、分かりづらい奴が増えたな。
ネタだとしたら弱いし、本気だとしたら痛い。

http://www.javaopen.org/jfriends/cforjava/
最高ｗｗ　　ってネタじゃないのか？

なんかどっかで見た文章だし、パロディーだろ？

＞Q.なぜCでアプレットが書けないのでしょうか?
ネタだろ？ネタだといってくれｗ

じゃぁ、C厨はこのギャグページの面白さを理解するためだけにでも
OO覚える価値あり、と言っておく。

でもさ、「Java の惑星」があって Java 使いしかいないところに
C 言語のコードを持っていくとしたら必須じゃない？

どっちかというとCの惑星にJava使いが行くときの手引き書だな。

ネタだ。

しかし、えんどうさんって昔のfjあたりの発言をみる限りではバリバリの(死語?)
UNIX,C好きって印象なので、いつ宗旨変えしたのか驚きでもあります。
むかしの記事を検索したり読み返したわけじゃないので、誤認だったらご本人さま
含めましてスミマセン。

　　　　　　　　 ＿p___
　　　　　　　／　⊥　＼
　　　 　　　 |＿＿＿＿|　　ふーん♪
　　　　　　(( （　　　 （
　　　　　　　　（´く_` ）
　　　　　　　　　（　　 ） ))
　　　　　　　((　 く　く
ふ〜ん♪　 |￣￣￣￣|
　　　　　　　 ＼__,､＿／

http://www.javaopen.org/jfriends/cforjava/

Ｃ->C++->JAVA
と経過を辿った俺からするとインデックスだけで笑えるのだが
古文、漢文を知らない現代人と同じ感覚なんだろうな。

http://pc.2ch.net/test/read.cgi/unix/1004227343/

UNIX使いはC++をオブジェクト指向を使えないと考えている人が
少なからず居るようです。

何かすごい進行になってるねユニ坊たちの会話>>270

Delphi/KylixやIBMのWin/Linux開発ツール http://www.zdnet.co.jp/news/0111/06/e_ibm.html
によって、駆逐される人達じゃないかな。
GUIツールは、好き嫌いに関わらず、生産性が高いからね。

GUIツールは生産性高いが、VBやWindowsMAKER等の非OOPは除く。

>>270
このスレでUNIXでＯＯが普及してると言ってた連中が、いかにデタラメか
よく分かるスレだな。

>>271
彼らが書くものはKylixなどで置き換え不能だから、駆逐はされないでしょ。

ゾヌゥゥゥゥゥゥゥゥゥゥ！！
￣￣￣￣￣∨
　　 ／￣￣￣￣＼
　　●　　●　　　 　＼
／　　　　　　　 Y　　Y |
| ▼　　　　　 　 |　　 | | (´⌒(´
|_人＿　　　　 　＼ 　|＿＿＿＿ (´⌒(´(´⌒(´(´⌒(´
＼＿＿＿　 　　　　 ／＿＿＿＿）≡≡≡(´⌒;;;≡≡≡
　　　　＼＿＿＿＿＿＿＿＿）≡≡≡(´⌒;;;≡≡≡
　　　　　　ｽﾞｻﾞｰｰｰｰｰｰｰｰｰｰｰｰｰｯ

オブジェクト指向は糞

>>271
GUIツールの生産性が高いと思ったことはないが...
あ、もしかしてGUIアプリを作るときの話？

>>276
このスレッドは、OOPに落ちこぼれた人が憂さ晴らしにくる所のようだな。（笑）

>>273
ひょっとしてここで事実が語られていると思ったことがあるとか？
困るなぁ

>>278
むしろ寂しいOOPの人が憂さ晴らしにくる所かと

Ｃで落ちこぼれた人の間違いだろ。

オブジェクト指向って文系だよね。
アルゴリズムは理系だけど。
オブジェクト指向って主観だよね。
アルゴリズムは客観だけど。
オブジェクト指向って馬鹿だよね。
アルゴリズムは賢いけど。

理系なのにオブジェクト指向を理解できないバカ発見。

理系が多いUNIXはオブジェクト指向は流行してないもんね。

理系的にはOOって何か子供騙しな感じがするんだよね。
なんつーか、プログラミング方法論バブル？

プログラミング方法論なんて数学でも物理でもないじゃん。
甚だしく非科学的だよな。その有効性を定量的、客観的に
証明することができない。

その意味でのソフトウェア工学も似非工学だよな。
科学的客観的根拠が希薄で、あくまで流行だったり主観だったり。

論文書かなきゃオマンマの食いあげだから、
次から次へと方法論をでっち上げるんだよね。
流行らせたもん勝ちだよね。本が売れるし。

＞数学でも物理でもない
なにいってんだこのDQNは?
強いて言うなら経済学だよ

>>285
なるほど。やっぱり似非科学だ。

いくらエレガントな数学的モデルを構築したところで
経済活動に人が絡む以上、常にそのモデルから逸脱して行くんだよ。

プログラミング手法なんか、
いかなる数学的モデルでもありえない。

じゃ、プログラミング手法→プログラミングモデル>>288

経験上言わせてもらうならば、
クラスライブラリは、現在のプログラミングにおいて
有効というか、必要不可欠である。

関数ライブラリでは整理不可能なほど現在の
GUIアプリは巨大かつ複雑だから、クラスライブラリ
なくしては、収拾不可能。

OO設計の有効性は当方未経験のため言及不能。

ファイル数が多くなればディレクトリ構造無くしては、
（人間にとって）管理できないのと同じこと。
よもやディレクトリの有効性を否定はすまい？UNIXの人？
OOも同じこと。クラスツリーはもろディレクトリ。
情報量が巨大になれば、何らかの手法で整理整頓
しない限り人間には管理できなくなる。
これも定量的に証明できないからって否定する？

巨大アプリの構築にはOOは必要不可欠。
それは人間の情報管理能力に限界があるから。
ソースコードを何らかの手法で分割管理しなければ、
全体を把握することができない。
巨大アプリの全体像を把握するためには、
手続きのみをツリー上に整理する構造化プログラミングでは
追いつかない。OOが必要である。

まあ、まだ発明されてないだけで、
OO以外にも有効な、あるいはOO以上に有効な
何らかの手法はあるかもしれない。

UNIXでOOが流行らない（？）のは、
コンソールアプリがメインで
GUIアプリほど巨大複雑じゃないから、
差し迫った必要性が無いからじゃないの？

ＯＯに文系が喜びそうなまやかし（あるいは未だ未開拓の部分）が
あるのは確かだけど、そんなのが流布してたのははるか昔の話で
今現在はずいぶん地に足が付いた技術になってる。というか常識。
合理的な理系人間こそその有効性を察知できそうなもんだが？

OOの有効性が人によって理解されにくいのは、
ある程度の規模のプログラミングをしないと
実感しにくいというのがあるだろな。

MSが曲りなりにもOOしてるのは、
別に、伊達や酔狂や趣味嗜好、あるいはカッコいいから、
ではあり得ない。MSに限ってそんなこと・・・
あくまで実際的な理由。
それが無いとやっていけないんだと思う。

>>296
なるほどね。
OOって昔からあるのに、
Windowsの登場に合わせて復活してきたのは、
そういうわけか。
何か何となく皮肉な話だよね。

ちょうどC++が登場したのもあるか。

OOは巨大ソフトの作成に威力を発揮するとか言ってる連中はニセモノです。
この類の議論は、１０年も前に終わってます。
有名どころでは、吉田某が同じようなことを言って、
コテンパンに言い負かされてました。

「OOは大規模開発でこそ有用だ」
↑この言葉はOOをわかってるかどうかのリトマス試験紙に使えます。

別にUNIXの人や理系の人がOOに否定的な訳ないでしょー。
そういう風に書いて煽ってる奴が一人かせいぜい２〜３人
いるというだけでさー。

>>299
威力を発揮すると言うか、OOじゃないと無理なんだと思う。
MSが開発環境としてC++を使う理由はそれしか考えられない。
たとえへぼいOOだとしても。

>>299
「ＯＯは少人数でその人数から見た場合の大規模開発を行う場合に有効だ」

純粋OO原理主義者の方には不本意な話かも知れませんがね。>>299

そういや吉田の爺も理系だったな。

>>299
「OOは大規模開発でこそ有用だ」
小規模開発では無用だなんて誰も言ってないよ。

ジャンケンプログラムの設計と実装で意見が結構分かれた
ところがOOの本質を見事に表しているような。

>>306
別に何も分かれてなかったと思うが？
なにか、特定の発言に罠だのなんだのと因縁つけた馬鹿はいたが。

別にＯＯじゃない大規模開発だってあるだろ。

>>306
だれかが書くと思ったよ。

ジャッ(・_・ )ノ ジャッ(・_・)ノ ジャッ( ・_・)ノね♪♪

こんにちは。情報システム板からやってきました。

今、情シス板で「オブジェクト指向の本質は、イベントドリブンだ」と主張している
人がいるんですが、これが正しいのかどうか素人なので分かりません。

この人を信じていいのでしょうか？

>>310
駄目。

>>310
一言で本質を言えたら楽だよね。

>>312 同意
私は一言で本質を言い現したがるような奴は胡散臭くて信用しません。
ほうれんそうとか
さ、し、す、せ、そとか標語を作りたがる奴も同類です。

>>306
オブジェクト指向を理解してないからネタとの区別がついてない。
ネタで嘘を教える人がいるのは 2chの常識。
OOP派ならどれが本当でどれがネタか分かる。

>>310　だめ。

オブジェクト指向は数学的じゃないとかいってるやつ
情報数学やったことある？

>>314
＞オブジェクト指向は数学的じゃないとかいってるやつ
＞情報数学やったことある？

オブジェクト指向に数学？
継承に関して、集合論とかグラフ理論とか？詳細希望。
どっちにしろオブジェクト指向に数学を使っても、
あんまり役に立たないと思うけどなぁ。

>>311-314
＞ひとことで本質を言えたら楽だよね。
＞オブジェクト指向は数学的じゃないとかいってるやつ
＞情報数学やったことある？

感想：やっぱりオブジェクト指向って胡散臭いなあって思いました。

>>314
あんたのが一番ネタっぽく見えるんだけど、どうよ？

>>316
でもオブジェクト指向使ってるでしょ？

>>315
>どっちにしろオブジェクト指向に数学を使っても、
>あんまり役に立たないと思うけどなぁ。
情報数学知らなくても OOPはできる。でも参考にはなる。
詳しいことは情報数学の本を読んで。

>>317
ジャンケンプログラムに答えている一人は典型的なネタスレ。

>>319
＞詳しいことは情報数学の本を読んで

ボロが出るんで退散ですか？

>>310
イベント駆動型フレームワークに必要な
多態を記述するのに合理的な考え方ではあると思う。
本質というのとは違うんじゃない。

>>319
情報数学って聞いたことないと思ったら、
数理論理学・計算機科学など情報分野で使われる数学一般のことか。
で、どの辺りが OO と関連するの？

>>315
カラーペトリネットを使ったオブジェクト指向プログラムの動的検証
という論文を読んだことがあるのでグラフ理論は末端的に関係してるといえる。
それをいえばなんでも関係させることができるが。

現在、情報数学の知識が人に教えられるレベルではありません。
大きな書店にいけば情報数学のコーナーがあると思います。
>>315さん >>322さんには詳細を教えられなくて申し訳ないです。

>>320
オブジェクト指向も理解できないやつに言われたくない。

あ、もしかしたら型理論のことか。それなら納得。

>>324
そうだと思います。
書店で情報数学の本をみていたらオブジェクト指向のことが
書いてあったのを覚えていただけというお粗末な話です。

オブジェクト指向は生き方さ。

オブジェクト指向は死に様さ。

オブジェクト指向は小宇宙さ。

何でオブジェクト指向ってあんな記述法なの？
英語べったりというか、なんか昔の化石言語の匂いがする。

大体、OOなんていう得体の知れない略語使う時点で
オブジェクトなんて幻想で、本当は幽体指向なのでは？

オブジェクト指向批判にはもう疲れた。

>>330
必死で弁護するからダＹＯ！

OOって金髪ネーチャンのアヘ声だから、
英語べったりも仕方がないと思われ。

>>330
じゃあ、人生先生よんでこい。(w

オブジェクト指向は人生そのものです。

あ、人生大先生を知らなかったかな。。。

>>333
誰それ？強いの？

最強。
素人にはおすすめできない。

えーと、現役が説明したほうがいいと思う。(w
おれはもう学会とは縁がない。

>>336
これは目に余る！
http://ton.2ch.net/test/read.cgi/rights/1004805400/
参照。

オブジェクト指向は構造体に毛が生えたようなのもの

プログラミング診断室などの偉大な著書を書いた
藤原先生の御言葉です。

時代を先取る偉大な人は言う言葉が違いますな。
先生の言うオブジェクト指向が腋毛程度なものと
認識されるのは何年後のことなのでしょうか？

構造体とクラスはちがう。

>>340
構造体の中に毛（関数）が混じってるように
見えたから、そう言ったんでしょうな。
調べもせずに直感的に・・
ま、奴はDQNだからね・・・

>>341
OOP否定派はだいたいクラスを構造体+関数と思っているよね(笑

>>845
>char (*(**hoge[0])[1])
コンパイラ通るの？

>>342
事実じゃねーか。
それとも属性＋振る舞いか？（ぷ

呼び名を小難しくして、
偉いんだと勘違いしてるだけの馬鹿＞OOP信者
自分の頭で考えることの出来ない馬鹿＞OOP信者
教科書を鵜呑みにする生真面目な馬鹿＞OOP信者

スレ違いです。すみません m(__)m

>>344はたぶんクラスを構造体的にしか使った事ないと思われ。

>>344
属性＋振る舞い = 構造体 + 関数

>>346
あーゆー考えって、やっぱC++の生噛りから来てんのかねぇ。
C++でさえvirtual classの継承とか考えれば
あんな結論にはならんと思うのだが。

>>348
仮想関数がそんなに便利か？
多態性（ご大層な用語。ぷぷ）が便利な場面なんて限られてるじゃん。

クラスが関数をメンバにできる構造体に過ぎないかといわれると本質的ではないけど、
C++の実装は実際そうなっている事を知らないとハマルよね？
virtualではないクラスを作成できてしまって、しかもそれが便利だったりするから、
OOPは上手くいかない事が多い。
C++で仕事していてOOマンセーな人って、言語外に厳しいルールを設けているんだよね？

>>349
ジョークか？

構造体なんてものも本物のプログラマからすればキッシュに過ぎないと思われ。

>>352
キッシュって何？

確かにOO原理主義者が偉そうな用語を振り回すのは鼻につく。
OO否定派ってかなりそういう用語が嫌いなだけでは？
構造体がメモリの塊に見えるような人にとっては、クラスは構造体+関数に
しか見えないし、継承も単なるメンバの追加にしか見えないけど、
そういう人にとってもそれなりにOOは便利だろう。
Cがアセンブラのプリプロセッサの性質を濃厚に持っていて、
C++に至ってははじめ実際にCのプリプロセッサだったのは、
単に実装が楽だったからではなくて、本来そういうものだから。
その意味で、>249って結構鋭い気がする。
まあ極端に過ぎるけど。

お料理

クラスとＯＯを混同するのはいいかげん止めよう。

>>349
virtual functionの話なんてしてないのだが。

>354
つまり、C++のクラスを構造体としてしか見えない人にとっては
Cの構造体すらまともに理解できてないって事ね。禿銅。

>>357
用語の言い換えはもういいよ。

オブジェクト指向なんだから、読んで字のごとくオブジェクトを指向する
のがまずあるんだろ。
多態にしろカプセル化・継承にしろ、その「考え方」を補助する
テクニックに過ぎないだろ。
オブジェクト指向は考え方だから、Ｃでも実装できる。
（しんどいし、わざわざそんなこともしないけど）

>>358
だからさぁ〜、
言い換えてんじゃなくて、
全然別の用語だって言ってんの。

ひょっとして君、
「そこはif文じゃなくてwhile文だろ」
と指摘されて
「用語の言い換えはもういいよ」
って答える人？ ププププププププ

>360
実装に近い立場で見れば関数＝手続きになったりする。
そして、そういう見方をする人でもまともなプログラムは書けるだろ？
いいかげん小難しい用語に酔うのはやめようね。

>>361
だからvirtual classは関数じゃないって言ってんのに (藁

せっかくだから訊くけどさ、
実装に近い立場で見れば関数＝手続きになったりする人にとって、
実装に近い立場で見ればvirtual classは何に見えるんだ？

virtual classってなに？

>>363
多重継承では1つの基底クラスが複数回継承される可能性があるでしょ？
その時、そのbase classを1つだけ継承するか
それとも、それぞれ別物として複数継承するか
を選択できるわけ。
で、1つだけ継承するようにした場合にその基底クラスを
virtual classとかvirtual base classとか呼ぶの。

ね、全然関数の話はしてないでしょ？

>>364
そんなもんプログラムに必要ない。
シンプルが一番。

>>364
virtual classなんてC++の仕様上の方便じゃないの？
他の言語でも出てくる？

vartual継承の話？
それってものすごく実装に近い立場で見た話では？

>>366
javaでは単一継承を理由に黙殺された(藁

ま、要するにCのポインタだけでは、構造体でのカプセル化もどきはできるが
継承までは実現できないってことが言いたいんだろうけどね。

>>362
unionが近いか? でも違うなぁ。

結局はクラスは型情報付のstructのようなものだとは思うが、
そういう見方だけならCでゴリゴリ書いててください、って感じ。

>>365
そんなもんが多重継承という意味なら同意。
でも知っていて損はないし、仕事だったりすると使わざるを得ない場面もあるんじゃない?

>>366
多重継承のやり方には
継承関係をグラフとして扱うやり方と木として扱うやり方があるわけで、
(っつーか、もうちっと小細工してるやり方もあるんだけど)
多重継承を使う言語を設計する上で考慮しなきゃいけない概念ではある。

C++ではデフォルトでは木として扱って
virtual指定されるとその部分はグラフとして扱うわけで、
virtualってキーワードはその切替スイッチ。
extended Smalltalkみたく木としてしか扱わない言語とかも
あるわけで、そういう言語には必要のない方便ではある。

>>367
うん。まあ、ある意味実装に近い概念だけど、
上に書いたように言語設計する上での概念も含んでいる。

継承はＯＯＰの癌。

>>368
っつーか、
Javaはvirtual classだのnon-virtualだの、
そんなヤヤコシイことしたくなかったんで
単一継承にした。
でも型的には多重継承みたいな事もしたかったんで
classの継承関係とは別にinterfaceを導入した、
って感じかな。

いつも実装と概念が混同されてるなあ。

一筋縄でいかない組み方をしたら、デバッグ・テスト関係も
一筋縄でいかないのは当然。継承？死ね。
組んでる奴だけがわかっているようなオナニープログラム（マ）は、
ハッキリ言って効率悪いので会社ヤメレと言いたい。
所詮オブジェクト指向の名を語った自分の自慢なんだろ？

ＧＵＩツールに頼らなければ、クラスなんて効率悪いだろ。

＞一筋縄でいかない組み方をしたら、デバッグ・テスト関係も
＞一筋縄でいかないのは当然。継承？死ね。
＞組んでる奴だけがわかっているようなオナニープログラム（マ）は、
＞ハッキリ言って効率悪いので会社ヤメレと言いたい。

そういうのばっかりだったからオブジェクト指向やデザインパターンができた。

>ＧＵＩツールに頼らなければ、クラスなんて効率悪いだろ。
禿同

エディタに頼らなければ、プログラムなんて効率悪いだろ。

cat でコードを書く、これが通のやり方
一文字もタイプミスできないという諸刃の剣
素人にはお薦めできない

CUIでクラスオブジェクト組みたくありませんが何か？

GUIで組むって方がどういうのか全く想像つかないんだが、
もしかしてjava使いってCaseツールなしではプログラム書かないってこと？

笑える

俺は何書くにしても emacs、Windows 環境でも Meadow で
困ったことないんだが。

>ＧＵＩツールに頼らなければ、クラスなんて効率悪いだろ。

この摩訶不思議な発想に乾杯

>>366
>virtual classなんてC++の仕様上の方便じゃないの？
>他の言語でも出てくる？

C++以外の多重継承できる言語はふつう
デフォルトで virtual classになる。
二重include禁止と同じような考え。
同じクラスが何度も継承されるのを禁止している

JAVAは多重継承の代わりにインナークラスを導入した。

>>383
ＶＣ＋＋房は
１）VisualStudioがあまりにも便利なので慣れ過ぎてしまう。
２）なんで動いてるのか判らなくても組める
という2点で他の言語に転換させようとすると使えない、というのが
採用担当者の間では定説です。

dialog editoとicon editorr以外のどのへんがGUIなんだ？あれ

>>385
C++もある。

>>388
interfaceの事が言いたかったんじゃない？

interfaceは最後の手段だ。使ってはいけない。Ｃ

>>390
そんなわけないっしょ
UML知らないとか？

ＵＭＬではインターフェースって多重継承やるためにあるの？

インターフェース!=継承
多重継承＝＝集約
ってとこじゃない？
C++でさえ多重継承なんて
設計ミスった時以外は使わないよ
俺はね

あなたは正しい

>>393
mixinやアダプタをやるのには多重継承が便利だと思うけど？
ま、自分はC++使いじゃないからアレだけど。

>>388
class A{ ... class B{ ... } }
JAVAは B から A のメンバにアクセスできるけど
C++はできないので、似てるけど違う。

class A extends Frame implements WindowListener{ ... }

class A extends Frame{
　　class B extends WindowAdaptor{ ... }
}
多重継承できれば
class A extends Frame, WindowAdaptor{ ... }

みたいにできるので、多重継承の代わりになってると思うけど . . .

インナークラスはレキシカルクロージャみたいね。

>>396
> 多重継承できれば〜多重継承の代わりになってると思うけど．．．

なんか言ってる意味が分からんけど…

>>398
多重継承があればインナークラスいらなかったんじゃないかな〜って意味。

クラス（学級）崩壊？

もしJAVAに多重継承があれば
class A extends Frame, WindowAdaptor{ ... }

みたいにできるので、多重継承の代わりになってると思うけど .

やっといってることがわかったよ。

多重継承できれば〜ので、多重継承できないjavaではインナークラスが多重継承の代わりに
なってるってことね。BからAのメンバにアクセスできるって話もつながった。

でもインナークラスと多重継承ややっぱ違うと思うけど。インナークラスは複数のインスタンスを
もてるから、多々重継承(?)。ってゆーより使い方としては委譲に近いのか…(!?)

幻想？

>>403
妄想！

>>1

その統計って単に使える人の人数に比例してるんじゃない？

>>405
違う。

むしろ
「使えると思ってる人数中で本当に使えてる人の数」
っぽいが

オブジェクト指向という名前が理解率や成功率を下げている。

SmallTalk指向という名前にすれば、もっと理解できたはずだと思う。

メッセージの概念が希薄な C++ や Java でオブジェクト指向の成功を語る方がおかしい。
C++やJavaは、メッセージじゃなくて、まんま関数ではないか。
構造化と、データ-関数の結び付きを表現しやすくしただけではないだろうか?


SmallTalk を使えば、デザインパターンなどオブジェクト指向の概念がもっと良く分かるし、
C++やJava のプログラムをオブジェクト指向と呼ぶことに違和感を持てるはず。

SmallTalk とオブジェクト指向を切り離したことが、
オブジェクト指向軽視傾向の原因だと思う。

>>408
指向なのに言語の評価と同一に考えてる時点でダメだろ。(w

>>409
オブジェクト指向 == SmallTalk みたいなプログラミングの仕方
だと思う。

よって、C++/Java でオブジェクト指向を実践するのは無理があると言いたい。
これは、C++/Java 自体の言語の評価とは別。

C++/Java はすばらしい言語かもしれないが、
これらの言語でオブジェクト指向を完全に理解し、実践するのは無理だと思う。

言語のオブジェクト指向実践可能性と言語自体の評価を同一視してはいない。

>>408
> SmallTalk とオブジェクト指向を切り離したことが、
> オブジェクト指向軽視傾向の原因だと思う。
電波発信中ですか？

>>411
SmallTalk やって、オブジェクト指向が理解できたのって僕だけ?
C++/Java ってオブジェクト指向じゃないじゃんって思ったのって僕だけ?

恥ずかしいなぁ。

SmallTalkやってる日本人って１４人しかいないしね。

>>412
OOとOOPを混同してる典型だね。
OO==OOP==Smalltalkですか？（藁

＞オブジェクト指向 == SmallTalk みたいなプログラミングの仕方

漏れはObjective-Cマンセーのイタイ厨房だけど、
漏れ以上にイタイひとハケーン。

>>410
> オブジェクト指向 == SmallTalk みたいなプログラミングの仕方

違います。(w

>>414
SmallTalk 以外で OOP できるかどうかって話だと思う。

C++/Java でやる OOP は OO--P と呼ぶべき物では?

SmalltalkとObjective-CとJAVAって、いくつか共通点が有ると思うけど…
どの機能があれば、おっしゃっている「オブジェクト指向言語」の
要件を満たすとお考えでしょうか？

[receiver message]のようなSmalltail風な表記じゃないの？
字面だけ見たってしょうがない。

いくらオブジェクト指向言語を使っていても、ほんとうにそれを
意識してうまく使ってるやつは残念ながら少ない。
Ｃと同じ感覚でしか使ってない連中が多いのは事実。

>>420
オブジェクト指向の醍醐味は言語では無く思考と設計である
っと言うことを理解してください。。。

ていうか、まともに使いこなせなかった人たちの自慰スレでしょ？

それはチミだけ。 >> 422

>421

その思想と設計を実現するために作られた言語か、そうでないか
ということを理解したほうがいい。

>>418
Java/C++ は、

プリミティブ型(int, doubleとか)がクラスでない。
データが実数か複素数かで操作を変えるとき、
意識して double型を Doubleクラスにしなければならないのが面倒くさい。
Double にした後、Math クラスをつかうときにまた double をとりだすのが面倒くさい。

メタクラスを取り出すのが面倒くさい。
インターセッションが不可能。
インスペクトが面倒くさい。

手続き(Block)をメッセージとともに飛ばせない。(objc は別)

MVC環境を構築することはできるが、MVC環境での開発はむずかしい。


面倒くさいと書いたものは、本来、
オブジェクト指向開発ならば、簡単にできるはずのもの。

>[receiver message]のようなSmalltail風な表記じゃないの？
>字面だけ見たってしょうがない。

同感。カレー粉をふりかけてインドカレーっていったら
インド人にどつかれてしまう

おにぎりに刺身を乗っけてお寿司って言われても
美味ければ別に気にしないけどな。
何か問題ある？

疑問なんだが、なぜこのスレはRuby厨が暴れないのだ？
Ruby厨 != Rubyユーザー
である証拠か？

>>427
それを出し、「これが寿司だ」と言って説明した場合、
外国人が寿司を理解できるのだろうか?

>>427
構造体に毛が生えればクラスと逝っているC++厨と
たいして変わらないな。

Ruby房ってrubyつかってないだろ？
踏み込んだ話はできないんだよ。

プログラム全体を眺めたときにさ、全部が全部OOでやる必要はないんだよね。

>>430
ちんちんに毛が生えれば大人と逝っているRuby厨と
たいして変わらないな。

結樹です。
ちんちんに毛がまだ生えていません。感謝しています。

>>427
全く同感である
ただし、付け加えて言うなら、寿司飯にネタをのっけた方が寿司としてはおいしい
また、寿司としておいしいなら、飯の方もおにぎりというより寿司飯になっている

>>425
これまた、付け加えて言うなら、
Smalltalkは、
　インターフェースがない
　カプセル化を破壊しやすい
　最近はMVCより、Selfから産まれたMorphicが流行りである
　環境とイメージが一体なので、ちょっとしたコードもサイズが大きくなる
とかがあるね
それでも、オブジェクトを扱うには最適な言語であるのは間違いない
C++/Javaは、どうしても、クラスベースにならざるを得ない
（たとえ、どんなにオブジェクトを意識しても）

好きなのは、プロトタイプにSmalltalk、本番にC++

>>424
アホだな〜。
オブジェクト指向に言語は関係ないんだよ。
構造化プログラムするときに構造化言語は必須じゃないだろ、オブジェクト指向に
よってデザインされたものを実装するのに純粋なオブジェクト指向言語は必須じゃ
ないんだよ。。ここまでいわね〜とわからんのか2ch厨房は。。

>>436
構造化プログラムするときにしたって、
構造化言語を使ったほうが
より適した抽象が得られるし
構造化された思考が促されるだろ。

オブジェクト指向にしたって、
ある言語でオブジェクトを素直に表現できるかどうかで
思考にも影響するだろ。実装言語にせよ、設計言語にせよ。

どうせ食うならおいしい寿司のほうがいい。

>メタクラスを取り出すのが面倒くさい。
>インターセッションが不可能。
>インスペクトが面倒くさい。
>
>手続き(Block)をメッセージとともに飛ばせない。(objc は別)
>
>MVC環境を構築することはできるが、MVC環境での開発はむずかしい。
>面倒くさいと書いたものは、本来、
>オブジェクト指向開発ならば、簡単にできるはずのもの。

直接的にオブジェクト指向とは関係ない機能ばっかりだね。
こういうこと言うと「オブジェクト指向とはなんぞや」って、めんどくさい話になりそうだけど。

> どうせ食うならおいしい寿司のほうがいい。

確かに、、、。
ですが私は寿司が苦手です。

>>440
そういう問題じゃないだろ(笑

Linux上でlocalhostのHOST名をゲットする方法に悩んでます。
ap_get_server_name関数が怪しいとは思うのですが・・・
詳しい方がおられましたらご教授くださいませ

>>433
>ちんちんに毛が生えれば大人と逝っているRuby厨と
>たいして変わらないな。
そうだな。皮がむけてないキミでも大人と名のれるほどだからな。

設計している時は、言語は関係ない。
C++ や Java は、コーディングしているときに、オブジェクト指向を意識できない。
C++ や Java は、昔作った部品を探したり、調べる時に手間がかかる。
Smalltalk なら、簡単に把握できる。

C++ や Java は、オブジェクト指向設計を実装するのを支援する言語ではないと思う。
オブジェクト指向の1パラダイムであるクラスと継承とインターフェイスを利用して、
コード量とコード管理の手間削減を支援する言語だと思う。

>>444
設計している時は設計言語により思考が束縛される。
そしてその設計言語の選択における実装言語の影響は否定できない。

C++でもJavaでもSmalltalkでも、
過去につくったコンポーネントを探したり調べたりする手間は
開発環境に依存する。言語自体の特性ではない。

また、C++やJavaのような静的型付け言語は
オブジェクト指向の機構であるクラス型や継承やインターフェイス型を用いて
オブジェクト指向による実装を支援している。

個人的にはSmalltalkマンセーだが、４４４の主張は荒すぎだと思う。

>>445
Smalltalkは言語ではなく、言語と環境とが一緒になった物だと思う。

>そしてその設計言語の選択における実装言語の影響は否定できない。

その理由は？
俺は言語選択は開発プラットホームと実装の手間を考慮して
一番最後に決めるけど。

>>446
環境を持たないで、普通のテキストエディタでソースを入力する
ような処理系もあるでしょ。

>>446
だとしたら、なおさらのこと
コンポーネントの検索などでC++やJavaと比較するのはおかしい。

>>448
環境一体でないSmalltalkについては、Smalltalk--と呼びたい。

>>449
Smalltalkと、VC++やJDK+Sunドキュメントを比較すれば良いと思う。

あのぅ・・・CoolPlexとかはダメですか・・・
あ、誰も知らない・・・失礼しました・・・

>C++やJavaは、メッセージじゃなくて、まんま関数ではないか。
>構造化と、データ-関数の結び付きを表現しやすくしただけではないだろうか?
smalltalkやった事無いから、どこが問題なのかわからない
具体的に説明してくれ

というか、「xx言語やればわかると思うけど・・・」的な表現やめない？
いくらでも代替表現があるのに、そういういい方すると一部の人にしか
伝わらない

俺的には
オブジェクト指向の最低ラインは実行時ポリモーフィズムだと思う

＞オブジェクト指向の最低ラインは実行時ポリモーフィズムだと思う
まぁ。。。GoFに書いてあることぐらいは最低ラインだろ。

GoFの紹介、感謝します。
間違いなく最低ラインと思います。同じ意見であること感謝します。

これだからガンダムヲタは・・・。

>>455
高度すぎて、そのボケにはツッコめん。
何繋がりなんだ？（笑

グフ？

強引すぎんぞｺﾞﾙｧ！
とりあえず、>>455は撮りが終わったら楽屋まで来るように。

Javaはブロックをデータとして渡せないが、無名クラスを使えばほぼ
同等のことができる。しかもtype safeに。

>>450
それではC++やJavaとの比較ではなく、
VC++やJDK+Sunドキュメントとの比較になってしまう。

例えばVisualAge/JavaはSmalltalkでJava開発環境を構築している。
その結果、非常にSmalltalkに良く似た環境が実現されている。
ならば４４４が問題としているのは個々のJava開発環境にあるのであって、
Java言語自体の問題ではない事になる。

>>460
VisualAge/Java と JDK+Emacs+Sunドキュメント と JBuilder は別物だと思う。
VC++ と gcc+Emacs も別物だと思う。
開発サイクルやコード管理が大きく違ってくる。
クラスやオブジェクトに重点をおいて管理、検索するという観点からも大きく異なる。

環境を別にして言語のみを比較しても机上の空論で終わると思う。

設計に関する全般を扱うようなスレ立てようよ。
非オブジェクト指向的な設計のノウハウとかも扱えるような。
もちろんオブジェクト指向的な設計もOK。
DBなんかもその範疇。
とにかく言語スレとかにちょっとづついい内容の書き込みがあるのに
設計用のスレがないためにノウハウが分散してしまってるからさ。

どうでしょうか？

ＤＢとオブジェクト指向ってどういう関係になるんでしょう。

>>461
「私は私と私の環境である」って言うしね

>>461
環境も込みで言語を比較するのは賛成だが、その時には
「この言語で提供可能な環境」だったり
「この言語ではこの環境は提供できない」だったりするべきで、
「VC++では..」は言語比較になってないと思う。
これは環境だけじゃなくてライブラリにも言える。
「MFCでは...」では商品比較。
「C++ではこのようなクラスライブラリは（素直に）表現できない」なら言語比較。

C++は(オブジェクト指向言語としては)最悪な言語だと思う。
ヘッダファイルの考え方自体は良いんだけど(時代遅れだけど)
クラスの実装部分もヘッダファイルに書かなきゃならない構造になってるのが痛い。
開発のときに、これは大きな障害となるのでは

だからそれを回避するテクニックがいろいろ出てくるんだろ〜ね
そういう本を読んでたら、なんだか自分で
新たに言語作ったほうが良い気がしてくるﾖ。。。。

どうしてもC++で開発を進めるなら、
「大規模C++ソフトウェアデザイン」くらいは読んどかないと

なんだかんだいってこのスレもOO使い増えてきたな。

>>466
そのほんのさわりをおしえてくだされ。

「大規模C++ソフトウェアデザイン」のテクニックはめんどくさすぎ。

>C++は(オブジェクト指向言語としては)最悪な言語だと思う。
>ヘッダファイルの考え方自体は良いんだけど(時代遅れだけど)

これは同意だけど、

>クラスの実装部分もヘッダファイルに書かなきゃならない構造になってるのが痛い。

実装部分はcppファイルに書いてるが？

C++ってオブジェクト指向言語だったんですか？

>>470
>>クラスの実装部分もヘッダファイルに書かなきゃならない構造になってるのが痛い。
>
>実装部分はcppファイルに書いてるが？

メンバ変数やプライベートメソッドのことを言ってるのでは？

>>472
「クラスの実装部分もヘッダファイルに書かなきゃならない構造」だから、
メンバ変数はあたらないし、privateでもcppに書きゃ良いじゃん。

>>471
C++は、オブジェクト指向プログラミングも可能な言語、であって、
オブジェクト指向をやらない選択肢もある。

>>473
C++批判派がよく言ってるのは、C++のprivateに書いてある
ことは、まともな言語なら、外部に出す必要のない情報だって
ことです。
変数やプライベート関数の情報も「実装」の一部です。

>>475
pimplイディオムを使えばprivateの中を覗かれる心配なくなるよ。
ポインタアクセスが一個はいるから、インライン展開とかつかっても
うまく性能が上がらないことがあるけどね。

他人に見せるクラスにはpimplイディオムを使うことを検討してみよう。

>>476
そういう一連の小賢しいテクニックを
やらなくても良いように、
言語側でそういう機能を提供してくれるなら良かったんだけど。
所詮構造体の拡張がクラスだからね…
もうちょっと考えてよ。Stroustrup。

ま、Ｃ＋＋も古くなってきたから仕方ないか。

>>476
チェシャ猫パターンというのもあるne.
EffectiveC++か何かに載ってたような。
公開クラスのメンバ関数を全てvirtual =0にするやつ。
どちらにせよ、単純なクラスでは使いたくない。

>>468-476
ちょっと言葉足らずでした。スマソ。
要するにprivateメンバはcpp側に書けるように
して欲しかったな…ということ。
ヘッダファイルの変更は他モジュール(クラス)にも影響するから･･･
pimplとかチェシャ猫とかで何とかできるんだけど、
どうしてもメンバ関数呼ぶのにポインタ１こ(vptrとか)
経由しなきゃならない。
だいたい>>475の言ってることと同じ。

ただ、いろいろC++勉強してからの結論だから
実感がこもってるけどね…

漏れ大学生だけど、プログラマーになっても
絶対にC++で中・大規模開発はやりたくないね。

ホント誰か漏れと新しいOO言語作らない？
D言語は実装の多重継承が無いのが気に入らない。
Eiffel辺りを参考にしてさ…

じゃEiffelでいいじゃん
Eiffelで不満な点てなに？

>>479
いろんな大学でいろんな OO言語が作られた。

しかし、C++ よりも広められることはなかった。
Java ですら、その浸透度で C++ に負ける。

現在の流行りは、関数型言語とエージェント指向言語。

こっちの方向で言語を作れば、広められるかもしれない。

エージェント指向言語


↑なにそれ

>>480
パフォーマンス
いや触ったこと無いんだけど(あれ？
今勉強中。
全部ANYから派生してるが、
小さなクラスでは邪魔だろ、とか。
表明は面白いね。
>>1とかも
http://www.ascii.co.jp/books/detail/4-7561/4-7561-0317-0.html
これ読むと良いのに。Eiffel本だけど、その部分を読み飛ばしても
読む価値はあるよ。

>>481
エージェント指向言語なんて存在するか？
いや漏れが知らんだけだけど

そろそろ逝きます。

最近、関数型言語ってはやってるのか？
昔からジミに使われてるだけのような気がするけど。

>>483
http://www.ascii.co.jp/books/detail/4-7561/4-7561-0050-3.html
これだった(鬱)逝ってきます

>>483
実際見たのは、正確には、エージェント記述言語。
検索すれば出てくると思う。

C++も正確には、オブジェクト記述言語かも知れない。

>>484
Webサービスのオブジェクトへの動的結合などで、
手続きのメタな情報が必要になったり、
手続きそのものをメッセージで飛ばすという需要が増えてくる
と勝手に想像しました。

オブジェクト「が」書ける言語よりも
オブジェクト「も」書ける言語の方がいいと思う今日この頃。

新しいOO作るんなら、実行時の継承。
生物の進化とか、ウィルス同志で、メソッドを転写しあうことが出来る、みたいな。
このスレにも出てたと思うが、オブジェクトベース。

>>488
そういうのは作ってみた。
だけど速度が遅いので萎えた。
無茶苦茶強力なJITを実装すればどうにかなるんだけど
JITの実装が相当面倒くさそうなので更に萎え。
今は速度重視で違う文法を検討中。

>>489

分かってると思うが、念のため確認。
インタープリタだから実行時の継承って意味じゃないＹＯ！

>>490
継承機構そのものがユーザーコード上での
実装対象になるという言語を組んだんだわ。
他にも色々と妙な特徴を持たせたせいで
インタプリタチックな構造になってしまった。
で、遅い、と。

僕が今、作ろうと検討しているのは、

a. 自己記述できる。(コンパイラもその言語で記述)
b. CやJavaなど任意の言語にトランスレートできる。
c. メソッドを型として扱える。
d. 環境を型として扱える。

こういう言語を、コードの自動生成を目的に作ろうと検討している。
変換用のルールベースをつくっておいて、その言語をあとで、
JavaやCやVBに変換する。

自己記述できて他言語にトランスレートできるから、
どんどんシステムが高性能になっていく。
言語の流行にも対応できる。

b, c, d の条件を満たすような、
SM制御用のOO--指向シェルを(仕事で)作ったことがある。
これを改造して作ろうと考えている。

継承に関しては、システムクラスからの1段階までとしている。

>>489
他言語へのトランスレート機能があれば、
インタプリタでもかなり高速にできると思う。
(世の中には、すばらしいコンパイラがたくさんあるので)

>>492
> b. CやJavaなど任意の言語にトランスレートできる。

イイネ、コレ。

> c. メソッドを型として扱える。

Java に変換できるのん？
VB は、かなり手間かと・・・。

> d. 環境を型として扱える。

これよくわからん。

> 継承に関しては、システムクラスからの1段階までとしている。

is-a やめて has-a オンリーにするって案は？

>>492
トランスレータは言語設計時の基本要求の関係で却下なんだわ。
本来の目的がエージェント記述用なんで。
元々JITを使って高速化することを前提に設計したので
概ね目的通りにできあがってはいるんだけど
JITなし時の速度が想像以上に遅かった(Python×１〜５程度の遅さ)ことと
JITの実装がこれまた想像以上にややこしげになったのが敗因。
現時点で機能的には十分なんだけどねぇ。

なんかすごいひとがいるのう。
もっと勉強してくるワ.

裸足で逃げ出せ

>>492
それって単にschemeでわ？

Eiffelの日本語のＨＰ
http://www.geocities.co.jp/SiliconValley/8632/
http://www6.plala.or.jp/sEiffel/
http://user.ecc.u-tokyo.ac.jp/%7Ess87039/eiffel.html
http://www.alles.or.jp/~corey/
http://kasiwa.sci.hokudai.ac.jp/cgi-bin/tiki/tiki.cgi?c=v&p=Eiffel

これ以上変な言語増やさないでくれ。
効率下がってしょうがない。

Eiffelって15年くらい前にできたと思うけど...

ネタスレなのでage

>>499
効率の悪い言語なら使わなきゃいいだけだが･･･

>>493
>環境を型として扱う
コンパイラとかエミュレータとか何種類も組み合わせて
開発していたので、そういうのがあると楽でした。

>>497
Scheme って数値計算もトランスレートできるのでしょうか?
(詳しく知らなくてすみません。)

492 で昔作った奴は、複雑な数値計算のトランスレート後のコードは
ソースコード内にいきなりバイトコードとか登場してきます。

>>499
ソースコードを C と Cもどき で書く必要があった。
(エミュレータが複数あったので)
トランスレート機能により、結構な開発速度だったと思う。

At 6:23 AM +0900 01.12.2, YahooBB@浅沼 美弘 wrote:
>今回はUPの勉強用として、
> 1.ユースケース入門
> （ユーザマニュアルからプログラムを作る）

この本には、ロバストネス図が、でてきますよ。
UPを著者がアレンジしています。

こういった本が売れるのですね。
コンポーネント系は、今年は人気がないようです。

Scottの本は、続々と訳本を出しますので
期待してください。
--

（株）テ●ノロジッ●アート
長●　●秀

--------------------------------------------
勘弁してくれーーーーーーー. また下手糞訳の本がでるらしい.
出版社は何してんだろう.

これからは、リフレクション指向開発。

糞設計でもいいからとりあえず動くものを汚くコーディングして、
そのあと動かしながら、コードを改善していくとともに、
そのノウハウを自分自身のスキルとして蓄積していく。

チームでやるなら、これほど迷惑なものはないが、
ひとりでやるなら、これが一番。

>>505
とりあえずオブジェクトの生成だけで動くものが出来る。
そのあと、オブジェクト（クラスベースの場合クラス）の振る舞いを変えていくという、
差分コーディングするなら、やっぱOOPだＮＥ！

1はどこへ逝きましたか?

リフレクションだの実行時継承だのは、システムユーザーには全然うれしくないねぇ。
プログラムの表現能力の向上ばかりに頭がいってると、言語作成自身が目的になってしまうよ。
オナニー言語は絶対に世の役に立たない。

現実のシステム上で満足に動くものを考えるために、まずGCとスレッドをどうするかを考えてみ。
OOとの相性はどんなかな？

>>505
そういう風にどんどん造語して満足するのは止めてくれ。
プロトタイプと利ファクタリング足せば同じことだろ。
これだからOO信者は詐欺集団と呼ばれるんだよ。

>これだからOO信者は詐欺集団と呼ばれるんだよ。

それは違う。505はOO反対派だよ、内容読んでよ。
506は、「505の内容はOOP以下」とかいてあるだけさ。

>>509
日本語にした時点で、造語。
日本語に混ぜた時点で造語。

オブジェクト指向を良く言う奴も
オブジェクト指向を悪く言う奴も
オブジェクト指向を理解していない。

所詮は道具だからねぇ。
他の方法論と組み合わせられないわけでもないし。

>>505
初期設計が腐ったプログラムは、後から手を入れても無駄。全部捨てて
作り直した方が早い。

っつーのは常識だと思うが。

うう、鬱です・・・。
・・・げっ、元気だして逝きましょう！
今やってること、どうやって、
ドキュメントに表現すればいいかわからん！

余談だけど：
オブジェクト指向はいいと思うよ。
ドキュメントにまとめやすいので。
もっと、いい方法がふじょうすればそれでもいいし、
うっ、お腹が痛い。

作ろうとしてるもんにも依ると思うけど・・
僕みたいなアマチュアにとってはいいかもと思う次第。

ただ、効率よく作れた試しがないような気もしなくもない。あれ？

あぼーん

売っても合法なんだろうか？

>>517
・・・見たけど、出品者の過去のデータ笑えますね・・・。

>>519
sage で頼む。

>>518
自分の物を個人的にバックアップするだけなら問題ないからな。
それが違法ならネオ麦に包丁売った奴もダメだろ。
買い手が違法コピーすることを知りつつあえて売ったのなら
幇助扱いされるかもしれないが。

>>516
その効率とは何？
作ろうと思ってからできあがるまで？
コードを書き始めてから動くまで？

>>522
>作ろうと思ってからできあがるまで？
>コードを書き始めてから動くまで？

どっちだろうな・・・。
ただ１から作ったほうがシンプルにできたかなと。
・・・変な日本語でしたね。すいません。

>>523
マジレスだが、効率を語る場合には、何の効率なのかを明示しないと
意味がない。

　プログラム実行時のメモリ消費量
　プログラム実行時の動作速度
　プログラム初期設計から動くものができるまでの時間
　プログラム仕様変更への耐性
　...

いろいろある。このうちにはトレードオフが発生するものも多いから、
目標を明確にしないと「あれもこれも」と言った挙句に、ダメなプロ
グラムができて終わる。

>>524

確かに。
アマチュア意識でプログラムを作る者が効率を語ったのは間違っていましたね。

>目標を明確にしないと「あれもこれも」と言った挙句に、ダメなプロ
グラムができて終わる。
意識してみます。

>>508
詳しく聞きたい。リフレクションや実行時にいろいろきめるのってすごく
柔軟性高くなるから、「やりたいと思ったことが何でも出来る」状況に
近くなる。これが利点だと思うけど、システムユーザーにとっては、何が
欠点となるのかな？

システムユーザってなんだ？

>>526
(特定の)システム(の)ユーザーにとって欠点となるのではなく、直接的な利点にならない。
言語によりリフレクションや実行時にいろいろきめることができるようになったところで、
それを活かしたシステムつくらんと無意味。手段を高機能にすることばかり考えていては
本末転倒だ。視点の違いがわかるかな？

だから、「リフレクションを使えばシステムにこういう機能を追加できる」という提案を聞きたいね。
そんなわけで、505は基本的なプログラミング能力が足りないに一票。

試行錯誤も必要だけど、それだけで十分じゃないよね。
理論の勉強をすると、試行錯誤ではここまで来れないなって思うことしきり。

>>528
システムという単語が何を指しているのか不明なんで、さっぱりわからん。

> 「リフレクションを使えばシステムにこういう機能を追加できる」
オブジェクトのシリアライズとか、カスタマイズしたサンドボックス環境を作るときには便利だね。

>>530
システムなんて抽象的な言葉を使っているのだから、特定の何かを指してはないよ。
わかりやすい言葉が欲しければ、例えば「プログラム」と言い換えれば君にも想像付くかな？

>> 「リフレクションを使えばシステムにこういう機能を追加できる」
>オブジェクトのシリアライズとか、カスタマイズしたサンドボックス環境を作るときには便利だね

リフレクションでオブジェクトのメモリ構造が完全にわかるという前提？
オブジェクトが持つフィールドに名前を持っているような言語なら、もし
かしたらできるかも。そうでない言語ならリフレクションから得られる情
報がシリアライズに役立つとはあまり思えない。530がどこまで考えてる
のかはわからんが、リフレクションが必要条件とは思えないな。

後者は、制限された機能群へアクセスするための統一された入り口を
作るようなことをするのかな？ それとも全てのメソッドアクセスに
フックしてセキュリティーチェックするようなこと考えてるのかな？
どっちにしても、リフレクションがどう関わってくるかが全然見えない。

そんなわけで、530の言ってることはよくわからん。

つか、リフレクション使って遊んでいるだけの人ってのもいないと思うんだが。。。
デザインパターンを使ったプログラムの実装に便利だし、
積極的に反対するものでもないと思う。

どうやら、リフレクションにはメリットが無いと言いたいようだね。
でもそれって、欠点かな？
もっと、何か弊害があるとか、そういう話を聞きたかったなあ。

>>532
530みたいに具体例出してみれば？

>>533
弊害なんてないでしょ。

ただ、技術で遊んでいるだけの奴にはいい言語なんて作れないと言いたいだけ。
リフレクションがどうのを論じる以前の話ができないんだったら、このスレ
ではこれ以上言うつもりはないよ。技術の背後にある思想や世界観なくてし
有益な議論にはなり得ないのだから。

ちなみに、俺はオブジェクト指向は大好きだ。(本題)

>>534
> リフレクションがどうのを論じる以前の話

なんの話のことだ？

＞技術で遊んでいるだけの奴にはいい言語なんて作れない
どこからそういう話が…

＞530みたいに具体例出してみれば？
Smalltalk の環境は リフレクションがなければ構築できない。
UnitTest ツールもリフレクションの恩恵を受けている。
Java で FactoryMethod パターンを簡易に実装するときも使える。

agege

> どこからそういう話が…
400後半にそういうやつらがいたろ？


> Smalltalk の環境は リフレクションがなければ構築できない。
> UnitTest ツールもリフレクションの恩恵を受けている。
> Java で FactoryMethod パターンを簡易に実装するときも使える。

なるほどね、技術的には使えそうだね。
そういう例を出してくれる方が説得力あって好印象だ。
念の為わかりやすくいっておくが、508からリフレクションを否定したことはないよ。

>そういう例を出してくれる方が説得力あって好印象だ。

例を出されないと説得力がない、などと感じてしまうような人は、
クヌース先生によってプログラマ失格の烙印を押されるがいい。

「思考の抽象度を上下自在にいききできる人」ってのが
先生がいうところのプログラマの適性だ。
たしかにこれは昔も今もそうそう変わるまい。

ま、たまたま実例が(今の話者に)みつけられなかった場合に
それを理由にうまく言いのがれる道具としては、役立つよね。「例を出せ」って要求は。

> 例を出されないと説得力がない、などと感じてしまうような人は、
> クヌース先生によってプログラマ失格の烙印を押されるがいい。

はいはい、机上で車輪の発明に専念しててね。

>机上で車輪の発明に専念

車輪の発明なら、現場のドキュのほうが余程得意ですね。
とっくに教科書に載ってることも知らなくても堂々としてる。

どうでも良いルーチンのコピペは好きだが
アルゴリズムの丸写しは嫌いだ。

ま、メタな話の世界に逝っちゃってる人は、放っておいてよろしいかと。

こういう観点で考えてはいけないだろうか？

生物は環境に適応するために進化を繰り返してきた。
生物の消化器官などは複雑化し、脳の思考回路も複雑化し
単純な生命体から人間などの複雑な生命体が誕生した。
宇宙の法則としてすべては常に複雑な形態へ変化していく
という学説がある。
プログラム言語の文法も複雑化していくのは自然の摂理で
ある。

私はJava,c,c++,VB,cgi,perl,ぐらいしか組んだことはな
いが、これだけ見てもコンピュータに人々が多くを求め始
めた結果、言語も複雑化してきたと思う。

オブジェクト指向は現時点でその有効性を疑問視する声も出
てきているがJavaやオブジェクト指向が廃れていったとして
も必ずまた新しい言語や思想は出てくるであろう。
ただし、プログラム言語を「言語」と考えた場合、言葉に文
化があるかどうかが根付く鍵となるが、Javaやオブジェクト
指向が出てきた背景を考えると既に文化といえるほど成熟し
た思想にのっとているため、成功例が増えれば自然と定着し
ていきそうな気はする。

はやくＣの考え方しかわからないやつがいなくならない
かぎり、オブジェクト指向プロジェクトは成功しない。

ＪＡＶＡ厨房がオブジェクト指向を語らないで欲しい。オブジェクト指
向がＪＡＶＡのような糞だと思われたくない。

>>545ばーか。
オブジェクト指向は言語によらず使えるんだよ！

>>547
そうだね。君には無理っぽいけど。

そういやGTK+って、CなのにOOやろうとしてるよね。
コードは美しくないけど、心意気は買うぞ！

定期age

>>549
え〜？？Ｃで書いたＯＯＰは美しいよ〜？

さらにCで書かれたものは理解が容易だ。

はぁ？

>オブジェクト指向は言語によらず使えるんだよ！
>え〜？？Ｃで書いたＯＯＰは美しいよ〜？
Java/C++理解できない奴の常套句

>>551
CでOOPを書いた時点でCじゃないっぽいけどな

>>551
思想的には、ちょっとイリーガルだけど美しさがあるな。芸術性ってところかな？
可読性が下がるという点では、激しく不同意。
多重ポインタって時点で、メンテナンシビリティに欠けるぞ。

>>555
OOPであっても、CはC。
Cっぽくなくなるんだろうけどね。

>>99
>Perlのオブジェクト思考系の機能はめんどくさすぎ。

どこが？ blessするだけじゃん。
あとはたんなるサブルーチンじゃん。

>>558
Perl のもともとの機能を使って実現しているので分かりにくい。
気分的には C で OO してるのと大して変わらない。
C++ と同じ後付け OO 共通の問題だ。

>>551 X window自体、Cでオブジェクト指向して作られているんですが... (元はCLU/Argus)
　　　

オブジェクト指向言語とそうじゃない言語の違いって具体的には
どんなものですか？

オブジェクト指向は幻想だと思ふ

オブジェクトの定義をコード上に書けるか、
オブジェクトというものを頭に描きながらコードを書かないといけないか、
の違いです>>561

OOが全能でないことは確かだけれど、ビジネスベースに載せられる代替案が無いのも事実。
趣味とか研究でやってるならいーけどさ、社会に出るとそうもできないのよ。
だから、OOが幻想と思うならそれはそれでいいだろうし、そういうやりかたすれば。

>>563
どもです。

>>564
>ビジネスベースに載せられる代替案が無いのも事実。
1の言うように、Cを使えばいいじゃん。

>1の言うように、Cを使えばいいじゃん。

WinでC開発は少ないヨ。
メッセージループのコードが膨大に膨れ上がるし、
Win32APIの数が１マソ近くになっててそれに対する構造体とかあって調べてると効率悪過ぎ。

>>567

だったら、VBでも、フレームワークだけC++のVCとかでもいいけど(^-^)

>だったら、VBでも、フレームワークだけC++のVCとかでもいいけど(^-^)

はあ？VBは死滅しましたが。

>>1 ある程度難易度の高い/複雑なプロジェクトは、
　　ＯＯを使う必要があり(目的: 情報隠蔽/相互依存性軽減)、
　　オープン・ソースではプロジェクト完了の義務がないので、
　　その成功率になる、と思った。

>>568
お前、自分で言ってること理解してるか？
これだからブビ厨は・・・ﾌﾟ

>>ビジネスベースに載せられる代替案が無いのも事実。
>1の言うように、Cを使えばいいじゃん。

客の希望する納期に、品質を確保した上でﾊﾞﾁｰﾘ収まるならCでもいい。
お前、できるか？

OO信者ってダメだなあ。
OOが生産性高いって前提でしか議論できないんだもん。
やっぱり、こういう盲信に支えられてるのがOOなんだよな。

>>573
はぁ？そういう流れになってないですが。
ブビチュウですか？

>>574
>はぁ？そういう流れになってないですが。

あなたに合わせて話をしてませんよ。

>OOが生産性高いって前提でしか議論できないんだもん。

って言ってる時点で土俵に乗ってるぞ、ｵﾏｴﾓﾅｰ
お前さんの発言とは意図が違うかもしれんが、
OOPと生産性云々と納期が守れるかどうかってのは、また違う話しなんだよね。

>>573
>OO信者ってダメだなあ。
>OOが生産性高いって前提でしか議論できないんだもん。
>やっぱり、こういう盲信に支えられてるのがOOなんだよな。

盲信でない意見を述べよ。
それができなきゃ、あんたもOO信者と同じ穴の狢。五十歩百歩。目くそ鼻くそを笑う。

(・∀・)　ｵﾅｼﾞｱﾅﾉﾑｼﾞﾅ!!

>560
非OOPLでOOPでやることの無謀さが良く分かる汚いソースだ
職人技てんこ盛りだからそれ相応の技術力がないと汚く見えるのかもしれない

さらに非OOPLの汚いソースはどうしようもないよね。

OOPLだとオブジェクトの中身が汚いコードでもその中に隠蔽されてるから、
あんまり問題にならない。差し替えたきゃ、そのオブジェクトのソースファイルだけ読み書きすれば良いし。

OOって、素養でしょ？実践するものではないと思うんだけど。

突然気持ち悪い文章>>581

スレが停止。

>>580
OOの恩恵をカプセル化でしか理解できないない奴。
コードの隠蔽だったら、逆にOOを持ち出すまでもないでしょ。

論理がおかしい>>583

OOでなくては綺麗に隠蔽出来ないだろう。
OOを知らないやつがフッカケテ来たんだね。

>>584
> OOでなくては綺麗に隠蔽出来ないだろう。
いや、情報隠蔽「だけ」なら OOPL でなくても可能。

外に見せるヘッダ。struct foo は宣言だけ。
------------
struct foo;

struct foo* foo_create();
int foo_do_something(struct foo*, param, param);
int foo_destroy(struct foo*);
------------

で struct foo は実装側で定義する。これは C で実際に使われてる手法だし、まったく無理の
ないコードだよね。

（もちろん継承とか多態とか絡んでくると、C だと綺麗に書けなくなるけど）

>>581
禿同。学校で習った言葉をただ使いたいだけの奴が多すぎ・・・

>>581, >>586
ブビ厨、発見。
おーっと、誤解するなよ。してもいいけど。
「ブビ厨の様に、実践投入するとデスマーチプロジェクトの要因を誘発するヤツ」
って意味だからな。決してお前らが、ブビラーだとは言ってないぞ。
実際は違うのかもしれないが、その発言からはそう受け取れる。

ちなみに、実践しない素養など無用。
より正しい発言に近い内容としては、
「OOって、素養でしょ？必要に応じて実践するものだと思うんだけど。」
つまり、必要でなければ無理にOOすることもないってわけだ。

ブビラーというのははつみみだが、ブイビャーを提唱。

いいづらいよー＞ブイビャー
ブイ房ってのは、どうよ？

ここ一年の煽られ言語の推移
VB -> Delphi -> Ruby -> VB

やる気になればメインフレームでＣＯＢＯＬでＯＯもスパイラルもＸＰもできるよー！
コボラー＠メインフレーマー＠ウォーターフォール会社、でした。出世せんわ。。。

>>585

>> OOでなくては綺麗に隠蔽出来ないだろう。
>いや、情報隠蔽「だけ」なら OOPL でなくても可能。

はっきり言ってちょー汚い。

>>587
>「OOって、素養でしょ？必要に応じて実践するものだと思うんだけど。」
>つまり、必要でなければ無理にOOすることもないってわけだ。

押忍！
開発者のレベルやプロジェクトの進行状況を無視して
OO的手法を無理矢理適用しようとする自己中キティガイに
浴びせる罵声として採用させていただきます！

>>589
んじゃブイビョー

>>592
どこが？　C++ で

　オブジェクト->メソッド();

とするのが

　関数(ポインタ);

に変わってるだけじゃないのか？

俺はむしろプライベート変数が外に見える C++ のクラス定義よりもマシな気がするなぁ。いや、
理由は良く分かるんだが。

>>595
> 俺はむしろプライベート変数が外に見える C++ のクラス定義よりもマシな気がするなぁ。
CでOOPしてプライベート変数を外に見えないようにするなら、
同じ手法でC++でもできる。
そういう部分では基本的にCとC++はそんなに差はない。

>>585
> int foo_do_something(struct foo*, param, param);
> int foo_destroy(struct foo*);

関数にすべてプリフィックスfooが付き、なおかつ引数の先頭でstruct foo*
を渡さねばならないことを冗長だと感じませんかい？

>>596
C++ で内部構造を隠蔽したければブリッジパターン使うのが普通だと思うが。C のコードと同じ
手法を使ってしまうと、メソッド呼び出しなんかが C++ 流に書けなくなってしまうからダサいコー
ドになるぞ。

>>597
C++ でそれやったら単なる馬鹿だが C だと別に違和感ないなぁ。個人的には。

>>598
本質的には同じだと思うけど。

>>599
何が？

>>600
CでOOPしてプライベート変数を外に見えないようにするには
ブリッジパターンを使うのが自然だろうということ。

まだ学生なのでよくわかんないんですけど、
データ中心アプローチとかだと、RDBMSがかなりのことをやってくれ
るんで便利なんですよね。アルバイトでプログラマやってたときもSQLで
ほとんど用がすんで、あとGUIをかぶせるだけって感じだったし。

でも、オブジェクト指向だとオブジェクト指向データベースなんて
あんまり使われていないので、結局RDBMSつかってオブジェクトと
リレーショナルデータベースのマッピングしなければならないのが結構
めんどうなんですよね。

まあGUIとかお絵かきソフトなどの分野でオブジェクト指向が便利なのは
よくわかるんですけど、会計とかの分野ではあまりありがたみがないのでは？

>>602
WebObjects（のEOF(Enterprise Objects Framework)）使えば、
RDBとオブジェクトのマッピングが非常に楽ですよ。
アポー製品なので、マクでしか動かないのではと思われがちですが、
Java2環境なら、一応All OK。漏れはWin2Kで使ってます。
SQLは、EOFが裏で書いてくれるので、PGが書く必要もないし。

オブジェクト指向なプログラム言語でなくても
オブジェクト指向は可能だけど、
オブジェクト指向的にコードを書くなら、
オブジェクト指向なプログラム言語のほうが簡単。

>>602
学生じゃわからないのは当然だけど、
業務アプリこそ、OOでメリットを享受できる（場合が多い）。
今のうち勉強しておくと、社会に出てからいいことあるかも。ないかも。
GUIなどの目に見える部分だけではなく、ビジネスロジックを記述することに
OOを使うのは、真実はどうあれ、もはや事実上の常識なのだよ。

重要なことを１つ。
プログラミングや関連技術の実装テクばかり磨いていても、
よほど天才的な才能がない限り、社会に出てからは長いことやっていけない。
３０歳PG定年説とか、３５歳PG引退説とか、聞いたことないかな。
要求に対してどういう形で答えるかとか、トラブルなどを解決するためには
何が必要なのかってことを考える勉強をしよう。
OOやその他プログラミング技術とは関係ないように見えるが、非常に重要だよ。

余計なお世話をしてしまった・・・鬱だ氏脳

OOといえば、アプ鯖で、OOをまともに実装してるのって、ｱﾎﾟｰ(元NEXT)のWebObjectsくらいだろ。
Enterprise Object Frameworkってやつ。
このフレームワークだけバラ売りしてほしい。

前に、興味本位でｱﾎﾟｰのWebObjects製品紹介の展示会に行って、NTT系のﾍﾞﾑﾁｬｰ
（NTTの社内ﾍﾞﾑﾁｬ第１号らしい）の社長のプレゼンとデモを見たんだよね。
光ファイバの構造を発明した工学博士。
いやー、すごかった。アプリが部品となってアプリを作り、それがまた部品となって
再利用されてアプリになる。オブジェクトのフラクタル図形って感じで、神、降臨って感じだった。
この工学博士社長の言った言葉で印象に残っているのは、
「私はアポーが好きなわけじゃないんです。WebObjectsのテクノロジーを評価してるんです。
これ以上のツールがあれば、すぐにでも乗り換えますが、今のところ無いですねー」
というお言葉。

で、価格もお手ごろなので、今、オレも評価中。
評価中なのだが。
今までオレがやってたことは、いったいなんだったのだあ〜(鬱)

そうそう、この工学博士シャチョーがWebObjectsで作ったソフトウェアが、
スミソニアン博物館に展示されてるんだと。
スミソニアンに入っている日本製のソフトウェアは２つあるらしいんだけど、
もう１つは、バーチャファイターだそうな（ワラ

WebObjectsってすごい安くなったんじゃなかったっけ？

>>608
去年の５月に、確かお値段を１／１００までsageたんだよね。正気の沙汰じゃないね(笑)
それまでは、同時アクセス数無制限の運用環境含めると、\700万以上だったのが、
いきなり\72,800だよ。ケタが１つ違うんじゃねぇのか？
NeXT時代は、ハードも含めると\1000万オーバーだったねぇ。良い時代になったものだ。
EOFという、RDBとアプリを連携させるフレームワークだけでも、数百万の価値があると思われ。
Javaのオブジェクトに、RDBのテーブル構造をマッピングできる。PGは、ほぼSQLゴリゴリから解放されるし。
UIとロジックを接続させるツールも良くできてるよ。
UIとロジックが完全分離できるから、Webデザイナにデザイン任せられるし。
JSPじゃ、完全分離は無理ですね。
しかも、異なる複数のRDBのテーブルを、１つのオブジェクトにマッピングできると。

日経ITProに出てた、
「イーズ・コミュニケーションズが複数DBのデータを一元操作するツールを販売」
http://itpro.nikkeibp.co.jp/free/NIT/NEWS/20011217/3/

「Webアプリケーションから複数のデータベースに接続する処理の開発コストを4割程度削減できる」
売り切りの場合で1CPUあたり価格は250万円かららしいけど、
これは、EOFでモデル間連携させれば、すむ話。
1CPUどころか、マルチCPU積んだ１サーバあたり、￥７万強で済んでしまいます。

でも、モノがいいからといって売れるとは限らないんだな、これが。
所詮、WebObjectsは知る人ぞ知るツールっていうか、マニアのツールからは抜けられない宿命か。
アップルがあまり力入れてないんだろうね。つーか、力の入れ方を知らないんだと思う。
コンシューマ相手に、誰でも使えるとゆーふれこみのパソコンの箱売り専門会社だし。
合掌。

＞599
そうだね。本質はおなじかもしれないね。x86アセンブラでオブジェクト指向
するのも、Ｃでオブジェクト指向するのも、C でやるのもRubyでやるのも。
ひょっとしたら、チューリングマシンでもできるかもね。本質的には同じだから。

ここでかんがえなきゃいけないのは、本質的に同じコードを、いかに簡単に、
わかりやすく書けるか、って事なんじゃないかな？(速さ、ってのは、�dでもなく
遅かったりしない限りは、優先度が下がるよね)

書きやすさが重要というのはもちろん。
OOってのは考え方の一つだから、どういう道具を使っても表すことはできる。
しかし、それをサポートする、あるいは促す道具を使ったほうがはるかに楽だ
し効率がいい。
まぁ、ごく当り前の話だが。

そうさなあ。

学生だと、あとからあとから仕様変更のリクエストが出てくる
プロジェクトってのをイメージしにくいんじゃないかなー。

プロジェクト開始時の要求仕様とまるで違うプログラムに進化
していくなんてことは、現場では珍しくない。で、仕様変更に
耐えやすいプログラムを開発する技術が大事なんだよ。

仕様が分析・設計フェーズで確定できて変化しないなら、業務
アプリケーションはRPGやCOBOLで書けば、ソースがそのまま
仕様書になるんで、それでいいんだ。問題は、仕様は変化するっ
てこと。仕様の変化にRPGやCOBOLは耐えられない（というか、
すごく高くつく）。

そういうことじゃない？

禿同

言語を大きく二つに分けるとしたら
「オブジェクト指向とそうでないもの」
に分かれるのかな

>>605
>社会に出てからは長いことやっていけない
一つの会社に定年まで居るつもりならそうだね。

OOであってもコンパイルした結果はOOでないのだから
部分最適化すると微妙だと思う。

デバッグ時OOで組んで最適化していくというケースはありなのでは？

例えば上位クラスを作って仮想メソッドを定義してから
汎用クラスを作って具体的実装をやるとか

暗号化とか画像ファイルや圧縮の読み書きの関数に
そういうのは多い気がする。

手続き一筋40年。

おいくつですか。。

水落ち一筋45年。

牛丼一筋１００周年

未だにＯＯで効率上がった（利益大幅増）プロジェクトの話は聞かないな・・・。
（仕掛け人サイドの情報は除く）
ＩＢＭの受けた仕事の破綻とか人口知能ベンチャーの破綻とかマイナス情報ばかり。

>>621
４つの価値のうち一番大切な「コミュニケーション」が不足しているものと思われ。

あと５〜10年は必要かな。
その頃おれはこの業界にいるんだろうか？
と、ふと鬱になってみたり。

>>622
利益ベースだっつうの。ＰＭあたりの「効率が上がった」なんて
与太話なぞ無意味。
本当なら、ＯＯマンセー会社が大幅利益増で人材募集拡大。
非ＯＯ会社が利益減でリストラ。
で自然と労働力移動が行われていなければならないでしょ？

結論。
クラス方式の言語は失敗作であった。
クラスはオブジェクト指向の敵である。

でもオブジェクト指向が目指したことそのものは
間違いじゃなかったんじゃ？

何を目指したんだっけ？

選民プログラマのハイソ化。
或いは、業界全体の階級社会化。

>>624
てゆうか非OOのVBでの請負仕事は大幅減益。
パッケージメーカーは以外にOOのDel使ってるでしょ。
で、非OOPのアクセス、VBでのパッケージは売れて無さそう。

募集状況見ると
C++が多く,C,Java,VB,Cobolが続く。
delなんか見当たらない。

それは募集の殆どが人材派遣だからでしょう

同じ値段で規模の大きいものを提供できるようになっただけで、利益が上がるわけないじゃん。
客も営業もぎりぎりのところでやってるんだし。もうちょっと競争社会で修行してきたほうが良い
のでは?

>>630

その募集でC++/Javaの案件のうち、OO的なプログラム開発
をしているプロジェクトはどれ位あるんだろう？

>>633
OO的が多くても少なくても、クラスライブラリ派生したらもうCには戻れん。
Javaなんて絶対に。

>>633

派遣や契約社員使って人海戦術で進めるプロジェクトは、手数が多く、でかく、遅く、拡張性が無く、
ダサくなってもいい代わりに、コーダーが悩まなきゃいけないような設計はしない。つまりインスタンスの
スコープ設計なんてもってのほか、コピペ歓迎、UMLなんて納品対象外なので不要、ツールを順番に
並べるためのフローチャートは必要、と来るから、OOPではなく従来の手続き型設計にしかならない。
だいたいこれが最近のでかくて金のあるプロジェクト。

# 手続き型設計が遅いとかいう意味ではないので、念のため。

いや、これはただの建前的な言い訳であって、本当はプロジェクトの上層部 (PMからメインの設計やる
SEあたりまで) にOOを「ふつーに」使える人が一人もいないってだけなんだけどね。以前そこそこの
人間が集まったのでシステムをOOで設計、開発、実運用してみたけど、別段問題はなかった (某生保)。
むしろあれが一番楽しかった。それ以外に、まともにOOでやってる仕事なんて見たことない。

RUPぐらいなんとか浸透しないものか・・

>>636
RUP ってなんじゃらほい。
育毛剤？

>>621
プロジェクトの評価は、微妙な点があるからなぁ。結局のところ「まったく同じプロジェクトを OO と非 OO
でやってみました」ってのは実際には存在しないし。

ところで「聞かないな」っつーのは、どのあたりの情報源をチェックした結果として言ってるの?　ソフトウェ
ア工学だと Communication of the ACM, IEEE Computer, IEEE Software あたりを読んどけっつー話を
耳にするんだけど、他にもチェックしてたものがあれば教えてもらえると嬉しいかな。

>>637
Rational Unified Process(TM)だろ。XPあればいらないんじゃない?

CでAPI直叩きとVBで、仕様があいまいなプロジェクトに、
どっちがどれだけタイムリーにテスト版を出荷できるか考えてみな。

# VBがOO的に最適だと言っているわけではないよ、念のため。

>>638
一太郎がある。結果は知らないが。

>>640 にとってオブジェクト指向とは、
コンポーネントをマウスでぺたぺたはることらしいです。

オブジェクト指向＝納期志向

オブジェクト指向が幻想と言うより、日本の職業プログラマに、
ある程度の向上心や理解力、好奇心といった健全な精神活動を
期待することが幻想なんだと思う。

>>644 が良いこと言った。
標準化のレベルを底辺にあわせて開発要員の単価を下げるのが日本のやり方。
生保、損保、銀行システムと渡り歩いてきてそう思う今日この頃。

オブジェクト指向って目的のことを達成するのに
異常に手間がかかることない？
Javaなり、MFCなら情報も豊富にあるだろうが、その企業独自の
クラスが数百もある開発環境だと、キーボード叩く時間よりも
ドキュメント眺めてる時間が数倍も長いんだよ。そういう環境だと
いかにオブジェクト指向がまどろっこしいか分かるよ。
関数型のほうが速攻性があるし実用的だと思うけどな。

>>646
関数型ってことは Haskell?

Ｃだろ。
アクセス制限だのインターフェースの儀式だの要らないから早い。

設計6割 コーディング2割 テスト2割

C を関数型と呼ぶかい…

＞アクセス制限だのインターフェースの儀式だの要らないから早い。
それでなぜ早くなるのかわからん。
川○氏？

独自のクラスが数百もある環境だと、クラスじゃなかったら数千になるだろうな、関数の数…

ｹｷｮｰｸのところ、OOﾏﾝｾｰなやつもｱﾝﾁOOなやつも関係ないのだ。
ひたすら精度とﾊﾟﾌｫｰﾏﾝｽを求められる組み込み系だと、
Embed系Javaであってもｸｿ食らえだし、
逆に業務系でｵﾌﾞｼﾞｪｸﾁﾌﾞに開発することを求められるｹｰｽもあるだろ。
ｹｰﾀｲのﾊﾞｯｸｴﾝﾄﾞなんて、未だにCだよ。
ｹｰｽﾊﾞｲｹｰｽなんだよ。
目的に応じた手段を選べばいいだけだ。
OOや構造化、その他を目的のようにカンチガイするからｵｶｼｸなるんだ。

クラスは複雑すぎる。関数が数千あっても呼び出せば、すぐ結果が
得られるわけだから整理されていればそっちのほうが楽だと思う

>>649
＞設計6割 コーディング2割 テスト2割

禿同。
ちまたにｺﾞﾛｺﾞﾛしてるDQNなSE/PGは、
設計1割 コーディング5割 テスト1割 虫取り3割
って感じだが。
漏れの親外車は、設計0.5割 コーディング9割 ｸﾚｰﾑ処理0.5割で鬱。
そろそろ潮時だな。

Web開発なら、ｱﾎﾟｰのWebObjects使うと綺麗に収まるな。
相変わらずｱﾎﾟｰとﾏｸ自体はｸｿだが。

>>653
関数がすべて、状態／副作用を持たない単純なものならね。

わかっとらんな君たちは。
OO = fool-proofなんだよ。
管理側の苦労も考えてくれたまえ。

>>651
クラス群だろうと関数群だろうとそれだけ多ければ分類されているだろう。
使っているうちに必要なクラス/関数は覚えるので長期的に見れば大差ない。

>>653
なんだそりゃ。実例を挙げてくれ。

>>650
互いに上下関係のない複数のオブジェクトが 相互作用するような
場合、アクセス経路で行き詰まるのです。

>>647
FPじゃないのかなあ

オブジェクト指向はお役所仕事のようなもの。
複雑怪奇なラビリンス。

>>658
言っているイメージが湧かないのだが。
friend 関数でも面倒だ、全部 public にしちゃえ、つーか全部静的関数だという感じか？
どんどんコーディングする前にコーヒーでも飲んでコードを眺めよう…

あえて例えるなら
会社オブジェクトと部オブジェクトと課オブジェクトと社員オブジェクト
とプロジェクトチームオブジェクトと銀行オブジェクトと取引先オブジェクト
を作って、人の移動、仕事の進捗状況、お金の流れ、バランスシートの
作成、人事を一括して扱うようなのを考えてもらえば良いだろうか・・・。

つーか、みんななんでそんなにこだわるわけ？
kernericに使えればそれで十分じゃないの？

kernericって何？

>>662
上下関係がなくても、関係がある場合はインターフェイスでまとめれ。

例の中の社員オブジェクトとそれ以外は Composite の Leaf と Composite にしておけ。

これでｽｷｰﾘ快便よん。

あ、662 はインターフェイスの継承を嫌がっているのか……。

それじゃいつまでたっても OO を有効活用はできないと思われ。

Ｃでいえばmain関数に全て書くようなやりかたですな。
そんなのＯＯではない。

部一つ、課一つ、社員一人のすばらしい会社クラスが出来上がりますね。

Haskellﾏﾝｾｰ

OOは、おんなじことを何度もやる場合に向いていると思う。

正直、構造化で作ってそれを何度も使うんならラッピングしてライブラリに
していったほうがいいんじゃないの？

結局のところ、TCP/IPとかHTMLとか同じように
漏れは、もっとコードが読みやすい言語がいいぞ
生産性うんぬんより

正論だね。>>670
ついでに関数によるラッピングとクラスによるラッピングの差を教えてやれ。

OOはラッピングで関係無い部分が隠れるので読みやすい>>671

OOの問題点は、オブジェクトの内部状態が影響することだと思う。正直。
それが使いやすい場合もあれば、使いにくい場合もある。
それは、関数型の時よりギャップが大きい。

誰かオイラーの公式をＣ言語で作って〜〜〜〜。おねがいだー。

>>668
クラスとインスタンスの違い。わかってる？

>>674
OOP の意味。わかってる？

そういう反感買う書き方やめい>>676

>OOの問題点は、オブジェクトの内部状態が影響することだと思う。正直。
内部状況を持たなければならないのは、開発するシステム自体が高度化し状態を持っているから。

そうでなければ、内部状態を初期化するinitメソッドを作っといて、内からか外からかコールすれば良い。
それだけ。

>>677
ごめんなさい。>>668 見て、ちょっとカチンときちゃったので
そのままの勢いでいやみ口調で書いちゃいました。

あと前スレが上がっているのでこちらをあげ。

わかりませんな。>>668のどこが間違ってるの？

>>679
まず、>>668 が何について言ってるか、についてですが、
直前の >>667
＞Ｃでいえばmain関数に全て書くようなやりかたですな。
だとすればクラスも何も登場しないので、
>>665-666の
＞上下関係がなくても、関係がある場合はインターフェイスでまとめれ。
＞例の中の社員オブジェクトとそれ以外は Composite の Leaf と
＞Composite にしておけ。
だと思われ、それを受けて
＞部一つ、課一つ、社員一人のすばらしい会社クラスが出来上がりますね。
だとすると、会社クラスは部一つ、課一つ、社員一人しかもてない
と、いう趣旨の発言だと受け取りました。

正直言って意味不明ですので、仮説として
クラスとインスタンスの区別がついていないとします。

そうすると…、会社クラスのコードに部クラスを使用するコードが書いてあって、
部クラスのコードに課クラスを利用するコードが書いてあって.........。
という、「インスタンス生成しる！」という突っ込みを入れたいコードを
想像してるんじゃないかなぁ…と。

>>677
このinit作業こそが悪の根源ナリ〜

ねぇ、 >>677 の言ってるのって コンストラクタじゃ駄目なの？

>>681
WinのC言語サンプルからしてInitInstcenceとかいうのあり。OOのせいじゃない。

>>682
良いけど、ｺﾎﾞﾗｰがJavaでヤッテル手で反OO軍団だよ。

>>658のアクセス経路に行き詰まるってのは分かる。
まあ、OO特有の問題ではないけど、OOだと表面化しやすい問題。
>>665のように責任関係をそのままComposite構造にしてしまった場合、
「部1-n課1-n社員」で社員→部への直接アクセスができなくなる問題がある。
さらに、社員→社員のアクセスも社員→課（→部→課）→社員という形でしかアクセスできない。
しかし、じゃあ直リンした方が楽かといわれれば、
最初の内は楽だが複雑になるに従い破綻は目に見えているといわざるを得ない。
今回のような問題だと複雑度がに従って
　直リンしまくり→Composite構造にする→Accountabilityパターンを用いる
のように臨機応変にすればいい。

>>684
ありがとうございました。
なるほど、データ構造を継承するのではなく、組織の形そのままに
クラスを構築するんですか・・・。

うう、個人意見ですけど、そうなるともはやＯＯの為に設計してるのか
クラスの不便さを回避する為に設計してるんだか、支離滅裂で訳わかんなく
なります。

いつのまにかデザパタスレになってるなぁ。

>>680
BU bu[5];
KA ka[12];
SYAIN syain[123];
とかいうのをどうやって実装するのかわかんなかったので

Composite　comp[100];
だと会社１００、部１００、課１００、社員１００になりませんか？

>>687
固定長配列に入れている時点で終わってます。

というか、それは C++ のソース？ Java のソース？
C++ だとしたら、それじゃスタックにインスタンス確保しちゃうんだけど...
(あと、配列は Type[] name って書こうよ。)

オブジェクトの生成手段は場合によって何が有効か違うから
自力で調べてよ(我等が経典 GoF 本 にもたくさん載ってるから)。
でもソースにハードコーディングしちゃう奴は糞だから気をつけてね。

あと、調べておいた方がいい言葉は
Collection 線形リスト 参照 ポインタ
かな？
んじゃ、勉強頑張ってくださいね。

>>685あ、いや、御礼を言われるほどうまく書き込みできなかったんだけどね。
少し間違って伝わったかもしれないので少し補足します。

クラス構造（例）
<スーパークラス/組織>-<サブクラス/部・課・社員>
１．「組織」を用いて、インターフェース統一
　　例えば、「営業成績」とかいうメソッドを「組織」クラスに定めておけば、
　　部・課・社員のどのクラスかを意識せずにメッセージが送れる。
　　（恐らく、課の営業成績には社員の営業成績を合計する手続が書いてあるだろう）
２．課と社員の間に「チーム」という新しい組織を作る場合も
　　ただ単に「チーム」サブクラスを増やすだけでいい。

オブジェクト構造（例）
<部>1-n<課>1-n<社員>　のような木構造。
構造がそのまま組織構造を表しているので理解がしやすい。

プログラム上でクラス構造は静的側面、オブジェクト構造は動的側面を表す。
その構造決定要因は、クラス構造の場合継承関係、オブジェクト構造の場合リンク関係である。

>>684で述べているのはオブジェクト構造についてです。
で、オブジェクトの上下関係を無視して直リンした方がその場では楽だなぁと述べているのです。
なんつ〜か、ほら、Windowsでファイルを開く時いちいち階層を辿るより
ショートカット利用した方が楽でしょ?
でも、ショートカットってよくリンクが切れた状態になるでしょ？ってことです。

意味はないが、なんとなく。
class 営業成績{
　public 営業成績(){???}
　public void 加算(営業成績　成績){???}
}
interface 組織{
　組織　親組織取得();
　void 子組織登録(組織 子組織)throws 登録不可例外;
　Iterator 子組織リスト取得();
　営業成績　営業成績取得();
}
class 部 implements 組織{/*省略*/}
class 課 implements 組織{
　private 部　所属部;
private List 子組織リスト = new ArrayList();
　public 課(部　所属部){this.所属部=所属部;}
　public 組織 親組織取得(){return 所属部;}
　public void 子組織登録(組織　子組織)throws 登録不可例外{
　　if(!(子組織 instanceof 社員))throw new 登録不可例外();
　　子組織リスト.add(子組織);
　}
　public Iterator 子組織リスト取得(){return 子組織リスト.iterator();}
　public 営業成績　営業成績取得(){
　　営業成績　課_成績　=new 営業成績();
　　(Iterator　イテレータ=子組織リスト取得();イテレータ.hasNext();)
　　　課_成績.加算((組織)イテレータ.next()).営業成績取得());
　　return 課_成績;
　}
}
class 社員 implements 組織{
　private 課　所属課;
　private 営業成績　個人営業成績;
　public 社員(課　所属課,営業成績　個人営業成績){
　　this.所属課=所属課;
　　this.個人営業成績=個人営業成績;
　}
　public 組織 親組織取得(){return 所属課;}
　public void 子組織登録(組織　子組織)throws 登録不可例外{
　　throw new 登録不可例外();
　}
　public Iterator 子組織リスト取得(){return null;}
　public 営業成績　営業成績取得(){
　　return 個人営業成績;
　}
}

>>688
配列でも、LinkでもVectorでもHashTableでもいいんですけど、
そのクラスでどうやって １：１：１以外の構成にできるのか教えてもらえませんか？
>>689
なるほど。アクセス問題を解決する為の多重継承には私はまだ踏み切れません。
だって美しくないんだもん。

つーか単純に現実を模倣したクラス構造は止めれ。
システムのモデルを作成するのに必要な現実だけを切り取ってクラス構造を作れ。

クラス階層と、インスタンス同士の上下関係をごっちゃにしてるような印象があるが…

>>691
ｲﾀｲ

>>694
出し惜しみしてないで実装例を書きなよ。
大威張りで書いているんだから、よもやまさか汚いコードじゃないよね？

>>694
何の実装例？

>>658-668
のインターフェースで一つにまとめたクラスでどうやって
各層のインスタンスの数を変えるのかという問いに対する答えの実装例。

ひょっとして、オブジェクト指向スレでたまに見かける
「オブジェクト指向の極意は多重継承と多態」とか言ってる人って
こんな使い方の事を言ってたの？
はあ、そんなコード書いといてなにをえらそーに・・・。

http://pc.2ch.net/test/read.cgi/prog/1007347519/829-833n

>>690
これって、継承ｦﾀのコード？
H◎RBとか使っていて、
似たよーな問題を見た気がするのは漏れがDQNだから？

>>692 に一票

>>700
単なるコンポジットパターンの今の話題での実装例。
実装がシケてるのは、行数制限があるから。
…こんなクラス作っても、おいらだって使わない。

＞ class 社員 implements 組織

つーのを見て、ﾁｮﾄﾆﾝﾏﾘしただけでした。

> 「オブジェクト指向の極意は多重継承と
騙されてますね。

>>690 せめて、
組織階層interfaceと、
成績提出可能interfaceを分けては
いかがでしょーか。

ああ、690の事を言ったんじゃないよ
ずっと上の方の会社クラスと部クラスと課クラスと社員クラスを
一つのクラスにまとめるやり方のこと。
漏れの知識で想像すると酷いコードくさいけど、実はものすごく
レベルの高いコードかも知れないし、見てみないと判らん。

>>705 すいませんでした。

ところで、Accountability Pattern て便利そうですね。
というか、パターン名と実装と潜在的な可能性が、
今日まで結びついていませんでした。デザパタで久々のカンドー!!!

ttp://www.ogis-ri.co.jp/otc/hiroba/specials/MartinFowler/analysis.html#analysis2_2

× 潜在的な可能性
○ 真価

>>695
俺は668じゃないよ？

>>700
C++ 方面の方ですか？ implements は実装(インターフェイス継承)だから、
実装継承と違って害は少ないと思うんだけど。
あと、やっぱりポリモーフィズム━━━(･∀･)━━━ﾏﾝｾｰ!!だと
思うのですがどうでしょう？

僕の稚拙な例え話に>>690のような渾身のレスがついたことに感動!!
しかし、漢字だらけだと得体の知れない迫力があるな。

あと、クラス構造やオブジェクト構造の構築をどうするかという例を
ボトムアップ開発＆リファクタリング＆デザパタで
書いてみたかったのだが、途中まで書いて挫折。
長すぎ。
（ttp://objectclub.esm.co.jp/evolutionalDesignWithPatterns/index.html
　こんな感じに書きたかったなぁ。
　しかも、話の流れに関係ないし）

書籍スレで書いたんですが、スレ違いの指摘を受けたので、こっちに
書いてみます。

オブジェクト指向本で気になるのは、発展の仕方が妙に自然科学的な
積み重ねじゃなくて、先人の否定で新規性を出そうという本が多いこ
とじゃないかと思います。
良書「憂鬱な…」もこの欠点があると思うんだけど、妙に「世の中の
の常識はこんなにまちがってた！」みたいなセンセーショナリズムに
走っている気がする。逆説をいうことが目的みたいなね。
正統派（あるなら）のアカデミックな場ではそうじゃないのかもしれ
ませんが。
ある種文芸批評とかみたいに、正しさの積み重ねじゃなくて、人とい
かに違ったことを言うか、という争いになっている気がします。

オブジェクト指向そのものの功罪じゃなくて、それを広めようとする
人に対するいかがわしさ、というのがあるんじゃないかなあと･･･。
どう思います？

>>710
そういう雰囲気はあるかも知れないですね。
「ふっ、いまだに時代遅れの構造化手法などに固執している馬鹿めがっ！」
的な雰囲気を醸し出しているエヴァンジェリストさんは多いですし。

私も古いやり方に固執している人を見ると、正直↑の様な気持ちが
湧いてくることもあります。
でも、オブジェクト指向って、それ以前のやり方とまったく違う方法でしょうか？
オブジェクト指向派の人だって、元々は C や Pascal をやっていた
人がほとんどだと思うんですよ、でもオブジェクト指向に出会って
「あー素晴らしいかも!!」
って思って鞍替えしているんだと思うので、本当はオブジェクト指向は
ちゃんと構造化手法を踏まえていると思います。
で、あまりにも感動しすぎて、まだ知らない人に
「いいものがあるんだよー」って教えてあげようとしてしまう。
でも、さしあたって必要性を感じてなかった人は
「あーOO信者ウザいナリよ」
となる、でもオブジェクト指向に染まる人が増えてくると、
あっちこっちから同じような人がでてきて
「またか！拙者には必要なりナリ！」→「またナリか！OO信者死ねナリ!!」
となっていくんじゃないかなーと。

つまり、本当にOO普及させたければ、押し売りじゃなくて、
「教えてあげないよ、ジャン♪(C)ポリンキー」
な態度に出れば、
「拙者だけオブジェクト指向しらないナリ！
なんかみんなで楽しそうにしてるナリ!!
拙者にもオブジェクト指向教えるナリよ〜〜！」
となって、末端まで普及していくかも知れないなぁ。なんて思ってしまいました。

ん〜、乱筆乱文ﾃﾞﾑﾊﾟな文章で失礼しました。

> オブジェクト指向に出会って
構造化を進めて行けば、OOは必然じゃないか？

最初にプログラム教えてくれたセンセイがCとかPascalとか
教えてくれたならともかく、今は最初からJavaやC++やるのが
全然珍しくない以上、「構造化手法 VS オブジェクト指向」
とかいまだにやってるのはある(最初にプログラミングを覚えた
時期が同じ)世代に限定されるんじゃないの。
勿論、オブジェクト指向の構造を設計するのと、
オブジェクト指向のフレームワークを使うのは全く別
(後者は、コンポーネント指向か)だけどね。で、後者のような
ことしか必要のない場所では、別にオブジェクト指向なんか
理解している必要もない。

>>711
オブジェクト指向教は他の宗教を認めないというドグマの上に成り立ってるので
無理です。

オブジェクト指向って、構造化のキレイなやつの1パターンと言う程度
じゃないのか？構造化でやってきて、オブジェクト指向分からないって
言ってる奴は、単に構造化設計もちゃんと分かってないクズだと思うよ。

オブジェクト指向でいっているクラスみたいな概念って、Cでもやってた
でしょ？構造体の内部隠蔽とか、構造体へアクセス可能な関数を限定したり、
ファイル分割利用してスコープ限定したり。継承＆多態みたいなことは
関数ポインタを利用した関数実装のディスパッチでやってたし。

それが言語仕様でなくて、Cを使っているユーザの「そういう構造を作ろう」
と言う意思がやっていたことを言語の仕様としてしまうことで、もうちょっと
楽をしようというのが、OOP言語のルーツのような気がするんだが。

OOって小回りがきかないのが欠点だと思うけどどうでしょ。

OOAしてOOPするのはいいけど、現実としてゼロからモノを作る場面って
多くないとおもうんですよ。
あたらしい手法はとりあえず、既存の手法のなかにいかに馴染ませて効果を
発揮させるかってのも大事だと思うですよ。
その点ではOOはやりにくい気がする。

>>715
＞オブジェクト指向分からないって
ＯＯ信者が勝手にレッテル張りしてるだけです。
むしろＯＯ信者に「クラスで書けたから、漏れはＯＯ理解してるよーん」
みたいのが居て叩きに来るのです。

>>714
たしかに信者は他の手法を認めないが、信者以外は構造化でも汎用プログラミング
でも仲良くやってると思われ。

（だから C++ 好きさ）

関数型プログラミングは、バカには「まったくわからない」から
「実用的なの？」みたいなツッコミしか受けないね。
OOPは、バカでも「感覚的にはわかる」から、本質を理解しない
実践をされて、「だからOOPはダメ」な実例を作られる。

# かくして本物のプログラマはFORTRANとアセンブラを使う、と;-)

>>710
例えば 青木淳さんのおっしゃる「主観的オブジェクト設計」と
他の客観的な指標に従って設計を進めようとする「客観的オブジェクト設計」
の違いなど、その例かもしれませんね。
http://www.sra.co.jp/people/aoki/Buddhism/Misc/BuddhistApproachToOO.html

私は、オブジェクト指向に深入りせずに、
関数型プログラミングと同じ視点で関わりたい。

>>719
その論理なら最後の１行は違うな。
>かくして本物のプログラマはFORTRANとアセンブラを使う
↓
よって、バカにはFORTRANとアセンブラで十分。

>>http://www.geocities.co.jp/Milkyway-Orion/3324/prog/realprog.html
本物のプログラマはFORTRANを使うってのはこの文書のこと。

なるへそ、引用ね。こりゃ失礼。

３月２４日〜２７日に立命館大学ＢＫＣに田中洸人氏が来ます。
http://210.172.69.179/jps_search_02au
http://nara.cool.ne.jp/mituto

>>724
プログラムの検索で空振りすると、
"フォーマットファイル「hyouji.html」が見つかりません"
てのちょーｶｺﾜﾙｲ。「田中洸人」で検索したんだが。

今日はわけあって、各種オブジェクト指向方法論の調査中(藁

オージスの「オブジェクトの広場」へ行ったら、
James Coplien「マルチパラダイム・デザイン」の翻訳者 金沢典子さんによる
読解ガイドを発見。
AOPやSeparation of Concerns(関心の分離)と比較して、
より一般的なソリューションを与えるドメイン分析手法との事ですが、
お前らはどのように感じているでしょうか？

http://www.ogis-ri.co.jp/otc/hiroba/technical/MPD/index.html
http://www.rcnchicago.com/%7Ejcoplien/Nippon/MPD/

原著は1998年に出ていて、翻訳を2002年に読んでいる、という時点で終わっている(藁
まじで洋書情報仕入れていかないと、何年たっても追いつけなさそう...

>>726
クラスの手法はやっぱ破綻してますね。

沿う鴨試練。

>>726
日本で、最近の猫も杓子もデザイン、テストという形で設計手法が
一般人の関心に上るようになったのが遅すぎた感もあるな。
「オブジェクト指向が〜」とかいう前置きすら無しに、OOがプログラ
ミングのイロハとして皆の共通認識となるべきなんだけど。
そうなってくると、いまだにOOについて有用性を論じているこのスレ
のような場所って何? ってことになる。
OOが基礎にあることは確かだが、マルチパラダイムデザインの場合
「各種オブジェクト指向方法論」と括るのすら無理があるね。

つーか本に書いてあることはあくまでモデルである、ということを
理解しないで真面目にやる馬鹿が多すぎるのではないか。

そうですね。
オブジェクト指向という囲い込みが疎ましく思えます。
普通にプログラムして、
・オブジェクト指向になったり、
・オブジェクト指向を使わなかったり、
・オブジェクト指向を拡張したり、
つう感じで、自由に行き来したいよぅー。

なーんでここに田中洸人（コウジンと打ってみつとと読むのか）
いるんだ！物理板から進出したのか！
ここはブラックホールじゃないのにな！
つーかなんでみつとって読める俺ってどうしてですか

マルチポストは潔く無視、が一番かと存じます。

>>729
>つーか本に書いてあることはあくまでモデルである、ということを
>理解しないで真面目にやる馬鹿が多すぎるのではないか。

僕？(藁

＞フローズンスポットと変化するホットスポットを切り分けることが
＞フレームワーク作成の重要点であることを指摘し，
＞さらにホットスポットの実装のためのメタパターンを提唱しました

やっぱメタ。で関数ポインタ。

っていうか目的指向だろ！

だって、そーゆーときは本買わなくても自然に使わざる得なくなったり、
使ったりするからな。

自分のスタイルやその説明を数年間追いかけたら、
型理論とか型推論とかSeparation of Concerns とかドメイン分析
でした。

＃モナドとか思い付く素養は無かったりする(藁

>>727 クラスの手法はやっぱ破綻してますね。

プロトタイピング・ベースのＯＯ言語か、
あるいはアナリシス・パターンでも出せば、
同意できるのだろーか？

＃アナパタすらリアルタイムで読んでいない＞＞俺

あるいは、こういう説明ならどうでしょう？
多重分類と動的分類
http://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/index.html

OO が役に立つかどうかなんていう高度な話題は提供できませんが
俺にも一つだけ言えることがありますな。

少なくとも OO には気休め効果というか、なんだっけ？
そう、スパシーバ効果だ。スパシーバ効果があります。

みんなで OO でスパシーバ！みたいな。

スパスィ〜ヴァ！！
スパスィ〜ヴァ！！
なんだっけ、ありがとうって意味？ロシア語？

ハラショー!!

皆さんスパシーバ効果は体験してもらってるだろうな？
ところで今日も言いたい事があります。みたいな。

CHain Of RespOnsibility の愛称は Choro ... チョロです。
チョロに決まりました。みたいな。

フィリピン人に会社の金使い込んで首吊り。みたいな。
そんな殺伐とした都会の具体的ジャングルを感じるパターン名ですな。

これからもチョロでスパシーバ！みたいな。

某研究所某主任研究員の証言：
「オブジェクト指向は間違っていた」(ﾀｲﾄﾙ大藁
　　http://www.ogis-ri.co.jp/otc/hiroba/technical/MixJuice/index.html

>>743
これってどうなんでしょう。interface の多用と、Strategy パターンを使えば解決する問題な気がする。
あと final なモジュールっていう機能を作らないと、
何でもアリ(例えば Singleton のインスタンスが複数作れたりする状況)
になっちゃうような...。
まだまだ修行が足りないからかなぁ？

いま、OOを勉強しているのだが、もしダメなのなら、何をやればいいんだ？

>>745
だめっていうことはないよ。
そこいらの手続き型設計しかできないおっさん/おばさん連中よりはるかにマシ。

>>744 求める機能を複数のクラスに分割実装して、
Compositeするみたいなやり方を、
不便さを感じながら使っている人も多いだろうね。


　

んで、クラスライブラリやフレームワークの
機能拡張やカスタマイズには、
複数クラスを系統的に修正/拡張する必要があって鬱。

>>747-748
機能拡張やカスタマイズの必要がある「部分」を特定して、
置き換え可能なように、TemplateMethodやStrategyにする。
置き換えが広範囲ならInterfaceにして、実装クラスの置き換えをする。

変更するだろう「部分」を事前に特定するのは難しい。

拡張/カスタマイズする度に、クラス設計を変えるのは面倒過ぎる。

>>744
＞これってどうなんでしょう。interface の多用と、Strategy パターンを使えば解決する問題な気がする。

「Cでもオブジェクト指向プログラミングをできる」ように、
「オブジェクト指向でも」可能でしょうね。
クラス構成が複雑で分かりにくくなるかとは思うけれど...

MixJuiceによる12のデザインパターン、通称 MJ12。
韮山編集長イチオシです。

それなんでしょうか？

>>752 はUFOオカルトネタ。

>>750
設計を後で変更するのが大変なのはオブジェクト指向に関係なく真。

そうじゃないよ。クラスの変更は簡単。
関数だと引数追加の度に呼び出し元と共に一斉に直さないといけない。
クラスだとプロパティみたいにしとくと該当個所のみ直せば良い。

>>756
関数でも構造体を引数にすれば変更は一箇所だけ。
そんなものは別にクラスの利点ではない。

データ抽象化の利点だろう

分割して統治しなよ
そうすれば反乱がおきにくい。

結論：　OOは馬鹿につける薬ではなかった。

＝＝＝＝＝＝＝＝＝＝＝　終　了　＝＝＝＝＝＝＝＝＝＝＝＝

馬鹿には劇薬となります。

>>759
そうだな、基本的に分割統治の発想で説明できる。
クラス、名前空間、UnitTest、
RUP のイテレーション、XP のストーリー/タスク

ooっていくつかあるプログラム方法論のワンオブゼムだろ
適材適所でつかえばいいんだろーが

オープン系が広まるのはこれからなんじゃないの。
早合点し過ぎ。

馬鹿は設計から任されたことがないから、
OOがなんなのか理解する機会に巡り合わせる
こともないんだろうな。

だからー。ＯＯ推進派は安く仕事受ければいいの！
効率良いなら単価下がっても量でこなせるはずだろ！

結論：ＯＯ推進派はの対実績所得を２割減らす。

>>756はゲッターとセッターだけでプログラム組んでるのか？

>>766
> だからー。ＯＯ推進派は安く仕事受ければいいの！
「だから」が何を受けてるのか謎だ。

>>758
データ抽象（カプセル化）と OO を区別できてない人は、よく見かける。
たしかに既存の OOPL の利点の一つは

　カプセル化を、細かいアクセス指定つきで実現できる

ことだけど、それは本質じゃない。

多くの場合、「本質」などの言葉を使う奴は
何も分かっていない。

>>769
確かに、アクセス指定については全く本質じゃないね。
アクセス指定については、それこそ言語によって仕様が違うし、
アクセス指定なんかない言語だってあるしね。
UMLの標準を決める際にも可視性の問題は結構もめてるみたい。

しかし、データ抽象（カプセル化）は本質的（基本的と言ったほうが良いか）だ。

>>769
＞データ抽象(カプセル化)
既にこの時点でもめると思われ

>>771
> しかし、データ抽象（カプセル化）は本質的（基本的と言ったほうが良いか）だ。
だから、それはオブジェクト指向ではなくて抽象データ型でしょう。

オブジェクト指向がなにもないところからいきなり生まれたと？

いきなり生まれたけど、そこにはまだ何も無い、と。

>>774
オブジェクト指向は、それまでの技術の積み重ねから出てきてる。ただ、そこに新たな
何かが加わったから

　オブジェクト指向

と銘打ってるのであって、単なるデータ抽象だけで OO とは言わん。

オブジェクト指向のテーゼは「インターフェースに対してプログラミングせよ」であって、
データの詳細を隠せじゃないでしょ。カプセル化よりは、むしろ仮想関数だと思うけど
な。

>>773
OOとデータ抽象を混同しているつもりは全くないのだが…
しかし、OOの基本の1つとしてカプセル化が含まれる事は間違いない。
いくつもある本質の1つとしてカプセル化を取り上げたのがまずかったのかな？
本質は1つであるべきだと？まあ、そうかもしれないね。

>>772
僕もデータ抽象＝カプセル化の時点で気になったのだが、
少し調べたら、まあ、同じ意味で使われることも多いようなので
そのままにしておいた。
言葉の定義で言えば、カプセル化と情報隠蔽も問題になってるね。
情報隠蔽がカプセル化に含まれるか否かってところで。

>>776
インターフェース…というより、メソッドネームを同じくする事は
確かにOOの中ではかなり重要な要素だ。
しかし、「型」という意味で言っているなら、
「インターフェース型」は単なる一技法である。

質問だけど、僕は「カプセル化」を「データと手続きを一体化すること」の意味で使っているけど
これは他の人にとっても一般的な定義なのかな？
カプセル化に情報隠蔽の意味を付け加えるかどうかは文脈で変える感じかな。

あと、OOで一番大切なのはメッセージパッシングだと僕は思う

オブジェクト指向って、なんか朗々と語る夢の詩のようだね…。

あなたの心の奥深く 隠された秘密を
僕は暴けない あなたの腕でしか その秘密を暴く事はできない。

どこにいるの？大切な君は
君が誰か知りたいと願っても その答えを僕は求めてはいけない
ぼくは君を君としか呼べないんだ。

僕と君の距離が壊れてしまわないように in the Human system.

thank you.

>>755
＞設計を後で変更するのが大変なのはオブジェクト指向に関係なく真。

真面目にクラス設計すると、デザパタみたいに、
１つの機能を複数のクラスで実現する形になる。

デザパタとか意識せず、いい加減にクラス設計をすると、
クラス数が少なくて済む事が多い。(個々のクラスは汚いけど)

後者の方が、カスタマイズやメンテナンスが
(見かけ上)楽だと思う人が居て、鬱。

前者のカスタマイズやメンテナンスを簡単にするには、
最低限どういう改良を加えればよいだろうか？

継承のし過ぎが有害なのと同様に、
クラス数が多過ぎるのも有害。

>>779
オブジェクト指向＝モデリング＋モジュール化機能
と考えてますが、ポエムですか？

＞継承のし過ぎが有害なのと同様に、
例：二世タレント、二世議員

＞クラス数が多過ぎるのも有害。
例：インドのカースト制。
　　士農工商で充分じゃｺﾞﾗｧ

>>781
> 継承のし過ぎが有害なのと同様に、
> クラス数が多過ぎるのも有害。
何が「同様」なのかはっきりさせないと、分の前半から後半は導き出せんぞ。

前者から後者を導出しようとはしてません:-)

前者(深いクラス階層)について、
・クラス拡張上の柔軟性が低くなる
・理解しにくい
というの反省があって、
・インターフェース継承とか
・オブジェクト・コンポジション
が重視されるようになったんとちゃいますか？

で、オブジェクト・コンポジションの考え方で
差分プログラミングすると、クラス数が増えるんで、
それはそれで理解しにくい/カスタマイズしにくいな、
って言いたかったんですが。

理解してもらえませんか？

それって数が多ければ把握しにくくなるというあたりまえの話かと。
いかに名前空間やデザパタで整理するかだな。

そのもーちょっと先の議論をしないと、スレ違いかと思う。

>>786 数が増えるだけでなく、密度が増えるのが問題(藁

>>785
何と比較して理解しにくいのかが良く分からん。

クラス継承、オブジェクト・コンポジション共、
「理解し難い」つーてるのは確かにデザパタを分からん奴。

「カスタマイズ/拡張しにくい」つーのはどうよ？

>>785
｢同様」という言葉の使い方については同意しかねるが、ｗ
785で言っていることの大半は同意する。
その質がどうであれ量が増えれば理解しがたくなるのは当然だね。
（デザパタは理解の助けになるとはいえ、あくまで作る側の指標。
　例えば、AdapterとBridgeは同型になるが、作る側には違うものだが、
　使う側からはどちらかを判断する事は難しいしする必要もない。
　理解の手助けにはメタパタの方が有用だといわれている。
　特にフレームワークでは作者がどこをホットスポットに想定してるかは大事な要素。）
話がそれたが、同意しかねる部分がある。
理解のしやすさとカスタマイズのしやすさを同列に扱ってる部分だ。
「理解すればカスタマイズしやすい」のと
「理解してもカスタマイズできない」のでは大違い。

>>790
> 「カスタマイズ/拡張しにくい」つーのはどうよ？
インターフェースは細かく分けてあった方が拡張しやすいと思うけど。

メタパタって、どれよ？ アナパタ第15章あたり？

・SchemeやRDBMSの動的データ構造に、
　アクセサ付けてOOっぽくする、とか、
・SmalltalkのReflection tower

みたいなのは昔からあって、
それに名前を付けてコモン・センスにするのはいーけど。

LispのCONSセルや、RDBMSのColumnsみたいに、
異様に小粒なクラス使って型システムを再構成しているんで、
最早オブジェクト指向っぽくない感じがする...

「マルチパラダイム・プログラミング」James O. Coplien
　　http://www.amazon.co.jp/exec/obidos/ASIN/4894712989/ref=sr_aps_d_1_1/250-1708863-4365039
てどうよ？

Compositeパターン、手続き型クラスとＯＯはもう死んでます。

オブジェクト指向における「生産性」とは
オウム真理教の空中浮遊術みたいなもの。

入信させる為にあたかも実在するかのように見せるが、
入信した後はどうでも良くなる。

いつまでたっても、この議論が消えないのは、
ＯＯを使いこなせていない症状が多いということでなかろうか。
物事の関係が掴めないからＯＯに結び付けられないか、
デザパタに頼りすぎて、過度の構造主義に嵌るか。
その中庸の道が上手く示されていけば、ＯＯの良さが説得力を持つ気がする。
（残念ながら、個人的に、そのレベルには達していないと思うが。）

物事の関係が掴めないからＯＯに結び付けられないタイプは救い様がないかもしれない。
どんなプログラムをやっても、上手いポイントがつけない気がする。
ＯＯ終わりというのは、何ゆえかはわからない。ネタか・・・

>>797
＞ＯＯを使いこなせていない症状が多いということでなかろうか。
であるから OO は技術として不適当であるといえるかもね。

OO は相対性理論なのか常温核融合なのか。
宇宙エネルギーではないと信じたい（ｗ

この板に登場する「俺はＯＯを使いこなしてる」って人
「クラスでプログラム書けた」という程度の人が多いんだよね。
本気でイコールだと思ってる人も少なくなかったし。

んでもって、使いこなしているという証拠・基準は
「どれだけ再利用性の高いオリジナルのクラスを作れるか」
だと思うんだけど、それを言うと「車輪の再発明」と言って叩いてくるしねー。

結局、理念はどうであれ、現実ではライブラリを暗記するのが得意で
ライブラリを並べるだけのコーダーがふんぞり返ってるという
亡国の状況に陥ってるワケ。

>>801
OO がやってくる前からずっとそうだね。
ソフトウェア危機だとかいって。

>>800
多少気の利いたクラス作るより、（例え標準化されたクラスの
「実装」が多少糞でも）コンセンサスがある程度得られている、
広く知れ渡った、多くの人に試験されていて枯れているクラス
使うほうが、長期的に見てコストかからないと思うよ。
最低でもそういうクラスとインターフェイスくらいあわせと
いたほうがいいかと。

そのライブラリを自前で保守するコストを負担してまで作るほど
のものなのかを判断しないで、すぐ作りたがるアホが多いよね。
自己顕示欲過剰の技術バカ。個人の趣味なら求道精神も構わんが、
会社で他人の金で食って作ってるのに、コスト意識ない奴はいい
加減にして欲しい。

ウチは、開発リスクも保守コストも、個人の力量任せ (個人でリスク負担)
ですが、何か？

>>793
メタパタっていうのはPreeの「デザインパターンプログラミング」で
述べられているメタパターンのことです。
コモンワードだと思って使ったけど他にも使われ方があるのかな？
まあ、ありそうだな。ありきたりな言葉だし。

あと、LispはSmalltalkに影響を与えた3つの言語(Lisp,Logo,Simula)の1つだし
Schemeに至っては、改良前のPlasmaがSmalltalkとSimulaに影響を受けてるし…
Lisp/SchemeとSmalltalkは類似点が結構ある感じだね。
（特に、PlasmaでのCarl Hewittのアクタ理論なんて、かなりOOっぽい）
Lispの「複雑な処理も簡単な原子的処理で構成される」って考え方はOOでも有用だが、
おっしゃる通り最早OOのクラスと言えないほど粒度が小さいね。

個人ライブラリはコストが低い。

>>805 THANX! 翻訳が出てすぐGETしたけど、
DOA & Reflectionのかほりがしたので
「逝ってよし」とばかりに会社の書棚に放置してました(藁

アナパタ以前の問題ですね。目を通しておきますです...

ＯＯの本読む前に童話「裸の王様」をよみませう。

What do you mean about ?

あ、外人さんだ！

どんな本を本でも、設計のOOと実装のOOの隔たりは
埋まらない気がしてならなら。これって俺だけ？

ＯＯ一派が行った焚書坑儒。
恨みは忘れない。

設計のOOはいいんだけど、
それがどうしてOOPLと結びつかなきゃならないわけ？
別にHaskellやMLだっていいじゃんよ。

例　　　　で
え　　　　
ば　　　　　　　　
、　　　　
ど　　　　？
んなへだたり

しょうか？

クラスの数が多すぎるー。これこれのオブジェクトのクラスはどれだっけ？
メソッドは何だっけ？クラスとメソッドを管理するDB作れ〜。
とかなっちゃったりしますか？厨質ゴメソ。

>>816
Win32API の DB はほしいね

>>817
で、それはOOのせいじゃあないよね。
結局は設計がクソかどうか。

>>807
察するによく本を読んでおられるみたいなので、
アドバイスするのは恐縮なんですけど、
だいたい、パターン系で言えば
ttp://www.ogis-ri.co.jp/otc/hiroba/OoBook/BookRanking/patternBook/index.html
辺りの本を読んでいれば、基本的なテクニカルタームは押さえることができると思います。
（とは言っても、僕も全部読んでるわけではないんだけど…ｗ。
　今はDesign Patterns Smalltalk Companionを読みたい。）

>>803
汎用的なフレームワークとしてのクラスライブラリと、問題領域固有のクラスは別物
でしょう。

C 言語でエディタを書く場合に、

　多少気の利いた関数を自分で書くぐらいなら、標準ライブラリ関数を使ったほうが
　良いと思うよ

というのと同じぐらい、話がずれてると思う。（標準ライブラリ関数では間に合わない
から自分で書いてるわけで）

>>799
カプセル化だけ使ったクラスだったら、それこそ ADT と何ら変わらんわな。

ADTてなに？

Abstract Data Type＝抽象データ型ですな。

オブジェクト指向の必須要素を挙げるとしたら、何だろう。

>>819 ありがとうございますです。精進させて頂きます。

オブジェクト指向の必須要素ねぇ…。

Abstract と Concrete を分けて考えて、分けて実装する事。かな。

抽象データ型も多態もこれで説明できるし。

つい最近の事だが「Java言語で学ぶデザインパターン入門」を読んだ。
Java の基本的な事から細かく説明してあってすいすい読める。
しかも結城氏は説明の合間合間に「分割して統治せよ！」等、道しるべまで書き記してくれた。
そんな結城氏の言葉も構造化親父は頑固一徹で聞く耳を持たなかった。
本を読み終わり何気なく後ろを見て驚いた。
大量のゴミプログラマーとゴミＳＥがいたのだ。
結城氏が彼/彼女らの存在に気が付いて必死に「とっとと OO くらい理解してくれ！」と頼んでいいたのだった。
これ以降、結城先生が大好きになったよ、おれ。

>>826?ﾊﾃﾅ?

>>827
http://ton.2ch.net/test/read.cgi/gline/1012264677/

Thanx!

>>825
GoF の言うところの

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

ってやつね。あとは、オブジェクト同士の関係を深く考えることだと思うよ。ADT だと
ADT を抽出して終わりになるところが、

　実は、A は B なんじゃないの (A is-a B)
　X は A, B, C を要素に持ってるのね

とか言い出すと OO っぽい気がする。

>>796
ちょとだけウケたよ。

この線でいくと、
「オブジェクト指向の××とかけて、〜ととく、その心は？」
というのはいろいろありそうだね。

このスレでもアンチOOは論破されてるのか…

パート２で
オブジェクト指向についていろいろ話しましょう
どーせ、アンチOOは一瞬で消えますから

アンチOOって、燃料にもなりゃしねんだよな。
Case by caseって言葉もわかってねぇ。

あが

再利用age

>>825
COMマンセーってことでよろしいか？

>>830
>>825のいっていることと、インターフェースに対してプログラミングせよ、とは
同じなのか？まあいいや。インタフェースが重要であり、中身は気にしなくても
良いようにするというのはカプセル化（隠蔽じゃないよ）でも説明できると
思う。

すぐ実装継承したがる継承猿は逝ってよし、と。

>>834
ワケの判らん単語並べて勝ったと思うなよ！

>>833
そう言う事はすでにある「オブジェクト指向スレ」でやれ。
誰もレスつけないで放置されているがな。