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

>>785
｢同様」という言葉の使い方については同意しかねるが、ｗ
785で言っていることの大半は同意する。
その質がどうであれ量が増えれば理解しがたくなるのは当然だね。
（デザパタは理解の助けになるとはいえ、あくまで作る側の指標。
　例えば、AdapterとBridgeは同型になるが、作る側には違うものだが、
　使う側からはどちらかを判断する事は難しいしする必要もない。
　理解の手助けにはメタパタの方が有用だといわれている。
　特にフレームワークでは作者がどこをホットスポットに想定してるかは大事な要素。）
話がそれたが、同意しかねる部分がある。
理解のしやすさとカスタマイズのしやすさを同列に扱ってる部分だ。
「理解すればカスタマイズしやすい」のと
「理解してもカスタマイズできない」のでは大違い。

792 ：デフォルトの名無しさん：02/01/31 05:32

>>790
> 「カスタマイズ/拡張しにくい」つーのはどうよ？
インターフェースは細かく分けてあった方が拡張しやすいと思うけど。

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

メタパタって、どれよ？アナパタ第15章あたり？

・SchemeやRDBMSの動的データ構造に、
　アクセサ付けてOOっぽくする、とか、
・SmalltalkのReflection tower

みたいなのは昔からあって、
それに名前を付けてコモン・センスにするのはいーけど。

LispのCONSセルや、RDBMSのColumnsみたいに、
異様に小粒なクラス使って型システムを再構成しているんで、
最早オブジェクト指向っぽくない感じがする...

794 ：ﾄﾞﾒｲﾝ愛好家：02/01/31 22:27

「マルチパラダイム・プログラミング」James O. Coplien
　　http://www.amazon.co.jp/exec/obidos/ASIN/4894712989/ref=sr_aps_d_1_1/250-1708863-4365039
てどうよ？

795 ：　：02/02/01 00:43

Compositeパターン、手続き型クラスとＯＯはもう死んでます。

796 ：　：02/02/01 00:49

オブジェクト指向における「生産性」とは
オウム真理教の空中浮遊術みたいなもの。

入信させる為にあたかも実在するかのように見せるが、
入信した後はどうでも良くなる。

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

いつまでたっても、この議論が消えないのは、
ＯＯを使いこなせていない症状が多いということでなかろうか。
物事の関係が掴めないからＯＯに結び付けられないか、
デザパタに頼りすぎて、過度の構造主義に嵌るか。
その中庸の道が上手く示されていけば、ＯＯの良さが説得力を持つ気がする。
（残念ながら、個人的に、そのレベルには達していないと思うが。）

物事の関係が掴めないからＯＯに結び付けられないタイプは救い様がないかもしれない。
どんなプログラムをやっても、上手いポイントがつけない気がする。
ＯＯ終わりというのは、何ゆえかはわからない。ネタか・・・

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

>>797
＞ＯＯを使いこなせていない症状が多いということでなかろうか。
であるから OO は技術として不適当であるといえるかもね。

OO は相対性理論なのか常温核融合なのか。
宇宙エネルギーではないと信じたい（ｗ

799 ：　：02/02/01 01:06

この板に登場する「俺はＯＯを使いこなしてる」って人
「クラスでプログラム書けた」という程度の人が多いんだよね。
本気でイコールだと思ってる人も少なくなかったし。

800 ：　：02/02/01 01:09

んでもって、使いこなしているという証拠・基準は
「どれだけ再利用性の高いオリジナルのクラスを作れるか」
だと思うんだけど、それを言うと「車輪の再発明」と言って叩いてくるしねー。

801 ：　：02/02/01 01:10

結局、理念はどうであれ、現実ではライブラリを暗記するのが得意で
ライブラリを並べるだけのコーダーがふんぞり返ってるという
亡国の状況に陥ってるワケ。

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

>>801
OO がやってくる前からずっとそうだね。
ソフトウェア危機だとかいって。

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

>>800
多少気の利いたクラス作るより、（例え標準化されたクラスの
「実装」が多少糞でも）コンセンサスがある程度得られている、
広く知れ渡った、多くの人に試験されていて枯れているクラス
使うほうが、長期的に見てコストかからないと思うよ。
最低でもそういうクラスとインターフェイスくらいあわせと
いたほうがいいかと。

そのライブラリを自前で保守するコストを負担してまで作るほど
のものなのかを判断しないで、すぐ作りたがるアホが多いよね。
自己顕示欲過剰の技術バカ。個人の趣味なら求道精神も構わんが、
会社で他人の金で食って作ってるのに、コスト意識ない奴はいい
加減にして欲しい。

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

ウチは、開発リスクも保守コストも、個人の力量任せ (個人でリスク負担)
ですが、何か？

805 ：791：02/02/01 01:48

>>793
メタパタっていうのはPreeの「デザインパターンプログラミング」で
述べられているメタパターンのことです。
コモンワードだと思って使ったけど他にも使われ方があるのかな？
まあ、ありそうだな。ありきたりな言葉だし。

