オブジェクト指向は戦場では必要なし�G

　オブジェクト指向はより自然なモデルに即したものではあるが、
クラスを理解する労力が大きく、目的まで達成するのに時間がかか
る。他人のソースを見るにも複雑でときほぐしにくい。ちゃんと
整備されたドキュメントがなければ粗大ゴミソース。またオブジェ
クト指向が○○に優れているとかいう話も、あくまでちゃんと設計
され、ちゃんと実装されたクラスがあるという前提での話。実際は
世の中にはそれほど有能なSEやPGなどいません。
　よってオブジェクト指向は戦場では使いものになりません。

前前前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1011997945/
前前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013266554/
前前前前前スレ http://pc.2ch.net/test/read.cgi/tech/1013875413/
前前前前スレ http://pc3.2ch.net/test/read.cgi/tech/1021468476/
前前前スレ http://pc3.2ch.net/test/read.cgi/tech/1027983898/
前前スレ http://pc3.2ch.net/test/read.cgi/tech/1029297075/
前スレ http://pc3.2ch.net/test/read.cgi/tech/1030029357/

　オブジェクト指向が誕生して30年以上の年月が経ちますが、
未だにオブジェクト指向は広く使われていません。それはオブジェクト
指向開発が理想を追っているだけの机上の空論に過ぎないからです。
　ある10年前のオブジェクト指向の本には、オブジェクト指向は
今後爆発的に普及してゆくだろうということが書かれていましたが、
結果は言うまでもなく無残なものです。おそらくきっとあと10年経っても状況
は大きく変わることは無いでしょう。相変わらず構造化言語は便利なのでこれ
からも半永久的にに使われてゆき、また開発効率が高い新しいツールや
開発方法が登場して複雑なオブジェクト指向は消えてゆくでしょう。
　オブジェクト指向よ、さようなら。

>>1
いい加減にしろ!

構造化でもデザパタみたいなことはできるしね。

>>3

OOは便利だが、
「OO厨は戦場では必要ない」に１票
あいつらはプログラムを知らない新人以上に邪魔

とりあえず, スレタイに機種依存文字使うなよ, と. そんな奴にOOがどうのこうのと言われたくない.

>>6
ﾌﾟ

>>6
>1はプログラマじゃないもん。

じゃ結論出すよ。

OOは最高。

*** the end ***

そんなに急いで結論を出す必要はない。

*** reopening ***

>>10
転送量の無駄。
お前みたいなｳﾞｧｰｶのお陰で閉鎖しかけた。
首吊れカス。

OOは便利だが
「OOは最高。」
などとRuby厨と変わらんことを言う奴も邪魔。
戦場どころか人として必要なし

