【常識】 OO厨房は戦場では必要無し！ 【事実】

このエントリーをはてなブックマークに追加
1 ：デフォルトの名無しさん：
過信しすぎですね
自分で作ったわけでもないのに:-)
設計バカなど死ねばいい。
2 ：真の1#：02/12/30 15:54
トリップつけた
3 ：1：02/12/30 15:58
OO厨 は糞!
4 ：C#：02/12/30 18:04
クソスレ
5 ：デフォルトの名無しさん：02/12/30 19:15
>>1 はObject Oriented 使ってひどい目にあったのかな?
6 ：デフォルトの名無しさん：02/12/30 19:16
【常識】 ○○厨房は戦場では必要無し！ 【事実】

にした方が汎用性が高くなるのに・・・>>1ってバカね。
7 ：デフォルトの名無しさん：02/12/30 19:32
>>5 Object Oriented 使い無い奴はこれからは

抵抗勢力

と呼ばれ徐々に滅びていくでしょう。
8 ：デフォルトの名無しさん：02/12/30 19:47
WebSphere使う案件増えたからな～

OracleとRADでやってる奴らにはOOは無用だろうけど。
9 ：デフォルトの名無しさん：02/12/30 20:14
最高の良スレ
10 ：デフォルトの名無しさん：02/12/30 20:19
-----------------------【【裏・情報・取引】】--------------------------
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
◆裏情報取引サイト→http://www.kawachi.zaq.ne.jp/dpdan803/◆
◆国際免許取得→→→http://www.kawachi.zaq.ne.jp/dpdan803/◆
◆悪徳業者情報→→→http://www.kawachi.zaq.ne.jp/dpdan803/◆
◆あらゆる調査→→→http://www.kawachi.zaq.ne.jp/dpdan803/◆
◆委託販売募集→→→http://www.kawachi.zaq.ne.jp/dpdan803/◆
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
---------------------↓↓↓↓↓↓↓↓↓↓↓↓---------------------
11 ：デフォルトの名無しさん：02/12/30 21:20
とりあえず、OO否定派はさぁ
C言語で文字列を扱うライブラリでも作ってみてよ。
12 ：デフォルトの名無しさん：02/12/30 21:21
最近、偉そうなコーダーが増えてます。
特にたかがVBができたくらいで調子にのってるバカです。

プログラミングってのはアルゴリズムを考える事に
意味があるのにもかかわらず、
デバッグとコーディングに誇りを持っちゃってるかわいそうな
人達がいます。
数学のできないバカや文系にはプログラミングは無理です。
しかしながら、そういう人達がいないと困ります。
スタープログラマーの間では、そのような人達を
使い捨てプログラマーと呼ぶのが一般的ですが、
その人達につまらないコーディングやデバッグを
安い賃金で任せる事ができるので非常に便利です。
でも、最近は使い捨てドカタは中国から輸入する事が
多くなりました。
そういうわけで、うちの会社では
使い捨てプログラマーは粗大ゴミとして捨てました。

ちゃんちゃん
13 ：デフォルトの名無しさん：02/12/30 21:25
>>1は、ＯＯが理解できない冬厨ということでよろしいか？
14 ：デフォルトの名無しさん：02/12/30 22:03
っていうかさ、非OOプログラミングで職場が毎回戦場状態に突入
しちゃうからOOが注目あびてるんでしょ?
OO否定派は、現状の改善に目を向けないの?
15 ：デフォルトの名無しさん：02/12/30 22:17
>>12
ちったぁ自分なりにアレンジしろよ。ｸｽﾞ
16 ：デフォルトの名無しさん：02/12/30 23:35
OperatorOverload派ですが何か？
17 ：デフォルトの名無しさん：02/12/31 00:19
>>16
で標準入出力に << とか >> とか使っちゃって、その後数十年にわたって批判され続ける事になる っと。
18 ：デフォルトの名無しさん：02/12/31 18:52
OOだろうがＸＸだろうが厨房は使えねぇ。
19 ：デフォルトの名無しさん：02/12/31 19:44
設計はプログラム開発の一部分に過ぎません。
20 ：デフォルトの名無しさん：03/01/02 13:03
>>19
age ってるから何かと思えば、当たり前の事を…。
OOD は OO の一部に過ぎませんが何か？
21 ：デフォルトの名無しさん：03/01/02 14:49
まあ入門書にも書いてあることですが
OOはあくまでも開発手段の一つに過ぎません。
22 ：名無し＠沢村：03/01/02 14:55
>>13
ＯＯが理解できない冬厨が現実に存在するということが信じられないが…
一体どうして…？その人は事故に遭って大脳の機能が失われたのか？
それとも生まれつき知能に深刻な障害を持った知的障害児なのか？
まあどちらかだろうね…
23 ：デフォルトの名無しさん：03/01/02 14:57
ooマンセーというよりは他に確立したまともな開発手法がないからooやってるにすぎないです。
24 ：デフォルトの名無しさん：03/01/02 15:00
Lispなんかは保守性にかんしてはどうなんだろう。
とっつきにくさはあるけど、それを乗り越えると
かなり見通しのいいものになるとかならないとか。
25 ：名無し＠沢村：03/01/02 15:01
ＯＯが理解できない冬厨はどこで壁にぶつかったのか報告してごらん？
ＯＯに壁になりそうな部分というのは私自身どう考えても思い付かないが、理解できないからにはその人なりにどこかで理解できない壁にぶつかったはずなんだ…。
私は君たちがどこで壁にぶつかったのか、とても興味があるよ…！！
まあ、チンパンジーが何歳の知能を持っているかに対する興味と類似した興味だよ♪
26 ：デフォルトの名無しさん：03/01/02 15:02
>>沢村
お前がOOを理解しているっていう匂いが、微塵も感じられない
内容だな...。
余計な事ウダウダ書いて無ぇで、勉強しろ。
27 ：名無し＠沢村：03/01/02 15:08
私はアセンブラ、ＯＯ、ＭＦＣのうちアセンブラとＯＯについては理解したつまりだよ。
ただＭＦＣだけはまだ理解できていないということが心の痛みとなっているよ…。
当分はＳＤＫで頑張ろう…
28 ：デフォルトの名無しさん：03/01/02 16:09
>>25
抽象データ型とOOの違いが良く判りません。
説明お願いします。
29 ：名無し＠沢村：03/01/02 16:23
>>28
ヌヒよ、抽象データ型はOOの一部だよ。
つまり抽象データ型 ＜ OOというわけだ。
Ｃ＋＋では抽象データ型は純粋仮想関数として表現できるよ。
つまり宣言したクラスでは定義せずに、そのクラスをうけついだクラスで定義するわけだ。
何にせよ、抽象データ型はOOの中のひとつの概念にすぎないが、ActiveXなどの内部では使われているのだかから、比較的かっこいい概念ではあるよ。
30 ：デフォルトの名無しさん：03/01/02 16:27
>>27
＞私はアセンブラ、ＯＯ、ＭＦＣのうちアセンブラとＯＯについては理解したつまりだよ。

アセンブラ ＝ アセンブリ言語の事？それともアセンブラ(ツール)の使い方の事？
OO ＝ Object Oliented 。これは「考え方」の話。「指向」の話。
MFC ＝ クラスライブラリ

なんで聞いてもいないような(無関係な)これらを一文に並べてるの？
「理解」ってどう理解しているの？
ていうか「意味の理解」だけなら意味無いだろ。普段どう使ってるつーのよ。

＞当分はＳＤＫで頑張ろう…
ﾊｧ？
31 ：デフォルトの名無しさん：03/01/02 16:29
>>29
＞比較的かっこいい概念

厨房
32 ：名無し＠沢村：03/01/02 16:31
>>30
つまり自分でプログラムを書くときにそれが使えるかどうかが基準よ。
使えれば理解したといってもいいのではないだろうか？
ＭＦＣはまだ使えない、それだけの話しよ。
33 ：デフォルトの名無しさん：03/01/02 16:31
OOってどうやって使うの？
34 ：31：03/01/02 16:33
ActiveX(COM)で使われている事と「かっこいい」がつながらない。

