>>664
>ＯＯを使っても、あまりに具体的で抽象化の必要がない
>（利益がない）データはもちろんあるよね。Javaだと

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

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

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

ファサードの奥には触るな、という事なら、やっぱOOは好きには
なれん。
大規模アプリ用の考えのはずなのに、大規模になりすぎると
いまいちに思える。Cもいまいちだが、他にいい物を知らん。