>>11
転送量だって(藁

> 転送量の無駄。
オマエモナー

このスレッド凄い。。。さすがですね。。。
2チャンネルってこんなに低レベルだったのか

>>15
ここは低レベルなやつを隔離するための場所だからだよ。
おかげで他のスレはちょっとはマシになる.

>>15
> 2チャンネルってこんなに低レベルだったのか
ハイレベルだと思ってたのか？

Ａ君、必死だな。

OO厨にもアンチを納得させられる
ほどの奴がいないという罠。

よくわからないのあげ

public static void main(String [] hoge);

逝ってよしの>>1は、戦場で逝ってﾖｼ

ポリモーフィズムって結局呼び出し部分を一緒の名前に
してるだけじゃん。

しまったsage

>>23
つか、OOそのものって別に小難しいもんじゃないよ。
わかっちまえば楽だよ。

オブジェクト指向自体は糞だろ。
多重継承しようが、クラスフラッドかまそうが、
オブジェクト指向はオブジェクト指向だ。
だから、糞。
オブジェクト指向だけではあまりにも欠点が多すぎるので、
デザパタとやらを持ち出して来るんだろう？違うか？OO厨さんよ。

オブジェクト指向がどーたら言う奴は消防。

OOはデザパタつかっても他人に伝えることが難しいし、
そのためのドキュメントもそろえないとダメだし、
そんな体制で凌いでも無駄だと思う。

「そんな体制」てのが、ｻﾊﾟｰﾘ見えませんが、何指して言ってるの？

>>29
OO厨に具体的なことを突っ込まないように（ｗ

>>1 って結局、専門用語小耳に挟んで業界人気取る痛い厨じゃん

まだやってんの？

>>23
それがなんの役に立つのか見当がつかないなら、それはアンタの
脳みそに知識が足りないからです(ﾜﾗ

今日はサンドバッグ>>1さん、現れないのかな(ﾄﾞｷﾄﾞｷ

>>33
機能追加したときに変える場所が少なくてすむからですか？？
先に考えとけよ。

>>35
アホが自供しました（ﾜﾗ

>>36
おまえはｱﾎ

久しぶりに、真性厨房のなんのひねりもない情報量0ツッコミをみました。
頭が悪いんだから、ヘンにプライド持ってても不幸だよ。人格改造したほ
うが君の為ですよ（ﾜﾗ

まーだやっていたーのかー

スレの雰囲気がどんどん変わるなあ・・・張るか。

　　　　　　☆
　. ∧∧　　/　：。
　 (*ﾟーﾟ)　ρ　 ‥
σ(　　 )　　　　・` 。・ ； ’ 、∴ ﾟ ，・・` 。・ ： ’ ∵、‘｡‥ ﾟ ，・・` 。∴ ､’．
　 υυ　　　　　、’　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・ﾟ
　　　　　　　　　 ・　　　　　　オブジェクト指向厨って不思議！！　　　　 ‘．
　　　　　　　　　。：　　　　　作：ファンシー乙女　　　　　　　　　　　　　　　 ；
　　　 　 　 　 　 …　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　`。
　　　　　　　　　 ；　　ＯＯ厨って不思議！能も無いのにいばってばかり 。 ‘
　　　　　　　　　∵　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　‘．
　　　　　　　　　 ･ 　　その自信は何を拠り所にしてるのかしら？ 　 ,‘．
　　　　　　　　　`。　　　　　　　　　　　　　　　　　　　　　　　　　　　　 。
　　　　　　　　　‘． ＯＯ厨って不思議！説明せずにけなしてばかり。　‘．
　　　　　　　　　。：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ；
　　　　　　　　　…　　その妄言の発想はどこから来るのかしら？　　　 `。
　　　　　　　　　｀ ;　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾟ ・
　　　　　　　　　｀ ;　　再利用、フレームワークと壊れたラジオのようね　　 ：・
　　　　　　　　　 ’。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ‥
　　　　　　　　　 ‘・∴ 。’∵ 、 ; ｡…． ・ ” ，・` 。・ ； ’ 、∴

結局、安置OO厨が能無しだから、スレの雰囲気悪くなってるんでしょ(ﾆﾔﾆﾔ

>>41
（　´,_ゝ`） ﾌﾟｯ

川俣晶が言ってたことは漏れ的には同意できる。
struct aclass{
char* id_;
int value_;

char* id() { return id_; }
int value() { return value_; }
};
で下のような関数は要らないって奴。id_とvalue_を外からは代入せずに
読むだけと決めておけばaclass内部で実装変更があってから初めて
char* id(), int value()を書けばいい。修正個所はコンパイラが検出してくれる。

再利用しないコードでOOする理由は保守性ってことになるが
上のような例やデザパタにあるような複雑な仕組み
を入れたりすると調整や辻褄合わせでコードが巨大になってしまい
余計に保守性が下がる気がするのは漏れだけだろうか？

川俣晶ﾀﾝって誰？
んで、>>43が問題にしてるのは、
人間がアクセサ (get*(),set*(value)とか、上の例のid(),value())
書く事による保守性の低下？

AspectJの人は、
「アクセサ・メソッドをいちいち書かなけりゃならないのって、
　コンピュータやコンパイラーが低性能/低機能だった時代の名残」
って逝ってたっけ。

struct?

>>45
struct {...}＝class {public: ...}

>>46
言語は何？
少なくともCやC++じゃないし。

おっと、C++だ。
C++って構造体に関数を定義できるんだったな・・・

>>45 >>47
あまり使われないﾊﾞｯﾁｲ文法らしいことがﾜｶﾀﾖ

>>49
Cではよく使うんだけどね(^_^;)
classのあるC++で構造体使う人いるのかな？既存のものは別として、新しく自分で定義するってこと。

つーか・・・・
あんたら何にも知らずに議論してるんだな・・・

>>51
つーか・・・・
あんた何の目的も持たずに非難しているんだな・・・

いちおう補足。

俺がC++を勉強していた頃の知識によると：
・Cの構造体の概念は、C++ではクラスの概念に吸収された。
・structによるクラス定義では、デフォルトでメンバにpublic属性がつく。
・classによるクラス定義では、デフォルトでメンバにprivate属性がつく。

その後Javaに移行しちゃったので、新しい標準でどうにかなってても知らないYO

かなり昔からこの手の類のスレ有るけど、


オブジェクト指向『開発』『分析』『設計』はまだまだ未発達だが
「オブジェクト指向『言語』は成功している」


この事実を無視した発言が多すぎる気がするのだ
言語うんぬんの論争は無意味だ。

> 「オブジェクト指向『言語』は成功している」
成功って何？
普及していること？使いやすいこと？信者を洗脳しやすいこと？

＞54　
　わけわからん

>>54ではないが。

OOPLはいっぱいあるが、
設計に関していえば、デザパタを入れていいのかわからんけども、
やっと出てきたところでしょうが。
UMLだってようやく普及してきたのかなぁというぐらいのもんだろう？
あぁん？

>>55-56
むしろ、おまえらがわけわからん
とりあえずゲーデル嫁。

OO厨は知ってる単語しか並べない。暗記しかできないから
思考能力がないのでまともな議論ができません
よってOOのプロパガンダ行えるがOOを使うことはできない

OOを使うにはOO厨は必要なし

おまいらに聞きたいが､OOが糞だってならそれに代わるナイスな開発手法ってどんなのがある？
煽りでなく｡漏れは趣味でプログラム組んでるだけのヘタレなんでよく知らんのです｡

>>43
>再利用しないコードでOOする理由は保守性ってことになるが
>上のような例やデザパタにあるような複雑な仕組み
>を入れたりすると調整や辻褄合わせでコードが巨大になってしまい
>余計に保守性が下がる気がするのは漏れだけだろうか？

いや、漏れもそう思う。
で、XPの "シンプルデザイン" はその問題に対する答えの1つだと思う。

http://w3.dreams.ne.jp/~pb1871/xpractices.htm

の "Do the simplest thing that could possibly work" が参考になるかも。

つかprivateなデータフィールドを
アクセサで包めなんて誰が言ったよ？

>>60
趣味でプログラム組んでるだけのヘタレにはOOがお似合い
君にはOOで十分

>>62
マイクロソフトはそんなレベルの低いことはいいません。

＞privateなデータフィールドをアクセサで
無効なデータの設定を防ぐため、

くらいしか思いつかない。

OOはプログラマを信用してないから糞。
同様にC++以外の言語はプログラマを信用していないので糞。
よって俺糞。

＃あぁ、漏れの書き込みのせいでスレが荒れる・・・ｗ

まぁお前らOOPLを批判するヒマがあったら
もっとOO開発手法の批判をしたほうが有意義ですよ！
ってこった。

…漏れも開発には疎い厨房だがｗ

>66
>よって俺糞。
ﾜﾛﾀ

今時アクセサネタかよ
get/set抽象化したプロパティ知らんの？

つまりVB最高ということですね？

ヽ(`Д´)ﾉ

VB.NETは最高だよな。

論理的にいくぞ！

１）全ての企業は利益を出すことが第一目標である。
２）すなわち、企業においてはソフトウエア技術は財の生産効率をいかに高めるか
　　だけがその評価の指標となりうる。
３）オブジェクト指向は狭い意味でも、保守設計費用を含めた広い意味でも
　　その生産性に有意の差は認められない。
　　むしろ低下する場合が多く報告されている。
４）真の技術革新によって従来の成熟した技術から転換が起こるには
　　数倍〜１０倍程度の明瞭な生産性の差がみられるのが一般的である。
５）従来技術からオブジェクト指向への転換によって生ずる資源の破棄コスト
　　や導入コストを回収できるだけの生産性の向上など、どこからも報告されていない。
６）結論として、企業としてのオブジェクト指向への転換は全く持ってナンセンス
　　と言うのが、現在私の得ている情報から得た結論である。
　　

>>26

OOPとはオブジェクトを組み合わせてプログラムを組むこと。
デザパタはオブジェクトを組み合わせるという当たり前のことをしてるだけ。
それにデザパタはどれもわずか数個のオブジェクトの組み合わせ。

数個のオブジェクトの組み合わせの何が複雑なんだ？
数個のオブジェクトの組み合わせで何か特別なことができるって
本気で信じてるのか？

おいお〜い。せっかく気合入れて書いたのに放置かよ。

＞３）オブジェクト指向は狭い意味でも、保守設計費用を含めた広い意味でも
＞　　その生産性に有意の差は認められない。
具体的なソースきぼーん。
DQNが導入して駄目でした、みたいなアレなソースはのぞいてね（ｗ

＞５）従来技術からオブジェクト指向への転換によって生ずる資源の破棄コスト
＞　　や導入コストを回収できるだけの生産性の向上など、どこからも報告されていない。
大手ベンダは軒並みOOを導入していますが何か？

ホントはね、ぼくちんもオブジェクト指向への転換ってものをしたいのよ。
でも今のぼくちんにはあまりにも難しくてさ、それで悔しくて、つい...。

OOの唯一の欠点はイニシャルコスト(つまり厨房の調教コスト)が意外に高いということだ。
このコストを負担できない人間・組織は旧来の開発手法を選択せざるを得ない。

きちがいすれきょうもげんきだなー

その有り余る時間をわけてくれ

>>73
いったい何に対して言ってるのか見えてこない。
まさかOOPLがわからないのか！？

OOPLを習得することすらできないならPGやらない方がいいぞ.

ていうかアンチOOなﾔｼは
OOの何がいけないというのか明確じゃないよな。
「OOPLを理解できないオヤジ共」的な煽りは案外的を得ているのかも。

ＯＯ側には論客が居ないな。
吹きこまれた嘘情報を全く検証せず権威主義で受け入れてるだけの
自らものを考えられない様なのばっかしだ。

1) オブジェクト指向の究極の理想。
　　↓
2) 必要なコードはすべてクラスライブラリとしてそろっている。
　　↓
3) あとは選んで混ぜるだけ。
　　↓
4) アプリケーションツクールに改名。
　　↓
5) でも誰がその究極のクラスライブラリ作るの？
　　↓
6) 一から作るのはめんどくせー
　　↓
7) 楽できる便利な方法ないかなぁ？
　　↓
8) goto 1)

5), 6)にビジネスチャンスを見出せない奴は一生コーダやってろ

ーーーーーーーーーーそんなもの売りつけるなーーーーーーーーーーー

>>81
そう思いたい事という理由で全く検証せず
自分の脳内世界を世の中の標準だと思っているあなたは何なんですか？

ちょっとだけ訂正

OOPとはオブジェクトを組み合わせてプログラムを組むこと。
デザパタはオブジェクトを組み合わせるという当たり前のことをしてるだけ。
それにデザパタはどれもわずか数個のオブジェクトの組み合わせにすぎない。

数個のオブジェクトの組み合わせの何が複雑なんだ？
数個のオブジェクトの組み合わせが複雑だとアンチは本気で思ってるのか？

抽象思考が苦手な人は OO 向いてないね。
デザパタもしかり。

>>74
デザパタで複雑になると言ったのは失言。パターンで認識することに
よって複雑なコードでも「ああ、あのパターンか」と分類ができて
分かりやすくなるから保守面でも有用だね。

ただ、いいたいのはOOによって意味のないコードが増えてないか？ということ。
あるプログラマが書ける（把握・管理できる）コード量は決まってると言うけど
漏れ的には本質以外のコードが増えて、それを浪費したくないんだよね。

>>89
で、本質以外のコードって、具体的にどんなの？

プロトタイピングなＯＯだったら、実働一週間残業なしで、一万行位書きますが、何か？

とりあえず、CでOOやってみれば
C++の良さがわかると思う。

CでOOやってみて、C++の良さがわからないなら
OOがくそなのか、そいつがくそなのか。

C++のよさがわからないという事は
C++の機能が不要という事

アンチはC++の不要な機能を指摘してください。

机上の空論はつまらんよ。

そもそもOOってーのは、分析・設計部分が肝であって・・・
88は明らかに勘違いしてると思うんだが。

つーか、デザインパターンはOO特有のものでも何でもないことぐらい
GoFの読者には常識だと思うが。

> 業界談義、愚痴はプログラマ板へどうぞ。
ということなので、このスレはプログラマ板が
ふさわしいとおもうが。

>>95
自治厨ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━━!!!!!
それはともかく、議論の進み方は半分ネタのようでもあり、
マ板のほうがふさわしいと感じることもある。

>>86
> 数個のオブジェクトの組み合わせの何が複雑なんだ？
> 数個のオブジェクトの組み合わせが複雑だとアンチは本気で思ってるのか？
従来の言語でも数個の関数を組み合わせればカプセル化、多態など
OOPLと似たようなことがでますが、複雑で面倒なので私は使いません。

同様に数個のオブジェクトを組み合わせないと概念を表現できないOOPLは
そろそろ言語としての限界が見えてきたと思ってます。
限界がみえたからこそデザインパターンで誤魔化しているのでしょう。

>>96
おっと、 自治厨と呼ばれちゃったよ(自治厨って何だろう？)
というより、このスレってマ板の方が盛り上がるんじゃない？
あの板はネタスレ限定だし。

>>98

オブジェクト指向を使わない理由を考えるスレ
http://pc.2ch.net/test/read.cgi/prog/1030649831/


この状況を見て判らない？　盛り上がらないと思うよ。

>>97
>同様に数個のオブジェクトを組み合わせないと概念を表現できないOOPLは
>そろそろ言語としての限界が見えてきたと思ってます。

オブジェクト指向では、複数のオブジェクトを組み合わせて概念を表現する。
手続き指向では、複数の関数と複数のデータ構造の組み合わせで概念を表現する。

私にはどちらも同じに見えますが。

ﾔｯﾀ!!
100ｹﾞﾄ

そうか？　構造化的に仕事をする場合は、先にデータの流れを調べて
データ構造を作ってから手続きを構築してゆく。

つまり、複数を組み合わせてるように見えて、巨大な一つのクラスを
作ってるようなもの

それが尺にあう場合はそれが一番判り易く効率的だけどね

>>97がどんなプログラミングしてるのか見てみたい

＞そもそもOOってーのは、分析・設計部分が肝であって・・・

ウソを書くな

>>81
無視してよろしいか？
オブジェクト指向プログラミングが普及するに至った
理論的背景、歴史的背景両方とも筋が通ったものだ。
自分で調べてくれ。

>>104の発言はちょっと言い過ぎたかも・ｽﾏｿ
しかし分析・設計はまだまだぁゃιぃ部分が多いぞ。

>>100
> 私にはどちらも同じに見えますが。
その通りです。限界が見えたからこそ新しい手法が考えられたのです
ポストOOPLが出現し、OOPLは古い開発手法になるときも来るでしょう。

>>106
根本的に他のデザパタやらツールやらに頼らざるを得ないOO開発は欠陥。

スズメバチ駆除　ビ−バスタ−ズ
　http://ww41.tiki.ne.jp./~mikihiro9649/

色んなモノを組み合わせて目的を達成できるなら,それでもイイじゃん.

>>107
>根本的に他のデザパタやらツールやらに頼らざるを得ない
うーん、ちょっと違うんだよな。
デザパタを使うのは、その方が楽だから。ツールを使うのは、その方が便利だから。
無ければ無いで自分で作る。

>>102
>そうか？　構造化的に仕事をする場合は、先にデータの流れを調べて
>データ構造を作ってから手続きを構築してゆく。
>
>つまり、複数を組み合わせてるように見えて、巨大な一つのクラスを
>作ってるようなもの

複数の要素を組み合わせてシステムを作成するという意味ではオブジェクト指向も手続き指向も同じだよね、ということを言いたかっただけなので、細かいところは聞き流していただけると幸いです(^^;

オブジェクト指向の場合、オブジェクト以下とオブジェクトの扱いが違う点が違うように思うのだが？

>>106

>>111 の繰り返しになりますが、
複数の要素を組み合わせてシステムを作成するという意味ではオブジェクト指向も手続き指向も同じ。
つまり、パラダイムに依存しない問題ではないかと。

それがオブジェクト指向の限界となるとは考えづらいです。

GoFが 「継承」をデザインパターンに含めるかどうか悩んだ、という話をどこかで読んだ覚えがあるんだけど。
誰か、ｿｰｽｷﾎﾞﾝﾇ。

そんぐらい特別なものじゃない、ってこった＞デザインパターン

>>113
複数の要素を組み合わせてシステムを作成することが
パラダイムに依存しない問題だからこそ、限界があるのです。

手続き指向では継承や多態は可能ですが、作成者にかなりのスキルと時間を要求します
OOPLではその概念を直接表現できるため、OOPLを使った方が作成時間も速く、
バグの少ないプログラムを作ることができます。
これは手続き指向の限界と私は考えます。

もし、デザインパターンの概念を直接表現できる言語ができ、
その言語を使った方が作成時間も速く、バグの少ないプログラムを作ることができた場合、
これはOOPLの限界と私は考えます。

>> 115
デザインパターンって「手続き指向」やオブジェクト指向と並列に並ぶパラダ
イムか？

あと「直接表現できる」っていうのはそういうパラダイムが言語仕様に含まれ
ているってことだと思うけど、そういう言語がそうでない言語に比べて優れて
いるっていうのは漏れはかなり怪しいと思ってる。

デザインパターンってOOの機能に依存してると思うけど・・・

>>117
あほはCでもデザパタできますなんて抜けぬけというけどな。

デザインパターンがOOの機能に依存してないなんていってないけど

デザインパターンなんて線形リストとか２分木とかハッシュとかの
延長線上のものだろ。
まあ、ハッシュとか自分でコーディングできないバカもいるんだろうけど。

とりあえず、CでOOやってみれば
C++の良さがわかると思う。

CでOOやってみて、C++の良さがわからないなら
OOがくそなのか、そいつがくそなのか。

C++のよさがわからないという事は
C++の機能が不要という事

アンチはC++の不要な機能を指摘してください。

机上の空論はつまらんよ。

かきあげ

手続き型言語においては、ある属性の持ち主が明確でない場合が多い。
したがって特に急ぎ仕事の場合、場つなぎ的ご都合主義的コードが増加する。
結果保守が難しくなる。ってのはどうなの

構造化設計も出来ないくせに、なにがOOだ。
直感で設計する奴は死んでくれ。

だからＯＯなんじゃん・・・アンタ思いっきりマヌケ

まあOOをカダイヒョウカしてる奴が理解できなくてアンチOOになるわけよ。
わかってる奴にとっては別に特別な手法ではないし。
まあICONIXとかuse-caseの問題点に突っ込むならまだマシだが、あれって
「OOを理解」してないと無理だろうし

>>122
うーん、そういう属性はヘッダで晒さなければいいから。
インスタンスが複数ない場合は手続き型言語でやっても一緒でしょ。

実際の話、クラスが使えない言語なんか難しくて使えない。
goto文使うぐらい難しい。

そりゃ無理すりゃどの言語でも可能ではあるかもしれませんが非効率的です。
そもそもあなたの言ってる事自体ＯＯの考え方では？

オブジェクト指向データベースとか馬鹿だよなぁ。
全然話題にものぼらないね。（ｗ
オブジェクト指向をカダイヒョウカした馬鹿が、
データベースにも適用するぜ！と
意気込んだはいいものの、
たいした成果もあげられてないよね。（嘲笑禿藁

まあ自然な考え方だからな・・・終了？

あ、でも継承は糞だね。

俺はできるだけ使わないようにしてる。

>>129
インピーダンスミスマッチも知らないあなたの方が馬鹿

久しぶりみみたら・・・「手続き指向」とか得体の知れない言葉がでてるな。
あと、「手続き型言語」という言葉の用法がすごく変。
この流行、何があったの？

>>115
ごめんなさい。よくわからなくなりました。

よろしければ、なぜ「数個のオブジェクトを組み合わせないと概念を表現できない」ことがオブジェクト指向言語の限界なのかをお聞かせ願えませんか?

構造化は安価である。導入コストはなきに等しい。
OOの導入コストは以外に高く、罠も多い。

これが全て。

>>134
変かな＞手続き指向
ぐぐったら結構出てくるので、得体が知れない程ではないと思うんだけど。

>>136
×以外に高く
○意外に高く

昔のテーブルマナーで、ライス食べる時フォークの背にナイフで乗せて食うのが
あったでしょ？

論理的に考えれば、【西洋人はライス食わないし、フォークの背は変だ】
インチキ料理評論家が流行らせたんだとすぐわかっただろうにね。

オブジェクト指向もあと１０年もすれば「フォークの背」と同じだと
みんな気付くと思う。

【メンテも実装も短いコードほど効率が高い】
実に単純な理屈だ。
これが今納得できない人が居るとしたら、それは権威主義で目が曇っているからに
他ならない。

フォークの背は不便だけどオブジェクト指向は便利だよ。

俺はOO厨だが、OOに変わる概念がずっと現れないとは思わない。
たしかにOOをきちんと理解するのは難しいところもある。
だが、その新しい概念が構造化より優しいとは限らないと思う。
つまり、OOが理解できた人間にその新しい概念は理解できても、
構造化しか理解できなかった奴に理解できるとは限らない。
そういう奴はその時代の2ch的サイトで
「○○指向は戦場では必要なし」
とかとんちんかんなスレ立ててるんだと思うよ。

OOPLは今も緩やかにではあるけど進歩し続けてるよ。
モダンな言語はデザインパターンを無理なく
ライブラリとして記述できるような柔軟性を持った文法に仕上がってる感じがする。

ポリモフィズムはテスト用のスタブをつくるためにあるかのような
気がしてきてる俺はテスト熱中症？

構造化のころも KJ 法やジャクソン法があったわけだが。
構造化はそういった分析設計技法を含めずに語られて、
OO では含めて語られているような感じがする。

前スレからコピペ

> デザパタは数個のオブジェクトの組み合わせに過ぎない。
> デザパタが理解できないのは構造化で
> 数個の関数の組み合わせが理解できないって言ってるのと同じ(藁

「OOは優れた考え方である。したがってOOPLも優れている。」
これは正しいですか？

＞西洋人はライス食わないし

アメリカが何故米国と呼ばれてるか少しは考えよう。
今時海外旅行経験者なんてざらなんだし・・・
つーかおまえって何をやっても駄目なタイプ？

OOだって得意分野と不得意分野があるわけだ。OO不要とか言ってる奴
はおそらく数値演算屋とかと、めっさ小さいトイプログラムしか書か
ないやつ（或いは書けない無能者）のどっちかじゃないかと

たしかにちっこいくだらんプロジェクトなら非OOのほうが設計が簡素な分
早いかもしれんが、保守っつーかいろんな実験すること考えたら。。。
つーか数値演算屋だってOOつかってるっつーか、そもそも元祖のSimula自
体が。。。

とりあえずsageようぜ。

>147
MAJIRESですか?

>>147は米国産米穀の喰いすぎ

>>147
お前も少しは考えよう。休むに似たり、かも知らんが。

>>147
> アメリカが何故米国と呼ばれてるか少しは考えよう。
おまえは本当に考えたことがあるのかと小一時間(略
昔は漢字で「亜米利加」と表記されて、最初の文字の
「亜」じゃ混乱するので(亜細亜とかあるもんな)
2番目の文字の「米」を使って米国と表記してるだけなんだけど。

>>147
すばらしい漢字と歴史の知識だ！（藁
亜はアルゼンチンかどっかだろう。

>西洋人はライス食わないし
スペインのパエリアなんかは米料理だよね。
食わないわけじゃないよな。

147は馬鹿だけど。

>>147 えーっと、とりあえず…アフォ！

>>154
あと、「米利堅」ってのもあるな。
147はアフォだけど。

>>147のようながアフォOO厨は逝って由

>>147
> アメリカが何故米国と呼ばれてるか少しは考えよう。
知識が間違っていて、それを自信満々で広めるのは迷惑
OO厨はこんな奴ばっかなので駆除しているのに
やつらはゴキブリや蛆と同じでいつも湧いて出てくる。

>>160
たとえば 160 の様にってか？

147 は希代の釣り師だな。

>>135
「すべてに通用する一つのオブジェクト」があればいいのさ

>>163
アンチパターン "The Blob"の典型的な症状っすね。

http://www.antipatterns.com/briefing/sld024.htm

>>147
あのさあ、イギリス国旗に、でっかく『米』の字が描いてあるのを知らないのか?


当然、日本の国旗が日の丸弁当なのは知ってるよね。

>>165
パラオ共和国の国旗がタマゴ弁当だということは
知っていますが、何か？。

インドの国旗はカレー

オブジェクト指向は必要ではない。
なくても問題ない。
必要と思うなら使え。
思わないなら使う必要なし。
それだけだろ？

>>168
それだとスレが伸びないじゃん。

これをコピペすればアンチは反論できません。

デザインパターンなんて線形リストとか２分木とかハッシュとかの
延長線上のものだろ。
まあ、ハッシュとか自分でコーディングできないバカもいるんだろうけど。

とりあえず、CでOOやってみれば
C++の良さがわかると思う。

CでOOやってみて、C++の良さがわからないなら
OOがくそなのか、そいつがくそなのか。

C++のよさがわからないという事は
C++の機能が不要という事

アンチはC++の不要な機能を指摘してください。

机上の空論はつまらんよ。

>>170
安置が批判してるのはOOとかOOAとかOODとか
OO至上主義とかであって、
OOPL批判はしてねぇだろ。
つうかC++にしてCより悪くなることなんて何もないでしょ．

>>171
だから前スレから何度も言われてるだろ。
OOPLとOOA、OODが区別できない馬鹿は放っておけ。
その手の馬鹿にレスし始めるとスレが無限にループする。

OOA、OODができないと
OOPLが使いこなせない罠。
そういうﾔｼはきっと、C++の良さもわからないんじゃね？

おまえらvirtual使ってますか？

>おまえらvirtual使ってますか？
今すぐこのスレから出て行け！！

同意

>>132
カプセル化→非OOでも常識
継承→糞
となるとOO廚の心のよりどころは多態だけだね(w

>>170
漏れはC++のクラス機能が嫌いで使ってないんだけど(struct+関数でやってる）
カプセル化ではこっちの方が強力だよ。
例えばC++のクラスは宣言時にprivateな属性もそこに書かなければならないけど
その属性がstructなりclassなら、その定義までヘッダに晒さなくてはならない。

他にもクラスオブジェクト、インターフェース
動的継承や多重継承なども(継承嫌いだから使わないけど)好きに表現できる。
object->fun(1)をfun(object, 1)としなければならないのが難点だが。。。

C++の不要な機能、それはclass宣言文(w

OOPL批判ならＪＡＶＡは関数ポインタ無いから糞だし。

ふぅ。

C++最高と。

VC++マンセー と。

>>177
STLの味がわからないガキなんだな。かわいそうに。
食わず嫌いは井の中の蛙なんで、無害だけど、
自分の知らないことまで大きな声で否定するのは厨房と思われ。

>>181
放っておいてあげましょうよ。
かわいそうだよ。

>例えばC++のクラスは宣言時にprivateな属性もそこに書かなければならないけど
>その属性がstructなりclassなら、その定義までヘッダに晒さなくてはならない。
なんというか「旧世代」を感じさせるレスですな。

ゲッターセッターはやっぱ要らないね。

もちろんいるよ。
まぁプロパティの無いJavaは糞だが。

>>184
情報隠蔽の意味を知らない厨房。

>>177
激しく嘲った

戦場で必要なものこそOOPなんだよ。ボケとんなハゲ

>>172
OOA,OODとOOPLの区別ってよりも。
データ構造とクラス間相互作用の区別がついてないって感じ。

つうか戦場ってシステム系の」ことだろ？

>>177
好き嫌いで語ってる時点で厨房っと…。
まともな PG ならただの好き嫌いに筋の通った理論をつけて
ごり押しする能力がある筈。

今日もたくさん釣れました(藁

>>192
釣れた、と言ってる時点で厨房っと…。

>>190
制御分野でも。
「リアルタイムＵＭＬ」って言う本よんだけど、
チンタラした制御でない限り、今のCPUでは実行不可能。

>>194
それはCPUが悪い・・・。
このご時世仕方ないかもしれないが。
制御系はやった事ないんで知らないが、まあ大変そうだな。
頑張って構造化プログラムしてやって下さいな。

ＯＯＰは小手先の技術じゃないんで、資産と人材が集まるまで
大変だとは思うＹＯ。
色んな会社を見て回るのが良いのかも･･･。

俺的にマジレスでした。

>>178
>OOPL批判ならＪＡＶＡは関数ポインタ無いから糞だし。

関数ポインタっていうか、メソッドがファーストクラスのオブジェクトだったら便利なのは同意。
けど、無いから糞って程じゃないと思う。
ちょっと複雑になるけど、以下のようにすれば望む機能は得られるわけだし。

* interfaceの宣言
public interface Comparer {
public int invoke(Object a, Object b);
}

*inner-classのインスタンス化
Comparer c = new Comparer() {
public int invoke(Object a, Object b)
{
return this.stringCompare(a,b);
}
};

* intefaceからの呼び出し
int comparisonValue = c.invoke(a,b);

(*)このコードは
http://member.nifty.ne.jp/masarl/article/nifty-logs/inner-vs-delegate.html
からお借りしました。

>>192
敗北から何を学ぶかが大事です。
あまり気を落とさないで下さいね(^^)

>>194
高級言語なんかで制御できるかよ。
構造化？ヴァカ逝ってんじゃねーよ。

なーんて時代もあったねえ。

C++の仮想基底を叩く人いないのか

>>196
それはCでも多態できるって言ってるのと同レベルだと思うよ.
関数ポインタ使えないのとコレクションが型安全じゃないのは
糞といわれてもしょうがないくらいに欠点

>>200
は？コレクションが型安全じゃないって…
君、型安全ってどういう意味で言ってる？

そもそも、>>196はポリモーフィズムの基本なんだけど。
それをCで多態できるのと同レベルって…

Javaって結局総称サポートしてないの？
駄目駄目じゃん。

>>201
いちいちキャストしなくちゃコレクションの中身使えないでしょ。
そして実行時までキャストミスには気づかない。
まあキャストするクラス書けばいいけど、
そりゃ結局CでOOPできるといってるのと同じレベルの話だ

面倒なコーディングすれば「Cでも多態やクラスみたいなことできる」
って騒いでるアンチと同レベルって言いたかったんだよ

>>203
特定のクラス用のcollectionクラスつくるのと
CでOOPできるのとが同じレベルに見えるのか…

すっげー不思議な奴だな。
特定のクラス用のcollectionクラスつくるぐらい、
開発環境工夫すれば自動的にできる話だろ。
アフォらし

>>204
だ・か・ら

>開発環境工夫すれば
CでOOPするのも
>自動的にできる話
なんだって

>>205
Cで開発環境に手を入れてOOPするには文法を拡張しなきゃいかんでしょ。
それこそC++みたいにね。
collectionクラスの自動生成はJavaの文法を拡張する必要ないでしょ。

というわけで、全然レベルが違うよ。

俺の脳内のイメージの話で恐縮だが、
オブジェクト指向を知らなかった時代の「プログラム」に対する認識は
すごく二次元的で平面的だった。
今は三次元的なモノに感じる。

２次元世界から３次元世界へ移行するのには
確かに労力ずいぶんかかったけど、
やっぱり表現力は爆発的に増えたよ。

そして普通なら複雑度も爆発的に増えるはずなんだろうけど、
GoF パターン等が、その複雑度の爆発を抑えて、むしろ以前よりも
複雑度は下がっている。

負け犬アンチは２次元世界から３次元世界を理解しようとして
悩んでしまった人や、
表現力の爆発に伴う複雑度の爆発を抑えるテクニックを知らなかった人達なような気がする。

>>207　知らないというより、「判ったからダマットレ」と言いたいの

確かに勉強不足の奴もプロジェクトにもいるが、会議はそいつの
勉強の為の場じゃないし、ましてや君の知識を披露する演台でもない。

やるなら一人でやれ。俺も一人でやってるんだから会議では黙ってろ

>>208 判ったからダマットレ？　ｹﾞﾗｹﾞﾗ
『負け犬アンチ』って言葉に敏感に反応する奴がなに言ってんだか。
そもそもあんたがひとりでやってんのは友達いないからでしょ？

と煽ってはいけませんよみなさん

プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。

>>209
典型的な鬱症状患者だな

　　　　　　　　ほら、またきちがいすれがあがっているよ
　　　　　　　　　　　　　　　　 　 　 　 ,!ヽ
　　　　　 　 　 　 　 　 　 ,!ヽ、　　　 ,!　 ヽ
　　　　　　　　　　　 _,..ィ´￣｀)-‐‐‐''　　　ヽ
　　　　　　　　　 　 /　　´｀)'´　 　 _　　　　 !、
　　またかよ…　/　　i-‐'´　　　,　｀　　　　 `!
　　 lヽ、　　/　 Y　 　 ,!　ヽ-‐‐/　 　 　 　 　 l　
.　　l　＞‐'´｀ 　 l　　 ﾉ 　　ヽ_/　　　 　 　 　 ﾉ
　 ,ﾉ　　　 　o 　 ヽ　　l　　　　　　　　　　　 _,ｲ
　i'.o　 r┐ 　 　　 ヽ、 ヽ､_　　　　　　,..-=ﾆ_
　l　　 ,!-l､　　 　　 ﾉヽ､,　　　　　　　　　　 ヽ
　ヽ　　　　　　　 _,.ｨ'. 　,!　　　　　　　 　､ 　　`!、
　　`ｰ-､_　 　 く´　 　 l　　　　　　　　　 ヽ 　 　l
　　　　　,!　　 　`!　　 l　　　 　 　 　 　 　 ヽ､__ﾉ
　　　　 l　　 `!　 `!　　!　　　　　　　 　 　 　 l
　 　 　 l　 l.　l　 ,　l　　ヽ、 ､_　,ｨ　　　　　 ノ
　　　　 l､_,!　 し'　 l　　　l　　 `l　　　　　　l

>>208
誰に逝ってるのか知らんが、お前、疲れてるぞ。ちったー休めや。
なーに、会社のほうは大丈夫。みんながちゃんと君の分もがんばってくれるよ。

つーか、いないほうが生産性があがるみたいだし。

>>207
そんなのはＣ時代に自分で発想していて当たり前。

Cでもできる厨
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

十年以上前のテクニックを最新技術だと思って得意になってるばかりか
「自分は進んでいて、ＯＯ知らない奴は遅れている」
などと勘違いも甚だしい奴が多過ぎる。
しかも、俺から見れば時代遅れのテクニックを押し付けてくるし、
「本当の最新のやり方はこうだ」
と俺が教えてやっても、逆に時代遅れと受け取るし、
雑誌や本に書いてあることなんて、大抵１０年は遅れている事ばかりなんだよ。
本当にＯＯ厨には困ったもんだ。

>>216
１０年前なら話が合ったかﾓﾅｰ

「本当の最新のやり方」キボンヌ

ネタに決まってるだろ
プロの逝って良しの１が技術的に具体的かつ正確な
レス付けたの見たことない。

それは商売の邪魔になるから教えられない。
過去スレにヒントとか書いてあるが。

目が曇っている者には目の前のものも見えない。

「技術的に具体的かつ正確なレス」きぼー＞＞風呂の逝ってﾖｼ

じゃあちょっとだけ。
継承の組み合わせで大量にクラスが増えそうな場合、
継承を使わずに、全ての要素を重ね合わせた基本クラスを用意し、
注文によって必要な機能を持った任意のオブジェクトの生成を行う。

>>206
>Cで開発環境に手を入れてOOPするには文法を拡張しなきゃいかんでしょ。
なじぇ？
Cの文法の中でできるよって主張してる奴がこのスレや前スレにたくさんいる。
そしてそれは事実だ。ただめんどくさいだけ。

君の思考回路は彼らと同程度だろ

>>223
委譲、Compositionってあたりだね

Facadeと言いたいのかな

>>223
（　ﾟдﾟ）ﾎﾟｶｰﾝ

デザパタ＝ノストラダムスの大予言

俺だったら、
OOPLの初期から確立していたFacadeを
自分の独自発見のようにいちいち言う奴とは
仕事したくはねぇーな。

共通概念として整理して名前つけて広報する事って、
意外と重要な仕事なんだよね。

知的所有権の共同保有とか相互使用協定と同じく、
技術の健全な発展のためには、欠くべからざる仕事だと思う。

皆が「俺が独自に発見した概念で、
　　　あんたの糞概念とは桁がちがうんだー」
とかいいだしたら、相互理解も共同作業も成り立たなくなっちまう。

それじゃ、真に有用と思われる新規概念を構築しちまった人は、
どう振舞えばいいの？

全然ちげーよ。ヴァカ！

＊「本当の最新のやり方はこうだ」と俺が教えてやっても、逆に時代遅れと受け取るし、＊

な？言ったとおりだろ？

１０年前なら、話が合ったのにねー。残念だね。

デザパタなんか勉強すんなよ。
目が曇って最前線に立てなくなるよ。
（システム系は除外）

>>232
は、漏れの過去の「10年前は…」発言を見て
厨が作ったﾈﾀｷｬﾗなんで、質が低くてスマン。

確かに、最前線の雇われｺｰﾀﾞには不用な概念かもな。
変に設計いじって欲しくないしぃ、
人の仕事で勝手に試行錯誤してほしくないしぃ

最近はOOPしないほうが難しくないか？

VBだってヘジがOOにしたし

おれは２０３の言ってること理解できたよ。
どの言語を使っても似たようなことはできる。
ただし、用意に記述できたり、できなかったりする。

だから、>>196のようなやり方をしてまでする方法は
CでOOPするのと同じなんだろう。

ただ、関数ポインタがないからJAVAがくそって言うのは理解できない。
C++をつかってて関数ポインタを使いたくなった事はないんだけど、
どういう時に使うと便利なの？

>>238 DLL作ったり使う時

携帯に収めたい時。
ＯＳ作りたいとき
インタプリタ作るとき
コールバック使いたい時

>>240
　コールバックはオブジェクトインスタンス(ポインタ)を渡してもいいじゃないか

分散オブジェクトしたい時
簡易スレッド作りたいとき
コードの動的生成やりたい時
プラグインやりたい時
言語解析機作るとき

>>224
話の流れ全然読めてますか？
>>205のCでOOPするのに自動化できるってに対するツッコミから来てるんですよ。
最初からCの文法でOOPしてたら自動化も何もないですね。
自動化するのであれば、Cの文法を拡張しなければ、どうしようもないと思いますが。

>>242
…virtual関数じゃだめなのか？
つうか、本当にOOPわかってんのあんた？

>>238
は？まさに動的束縛の典型例というか、一番単純な部分だと思うんだけど。

>>241
よくわからん。

良く不便だなと思うのは通信でのエラー処理だな。
元が同じエラーでも現在のアプリ側の状態によってエラーの種類が
かなり予測不能に増える。

>>223
そんなものはとっくに常識になってますが。
万能チューリングマシンって聞いたことない？

オブジェクト指向も結局は手続き型じゃないの？

関数型ベースのオブジェクト指向言語もあるけど。
OCamlとか

>>246
へっぽこ

>>248
>>249に加えて、論理型オブジェクト指向言語もある。

>>246
　それならコールバックより例外の方がより適切では？
　それともエラーが発生したらとりあえずコールバックして誰かに処理してもらう事にしてるの？
　回復可能ならreturn して貰って　でなければ例外投げて貰うとか？

>>247
昔delphiスレを潰した方ですか？

>>246
なんだ、実装技術低いだけｼﾞｬﾝ(ﾜﾗ

>>246
C++なのに戻り値で0か-1返して、受けた側でIF ELSE分岐してる
馬鹿がｺｺにもいたか…うちの会社にもいるんだよ…肩書きｴﾗｰｲ奴に…

>>200
もともと言語でサポートされていない Cでの多態。
メソッドが一個だけの Strategyパターンとしてサポートされている Javaでの関数ポインタ。
両者を同じものとして扱うのは乱暴杉。

>>254
アフォ

>>255
Javaだっつうのに！

>>243
最初にクラスもどきを作るのに自動化されたジェネレータを一発起動。
出来上がったソースはCの文法どおり。
これで立派な自動化だけど?

>>206の
>collectionクラスの自動生成はJavaの文法を拡張する必要ないでしょ。
これだって同じ意味でしょ？
最初に造るときだけ自動化してあとのメンテはJavaの文法どおり。

もしのちのちのメンテまで自動化しようとしたらJavaも文法拡張するしかない。
例えば IntegerVector,StringVector とか造ったあとに DebugVector
というデバックプリントはくVector造ったら継承しなおせないでしょ

話の流れを読めていないのは君だと思うが

>>257
少なくとも実力の伴っていないお前よりはマシだ。

>>258
どうせ同じはなしだろ、馬鹿。

>>202
いずれサポートされると思われ＞総称
http://jcp.org/jsr/detail/014.jsp

>>256
あほですか？
関数ポインタはまさに「多態」をサポートするために
Cに組み込まれていますが？

>>258
Javaならリフレクションでメタプログラミングできる方法が
コアAPIにあるんだぞ？それで関数ポインタが必要なんていってる
やつは、C++でそれをいう奴の1000倍馬鹿だと思うが…

OO厨＝二周遅れのなのに先頭を走ってると勘違いしているランナー

通信でのエラー処理は時間シーケンスが絡むから確かに普通に実装してたら閉口するな

俺はどうやってるかというと簡単なスクリプトを作ってその行番号でエラー処理したり
それほどでもない場合は

static no=0;
switch(no++)
{
case 0: ...
case 1: ...
case 2: ...
no:=0;
}

みたいな感じで書いて エラーが起きた時はこのnoと組み合わせて判断させたりしてるな

>>246
不便なだけ

>>266
エラーオブジェクトのクラス自身にディスパッチロジックおいといて、
それをコールすればええだけﾔﾝ…

>>267
おまえ、社会人じゃないだろ。

>>268
言ってる事が良く判らんが
エラー処理はオブジェクトに依存しない。手続きに依存する。

int a = 10;

if ( 9 < a < 10)
printf("9 < a < 10");
else
printf("!(9 < a < 10");

これを実行したら, 9 < a < 10 と表示されました。
これはコンパイラのバグでしょうか？

>>270
手続きをオブジェクトでラッピングするんだよ。
状態が関わるダブルディスパッチなら、その方が管理が楽。

うちの上司並の馬鹿だな（ﾜﾗ

256 GET!!!
小さくガッツポーズ。

>>272
相変わらず意味が判らんな
エラー処理が１００種類有る場合には１００個クラス作るのか？
それとも処理の中に状態フラグいじるルーチンをいちいち置いて
switch-case１００個並べるのか？

9<aが1を返してそれと10を比べているだけだと思うが。。。>>271

>>274
関数100本書くほうが賢いか？

>>276
はあ？
異なるエラー処理が１００種類生じる場合の話だぞ
それとも「通信エラー」と表示してアプリ終了させるだけのヘタレプログラム
でも作ってるのか？

>>276
はい、賢いです。

>>263
そうですね。
構造体の中の関数ポインタの値を置き換えることで多態を表現できますね。

>>73
>３）オブジェクト指向は狭い意味でも、保守設計費用を含めた広い意味でも
>　　その生産性に有意の差は認められない。
>　　むしろ低下する場合が多く報告されている。
>４）真の技術革新によって従来の成熟した技術から転換が起こるには
>　　数倍〜１０倍程度の明瞭な生産性の差がみられるのが一般的である。

ｿｰｽｷﾎﾞﾝﾇ。

このスレにいるやつって職業プログラマ？？
アフォな議論してるとしか思えん。

http://www.njk.co.jp/otg/Drop/Drop_v20/part2/chapter5.html

コンポーネントを組み合わせながらシステムを構築することで、生産性の向上を
＞図り、再利用性を高めるというのは、オブジェクト指向の理想であり、
＞オブジェクト指向技術採用時の大きなメリットと言われている。
＞しかしながら、オブジェクト指向開発の評価として
＞「再利用可能なコンポーネントは作成できなかった」、
＞「従来よりも生産性は落ちたようだ」などといった愚痴をよく耳にする。

＞オブジェクト指向は、５年後、１０年後の企業のあり方を前提とした長期的な
＞ビジネスプロセスのリエンジニアリングが必要とされる。

>>281
ｱﾌｫ上等。
ばっちこい!!

元のＨＰはサイトごと無くなっているが、紹介記事。

http://slashdot.jp/article.pl?sid=01/09/22/109245&mode=thread&threshold=
オープンソースプロジェクトの成功率

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

ねたりさいくるっすか

４）は列挙に疲れるから歴史の本でも読んでくれ。

>>281
ネタで書き込んでる奴が大半。

OOってのはまだまだ枯れた技術ではない。
構造化は既に枯れた技術。

OOと構造化の差はここにある。
OOが構造化を含むというのは当然。
枯れた技術に負い目を感じているからである。

>C++を採用したプロジェクト→20.8%
>JAVAを採用したプロジェクト→20.6%
>Cを採用したプロジェクト→45.13%
Cよりもはるかに歴史が浅いC++やJavaがすでに20%以上もの成功率を誇っているっていう
好意的な解釈はできないのかな？俺はこの記事を見た時、単純にそう思ったんだけど。

# っていうかオープンソースプロジェクトの「成功」って何を基準にするんだろう。

>>284
誰だか知らないが、そんなところで厨房なんて言葉を使うなよ。恥ずかしい・・・・

>>290がショックで気がふれてしまいました。
ご冥福をお祈りします。

>>284
どこに使ってるんだ？

リンク先の
>Javaで始めようとする人に厨房が多いのか。
この事だと思われ

>>289
オープンソースプロジェクトに参加する人間は
C ハッカーな UNIX 野郎が多いということか。

>>288
うましか

ああ、下の方に掲示板があったのに・・・。
ごめんなさい。

こんなの発見。

オブジェクト指向の生産性評価に関する一考察
http://homepage.mac.com/nanameneko/job/papers/ITCproductivity.pdf

うううう
＞Delphi 0.042
我が愛しのDelphiがこんなところに……

(同じRAD系の)VisualBasicより上だから少しはましですけどね．


Del厨ってどこでもVBを目の敵にするのね。
ところで、あそこは2ちゃんねらーの巣窟なのかしら。

ちゃんと’すくつ’っていわなきゃだめだよ

「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。

くそすれ３００げとおめ

>>297
その PDF の中に書いてある怪獣の絵
とても可愛いっ！！

そもそも、このスレ　マ板のネタだろ！

>>282
もうちょっと定量的な評価が欲しいっすね。
いや、漏れは何も出せてないので大きなことは言えんのですが。

>>303
だね。

そのＰＤＦねえ・・・
ソフトウエア部品の流通には根本的な問題がある。
事前にその部品の製品の品質を確かめる事が出来ないという点である。
「買ってみるまでは何が出てくるか判りません」
じゃ、くじ引きみたいなもんだな。
マイカルだな。

>>306
しかしネタキャラ演じるのうまいね、あんた。

>>277
＞100種類のエラー
分　類　し　ろ　!!

言語以前の問題。
ｱﾌｫですかアンタ？

＃と。ここで多態が役立つのでわ。

>>259
だから、
> 最初にクラスもどきを作るのに自動化されたジェネレータを一発起動。
> 出来上がったソースはCの文法どおり。
> これで立派な自動化だけど?

ジェネレータに食わせるソースはCじゃねーだろうが。
どこ読んでんだ、こんヴォケは。

> >collectionクラスの自動生成はJavaの文法を拡張する必要ないでしょ。
> これだって同じ意味でしょ？
> 最初に造るときだけ自動化してあとのメンテはJavaの文法どおり。

全然違うだろうが。collectionクラスを自動生成したけりゃ、
基底のcollectionクラスと要素にしたいクラスのソースがあれば十分だろ。
なんでこの程度の事にここまで説明しなきゃならないんだ？
ほんと白痴相手は疲れる。

>>309
君、早朝からテンション高いな。

>>310
君の所じゃどうか知らんが、俺の所じゃもう午後ですが、何か？

>>310
ワラタ

>>310-311
藁た。
>>310君、早朝からマヌケだね。

>>274
普通に考えて、エラーを例外オブジェクトに格納して throw する
以下、適当にでっちあげたソース.

//ﾀﾞｳｿ
void download(string inUrl , string inSaveFilename) throw()
{
　UrlParse url(inUrl); //URLをパースする. 失敗時例外 UrlParseException

　Socket soc;
　soc.Connection( url ); //ホストに接続 失敗時例外 UrlParseException

　SaveMemory bufer;
　HttpRequestMaker req(url); //リクエスト作成
　soc.Send(req); //リクエスト送信 失敗時例外 UrlParseException
　soc.Reserve(memory,inSaveFilename); //結果を保存 失敗時例外 UrlParseException

　//後処理は全部デストラクタががんばってくれるのでやらねーよ
　//OO万歳!
　return;
}

×　soc.Reserve(memory,inSaveFilename); //結果を保存 失敗時例外 UrlParseException
○　soc.Reserve(bufer,inSaveFilename); //結果を保存 失敗時例外 UrlParseException

すまん、ぴたてん見ながら書いていたら間違ったYO。
んぢゃ、寝るので反論かいといてくれ。

む、さらに間違っていたのでいっそのこと書き直す。
レス汚しｽｽﾏｿ.
//ﾀﾞｳｿ
void download(string inUrl , string inSaveFilename) throw()
{
　UrlParse url(inUrl); //URLをパースする. 失敗時例外 UrlParseException

　Socket soc;
　soc.Connection( url ); //ホストに接続 失敗時例外 ResolveException,ConnectException

　HttpRequestMaker req(url); //リクエスト作成
　soc.Send(req); //リクエスト送信 失敗時例外 IOReadException
　soc.Reserve(inSaveFilename); //結果を保存 失敗時例外 IOWriteException

　//後処理は全部デストラクタががんばってくれるのでやらねーよ
　//OO万歳!
　return;
}

ついでに使い方を書くと
try
{
　download("http://www.2ch.net/" , "2ch.html");
}
catch(Exception e) //すべての例外は Exception から派生している
{
　//俺は printf が好きなのでこれを使う　文句ありますか?
　printf("エラーﾆﾀﾞ!謝罪しる\n%s\n" , e.getMessage() );
}

>>274
JavaやC#のように、クラス毎にどの例外が発生するか具体的に明示してあるほうが
多種の例外をハンドリングするのに適していると思うが。

>>314-316
だから、それは使う方だろ？　使う方が楽なのは皆が認めるよ。

ここではソレを作る方の話をしてるんじゃないの？

>>318
いや、作るにしても、ちゃんと互いに責任関係を明確にできるほうがいいでしょ？
「俺はこの例外投げるから、ちゃんと処理しろよ」と言える事のメリットは大きい。
特に複数人で開発するのならね。

人数が増えれば増えるほどこれができない言語との差が広がっていくよ。
他のメンバーがつくったオブジェクトがどんな例外を投げるかわからないんじゃ、恐くて使えないでしょ。

ここにきてる奴はクラス使ってﾏﾝｾｰ厨ばかりです。（ｗ

C#だと結局追える範囲が限定されるしな。MSに規定される量が多すぎる。

>>318
はあ？例外をやたら投げるだけなら誰でもできるでしょ。

俺が考えるには、オブジェクト指向は再利用価値のある部分のみ、もしくは
すでにパターンかされ尽くされた部分に使うべきであると思うなぁ。
関数の場合はそれだけで仕様は終わるがクラスとなるとクラスひとつが仕様
になるような気がする。

>>318
そうそう、とりあえず>>274は例外を処理する側の話だよねえ。

274 ：プロの逝って良しの１ ：02/09/07 16:36
>>272
相変わらず意味が判らんな
エラー処理が１００種類有る場合には１００個クラス作るのか？
それとも処理の中に状態フラグいじるルーチンをいちいち置いて
switch-case１００個並べるのか？

>>263
それは多態というよりはメソッドの動的束縛なのでは？
本来は、多態ってのはある型の変数や関数に多種の型の値を適用できることで、
parametric polymorphismとかinclusion polymorphismとかad-hoc polymorphismなどがある。
それをOOPLに持ち込むとメソッドの動的束縛につながっていくということで。
メソッドの動的束縛以外の多態の効用としては、
関数型言語の高階関数などは多くの場合多態だし、
Cの算術演算子もad-hoc polymorphismで多態だよ。

人海戦術。全部switchでかく。これ最強。

>>324
無名インナークラスつこたらあかんの？

>>327
きたねーソースになるな。
よめね―じゃん。

>>328
ひょっとして関数のネストを許す言語もお嫌いで？

>>328
100個も関数作る方がよっぽど汚いかと。
あと無名クラスも書き方次第で読みやすくかけるよ。

>>329
関数のネストを許す言語ってあるの？ gccの独自拡張で関数ネストできるのは知ってるけど。

>>330
アフォか！
処理と例外処理をそばに並べておけるから可読性高いの！
「この例外処理はなんだっけ」っていちいち他のファイル開けにいくのか？

>>330
Perl

>>332
ぉ、本当だ。でもこれって用途あるのか…？謎。

>>331
誰が他のファイルに書くっつったよ。同じファイルに書けばいいだろう？
とりあえず、お前要らないから黙ってろよ。

>>330
Modula-2(当然Modula-3も)とかpythonとか…それぞれ細かい制約がつくけど。

>処理と例外処理をそばに並べておけるから可読性高いの！
駄目だこりゃ

オブ戦スレもここまで成長しましたか。
うれしいですね^-^

ここで出た例外ってどこでcatchされるんだっけ・・・
と悩むようなら設計がヤバイ。

>>333
private methodが1つのmethodからしか呼ばれてないようなのは結構あるでしょ？
そういうのはnested procedureで十分だよね。

>>337
逆に、本来はどこでcatchされても意味が通るような設計/実装を心掛けるべし、と思われ。
その意味でも>>331は論外。

ダメプログラマー必死だな（藁

いいか、お互いに関連の高い変数や関数はなるべく近くに置く。
一画面に入るようにするのがベスト。
同じファイルなんてのは失格。

>>340
必死なのはお前だろ(藁

>>334,338
ふむ、参考になったっす。たしかにprivate method並べるよりはイイかもしれん。

>>339は通信やったことなさそうなんで論外

>>343
>本来はどこでcatchされても意味が通るような設計/実装を心掛けるべし
通信するプログラムでもこういう設計/実装は可能。アンタこそ実務やったことあるの？

「意味が通る」の意味が不明だが、
例えば、アプリケーション層でキャッチした下位層からの通信例外は
アプリケーション層の状態や手続きによって千差万別の処理が必要になるのだがね。

意思の疎通がまったく取れていない模様

じゃあ二周遅れの君達に最先端技術の一端をちょっとだけ教えて上げよう。
「最良のコードは上から下へと乱れなく読める手続き型である」

>>347
激しく同意！！
モジュール分割なんて流れを阻害するだけだし
オブジェクトが自立的に動くなんて論外だ。

おまえ等おはようございます。

>318
実装のやり方? おまえは俺様の擬似コードをみても実装方法が
ひらめかねーのかよ。おまえ本当にプロか?
オブジェクト指向は、
設計が決まってしまえばあとは実装を詰め込んでいくだけだろう。
ついでに使い方のテストもできているんだからな。

>328
おまえが昔書いたソースよりはマシ

>331
例外にもそれをスローするクラスから連想できるような
わかりやすい名前を付けるべき。

>341
よし、俺はもうソースを一部だが公開したぞ。
次はそのおまえのすばらしい非OOのエラー関数が100個ある
プログラムを公開してみろよ。まってるにょ。

>341
そうかそうか、ぢゃあ、宿題のプログラムは
激しく見やすくなるね。早く公開してほしいにゅ。

>>347-348
多分君たちは、プログラマ止めた方が幸せになれると思うよ。

>>331
バカ発言の極致ですな。
一種類のエラー発生元からの一種類のエラー種別ごとに、いっこの
処理ブロックを、発生もとの近くに羅列してるんだね。
こんな奴が「俺は最先端の技術者」と思っていて職場じゃ通用して
るのか…そりゃ日本の開発会社は低レベルっていわれるわなあ…

で、ネタですよね？まじでいってんの？

>>347
すげー、エラー処理とかで戻ることもないのか。
それに複数のファイルに、プログラムを分けたりしない人ですか?
ますます、宿題のプログラムが楽しくなってきた。

>>347
じゃあ関数なんて使えないね・・・・

>>350
いやいや、なにも昔流のコードを主張している訳ではないのだよ。
メッセージ機構やらなんやらをバックグラウンドに隠蔽した
ニュータイプの手続き型。

>メッセージ機構やらなんやらをバックグラウンドに隠蔽した
>ニュータイプの手続き型。

ニュータイプキタ━━━━（゜∀゜）━━━━!!!!!
師匠!
そのニュータイプの手続き型というものを是非伝授してください。
おながいします。

>>331
あーう、良く読んでくれ。
上位層では一個の例外から複数の場合の処理が発生する。
それはオブジェクトによって固定ではなく、それまでの処理に依存する。
つうことだ。
同じルーチンを走っていても違う処理が必要になったりする。
それまでの処理の履歴に依存すると言う事だ。

お前ら釣られすぎ。
言っとくけど奴は絶対コードなんて出さないよ。

>>357
ネタ雑談スレで何を言う。

>>355
なんとなく語り口がシャアっぽくなってるが俺。

これだけ情報あれば充分だろ。

360げとずざー

コード出して欲しいのか？
んー、人のを探して見る。

>>358
> ネタ雑談スレで
マ板に逝ってくれないかなぁ...。

>356
フラグを例外を使ってとばすの?
それこそ、例外オブジェクトに解析に必要なフラグやメッセージをバインドして
飛ばしたほうが見やすくなると思うがな。

try
{
　throw FlgException(500 , "僕の肛門も閉鎖されそうです");
}
catch(FlgException e)
{
　printf("エラー %d: %s", e.getErrorCode() , e.getMessage() );
}

別に全部の例外を呼び出されたメソッドに投げ返す必要はない。
普通は自分のクラスの中で処理して、もうだめぽな状態になったら
例外を投げる。

>>363
大変失礼、間違えた 314 です。
プロの逝って良しの１を語ってしまったスマソ。
決してｼﾞｻｸｼﾞｴｰﾝではないので。。。

>>359
わかんねーよ。
ニュータイプって何だよ。おまえはただのガンオタか?
シャア専用板へ(・∀・) ｶｴﾚ!!

説明しろとはいわないが、
どっか参考になるURLぐらいは教えてくれよ。

わかったよ。

プロ逝＝末端のスクリプト書き

汎用的ライブラリの書き方の話をしても通じないわけだ。
そりゃあ末端で複雑な事をして汎用性を高めてもしかたがないわな。

（java）

FileInputStream fis = new FileInputStream("filename");
int b = fis.read(); //←ココ
fis.close(); //←ココも多分

良い例がみつからないが、これなんかどうだ？
イベントや割りこみを隠蔽して見事に手続き型にしちゃってるぞ。
実はイベント駆動なんかウザくてやってらんねーつうのが
ライブラリ作成者の本心だろうな

知恵のある人は一を聞いて十を知る。
私は一を示した。

よって
//// 終了 ////

>>367
なんで入出力をイベントドリブンにしなきゃいかんのよ。
使い分けろって言ってるの。

# こいつ、十を言っても一すら分からんボケだな。

愚かな。
十年後くらいには再手続き型化がブームになっているであろう。

>>370
はいはい、そーですね。おめでてー頭だな。

>>367
>FileInputStream fis = new FileInputStream("filename");
>int b = fis.read(); //←ココ
>fis.close(); //←ココも多分

FileInputStreamオブジェクトのメソッドをコールしてるよね。
このコードはバリバリのオブジェクト指向だと思われ。

オブジェクト指向、手続き指向をなにか勘違いしておられませんか?

>>354
>いやいや、なにも昔流のコードを主張している訳ではないのだよ。
>メッセージ機構やらなんやらをバックグラウンドに隠蔽した
>ニュータイプの手続き型。

ニュータイプの手続き型かどうかはわかんないけど、要は Composed Methodと同じことを言いたいんだよね、きっと。
それ自体は正しい方向性だと思う。

http://c2.com/cgi/wiki?ComposedMethod

>>325
おー、325さんカコイイ。
そのへんに関する良い文書がありましたら教えていただけませんか?

>>367
それが手続き型?
めちゃ、オブジェクト指向ぢゃん。
　　　　　　　　　　　　　　　　　　　　　　＿＿＿＿　　　　､ミ川川川彡
　　　　　　　　　　　　　　　　　　　　／:::::::::::::::::::::::::""'''-ミ　　　　　　　彡
　　　　　　　　　　　　　　　　　　　//, -‐―､:::::::::::::::::::::三　　ギ 　そ 　三
　　　　　　　　　　　　＿＿_　 　 巛/　　　　＼::::::::::::::::三.　　ャ 　れ 　三
　　　　　　　　＿-=三三三ミミ､.//!　　　　 　 ｌ､:::::::::::::三　　グ 　は 　三
　　　　　=＝三＝￣　　　　　　《|ll|ﾆヽ　l∠三,,`＼＼::三　　で 　 　 　 三
　　　　　　　 /　 　 　 　 　 　 　 |||"''》 ''"└┴‐`　`ヽ三 　　言　 ひ 　三
　　　　 　 　 !　　　　　　　 　 　 　| /　　　　　　　　　 三 　　っ　　ょ 　三
　　　　　　　|‐-､:::､∠三"`　　　　| ヽ=　　　　　U　 　三.　　て 　 っ 　三
　　　　　　　|"''》 ''"└┴` 　 　 　 | ゝ―-　　　　　 　 三　　る　　と　 三
　　　　　　　| /　　　　　　　　　　　ヽ　""　 　 　 　 ,.　三 　 の 　 し　 三
　　　　　 　 | ヽ= 　 ､　　　　U　　　 lヽ､＿__,,,...-‐''" 　三 　 か　 て　 三
.　　　　　 　 | ゝ―-'′　 　 　 　 　 | 　|::::::::::::＿,,,...-‐'"三　 !?　　　　三
　 　 　 　 　 ヽ　""　 　 　 　 ,.　 　 | |￣￣￣　　　　　　彡　　　　　　ミ
　　　　　　　　ヽ､＿__,,,...-‐''"　 ,,..-'''~　　　　　　　 　 　　 彡川川川ミ
　　　　　　　　　　厂|　　厂‐'''~　　　　　　〇
　　　　　　　　|￣＼|　／

それに、例外は飛ぶし、おまえが文句つけた俺の書いたソースと同じようなもんだろ。
そもそも、例外がいやとか上から下へ流れていないとダメだというやつが java なんて使うなよ(w

恐怖：OOのテクニックを全て構造化プログラミングにマッピングして理解する奴

あのコードをオブジェクト指向と言っている奴はネタかと思ったが
二人も居るのか(藁

>>377
お前、本当に哀れだな。
最初から勉強しなおして強くイ�`

あのコードがオブジェクト指向？？
なるほど。オブジェクト指向ﾏﾝｾｰする気持ちもわかるな（ｗ
いやぁ爆笑だよ。OO厨諸君

>>379
> あのコードがオブジェクト指向？？
そんぢゃあ、さっきこのコードを
お前が言うオブジェクト指向で書いてみろよ。

いやぁ爆笑だよ。アンチOO厨諸君

必死だなぁ。OO厨よ。落ち着けよ。な。な。

OOを目的語先行と定義すれば、ForthもOOかな

class aho{
private:
int aho;
int kuso;
int baka:
public :
aho(){
printf("アンチOO厨逝って良し")
}
}
main(){
object d=new aho()
d.aho;
return aho;
}

>>380
おいおい、さっきのコードとは、>>367 のコードだぞ。
ついに頭まで悪くなったか?
事件起こして人様にめーわく書ける前に、早めに鉄格子のある病院に入院しる!

すごいオチがついたな。
「8時だよ全員集合」だったら音楽が鳴って舞台が回転し始める。

>>380
public class TestClass implements java.io.Serializable {
...
}

TestClass test;
ObjectInputStream in = new ObjectInputStream( new FileInputStream("hoge"));
test = (TestClass)in.readObject();

イベント＝割り込みと誤解している痛い厨がいるすれはここですか？

>>386
それはただオブジェクトをオブジェクトでラップしただけだろう。

>test = (TestClass)in.readObject();
しかも、せっかくラップしたのに、とりだしてどうする?
なんか意味でもあるのか?

しかしこれが OO だとすれば、キミがアンチOOになるのもよくわかるよ。
とりあえず、いますぐ PG の道は挫折することだな。

ていうかなんで1は立て逃げなのよ？
能無し？

哀れなりＯＯ厨

>>390
∧　∧　( ｵﾏｴｶﾞﾅｰ )
(・ω・) ノ
o(U_U)っ

class Status{
　String getHandlerName(){/*implementation*/}
　//...some status manage codes
}

interface ErrorHandler{public void handle(Exception e);}
class ErrorHandlerImpl1{public void handle(Exception e){/*Implementation*/}}
class ErrorHandlerImpl2{/*same*/}
class ErrorHandlerImpl3{/*same*/}
//...

public class ErrorHandlerFactory{
　public static ErrorHandler getHandler(State state){
　　return Class.forName(state.getHandlerName()).newInstance();
　}　　　
}

Usage:
try{
//some implementation
}
catch(Exception e){
ErrorHandlerFactory.getHandler(getStatus()).handle(e);
}

Javaで、エラー処理を実行時に動的変更(実行中の処理ロジック追加も許す)する
なら、例えばこんなかんじかな？いちいちnewするの無駄とか、そういう重箱すみ
突っ込みについてはカンベン。わかってっから。

１）上位層に依存した下位層作ってるし
２）問題になってたのは投げるエラーの種類をどうするかじゃなくてエラー処理

無名インナークラス

>>394
俺もそうするのが一番スマートだと思う。何がどう汚いソースになるのか小(略。

一画面に収まらないじゃん。ｲﾔﾝｲﾔﾝ

>>396
使った事ないでしょ？

インナークラススレッドで使ったっきり使ってないな。

OOのおかげで、抽象的なプログラミングができて、
より高い世界（知ってる人だけわかる世界）へあがることができる。
実際の作業にあまり役立たなかったとしても、
うまく使えば効率を上げられるはず、と思えたり、
プログラミングにおける地道な作業があまり好きではなく
学際的な雰囲気が好きな人には、
OOを勉強する事が心の支えになってるわけ。

だって気持ち悪い名前のクラスファイルが出来るし・・・。

…もう呆れて何も言えない…。

いいぞいいぞ！プロの逝って良しの１！！
この調子で蹴散らせ！馬鹿なOO厨を！
あっはははははははー。
必死なOO厨よ。貴様らは戦場では必要なしだ。
あはっはははははー。

>>プロの逝って良しの１
318に対する反論はまだ?

とりあえず、ワるきゅーレ始まるんで実況してくるから
俺が(；´Д`)ﾊｧﾊｧしている間にでも反論を書いておいてくれよ!

　

む、また間違ってしまった。
>×318に対する反論はまだ?
>○388に対する反論はまだ?

んぢゃ、よろしこ。

(´Д｀)逝って良しって何人いるの？

>>406
過去ログを読む限り、どんどん世代交替が行われてるっぽいね。ちょっと前の逝って良しの１と、
今回のプロの逝って良しの１は、そん中でもレベルがかなり低い。まー過去ログ読んでみなよ。
面白いぜ。

マジで答えなきゃならんのか？

＞それはただオブジェクトをオブジェクトでラップしただけだろう。

これが間違い。
どこをどう読んだらそうなるのかおしえてﾎｽｲ
それからオブジェクトシリアライゼーションくらいＯＯ厨ならしっておいて欲しい。

>>406
一人。たまに偽物あり。>>77とか。

>>407
一人だっつうの！

本当に激しくレベルが低いのか、確信的釣り師なのか？＞プロの逝って良しの1

っていうか、 >>367 のコードだけみて
「これはオブジェクト指向的か？」っていう質問に
Yes でも No でも答えを出せる時点で思い込み厨だろ。

InputStream is = new FileInputStream("filename");
int b = is.read();
is.close();

これなら多少 OO 的だけどな。

プロの"逝って良し"なわけね。確信犯なのね。
おかげで、いつになく盛り上がったよ。

良くそんな頭の悪い文章、恥ずかしげもなく自信満々
な文体でかけるね。えらい。

┐(；´へ｀)┌　

>>412
Javaつかってるなら、JDKのコアAPIライブラリを、便利で綺麗で
らくちんだと感じたことは、ないのかな？

>410
read() がストリームのメソッドであることがOO的
ファイルハンドルとかファイル名（ﾌﾟ を指定してないし

>>413
問題が違いますが何か？

綺麗とは思わないし。

>>408
おー、すまんすまん。
javaは素人なもんでトンチンカンなことをいっているな。
今調べて鬱になったよ。ごめんな、素人で。

ぢゃあ、それを踏まえた上で。。。
>>367 が 非OO で
>>386 が OOだとしたら、
ファイルから read メソッドで値を読み込むのが 非OOで
シリアライズで取得するのが OO ?

たしかにオブジェクトをシリアライズしているわけで OO であるとは
間違いないのだが、それはちょっと違うんぢゃない?

ＯＯ派はなんのためにレスしてるの？

>>414
たしかにメソッドを使うのはオブジェクト指向だけど、
それだけじゃ「シンタックスシュガーだ！Cでもできる」派に負けてしまうよ。
(この例(>>367のコードね)だとCでもできる派の意見も、もっともだと言える)

>>417
頑固馬鹿の代表者みたいなスレ主が、リクエストにどんなレスポンスを
返すのかを調査し、それをもって自社の馬鹿年寄との対話を行う上での
自衛策を構築する際の参考にするため。

>>419
アンチと年齢は関係ないと思うけど…

>>347

遅レスすまねえが一言いわせろ。

>「最良のコードは上から下へと乱れなく読める手続き型である」

あんたメソッド使用を禁止したうちの化石チックプロジェクトリーダーですか？

あげてしまった(鬱

>>410
まあ、おちけつ。

まず、>>367は例外処理をどうスマートに解決するかという例題として出されたものだろ？
ところが>>367は例外がstream経由でthrowされることはあっても、>>367のソースではcatchされてない。
streamオブジェクト内でcatchしていることはあっても、な。

とすると、FileInputStreamで外に出てくる可能性がある例外を宣言している点ぐらいしか
>>367のソースと例外処理の接点はない。
したがって、FileInputStreamの例外の宣言やFileInputStream自体の実装はOO的かどうかという事になる。
するとやはり、FileInputStreamはOO的に実装されていると見るのが自然じゃないのか？

それともFileInputStreamはOO的ではないと言うのか？

つまりは模擬戦なわけだ。
戦場では必要なしと言ってしまう馬鹿者を戦場でやっつけるためのね。

OO使いたければ、使うがよし。
使いたくなければ、使わんでよし。

500km離れた地点へ行くのに、車や、高速バスなどで行くのが
普通だろうが、
原付でもよいのだ。自転車でも。
原付で行けば、交通費1000円だ。
問題はどこに重きを置くかによるだけで、
どーしようが、勝手にしろ。

見てるとこのスレのアンチOO厨は
かなりのOO信者であるように見受けられるね。

>>425
そう思う。

>>425
全然関係ないけど...
> 原付で行けば、交通費1000円だ。
微妙に正しい値なんだけど、経験者 ?

ばれたか（ﾜﾗ

つまり日本の端から端まで行くのって結構安いのね。

>>430
でも時間がかかればかかるほど宿泊費や食費が増えるし・・・・

>>421
いや、俺は機能が独立してればメソッド化すべきだと思うね。
俺のソース３−４行のメソッド多いし。

>>423
いや>>354,355に対するレスです。

話の流れを書くと
ＯＯはともかくＯＯＰＬはいいじゃん
　　　↓
ＪＡＶＡはポインタ無いから糞
　　　↓
ポインタ無いと何が困るの
　　　↓
・・・とか・・とか・・・コールバックとか・・・どか
　　　↓
インターフェースで出来るじゃん
　　　↓

履歴に依存する場合は出来ない
　　　　　↓
話が飛んでイベント機構の隠蔽とニュータイプ手続き型の話に
　　　　　↓
イベントが隠蔽されたコードの例>>367
　　　　　↓
思いっきりオブジェクト指向じゃん>>372,375
　　　　　↓
（話が変わってるが）いやオブジェクト指向ではない
　　　　　↓
じゃオブジェクト指向にしたコードをみせてよ
　　　　　　↓
で、>>386　　　　　

いつまで続くんだろう…

>>434,435
殊勝ﾀﾞﾅｧ

>>435
じゃあ>>367がオブジェクト指向でなくて>>386がオブジェクト指向だという理由は？

前者は単なるデータを扱い、後者はオブジェクトを扱っている

とーとろじー

みたいに聞こえるかもしれんが・・・

なんでsageてるの？

別の説明

前者は外部のプログラムがデータの出し入れを行うが
後者はオブジェクト自身がデータの出し入れを行う機構を備えているとみなされる。

ageるとバカが来るから
ギコナントカとか

さっきの２連レスでsage設定してただけ。

偽物かと思った。

>>1は、これ読んで、もっと煽り方を勉強汁

【デベロッパー: 日本語が読めず、テストファーストが嫌いなプログラマ】
http://slashdot.jp/article.pl?sid=02/09/08/0734254&mode=thread

スネークマン・ショーのパロディーですか？

ネタだと分るように書いてあるのにマジレスするのはバカだけど
わざとマジギレ反応をして盛り上げるのも宴会テクですよ

>>425の言う通り自分が好きな言語を使うということで終了。

>>443
> 後者はオブジェクト自身がデータの出し入れを行う機構を備えているとみなされる。

惜しい。
「オブジェクト自身が他のオブジェクト(シリアライザ)を使って自身をデータオブジェクト化することができ、
かつ、その後他のオブジェクトが元のオブジェクトを復元することができる。」

そのオブジェクト自身はシリアライズに参加してはいるがシリアライズしている主体ではないことに注意ね。

つーか、じゃあ>>443に聞くけどさ、

Javaのように整数がobject typeじゃない言語ならば>>443のように言えなくもないけど、
Smalltalkのように整数のオブジェクトな言語ならばどうなるんだろうね？
読み取るのが整数だろうが文字列だろうがバイト列だろうが、
みんなオブジェクトなんですが。

　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 ミ,,ﾟДﾟノ,っ━~　　＜ OO厨のWeb掲示板まだかよ？
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣ 　 .┻

ﾟДﾟノ 掲示板のひとつやふたつ早くOOで作ってみろよ。ｺﾞﾙｱ！

Javaならいくらでもあるだろ
ゴーグルくらいすれよ
http://www.hellohiro.com/jspbbs.htm
http://hosting.yoko.ne.jp/servlet/SampBBS01
http://hosting.yoko.ne.jp/jsp/SampBBS.jsp
http://www.asahi-net.or.jp/~jz6h-ymmt/servlet/sv20011202.htm

>>455
自分で作ることは避けるんだな（藁
再利用性に優れている、仕様変更に強いことを
証明してもらおうと思ったのだが。

>>456
OO厨の同士へ
　アンチの術中にはまらないように！

>>454は他人のコードをパクるしか能がないPerl廚とみた。

> >>454は他人のコードをパクるしか能がないPerl廚とみた。
ﾟДﾟノ そういう>>458はパクッても完成させられないC#厨と見た。

ご自慢御のＰｅｒｌ掲示板はどこ？>>459

>>455
ソース見たけど、ここのOO厨って
オブジェクト指向設計って何か分かってるのかな？

>>461
クラスを使うってことでしょ？(^0^=)

ぜひとも貴殿にご高閲賜りたい>>461

>>455

OO信者が紹介してくれたページの掲示板のソースだが・・・
も少しオブジェクト指向設計らしいのはないのか？
つーかおまいらが作れよ。ﾟДﾟノ

> public void do(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> PrintWriter out = response.getWriter();
> out.println("<html>");
> out.println("<head>");
> out.println("<title>掲示板</title>");
> out.println("</head>");
> out.println("<body>");
> out.println("<h1>掲示板 No.1</h1>");
> out.println("<form method=post>");
> out.println("<table>");
> out.println("<tr><th>名前</th><td><input type=text name=\"userName\"></td></tr>");
> out.println("<tr><th>題名</th><td><input type=text name=\"subject\"></td></tr>");
> out.println("<tr><th>内容</th><td><textarea name=\"content\" rows=5></textarea></td></tr>");
> out.println("</table>");
> out.println("<br>");
> out.println("<input type=submit value=\"投稿\">");
> out.println("<input type=reset value=\"クリア\">");
> out.println("</form>");
>
（略）
> out.println("</body>");
> out.println("</html>");
> }

>>464
なんか実は結構詳しいみたいね。
OO知らないとケナすにも取り付くしまがないしね。
アンチ巨人が必死に巨人戦見るような物か？

ﾟДﾟノ こんなページもあるぞ、ｺﾞﾙｧ
判断はおまいらにまかせる。

http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

有名なネタじゃん

>>465
というか構造化プログラム以前の糞ソースじゃねーか。
OO厨ってプログラムの善し悪しも分からないのにOOを語ってんのかよ。

この前日本でワールドカップがあった時、解説者とか言う肩書きで
サッカーのルールも知らん奴がのさばったことがあった。

OO厨もそれと同じ、OOどころかソースの善し悪しも分からないのに
OOという流行に踊らされるピエロ。

サッカーやOOは嫌いではない、というかOO自体は有効な技術だと思っている。
しかし、ソースの善し悪しも分からないOO厨は必要なし。

キチンとOO使えている人は綺麗な設計・実装できるし, OO以外でもそれなりのコード書けると思うんだけど….

# 俺? ﾍﾀﾚなんでもう非OOPLは触れませんです,ハイ.

>>469
能書きはいいから早く作られよ（作れるんだったらな）

>>464
掲示板の作者に代わって反論。

1. HTMLの出力が汚く見えるのは当然。ﾂｯｺﾑ方がおかしい。
2. この掲示板の規模のアプリならこのくらいの設計は妥当。ﾑﾀﾞにOOするより断然いい。
3. 464のコードから、以下の行を省いてるのに作為を感じる。
> if (msgList != null) {
>for (Iterator it = msgList.iterator(); it.hasNext(); ) {
> BbsMsg msg = (BbsMsg)it.next();
> out.println("<hr>");
> out.println("<table>");
> out.println("<tr><th>名前</th><td>" + msg.getUserName() + "</td></tr>");
> out.println("<tr><th>題名</th><td>" + msg.getSubject() + "</td></tr>");
> out.println("<tr><th>内容</th><td>" + msg.getContent() + "</td></tr>");
> out.println("</table>");
> }
> }

まあ、OOな掲示板を出せと言われてこれらの掲示板を示した 455も不用意といえば不用意。

>>471
分かったから早く作れ。

>>472
まず仕様を決めたほうがいいのでは？

>>471
武士の情けじゃないのか？
ところで、１件目が出力されないのって仕様？
>for (Iterator it = msgList.iterator(); it.hasNext(); ) {
> BbsMsg msg = (BbsMsg)it.next();

普通こうだろ？
for (Iterator it = msgList.iterator(); it.hasNext();it.next()) {
BbsMsg msg = (BbsMsg)it;

１件目を出したくないならListIteratorを使って
for( ListIterator it = msgList.listIterator(1); it.hasNext();it.next()) {
BbsMsg msg = (BbsMsg)it;

ま、１件目を特別視したいってことは設計が間違っている可能性が高い。

じゃあ、472が非OOの掲示板を書いてよ。
OOに書き換えてみるからさ。

>>475
>>455にJavaで書かれた非OOの掲示板がイッパイあるけど、それでは不満なの？

# 前もこんな流れがあったな

>>475
漏れは↓の掲示板を使ってるから
http://www.rescue.ne.jp/cgi/minibbs-ic/
とりあえずは、これと同等の機能をOOで実現してくらはい。
趣旨はOOは本当に再利用性、仕様変更に強いかの検証です。
本当に作ってくれるのなら、おながいします。

>>476
>455にJavaで書かれた非OOの掲示板がイッパイあるけど、それでは不満なの？

うん。
455で示されているやつは書きかえる気しないけど、472が書いたやつなら書きかえる気がする。

オブジェクト恥垢

>>474
> >for (Iterator it = msgList.iterator(); it.hasNext(); ) {
> > BbsMsg msg = (BbsMsg)it.next();
>
> 普通こうだろ？
> for (Iterator it = msgList.iterator(); it.hasNext();it.next()) {
> BbsMsg msg = (BbsMsg)it;

漏れはこうする事が多いです。
いろいろやり方があるのね。

Iterator it = msgList.iterator();
while (it.hasNext()) {
BbsMsg msg = (BbsMsg)it.next();
...
}


> ま、１件目を特別視したいってことは設計が間違っている可能性が高い。

禿胴。

>>479
ﾜﾗﾀ

オブジェクト指向は戦場では必要なし！とか言っている椰子のおかげで仕事場が
戦場になる説はキシュツですか？

>>477

【OO厨によるオブジェクト指向設計のWeb掲示板開発が決定！】

　　∧＿∧　　ﾄﾞｷﾄﾞｷ
　 （ ；´∀｀）　ちんこ勃ってきた。
　 人　Y /
　(　ヽ し
　（＿）＿）

>>480
１件目が出力されないのって仕様？
１件目から出したい場合どうするの？
> Iterator it = msgList.iterator();
> while (it.hasNext()) {
> BbsMsg msg = (BbsMsg)it.next();
> ...
> }

>>477　

そ　れ　は　お　ま　え　が　作　っ　た　の　か　？

>>477
>>>475
> 漏れは↓の掲示板を使ってるから
> http://www.rescue.ne.jp/cgi/minibbs-ic/
> とりあえずは、これと同等の機能をOOで実現してくらはい。
> 趣旨はOOは本当に再利用性、仕様変更に強いかの検証です。
> 本当に作ってくれるのなら、おながいします。

ぐげっ、perlっすね?
5行以上の perlのソースはクラクラしてくるんだよね。
一応目は通してみますが。

472が書いたソースなら perlでもがんばってみるけどさ。

つーかここで聞かないで作者にきけよおまいら、、、

>>483
　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 ミ,,ﾟДﾟノ,っ━~　　＜ これでやっとこのスレも新しい段階に入れるな。ｶﾞﾝｶﾞﾚ
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣ 　 .┻

レガシー野郎の夢の宴age

おまゑら戦場とやらで撃ち合って市に絶えなさい
ガンガレ

かなり久しぶりに書き込むが、ここは
perlしか書けない厨房
Cしか書けない老兵
がタッグ組んでるのか?

前者は微笑ましい無害な連中で 後者は職場では非常に有害な連中だと
個人的は思っているが、まぁそれはおいといてだ。後者の連中は、厨房
ドモと組むことに恥ずかしさを感じないのか?

一 応 ベ テ ラ ン だ ろ ? お 前 ら 。

>>484
471のコードはちゃんと1件目から出力されますね。
ちゃんとコード読まずに発言してました。
ごめんなさいごめんなさい。

・・・逝ってきます。

>>491
じゃあそいつらの相手は
・Javaでプログラムを書くことをOOと勘違いしてる奴
・OOで掲示板を書くと豪語しながらforとwhileの使い分けも知らない奴
だな。壮絶な試合になりそうだ

>>493
OOD是非はともかくとしてだ(重要)。

そういうOO厨(と言うんですか?)でも、老兵よりマシ。

老兵は "OOPLを使えば堅牢なコードを書くことが可能である" っていう、
そのうち小学生でも実体験で理解しそうな事すら認めようとしないからな。

>>486
> ぐげっ、perlっすね?
> 5行以上の perlのソースはクラクラしてくるんだよね。
> 一応目は通してみますが。
> 472が書いたソースなら perlでもがんばってみるけどさ。

漏れはPerlも使えるけどさ、この掲示板は使ってるだけで
漏れが書いた奴じゃないよ。
また結果的に同じ機能を実現してもらえればいいし。
言語は>>100はJava使いのようだからJavaでいいよ。

>>493
>・OOで掲示板を書くと豪語しながらforとwhileの使い分けも知らない奴

480から、どうやって「for と whileの使い分けも知らない奴」という結論を導いたかをお聞かせ願えませんか?

>>493 の立場は何だ? Haskell大好き とかなら少し尊敬する。

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　辞めるなら今のうちですよっ
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　>>100　 ／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　そ、そうだよなっ
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| BIBLO |＼
　　　 　 　￣　　　=======　　＼

>>497
厨房同士の馴れあいスレなんだからHaskellとか言っちゃダメダメ。

>>494
×：OOPLを使えば堅牢なコードを書くことが可能である
○：ある一定規模以上のプロジェクトでは
　　OOPLを正しく使えば堅牢なコードを書くことも可能である

>>100 が 敵 前 逃 亡 す る に 10000ｸﾗｽ

> 10000ｸﾗｽ
禿げワラ

>>500
走り書きでもOOPLのほうが堅牢だろ。

むずかしいこと何も考えなくていいんだから。
数十行のC++ (with STL)はperlみたいな感じだなぁ。

504の名前の500は503の間違いネ。

>>495

495=472?

おれひとりでコード書くのはなんだか悔しいんだよね。心狭いんで。

perlで良いので 472が書いてくれれば、モチベーションが高められるんだけど。
>>475の発言は >>472の反応してのことだしさ。

504の気分をちゃんと理解できる奴がいないに1票

>>501
正直、言わなきゃ良かったなと思わなくもないです。

おいおい。おめーらこんなことで争ってるんじゃねぇよ。
VB厨もVB.NETでオブジェクトばりばりやってんだぜ？
VB厨ですらオブジェクト指向やってんのに、
今時構造化かよ。つーかおまえら構造化ちゃんと
できんの？
制御文使うだけで構造化できてるなんて思うなよ。
構造体をちゃんと定義して使え。これ重要だ。
それができて初めてオブジェクト指向へステップアップ
できんのさ。まぁ、OO厨には荷が重いかな。

>>509
もちろんネタだよな?

>>510
ネタのつもりじゃないけど？
図星だった？悪いねぇ。（ｗ

どのへんがどう図星なの?

構造体をちゃんと考えて作ってっか？ってこった。
ちゃんと考えとかないと、ロジックも冗長なものが
できあがってしまう可能性があるわけだが。
それができないのに、OOなんてできないよ？
クラスライブラリ使ってOOﾊﾞﾘﾊﾞﾘだぜ。ってなら
それでいいけど。（ｗ

組み込み以外ではもう随分Cは使っていませんね。

おまえもう発言しない方がいいかもよ>>504=503
OOPLをオブジェクト指向ライブラリとか思ってるだろ（ﾊｹﾞﾜﾗ

>>514
日本語でお願いします

515、か。
よくまちがえるな。

オブジェクト指向ライブラリって何だよ（藁

走り書きでもOOPLのほうが堅牢だろ。

おまえのこの発言のことを言ってんだよ。

>>496
> 「for と whileの使い分けも知らない奴」
for文を使って書いた方がわかりやすく書けるケースにわざわざwhile文を使うから、
その証拠にwhile文で書いて間違えてる

>>497
OO厨が嫌い。OOについては勉強中なので保留。

>>519
なるほど、よくわかった。謝罪する。

>>519は>>500についてはどう考えてるの?

>>506
>おれひとりでコード書くのはなんだか悔しいんだよね。心狭いんで。

目的は本当にOOは再利用性と仕様変更に強いかの検証なので、
申し訳ですがオブジェクト指向派の>>100がひとりで作ってください。
>>100以外の人でも可です。

>>522
一言で言うと、
当たり前。

構造化に置き換えてもなんらおかしいことはないだろ？

「正しく使えば」
これは逃げ。

え、よくわかんないんだけど、519はOO好きなの嫌いなのどっち?

>>525
両方だ。

>>523
> 目的は本当にOOは再利用性と仕様変更に強いかの検証なので、
> 申し訳ですがオブジェクト指向派の>>100がひとりで作ってください。
> >>100以外の人でも可です。

検証したいのは、「オブジェクト指向が手続き指向に比べて再利用性と仕様変更に強いこと」でしょう。
やっぱり欲しいでしょう。

っていうか、おれは 472に作って欲しいだけなのです。
粘着ｳｻﾞ、と言われるでしょうが。

>521
やたらヨワいな(w

>>500
スクリプト言語以外で走り書きしろって言われた場合に現実的な選択肢としてC,C++,C#,Javaを考えると、503であってる気もする。519の指摘の通り、OOPLだからという理由ではないよ。
文字列が使える、typesafeなコンテナがある、というあたりのしょーもない理由ね。それでも俺はCでそういうこまごましたコード書くとよく間違えるね。厨房だし。

>>524
> 構造化に置き換えてもなんらおかしいことはないだろ？
どんな手法にしても正しく使わないと危険
そしてOOは構造化以上に正しく使うことが難しい技術

特にC++の場合は演算子の振る舞いを変えることができるので、
最悪の使い方を行えばグローバル変数乱用以上の打撃を与えることも可能

どこで拾ったテンプレートですか?漏れにも教えて。>>530

どした？今日のOO派のレベルは著しく低いぞ。
今度は教えて君か？

>>532
ネタじゃない？

>>530
日経BPあたりの文系の記者でも書けそうではある

ttp://www.h5.dion.ne.jp/~ikeruze/nae/sis1.htm

>>527

申し訳ないですが少なくとも漏れを頼らんでください。
おながいすます。

なんで誰も'掲示板くらいperlで'、って言わないんだ？OOだろうが何だろうが適材適所だろ。
掲示板でOOの良さ(?)を行かそうと思ったら/.みたいな大がかりなモン作らないと分からん。
仮にできあがっても>>367関連の話しと代わらんぜ。

/.のシステムってそんな大掛かりか？
にしてはずいぶん使いにくいよ。

>>537
大言壮語はいいから、早く作ってくれぃ。

> なんで誰も'掲示板くらいperlで'、って言わないんだ？
537がperlで掲示板を作るみたいです。

>>520
> for文を使って書いた方がわかりやすく書けるケースにわざわざwhile文を使うから、

for文で Iteratorの初期化を行うと分かりやすいケースは、Iteratorの初期化と Iterationが隣接している場合のみ、それ以外は while文を使用する方が簡潔だと思う(オレはね)。
で、あるときは for文、あるときは while文となると、コードの一貫性がなくて読みづらいよね。
だからオレは常に whileを用いている。
これがおれの「forとwhileの使い分け」。

> その証拠にwhile文で書いて間違えてる

どこが間違ってるかもう少し詳しく教えていただけませんか?
以下のサンプルコードで指摘していただけると助かります。

// Omaemona.java
import java.util.*;
public class Omaemona {
static Iterator getIterator() {
String[] strings = { "o","m","a","e","m","o","n","a" };
return Arrays.asList(strings).iterator();
}
static void printIterator(Iterator itr) {
while (itr.hasNext()) {
System.out.print(itr.next());
}
}
public static void main(String[] args) {
Iterator itr = getIterator();
printIterator(itr);
}
}

自分で作らないクセに人には作れっていうんだな。

だってただの煽りだもん

　　　∧∧＿__　　http://www.muuz.ne.jp/hosting/　　
　／(*ﾟーﾟ)　／＼ 月額200円コバルト激安レンタルサーバーホスティング
／|￣∪∪￣|＼／　150MB大容量。電子メール最大20個作成可能
　　　　　　　　　　　サブドメイン、独自ドメインOK CGI/SSI/PHP/ASP/JSP利用可能 　

>>536
ﾗｼﾞｬ。粘着ｺﾞﾒｿﾈ。

Ruby最高ォォォォォォッ！！！！！！！！！！！！！！

あぁ。このスレ好きだ。
この殺伐とした馴れ合いが。
あぁ愛してるよ。ﾁｭｯ!

>OOPLを使えば堅牢なコードを書くことが可能である

そうか・・・・

int　a[1];
for( int i=0;i<2;i++ ) a[i]=0;

>>548
(ﾟДﾟ)ﾊｧ?

JavaならArrayIndexOutOfBoundsExceptionがスローされるし、
C++ならオーバーヘッドを気にしないならoperator[]()をオーバーロードして
safe array使えますが何か？OO関係ねーよ、ボケ。

>OOPLを使えば堅牢なコードを書くことが可能である
を
>OOPLを使えば全てのコードが自動的に堅牢になる
と勝手に読み替える莫迦

おいおい。やめろ。
もう既に俺が突っ込んで、
発言主も謝っているだろう？
無理に続けようとせずともよい（ｗ

おいおい、このスレは粘着で成り立ってるんだろうが。
もっとベトつけよお前ら。

蒸し返してきたのは逝って良しの１だろ。

非ＯＯＰＬでも可能だから意味無くなっちゃうじゃん。
意味の無い解釈と意味のある解釈と二通りあったら
普通は意味の有る解釈をするがねー。

ああ、終わってたのか。ｺﾞﾒｿ

>>552
わかった

552とオブジェクト指向は戦場では必要なし

まったくぅ。血の気が多い奴ばっかでやんなっちゃう。ﾜﾗ

あまり逝って良しにかまうなよ。
彼はここが余りに気になって仕事中から帰宅してまで
しょぼついた目で画面に貼り付いて
右腕の痛みをこらえつつ際限なくリロードし続けてるだぞ。

才能のないコーダが集中力と健康を失ったときどうなるかを
ちょっとは考えてやってくれないか。

んー。ならあげんなよ。

>>559
>しょぼついた目で画面に貼り付いて
ちょっとでもスレ探すのを楽にしてあげようという>>558の計らいだよ。

>>541
> for文で Iteratorの初期化を行うと分かりやすいケースは、Iteratorの初期化と
> Iterationが隣接している場合のみ、それ以外は while文を使用する方が簡潔
だと思う(オレはね)。
つまり、>>480のケースでは（以下再掲）
> Iterator it = msgList.iterator();
> while (it.hasNext()) {
> BbsMsg msg = (BbsMsg)it.next();
> ...
> }
for文の方がよいと認めるということか？
forで初期化した方が変数名のスコープが小さくなるという利点も考えとけよ。

> 以下のサンプルコードで指摘していただけると助かります。
public static void main(String[] args) {
Iterator itr = getIterator();
printIterator(itr);
printIterator(itr);
}
printIterator()って何回も呼べない仕様なの？
前で呼んでないかどうか調べないといけない不便なメソッドだな。

printIterator()中で何か中間オブジェクトを初期化させる必要がないかい？
そうすると上記の再掲コードと同じようなことにならないかい？

552は将来大物になる、もしくはもう大物だ。
そんな気がするんだ。
漏れが保証するよ。

どうでもいいけど、だっせえデザインのイテレーターだな。

>>561
全面的に同意。

なんか今日は外が駄スレの嵐だな。

>>561
まず最初に、そちらの質問にお答えします。

(Q1) 480のケースでは for文の方がよいと認めるということか？
(A1) 認めます。
ですが私は whileを使います。理由は 541で述べた通りです。
「forで初期化した方が変数名のスコープが小さくなるという利点」よりも 541の方が私の中では優先度が高いです。
もう一度言いますが、私は「forと whileを使い分けて」います。
それを「for と whileの使い分けも知らない奴」とあなたが思い込むのは自由ですが。

541のコードで
(Q2) printIterator()って何回も呼べない仕様なの？
(Q3) printIterator()中で何か中間オブジェクトを初期化させる必要がないかい？
(Q4) そうすると上記の再掲コードと同じようなことにならないかい？

(A2) printIterator()は何度も呼べます。ただし itrを初期化せずにもう一度 printIteratorを呼ぶのは Iteratorの使い方としては間違いです。
JCF(http://java.sun.com/docs/books/tutorial/collections/index.html)と、デザインパターンの Iteratorパターンを読んでみてください。
簡単に言えば Q2でやりたがっている事は以下のコードと同じようなことです。

int itr = 0;
String[] array = {"A", "B", "C"};
for (; itr < array.length; itr++) {
System.out.println(array[itr]);
}
for (; itr < array.length; itr++) {
System.out.println(array[itr]);
}

(A3) 必要ありません。中間オブジェクトは必要ありません。
(A4) なりません。

いつものことさ・・・

>>561
次にこちらから質問です。

496で
>480から、どうやって「for と whileの使い分けも知らない奴」という結論を導いたかをお聞かせ願えませんか?

とお願いしたところ

520で
>for文を使って書いた方がわかりやすく書けるケースにわざわざwhile文を使うから、
>その証拠にwhile文で書いて間違えてる

という回答をいただきました。
その回答に対して

541で
>> その証拠にwhile文で書いて間違えてる
>
>どこが間違ってるかもう少し詳しく教えていただけませんか?
>以下のサンプルコードで指摘していただけると助かります。

と 541のコードの中で while文のどこが間違えているかをお聞きしたところ
561の回答をいただきました。

が、この中では「while文のどこが間違えているか」の回答はいただけませんでした。

もう一度お伺いします。
541のコードの中で while文のどこが間違えているのですか?

>>563
>どうでもいいけど、だっせえデザインのイテレーターだな。

どうださいかをご指摘いただければ幸いです。偽者さん。

>printIterator()って何回も呼べない仕様なの？
>前で呼んでないかどうか調べないといけない不便なメソッドだな。
おれは>>563ではないが、少なくともこの仕様はダサいと感じた。簡便性のために複数回コールできるように設計すべきかと。

next()だけで充分。
hasNext()は余計。

>>570
566ではお答えになりませんでしょうか?

>>571
じゃーどうするの？next()がnull返したら次の要素はないってコトにするの？
Iterator#next()がnullを返す事もあり得るんだから、hasNext()は必要。

>>572
いや理屈は分かるけど、実用的ではないと思われ。
>簡便性のために複数回コールできるように設計すべきかと。
が俺の意見っす。
# 好みの問題だ、と言われればそれまでだけど。

>>571
>next()だけで充分。
> hasNext()は余計。

next()だけだと、どんなコードになるか教えていただけませんか?

while( true ){
　　if( it.next()== null ) break;
・・・
}

>>576
>>573

while( true ){
　　if( ( a=it.next())== null ) break;
・・・
}

どっちでもいい事を
おまえは間違ってる、俺が正しい的な言い切りをするところがプロ１のすばらしい所だよね。

>>578
（　ﾟдﾟ）ﾎﾟｶｰﾝ
それだと答えになってないでしょう？

ねえ、もしかしてすげーくだらねえ議論？

nullは扱わない。
これ最強。

>>581
その通りだと今、激しく痛感した…。

>>582
君の大嫌いなデザパタにそういうのあるねえ。プ

>>576
>while( true ){
> 　　if( it.next()== null ) break;
> ・・・
> }

だから JCFのドキュメント読んでって言ってるのに（ ´Д⊂ヽ

http://java.sun.com/j2se/1.4/docs/api/java/util/Iterator.html

これ以上要素が無い時に next()を呼んだ場合、NoSuchElementException例外が発生します。
よって、上記のコードは期待した通りには動きません。

>>574
ごめんなさい。
今日は疲れました。
また後日お答えさせていただきます。

今回の逝って良しの１のレベルの低さは半端でないねヽ(´▽｀)ﾉ
>>571-582のやり取りは禿しくﾜﾗﾀ

↑なんだかその仕様もクソっぽいね。
Javaerは大変だな。
デザパタにNullパターンって無かったっけ？

あ、↑は>>585のリンク先のことね。

>>プロの逝って良しの１
メンバ関数に見立てたファンクタによる動的継承についてどう思われますか？

>>590
ここで発言が止まっちゃうと、明日の朝が楽しくないので何か書いてもいい?

>>588
>↑なんだかその仕様もクソっぽいね。
> Javaerは大変だな。

だんだん慣れてきます。
毒されてるのかもしれません。＞漏れ

> デザパタにNullパターンって無かったっけ？

ありますね。
UnitTestする時によく使ってます。
スタブとして NullObjectを使うです。
すげー便利です。

>>591
イイんでないの？確かにココで止まると面白くない。

>>588,592
Iteratorの仕様はアレゲだよね。Java使いでも結構賛否両論あってもいいような気がするんだけど、
意外と反論の声が上がらない。

まあ、言葉にするのもなんですが。

OOの真意の一つは、
自分はしょぼくないと思っているプログラマが色々と内容を
いじって欲しくないから閉じ込めたいって所だと思います。

ようは、世の中がほんとにできるプログラマの集団だったら
どんな言語も問題ないわけで。

真にOOを分かってる人々のプログラムは目からうろこが落ちそう。
なんでもいっしょか。

＞で、あるときは for文、あるときは while文となると、
＞コードの一貫性がなくて読みづらいよね。
＞だからオレは常に whileを用いている。
＞これがおれの「forとwhileの使い分け」。

つか、
「繰り返しを実現するには、構造化された方法(whileとか)と、
されていない方法(gotoとか)があるけど、構造化されないのは
読みづらいから、いっつも構造化構文の方をつかってるよ」
ってのは、
「構造化構文 と 非構造化構文を使い分けている」
と言えるのか？
なんつーか、「道は０人の男がいます」的違和感を覚えるﾅｧ

>>590
調査なし、資料なしで書くので間違い、ﾂｯｺﾐどころ満載かと思いますが。

JavaScriptの継承はこのタイプだったよね。
たしか Rubyもこの形式をサポートしていたはず。
使ったことはありませんが、新しくクラスを作らずにオブジェクトの振る舞いを変えれるのは便利そうだなと思います。
その場限りの、ちょっとした振る舞いの違いのために新しいクラスを作成するってことって結構あるよね (ねーか)。

クラスベースでない(プロトタイプベース?)オブジェクト指向言語ではこの形式が標準なのでしょうか?

>>595
>＞で、あるときは for文、あるときは while文となると、
> ＞コードの一貫性がなくて読みづらいよね。
> ＞だからオレは常に whileを用いている。
> ＞これがおれの「forとwhileの使い分け」。
>
> つか、
> 「繰り返しを実現するには、構造化された方法(whileとか)と、
> されていない方法(gotoとか)があるけど、構造化されないのは
> 読みづらいから、いっつも構造化構文の方をつかってるよ」
> ってのは、
> 「構造化構文 と 非構造化構文を使い分けている」
> と言えるのか？
> なんつーか、「道は０人の男がいます」的違和感を覚えるﾅｧ

むむ、forを全然使ってないくせに「forと whileの使い分け」で forが出てくるのがおかしい、ってことでしょうか?


関係ないけど、「つか、」て G某さんに似てる。
気のせい?

for (;;)
ってソースを見ると萎えるんですが。スレ違いですね。

「googleとyahoo？使い分けてるよ。
yahooは検索結果が糞だから使わないけどネ」
「'ゐ'は現代仮名遣いでは全然使いませんね。'い'だけ使います。
よって、私は'い' と 'ゐ' を使い分けてます。 」
ﾊｧ?使い分けてねーだろ、と思わない？

if( 1 ) use(A);
else if ( 0 ) use(Z);
を条件分岐と主張された気分。

「A,B,Cを使い分ける」って「A,B,Cを使っていて、条件により
A,B,Cのうち適切な物が選ばれる」ってことじゃないん？

>>598
ミクロな最適化テクの代表例みたいなもんだな。

まあ、今時のコンパイラならwhile (1)もfor(;;)に置き替えてくれるだろうけど、
昔は「while (1)は1を評価して条件分岐する分、遅い」と信じられていたし、
実際そうなるccが多かった。

>>595
俺は100じゃあないけど、
構造化された制御構造とgotoによる制御構造の違いを理解した上で
構造化された制御構造を採っているのであれば、
それは使いわけていると言えるんじゃない？

なんがほんとミクロなどうでもいい話になってるな・・・

結局プログラミング技法なんてのは制限にすぎない
制限する事によって効率的になる部分と、そうじゃな
い部分や制限内で実現不能になる部分が生まれる。

しかし、制限された世界しか知らなければ、それが世界
だと思っていまう。

　オブジェクト指向も、その世界を知らない事も、その
世界に漬かりすぎてしまう事もどちらも不幸な事だ。

>>602
ハゲ堂。つーわけで、終了ね。

どちらの世界もどっぷりはまった上でOOは糞と思ってますが？

>>604
くせー奴。肥だめにでもはまってたんだろ。

>>604
ハマったけどツカったことはないんですね

>>100
Perlでオブジェクト指向掲示板はいつごろ出来るのかな？

>>607
607が perlで掲示板を作ってからだよ。
あと、perlでOOは正直ｷﾂｲ。

そんな人のためにRubyがあると何度言えば分かるんだ。

>>609
漏れ Ruby好き。
Rubyのイテレータ(もう、そう言わないっけ?)はすばらしい。
あと、Smalltalkも内部イテレータなので萌える。

# ruby
array=["o","m","a","e","m","o","n","a"]
array.each { |item|
puts item
}

"smalltalk"
#('o' 'm' 'a' 'e' 'm' 'o' 'n' 'a') do: [:item|
Transcript show: item; cr
]

やっぱり、外部イテレータよりも内部イテレータの方が楽でいいよね。

過猶不及如

>>602
達人プログラマに「毎年少なくとも1つの新しいプログラミング言語を学習せよ」とありましたね。
ある言語の制限に慣らされた頭をリセットするには、とても有効な手段だと思います。

http://www.pragmaticprogrammer.com/loty/ の機械翻訳。
>毎年少なくとも1つの新しい[プログラミング]言語を学習してください。
>異なる言語は、異なる方法で同じ問題を解決します。
>いくつかの異なるアプローチの学習によって、あなたの思考を広げて
>慣習に差し込まれることを回避することを支援することができます。

ちなみに漏れは、毎年少なくとも1つの新しいプログラミング言語に挫折しています。

>>610
Rubyはよく知らないけど、Smalltalkの場合にはstreamによる外部イタレータもあるね。
| stream |
stream ← 'omaemona' readStream.
[ stream atEnd not] whileTrue: [Transcript nextPut: stream next]

元が配列でなくても、例えばファイルなら
| stream |
stream ← 'file.name' asFilename readStream.
[ stream atEnd not] whileTrue: [Transcript nextPut: stream next].
stream close
とか。
内部イタレータだけでできる事は限られてくるから、
外部イタレータも必要に応じてちゃんと用意しといたほうがいい。

発音は中間だからアレだが、書き言葉だとイタレータってのはちょっと抵抗があったり。

>>613
なるほど、streamは外部イテレータとしても使えちゃうんですね。感動ｼｽﾏﾀ。

> 内部イタレータだけでできる事は限られてくるから、
> 外部イタレータも必要に応じてちゃんと用意しといたほうがいい。

ふむふむ、勉強になります。

>>607
Perlじゃなくてもいいって言ってるじゃん。

#!/usr/bin/perl
@array = ("o","m","a","e","m","o","n","a");
foreach $item ( @array ) {
print "$item";
}

で、これってイテレータなの？イテレータって何？

繰返子

>>618
ﾜﾗﾀ

イッテモータ

逝テレーター 次々に持ってくる奴

スレッドセーフなイテレータは、
イテレータ呼び出しの度に、毎回一から数えなおしている罠

>>617
> で、これってイテレータなの？イテレータって何？

617は内部イテレータっすね。

イテレータの明確な定義を見つけられなかったのですが、私は以下のように認識しています。

イテレータとは「繰り返し処理」を行うフレームワーク。
で、繰り返し処理を行う場合に
- フレームワークの利用者側で「繰り返し処理」の制御を行うのが外部イテレータ
- フレームワーク側で「繰り返し処理」の制御を行うのが内部イテレータ

繰り返し処理に「フレームワーク」という言葉も大袈裟な気もしたのですが、他に良い言葉が思いつきませんでした。
間違っていたらご指摘ください＞識者

>>612
さすがにC++知ってる人が
JAVAとかC#やると３時間くらいで、理解できてしまうというか、
それくらい同じというか。（DELも）
まあ、RUBYもPERLもオートマトン知ってれば、３時間で理解できるし・・・
LISPなんかはもっと早く理解できるよね。
でもprologは、使い道で悩みそうだね。
prologを他の言語から使うのはいいと思うけど、
prolog単体だとしょぼいね。

LOGO厨の俺でも3日でJavaを理解できたぞ

気のせい

なんでオートマトンがでてくんの？
クロージャとかそういう話？

オートマトンだとおお！！！
…(((;ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

オートマトンと言えば・・・・Delphiスレを潰し、ギコ猫を2CHから
追い出したアイツ・・・・

Javaを理解するってなんだか曖昧だなぁ

>>629
えいとおーとぅーのことか？

オートマトン知ってれば、正規表現も習ってるだろ。
オートマトンなんて、まともな大学入ったら
１年か２年の時に習うよ。

じゃぁそこらの大学生に聞いてみ。
オートマトンって何ですか？って。
さーて何人答えられるやら・・・（ｗ

>>624
なっつかさぁ、マージャンできる奴が7ブリッジのルール覚えたからって
すぐに強くなるわけじゃないだろ。
基本は同じだけど､やっぱ違うところはある。まさに同じ問題に別のアプローチで
挑んでいるわけよ。

俺はその言語の「こころ」がわかるようになるには相応の時間がかかると思うよ。

少年サンデーの読者は皆知ってたりする。

つーか、言語仕様を理解することとその言語を使えることには
大きな隔たりがあるということを>>624に教えてやってくだせえ。
さらに、それぞれの言語が仮定しているアーキテクチャで
効率的なプログラムを書けるということもまた別の事だってこともね。

>>634
考えてみればわかると思うけど、
言語って、制御構文＋αなの。
制御構文は、
if/else,while(),breakくらいしかない。

αはOOPLなら継承とポリもーフィズムの実現方法
RUBYとかPERLなら、言語に組み込まれたデータ構造とそのアクセスの仕方
くらいでしょ？

>>637
晒しあげていいでつか？

>>633
うちの大学の情報系の奴に聞いてみてください。

オートマトンについて学べるページってないすかね？

ちょっと違うけど、なんとなくわかると思うので
http://web.sfc.keio.ac.jp/~n96229sh/Research/page1.htm

>>641
おおっ。ありがとうございます。

つーか、セルラオートマトンはまだ工夫すれば面白そうな部分が残ってるけどね、
ただのオートマトンじゃ面白くもなんともねえなあ。

>>643
そりゃそうだけど、コンパイラは使ってる

>>634
×：まあ、RUBYもPERLもオートマトン知ってれば、３時間で理解できるし・・・
○：まあ、RUBYもPERLもBNF知ってれば、３時間で「文法だけ」は理解できるし・・・

普通言語を作る場合って、BNF書いてyacc & lex使うもんだけどな
yaccではオートマトンを使って実装されてるけど、そんなものは
yaccを実装する場合ぐらいしか必要ない。

また、文法を理解しても言語を覚えたことにはならない。
自然言語には言葉があり、プログラム言語にも関数がある。
言語特有の言い回し、慣用句があり、プログラム言語にもある。
君って英語の文法理解したただけで英語を話せるの？

# 英語だと英語でジョークを飛ばせれば、英語を使えると言っていいみたいだけど、
# プログラム言語だと何ができれば使えると言っていいんだろう？

>>623
> 617は内部イテレータっすね。
イテレータということは同意だね。

> イテレータとは「繰り返し処理」を行うフレームワーク。
個人的には
イテレータとは「コレクション（要素の集合を抽象化したもの）」を
操作する手続きを抽象化したものと定義したいな。

ということでOOPLでなくともイテレータは存在する。

>>574
ちょっと質問です。
「複数回コールできるように設計すべき」ってのは、printメソッドの引数に Iteratorを使わない方がいいんでない?、ってことでしょうか?

こんな感じで。

// Omaemona2.java
import java.util.*;
public class Omaemona2 {
static List getList() {
String[] strings = { "o","m","a","e","m","o","n","a" };
return Arrays.asList(strings);
}
static void print(List list) {
Iterator itr = list.iterator();
while (itr.hasNext()) {
System.out.print(itr.next());
}
}
public static void main(String[] args) {
List list = getList();
print(list); // うひょー
print(list); // 何回でも呼べちゃう
print(list); // まじすか?
}
}

>>646
そっちの方がしっくりきますね。

粘着オートマトン馬鹿は去りましたか？…((;ﾟДﾟ)))ﾌﾞﾙﾌﾞﾙ

つーか「オートマトン」という言葉を使いたかっただけかと・・

>>647
うん、だいたいそんな感じ。>>647が書いてるけど、
>イテレータとは「コレクション（要素の集合を抽象化したもの）」を
>操作する手続きを抽象化したものと定義したいな。
…ってコトなんで、引数としてIteratorを渡すのはなるべく避けたいな。俺ならそうする。

あと、くだらん突っ込みをするならprint(List)よりもprint(Collection)の方が良いかと思われ。
どのコレクションに対しても一意の方法でアクセスできるのがIteratorの利点だから、Listだけに
束縛するのは勿体無い。その用例ならIterator使わなくてもList.get(int)で代用できるんだから。
# もちろん、Listにあるメソッドをフルに使うっていうのなら話は別だけど。

>>651
>どのコレクションに対しても一意の方法でアクセスできるのがIteratorの利点だから
それ違うと思うよ・・

イテレーターとは必要なデータを自動的に順番に取り出してくれる仕組みのことです。
カウンタやループ処理のことではありません。

>>651
genericのと混同してるっぽいね。
あれはたまたま。（名前を一緒にしてるのは偶然ではないが）
「一意の方法でアクセス」をイテレータが保証してるってわけでは無いよ。

あうースマソ、勘違いっす。

>言語特有の言い回し、慣用句があり、プログラム言語にもある。
具体例教えて。

>○：まあ、RUBYもPERLもBNF知ってれば、３時間で「文法だけ」は理解できるし・・・
もう一回書き込み読んでね。
正規表現とかが、言語に組み込まれてるPLについての話ね。
もちろん使わなければ、JAVA等と同じだけど。

↑え、、、続けるの？（ｗ

呼んじゃダメ―！！！
奴が来たらこの当たり一帯が火の海に・・・
…(((;ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>656
>>645
そのネタ、もう終わりじゃないの？

>>1って何様でしょうか？

俺はあいたたた氏とは別人です。

改名しますた。

仮想関数なんて言葉も使ったけど、
virtualを日本語化しただけなんだよね。
仮想関数って何？とか思ったら、
継承先で実装しなきゃならんのよね。
もう馬鹿かと思ったよ。
純粋仮想関数なんてもう愚の骨頂だよね。
これ最初に見たときは名前の付け方が
意味不明すぎて笑えたよね。

で、だからなに？

>>664

あなたに言ったわけではありませんので。
何も答えなくていいですよ（ｗ

独り言は余所でやってほしいなぁ。

>>666
じゃあ他所でやってくださいね。

>>663
釣られてみるけど、仮想関数と純粋仮想関数がゴッチャになってると思われ。
「仮想関数って〜継承先で実装しなきゃならんのよね。 」のあたり。

純粋仮想関数とかのネーミングが分かりづらいのは同意。

あーつまらんな。次のネタどうぞ。

>仮想関数って何？とか思ったら、
>継承先で実装しなきゃならんのよね。

もう馬鹿かと思ったよ。

あっと。間違えてたじゃん。
C++なんて最近全然やってないからなぁ。
糞言語には付き合ってられないのよねぇ。

>>669
つまらんつまらんと不平を言うよりも、
進んでオモロイネタを言いましょう。

>>672
うむ、確かにそうだな。ちょっと考えてみる…。
けど、面白いネタって天然やから面白いんじゃねーか？

C#厨が「仕事がねえ〜」って上の方で騒いでますな。

>>662
（自称プロ）の逝って良しの１ よりは
(自称プロの)逝って良しの１ のほうが
"自称プロの" interfaceへのnarrowing type conversionみたいでカコイイぞ！

>>646
つーか、関数型言語なんかの高階関数つかったイテレータって美しいよな。
ひさしぶりにMLやHaskelで遊びたくなってきた。OCamlでも使ってみるか。

>>672
それ聞いたことある。朝のラジオでやってるよね。
ttp://www.tomoshibi.or.jp/top.html

>>574
> いや理屈は分かるけど、実用的ではないと思われ。
> >簡便性のために複数回コールできるように設計すべきかと。
> が俺の意見っす。
> # 好みの問題だ、と言われればそれまでだけど。

メソッドの引数では Listよりも Collectionの方が 汎用性が高いのと同様、Collectionより Iteratorの方が汎用性が高いですよね。
で、Iteratorを使用すべきか否かは、簡便性と汎用性のどちらに重きを置いているかによるわけで、一概にどちらが良いとは言えないと思うんですよ。

ちなみに 541のコードは簡便性も汎用性も求めていない、ただ Iteratorのサンプルを示すためのコードなので
「複数回呼べないのでださい」
と言われてもリンダ困っちゃう。

ここまで書いておいて、こう言うのもなんですが、普段はメソッドの引数には Iteratorはおろか Collectionも使いません。
そのまま ArrayListとか書くことが多いですね。
先を見越して汎用的にするよりも、必要になってから汎用的になるようにリファクタリングした方が楽なんですよね、個人的には。
# けど、Collectionぐらいは使った方がいいかな?

652から 655まで話についていけてないです。
STLの Iteratorとか調べればついていけますか?

>>675
((自称プロ)の)逝って良しの１
の方が汎用性が高い。

>>678
>メソッドの引数では Listよりも Collectionの方が 汎用性が高いのと同様、
Listの方が指定された位置に要素を追加できたりするので、汎用性ではListの方が高い。

> Collectionより Iteratorの方が汎用性が高いですよね。
いいえ、CollectionとIteratorは別物です。

Collectionは要素の集合の抽象化であり、Iteratorは操作の抽象化です。
print()に渡すものは「要素の集合」でしょうか「操作」でしょうか？

> そのまま ArrayListとか書くことが多いですね。
ArrayListはCollectionのサブクラスだよね？
つまり、君はprint()には「要素の集合」を渡すべきだと思っているはず。

>>646
> イテレータとは「コレクション（要素の集合を抽象化したもの）」を
> 操作する手続きを抽象化したものと定義したいな。

今ごろ気付いたのですが。
ここの「操作」、実は「走査」だったりしないですか>646

>>681
> >メソッドの引数では Listよりも Collectionの方が 汎用性が高いのと同様、
> Listの方が指定された位置に要素を追加できたりするので、汎用性ではListの方が高い。
> > Collectionより Iteratorの方が汎用性が高いですよね。
> いいえ、CollectionとIteratorは別物です。

678は書き方まずいっすね。
↓これならどう?

printList よりも printCollection の方がメソッドの汎用性が高い。
また、printCollection よりも printIterator の方がメソッドの汎用性が高い。
なぜなら Collection クラスは iterator()メソッドにより Iterator を生成可能なことを保証しているから。

void printList(List l) { ... }
void printCollection(Collection c) { ... }
void printIterator(Iterator i) { ... }

List list = getList();
Collection collection = getCollection();
Iterator itelator = getIterator();
// list
printList(list); // ○
printList(collection); // ×
printList(iterator); // ×
// collection
printCollection(list); // ○
printCollection(collection); // ○
printCollection(iterator); // ×
// iterator
printIterator(list.iterator()); // ○
printIterator(collection.iterator()); // ○
printIterator(iterator); // ○

// iterator
printIterator(list); // ×
printIterator(collection); // ×
printIterator(iterator); // ○

>>681
> Collectionは要素の集合の抽象化であり、Iteratorは操作の抽象化です。
> print()に渡すものは「要素の集合」でしょうか「操作」でしょうか？

Collectionが「要素の集合を抽象化したもの」は OKなんだけど、
Iteratorが「操作を抽象化したもの」ってのは違うんじゃないかなと思います。

実際に、646では

>イテレータとは「コレクション（要素の集合を抽象化したもの）」を
>操作する手続きを抽象化したものと定義したいな。

とありますし、GoF本の Iterator パターンの「構成要素」(P277)には

>Iterator クラス
>- 要素にアクセスしたり操作したりするためのインターフェースを
>定義する。

とあります。

>また、printCollection よりも printIterator の方がメソッドの汎用性が高い。
なんの話をしてるのか良くわからんけど、
IteratorとCollectionは別物なんだから
汎用性とかの問題じゃないと思うぞ。
そもそもインターフェースに汎用性もくそも無いだろ。
あるなら、比較する基準、つまりどのように汎用性を計量するのかを
教えてくれ。

なんか誤解を含みそうな表現をしてしまったけど、
インターフェースはJAVAでいうinterfaceね。

>>684
http://java.sun.com/j2se/1.4/docs/api/java/util/Collection.html#iterator()

>>681

> > そのまま ArrayListとか書くことが多いですね。
> ArrayListはCollectionのサブクラスだよね？
> つまり、君はprint()には「要素の集合」を渡すべきだと思っているはず。

いえ、思ってません。

print() メソッドで Iterator のメソッドしか使用しないのであれば、
Iterator を渡すべきだとと思っています。
# めんどくさいから必要になるまではやらないけど。

541の print()メソッドが必要としているのは
「要素の集合を走査するためのインターフェース」であって、
「要素の集合」ではないよね。
なぜ「要素の集合」を渡す必要があるの?

>>689
なぜageた？

>>686
> IteratorとCollectionは別物なんだから
> 汎用性とかの問題じゃないと思うぞ。

Iteratorは Collectionからクラスからコレクション走査のための
責務を委譲されている。
文法的に別物かもしれないけど、意味的には Collectionは Iterator を
内包していると考えるのはヘンですか?


> そもそもインターフェースに汎用性もくそも無いだろ。
> あるなら、比較する基準、つまりどのように汎用性を計量するのかを
> 教えてくれ。

ごめん。
インターフェースの汎用性じゃなく、メソッドの汎用性なんです。

比較基準は 683のコードじゃだめかな?

>>690
ｽﾏｿ。sage忘れです。

>>685
> Iteratorが「操作を抽象化したもの」ってのは違うんじゃないかなと思います。
GoF本を持っているならばIteratorパターンは「振る舞い」に関するパターン
ということは分かるはずだ。

そして、オブジェクトの木構造を提供するCompositeパターンを
単純にし、オブジェクトの集合を提供するのがCollection

その「構造」をアクセスしたり操作したりするための「振る舞い」を
提供するのがIterator

よって、CollectionとIteratorには深い関係は存在するが全くの別物

>>680
お！　
イテレーターはgetNext()一本にすべきという私の考えの支持者ﾊｹｰﾝ

イテレータなんぞ知らなくても
ちゃーんとプログラムは作れます。
残念ですね。OO厨のみなさま

イテレーターはＯＯじゃないし・・・

>>693
> そして、オブジェクトの木構造を提供するCompositeパターンを
> 単純にし、オブジェクトの集合を提供するのがCollection

うーん。
ちょっとイメージが湧きません。

Composite パターンの構成要素として
- Component クラス
- Leaf クラス
- Composite クラス
とかがありますよね。
Collectionに関するどのクラスがどの構成要素となるか教えていただけませんか?

イテレータパターンだよ。ﾊﾞｶﾁﾝ

デザパタ＝ＯＯ論でつか？
アフォでつか？

氏らねｰよ。ﾊﾞｶﾁﾝ

ふう。

デザパタ有用っと。

ちんぽも有用だよ！忘れないで！

>>699
その点については完全に同意するよ。
デザパタ自体が建築からの借り物なのを忘れてどーすんだよ。

OOそのものではないが、
OOPL周辺でよく出てくる概念ってあるよね。

C++だと
・コレクション
・ストリーム
・マルチスレッド
とか、Javaだとそれに加えて
・デザパタ
・イテレータ
等々が加わる、と。

そーゆーのって結局、
OOよりもっと基本的なプログラミング上の概念や、
あるいはそれまでプログラミング言語のサポートが足りなかった概念を、
Objectとしてモデリング/カプセル化する事で、
扱いやすくなった(かもしれない)って例なんだろーね。

つう意味で、上記リストへの概念追加をきぼん

>>685

ｺﾞﾒｿ、訂正。
操作じゃなくて、走査です。

>Iterator クラス
>- 要素にアクセスしたり操作したりするためのインターフェースを
>定義する。

Iterator クラス
- 要素にアクセスしたり走査したりするためのインターフェースを
定義する。

>>697
> Collectionに関するどのクラスがどの構成要素となるか教えていただけませんか?
あえて言えばComponentクラスしか無いクラスかな？

というか、JavaでIteratorパターンを構成する要素が
- Aggregate → Collection
- Iterator　→ Iterator
といった方がわかりやすいか？

またデザインパターンでは、IteratorはFirst(),Next(),IsDone(),CurrentItem()
メソッドが定義されてるが、Javaでで相当するのはhasNext(),next()しかない
AggregateのCreateIterator()中でFirst()相当の処理も行い、
Iteratorのnext()中でNext(),CurrentItem()相当の処理を行い、
hasNext()でIsDone()相当の処理を行っている。

これには激しく違和感を感じるし、そんなにメソッドをケチりたかったら
Cみたいにwhile((c = getc(fp)) != EOF)と書けるように
while((obj = itr.getNext()) != itr.IsDone())と書けるようにすればいい
プロの逝って良しの１が大喜びするぞ。

>>706
>>> そして、オブジェクトの木構造を提供するCompositeパターンを
>>> 単純にし、オブジェクトの集合を提供するのがCollection
>>
>> うーん。
>> ちょっとイメージが湧きません。
>>
>> Composite パターンの構成要素として
>> - Component クラス
>> - Leaf クラス
>> - Composite クラス
>> とかがありますよね。
>> Collectionに関するどのクラスがどの構成要素となるか教えていただけませんか?
>
> あえて言えばComponentクラスしか無いクラスかな？

???

>>706
> またデザインパターンでは、IteratorはFirst(),Next(),IsDone(),CurrentItem()
> メソッドが定義されてるが、Javaでで相当するのはhasNext(),next()しかない

まあ、そのまま使わなきゃダメってわけじゃないですからね＞デザインパターン
常識的な変更の範囲内だと思います。


> またデザインパターンでは、IteratorはFirst(),Next(),IsDone(),CurrentItem()
> メソッドが定義されてるが、Javaでで相当するのはhasNext(),next()しかない
> AggregateのCreateIterator()中でFirst()相当の処理も行い、
> Iteratorのnext()中でNext(),CurrentItem()相当の処理を行い、
> hasNext()でIsDone()相当の処理を行っている。

確かに next() は少し微妙な気はします(少しね)。
けど、コンパイラの本とか読んでるとよく登場するので、
Javaの Iteratorだけが特殊だというわけじゃないみたいです。


> これには激しく違和感を感じるし、そんなにメソッドをケチりたかったら
> Cみたいにwhile((c = getc(fp)) != EOF)と書けるように
> while((obj = itr.getNext()) != itr.IsDone())と書けるようにすればいい
> プロの逝って良しの１が大喜びするぞ。

getcと違って next()ではどんな値でも来得るので(もちろん -1(*)や nullも)
EOFに相当する値を定義できないですよね。
なので、hasNext()のは必須でしょう。

(*) new Integer(-1)

＞Objectとしてモデリング/カプセル化する事で、
＞扱いやすくなった(かもしれない)って例なんだろーね。

「ライブラリのコードを並べてるだけ」をカッコ良く言うとそうなるのか（ｗ

アホどもがいつまでも同じ話題で盛りあがってるな。

>>100=アホの代名詞

>>711
使えない奴は放っておいて俺たちのような使える奴だけで話しすすめようぜ

光あるところ影がある。
まことの栄光の陰に数知れぬＯＯの姿があった。
だが人よ、名を問う無かれ。
闇に生まれ闇に消えるそれがＯＯの運命（さだめ）なのだ。

>>713
ＯＯのところはいろんな言葉があてはまりますね(w
もちろんOOだってことはわかってますが　テンプレートかな

OO：ObjectOrientedの中傷クラス

うちの部署では構造化チップででOOを実現している。

プロの逝って良しの1が入ると議論が破綻するな

>>711
どのへんがアホかご指摘願えませんか。

ほんとに構造化だけでやってる奴このスレにいるのか？

>>719 OOPLは使うけど構造化の精神を貫いております

このスレの住民はレベルが低い奴しかいないな。
参加するのは止めとこう。

>>721
レベルが低いからいいんだよ。
中にはｷﾗﾘと光る発言もあるしさ(漏れのではない)。

よいしょ。

Object Compositionっと。

下がり過ぎあげ

>>719
ＯＯマンセー派の大部分がそうですが何か？

>>719
キミはどんな小さなアプリでもクラス設計から始めないと気が済まないのかい？

>>721
2度と来んなよ。

Classクラスのオブジェクトはクラスなのかオブジェクトなのか・・・

初心者さんが沢山いる様で・・

初心者しかいませんが何か？

>>727
アホですね。

>>725
まぬけ

>>727
言語や環境によるが、Classクラスを提供しているようなOO言語/環境であれば
そのインスタンスもオブジェクトだが、それがどうかしたのか？
そもそも、この手のメタタワーなモデルはOOよりもLISPのほうが歴史が長いのだが。

メタレベルとオブジェクトレベルっていう議論を
回避するために型理論ってあるんじゃないの？

つーか、Smalltalkの階層構造では、下図のよーにぜーんぶオブジェクト

　Object
｜　　　↓
｜　　　　MetaClass
｜　　　　　　↓
｜　　　　各クラス
↓(instance)↓(super)
各インスタンス

>>732
LispでReflectionてな話って、どのあたりでしぉうか？
Lisp3 とか？

スマソ、間違えた

　Object
｜　　　　↓(instance)
｜　　　　　MetaClass
｜　　(super)↓↑(instance)
｜　　　　　Class
｜　　　　　　↓(instance)
｜　　　　　各クラス
↓(instance)　↓(super)
　各インスタンス

てな感じで、Metaclass階層をinstance of と super で循環定義してるんだっけ？

>>736
へえ、smalltalkってそうなってるんだ。
それだとC++からのアナロジーで考えることを当然のこととしてると
分かりにくいね。こんどsmalltalkを勉強してみます。

>>735
とりあえずevalがLispで実装されてればメタサイクリックじゃないか？

>>737
Smalltalkでのクラスはインスタンス変数やインスタンスメソッドを持っている部分と
クラスインスタンス変数(C++のstaticメンバに相当)やクラスメソッドを持っている部分に
わかれていて、それぞれ別のオブジェクトになっている。
ここを見誤ると混乱する。
たとえばObjectクラスのインスタンス担当部分はObjectで
クラスメソッドなどを持っている部分はObject classというオブジェクト。

また、Smalltalkではオブジェクトにclassというメッセージを送ると、
そのオブジェクトのクラスインスタンスを返してくれる。

1 class → SmallInteger : Objectのサブクラス
SmallInteger class → SmallInteger class : Classのサブクラス
SmallInteger class class → Metaclass
Metaclass class → Metaclass class : Classのサブクラス
Metaclass class class → Metaclass
下2つでループになってる。

なお、ClassとMetaclassは共にBehaviorのサブクラスで、
BehaviorはObjectのサブクラスになっている。

Object class → Object class : Classのサブクラスであり、また、Objectのサブクラスでもある。

VB.NET使って、継承やらオーバーロード、オーバーライド、
クラスライブラリやら使えるが、
当然VBAでは使えん。鬱だ。

うーん、Behaviorクラス忘れてましたぁー。
あと、Metaclass や Classにもclassありますよねぇー。
＃所で、上記の式で Classそのものが出てこないのはどしてでしょうか？superしないとだめ？

＃いずれにせよ、>>734 も >>736 も、ｶﾅｰﾘ恥ずかしい図面だ。
＃↓super は、 ↑superか↓subclassのまてぃがいだし、
＃Class と Objectの峻別忘れてMetaclass語ってるし。

>>738の情報をまとめると、こんな感じかな。
(ﾒｯｾｰｼﾞclassでｲﾝｽﾀﾝｽ関係━、ﾒｯｾｰｼﾞsuperでｻﾌﾞｸﾗｽ関係─を追っかけるとして)

　　　　　　　　　　　ｻﾌﾞｸﾗｽ
　　　　　　　─────→
　　　Object←━━━━━Object class
　　　　││　ｲﾝｽﾀﾝｽ　　　　 ↑ｻﾌﾞｸﾗｽ
　　　　││　　　　　　　　　　 │　　ｻﾌﾞｸﾗｽ　　　　　　　　　　　　　　　　ｻﾌﾞｸﾗｽ
　　　　│└─────────→Behavior　　　　　　　　Class class━━→Metaclass class
　　　　│　　　　　　　　　　　　│┏│━━━│━━━━━━━┛　　　　　　　　 ┃↑ｲﾝｽﾀﾝｽ
　　　　│　　　　　　　　　　　　│┃│　　　　 │┏━━━━━━━━━━━━━┛┃　
　　　　│　　　　　　　　　　　　│┃│　　　　 │┃┏━━━━━━━━━━━━━┛
　　　　│　　　　　　　　　　　　│↓↓ｻﾌﾞｸﾗｽ↓↓┃ｲﾝｽﾀﾝｽ
　　　　│　　　　　　　　　　　　Class　　　　Metaclass
　　　　│ｻﾌﾞｸﾗｽ　　　　　　　　　│　　　　　　┃
　　　　↓　　　　　ｲﾝｽﾀﾝｽ　　　　↓ｻﾌﾞｸﾗｽ　↓ｲﾝｽﾀﾝｽ
　　SmallInteger←━━━━━SmallInteger class
　　　　┃※ｲﾝｽﾀﾝｽ定義　　　　　　　　※ｸﾗｽ定義
　　　　┃
　　　　↓ｲﾝｽﾀﾝｽ
　　　　1

ところで、Smalltalk80って、多重継承なしだから、
「２種類のｸﾗｽのｻﾌﾞｸﾗｽ」(例:Object class)っつう事は、
どっちかのｸﾗｽはもう一方のｻﾌﾞｸﾗｽなんだよね？
つう意味で、上記の図面はまだ誤りがある。

Smalltalk80の原理原則
「全てがオブジェクトであり、
　全てのオブジェクトはクラスのインスタンスであり、
　全てのクラスはClassのサブクラスである」
は美しいけど、
それを実装すると上の図みたいに複雑になるわけで、
Smalltalk80作った人々はこの複雑さをどう捉えたんだろうね？

>>734
解説どうもありがとう。
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/S4-5-4_1.html
ここなどと照らし合わせて勉強してみます。

class と super の二元論で全てを記述しようとしたのが、
構造の複雑さの原因じゃないかな？

んで、flavorとかinterface追加してみたり(flavor, Objective C)、
classとsuper以外の、多種多様なObject間相互作用を考えたり(デザパタ)、
classオブジェクトを無くしてみたり(C++)、
プロトタイピング・ベースのOOPL作ってみたり(Self,Squeak Morph,JavaScript???)
したんでしょ

言い方逆かもね。

classとsuperで、シンプルな世界を実装したらsmalltalk80になりますた。
概念が未整理で、実装基盤も不充分な現実世界で、OOしようとしたら、
classとsuperで寄木細工の閉じた世界作ってる暇がないんで、拡張しよう。

ってな感じ

ふう。

ここはStratege patternで組んでと。

>741が複雑？
どこが？

>>741が複雑？
>どこが？

こんな事言いながらOO厨は保守でｋないコード量産するんだよな。

>>747
循環定義でオナニーしてしまうくせがあるよな＜学者さん

>>747
　>>744-745という事だよ。

ちなみに>>741は、
その昔オブジェクト指向LISP(Dylanの人のヤツ)を、
Smalltalk風OOPLに拡張した時の階層に近くて、
当時も今もBehaviorやClassDescriptorの機能をよく知らなかったりする(藁

誰か解説きぼん

メタクラスは関数型言語のカリー化のオブジェクト版って事よ。

意味が全く分かりません。

皿仕上げても（・∀・）ｲｲ？

>>752
全然違うだろ。

>>752
全くその通り。

わざわざカリー化しなきゃならないのはダサイ言語。

理解できてないﾔｼ(＝アンチFP)がたくさんいる。

久しぶりにghc入れてHaskellの勉強でも再開しようかな・・・

>>752
酔っ払った勢いで、無理矢理介錯してやる。











只今考え厨

例えば、高階関数＝状態の畳み込み、と考えて、
meta instance ＝ class
class instance ＝ object
-------------------------
meta instance instance = object
みたいなのを考えてるのｶﾅｰ

カリー関数→...関数→最終的な出力(オブジェクト)
メタクラス→...クラス→インスタンス(オブジェクト)
ってことでしょ？

instanceはclassの逆関数だけど、追加の引数(class定義やobject定義)が必要な罠

何逝ってんのかサッパリ………？？？

初心者＆厨房の追い出しには成功したな

ただいま厨房によるパトロール中・・・

はーい
厨房が通りますよ
道を空けてね

クラス型オブジェクト指向はその基礎に重大な矛盾を孕んでいることが判明
と理解して良いですか？

>>767
何言ってんの？

>>768
日本語読めないんですか？

>>769
読めるよ

つーか、>>767だけじゃ会話になってないと思われ。
独り言ですか？

>>767
では"重大な矛盾"とやらを具体的におながいします。

Class クラスがクラスだかインスタンスだか判らない点

>>773
Classクラスはクラスでしょ。Object#getClassで返ってくるのは
Classクラスのインスタンス。

どこがわからない? もしかしてメタクラスって理解できない?

メタクラスもクラスもインスタンスも流動的で、
特に区別されないところがキモだと思うんだが。
これは使ってみないとわからないか。

>Class クラスがクラスだかインスタンスだか判らない点
いや、クラスだって分かってるじゃん…「Classクラス」って言ってるんだから。
俺はこの発言の意図の方がよっぽど分からん。

>>773
Metaclassのインスタンスはクラスでありかつインスタンスでもある。
すなわちClassクラスはクラスでありかつインスタンスでもある。
何の不思議もないけど。

結局、メタ循環から木構造に落す時にどれを根として扱うかということでしょ。
Object → Class(のサブクラスであり、かつObjectのサブクラス) → Metaclass(Objectのサブクラス)
という循環をObjectを中心に見るか、それともClassを中心に見るかという問題で、
Objectを根にすればSmalltalk的な「何でもオブジェクト」な言語になるし、
Classを根にしてObject以下の階層と分離すればC++的な「クラスはオブジェクトじゃない」ような言語になる。
あるいはObjectを根にしてMetaclass以下を省略すればPythonのような「クラスもオブジェクトだが、クラスのクラスは存在しない」言語になる。

それぞれ長所も短所もあるわけだけど、Smalltalk的な「何でもオブジェクト」が複雑とは思えん。
むしろ、「これはオブジェクトだが、これはオブジェクトではない」のほうが複雑だと思うが。

>>773
ところで、Classクラスっていうけど、どの言語でのClassクラスの話なんだ？

SmalltalkのClassクラスであれば、Classという名前のオブジェクトなのか、それともClassという名前クラスなのか。
Classという名前のオブジェクトであれば、それはクラスでありかつClass classのインスタンスだ。
Classという名前のクラスであれば、それはクラスでありかつMetaclassのインスタンスだ。

Smalltalk80だと、grobalにClassというクラスがあるんで、Classというオブジェクトは存在し得ない。

>>779
Smalltalk-80だと、
globalにClassというクラスがあり、
そのインスタンスメソッドなどを管理したりインスタンス生成をおこなう
Classというオブジェクトが存在します。

あれ、dictionaryの空間分かれてるんだっけ？Class dictionary？

>>743の図面が判りやすいんで、AAこぴぺ

http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/img/metaHiera9.gif

　　　　　　　　　　　　　　┌───┐　　　　　　　　 meta┏━━━━━┓
　　　　　　　　　　　　　　│Object├…………………→┃Object class┃
　　　　　　　　　　　　　　└─△─┘　　　　　　　　　　　 ┗━━△━━┛
　　　　　　　　　　　　　　┌─┴──┐　　　　　　　 meta┏━━┷━━━┓
　　　　　　　　　　　　　　│ Behavior├………………→┃Behavior class┃
　　　　　　　　　　　　　　└─△──┘　　　　　　　　　　 ┗━━△━━━┛
　　　　　　　　　　　┌───┴────┐　 meta┏━━━━┷━━━━━┓
　　　　　　　　　　　│ ClassDescription ├……→┃ClassDescription class ┃
　　　　　　　　　　　└───△────┘　　　　 ┗━━━━△━━━━━┛
　　　　　　　　　　　　　　　　　│　　　　　　　　　　　┌────┴──────────────-┐
　　　　　　　　　　　　　　　　　├────────|─────────┐　　　　　　　　　　　　　　 │
　　　　　　　　　　　　　　┌─┴─┐　meta┏━━┷━━┓　　　 ┌──┴──┐ meta┏━━━┷━━━┓
　　　　　　　　　　　　　　│ Class ├……→┃Class class┃　　　 │ Metaclass ├……→┃Metaclass class┃
　　　　　　　　　　　　　　└─△─┘　　　　┗━━━━━┛　　　 └─────┘　　　　 ┗━━━━━━━┛
　　　　　　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　↑meta↑meta
┌────┐　meta┏━━┷━━━┓　　　　　　　　　　　　　　　　 ：　　　　：
│ Object　├……→┃Object class　┠……………………………┘　　　　：
└─△──┘　　　　┗━━△━━━┛　　　　　　　　　　　　　　　　　　　　 　：
┌─┴──┐　meta┏━━┷━━━┓　　　　　　　　　　　　　　　　　　　　　 ：
│Account ├…･･→┃Account class┠……………………………………･┘
└────┘　　　　┗━━━━━━┛

sinu

>>781
Smalltalk-80では"Class"というクラスは
"Class"と"Class class"という2つのオブジェクトによって実装されているという話。

だから、Smalltalk-80のクラスライブラリにはClassというクラスが存在すると同時に
Classという大域変数とそれによって差されるClassというオブジェクトも存在する。
そしてそのClassという大域変数で差されるオブジェクトと、
大域変数では差されていないが"Class class"というメッセージ式で得られるオブジェクトが、
クラスライブラリ上の"Class"という名前のクラスを構成している。

上記図面で Account, Object, Class の各Objectは、
それぞれ Account class, Object class, Class classの各クラスのSingleton であり、
インスタンス・オブジェクト作成はサブクラス任せにするFactoryMethodパターンでもある
と言えそうですね。

さて、と。

次の問題は、クラス・ベースのOOPLのやり方を、
実行時にクラス・オブジェクトを持たないOOPLで
いかに実現するか、ですね。

落ちが無いし・・・

え？

もしかしていまとなってはスモールトークユーザーってRubyよりすくない？

ふう。

ここはSingleton�dっと。

日本でSmalltalkの需要なんてまずないのでは。
研究関係はよく知らないけど。

でもこの前ジョブズがSmalltalkのサブセット子供に教えてたよ。

Smalltalkerから言わせるとC++やJavaのオブジェクト指向は糞ですか？

いと懐かしきかな純準論争。

>>768
クラス・ベースOOPLと、クラス・オブジェクト無しOOPLのマッピングかよ！
ＯＯって、マッピングが多いなぁー
＃オブジェクト・リレーショナル・マッピングとか、
＃ＭＤＡでも標準マッピングの嵐らしいし…

OOPLあらため、マッピング指向言語って呼んでも（・∀・）ｨｨ？

誰か、型理論とZFC集合論のマッピングをしてくれんかのぅ。

>>791
ジョブスは変態です。
他にも小さい子に悪戯にLispを教えるのです。

教えるんじゃなくて喋ってるだけだろ。ただの自己満足じゃん。

ZのツールでGPLライセンスのものはありますか？

ハァ？

　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　800げっとぉぉぉ〜♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは〜っ、800ｹﾞｯﾄ〜！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 〜〜　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;

　　　　　　　　　　　　 ＿ _　　　　 / ）
　　　　　　　　　　 〃┏━━ 、／ フ
　　　　　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　やった〜♪
　　　　　　　　(＼／|」~　　~|」／)
　　　　　　　 ヽ／, ｲ/￣￣　i／）
　　　　　　　＜／ヽ| 　 　　　i／
　　　　　　 (_ノ　 　レ'⌒i 　 |
　　　　　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 　　　　(＿|＝|).､　 ＼
　　　　　 　　　　　　_|(　 | 　>　　）））
　　　　　　　　　　／ Ｏし'Y==_／
　 　 　　　　　 　/ ＼ | ／ii／
　 　　　　〜〜　|l─-0-─||
　 　　　　　　　　!　　ﾍへ !!ﾍ　 プチｯ
　　　　　　　 r'´⌒⌒ ヽ彳# ７
　　　　　　⊂(（(ﾊ)）⊂〃＿〃つ ﾆﾊｶﾞｫｸﾞｹﾞﾎﾞｯ

>>794
ねえ、君、クラスベースOOPLってどういう意味で言ってるの？
普通はクラスがオブジェクトであろうがなかろうがクラスという概念があればクラスベースOOPLなんだが。
例えばC++も普通はクラスベースOOPLと呼ばれる。

文法レベルでの直截的なサポートがない場合でも
クラスという概念を使ったコーディングが可能と言い張れば
クラスベースOOPLなの？

ごめん、クラス・オブジェクトを持つOOPLと読み替えてくれ。

↑は>>794の訂正。言葉使いが適当でスマソ。

ところで、数日前から議論が初級Smalltalkみたいな所で頓挫してるのはﾅｾﾞ？

ﾔﾊﾟｰﾘ２ちゃんでは、言葉尻を捕らえた不毛な議論しかできないのｶﾅｰ？

ぁーあ。

次の課題は、クラス・オブジェクトを持たないOOPLのメリット/デメリット
の検討、ですね。

その次の問題は、クラス・オブジェクトを持つOOPLのやり方を、
実行時にクラス・オブジェクトを持たないOOPLで
いかに実現するか、ですね。

そのまた次の課題は、クラス・ベースでないOOPLのメリット/デメリット
の検討、ですね。

って感じで、12時間位でちゃっちゃと進まないのかな

>>807
＞の検討、ですね。
はぁ？課題？
検討？
ここ何処だか知ってる？

最近電波な人多いね

オブジェクト恥垢初チン者が、入門書の中身をえらそーに講義してるスレッド。

>>809
君ほどじゃないよ。理系のど真ん中で、電波電波って、恥ずかしいったらありゃしない

ﾌﾟﾛﾌｪｯｿﾅﾙな人は、>>807のテーマでもあくびが出る罠

>>812
3点

>>807
OOPLにおいてクラスが1st class objectでない事の
メリット: 実行時メモリの節約
デメリット: クラスを変数やパラメータとして渡せない

クラスが1st class objectでないOOPLにおいてクラスを1st class objectとして扱う方法
プロトタイプ・パターンを使う

クラスベースでないOOPLの
メリット: 比較的簡単に多種の振舞いを持つオブジェクトを実行時に生成できる
デメリット: method dictionaryのオーバーヘッドが(時間、空間共に)大きくなりやすい

おっと、
> クラスが1st class objectでないOOPLにおいてクラスを1st class objectとして扱う方法
> プロトタイプ・パターンを使う

ここはプロトタイプ・パターンを使ってもいいんだけど、
1st class objectでないFooクラスに対応してFooClassクラスを作って、
そのsingletonをFooクラスに対応させてもいいな。

プロトタイプ・パターン、ですか？

　http://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/gof/prototype.html

慎重に検討した事がない解ですたので、
ちょっと考えさせて下さいです。

>>1->>816
おまいら、わかったからさ、はやくOOでOS作れよ

>>817
すでにLinux、WindowsがOOで作られてるじゃん。

>>818
ネタにもなんねー

　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　820げっとぉぉぉ〜♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは〜っ、820ｹﾞｯﾄ〜！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 〜〜　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;

抽象クラスなんぞ必要ない。
インターフェイスで十分。
それがわからんOO厨の多いこと多いこと。

なぜ？>>821

　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　823げっとぉぉぉ〜♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは〜っ、823ｹﾞｯﾄ〜！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 〜〜　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;

816です。>>816の行間、伝わったかなぁー？

　　　　　　　　 ＿ _　　　　 / ）
　　　　　　 〃┏━━ 、／ フ
　　　　　　 |　 ノﾉｿﾊ)））　／
　　　　　　 リﾘ ´∀｀）ﾘ／　　＜　825げっとぉぉぉ〜♪
　　　　(＼／|」~　　~|」／)
　　　 ヽ／, ｲ/￣￣　i／）
　　　＜／ヽ| 　 　　　i／
　　 (_ノ　 　レ'⌒i 　 |
　　　　　　 （__|　 |　 ＼　ｷｺｷｺ
　　　 　 　 (＿|＝|).､　 ＼　　　　　　　　　　　にはは〜っ、825ｹﾞｯﾄ〜！
　　　　　 　　_|(　 | 　>　　）））　　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣
　　　　　　／ Ｏし'Y==_／　　　　　　　　　　　　　　　　　　　　ﾍへ
　 　 　 　/ ＼ | ／ii／ 　　　　　　　　　　　　　　　　　r'´⌒⌒ ヽ彳
　 〜〜　|l─-0-─||　　　　　　　　　　　　　　　　　　(（(ﾊ)）)）》 ）　へ　　　　　　　 　(´´
　 　　　　!　／| ＼ !!.　　　　　　　　　　　　　　　　　　||´∀｀ l| /|⌒ ７　　　　　　　(´⌒(´
　　　 　　ヽ　 .|　　/　　　　　　　　　　　　　　　　　　⊂∨†⊂〃＿〃つ≡≡≡(´⌒;;;;≡≡≡
　　　　　　　ﾞ ー " 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒(´⌒;;

>>821
> 抽象クラスなんぞ必要ない。
> インターフェイスで十分。
抽象クラスがあったほうが楽にできるケースもある。
そんなことを言うんだったら
「swich文など必要ない。if-elseで十分。」とも言える。

>>822
（821が）坊やだからさ。

>>821
面倒だから、お相手しません。悪しからず

>>827
すでに相手しちゃってるじゃん(藁

(実装)継承に頼るのはよくないぞ。>OO厨。
確かに実装継承はコードを書く手間も省けるし、
インターフェイスも同時に継承できる。
しかし、OOのポリモーフィズムやらは
インターフェイスの継承によって
実現していることを忘れるなよ。
俺の愛の忠告を受け取れ>>OO厨

（´-｀） .｡oＯ（誰も相手してないのに、どうしてそう熱く騙れるんだろう…）

インターフェースの向こう側にAOPがありそうだと直感してしまった今日この頃♪

>>831
> インターフェースの向こう側にAOPがありそうだ
Cloneable, Runnable, Serializableなどの〜able系インタフェース
AOPを使えばこれらが一掃されそうな予感がする

はっきり言って、〜able系インタフェースは動詞を無理矢理名詞化して
クラスらしく見せかけているような胡散臭さを感じる。

ＡＯＰ：アナルおまんこプレイですか？

>>832
捻りすぎでよくわかりませんでした。

つか、>>831で言いたかったのは、概略次のような事。
インターフェース：既存のオブジェクトの型の一部分のみを取り出して、
　　　　　　　　　継承(型の包含関係)を柔軟に実現するためのもの。
AOP:　　　　　　　既存のオブジェクトの機能の一部を取り出したり、
　　　　　　　　　あるいは既存のオブジェクトに一部機能を追加して、
　　　　　　　　　クラス(やインターフェースｗ)とは違う切り口で、
　　　　　　　　　実装(ソースコード)を再構成するためのもの。
として。
AOPが既存オブジェクトから部分的に切り出したり追加したりする機能というのは、
インターフェースが既存オブジェクトから切り出す部分型と、結構似ているのではないか、と。
すると、実装を切り捨て、型の包含関係のみを議論するインターフェースよりも、
実装方法やソースコードを前提に、型の再構成をするAOPの方が、より有用なのではないか、と。

＃OOA/OODだと、概念モデルがインターフェースに相当するわけだけど、
＃ここでは実装ﾏﾝｾｰで、実装の観点からのみインターフェースを見てますです。
＃でも、AOPって実装がある程度進んだ段階で有用な手法みたいだから、
＃インターフェース：上流工程で概念モデルと実装を結び付ける手段
＃アスペクト：　　　下流工程で実装を整理する手段
＃みたいな感じで、現時点では対象的なのかな〜。(AOAとかAODとか出てきたりして(w))

>>833
交互なの？

ふう。


ここはTemplate Methodパターンを使って、と。

>>835
やる前にちゃんと洗浄する。
Ａ→Ｏ→Ａ→Ｏ→Ａ→Ｏ

>>836
テンプレート使ってるだけだろ？

>>834
AOPのメリットはわかったけど、
デメリットは何なの？

OOもメリットがある反面、デメリットがあるわけだけど
そんなのはわかってるものと信じて話を進める事にする。

それがわかってないOO厨ばっかりだからこそ、
このスレがあるんじゃん。大丈夫？>>839

>>839
バカ(840)は気にするな。

>>839
バカ(841)は気にするな。

実は俺、クラシックファンぶってるけどマジでアニメファンです。
アニメージュ毎月買って読んでます。
部屋のミケランジェロの絵の裏には
カードキャプターさくらのポスターが貼ってあります。
「モーツァルト歌劇」のラベル貼ってあるビデオの中身は
全部カードキャプターさくらです。
人にはモーツァルトファンってことにしてあります。
でもモーツァルトなんかより、カードキャプターさくらの
主題歌聴いてる方が落ち着くんです。
クラシック界はこの先どうなっていくのかを
クラシック友だちと真剣に語り合ったりしてますが、
本当はさくらたんの個々のアニメの回の出来について
真剣に議論したいんです。
コミケにも毎回行ってＣＧ集も売ってます。
　　　真面目ぶってるけど、さくらたんと知世さまのワレメが大好きなのです。
あ、モーツァルトもそれなりに好きですよ。
でももちろんさくらたんの主題歌のほうが好きですけどね。
　　　これからも幼女のワレメ萌え萌えな絵を描いていくつもりですので応援してください。
　　　描いて欲しいキャラなど要望ありましたら
　　　http://www.coara.or.jp/~yoshioh/までよろしく！

つまり、現代社会というオブジェクトから、病根というアスペクトを切り出すと>>843になり、
個別のインターフェースはアニメファン、ロリという事なのだろうな
＃そーじゃなかったら物故ろす！

未実装の抽象クラスは　クラシックファン　のあたり

…で？

AOPが注目されているのは、OOPの弱いところを補完できるから。
だからAOPのデメリットは、「それだけじゃシステムが組めない」こと。

確かに、一般論過ぎて、
ＯＯに別の言葉を穴埋めしたくなるな(ｗ

>>848が注目に値するのは、>>847の弱いところを補完しているから。
だから>848のデメリットは「>>848だけではツッコミ漫才をできない」ことだ。

AOP唱えてる奴は、OOもわかってるんだと思ってね。
OOのデメリットは、まともなOO本ならちゃんと記されているので、
厨房な方々はそちらを参照してください。

>だからAOPのデメリットは、「それだけじゃシステムが組めない」こと。
俺の言い方が悪かったのか、コミュニケーション能力が足りないのか
あるいはバカなのかはよくわからないけど、
AOPを導入した場合のメリットと、導入した場合のデメリットを
「具体的」に書いてねって事。
それがわからないと、AOPのどこを評価していいのかわからない。

サクラ大戦ってなに？

どうせＡＯＰＬとか出てきて
ＡＯＰＬで書いてるからＡＯＰだろ！
つうのが（略

クラスオブジェクトって実行時に必要だろうか？
それならSelf的な(真の意味で)全てがオブジェクトという方が綺麗な気がするけど。

>>853
気がする理由を考えないと、気のせいで終わっちゃうぞ。

おまえらさぁ、ちゃんとjavaとか使い込んだ上でいってんのか？
馬鹿ちやう？馬鹿？え？俺？そうだよ。あぁ。明日な。
いや、違うって。だからあの娘とは関係ないんだって。
え？もういい？ちょっとまてよ。え？え？
その話はまた今度ゆっくりしよ。な？な？なぁぁぁぁぁぁぁぁ！！！！！！！！！

理解の基盤が違うようですので、議論が成立しそうにありませんね。(苦笑

（°Д°)ﾊｧ？

（ﾟДﾟ;)ﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧﾊｧ､ｳｯ

>>855
俺はOOﾏﾝｾｰ派だけど、OO使い=Javaが使えないとダメ、なんて短絡的発想しか出ない馬鹿はすっこんでろ。

JavaOneが今年も開かれます。
生贄の少女から生きたまま心臓を引きずり出し、皆で生き血を飲むという野蛮な
儀式が今年も行われるそうです。
http://servlet.java.sun.com/javaone/

>>853
Selfって書きたいだけだろうと(略)
SPARC版Self触った事ないだろうと(略)

JavaなんてOOじゃない。本物のOOはFB

>>860
残念ながらそれが文化です。
日本だけに引き篭もってるから好きなことが言えるのです。

>>859
ＯＯＰは組み込み分野でこそ発揮されるべきだ！

Java 高速GUI SWT
http://pc3.2ch.net/test/read.cgi/tech/1032448424/
SWTはJavaでOSのネイティブAPIを直接呼び出し、高速に動作する
GUIツールキッドです。


つうか、回りくどいこと止めてＣで組め。
んでＣからＪａｖａのＡＰＩ呼べるようにした方が率直だろうが

たしかにそうだ（ｗ
GUI全部Cで作って
ソケットでデータやり取りしてろって

だいたい、トチ狂って「呼び出す」なんて書いちゃってるしな。
「メッセージを送ると自立的に動作する」んじゃなかったのか（藁

>>865
ん、なんで？CからJavaのAPIを呼ぶ必要性なんて皆無だと思うけど？
Javaと違って本当の意味で「何でもできる」んだから、わざわざJavaのAPIなんか使う必要ない。
# もしJavaの便利なAPIが使いたいっていうのなら、JavaのAPIを使うよりも
# 用途に合わせたCのライブラリを使う方がずっと良いしスマートだよね。

遅いのをカバーするためにより下層のAPIやライブラリとかを使うのは普通のアプローチじゃないか。
Cが一部でasmを使うように、Javaがnativeを使ってもいいはず。

>>866
なんでソケット通信？SWTのアプローチの方が自然だし(おそらく)パフォーマンスも良いよ。
実装もはるかに簡単だし。

>>867
「メッセージを送ると自立的に動作する」ってのがこのスレのどっから出てきたか知らんが(検索したけど分からん)
それはOOで設計なり実装された場合であって、下層のnativeは当然OOじゃないよね。だから「呼び出す」とい
う表現は正しいと思う。


# もっと勉強してOO派を何とかしろよ。
# OO反対派だけど、ハッキリ言って見てられない。＞逝って良しの１やその他諸々。

>>868

>なんでソケット通信？SWTのアプローチの方が自然だし(おそらく)パフォーマンスも良いよ。
>実装もはるかに簡単だし。

疎結合にしてGUIの実装側を楽にした方が何百倍もマシということだろ

>>868
オブジェクト指向では関数呼び出しの事を「オブジェクトにメッセージを送る」
などとほざくのです。

>>867
メッセージを送ると自律的に動作するのはエージェント指向と思われ。
もっとも一言でエージェント指向といっても粒度によって色々あるけど。

オブジェクト指向の場合は自律性よりも相互作用のほうに重点が置かれてるだろ。

>>870
ソースキボンヌ。もちろん君の脳内妄想以外の。

OOPLによるWindow systemハンドリング方法の変遷を、
仮に、

1)Window systemをグラフィックシステム上にOOPLで直接記述:
　　Smalltalk
2)Window widget/component簡易wrapping:
　　Java AWT, little smalltalk
3)既存のwindow systemにbitmap貼り付けて、軽量widget/component:
　　Java Swing, Dynamic HTML, Linux系WindowManager (KDE, GNOME)
4)特定環境固有のWindow system wrapping
　　MS SDK Java(J++)

ってな感じに分類できるものとすると、
SWTって、4)に近いの？それとも、5)新しい手法になるの？

＃OS〜Windowシステム周辺のOOPL primitive を、
＃OS記述言語で記述するって当たり前の議論に見えるが

簡易ラッピングじゃなくて、
本格的なラッピング

社会主義市場経済みたいなもん。
Write Once Run Anywhereの原則に反する。
自己否定に近い。

>>868
865の意図した事は
複雑な部分をJAVAで組んで
単純なGUIはCでいいじゃんって意味だと思うよ。

で、868では
俺は複雑な計算をするアプリケーションを作ってるんだけど
まあ、そういうロジックの部分はJAVAで書きたいわけ。
やっぱりJAVA>C++なんだよね。(生産性においては）
で、JAVAでGUI作って不満たれてるなら
GUIだけCで作ればいいだろ？ってね。
ちなみにソケット使ってパフォーマンスが落ちるって・・・
もうちょっと良く考えてみな。

まあ、俺はGUIなんてどうでもいいし
そんなのはコーダーにやらせとけばいいから、
SWINGで適当に作って、投げとくけどね。

ちなみにSWTのようなライブラリーが作れる技術がある人は
少ないよ。
それはJNIが難しいんじゃなくて、
設計が難しいという意味で。

>>868
俺はOO原理主義派だけどアンタはまとも。


アンチにまともな人がいたなんて驚き！

俺の中ではプロの逝って良しの１がアンチの基準なんだけど…(藁

どんどんOOから離れた枝葉の議論になってるな。矯正不可能って感じ

起動修正するか。

このスレで出た結論一覧

1)既存のライブラリ＆フレームワークの使いやすさ：ＯＯＰ＞非ＯＯＰ
2)メンテ＆引継ぎのし易さ：非ＯＯＰ＞ＯＯＰ
3)バグの混入度：非ＯＯＰ＝ＯＯＰ
4)生産性：非ＯＯＰ＞ＯＯＰ

反論よろしく。

オブジェクト指向がいらないとか下らないこと言ってる香具師は実名晒せや。
まあお前ら腰抜けは2chで煽るのが精一杯ってこった。

>>878
頼むから最初から読んでくれって。
このスレで出た結論は
アンチはポリもーフィズムが理解できていない。
よって、議論にならない。
だろ？

まあ、非OOPでJavaAPIよりいいもの作れたら
土下座して謝るよ。

>>880
パート I からそうだったが。

>>882
このスレの結論からゆうと
書き込む香具師はみんな職場では居場所のない寂しがりやさんだってことだよね

あるスレではこんな事が書いてあったけど、
>C++/Javaは定義済みのクラスライブラリの使い方との戦いであり
>言語仕様はCとそんなに変わらない
>構造体から拡張されたクラスの概念・設計手法を覚える程度
言語と、既存のライブラリーをセットで考えるからわけわかめになる。
言語があって、その上でのライブラリーなんだよね。

手続き型設計が最高だ。
OOP なんてやってられるか。
至急、仕事下さい。

.　　　　　　　∧＿∧
　　　　　　　（；´Д｀）ﾊｧﾊｧ
　　-=≡ 　/　　　 ヽ
.　　　　　 /|　|　　 |. |
　-=≡　/.　＼ヽ／＼＼_
　　　　/　　　 ヽ⌒)==ヽ_）=,.、,､,..,､､.,､,､､..,_　　　　　 　／i
-= 　 /　/⌒＼.＼　||　　;'｀;、､:、. .:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i　）)
　　／ ／　　　 >　） || (( '､;: ...: ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ ￣ ￣
　/　/ 　　　　/ ／＿||＿＿||｀"ﾞ',''`ﾞ.`´ﾞ｀´´´.＿＿＿
　し'　　　　　（＿つ￣(_））￣(.)）￣￣￣(_））￣(.)）￣

朝出勤する。
今日の業務はツール作成だ。
言語はもちろんＣ。
私の指がキーボードの上を一閃すると、モニタ上を美しいコードが流れていく。
午後、デバックが完了する。
向かいのＪａｖａ坊が２ヶ月も掛かって作っているコードを自動生成するツールである。
プロジェクトで割り当てられた１２本のサーバーサイドプログラムを
私は一日で作り終えた。
午後は優雅に紅茶をたしなみ、定時に帰宅した。

しばらく来ないうちに電波が増大しとるなぁ。
コネクションプールでスピンロックかましてたのは直したのかよ。