あと「抽象データ型がOOの中のひとつの概念」なのではなく、
「データ(と実装)を抽象化するのが」OOの中心概念。
35 ：デフォルトの名無しさん：03/01/02 16:35
だからアセンブラの話もMFCの話も聞いてねぇってば。＞沢村
36 ：名無し＠沢村：03/01/02 16:35
>>33
ヌヒよ、OO自体は概念だから使えないよ。
OOベースのＣ＋＋とかを使うということよ。
37 ：デフォルトの名無しさん：03/01/02 16:37
分析・設計だけでは決してプログラムにはなれません。
38 ：名無し＠沢村：03/01/02 16:39
>>34
確かに仮想関数が使われていないＣ＋＋のコードはほとんど見かけないが、たまにはあるよ。
だからやはりデータ(と実装)を抽象化するのがOOではなく、抽象データ型はOOの中のひとつの概念だよ。
39 ：デフォルトの名無しさん：03/01/02 16:39
OOするにはどんなソフトが必要なんですか？
40 ：名無し＠沢村：03/01/02 16:44
ＶＪ＋＋とかＶＣ＋＋だろうね。
ＶＪ＋＋は使ったことないからわからないが、聞くところによるとOO言語ということだ。
抽象データ型を表現するのに「インターフェイス」という概念が用意されているらしい。
私はＪａｖａまでは手が回らないので、ヌヒが使ってみるといいよ。
41 ：デフォルトの名無しさん：03/01/02 16:44
>>38
おいおい、C++のOOじゃない部分を取り出してOOを語るなよ・・・(苦笑
42 ：デフォルトの名無しさん：03/01/02 16:45
>>40
> ＶＪ＋＋は使ったことないからわからないが、聞くところによるとOO言語ということだ。

言語じゃないだろ・・・(苦笑
43 ：34：03/01/02 16:48
>>38
？？なんか "C++ == OO"だとでも思っているような発言。(>>36も参照)
というか、
「"C++ == OO"であり、そしてC++ではそう書かない可能性がある(書かなくても書ける)から云々」
って言ってるように聞こえる。

C++はOOな言語....じゃなくて、「OOとして書くこともできる言語」でしょ。
「C++」っていう限定された言語でのコーディングスタイルが、なんで、
「オブジェクト指向」そのものにフィードバックされんだよ。
44 ：◎◎：03/01/02 16:51
何でも聞いて・・・
45 ：デフォルトの名無しさん：03/01/02 16:52
なんだこのレベルの低さは
46 ：デフォルトの名無しさん：03/01/02 16:53
沢村さんの言わんとしていることは

　抽象データ型＋ポリモーフィズム＝ＯＯ

なんじゃなかろうか？
47 ：◎◎：03/01/02 16:53
>>45
失敬な！
48 ：◎◎：03/01/02 16:54
何でも聞いていいよ～。いまならタダで回答してやるよ。
49 ：デフォルトの名無しさん：03/01/02 16:57
たぶん沢村はどこぞのスレ等で...
「C++を使ってオブジェクトオリエンテッドな開発を行うにはどうすればいいか」みたいな
問いに対する答えとして、
「抽象基底クラス(virtual)を定義し、そこで公開されるインターフェイスを用いた実装を云々」
みたいなレスを見つけて、「そうか」と納得したのではないか。
だから、「C++＝OO」だと思っているのではないか。

沢村...浅過ぎ。
50 ：デフォルトの名無しさん：03/01/02 17:00
>>46
たぶんそう言いたいんだろうけど、そこで

「＝OO」

は、変でしょ。それはOOの「機構の話」でしょ。
「機構」と「概念」を一緒にするから、話のレベルが下がるんだよ。
51 ：◎◎：03/01/02 17:02
・・・
52 ：デフォルトの名無しさん：03/01/02 17:07
>>51
シングルトンてグローバル変数みたいなものじゃない？
昔は、グローバル変数使うなと言われていたけれど
シングルトンはいいの？
53 ：名無し＠沢村：03/01/02 17:10
>>46
＞沢村さんの言わんとしていることは

＞　抽象データ型＋ポリモーフィズム＝ＯＯ

＞なんじゃなかろうか？

ヌヒよ、ヌヒの発言は俺のいわんとしていることに近いよ。
欲をいえば俺はOOに必ずしも抽象データ型もポリモーフィズムも必要ないと思ってるよ。
何故ならOOはオブジェクト指向だろ？
つーことはクラスのインスタンスが生々されさえすればオブジェクト指向なんだよ。
何故ならクラスのインスタンスのことをオブジェクトと呼ぶのだからね。だからオブジェクト指向というんだと思うよ。元々はね。
54 ：デフォルトの名無しさん：03/01/02 17:14
馬鹿増えたなぁ。
一つの小さい機能とってなんでOOっていうのかなぁ。
OOってのは平たくいうとプログラムの組み方っつーか組むにあたっての方針だよ。
ま・と・め・か・た
わかる？
こんな簡単なことが馬鹿には一生わかりそうもないんだな。
わかってないくせに難しそうな単語ならべてごまかすのはやめろや。
OOを理解した奴は理解してない奴を一発で見抜ける。
なぜならOO自体は糞簡単だから、変な単語出した時点で
ああ、こいつわかってねぇな。って感じ。
OOてな、すっげぇ大雑把な概念だぞ。
55 ：名無し＠沢村：03/01/02 17:19
ヌヒ等よ、オブジェクト指向とはプログラムの中でクラスのインスタンス（＝オブジェクト）を生々することだよ。
だけどそれだけじゃ学者が一般人から馬鹿にされるんでポリモーフィズムと抽象データ型を付け加えておしゃれにしたのだと思うよ。
56 ：デフォルトの名無しさん：03/01/02 17:22
アーキテクチャやデザインの話だと思ってたが・・・
57 ：デフォルトの名無しさん：03/01/02 17:22
>>55
クラスがないOO言語はどうする？(苦笑
58 ：名無し＠沢村：03/01/02 17:25
>>57
クラスがないOO言語があるのか？
それは知らんかった…。それはまがいものかも知れないぞ。
59 ：デフォルトの名無しさん：03/01/02 17:25
レベルが低すぎてゲロ吐きそうだ
60 ：デフォルトの名無しさん：03/01/02 17:31
なら見るなよ
61 ：デフォルトの名無しさん：03/01/02 17:46
厳密な定義なんかねぇよ。
いい加減理解しる！
インベーダーゲームなら自機、敵、弾がそのままクラスになるんだよ。
カードゲームならカードとプレイヤーぐらいしかクラスがでねぇよ。
でかいもの作るときは管理クラスが間に入るだけだって
こーゆー考え方をOOっていうんだよ。
それ以外ねーよ。
なんで難しく考えるんだよ
憂欝本読んだんだろ？
なんでいまだに理解できねんだよ。
そんなにお前等馬鹿なのか？
こんなの理解するのに十分間必要か？
いい加減うざいよ。
さっさと理解しろよ
62 ：デフォルトの名無しさん：03/01/02 17:54
>>54
確かにわかってなさそうだな。
まあ、止めないが。
63 ：名無し＠沢村：03/01/02 17:58
>>61
欲をいえば、
インベーダーゲームならfring抽象クラスをつくって自機クラス、敵クラス、弾クラスでそれを実装すれば、
抽象データ型、ポリモーフィズム、多態というOOの３要素を全部使ったおしゃれなOOになるよ。
カードゲームならプレイヤー抽象クラスをつくって自分クラス、相手クラス、ＶＳコンピュータクラスでそれを実装すれば、おしゃれなOOになる。
カードクラスはいらないね。
64 ：デフォルトの名無しさん：03/01/02 18:14
クラスがあるからOOだと思ってる奴がいたとは・・
65 ：デフォルトの名無しさん：03/01/02 18:16
>>63
＞抽象データ型、ポリモーフィズム、多態というOOの３要素を全部使ったおしゃれなOOになるよ。

多態性＝Polymorphism

虚ろな知識で語らないで下さい。
沢村さんがレスを始めると、どんなスレもレベルが下がりだし、みんな死にます。
ちゃんとした議論や情報を期待してたJava3Dスレも、君の妄想のせいで死にました。
もう、いいかげん本棚に本飾ってるだけで「知ってる気」になるのは
やめて下さい。お願いします。
66 ：デフォルトの名無しさん：03/01/02 18:24
沢村==釣り
これが世界の定説です
67 ：デフォルトの名無しさん：03/01/02 18:28
>>58
むしろ、
クラスがないオブジェクト指向言語のほうが、より純粋なオブジェクト指向の実装だ
という主張をする人が少なくないのだが。
68 ：デフォルトの名無しさん：03/01/02 18:31
オブジェクト指向の父と呼ばれているアラン・ケイ博士によるオブジェクトの定義：
「オブジェクトとは再帰的に組み合わせることのできる小さなコンピュータである」

クラスだの多態だの抽象データ型だの、枝葉末節だよ・・・(苦笑
69 ：デフォルトの名無しさん：03/01/02 18:32
(´-`).｡oO(沢村って世界的に知られてる人なのか…)
70 ：デフォルトの名無しさん：03/01/02 18:33
結局ん十年前から存在していても話すらまとまらない洗練されてない手段なのですか？＜OO
71 ：デフォルトの名無しさん：03/01/02 18:34
オブジェクト指向を実現するのにクラスっていうのは理想的な仕組みじゃないんだね。
それで今のところ理想的な仕組みってあるの？
どなたか教えてプリーズ
72 ：デフォルトの名無しさん：03/01/02 18:35
>>沢村
君が語ってる話は、あえて言うなら性的お片づけ言語における
効率的な OO 開発方法の話に近いな。

ハシバシがあってないから無茶苦茶だってがバレバレだけど。
73 ：72：03/01/02 18:37
>>71
smalltalk やれ！
っていうか俺も Squike (綴りがわからん) をちょびっと触ったくらいしか
しらないけど。
74 ：デフォルトの名無しさん：03/01/02 18:38
>>71 == アフォ
75 ：65：03/01/02 18:38
>>63
さらに言うなら、オブジェクト指向において、なぜ「型（＝Class）」という考え方があるのかっていうと、
要するに「実装とその周辺データ(属性(＝Attibutes))を包含するもの＝物体(＝Object)」を実体化(＝Instanciate)するためには、
その設計図となるものが必要だから、です。 ...っていうのが、実際のコーディング作業から見た場合の、
逆説的なOOの説明だと思う。

で、コーディング的には、「実装、つまりその物体の振る舞い(＝Method)があり、それらに必要な属性がある場合に、
その属性を変える事で、『別の実体』を作れる再利用性」というものが、OOのポイントになるわけで、

そこにOOの中心的な要素、「集成と委譲（要するに継承）」という概念が付加されると、
さらに「全ての物体に必要な基本的なものはここで定義しておいて」の後、「Ａではこれを、Ｂではこれを」といった具合に
「単位としての物体」を構築するようにして（要するにパズルをくみ上げるみたいに）、最終的な機能の塊（開発目標である、最後の集成）を
行う事ができる。

簡単に言えば、「大雑把に機能単位でコーディングできる」っていう事。
76 ：デフォルトの名無しさん：03/01/02 18:42
>>73
サンクス。
Javaとsmalltalkって似てる感じがするけどsmalltalkの方がオブジェクトを
理想的に表現できるの？
こればっかりはやってみるしかないか・・
77 ：65：03/01/02 18:43
自己レス>>75
なんかTV見ながら書いてたら、良くわからん文章になってしまった。(^_^;

ていうか、なんか知らん間にこんなにレス進んでたのね。
78 ：デフォルトの名無しさん：03/01/02 18:43
OOは創造性に欠けるね。
面白さが少ない。
79 ：デフォルトの名無しさん：03/01/02 18:45
広末は大人の女になったねー
80 ：デフォルトの名無しさん：03/01/02 18:46
>>78
戦場で「面白さ」は必要か？
81 ：デフォルトの名無しさん：03/01/02 18:48
>>80
もちろん。
82 ：デフォルトの名無しさん：03/01/02 18:49
>>81の考え方は少数派
83 ：デフォルトの名無しさん：03/01/02 18:49
>>80
禿同。じゃないと仕事がつまらん。（笑

時に、"MFC"ってOOだと思う？＞皆
84 ：デフォルトの名無しさん：03/01/02 18:50
>>76
まあJavaの言語設計やVMの設計にはSmalltalkの影響がかなり大きいからね。
で、どっちがオブジェクトを理想的に表現するかだけど、
そりゃ何を理想的とするかによるわな。
とりあえずSmalltalkにはJavaで言うprimitive typeがないから
いちいちオブジェクトかどうかを意識する必要がない。何でもオブジェクトだから。

で、実は言語としての完成度はオブジェクト指向的要素自体よりも
型付(静的か動的か)だとか、名前空間(単一か複数か)だとか、
そういうオブジェクト指向以外の要素が占める割合が大きいと思う。
85 ：デフォルトの名無しさん：03/01/02 18:52
>>73
ちなみにSquikeじゃなくてSqueakね。

86 ：デフォルトの名無しさん：03/01/02 18:55
>>83
思わん。ちょっと使っただけだが直感的にそう思う。
87 ：デフォルトの名無しさん：03/01/02 18:57
OO厨ってどういう人のことなんですか？
単にOOを実践しているだけではOO厨になれないんですよね？きっと。
88 ：デフォルトの名無しさん：03/01/02 19:00
>>75
一方でプロトタイプベースのオブジェクト指向言語を支持する人達にとっては
クラスというものの存在はオブジェクト指向的ではないことになる。

具体的には、例えばクラスがメソッドを持っているというモデルでは
そのオブジェクトは単独では何もできないことになってしまう。
オブジェクトの独立性を考えれば、メソッドはオブジェクト自身が持っていたほうが
よりオブジェクト指向的ということになる。

アラン・ケイによるオブジェクトの定義(>>68参照)に沿って言えば、
あるコンピュータ(オブジェクト)が仕事をしようとしたら
プログラムを別のコンピュータ(クラス)からダウンロードしてこなければならないのでは
本当にそのコンピュータ(オブジェクト)は一人前のオブジェクトと言えるのだろうか？
89 ：デフォルトの名無しさん：03/01/02 19:04
ＯＯは便利だよ。
90 ：83：03/01/02 19:10
>>86
あ、やっぱそう思う？
俺もなんか初めてMFCのクラス構成図見たとき、「ただのサブルーチン集やんけ」って思ったんだよね。
ようするにクラスに包んで「はいオブジェクト指向ですよ」って味付けされただけの、
Win32ラッパークラス。
なんか、無理やり具合がVBっぽい。(笑
91 ：デフォルトの名無しさん：03/01/02 19:12
じゃあ、>>83じゃないけど、まじめにVBでOOなコーディングしてる人っている？

...いや、VBはOO向きじゃないって言われればそうなんだけど...。
（まだJavaScriptの方がソレっぽく書けそう....）(藁
92 ：デフォルトの名無しさん：03/01/02 19:14
＞Win32ラッパークラス。
俺もそんな感じがした。
ハンドル剥き出しななんとも半端なラッパー具合。
93 ：デフォルトの名無しさん：03/01/02 19:15
>>91
やってるよ。っていうかJavaライクなやり方だけど。
インターフェイス使ってみたり（ってVBだとクラスだけど）
94 ：デフォルトの名無しさん：03/01/02 19:18
>>92
ハゲ同。あるいは文法砂糖塊。
95 ：デフォルトの名無しさん：03/01/02 19:22
SDKで１からだとさすがに辛すぎるからクラスにしてみましたって感じ。
96 ：デフォルトの名無しさん：03/01/02 19:23
OfficeもVCでつくってんのかな？
VCお得意のドキュメントビュー方式ってOfficeの構造ととっても似てる
97 ：名無し＠沢村：03/01/02 19:25
>>65
ポリモーフィズムとは多態性のことだったのか。
俺はまた継承の意味で使っていたよ。英語は苦手なものでね…。
ヌヒ等よ、これはプログラムの理解力の問題ではなく、単に英語力の問題だよな。
98 ：デフォルトの名無しさん：03/01/02 19:28
>>97
いや、知能の問題だと思う。
ちなみに継承もオブジェクト指向では必須ではないよ。
99 ：デフォルトの名無しさん：03/01/02 19:28
ポリモーフィズムなんて単語日常使わないよ
専門用語だよ
よって英語力の問題ではない
100 ：75：03/01/02 19:29
>>88
うーん.....なるほど。なんか面白くなってきた（笑

俺はアラン・ケイ氏は名前しか知らないけど、
その場合の、「別のコンピュータ（クラス）から自分の実行内容を持ってくる」っていうのが
「オブジェクトが独立していない」という事の証明にあたる、つまり
「あるクラスがInstanciateされるには、別のオブジェクトがトリガーにならなければならない」＝
「これではそのオブジェクトは他のオブジェクトに依存している」から、
「真のオブジェクト指向とは呼べない」ってなると、ちょっと泥臭い話になるけど、
全部static Methodなら、ある意味理想に近い？？　違うか。（笑

でもさ、例えば細胞が群れを成して器官を作った時、その器官を利用し、キックするのは
それを利用する他の器官だったりするんじゃない？
その時、その器官は「その機能を持った物体」では無い？？独立はしていない。が、
単位として存在している。....これってどう？

...ちなみに俺の頭の中でのOOの体現は、せいぜいJavaの機構止まりです。(^_^;;
101 ：名無し＠沢村：03/01/02 19:33
>>100
＞あるクラスがInstanciateされるには、別のオブジェクトがトリガーにならなければならない

これは宇宙の仕組みと同じだね。宇宙はオブジェクト指向で設計されているんだね。
102 ：名無し＠沢村：03/01/02 19:36
以前記憶違いかも知れないが、何かの本でオブジェクト指向の登場で人口知能の実現に近づいたというのを読んだことがあるよ。
オブジェクト指向と人口知能とのつながりはまだ見えてこないけどね…。
103 ：デフォルトの名無しさん：03/01/02 19:37
>>100
> でもさ、例えば細胞が群れを成して器官を作った時、その器官を利用し、キックするのは
> それを利用する他の器官だったりするんじゃない？

細胞の例で言えば、細胞分裂すればいい。
実際、プロトタイプベースなオブジェクト指向言語では
インスタンス生成は元のオブジェクトからコピーするわけだし。
104 ：デフォルトの名無しさん：03/01/02 19:38
沢村ってだれ？
まあ、いいけど
馬鹿だねほんとに、OOの概念をはなしたんであって、てめぇがどう作るかなんてどうでもいいんだよ。
普通はそんなところはこだわらない。
インベーダーゲームの自機、敵、弾や
カードゲームのカードとプレイヤーは
OOで組むにあたってなければいけない最小限のクラスだ。
それを管理するときにどう組むかはさほど大事なことじゃない。
OOをわかってないだろ？
大事なのはものだよ、MONO。
お・ぶ・じ・ぇ・く・と
OK？
105 ：デフォルトの名無しさん：03/01/02 19:40
オブジェクトの共通部分をクラスとしてまとめてしまうクラスベースのほうが、
プロトタイプベースより空間的に効率が良い
106 ：名無し＠沢村：03/01/02 19:41
>>104
大事なのはものじゃないよ。金でもない。
ココロだよ。つまりハート。おわかり？
107 ：デフォルトの名無しさん：03/01/02 19:41
>>102
人口知能じゃなくて人工知能ね。
オブジェクト指向と人工知能のつながりということで言えば、
ミンスキーの「フレーム」はオブジェクトに限り無く近い。
108 ：72：03/01/02 19:42
>>85
あう、そか、ありがとう。

>>101
もっともらしい事を書いてるし、そう考える事もできるが、理由がないから却下。
109 ：デフォルトの名無しさん：03/01/02 19:43
>>104
痛いのはもういいよ…
ゆっくり休め、そして首吊れ。
110 ：デフォルトの名無しさん：03/01/02 19:44
[脊椎動物]
↓　　　↓継承
[犬]　[猫]

[ 鳴ける ]
↓　　　↓多態性
[犬]　[猫]
111 ：名無し＠沢村：03/01/02 19:44
>>103
＞プロトタイプベースなオブジェクト指向言語では
＞インスタンス生成は元のオブジェクトからコピーするわけだし。

何かプロトタイプベースなオブジェクト指向言語って面白そうだな…。
プロトタイプベースなオブジェクト指向言語でライブラリが充実しているwindows開発環境ってない？
満足のいくものがあれば、Ｃ＋＋からそっちに乗り換えてもいいな。
112 ：72：03/01/02 19:46
>>105
そういう理由だろうか？
俺は複雑度の管理上の理由だと思う。

静的な部分の複雑度は固定だから、それが扱いやすさに繋がるのだと思ってる。
レベルは異なるけど「フレームワーク」とかと同じ、
ルールがあるから、想定されている範囲の事はやりやすくなる。
そのかわり想定外の事をやるのが難しくなる。

それがオブジェクト指向におけるクラスだと思う。
113 ：デフォルトの名無しさん：03/01/02 19:47
>>111
JavaScript
114 ：デフォルトの名無しさん：03/01/02 19:56
>>111
Object-based PLs page of Rainer Blome
http://www-alt.pasteur.fr/~letondal/object-based.html
115 ：100：03/01/02 20:01
>>103
なるほど。
だとすると、現実的にメモリに展開されるコンピュータ言語（というかロジック）を
そのように実装するとなると、>>105が言うように、メモリ効率が悪くなるよね。
俺はJava野郎なので、そこんところを具体的にイメージすると、やっぱり全てをstaticに実装する絵を
思い浮かべてしまう....。

そんで、Clone。...というか、根こそぎ全部DeepCopy。（ちなみにJavaのオブジェクトのCFoo#clone()は、大抵シャロー・コピー..実装によるが）

..真のオブジェクト指向を体現するような言語って「内部まで真に」してしまうと、
かなり厳しいね。メモリに乗せて現実的に使おうとすると。
116 ：デフォルトの名無しさん：03/01/02 20:10
>>115
メモリ効率については、実はほとんどのプロトタイプベース言語は
完全に全てコピーするのではなく、共通部分は元オブジェクトへの参照になる。
もちろんクラスベースよりは効率は悪いが、それほどひどいわけではない。

Self(プロトタイプベースOO言語)では、メソッドだけでなく変数でも同じ事ができる。
(というか、変数もメソッドも同じ「スロット」であり区別しない。)
この仕組みを使うとクラスベースのものよりも柔軟な変数の共有ができる。
117 ：100：03/01/02 20:12
よく「本当のOO」な人たちが、「Javaは中途半端」の理由として、
「なんでプリミティブ型なんてあるんだよ」っていうか「オブジェクトじゃないんだよ」って
言うじゃない？

でも、「物体」とは「真に独立して存在している、物」であるって考えると、
ますます、「Java＝現実と指向の折衷」って感じがしてくるね。

...ま、実際JavaってC++の中からOOな部分だけを持ってきて、拡張し、補完し、
細胞そのものを実体とする代わりに、その「物体同士の連鎖」の部分だけを
モデル化したものなんだろうけど....。
118 ：100：03/01/02 20:17
>>116
へー。Self..？初めて聞いた（恥
面白そうですね。

でも、やっぱりクラス指向（型紙ありき）でも、プロトタイプ指向（実体ありき）でも、
いざコンピュータの言語として実装するには、それぞれに「現実と理想の折衷」部分が
存在するんですね。
...じゃないと、無理。っていうか形にならないけど。

で、Self。ちょっと面白そうなので、ぐぐってみます。（笑
ありがとう。
119 ：デフォルトの名無しさん：03/01/02 20:19
●●●●●●●●「オセロさえ納期内に作れない＝ＯＯ役立たず 」祭り●●●●●●●
http://pc3.2ch.net/test/read.cgi/tech/1041230298/l50／|　　　　　　 　 |　 |＿＿＿＿_ΦΦΦΦΦΦΦΦΦΦΦ||ΦΦΦ
　 |　　　　　　 　 |　 |￣￣￣ ／|　　　　　 　 　 　 　 　 　 　 ||
　 |　　　　　　 　 |　 |　　　／ ／|TTTTTT　　 TTTTTTTTTT||TTTTT
　 |　 　 　 　 ／＼　|　 ／|／|／|^^^^^^ |三三| ^^^^^^^^^^^||^^^^^^^
　 |　 　 　 ／　 ／　|／／ ／ ／|
　 |　　　／　 ／ |＿|／|／|／|／|
　 |　 ／　 ／　　|文|／ ／／ ／
　 |／　 ／.　 ＿.|￣|／|／|／　　　　　　　　　Λ＿Λ
／|＼／ 　／　／ 　|／ ／　　　　　　　　　　 （＿＿_）
／|　 　 ／　／　 ／ヽ　　　　　　　　　　　　/〔 非OO 〕〕つ
　 |　　　|￣|　 |　|ヽ／l　　　　　　　　　　　 ｀/二二ヽ
　 |　　　|　 |／|　|__|／　　　Λ＿Λ　　　　 /　/（＿）
　 |　　　|／|　 |／　　　　　 （　´∀｀）　　　（＿）　　　 Λ＿Λ
　 |　　　|　 |／　　　　　 ／/ /　 ^￣］ﾟ　　　　　　　　（｀　　　）
120 ：デフォルトの名無しさん：03/01/02 20:20
MFC（GUI関連）に関しては
なるべく薄いAPIラッパーをオブジェクト指向で作ろうと思うと
あんな感じになると思う。
もちろん、JAVAみたいに完全にオブジェクト指向で作ってくれたほうが
使いやすいけどね。
ただ、MFCの方が薄い分、できる事の幅は広いはず。

OOってのはC言語で関数ポインタが使いこなせて、
ファイル分割によるモジュール化ができていれば、
別に難しい事じゃない。
逆に、関数ポインタが使えない奴、ファイル分割によるモジュール化が
できない奴には、OOはまだ早い。
ポリモーフィズムは関数ポインタだし
情報隠蔽、データ抽象あと継承は、
ファイル単位のプログラム分割に過ぎない。
それを言語機能として取り込んで、使いやすくしているのが
オブジェクト指向言語なわけだ。
だからCが使いこなせる奴は、
C++を使うと当然オブジェクト指向になる。
逆に、CからC++へ移行してオブジェクト指向プログラミングを
しない奴はCを使いこなせていないんだろう。
121 ：デフォルトの名無しさん：03/01/02 20:20
じゃあ、オブジェクト指向プログラミングは何をするかといと
使いやすくなった、関数ポインタとファイル分割によるモジュール化を
積極的に使っていく事にある。
逆に言えば、関数ポインタより使いやすいポリモーフィズムがあるのに
なぜ使わないんだ？という事になるわけだ。
そういうわけで、OOを否定している奴は
関数ポインタが使えないか、
あるいはファイル単位でのモジュール化を実践する事すらも
拒んでいる事になるんだが。
あるいは、しょぼいプログラムしか書いた事ないんだろうな。

ところで、プロトタイプベースのOOって何？
122 ：デフォルトの名無しさん：03/01/02 20:22
>>121
はは、関数ポインタを仮想関数に置き換えたスタイルのコード書いて晒してごらん
それはOOじゃないってさっそく回りのOO厨にボコボコに言われるのは間違いない。
123 ：デフォルトの名無しさん：03/01/02 20:26
>>122
ん？
関数ポインタを使ったコードを
仮想関数によるポリモーフィズムで書いてみろと？
あ、逆か。

で、何でOOじゃないって言われるんだ？
124 ：デフォルトの名無しさん：03/01/02 20:27
じゃ言います。

　OO厨は逝ってよしっと。
125 ：デフォルトの名無しさん：03/01/02 20:40
まあいいや、じゃあ書くか
C言語の知識が怪しいけど、やりたい事はつたわるはず。

ファクトリーメソッドメソッドの例
struct abstractProduct{//親クラスみたいな物
void (* func)(int* i);//純粋仮想関数？
int property;//プロパティーは本当は構造体で作るのかな？
};

int polymophism(int a,int b){
struct abstractProduct* concreteProduct=Factory(a);
//親クラスを継承したクラスがファクトリメソッドで生成される。
abstractProduct->func(b);
//純粋仮想関数ライクなメソッドfunc(int)が呼ばれる。
}

こんな感じでいいかな？
C++の仮想関数テーブルの仕組みとは違うので注意
126 ：122：03/01/02 20:44
>>125
？　俺は"関数ポインタを仮想関数に置き換えたスタイルのコード書いて"　って言ったぞ？

OO厨は、OO言語を便利に使うだけじゃOOだとは認めないんだよ。
OO設計、OO分析込みでないと真価を発揮しないとか何とかな
必ず言い出すから
127 ：デフォルトの名無しさん：03/01/02 20:52
ああ、スマソ
でも、ファクトリーメソッドをOOで書くのは簡単だよね？
って事で125を脳内でC++化してくれれば
いいっしょ？
128 ：デフォルトの名無しさん：03/01/02 20:56
>OO厨は、OO言語を便利に使うだけじゃOOだとは認めないんだよ。
OOPLを便利に使うだけじゃ、OOと認めない人をOO厨っていうわけ？

てか、OO設計とOO分析ってどういう意味？
それなりのプログラムを作るには設計が必要だし、
開発しながら（仕様変更が予定にある中で）、
コーディングするんであれば（ってかそれが普通）
分析する必要もあるわけだ。
で、そんなのも
どこをどうやってモジュール化するかの問題でしょ。
ようするに、どの変が仕様変更が起こりやすいかを分析するというか。
分析ってそういう意味じゃないの？
129 ：デフォルトの名無しさん：03/01/02 20:56
てか、仮想関数テーブルをCで書けばいい訳でしょう？
X toolkitのウィジェットセットはそういう方法でオブジェクト指向していたはず。
130 ：デフォルトの名無しさん：03/01/02 20:58
>てか、仮想関数テーブルをCで書けばいい訳でしょう？
まあ、そうだけど
131 ：デフォルトの名無しさん：03/01/02 21:06
>>128
OODだのOOAだのって、それこそ新しい概念でもなんでもないと思うけどねえ。
OOPLとは別に、プログラムを小さなプログラム(なり何なりの小サイズのカタ
マリ)の集合とみなして構築するようなことは昔からやってきていて、それを
OOPLベースの考え方で体系化しただけのような気がするんだけど。
OOAだのOODだのって呼んではいなかっただけで、賢いヒトはみんなやってた
ことのような…
132 ：118：03/01/02 21:08
>>126
横から関係無い話で、ごめん。
俺は基本的にJava野郎で、OOに興味があり、それ自体が楽しいと思ってるクチなんだが、
現実的に仕事で使う場合は、(>>118にも書いたけど）それは（まるでJava自身でそうであるように）
「いいところを使う」って感じで使ってるよ。
さっき>>116に聞いた話だけど、そういう意味では「プロトタイプ指向なOO」とかは、
（理想通りの実装にした場合）とても現実的だとは思わないし、とても
仕事で使えないと思う。メモリの管理どうすんの！？って感じだし。(注・これは"Self"の話では無いです)

だから、たとえJava（のようなクラス指向のOO）が「真のOOではない」と研究者に言われても、
「そうなんだ」としか言えないし、今後も使って行くと思う。

...って所で考えるに、>>126の言う「OO厨」って、ちょっとリアルじゃない人の事だね。

以上、余談失礼。
133 ：122：03/01/02 21:11
>>128
俺に聞かれても知らないよ。　

確かに構造化ベースで考えて、
クラス機構は便利に使うという方針でやってたけどね。
134 ：デフォルトの名無しさん：03/01/02 21:12
あんまりここでオブジェクト指向についてガリガリ書くと、
また沢村がどこかの初心者向けスレで、さも自分で考えた風にエラソーにレスするぞ。
発見次第、要突っ込み。(w
135 ：128とか127ついでにJohn：03/01/02 21:35
>>132
プロトタイプ思考なOOってのはどういう意味？
仕様変更を想定した設計って意味に聞こえるんだけど。

>「いいところを使う」って感じで使ってるよ。
そもそもJavaには「いいとこ」しか言語機能としては
実装されていないというか、
名前忘れたけど、設計者が必要と思ったものしか
組み込んでないはずだけど。

どう考えてもポリモーフィズムは便利なんだが、
それを使いこなせていない人が多いと思う。
そんな人の設計はどうしてもクソになる。
設計には経験も必要だけれど、その前に知識が必要になるわけだ。
136 ：128とか127ついでにJohn：03/01/02 21:35
Javaやってる人の９割はポリモーフィズム知らない気がする。
２ｃｈに何度か書いているんだけれど
この動作がどんな物か想像できれば、ポリモーフィズムがわかるよって
奴。
class A{
pulic void write(){
print();
}
private void print(){
System.out.println("a")
}
}

class B extends A{
private void print(){
System.out.println("b");
}
}

int main(){
A a=new B();
a.write();
}

出力される物は何でしょう。
137 ：デフォルトの名無しさん：03/01/02 21:48
>>136
こんな例示してもポリモーフィズムの本質は語ってない。
Compositeパターン使ったDrawルーチンとか実際に役に立つ例でないと。
138 ：デフォルトの名無しさん：03/01/02 21:50
privateなものがoverrideされちゃあおかしいから
"a"だろうなあ。
139 ：デフォルトの名無しさん：03/01/02 21:53
猫がニャー、犬がワンが一番わかりやすいと思う。
140 ：132：03/01/02 22:01
>>135

＞プロトタイプ思考なOOってのはどういう意味？

すいませんが、↓この辺のやりとりを参照して下さい。

>>75 >>88 >>100 >>103 >>115 >>116 >>117 >>118　(特に>>88)

..要するに、Javaのような「クラス指向（設計図型？）OO」では無い、また別のOOの考え方の事です。
>>132でのソレは、↑のやりとりの中で出てきたものを指しています。
141 ：名無し＠沢村：03/01/02 22:16
>>138
"a"だろうなあじゃなくて、"a"だよ！！
俺はＪＡＶＡは知らないが、Ｃ＋＋OOからの類推でそれは断言できるよ！！
ヌヒはＪＡＶＡは知ってるが、OOをよく理解していないために自信なげなんだよ！！
142 ：デフォルトの名無しさん：03/01/02 22:18
>>141
じゃC++で書き直してみて下さいな
143 ：名無し＠沢村：03/01/02 22:19
>>142
そんなヒマはねーよ！！
144 ：デフォルトの名無しさん：03/01/02 22:22
C++ は virtual が付くかどうかだろ
145 ：デフォルトの名無しさん：03/01/02 22:22
"a"ではなくエラーメッセージと思われ
146 ：デフォルトの名無しさん：03/01/02 22:23
>>141
両方使ってるけど(現在JNIで苦戦中)、JavaもC++もクセが強すぎて
これらからOOを学ぶというのは無理があるなあと思うことしきり。

とはいえ、JavaやC++、.NET等を知らないでOO知ってますってのは、
知ったか小僧以下なんだがな。
147 ：デフォルトの名無しさん：03/01/02 22:37
プロトタイプベースわかったよ。
オブジェクト指向には
クラスベースとプロトタイプベースがあるのね。
なるほど。
で、プロトタイプベースの言語はself,javascriptなどと。

>>138
ナイスツッコミ。
privateは蛇足だった。
protectedにしといて。

>こんな例示してもポリモーフィズムの本質は語ってない。
役立つかどうかじゃなくて、
ポリモーフィズムがわかっているかどうか、を判定するテストだからね。
この結果がどうなるかを知る事で、役に立つわけじゃない事は１００も承知。
あくまでテスト。
まあ、文句があれば他のテストを考えて提示してくれ。
148 ：デフォルトの名無しさん：03/01/02 22:43
どうにもロマンティックが止まらんのだが、どうしたらいい？
149 ：デフォルトの名無しさん：03/01/02 22:48
>>145
true
150 ：デフォルトの名無しさん：03/01/02 22:56
みなさんの話は半分以上理解できません。
現在憂鬱本読んでいますが、オブジェクト指向を理解するために
次に読む本を探しています。なにか教えてください。

ちなみにJAVAは普通に使えるレベルです。
151 ：デフォルトの名無しさん：03/01/02 23:49
>>136
System.out.println("a") ←Java
int main() ←C(++)

コンパイルできなくね？
152 ：デフォルトの名無しさん：03/01/03 00:07
int main(String argv() )
ってことを言いたいの？
153 ： ◆F52DmOxJlc ：03/01/03 00:12
Java なら main() もクラスの中に書くでしょ。
static 宣言もしてないし。
154 ：デフォルトの名無しさん：03/01/03 00:17
>>136
>Javaやってる人の９割はポリモーフィズム知らない気がする。
んなばかな･･･
オブジェクト指向関係の入門書には間違いなく出てくるしょ
それとも本も読まずにJavaやってる人が大半だと？
155 ：デフォルトの名無しさん：03/01/03 00:21
スタージョンの法則を応用したんじゃない？
2:8 の法則と一緒で何にでも使える。
156 ：デフォルトの名無しさん：03/01/03 00:26
>>154
機能を知ってるかじゃなくて、どう使うべきか知らないという意味じゃない？
157 ：デフォルトの名無しさん：03/01/03 00:30
> それとも本も読まずにJavaやってる人が大半だと？

継承による実装のオーバーライドや
インターフェースの実装を知ってて、使ってる人だとしても、

ポリモーフィズムとは何ぞや？
ということを深く考える機会はあまりないと思う。
158 ：140：03/01/03 00:52
>>150
あまり本は読まなかったので、紹介するネタが無いんですが、
俺の中での、オブジェクト指向を理解する時のポイントは、
「オブジェクト指向とは！」って所から入らないって事です。
要するに、「とりあえずコードを書き、ルールとして理解する」。

俺が最初に読んだ本(Javaの)では、確かいきなり冒頭で「傘」の話が
始まったように記憶しています。

『傘には”雨を避ける”という意味があり、そこには”押すと開く”という
動作があり、また”大きさ、色、材質”等の属性がある』とか...。

最初はもちろん、「え？」って感じでした。

でも今では意味（どうしてそういう例が出たのか）はなんとなくわかります。
で、ある程度構文やルールがわかってきたら、後はそれらの「理由」を探る方向に
向かってみるといいです。

例えば「集約」「委譲」といった概念は「純粋なOO(？)」の世界の物では無く、
JavaやC++における「機能の説明でしかない」のですが、これが
「どうして必要なのか」とか「何をするものなのか」、またぶっちゃけ
「何の役に立つのか」っていう視点で掘っていくと、たぶんだんだん見えてくると
思います。

>>150が普通にJavaでコーディングできるのなら、後は内部の機構の「意味」をWeb等で
（単語単位でいいから）検索するなりして、掘っていくといいかもしれないです。
159 ：140：03/01/03 01:10
>>157
俺の中でのポリモーフィズムの認識っていうのは、単純に言葉どおり「多態性」のイメージでとらえています。
全てのクラス（物体の設計図）は、何がしかのルーツ(Javaで言うならぶっちゃけ、java.lang.Object)からの継承(派生)であり、
それらは、全て同じ祖先から、またその後それぞれに枝分かれした実装の多様性を持ったオブジェクトであるのだから、
例えば、「この処理は、文字列を検索します」とした時に、その「文字列って、誰？」の問いに対して、
「文字列を祖先に持つ物なら誰でもいい」っていう受け方ができた方が都合がいいし、また、
「文字列のように認識される（扱える）ものなら同じようにできた方が」便利だったりします。

実際、開発の時などは、大体こんな感じで大雑把に意味付けして、
クラス設計します。
160 ：デフォルトの名無しさん：03/01/03 01:39
なんでそんなたったひとつの機能についてうじうじこだわるの？
OO理解してないでしょ？
どう組んだってかまやしないでしょそんなところ。
そんな小さいところこだわってたら仕事進まないよ
そんなに君にとって大事なことなの？
161 ：デフォルトの名無しさん：03/01/03 01:43
「ｘｘ理解してないでしょ？」っていうとスカッてするのホント？
162 ：159：03/01/03 01:51
>>160
＞なんでそんなたったひとつの機能についてうじうじこだわるの？

うじうじですか(^_^;;
ていうか、感覚と認識の話です。...別にクラス設計の時にこれらをいちいち
ずーーーっと、考えてる訳ではないですよ。(当たり前

＞そんなに君にとって大事なことなの？

「意味」として固まってた方が、後でわかりやすいでしょ？
それだけです。
163 ：デフォルトの名無しさん：03/01/03 02:03
OO厨っぽくなってきたね
ワクワク
164 ：デフォルトの名無しさん：03/01/03 02:08
>>159
＞javaで言うならぶっちゃけ、java.lang.Object)からの継承(派生)であり、
モノリシックな継承階層なんて時代遅れだよ！
165 ：デフォルトの名無しさん：03/01/03 02:12
また話のﾚﾍﾞﾙが下がりそうなﾖｶｰﾝ＞ワクワク
166 ：159：03/01/03 02:18
＞モノリシックな継承階層なんて時代遅れだよ！
そうですか(^_^;;
実際、俺の中のOOって、Java止まりなんで..。
"Self"っていうプロトタイプベースOO言語の話もこのスレで知ったくらいだし...。
167 ：デフォルトの名無しさん：03/01/03 02:19
それが意味ないっつってんの。
俺はそういう小さい機能についていちいち定義付けを始めることが
すごくうざったいとすら思うよ。
誰がどうやって決めるのかは知らないけど、
どこにも定義されてない上に誰も形を認識していないのが現状だよ。
このスレと同じような内容を海外の掲示板でもみるよ。
要するにOOがあんまり大雑把すぎるから
みんな自分が理解できているか不安なんだよね。
だからどうでもいいようなOOの副産物に定義をし始めるんだと思うよ。
で、それをさもOOの本質みたいにいう沢村みたいなのがでてくるんだろ。
168 ：デフォルトの名無しさん：03/01/03 02:27
>>158
＞例えば「集約」「委譲」といった概念は「純粋なOO(？)」の世界の物では無く、
＞JavaやC++における「機能の説明でしかない」のですが、
なんだそりゃ。
169 ：デフォルトの名無しさん：03/01/03 02:35
167は162へのレスだす
170 ：デフォルトの名無しさん：03/01/03 02:39
>>166
JavaだってinterfaceによるMix-inで一種の多重継承をサポートしているでしょ。
単一の木構造モデルで物事を表すなんて最初から無理があるということ。
171 ：デフォルトの名無しさん：03/01/03 03:17
愚痴の垂れ合いは充分だから次世代言語作れや
172 ：デフォルトの名無しさん：03/01/03 04:02
>>170
単なる単語の使い方の問題だが、interface 継承は Mix-in とは呼ばない
と思われ…。

>>167
> どこにも定義されてない上に誰も形を認識していないのが現状だよ。
世界中の人間が同意する唯一絶対の経典はないけど、だいたい合意が取れてる
用語の使い方ってのは存在してる。

っつか世の中の学問なんて、どれもそんなもんだよ。定義がわりと明確な物理
学あたりだって、細かい部分になると専門家によって意見の相違があったりす
るし、経済学に関しては言わずもがな。（アナリストによって景気動向を正反
対に見積もったりするのは日常茶飯事、っつーのはニュース見てれば分かるわ
な）
173 ：デフォルトの名無しさん：03/01/03 11:52
>>168
集約とか委譲とか継承って、結局>>159氏が言うような、
クラスベースOOとしてのJava（とかC++とか）の機能でしかない、と。
だから、純粋にオブジェクト・オリエンテッドとして「絶対に必要」とかな
概念ではないと。たぶん、そういう意味なんじゃないかと思われ。
174 ：デフォルトの名無しさん：03/01/03 11:53
保守
175 ：デフォルトの名無しさん：03/01/03 11:57
ていうかオブジェクト指向って今も議論されていて、いろんな形でそれを
表現しようとしているんでしょ？
>>167も

＞どこにも定義されてない上に誰も形を認識していないのが現状だよ。

って言ってるけど、要するにそんなだから、

＞例えば「集約」「委譲」といった概念は「純粋なOO(？)」の世界の物では無く、
＞JavaやC++における「機能の説明でしかない」のですが、

って言ってるんじゃない？
176 ：プ：03/01/03 11:59
理解できないのにプライドだけは高い猿には、どうしても受け入れられない物らしい。
ただの便利機能でしかないのにね。
177 ：プ：03/01/03 12:00
あ、176は>>167へのレス。
178 ：デフォルトの名無しさん：03/01/03 12:06
>>173
「絶対に必要」 な概念ではないが、プロトタイプベースだろうと
集約や委譲として記述できるオブジェクト間の関係は生じると思うけど。

>>175
167 は指示代名詞ばかりで何言ってるかわからんから読み飛ばした。
179 ：デフォルトの名無しさん：03/01/03 13:18
OO死ねっつうか
糞憂鬱本死ね
と。
180 ：デフォルトの名無しさん：03/01/03 13:27
>>1-179
頭でなんとか理解した程度ではOOは使えない。
そんなおまいらはOOを使いこなせていないに10OO。
181 ：デフォルトの名無しさん：03/01/03 13:58
オブジェクト指向を理解してる人はこんな低レベルの議論には参加しない。
182 ：デフォルトの名無しさん：03/01/03 14:17
つうかまともなPGは2chなど来ない。
結城・引き篭もり・ガイキチぐらいだよ。
183 ：デフォルトの名無しさん：03/01/03 14:21
>>182
根拠がないっすよそれ。
184 ：デフォルトの名無しさん：03/01/03 14:22
GUIプログラミング以外にOOの必要はない。
GoFのパターンの使用例だってGUIばかりではないか。
185 ：デフォルトの名無しさん：03/01/03 14:25
>>182
true
186 ：マイク ◆yrBrqfF1Ew ：03/01/03 14:26
>GUIプログラミング以外にOOの必要はない。

そうかな？
憂鬱本のGUIのところなんて少し無理してる感じがするけど
187 ：デフォルトの名無しさん：03/01/03 14:30
GUI以外でもフレームワーク構築しようとするとき便利だけど。
188 ：デフォルトの名無しさん：03/01/03 14:48
>>182
まともなPG == ガイキチ なので
ほとんどみんな来てるはずですが？
189 ：188：03/01/03 14:50
あ、>>182 は書き間違ったんだね。
まともなコボラーはたしかに 2ch などには来ないかもしれない。
190 ：デフォルトの名無しさん：03/01/03 14:52
仕事ができるのが良いPG
人格がまともでも仕事ができなれば悪いPG
191 ：デフォルトの名無しさん：03/01/03 14:55
人として未熟なのであれば仕事なんて到底できるはずがない。

というのが国際社会の常識ですが？
192 ：デフォルトの名無しさん：03/01/03 15:00
人として成熟していてもスキルがなければ仕事はできない。

というのが現実ですが？
193 ：デフォルトの名無しさん：03/01/03 15:23
>>191
だから仕事ではなくて作業をさせられるわけだ。
194 ：デフォルトの名無しさん：03/01/03 15:31
外注丸投げで仕事をした気になっていますが、なにか？
195 ：デフォルトの名無しさん：03/01/03 15:33
>>193
そりゃ仕方ないだろう。
自分が悪いんだから。
196 ：デフォルトの名無しさん：03/01/03 15:36
>>194
逝ってよし
197 ：デフォルトの名無しさん：03/01/03 15:40
これから必要とされる人材は
・外注丸投げ
・外注尻叩き
のデキる人ですが何か？
198 ：実話：03/01/03 15:59
漏れが1日で書いたソースを却下し、1週間かけて自分で書き直した上司。
却下の理由は、仕様書では固定長配列使って組む事になってる部分を、
vector+mapで組んでたから。

仕様を無視した漏れも悪いとは思うが、レビュー済みだからって
どう見てもウンコな仕様書を直さず、ソースを１から書き直す上司もどうかと思った。
（でもスパゲティーにも関わらず、問題なく動くソースはある意味スゴかった）

流石は2ちゃんねらー。(しかも●波板住人)
199 ：デフォルトの名無しさん：03/01/03 16:08
asso
200 ：!：03/01/03 16:17
>>198
うわ
酷いね
糞上司じゃん
201 ：デフォルトの名無しさん：03/01/03 16:39
>>198
仕様書と設計書の区別がないのね。
そりゃ変更が面倒だわ。
202 ：デフォルトの名無しさん：03/01/03 18:00
恒例のOO派ｖｓ非OO派　アプリ制作対決しないの？
203 ：デフォルトの名無しさん：03/01/03 18:15
OO派に一票。
但し必要なければOOにこだわることはしない。
204 ：デフォルトの名無しさん：03/01/03 18:16
OO厨は肝心な実装ができません。
なのでアプリは作れません。
205 ：デフォルトの名無しさん：03/01/03 18:35
非OO厨は誰も読めないゴミコードしか書けません。
なのでプロジェクトから追い出されます。
206 ：デフォルトの名無しさん：03/01/03 20:13
class A{
pulic void write(){
print();
}
protected void print(){
System.out.println("a")
}
}

class B extends A{
protected void print(){
System.out.println("b");
}
}

int main(){
A a=new B();
a.write();
}

だとすれば
出力はbだね。
ってか、これがわかなかった人いるの？

>GUIプログラミング以外にOOの必要はない。
おまえはGUIプログラミング以外になんか知ってるの？
JAVAのライブラリの中身でも見てみれば？
207 ：デフォルトの名無しさん：03/01/03 20:15
>>1-206
一生やってろ。
208 ：デフォルトの名無しさん：03/01/03 20:18
>>206
シンタックスエラーだろ
でじゃぶ
209 ：名無し＠沢村：03/01/03 20:29
ヌヒ等よ、俺はOOを文法としてとらえてるよ。
Ｃ＋＋の文法としてね。これはちゃんとしたプログラムをつくるための文法だよ。
ただＣ＋＋の文法の下部構造としてＣの文法があり、この下部構造だけでもプログラムがつくれちゃうことから、OO厨と非OO厨の対立が生まれるのだと思うよ。
この二重構造性はとりあえず非OOで手っ取り早くプログラムを仕上げ、将来のためにあとでゆっくりそれをOOで聖書するときに便利だよ。
つまり非OOは手っ取り早くつくるのに向いているし、OOは一生の財産とするためにじっくりつくるのに向いていると思うよ。
210 ：166：03/01/03 20:31
ぶっちゃけ俺は、別に「OOが全て！」「OOこそ最強！」とかは思って無いです。
もちろん興味があるし、いい感じのクラス設計（もちろん一人で設計..とかじゃないですよ、念のため）
とかできると、気持ちよかったりします。

ていうか、「JavaベースのAPサーバでWebシステム開発」とかになったら、当然
問答無用でOOな言語(Java)を(開発担当者は)全員使うわけで。
その上で詳細設計の際に、効率とか再利用性を考えるなら、柔軟な、汎用的なクラスまでも意識して
クラス設計した方が、無駄な工数使う必要も無い訳で。

きちんと意味的な分割が徹底されていれば、保守性も上がる(ていうか問題点を特定し易くなる)ワケだし。

...って、別に上記のポイントを押さえられるのがOOしか無い！って話では無いですよ。
ただ、言語仕様的にそれらを表現しやすいかなーと思ってるだけで...。
211 ：166：03/01/03 20:32
あ、ageちゃった(^_^;;
失礼
212 ：166：03/01/03 20:33
↑再び失礼。
213 ：デフォルトの名無しさん：03/01/03 20:38
「オブジェクト指向は、それが意味をもつ場合に使い、そうでないときには避けること。」
214 ：デフォルトの名無しさん：03/01/03 20:42
OOの真髄は言語(文法)とか実装レベルじゃなくて、分析・設計レベルでしょ

沢村根本的に間違ってるよ
OOと構造化は分析・設計段階で大きく異なるわけだから、
C++で実装された非OOなプログラムをOOにするには、
分析・設計からやり直さなければならない。

>この二重構造性はとりあえず非OOで手っ取り早くプログラムを仕上げ、将来のためにあとでゆっくりそれをOOで聖書するときに便利だよ。
┐(ﾟ～ﾟ)┌　よくこんなことする気になるね

ということで、沢村はアセンブリでもやってな。
OO語るな。
215 ：名無し＠沢村：03/01/03 20:43
Ｃ＋＋のコンパイラはＣの文法だけで書かれたコードを受け付けないようにするといいね。
最低、仮想関数、継承、const修飾子、コンポジションが入ってないコードはコンパイルエラーになるようにするとかね。
「エラー～仮想関数が定義されていません」とかね。
そうすれば非OO厨もいやがおうでもOOを覚えざるを得ないよ。
216 ：デフォルトの名無しさん：03/01/03 20:47
>>215
無茶言うな。
217 ：デフォルトの名無しさん：03/01/03 20:48
>>215
ちょっと同意。
なんちゃってクラスがコンパイルエラーになるのは嬉しいね。
最低インターフェイス定義が必要とか、Javaもそうなればいいのに。
218 ：デフォルトの名無しさん：03/01/03 20:55
>>215
沢村さんったら最高♪
219 ：デフォルトの名無しさん：03/01/03 20:56
ある意味沢村はＯＯの適用先が良くわかってないヤツの代表という事で、
これはこれで面白いかもしれない...(藁
220 ：デフォルトの名無しさん：03/01/03 20:58


今年も、、今年こそ、、
いい思いをしちゃいましょう(^▽^)v

http://ok.halhal.net/~2ch/


221 ：デフォルトの名無しさん：03/01/03 20:58
>>215
C#でいいじゃないの
222 ：デフォルトの名無しさん：03/01/03 21:01
>>215
強制はアレだけど、面白いかもしれない。
ていうか、コンパイラに「ＯＯ判定を強制する」スイッチとか付けてさ。

いやー、真性厨房沢村も、たまには面白い事言うね。
223 ：名無し＠沢村：03/01/03 21:01
>>221
すまん、C#はいじったことがないの。それからＮＥＴ何とかというのも…^^;
224 ：デフォルトの名無しさん：03/01/03 21:05
>>214で叩かれていながら平然と穏やかな書き込みを続ける沢村先生は実は人格者なのかもしれない。
225 ：デフォルトの名無しさん：03/01/03 21:07
必要もないのに仮想関数使うとパフォーマンス悪くなるよ
226 ：デフォルトの名無しさん：03/01/03 21:12
パフォーマンスチューニングは後にすれ。
227 ：名無し＠沢村：03/01/03 21:37
>>225
ごく短いプログラムならいざしらず、ある程度以上の大きなプログラムの場合、仮想関数は必要ではないが、使わないより使ったほうがいいよ。
使わないほうがいい場合など有り得ないと、近頃そう思うよ。
228 ：デフォルトの名無しさん：03/01/03 21:45
>>227
必要になった時点で virtual 宣言すれば問題ないのではないですか？
また、ポリモーフィズムが必要な局面は、設計の早期に判別できると思うのですよ。
229 ：デフォルトの名無しさん：03/01/03 21:49
やっぱりアプリ制作対決を
230 ：デフォルトの名無しさん：03/01/03 22:14
>>215 あのですね、字面から OO を判定するのはあんまり意味ないと
思うわけですよ。そーゆう機能使ったら OO ってのは全然真じゃない。
むしろよくわかってないなんちゃって OO なヤシが増えるだけだろ。
OO 的な設計を支援するためのツールでも使わせたほうがましでしょう。
231 ：デフォルトの名無しさん：03/01/03 22:18
【適材適所】
232 ：デフォルトの名無しさん：03/01/03 22:21
>>230 うっさい。九州にｶｴﾚ！
233 ：名無し＠沢村：03/01/03 22:25
ヌヒ等よ、OOっていうのはある意味で必要だともいえるし、必要でないともいえるよ。
英語はアメリカ人にとっては必要だが、日本人にとっては必要なく、日本語があればいいのだからね。
でも日本人にとっては日本語は必要だよ。
それと同じでOO厨にとってはOOは必要で非OO厨にとってはOOは必要ないよ。
ただ英語ができる日本人に英語ができない日本人はコンプレックスを持つだろうね。それだけだよ。
234 ：デフォルトの名無しさん：03/01/03 22:26
なんか口ばっかで足腰の弱そうな香具師だな｡
235 ：デフォルトの名無しさん：03/01/03 22:27
素朴な疑問なんだが、>>230 が九州の人ってどーやって見分けたの？
236 ：名無し＠沢村：03/01/03 22:30
>>232
ヌヒよ、>>230が九州人だと見抜いたのは偉いが、俺が九州人だとまでは見抜けなかったようだな。いまいちだな、ヌヒは。
せっかく「ヌヒ」というのがヒントだったのにな…。
ヌヒ等よ、俺も九州人だよ。
237 ：デフォルトの名無しさん：03/01/03 22:31
それよりも仕様書を保守要員(シス管)がソースコードから起こす
悲惨なプロジェクトに放り込まれた僕を何とか救ってください。
238 ：デフォルトの名無しさん：03/01/03 22:31
一説によるとOO厨は九州出身者が多いそうです。
239 ：名無し＠沢村：03/01/03 22:38
OO厨房は戦場では必要無しというのは、アナウンサーのようなきれいなしゃべりかたが野蛮な実社会では必要なし、というのと似てるね。
240 ：デフォルトの名無しさん：03/01/03 22:44
>>238
どんな一説だよ！
241 ：デフォルトの名無しさん：03/01/03 22:44
設計に時間をかけるかデバグに時間をかけるかということだね。
242 ：デフォルトの名無しさん：03/01/03 22:45
設計のほうが、夢があって楽しいな・・・
243 ：hage：03/01/03 23:03
>>242
夢が現実の悪夢となって帰ってくるんだよ。
このブタ野郎♪
244 ：デフォルトの名無しさん：03/01/03 23:12
　　　　　　　　　　　　　／￣￣￣￣￣
　　 　　,＿＿　　　　　|　 243 ：hage が一生悪夢に付きまとわれますように・・・
　 　 ／　　.／＼ 　　　＼＿＿＿＿＿
　 ／　　.／( ・ ).＼ 　　　　　　o〇　 　 　　 ヾ!;;;::iii|//"
／_____／ .（´ｰ｀）　,＼　　 ∧∧　　　　　　 　 |;;;;::iii|/ﾞ
￣|| || || ||. |っ￠..||￣　　（,,　　,）　ﾅﾑﾅﾑ　　 |;;;;::iii|
　 || || || ||./,,,　|ゝ iii~ 　　⊂　　ヾｗｗｗｊｊｒｊｗw!;;;;::iii|ｊｗｊｊｒｊｗw〃
　 |￣￣￣|~~凸（￣）凸　.（　　　）～　ｗｊｗｊｊｒｊ从ｊｗｗｊｗｊｊｒｊ从ｊｒ
245 ：デフォルトの名無しさん：03/01/03 23:39
沢村よ。なんか気づいてみれば、このスレの最初の方の書き込みと現在の話っぷり。
ずいぶん進歩(※１)したようだな。
そうとうあちこち調べて回ってたろ。(w

※１・正しい事を言っているとかじゃないヨ。良く考えるようになった、って意味だＹＯ。
246 ：デフォルトの名無しさん：03/01/03 23:43
ところで、COMって、ＯＯなん？
247 ：デフォルトの名無しさん：03/01/03 23:47
あと、他のスレで撃沈されて打たれ強くなった気もする。
248 ：デフォルトの名無しさん：03/01/03 23:51
そうやって成長していくのさ。2chでなww
249 ：デフォルトの名無しさん：03/01/04 09:04
>>246
staticだけどdynamicなOO
250 ：デフォルトの名無しさん：03/01/04 11:28
結論として
OOするにはポリモーフィズムの壁があって
これを超えてないのに
OOできたと思ってるバカが多く存在し
そいつらはバカであると。
しかし、ポリモーフィズムの壁を越えてない奴は
一律にばかであると。
そして、OOがなんなのかわかっていない。
251 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/01/04 11:40
出たなポリモ厨
252 ：デフォルトの名無しさん：03/01/04 12:02
だから一つの機能についての解説はOOと結びつかないっていってんだろ沢村ぁ！
253 ：デフォルトの名無しさん：03/01/04 12:04
>>250
こらこら、あんまり人をバカバカって言うもんじゃないよ。

それに、ポリモーフィズムってオブジェクト指向の中でそんなに重要な位置を占めてるのか？
まさか「同じメソッドを呼び出した場合でも、現在参照しているオブジェクトの種類によって異なる動作をする」なんて言うつもりじゃあ　な　い　よ　な　？
そいつは遅延束縛ってんだが……。
254 ：デフォルトの名無しさん：03/01/04 12:18
＞出たなポリモ厨

これを "ポリモ蟲"って書くと、なんかすごい嫌な虫が体の中に巣食っているように
見えて怖い。頭が複数(Poly)あるとか。じゃその時の、"モ"ってなんだ。
255 ：デフォルトの名無しさん：03/01/04 12:19
ポリモ厨ってうざいよね
ポリモごときで何ができるっていうんだろう
256 ：デフォルトの名無しさん：03/01/04 12:19
そしてそんな状態もある意味「人体」に対しての「集約」とか言うんだろうか（w
257 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/01/04 12:38
犬がワンワン猫ニャーニャーの入門書でも読んだんだろ。
258 ：デフォルトの名無しさん：03/01/04 12:46
おまい、修飾語が離れてて読みづれーな。

プロか逝ってよしかどっちかに絞れよ。
259 ：デフォルトの名無しさん：03/01/04 12:48
多態はﾃﾞｻﾞﾊﾟﾀ本読んで初めてOO的だってわかった
継承よりも重要な概念だと思うが
260 ：デフォルトの名無しさん：03/01/04 12:51
こことリンク

【C++】2ちゃんねらーはOO嫌い？【Java】
http://pc3.2ch.net/test/read.cgi/tech/1026974531/
261 ：デフォルトの名無しさん：03/01/04 13:01
>>52
グローバル変数違う。
結城浩のデザインパターンの本でも読ぬ!
Javaではグローバル変数の使用を禁止しているが
それでもシングルトン使える。

>>160
うじうじいいたくなるのは、学生としてOOを使っている人が多いからじゃないかな?
仕事で使っているんじゃなく、OOそのものの研究をしている人たちなんじゃないかな?

>>233
おい、澤村氏よ。非OO厨にとってOOは必要ないというが、それでは完全OO使用を前提とするプロジェクトで活躍できないぞ。
非OO厨が嫌でもOO使わされる。いやいやながら使うわけだからプロジェクトにのめりこむのに時間がかかる。
嫌いなOOを必死で理解しなければならないんだからな。
staticメソッドばかり使うなとかちゃんとクラス作れ作れとかモジュール分割しろとか抽象クラス作れ作れとか文句言われるぞ。
262 ：デフォルトの名無しさん：03/01/04 13:26
継承もポリモも所詮はOOの副産物ということをわすれてはならん。
263 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/01/04 13:29
OO厨にとってOOは必要ないというが、それでは完全非OO使用を前提とするプロジェクトで活躍できないぞ。
264 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/01/04 13:57
ああ、はずしちゃった
265 ：デフォルトの名無しさん：03/01/04 14:04
>>263
> OO厨にとってOOは必要ないというが、それでは完全非OO使用を前提とするプロジェクトで活躍できないぞ。
"OO厨にとって非OOは必要ないというが" の間違いでない?
というか、OOは非OOを包含している部分があると思うのだが。笑えるぞ。
これはC++のような中途半端OOではなくJavaのような完全OOの場合の話だが。

OOを知っている者は非OOでも簡単にプログラミングできる。
だが、その後にソフトの巨大化で苦しむのは、OO厨も非OO厨も一緒。
このとき、OO厨は「だからOOを使えと言ったんだよ」と文句を言うだろう。
場合によってはOOで作り直すかもしれないな。

こういうプロジェクトの場合は、OO厨は、(使える言語なら)構造体をクラスの代用として使用するよ。
ポリもーフィズむとか言ってランないけど、それも集約(構造体の構造体)で(それらしく代用できないが)代用するだろう。
266 ：デフォルトの名無しさん：03/01/04 14:04
話が長くなるのでこのスレでは最低限
OO⊃{カプセル化､　継承､　多態} を前提にして､
非クラスベースなOOPLはマイナーOOPLスレ立ててやってくれよ｡

そうすれば大半のｳﾞｧｶを排除できてスレがすっきりするよ｡
267 ：デフォルトの名無しさん：03/01/04 14:15
>>266
胴衣。ていうかスレの主旨に基づいていうなら、このスレって、
「OO厨房は戦場では必要無し！」だから「OO厨は戦場で必要かどうか」を、
話すスレなのではと言ってみるテスト。
268 ：デフォルトの名無しさん：03/01/04 14:20
OO「厨房」についてのスレなら板違いだろう｡
せめてOOを理解した上でなお向かないプロジェクト､
失敗したプロジェクトについて騙ってくれよ｡
269 ：Java曹長：03/01/04 14:30
スレ立ててみました。

【OO?】オブジェクトオリエンテッド総合【非OO？】
http://pc3.2ch.net/test/read.cgi/tech/1041658161/
270 ：デフォルトの名無しさん：03/01/04 14:31
>>268
スレ違い
271 ：デフォルトの名無しさん：03/01/04 14:36
>>270
板違い
272 ：デフォルトの名無しさん：03/01/04 14:37
>>271
終了
削除依頼よろ
273 ：デフォルトの名無しさん：03/01/04 15:06
具体的にOO厨房からどんな迷惑を被ったかという経験談を聞かしてほしい。
274 ：デフォルトの名無しさん：03/01/04 15:09
>>273

　ウザかった
というか
　ウザイ

　　ウ　　ザ　　イ
275 ：デフォルトの名無しさん：03/01/04 15:11
>>273
それは愚痴スレで。

ていうか、あっと言うマにレベル下がったな、このスレ...。
276 ：デフォルトの名無しさん：03/01/04 15:13
レベル最高潮のレス番教えてください｡
277 ：デフォルトの名無しさん：03/01/04 15:18
274がスパゲッチーなコード書いていたので、
注意してやったら逆切れされた。
278 ：デフォルトの名無しさん：03/01/04 15:37
"OO厨にとって非OOは必要ないというが" の間違いでない?というか、OOで作り
直すかもしれないな。こういうプログラミングできる。だが、その後にソフト
の巨大化で苦しむのは、OO厨も非OOは必要ないというが" の間違いでない?と
いうか、OOは非OO厨も非OO厨も一緒。
279 ：デフォルトの名無しさん：03/01/04 15:39
日本語喋って下さい
280 ：デフォルトの名無しさん：03/01/04 15:39
過信しすぎですね自分で作ったわけでもないのに:-)設計バカなど死ねばいい。
トリップつけたOO厨は糞!
281 ：274：03/01/04 15:41
あはは
OO厨は必死ですね:-)
282 ：trip ◆6AcxUE04XA ：03/01/04 15:43
へぇ
283 ：trip ◆6AcxUE04XA ：03/01/04 15:43
284 ：デフォルトの名無しさん：03/01/04 15:43
OOは非OOを包含している部分があると思うのだが。笑えるぞ。これはC++のよ
うな中途半端OOではなくJavaのような完全OOの場合の話だが。OOを知っている
者は非OOでも簡単にプログラミングできる。
285 ：trip ◆u2YjtUz8MU ：03/01/04 15:48
>OOは非OOを包含している部分があると思うのだが。

へぇ。
で、どこ？
286 ：デフォルトの名無しさん：03/01/04 15:54
Java が *完全* OO ですか…。あんまり他人に言わないほうがいいよ。
恥ずかしいから。せめて相手が Smalltalker じゃないことを確認
したほうがいい。あとね、世の中 OO だけじゃないことを知っといた
ほうがいいと思うな。おじさんは。
287 ：デフォルトの名無しさん：03/01/04 15:56
昔懐かしの純準論争ですか｡
あんまり議論をふっかけないほうがいいよ｡
恥ずかしいから｡せめて２ｃｈだけにしておこうね｡おっさん｡
288 ：デフォルトの名無しさん：03/01/04 15:56
OO厨にボコボコに言われるコンピュータ言語（というかロジック）をそのよう
なきれいなしゃべりかたが野蛮な実社会では必要なし、というのと似てるね。
抵抗勢力と呼ばれ徐々に滅びていくでしょ。static 宣言もしているでしょ。
単一の木構造モデルで物事を表すなんて最初から自分の実行内容を持ってく
る」っていうのが現状だよ。って感じ。
289 ：デフォルトの名無しさん：03/01/04 15:57
>>288
スパゲッティなレスですね。
リファクタリングしてください。
290 ：デフォルトの名無しさん：03/01/04 15:58
OOってのはC++のような中途半端OOではない。Javaやってる人の９割はポリモー
フィズム、多態というOOの３要素を全部使ってる。おしゃれにしたのだと思う
よりは他に確立したまともな開発手法がないからooやってるにすぎないです。
Lisp なんかは保守性にかんしてはどうな。
291 ：デフォルトの名無しさん：03/01/04 16:02
>>285 クラス無いにあるメソッドを全部staticにすれば非OOとかわらんでしょう。

>>286
> Java が *完全* OO ですか…。あんまり他人に言わないほうがいいよ。
> 恥ずかしいから。せめて相手が Smalltalker じゃないことを確認
> したほうがいい。あとね、世の中 OO だけじゃないことを知っといた
おじさんのために「C++と比べて」を追加すべきだったかな。
ここでいう完全オブジェクト指向、とは100%完全と言うものではなく、
C++やC#と比べOO的であるってことよ。
そりゃ確かにJavaはSmallTalkよりOO的でないけどな。

まあ余計な突っ込みはいれんことよ。
292 ：デフォルトの名無しさん：03/01/04 16:09
>>291
何を基準に 「より OO」 「より OO でない」 といっているわけ？
このスレは論点もなく議論をしているのが笑える。
293 ：デフォルトの名無しさん：03/01/04 16:17
>>291 お前の脳内では「完全 OO」= 「C++ より OO 的」が常識なのか…
OO 以前に日本語勉強したほうがいいんじゃねーか。
294 ：デフォルトの名無しさん：03/01/04 16:20
MFC（GUI関連）に関してはなるべく薄いAPIラッパーをオブジェクト指向で作
ろうと思うとあんな感じになると思う。もちろん、JAVAみたいに完全にオブジェ
クト指向で作ってくれたほうが使いやすいけどね。OOは非OOを包含している部
分があると思うのだが。これはC++のような中途半端OOではなくJavaのような
完全OOの場合の話だが。
295 ：デフォルトの名無しさん：03/01/04 16:21
>JAVAみたいに完全にオブジェクト指向で作ってくれたほうが使いやすいけどね。

でもAWTやSwingが糞呼ばわりされてる事実はどうしょうもないです
SWTの人気度がそれを物語ってます
296 ：デフォルトの名無しさん：03/01/04 16:24
Java好きも結構だけど、C++を貶めなくてもいいだろう。
297 ：デフォルトの名無しさん：03/01/04 16:25
>>293
> >>291 お前の脳内では「完全 OO」= 「C++ より OO 的」が常識なのか…
> OO 以前に日本語勉強したほうがいいんじゃねーか。
2chでそんなこと言っても無駄無駄無駄無駄
くだらないことで揚げ足とってお前も暇人だのう。幼稚な奴と思われるぞ。

298 ：デフォルトの名無しさん：03/01/04 16:29
>>286
> Java が *完全* OO ですか…。あんまり他人に言わないほうがいいよ。
> 恥ずかしいから。せめて相手が Smalltalker じゃないことを確認
キミも恥だな。わしはこの程度のこと書いても恥だと思わんが。
Javaを完全OOと言っている書籍やサイト、ニュースサイトは沢山ある。

キミは本当に世の中を見ているのかな? 澤村君よ
299 ：デフォルトの名無しさん：03/01/04 16:30
>>294
Java の GUI モデルは、低レベル API のラッパライブラリに比べれば
強度に MVC アーキテクチャに則ったものである、とは言えるが。
「完全にオブジェクト指向」 ってナニ？

>>295
反応速度が良くなかったり、レスポンスが Windows ネイティブと異なったりするのは、
オブジェクト指向とはまた別の話だろう。
オブジェクト指向で設計した結果それらの欠陥が生じたというなら合っているが。
300 ：デフォルトの名無しさん：03/01/04 16:32
Javaは整数のような基本型がオブジェクトじゃないよね。
世の中には全てのデータ型をオブジェクトと定義する純粋なOO言語もあるんだよ。
301 ：デフォルトの名無しさん：03/01/04 16:36


　こ　の　ス　レ　に　人　工　無　能　が　降　臨　し　て　い　ま　す　！　！
302 ：デフォルトの名無しさん：03/01/04 16:37
>>300 それがSmallTalkといいたいんだろ
303 ：デフォルトの名無しさん：03/01/04 16:39
>>300
だから性能に問題が・・・
304 ：デフォルトの名無しさん：03/01/04 16:40
>298 愉快なやつだな。間違った本やサイトがたくさんあったら
間違いが正しくなるのか？ Java はなぁ、効率を優先してあえて
基本型を区別してるんだよ。わざとやってるのにそれを「完全」と
言うのはどうよ？
305 ：300：03/01/04 16:41
優劣の問題じゃなくて、OOPLにも様々あって、
その内一つを完全なOOと決め付けるのは無茶だということ。
306 ：デフォルトの名無しさん：03/01/04 16:45
性能面ではやはりC++が・・・
307 ：デフォルトの名無しさん：03/01/04 16:46
まあウェボサイトのことをホームページと言ったり、
重複(ちょうふく)を「じゅうふく」と読んだり、
みんなが間違えばそれが正解になってしまうっていう事もあるとは思うが、

それでも Java は完全 OO じゃないよなぁ。
308 ：デフォルトの名無しさん：03/01/04 16:47
>>304
> >298 愉快なやつだな。間違った本やサイトがたくさんあったら
> 間違いが正しくなるのか？ Java はなぁ、効率を優先してあえて
> 基本型を区別してるんだよ。わざとやってるのにそれを「完全」と
> 言うのはどうよ？
そんなことでJavaがSmallTalkよりオブジェクト指向的だと思いこむ香具師がいるか?
309 ：デフォルトの名無しさん：03/01/04 16:48
>>303
速度を気にするなら CLOS でも使ってくれ。
310 ：デフォルトの名無しさん：03/01/04 16:49
いまどき完全かどうかなんて意味ねーよ｡
純粋なOOPLであるSmallTalkが撃沈してしまったので､
各言語とも実装に工夫をせざるを得なくなってそ
の結果言語仕様にも影響がでてしまったってことだろ｡

Rubyはその辺うまくやってはいるが､全体が遅いのが玉に瑕(藁
311 ：デフォルトの名無しさん：03/01/04 16:51
>>306
漏れは C++ 使いだが、残念ながら最近は仮想機械前提系の言語に
実行時性能で押されているという話を聞くが？

それでも C++ でやらなきゃいけない事っていうのは
C++ じゃなきゃできない環境か、Java みたいな安全装置たくさんの言語だと
どうしても回り道が多すぎる部分の仕事だが…。

もはや性能で言語を選ぶ時代は終わったよ。
312 ：デフォルトの名無しさん：03/01/04 17:06
>>306 ハイスペックマシンでも自作しる!
313 ：デフォルトの名無しさん：03/01/04 17:49
>>298
書籍やサイトに書いてあれば真実、か。
おめでてーな。
314 ：デフォルトの名無しさん：03/01/04 17:58
C言語の構造化プロブラミングで関数をきちんと規定してプログラムするのと
C++言語のオブジェクト指向でクラスをきちんと規定してプログラムするのと
どちらが、大掛かりなプログラムで効率がよいかを明確に示せば誰もが
納得すると思うけど。
315 ：デフォルトの名無しさん：03/01/04 17:59
>書籍やサイトに書いてあれば真実、か。

その通りです。
316 ：デフォルトの名無しさん：03/01/04 18:13
>>314
効率とは
パフォーマンスのことですか？
生産性のことですか？
保守性のことですか？
再利用性のことですか？
317 ：デフォルトの名無しさん：03/01/04 18:36
>>315 >>315
まあ　>>308　をよんでくれ。
真実だとは思わんが、そういう書籍があるということだ。
完全と書いてあるが100%完全でないというだけ、で十分だ。
318 ：名無し＠沢村：03/01/04 19:52
ヌヒ等よ、Java は完全 OO云々の話題が出ているが、俺はJavaは知らん。
俺はJavaは知らんが、Javaってホームページにアプレットを表示するためのホームページ言語というのが俺の認識よ。
だからそんな限定された言語なんか時間の無駄で勉強する気になれなかったわけよ。
実際はどうか知らんが、イメージとしてはそうよ。
319 ：デフォルトの名無しさん：03/01/04 19:55
> Javaってホームページにアプレットを表示するためのホームページ言語

今も大して変わってないことに気付いた。
アプレットじゃないけど。
320 ：デフォルトの名無しさん：03/01/04 19:59
再利用性を考えてクラス作るのは難しい。
あとJavaは動作が遅すぎてどうにもならない。
321 ：デフォルトの名無しさん：03/01/04 19:59
>>318
沢村さんはCGIとかは作らないのでしゅか？
322 ：デフォルトの名無しさん：03/01/04 20:03
沢村先生はＰ２Ｐを極めようとなさっているのです。
323 ：デフォルトの名無しさん：03/01/04 20:08
>>318
漏れ、仕事でJavaのAPサーバ(IBM WebSphere)使ってるけど、やっぱりJSP＋Servlet＋Beanっていう
MVCな開発スタイルが基本的に知られているサーバサイドJavaって、楽だぞ。見通しのいいコード書けば、だけど。
重いのが玉に傷だが。(w
ていうかJavaって漏れの中の認識では、サーバサイドの開発用って感じ。

そんな「ホームページ言語」程度の認識しか無いんだったら、確かに勉強するだけ
時間の無駄かもな。
324 ：デフォルトの名無しさん：03/01/04 20:08
>>320
>再利用性を考えてクラス作るのは難しい。
再利用性を考えてクラス作るのは*あんたには*難しい。
>あとJavaは動作が遅すぎてどうにもならない。
聞いててはずかしいので昔のPC板に逝ってください。
325 ：デフォルトの名無しさん：03/01/04 20:12
>>320
＞再利用性を考えてクラス作るのは難しい。
＞あとJavaは動作が遅すぎてどうにもならない。

この２つに関連は無いと思うが。
ていうか、再利用性を考えないクラス設計って、意味無いじゃん。
ま、もっとも一人で、趣味でやる分にはめんどくさいのかもしれないけど。

仕事で便利な汎用クラスとか作ったら、後の資産になるわけじゃん。
案件のケース毎に適用できるMyAPIとかあれば、工数も減らせる訳だし。
徹夜も減るかもしれないし（藁
326 ：デフォルトの名無しさん：03/01/04 20:15
> 再利用性を考えないクラス設計って、意味無いじゃん。

学生ってことがこれでバレちゃったねえ
327 ：デフォルトの名無しさん：03/01/04 20:16
>>320 と >>324-325
ＯＯを理解できない派 と できる派の意見の相違のモデルケース。
328 ：325：03/01/04 20:22
>>326
"再利用性を"、"考えない"、"クラス設計"って、意味が無いじゃん。
再利用しないクラスなんて、いくらでもあるさ。
固有のビジネスロジックを詰めたBeanとかさ。でもそれにしたって、
インタフェース(あるいは抽象クラス)ぐらい定義して継承とかするだろが。
それだって、「将来の利用を考慮」とかの意味で「再利用を考慮」する事になるだろが。
329 ：デフォルトの名無しさん：03/01/04 20:23
>>318
> ヌヒ等よ、Java は完全 OO云々の話題が出ているが、俺はJavaは知らん。
> 俺はJavaは知らんが、Javaってホームページにアプレットを表示するためのホームページ言語というのが俺の認識よ。
> だからそんな限定された言語なんか時間の無駄で勉強する気になれなかったわけよ。
「JavaといえばApplet」とは7年前の認識。
Javaは、C++からセキュリティホールやバグの原因になりやすい余計な機能を徹底的に切り落としたようなもの。
実際Javaを使った人々はC++の欠点を参考にしてJavaを作った。

C++よりネットワークに強く、セキュリティに強く、メモリリークの原因となるバッファーオーバーフローを
起こす心配もなく、プラットフォーム非依存性が高いことがJavaの強み。
C#もこれをすべて真似しているがどんなコードを書こうがバッファーオーバーフローは常に避けられるかというとそうでもない。

今はAppletに加え携帯電話にServlet/JSP、J2EE。
それ以外にC/C++と同じようにコマンドラインで実行できるApplication。
Javaは家電製品を遠隔操作するために生まれたということだけは認識しておけ。
その技術がJini。
P2PやるならJxtaもいいと思われるがどうだろうか?
330 ：デフォルトの名無しさん：03/01/04 20:28
でも今も「Javaといえばアプレット」・・・・
331 ：デフォルトの名無しさん：03/01/04 20:32
>>330
アプレットっていう言葉がね。
「C++でアプレット」とか「VBでアプレット」って言わないもんね。（そりゃそうだ）
言葉が一人歩きして、有名になっちゃったもんだからさ。

ま、「藤田まこと」と言えば「中村主水」みたいなもんさ。
332 ：デフォルトの名無しさん：03/01/04 20:34
再利用を考えてクラスを作るのが難しいとかほざくヤツは、
オブジェクトを使わないで関数を作ったとしても再利用できないソースになる。

つまり、ダメなヤツは何をやってもダメなわけ。
333 ：デフォルトの名無しさん：03/01/04 20:43
>>332
じゃ再利用性とOOは関係ないってことか。
334 ：デフォルトの名無しさん：03/01/04 20:52
いや、再利用「しやすさ」には大いに関係があるよ。
スゴイプログラマに対しては、限界を取り払う効果が期待できる。
その意義を知らないダメプログラマの場合は、>>332参照。
335 ：デフォルトの名無しさん：03/01/04 21:04
正直、漏れも再利用性が高いクラス設計（特にフレームワーク）には自信がない。
優れた設計を行うには経験の蓄積が必要なのではないかと思う。
336 ：320：03/01/04 21:05
趣味でやってるから駄目プログラマです。
たとえば一番元になるクラスはどう作れば良いだろうとか
ＯＯは設計の要素が不可欠だと実感しただけです。
Javaって起動とか遅くないですか？
337 ：再利用万歳：03/01/04 21:10
うちの近所では、XMLパーサエンジンを自作してる馬鹿がいる。
FTPサーバ/クライアントを自作している馬鹿がいる。
J2EEのような仕組みの劣化コピーを自作している馬鹿がいる。
Strutsのような仕組みの劣化コピーを自作している馬鹿がいる。

会社の研究開発部門などといっても、学習意欲も独創性の欠片も
ない馬鹿が決裁権限もっていると、碌なことがない。前線部隊は
ｵｺｯﾃﾙだろうなあ…俺たちの稼いだ金でナニ遊んでんだ！って。
338 ：再利用万歳：03/01/04 21:11
>>336
クラスライブラリがオールダイナミックリンクという起動の仕組み上、
起動が遅いのは諦めよう。
339 ：デフォルトの名無しさん：03/01/04 21:20
>>337
どうして馬鹿なの？　自作しないと著作権は主張出来ないよ？
340 ：再利用万歳：03/01/04 21:26
>>339
なんでこのへんのライブラリに自社の著作権が必要なの？売るの？
341 ：デフォルトの名無しさん：03/01/04 21:31
>>340　じゃ何を売ってるの？　サービス＝労働力？
342 ：デフォルトの名無しさん：03/01/04 21:37
>>339
じゃあ自社のAPサーバ製品のWebサーバ部として、ApacheをカスタマイズしたIHSを
バンドルしているWebSphereについて、IBMは著作権を主張出来ないのか？

ライセンス良く四打ほうが宵と思われ。
343 ：342：03/01/04 21:38
>>342 に自己レス。
>>339が言っているのは、「ライブラリそのものの著作権か」
漏れの例え、間違いですた。失礼。
344 ：デフォルトの名無しさん：03/01/04 21:42
>>342
そういうふうな事ばかり言ってるから競争力無くなったんじゃないの？

じゃ、組み込みCPUにXMLパーサやFTPが必要になったら、いちいち買うのか？
それともGNUの成果を使って、ソース公開するのか？

自作すれば再利用コストは　貰い物より低いくなるんだから、トータルで得すればいいだろ？

だいいち、そういう技術を他者依存してたんじゃ、もはやプログラミングじゃない
エクセルやワープロ使ってるだけの人と同じだよ。
345 ：デフォルトの名無しさん：03/01/04 21:46
> そういう技術を他者依存してたんじゃ

Apacheなんか使ってる愚かな連中は、もうhttpサーバ書けないだろうね。
346 ：再利用万歳：03/01/04 21:50
BCCやGCC使ってコンパイルしている開発者は馬鹿ですか？
WeblogicやWebSphereでWebアプリを開発するヒトは、馬鹿ですか？

馬鹿かもしれませんが、貴方ほど暇人ではないです。>>344
347 ：汎用系の話：03/01/04 21:52
>>337
大丈夫。前線部隊にもバカが多いから。
判定条件が1箇所違うだけのソースを10数個も作った挙句、
仕様変更が来る度、数百に及ぶソースから↑を洗い出したり…

1年間居たが2度と戻りたくねぇ。
348 ：デフォルトの名無しさん：03/01/04 21:54
>>344
に激しく同意！！！
最近の連中はもうTCPスタックの一つも作れないと見た。
ソフトウェア輸入大国って哀れだよね。
349 ：デフォルトの名無しさん：03/01/04 21:54
>>346
何わけの判らん事を？
もっと噛み砕いて言わないと判らんなら言ってやる

XMLパーサエンジンや、FTPサーバ/クライアント程度の自作が大変か？
それが、大変だっていうなら、もうちょっと大変でなくなるようにしろよって事だよ！
350 ：デフォルトの名無しさん：03/01/04 21:58
大変かどうかで自作するかどうかを決めるワケないっしょ
351 ：デフォルトの名無しさん：03/01/04 21:58
もうアレだね。ＯＯが理解できるかどうかというより、もっと単純な話やね。
再利用によるメリットを知り、再利用できるように設計できる柔軟な頭。
これがあるか無いか、そこに想像力を闘魂注入できるかどうかなんだね。問題は。

その辺の基本的な設計力があるか無いかで、たぶんＯＯを見る目を分かれるのかも。
..と、飛躍してみたりするテスト。(w
352 ：再利用万歳：03/01/04 21:59
>>349
作るのは簡単でも、動作を保証するのは大変です。
作りっぱなしで済ましてる馬鹿PGは平和でいいですね。
353 ：デフォルトの名無しさん：03/01/04 22:00
>>352
はいはい、動作の保証まで誰かにしてもらえて、まあ羨ましい事。
おもつもまだ取れないのでしゅか？
354 ：デフォルトの名無しさん：03/01/04 22:00
>>349 が問題にしているのは、スキル。
>>350 が問題にしているのは、工数。

どっちもベターな方向が理想。
355 ：デフォルトの名無しさん：03/01/04 22:04
＞>>350 が問題にしているのは、工数。
むしろ保守性。
356 ：デフォルトの名無しさん：03/01/04 22:05
その辺を鑑みて
自作するか買ってくるか
内部人員でやるか外注するか外注つれて来るか
決めるんでしょうね。

OOをいくらやっても、ライブラリをいくら書いても
こういうことを考える訓練にはならないけどね。
357 ：デフォルトの名無しさん：03/01/04 22:06
前居た会社で VB で HTTP サーバ書きましたが何か？(前線部隊だよ、暇を見つけてコツコツね)。
趣味のプログラムの C++ で shared_ptr や weak_ptr を生のまま使うのが怖いから
自作クラスでラップしてますが何か？

Reinvent the Wheel アンチパターンだと自覚してますが何か？
わかっちゃいるけど止められないんですが何か～～～？(泣)
358 ：デフォルトの名無しさん：03/01/04 22:09
＞前居た会社で VB で HTTP サーバ書きましたが何か？
いろんな意味でスゲェ。
359 ：357：03/01/04 22:11
>>358
結構楽しいよ。VB でも HTTP サーバーかけるんだなって、我ながら驚いた。
HTTP と周辺プロトコルの理解も深まったし、勉強としてはオススメ。

その後地獄を見ることになるから絶対実務では真似しない方がいいという事だけは
忠告しておくけど。
360 ：デフォルトの名無しさん：03/01/04 22:11
>>357
それでいいじゃん。　労働的プログラミングで世の中回ってた時代は既に峠を越えたと思うよ。

車輪の再生産でも、再生産コストを　車輪の継承より下げられればいいんだ。
って、そういう方向性の方が将来があると思うけどね。
361 ：357：03/01/04 22:14
あぁ、そうだ、ページからスクリプト部分を抜き出して WSH に投げるだけなんだけど、
偽 ASP 機能まで作ったりしてた。

給料安かったけど、その分遊んでたな。俺ってちっちゃな犯罪者だな。
362 ：デフォルトの名無しさん：03/01/04 22:17
スキルを過信して全部自作してしまうと、もしミスった時、客に言い訳できない。
かと言って、常に外からライブラリ買ってきて詰め合わせばっかり納品してる会社じゃ、
社員のスキルは一向に上がらない。

最後は個人の気合と知能だな。

ＯＯも便利に使えばメリット大だと思うが(特にそれが前提の現場なら)、それを、それが体言された環境で
ただのフレームワークとして利用するだけなら、結局「これってなんでこんなトコ参照してるの！？」
ってな、混乱したコード書く馬鹿も生まれる可能性がある訳で...。

やっぱ人次第だな。
363 ：357：03/01/04 22:17
>>360
VB で HTTP サーバ作るのは良くないと思うぞ。

人が作ったコンポーネントをラップして使う方は俺的にはオススメだ。
だけどみんながそれをやっちゃうと、別の人が作った同じ機能の物を使うときに
常に Adapter が必要になるのがイヤンバカンスな感じだな。
364 ：357：03/01/04 22:19
大事な説明が抜けてたな

慰安バカンス ≒ イヤンバカンス ≒ イヤン、バカン

だ。
365 ：デフォルトの名無しさん：03/01/04 22:23
スキルに突っ走れるのは暇な学生か、あるいは、もう本当にソレが好きで好きでしょうがない
馬鹿。（注・←これはいい意味でだＹＯ！「役者馬鹿」とか「空手馬鹿」とかの）
で、工数とか保守にこだわるのは、やっぱり社会人だよな。

ドリフで言うと、志村＆加藤 vs いかりや みたいな構図か。（なんて
366 ：357：03/01/04 22:26
>>365
前半部分には烈しく同意だが、後半と繋がらん…。

志村＆加藤 と いかりや 。どっちが笑い馬鹿でどっちが仕事上の笑いをしてる人なんだ？
367 ：デフォルトの名無しさん：03/01/04 22:27
> で、工数とか保守にこだわるのは、やっぱり社会人だよな

管理してる側としても、工数にはこだわってほしいんだけど、
その反面、技術力の保持も必要だなあと感じることはしばしば。

まあ技術力が飛びぬけてる奴は一人いれば充分なんだけどね。
368 ：デフォルトの名無しさん：03/01/04 22:40
>Java はなぁ、効率を優先してあえて
>基本型を区別してるんだよ。
別に効率優先だけじゃないよ。
intがオブジェクトだったら面倒じゃん。

>Apacheなんか使ってる愚かな連中は、もうhttpサーバ書けないだろうね。
だから、アホみたいなCGIの使い方とかしちゃったり
COMを使うためにサーバーOSがWindowsになっちゃったりと・・・

ちなみに、JAVAが遅いと思ったら、
自分でテストプログラム書いてみてね。
時代遅れ発言はもうやめた方がいいかと。

ついでに、OOから動的バインド（実行時ポリモーフィズム!=オーバーロード）
とったらクソみたいなもんだけど。
逆に聞きたい。
なんでOOPL使ってるのかと。
369 ：デフォルトの名無しさん：03/01/04 22:49
可読性が高くなるから。
370 ：デフォルトの名無しさん：03/01/04 22:53
プログラムの動作中に、本当に動的バインドする場面なんて
少ないと思うんだがなー。例があったらおせーて。

DirectShowのフィルタグラフぐらいしか知らん。
371 ：デフォルトの名無しさん：03/01/04 22:55
これから >>450 くらいまで「動的バインド」の定義について論争が起こります。
372 ：デフォルトの名無しさん：03/01/04 22:56
>>368
＞別に効率優先だけじゃないよ。
＞intがオブジェクトだったら面倒じゃん。
何で？
373 ：デフォルトの名無しさん：03/01/04 23:00
やだやだJava厨は。ちょっとは他の言語の勉強もしろ。
374 ：デフォルトの名無しさん：03/01/04 23:03
> 別に効率優先だけじゃないよ。
> intがオブジェクトだったら面倒じゃん。
演算子とかのことをゆーてますか？それぐらい OO 優先だったらなんとか
したと思うのだが…。
375 ：デフォルトの名無しさん：03/01/04 23:04
>>372
おいらも、C/C++馬鹿相手の後方互換確保と、実行時効率以外に
理由が想像つかんね。
376 ：デフォルトの名無しさん：03/01/04 23:04
冬厨が必死で埋め立てたからね
377 ：368：03/01/04 23:06
>プログラムの動作中に、本当に動的バインドする場面なんて
>>370
てか、マジで言ってる？
C++のvirtualとか使った事ない？
デザパタは知らない？
Javaのライブラリは使った事ない？(InputStreamとか）

>>372
計算だけをするプログラムとか作ってみてそう思わないなら
人によるのかもしれないけど。
378 ：デフォルトの名無しさん：03/01/04 23:06
OO覚えてこのスレに参加すると人生の生産効率は上がりますか？
379 ：デフォルトの名無しさん：03/01/04 23:08
>>377
オーバーロードのことでなくて、Javaでいうリフレクションによる
実行時参照解決のことだと思うよ。
380 ：デフォルトの名無しさん：03/01/04 23:15
>377 だから、それは今の Java での話だろ。基本型までオブジェクト
にした場合は当然なんとかするだろう…。まさか Java の開発者が
add(x,y) -> x + y のようなシンタックスシュガーが作れないから
基本型を区別したと主張するわけではなかろうな？
381 ：デフォルトの名無しさん：03/01/04 23:20
OO厨は、人生の効率も、生産効率も最低ですが、
脳内で、現実にはありもしない、再利用効率が上がります。
もちろん、そんな自分よがりのコード、誰も再利用しませんし、
実際再利用できません。
382 ：デフォルトの名無しさん：03/01/04 23:24
>>380
イコールはどうするの？
a=b

>>379
ああ、なるほど。
それはポリモーフィズムじゃないね。
もしかして、レイトバインドと動的バインドって同じ意味じゃない？
383 ：デフォルトの名無しさん：03/01/04 23:26
>>381
＞もちろん、そんな自分よがりのコード、誰も再利用しませんし、
自分よがりなコードならな。

一人でいじってる学生にはわからんて。
384 ：デフォルトの名無しさん：03/01/04 23:27
>>379
そそ。動的に結合されるとしても、
あらかじめつながるオブジェクト/クラス/インスタンスが決まってるなら
設計時は動的かもしれんが実装時/実行時は静的だわな。
385 ：デフォルトの名無しさん：03/01/04 23:28
>>382
C#のboxingがJava1.5～7あたりで載るらしいよ。
386 ：デフォルトの名無しさん：03/01/04 23:30
>>385
ﾜﾛﾀ
ボクシングはクソすぎ
387 ：デフォルトの名無しさん：03/01/04 23:31
ついにJavaがC#の後を追うようになったか（感涙
388 ：デフォルトの名無しさん：03/01/04 23:32
P/Invoke、unsafeも入ってくれるとうれしい・・・
389 ：デフォルトの名無しさん：03/01/04 23:33
>>386
嘘じゃないよ。Generics盛り込みと関連して、そういう類の
異種代入を許すようなコンパイラの拡張が必要になるらしい。
おいらには、なんでかﾜｶﾗﾝｹﾄﾞ。

単体の機能としては、boxingって型安全ぶち壊しのような気
がしてｷﾓｲよね。
390 ：デフォルトの名無しさん：03/01/04 23:33
>あらかじめつながるオブジェクト/クラス/インスタンスが決まってるなら
JAVA風(全てのクラスの基底になるObjectクラスがある）
な言語なら

class Test{
public void(Object o){
object.toString();
}
}

というクラスを定義した時、
つながるインスタンスもクラス（メソッド）も
決まってないけど。
391 ：デフォルトの名無しさん：03/01/04 23:35
genericsはプリプロセッサを用意するんじゃなかったっけ？
392 ：デフォルトの名無しさん：03/01/04 23:39
Generics自体もOOとして反則のような気がするのだが、仕方がないのかな。
393 ：デフォルトの名無しさん：03/01/04 23:43
OO的な解決方法はいまだ示されていないのでしょうがないでしょ｡

あえてやろうとすれば
Stack.Push(Object Item)
Object Stack.Pop();
を継承して
MyStack.Push(MyObject Item)
MyObject MyStack.Pop();
にoverloadするくらいか｡
394 ：デフォルトの名無しさん：03/01/04 23:44
>>392
あると便利だからねえ。
395 ：デフォルトの名無しさん：03/01/04 23:45
>>390
そりゃたんなるtoString()のオーバーロードでしょ。

引数として渡されるインスタンス(o)のクラス定義によって
toString()の実装は静的に決まってるよね。
396 ：デフォルトの名無しさん：03/01/04 23:45
Genericsってなんでつか？
397 ：デフォルトの名無しさん：03/01/04 23:46
>>396
List<Integer> l = new ArrayList<Integer>();
lにaddできるのはInteger（またはそのサブクラス）だけ。
398 ：デフォルトの名無しさん：03/01/04 23:47
>>394
どこが便利なの？

>>393
勝手にキャストしてくれればいいんでしょ?
Stack.Pop()を実行したら
型パラメーターにキャストするのを自動でしてくれれば
いいわけだ。
399 ：デフォルトの名無しさん：03/01/04 23:47
そうしよう
400 ：デフォルトの名無しさん：03/01/04 23:48
>>396
C++でいうところのテンプレート。
期待される用途はタイプセーフなコレクションクラスの実現。
401 ：デフォルトの名無しさん：03/01/04 23:48
コレクション・コンテナだけでいいの？
402 ：デフォルトの名無しさん：03/01/04 23:50
>>398
ライブラリを外部に提供することを考えてミソ。
メソッドの引数や戻り値がListのときとList<Integer>のときで
どちらのほうがよいでしょうか？コンパイル時に型安全を保障で
きるのは、便利だよ。
403 ：デフォルトの名無しさん：03/01/04 23:50
>>398
勝手にキャストより静的にチェックして欲しいかも｡
404 ：デフォルトの名無しさん：03/01/04 23:51
C#て#include相当の機能あったっけ?
そうしたら今でもできなくはないでしょ｡
405 ：デフォルトの名無しさん：03/01/04 23:51
>>401
変数型に束縛されないクラス実装っていうのが存在しうるなら、
それら全てに適用は可能だね。ﾖｸﾜｶﾗﾝｹﾄﾞ。
C++でテンプレート書きまくってたヒトなら詳しいかな？
406 ：デフォルトの名無しさん：03/01/04 23:52
>>404
using(=Javaのimport)
407 ：デフォルトの名無しさん：03/01/04 23:52
>引数として渡されるインスタンス(o)のクラス定義によって
>toString()の実装は静的に決まってるよね。
どのOOPLも実行時に動的にメソッドを探してくるけどね。

ただ、いいたい事はわかるけど
それって動的リンクって呼ぶんじゃない？
408 ：396：03/01/04 23:53
>>397
型保証を受け取る側のメソッド依存で済ますだけでなく、
明示的に制限かける...みたいな解釈でよろしいんでせうか？
409 ：396：03/01/04 23:55
あ、気づいたらレスが..（笑
>>400 サンクスです。

ていうか、急に回転早くなったね、このスレ。(笑
410 ：デフォルトの名無しさん：03/01/04 23:56
>ライブラリを外部に提供することを考えてミソ。
その時は委譲すればいいのでは？
つまり
class MyList{
privtate List list;
void add(int i);
}
って感じ

あと、汎用性が欲しければ、
コンストラクタでClassを引数に加えておいて
代入時に型をチェックするってのはどう？
public constructor(Class class){
}
Javaの場合だけど
411 ：デフォルトの名無しさん：03/01/04 23:57
>>406
そんな高級なのじゃなくて
指定したテキストファイルをそのまま展開するようなもの｡
T max(T a, T b)
{
　return (a>b)?a:b;
}
をインクルードしてTを好きな型に書き換えればなんちゃってgenericの出来上がり｡
412 ：デフォルトの名無しさん：03/01/04 23:57
>>410
そういうことをいちいち実装するより、コンパイラがやってくれる
ほうが楽でしょ。
413 ：デフォルトの名無しさん：03/01/04 23:59
>>411
それじゃだめだろ・・・
414 ：デフォルトの名無しさん：03/01/05 00:00
何で?
415 ：デフォルトの名無しさん：03/01/05 00:02
>>412
動的である必要がなければ、
言葉はかぶるけど
Listのテンプレート（雛形という意味で）を用意しといて
Tのところだけある型にした
クラスのソースコードを出力してくれれば
充分だと思う。
416 ：デフォルトの名無しさん：03/01/05 00:03
>>414
テンプレートを使って定義されたクラスのインスタンスを返す関数は
どうなるんだ？
417 ：COMer：03/01/05 00:03
行き着く先は、VARIANT....。
418 ：デフォルトの名無しさん：03/01/05 00:07
>>417
逝って良し｡いや､逝ってくれ｡
419 ：デフォルトの名無しさん：03/01/05 00:08
つかMSの実装はどうなってるの？
420 ：デフォルトの名無しさん：03/01/05 00:09
OO スレじゃなくなってきてるし…。
それでもテンプレートの話が気になる人は
Modern C++ Design を読んでから来い！
おまえらに Generic の先にある Generative の世界を垣間見させてくれるだろう。
421 ：M.C. COMer：03/01/05 00:10
>>418
イエッサー！！
422 ：デフォルトの名無しさん：03/01/05 00:10
>>420
もともとOOのスレじゃないさ。
低レベル社員同士のののしりあいの場所。
423 ：デフォルトの名無しさん：03/01/05 00:12
ＯＯスレとして。(ｗ
で、Genericの考え方って、ＯＯ的にどうなん？
許容されるのかな。ゴリゴリのＯＯな人に。
424 ：デフォルトの名無しさん：03/01/05 00:13
Lokiはあまり知らないけど､なんか激しく勘違いというか考え違いが入ってるような・・・
C+++STLだからああなってしまったというだけで
柔軟な言語仕様を備えたOOPLであればいらなさそうな気もするんだけど｡
425 ：デフォルトの名無しさん：03/01/05 00:13
>>423
ののしりあう底レベル社員には許容できない。むしろ脆弱性。
426 ：デフォルトの名無しさん：03/01/05 00:15
>>423
最上位クラスObjectのインスタンスを保持するコンテナで何が不満なんだ?
427 ：420：03/01/05 00:17
>>423
OO と generic や generative は直行する概念だというのが一般的な見解だ。
つまり、互いに補強しあって掛け算のように高い結果を出す。

>>424
> C+++STLだからああなってしまったというだけで
この部分の意味がよくわかんないんですが、
loki はたしかに C++ がもっと強力な言語だったら不要なものだろうね。
でも現実には C++ には限界があって、それを打ち破る力をもってるのが loki なんだよね。
タイプリストとかヒエラルシーとかはちょっとやり過ぎ感を感じないわけでもないが…。
428 ：デフォルトの名無しさん：03/01/05 00:21
>>427
＞OO と generic や generative は直行する概念だというのが一般的な見解だ。
このスレ的には、OOと直交する概念の存在を認めないOO厨は逝ってよしというところか。
429 ：デフォルトの名無しさん：03/01/05 00:22
>>428
そんな奴いるのか？アスペクト指向とか好きな奴多そうだけど。
430 ：424：03/01/05 00:28
> C+++STLだからああなってしまったというだけで
は
> C+++テンプレートだからああなってしまったというだけで
ですた｡

テンプレートに感じる違和感はStackをコピペしてMyStackを作ることにあって
心情的にはStackを継承してMyStackを作りたいんだよね｡
Foo（Object Item)をFoo(MyObject Item)に書き換えるだけなのに
ほんとにクラス全体をコピペする必要があるのかと｡
431 ：427：03/01/05 00:30
>>428
いいね。OO以外認めない教の信者が出てきてくれると嬉しいんだけど。

>>429
いるだろうね、俺もあと少しでそういう間違いを犯すところだったかもしれない。
慣れないうちはなんかすごく嫌なものに見えた。
汚い、小手先の物に。

今はすっかりハマっているわけですが。
432 ：デフォルトの名無しさん：03/01/05 00:30
テンプレートではバイナリの再利用ができないのでは？
433 ：427：03/01/05 00:34
>>430
テンプレートをコピペしてる？
MyStack を作るときに Stack を継承したい？
ちょっとよく意味がわからんです。

>>432
バイナリの仕様がテンプレートを意識してあれば問題ない。
特に仮想マシン + JIT の時代なので、実行時テンプレート展開とか、
今後はありうると思う。
(Java の generics はそういう方法ではなくて、プリプロセッサ的な仕様になったようだけど…)
434 ：デフォルトの名無しさん：03/01/05 00:34
バイナリって何？
Javaバイトコード？ .NETアセンブリ？
435 ：427：03/01/05 00:36
>>434
あとネイティブなマシン語コードもね。
436 ：デフォルトの名無しさん：03/01/05 01:13
ていうかテンプレが動的なのは、ソースレベルだけ(要するにプリプロ)なのでは。
だとすると、なんか変な言い方だけど、ソース・シュガー(シンタクス・シュガーに対して)って感じだな。

で、バイナリの仕様でテンプレ意識するという事は....最終的になんか
「キャストを手で書きたくない」だけの為に実装されているような気が。

...なんか間違ってる？俺。
437 ：デフォルトの名無しさん：03/01/05 01:13
>>435
ネイティブなコードが「テンプレートを意識する」って、どういう意味だ？

バイナリっつーかダイナミックリンカ (UNIX だと ld.so あたり）に
コンパイラの機能を一部突っ込もう、という話だと思ってたんだが。
438 ：436：03/01/05 01:15
..なんか間違ってるみたい。(苦笑
あ、そういう話ですか(>>437)。失礼。
439 ：435：03/01/05 01:24
>>436
俺は自分のお気に入りの環境にない物を、
なんでも「シンタクスシュガー」で片づける奴らは好きじゃないな。
だったらバイナリエディタでハンドアセンブルしてろよって感じ。
アセンブラより高級言語が汎用的なのといっしょで
テンプレートは非テンプレートよりも汎用的だ。

>>437
実行可能なファイルに入っている物はネイティブコードだけじゃないでしょ。
実行環境まで巻き込んだ話だけど、型に対して抽象的なプリコンパイル済みのコードが含まれていて、
共有ライブラリなり、外の世界から新しい型が与えられた時、
その型に対してネイティブコードを生成する。
みたいな仕組みがあれば OK 。てな話。
440 ：435：03/01/05 01:31
補足
> 実行可能なファイルに入っている物はネイティブコードだけじゃないでしょ。
の意味がわからない人は、手近にある .exe ファイルをテキストエディタで開くと、
いちばんはじめに MZ って書いてあるはず(MS-DOSからWindowsまでは間違いなくそう書いてあるはず)。

つまり実行可能ファイルにはマシン語部分以外にも OS 等が
「これってどうやって扱うねん？」っていう情報が入っている。という話ね。
441 ：デフォルトの名無しさん：03/01/05 01:44
>>337
> J2EEのような仕組みの劣化コピーを自作している馬鹿がいる。
> Strutsのような仕組みの劣化コピーを自作している馬鹿がいる。

そういうところまだ多いよ。J2EEが余り知られていないころTomcat + JDBCだけで済ましてしまい、、
いまさらJ2EEにいこうするのも今までの努力が無駄になってしまうとか。
ある会社ではstrutsもまだ登場していなかったし知られていなかったからTomcat + J2EEだけで済ませていたよ。
いまでも残ってWeb上で稼動しているんだろうな。
442 ：伝説のＳＥ：03/01/05 01:51
ＯＯってのはな。

納期のプレッシャーに負けないな。

伝説のＳＥのみな。

使いこなすことができるのな。

な？


じゃ、ソープ逝ってきます。あとは任せた。おつかれ。
443 ：デフォルトの名無しさん：03/01/05 01:52
>>441
さらに、「今度、以前開発したシステムを、Tomcat4.xに対応させたいんだが、
同じTomcatだから簡単だよな」とか言われたらかなり ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ (w

＞Tomcat + J2EEだけで済ませていたよ。
これって4.x以前の話だよね。(4.xはJ2EEのRI）
444 ：デフォルトの名無しさん：03/01/05 01:53
JavaGenerics はC++テンプレートと比べ限定的らしい。

Vectorの要素の取出しなどで型キャストに悩まされる心配がなくなるなら
J2SE1.5からのGenericsは歓迎したい。

C++みたいな何でもできてしまう取り扱い要注意テンプレートは避けたい。
445 ：デフォルトの名無しさん：03/01/05 01:53
>>442
改行多いよ。
446 ：デフォルトの名無しさん：03/01/05 02:02
Java Generics の概要はこの辺で。
http://objectclub.esm.co.jp/JavaGenerics/
447 ：デフォルトの名無しさん：03/01/05 02:07
C#のGeneric関連のサイトもどっかにあったような
448 ：デフォルトの名無しさん：03/01/05 02:08
あとはこことか。多態の分類についても触れてる。
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/
449 ：デフォルトの名無しさん：03/01/05 02:09
つか、なんでOOに粘着してんの？知恵遅れ？
450 ：396：03/01/05 02:12
>>446 >>448
ポインタありがとん。勉強しまっす！
451 ：デフォルトの名無しさん：03/01/05 02:12
>>449
スレ違い
http://pc.2ch.net/test/read.cgi/prog/1031059923/
452 ：４４９：03/01/05 02:17
んじゃいっとくと、このスレの題名はGenericﾏﾝｾｰスレとでもすべきだろうね。
なんでOOに拘ってるの？
453 ：デフォルトの名無しさん：03/01/05 02:19
>>452
なんでこんな糞スレに拘ってるの?
もしかしてこのスレで真面目に議論しているつもりになっていた
痛々しい方々の一人？
454 ：４４９：03/01/05 02:20
ﾎﾟｿ
１０年遅れの知恵遅れ君たちのスレか(ｹﾞﾗｹﾞﾗｹﾞﾗ
455 ：４４９：03/01/05 02:22
>>453
からかうと面白いから。初々しいけどﾃｷﾄｰなｷﾐらの姿勢がおもろいから。
456 ：デフォルトの名無しさん：03/01/05 02:23
じゃ、ソープ逝ってきます
457 ：４４９：03/01/05 02:24
逝ってラッシャーい
458 ：デフォルトの名無しさん：03/01/05 02:24
沢村さん寝ちゃったのかな
459 ：デフォルトの名無しさん：03/01/05 02:27
.NET Generics
http://research.microsoft.com/projects/clrgen/
http://research.microsoft.com/projects/clrgen/generics.pdf
460 ：デフォルトの名無しさん：03/01/05 02:30
>>443
version3から4への以降はつらい?

あれはTomcat3.xだった。2001年のことだった。
4.xからはJ2EEに内臓か。MyマシンにTomcatいれてからJ2EEいれた。
Tomcatがダブってる。
461 ：デフォルトの名無しさん：03/01/05 02:31
>>449
10年前の知恵ってどんなですか？
462 ：デフォルトの名無しさん：03/01/05 02:36
多態の定義だろ
463 ：デフォルトの名無しさん：03/01/05 02:40
>>448 そのサイト見たんだが
genericsに関してはJavaよりC++のほうが何でもできるぞ、なことばかり書いてあった気がする。

(どんないかなる場合にでも)構造化プログラミングだけで十分と思い込んでいるOO嫌っている連中をからかうと確かに面白いね。
genericsとOOが関係ないと思い込んでいる香具師も笑えるな。
464 ：443：03/01/05 02:41
>>460
いや別にWebApp側から見れば問題無いですＹＯ。すんません。
つーか

＞4.xからはJ2EEに内臓か。

では無くて、Tomcat4.x側に、J2EEのライブラリが使われていると。
※RI【Reference Implementation】==参考用の実装
465 ：デフォルトの名無しさん：03/01/05 02:45
>>461
つか、
多態＝継承 とか、10年位前に逝ってた奴が居て、
そいつにGeneric やらParameterizedTypeの説明した事を、
スレの最初の方斜め読みしてたら思い出して、笑った。

お前等、せっかくの冬休みなんだから、もっと浮世離れした研究でもしてて下さい
って感じ。
466 ：デフォルトの名無しさん：03/01/05 02:49
>>464
数年前にやってたテーマなんで、横から口挟まさせて頂きます。

Tomcat4.x こないだ仕事で久々入れてみたんだけど、
JavaIDL近辺はサポートされたんですか？

＃昔はねぇー。Enhydraとか J2EE containerとして使えるって言うから
＃Tomcat連携しようとしたんだけど、JavaIDL近辺のJNIライブラリが互換性なくて、
＃さっさとあきらめた覚えがあるんです。今ならJBOSS近辺で楽々連携？
467 ：M.C. COMer：03/01/05 02:51
そそ。
Genericの行く先にあるVARIANTのカオスをみつめてみるとか...。
はっ！（人の気配
468 ：デフォルトの名無しさん：03/01/05 02:52
>>449
はあ、多態とGeneicなんて関係ないだろ。
君と友人の雑談なんてどうでもよし。
469 ：デフォルトの名無しさん：03/01/05 02:54
下ね一句？
470 ：デフォルトの名無しさん：03/01/05 02:56
で、JavaIDLライブラリはJavaSoft J2EEから寄贈？って感じなの？
471 ：デフォルトの名無しさん：03/01/05 02:57
>>467
強いて言うなら、Generic(型総称性)とVARIANTはむしろ逆のような...。
472 ：デフォルトの名無しさん：03/01/05 02:59
VARIANTて、VBの void* みたいな奴とはちゃうの？

＃VBとかMSは、ユーザの質が悪いからなーﾎﾟｿ
473 ：デフォルトの名無しさん：03/01/05 03:08
>>470
http://jakarta.apache.org/tomcat/index.html
474 ：デフォルトの名無しさん：03/01/05 03:12
>>473
読んだけど？

あと、Tomcat4.xの管理インターフェースはJavaWebServerのフリー版って感じで、萎える
475 ：デフォルトの名無しさん：03/01/05 03:33
恩恵の無いＯＯはただのキマイラ。
476 ：デフォルトの名無しさん：03/01/05 03:37
なにをかをいわんや
477 ：デフォルトの名無しさん：03/01/05 04:07
>>475
それは
１）ＯＯに恩恵は無い
２）ＯＯによる恩恵が得られない
どっち？
478 ：名無し＠沢村：03/01/05 06:42
ヌヒ等よ、ＯＯの恩恵のひとつはソースを堂々とみせびらかせることだろうね。
（ただし苦労して解決した部分は見せたくない）
一方非ＯＯのソースは恥ずかしいからこそこそ隠すしかないよね？
まあできあがったアプリが作品であって、ソースが作品じゃないといえばないけどね…。
479 ：デフォルトの名無しさん：03/01/05 07:07
もういいから黙ってろ、沢村
480 ：デフォルトの名無しさん：03/01/05 08:51
沢村、おはよう。
481 ：デフォルトの名無しさん：03/01/05 09:47
沢村先生おはようございます！
482 ：デフォルトの名無しさん：03/01/05 12:09
>>439
> 実行可能なファイルに入っている物はネイティブコードだけじゃないでしょ。
だから「ネイティブコードがテンプレートを意識する」ってのは意味不明だと
突っ込まれてるんだろう。
483 ：439：03/01/05 14:41
>>482
> だから「ネイティブコードがテンプレートを意識する」ってのは意味不明だと
おいおい。だれが「ネイティブコードが」って書いた？
俺は
# バイナリの仕様がテンプレートを意識してあれば問題ない。
としか書いてない。
たしかに「ファイル」が抜けてたけど（Windowsでいえば .exe や .dll などがっていう意味だったのよ）。
これを「ネイティブコードが」と読むのは
文脈読めてなさすぎー。
484 ：483：03/01/05 14:44
よく考えたら、(バイナリファイル==実行可能ファイル)っていうのは
変な気がしてきたんだけど、「ソースはこっち、バイナリはこっち。」
っていう言い方するよね？
485 ：デフォルトの名無しさん：03/01/05 15:49
型をに束縛されずにアルゴリズムかけれたらいいよね
　　↓
テンプレートを使う
　　↓
いっそのことすべてのデータを同じ型に入れられちゃえばいいんじゃ？
　　↓
VARIANTを使う
　　↓
（ﾟдﾟ）ｳﾏｰ
486 ：デフォルトの名無しさん：03/01/05 16:43
>>485
その VARIANT には、アルゴリズムで使う演算子やメンバ関数が全部
定義されてるのか？ ありえん…。
487 ：デフォルトの名無しさん：03/01/05 16:45
>>486
まあでも、 そんな方向に向かってる感じだね
488 ：デフォルトの名無しさん：03/01/05 17:17
向かってるのはRubyだけ
489 ：デフォルトの名無しさん：03/01/05 17:58
このスレの用語でいう「プロトタイプ指向」な言語(動的型付言語)の
オブジェクトは Variant に近いかもね。
あらゆるオブジェクトがあらゆるメッセージを受け付けるみたいなー。
490 ：デフォルトの名無しさん：03/01/05 20:43
ぜんぜん違います
491 ：名無し＠沢村：03/01/05 20:47
>>489
俺も自作のデバッグ用につくった関数の中ではあらゆる型をメッセージとして表示できる完全なVariantを実現しているよ。
このおかげでデバッグはずいぶん楽になったよ。
492 ：デフォルトの名無しさん：03/01/05 21:19
>このおかげでデバッグはずいぶん楽になったよ。
その分・・・
493 ：デフォルトの名無しさん：03/01/05 21:48
型をメッセージって一体…
494 ：デフォルトの名無しさん：03/01/05 21:56
文字列にするってんだろ
495 ：デフォルトの名無しさん：03/01/05 21:59
>俺も自作のデバッグ用につくった関数の中ではあらゆる型をメッセージとして表示できる完全なVariantを実現しているよ。
それだけで完全なVariantになるのか（藁
オブジェクト指向のポリモーフィズムを知らないらしい（激藁
496 ：デフォルトの名無しさん：03/01/05 22:13
Javaだとふつー
各クラスでString toString()みたいなメソッドを定義しといて、
ポリフィズムで切り替えるって感じｰ。

>>491は switch caseか if文の羅列を書きまくってるﾖｶｰﾝ。

＃厨房と話してると、OO適用の使用前＆使用後の、
＃使用前の例ばっか出してくるから萎え萎え
497 ：デフォルトの名無しさん：03/01/05 22:55
でも、ポリモってなんでこんなに普及してないんだろうね。
日本ってバカだらけ？
498 ：デフォルトの名無しさん：03/01/05 22:57
普及しているよ。みんな使っているよ。
使ってないのは>>497の周囲だけだよ。
499 ：デフォルトの名無しさん：03/01/05 22:59
いや、２ｃｈを見ての感想。
あきらかに
アンチはポリモを知らないじゃん。
今までのOOスレは
アンチが騒ぐ
ポリモの話がでる
終了
また、アンチが騒ぐ
・・・
の繰り返しだったよ
500 ：177：03/01/05 23:01
>>498禿同

ところがCLOSのメソッド・ディスパッチャーでは switch case文の羅列が正しい罠
501 ：デフォルトの名無しさん：03/01/05 23:08
>>494
なるほど。486 に対してその回答じゃあ、沢村は Generics をまったく理解
してないワケね…
502 ：デフォルトの名無しさん：03/01/05 23:10
>ところがCLOSのメソッド・ディスパッチャーでは switch case文の羅列が正しい罠
ｿｰｽｷﾎﾞﾝ
お前インタプリタの知識０っぽい
503 ：デフォルトの名無しさん：03/01/05 23:22
>>502ﾎﾟｶｰﾝ
504 ：496=500：03/01/05 23:34
>>502
こ奴(>>502)は、結局ナニが言いたかったんだろぉ？
CLOSインタープリタの話？
505 ：496=500：03/01/05 23:38
おソースは、このあたりでいいんでないの？
http://www.google.co.jp/search?num=100&hl=ja&ie=UTF-8&oe=UTF-8&q=CLOS+method+dispatcher+hash&lr=
506 ：とおりすがり：03/01/06 20:22
余談：
非ＯＯ派のヤツってのは、それを否定するだけの明確な理由を説明できない。
「だってわかんねーもん！！」とか言ってしまうと小さなプライドが傷ついてしまうので、
こんな所で感情をスレを立て、感情のバランスを保っているのか。

王様の耳はロバのミミー。
507 ：赤便先生：03/01/06 20:24
×こんな所で感情をスレを立て
○こんな所で感情的なスレを立て
508 ：デフォルトの名無しさん：03/01/06 20:28
OO厨が会社には必要ないってことは明白だし～
OO厨はいらねっ。
509 ：名無し＠沢村：03/01/06 20:29
>>496
Javaだとふつー
各クラスでString toString()みたいなメソッドを定義しといて、
switch case文で切り替えるだろ？
それがヌヒにとってのポリモーフィズムだろ？

510 ：デフォルトの名無しさん：03/01/06 20:36
三尺キ寸ｺﾋﾟﾍﾟｷﾀｰ
511 ：デフォルトの名無しさん：03/01/06 20:37
Javaだとふつー
各クラスでString toString()みたいなメソッドを定義しといて、
ポリフェノールで切り替えるって感じｰ。
512 ：名無し＠沢村：03/01/06 20:40
>>511
俺はJavaはあまり詳しくないんだが、ポリフェノールというのはどういう概念ですか？
513 ：デフォルトの名無しさん：03/01/06 20:42
( ´,_ゝ`)ﾌﾟｯ
ポリフェノールも知らないでOO語るな
514 ：名無し＠沢村：03/01/06 20:48
>>513
教えて！！ポリフェノールってどういう意味？お願い！！
515 ：デフォルトの名無しさん：03/01/06 20:49
何やら真のｳﾞｧｶが紛れ込んだようで。
516 ：デフォルトの名無しさん：03/01/06 20:58
チョコレートで健康になるっていう、
お菓子業界通例の販促物質だよ。
517 ：デフォルトの名無しさん：03/01/06 21:00
>>516
あんまりネタやっても調子に乗るだけだよ。ちゃんと教えてやらないと。

ポリは　ポリゴンやポリモフェーズのポリ　と同じで　たくさんって事だ
フェノール はフェナムと書いた方が近いが,　驚異的なって意味もあるが、事象という意味だ　
まあ、時間的概念を含んだポリモフェーズと考えたらいいな
518 ：デフォルトの名無しさん：03/01/06 21:06
( ´,_ゝ`)ﾌﾟｯ
ポリンキーも知らないでOO語るな
519 ：名無し＠沢村：03/01/06 21:10
>>517
＞時間的概念を含んだポリモフェーズ

だとすれば俺の趣味に合っているな…。時間的概念を含んだとはマルチメディアタイマーなどを使うのに便利な概念ということか？
520 ：奈菜氏＠ｼ村：03/01/06 21:12
>>517
んじゃベンゼン環に水酸基くっつけた奴はなんつーのよ？
521 ：名無し＠沢村：03/01/06 21:27
俺の名を語ってバカを丸出しにしているヌヒがいるな…。
ヌヒ等よ、ポリフェノールの話は化学板でするんだな。
たしかに俺はＪａｖａを知らないがそれは必要ないからだよ。
もしＪａｖａが学習に値する言語に育ってきたら手を出してみるつもりだよ。
522 ：デフォルトの名無しさん：03/01/06 21:32
技術版のコテハンの癖にいちいち煽るなよ｡馬鹿｡
523 ：デフォルトの名無しさん：03/01/06 21:33
沢村って共有コテじゃないの？
524 ：名無し＠沢村：03/01/06 21:35
>>521
おまえ、本当にJavaを知らないみたいだな…
525 ：デフォルトの名無しさん：03/01/06 22:49
>>520
フェノール
526 ：デフォルトの名無しさん：03/01/06 22:51
ﾅﾝﾀﾞｺﾉｽﾚ
527 ：デフォルトの名無しさん：03/01/06 23:39
>>506 wrote:
＞非ＯＯ派のヤツってのは、それを否定するだけの明確な理由を説明できない。
＞「だってわかんねーもん！！」とか言ってしまうと小さなプライドが傷ついてしまうので、

>>508 wrote:
＞OO厨が会社には必要ないってことは明白だし～
＞OO厨はいらねっ。

... >>506 の言う事は証明された、という事で。
528 ：とおりすがり：03/01/06 23:42
お？　まぁいいや。
ていうか、別に >>521 (名無し＠沢村）の肩持つわけじゃないが、
とりあえず、人のハンドルをコピーするのは、もう、なんだかワケわかんなくなってしまうので、
やめてみましょう。

そして沢村さん。なんで沢山カキコしてるのに、トリップつけないのれすか？
529 ：デフォルトの名無しさん：03/01/07 00:38
>>509
> Javaだとふつー
> 各クラスでString toString()みたいなメソッドを定義しといて、
> switch case文で切り替えるだろ？

ポリモーフィズムとは関係がないが
Javaのswitch文の引数の型はプリミティブ型に限られているため使いこなすには限度がある。
if-else文の方が使いやすい。if文はswitch文と比べ型がbooleanと更に限られているが。
530 ：デフォルトの名無しさん：03/01/07 00:45
つか、メソッド・オーバライドした上で、何故にswitch caseに拘るのか、
ワシャわけわからん
531 ：デフォルトの名無しさん：03/01/07 01:06
Javaのswitch文って文字列型を使えないんだっけ？
C#では使えるけど
532 ：デフォルトの名無しさん：03/01/07 02:19
で？

なんかswitch caseに拘ってる沢村が居て、わらた
533 ：デフォルトの名無しさん：03/01/07 02:24
>>531
使えないよ。.NETはその点きっちり進化してるね。
534 ：デフォルトの名無しさん：03/01/07 02:29
>>530
わしもわけわからん。沢村(の騙り)の思考なのか?

わけわからんけど、ちょっと脱線させる。
>>531Javaのswitch文で使えるのはprimitive型のうちchar, byte, short, intのみ。
booleanが使えないからif-elseのほうが良い。

C#ではstringという値型(?)があるから使えるのだろう。

だがな、こういう値型がある時点でJavaにしろC#にしろどちらもOOらしさを失っているんだよ。
Javaでは使えなくC#で使えるからC#の方が便利だと決め付けるのはちょっと「非OO厨寄り」と思われるだろう。

C#ではJavaのプリミティブ型に相当する型が余りにも多過ぎる。
しかもC#独自の特殊な構造体で値型を自作できてしまう。
しかし細かいことが何でもできるから便利であるとは限らない。余計な機能はライブラリなどで提供すれば良い方ではないか?

JavaのswitchでString使いたければString#equals()メソッドを使って、同値ならint型で1,異なれば0を返す専用のメソッドを作って
switch文の引数にそのメソッドを入れるか、
ループ内にswitch文をいれStringをcharに分解して判定するか、だが、
そこまでしてswitch文など使いたくない。if-elseのほうが良い。
535 ：しつこいﾔｼがいるんで、粘着してみる：03/01/07 02:30
つか、switch case文の起源やら、Cでの実装とか知ってる？
536 ：デフォルトの名無しさん：03/01/07 02:30
>>533
>>534を見ると退化してるように見えますが、何か?
537 ：デフォルトの名無しさん：03/01/07 03:14
>>533 そなたの論理では、 C++は C#よりも進化しているということになる。
538 ：デフォルトの名無しさん：03/01/07 05:00
コンパイラはちゃんと最適化できるの？
539 ：デフォルトの名無しさん：03/01/07 07:26
>>538
どういう意味？　文字列でswitchする時、hashとか２分木とか適時使って高速化してくれるかって？
やるかもしれないし、やらないかもしれないけど、
それが気になるならコンパイラに任せずに自分で書くべきだよ
540 ：デフォルトの名無しさん：03/01/07 10:14
>>528 自明な事を聞きますね。都合が悪くなったときに偽物だった
という逃げ道が使えなくなっちゃうじゃないかYO!!
541 ：デフォルトの名無しさん：03/01/07 12:17
>>540
(ﾟ∀ﾟ)!!
542 ：名無し＠沢村：03/01/07 17:29
ヌヒ等よ、素朴な疑問だが、ＯＯってオブジェクトオリエンテッドで、オブジェクト指向だろ？
どうしてオリエンテッドが指向になるわけ？
オリエントって東洋という意味だろ？
ならオブジェクト東方指向が正しいはず…
どうよ？
543 ：デフォルトの名無しさん：03/01/07 17:48
>>542
「指南」と同じ。もともと方向を指し示すという意味だったのが、
指導するという意味に発展したということでしょう。
544 ：デフォルトの名無しさん：03/01/07 17:53
>>542 指向性マイクロフォンの意味を調べよ!
545 ：デフォルトの名無しさん：03/01/07 17:56
>>542
ここ読め
http://wedder.net/kotoba/orient.html
546 ：デフォルトの名無しさん：03/01/07 19:09
>>540 >>541 お前らは彼の御方を甘く見すぎている！あの御方にとって
　都　合　の　悪　い　事　は　無　か　っ　た　こ　と
ですから。トリップ云々も見事に無視してくれると信じています。
547 ：デフォルトの名無しさん：03/01/07 20:43
そもそもswitchなんてあまり使わないんだけど
文字列でswitchならファクトリーメソッドで
一つのクラスの中に当然押し込んでるんだよな？
そんなのは、if/elseでいい気がする。
548 ：デフォルトの名無しさん：03/01/07 20:47
CLOSのメソッド・ディスパッチャーの話だったよね？たしか
549 ：デフォルトの名無しさん：03/01/07 20:48
>>547 誰に対する応答だ?
550 ：デフォルトの名無しさん：03/01/07 20:56
CLOSのメソッド・ディスパッチャーは
仮想関数テーブルと同じ仕組みじゃなかった？
551 ：デフォルトの名無しさん：03/01/08 15:45
>>550
え、vtableでmulti-methodをresolveできるのか？
552 ：IP記録実験：03/01/08 21:35
IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。
553 ：名無し＠沢村：03/01/08 22:01
ヌヒ等よ、オムツひろゆきに関するマルチポストでずいぶんさがってしまったのであげるよ。
ヌヒ等よ、mklファイルのヘッダチャンク１１バイト目から１３バイト目の01h01h01hというのは何？
554 ：名無し＠沢村：03/01/08 23:15
格言：金は金を呼ぶ、無金は無金を呼ぶ、借金は借金を呼ぶ

理由：ヌヒ等はプログラムをやって金をもうけることが夢に違いない。
だが、いくら技術力や企画力や実務の力があっても、金を持たない人に金が集まることは絶対ない！！
金を稼ぐのに一番大事なことは、その人が金を持っているかどうかである。
金さえたくさん持っていれば自然に金は集まってくるし、金を持ってないといくら努力しても金を稼ぐことはできない。
これはいついかなる場合でもあてはまる絶対的な法則である！！
だが、借金をして自分を金を持っている状態にしても金は集まらない。
借金をして集めることができるのは、次なる借金だけである！！
ヌヒ等よ、これはいついかなる場合でもあてはまる絶対的な法則であるぞよ！！
555 ：デフォルトの名無しさん：03/01/08 23:32
Lispは変数オブジェクトに型情報も含まれるから
ダブルディスパッチャも可能なんじゃなくて？
556 ：デフォルトの名無しさん：03/01/09 00:20
　　　　 *　 ※ ☆　 ※ 　 ※ 　 ※ 　☆ ※　 *
　　　 *　※ ☆　※ 　 ※ ☆ ※　　※　☆ ※　*　　　　　　
　　 *　※ ☆ ※　 ※ ☆　　.☆ ※　 ※ ☆ ※　*
　　*　※ ☆ ※　※☆　　　　　☆※　※ ☆ ※　*
　　*　※ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━ !!!※　* 　　　
　　*　※ ☆ ※　※☆　　　　　☆※　※ ☆ ※　*
　　 *　※ ☆ ※　　※☆　　.☆※　　※ ☆ ※　*　 　
　　　 *　※ ☆　※ 　 ※ ☆ ※　　※　☆ ※　*　　　
　　　　 *　 ※ ☆　 ※ 　 ※ 　 ※ 　☆ ※　 *
557 ：デフォルトの名無しさん：03/01/09 00:26
（;´Д`）ﾊｧﾊｧ
558 ：デフォルトの名無しさん：03/01/09 00:47
実験だよ 実験。
なにもかわらんよ。
559 ：デフォルトの名無しさん：03/01/09 00:53
>ひろゆき

結婚したって本当？
560 ：デフォルトの名無しさん：03/01/09 01:12
>360
そんなサーバ内で完結する方法採用するわけないだろ
561 ：デフォルトの名無しさん：03/01/09 01:27
これじゃ2chがつまらんよ
漏れらを安心させてくれよ
562 ：IP記録実験：03/01/09 01:50
IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。
563 ：デフォルトの名無しさん：03/01/09 01:54
>>546
衝撃の事実が。夜勤さんだったんだ
564 ：デフォルトの名無しさん：03/01/09 02:49
　　　　　　　　　　　　　　　　　　　/＼　　　　　　　 /＼
　　　　　　　　　　　　　　　　　　 /:::::::ヽ＿＿＿＿/::::::::ヽ、
　　　　　　　　　　　　　　　 　　丿　::.__　　.:::::::::::::　 __　 ::::ヽ_
　　　　　　　　　　　　　　　　 ／　／。 ヽ_ヽｖ /:　／。ヽ　 ::::::ヽ
　-┼-　　　丿~~~|　　　　　/　／￣￣√_＿＿丶 ￣￣＼　 ::::|　　　　　　　　　 　 ■　■
　-┼-　　 /~~~~/ ━━━ |　.::::::::::　/ / ｔｰｰｰ|ヽ　　　　 ..::::: ::|━━━━━━　　▼　▼　
　　.|　　　 　　 丿 　　　　　|　.:::::.　　..:　|　　　　|ヽ　　　 　 　 ::|　　　　　　　 　　 　●　●
　　　　　　　　　　 　　　　　|　:::　　　　| |⊂ニヽ| |　　　　　　:::::|　＼
　　　　　　 　 　　　　 ／ ／|　:　　　　| |　 |:::T::::|　!　　　　　 .::|　＼　＼＼
　　　　　　 　 　　　　／　／ ＼:　　　　ﾄ--^^^^^┤　　　　　 丿 ＼＼＼　＼＼＼

　　　　　　　　　　　　　　　　　　　　　　お、大阪・・・・　　　　　　　　
565 ：デフォルトの名無しさん：03/01/09 03:35
気軽さが無くなったな
566 ：デフォルトの名無しさん：03/01/09 12:29
PTAが調子にのって通報しまくりそうだな
567 ：デフォルトの名無しさん：03/01/09 18:07
======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 138720人　発行日：2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
568 ：名無し＠沢村：03/01/09 22:39
ヌヒ等よ、若いヌヒ等よ。ヌヒ等はプログラムをしていて気が散ることはないか？
ヌヒ等よ、ヌヒ等は若いのでその気の散り方は主に性的なものであろう？
ヌヒ等はプログラムをしていて性的にムラムラッとして気が散るのであろう？
ヌヒ等よ、それはプログラムの能率を下げるので直したほうがいいぞ。
ヌヒ等よ、ヌヒ等が何故性的にムラムラッとして気が散るかといえば、それは女の尻がきれいだと思うためだ。
ヌヒ等よ、女の尻がきれいだと思うのは、若さ故の錯覚よ！！
そしてヌヒ等は男の尻はこぎたないと思っているのであろう！？
ヌヒ等よ、女の尻のきれいさきたなさは、実は男のしりのきれいさきたなさと何ら変わるところがないのだぞ！！
このことを実感として認識できるようになったとき、ヌヒ等は真に大人になったといえるのだぞ！！
ヌヒ等よ！！
569 ：デフォルトの名無しさん：03/01/09 22:59
>713　ほう・・・
570 ：デフォルトの名無しさん：03/01/10 00:54
肉倉もNGですか？
571 ：デフォルトの名無しさん：03/01/10 02:10
保守
572 ：デフォルトの名無しさん：03/01/10 02:16
オブジェクト指向の定義って何ですか？
573 ：デフォルトの名無しさん：03/01/10 02:23
http://pc3.2ch.net/test/read.cgi/tech/1041658161/47

オブジェクト指向の基本要素。

１）カプセル化【Encapsulation】
２）継承【Inheritance】
３）多態性【Polymorphism】

この中でも中心となるのがカプセル化。後の２つはカプセル化の実現と
利便性のための補助機能でしかない。

そしてそれは、フロー中心(構造化指向)からデータ中心(オブジェクト指向)への
転換を表現する手段でもある。
574 ：デフォルトの名無しさん：03/01/10 02:30
継承はOOの必須条件ではない。
プロトタイプベースのOO言語も存在するのだ。
575 ：デフォルトの名無しさん：03/01/10 02:32
OO厨の手にかかればVBもOO言語ということになるがそれでもいいのか？
576 ：デフォルトの名無しさん：03/01/10 02:32
>>574
まともに使ってもいない言語持ち出すなよ｡
いちいち例外考慮してたら話が進まないだろ｡
577 ：デフォルトの名無しさん：03/01/10 02:34
>>574
ん？プロトタイプベースは継承しない？んだっけ？
じゃ、他のオブジェクトの機能は包含できないの？っていうか、
包含(コンポジション)だけなんだっけ？（マジ忘
578 ：デフォルトの名無しさん：03/01/10 02:37
委譲するのです
579 ：歌○：03/01/10 02:38
>>575
VBにおけるOOって、まるでキーボードで遊ぶ格ゲーだな。

どちらも、「インターフェースに問題があるでしょう」
580 ：デフォルトの名無しさん：03/01/10 02:39
なるほど
つまり、クラスや継承や多態は欲しいと思ってても
カプセル化は必要ないと思ってる漏れはオブジェクト指向では無いと
581 ：577：03/01/10 02:40
>>578
あ、「コンポジション=委譲」だよね。失敬。
582 ：デフォルトの名無しさん：03/01/10 02:44
>この中でも中心となるのがカプセル化。後の２つはカプセル化の実現と
>利便性のための補助機能でしかない。
そんな事はないよ。
多態が補助機能かどうかはしらないけど、
多態がなきゃOOPLにそれ程価値は感じない。
裏を返せば、多態があるからこそOOPLは魅力的なんだと思う。
継承ってのは差分プログラミングの意味かな？
そういう意味では継承は便利だね。
で、この２つは確かにclassって概念がないと使えない気がするけど
変数と関数をセットにしておいて
アクセシビリティを設定できる事自体はそれ程
強力ではないと思う。

そういうわけで、俺はvirtualのないC++のプログラム書いてる奴
は一律に低脳で才能がないから
プログラムが関わる仕事には就かないほうがいいと思う。
583 ：デフォルトの名無しさん：03/01/10 02:45
thisあるいはself、これがOOの本質
584 ：デフォルトの名無しさん：03/01/10 02:53
>>579
何が言いたいのかわからん。
585 ：デフォルトの名無しさん：03/01/10 02:54
>>582
多態が重要だってのは認めるよ。
OOから多態を差し引いたら抽象データ型でしかないかららね

しかし
＞そういうわけで、俺はvirtualのないC++のプログラム書いてる奴
＞は一律に低脳で才能がないから

これはどうかな？
必要がないのにvirtual宣言をしているほうがアホだと思うが。
586 ：デフォルトの名無しさん：03/01/10 02:59
>必要がないのにvirtual宣言をしているほうがアホだと思うが。
どっちにしろ
複雑なプログラムを書いてる人間は
多態が必要となるわけだし、
多態が必要とならないような
単純なプログラムを書いてる人間はその程度でしょ。
587 ：577：03/01/10 02:59
つーか、ふと思ったんだけど、

「元オブジェクト＝動物」とした時に、その「動物」に「新しい振る舞いが付加された」が、
例えば「人間」っていう新しいオブジェクトであるっていう説明は、クラスベースにおける継承の説明として
時々聞く気がするんだけど、これは
「そのオブジェクトの次の形態＝単一の新規オブジェクト＝進化」ってイメージがして、Java覚えたての当時俺は
凄く鮮烈な印象を受けたんだけど、

これが「プロトタイプベース＝委譲による新しい振る舞いを持った新規オブジェクト」って話だと、なんか
「プラグインで機能強化され続ける古いオブジェクト」＝「DLLで機能補完するWindows」って感じがして、
なんだか、あんまりキレイな感じがしない。

つーか、構造化の世界に立ち戻ったような印象を受ける。..ってのは、俺の妄想。
588 ：デフォルトの名無しさん：03/01/10 03:04
そもそもオブジェクト指向を
現実の物事の属性みたいなので例えて解説してるのは
比喩であるわけだから・・・・
そこを混同しないように注意

プロトタイプベースが流行らない理由はなんだろうね。
もちろんソースは書いてみればわかるけど
汚いね。
見通しの悪いプログラムになる。
最初から仕様が決定してるなら、クラスベースのOOPLを使ったほうが
いい事は明らかだ。
589 ：デフォルトの名無しさん：03/01/10 03:07
使わないから良いけど
演算子のオーバーロードはやり過ぎだと思うのは俺だけ？
590 ：577：03/01/10 03:08
なんかボーっとしてる間に進んでしまった...(笑

>>582
＞多態がなきゃOOPLにそれ程価値は感じない。

魅力とか価値とか、そういう「現場サイド」の気持ちとしてはそうなんだけどね。(笑
ただ、「オブジェクト指向」のオブジェクトって、要するに「一塊の処理の抽象化された物」なので、
（>>583の言う "this","self"がその象徴）それをコードとして表す時のスタイルとして、
「カプセル化」という物があるわけで、そう考えると、「それを継承できる」とか「他の何かのように振舞える」っていうのは
結局の所付随する概念でしかない、と。

そういう意味で、あの３原則があるんじゃなかろうか。
591 ：デフォルトの名無しさん：03/01/10 03:18
>演算子のオーバーロードはやり過ぎだと思うのは俺だけ？
識者の多数決の結果Javaの仕様が決まったわけだ。
演算子のオーバーロードは使うなと。


>一塊の処理の抽象化された物
この意味がよくわかんないかな・・・

>それをコードとして表す時のスタイルとして、
>「カプセル化」という物があるわけで
あるクラスは継承によって定義されたり
そのクラスのあるメソッドは多態を利用したコーディングをしてる
と思うけど。
592 ：デフォルトの名無しさん：03/01/10 03:24
>>589
オレもほとんど使ったことがないけど。

プリミティブ型がないOOPLや、
プリミティブ型とオブジェクト型を同様に扱えるC++のテンプレートみたいな
ものをもつOOPLとは相性がいいんじゃないかと考えてる。
593 ：デフォルトの名無しさん：03/01/10 03:25
>プリミティブ型がないOOPLや、
>プリミティブ型とオブジェクト型を同様に扱えるC++のテンプレートみたいな
>ものをもつOOPLとは相性がいいんじゃないかと考えてる。
理由を書かない奴はバカ
594 ：590：03/01/10 03:29
>>591
ん？　たぶん、話の視点がズレてる。かも。
俺が599で言っているのは、「オブジェクト」っていう「なんらかの属性と振る舞いを持った単位」を、
言語なりコードなりで表現すると、っていう概念を元にした視点。で、

＞あるクラスは継承によって定義されたり
＞そのクラスのあるメソッドは多態を利用したコーディングをしてる
っていう591の話は、現行のOOな言語を用いたコーディングを元にした視点...

なんじゃないだろうか...ってね。別に俺がOOの定義してるワケじゃないんだから、
いいんだけどさ（笑
595 ：デフォルトの名無しさん：03/01/10 03:31
いいかげん、誰かVBはOO言語じゃない。と言ってくれよ。
596 ：595：03/01/10 03:31
理由も書いてな。
597 ：デフォルトの名無しさん：03/01/10 03:34
継承は定義では無く、宣言。
598 ：デフォルトの名無しさん：03/01/10 03:42
>>595
VBがＯＯでは無い理由：
　１）インタフェースの継承が無い。
　２）メソッドのオーバロードによる多態性の実現が、Variantがあるおかげで保証されない。
　３）結局Win32APIをDeclareしてしまうので、関数言語として使えてしまう。
599 ：592：03/01/10 03:44
>>593
ホイホイ。理由を書きますよ。

オブジェクト型は内容が隠蔽されているので、演算子の具体的な処理は意識しない。
プリミティブ型はパフォーマンス向上のために使われたりするので、演算子の具体的な処理を意識しがち。
この差が混乱のもとになっているんじゃないかと思う。

プリミティブ型がないOOPLは処理を意識しないで済む。
C++のテンプレートを持つOOPLでは、型がわからないので、処理を意識しない。
（テンプレートを使っているところに限っての話だけど）
600 ：デフォルトの名無しさん：03/01/10 03:45
>>595
結局MSは概念とかより、OS(というメイン商品)を中心に開発環境を提供しているので、
別にOOがどうだとかにこだわっていないんだという理由は、どうか。
601 ：デフォルトの名無しさん：03/01/10 03:46
>>598
１）あります。
２）多態はVariantなんか使わなくても実現できます。
３）同じことはC++もDelphiもC#等にも当てはまります。
602 ：595：03/01/10 03:50
どうせなら、VBにはOOに必須の○○がない。って書いてくれると嬉しいな。
603 ：デフォルトの名無しさん：03/01/10 03:52
>>595
VB厨はマイクロソフト嗜好だからと言う理由はどうか
604 ：デフォルトの名無しさん：03/01/10 04:01
>>601
1)あるの？（素
2)多態とVariantになんの関係が？
3)話がすりかわってます。

>>602
だから、interfaceが無いって言ってるんだＹＯ！
605 ：デフォルトの名無しさん：03/01/10 04:04
まあ、601は多態がわかってないんだろう。

606 ：デフォルトの名無しさん：03/01/10 04:05
>>604
> 2)多態とVariantになんの関係が？
んなもん>>598に聞いてくれ。

> 3)話がすりかわってます。
すりかわっていません。APIが使えるだけでOO言語じゃなくなるなんておかしすぎます。

> だから、interfaceが無いって言ってるんだＹＯ！
だから、あるって言ってるんだＹＯ！
607 ：デフォルトの名無しさん：03/01/10 04:09
VB 多態性 で検索して一番最初に表示されたサイト。いいサイトとは言えんが。
http://www.asahi-net.or.jp/~jz6h-ymmt/sandbox/vbPolymorphism/vbPoly.htm
608 ：598：03/01/10 04:12
>>606
多態性っていうのは、ぶっちゃけていうとメソッドのオーバライドによる表現（メソッドのバリエーション？って言えばいい？）
です。で、「Variantのせいで保証されない」と書いたのは、俺もVB良く知らないから間違ってるかもしれないけど、
メソッドの「"引数の型によるディスパッチ"が阻害されるから」そのバリエーションに支障が出るのでは？と
思った訳です。

で、後>>604の3)については、
「APIが使えるからOOでない」と言ってるんじゃなくて、「結局関数言語的な色彩が強い」と、言ってるんじゃ
なかろーか。で、

interface。あるの？どんな感じになるの？
609 ：デフォルトの名無しさん：03/01/10 04:15
>>608
たぶん>>607を見る前に書いたのだろうが、>>607でも見れ。
610 ：デフォルトの名無しさん：03/01/10 04:15
>>599
基本型があってもなくても混乱すると思うけど。
同じ演算子でもオブジェクトによって意味がかなり異なって定義される。

例えば、整数型とストリーム型での <<。
また、数学畑の人は String 同士の連結が + でできることに相当な違和感を覚えるみたい。

混乱が少なく便利なのは == のオーバーロードくらい。
611 ：598：03/01/10 04:16
>>607
ｻﾝｸｽ！へぇ、初めて知った。
612 ：デフォルトの名無しさん：03/01/10 04:16
>>608
どうやらあなたは関数言語がどんなものかも知らないようだ。
613 ：607：03/01/10 04:17
>>609
その通り（笑
なるほどね。
614 ：デフォルトの名無しさん：03/01/10 04:19
>>613 お前は>>607じゃないだろうが。と細かいツッコミをしてしまう俺は>>607の>>609
615 ：608：03/01/10 04:21
>>608の、
＞「結局関数言語的な色彩が強い」
は適当。申し訳無い。つーかようするに、
「オブジェクト主体でコーディングしなくてもいい＝構造化の中で関数主体で書いてもいい」っていう事を
言いたかった。＞ >>612
616 ：608：03/01/10 04:24
>>607 (>>609)
失礼。>>613 は俺です。m(_ _)m
617 ：デフォルトの名無しさん：03/01/10 04:24
>>615
C++はOOじゃないと言いたいんですね
618 ：デフォルトの名無しさん：03/01/10 04:24
結論としてはVBはOO言語としての必要最小限の機能は持っているということに？
619 ：615：03/01/10 04:26
>>617
言いたいです。(笑
620 ：デフォルトの名無しさん：03/01/10 04:29
VBにはNEWみたいなインスタンスを作る演算子ってあるの？
621 ：デフォルトの名無しさん：03/01/10 04:34
NEWは演算子では無い。キーワード。そして、ある。

あるからって訳では無いが、VBをOOの観点から見るとものすごく中途半端。
だからOOな言語では無い。C++も同じ。
"OOとして書く事もできる"言語ってだけ。VBにいたっては"OO風に書ける"ってだけ。

物体=オブジェクトを正確にモデリングできない言語は、そもそもOOでは無い。
622 ：デフォルトの名無しさん：03/01/10 04:37
http://www.atmarkit.co.jp/fdotnet/vb6tonet/vb6tonet09/vb6tonet09_01.html
参考までに。
VBになかったのは継承だけみたい。
差分プログラミングができなかったと。
623 ：デフォルトの名無しさん：03/01/10 06:42
>>599
Smalltalkのように演算子そのものが無い言語については？
624 ：デフォルトの名無しさん：03/01/10 09:28
>>13
そこまで端的に書かれてみるとかなり怖いものがあるな・・・。
625 ：デフォルトの名無しさん：03/01/10 09:44
過去の裁判関係資料として。

日本生命の削除依頼公開スレッド
http://news.2ch.net/test/read.cgi/newsplus/1004597354/
1 名前：ひろゆき＠暫定管理人 ★ [] 投稿日：01/11/01 (木) 15:49 ID:???
「削除依頼は公開」の原則に従って削除したものを公開してますー。
ソース。
http://www.dd.iij4u.or.jp/~cap/nissei/

3 名前：ひろゆき＠暫定管理人 ★ [] 投稿日：01/11/01 (木) 15:53 ID:???
仮処分で削除と決まったやつです。
626 ：デフォルトの名無しさん：03/01/10 09:49
過去の裁判関係資料として。

日本生命の削除依頼公開スレッド
http://news.2ch.net/test/read.cgi/newsplus/1004597354/
1 名前：ひろゆき＠暫定管理人 ★ [] 投稿日：01/11/01 (木) 15:49 ID:???
「削除依頼は公開」の原則に従って削除したものを公開してますー。
ソース。
http://www.dd.iij4u.or.jp/~cap/nissei/

3 名前：ひろゆき＠暫定管理人 ★ [] 投稿日：01/11/01 (木) 15:53 ID:???
仮処分で削除と決まったやつです。
627 ：デフォルトの名無しさん：03/01/10 10:07
>>13
また、適当なこと書いて・・・。
はぁ～あ。
628 ：デフォルトの名無しさん：03/01/10 10:10
演算子の振る舞いで、OOPLかどうかを判定するのは、結果から見て問題を推測しているに過ぎない。
OOであるかどうかは、その言語の設計思想とその実装による言語機構の表現からにじみ出るものだと
思う。
629 ：デフォルトの名無しさん：03/01/10 10:42
>>354

二審も２ちゃんねるが敗訴、動物病院への中傷発言
http://www.nikkei.co.jp/news/shakai/20021225AT3K2503I25122002.html
630 ：デフォルトの名無しさん：03/01/10 11:24
その100万人がモナーが商標登録された時(現在も継続中だが)に
何かやったのかい？
2ちゃんねらーってのは口でなんか言うだけだろ？
誰も実際に行動なんかおこさねぇよ
631 ：デフォルトの名無しさん：03/01/10 11:50
コピペを上手にNGワードにする方法教え給え
632 ：デフォルトの名無しさん：03/01/10 12:45
IP記録されるようになったくらいで何でそんなにビビってるのかがわからん。
633 ：デフォルトの名無しさん：03/01/10 14:12
>>581 なんか違わない? コンポジション集約は委譲の一部だけどさ。
コンポジションは コンポジション集約(関係が強い集約)では?

というのはおれの脳内のUML的な表現


>>585
>必要がないのにvirtual宣言をしているほうがアホだと思うが。
Javaだとfinal宣言しなくともvirtual宣言とほぼ同様の効果があるんだが。
Javaではオーバーライドする必要がないかわからないメソッドにはfinal宣言しておかないとアホ?
ちょっと聞きたいんだが、あんたにとって、Javaはアホ?

>>589 やりすぎだと思う。C#であれを復活させた理由はC++プログラマがC#に移行しやすくするためなのか?

>>600 関係ないかもしれないけど、ビルゲイツがウプサラ(ウプシラ?)にやってきてOOについて熱く語っていたらしいよ。
Rationalを吸収したIBMと張り合っているみたい。
634 ：デフォルトの名無しさん：03/01/10 15:07
上に同じ？
635 ：デフォルトの名無しさん：03/01/10 16:35
響子さん・・・
636 ：599：03/01/10 17:33
>>610
普通のメソッドでも同じ名前で処理の意味を異ならせることが
出来てしまうので、同様の混乱は起こる。
演算子は名前が短いので、その混乱が起き易いとは思うが。

==も同じオブジェクトなら真なのか、同値なら真なのかって混乱が
あると思ったけど。

>>623
Smalltalkってメソッド（メッセージ？）の名前に記号を使えなかったっけ？
+とか@とか見た覚えがあるんだけど。
プリミティブ型のないOOPLってことで相性はいいと思う。
637 ：名無し＠沢村：03/01/10 22:53
「名誉毀損」って何？
そもそも名誉なんて普通の人間にはないだろ？
あるのはノーベル賞受賞者とか皇族とか名誉教授くらいだよ。
ないものをどうやって毀損する？
どう考えたって「名誉毀損」っておかしいよな…？
また「プライバシー保護法」ってのもおかしいよな…？
もちろん泥棒してない人のことを「あの人は泥棒した」といって回ったらいけないけど、ホントのことをいって何がわるいと思うよ。
ホントのことをいうことがどうして法に触れるの？
どう考えたってこれらの法律はおかしいよ。
638 ：デフォルトの名無しさん：03/01/10 22:56
質の低い書きこみを減らすのが趣旨です。
639 ：デフォルトの名無しさん：03/01/10 23:02
俺の人生はＩＰそのものだった
なんてことしてくれたんだ、ばぼゆき・・・
640 ：デフォルトの名無しさん：03/01/11 00:00
おまいら、これ見れ！
http://dailynews.yahoo.co.jp/fc/computer/2channel/
641 ：デフォルトの名無しさん：03/01/11 00:07
あ、そうだIP記録してんなら削除三板のリモホ表示やめれ
642 ：デフォルトの名無しさん：03/01/11 09:31
IPアドレスを記録してるログでしょ？(^_^;)
643 ：デフォルトの名無しさん：03/01/11 09:32
逮捕されるとどうなるの?
644 ：デフォルトの名無しさん：03/01/11 10:05
======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
645 ：デフォルトの名無しさん：03/01/11 10:58
そっか、大変だな
646 ：デフォルトの名無しさん：03/01/11 11:27
ダイヤルアパーはそうでもないけど、常時接続してる人には切実な問題なんだよ。
647 ：デフォルトの名無しさん：03/01/11 13:03
別スレに誤爆してしまいました、すみません。

813 ：ＡＣＮクルー ◆EMZHGo6oyI ：03/01/09 02:03 ID:nnoy9xUR
この板のＩＰ記録スレはもう終了してたのか。次スレたってないようなのでこちらに。

自分でもこじつけだと思うのだが、今の２ちゃんねるはそれなりに「国民クイズ」の
３７話あたりに近いような気はしている。「国民クイズ」は全４４話、２ちゃんねるは
４４ヶ月。「国民クイズ」はお話しとしては４４話で終わるのだが、「国民クイズ」
体制は続いていく（というか、多少形を変えて世界に広がっていく）。主人公の
Ｋ井Ｋ一は「国民クイズ」に参加し、敗北して、その刑罰としてクイズ番組の司会者となる。
しかし、「国民クイズ」の司会者となった彼は水を得た魚のようになり、しまいには
「国民の意思」通りに動こうとして壁にぶつかる。

なんとなくひろゆきがＫ井に重なるんだが。まあ、考え過ぎだろうな。


814 ：ＡＣＮクルー ◆EMZHGo6oyI ：03/01/09 02:09 ID:nnoy9xUR
ちなみに、「国民クイズ」内では日本国憲法が改正され、こんな条文が追加されてる。
日本国憲法第１２章１０４条「国民クイズは国権の最高機関であり、その決定は
国権の最高意思最高法規として、行政、立法、司法、その他あらゆるものに絶対、
無制限に優先する」

笑えるところなのかわからんが３４話にはムネオたんか？と思われる方もカメオしてる。
648 ：デフォルトの名無しさん：03/01/11 15:52
じゃな　そろそろ消えるわ　まともな話したいならネタと煽りあい
ばかりの２ちゃんねるになんか来ちゃいけなかったんだと思うよ
そういうスタイルの掲示板なら腐るほどあるわけだしな
649 ：デフォルトの名無しさん：03/01/11 15:57
半角板がおもしろい
650 ：名無し＠沢村：03/01/11 20:28
ヌヒ等よ、大変だぞ！！
俺はふと思って２ちゃんねるのあっちこちの板を見て回ったのよ。
格闘技板とかアナウンサー板とかプログラマー板とかをな。
そうしたらな、どこのスレ開いても最近ひろゆきの話題が出てる板はプログラム技術板だけだったぞ！！
ヌヒ等よ、ここは２ちゃんねる一恥ずかしい板だぞ！！
651 ：デフォルトの名無しさん：03/01/11 23:32
いやそんな今時な煽りやられてもな

ただ俺は「誰もお前には聞いてねーから大人しくROMってろや低脳」って言いたいんだよｗ
理解出来た？？
652 ：デフォルトの名無しさん：03/01/11 23:32
逆に立てて欲しくなかったんだが（ｗ
653 ：デフォルトの名無しさん：03/01/11 23:42
質の低い書き込みの例

302 名前：心得をよく読みましょう ：03/01/11 21:57 ID:A+3kp3mQ
いやそんな今時な煽りやられてもな

ただ俺は「誰もお前には聞いてねーから大人しくROMってろや低脳」って言いたいんだよｗ
理解出来た？？
654 ：デフォルトの名無しさん：03/01/12 02:21
逆さ読み？
655 ：デフォルトの名無しさん：03/01/12 02:25
止まったのか？
656 ：デフォルトの名無しさん：03/01/12 09:56
そういや俺も富山県警とフジTVに通報したっけな
マジでやりかねないからな
バカ多いシナ
657 ：デフォルトの名無しさん：03/01/12 20:45
それは単に業者への制裁措置じゃ？
658 ：デフォルトの名無しさん：03/01/12 20:48
通ることもあるわな。

「見なかった」といわれて終わるのは証明の問題であって実体の問題ではない。
659 ：デフォルトの名無しさん：03/01/12 20:57
あった
660 ：山崎渉：03/01/13 18:38
（＾＾）
661 ：デフォルトの名無しさん：03/01/13 22:34
6 名前：心得をよく読みましょう 投稿日：02/12/31 12:49 ID:ADTGAx9x
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
まんこまんこまんこまんこまんこまんこまんこまんこまんこまんこ
662 ：山崎渉：03/01/15 17:58
（＾＾）
663 ：山崎渉：03/01/23 22:18
（＾＾）
664 ：デフォルトの名無しさん：03/01/24 12:14
一応ageておく
665 ：デフォルトの名無しさん：03/01/29 01:23

そういや、前にＯＯでｵｾﾛ作るとか作らないとか
やってなかったか？どうなったんだ？

偉そうにﾀﾝｶ斬ってたOO軍が、どんどん消えてった
のだけは覚えてるが。
666 ：デフォルトの名無しさん：03/01/29 02:08
俺はOO信者じゃないけど。
OOでオセロ作ってもらったとしてそれで何をするの？
ふたことめにはソースだせだせってレベル低いよ。
駆け出しPGでもあるまいて
オブジェクト指向云々の前にプログラム組めるの？
667 ：デフォルトの名無しさん：03/01/29 02:09
設計があれば実装はできる。欲しいのは設計ですね。
668 ：666：03/01/29 02:19
いーよオセロなんてショボイもん作らなくて。
もし作ったとしてもDirectX9で3Dモデルぐらい表示されてなきゃけなす。
しょぼいもんみせんな。
時間は有効に使え。
669 ：詭弁の特徴のガイドライン：03/01/29 19:27
１：事実に対して仮定を持ち出す
　　　 「犬は子供を産むが、もし卵を生む犬がいたらどうだろうか？」
２：ごくまれな反例をとりあげる
　　　 「だが、時として尻尾が２本ある犬が生まれることもある」
３：自分に有利な将来像を予想する
　　　 「何年か後、犬に羽が生えないという保証は誰にもできない」
４：主観で決め付ける
　　　 「犬自身が哺乳類であることを望むわけがない」
５：資料を示さず自論が支持されていると思わせる
　　　 「世界では、犬は哺乳類ではないという見方が一般的だ」
６：一見関係ありそうで関係ない話を始める
　　　 「ところで、カモノハシが卵を産むのは知っているか？」
７：陰謀であると力説する
　　　 「それは、犬を哺乳類と認めると都合の良いアメリカが画策した陰謀だ」
８：知能障害を起こす
　　　 「何、犬ごときにマジになってやんの、バーカバーカ」
９：自分の見解を述べずに人格批判をする
　　　 「犬が哺乳類なんて言う奴は、社会に出てない証拠。現実をみてみろよ」
10：ありえない解決策を図る
　　　 「結局、犬が卵を産めるようになれば良いって事だよね」
11：レッテル貼りをする
　　　 「犬が哺乳類だなんて過去の概念にしがみつく右翼はイタイね」
12：決着した話を経緯を無視して蒸し返す
　　　 「ところで、犬がどうやったら哺乳類の条件をみたすんだ？」
13：勝利宣言をする
　　　 「犬が哺乳類だという論はすでに何年も前に論破されてる事なのだが」
14：細かい部分のミスを指摘し相手を無知と認識させる
　　　 「犬って言っても大型犬から小型犬までいる。もっと勉強しろよ」
15：新しい概念が全て正しいのだとミスリードする
　　　 「犬が哺乳類ではないと認めない限り生物学に進歩はない」
16：反論の代わりに詭弁ということにしてすます。
　　　 「それは詭弁です。いいから詭弁なんです。」
670 ：デフォルトの名無しさん：03/02/02 12:34
まだやってるのか。
671 ：デフォルトの名無しさん：03/02/21 13:28
不滅あげ
672 ：デフォルトの名無しさん：03/02/21 14:04
>>666
> オブジェクト指向云々の前にプログラム組めるの？
昔はそういう奴が多かったからソースをみせて見ろと言った経緯がある。
で、お前はオセロ程度のプログラム組めるの？
673 ：ハッカ飴：03/03/15 00:58
今ふと思ったが、バルーンファイトってオブジェクト指向なゲームだったんだな。
昔から他のゲームとはちょっと違うって思ってたけど、オブジェクト指向だからだったんだ。

このゲームは風船をつけたプレイヤーキャラ2人が、敵キャラの風船をﾊﾞﾝﾊﾞﾝ割っては海の中に叩き落していくゲームだが、
当たり判定は風船とキャラクターで別になっている。
風船が無くなったからといって、やられるわけじゃない。一定以下の位置まで落ちたらやられたことになる。
落ちている間にもう1人のプレイヤーが敵をやっつければ次のステージに進めるし、
落ちている間に敵キャラが魚に食われてステージクリアということもある。
それに低い位置からだったら落ちても復活できる。これは敵キャラに限るけど。
つまり、風船が割れること、落ちることはゲームのルールとは独立しているってわけ。
ちなみに、風船を復活させようとしている間の敵キャラに限って、蹴られたと同時にやられたことになるけどな。

もっともオブジェクト指向らしさを感じさせるのが魚だ。
あの魚は水面下に落ちたキャラクターに襲い掛かる。
自キャラ敵キャラの見境なしにだ。
水面下に落ちてもミスにはならず、ただ魚が襲い掛かる条件になっているだけ。
魚の振る舞いや、水面下に落ちることもゲームのルールとは独立してるってわけ。

あと、ゲームオーバーになっても画面のキャラクターたちが動きつづけることも、オブジェクト指向らしさを感じさせるな。
674 ：デフォルトの名無しさん：03/03/15 01:33
>もし作ったとしてもDirectX9で3Dモデルぐらい表示されてなきゃけなす

なにこれ？ギャグ？(プ
675 ：デフォルトの名無しさん：03/03/15 01:44
>>674
それが厨房の想像力のｲｯﾊﾟｲｲｯﾊﾟｲなんだろうよ。
676 ：デフォルトの名無しさん：03/03/15 01:49
>もし作ったとしてもDirectX9で3Dモデルぐらい表示されてなきゃけなす
ギャグでしょ。
本気だったら自爆。
677 ：デフォルトの名無しさん：03/03/16 17:54
>>12
君のおかげで新しい何かに気づいたよ
678 ：デフォルトの名無しさん：03/03/22 00:09
まだこのスレあったんだ。
679 ：デフォルトの名無しさん：03/03/22 00:23
戦場ではプログラム言語すら不要です。
680 ：デフォルトの名無しさん：03/03/22 01:55
3Dまで作らなくてもいいけどある程度大きい規模のものじゃないと
OOのよさがでないことはたしか。
オセロっつってもそのへんに落ちてる糞みたいなフリーソフトと似たようなもんなら
何でくんだっていいだろ。
681 ：山崎渉：03/04/17 15:52
（＾＾）
682 ：デフォルトの名無しさん：03/05/04 21:32
OOの本場のプログラムとか見てても
OOらしいプログラムってほとんど皆無だね。
683 ：デフォルトの名無しさん：03/05/04 21:53
>>682
がんぱってスレ盛り上げてくれ。
684 ：デフォルトの名無しさん：03/05/05 10:31
http://www.sente.ch/cetus/software.html
そもそも抽象的な思考がまともにできないアホにはオブジェクト指向プログラミング
なんて出来ない罠。　俺なんてオブジェクト指向なんて学ぶまでもなかった。
すでにやってた。
685 ：デフォルトの名無しさん：03/05/05 10:33
オブ戦スレってまだあったんだ。
686 ：デフォルトの名無しさん：03/05/05 10:36
>>415
ダメダメなのは、.NET でもなく MS でもなく、　その対抗を作れないで批判ばかりしてる俺達であったり

対抗を作れないどころか、派遣システムをはじめとしてソフトウエア産業＝労働力市場化させてしまった俺達なんだろな
687 ：デフォルトの名無しさん：03/05/05 10:37
誤爆スマン
688 ：デフォルトの名無しさん：03/05/05 10:38
がんばってるなぁ。
根気強くやってれば小さな種火でも
炎をあげて燃え上がる。

・・・かもしれない。
689 ：デフォルトの名無しさん：03/05/05 10:41
ＯＯＰできないやつが生き残れるわけないわな。
おまいら、これからはネットを介した分散コンピューティングの時代だぞ。
そんな複雑なプログラムはＯＯＰでないと管理しがたいわな。
１はもうアホかと。
690 ：デフォルトの名無しさん：03/05/05 10:43
>>689
　分散コンピューティングにOOというのは何か的外れなような
　関数型が適してるというなら議論になると思うが　どうか？
691 ：デフォルトの名無しさん：03/05/05 10:47
根拠は？
692 ：デフォルトの名無しさん：03/05/05 10:53

的外れなんてのはどういう意味だい？　＞690
OOを一体なんだと思ってるんだい？

693 ：デフォルトの名無しさん：03/05/05 10:54
関数型は,副作用を原理的に排除出来る。　その為並列処理を自然な方法で記述出来る。

という事で、並列処理、分散処理用に研究されてきた。
ただ、オブジェクト志向という概念以上に、使いこなせる人を選ぶ方式でもある。
694 ：デフォルトの名無しさん：03/05/05 10:55
＞６９０
じゃあさ、ＯＯはなんに適してるんだよｗ
695 ：690：03/05/05 10:55
>>692
じゃあ、逆にOOのどういうメリットが　分散コンピューティングに適しているというのだい？

複雑なプログラムがOOPでないと管理出来ないのはどうしてだい？
696 ：デフォルトの名無しさん：03/05/05 10:57
ＯＯだって副作用を原理的に排除するものでもあるわけだが。
その関数型ってのは知らないがね。
697 ：デフォルトの名無しさん：03/05/05 11:00
６９０はＯＯ知らないんだろ。
698 ：デフォルトの名無しさん：03/05/05 11:02
おっ、燃え出した（ｗ
699 ：デフォルトの名無しさん：03/05/05 11:02
ここでいう副作用・関数型　というのは専門用語だよ >>696

そして、OOと　関数型・論理型・手続型とは直交する概念だ。

700 ：デフォルトの名無しさん：03/05/05 11:03
>690が言いたいのが純関数型ということなら
別にOOとは対立しないような…
701 ：デフォルトの名無しさん：03/05/05 11:10
画面に表示って副作用なしにどうやって実現するんだ？
702 ：デフォルトの名無しさん：03/05/05 11:28
＞６９５
ＯＯというのは正に複雑さを軽減して管理するための技術なんだが。
関数型ってのは一体なんなんだい？　関数型指向プログラミング？
ただの型？
まさかＣでいう関数型のことかい？　
原理的に副作用を排除するって、その原理ってスコープのことかい？
有効範囲のことかい？
Ｃにあるような機構だけじゃ不十分なほどにプログラムが複雑化し
てきたからＯＯが登場したわけだが。


　　　



　

703 ：デフォルトの名無しさん：03/05/05 11:32
>>702
もうやめろよ
　副作用って言葉が関数型と一緒に出て、　なんで他の解釈が成り立つんだ？
704 ：デフォルトの名無しさん：03/05/05 11:32
６９０はどんな仕事してんの？　関数型って。
705 ：デフォルトの名無しさん：03/05/05 11:37
＞703
手続き型でいう副作用ってのは、グローバル変数を使用したときの予定外の、
意図してない作用に値するからだよ。　ＯＯではそれを回避するために
データとそれに作用しうる、その値を変更する権利を持つ手続きを
まとめるわけだ。
706 ：デフォルトの名無しさん：03/05/05 11:41
だから、ちゃんと関数型プログラミングをお勉強してから　議論しろ！
707 ：デフォルトの名無しさん：03/05/05 11:47
糞スレに認定始末
708 ：_：03/05/05 11:48
　 ∧＿∧ 　　
　（　・∀・）/＜　こんなのみつけたっち♪　
http://www.japan.pinkserver.com/kaorin/hankaku/hankaku07.html
http://japan.pinkserver.com/kaorin/zenkaku/index.html
http://www.japan.pinkserver.com/kaorin/hankaku/hankaku08.html
http://japan.pinkserver.com/kaorin/hankaku/hankaku10.html
http://www.japan.pinkserver.com/kaorin/hankaku/hankaku07.html
http://japan.pinkserver.com/kaorin/hankaku/hankaku03.html
http://www.japan.pinkserver.com/kaorin/hankaku/hankaku05.html
http://japan.pinkserver.com/kaorin/hankaku/hankaku01.html
http://www.japan.pinkserver.com/kaorin/hankaku/hankaku06.html
http://japan.pinkserver.com/kaorin/hankaku/hankaku04.html
http://www.japan.pinkserver.com/kaorin/hankaku/hankaku09.html
709 ：デフォルトの名無しさん：03/05/05 11:50
ここはＯＯスレだと思うが。＞７０６
710 ：デフォルトの名無しさん：03/05/05 11:52
OOスレだから705のようにOOについてお馬鹿な発言するのはネタの範疇だろう。
711 ：デフォルトの名無しさん：03/05/05 11:53
非ＯＯ厨はＯＯを知らないということでいいですか？
712 ：デフォルトの名無しさん：03/05/05 11:55
＞７１０
どこが馬鹿な発言なのか言ってみ。
713 ：デフォルトの名無しさん：03/05/05 12:02
メソッドが、オブジェクト内変数に作用する事も副作用だ。
714 ：デフォルトの名無しさん：03/05/05 12:13
副作用と言うのは、意図してない作用のことなわけなんだが。
どういうわけで、それを副作用だと言うわけ＞７１３

715 ：デフォルトの名無しさん：03/05/05 12:15
関数型言語でいう副作用がないってのは、
「a=bなら、f(a)=f(b)が常に成り立つ」って話だと思ってるんだが違うかね。
OO風に「a=bなら、o.f(a)=o.f(b)」と書いてもいいけど。
a=bなのにf(a)≠f(b)となる＝副作用を生むケースってのは
関数を評価した側には見えない状態があれば起きるわけで、
それがインスタンス変数だろうがグローバル変数だろうが
副作用が生まれることには変わりない。
だから、オブジェクト指向言語と対比して言うところの手続き型言語
（そんな用語あったかな？）と、関数型言語をごっちゃにするのはやめれ。
716 ：デフォルトの名無しさん：03/05/05 12:16
また、関数型でいう副作用の意味でいってんのか？
アホは去れ。
717 ：デフォルトの名無しさん：03/05/05 12:18
やっぱりな。
ただのアホだろ＞７１５
718 ：デフォルトの名無しさん：03/05/05 12:20
関数型　と　副作用が並んでるのに、それぞれ独自解釈するってのはどいう事だ？

オブジェクト指向においても一番大事なのは抽象化だよ。
抽象化というのは　概念に名前を付ける事に他ならないんだよ。

概に付けられた名前を勝手に解釈して訳の判らん議論をするのがキミのいうオブジェクト指向なのかい？　
719 ：デフォルトの名無しさん：03/05/05 12:21
>>714
> 副作用と言うのは、意図してない作用のことなわけなんだが。
あぁ、専門用語じゃないほうの言葉ね。
いいかい、ここはム板なんだよ。
ここのデフォルトは専門用語の方だ。
ちなみにデフォルトも専門用語だからね。
720 ：715：03/05/05 12:22
あ、「a=bのときにf(a)=f(b)が常に成り立つ」場合でも副作用があるときがあるね。
例えばファイルの出力とか。ファイルに出力する文字列を与えると書き込んだ
バイト数を返す関数write()がある場合、引数が同じなら戻り値（文字列の長さ）は
同じだけど、ファイルに書き込んだという副作用は発生する。
うー、上の定義は間違いでした。
721 ：デフォルトの名無しさん：03/05/05 13:23
副作用が必要だからオブジェクトにして、副作用をオブジェクト内に抑えるのだが
しかし、副作用があるという事は、オブジェクトのメソッド呼び出しには
要求される順がある事になり、それは分散処理にとっては大きな制約になるだろう。

といって関数型プログラミングには適性があり、誰にでも出来るという訳にはゆかない。

何か新しいパラダイムが欲しい所だね。
722 ：デフォルトの名無しさん：03/05/05 15:09
この板で、文脈にかかわらず医学的な意味で副作用と言いたいときには、
「主な作用に付随する副次的作用」とでも言ったほうがいいのかな。
723 ：デフォルトの名無しさん：03/05/05 15:11
>>722
ばかじゃないんだからさ、普通に薬の副作用と言えばいいと思うよ。
ペニシリンの副作用でとか、薬名が出れば誰も間違えはしないさ

724 ：デフォルトの名無しさん：03/05/05 15:12
戦場で必要なのは武器や兵器、
そして我々に必要なものはVisual Basic
725 ：デフォルトの名無しさん：03/05/05 15:13
Microsoftは貴方のそばに
726 ：デフォルトの名無しさん：03/05/05 15:14
食料は？
727 ：デフォルトの名無しさん：03/05/05 15:23
兵士は捨て駒なので食料は要らんのです。
728 ：デフォルトの名無しさん：03/05/05 17:45
>オブジェクト指向においても一番大事なのは抽象化だよ。

これはまあ同意しまつ。

＞抽象化というのは　概念に名前を付ける事に他ならないんだよ。

概念に名前を付けるというのは命名というと思いまつ。
概念をより具体的なものから抽象して作り出すことが抽象化だと思いまつが。


729 ：デフォルトの名無しさん：03/05/05 17:52
＞副作用が必要だからオブジェクトにして、副作用をオブジェクト内に抑えるのだが
副作用させるにはオブジェクトにしなくても可能なことなんだから、
それを目的にしてオブジェクトにするわけがない。



730 ：デフォルトの名無しさん：03/05/05 17:56
＞関数型プログラミングには適性があり、誰にでも出来るという訳にはゆかない。
どういう人が向いてるわけ？
731 ：デフォルトの名無しさん：03/05/05 18:19
副作用ってのは、値を計算するため以外に、プログラムの状態の変化を起こすものだろ。
だから、代入文ってのは副作用がある。したがって、
『副作用が必要だからオブジェクトにする』とかいうのはおかしい。


732 ：デフォルトの名無しさん：03/05/05 18:30
>オブジェクト指向においても一番大事なのは抽象化だよ。
>抽象化というのは　概念に名前を付ける事に他ならないんだよ。


こいつの考えでは、オブジェクト指向において一番大事なのは概念に名前をつけることみたいだなｗ。

733 ：デフォルトの名無しさん：03/05/05 19:07
>>732
その通りだと思うよ。

一番大事なのは、必要な概念に名前を付けてゆくこと。　それが本質だと思うね。
734 ：デフォルトの名無しさん：03/05/05 19:13
プッ
735 ：デフォルトの名無しさん：03/05/05 19:16
>>733
一番大事というのは同意するけど
それはプログラミングの本質であって、オブジェクト指向においてのみの話ではないね。

736 ：デフォルトの名無しさん：03/05/05 19:18
７３３＝７３５

737 ：デフォルトの名無しさん：03/05/05 19:19
>>736=>>1
738 ：デフォルトの名無しさん：03/05/05 19:27
おまえらＯＯなんてくだらないことで議論しないで、
明日の飯の種作るほうが先だろ。プライオリティって知ってるか？
739 ：デフォルトの名無しさん：03/05/05 19:28
人はパン種のみ生きるにあらず。
貧しいって、悲しいね
740 ：デフォルトの名無しさん：03/05/05 19:29
＞概念をより具体的なものから抽象して作り出すことが抽象化
その通りだよ。

でもそれは抽象化作業の途中だ。最後の仕上げでかつ、一番大事なのは命名って作業さ

学術の世界でも同じだよ。概念なんて誰でもしらずに操ってるもの、それに最初に名前を付けた人が発明者なんだ。
741 ：デフォルトの名無しさん：03/05/05 19:51
JAVAはいいぞ！　
すごくいい！
Concurrent　Programmingできるしよ。これできないと職（以下略
742 ：デフォルトの名無しさん：03/05/05 20:02
>>723
ばかじゃないんだかさ、関数型言語での副作用と医学用語での副作用を専門用語として対比してるんだって気付けよ。
医学的な文脈でなくても副作用って言葉は一般的に使われるが、それは医学用語が一般化したものだろ。
743 ：デフォルトの名無しさん：03/05/05 20:13
>>730
こんなの読んだらどうかな
http://www.sampou.org/haskell/article/whyfp.html
744 ：デフォルトの名無しさん：03/05/05 20:41
ああホント死滅スレで煽ってると色々勉強になるよな
昨日は、万歳はマンザイと読むこと知ったし、
今日は　副作用と抽象化のを知ったよ。
早速明日みんなに吹聴してやろう
745 ：デフォルトの名無しさん：03/05/05 21:06
調べてみたが、副作用ってのは関数型プログラミングの専門用語というわけでは
ないみたいね。というより、プログラミング言語理論の用語みたいだな。
if(x+y) のｘ＋ｙにはｘ＋ｙの値を計算、評価するだけで、副作用はない。
x=x+y；はｘ＋ｙを計算、評価するだけでなく、変数ｘの状態を変える。したがって
副作用ありだ。
ｘ＋＋；　これも副作用ありだ。　ｘ＝ｘ＋１だから、ｘの状態を変えるから。
要するになんらかの操作にともなって、実行中のプログラム、つまりプロセスの状態
（変数の値）が変更されることがある。これを副作用というらしい。

ではこれはどうだろう？
ｘ＝ｘ；



746 ：デフォルトの名無しさん：03/05/05 21:36
副作用が起こりえるコードだが、実質副作用が発生してない状態だろ？
747 ：デフォルトの名無しさん：03/05/05 21:38
副作用と作用は違うと思うのだが
748 ：デフォルトの名無しさん：03/05/05 21:38
最適化できえんじゃね？
749 ：デフォルトの名無しさん：03/05/05 21:44
なんだ？
750 ：デフォルトの名無しさん：03/05/05 21:48
ｘ＝ｘ；
は副作用なしだろ。
代入文は副作用を伴う操作の典型ではあるが、代入文は必ずしも副作用を伴うわけではないということだ。
751 ：デフォルトの名無しさん：03/05/05 21:52
*x++;
752 ：デフォルトの名無しさん：03/05/05 23:44
x++;
x--;
753 ：デフォルトの名無しさん：03/05/06 01:26
>>750
ふと思ったんだけど、これって実際にはバイトコードに展開されるんでしょうかね?
アセンブラではどう書くんだろ?
754 ：デフォルトの名無しさん：03/05/06 01:37
OOPって要は、機能をコンポーネント単位に分割して、
Messageでやりとりさせりゃいいんですよね？
755 ：デフォルトの名無しさん：03/05/06 02:35
>>750
わかってないな
値が「変わる」ことが副作用じゃない。
「代入する」という動作が副作用を意味する。

あと現実的にも、X=X; に作用がないわけじゃない。
Ｘがレジスタで、（１を書くとクリアするような仕様のとき）
X=X; みたいな記述をよくする。
756 ：デフォルトの名無しさん：03/05/06 07:44
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?side-effect
757 ：デフォルトの名無しさん：03/05/06 07:50
システムの状態を変える言語のコンストラクトのことを副作用という。
したがって、副作用と言うのは動作ではない。＞７５５　
システムの状態を変える動作をする言語のコンストラクトを
副作用と言うのだ。　

命名が変だと思うがどうか。＞733
758 ：デフォルトの名無しさん：03/05/06 08:27
>>757
お題目というのはとても大事だよ。　標語的に表現するって意味ね。
　
副作用を説明するのにコンストラクトってカタカナを持ち出したら一見精密になったようで
今度はコンストラクトの説明しなければならなくなる。
　説明が説明を呼び発散してしまうわけだ。

抽象化を説明するのに「概念に名前を付ける事」と言えば精密ではないけど、これはお題目になる。
精密でない部分は、それに応じて補足してゆけばよい。

　お題目を作る事＝オブジェクトを作る事
　精密でない部分を補足してゆく事＝メソッドを組み立ててゆく事

こういうふうに対応見せれば、
　「概念に名前を付ける事」がオブジェクト指向で一番大事というのがもっともらしく見えてくるだろ？

オブジェクト指向ではもっともらしさも大事だよね
759 ：デフォルトの名無しさん：03/05/06 10:37
＞こういうふうに対応見せれば、
　「概念に名前を付ける事」がオブジェクト指向で一番大事というのがもっともらしく見えてくるだろ？

残念ながら、全然見えてこないな。　

現時点での俺の意見はこう↓

ＯＯＰの本質は言語化。
プログラミングの本質は言語化。
760 ：デフォルトの名無しさん：03/05/06 10:45
>>759
それもいいお題目だね。　ただ、言語化　と用語を使ったら、解説をすぐ入れないと
761 ：デフォルトの名無しさん：03/05/06 12:41
抽象化のプロセスが人によって異なるというだけの話な気がする
762 ：デフォルトの名無しさん：03/05/06 16:51
http://www.ebaumsworld.com/celebgay.html
なかなか魅力的だよ。
763 ：デフォルトの名無しさん：03/05/07 07:57
764 ：デフォルトの名無しさん：03/05/07 08:02
>>762
ちょっと男もしろかった。
765 ：デフォルトの名無しさん：03/05/07 08:04
>>764 うん、面白かった
766 ：デフォルトの名無しさん：03/05/07 08:32
>>７６２
たしかにかなりもてそう魅力的な人間ではあるな。
767 ：デフォルトの名無しさん：03/05/07 08:37
ＪＡＶＡ学べよ。ＯＯの勉強にもなるぞ。
なぜかというと、ＪＡＶＡ自体、ＯＯで設計されてるからさ。
要するにＪＡＶＡそのものがＯＯのお手本なんだよ。
一石二鳥だ。ＪＡＶＡやっとけ。　

768 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/05/07 10:43
>767
ＭＩＤＩ演奏プログラム作ってＯＯの素晴らしさを体験してから言え
769 ：__：03/05/07 10:56
　　 川o・-・）ノ　＜先生！こんなのがありました！
ttp://www.yamazaki.90.kg/hankaku/hankaku01.html
ttp://yamazaki.90.kg/zenkaku/index.html
ttp://www.yamazaki.90.kg/hankaku/hankaku04.html
ttp://yamazaki.90.kg/hankaku/hankaku10.html
ttp://www.yamazaki.90.kg/hankaku/hankaku07.html
ttp://yamazaki.90.kg/hankaku/hankaku08.html
ttp://www.yamazaki.90.kg/hankaku/hankaku05.html
ttp://yamazaki.90.kg/hankaku/hankaku03.html
ttp://www.yamazaki.90.kg/hankaku/hankaku06.html
ttp://yamazaki.90.kg/hankaku/hankaku02.html
ttp://www.yamazaki.90.kg/hankaku/hankaku09.html
770 ：デフォルトの名無しさん：03/05/07 11:02
>>768
逝ってよし！
771 ：デフォルトの名無しさん：03/05/07 11:25
ＭＩＤＩ演奏プログラムって何？
772 ：デフォルトの名無しさん：03/05/07 11:28
ＭＩＤＩを演奏するプログラムのことだろ
ちなみにＭＩＤＩってMusical　Instrument　Digital　Interface
だったと思うがな。
773 ：デフォルトの名無しさん：03/05/07 11:34
釣りか？
774 ：デフォルトの名無しさん：03/05/07 12:19
m(_ _)m
775 ：デフォルトの名無しさん：03/05/07 12:21
（-。-）y－゜゜゜
776 ：デフォルトの名無しさん：03/05/07 14:19
Drawソフトやワープロを作るとOOのすばらしさが分かると
gof本にも書いてあるよ
777 ：デフォルトの名無しさん：03/05/07 17:18
>>776
オセロじゃだめ？
778 ：デフォルトの名無しさん：03/05/07 21:00
openoffice
779 ：デフォルトの名無しさん：03/05/07 21:14
>>767
Javaクラスは肥大化を何とかしろ
780 ：デフォルトの名無しさん：03/05/11 02:58
OOPを駆使してライブラリを作り納品した
別の会社の仕事のときにそのライブラリを使おうとした
しかし最初の契約書で著作権の移転が明記されていたので使えなかった
結局同じ機能を持つライブラリを新たに作った

・・・こんな目に遭った奴はいないのかな？

OOPを使えば再利用可能なライブラリを作れる
というのと
OOPで使ったライブラリを再利用できる
ってのはイコールじゃねえわな

まあOOPが悪いわけじゃないのは間違いないんだがな
781 ：デフォルトの名無しさん：03/05/11 03:16
×　OOPで使ったライブラリを再利用できる
○　OOPで作ったライブラリを再利用できる
782 ：デフォルトの名無しさん：03/05/11 08:14
>>780
　それはいくつか前のスレで言われてたね。　労働者にはＯＯは必要なしって
783 ：デフォルトの名無しさん：03/05/16 16:58
そもそもOOってなんだ？
784 ：デフォルトの名無しさん：03/05/16 17:45
OOはオブジェクト＋メッセージによる設計＆プログラミング
それ以前のはデータ＋アルゴリズムの設計＆プログラミング

難しく考えなくていいよ
785 ：PGバイト人（学生）：03/05/16 20:40
漏まえらに質問です。
ＯＯＰ設計が出来ていると言える基準ってどこよ？

漏れは適当にUML書いて、データ構造をラップして、デザパタ使えそうな
所は使って、後はわからんもんで適当にユーティリティクラスを作って
関数をぶち込んでる。
が、ＯＯＰ設計とはこんな適当に設計されるもんじゃないはずだ。

一般で言う「ＯＯＰ設計が出来ている」と言う基準を知りたい。
誰か教えてクロ。
786 ：デフォルトの名無しさん：03/05/16 20:51
>>785

・「ＯＯＰ」て全角でかかないこと
・「ＯＯＰ」と「ＯＯＤ」の違いがわかること
787 ：デフォルトの名無しさん：03/05/16 21:10
>>768
MIDIといえばJavaSoundAPIだな。
788 ：PGバイト人（学生）：03/05/16 21:11
>・「ＯＯＰ」て全角でかかないこと
OOPとな...ﾘｮｶｰｲ

>・「ＯＯＰ」と「ＯＯＤ」の違いがわかること
敢えて分けています。
OODだとプログラム以外の設計にも通じてしまうのでOOP設計と書きました。
んじゃOOPDかな・・・？訳ワカメ
789 ：名無し：03/05/17 10:16
OOでなんかアプリ作れ
790 ：デフォルトの名無しさん：03/05/18 01:22
>>785
一般的な基準なんて存在しないだろう。強いてあげるなら、
クラスじゃなくてオブジェクトにちゃんと仕事させている。
ってところじゃないかね。
791 ：デフォルトの名無しさん：03/05/18 05:46
（´,_ゝ`）ﾌｰﾝ
792 ：デフォルトの名無しさん：03/05/18 05:46
（　´,_ゝ`）ﾌﾟｯ
793 ：デフォルトの名無しさん：03/05/18 05:48
（゜;＂;゜)
794 ：_：03/05/18 05:57
　 ∧＿∧　　　　http://togoshi.ginza.st/mona/
　（　・∀・）/＜　こんなもの見つけたっち♪
http://togoshi.ginza.st/mona/mona10.html
http://www.togoshi.ginza.st/mona/mona08.html
http://togoshi.ginza.st/mona/mona05.html
http://www.togoshi.ginza.st/mona/monaz07.html
http://togoshi.ginza.st/mona/mona06.html
http://www.togoshi.ginza.st/mona/mona02.html
http://togoshi.ginza.st/mona/mona04.html
http://www.togoshi.ginza.st/mona/mona03.html
http://togoshi.ginza.st/mona/mona01.html
http://www.togoshi.ginza.st/mona/mona09.html
795 ：デフォルトの名無しさん：03/05/18 13:03
==================================
=================／∧　=========／∧
===============／　/ λ=======／　/ λ　　　　　　　　ー
=============／　　/　 λ====／　　/　 λ　　　　　　 　ー　／
===========／　　　/　 /λ =／　　　/　　/λ　　　　　　 　／
=========／　　　　/　/ //λ　　　　/　/ //λ　　　　 　 ＿＿
=======／　　　　　　　　　　　￣￣￣　　　　　　＼　　 　 ＿＿＿
=====./　　　　　　　　/￣ ）　　　　　　　　 （￣ヽ　λ　　 　 　　／
====/　　　　　　　　/●／　　　　　　　　　　＼●　/λ 　 　 ／
===/　　　　　　　　/／　　　　　　　　 　 　 　　 ＼　 /λ
===|　　　　　　　　　　　　　　　　　　　　　　　　　　　 / /|　　 ___|____
==｜　　　　　　　　　　　∧＿＿＿＿＿＿＿＿　　　/ //|　　 　／
==｜　　　　　　　　　　　ヽ───────〆　　　///// 　／|＼
===|　　　　　　　　　　　　　　　　　　　　　　　　/ / ////|　　　　|
===＼　　　　　　　　　　　　　　　　　　　　　 /　/ /////
=====＼_　　　　　　　　　　　　　 　　 　 / //////__／. 　 　 　｜
========＼　　　　　　　　　　　　　　　　　 　ミ／　 　 　 　 　 ｜
==========＼　　　　　　　　　　　　　　　 　／　　　 　　　　　─┐
============＼　　　　　　　　　　　 　　 　＼　.　 　 　 　 　 ─┤
==============＼　　　　　　　　　 　　 　　　＼ 　 　 　. 　　─┘
================＼　　　　　　 　　 　　　　　　＼
==================＼　・　　 　 　 　 　 　　　　　＼
=====================
======================
796 ：デフォルトの名無しさん：03/05/18 13:07
OOが理解できねーから戦場になってしまうわけでしょ
そりゃOOが理解できねーやつにOOなプログラムを書く部下は｢つかえねー｣よ
797 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/05/18 14:20
ＯＯを理解してない奴が粋がって使いたがるんであって
理解してたらそうやたらに使おうとは思わん罠
798 ：デフォルトの名無しさん：03/05/18 14:53
一番上のレイヤーは動けばどんな構造でもいい､OOなんて関係ない
しかしさらに上のレイヤーに少しでもなにか構築するんであれば
きちんと設計されていないと地獄
799 ：デフォルトの名無しさん：03/05/18 14:54
OOいらないやつはやっつけ仕事しかしてないってこと
800 ：デフォルトの名無しさん：03/05/18 15:37
ＯＯは使いまわしが出来るから、２度作らずに楽なんだけどな。
801 ：デフォルトの名無しさん：03/05/18 15:44
>>800
藁
802 ：デフォルトの名無しさん：03/05/18 16:46
コードの再利用は結局できないが、経験の再利用が OO 以前と比べて楽になった。
803 ：デフォルトの名無しさん：03/05/18 18:25
>>796
に一票
804 ：デフォルトの名無しさん：03/05/18 18:32
OO ←これは鼻の穴に見える

OQ ←鼻毛が出てる
805 ：デフォルトの名無しさん：03/05/18 18:41
あんたらが同じ数字シコシコ足し算やってるあいだにうちらは掛け算やってんだよ
806 ：デフォルトの名無しさん：03/05/18 19:44
0に何掛けたって0なんだよ！
807 ：デフォルトの名無しさん：03/05/18 20:07
806は中卒
808 ：デフォルトの名無しさん：03/05/18 20:08
>>785
俺趣味プログラマだけどデザパタ勉強したらとたんに設計が面白くなった。
開発効率落ちてるから素人レベルだけど。
結局先人達の巧い設計手法が公開され定番化されてる物って信じきってるから
三流厨プログラマでも悩まずにモノを作れる。
ソース公開したら意外と反響あってブラッシュアップされてびっくりした。
俺OOPもOODも出来てると言えないと思うけど、それができる人に再利用される
余地があったんだなぁってびっくりしたよ。

やっぱアレだよ。OOPなり君の言うOOPDなりを意識してる事に価値があるんじゃ
ないかと思う次第ですよ。

>>798
そんな感じでやてまつ。
メイン関数が一画面に収まるだけでOOPスゲーとか言っちゃってる勘違い野郎ですが。
809 ：デフォルトの名無しさん：03/05/18 21:01
デザパタは糞設計
810 ：PGバイト人（学生）：03/05/19 01:05
>>790
どうも手続き手法に慣れすぎた為に、"もの"単位に考える事ができてないのです。
本とか読めば理解は出来るんですが、実践で設計すると頭の切り替えが難しい・・・。
どうしても便利関数の詰まったクラスがドーンと出来てしまうのです・・・。
修行たらんなぁ・・・。

>>808
うちもデザパタで目覚めたタイプです。
一時期はデザパタ厨になってしまっていて、プログラムを全然組んでいませんでした。
まあデザパタの本ってJavaとかSmalltalkが多いんでC++でやってる漏れは苦労しましたが。

やぱ先人の巧い設計を取り込みやすいって事は重要だと思うんで、OOPD(?)をこれからも
意識してやっていくです。

漏れも、main関数にAppオブジェクトを生成してmain終了～と書いた時には感涙してました。
俺も勘違い野郎ですな。
811 ：山崎渉：03/05/28 12:58
　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉
812 ：デフォルトの名無しさん：03/06/13 00:29
クラスがあるからOOだと思ってる奴がいたとは・・
813 ：デフォルトの名無しさん：03/06/13 01:22
OOPにしろOODにしろUMLにしろ、素人がいきあたり
ばったりで作るのを助長するんで、迷惑
814 ：デフォルトの名無しさん：03/06/13 01:59
>>813
それは道具のせいじゃないだろ。
アサイン担当がバカだから。
815 ：デフォルトの名無しさん：03/06/13 08:22
（程度によるが）いきあたりばったりなのは誰でもそうだろ。
816 ：あぼーん：あぼーん
あぼーん
817 ：あぼーん：あぼーん
あぼーん
818 ：あぼーん：あぼーん
あぼーん
819 ：デフォルトの名無しさん：03/07/27 00:25
そしてさようなら
820 ：デフォルトの名無しさん：03/07/27 00:45
まだまださようなら
821 ：デフォルトの名無しさん：03/07/27 00:49
かけるかな？
822 ：デフォルトの名無しさん：03/07/27 00:53
落ちる前に１０００までねばるぞ
823 ：デフォルトの名無しさん：03/07/27 00:56
あきた、もう寝よ
824 ：デフォルトの名無しさん：03/07/27 01:12
まだ落ちないのですか？
825 ：あぼーん：あぼーん
あぼーん
826 ：あぼーん：あぼーん
あぼーん
827 ：デフォルトの名無しさん：03/07/27 07:33
OO厨房は戦場で戦死or行方不明or遺骨帰還or廃人帰還or厨房卒業

後輩なら出来る限り無駄死にさせたくない…訓練半ばで激戦地に送りださざるをえないのはなんとかならんか
828 ：デフォルトの名無しさん：03/07/27 07:34
オブ戦スレってまだあったのか
829 ：山崎 渉：03/08/02 02:17
（＾＾）
830 ：デフォルトの名無しさん：03/08/02 21:10
>>802に一票。
831 ：山崎 渉：03/08/15 16:25
　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
832 ：デフォルトの名無しさん：03/08/21 20:56
>>827
うるせぇーよ。
デザパタ厨上等。
おまぃが深く物を考えるのが苦手なだけだろ
833 ：デフォルトの名無しさん：03/08/26 10:03
MIDI演奏プログラムって何?
834 ：デフォルトの名無しさん：03/08/27 18:04
JavaHouseついに閉鎖か・・・・
835 ：デフォルトの名無しさん：03/08/27 23:35
お前ら！Ｄｅｌｐｈｉ知ってんのかよ！
Ｄｅｌｐｈｉこそが最強オブジェクト指向言語だぞ！
836 ：ココ電球（買い方：本物） ◆hEpdoZ.tHU ：03/08/30 04:03
　　地上にある星を誰も覚えていない

　　人は空ばかり見てる
837 ：デフォルトの名無しさん：03/08/30 12:26
>>785
人それぞれでしょうね。
漏れ的には要件開発を経験していない人はあんまりのような気がしますが。

>>835
一番使いやすいですな。
838 ：デフォルトの名無しさん：03/08/30 12:29
>>1
当たり前ですよ。戦場にしないためのＯＯなんだから。
839 ：デフォルトの名無しさん：03/08/30 12:40
>>806
> 0に何掛けたって0なんだよ！
ほう、NaNをかけてもか(嘲笑
840 ：デフォルトの名無しさん：03/08/30 13:07
NaN かける段階で double に型変換しちゃってるよーな。
841 ：デフォルトの名無しさん：03/08/30 15:39
OOPとOOA(D)がごっちゃになってないか。
OOPは有効だけど、OOA(D)はほとんど失敗する、
ちゅうかできる人がほとんどいない。
842 ：デフォルトの名無しさん：03/08/31 00:09
>>841
>OOPは有効だけど、OOA(D)はほとんど失敗する、
>ちゅうかできる人がほとんどいない。

激しく同意。
今の職場ではOOPすら出来ない男がリーダとしてOODやろうとしてまつ。
そいつは共通な手続きのサブルーチン化すら出来てないソース書いてるし
単にJAVAの文法を知っているだけ。
久しぶりに悲惨なプロジェクトを見た気がします。
843 ：デフォルトの名無しさん：03/08/31 01:39
OODって、デザパタヲタかい。
ちゃんとやれれば、それでええんやけど。

OO房も不満あればかけや、対決するで。
844 ：デフォルトの名無しさん：03/08/31 01:59
基地外が参戦して参りました・・・・
845 ：デフォルトの名無しさん：03/08/31 02:00
>>843　はExcelVBAしか書けないくせに、
　OOを騙ろうとするとは、不逞な輩だ(ｹﾞﾗｹﾞﾗ
846 ：デフォルトの名無しさん：03/08/31 07:50
集中力を手続き型より、必要とすると思う。
847 ：デフォルトの名無しさん：03/08/31 09:30
>>845
OODでうまくいったプロジェクトなんかほとんど見たことない。
1,2人できるやつがいても、まわりからみると
ややこしそうなコードを書いてるようにしか見えない。

OODの問題ってそこよ。
みんなが理解できてメンテできることが大事。
構造化手法で分析して、手続き型で設計する。
実装はOOP。継承やカプセル化などわかりやすい概念は使う。
848 ：デフォルトの名無しさん：03/08/31 10:20
ああああああああああああああああああああああああああああ
849 ：デフォルトの名無しさん：03/09/02 10:39
正直、プロジェクトが戦場になるのとOO採用するしないは無関係だと思われ。
それ以前の糞体制が多すぎる。
850 ：デフォルトの名無しさん：03/09/03 23:36
OOかんがえたやつはえらい。
正直簡単になった。。
851 ：デフォルトの名無しさん：03/09/07 22:11
OODでうまくいくのは、フレームワーク開発だけだな。
その上にのせるアプリケーションはOOなんか
はじめから捨てて考えた方がいいよ。
何十人、何百人に浸透させることなんてできっこない。
852 ：デフォルトの名無しさん：03/09/07 22:14
論拠も何も示さずに主観で言い放つだけなら、猿でもできる。
853 ：デフォルトの名無しさん：03/09/07 22:14
>>849
>それ以前の糞体制が多すぎる。
そうそう、それ以前の問題の方が多いよね。
854 ：849：03/09/08 13:27
うむ。
はっきり言って、OO採用したところで１ヵ月縮むかってとこなんだよな。
それ以外の意思決定だの調査だのの方が遥かに長い。
ま、その１ヵ月が命取りってなPJもあるかも知れんから無駄とまでは言わんが。
855 ：デフォルトの名無しさん：03/09/08 16:24
>>849
激しく同意。
OO採用してもしなくてもウチは戦場にならなかった例が無い。
毎日家に帰れる職業の人がたまに羨ましいよ…
856 ：デフォルトの名無しさん：03/09/08 18:15
設計もだが、リスク管理の問題か。
857 ：デフォルトの名無しさん：03/09/08 18:50
リスク管理なんて高尚なレベルじゃないんだよ。
基本的なホウレンソウが出来てないチームがあまりにも多い。
愕然とするほどにな。
858 ：デフォルトの名無しさん：03/09/08 21:27
PG はソースコードで語る。
もとい、コンパイルエラーと SEGV で語られた。
859 ：デフォルトの名無しさん：03/09/08 22:02
>どうも手続き手法に慣れすぎた為に、"もの"単位に考える事ができてないのです。
>本とか読めば理解は出来るんですが、実践で設計すると頭の切り替えが難しい・・・。
才能の問題だと思う。
OODはセンスが問われる。
バカには一生わからないだろうし
頭いい人はすんなり理解できて、使いこなしてる。
860 ：デフォルトの名無しさん：03/09/08 23:14
>>859
>バカには一生わからないだろうし
そう、↑これが本質。
なぜか理解できない奴は一生かかっても
できないとちゃうんかっつーぐらいほんとに駄目。
「てめー！なんでこんな簡単なことわかんねんだよ！馬鹿！」
ってうっかり叫んじゃうぐらい駄目。
861 ：デフォルトの名無しさん：03/09/09 07:59
>>859
どんな優れた考え方でも、まわりが理解できないなら、
実際のプロジェクトでは使えない。
みんなが理解できてメンテできることが大事。

851が書いているように、フレームワークなど
ブラックボックス化できるとこなら、OOもいいと思うけど。
862 ：デフォルトの名無しさん：03/09/09 09:15
馬鹿に関わらないことの方が大事だと思われ。
863 ：デフォルトの名無しさん：03/09/09 11:35
プログラマーの世界って悲惨でさ、
バカが100人集まっても、天才一人に勝てない。
そういう世界だよ。
864 ：デフォルトの名無しさん：03/09/09 11:42
凡庸な人間でも訓練次第で達人の1/5、いや1/10くらいまでの
能力を持てるようになるってのが技術だと思うんだが、甘いかねぇ。
いや、そうでも思わないと、
社内教育担当者としてはやってられないです(⊃дＴ)
865 ：デフォルトの名無しさん：03/09/09 11:50
>>864
イ㌔
しかし現実は残酷だが。
むしろダメな香具師は早めに引導渡してやるのが本人のためであろ。
866 ：デフォルトの名無しさん：03/09/09 11:56
ダメかどうかは判断できないが、少なくともやる気のあるなしは判断できるよな。
やる気無いくせに出社してくる奴、特にこんな時間に2chなんぞやってる奴は
俺以外全員ｸｽﾞ。
867 ：デフォルトの名無しさん：03/09/09 14:58
ホントに屑な奴ほどそう言うよな。
>>866は生きたサンプル。みんなじっくり観察するように。
868 ：デフォルトの名無しさん：03/09/09 15:04
何万もの民衆より一人のペリクレスのほうがよく働く
869 ：デフォルトの名無しさん：03/09/10 08:02
>>864
大丈夫。みんな最初は、凡庸な人間だから。
達人と呼ばれる人は、それだけ努力したからでしょう。

はじめはできない人間でも、教えてあげれば必ず伸びる。
みんな良い仕事をしたいと思っているのだから。

なんて、まじレスしてみるテスト。
まぁ、人を馬鹿にしてるだけのOO房は屑。
870 ：デフォルトの名無しさん：03/09/10 10:26
>>869
その発言は世の中を知らないか、でなければご自分が余程の適正があるのでしょうね。

プログラマとして給料を貰っている人100人集めても、ほんとに適正あるのは1人だけでしょう。
残りは
20人は才能＋努力で埋めている。
50人は努力で埋めている
29人は、そのほかの人の足を引っ張っている
871 ：デフォルトの名無しさん：03/09/10 12:04
OO厨なんていうな！
アフォの一つ覚えと言い換えろ！
872 ：デフォルトの名無しさん：03/09/11 00:32
>870

そーゆー考えをマジで逝ってるとするならお前はまだ２０台前半の筈だ。

873 ：デフォルトの名無しさん：03/09/11 00:36
>>872
実際には、開発に携わる人間が100人いて

1.交換不可能な有用な生産活動をしているのが1～2人
(天才1人と努力家1人)
2.交換可能な雑務担当が50人くらい
3.人月稼ぎのためのゴミが50人くらい

自分が1だと思ってる2が2,3人(非常にウザイ)
自分が1だと思ってる3が2,3人(ネタの宝庫で意外と面白い)

というところかな。
874 ：デフォルトの名無しさん：03/09/11 03:12
企業において、そいつでなければいけない！という存在は排除されるということも知っておけ。
そいから天才は生産活動、創造活動を行うが、企業はそれを理解できない。
努力家は創造活動は出来ない。

人月稼ぎのゴミ５０人の中に帳尻合わせの名人が２～３名紛れているのが普通だ。

＞自分が1だと思ってる3が2,3人(ネタの宝庫で意外と面白い)

これは実際、才能ある奴だが、飛びぬけた才能は企業に切られる事をさとったやつだろ。
思い込んでいるだけの奴はネタの宝庫になりえない。
875 ：デフォルトの名無しさん：03/09/11 07:45
>>874
そのロジックだと、企業は創造活動できないような(ｗ
プロジェクトが、才能のあるやつに依存するのは危険だけど、
企業を前に進めているのは、やはり才能のあるやつだと思うよ。

それを全部排除していたら、活力を失った駄目企業になる罠。
実際そういうとこもあると思うけど、そのうち滅びる。
876 ：デフォルトの名無しさん：03/09/11 07:57
ところが、最近の開発環境は、才能ない奴ばかり集めてもなんとかなってしまう。
それだけライブラリが豊かになってしまったって事だね。

いわく
・それは買ってきて貰った方が安上がりですよ
・遅いならパソコン買い換えればいいでしょ
877 ：デフォルトの名無しさん：03/09/11 08:31
>>874
ちょうど今日の週刊モーニングで、似たような話をしてたね。
　人間が人間で、てな話
878 ：デフォルトの名無しさん：03/09/11 11:41
>>873
同意。
顧客管理の世界に「80:20(20:80)の法則」(上位20%の顧客の支払うお金が、売り上げの80%を占める)
・・・というのがあるが、開発の世界も同じかな？
(1)全体の20%の人間が80%の仕事をする。
(2)その20%の人間のうちの、20%の人間が、その80%の仕事のうちの、80%の仕事をする。

ネスト2段で、100人の開発チームに適用すると・・・
(1)チーム内の上位4人が全体の64%の仕事をする。(一人16% : 天才と努力家)
(2)続く16人が全体の16%の仕事をする。(一人1%：人並み)
(3)残りの80人が残った20%の仕事をする。(一人0.25%：給料泥棒)

ネスト3段にすると、もっと面白いが、ここでは割愛。
879 ：デフォルトの名無しさん：03/09/11 12:50
>>878

上位20%の顧客の支払うお金が、売り上げの80%を占め
残りの80%の顧客の支払うお金が、売り上げの20%となり
その残りが万引きして20%を奪う

業種によっては利益にしたら20%の利益は利益の殆どという事になるだろうな。
880 ：デフォルトの名無しさん：03/09/11 15:02
利益だしを追求したければ、金貸しをやればいいんだよ。
利益率を言う奴は経済破壊者にすぎないんだ。
881 ：デフォルトの名無しさん：03/09/11 17:05
才能ない奴が才能ある奴を見抜けるはずがないのだよ
つまりだ、凡庸な人間が才能があるかどうかわかるはずがないのだよ
よってだ、俺様以外はみんな幻想を見ているのだよ
わかるか？負け犬℃も
882 ：デフォルトの名無しさん：03/09/11 17:10
>>881
うん。そんな感じのニオイがほんとにするよね。　ネタだとしたら上手だね。
883 ：デフォルトの名無しさん：03/09/11 17:22
>>負け犬℃も
これヤバイｗ

℃も℃もｗ
884 ：デフォルトの名無しさん：03/09/11 18:37
才能ある奴が他人の才能を認めて賞賛するわけないのだよ。
つまりだ、才能ある奴は自力で売り出すしかないのだよ。
よってだ、俺様含めてみんな幻想を期待しているのだよ
わかるよな？負け犬℃も
885 ：デフォルトの名無しさん：03/09/11 20:05
やばい、881のポテンシャルが高すぎる。
「負け犬℃も」
↑これわざわざ「ども」を変換して「℃も」を選択したんだろうな。
886 ：デフォルトの名無しさん：03/09/12 00:09
>>884
俺の経験上、才能ある人（＝できる人）は他人認めるのが上手いのだが。。。
どうよ？
887 ：デフォルトの名無しさん：03/09/12 01:02
>886
それは
今の職場に不満があって抜けたがっている奴は自分の後釜に据えられる奴を上司に示す（後が出来たから盛れを昇格しろ！というメッセージにもなる）

または、そいつがどう間違っても自分を脅かさない程度の人物である場合

さらには、そいつをどうにか追い出そうと考えているとき。能力以上の能力があると会社に思わせれば、普段そいつは手抜きをしているという印象になるからリストラリストに掲載されることウケアイ

同じ被雇用人どうしで、打算なく他人を誉めることはバカのやることだ。
888 ：デフォルトの名無しさん：03/09/12 02:41
>>886
相手を認めることが、自分の立場を脅かさないと確信している＝能力がある。感じ悪いけどな。
相手を認めてしまうと、自分の立場が危うい＝要するにその程度の能力しかないﾄﾞｷｭｿ。気持ちはﾜｶﾗﾝでもない。

まあ、ﾄﾞｷｭｿが不相応な立場にいると、仕事の上でいろいろなことが非効率的になるので、この際給与据え置き
でもいいからとっとと退場して欲しいもんだな。
889 ：ココ電球 ◆hEpdoZ.tHU ：03/09/13 03:37
上位２０％が８０％の仕事をこなし
中間６０％が６０％の仕事をこなし
下位２０％が４０％の仕事を増やす
890 ：デフォルトの名無しさん：03/09/13 07:22
>>889
波動砲かよ！
891 ：デフォルトの名無しさん：03/09/13 08:52
>>889
合計が160%だけど

派同胞って100%越え？

892 ：デフォルトの名無しさん：03/09/13 08:55
>>891
どう足したの？
893 ：デフォルトの名無しさん：03/09/13 11:44
>>891
客観的に見て下位２０％に入ってるよ。
894 ：デフォルトの名無しさん：03/09/13 12:33
設計バカなど死ねばいい。
895 ：一般PG：03/09/13 12:35
設計利口な設計責任者の下で働きたいもんですよ、まじで。
意味不明なくだらない苦労したくないですよ。
896 ：デフォルトの名無しさん：03/09/13 14:18
設計ミスがありゃすぐ指摘してやれよ。　・・・・ただし、やんわりな。
897 ：デフォルトの名無しさん：03/09/13 15:13
OOなんて当たり前の技術だろ？
OOすら使わないやつと一緒に仕事なんかできるか。
898 ：デフォルトの名無しさん：03/09/13 16:27
>>897
ＯＯ以外使えないんでしょ。厨ってことでいいですね。
899 ：デフォルトの名無しさん：03/09/13 16:31
あまりに効率が落ちるから使いたくないだけだな。
900 ：デフォルトの名無しさん：03/09/13 16:53
>>899
2倍3倍の効率低下はハードウェアのスペックで
どうにかなる。オーダーが違うわけじゃないんだ。
気にすんな。
901 ：デフォルトの名無しさん：03/09/13 16:55
C++やJAVAなどが有効なほとんどの状況では、良いプログラムを書こうとおもったら必然的にオブジェクト指向になると思うが。
確かに不要な状況も、まれにあるが。
902 ：一般PG：03/09/14 00:51
>>896
指摘すると逆恨みされて、ろくな目にあわないのですよ。
馬鹿のくせに、一流企業の花形職種でプライド高いので困り者です。
903 ：デフォルトの名無しさん：03/09/14 14:03
>>902
だから、やんわりとな。　　相手に花持たせるようにしながらくらいの処世術は身に付けてるでしょ？
904 ：デフォルトの名無しさん：03/09/14 15:27
ほんと、正規表現スレで暴れてるキティみたいなのが現実社会にも実在するからね。
905 ：デフォルトの名無しさん：03/09/15 09:58
結局、OOプログラミングは有効だけど、
OO設計をちゃんとできる人はほとんどいない
ちゅーことかな。
できるつもりのOO設計房が一番迷惑だと。
906 ：デフォルトの名無しさん：03/09/15 10:28
というか、
OO設計というのが子供だましみたいなもんだからさ
確かに大勢でドタバタやる時には共通のコミュニケーションベースとして役立つし
身に付けるのは悪くないけど、

現実の現場は、そんな設計フェーズなんかすっ飛ばして（というか設計フェーズ要るような仕事じゃないよ）
のラピッド開発じゃないとやっけないよ。

OO設計なんてしないで、OO言語を便利な道具として使う範囲が一番効率的さ
907 ：デフォルトの名無しさん：03/09/15 11:06
>>905
うちにも居るので禿同、おまいはOOすんな、その方がマシって奴がOO(のつもり)の設計してやがる。
デザパタくらい勉強しろや、それもしないでセンスがどうのこうのって10年早いって言ってやりたい。
たのむからそのレベルならC素直にで組んでくれ感じ。
908 ：デフォルトの名無しさん：03/09/15 11:08
>>907
加工中にへんになった
>たのむからそのレベルならC素直にで組んでくれ感じ。
たのむからそのレベルならCで素直に組んでくれって感じ。
909 ：デフォルトの名無しさん：03/09/15 20:23
>>906
確かに子供だまし。
うちの外注も、UMLのなんとか図とかを自慢げに示すんで、
ちょっと設計内容について質問してみると、スーパークラスがどうとか
言語レベルの説明しか出来ず、ぜんぜん質問に答えられない。
内容を理解してないんだよね、結局。

>>908
そのレベルの連中はＣで書いても使い物にならないわけだが

910 ：デフォルトの名無しさん：03/09/15 20:29
業務上必要な機能が何であるかを明確にする部分はＯＯではないよね
戦場になるのはこれが明確になる前にスケジュールが押すからなんで、
ＯＯ厨に責任はないのだが、そういった状況を読めない奴や自己保身に
走る奴はホントに使えない。
911 ：デフォルトの名無しさん：03/09/16 07:41
>>909
使い物にならない度合いがまったく違うんですよ、
goto スパゲッティーの方が OO スパゲティーよりは少なくとも見通しがいい
根性があれば何とか読める。
OO がスパゲティーになると、マジで救いようが無くなる。
912 ：デフォルトの名無しさん：03/09/16 07:53
>>911
Javaですべてをstaticメソッドにして、
1メソッドあたり、30ステップ以内とか決めてシステム作ると
案外見通し良かったりして。
913 ：デフォルトの名無しさん：03/09/16 10:13
>>911
呼び出し先のメソッドが実行時に決定される分、
ソースを眺めているだけでは実行順が追いづらくなり得るというのはあるな。
オブジェクト指向＝継承と考えている初心者が半端にOO気取るとそうなるかも。
914 ：デフォルトの名無しさん：03/09/16 11:27
【チンコのレス】

〓〓〓〓〓
　｜〓｜
　｜〓｜
　｜〓｜
　(⌒⌒)
　 ＼／
　　〓
　【チンコお守りレス】このお守りを見たあなたは超超超幸せ者！
2週間以内に必ず彼氏・彼女が出来るよ！
すでにいる人は超～ラブラブ　みんなが幸せになりますように…
そのかわりこのコピペを１時間以内に、5つ別のスレに貼り付けてね・・
でないと、あなたはインポや性病になります。
915 ：デフォルトの名無しさん：03/09/16 13:43
>>910
てゆーか戦場になってるにも関らず呑気にデザパタとかほざいてる香具師はマジで頃したくなる。
916 ：デフォルトの名無しさん：03/09/16 13:45
戦場には火の付くものだけあればいい
917 ：デフォルトの名無しさん：03/09/16 20:29
OO厨房とは、
A.OOを理解できない厨房なのか？
B.OOを効果的に使いこなせてない厨房なのか？
C.自分がOOを理解できないものだから、OO理解者をねたんで厨房と呼ぶのか？

どれだ？
918 ：デフォルトの名無しさん：03/09/16 22:29
OOが全てだと思っている。他のことは何もしらない。

信者ってものは総じてキモイな
919 ：デフォルトの名無しさん：03/09/17 00:12
>>918
そんなやついねーよ。
OOなエンジニアは、OOでなくとも設計＆コーディングできる。
と、願う。
920 ：デフォルトの名無しさん：03/09/17 02:15
>>919
ちがう。
ＯＯなエンジニアは、言語に依存せずにＯＯ的思想？で
設計＆コーディングする。
921 ：920：03/09/17 02:17
ＯＯなエンジニアは、ＯＯが道具であることを理解している。

ＯＯ厨は、ＯＯ！とかデザパタ！とか叫ぶと、社内その他の
所属するコミュニティ内部で自分の地位が上がるとでも思っ
ているかのような勘違いをしている。痛い。
922 ：デフォルトの名無しさん：03/09/17 03:46
>>921
いまどきそんな奴いねえよ。
趣味に「パソコン」とかくやつがいないのと同じようにな。

オブジェクト指向を知っているものは、常に新しいものを取り入れていかなければ
ならないという意識が、お前ら手続き型言語つかっているくらいで満足してい
るような奴らよりも非常に大きいんだよ。

今ではオブジェクト指向はもはや知ってて当たり前、使うは常識の時代だ。
923 ：デフォルトの名無しさん：03/09/17 03:56
>いまどきそんな奴いねえよ。
おまえがそうなんじゃねえの？
924 ：デフォルトの名無しさん：03/09/17 04:09
>>923
≧∇≦ﾜﾗﾀ
925 ：デフォルトの名無しさん：03/09/17 07:03
>>922
OO房は、常に新しいものを取り入れていかなければならない意識が
非常に強いと。(藁

そんなわけないだろ。
OOのどこが新しいんだ?
926 ：デフォルトの名無しさん：03/09/17 08:49
>>913
それだけならコードが縺れているだけだから、たいした事ないよ。難読ではあるが根性で読める。
インスタンスが縺れてくるとしゃれになりません。どんなに根性すえても読めません。
実行順序はおろか現状把握も不可能です。
927 ：デフォルトの名無しさん：03/09/17 09:30
gotoスパゲティや手続きスパゲティは局所的。
OOスパゲティは大域的。
928 ：デフォルトの名無しさん：03/09/17 11:21
OO厨はどんなものでもOOで解決出来る、と思いこんでるのが痛過ぎる。
929 ：デフォルトの名無しさん：03/09/17 12:21
>>923-925==>>928みたいなアンチも必死だな

>>928
OOの代わりにUMLで図を書いてみろよ。OOがプログラミング以外にも
使える用途があることがよくわかるぞ(藁
930 ：デフォルトの名無しさん：03/09/17 13:53
>>929
で？
使えるのとご利益があるのは別物だってくらい知っとけ。
お前みたいのが状況見ないで騒ぐんだよな。
「OO使えば愕然とするほど簡単なのに」てな。
931 ：デフォルトの名無しさん：03/09/17 17:55
>>925がアンチには読めないな。
オブジェクト指向ってそんなに新しい技術ですか？
WindowsやVBより古い技術が何で普及しないんだろうね。
932 ：デフォルトの名無しさん：03/09/17 21:16
>>931
OOは初心者プログラマには理解できないからなぁ。
個人的にOO大好きだけど、
他社（他者）の業務を引き継ぐ立場の人からみるとOOは敵かもしれないね。
933 ：デフォルトの名無しさん：03/09/17 23:31
ＯＯって言われても何のことだかわかんねーよ！！

えんえん900までみんなして伏字で語るな！ばかちん！！
934 ：デフォルトの名無しさん：03/09/18 00:01
Open Officeに決まってるだろうが！ばちかん！
935 ：デフォルトの名無しさん：03/09/18 00:12
>>931
なにいってんだお前はWindowsとオブジェクト指向がどう
関係があるんだか。Windowsもオブジェクト指向を使って
作られているだろ。オブジェクト指向でなかったら
さすがにあんなもんは作れない。

オブジェクト指向の考え方はプラトンの時代の頃からあったみたいだ。

VBより普及していない？　それも捕らえ方によっては微妙だ。
初心者やなんちゃってプログラマを除き、
上級者だけに絞りこめばOOはかなり普及していると思われ。

OOなしの開発は考えられないと言うのが業界の常識。
インドやアメリカではCMMレベル4,5を獲得し、すでにオブジェクト指向を
かなり使いこなしている。
936 ：デフォルトの名無しさん：03/09/18 03:22
>>935
CMMがOOとりんくしているのか、初めて知ったよ。
CMMのレベル5を取得していても腐った開発しているのは、
結構有名な派無しなわけだが。

それこそ、手続き型ジャン。
937 ：デフォルトの名無しさん：03/09/18 10:19
>>932
全くの初心者（文系卒新人プログラマ）にOOの初歩の初歩
（実世界の存在と対応するモジュール化とか、データのカプセル化とか継承とか）
を比喩を交えて説明したら、
「それって普通のやり方じゃないの？」と返ってきた。
ま、これはまれな例なんだが。
古参のCOBOLerが手続き型からのパラダイムシフトをできないでいる
様子と比べると、単純に初心者にOOは難しいとも言えないのかも。

「OOは戦場では云々」という発言は、そういうパラダイムシフトに失敗した人と、
パラダイムシフトに失敗しながらもOOを気取る奴を横目で見ている人が
言っている事なんじゃないか？

と煽ってみるテスト。
938 ：デフォルトの名無しさん：03/09/18 11:28
>>937
手続き型からなんでパラダイムシフトしなきゃいけないんだよ。
手続き型の欠点上げてみろよヴォケが。

って煽ってみるテスト。
939 ：デフォルトの名無しさん：03/09/18 13:18
>>937
だから戦場になるような職場ってのはOO以前の問題なんだって。
そして戦場になってからOODだの呑気な事ほざいてる香具師は逝ってよしなに。
940 ：デフォルトの名無しさん：03/09/18 19:31
手続き型からのパラダイムシフトってなんだよ。
JAVAは関数型言語なんか？
構造化設計からといいたいのか？

ところで、要件定義はOOではどのように扱うのかな？
941 ：デフォルトの名無しさん：03/09/18 20:04
戦場で生き延びるための道具なんじゃないかな。
ナイフ一本でも生き残れる奴は生き残るんだろうけど、
できれば中隊全員生かして帰したいしね。
942 ：デフォルトの名無しさん：03/09/18 20:42
>>938
あのな、手続き型の欠点ではなく、手続き型onlyによる手法に
欠点があるのだよ。そこらへんはUMLの本に載っていたりするよ。

オブジェクト指向型プログラミングは手続き型プログラミングを包含しているのだよ。
943 ：デフォルトの名無しさん：03/09/18 21:33
手続き型にしろOOにしろ、構造化を知っとらんとはなしにならん。
要は如何にうまく情報を整理できるかだ。それだけだよ。
944 ：デフォルトの名無しさん：03/09/18 21:43
>>943
混乱を避けることこそ一番期待される効果ですよね。

ところで、あなたの言う構造化とはどういう意味なのか教えていただけますか？

945 ：デフォルトの名無しさん：03/09/18 22:48
ところでOOは手続き型の一種だと思うんですけど・・・
あえて言うなら非手続き型というより超手続き型ってイメージだよな
946 ：デフォルトの名無しさん：03/09/18 22:55
>>940
要件定義は、OOでは行えない。
OOAの代表のようにいわれているユースケース分析は、
実は、構造化分析だ。OOとは相性が悪い。
947 ：デフォルトの名無しさん：03/09/18 22:58
>>942
そりゃ、手続き型Onlyは、無理があるだろう。
ほとんど手続き型で設計して、
ほんとに有効な部分は、OODでいく。
これが現実的。
948 ：デフォルトの名無しさん：03/09/18 23:45
て、手続きを上手に管理するための
949 ：デフォルトの名無しさん：03/09/19 00:08
COBOLでバッチとか、見方によってはOOだよ。
950 ：デフォルトの名無しさん：03/09/19 00:13
>>949
なんだ俺はＯＯ使いだったのか
でもそんなトリビアルなのなんでもいいんじゃない
951 ：デフォルトの名無しさん：03/09/19 06:52
戦場で必要ない理由は明らかだ。
戦場はすでに実装フェーズに入っている。
実装段階で有効な手法をOOは何も与えてはくれない。
ここはまだ構造化の世界さ。


ではOOはどこで有効なのか。１０も２０もの戦場を一度に管理し、
共通する項を見い出し、１０の戦場を５の兵隊で勝利するような場合に有効なのさ。

そう、戦場で兵隊がOOするのが間違いさ、兵隊使うのみ
952 ：デフォルトの名無しさん：03/09/19 08:34
脳みそがシュリンクし掛けた老人が、懐古趣味なカキコを続けてる、
レガシー・スレはここですか？

ここ１０年、このスレ住人みたいな原始人見続けてきたから、
いい加減飽きた。そろそろ進化して欲しい。
953 ：デフォルトの名無しさん：03/09/19 08:35
>>946
要件定義の際にOOなビジネスモデリングをする方法もあるのでそうともいえないかと。
ユースケース分析だけやってるとOOな気がしないけどね。
954 ：デフォルトの名無しさん：03/09/19 08:36
10年って事は自分も立派にご老人だとは思わないのかねえ
955 ：デフォルトの名無しさん：03/09/19 08:39
>>951
実際には「戦場はこれで終わりだ」という根拠不明の楽観論か
「次の戦場？しらね―よ」という無責任な論理を振りかざしているから、
次も、またその次も戦場になるんだけどね。

将来血を流さないために今だけ多目に血を流そうって言う考えがない奴多すぎ。
956 ：デフォルトの名無しさん：03/09/19 08:46
>>955
兵隊にそれを望むのが間違いなんだろう。
兵隊はその戦いの為に集められ、戦場が終われば散って行くもの。
957 ：デフォルトの名無しさん：03/09/19 08:53
>>953
OOなビジネスモデリングして客が理解できるのか?
958 ：デフォルトの名無しさん：03/09/19 08:54
ユースケースがOODではなくて構造化分析だ、
と主張する方が居るようですが。

Yourdonの構造化分析手法～OODには、当然のように連続性があるから、
両者を混同してしまうのも致し方ないかもしれませんね。
国内では不連続なトレンドとして扱われているかもしれませんが、
海の向こうでは、20年前から連綿とした進化があったわけで。
959 ：958：03/09/19 08:57
>>957
理解できない客なら、教育してさしあげたらどうでつか？
教育できなかったら、単に君の仕事の水準が下がるだけで、
俺は全然困らないわけだが（ｗ

>>958
× OOD
○ OOA
ね。
960 ：デフォルトの名無しさん：03/09/19 08:59
>>954
俺は10年で陳腐化するような、ちんけな基礎体力でちんけな仕事してる訳じゃーないんだが。
俺にとって、OOなんて所詮は、ちっぽけな一応用分野。。。
961 ：デフォルトの名無しさん：03/09/19 09:05
・・・・ちんけな仕事・・・・・

そう言われると、ご立派なお仕事なさってらっしゃるんでしょうな～と反応せんわけにはいかんのだが・・・
まあ、無職の妄想屋に聞いてもそんな面白い展開になるわけじゃなし、やめとこう
962 ：デフォルトの名無しさん：03/09/19 09:16
つうか、ひとつの技術・言語を妄信するやつは要らない。
963 ：デフォルトの名無しさん：03/09/19 12:04
つうか、「つうか」とか書き出すレスは糞
964 ：デフォルトの名無しさん：03/09/19 12:16
いわゆる1つの糞スレの終焉
965 ：デフォルトの名無しさん：03/09/19 12:35
中華、TuKa。
966 ：デフォルトの名無しさん：03/09/19 12:46
OO厨は文系率が高そうだな。なんであの程度のものに萌えられるんだ？
967 ：デフォルトの名無しさん：03/09/19 15:15
君子、キチガイに近付かず。
ＯＯすらさらっとこなせないキチガイが、
なぜこのスレに粘着しているのだろう。

療養と社会復帰訓練、頑張って下さいね（はぁーと
968 ：デフォルトの名無しさん：03/09/19 15:25
だから、サラっとこなしたいのよ。

さらっとやってくれ、さらっと。　実装段階に入ったら、それはもう要らん話なのよ。
なんとかパターンだのなんだの、そんなのはこっちに任せてくれって事よ。

そういうのはさ、鉛筆握って書き順なぞってやらにゃならんお子様にやってくれって。
969 ：デフォルトの名無しさん：03/09/19 15:49
分析での話しと実装設計での話をごっちゃにするとおかしいよね。

分析は正直わからん。
属人度が高くて、手法が確立できないじゃん。
万人がある手法にのれば、ほぼ同じ解をだせないようじゃ、品質が安定しない。

実装設計は上流の成果にもよるけど、安定はするよね。
970 ：デフォルトの名無しさん：03/09/19 16:04
んじゃ戦場になる原因を上げてくれ。
漏れは基本設計フェーズまでにプロジェクト内の力関係が解決出来なかったってﾊﾟﾀﾝが半分以上占めると思う。
971 ：デフォルトの名無しさん：03/09/19 16:08
>>969
普通、分析を元に設計するだろ。
972 ：デフォルトの名無しさん：03/09/19 16:11
>>971
だから、上流の成果にもよるとかいてるのよ。

分析が糞なら設計も糞か不可能。
分析がよければ、設計もよいと。

で、分析フェーズは属人性が高いけど、
設計はそれに比較して属人性が低いと感じているからその分安定する。
973 ：デフォルトの名無しさん：03/09/19 20:37
>>970
それは真実なのだから触れてはいけない、OOでファンタジーしましょ
974 ：デフォルトの名無しさん：03/09/19 21:13
今ふと思ったんだけど、究極のＯＯって、
こんなん作って　って言われたら、
インターネットやらなんやらからかき集めたもので、
いっちょ上がりとやる事なんだろうか？
再利用技術が進めば、誰もコーディングはしなくなり、
部品を集めて詰め込むだけで出来上がり。

そういう人はプログラマと言えるのだろうか。

そうであれば、常に新たなものを追い求める必要性ってのはＯＯは
切実だな。

逆に何にもないところでは何も出来ない奴になっちまうなあ
975 ：デフォルトの名無しさん：03/09/19 21:43
>>974
WEBサービスとかってその究極と思うけど。
部品をあるめるのではなく、あるサイト（サービスを提供している会社）に依頼して
その結果をもらう。
976 ：デフォルトの名無しさん：03/09/19 22:54
>>959
客を教育しようたぁ、大上段に構えたものだね。
客は新しいことを覚えることを望んでいない。
単に自分がやりたいことが実現されれば良いだけ。

OOのコンサルしてくれいわれたら別だが。
977 ：デフォルトの名無しさん：03/09/19 22:56
>>958
ユースケース分析のどこがOOなのか、
語ってくれよ。
国内も海外も関係ない。
978 ：デフォルトの名無しさん：03/09/19 22:58
>>976
>>959じゃないけど、仕向ける程度はよくやるけどね。
勉強しろー！は流石にいえないな。
利点をといて一緒にやってみます？がせいぜい。
979 ：デフォルトの名無しさん：03/09/20 11:53
>>974
アプリ・システムのデザインをする人
部品の組み立てをする人
部品を作る人
それぞれ特化していくんじゃない？
OOは組み立てをする人が憶えないといけない物、むしろアルバイトでもできるほどに簡単になるのが理想的。
OOを研究する立場にある人は大丈夫だろうけれど、OOプログラマはいずれ単価は極端に安くなると思う。
こういう事
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
をする人がいると多少もつかも知れないけれどね。
OOは絶対に知っておく必要はあると思うがあまり深く関わりたくない。
980 ：デフォルトの名無しさん：03/09/20 13:58
なんかC++だとOOも大上段に構えないといけないから大変だな。
981 ：デフォルトの名無しさん：03/09/20 13:59
>>979
ナイスなリンク　サンキュー。
しかしホントなんだろうか
982 ：デフォルトの名無しさん：03/09/20 15:02
>OOは組み立てをする人が憶えないといけない物、むしろアルバイトでもできるほどに簡単になるのが理想的。

そうなるように下位レイヤを組み立てられる人間がいないんだよねー。
OO厨は独り善がりな馬鹿がおおいので。
983 ：デフォルトの名無しさん：03/09/20 16:43
>>982
賛同しまつ。
984 ：デフォルトの名無しさん：03/09/20 17:01
>>982
なんか必死過ぎるなｗｗ
985 ：デフォルトの名無しさん：03/09/20 17:08
なんだかな。
986 ：デフォルトの名無しさん：03/09/20 17:08
やれやれ。　　
987 ：デフォルトの名無しさん：03/09/20 17:09
あらあら　　　　　　
988 ：デフォルトの名無しさん：03/09/20 17:09
こりゃこりゃ　　　　　　　　　　　　
989 ：デフォルトの名無しさん：03/09/20 17:10
かっぽれかっぽれ　　　　　　　　　　　　　　　　　　
990 ：デフォルトの名無しさん：03/09/20 17:10
それそれ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
991 ：デフォルトの名無しさん：03/09/20 17:13
991
992 ：デフォルトの名無しさん：03/09/20 17:14
９９２
993 ：デフォルトの名無しさん：03/09/20 17:15
九百九十サン
994 ：デフォルトの名無しさん：03/09/20 17:16
九九四
995 ：デフォルトの名無しさん：03/09/20 17:16
>>980
プログラムでご飯を食べている人にとってはC++は有り難い限りです。
996 ：逝ってよし：03/09/20 17:16
１０００！
997 ：逝きたい：03/09/20 17:16
一〇〇〇
998 ：逝く逝く、逝く～：03/09/20 17:17
1,000
999 ：さっさと逝け：03/09/20 17:17
アンチOO厨もOO厨も、もっと勉強しろ！！！
1000 ：さっさと逝けば？：03/09/20 17:18
マターリ逝こうや
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。