あと、LispはSmalltalkに影響を与えた3つの言語(Lisp,Logo,Simula)の1つだし
Schemeに至っては、改良前のPlasmaがSmalltalkとSimulaに影響を受けてるし…
Lisp/SchemeとSmalltalkは類似点が結構ある感じだね。
（特に、PlasmaでのCarl Hewittのアクタ理論なんて、かなりOOっぽい）
Lispの「複雑な処理も簡単な原子的処理で構成される」って考え方はOOでも有用だが、
おっしゃる通り最早OOのクラスと言えないほど粒度が小さいね。

806 ：　：02/02/01 02:46

個人ライブラリはコストが低い。

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

>>805 THANX! 翻訳が出てすぐGETしたけど、
DOA & Reflectionのかほりがしたので
「逝ってよし」とばかりに会社の書棚に放置してました(藁

アナパタ以前の問題ですね。目を通しておきますです...

808 ：　：02/02/01 03:28

ＯＯの本読む前に童話「裸の王様」をよみませう。

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

What do you mean about ?

810 ：　：02/02/01 03:33

あ、外人さんだ！

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

どんな本を本でも、設計のOOと実装のOOの隔たりは
埋まらない気がしてならなら。これって俺だけ？

812 ：　：02/02/01 03:42

ＯＯ一派が行った焚書坑儒。
恨みは忘れない。

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

設計のOOはいいんだけど、
それがどうしてOOPLと結びつかなきゃならないわけ？
別にHaskellやMLだっていいじゃんよ。

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

例　　　　で
え　　　　
ば　　　　　　　　
、　　　　
ど　　　　？
んなへだたり

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

しょうか？

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

クラスの数が多すぎるー。これこれのオブジェクトのクラスはどれだっけ？
メソッドは何だっけ？クラスとメソッドを管理するDB作れ～。
とかなっちゃったりしますか？厨質ゴメソ。

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

>>816
Win32API の DB はほしいね

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

>>817
で、それはOOのせいじゃあないよね。
結局は設計がクソかどうか。

819 ：791：02/02/01 06:08

>>807
察するによく本を読んでおられるみたいなので、
アドバイスするのは恐縮なんですけど、
だいたい、パターン系で言えば
ttp://www.ogis-ri.co.jp/otc/hiroba/OoBook/BookRanking/patternBook/index.html
辺りの本を読んでいれば、基本的なテクニカルタームは押さえることができると思います。
（とは言っても、僕も全部読んでるわけではないんだけど…ｗ。
　今はDesign Patterns Smalltalk Companionを読みたい。）

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

>>803
汎用的なフレームワークとしてのクラスライブラリと、問題領域固有のクラスは別物
でしょう。

C 言語でエディタを書く場合に、

　多少気の利いた関数を自分で書くぐらいなら、標準ライブラリ関数を使ったほうが
　良いと思うよ

というのと同じぐらい、話がずれてると思う。（標準ライブラリ関数では間に合わない
から自分で書いてるわけで）

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

>>799
カプセル化だけ使ったクラスだったら、それこそ ADT と何ら変わらんわな。

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

ADTてなに？

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

Abstract Data Type＝抽象データ型ですな。

オブジェクト指向の必須要素を挙げるとしたら、何だろう。

824 ：807：02/02/02 23:04

>>819 ありがとうございますです。精進させて頂きます。

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

オブジェクト指向の必須要素ねぇ…。

Abstract と Concrete を分けて考えて、分けて実装する事。かな。

抽象データ型も多態もこれで説明できるし。

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

つい最近の事だが「Java言語で学ぶデザインパターン入門」を読んだ。
Java の基本的な事から細かく説明してあってすいすい読める。
しかも結城氏は説明の合間合間に「分割して統治せよ！」等、道しるべまで書き記してくれた。
そんな結城氏の言葉も構造化親父は頑固一徹で聞く耳を持たなかった。
本を読み終わり何気なく後ろを見て驚いた。
大量のゴミプログラマーとゴミＳＥがいたのだ。
結城氏が彼/彼女らの存在に気が付いて必死に「とっとと OO くらい理解してくれ！」と頼んでいいたのだった。
これ以降、結城先生が大好きになったよ、おれ。

827 ：　：02/02/03 02:01

>>826?ﾊﾃﾅ?

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

>>827
http://ton.2ch.net/test/read.cgi/gline/1012264677/

829 ：827：02/02/03 12:28

Thanx!

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

>>825
GoF の言うところの

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

ってやつね。あとは、オブジェクト同士の関係を深く考えることだと思うよ。ADT だと
ADT を抽出して終わりになるところが、

　実は、A は B なんじゃないの (A is-a B)
　X は A, B, C を要素に持ってるのね

とか言い出すと OO っぽい気がする。

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

>>796
ちょとだけウケたよ。

この線でいくと、
「オブジェクト指向の××とかけて、～ととく、その心は？」
というのはいろいろありそうだね。

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

このスレでもアンチOOは論破されてるのか…

833 ：t&t ◆CudPDzYA ：02/02/10 00:25

パート２で
オブジェクト指向についていろいろ話しましょう
どーせ、アンチOOは一瞬で消えますから

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

アンチOOって、燃料にもなりゃしねんだよな。
Case by caseって言葉もわかってねぇ。

835 ：デフォルトの名無しさん：02/02/24 20:44

あが

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

再利用age