オブジェクト指向ー詐欺師の時代の終焉。

このエントリーをはてなブックマークに追加
1 ：逝って良しの１：
ついに統計が出てしまいましたね。

２CHでも、大分前からＯＯの有用性については現場レベルから疑問視
する声が上がっていました。

かような擬似技術が今までまかり通っていた原因は供給側、つまり
日経提灯やセミナー屋にももちろんあるでしょうが、需要側にも
擬似技術を受け入れる下地があったと思われます。

何時の時代にも仕事の出来ない、自分の能力の限界に気付いてしまった
若いＰＧがいます。
今のままでは決してベテラン技術者に追い付けない事を仕事で
実感している連中です。
彼らの逆転のチャンスはなんでしょうか？
社会の混乱を醸成し、混乱に乗じた革命。これしかありません。

ＯＯの出現はそんな彼らの需要にぴったりのモノでした。
従来からある用語を言い換えただけのインチキ性。
既存の技術者のスタイルを否定する構造。
反対者や疑問を抱く者には「新技術について行けない人」というレッテル
を貼るだけで追い出せるのですから、詐欺師にとってはこんなオイシイ
仕掛けはありません。

しかし、もう結果は出始めています。
革命ごっこはもう終わり。
まだ詐欺師に占拠されていない会社においては、一刻も早くこうした
擬似技術者の駆逐による経営の健全化を強く望むものです。
2 ：デフォルトの名無しさん：01/10/24 00:31
ガイシュツ。
3 ：デフォルトの名無しさん：01/10/24 00:33
オブジェクト指向プログラミング言語を今現在開発中の
ワタクシめはソフトウェア業界における逆賊ですか。
4 ：デフォルトの名無しさん：01/10/24 01:01
ネタだろ
5 ：デフォルトの名無しさん：01/10/24 01:02
>>1
まぁ。。。いつかは終焉を迎えるだろ＜オブジェクト指向
そして１０年もすれば新しいパラダイムが生まれることだろう。

>従来からある用語を言い換えただけのインチキ性。
制御文の構造化アプローチがgotoの悪用を防ぐために
導入されたのと同様、データー中心アプローチが進化
しただけで「優秀な」技術者にとっては何の新規性も
無いはずだ。

>既存の技術者のスタイルを否定する構造。
オブジェクト指向は、お前の従来のスタイルを否定するの
か？ということは、もともとデータ中心アプローチなんて
意識してこなかったんだろ？ゴミプログラマーめ。

>反対者や疑問を抱く者には「新技術について行けない人」というレッテル
>を貼るだけで追い出せるのですから、詐欺師にとってはこんなオイシイ
>仕掛けはありません。
別に「新技術について行けない人」というレッテルを貼っ
てるわけではない。
従来から存在する堅牢なプログラムを開発する手法に疎い、
それを判ってないあんたと一緒に仕事したくないと言ってる
だけ？判るか言ってることが？え？
6 ：デフォルトの名無しさん：01/10/24 01:04
たとえオブジェクト指向言語の使用を禁止されたとしても、
C言語だけには戻りたくないもんだ。

2chでやるより会社で反革命運動したほうがええんのちゃう？＞1のジジイ
7 ：名無しさん：01/10/24 01:14
オブジェクト指向が理解できない人って本当にいるの？
なんか信じられないんだけど。
つーかそんなやつが構造化プログラミングをちゃんとできるとは思えん。
8 ：6：01/10/24 01:21
一般社会では、齢を重ねるほど自分の力量を知り、無茶をしなくなる
ものだが、プログラマーの世界では全く逆なのがおもしろいな。
ジジイほど己の力を過信し、学校の窓ガラスならぬメモリを破壊しま
くる（わら

というわけで、1のタイプの人間を珍と呼んでいいですか？
9 ：デフォルトの名無しさん：01/10/24 01:23
マ板からの輸出品ﾊｯｹｿ
10 ：デフォルトの名無しさん：01/10/24 01:26
俺は構造化アプローチでプログラミングしてるからgotoは絶対
使わん！とわめきながら、if-elseを多重ネストした下手糞な
例外処理書いてそうで怖いです。＞オブジェクト指向わからん馬鹿ども
11 ：デフォルトの名無しさん：01/10/24 01:26
>>1
の○○ってのは、オーオーではなくて、なにか２文字当てはめてください
ってことなんじゃないの？ワザワザ全角にしてるんだし。
あてはめてあげようよ。

まぁ>>1は盗んだバイクで走り出してなさいってこった。
12 ：デフォルトの名無しさん：01/10/24 01:27
もう生まれて30年近いのに新技術か。。。

>>1
＞従来からある用語を言い換えただけのインチキ性。
暗黙知の形式知化って知ってる？
13 ：デフォルトの名無しさん：01/10/24 01:33
> ついに統計が出てしまいましたね。

いつ出たのだ?
14 ：デフォルトの名無しさん：01/10/24 01:34
少なくともこのスレと重複してるな。

やっぱりオブジェクト指向は幻想でした。
http://piza2.2ch.net/test/read.cgi/tech/1003815855/
15 ：13：01/10/24 01:34
>>14
統計ってそのスレにでてるやつ?
16 ：デフォルトの名無しさん：01/10/24 01:34
>>12
吉牛だって８０年前からあったなんて誰もしらなかったぞ？

もう無意味な「言葉遊び」は止めようね。＞ＡＬＬ
17 ：デフォルトの名無しさん：01/10/24 01:36
会社のジジイにSTLとEJBを教える小さな親切運動からはじめます。
アメリカのようにジジイ爆撃してばかりだとテロされるからな。
18 ：デフォルトの名無しさん：01/10/24 01:38
> 社会の混乱を醸成し、混乱に乗じた革命。これしかありません。

warata
19 ：デフォルトの名無しさん：01/10/24 01:41
ここからヘタレのボヤキが始まります。

=============== 開 始 ===============
20 ：デフォルトの名無しさん：01/10/24 01:41
>>16
まあ、1が「新技術」などとのたまう背景もあるわけで。
OOの周辺技術が盛んに研究されてるからね。

オブジェクト指向に関する新技術は今もたくさん出現していて、
その多くは使い物にならないが、
オブジェクト指向という基本概念自体の有用性は
オブジェクト指向をサポートした言語（C++/Javaなど）が主流になっている事実からも否定できない。
と言っておこう。
21 ：デフォルトの名無しさん：01/10/24 01:42
データー構造に着目して分析を行う事は別にOOではないよ。
データーフロー分析は構造化アプローチと親和性あるし。
要するに極度に抽象化された仕様を実装するためには高度な具体化が必要で、
そこまでやるのにOOの持つボトルネックが却って仇になるケースが現場では
起こりがちということなんだろうな。

ようは、手法なんてツールなんだから必要な物を使えばよし。
22 ：デフォルトの名無しさん：01/10/24 02:27
データーってゆーな、ジジイ！
23 ：デフォルトの名無しさん：01/10/24 02:31
22が良い事言った。
24 ：デフォルトの名無しさん：01/10/24 02:36
エヌ・ティ・ティ・データー
25 ：デフォルトの名無しさん：01/10/24 02:59
オブジェクト指向ー
ってなんですか？なんで語尾を延ばす必要があるんですか？
26 ：デフォルトの名無しさん：01/10/24 08:47
オブジェクト指向を使えないなんて、もったいないね。
かなり有用なのに。
27 ：親切な人：01/10/24 08:49
まあ、1は「憂鬱なプログラマのためのオブジェクト指向開発講座」でも
読んでおきなさいってこった。
28 ：デフォルトの名無しさん：01/10/24 11:01
１は自然科学の理念を勉強すれ！！
相対性理論はニュートン力学（過去の実績）を否定しない。
適用限界（あらたな需要）が生んだまで。
今日日へたすりゃ小学生でもわかる理屈です。
29 ：デフォルトの名無しさん：01/10/24 15:24
12と27が結論ってことで。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ ド終了 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
30 ：逝って良しの１：01/10/24 22:09
俺の時代が来る予感あげ。
31 ：デフォルトの名無しさん：01/10/24 22:16
ものごとを論理的に考える能力の無い奴、仕事に対する情熱のカケラもない
奴、などを積極的に採用していうことにより君の時代がくるかもしれん。
クズ連中と一緒に地獄の行進を。アーメン。
32 ：お胸おっぱい：01/10/24 22:22
また落ちこぼれｽﾚですか。
33 ：無理やり七資産：01/10/24 23:17
無理矢理合わないフレームワークに嵌めたソフトって
見たことない？
GUIと切り離せないクラスライブラリのせいで
デスクトップ開かないと動作しないサーバーとかあった気が。
34 ：デフォルトの名無しさん：01/10/25 22:04
連帯あげ
35 ：デフォルトの名無しさん：01/10/25 23:38
>>31
「ＯＯができない人間は、情熱がない、根性がない」
ＯＯが普及しない理由は、体育会系のプログラマにはそう写るんだね。
36 ：デフォルトの名無しさん：01/10/26 00:17
>>33

それはそのフレームワークのアーキテクチャが悪いのであって、
アーキテクチャのアーキテクチャ(メタアーキテクチャとでもいうか)、
フレームワークのフレームワーク(メタフレームワークとでもいうか)、であるOOには
あんまり責任はないと思うが。

>>35
どんなアーキテクチャやメタアーキテクチャでも、
「それを理解する"能力"が無い」か、
アーキテクチャのほうに「理解される"能力"が無い」
つまりアーキテクチャのほうがドキュだ(w)ってのか、
どっちかに属すると思われ。
37 ：＿：01/10/26 00:34
まずクラスの設計で躓くんだけど。
ソースを書く段階にに至れない。
プロの方々は違うのですか？
38 ：デフォルトの名無しさん：01/10/26 00:47
>>36
そう、OOが良い悪いっていうよりも、
既存のフレームワークが肌に合わない。
TCP/IPで通信したいだけなのに、
ウインドウイベントを処理しないと動作しない
通信ライブラリとか、依存関係に納得できない。
そこら辺だな。OO自体を否定する気はないね。
39 ：デフォルトの名無しさん：01/10/26 01:19
>>37
プログラミングとその前の設計（とその前の解析）は別。
ユースケースから勉強城屋。
40 ：デフォルトの名無しさん：01/10/26 02:42
>>1
すばらしい煽りだ。
41 ：デフォルトの名無しさん：01/10/26 04:04
方々のMLやBBSで、二言目には「オブジェクト指向では」と言う奴等がいて、
お決まりのパターンとして、そこのメインテーマを無視し
「おぶじぇくと指向とはなんぞや」を議論し出すから、なんとなく
イメージ悪い（藁

ま、今は普通に仕事で使うから、別段の思い入れは無いけど。
42 ：デフォルトの名無しさん：01/10/26 04:13
1がこのスレで
http://piza2.2ch.net/test/read.cgi/tech/1003924678/1-5
>なにそれ？
>必要な時に覚えればいいじゃん？
と仰っています。じゃぁOO言語なにかひとつ覚えろよゴラー!!と
思ったんは俺だけじゃあるまいsage。
43 ：デフォルトの名無しさん：01/10/26 09:05
>>42
覚えられないからダメといってませーん。
役に立たないからダメといってまーす。
sage
44 ：デフォルトの名無しさん：01/10/26 09:35
ははは
45 ：デフォルトの名無しさん：01/10/26 10:05
>>43
覚えられないから役に立たないんだよ・・
46 ：デフォルトの名無しさん：01/10/26 10:24
ＯＯを覚えられるか否か・・・・・
そんなレベルの低い話をしてるのでは無いだろ　ふぅ・・・・
47 ：デフォルトの名無しさん：01/10/26 10:34
道具の使い方がわからない（覚えられない）から
使い所もわからないんだろ？
巷で箸が流行り出したから箸でスープを食べてみたら
全然効率的じゃなかった。そういってるように見える。
48 ：デフォルトの名無しさん：01/10/26 11:33
俺からは４７も漏らさず厨房に見える。
49 ：デフォルトの名無しさん：01/10/26 12:21
厨房合戦が始まりました。
50 ：デフォルトの名無しさん：01/10/26 13:11
　　　＼＼　 厨房ワッショイ！！　／／
　+　+　＼＼　厨房合戦ワッショイ！！／+
　　　　　　　　　　　　　　　　　　　　　　　　　　　　+
.　　　+　　／■＼　 ／■＼　　 ／■＼　 　+
　　　　　（´∀｀∩　（´∀｀∩）　（´∀｀）
　+　　（(（つ　　ノ　（つ　　丿 　（つ 　つ　)）　　+
　　　　　 ヽ　（　ノ　（　ヽノ　　　）　））
　　　　　（＿）し'　　し（＿）　　（＿）＿）
51 ：デフォルトの名無しさん：01/10/26 19:52
こっちに移動よろしく

やっぱりオブジェクト指向は幻想でした。
http://piza2.2ch.net/test/read.cgi/tech/1003815855/
52 ：デフォルトの名無しさん：01/10/26 21:57
今日もあげあげ今日もあげ。

>>49
生活がかかってんの！
53 ：デフォルトの名無しさん：01/10/26 22:04
いい気なもんだよ。
そのうちＯＯ採用会社でリストラ始まるぞ。
それでもＯＯマンセーしてるつもりかねー。
54 ：デフォルトの名無しさん：01/10/26 22:28
で、1がこの板に出現してから何ヵ月も立ったけれど、
1はオブジェクト指向技術を何か一つでも体得できたのかね？
いや、マジで。oo云々以前に、そもそも進歩の無い奴はダメだと思うんだが。

ひょっとして、このスレで一番能力が低いのって・・・

1よ、君の血の滲むようなスレ立て・煽りカキコの努力の跡を、
私達は決して忘れはしない。私達は前へ進む。さようなら、1よ
55 ：デフォルトの名無しさん：01/10/26 22:35
それは進歩ではない幻想だ！
砂漠で見ているオアシスの蜃気楼と同じだ。
そっちへ行ってはいけない。
56 ：デフォルトの名無しさん：01/10/26 22:36
と、煽りだけになってるから。
生産性の低下は進歩ではなく退化だ。と付け加えておこう。
57 ：逝って良しの１：01/10/26 22:37
ハンドルも忘れたんで押しておこう。
58 ：デフォルトの名無しさん：01/10/26 22:42
いや、だから生産性低下してないし。
はやく蜃気楼見てるのは自分の方だって気づけよ･･･
59 ：デフォルトの名無しさん：01/10/26 22:43
統計は嘘をつかない。
60 ：デフォルトの名無しさん：01/10/26 22:49
>>59
統計でウソをつく方法
http://www.amazon.co.jp/exec/obidos/tg/detail/glance/-/books/4061177206/250-3156298-7668241
この本でも読んでしっかり勉強しろよ（ｗ
61 ：54：01/10/26 22:56
どうやら図星だったようです。プログラマー>>1に合掌。
62 ：デフォルトの名無しさん：01/10/26 23:21
>>60
死体画像。
63 ：デフォルトの名無しさん：01/10/26 23:27
>>62
アマゾンが死体なわけないだろ。
64 ：デフォルトの名無しさん：01/10/26 23:31
>>63
いや、アマゾン川のドザえもんだよ。≠ドラえもん
65 ：デフォルトの名無しさん：01/10/26 23:32
誰だよ,速報板に転載したのわｗ
66 ：デフォルトの名無しさん：01/10/26 23:39
おもしろいネタだった！感動した！>>1
でももう九尾吊って氏んでね。
67 ：デフォルトの名無しさん：01/10/26 23:40
>>63
アマゾンにはピラニアがいるだろうが。死体画像の可能性大だぞ。
68 ：速報板同一名スレッドからのこぴぺ：01/10/27 00:03
50 ：にょ ：01/10/26 23:43 ID:cekAAgue
オブジェクト指向って上級者のテクニックを何も知らない初心者・未経験者におしえるようなものだと思う。

何年か開発を経験した後にオブジェクト指向の本を読み直すと、非常に参考になることが多い。

とくにパターンの本は参考になる。


51 ：　 ：01/10/26 23:44 ID:rXMlpsSM
仕事してなくても帰りは遅い、生産性の低い>>49


52 ：　 ：01/10/26 23:48 ID:3B2NF3JY
東洋思想でオブジェクト指向を語る
「タオ・オブ・オブジェクト」って、オブジェクト指向の世界では
名著と言われてるんだけど、非常に胡散臭いと思うのは俺だけ？


53 ：にょ ：01/10/26 23:49 ID:cekAAgue
>>44
君は、小規模な開発しかしたことないね。（まあ、わしもだけど・・・）

１日～数日で中規模なソフトを作ろうといろいろ工夫していると、いつのまにかオブジェクト指向の考えに近づいていることが多い。

プログラムしかしないプログラマはむしろ駄目かも・・・。（わしは製品開発にプログラムを使用しているのであって、本業はプログラマとはいえない）


54 ： ：01/10/26 23:49 ID:APQkMxU/
オブジェクト志向は確かに上司を不機嫌にさせて遊ぶのにも使えるね。


55 ：　 ：01/10/26 23:50 ID:Vi0KjFnP
>>25
逆。
１の文章はプログラム板からのコピペだよ。


56 ：a ：01/10/27 00:00 ID:ahANcsYi
オブジェクト指向というと、オブジェクト指向をサポートした言語、
たとえばC++やJavaを思い浮かべるかも知れないが、サポートして
いないC言語などでもオブジェクト指向を取り入れた設計は可能で、
実際にOSなんかはそのように作ってある。つまり、OSというブラック
ボックスにメッセージを送ると、OSはそれに従って動くということだ。
Windows でも MS-DOS でも Linux でもこれは変わらない。


57 ：a ：01/10/27 00:01 ID:ahANcsYi
>>55
そうか。じゃああとでそっちに行こうっと。
ここじゃ場違いだよな。
69 ：デフォルトの名無しさん：01/10/27 00:06
>>56
たしかにデバドラとかUnixのVFSとかはオブジェクト指向っぽいと
言えなくもないが、ただのシステムコールをメッセージパッシング
と呼ぶのは牽強付会というものだろう。
70 ：デフォルトの名無しさん：01/10/27 00:43
ニュー速スレの方がそれなりのレベルに達しているのには笑った。
71 ：デフォルトの名無しさん：01/10/27 01:03
ニュー速の>>56みたいな意見を何度か目にするけど、
オブジェクト指向的？な設計がCでもできるということと、
継承や多態などのオブジェクト指向の強力な概念をOOPL
を使って駆使することの間には相当な開きがあると思われ。
72 ：デフォルトの名無しさん：01/10/27 01:09
>>71
#includeがあります。
73 ：デフォルトの名無しさん：01/10/27 01:10
>>71
ハァ？
74 ：73：01/10/27 01:13
チガターヨ。
>>72
にハァァ？


……ハァハァ………。
75 ：デフォルトの名無しさん：01/10/27 01:25
> 継承や多態などのオブジェクト指向の強力な概念をOOPL
> を使って駆使することの間には相当な開きがあると思われ。

おまえにとってのオブジェクト指向とは、
継承や多態の事らしいな。
技術を駆使してると勘違いしたプログラムほど、
はた迷惑な物はない。
1人で趣味でやってくれ。
76 ：デフォルトの名無しさん：01/10/27 01:34
>>75
オッサンでてきたね。最近どうやって召還したらいいかわかってきたよ。(w
ちなみにOOPLつかえば継承も多態も言語機能の一つに過ぎず、
『技術を駆使』してるつもりがなくても便利に使えるよな。
で、オッサンはCで関数ポインタや『ハンドル』駆使した再利用可能なライブラリを
日頃作り続けてるンですのん？
77 ：デフォルトの名無しさん ：01/10/27 01:36
ニュー速で言ってる事一部理解できませんが何か？
がはははははは　　ﾊｧ...詩嚢...
78 ：デフォルトの名無しさん：01/10/27 01:36
煽られると、すぐムキになる・・・・
79 ：1：01/10/27 01:44
>>75は俺じゃないぞ。民の声を聞け。
80 ：デフォルトの名無しさん：01/10/27 01:45
オブジェクト指向信者には共通した思考(指向?)パターンがある。妄想
で相手の人物像を作り上げ、自分で作った妄想に対して批判する。その
パラノイア的思考パターンを、自分では論理的だと信じている。どこか
のデザパタに、狂った思考パターンが存在するのか？
81 ：１：01/10/27 01:46
>>76
ちなみに俺はJava用のサブルーチンライブラリを構築中だ。藁
82 ：デフォルトの名無しさん：01/10/27 01:52
>>81
> サブルーチンライブラリ

ださっ！
83 ：１：01/10/27 01:54
>>82
笑うだろｗｗ
84 ：デフォルトの名無しさん：01/10/27 02:09
ウインドウハンドル（API）とウインドウクラス（MFC）なら、
前者の方が少なくともカプセル化の度合いは強いと思うけど・・
85 ：デフォルトの名無しさん：01/10/27 02:19
カプセル化だけがOOじゃないでしょ。
多態と継承はどうすんのさ。
86 ：名無しさん：01/10/27 02:31
結局>>1はオブジェクトとは何かすらわかっていないと思う。

どうでもいいけど、ここ（２ｃｈプロ㌘板）ってレベル低すぎ。
考え方も古いし視野も狭い。得るもの無し。
87 ：デフォルトの名無しさん：01/10/27 02:35
>>86
オマエモナー
88 ：名無しさん：01/10/27 02:42
スレによってあからさまにレベルが違うのがこの板のいいところ。
89 ：名無しさん：01/10/27 02:49
このスレってマルチユーザーアプリケーション作れない人たくさんいそう。
こわいこわい。
90 ：デフォルトの名無しさん：01/10/27 02:56
マルチユーザーマルチタスクのことですか？
91 ：ナナシ：01/10/27 03:04
「オブジェクト指向」が頭につく言葉っていろいろあるのだが、
どれの話をしているのだろう?
92 ：　　：01/10/27 03:10
>>86
ニュー速版のほうがレベル高いぞ(w
93 ：デフォルトの名無しさん：01/10/27 03:12
アンチOOって視点で捕らえなおすと発見があるかもしれん。
上流工程でのOOAも批判を見たいところ。
OOAの本を買ってみたんだけど、具体的なハナシに入る前に
終わっていて、セミナーの紹介があった。商売気がありすぎ。
94 ：デフォルトの名無しさん：01/10/27 03:14
>>86
新思想においては生産性など無視して良いのですね。
95 ：デフォルトの名無しさん：01/10/27 03:15
速報の内容にレスするのもなんだけど >>68-52
俺も Tao of object は迷著(!名著)だと思う。
話が抽象的すぎて何を言いたいのか具体的でないし
OOやデザインパターンを理解した現時点で読めば
内容が浅薄すぎる。混乱ばかり招いて何の役にも立たなかったな。
96 ：デフォルトの名無しさん：01/10/27 03:19
ま、「OOは役に立たない」なんて２ｃｈでしか言えないことは
確かだ・・・実世界で言ったら正気を疑われる。
97 ：デフォルトの名無しさん：01/10/27 03:24
というか OO が役に立たないといっている連中は何の言語を使ってるんだ？
組み込み系でアセンブラや C を駆使しているというならまだ分かるが。
98 ：ﾄﾞｷｭｿ：01/10/27 03:32
C++でのOOPってプログラムの挙動をソース内の2箇所を変更して違う実装で
同じことをするために導入したんだろ｡全部templateLibraryに置き換わった
理由じゃないか｡たいていのC++OOPにゅーもんしょは宅建技能の通信講座みたいな
もんだよ。○洋せんせーマンセー。
99 ：デフォルトの名無しさん：01/10/27 10:43
関連スレ

http://news.2ch.net/test/read.cgi/news/1004087790/
100 ：デフォルトの名無しさん：01/10/27 10:58
>>98
ＯＯとは関係ないけど、テンプレートはすごく便利だと思う・・・。
ばんばん使いまくっている。
101 ：デフォルトの名無しさん：01/10/27 10:59
>テンプレートはすごく便利だと思う・・・。
つーか使ってない奴はアフォ
102 ：デフォルトの名無しさん：01/10/27 11:04
何故、俺はこれができるを顕示したがる人が多いのだろう？
それが何の役に立つのだろう？さらっと何事もなかったように
いろいろな技術を使っていくことのかっこよさに何故気づかないの
だろう？
103 ：デフォルトの名無しさん：01/10/27 11:04
普通、作り始めてしばらくすれば、いじるのは上位層だけになる。
ライブラリを使うような層は滅多に触らない。
テンプレート使う奴は素人。
104 ：デフォルトの名無しさん：01/10/27 11:19
>>103
HA?
105 ：　　　：01/10/27 11:32
つーか、どこがオブジェクト指向だったんだ？
106 ：イソダ：01/10/27 11:33
ビットノ　ワタシノ　キジヲ　ヨミタマヘ
107 ：デフォルトの名無しさん：01/10/27 11:56
むかし、カメラができたころ、「写真を撮ると魂抜かれる」とか言ったんだって。
で、そういうの言い出したのは、カメラを受け入れられなかった人たち。
オブジェクト指向なんて、カメラやラジオのような当たり前の技術のひとつでしょ。
まだ、それを詐欺とか言ってるのは、まあ、あれだな、「俺は電話なんか使わんっ」
て言ってるGさんと同じだな。もう、今時、そんなのいないけどな。

ちなみに、カメラがあっても、使わなきゃいかんというもんでもない。
108 ：デフォルトの名無しさん：01/10/27 12:34
>>105
だから、「ＯＯとは関係ないけど」って但し書きしている。

>>103
上位層でもテンプレート使うけどね・・・。
109 ：デフォルトの名無しさん：01/10/27 12:43
>>108
俺もコンテナ程度ならバリバリ使うよ
110 ：　：01/10/27 13:08
>>108
なら、
テンプレートとか、継承とか、
そういう長所ごとにすすめてほしいもんだ。
111 ：デフォルトの名無しさん：01/10/27 13:15
103はSTL知らない素人
112 ：デフォルトの名無しさん：01/10/27 13:30
>>103
上位層にてvector,map,set,listを使わない理由を述べよ
113 ：デフォルトの名無しさん：01/10/27 13:39
>>112
>>103は template を書かないと言ってるような…。
114 ：デフォルトの名無しさん：01/10/27 15:04
>>113 普通は template も書くだろ。
class も書かないような使い方なら別だが。
VC++ などのコンパイラが力不足なので、言語仕様的に正しい
template メソッドがコンパイルできなかったりして鬱なことは
多々あるが
115 ：デフォルトの名無しさん：01/10/27 15:25
テンプレート（機能）とSTLをごっちゃにしないでくれよん。
テンプレートはC++の高度なマクロにすぎない、とか言ってみる。
116 ：デフォルトの名無しさん：01/10/27 15:36
>>112
iteratorを使わずにかってに実装依存の領域にまで踏み込んで、
vectorの内部配列をいじったりしてるんだろ
117 ：デフォルトの名無しさん：01/10/27 15:39
>>115
言うのは自由だが、C のマクロと同等だと思ってるようなら出直したほうがいい。
118 ：デフォルトの名無しさん：01/10/27 15:41
template ちゃんとサポートしてる処理系ってあるの？
現状ではまだ汎用性が疑問なんだけど。
119 ：デフォルトの名無しさん：01/10/27 15:51
>>118
Code Warriorはほぼ完璧だが
120 ：デフォルトの名無しさん：01/10/27 15:52
テンプレート＝つゆだく
言って見たかっただけと思われ。
121 ：デフォルトの名無しさん：01/10/27 16:24
>>118
まだ、処理系によって不完全な部分がある。特に partial specialization や member template,
namespace がからむと厳しい。

とはいえ、問題部分を抽出して #ifdef で切り分ければ、そこそこ使えるレベルには達してる
処理系が多いと思われ。
122 ：デフォルトの名無しさん：01/10/27 17:26
デザパタ＝ねぎだく
123 ：デフォルトの名無しさん：01/10/27 17:35
C言語＝つゆなし
124 ：デフォルトの名無しさん：01/10/27 17:53
COBOL＝ごぼうｻﾗﾀﾞ
125 ：joke：01/10/27 20:10
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
126 ：デフォルトの名無しさん：01/10/27 21:21
Ｃを批判する人に質問

なぜきみ達はＶＢを批判するのですか？
127 ：デフォルトの名無しさん：01/10/27 21:22
>>126
ﾃﾞﾑﾊﾟ?
128 ：デフォルトの名無しさん：01/10/27 21:31
http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html
「ほげ言語」のパラドックス

を読みましょう。

＞誰であれ、プログラムについて考える時には自分が使うことになった言語に思考が支配されているから、その言語に満足してしまうんだ。
129 ：デフォルトの名無しさん：01/10/27 22:43
>>128
激しく同意。だから、プログラムしかしない技術者はプログラマとしての視野が狭いことが多いように思える。
130 ：デフォルトの名無しさん：01/10/27 22:46
>129
それはまた別の話。
131 ：デフォルトの名無しさん：01/10/27 23:55
コーラン読んでる人間に、
回教は良いかと聞けば、
すばらしいと言うに決まっている。
批判なんかしたら、大変だよ。

聖書を読んでる人間でも同じ。
キリスト教のために、
過去に何万人死んでようが、
批判する人間は馬鹿にしか見えない。

コーランを読めば読むほど、
聖書を読めば読むほど、
教義の問題点が見えなくなっていく。

最後には、現実の生活のための教義ではなく、
教義そのもののために命までかける。
132 ：デフォルトの名無しさん：01/10/28 00:43
そのうち相対性理論は嘘だったとか、
おなじみのトンデモネタに移行しそうですね
>>1
133 ：デフォルトの名無しさん：01/10/28 00:45
>>132
批判はトンデモに移行してからにしたら？
134 ：デフォルトの名無しさん：01/10/28 00:49
コーラン読めない奴が居るとは・・・。
このスレのレベル低すぎ。
135 ：デフォルトの名無しさん：01/10/28 00:54
>>134
読めなくても、レベル低くても食っていけるからなぁ(藁
136 ：デフォルトの名無しさん：01/10/28 00:57
>>134
>>128-131の意味がわかってないほどレベル低い奴は
君以外にいないだろうな。
137 ：デフォルトの名無しさん：01/10/28 01:00
>>128
各言語での個人的蓄積と学習コストを無視したlisp信者の戯言である。
マシン語を低レベル低レベルと連呼してるのにはむかつく。
138 ：デフォルトの名無しさん：01/10/28 01:02
>>136
ジョークの判らない奴発見！
あれは

「ＸＸを指向理解できない奴が居るとは・・・。
このスレのレベル低すぎ。」

のパロディー
139 ：デフォルトの名無しさん：01/10/28 01:02
>>137
lisp知らないとそう思うんだよね・・。
140 ：デフォルトの名無しさん：01/10/28 01:04
信者の方が教義に詳しいのは当然。一般人は教義なんて知りたくもな
い。しかし教義がもたらす現実なら、一般人の方が冷静に判断できる
141 ：訂正：01/10/28 01:05
>>136
ジョークの判らない奴発見！
あれは
「ＸＸを理解できない奴が居るとは・・・。
このスレのレベル低すぎ。」
のパロディー
142 ：デフォルトの名無しさん：01/10/28 01:09
実際はマシン語でもスタートアップ時の差があるだけで
蓄積が増えて行けば生産性は高級言語と変わらなくなるんだよね。
実は言語の差などではなく、ライブラリの差だというのが
正解だと思う。
143 ：デフォルトの名無しさん：01/10/28 01:10
というわけで、白い言語でも黒い言語でも
ライブラリの豊富な言語が良い言語。
144 ：デフォルトの名無しさん：01/10/28 01:14
Lispの話はひとまずおいておいて
自分の知る言語が「ほげ」であるとして周りをみろ。
「ほげ」でばかりで思考するな、上も見ろってことだろう。

非OO言語だけの奴がOOが理解できるわけがない。
145 ：デフォルトの名無しさん：01/10/28 01:15
ただし、どんな言語のライブラリでも個人の蓄積を超えるライブラリ
は提供していない。
よって言語移動やってコスト的に見合うのは蓄積のない新米ＰＧか
蓄積できないアホＰＧだけということになる。
146 ：デフォルトの名無しさん：01/10/28 01:17
>>144
ＯＯが非ＯＯより上だと言ってるところが信者。
んでもって「向上心が無い」っつうんですか？
147 ：デフォルトの名無しさん：01/10/28 01:19
>>142
いや、
マシン語がアセンブリ言語より生産性が上がることは
絶対にない！

16進数でコーディング、命令増やすたびに分岐アドレス再計算
などやってられん。
148 ：デフォルトの名無しさん：01/10/28 01:20
>>144
言語なんかなんでもいいけど、糞Javaはライブラリ作るのに邪魔。
まあＯＯＰＬではＣ＋＋が一番まともだな。Ｃでも書けるから　藁
149 ：デフォルトの名無しさん：01/10/28 01:21
>>146
理解できないオヤジっていう、妄想パターンもある。
150 ：デフォルトの名無しさん：01/10/28 01:22
>>147
丁度良い比較対象として
ゲームボーイ（アセンブラ）と
ゲームボーイアドバンス（Ｃ言語）
を揚げておこう。
カセットのハード原価なんか同じっぽいし。
市場価格の差が無ければ、生産性の差が無い証拠。
151 ：デフォルトの名無しさん：01/10/28 01:24
>>147
そんな奴はいない。せいぜいハンドアゼンブル止まり。
152 ：デフォルトの名無しさん：01/10/28 01:24
まあ、アセンブリ言語のことをマシン語と呼ぶ場合もあるということで。
だってマシン語は言語じゃないし。
153 ：デフォルトの名無しさん：01/10/28 01:25
「オブジェクトほげ」使いから「非オブジェクトほげ」使いを見ていると
滑稽ですね。
154 ：デフォルトの名無しさん：01/10/28 01:26
>>151
いや、ハンドアセンブル無しでいきなり１６進で入力してマシン語
組む奴も居なくは無い。
155 ：ＯＯ使い3年生：01/10/28 01:27
プログラミング方法論の一つとしては結構面白いと思うんだけどなぁ。
156 ：デフォルトの名無しさん：01/10/28 01:27
>>153
だからお前だけが「オブジェクトほげ」使ってるんじゃないんだよ。
157 ：デフォルトの名無しさん：01/10/28 01:28
馬鹿は優越感を与えてくれる思想を信じるものです。
158 ：デフォルトの名無しさん：01/10/28 01:33
どんな言語にも、長所と短所がある。
長所が生きて、短所が障害にならない場所で、使えばよい。
アセンブラよりLispが優れているから、アセンブラはいらないとでもいうのか？
159 ：デフォルトの名無しさん：01/10/28 01:36
プログラマは自分の好みの言語を深く愛する質だし、私は誰も傷つけたくないので、
ここで仮想的なプログラミング言語「ほげ」を使って私のポイントを説明しよう。
「ほげ」は抽象度のスペクトルのちょうど真中に位置するものとする。
最もパワフルな言語ではないけれど、Cobolや機械語よりはパワフルだ。

そして、仮想的な「ほげ」プログラマ氏は、Cobolも機械語も使わない。
もちろん機械語なんて使わない。あれはコンパイラのためのもんだ。
それにCobolだって、あれで何かをきちんと動かしたことがあるって人を知らないよ。
結局のところ、「ほげ」にある機能xが無いもんな。

このプログラマ氏がパワーのスペクトルを見下ろしている時、
彼にはそうしているという自覚がある。
「ほげ」よりも力の弱い言語は、明らかに力が弱い。
彼が慣れ親しんだ機能が無いからだ。しかし、このプログラマ氏が反対の方向に目を転じた時、
彼は自分が見上げているのだということに気付かないのだ。
彼が目にするのは、変てこりんな言語ばかり。
多分、それらは「ほげ」と同じくらいパワフルなんだろうけど、
どういうわけかふわふわしたおまけがいろいろついているんだ、
と思うだろう。彼にとっては「ほげ」で十分なのだ。
何故なら彼は「ほげ」で考えているから。
160 ：デフォルトの名無しさん：01/10/28 01:37
OOは、分析・設計にまでは役に立つが、プログラミングそのものに対しては言語仕様に
依存するところが多すぎて、スマートさが失われることが多いぞ。
161 ：デフォルトの名無しさん：01/10/28 01:42
>>159
失礼とは思うが、あえていわせてもらおう。間抜けすぎる。
君がキャッシュカードを使うとき、汎用機のコボルプログラムが動いている。
汎用機のない全国システムとか、作れると思うのか？
日経バイトでも読んで、そんな幻想を抱いたか？
適材適所という言葉を、君に捧げよう。
162 ：デフォルトの名無しさん：01/10/28 01:42
>>159
だからその文章は各言語ＰＧの蓄積を無視してるんだって。
おまへは自分のライブラリを持ってなくて、プログラム組むたびに
１から全部コーディングするのか？
163 ：デフォルトの名無しさん：01/10/28 01:46
用途が尋常じゃなく多種多様にある計算機を、
ただ一つの概念で斬ろうとするから毎回こういった論争が起きるのでは・・・
164 ：デフォルトの名無しさん：01/10/28 01:46
>>161>>162

>>128のリンク先を読めよバカ
情報も集められないﾏﾇｹとは話にならんね
165 ：デフォルトの名無しさん：01/10/28 01:47
汎用機なんて２～３年すりゃ無くなるでしょ…
同じ性能のWS10個買う方が安いし…
信頼性っても、WSが同時に10個ぜんぶ壊れるよりは、壊れる確率高いし…
コボルで書いた過去の遺物プログラムはwrapしてそっと安楽死
させるんだろうけど、今から書くのにコボルつかっちゃ終りでしょ。
166 ：デフォルトの名無しさん：01/10/28 01:49
>>164
はたから見てると、只の負け犬の遠吠えにしか聞こえんのだが。
167 ：デフォルトの名無しさん：01/10/28 01:49
>>159
どの言語でもベテランなら「今の言語のままの方が速い」と言う。
当然だ。そして事実速い。
その言語での蓄積があるからね。
蓄積の問題を「嗜好」にすりかえた酷い煽りだ。
168 ：デフォルトの名無しさん：01/10/28 01:51
>>165
スパコンもなくなると思うのか？
金出しても、高性能と安定性を求める場所があるのだよ。
169 ：デフォルトの名無しさん：01/10/28 01:51
>>164
とっくに読んだよボケ！
お前はその後の反論が理解出来ないのか？
自分の共感を感じるだけで論理的に説明できないのか？
170 ：デフォルトの名無しさん：01/10/28 01:52
>>167
アセンブリ言語無しで動く電化製品を上げてみろ。
171 ：デフォルトの名無しさん：01/10/28 01:54
>>165
今あるコボルの資産を他の言語で書き直すことなどありえない。
だれもそんな費用を負担できない。
汎用機はクラスターマシンとして残るだろ。
172 ：デフォルトの名無しさん：01/10/28 01:56
>>165
日経コンピュータとかで、ずいぶん昔に同じ事いってたよ。
まあ、想像（希望？）と現実のギャップってやつかな。
173 ：デフォルトの名無しさん：01/10/28 01:57
いや、汎用機は只単に Linuxの入れ物と化すだろうよ。
まとまってた方が課金の管理とか楽だしね。
174 ：デフォルトの名無しさん：01/10/28 01:59
>>166
自作自演、必死だな。

>>167
では上をみることなく、「ほげ」にへばり付いて生きてください。
仕事は減っていくばかりで、後輩からは疎まれるだけでしょうけど。

>>165
IBMでも新規プロジェクトでCOBOLはもうありえないって。
ぜえんぶJavaですって。
残るけど保守だね。

>>169
じゃあコピペにまじれすしてないで
個人の蓄積が言語の進化を上回るという
納得できる資料を持ってきてもらいたいものだ。

>>160
まともな意見だね。その通り。スマート差を求めた結果がOOではないもの。
175 ：デフォルトの名無しさん：01/10/28 02:00
137は低レベルの意味わかってんのか??
176 ：デフォルトの名無しさん：01/10/28 02:01
>>171
どこかで「保守コスト」が「書き直すコスト」を上回ると思うが…

それはともかく、汎用機じゃなくてもCOBOLが動きゃいいんだろ？
177 ：デフォルトの名無しさん：01/10/28 02:01
>>174
また、根拠のない批判と、妄想による仮想人物像の生成・・・・・
あんた、ＯＯ信者だね。
178 ：デフォルトの名無しさん：01/10/28 02:03
>>176
想像の話と、現実の話は、区別してください。
179 ：デフォルトの名無しさん：01/10/28 02:04
>>176
書きなおした言語での保守コストも勘定に入れよう。
ひょっとして仕掛け人か？
180 ：デフォルトの名無しさん：01/10/28 02:05
実の無い論争・・
181 ：169：01/10/28 02:06
>>174
とっくに反論の中にはいっとる。
読んでから反論しろ　ぼけ！
182 ：デフォルトの名無しさん：01/10/28 02:06
OO を否定する気はないが アホな OO 信奉者にはウンザリ (-_-)
183 ：デフォルトの名無しさん：01/10/28 02:09
>>174
馬鹿が！自分だけがＯＯＰＬ使ってるとおもってやがる。
とさっきも書いた。
周りが見えなくなるくらいなら有害。
184 ：デフォルトの名無しさん：01/10/28 02:09
>>182
一生懸命にOOを否定してるやつにもうんざり
185 ：デフォルトの名無しさん：01/10/28 02:09
化石ソフトのお守りはともかく、
今から新たに書くならCOBOLは誰もつかわんだろ。
186 ：デフォルトの名無しさん：01/10/28 02:10
つーかさ。
java使ってるやつってほんとにOOわかってんの？

そんなんだからこういうスレたつんだよ。
187 ：デフォルトの名無しさん：01/10/28 02:10
>>184
私は OO 否定なんてしてないよ
188 ：デフォルトの名無しさん：01/10/28 02:11
>>185
汎用機はコスト高になるから案件が少ないしな
189 ：デフォルトの名無しさん：01/10/28 02:12
>>184
ハイハイ。せいぜいＯＯ目一杯導入してデスマーチで死んでくださいね。
190 ：デフォルトの名無しさん：01/10/28 02:12
>>187
ageてるのおまえだけだし。(藁
191 ：デフォルトの名無しさん：01/10/28 02:14
ＯＯがここまで叩かれるのは、ＯＯ派の一部に、現実離れした空想家がいるせいだろう。もしかして、反ＯＯ派の自作自演か？
192 ：デフォルトの名無しさん：01/10/28 02:14
>>186
判ってる奴は欠点も見えてくるものなのです。

判ってない奴は日経なんかのプロパガンダが頭の中を駆け巡るだけで
自分見て自分の頭で考える事が出来ない人なのです。
193 ：デフォルトの名無しさん：01/10/28 02:15
俺も上げてるけど？藁
194 ：訂正：01/10/28 02:16
自分の目で見て自分の頭で考える事が出来ない人なのです。
195 ：デフォルトの名無しさん：01/10/28 02:17
>>185
たしかにイー・ウイング証券はPCサーバだし、
スター・フューチャーズはUnix、
富士サイバーバンクはUnixクラスタだね。

海外の銀行や証券は5～6年前からUnixに移行してるよ。
196 ：デフォルトの名無しさん：01/10/28 02:17
いや、OOをよく分かってない段階で導入して痛い目にあったのが
山ほどいるからだろう。

ツールや言語がOOベースだからといって、それで生産性や品質が
常によくなるわけではない。

OOで何かをはじめるには、従来のソフトウェア開発の手法とは
違うベクトルでものを考えなければいけないのに、
それに気付かず、いざはじめて見て挫折するんだろう。
197 ：デフォルトの名無しさん：01/10/28 02:17
つーか、馬鹿には理解するのが困難だったり非常に時間がかかるが、学習後は飛躍的に生産性があがる
という言語があったとするわな。あくまで仮定な。
そして、君の下に何人か馬鹿な部下がいるとする。(あるいは君が馬鹿なプログラマだと仮定してもよい)
君なら開発言語に何を選ぶ?

馬鹿だらけの今の業界の状況では学習が容易な言語を選んだほうが生産性が結局は高いことはざらなのよ。
グローバル変数使いまくったほうがいいって言うぐらい馬鹿なやつしか集まらない惨状もあるのだよ。
そして、君は個人的に志を高くして効率のいい方法を学べばよい。
大きいところにいちゃだめだ。大勢の凡人がいるところでは凡人にあわせる必要があるからね。
128はベンチャーの話題だろ?
198 ：デフォルトの名無しさん：01/10/28 02:17
>>190
183も185も189も 私じゃないよ
自作自演だっておもってるの
だとしたら ちょっとノイローゼ気味かも
199 ：デフォルトの名無しさん：01/10/28 02:20
>>195
意味不明。
ＣＯＢＯＬってのはいつからＯＳになったんだよ　藁
200 ：デフォルトの名無しさん：01/10/28 02:20
　　　　　　　　　　　　　　　　　　　　　　　∧＿∧　　／￣￣￣
　　　　　　　　　　　　　　　　　　　　　∧（　＾∀＾）＜　終了
　　　　　　　　　　　　　　　　　　　∧（　 （ つ ⊂ ）　　＼＿＿＿
　　　　　　　　　　　　　　　　　∧（　（　つ.）　 ）　）
　　　　　　　　　　　　　　　∧（　（　つ　 （＿_）＿）
　　　　　　　　　　　　　∧（　（　つ　（＿_）＿）
　　　　　　　　　　　∧（　（　つ　（＿_）＿）
　　　　　　　　　∧（　（　つ　（＿_）＿）
　　　　　　　∧（　（　つ　（＿_）＿）
　　　　　∧（　（　つ　（＿_）＿）
　　　∧（　（　つ　（＿_）＿）
　∧（　（　つ　（＿_）＿）
（　（　つ　（＿_）＿）
（　つ　（＿_）＿）
｜　（＿_）＿）
（＿_）＿）
201 ：デフォルトの名無しさん：01/10/28 02:21
>>199
汎用機の意味わかっていない人発見
202 ：デフォルトの名無しさん：01/10/28 02:22
>>197
妄想大爆発非論理的思考回路要転職
203 ：デフォルトの名無しさん：01/10/28 02:25
＞馬鹿だらけの今の業界の状況では学習が容易な言語を選んだほうが生産性が結局は高いことはざらなのよ。
＞グローバル変数使いまくったほうがいいって言うぐらい馬鹿なやつしか集まらない惨状もあるのだよ。
はい、デスマーチ決定。
馬鹿を何人も自殺させ、退職に追い込んで、その上プロジェクトの顧客満足度は限りなく低いまま
プロジェクトは崩壊しましたとさ。
204 ：デフォルトの名無しさん：01/10/28 02:25
>>201
なんでＵＮＩＸに移行するとＣＯＢＯＬが使えなくなるのか
小一時間問い詰めたい。
205 ：デフォルトの名無しさん：01/10/28 02:28
PCサーバやUnixサーバで＊わざわざ＊COBOLで書くのか？
ヴォケか？
206 ：デフォルトの名無しさん：01/10/28 02:29
>>197
典型的な信者の反論だな。
想定問答集でもあるのか？
いままでちゃんと商売が成り立っていたのにＯＯ導入で大赤字
っつう現実をそうやって他人のせいにするとは。
207 ：デフォルトの名無しさん：01/10/28 02:29
>>202
面白意
藁汰
208 ：デフォルトの名無しさん：01/10/28 02:31
>>205
ＣＯＢＯＬは大抵ＵＮＩＸベースだろ？
ああ、サーバーね。
ｶﾞｲｼｭﾂだけどわざわざ最新のプラットホーム用のＣＯＢＯＬも
後を絶たないらしいんだな。
209 ：デフォルトの名無しさん：01/10/28 02:31
>>206
OO導入していない企業が
OO導入した企業を駆逐したという事例を紹介してください。

OO導入に失敗したという企業はわんさかありそうだが。
210 ：デフォルトの名無しさん：01/10/28 02:34
ＯＯ導入した企業が
ＯＯ導入してない企業を駆逐したという事例を紹介してください。

ＯＯ導入に成功したのに赤字という企業はわんさかありそうだが。
211 ：デフォルトの名無しさん：01/10/28 02:35
マ板へ逝け
212 ：デフォルトの名無しさん：01/10/28 02:38
>>210
情報関係なら、OOについていけない窓際族はいても、
企業ごとOOを導入してない企業なんて無い。
213 ：デフォルトの名無しさん：01/10/28 02:38
ＯＯが３０年前からあるそうなのに、ＯＯが未だに広く普及してないのは、
ＯＯを導入した企業がパタパタ潰れて行くからなのです。
214 ：デフォルトの名無しさん：01/10/28 02:39
で、OO を使わないとしたら開発手法は何使うわけ？
ひたすら「気合」「根性」「徹夜」「できるやつ頼み」？
215 ：デフォルトの名無しさん：01/10/28 02:39
>>212
そりゃＯＯＰＬ。
216 ：デフォルトの名無しさん：01/10/28 02:40
>>214
自分で蓄積したライブラリ。
217 ：デフォルトの名無しさん：01/10/28 02:44
>>216
転職（転社）したらどうするの？
218 ：デフォルトの名無しさん：01/10/28 02:46
>>217
言語変わっても同じようなライブラリを組んでしまう。
だから言語関係無し。
219 ：デフォルトの名無しさん：01/10/28 02:49
>>214
ソフトウェア工学って知ってる？
220 ：デフォルトの名無しさん：01/10/28 02:51
214 名前：デフォルトの名無しさん 投稿日：01/10/28 02:39
で、OO を使わないとしたら開発手法は何使うわけ？
ひたすら「気合」「根性」「徹夜」「できるやつ頼み」？

216 名前：デフォルトの名無しさん 投稿日：01/10/28 02:40
>>214
自分で蓄積したライブラリ。


馬鹿はいいねえ。気楽で。
あなたこのように思われてます

なんでこんな奴と給料が一緒なんだと思う瞬間
http://pc.2ch.net/test/read.cgi?bbs=prog&key=1000730743
221 ：デフォルトの名無しさん：01/10/28 02:51
>>217
そういった同じ様な開発手法を集めたんがデザパタじゃないの？
あまりレス読んでないんだが
222 ：214：01/10/28 02:55
>>220
なんじゃそりゃ。
指示ファイルに記述された複数のファイルにある複数の単語
（または文法規則）を一気に変換する個人ツール持ってますが何か？
223 ：デフォルトの名無しさん：01/10/28 02:56
>>219
もちろん in house な開発手法でやってるのだろうけど、
ほとんどは明文化されずに「いつもやっているようにやる」だけではと思ったので。
文書があっても読むと頭痛がするようなのだったりするが。。。
224 ：デフォルトの名無しさん：01/10/28 02:57
追記
アセンブラソースをＣ言語のソースに変換したりできる強力な奴ね。
225 ：220：01/10/28 02:58
>>>222
216のことを馬鹿にしてみたのですが、
226 ：デフォルトの名無しさん：01/10/28 03:00
まさか、自作自演ですか？
227 ：214じゃなくて216：01/10/28 03:00
間違いね。
228 ：デフォルトの名無しさん：01/10/28 03:02
>>218
そんな簡単に作り直せる量なら蓄積にこだわる必要もないね。
229 ：デフォルトの名無しさん：01/10/28 03:03
>>224
アセンブラからJavaにもできる？
だったら欲しい。
230 ：デフォルトの名無しさん：01/10/28 03:04
そうか、お得意の自作自演、しかも失敗か。毎度ごくろうさま。
231 ：デフォルトの名無しさん：01/10/28 03:05
218=216ね。
簡単ね。
つうか言語は邪魔ね。
変換規則ファイルいちいち書かなきゃいけないし。
232 ：デフォルトの名無しさん：01/10/28 03:07
>>229
あげない。
つうか個人ツールだから目的のファイルが得られたらそこで作るの
止める。
Ｊａｖａだと文法規則の解釈ルーチンを拡張しなきゃならんなあ。
233 ：デフォルトの名無しさん：01/10/28 03:08
ＯＯ使ってるけど、生産性は酷い。これは確実な実感。
再利用性は既存手法と変わらない。というより、既存手法でもＯＯでも無理。
でもＯＯを使い続ける。時代の流れなんだからしょうがない。
234 ：デフォルトの名無しさん：01/10/28 03:41
コードの再利用性を上げる唯一の方法は、コネで取れる常連客以外の仕事を
全部断る事だろ？
235 ：デフォルトの名無しさん：01/10/28 06:53
個人のコード蓄積うんぬんをいってるけれど、結局それは
プログラマそれぞれが車輪の再発明をやっている、という
世界観だよね？その世界観だと『コードの再利用』って奴は
せいぜい個人のレベル止まり。
そんな事をいつまでもやっていれば、
・他人のコードを修正する。
・新しい言語に移行する。
といった行為がコスト高になってしまうのは当たり前だと思うが。
236 ：デフォルトの名無しさん：01/10/28 07:08
ＯＯのお題目の再利用は非常に高貴なものだが
多種多様なリアル社会においては実践不可能
理論上可能なので試してみたら不可能だったのだ
237 ：デフォルトの名無しさん：01/10/28 09:21
>>235
あほか。
ライブラリレベルの細かいものじゃないわい。
どこにもないから自分で作るしかないの。

お前最先端の仕事した事ないだろ？
最先端の技術ってのは他社には秘密だし、名前なんかついてないんだよ。
世間でも認知されてないものなの。
238 ：デフォルトの名無しさん：01/10/28 09:52
> お前最先端の仕事した事ないだろ？

こいつ馬鹿？
239 ：デフォルトの名無しさん：01/10/28 09:54
>>237
厨房決定
240 ：デフォルトの名無しさん：01/10/28 10:47
>>238-239放置でおねがいします。

>>236、それはある意味正しい。
再利用性を考慮してOOを使いこなすのは非常に難しい
単なる構造化の方が再利用性は高い。

再利用性で生産性を高めるためにOOが生まれたわけじゃないです。

現実の事象にそってプログラミングできる利便性
それにより設計段階のプログラミングが非常にやりやすくなるし
仕様変更にもより柔軟に対応できるようになる。
加えてマルチタスクプログラミングがやりやすくなっている。
デザパタのStateパターンがイメージとして近い。
そういう目的があってOOが導入されてきたわけ。

OOが生産性が低いといっている人は
設計を行わずにいきなりコードを書き始めていないか？
決まりきった定型処理ばかりなら
それで生産性の高いことが出来るだろうが
複雑な仕様になると設計は必須だし
その設計を反映させるためのOOも重要になるのだが。
241 ：デフォルトの名無しさん：01/10/28 11:27
>>238-240
君ら、望み無し。
救いがたい。
242 ：デフォルトの名無しさん：01/10/28 11:48
＞237=241だよね？
面白い人ですね。コテハンを名乗られては如何でしょうか
243 ：デフォルトの名無しさん：01/10/28 11:51
237=241=あいつ、ほらちょっとまえこの板を荒らしていた、アイツ。

厨房に救われても迷惑だろう。
244 ：デフォルトの名無しさん：01/10/28 12:22
オブジェクト指向といえばRubyだよな。
245 ：デフォルトの名無しさん：01/10/28 12:30
継承による再利用は、うまくいかないことが多い。
委譲による再利用は、うまくいきやすい。
246 ：デフォルトの名無しさん：01/10/28 13:03
厨房は委譲という言葉の意味がわからないから絡んでこないらしい。

委譲はOOの中でもより構造化プログラミングに近い。
その方が再利用がうまくいくということ。
OOが再利用性が高いと思うのが間違い。
247 ：デフォルトの名無しさん：01/10/28 13:29
ＯＯは構造化プログラミングじゃないんですか？
248 ：デフォルトの名無しさん：01/10/28 13:31
ここに居るような奴等にはRubyなんて勿体ない。死ねよ。
249 ：デフォルトの名無しさん：01/10/28 13:39
>>245
委譲ってレイヤリングみたいなもん？
250 ：デフォルトの名無しさん：01/10/28 14:06
>>246
　　委譲はOOの中でもより構造化プログラミングに近い。
　　その方が再利用がうまくいくということ。
　　OOが再利用性が高いと思うのが間違い。

ワラタ
delegation (black-box再利用)の方を多用すべきなのは
OOを勉強した人間なら常識だろ。デザパタもそう。
251 ：デフォルトの名無しさん：01/10/28 15:19
継承しないでクラス変数のインスタンス置いて使うのが委譲。
252 ：デフォルトの名無しさん：01/10/28 15:55
クラス変数のインスタンス??
つゆだく認定。
253 ：デフォルトの名無しさん：01/10/28 16:11
変数のインスタンスって…
254 ：デフォルトの名無しさん：01/10/28 16:14
クラス変数のインスタンスはクラスです
255 ：デフォルトの名無しさん：01/10/28 16:19
>>251
なるほど。
レイヤリングもクラスのメンバにオブジェクトのインスタンスを
置いて使うものと自分は理解しているんだけど、委譲とは
何か違いがあるのかな？初心者でｽﾏｿ
256 ：デフォルトの名無しさん：01/10/28 16:26
他のオブジェクトをフィールド/メンバ変数/インスタンス変数として保持し、
そのインターフェイス（publicなメソッドね）の一部（または全部）をラッピングして
自分のインターフェイスとして外部に提供する。
257 ：デフォルトの名無しさん：01/10/28 16:28
頭痛が痛い。
258 ：デフォルトの名無しさん：01/10/28 16:28
>>255
いいから251じゃなく256を信じとけ。
259 ：255：01/10/28 16:33
>>256
他のクラスを、インタフェイスも含めて内包したものが(継承は行わずに)
委譲ってことですね。わかりました。
ありがとうございます。
260 ：デフォルトの名無しさん：01/10/28 16:56
どっちか一つのスレに統一したら？
261 ：デフォルトの名無しさん：01/10/28 17:07
両方終了でいいよ。くだらねえ。
262 ：デフォルトの名無しさん：01/10/28 17:08
こちらのスレはオブジェクト指向相談室になりました。
263 ：デフォルトの名無しさん：01/10/28 17:41
>>259
何故委譲が推奨されるか（つまり安易な継承が推奨されないか）は
この文書の「実装の継承に関する問題」を読んでくれ。
http://www.microsoft.com/japan/developer/library/jptech/TechArt/VTools/vb/vb6/ifacebased.htm
264 ：デフォルトの名無しさん：01/10/28 17:43
>>263
ﾌﾞﾗｸﾗﾁｭｳｲ
265 ：デフォルトの名無しさん：01/10/28 18:11
>>264URLみろよ。

不毛な議論の
マ板での受け入れ先がきまりました。
各位よろしくおねがいいたします。

今思ふ　　今の時代言語は何でも言いと・・・
http://pc.2ch.net/test/read.cgi?bbs=prog&key=1003835137
266 ：デフォルトの名無しさん：01/10/28 22:33
不毛だ不毛だなんて言ってごまかしてる。
そんな手しか思いつかないのか？

１）ＯＯ推進者は実は生産性なんかどうでも良いと思ってる詐欺師。
２）ＯＯ推進者はプロジェクトが失敗しても何かを生産したと思ってる馬鹿

これは問題だぞ。
267 ：デフォルトの名無しさん：01/10/28 22:36
>>266
馬鹿呼ばわりされて悔しい日常なのには同情するがもう飽きた。
268 ：デフォルトの名無しさん：01/10/28 23:09
>>266
憐れみすら感じさせる発言だねぇ。
ageてるし。
よっぽどかまって欲しいらしい。
269 ：デフォルトの名無しさん：01/10/28 23:40
３）旧世代を倒せ！未来は君達若者の手に掛かっている。
　　と煽って紅衛兵を生産した。
270 ：デフォルトの名無しさん：01/10/28 23:43
すいません。コンポジションも教えていただけるとうれしいです。。
私は委譲は>>251さんの意見と同一の理解で、コンポジションは
委譲と同様のインプリで意味は他のオブジェクトとのつながりが非常に密なもの(切り離せない)という理解です。
委譲の方の意味は実現したい昨日を他にお任せするという理解です。
・・・どうでしょうか？
271 ：デフォルトの名無しさん：01/10/28 23:46
コンポジションは多態とのつながりが密接だからなあ。

他とのつながりが密なわけではなくて、
他との切り口が同じになっていることを言うんだよ。
272 ：デフォルトの名無しさん：01/10/28 23:56
>>271
もっと分かりやすくきぼん。
273 ：デフォルトの名無しさん：01/10/29 00:15
>>272
わかりやすく言うからよーく聞け。

スレ違いだ。
274 ：デフォルトの名無しさん：01/10/29 00:23
>>273
本来ここは技術板なのだから、1の方が板違い。
275 ：デフォルトの名無しさん：01/10/29 00:28
>>274
オブジェクト指向の効能書きを読み返すべし。
生産性を問題にしないオブジェクト指向なんて合って良いはずが無い。
276 ：デフォルトの名無しさん：01/10/29 03:00
派生クラスでオーバーロードした関数の返り値などは、基本クラスで約束されたものの範囲でなければいけない。
277 ：デフォルトの名無しさん：01/10/29 03:05
>>276
どうしたいきなり？
まあ、静的型言語ならそうだな。
278 ：デフォルトの名無しさん：01/10/29 03:11
>>277
covariantかcontravariantかっていう話じゃないの？
279 ：デフォルトの名無しさん：01/10/29 03:36
>>278
その問題は typing があるから生じるんでないの？
まあ、確かに型付けがある言語が一般的だし、
コンパイルをすり抜けるようなエラーが生じるややこしい問題だってのは分かるが。
280 ：デフォルトの名無しさん：01/11/01 01:21
再利用あげ
281 ：デフォルトの名無しさん：01/11/01 01:23
>>276
VC++でcovariant return typeの扱いにバグがあるのは有名な話だが、
それが何か？
282 ：デフォルトの名無しさん：01/11/01 01:24
>>280
これ↓の次スレとして使おうという目論見？　それなら、賛成一票入れとく。

やっぱりオブジェクト指向は幻想でした。
http://pc.2ch.net/test/read.cgi/tech/1003815855/
283 ：ＯＯ初心者：01/11/01 07:57
こういうＯＯ批判（罵倒？）スレを見かけると、物理板で定期的に
上がってくる「相対性理論は間違っていた！」みたいなスレをつい
連想してしまう。
ただしそちらでは相対論擁護派の勢いが強くて（まあ当然だけどね）、
やがてスレ立ての１はスゴスゴと退散というのがいつものパターン。
しかしこちらではＯＯ擁護派の意見に今ひとつ迫力が感じられないのは
どういうわけだろう？　やっぱり胡散臭いところがあるということか。
擁護派の皆さん、何か後ろめたい気持ちがあるんじゃないの？（ｗ
284 ：デフォルトの名無しさん：01/11/01 08:41
なんつーの、OO批判って的外れな批判なんでなあ。
ソフトウェアの品質をどう評価するかって部分で噛み合わないし、
ウォーターフォール開発に凝り固まっている組織にOOを導入するコストは
OOを導入したことによるメリットを軽く上回るだろうしなあ。

# まったく新規にソフト会社を作るとして、OOを採用しない理由はないと
# 思うがな（関数型言語を採用するなんて剛毅な会社があってもいいけど）。

まあ、とりあえずOOを批判するならMeyerの著作の主張に反論してみて
ほしいね。あと、どうしてIBMがRGBとかを捨ててJavaに移行してるか
とかな。
285 ：デフォルトの名無しさん：01/11/01 09:09
ＯＯがウオーターフォールと対立すると思ってる馬鹿発見。
286 ：デフォルトの名無しさん：01/11/01 09:11
>>283
ＯＯが原理だと思ってる基地外発見。
287 ：デフォルトの名無しさん：01/11/01 09:28
>>284
学生さんですか？
反論とか理論とかは私には意味無いです。
現実に使えるかどうか、それしか興味ありません。
生産性が上がるなら理論でなくても、たとえ矛盾してても使いますし、
下がるならどんな立派な理論でも使いません。
それだけ。
288 ：284：01/11/01 09:35
俺はOOで飯食ってるよ。
生産性ってのもプログラマーしかやっていない奴のレベル
（生産性＝仕様書通りのコードを早く書けること）
と、クライアントと交渉する奴のレベル
（生産性＝クライアントの要求を低コストで実現すること）
とでは、まったく観点が違うからね。仕様書も書くし、
コードも書くという奴なら、なおさらOOを選択するでしょ。

要求が五月雨式に出てくるようなプロジェクトで、
OOしないなんて、少なくとも俺にはできない。
289 ：デフォルトの名無しさん：01/11/01 09:38
>>287

生産性っていう言葉の定義が問題だな。
誰が何を使うとどう生産性に影響がでるか。
学習に多大なコストがかかるのは、学習内容のレベルが高い場合と
学習者のレベルが低い場合がある。

反論とか理論とか、と並記するあなたの国語のレベルはどうかと思うが。
290 ：デフォルトの名無しさん：01/11/01 09:40
プログラマから見ると

　OO的に継承を使う処理は、インスタンスが複数作られ、かつオブジェクトの機能が固定され
　る事を前提にする場合非常に巧くゆく
　　その代表はGUI的処理

一つのプロセスでインスタンスが１つあればよい場合は　ユニット・モジュール分割で十分

オブジェクトの機能が固定されない場合、OO的に継承を使って書くのは馬鹿げている
　その代表は、社員や商品ををクラスで表現なんて事
291 ：デフォルトの名無しさん：01/11/01 09:46
詐欺師も必死だよ。
誰だって死にたくないからな。
292 ：デフォルトの名無しさん：01/11/01 09:59
>>283
ホントだね。トンデモな人達がこんなに多いとは。

>>290
OOで継承が重要だと思ってるバカ発見。
293 ：デフォルトの名無しさん：01/11/01 10:38
こういう継承の使い方を勘違いしたバカがいるために、
OOに関する間違った印象を与えているとしたら
とてーも残念なことですねー。
294 ：デフォルトの名無しさん：01/11/01 12:01
>OOで継承が重要だと思ってるバカ発見。
↑
こういう言い方が一番根拠が無い、知ったか学生だＹＯ！
自分の立場も明らかにしてないし、自分の意見も無い。
継承を否定するのが大学のトレンド（古い言葉だけど厨房にピッタリ）なだけだろ？

OOで継承が重要じゃないと仮定しても、
プログラミング（OOP）では、時間が有限であるため、差分コーディングは重要。
295 ：デフォルトの名無しさん：01/11/01 12:06
>>294
でも誰が見ても290はバカ。
296 ：294：01/11/01 12:08
そう言われればそうだ、290の文章って見た目階層があるのに中身に階層無くて、羅列だ。
297 ：デフォルトの名無しさん：01/11/01 12:59
何このスレ？ OOについて行けない>>1のバカぶりをみんなに
知ってもらうためのスレ？
298 ：290：01/11/01 13:01
おバカな290 です

　じゃ、継承を使わないオブジェクト指向によるコードの例あげてみてよ >>ALL

　既存の言語で継承使わないで書いたら、　普通はモジュールとかユニットって呼ぶぞ
　そしてそれは FILE *fp の頃からやってたやり方だ
299 ：デフォルトの名無しさん：01/11/01 13:06
>>298
FILE* をモジュールとかユニットとか言う人は少ない
300 ：デフォルトの名無しさん：01/11/01 13:14
>>298
そもそもクラスベースではないオブジェクト指向言語もある。Smalltalk とか JavaScript とかね。
勉強して出直しましょう。
301 ：デフォルトの名無しさん：01/11/01 13:33
http://www.atmarkit.co.jp/fwin2k/opinion/ogawa/ogawa_200110.html

この手のブームはMISで耐性がついています。
302 ：290：01/11/01 13:38
>>300　　おいおい
　おバカな290でも Smalltalk にも JavaScript にも継承がある事くらいは判るぞ
303 ：290：01/11/01 13:44
おバカな290だから Smalltalkなんて高尚なものは触った事もないが
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak4/index.html
　ここを見た感じでは　クラスという概念はあるようじゃないか
304 ：デフォルトの名無しさん：01/11/01 13:45
>>300書いた奴はｲﾀｲ。。。
305 ：デフォルトの名無しさん：01/11/01 14:02
>>304
ネタであることを祈ろう。
306 ：デフォルトの名無しさん：01/11/01 14:06
>>300 の定義はおそらく↓

オブジェクトベース→実行時に継承→インタープリタ実行時に継承
→インタープリタ＝Smalltalk or JavaScript
307 ：デフォルトの名無しさん：01/11/01 14:30
JavaScriptがクラスベースでないのは確かだが継承はあるよね。
>>290よ、OOはダメだそうだが抽象データ型はどうなんだ？
308 ：デフォルトの名無しさん：01/11/01 14:45
>>1
OOで失敗を経験した奴がOOに私怨を抱いているだけと思われ
309 ：290：01/11/01 17:25
>>307　抽象データ型って C++でいう テンプレートじゃなくて interfaceの方でやんすね？
　いわゆる似た操作には同じ名前を使いましょうって事を発展させた奴でやんすね？

　あれば便利って事なら異存はございやせんぜダンナ。

　単に同じ名前にしとけば interface被せて便利に使えるんだから、こりゃ便利でやんすね
310 ：デフォルトの名無しさん：01/11/01 17:41
別スレで抽象データ型、という言葉を出したら誤解
してた人もいたようなので便乗で書いておくと、
抽象データ型(Abstract Data Type)、とはそれの
内部表現にまつわる関数群等をデータと一体にし
て定義したデータ型の事だ。そのデータ型を用い
る事により内部の実装を隠す事をデータ抽象と言う。
オブジェクト指向の一つ前の段階。

もちろんオブジェクト指向はデータ抽象を支援する。
311 ：290：01/11/01 17:50
290で書いた事と重複するけど、
　抽象データ型も、
　オブジェクトの機能がが静的な場合　つまり属性、所属が静的な場合非常に巧くゆく。
　GUI以外に、数学ライブラリ（行列ベクトル、多倍長）とかね
　だからあれば便利だと思うよ

しかし、 時間変化とともに状態＝所属が変化するようなものを扱う場合＝
　interfaceを動的に切り替えなければならない場合困った事になる
　　JavaScriptなら動的にメソッドチェンジ出来るし、Delphiならイベントにしと
　けば動的にメソッドチェンジ可能だけど、
　　これって判り易いか？

　歩と成歩くらいの事なら、どっちでも、そりゃ問題ないけどさ
312 ：デフォルトの名無しさん：01/11/01 17:50
>関数群等をデータと一体にして定義したデータ型の事だ。
↑
誤解してるＺＥ！
だって、データ型の事だ、だと、データが隠蔽されてないじゃん！
313 ：デフォルトの名無しさん：01/11/01 17:53
>>312
日本語変だぞ

> だって、データ型の事だ、だと、データが隠蔽されてないじゃん！
言語と、やりかたによる。
314 ：312：01/11/01 18:04
だせーいいわけ！>>313

どっちにしても、日本語変だとしても、
「データ型」ってのは、データ丸見えであって、データ隠蔽してないの！
従って、データ抽象にはならん。
315 ：デフォルトの名無しさん：01/11/01 18:12
ふう・・・
>>314 みたいなのがプロジェクトで頑張ると　OO導入は大失敗に終る事間違いなし
316 ：デフォルトの名無しさん：01/11/01 18:17
なんか、言い訳が情けないＹＯ>>315

だって、文書の間違いを指摘されたら、修正版の文書を出すのが先でしょ！
317 ：デフォルトの名無しさん：01/11/01 18:17
>>314
つーか、黙れ。
318 ：デフォルトの名無しさん：01/11/01 18:18
>>316
話が出来ないなら、書き込みするな。
うざ。
319 ：デフォルトの名無しさん：01/11/01 18:20
間違いを指摘した相手に黙れとはダメだろ。
話が出来ないって「314」に論理的に書いてるじゃない。
出きるもんなら、314に反論してみろＹＯ！
320 ：デフォルトの名無しさん：01/11/01 18:21
反論も何も、言ってる事判んないよ >>319 あんたダメダメ
321 ：デフォルトの名無しさん：01/11/01 18:23
では、先ず、「データ型ではデータ丸見え」って分かりますか？
322 ：デフォルトの名無しさん：01/11/01 18:24
じゃまあ　相手しますか・・・・　判りませんよ >>321
323 ：デフォルトの名無しさん：01/11/01 18:27
データ型で変数宣言しますよね。
そのとき、その変数に値を入れることが出来ますよね。
また、その値を他に移すことできますよね。
これを値丸見えと言います。

で、どうだ？>>322
324 ：310：01/11/01 18:28
うわ、なんかすごい事になってる。
どういうレベルの話をしたいのかわからないが、
データ型、がデータ丸見えってのはどっから出てるんだ？
俺はただ、Data Typeの事をデータ型、と書いただけなんで、
もしデータ型、という特別な意味の専門用語が既にあるなら、
適当に直してくれ。
修正した文のせたいなら勝手にやってくれ。
別に俺の文の正しさを強固に主張する気も無い。
325 ：323：01/11/01 18:29
じゃ、僕もヤメ。
326 ：デフォルトの名無しさん：01/11/01 18:33
>>319
自分以外の全ての書き込みは、一人の対話相手のものだと勘違いしてるみたいだな。
2ch初心者か、デムパってとこか。
327 ：310：01/11/01 18:35
>>326

俺がオブジェクト指向が詐欺かどうか、というスレ
の主旨と関係無い書き込みしたのが悪かった、という
事でおさめてくれんか？
この喧嘩続けてもつまらんだろ。
328 ：322：01/11/01 18:35
　では　関数の帰り値はどうだ？　これは型をもってるけど
　関数に代入は出来ないだろ？

　 property はどうだ？　これは　型を持ってるけど書き込みだけ、読み出しだけしか出来ないように設定出来るぞ


それから　C++ の　テンプレート関数のテンプレート引数は？
329 ：322：01/11/01 18:37
おっと・・書いてる間におさまってたか・・・
330 ：デフォルトの名無しさん：01/11/01 18:47
>>323
もしかして、「データ型」って、プリミティブな型のことを言ってるのか？
だとしたら痛すぎる。つかバカ。
331 ：310：01/11/01 19:09
ごめん、俺が全部悪かった。
この手の喧嘩はいつも知るべき人を遠ざけるから避けたい。

ttp://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html

データ抽象ってのはこれの事だ。

(define a (make-complex 1 2))
(get-real a)
(get-imaginary a)
みたいな感じでやるのがData Abstractionだ。
aがどう実装されてるかはわからんから、データが抽象的。

OOと抱き合せの概念でも、排他的概念でも無い、
と言いたかっただけだ。
332 ：デフォルトの名無しさん：01/11/01 19:29
>>312
例えば、Cの場合は構造体を使うことになるから、
メンバ変数を直接触ることが可能なので、
隠蔽されていないと言いたいのだろう？

考え方を逆にしてみてくれ。
メンバ変数を直接触らなくても（どう定義されているか知らなくても）、
そのデータ型に関して十分な処理ができるように
関数が定義されているからデータ抽象。

つまり隠蔽が言語でサポートされていない場合は紳士協定になるんだよ。
333 ：デフォルトの名無しさん：01/11/02 00:09
データ型を書いたらデータが丸見えって？？
抽象化って言うものを知らずにプログラマをやってるのか？

Cにおけるデータ抽象の例：文字列から整数値へのマップ

#ifndef map_h
#define map_h

typedef struct _map *map_t;

map_t map_create(void);
void map_add(map_t, const char *key, int value);
int map_probe(const map_t, const char *key, int dflt_value);
void map_delete(map_t, const char *key);
void map_iterate(map_t, int (*func)(const char *, int));
void map_free(mapt_t);

#endif

struct _mapの実装は見えない。
ハッシュ表かも知れない。二分木かも知れない。
線形リストかも知れない。

キーと値の型が限られる（monomorphicである）ことがCの限界。
また、メモリ管理に神経を使う（例えば、map_free時にkeyは解
放するか等）もCの面倒な点。
334 ：デフォルトの名無しさん：01/11/02 00:19
ｽｰﾊﾟｰﾊｶｰ登場の予感age
335 ：デフォルトの名無しさん：01/11/02 01:36
そこはかとなくjava臭漂う今日このごろ。
336 ：デフォルトの名無しさん：01/11/02 01:36
>>333
昔そういうことやってたよ。C++コンパイラが入ってなくて、
入れさせてもらえなかった環境で苦肉の策として。
C++使えるって幸せだよな。
337 ：５１５：01/11/02 01:39
>>333
データ抽象の意味が分かりかけてきたので、教えてください。

Cでのデータの抽象化とは、メンバ変数を直接触らなくても、
そのデータ型を使用するのに十分な関数群が定義されていて、
そのデータ型を使うユーザの間で、データ型に直接触らない
(必要なら新しく関数を作る)ようにルールを決めて運用すること
を指している

という理解でいいんですよね？

＃2ch初心者です。
338 ：　　　：01/11/02 01:41
優良スレの予感
339 ：デフォルトの名無しさん：01/11/02 01:41
>>336
つーか、構造化以後オブジェクト指向以前の書き方だよ。
Modula-2とかAdaとか。

C++だとBridgeパターン使うんだろうな。
340 ：デフォルトの名無しさん：01/11/02 01:46
だいたいOK。

抽象データ型ってのは、具体的なデータ表現が隠されていて、
データに対する操作のみが定義されているデータ型。

実際には完全に隠されてなくても良い。「紳士協定」で、抽象
データ型「だと思って」使うっていうのでもかなり役に立つ。
341 ：５１５：01/11/02 02:01
>>340
なるほど。ありがとうございました。

＃オブジェクト指向の抽象化と理解がごっちゃになってました。
342 ：デフォルトの名無しさん：01/11/02 02:09
>>341
オブジェクト指向の抽象化も、元々の意味合いとしては同じだよ。
Javaのinterfaceなんてまさに抽象データ型（＋継承）だし。
343 ：デフォルトの名無しさん：01/11/02 02:15
レベル低～
344 ：デフォルトの名無しさん：01/11/02 02:19
>>343
オマエモナー
345 ：５１５：01/11/02 02:28
>>342
オブジェクト指向の抽象化は、「車をcarクラスにする」みたいな
話ですよね？
オブジェクトの機能を抽象化するのとデータの抽象化は
ちょっと違うような気がするのですが。。。
346 ：デフォルトの名無しさん：01/11/02 02:30
オブジェクト指向の抽象化は、「車をcarクラスにする」みたいな
話ですよね？

なんじゃそりゃ（ｗ）
347 ：デフォルトの名無しさん：01/11/02 02:31
じゃあ、残りの車はcdrクラスか？
とか思ってみたり。
・・・逝ってくるよ
348 ：デフォルトの名無しさん：01/11/02 02:33
じゃあ俺はcaddr、、、、
ごめん、俺も逝ってくる
349 ：デフォルトの名無しさん：01/11/02 03:00
>>345
始まりはともかくとして、
プログラミングにおけるオブジェクト指向は、抽象データ型の
「データと、それに対する操作の組」という考えを素直に発展
させたものだと思うよ。極論すれば「すべてのコードは、デー
タに対する操作としてデータに付随するものである」とか。

言い過ぎかな。
350 ：310：01/11/02 06:58
345みたいな人に読んでもらえるように310を書いた
んだが、読むべき人に読まれてよかった。
Data Abstractionという言葉を知らなくてもOOPは
出来るし、結果としてその恩恵を得る事も出来るが、
意識して組むといろいろわかりやすい事も多いと思う。
JavaやC++の入門書にはゲッタやセッタ作れ、みたい
な事がちょろっとした例と共に書いてある事が多い
と思うが、結局Abstract Dataという考え、というか
その心を知らないと納得出来ない様な内容が多いだろう。
CにおけるData Abstraction、とかOOPLにおけるData Abstraction、
という視点だけではなくて、Data Abstraction、という
視点から両者を見る、という事も出来ると良い、と思う。
上で挙げたSICPの該当個所は、英語だけど入門とし
て読むにはいいと思う。Schemeなのがちょっとあれだが。
351 ：339=349：01/11/02 16:23
>>350
禿しく概出だったね。申し訳ない。

>>345
JavaのinterfaceやC++のBridgeパターンを使うと、マップの実装
(ハッシュ表か、木か等)を実行時に選ぶことができる。

Cで同じようにやるには、以下のようにする。

struct map_impl;

typedef struct _map *map_t;

struct _map {
　　struct map_impl *impl;
　　void (*add)(map_t, const char *key, int value);
　　int (*probe)(const map_t, const char *key, int dflt_value);
　　void (*delete)(map_t, const char *key);
　　void (*iterate)(map_t, int (*func)(const char *, int));
　　void (*free)(mapt_t);
};

別途 hash_map_create() とか tree_map_create() とかを用意する。
どちらも map_t を返し、使い方は同じ。
map_t map = hash_map_create();
map->add(map, "Key", 0);
のように使う。

これはC++コンパイラがやることを自分でやってるようなもんだが、
Cのコードでも同じような書き方を目にすることは多いはず。
具体的には、Unixのファイルシステム(vfs)、デバイスドライバ、
ウインドウシステムなんかで良く出てくる。

Cで書いてても、やっぱりOO的な考え方はあちこちで必要になってく
ることが分かる。
352 ：デフォルトの名無しさん：01/11/03 00:24
>>349
言い過ぎ。
353 ：デフォルトの名無しさん：01/11/03 01:23
>>351 すげ。ここまでやるならなぜC++を使わない？といったレベルだ
反ＯＯな人たちへの最高のサンプルコードですね。
すぐ思いつくメリットだけでも

１．使用者は処理の実装を意識する必要はなく、結果のみを得られる
２．使用者が非正則な手段を使わない限り勝手にデータを操作することは
不可能なので実装者はデータの一貫性を保証される
３．動的に処理を切り替えられる柔軟性がある

反ＯＯな人にとってこれは「悪い」コードなのか？
354 ：デフォルトの名無しさん：01/11/03 01:30
>>351
>これはC++コンパイラがやることを自分でやってるようなもんだが、
>Cのコードでも同じような書き方を目にすることは多いはず。
別に反論じゃないけど､この方式だとC++のVtblと違ってすべてのオブジェクトがすべての
メソッドへのポインタを持つことになる。
だから実行時にメソッドを付け替えるのも簡単だ。
強力なオブジェクトはこの機能を必要としていることが多い。だからStateパターンだの
Templateメソッドパターンだのが作られるのだと思う。
355 ：デフォルトの名無しさん：01/11/03 01:33
>>351
struct map_vtable {
　void (*add)(map_t, const char *key, int value);
　...
};

struct _map {
　struct map_impl *impl;
　struct map_vtable *vtable;
};

typedef struct _map *map_t;

map_t map = hash_map_create();
map->vtable->add(map, "Key", 0);

の方が良いんじゃないか？

いずれにせよ、この書き方を否定するなら、たいていのＯＳの
デバイスドライバやＧＵＩの仕組みを否定することになるね。
356 ：デフォルトの名無しさん：01/11/03 02:03
オブジェクト指向は必要ということで。
357 ：デフォルトの名無しさん：01/11/03 02:11
必要な所だけに使うのなら良し。
358 ：デフォルトの名無しさん：01/11/03 03:10
常識的な議論になってつまんない。

>>312 みたいな基地害が出てきてくれないと面白くない。
それとも312はOO派のネタだったのか？
359 ：デフォルトの名無しさん：01/11/03 03:25
C++,JAVA,Delphi,Smalltalk 以外のオブジェクト指向派っているの？
360 ：デフォルトの名無しさん：01/11/03 03:28
>>1
自殺するなよ･･･
361 ：デフォルトの名無しさん：01/11/03 03:30
>>359
Ruby、C#、Dylan、Eiffel、OCaml、Lisp・・・
362 ：デフォルトの名無しさん：01/11/03 03:38
>>359
ruby.Python
(perl5,phpはムリヤリっぽい)
363 ：デフォルトの名無しさん：01/11/03 03:40
>>361
そうじゃなくて「私は Ruby派」と書いてほしいのです。
364 ：デフォルトの名無しさん：01/11/03 03:44
私は自作言語派。
365 ：デフォルトの名無しさん：01/11/03 03:50
最近 Ruby派の人多いなあ。
Eiffel派だからうらやましい。いい言語なんだけどなあ。
366 ：デフォルトの名無しさん：01/11/03 04:22
CLU派。
367 ：365：01/11/03 04:29
>>366
CLUに興味あるのでどんな言語か説明してほしい。
368 ：デフォルトの名無しさん：01/11/03 04:31
http://www.pmg.lcs.mit.edu/CLU.html
369 ：デフォルトの名無しさん ：01/11/03 04:40
>>365
Eiffel派ですか？いっしょにスレ立てませんか？
っていってもド素人なんてですが、、、
370 ：デフォルトの名無しさん：01/11/03 04:45
Dylan派とO'Caml派は居ないかー。
371 ：デフォルトの名無しさん ：01/11/03 04:51
>>370
http://www.gotdotnet.com/resourcecenter/resource_center.aspx?classification=Language%20Vendors
いまなら誰も実装していないからチャンスありますよ！
372 ：デフォルトの名無しさん：01/11/03 04:59
>>368
Windowsで psファイルって何で見るんですか？
>>369
立てましょう。でも、あまりこれないかもしれません。
373 ：369：01/11/03 05:11
>>372
たとえ、地味―なスレになったとしても
地道にがんばりますのでよろしくお願いします(^^；

ここの板もスレの傾向が
１．業務スレ
２．ねた、煽りスレ
３．個別言語スレ
４．個別テーマスレ(ex.ゲーム、ネットワーク)
と大体棲み分けが出来てきたような感じなので
続くと思います！
374 ：デフォルトの名無しさん：01/11/03 05:24
>>373
こちらこそよろしくお願いします。
375 ：デフォルトの名無しさん：01/11/03 05:38
>>372
ghostscriptで見れるんじゃねーの？
376 ：デフォルトの名無しさん：01/11/03 05:44
>>375
ありがと。
377 ：デフォルトの名無しさん：01/11/03 06:20
#include <iostream.h>
enum Janken{ Guu, Tyoki, Paa };
enum Shouhai{ Kati, Make, Aiko };

class Player{
Janken j1;
public:
Janken te(){ return j1; }
};

class Computer : public Player{
public:
void janken_pon(){ j1 = Janken(rand()%3);}
};

class Man : public Player{
int kati_cnt, make_cnt, aiko_cnt;

public:
Man(){ kati_cnt=make_cnt=aiko_cnt=0; }
bool janken_pon();//終了するときはfalseを返す。

//判定と勝ち負け回数のカウント
Shouhai hantei(Janken com);

int kati(){return kati_cnt;}
int make(){return make_cnt;}
int aiko(){return aiko_cnt;}
};

class JankenGame{
Man man;
Computer com;

void kekka_hyouji(Janken man_te, Janken com_te, Shouhai shouhai);
void syuukei_hyouji(int kati, int make, int aiko);

public:
void play()
{
while(man.janken_pon()){
com.janken_pon();
kekka_hyouji(man.te(), com.te(), man.hantei(com.te()));
}
syuukei_hyouji(man.kati(), man.make(), man.aiko());
}
};

int main()
{
JankenGame game;
game.play();
return 0;
}
378 ：377：01/11/03 06:25
>>377
コンソールで動く簡単なじゃんけんゲームを作ってみました。
（実装一部略）（ももともと大学の課題なんですが）
僕がオブジェクト指向を理解しているか勘違いしているか
判定してやって下さい。
（いまいち自信がない。周りにOOな人もいない。）
379 ：デフォルトの名無しさん：01/11/03 06:45
ついでに怒られるのを承知で書くと
OOにいまいちメリットを感じない。
（このじゃんけんゲームはもともとCでの課題です）
やたらと作為的で、不自然で、まだるっこしい。
自分のコーディングがそうなだけかも知れないんですが。
380 ：デフォルトの名無しさん：01/11/03 06:45
379＝377です
381 ：デフォルトの名無しさん：01/11/03 06:56
>>377
オブジェクト指向を理解していない。
382 ：デフォルトの名無しさん：01/11/03 06:59
>>381
添削お願いいたします。
理解したいとは思っているのです。
383 ：382：01/11/03 07:01
>>381
つーか、いじわるで言ってるだけだろと
心の中では思っています。
384 ：デフォルトの名無しさん：01/11/03 07:06
>>382
>つーか、いじわるで言ってるだけだろと
>心の中では思っています。
そうなふうに感じたなら ごめんなさい。
ふつうは JankenGameクラスを１つ定義するだけだと思います。
385 ：382：01/11/03 07:11
>>384
こちらこそすみませんでした。
game.play()の中で全部書くような感じになるんですか？
386 ：382：01/11/03 07:15
こんな短い小さなプログラムで
ComputerやらManやらクラスを三つも四つも作れば
そりゃ、作為的で不自然でまだるこしくもなるわな、
という意味ですか？>>384
それとも全然勘違いしていますか？
387 ：382：01/11/03 07:25
そうのようですね。（勝手に納得）
388 ：デフォルトの名無しさん：01/11/03 07:32
>>382
>game.play()の中で全部書くような感じになるんですか？
ちがいます。play() を main関数にみたてます。
他にもメンバ関数をいくつか定義する必要があると思います。
play()の中で全部書くのは Cで main関数の中に全部書くようなものです。
389 ：デフォルトの名無しさん：01/11/03 07:34
>>388
ありがとうございました。
390 ：デフォルトの名無しさん：01/11/03 07:34
>>382
全然理解してない。クラスの作り方はそれでもいいかもしれないけど、
クラスの使い方を間違ってる。
せっかくPlayerから派生させてるのに、多態を使ってない。
391 ：デフォルトの名無しさん：01/11/03 07:37
>>390
ありがとうございます。
多分僕は基本的には理解してるだろうと思えてきました。
392 ：デフォルトの名無しさん：01/11/03 07:39
>>391
だから全然理解してないってのに。
ネタですかぁ？
393 ：デフォルトの名無しさん：01/11/03 07:42
いやだって、この場合、多態を使っても
そんなにメリットというかありがたみがないでしょ？>>392
394 ：デフォルトの名無しさん：01/11/03 07:43
>>391
388です。390は別の人です。
395 ：デフォルトの名無しさん：01/11/03 07:46
>>393
そりゃ、この場合オブジェクト指向使ってもメリットはあまり無いよ。
396 ：デフォルトの名無しさん：01/11/03 07:48
>>393
FoolComputerと、GeniusComputer追加したくなったときに
役立つよ。（ｗ
397 ：393：01/11/03 07:50
>>395
もうわかりましたんで。終了ってことで。お騒がせしました。
398 ：デフォルトの名無しさん：01/11/03 08:00
JankenGameクラスにある、Computer型やMan型はPlayer型にして多態に
するべきだし、hantei()やkati_cnt、make_cntがManクラスにあるのは
良くない。JankenGameに、移動すべきだ。
つまり、JankenGameはManに特有の操作やComputerに特有の操作を
してはいけない。
Playerを追加して、Playerを入れ替わり立ち代り変えてゲームしたり
するように拡張する時に、ソースコードを再利用できるようにする
ためにね。
まあ、この場合将来そんな拡張することは無いだろうけど、
オブジェクト指向とは、そういう拡張を想定してのものだからね。
399 ：デフォルトの名無しさん：01/11/03 08:05
>>398
＞つまり、JankenGameはManに特有の操作やComputerに特有の操作を
＞してはいけない。
＞Playerを追加して、Playerを入れ替わり立ち代り変えてゲームしたり
＞するように拡張する時に、ソースコードを再利用できるようにする
＞ためにね。

なるほど・・・勉強になりますです。
400 ：デフォルトの名無しさん：01/11/03 10:29
>>399
ワナにマジレス。ｗｗ

>>398は、ＯＯは使い所を間違うと死ぬという例だよ。
401 ：デフォルトの名無しさん：01/11/03 10:41
＞オブジェクト指向とは、そういう拡張を想定してのものだからね。
ﾊｧ?
402 ：デフォルトの名無しさん：01/11/03 13:34
>>400
罠かい。どうりで日本語が変だと思った・・・
403 ：仕掛け人：01/11/03 14:13
ＯＯの次はLYEEでやります。
まもなくビジネス情報系や投資情報系がLYEE賛美で埋め尽くされます。
セミナーも開きますし、成功事例もでっち上げます。
抵抗すれば理解出来ない旧世代とレッテルを貼って追い出す仕組みも
作ります。
抵抗しても無駄です。
404 ：デフォルトの名無しさん：01/11/03 16:19
>>403
Lyee では、さすがに役者不足だ。売り込むなら、せめて .net にしとけ。

そしてネタは sage でやってくれ。
405 ：デフォルトの名無しさん：01/11/03 16:48
398 の前半は間違ってないと思うけど。
後半は「結局オブジェクト指向はその謳い文句通りにいかないじゃん」というでかい声にかき消されるが。
406 ：デフォルトの名無しさん：01/11/03 22:40
>403

OOもそうであったのか？
407 ：デフォルトの名無しさん：01/11/04 00:42
>>363
372です。Eiffel のスレ立てる話はどうなったの？
408 ：デフォルトの名無しさん：01/11/04 00:54
自分で立てれば？>407
せいぜい自作自演で盛り上げるこったな。
409 ：407の訂正：01/11/04 01:09
>>373
372です。Eiffel のスレ立てる話はどうなったの？
410 ：408の修正：01/11/04 01:13
自分で立てれば？>409
せいぜい自作自演で盛り上げるこったな。
411 ：デフォルトの名無しさん：01/11/04 03:03
>>1
オブジェクト指向の時代は終わらない。
412 ：デフォルトの名無しさん：01/11/04 03:05
マルチメディアとかＡＩの時代はどうなったんですか？
413 ：デフォルトの名無しさん：01/11/04 03:13
っていうか、もしも関数型言語の方が流行ってたら
スレタイトルが、「関数型言語ー詐欺師の時代の終焉。」になってただろうな
414 ：デフォルトの名無しさん：01/11/04 03:18
関数型言語とオブジェクト指向は両立するよ。
415 ：デフォルトの名無しさん：01/11/04 03:27
サブルーチンコ－ル＞関数呼び出し＞メソッド呼び出し＞メッセージを送る

実質はなにも変わってないのになんで名前変える？
416 ：デフォルトの名無しさん：01/11/04 03:33
手続き至高、逝ってよし！
417 ：デフォルトの名無しさん：01/11/04 03:34
おバカなOOPLも、早く独立関数型メソッドになれ。
418 ：デフォルトの名無しさん：01/11/04 04:12
Ｃは美しいプログラムが書ける。
ＯＯＰＬでは書けない。
419 ：デフォルトの名無しさん：01/11/04 04:14
>>415
ただのサブルーチンコールじゃ
動的結合できないじゃないか。
420 ：デフォルトの名無しさん：01/11/04 04:17
>>418 おまえだけ
421 ：デフォルトの名無しさん：01/11/04 04:30
>>418
ＯＯＰＬのプログラムは美しい。
422 ：デフォルトの名無しさん：01/11/04 04:31
>>415それを言っちゃあ、お終いよ
どんなものでも最終的に機械語になって実行されるからな

うまい料理もまずい料理も最終的にはクソになるって～やつだな
423 ：デフォルトの名無しさん：01/11/04 04:35
オブジェクト指向って要はプログラマのオナニーでしょ？
顧客には何のメリットも無いじゃん。
あと、よく知らない人を煙に巻いて騙すためでしょ？
424 ：デフォルトの名無しさん：01/11/04 04:37
まだ１がいたよ･･･
425 ：デフォルトの名無しさん：01/11/04 04:40
いや、漏れもオブジェクト指向というコーデック（？）にとらわれず
に書いたほうが、綺麗だと思ったりなんかしていました・・・

オブジェクト指向って、一体なんなんだろうね・・・
思想？コーデック（規約）？言語？
なんだか抽象的ﾀﾞﾖﾈ
426 ：デフォルトの名無しさん：01/11/04 04:40
>>423
顧客にとって、バグありありの非OOプログラムを受け取るのと
バグの少ない高品質、高機能のOOプログラムを受け取るのとでは
メリット的な違いは無いのですか？
427 ：デフォルトの名無しさん：01/11/04 04:42
>>424
早くできるのか？
安くできるのか？
バグが減るのか？
おらおらどうなんだ？糞グラマども。
428 ：デフォルトの名無しさん：01/11/04 04:42
>>419
関数ポインタがある。
どこからでも呼び出せる。
プログラムの任意の場所を可変に出来る。
そして美しい。
429 ：デフォルトの名無しさん：01/11/04 04:43
>>425
スタイルだろ。
つうか、綺麗とか汚いとかいう話は感覚論に陥るから
不毛だ。
俺はOOは結構綺麗なスタイルだと思うし。
430 ：デフォルトの名無しさん：01/11/04 04:43
>>423>オブジェクト指向って要はプログラマのオナニー
っていうか、それで十分だよ
431 ：デフォルトの名無しさん：01/11/04 04:44
>>427
早く出来るぞ。
多態を考慮してる汎用的部品が使えるから、コードに余分な変更加えなくても
再利用できるからな。
432 ：デフォルトの名無しさん：01/11/04 04:44
>>426
前提がすごいね。
まあ、どこでメモリリークしてるか判らないプログラムよりはマシ。
433 ：デフォルトの名無しさん：01/11/04 04:45
>>427
早くできるし、安く出来るし、バグが減りますが何か？
434 ：デフォルトの名無しさん：01/11/04 04:46
オブジェクト指向から認知科学に興味を持ったけど、
お勧めの本とかだれかしらない？
スレ違いだけどどこの板に行けばいいのかよく分からなかったから、、、
435 ：デフォルトの名無しさん：01/11/04 04:46
>>431
再利用をＯＯで初めて知った人発見！
436 ：デフォルトの名無しさん：01/11/04 04:47
>>435
多態を考慮した部品と、そうでない部品では再利用は前者の方が
上。
437 ：デフォルトの名無しさん：01/11/04 04:48
>>434
純粋理性批判（カント）
438 ：425：01/11/04 04:48
>426
そもそも論じる以前の問題よそれ（；´Д｀）
ooと非ooが釣り合い取れていないのですが・・・

結局、非ooであってもooで組んでも、要は

「ちゃんと動いて、ちゃんと保守ができて、ちゃんと安定する」

物であればいいのよ。425氏はそれを言いたかったんじゃない？

プロジェクトメンバー内で理解している人が少ないooで組むより、
誰もがわかっているであろう非oo（あえて非ooって言います）で
組んだほうが、よっぽど効率的だと思うのは、漏れだけですか？（；´Д｀）
439 ：デフォルトの名無しさん：01/11/04 04:50
OOを否定する白痴の人々はデータ抽象化も否定するのですか?
440 ：デフォルトの名無しさん：01/11/04 04:51
OOは環境依存の部分を局所化できるから、移植も簡単だよね。
441 ：デフォルトの名無しさん：01/11/04 04:51
>>426
＞バグの少ない高品質、高機能のOOプログラム

>>431
＞早く出来るぞ。
＞多態を考慮してる汎用的部品が使えるから、コードに余分な変更加えなくても
＞再利用できるからな。

それはOOプロパガンダに洗脳された思い込み。
何ら科学的根拠の無いドグマ。
442 ：デフォルトの名無しさん：01/11/04 04:52
>>438
その名前はギャグか？
443 ：デフォルトの名無しさん：01/11/04 04:53
>>441
426はともかく、431は根拠を述べてる文だと思うが。
444 ：デフォルトの名無しさん：01/11/04 04:53
>>436
「これまでのプログラム技術では単一の目的にしか使えなかったのが
多態になって初めて他用途での使用が可能になりました」
つう、ＯＯの解説書見てインチキだと思う奴と納得する奴と
2種類に分かれる。
445 ：425：01/11/04 04:53
うげ、425>423 に訂正・・・
ｽﾝﾏｾﾝもうｲｯﾊﾟｲｲｯﾊﾟｲで頭が回ってません。
逝ってきます
446 ：デフォルトの名無しさん：01/11/04 04:54
>>438
そりゃ、理解してない馬鹿がたくさんいる職場では
無理してOO使わない方がいいに決まってる。
447 ：デフォルトの名無しさん：01/11/04 04:55
>>440
酷いな。最近のＯＯの布教ではそんな事まで言ってるのか？
カナーリ悪質。
448 ：デフォルトの名無しさん：01/11/04 04:55
>>444
ハァ･･･
そういう極端な文持ってこられてもなあ。
ただ、一つの型ごとに関数を作らなきゃいけないのに比べれば
多態は便利よ。
449 ：デフォルトの名無しさん：01/11/04 04:56
>>447
abstract factory
450 ：デフォルトの名無しさん：01/11/04 04:57
>>423
>オブジェクト指向って要はプログラマのオナニーでしょ？
ちがう！
>あと、よく知らない人を煙に巻いて騙すためでしょ？
人を煙に巻くようなオブジェクト指向本はたまに見かける。
451 ：デフォルトの名無しさん：01/11/04 04:59
＞一つの型ごとに関数

これは何？
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaStream.html
452 ：デフォルトの名無しさん：01/11/04 05:01
OO否定派の正体
・OOの有効性を理解出来ないのが悔しい。
・実はOOの有効性を理解したいと思っている。
・否定派になってみることで、肯定派から意見を聞き、
　参考にしようとしている。
453 ：デフォルトの名無しさん：01/11/04 05:04
>>451
言い方悪かったね。それもそれは確かに一つの型ごとに
関数作ってるけど、多態を利用してるから、使う方のソースは
型に依存しないように出来る。
だから、関数を変えても変更は一箇所で済む。
454 ：デフォルトの名無しさん：01/11/04 05:04
ＯＯなんて昔使ってたテク。
そんな木の車輪持ち出されて「さあ便利だから使え！」と言われてもねえ・・・。
455 ：デフォルトの名無しさん：01/11/04 05:06
>>454
それは先進的ですなあ。
でも木の車輪はその時代には役に立ったけどね。
詐欺でなく立派に。
456 ：デフォルトの名無しさん：01/11/04 05:07
木の車輪の構造はゴムの車輪にも受け継がれている！
457 ：デフォルトの名無しさん：01/11/04 05:08
OOを否定する白痴の人々はデータ抽象化も否定するのですか?
それとも「データ抽象化」という言葉も理解できませんか?
458 ：デフォルトの名無しさん：01/11/04 05:08
>>454
今は何を使うべきですか？
459 ：デフォルトの名無しさん：01/11/04 05:10
>>458
サブジェクト指向
460 ：デフォルトの名無しさん：01/11/04 05:10
>>457
やつらは抽象化という言葉も理解してません。
461 ：デフォルトの名無しさん：01/11/04 05:13
>>458
今使ってるテクの一部はデザパタの本に書いてあった－よ。（泣）
まあ、俺には問題発見解決能力があるらしいんで世間のテクは
見ないようにした方が良いらしい。人の見ると発想が鈍る。
462 ：デフォルトの名無しさん：01/11/04 05:14
このｽﾚは、能無し専用ですか?
463 ：デフォルトの名無しさん：01/11/04 05:14
構造体のことでしょ？Cで言えばFILEとか。
なんでメソッドも含めてデータ抽象というのかが理解でない。
単なる構造体で十分データを抽象化してるのに。
464 ：デフォルトの名無しさん：01/11/04 05:15
Predicate Orientedってなんですか？
どっかのスレに書いてあったけど。
465 ：デフォルトの名無しさん：01/11/04 05:15
>>461
一部だけで喜ぶなよ･･･
つうか、それならますます他のも役に立つはずだと思って
勉強した方がいい。
466 ：デフォルトの名無しさん：01/11/04 05:16
>>461
学生さんの勉強なら、自分で考えるのは大切だね。
仕事ならそんなムダはやってられないが。
(quick sortも自分で再発明するのか?)
467 ：デフォルトの名無しさん：01/11/04 05:16
>>463
ネタか？ それとも本当にこんなアフォばかりなのか？
468 ：デフォルトの名無しさん：01/11/04 05:17
自分で考えるのは人の発想を学んだ後からやること
じゃないのか？
誰も言及してないことを考えるのが普通だろ？
469 ：デフォルトの名無しさん：01/11/04 05:18
>>462
ＯＯ肯定派・否定派問わず、能無であれば参加できます。
470 ：デフォルトの名無しさん：01/11/04 05:18
勉強サボる言い訳に使えそうだな。
俺は自分で考えたいから勉強しないんだ！
471 ：デフォルトの名無しさん：01/11/04 05:18
>>463
FILE *に対しては、操作(fopen, fclose, fread, fwrite等)
だけ定義されてて、FILE構造体の内部を直接触ることは
ないよね？ それが抽象化。単に「構造体である」だけじゃ
ない。
472 ：デフォルトの名無しさん：01/11/04 05:20
>>468
発想なんて勉強しても出てきませんよ。
必要に迫られてやむなく生み出すものです。
473 ：デフォルトの名無しさん：01/11/04 05:20
>>471
FILEが構造体だなんて誰が決めた？
474 ：デフォルトの名無しさん：01/11/04 05:23
>>467
ネタじゃないっす。
教えてくれたら嬉しいっす。
OO否定派じゃないですので。

構造体はデータの詳細を隠すから
データを抽象化していると思うのですが、
なぜか学術的にはそれだけではデータ抽象とは呼ばず、
データを処理する手続きを抽象化したメソッドも含めて
はじめてデータ抽象と呼ぶわけでしょう？

なんで？手続きの抽象化は別物じゃんとか思うんだけど。
475 ：デフォルトの名無しさん：01/11/04 05:23
データ抽象化という言葉が理解できない消防はもういちど
>>333-355 を読み直しましょう。
476 ：デフォルトの名無しさん：01/11/04 05:26
>>472
だから何？勉強しない方がいいとでも？
477 ：デフォルトの名無しさん：01/11/04 05:27
>>469

それは必要条件、十分条件ではない
オブジェクト指向への愛(または憎悪)も必要
478 ：474：01/11/04 05:28
>>471
なるほど。わかったような。操作するさいに
中身を丸出しにしてちゃ、頭かくして尻隠さずか。
ありがとうございました。
479 ：デフォルトの名無しさん：01/11/04 05:28
じゃあ俺は必要条件を満たしてないな。
480 ：デフォルトの名無しさん：01/11/04 05:29
>>474
構造体は具体的すぎるだろう。構造体の中身を直接触るようなコードは、
構造体の定義が変わったら全て使えなくなる。少なくともコンパイルし
直さないと。

>>333 のように抽象化してあれば、データの具体的表現が変わっても
リンクし直すだけですむ。モジュール間の依存性が最小限に保たれる。
さらに >>351 のようにしてあれば、複数の具体的表現の中から使う
表現を動的に選ぶこともできる。動的束縛というやつだ。
481 ：デフォルトの名無しさん：01/11/04 05:30
>>477
無能で（愛・憎悪）が必要ですか・・・。
病者の隔離スレって事ですね。
482 ：デフォルトの名無しさん：01/11/04 05:31
>>476
そうだよ。
知識を詰め込めばそれが邪魔になって発想が鈍る。
詰め込んだ後ではその知識に沿ってしか考えられなくなる。
483 ：474：01/11/04 05:33
>>480
解説ありがとうございます。
484 ：デフォルトの名無しさん：01/11/04 05:33
>>481
リンクし直さなくてすむとか動的束縛とかの利点以前に、
モジュール分割の原則としてデータ抽象化は便利。

モジュール間で互いの実装に依存しているような分割だ
と、本当の意味で「分けた」ことにならないので（他の
モジュールの中も見ないと理解できないから）大規模な
開発では使えない。保守性も劣る。

モジュールをきっちり分ける手法として、データに注目
して抽象化するというのはすでに定石だろう。
485 ：デフォルトの名無しさん：01/11/04 05:35
>>476
俺の大学の教授が同じようなこと逝ってたよ。「他人の書いたものを
読むと発想が鈍るから読むな。自分で考えろ。」

学生はうんうん唸って考えるんだが、考え付くのは当然、過去にあった
もののでき損ない。数十年の蓄積を一人で越えられるような天才がそう
いるわけはない。
486 ：デフォルトの名無しさん：01/11/04 05:37
プログラミングでいちいち「新たな発想」とか要るか？
たまには要るだろうが、それよりもいかに既存の手法を
使いこなすかの方がずっと重要だろう。

もしかしてライブラリも学ばずに一から書くのか？
487 ：デフォルトの名無しさん：01/11/04 05:46
多少不細工■だったとしても■、自分で見つけ出したものは本に書いてないような
ノウハウや長所短所を心得ているせいか巧く行くのです。
というのは俺の経験だけではないらしい。
http://www.atmarkit.co.jp/fwin2k/opinion/ogawa/ogawa_200110.html
488 ：デフォルトの名無しさん：01/11/04 05:47
>>485
100人の秀才と900人の凡人を作るか、
1人の天才と999人のバカを作るかの違い。
日本では前者の方法を好む。
489 ：デフォルトの名無しさん：01/11/04 05:48
んー例えばクイックソート知らないで高速のソートが必要になった場合とか。
たまに世間で流布されてるソートより10倍以上速いのを発見したりする。
490 ：デフォルトの名無しさん：01/11/04 05:48
>>474
構造体は幾つかの変数を一つにパックしてはいるけれど、
それだけでは隠しているわけではないので、
その違いに注意すると良いよ。

抽象はまた別の概念。
class TV と　class Light のどっちも関数 on と off とか color
なんて変数だか関数だかもあるかも知れないけど、
各々の実際というか《具体的》なことは違う。
でも、利用者にとっての「光を出す電気機器とはなんぞや」
という考えの中の《抽象的》なことは同様になるかも知れない。
491 ：デフォルトの名無しさん：01/11/04 05:50
>>488
で、あんたは天才を目指しているわけか？

プロジェクトのメンバーが求めてるのは、せめて
凡人であってくれれば良い（バカじゃなければ）と
いうことだと思うが。
492 ：デフォルトの名無しさん：01/11/04 05:52
>>489
どうせ、ビンソートとか度数ソートとか、良く調べれば本に
載ってるヤツだろ？ でなければ特許取れば大儲けだよ。
493 ：デフォルトの名無しさん：01/11/04 05:53
>>487
リンク先との関連が分からない。
OOとの関連も分からない。
SISとかCRMとかいう営業マンの流行り言葉とOOの区別が
ついてないとか？
494 ：デフォルトの名無しさん：01/11/04 05:54
>>492
単なる例、喩え話。
厳密に言うと純粋なソートではないし、特定の状況下でしか使えないので
汎用性は無い。
495 ：デフォルトの名無しさん：01/11/04 05:54
>>491
どちらの方法が良いとは言わない。
日本は均一的な高水準の教育が売りだが、
新規創造的分野に弱い。
496 ：デフォルトの名無しさん：01/11/04 05:55
>>489
比較が必要なソートでは、クイックソートの比較回数が
平均的に最小と証明されてるが。

だいいちアルゴリズムの比較に「１０倍」ってなんだよ（藁
497 ：デフォルトの名無しさん：01/11/04 05:57
　この取材中、インタビューで現場のニーズやら、IT化の目標やらを聞いていると、
「ああ、それはいま言われている×××のことですね」と、職業柄、反射的に3文字略
語が口から出てくることがある。それに対する現場担当者の反応は、たいてい決まって
いる。「かっこよく言えばそうなりますね」。
インタビューの冒頭から、3文字略語が大活躍することはあまりない。あくまで自分
たちが抱えている現場のニーズや問題点と日夜格闘して、結果出来上がった情報システムが
、はたから見れば3文字略語の要素を含んでいたということだ。こういう情報システムは成功する
と思う。

SISの教訓から分かるとおり、これとは逆に、3文字略語から出発した、到達目標のはっきり
しない情報システム、現場のニーズであるとか、情報化の効果に対する評価・検討が十分でないまま進めら
れてしまったプロジェクトは、まずもって失敗に終わる。
498 ：デフォルトの名無しさん：01/11/04 05:58
>>495
ソフトウエア設計やプログラミングは創造性とか芸術性とか
は不要だろ。engineering とか problem solving だろ。

新たなソフトウエアを産み出すのは設計とかプログラミングの
問題ではない。
499 ：デフォルトの名無しさん：01/11/04 05:59
>>497
無断転載ヤメロ。

それにOOともOOPLとも関係ないよ。どっちも3文字じゃないから。
500 ：デフォルトの名無しさん：01/11/04 06:02
どうやら「データ抽象化」を否定する人はいないみたいですね。

データ抽象化と、それに基づく設計を素直に発展させたのがオブジェクト
指向ですから、データ抽象化を認めてオブジェクト指向を認めないのは
全く矛盾していると思うのですが?
501 ：デフォルトの名無しさん：01/11/04 06:02
ソートに限らない話として、
すでに何が有るかは知っていた方がいいけれど、
それぞれの長所短所とか使い道も理解していないとね。
その為には自分で考案してみたり作ってみるのも良い勉強だと思うな。
特に初期の段階では。
502 ：デフォルトの名無しさん：01/11/04 06:05
>>501
まあね。趣味でなら何日も悩んで考案するのも楽しいね。
でも仕事ではできないね。「自分で考え付きました」と
言っても誰も誉めてくれるわけがない。
503 ：デフォルトの名無しさん：01/11/04 06:06
>>500
データ抽象化が良ければ、オブジェクト指向の全てが良いわけではない。
504 ：デフォルトの名無しさん：01/11/04 06:07
>>503
具体的には？
505 ：デフォルトの名無しさん：01/11/04 06:10
>>503
でも、データ抽象を使うために、例えばOOPLはものすごく便利だし、
他の言語でもOOの考え方を使えば自然にデータ抽象が行えるでしょ？
506 ：デフォルトの名無しさん：01/11/04 06:12
>>504
具体的も何も、一部が良ければ全て良しというのは変。
507 ：デフォルトの名無しさん：01/11/04 06:14
>>498
ＯＯの発展にも、創造性は必要だ。
しかし、過去の創造性に頼って生きるのも、人生の選択の１つ。
良いと思う。
508 ：デフォルトの名無しさん：01/11/04 06:15
>>506　何が駄目なの？
509 ：デフォルトの名無しさん：01/11/04 06:15
オブジェクト指向は初期のコストが高いけど、使いこなせば
後からそれ以上に楽になってくるというやつでしょ。
510 ：デフォルトの名無しさん：01/11/04 06:16
>>506
OOを正しく使った結果のがデータ抽象の方法の１つだと仮定すれば
（あくまで仮定）、データ抽象全体を肯定すれば、その部分集合で
あるOOも肯定したことになる。

そうでないとするならば、「OOを正しく使って、しかしデータ抽象
ではない」例があることになる。

それを具体的に挙げてみてくれないか？
511 ：デフォルトの名無しさん：01/11/04 06:17
アホか。勉強してると発想が鈍るというやつは大きな間違い。
そういうのは、元から頭が固いやつだよ。
現に、有名な天才学者はその分野について詳しく知ってるぜ。
例外無くな。
512 ：デフォルトの名無しさん：01/11/04 06:18
>>507
OOを発展させるかどうかなんていう大言壮語以前に、
本に書いてあることくらいちゃんと理解しようよ（ｗ

「飛ぶことを覚える前に、人は歩くことを覚えるべきだ」
513 ：デフォルトの名無しさん：01/11/04 06:18
>>508
ＯＯ自体じゃなくて、あんたの理論。
514 ：デフォルトの名無しさん：01/11/04 06:19
>>502
極端なこと言えば「エンジニアリング」って目標なり要求を
満たすにはどうしようかが出発点にあるからね。
その中には例によって期日（納期）も入っているだろうし。

ただ、そればっかり繰り返していると「枯れ果てちゃう」から、
勉強も必要だと思ってるよ。些細なテーマでもね。

創造とか芸術とかっていうのは、むしろそういう「固定した評価関数」
を用意しない仕事だろうとも思うな。
プログラミングやソフトウェアにもそういう発想があって良いと思う。
そして、誰かがいつか、それをハッキリした目的のために使う時も
あるかもなと思ってる。

じゃ、OOPは創造性の賜物なのか？
なーんてギチギチなこと考えることもないだろけど
515 ：デフォルトの名無しさん：01/11/04 06:20
勉強＋独自の発想の方が、ただの発想よりも高いレベルに
達することができると思うけど。
516 ：デフォルトの名無しさん：01/11/04 06:20
いつもの妄想が始まったんで逝くよ
517 ：508：01/11/04 06:20
>>513
504じゃないよ。
518 ：デフォルトの名無しさん：01/11/04 06:21
Ｒｕｂｙ至上主義に入信しました。
519 ：デフォルトの名無しさん：01/11/04 06:22
本を読むと創造性が失われるなんてどう考えても嘘っぽいなあ。
良い絵画を見たり、良い音楽を聴くと芸術性が失われるのかい？
520 ：504：01/11/04 06:25
>>513
「あんたの理論」って何？
521 ：デフォルトの名無しさん：01/11/04 06:29
>>514
しかし99.9%(当社調べ)の仕事には「固定した評価関数」があるんだよ。
納期までに完成して、安定して動いて、変更に強いこと、とか。

「ちょっとここんとこ芸術的に書いてみました」ってのは評価関数では
どっちかというとマイナスになる。
522 ：デフォルトの名無しさん：01/11/04 06:30
>>519
がいしゅつだが勉強しないヤツの言いわけだってば。
523 ：デフォルトの名無しさん：01/11/04 06:39
>>512
わかるよ、そうゆう仕事の中では良く思われないね

世の中見渡せば、結構違った種類の「仕事」もある。
その中には一体全体ホントに利用されるのか分からないような
モノを作ってるところやら色々だね。
それこそUNIXやLispだってそんな立場から始まってるしね。
524 ：523：01/11/04 06:41
>>521でした。すんませんでした
525 ：デフォルトの名無しさん：01/11/04 07:02
結局さ　ライブラリを使うのは楽だけど　作るのは同じじゃないってのが最大の難点？

　というかアプリ作るのにOOライブラリを使うのは便利だけど、
　　それ作りながらは・・・・
526 ：デフォルトの名無しさん：01/11/04 08:10
>>521
「芸術＝不採算」のレッテル貼って終わりか。
つまらん仕事しとるな。
つうかＯＯの方が芸術に近いと思うが。
527 ：デフォルトの名無しさん：01/11/04 08:15
>>526
つか、プログラミングとかソフト設計とかの「技術」の世界に
「芸術」を持ち込んだらどちらにとっても不幸だろう。

評価尺度がそもそも違うんだから。

ま、いずれにせよ芸術とか創造性が不勉強の言いわけにはならん
よ。
528 ：510：01/11/04 08:18
>>510 に反論無ければ
「データ抽象化は素晴らしい。よってOOも素晴らしい。」ってことで。

---------------------------- 終了 -----------------------------
529 ：デフォルトの名無しさん：01/11/04 08:21
不勉強ねえ。
勉強＝良い事/勉強しない＝悪い事
という固定観念と
ＯＯやデザパタは勉強と呼ぶに値するという固定観念に囚われていて
お話になりませんな。
勉強するに値するものなら労苦は問いませんが、ＯＯは違うという考えが
理解できませんか？
530 ：デフォルトの名無しさん：01/11/04 08:22
>>528
馬鹿の一つ覚え
531 ：523：01/11/04 08:41
>>527
> つか、プログラミングとかソフト設計とかの「技術」の世界に
> 「芸術」を持ち込んだらどちらにとっても不幸だろう。

いわゆる『現場』ではそうだろう。けれど基礎技術や概念が出来るのは、
掃いて捨てるほどの技術のタネが上がってくる、広いすそ野が有るのも事実さ。
創造的（芸術とは限らないよ）と言うかどうかは、そう見いだす人の感じ方
や審美心にもよるけど。

> ま、いずれにせよ芸術とか創造性が不勉強の言いわけにはならんよ。

そりゃそうだ。

>>529
理屈っぽくなって申し訳ないが、勉強するに値するかしないかも、
何かしら深い洞察があってこそ出来る判断だろう。
それは人に言われて信じるより、もともと余程しっかりした下地があるか、
実際にやってみる以外にないだろ。
そう思えば値しないものなんてこの世にないよ。（極論だろけど）
532 ：デフォルトの名無しさん：01/11/04 08:55
>>528
データ抽象化はいいことだと思う。だから、その言葉を知る前から、
Cで構造体を使うときは、それ専用の関数を用意していた。

なおかつ、構造体の定義と専用関数のプロトタイプは同一ヘッダファイルに
まとめ、専用関数群の実装は同一ソースファイルに収めていた。

だからそれら（構造体＋関数）をオブジェクト化するのに異存は無いのだが、
プログラムのそれ以外の部分をオブジェクト化する必然性を感じない。
だからプログラム全体をオブジェクト化するOOが素晴らしいと言われても
何が素晴らしいのか理解できない。
533 ：デフォルトの名無しさん：01/11/04 08:57
>>530
でも反論はできないのね。
534 ：デフォルトの名無しさん：01/11/04 09:02
>データ抽象化はいいことだと思う。だから、その言葉を知る前から、
>Cで構造体を使うときは、それ専用の関数を用意していた。

なるほど。自分でデータ抽象化を再発明したのね。
ちょっと勉強してればそんな苦労はいらなかったのに。

>だからプログラム全体をオブジェクト化するOOが素晴らしいと言われても
>何が素晴らしいのか理解できない。

なるほど、理解できないと。それは勉強してから言ってる？
それとも自分で再発明するまで納得できない？
（一生再発明できないに一票。）
535 ：デフォルトの名無しさん：01/11/04 09:10
>>532
プログラムの中（例えばCのmain）で宣言している変数は
全てmainという構造（体）の中の変数として考えられないのかな。
536 ：デフォルトの名無しさん：01/11/04 09:11
芸術=技術=art
537 ：デフォルトの名無しさん：01/11/04 09:11
>>532
すべてのデータを抽象化しなければならないわけではない。当然どこかに
具象データ型を直接扱うコードは出てくる。

しかし、モジュール分けの原則としてデータ抽象が有効である以上、全体
を同じ原理で書けるようにして何が悪いのか分からない。

もちろん、例えばOO言語でもクラスメソッド(Javaならstatic method)にしか
しようがないコードはある。しかし、多くの場合、コードは特定の種類のデー
タだけを受け付けて動くようにできているのだから、データとコードを一体と
してモジュール分けの原則とするのは極めて合理的だと思う。
538 ：532：01/11/04 09:12
>>532
だから私の場合、オブジェクト指向しろと言われても、
プログラムの中で構造体が必要になる場所でしかできないだろう。
局所的なオブジェクト指向しかできない。

プログラムの中で構造体が登場しなければ
全くオブジェクト指向できない。
つまりOO初心者がとまどう
「何をオブジェクトにしたらいいの？」
という疑問が生じるのだ。

構造体を使う場合は戸惑わない。
必要なければ使わないまでだからだ。
ところがOOでは全ての部分で構造体を使え
と強要されるようなものなのだ。

プログラムの中で構造体絡みの部分は私の場合、
感覚的にせいぜいいって５～１０％くらいだと思う。
そのプログラムの種類にもよるが。
539 ：デフォルトの名無しさん：01/11/04 09:16
>>536
Knuthのようなヘタクソ日曜プログラマならそういう混同をするかも
しれないが、君は技術者をartistと訳すのかね？

問題があってそれをソフトウエアによって解決するときの(工学)技術
とはtechnologyでありengineeringだろう。
540 ：532：01/11/04 09:17
>>535
なるほど。ただ（広義の）構造化プログラミングを
そのようにしてOOPに「翻訳」したとして、
果たしてそれがOOPと言えるかどうか・・・
541 ：デフォルトの名無しさん：01/11/04 09:21
>>538
たくさんのグローバル変数があるとき、関連するものは
１つにまとめて扱うとモジュール化が容易だと思わない？
例え１つしか作らなくても、オブジェクトにする価値はあ
る。

たとえば、入力バッファとその中のポインタと、入力ファ
イルポインタを１つにまとめて、それを扱うコードと組に
すれば、Readerクラスのできあがり。別にReaderが１つし
か要らなくても、まとめて他と分離して悪いことはなかろう。
542 ：デフォルトの名無しさん：01/11/04 09:25
たとえば、今のOO言語でオブジェクトを作ろうとすれば
　 Get Putタイプのメソッドを作ってやらなければ
　　「使う側」が便利に使えない。

しかし、作る側は Get/Putメソッドを実装するのは逆に比べて何倍も労力を必要とする
　　同期型のスレッド・・・・重い上、少しのミスが命取り労力は非常に大きい
　　結局内部でIF文・スイッチ文テンコモリのメソッドが出来てしまう

言語機能として完全同期型＝コルーチンスタイルを実装しなければこれは解決出来ないだろう
543 ：デフォルトの名無しさん：01/11/04 09:26
日本民族は既存の技術を学び･理解し･組み合わせ･応用するのが得意
日本の教育は決して悪いものではないが新技術の開発には向かない
544 ：デフォルトの名無しさん：01/11/04 09:26
>>533
530 じゃないけど、電波すぎる。つっこみ所が多すぎて、つっこむ気になれない。
545 ：デフォルトの名無しさん：01/11/04 09:29
>>544
１つでいいよ。挙げてみて。
546 ：535：01/11/04 09:30
実際には取り立ててOOとは言わないよね。
やっぱり
> （広義の）構造化プログラミング
でしょう。
でも、その考えで一貫させておけば、
処理系とかも考えやすいと言うことはあるんじゃなかろか。

Javaではmainはあるクラスの一関数であるみたいなのを見たとき、
ああなるほどって気になったなぁ。

Cプログラミングは「Cのプログラム」という多分一番大きな
クラスの定義の中で定義されたモノを使っているわけでもあるし。
それでも、その中に更に小さい単位のクラスを作って、
そこでしか見えないモノを使ったりもしているんだよ。
547 ：デフォルトの名無しさん：01/11/04 09:31
>>545
１つだけだよ(藁
データ抽象が必要だとして、それをよりよく実現する方法は、いろいろ考えられるだろう。
データ抽象を目指している方法論の全てが、正しいとは言えない。
548 ：デフォルトの名無しさん：01/11/04 09:32
>>542
それは「データ抽象化したくない」と言ってるわけね。

抽象化が不要なオブジェクト(例えば単なる「座標」とか
「サイズ」とか)なら、別にgetter/setter作る必要ないの
では？
549 ：デフォルトの名無しさん：01/11/04 09:33
>>547
うーん、それはOOへの批判とは言えないな。
「データ抽象化とOOが相容れない具体例」を挙げてもらわないと
反論にはならないと思うが？
550 ：デフォルトの名無しさん：01/11/04 09:34
>>549
ＯＯへの批判じゃないよ。
あんたの決めつけへの批判。
551 ：デフォルトの名無しさん：01/11/04 09:39
>>550
決めつけつか、単純な論理だが。
「OOがデータ抽象化の一種なら、
『データ抽象化が良い』→『OOが良い』」

『データ抽象化が良い』を前提にこれを否定するには
「OOがデータ抽象化の一種でない」を示す必要がある。
552 ：デフォルトの名無しさん：01/11/04 09:41
>>550
１つだけって言ったでしょ(藁
後は、自分の言ったことを信じられるか、自分に聞いてみて。
553 ：デフォルトの名無しさん：01/11/04 09:41
>>542
なんでOOにすると急に同期が必要になるの？
Cでデータ抽象化するときにも必要？
554 ：デフォルトの名無しさん：01/11/04 09:43
>>552
500は単純化しすぎているかも知れないが、
俺は、OO言語はデータ抽象化を強力に支援するし、
データ抽象化を突き詰めたひとつの形がOO設計であると
信じている。
555 ：デフォルトの名無しさん：01/11/04 09:45
>>554
信じられるかってのは、ＯＯの事じゃなくて、551みたいな理論の事ね。
556 ：デフォルトの名無しさん：01/11/04 10:42
>>539
ていうか、「芸術」の定義がゆがんだ形で変化している。
もとは技術と分け隔てできるものではなかった。
芸術について真摯に考えると、やっぱり技術と
切り離せるものではないと分かる。
557 ：デフォルトの名無しさん：01/11/04 10:53
>>556
世の中がギリシャ時代に戻ったら考え直すよ。
そのころも芸術とは無縁の労働者はいたはずだけどね。
558 ：デフォルトの名無しさん：01/11/04 11:07
>>553
データ抽象化する時に同期が必要な場合は
　　呼び出す事が情報を与える＝呼び出す事により状態が変化する場合。
　　状態が変化しなければ、もちろん不要だよね。
　　でもそれなら、そのデータを作っておいて参照させる場合と比べての
　　メリットは、そんなにないぞ
559 ：デフォルトの名無しさん：01/11/04 13:31
>>558
マルチスレッド環境を考えてるの？
抽象化しないときには同期が要らないの？
560 ：デフォルトの名無しさん：01/11/04 15:25
言っただろ、詰めこみ過ぎるとその知識での物の見方しかできなくなるって
＞データ抽象化
561 ：デフォルトの名無しさん：01/11/04 15:45
>>560
意味不明。データ抽象化の知識くらい詰め込んどいて損はなかろ。
562 ：デフォルトの名無しさん ：01/11/04 15:56
Lyeeの回し者じゃないけど、もっと日本人は自身を持て！
イチローや中田みたいにアイデンティティ無しに個を確立
できるような強い人間でもない限りやはりどこかに帰属するしかない。
で、その日本人だがや・れ・る・！
自信を持て。まずは舶来物を批判的に見る習慣をつけろ！
批判といってもただダメだというんじゃなくて相対化することだ。
おれの見た感じでは、オブジェクト指向ﾏﾝｾｰなやつは
何がだめかって、これがまったくできていないやつが多い。

がんばれ2chネラー、がんばれニッポンジン！！
563 ：デフォルトの名無しさん：01/11/04 16:00
>>562 おまえがやればいいじゃん
人煽るくらなら
564 ：デフォルトの名無しさん：01/11/04 16:04
>>562
ネタにしてもつまらん。
アイデンティティなしに個を確立っていきなり矛盾じゃん（藁
565 ：デフォルトの名無しさん：01/11/04 17:11
データ抽象は、オブジェクト指向の原因（動機）ではなく、
結果（副産物、しかもどちらと言えば、プログラミングにおける
オブジェクト指向の必要性を、一般化・合理化したいがための、
後から取って付けた理屈）だから、データ抽象の延長線上には、
オブジェクト指向は見えてこない。オブジェクト指向の真の動機
は別にあるからだ。

その真の動機とは、文字通りオブジェクトを指向すること、
現実世界の様々な「モノ」をプログラムの中に記述することである。

これはSimulaなどのシミュレーション用言語においては、
シミュレーションの対象物（モノ）をプログラムのコードとして
素直な形で記述するという意味で、自然な動機であったのだが、
シミュレーション以外の用途ではさほど必要性はないと思われる。

故に、何をオブジェクトにしていいか分からない、という困惑は
一般的プログラミングにおいては当然のことなのである。
一般的なプログラミングにおいて、オブジェクト指向しようと
すれば、プログラム中の様々な要素を「モノ」に見立てる
必要があるだろう。その必要性が無いにもかかわらず。

しかし、WindowsなどのGUIプログラミングにおいては、
様々なGUI部品（モノ）をプログラム中にオブジェクトとして
素直な形で記述できるので、オブジェクト指向の必要性は
高いと思われる。
566 ：デフォルトの名無しさん：01/11/04 17:27
賛成！
やがてＯＯと相性の良さそうな使い道がリストアップされ、
使い所を見分けるのが常識になり、ＯＯは単なる数ある手法の一つに落ちつくに一票。
（OOPLがどうなるかは知らんが）

OOは秀才向けかもしれんな。
567 ：デフォルトの名無しさん：01/11/04 19:44
>>565 より
> 何をオブジェクトにしていいか分からない、という困惑は
> 一般的プログラミングにおいては当然のことなのである。

「作りたいもの（作るべきモノ）がどんなモノなのかを
本当に分かっていないでプログラムしていも当然」
と言ってしまっている様にも読めるが…。

手続き又は手順でしか考えられない人もいるが、
それはトレーニング不足の様な気がするなあ。
（「…で考える」と言うことだよ。使う道具の事じゃないよ。）
568 ：デフォルトの名無しさん：01/11/04 19:49
>>567
565はどの立場にたって見るかでオブジェクトの切り出しかたが
ちがうっていうふうに読めたけど。
569 ：567：01/11/04 19:55
例えばどう違うと？　大まかでも例を出して貰えると良いんだけど
570 ：デフォルトの名無しさん：01/11/04 23:11
>>558
オブジェクト指向のスレッドを分かってない。
571 ：デフォルトの名無しさん：01/11/04 23:38
>>565
>一般的なプログラミングにおいて、オブジェクト指向しようと
>すれば、プログラム中の様々な要素を「モノ」に見立てる
>必要があるだろう。その必要性が無いにもかかわらず。

そんなこと考えてクラスをつくるやついるの？
572 ：デフォルトの名無しさん：01/11/04 23:39
別にプログラムの要素を「概念」に見立ててクラスを作っても良いのでは。
573 ：デフォルトの名無しさん：01/11/04 23:46
>>572
いいけど。でも、>>565は「モノに見立ててクラスをつくらなければいけない」
と思いこんでるみたいだから。
574 ：デフォルトの名無しさん：01/11/04 23:47
＞プログラム中の様々な要素
原理主義的には、
「プログラムが実現しなければならない機能要件を満たす何か」
だな。
コードから逆にクラスを起こすのはアレだ。
575 ：デフォルトの名無しさん：01/11/04 23:55
>>574
言ってることが分からない。
576 ：デフォルトの名無しさん：01/11/04 23:58
>>575
UMLを使った開発なら、まずユースケース書いてシナリオ書くじゃん。
シナリオの中に実現すべき機能要件が現れる。
んでクラスを抽出するじゃん。

「プログラム中の様々な要素」というのが実装レベルの話だと感じたので。
577 ：デフォルトの名無しさん：01/11/05 00:15
>>575
分かったけど、おれが言いたいのは UML 書くときでも
「こういうクラスがいるな」とか考えて書くと思うけど。
ああ、うまく説明できない、、、
578 ：デフォルトの名無しさん：01/11/05 00:16
>>576 の間違い。
579 ：デフォルトの名無しさん：01/11/05 00:22
そういえば、ＯＯは限りなく実装に近い設計しないと継承などで
失敗するんだったね。
設計しないでおもむろに書き始めた方が速かったり。
580 ：デフォルトの名無しさん：01/11/05 00:23
>>577
うん。コードが思い浮かぶよね。
このクラス作るには線形リスト使って、addとfindメソッドがあればいいか…とか。
RUP かなんかだと、分析/設計段階では抽象的な役割だけを表したクラス図を書いて、
実装段階でコードに落とせるクラスを書くみたいだけど、
さすがに面倒なのでやってない。
実装に引きずられたクラス作って後で後悔するんだけどね。。。
581 ：デフォルトの名無しさん：01/11/05 00:30
>>580
いま思ったんだけど、まずコードが思い浮かぶようになるのが OOP の第一段階。
実装に引きずられないクラスを作れるようになるのが第二段階。
582 ：581：01/11/05 00:49
いや、実装に引きずられてもいいかも . . .
とにかくコードが思い浮かぶようになればいいと思う。
583 ：言い逃げ日曜プログラマ：01/11/05 01:33
オブジェクト指向のプログラミングなんてほとんどやらないけど
それは俺が大物を作らないせい。
思うにオブジェクト指向の出元って少し大きなプログラム組むときまず
データ構造(構造体と言い切って良いかも知れない)を考えるところから
きているんだと思う。
データ構造が決まればプログラミングのメインはその構造体を
いじくるサブルーチンを考えることになるわけで、そりゃ結局メソッドのこと
なんだオブジェクト指向じゃん->ｳﾏｰ

ここからさらに広がって
よーしパパ関数もオブジェクトにしちゃうぞー。なんて言すくらいなら
よかったが調子に乗って多態だの複雑な継承関係だのやり出しちゃうともう大変。
プログラムの改変性ニアリーイコールゼロ。
おまえら本当に動くプログラム書きたいんかと問いたい。小一時間問い詰めたい。
ただpureOOって言いたいだけちゃうんかと。
ぜんぜん使えない奴はもちろん論外。
まあお前らは出来合いのOOライブラリで全然OOじゃないプログラムでも
書いてろってこった。俺のことだがなあぐはははは
584 ：デフォルトの名無しさん：01/11/05 01:39
>>583
オブジェクト指向を勘違いしてる。
585 ：デフォルトの名無しさん：01/11/05 01:46
>>583

そのデータ構造を最初に固定する、
ってのが嫌(むずかしい)からOOPってのは出来たと思う。
でもその結果、構造に変更出来る部分が増えたYO!
と理論上はなっても、実際、変更がそれ程うまく行くか、
というと....
586 ：580：01/11/05 01:53
>>582
getter/setter 含めてメソッドをがりがり実装して
よーし実行しちゃうぞー → 動かない → このアプローチじゃだめじゃん
となったときに、実装中心で考えていると
駄目なコードでも改良を続けてしまって捨てられなくなる。
インターフェイスとしてのメソッドがちゃんと決まっていれば、
定義は変えずに中身だけごっそり変更すればいいんだけど、
そうでないと泥沼的にメソッドを追加したり減らしたりが始まる。
挙句の果てにヘルパークラスを作り出すともうお手上げ。
一から書き直したほうが早かったと思っても後の祭り。

設計きちんとやればこういう惨事も回避できるのではと思うんだけど、
コードをごりごり書いてる方が楽なんだよね、泥沼に陥っててさえも。
587 ：デフォルトの名無しさん：01/11/05 01:59
>>586
不変条件を書いておけばなんとかなるような気がする。
588 ：デフォルトの名無しさん：01/11/05 02:01
583は構造体とクラスは同じと勘違いしている
初心者C++プログラマが陥りやすい罠に
まんまとひっかかっている
589 ：デフォルトの名無しさん：01/11/05 02:04
getter/setterがあふれているような設計なら確かに、
OOダメじゃんって思うだろうな。

プロパティだらけのオブジェクトでナにか作りたいなら
VBかなんかでもやってロ。
590 ：デフォルトの名無しさん：01/11/05 02:06
structとclassの違いがデフォルトのスコープだけってのが
C++の糞なところだな。
591 ：デフォルトの名無しさん：01/11/05 02:21
>>589
多くて4、5くらいだけど、
川俣某氏のように書くのが面倒なので（ｗ
ちなみにダメなのはOOじゃなくて自分なのは自覚してます、はい。
592 ：デフォルトの名無しさん：01/11/05 02:40
>>535
>プログラムの中（例えばCのmain）で宣言している変数は
>全てmainという構造（体）の中の変数として考えられないのかな。
いってることなんか変。
593 ：デフォルトの名無しさん：01/11/05 03:11
OOP初心者が非OOP派にならないことを祈ります。
594 ：デフォルトの名無しさん：01/11/05 03:33
>>592
例えば、

main()
{
　　int i;
　　for(i=1;i<=5;i++)
　　　　printf("HELLO WORLD\n");
}

こんなもん、OOPを強要するOOPLでどう書けばいいかって話で
↓こうすればどうかというわけです。

class Main{
　　int i;
public:
　　void execute()
　　{
　　　　for(i=1;i<=5;i++)
　　　　　　printf("HELLO WORLD\n");
　　}
};

でも、この場合iをメンバー変数にしてもあんまり意味が無いんで
↓これでいいと思いますが。

class Main{
public:
　　void execute()
　　{
　　　　int i;
　　　　for(i=1;i<=5;i++)
　　　　　　printf("HELLO WORLD\n");
　　}
};
595 ：デフォルトの名無しさん：01/11/05 03:33

しかし、一貫して、この方法で構造化プログラミングを
形式的にオブジェクト指向に変換しても、
それはオブジェクト指向だろうかという話です。
例えば

main()
{
　int x,y;
　x=input();
　y=func(x);
　output(y);
}


↑これを形式的に変換したもの↓はオブジェクト指向か？
（私はYESだと思うのだが、どうですか？
これを認めないとOOPを強要する言語では
小さなプログラムは組めないと思うのですが。）

class Main{
　int x, y;
public:
　void input();
　void output();
　void func();
　void execute(){ input(); func(); output(); }
}
596 ：デフォルトの名無しさん：01/11/05 03:41
こうしたほうがいいか。

class Main{
　int x, y;
　void input();
　void output();
　void func();
public:
　void execute(){ input(); func(); output(); }
}
597 ：デフォルトの名無しさん：01/11/05 03:42
>>594
>class Main{
>public:
>　　void execute()
>　　{
>　　　　int i;
>　　　　for(i=1;i<=5;i++)
>　　　　　　printf("HELLO WORLD\n");
>　　}
};
こつちはいいと思う。
598 ：デフォルトの名無しさん：01/11/05 03:54
何か段々馬鹿馬鹿しくなって来ましたが
これならオブジェクト指向ですかね?

class X{
　　int m_x;
public:
　　void input();
　　int func();
};

class Y{
　　int m_y;
public:
　　void set(int y);
　　void output();
};

class Main{
　　X x;
　　Y y;
public:
　　void execute()
　　{
　　　　x.input();
　　　　y.set(x.func());
　　　　y.output();
　　}
};
599 ：デフォルトの名無しさん：01/11/05 04:01
>>595

class Main{
public:
　　execute(){
　　　　int x,y;
　　　　x=input();
　　　　y=func(x);
　　　　output(y);
　　}
　　int input(){ ... }
　　int func(int x){ ... }
　　void output(int y){ ... }
};
600 ：デフォルトの名無しさん：01/11/05 04:02
>>598
ミニプログラムを実際には、ここまでしても無意味でしょう。
>>596みたいな書き方で十分と思うわけで。
601 ：デフォルトの名無しさん：01/11/05 04:04
>>599の方がいいか・・・
602 ：デフォルトの名無しさん：01/11/05 04:10
JavaとかOOを強要する言語でミニプログラムを
書く場合はこんな感じ>>599でよろしいか？OOな方？
OO初心者はこんなことで真剣に悩むのです。
OOな方の見解を求む。
603 ：599：01/11/05 04:17
>>602
言語による。だいたいこんな感じ。
604 ：602：01/11/05 04:17
>>509-602
のうち
>>597>>599が別の方です。
605 ：デフォルトの名無しさん：01/11/05 04:19
>>603
599さん、ありがとうございます。
これで眠れます。
606 ：デフォルトの名無しさん：01/11/05 04:21
　　　　　＿＿＿＿＿
　　　 ／＿　　　　　　|
　 　 /.　＼￣￣￣￣|
　　/　　／　 ―　― |
　　|　 /　　 　-　　- |
　 ||| (6　　　　　　>　|
　| | |　　　　 ┏━┓|　　 ／￣￣￣￣￣￣￣￣
| | | | 　　　　┃─┃|　 ＜　正直、もう寝なさい
|| | | | 　＼　┃　 ┃/　 　 ＼＿＿＿＿＿＿＿＿
| || |　|　　　￣　￣|
607 ：599：01/11/05 04:23
>>605
JAVAはメソッド全部に static を付けないといけない。変数にも。
608 ：デフォルトの名無しさん：01/11/05 04:29
OOPでなくては、と思うのは、
幼児期の寂しい思いを引きずっていることに原因がある｡
始めのうちは、何でもできるグルーヴに酔っていて解らないが｡
やがてOOPでなくてもできるようになる。
609 ：599：01/11/05 04:48
>>605
607に書いたことは誤解を与える可能性があるので無視してください。
610 ：デフォルトの名無しさん：01/11/05 05:27
くだらないmain書いてると、ﾌﾟﾛｸﾞﾗﾑ的にどうかより、
OO的にどうかの方が重要な原理主義者だと思われますよ。
ただのﾈﾀだと思うけど。
611 ：オブジェクト指向の真実：01/11/05 06:54
オブジェクト指向とは、
変数と関数の位置を、
形式的にひっくり返すだけのこと。

y = function(x);
↓
y = x.function();

printf("Hello world.\n");
↓
"Hello world.\n".printf();
612 ：デフォルトの名無しさん：01/11/05 06:57
a = add(b, c);
↓
a = b.add(c);
↓
a = b + c;
613 ：デフォルトの名無しさん：01/11/05 07:00
つまりオブジェクト指向であるかどうかは、
単に形式上の問題に過ぎない。
614 ：デフォルトの名無しさん：01/11/05 07:11
でも、add(b,c)形式のままで継承とかクラスとかやられたら
非常にわかりにくいだろうなあ･･･
615 ：デフォルトの名無しさん：01/11/05 07:16
>>598>>610
おいおい馬鹿馬鹿しくも、くだらなくも、ないぞ。
それがオブジェクト指向だ。

この場合、プログラムが小さ過ぎて、
ありがたみがわからないが、
（だからそこまでする必要はないが）
プログラムによっては、
そのようにコーディングしておくことで、
保守、改良、拡張に威力を発揮する。
616 ：デフォルトの名無しさん：01/11/05 07:34
>>613
単に形式上の問題というが、それが大問題なのだよ。
どのような形式でコーディングするか、
それによって生産性が大きく違ってくる。

なぜならプログラムは人間が書くものだからだ。
単なる形式と言うならば、それは構造化プログラミングとて同じこと。
617 ：デフォルトの名無しさん：01/11/05 07:52
それは表面しか見ていないからだと思われ。
618 ：デフォルトの名無しさん：01/11/05 07:52
617>613
619 ：デフォルトの名無しさん：01/11/05 13:25
>>611
CLOSのようにメッセージパッシングでないオブジェクト指向システムもある。
CLOSでは (gf obj1 obj2 ...) と書くと、すべての引数のクラスによって
gfという名のメソッドの中から当てはまるものが選ばれる。最初だけが
特別ということはない。
620 ：デフォルトの名無しさん：01/11/05 13:26
オブジェクト指向において継承は重要じゃないし、特に設計段階では重視
しないほうが良い。インターフェースが重要。（実装の）継承は、設計を詳細
化していく過程で行われる一種の最適化だと思った方が良い。

昔はOOの利点として継承を強調することもあったが、今ではホワイトボックス
再利用の弊害が分かっているので、継承にはむしろ慎重になるのが常識だろう。
621 ：デフォルトの名無しさん：01/11/05 13:33
何、突然出て来て、一般論書いて喜んでんだよう>>620

OOでは継承は重要でない。
OOPでは、ステップの削減は重要だから、OOに関係無く継承は重要。

位のネットで言われてないこと書いたらどうだ？
622 ：デフォルトの名無しさん：01/11/05 13:36
私は、学んだが、
仕事では使う機会がない。ただ、

ラッパークラス却下
623 ：デフォルトの名無しさん：01/11/05 13:36
>>621
OOの話ですぐ「継承で悩む」とかいう厨房ばっかりだから。
ステップってLyeeの話か？（藁
624 ：デフォルトの名無しさん：01/11/05 13:38
継承で悩むなんて聞いたこと無いぞ。
継承しまくって行き詰まる、という話なら聞いたことあるが。
625 ：デフォルトの名無しさん：01/11/05 13:49
きたないやつだな>>623

OOとOOPと別けてるだろ。
ステップが減るというメリットが分からないやつは学生。
626 ：623：01/11/05 13:51
>>625
最適化としてはいいと思うよ。
設計から継承をあまり考えるとはまる。
627 ：デフォルトの名無しさん：01/11/05 14:02
あ、623てOOPのPが何かわかってないんだろ。
628 ：デフォルトの名無しさん：01/11/05 23:14
>>620
継承がホワイトボックスになるのは assertion を書かないから。
629 ：デフォルトの名無しさん：01/11/05 23:16
意味ﾜｶﾗﾝ。
630 ：デフォルトの名無しさん：01/11/05 23:22
>>629　どこが？
631 ：デフォルトの名無しさん：01/11/05 23:24
assertionを書くと、継承がブラックボックスになるという所。
632 ：デフォルトの名無しさん：01/11/05 23:32
>>631
assertion が言語に実装されていればってこと。
実装されていなくてもコメントに書いておけば継承するときの指針になる。
633 ：sage：01/11/05 23:34
たったの一、二行なのに突っ込みどころは多いな
634 ：デフォルトの名無しさん：01/11/05 23:38
>>632
あぁ、contractの話ね。
635 ：デフォルトの名無しさん：01/11/05 23:38
>>633　どういうところ？
636 ：デフォルトの名無しさん：01/11/05 23:40
>>634　そう、そう。
637 ：デフォルトの名無しさん：01/11/05 23:43
>>620
そういえば、「ホワイトボックス再利用」ってどういう意味なんでしょ？
なんとなーく、分かるけど。
質問しようと思っていて、忘れてた。
638 ：sage：01/11/05 23:50
>>634
了解した。

継承はともかく、予定されていない再利用は例外なく破綻するな。
639 ：デフォルトの名無しさん：01/11/05 23:55
>>637
インターフェースを介して（見えるものが制限された状態で）
部品を再利用しようとするブラックボックス再利用に対する
言葉で、実装のコードが丸見えの状態で、別にインターフェー
スには制約されずに再利用を行うこと。特に、子クラスが親
クラスのpublicでない変数やメソッドに直接アクセスするよ
うな再利用のやり方。
640 ：デフォルトの名無しさん：01/11/06 01:36
オブジェクト指向プログラミングは不滅です。
641 ：デフォルトの名無しさん：01/11/06 02:52
>>1
オブジェクト指向はインチキじゃない！
理解できない人がそう思ってるだけ。
642 ：デフォルトの名無しさん：01/11/06 03:14
>>641
10回くらい同じ台詞を聞いたが、みんなあんたか？
643 ：sage：01/11/06 04:22
>>642
そんなわけないだろ！
644 ：643：01/11/06 04:26
sage 書くとこ間違えた。
645 ：デフォルトの名無しさん：01/11/06 04:35
>>628
まあ、ある程度主旨はわかるが、
たとえあるclassがassertionでいろいろ教えてくれたとしても
継承したclassがassertionで宣言されていない性質を利用できないような仕組みがないと
結局white boxになるのでは？
646 ：デフォルトの名無しさん：01/11/06 04:47
>>645
「宣言されている性質」じゃないの？
647 ：デフォルトの名無しさん：01/11/06 04:53
勘違いした。「宣言されていない性質」であってるね。
648 ：デフォルトの名無しさん：01/11/06 05:22
再利用のしやすさ。
コピペ　>=　関数　>　クラス
649 ：デフォルトの名無しさん：01/11/06 05:38
派生クラスに対してすら、情報隠蔽
（デフォルトでメンバーの属性がprivate）しようとするのはやりすぎ。
デフォルトでprotectedにすべき。と思うのは俺だけ？
あとメンバー変数にread-only属性が欲しい。

インスタンスを操作するだけの場合と
クラスを派生させる場合とでは、明らかに
プログラミングにおける次元が違うというか、フェーズが違うというか。
それを同列に扱ってるように感じる＞デフォでprivate
650 ：628：01/11/06 05:39
>>645
>継承したclassがassertionで宣言されていない性質を利用できないような仕組みがないと
>結局white boxになるのでは？
そういう仕組みがある言語もある。
651 ：628：01/11/06 05:51
>>649
private の代わりに assertion があればもっといい。
652 ：645：01/11/06 05:58
>>650
例えば、ある配列型のインスタンス変数arrayについて
assertionでは a[i] <= a[i+1]としか表明していないけど
実装ではa[i+1] = a[i] + 1になっている場合を想定して、
subclassで実装したメソッドがa[i+1]=a[i]+1を前提にしている
というような場合も検出できるってこと？
653 ：デフォルトの名無しさん：01/11/06 06:02
>>649
assertionは良く知らんが、C++などでデフォルトprivateなのは
正しいと思う。よほどの決心をしない限り、子クラスであっても
インスタンスを組み合わせる場合と同じく「他人」として扱う
べきだ。

protectedはfriendと同じく、最適化のためにインターフェースを
緩める（そのぶん変更には弱くなる）仕組みと考えるべきだ。
654 ：デフォルトの名無しさん：01/11/06 06:06
ここのスレの大半がﾄﾝﾃﾞﾓなんだけど
ﾈﾀｽﾚなんだよね？
655 ：628：01/11/06 06:08
>>645
コード希望。きいてることが よくわからない。
656 ：628：01/11/06 07:07
>>652
参考にしてください。
http://www.eiffel.com/doc/online/eiffel50/intro/language/invitation-00.html
http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-10.html
オブジェクト指向言語のはなし ピアソン・エデュケーション
657 ：デフォルトの名無しさん：01/11/06 15:54
>>654
本気です。
658 ：デフォルトの名無しさん：01/11/06 17:10
VCでWinプログラム作った。
Javaでアプレットも作った。
だが未だにオブジェクト指向がわからん。
色んな奴が色んなことを言う。
俺のソース見てもOOじゃないと言われる。
でもちゃんと動くぞ。
659 ：デフォルトの名無しさん：01/11/06 22:25
みなさんUML使ってますか？
UMLを使ってみれば、自分が本当にOOを理解してるのかわかると思いますよ

OOPを実践してる人なら、UMLはすぐにつかえますよね

この前仕事で、VC++のコードを読んだのですが
virtualが一個もありませんでした（笑）
そして、if/eles/if/else/・・・めまいがします
OOがわかってないけど、C++なんて例は結構ありますよ

関数が、処理のモジュール化なら
OOは設計のモジュール化でしょうか？

OOを簡単に短期間でマスターするのにうってつけの方法は、
JavaのライブラリーをC++に移植する事です。
そうすれば、JAVAの理解がかなり深まりますし、
C++でOOPもできるようになるのでは？

がんばってください
660 ：デフォルトの名無しさん：01/11/07 00:42
>JavaのライブラリーをC++に移植する事です。
アホなこと抜かすな
661 ：デフォルトの名無しさん：01/11/07 01:25
>>660
JavaのライブラリってOO的には駄目なのか？
つうか、現存するOO的に良いライブラリってなんだろ。
662 ：デフォルトの名無しさん：01/11/07 01:34
>>661
Javaのライブラリが駄目か良いかじゃなくて 660は
Javaのライブラリーを C++に移植をしても OOPできるように
ならないっていいたいんじゃないの？
663 ：デフォルトの名無しさん：01/11/07 04:06
>>659
659に一票。Javaのソース読むだけでも随分理解は深まると思う。
664 ：デフォルトの名無しさん：01/11/07 05:03
>>663
同意。
ただ、C++に直すには、GCライブラリを併用しなきゃ無理だね。
665 ：デフォルトの名無しさん：01/11/07 05:22
UMLなんてお絵描きはどーでもいいし、
Java的に良いライブラリと
C++的に良いライブラリってのは別だし
Smalltalk的に良いライブラリってのもまた別だろ。
666 ：デフォルトの名無しさん：01/11/07 07:31
>>665
んな細かいこと言ってたら、
初心者は一歩も前に進めないよ。

OO初心者にはとりあえずOOどんなものか、
百聞は一見に如かずで、
Java（メジャーなC/C++に近いJavaがいい）
のソースを読んだ方がいい。

大体、俺もそうだったけど、具体的なコードも無しに
抽象的な理屈ばかり聞かされても、それじゃあ
"Hello world"はどうすりゃいいのか、それすらわからなかったよ。
（見てみりゃ「なんだこりゃ。こんなんでいいのか？」だった）

その方が、小うるさい偏屈どもの見解バラバラの議論を
聞かされるより、初心者には混乱が無い分ずっといい。
細かいことはそれからだよ。
667 ：　：01/11/08 02:09
まぁ、たいしたこともない既存の考え方にちょいと小難しい名前をつけて、
なんか新しい発見をしたように見せかけた（見えた）って言う面では詐欺師だな。
668 ：デフォルトの名無しさん：01/11/08 03:43
>>667
それならオブジェクト思考を否定しなくてもいいんじゃないかな。
669 ：659：01/11/08 21:22
>ただ、C++に直すには、GCライブラリを併用しなきゃ無理だね。
え、そうですか？
具体的にクラスを挙げてもらえるとわかりやすいのですが

もちろんdeleteは自分で書かなきゃいけないですけど

私はJAVAをやってからC++やったので
virtualの意味もわかりましたが、
C++から始めた人が、オブジェクト指向をどうやって理解してるのかが
かなり疑問です。
とりあえず、C++は世の中から早く消えるべきですね（笑）
670 ：デフォルトの名無しさん：01/11/08 21:36
>>659
ていうかオブジェクト指向はC++の用意してる道具のひとつ
に過ぎないんだが... 標準C++知らないんだろ。
generic programmingは知ってるかい?
STLはJavaのライブラリが作られたのと同時期に別の方針で
作られたんだが。
671 ：670：01/11/08 21:39
正確にはSTLを含むC++標準ライブラリね
プラットフォーム依存の部分が標準化されなかったのは問題ではある
672 ：デフォルトの名無しさん：01/11/08 21:52
Javaのコンテナクラスって、どうしても、ダウンキャストしなきゃ
ならなくなるだろ。
静的型付けの言語ならSTLのアプローチが正解。
673 ：デフォルトの名無しさん：01/11/08 23:34
templateをつかった genericはインスタンス化するまで型チェックできないので
parameterized classをつかった genericが正解。
674 ：デフォルトの名無しさん：01/11/09 23:29
名スレの予感。
675 ：デフォルトの名無しさん：01/11/09 23:52
>>673
別に、インスタンス化したときに型チェックが出来れば、それでいいんでは？
676 ：デフォルトの名無しさん：01/11/10 00:50
>>675
それではinstanceが型的に正しい事がわかるだけで、
template自体が型的に正しいかどうかはわからない。
libraryで使うにはダメダメでしょう。
677 ：デフォルトの名無しさん：01/11/10 20:20
OO信者に限って全然OOを使いこなしていない説に一票。
小難しい用語を振り回せば気分はスペシャリスト？
アンチはアンチで、OO自体糞といっているのか、今あるOOPLが不満
なのか、単に信者がうざいのか不明。
どーにかしてくれ。
678 ：デフォルトの名無しさん：01/11/10 20:22
みんなでlispやれ
679 ：デフォルトの名無しさん：01/11/10 21:59
>>676
＞template自体が型的に正しいかどうかはわからない。
＞libraryで使うにはダメダメでしょう。

「型的に正しい」とはどういう意味? どんな型でも「正しい」
のがテンプレートですが何か? 適切な演算子/インターフェイス
さえ存在する限り適用できる。
680 ：デフォルトの名無しさん：01/11/10 22:31
>>678がいいこと言った！
681 ：673：01/11/10 23:59
あれからいろいろ考えた結果
673の主張を取り下げます。
お騒がせしてすみません。
682 ：デフォルトの名無しさん：01/11/11 01:29
>>677
>OO信者に限って全然OOを使いこなしていない説に一票。
>小難しい用語を振り回せば気分はスペシャリスト？
激しく同意。
あ～もう信者がウザイ、マジでしね。
おかげでおれはもうすっかりアンチ Lisp でもやるかな、もう。
OO は本質じゃないところで効率が落ちる。
683 ：横槍くん：01/11/11 01:42
LispってOOだったのか
684 ：デフォルトの名無しさん：01/11/11 01:48
プログラマの教養言語>683
685 ：デフォルトの名無しさん：01/11/11 02:05
>>683
LispにはCLOSという名前のOO機能がある。
686 ：デフォルトの名無しさん：01/11/11 03:09
C++が完全にオブジェクト指向かは疑問。
687 ：デフォルトの名無しさん：01/11/11 04:02
>>686
だからテンプレートとかオブジェクト指向と関係ないんだって。
オブジェクト指向「だけ」サポートすればいい言語とそうでない
言語の違いだよ
688 ：デフォルトの名無しさん：01/11/11 04:03
完全なオブジェクト指向言語は駄目。
混ぜて書けるＣ＋＋が正解。
689 ：デフォルトの名無しさん：01/11/11 04:14
>>685
CLOS以外にもLOOPSとかFlavorとかのOO拡張があるよね。
で、それらはオブジェクト指向の歴史にもかなり影響を与えているわけで。
690 ：デフォルトの名無しさん：01/11/11 04:21
>>688
アホ発見。
691 ：デフォルトの名無しさん：01/11/11 04:23
オブジェクト指向かどうかで言語を評価するなんて
ダサダサにもほどがあるよ。
692 ：デフォルトの名無しさん：01/11/11 04:32
>>691
いや、それも重要な評価要素ではあるんじゃない？
オブジェクト指向使わない人にはあまり関係ないけど。
693 ：デフォルトの名無しさん：01/11/11 04:39
＞＞タイトル

オブジェクト指向ー詐欺師の時代の終焉。

あまりにもＣ＋＋に特化して話してない？
694 ：デフォルトの名無しさん：01/11/11 04:46
ネタスレだからいいんだよ
695 ：691：01/11/11 04:50
>>692
っていうか、プログラミング言語ってのは
いろんな概念を組み合わせて一つのモデルと表現を提示するわけで、
どんな概念を実装しているかみたいなカタログスペックよりは、
全体として、それぞれの概念がうまく継がって組織化されているかが
言語が実装している概念に関して評価するためのポイントになると思う。

っていうか、オブジェクト指向という構造だけを捉えて
良い悪いも何もないと思うのだが。
696 ：デフォルトの名無しさん：01/11/11 04:56
＞っていうか、オブジェクト指向という構造だけを捉えて
＞良い悪いも何もないと思うのだが。
これは言語中心の視点でのこと？
オブジェクト指向というモデルが有用かそうでないかはいえると思うが。
697 ：デフォルトの名無しさん：01/11/11 05:53
全部クラスで組め！つう言語は駄目。
ＯＯあるいはクラスを使わない部分を組む時はマイナスでしかない。
698 ：デフォルトの名無しさん：01/11/11 07:15
>>697
全部クラスで組めないのはオブジェクト指向を分かってない証拠。
699 ：デフォルトの名無しさん：01/11/11 07:57
>>681
>templateはインスタンス化するまで型チェックできない
というのは違ってるけど
取り下げなくてもいいんじゃないかな。
templateはインスタンス化するまでコンパイルエラーを検出できないし。
700 ：デフォルトの名無しさん：01/11/11 12:39
>Javaのコンテナクラスって、どうしても、ダウンキャストしなきゃ
>ならなくなるだろ。
これは問題ですよね？
Javaでは委譲させる方針なのではないでしょうか？
例えばStackなら
class NewStack{
private stack;
void push(NewObject obj){stack.push(obj)}
NewObject pop(){return (NewObject)stack.pop();}
}
ってな感じで・・・
私は、ダウンキャストが必要なほどの汎用的なコンテナはあまり使わないので
よくわかりませんが・・・
701 ：デフォルトの名無しさん：01/11/11 14:58
>>698
ＯＯ原理主義者発見！
702 ：デフォルトの名無しさん：01/11/11 16:25
>>701
反ＯＯ原理主義者発見！
703 ：デフォルトの名無しさん：01/11/11 17:00
>>595

>しかし、一貫して、この方法で構造化プログラミングを
>形式的にオブジェクト指向に変換しても、
>それはオブジェクト指向だろうかという話です。
>例えば
>
>main()
>{
>　int x,y;
>　x=input();
>　y=func(x);
>　output(y);
>}
>↑これを形式的に変換したもの↓はオブジェクト指向か？
>（私はYESだと思うのだが、どうですか？
>これを認めないとOOPを強要する言語では
>小さなプログラムは組めないと思うのですが。）
>class Main{
>　int x, y;
>public:
>　void input();
>　void output();
>　void func();
>　void execute(){ input(); func(); output(); }
>}
ってゆーかinput func outputとか機能を関数的に分解して思考してる所が
すでに駄目なんだな。うちにもそういうボケたオヤジがいるんだけど、
おまえらマジどっか行けって感じだな。
704 ：デフォルトの名無しさん：01/11/11 17:04
>>703
ネタにマジレス
705 ：595：01/11/11 17:10
>>703
んじゃどーゆーふうにするの？教えて？
ネタじゃ無いです。
706 ：595：01/11/11 17:12
いつも違うとだけ言われて、
どう違うのか示さないんじゃ
OOに不信感を抱く。（ネタじゃありません）
707 ：デフォルトの名無しさん：01/11/11 17:13
>>703
お前が本当にOOを理解してるならな。
708 ：デフォルトの名無しさん：01/11/11 17:14
707=595
709 ：595：01/11/11 17:20
>>703
お前ならどう書くんだよ。マジで知りたい。
短いプログラムなんだからよ、書くのに時間はかかんねえだろが。
いらいらすんだよ。さっさと書けよ。ネタじゃねえぞ。
710 ：704：01/11/11 17:20
マジだったの？絶句。
構造化プログラミングにおけるモジュール強度の議論は知ってる？
e.g. http://hata.cc/docs/software-guide/2-1.html

595 のやり方だとせいぜい時間的・手順的強度しか持たない。
もちろんサンプルのコードがごく短いため、
それ以上の強度が必要とされないということもある。

オブジェクト指向のメソッドは、
この指標では情報的・機能的強度を持っているモジュールといえる。
711 ：595：01/11/11 17:24
>>710
いやだから本当のところどうなのさ？
あの短いプログラムをOOで書いてたらどーなるの？？
712 ：デフォルトの名無しさん：01/11/11 17:27
inputクラスとfunctionクラスとoutoputクラスを作って多重継承
するんだろｗ
713 ：704：01/11/11 17:30
>>711
前提となっているプログラムの
input() func() output()
といった関数がオブジェクト指向プログラムのメソッド程度の
モジュール強度を有していないので、
変換するという行為自体無意味。

input/output は入出力を司るクラスに任せるだろうし、
func なんて何するか分からんメソッドはそもそも作らない。
714 ：デフォルトの名無しさん：01/11/11 17:31
>>712
俺ならそうする。（マジ）
715 ：デフォルトの名無しさん：01/11/11 17:32
なんだよ「モジュール強度」つうのは？
書いていて恥ずかしくないか？
716 ：704：01/11/11 17:36
オブジェクト指向に懐疑的なら
オブジェクト指向以前の用語を使おうと思って。
ソフトウェア工学方面でしか使われない用語だけど、
モジュール強度の考え自体はおかしくないと思うが。
717 ：595：01/11/11 17:42
>>713
＞func なんて何するか分からんメソッドはそもそも作らない

言ってる事が無茶苦茶だ。
OOPLではどんな処理でもメソッドに書くしかないだろうが。
あんな簡単な小さなプログラムが
あんたには書けないということになるぞ？
718 ：595：01/11/11 17:49
もう俺的には、あんたは信用しない。>>704
抽象的なことばかり言って煙に巻こうとするだけ。
ネタでもあおりでもないよ。
719 ：704：01/11/11 17:51
>>717
名前が悪いってことだよ。
メソッドの処理・機能に適した名前を付けなきゃしょうがない。
これは OO 以前の話か。

OO 的にするなら、func() の代わりに func() が成す
機能を表したクラスを作って、そいつのメソッドを呼び出す。
720 ：704：01/11/11 17:57
>>718
前提とする概念が存在するのだからしょうがないじゃん。
プログラミングするときに、漠然として無意識的に考えていること（暗黙知）を
形式知に変えてやるのが構造化プログラミングやOOP（などの手法）の仕事の一つなんだよ。

例えばデザインパターンはその代表例。
ある程度の経験をもった人なら同じようなことを考えついているし使ってもいるが、
それをみなが共通して使える概念として形式知化したのが大きな功績。
721 ：595：01/11/11 17:58
>>719

>>598と>>599も見てくれ。どっちがいい？
それともどっちもだめか？（しつこいけどマジ。）
722 ：595：01/11/11 18:00
どっちも強度はあるとおもうんだが。
つうか全然一連の文脈の中で読んでないだろ>>704
723 ：デフォルトの名無しさん：01/11/11 18:03
>>720
そして木の車輪を押し付けてくる。と。
724 ：704：01/11/11 18:11
>>721
OOPL の形式的には両方正しいよ。
コードの抽象度が高いから何ともいえない。

C++ で例を挙げれば、
input が scanf を呼んで得た値をメンバ変数にセットするなら
余り行儀がいいとは思わない。
俺ならデータ入出力用のクラスを作るという程度なので、
（テキストから読むか、DB から読むか、あるいはデータの形式が変わるかも知れないので）
それが悪いとはいえないが。
725 ：595：01/11/11 18:13
サンクス>>704
726 ：704：01/11/11 18:15
>>723
使わなくても何ら困らないなら
使わなくていいものなんだろう。

俺は Java 使ってるから OO 使わないと困る。
727 ：デフォルトの名無しさん：01/11/11 18:59
追加
木の車輪を押し付けてきて、
使わないと「ロートル、頭が固い」とレッテル貼りする。
728 ：1/3：01/11/11 19:08
///////////////////////////////////////
// mainbase.h
///////////////////////////////////////
#ifndef MAINBASE_H_INCLUDE
#define MAINBASE_H_INCLUDE
class IInput
{
public:
virtual int Get() = 0;
};

class IOutput
{
public:
virtual void Put(int x) = 0;
};

class MainBase
{
protected:
IInput* m_Input;
IOutput* m_Output;
protected:
void SetIO(IInput* in, IOutput* out){m_Input=in;m_Output=out;}
int Input(){return m_Input->Get();}
void Output(int x){m_Output->Put(x);}
public:
virtual int Execute() = 0;
};
#endif// MAINBASE_H_INCLUDE
729 ：2/3：01/11/11 19:08
///////////////////////////////////////
// ui.h
///////////////////////////////////////
#ifndef UI_H_INCLUDE
#define UI_H_INCLUDE

#include <iostream>
#include "mainbase.h"
using namespace std;

class IInputStandardStream : public IInput
{
public:
int Get()
{
int i;
cin >> i;
return i;
}
};

class IOutputStandardStream : public IOutput
{
public:
void Put(int x){cout << x <<endl;};
};
#endif// UI_H_INCLUDE
730 ：3/3：01/11/11 19:09
///////////////////////////////////////
// main.cpp
///////////////////////////////////////
#include "mainbase.h"
#include "ui.h"

class MainSample : public MainBase
{
public:
int Execute();
private:
void Initialize();
int Func(int x){return x++;}
};

void MainSample::Initialize()
{
IInputStandardStream *in = new IInputStandardStream();
IOutputStandardStream *out = new IOutputStandardStream();
SetIO(in,out);
}

int MainSample::Execute()
{
Initialize();
Output(Func(Input()));
return 0;
}

/////////////////////////////
int main()
{
MainSample sample;
return sample.Execute();
}
731 ：728-730：01/11/11 19:11
先生! Bridgeパターン使ってみました!
732 ：728-730：01/11/11 19:20
先生! Interfaceのdelete忘れてました。逝ってきます。
733 ：先生：01/11/11 19:31
ＯＯは生産性が落ちるというのが良くわかりましたか？
734 ：728-730：01/11/11 20:08
先生！　とてもよくわかりました！
ﾃﾞﾓOOｽｷﾖ
735 ：デフォルトの名無しさん：01/11/12 00:48
OOを理解できない人達のあがきって、ホントに哀しいね。
本人は「理解して批判してるつもり」なのに、まわりから見ると
ただの「ついていけない人間のアガキ」。
736 ：デフォルトの名無しさん：01/11/12 00:57
>>735
OOは役立たずの糞。猿プログラマのオナニー。
737 ：デフォルトの名無しさん：01/11/12 01:11
>>736
あー、はいはい。努力したのに理解できなかったのね。
可哀想に。

消えろ。
738 ：デフォルトの名無しさん：01/11/12 01:16
理解してるつもりの737であった。
739 ：デフォルトの名無しさん：01/11/12 01:19
OO信者は小うるさくてかなわん。
うざすぎ。黙ってオナニーしてろ。
オナニーの仕方を押し付けるな。
740 ：デフォルトの名無しさん：01/11/12 01:22
OOを理解してるという奴が１０人いれば
１０人とも違うことを言うじゃねえか。
いい加減それがオブジェクト指向の
正体だと悟りやがれ。間抜け。
741 ：デフォルトの名無しさん：01/11/12 01:23
つーか、735見たいなやつ、ウチの会社にも多いけど
一番理解してなかったりするんだよね。
大体バグだしてトラブル起こして、ついでに人間関係にまでトラブル起こす。
もう最悪
742 ：デフォルトの名無しさん：01/11/12 01:23
今どきオブジェクト指向の利点を疑う人間がいるということがどうしても信じ
られなくてスレを読み返してみたんだが、反OO派は結局「データ抽象」を持ち
出されるたびに黙り込んで答えず、しばらくしてまた中身のない批判を繰り返
しているだけに見える。

・反OO派はデータ抽象の利点を認めないのか？
・認めるなら、>>351 みたいなコードを自分で毎回書くのか？
・それくらいならC++やJavaを使った方が良いということがわからないのか？
743 ：デフォルトの名無しさん：01/11/12 01:29
>>742
妄想君。
ＯＯ原理主義は生産性下がるから駄目だという簡単な話。
744 ：デフォルトの名無しさん：01/11/12 01:30
>>742
結局、今自分がいる環境によりけりな気がする。
OO を取り入れている職場かそうでないか。
使ってなくても仕事ができているなら
わざわざ勉強してまで使う気がしないのかも。
特に自分ひとり頑張っても職場全体で使われなきゃだめなことだし。
745 ：デフォルトの名無しさん：01/11/12 01:30
>>743
そうやって話をはぐらかしてばかりいると「分かっていない」と思われても仕
方がない。
746 ：デフォルトの名無しさん：01/11/12 01:31
なぜ >>742 のような単純な質問に答えられないんでしょーね～
747 ：デフォルトの名無しさん：01/11/12 01:33
>>745
はぐらかすって何が？
抽象データ型がどうしたって？
748 ：デフォルトの名無しさん：01/11/12 01:33
>>745
分かってるわかってないとかじゃなくて、OOは精神病患者を呼び寄せる何かがあるから厄介なんだよ。
黙って使ってりゃいいんだ。
749 ：デフォルトの名無しさん：01/11/12 01:36
>>746
妄想だと言ってるだろ。VOKE!
750 ：デフォルトの名無しさん：01/11/12 01:38
知識振り回しても馬鹿にされるだけ。
それが判らないキティーが集まるのがＯＯ。
751 ：デフォルトの名無しさん：01/11/12 01:39
生産性が下がる下がるとオウム返しのようにいっているが、
その生産性って一体何？
コードを書く速さ？
設計から保守までを含めたもの？
752 ：デフォルトの名無しさん：01/11/12 01:39
クラスを継承するよりはクラスを修正した方が早いというのは事実。
753 ：デフォルトの名無しさん：01/11/12 01:40
ああ、やはり反OO派は過去ログも読まず、OOと抽象データ型の関係も理解せず、
ただ「OOはダメだ」と繰り返していればOOが自分の前から消えてくれると信じ
て「ダチョウ的対応」をしているのにすぎないのか…

>>742 の３つの質問に答えることさえ出来ないのか？
754 ：デフォルトの名無しさん：01/11/12 01:40
>>751
全部
755 ：デフォルトの名無しさん：01/11/12 01:42
抽象データー型馬鹿はもう寝ろや。
クラスとＯＯを混同してるし、メソッドをゲッターとセッターしか
思いつかないらしいな。
756 ：デフォルトの名無しさん：01/11/12 01:42
>>753
ムダだよ。やつら反ＯＯ派は「妄想」「信者」と繰り返すばかりで
中身の議論なんかしようとしない。まあ仕様と思ってもできないん
だろうけどな。
757 ：デフォルトの名無しさん：01/11/12 01:43
>>752
人の迷惑、考えたことある？
758 ：デフォルトの名無しさん：01/11/12 01:43
>>755
はぐらかすのはもう良いからさっさと質問に答えてくれないかな？
759 ：デフォルトの名無しさん：01/11/12 01:43
>>757
むやみに継承するほうが迷惑。
760 ：デフォルトの名無しさん：01/11/12 01:44
反ＯＯ派の中には、ＯＯ自体は否定しないが、ＯＯ使う人間が嫌いなヤツもいます。
761 ：デフォルトの名無しさん：01/11/12 01:45
>>755
>>351にはgetterもsetterも出てこないが？
ホントにわかってんの？（ｗ
762 ：デフォルトの名無しさん：01/11/12 01:45
>>760
そういう人にこそ >>742 の答を聞いてみたいもんだ。
763 ：デフォルトの名無しさん：01/11/12 01:47
>・反OO派はデータ抽象の利点を認めないのか？
　みとめるよ、よく使う
>・認めるなら、>>351 みたいなコードを自分で毎回書くのか？
　かかない。
>・それくらいならC++やJavaを使った方が良いということがわからないのか？
　意味不明
764 ：デフォルトの名無しさん：01/11/12 01:47
>>762
禿動
765 ：デフォルトの名無しさん：01/11/12 01:49
>>763
じゃ >>333みたいなコードは書く？
766 ：デフォルトの名無しさん：01/11/12 01:50
>>755 「データー」ってゆーな、ジジイ！
767 ：デフォルトの名無しさん：01/11/12 01:51
かかんよ、C++使う。でもＯＯキチガイクソヤロウは嫌い。
768 ：デフォルトの名無しさん：01/11/12 01:52
謎は全て解けた！
みんなオブジェクト指向なんて普通に使ってるんだよ。
ここは当たり前のことをわざわざ力説するやつを馬鹿にするスレなんだよ。
1+1 は 2 なんだよって幼稚園生以外に力説してたら馬鹿だしね。
769 ：デフォルトの名無しさん：01/11/12 01:52
>>767
なんだ、「ＯＯ使う人間が嫌い」な側から見ればあんたも
嫌われるんじゃん。
770 ：デフォルトの名無しさん：01/11/12 01:54
>>768
つまりあなたも（気が付かないうちに）ＯＯ使ってました、と。
771 ：デフォルトの名無しさん：01/11/12 01:56
ＯＯキチガイよりは、シッタカＯＯ使いの方が迷惑だな。
772 ：デフォルトの名無しさん：01/11/12 01:57
>>770
その挙句、
OO使うかどうかでその人が嫌いかどうかを決めてしまうぐらい
OOに頼りっきりの人間になっていました、と。
773 ：デフォルトの名無しさん：01/11/12 01:58
>>770
情けない話だね。
自分が罵っていたのが自分自身だったことにやっと気づいた768（藁
774 ：デフォルトの名無しさん：01/11/12 01:59
>>771
で、君は他人がシッタカかどうかを判断できるほど
ちゃんとした知識と技術があると思ってるんだね、シッタカ君？
775 ：デフォルトの名無しさん：01/11/12 02:00
否定はともかくこのスレでマジレスしてる肯定派は芯だ方がいい
776 ：デフォルトの名無しさん：01/11/12 02:01
>>772
>OOに頼りっきりの人間になっていました、と。
そんなこたぁねえよ、世の中は広い、関数型言語とか論理型言語とかやってみな。
OOは万能じゃねぇ。
777 ：デフォルトの名無しさん：01/11/12 02:02
>>775
プププププ‥　何、涙目になってんだYO!
778 ：デフォルトの名無しさん：01/11/12 02:03
>>776
手続き型・関数型・論理型というパラダイムとOOかどうかは直行する。
オブジェクト指向関数型言語(Ocaml)やオブジェクト指向論理型言語
(ESP)もあるよ。
779 ：デフォルトの名無しさん：01/11/12 02:03
>>776
>OOは万能じゃねぇよ。
の間違い
780 ：デフォルトの名無しさん：01/11/12 02:04
>>776
ハア？
関数型言語も論理型言語もOOを取り入れてる言語は色々あるが、
それが何か？
781 ：778：01/11/12 02:05
直行じゃなくて直交でした。逝ってきます。
782 ：デフォルトの名無しさん：01/11/12 02:06
>>780
しってるだけで使ったことねぇだろ（藁
783 ：デフォルトの名無しさん：01/11/12 02:06
>742
・データ抽象化が便利な時は当然そうする。
・Cと共存させるなら>>351みたいなコードを書くことはある。
・全部objectiveに書くプログラムならC++なり何なりで書く。

逆に質問。
・OO原理主義者はデータ抽象化が無用の長物になる場面があると認めないのか？
・Hello worldをいちいちクラス作って書くのか？
・それくらいならCで非OO的に書いた方が良いということがわからないのか？
784 ：780：01/11/12 02:09
>>782
そういう(OO+FPL, OO+LP)処理系を実装したことがあるのだが。
Smalltalkで。
785 ：デフォルトの名無しさん：01/11/12 02:11
>>783
>・OO原理主義者はデータ抽象化が無用の長物になる場面があると認めないのか？
認めるとも。抽象データ型もどこかで具体的なデータ表現に落すんだから。

>・Hello worldをいちいちクラス作って書くのか？
それは言語による。「プログラムはクラス（とメソッド）。関数や手続きなん
てものはない」と割りきった言語（メソッドと関数を両方持つよりはまし）な
らクラス作る。C++ならmainだけで書くね。

>・それくらいならCで非OO的に書いた方が良いということがわからないのか？
「データ抽象化（やOO）を使わない局面がある」のと「OOを否定する」のは全
く別の話。「OOを全否定する」のは「OOが有用な局面など存在しない」と言っ
ているのと同じなのだから。
786 ：785：01/11/12 02:12
あー、俺はOO原理主義者とは言えないようなので、答えちゃいけなかったのか
も知れん。
787 ：デフォルトの名無しさん：01/11/12 02:12
おれも、その手の実装したことあるよ。
flex bison で、
そういうのエラソーに自慢するからバカにされるんよ。
788 ：デフォルトの名無しさん：01/11/12 02:22
>>783
君はHello worldを書く時の生産性や実行効率で
言語を評価するのか（藁

それは横に置いといて、まあマジレスしてみるよ。

・データ抽象化が無用の長物になる事は、あるな。
　ただ、どんな形で再利用されるかわからないような状況では
　できるだけ抽象しておいたほうがいい、とは思うが。

・Hello worldぐらい、どっちでも構わんな。
　それにクラスを使わないOOもあるでよぉー。

・Cで非OO的なアプローチのほうが向いてる分野ってのは、確実にあるよ。
　俺、現状ではSmalltalkでデバイスドライバ書きたくないもん（藁

っていうか、ちゃんとしたプログラマなら、
どんな状況でどんな言語を使うか、それぞれの言語が
取り入れている概念を理解した上で判断するもんだろ。
俺が哂ってるのは、OOだから糞だとか、そういう主張ね。
789 ：デフォルトの名無しさん：01/11/12 02:28
>>787
flex bisonでねぇー。
そういうのエラソーに自慢するからバカにされるんよ。
790 ：デフォルトの名無しさん：01/11/12 02:33
ああ、俺的には「謎は全て解けた」なー。

「全部抽象化しろ」というのは不可能だし「OOは全部ダメ」というやつは本当
に分かってないのが明らかだ。つまり、まともなヤツはみんな「適切なところ
だけ抽象化して書く」という点で一致してる。

だいいち、必要なところだけ抽象化して書けば、ある意味それで立派なOOPに
なってるわけだからな。その道具として便利なら当然OOPLを使うだろう。

OO全否定派は論外として、OO否定派が「会社にOO原理主義者がいてウザイ」と
いうのは、「どこまで抽象化するか」で意見が食い違ってウザイ、ということ
じゃないの？

（少なくとも「いたるところ全て抽象化して書け」というようなOO原理主義者
はこのスレで見たことがない。）
791 ：デフォルトの名無しさん：01/11/12 02:37
>>790
まとめようとするなよ（藁
せっかく煽ってるのに。

「OO全部ダメ」とか「すべてメソッドで」とかの両極端が糞なのは
最初から分かりきってるだろーが。それを承知で遊ぶのがこのスレ
だろう？
792 ：デフォルトの名無しさん：01/11/12 02:46
ＯＯ原理主義者の素朴な疑問

ＯＯＰするときはクラスしか思い浮かばないけど
クラスを使わない部分があるってどういうこと？

ＵＭＬはどんなふうに書くの？

デザパタはどんなふうに使うの？

Smalltalk, JAVA, C# のような言語をどう思ってるの？
793 ：デフォルトの名無しさん：01/11/12 02:54
>>792
俺はOOマンセーな人間だがUMLによるOODには正直疑問を抱いている。
インターフェースを用いた抽象化を十分支援していないように思えるから。

UMLでクラスの属性を書いてしまうと、かなり具体的な表現を与えてしまう
ことになる。設計の初期段階でクラスの内部表現を具体的に決めてしまうの
は害があるように思える。

デザパタについては、インターフェースを用いたオブジェクトコンポジショ
ンを強調しているところが良い。インスタンス変数を直接触るようなコード
は出てこない。そういう具体的な表現は、デザパタで扱うより下位のレベル。

Smalltalk: 「何でもクラスとメッセージ」でやってみようという気概は買
うが、数式や関数の表し方が不自然になった。

Java: いろいろ細かい不満はあるが、今のところもっとも良いOO言語。

C#: Javaの焼き直し。後出しだけに優れたところもあるが、MSらしい汚らし
いところも多々ある。デフォルトnon-virtualなのは何とかしろ。
794 ：792：01/11/12 03:09
>>793
おれもUMLは嫌いだ。

>C#: デフォルトnon-virtualなのは何とかしろ。
その通り。
795 ：デフォルトの名無しさん：01/11/12 03:10
>>792
おれもかなりOO原理主義っつーかSmalltalk原理主義はいってるが...

OOPするときにはクラスよりもまずインスタンスを思い浮べるよ。
クラスはあくまでインスタンスを実装する手段って感じ。

Smalltalk: マンセーだけど、四則演算ぐらい特別扱いしてやっても...
Java: interfaceは買い。checked exceptionもイイね。
　　　静的型OO言語としては、かなりよい言語だと思う。
　　　ただ整数がオブジェクトじゃないのは萎え。
C#:　boxingは買い。あと、使った事ないけどstructもいいかも。
　　あとはJavaと同様。
796 ：デフォルトの名無しさん：01/11/12 03:10
＞UMLでクラスの属性を書いてしまうと、かなり具体的な表現を与えてしまう
＞ことになる。設計の初期段階でクラスの内部表現を具体的に決めてしまうの
＞は害があるように思える。
俺は初期の段階ではクラス名だけのクラス図を書いて、
後で実装しつつクラス図を詳細化（またはその逆）してる。
最初に書くクラス図とその後に作るクラス図は必ずしも対応してない。
大抵は分割したりデザパタのためにクラスを追加したりだな。
箱書いた紙だらけになるけど、
クラス図眺めておかしいところを発見することがままあるので良しとしてる。
797 ：デフォルトの名無しさん：01/11/12 03:17
>>793
デフォルトnon-virtualは、間違いをコンパイラで拾えるから
むしろ、良い傾向だと思うが…

どちらかというと、C++でいうところのテンプレートを
サポートしなっかったのは、どうでるでしょうか？
Javaでももうすぐサポートしそうな感じ(?)なんだけど…
798 ：デフォルトの名無しさん：01/11/12 03:29
既出だが Map とかいう共通インターフェースを作っといて、
実装がハッシュか木か等は実行時に決まる、という重要な
特性がnon-virtualだと失われる。コンパイル時に実装も
一意に決まってしまう。
799 ：デフォルトの名無しさん：01/11/12 03:30
>>797
デザインパターンの多くのパターンはnonvirtualだと使えないよ。
800 ：792：01/11/12 03:32
おれは Eiffelマンセーなので多重継承派。
Design by Contract がお気に入り。
メソッドはデフォルトnon-virtualだがオーバライドすると
コンパイラが virtualにしてくれる。
801 ：デフォルトの名無しさん：01/11/12 03:39
>>800
確か、Eiffel って演算子オーバーロードできたよね。
どういう仕組み使ってるの？coerce？
802 ：800：01/11/12 03:48
>>801
prefix"+": ANY is do ... end
infix"+"(i: ANY): ANY is do ... end
803 ：デフォルトの名無しさん：01/11/12 03:55
結論：反OO派などいませんでした。いるのは、自分もOO派であることに
気づかなかった間抜けな厨房だけでした。

---------------------------終了---------------------------------
804 ：デフォルトの名無しさん：01/11/12 04:01
>>803
おいおい、決めつけるなよ。
本当にOOも抽象化も使ってないバカもきっといるって（藁
805 ：デフォルトの名無しさん：01/11/12 04:15
>>802
サンクス。が、不勉強で悪いけど読めない…
前者が単項の + で後者が加算の + なのはわかるけど、
ANY というのは文字通り何の型でも受け付けるという意味？
それとも対応したい型の数だけ定義が必要？
あるいは同じ型に対しての演算に閉じた演算子を定義可能なのかな。
静的型だと3番目か。

入門ページ見つけたけど特徴だとか総称だとか漢字が溢れててダメだ…
806 ：800：01/11/12 04:22
>>805
ちゃんと書かなくてすみません。
ANY は JAVA の Object と同じです。
807 ：デフォルトの名無しさん：01/11/12 04:31
>>797
逆に言うと、デザパタの多くのパターンの多くはoverride"しなければならない"。
または、TemplateMethodのようにoverride"すべきでない"こともある。
それをPGがはっきり意識するように、virtual/overrideキーワードがある。

とはいうものの、C#のvirtual/overrideは、Javaのfinalの裏返しみたいなものだから
どちらの方が良いというものではないかもしれない。
むしろ、virtualにする場面の方が、はるかに多いと思われるので、
上の方のclassはvirtualだらけになってしまうだろう。
しかし、この「いつも意識しなければいけない」というのが狙い。

ただまあ、気構えとかコードの見栄えとか好みの問題なので
どちらの方が良いかは、かなり賛否両論だろう。
808 ：デフォルトの名無しさん：01/11/12 04:36
>>807
virtualにしないでvirtual的な使い方をしようとしたとき、
ちゃんとエラーになるなら良いけど、C#だと、気づかずに
nonvirtualになっちゃうことはないの？
809 ：デフォルトの名無しさん：01/11/12 04:42
>>807
C#には sealedってキーワードがあったような . . .
810 ：807：01/11/12 04:58
C#とかあんま知らないのに、適当に受け答えするから
しんどくなってきたよ（TДT）

実は、>>807を返答するにも、必死でwebをあさっていたのさ
ttp://www.asahi-net.or.jp/~AN4J-UEHR/homepage.en/jp/.NETplaf/bench.htm
ttp://www.users.gr.jp/ml/archive/CS/66.asp
よく知ってる人、あとは任せた
811 ：デフォルトの名無しさん：01/11/12 16:49
C#のメソッドについてちょっと調べたよ。

C#で新たなインスタンスメソッドを宣言するときには、
C++と同じようにvirtualかnon-virtualかを選ぶことができる。

その派生クラスで同じシグネチャのメソッドを宣言するときは、
overrideするか、同じシグネチャの別のメソッドを新しく作るか
の2通りがある。後者の場合、基底ではvirtualだったメソッドと
同じ名前のnon-virtualなメソッドを新たに作るなんてこともできる。
（逆に、non-virtualだったのをvirtualにすることもできる。）

例えば、クラスComponentにresize(int x, int y)というvirtual
メソッドがあって、その派生クラスFrameのインスタンスに対して
resize(x, y)を呼び出すとき、Componentの定義を見ただけでは
これがvirtualメソッドかどうか分からない。Frame、その親、その
また親、...と定義を見ていって、resize(int, int)を定義している
場所を見つけなければならない。

その他、新たなメソッドを宣言するときにはabstractメソッドに
することができる（暗黙のうちにvirtualになる）。新たなメソッド
宣言やoverride宣言でsealed修飾を加えてoverrideを禁止できる。
（でも、同じ名前の新しいメソッドを派生クラスで宣言することは
できる。）
812 ：デフォルトの名無しさん：01/11/12 21:01
粘着抽象データ型馬鹿に荒らされてたのか。
そのメチャクチャな論法で行くと、どのソースも構造化使ってるからＯＯＰなど
存在しないことになるぞ？
813 ：デフォルトの名無しさん：01/11/12 21:08
>>812
意味不明。構造化構文とOOは独立だがデータ抽象化とOOは密接な関連がある。
814 ：デフォルトの名無しさん：01/11/12 21:09
>>812
メチャクチャってどこがどう？
815 ：sage：01/11/12 22:20
>>814
812は荒しだよ。放置しろ。
816 ：デフォルトの名無しさん：01/11/12 22:26
int main()
{
　　new 812;
　　return 0;
}
817 ：デフォルトの名無しさん：01/11/12 22:34
>>813
じゃあファイル操作やってるプログラムは全部オブジェクト指向ね。
あいつの論法だけど。
IO操作も大体抽象化してるから全部オブジェクト指向ね。
818 ：デフォルトの名無しさん：01/11/12 22:40
>>816
リークしてるよ、それTT
819 ：デフォルトの名無しさん：01/11/12 22:43
メモリが812で埋め尽くされる＝812勝利という意味。
820 ：デフォルトの名無しさん：01/11/12 23:15
>>818-819
別にリークしてないが？（藁
821 ：デフォルトの名無しさん：01/11/12 23:30
>>817 はアホだな～
それだと「データ抽象化はOOの一種」になっちゃうだろう。
逆だよ逆（藁
822 ：デフォルトの名無しさん：01/11/12 23:59
オブジェクト指向を理解できないアホが多いな。
俺なんか全てＯＯで書くし。
ＵＭＬはもちろんＸＭＬだって使いこなしてるのさ。
823 ：さすらいプログラマ、旅情編：01/11/13 05:17
「図解でわかるソフトウエア開発のすべて」　経営情報研究会著　より抜粋

　【ソフトウエアの開発は「すっきりと単純に」行うことが大切です。とくに規模
の大きいソフトウエアであるほど、単純なアーキテクチャのほうが、お互いに
設計を理解でき、共同作業するのが楽になります。
『データベースチューニング２５６の法則』（Ｃ．ルースリー、Ｆ，ダグラス
著　間宮あきら訳　日経ＢＰ社　１９９９）によると、『「ソフトウエアが何も
しなくても単純になる」ということはまずあり得ません。むしろ、その逆が正しい
でしょう。単純性は、開発プロセスを通じて大切に育て守っていかなければならな
いものなのです。単純性を明確な目標としない限り、大きなソフトウエアシステム
は開発の段階が進むに連れてより複雑になる傾向があります』と記述されています。
　この「単純性を守っていく」という考えは、筆者自身の経験からも大いにうなずけ
るものです。ソフトウエアの世界では、よく職人芸的なプログラミングに意義を見出
して、凝りに凝った設計、プログラミングをひそかに自慢がいますが、それでは大切
に育てるべき単純性に逆行しています。
すっきりと単純な設計こそ、美しく、効果的なすばらしいソフトウエアなのです。】

ＴＥ試験のシステム管理を春季に受けるために勉強してて、こんな文節があったので
ここに紹介。
この文を見てまず思ったことは、「自分はオブジェクト指向の概念を知らない人に、
わかりやすくはっきりとその概念を伝えることができるだろうか？」っつー疑問ﾀﾞﾀｰﾖ
本当にオブジェクト指向が理解できているのなら、オブジェクト指向のさわりもわから
ないプログラマに、その概念を伝えることができるはずだ。
っていうか、俺本当にoo系が理解できてるのか？って感じた（藁
オブジェクト指向ってさ、理解するのに結構時間かかると思います。少なくとも俺は
１年はかかりました。いや、わかっちまえば楽チンなんだけどね。まー、概念が難しい
つーことは、それを具現化した「プログラミング」は同様に難しいわけで。追っかけ
ねばわからんような継承など、ある意味スパゲッティＰｒｏｇだよな。

本当に効率よく開発したいのであれば、多分プロでの言語習得人口が最も多いと思われる
Ｃが一番いいのかもな。「ＣはできますがＣ＋＋はできません」てのは結構多いけど、
「Ｃ＋＋はできますがＣはできません」て人は見たことが無いっていうのが正直な感想。

プログラムの理想は、「誰でも理解でき、誰でも保守ができ、誰でも拡張ができるソース」
と俺は思っている。上記の理想を遂行する為には、オブジェクト指向の概念（継承、隠蔽、
ポリモルフィズム）を切ってでも設計していくしかないのかなーと一人妄想。

長い長文呼んでくれてthxxx
824 ：さすらいプログラマ、旅情編：01/11/13 05:29
>822
>俺なんか全てＯＯで書くし。

一体何を書くんだか。マスでもカクのか？
寝不足で頭イってるかな・・・氏んできます。
825 ：デフォルトの名無しさん：01/11/13 06:39
>>742

>・反OO派はデータ抽象の利点を認めないのか？

認める。

>・認めるなら、>>351 みたいなコードを自分で毎回書くのか？

書かない。例えば、構造体とそれを操作する関数を別個に用意するだけ。
わざわざ関数のポインタを構造体のメンバーにするのは、
見かけをC++っぽくするだけで無意味に複雑。

>・それくらいならC++やJavaを使った方が良いということがわからないのか？

わかる。だから、そんな馬鹿なことはしない。

逆にOO派に問いたい。
構造体とそれを操作する関数をクラスにまとめただけで、
それをOOPと認めるか？

俺はネット上で散々、「それはOOPではない」と言われ続けてきたぞ。
俺は今でもOOPのつもりだが。
826 ：デフォルトの名無しさん：01/11/13 07:06
>>825
オブジェクトを考えて設計/実装すればOOで、
それらのオブジェクトがソースに表現されていればOOPだ、
なぜなら書く人だけでなく読む人も関係することだから、
ってのが俺的な定義。

だから、コメントその他の付帯的条件にもよるが、
825が言ってるのはOOではあるがOOPではないと思う。
ただし、825のコードがただ単に構造体と操作関数だけでなく
コメントでもいいからそれらがオブジェクトである事が
表現されていれば、それはOOPだと思う。
827 ：　：01/11/13 07:58
>>824

すべてＯＯで。
現在主流な言語に純ＯＯは存在しないので不可能。
smalltalkはそうだったかな？
828 ：デフォルトの名無しさん：01/11/13 08:04
824も意味不明だが、827も頓珍漢なこといってないか？
829 ：デフォルトの名無しさん：01/11/13 08:07
>>825
んじゃ、>>333 みたいなプログラムは書く？
830 ：さすらいプログラマ、旅情編：01/11/13 16:04
構造化もオブジェクト指向も所詮「地方の方言」と同じ事。
ただ、どちらの方言が万人に伝わりやすいか、それが問題だ。
831 ：新米プログラマ：01/11/13 16:30
構造化プログラミングのときもそうだった。
本当に理解しているのならわかるはず・・。
楽したいんですよ。

HELL

って表示したいなら
誰かに作らせたいい。

そしてワシはMAINのところに書くだけ
らくらく。

一番必要なのは人間オブジェクト指向だよ。
・・・意味わかりませんか？？？

ならすべて一人でするんですね。
がんばってください。

わたしは楽したいので・・・

中で何をしているかわからないのは怖いが・・・
それは通常でもソースを読まないとわからないのといっしょですよね？

動きで判断するなら・・・

ただはやりのものはつかわなくても知らないと
はずかしわな・・。

ほらね無理に取り入れると時間がかかる。
頭のいいやつにクラスをつくらせ・・
わしは組み立てるほうがいい・・・・。

メニューからプログラムを呼ぶのもある意味
いっしょのことではないかな・・？

またきますので・・・

反論をまってます。「新米なのでやさしくしてください」
832 ：デフォルトの名無しさん：01/11/13 16:44
>>831
文章が微妙に変です。
833 ：さすらいプログラマ、旅情編：01/11/13 17:58
>831
この文章の本質が汲み取れない漏れは、まだまだ2ch初心者ﾃﾞｽｶ?

831の文章を見て俺が感じた事っていえば、「みんなが楽をしたらどうなるんだろう」
つーことかな。１０人中１０人が「俺も俺も」って言って楽したいなんて言ったら、
多分そのプロジェクトは崩壊する。の下に来る奴でそんな性根の腐った方がいらっ
しゃったら、多分放置ｼﾏｽ。あ、いや、831がサンデープログラマだったら別に関係
ないな。所詮趣味だし。

「楽をするため、地道に努力する」のは認めるが、「楽をするため、人に代替してもらう」
のは、お粗末ｽｷﾞﾏｽ。プロジェクトっていう協力プレイの意味ないじゃん（藁
「プロジェクト」と「協力」の意味をもう一度考え直してみましょう。

って、オブジェクト指向と全然関係ないな。sageだsage
834 ：デフォルトの名無しさん：01/11/13 18:06
>>833
Warning : 既に言葉遊びの域に達しています。
835 ：デフォルトの名無しさん：01/11/13 18:10
>>833
別に人を雇うのもありだと思うが。
836 ：デフォルトの名無しさん：01/11/13 20:14
>>833
ひょっとして部品化とか再利用とかいうOO信者のキーワードを引き出す
戦術？ それともこれらのキーワードを知らない厨房？
837 ：デフォルトの名無しさん：01/11/13 21:01
派遣社員のインスタンスを生成っと。

deleteし忘れるなよ
838 ：デフォルトの名無しさん：01/11/13 21:09
>構造体とそれを操作する関数をクラスにまとめただけで、
>それをOOPと認めるか？
認めないですよ
ポリモーフィズムや
コード管理を含めてOOPです
839 ：デフォルトの名無しさん：01/11/13 21:14
>「Ｃ＋＋はできますがＣはできません」て人は見たことが無いっていうのが正直な感想。
C++知らないのかな？
C++ができる->Cができる
なんだから当たり前でしょ
840 ：デフォルトの名無しさん：01/11/13 21:15
>>838
なんで？
オブジェクト指向の考え方を使った（利用した）プログラミングを
すればＯＯＰじゃないかな
付随したすべての技術をなめる必要はなし
841 ：デフォルトの名無しさん：01/11/13 21:24
>>840
それは、小さいプログラム限定での話でしょうか？
プログラムが小規模な程OOPの効果は薄れる
プログラムが大規模な程OOPの効果は大きくなる
プログラムが大規模な場合ポリモーフィズムを使うのは
当然ですよね？

もちろんif/elseが３つくらいなら
そっちの方が開発効率がいいとは思いますよ
まあ、if/elseが２０個続く時は
当然ポリモーフィズム使いますよね
でもif/elseは通常増える方向で設計しますので
最初からこの部分をポリモーフィズムで書くのは当たり前だと思います
という事で、ポリモーフィズムができないとOOPじゃないですよね？
842 ：sage：01/11/13 21:27
突っ込みどころが多すぎて萎える。>>841
843 ：デフォルトの名無しさん：01/11/13 21:38
めちゃくちゃ簡単にいうと、おれはオブジェクト指向というのは
拡張できるインターフェース
をもつことだと思っている。

だから、インターフェースを持っているのが当たり前な立場から言えば、
拡張できないインターフェースはオブジェクト指向ではないし、
インターフェースが当たり前でない立場から言えば、
インターフェースの導入でオブジェクト指向と言える。
ということで OK ?
late binding を普通に書けないで O-O というのはねー。という抵抗はあるね。
844 ：デフォルトの名無しさん：01/11/13 21:43
>>841
つか、どう多態を誤解しているのか読み解こうとしたけど
それも不可能なほど謎な文章
よって逝ってよし認定
845 ：デフォルトの名無しさん：01/11/13 21:43
多態性がOOの本質とは思えない。
やっぱりデータ抽象がOOの根幹であり第一歩だろう。
846 ：デフォルトの名無しさん：01/11/13 21:47
>>841
polymorphism原理主義者ハケン。
激しく便利な機能だが、使わなければOOPとヨバンというのはどうか。
OOPLが備えるべき機能としては必須としても良いかとは思うが。

ところで >>351 のCコードはpolymorphismと認めるかね？
847 ：さすらいプログラマ、旅情編：01/11/13 21:49
>839
>C++ができる->Cができる

sorry839,CとC++は似てて非なるもの。C == C++ では無い。
848 ：８４０：01/11/13 22:02
>>843
インターフェースとはJavaのinterfaceのことか？
late bindingが多態のすべてじゃないだろ

OOを概念と見るか技術と見るかの違いで、もう議論の接点はない
はぁ、教科書バカとは議論するだけ無駄かな
849 ：デフォルトの名無しさん：01/11/13 22:10
>>841
ＯＯは規模が大き過ぎると使えない。中規模に向いていると別の
信者が言ってたが。
850 ：デフォルトの名無しさん：01/11/13 22:11
漏れはCOMを知ったときOOの神髄を見たと思ったよ
みんなはいつね？
851 ：さすらいプログラマ、旅情編：01/11/13 22:11
ooを技術と見るか概念と見るかってのは難しい問題ｶﾓﾈ

漏れの足りない頭で考えると、ooの概念と技術って

ooA, ooD > 概念
ooP > 技術
ooPL > 別物

かな・・・間違ってるかも。すいませんでした、やっぱ俺ｳﾞｧｶだ
852 ：デフォルトの名無しさん：01/11/13 22:15
ＯＯはキャッチフレーズでしょ。
853 ：デフォルトの名無しさん：01/11/13 22:16
単なるキャッチフレーズにしては洗脳効果が強烈だな。
854 ：デフォルトの名無しさん：01/11/13 22:21
誰か結論をまとめてくれ。
855 ：デフォルトの名無しさん：01/11/13 22:24
>>850
じじいでスマソ
サザンの Smalltalk on PC98 だった
なんでもオブジェクトにできたし、
コードをトレースしていって、衝撃感じたね。
856 ：デフォルトの名無しさん：01/11/13 22:26
まとめてやる。

OOは○○だからダメ。
OOの神髄はつまりコレ。
○○するのがOOなんだな。

こんな事書いてる様ではまだ、部分的にしか理解しきってない。
とりあえず、効果の上がる場面で、適切に使っていればよい。
857 ：デフォルトの名無しさん：01/11/13 22:26
継承は第２のGOTO文ということで。
858 ：８４１：01/11/13 22:27
>late bindingが多態のすべてじゃないだろ
他にあるの？
OOのすべて・・の書き間違いかな？
まあOOの全てじゃないけど、一部だからできないとダメだよね

>>846
関数ポインタ使ってあれこれやるのは実行時ポリモーフィズム
だと思うよ
ただ、コードの書き方が
Java>C++>C
の順で書きやすいって事では？

ちなみにMFCでもJAVAのライブラリーでも
動的バインド使ってないのは、ないよね
そういうわけで、少なくてもOOなライブラリを作るには
ポリモーフィズムが必須ですね
ポリモーフィズムしないのに継承使ってるのもバカっぽいと思いませんか？
virtualが一個もないc++のコード書いてる人は一度Javaをどうぞ

大規模開発にOOが向かないんだ
じゃあ、どうするの？cobolですか？
859 ：デフォルトの名無しさん：01/11/13 22:31
>>858
>ポリモーフィズムしないのに継承使ってるのもバカっぽいと思いませんか？
>virtualが一個もないc++のコード書いてる人は一度Javaをどうぞ

そういう奴はjavaやっても結果は同じだと思うが？(藁
860 ：デフォルトの名無しさん：01/11/13 22:37
(ﾟдﾟ)ｱｲﾀｸﾁｶﾞ....ﾌｶﾞｸﾞｸﾞ >>858
861 ：デフォルトの名無しさん：01/11/13 22:39
>>857
多重継承のこと？それなら違うぞ。
もう一度多重継承を勉強されたし。
862 ：デフォルトの名無しさん：01/11/13 22:40
＞>late bindingが多態のすべてじゃないだろ
＞他にあるの？
そこだけ抜かれてもねぇ・・・
言いたいことはその後の行の方だったのに。

つまり、技術的にはそうかもしれんが、概念的にみたら
多態はis-aの関係を表すのに、より適しているだろ
多態は抽象化を考える上で自然なことだったの
late bindingは後付の副産物だよ

>ポリモーフィズムしないのに継承使ってるのもバカっぽいと思いませんか？
>virtualが一個もないc++のコード書いてる人は一度Javaをどうぞ
結局ただのJava信者でしたか。
JavaをマスターしたぐらいでOOを語らないでね（はぁと

>大規模開発にOOが向かないんだ
>じゃあ、どうするの？cobolですか
世の真実は、システムが複雑になると大規模なんじゃなくて
動くお金が大きいと大規模なんだなぁこれが。
その意味ではCOBOL正解。ABAPなんてのもあるぞ（藁
863 ：デフォルトの名無しさん：01/11/13 22:41
どうでも良いが、俺に関数ポインタを返せ。
864 ：デフォルトの名無しさん：01/11/13 22:44
Javaですらマスターしたとはおもえん。

こんなやつでもOOできる気になれるJavaはたしかにC++よりすごいかモナ（藁
865 ：デフォルトの名無しさん：01/11/13 22:44
継承にしろ、多態にしろ、
使う必要が無い場面で無理やり使わんでもいいだろう。
小さいプログラムなら使わないことが多い。
逆もまた然り。
866 ：８４１：01/11/13 22:58
＞多態はis-aの関係を表すのに、より適しているだろ
多態を何と比べてるの？
俺はif/elseと比べたんだけど・・・
if/elseと比べるのは技術面の話なのかな？
かなり意味わかんないけど、技術面ってなに？
普通比較するのは、現実とじゃない？

>多態は抽象化を考える上で自然なことだったの
プログラミングの話をしてるのかな？
それとも、知識の定式化とかの話をしてるの？

JavaとC++の違いも，オブジェクト指向という点では特に違いないと思うけど
どこか違う？
まさか，多重継承って言わないよね（ｗ
UML知ってればアグリゲーションも理解できるよね
多重継承クラスを多重継承したら、どう転んでも痛いだけ

>JavaをマスターしたぐらいでOOを語らないでね（はぁと
一応C++とschemeくらいは・・・
あと何をマスターしましょうか？

>動くお金が大きいと大規模なんだなぁこれが
間違った解釈ですよ（はぁと
867 ：デフォルトの名無しさん：01/11/13 23:02
841はたたり神になりました
868 ：デフォルトの名無しさん：01/11/13 23:06
触らぬ髪に祟りなし！
869 ：デフォルトの名無しさん：01/11/13 23:25
・多態が強力な一般化・抽象化の手段である。
・多態は静的な型チェックと動的なlate bindingを両立させる。
・late bindingによって実装を隠蔽したままオブジェクト間の組合わせを変え
　る自由度が得られる。
・late bindingによって「インターフェースのみを決めた」プログラミング、
　たとえばさまざまなデザインパターンが可能となる。

…のは確かなんだが、肝心なのは抽象化であって多態やlate bindingはその
手段じゃないかなあ。
870 ：デフォルトの名無しさん：01/11/13 23:27
（実装の）継承の害については概出。>>620 参照。
871 ：デフォルトの名無しさん：01/11/13 23:43
>>869
なるほど
インターフェースが抽象化（）
で，実装がlate binding...なわけね
でも、他に選択肢ってあるの？
866説では当然の結果みたいに書いてあるけど

ところで抽象化＝＝プログラミング
っていう意味でいいのかな？
アカデミックな本にはそう書いてあると思うけど・・・
872 ：デフォルトの名無しさん：01/11/14 00:00
＝＝ってなに？
873 ：デフォルトの名無しさん：01/11/14 00:15
>>896
ごちゃごちゃと、もーいいから、おまえは早く客の要望と実装をbindingしてみろよ
机上の理論を受け売りしていた自分が若かったと気づくからさ
874 ：　：01/11/14 00:17
>>872

比較演算子？
現在イテレータにメロメロっす。
875 ：デフォルトの名無しさん：01/11/14 00:34
>>866>一応C++とschemeくらいは・・・
惜しい！せめて、あとSmalltalkはやってみたほうが良い。

>>869自身が、結構、よく分かってる人みたいなので、
わざわざ、こちらが指摘することでもないが、
これらの意見は、一見、OOの利点に聞こえるが（実際、利点だが…）
この中にある『「インターフェースのみを決めた」プログラミング』が問題。
OOの利点を生かすためには、＜インターフェースのみを先に設計する＞という
前提が必要になるのだが、実際にはこの部分の実践が難しい。
876 ：デフォルトの名無しさん：01/11/14 00:54
>873
神？
877 ：デフォルトの名無しさん：01/11/14 05:59
とにかく偉そうにする奴が多いよな
878 ：新米プログラマ：01/11/14 12:44
おそろしい・・
いっぱいかいてある・・・。
なにからはなして良いかわからん・・。

オブジェクト指向の恩恵は大きいプロジェクトで
をしてみないと実感できませんよ・・。
たぶん・・

今わしはCBLをつかっているので・・。
つかえません。

でもオブジェクト指向の問題点を一つ・・・。

なんでもできるようになるので・・・。
収集がつかなくなるぞ・・。
システムを組むなら・・・
最小限にしましょう。
ってここにいる人らはわかってますから
いらぬおせわか・・（すんまへん）

始めの設計がよかったらそれだけでOKですよ。
あと・・・

注意：ぷろぐらま＝おぶじぇくと

おぶじぇくとにぷろぐらむをたのむのはいいが
とちゅうでの変更はやめてください・・。

ぜんぜんちがうめっそどは発行できません。
ことなるおぶじぇくとにたのんでください。

ところで・・・オブジェクト指向の本当の意味を理解している人
おねがいです。
「ぞうりむしでもわかる説明」をしてくれませんか？

・・・クラス
・・・カプセル化
・・・継承（多重）
・・・・
879 ：デフォルトの名無しさん：01/11/14 12:56
>システムを組むなら・・・最小限にしましょう。

ここから、理解しなおした方が良いＺＯ！
昔は、コボルという言語でユーザの仕様に沿ってシステム開発したのさ。
それで、ユーザが違っても、処理は一緒なので、
ルーチンに処理を全て入れようとなった。肥大化で×。
次にコードジェネレータ。仕様書ツールで設定すると、ガバットコボルコードを吐き出す。
ジェネレートコードは小さくはないし、読み難くて手直し大変。
だけど、このころは、１Ｋステップいくらの時代だったからこれでＯＫだった。
880 ：デフォルトの名無しさん：01/11/14 12:59
次に、C言語で、ルーチンに全ての処理を入れるんでなく、
小さい関数の組み合わせによって、処理を変えようという時代になった。

これは、コボルよりは良かったが、長くは続かなかった。
このころに、ウィンドウシステムが主流になり、
ウィンドウシステムがやたらと多くのAPI（C言語関数みたいなもん）を持ってて、
それ専用のエンジニアが必要になった。
881 ：デフォルトの名無しさん：01/11/14 13:05
で、GUIツールとして、VBがあらわれた。
画面はVB、内部処理はC言語によるDLL関数時代になった。

しかし、GUIツールの能力を超えて処理するには大変、
関数が一杯あったら管理が大変、というところに、Delphiが現れた。

Delphiだと、GUIの処理変更も差分だけ定義、
内部処理も１クラスに閉じ込めて散り散りにならない、
１言語でGUIと内部処理を記述し、混ぜることも出来るようになった。（で第一章完了）
882 ：デフォルトの名無しさん：01/11/14 13:13
補足
・Delphiは、クラスライブラリ系GUIツールね。
差分プログラミングでコードが最小であり、関数と違い振る舞いを変更できる
・第二章続きは他の人書いてＮＥ！反論もＮＥ！
883 ：デフォルトの名無しさん：01/11/14 13:23
おもしろくない。

それにアフガンの何の罪もない人々の命と生活を守ろうという
気持ちがみじんも感じられない。

よって
------------終了-------------------------------
884 ：新米プログラマ：01/11/14 14:27
>ここから、理解しなおした方が良いＺＯ！
しくしく・・。
意味がわからないよ。

VBでいったら

ぺたぺたはるだけで
その機能を実現できるから・・。
なんでもかんでも一つのプログラムでしないほうがいい
って意味なんだけど・・・・。

説明不足でごめんなさい・・。
勘違いしてたらもっとごめなんなさい・・

勉強してきます。では
885 ：デフォルトの名無しさん：01/11/14 14:51
>>883
あんたが一番面白い(w
終了せずにあんたが続けてくれ。ぜひ
886 ：デフォルトの名無しさん：01/11/14 14:59
>>878 >>883
怪文書？
887 ：デフォルトの名無しさん：01/11/14 16:31
システム最小限って、無意味な機能拡張に備えた多態とか多用するな
つーことじゃねーの？
888 ：デフォルトの名無しさん：01/11/15 00:57
YAGNI ですな。
889 ：デフォルトの名無しさん：01/11/15 01:13
９００目前上げ
890 ：デフォルトの名無しさん：01/11/15 04:10
OOは面白いパズルだった
でも、そろそろ新しいパズルが欲しい
891 ：デフォルトの名無しさん：01/11/15 09:37
OOになって、デザインパターンが出てきて、なるほど頭いい人は
こうやってコーディングするのだなあって思った。抽象化された
コアを作り込んで、具象化はなるべく後にする。そうすることで
問題の本質が見えてくるし、コードの再利用も進む。

頭いい人の手法を「再利用」できるようになったことは、OOによ
る恩恵だなあ。構造化プログラミングの時代には、データ構造＋
アルゴリズム＝プログラムだったから、ついついすべてのコード
がそのプログラムで解決したい具体的な問題に「べったり」なも
のになりがちだった。似たような、しかし、ちょっとずつ違うコー
ドを大量に書いた。いつもデバッグばかりしていた。それがOOに
なって、デバッグの済んだコードを再利用するケースが増えてき
た。デザインパターンまで来て、ようやく得られた恩恵だけど。

デザインパターンを知らないでいると、OOなんてちょっと気の利
いた（しかし、けっこう面倒な）モジュール化技術にしか見えな
いだろうな。
892 ：デフォルトの名無しさん：01/11/15 23:36
>>891
はあ・・・・。
893 ：デフォルトの名無しさん：01/11/15 23:41
>>891
あのなー、今みたいにソフトウエア技術の本が一杯出まわる前は
どうやってたか想像してみろや。
それぐらいの事は自分で考え出すの。
最近の若いもんは駄目だな。
本なんかに教えてもらうような権威主義のヘタレばっか。
894 ：デフォルトの名無しさん：01/11/15 23:41
>>892
ゴミレスでageるな。
895 ：デフォルトの名無しさん：01/11/15 23:43
>>893
本に教えてもらうことが権威主義なのか。知らんかったな。
896 ：デフォルトの名無しさん：01/11/15 23:50
>>891
ふぅぅぅぅぅぅぅぅ
897 ：デフォルトの名無しさん：01/11/15 23:51
>>893
想像したくないんすけど。
究極的には、プログラミングなんてしなくてすめば
それに越したことはない。
898 ：デフォルトの名無しさん：01/11/15 23:51
まぁクラスライブラリに頼ってるJavaプログラマは駄目って事だな。
アセンブリに帰るぞ
899 ：デフォルトの名無しさん：01/11/16 00:14
>>893
ユークリッドやピタゴラスから自分で考え出してたら、
楕円暗号や量子計算機まで辿り付くまでに一生終わりそうだね（ｗ
900 ：デフォルトの名無しさん：01/11/16 01:00
>>899
同意。つーか、そんな無駄なことブッコいてるヤツはさっさと首にしろ。
「昔は何でも自分で考えた」だ？ そういう不勉強なアホを雇っとく余裕
があったってことだろ。
901 ：デフォルトの名無しさん：01/11/16 01:09
>>900
今この瞬間も考え出さないといけないの、判ってる？
902 ：デフォルトの名無しさん：01/11/16 01:13
量子計算機ぃーー？？
そんなもんモノになると思ってんのか？
903 ：デフォルトの名無しさん ：01/11/16 01:15
もう良いよ、
俺は田舎に帰って煎餅屋継ぐ事にする。。。。
904 ：デフォルトの名無しさん：01/11/16 01:54
>>902
浦島太郎ハケーン！
905 ：昔の人：01/11/16 02:10
ごみスレ
906 ：デフォルトの名無しさん：01/11/16 02:16
これからはDNA計算機だろ。
907 ：デフォルトの名無しさん：01/11/16 02:33
その前にジョセフソンコンピューターです。
908 ：デフォルトの名無しさん：01/11/16 02:34
たんぱく質分子コンピューターってのもあったな。
909 ：デフォルトの名無しさん：01/11/16 02:36
本命は脳型コンピュータだろ。
910 ：デフォルトの名無しさん：01/11/16 04:25
>>906-909
新たな詐欺師時代の夜明けだ
911 ：デフォルトの名無しさん：01/11/16 16:31
どうでもいいけどJAVAのソースでクラスのコンストラクタをCの関数のように
使ってるソース読んだよ。
Cとの違いは関数呼ぶのにnewするってことだけ(ﾜﾗ
OOPでCのように書くとGOTO使うより悲惨なことになるな。
これを普通のOOの感覚で読むと違和感んじまくったが、
Cの関数＝クラスのコンスラクタ、メンバ関数はコンストラクタで使う関数と
して読んだらすんなり読めたYO（ﾜﾗ 戻り値はpublicなメンバ変数に格納（ﾜﾗ
どうでもいい話だな。ただちょっと悲しかったので、、、sage
912 ：デフォルトの名無しさん：01/11/16 16:36
>>911 日本語変だな 鬱氏。
913 ：デフォルトの名無しさん：01/11/16 16:54
>>911
でもまあ、それでもGCあるだけCよりデバッグ楽じゃん。
914 ：デフォルトの名無しさん：01/11/17 01:07
GCなら昔のベーシックからあったよ。
ユーザープログラムから呼ばないだけ。
別に新発明ではない。
915 ：デフォルトの名無しさん：01/11/17 01:39
>>914
BASICのGCって文字列のやつね。オッソロシク効率悪かったよね。
ちょっとはLispの技術でも学べば良かったのにね．

ところでBASICにはポインタもなけりゃヒープに割り当てるデータも
文字列以外になかったんだから、GC使う方がデバッグしやすいという
話とはあんまり関係ないよ。
916 ：デフォルトの名無しさん：01/11/17 14:07
終焉が見えてまいりました。
917 ：逝って良しの１：01/11/17 14:24
パート２まで行ったら、例の統計のタネ明かしをします。
918 ：デフォルトの名無しさん：01/11/17 14:27
OOを理解できないDQNなプログラマの率に関する統計の資料も出せよ。
919 ：デフォルトの名無しさん：01/11/17 15:18
OOわかってるつもりで実はわかってないプログラマの率もほしいな。

めちゃくちゃ邪魔、つーかゴミ以外の何物でもないんだけど。〈みなさ
んはちゃんとわかってて、こういう人たちと違うと思うけど〉
920 ：デフォルトの名無しさん：01/11/17 15:37
ＯＯは実用レベルで使える人が集まれば、
「私はＯＯ解ってます」
なんて、恥ずかしくて言えないと思われ。
921 ：デフォルトの名無しさん：01/11/17 15:43
分かってるという場合には
どういう時に使えないのかも分かってるもんだよな。
922 ：デフォルトの名無しさん：01/11/17 19:50
>>911 お前まだまし。コストラクトをお前が書いてるように使ってるのは同じなんだが、
オーバーロードコンストラクタによって全く違った振る舞いをする関数作ってる
コードみたことあるか？氏ぬぞ。
同じ名前の関数が渡される仮引数によって全く違った振る舞いをする。
もう恐怖としかいいようがなかった。アレは。
923 ：デフォルトの名無しさん：01/11/17 20:04
>>900
同意。

で、「デザインパターンと同等の方法論なんて、前から自分で考えてたよ」というやつに、それなら
「現在は世間に広まっていない、自分の持っている素晴らしい方法論はないのか？」と聞くと何も
でてこない。
924 ：デフォルトの名無しさん：01/11/17 20:33
1は本気であんなこと書いてるのかな？
世の中広いからなー
925 ：デフォルトの名無しさん：01/11/17 21:38
>>922
Java で static メソッドしかないソース読んだことあるぞ。
new すらない（ｗ
926 ：デフォルトの名無しさん：01/11/17 23:27
今、私は引数が２０個くらいある関数のメンテ中だったりします（泣）

プログラマーってのはレベルの差が激しいですよね
私より１０年以上長くやってるのに・・・・この差はいったいなんでしょうか？
927 ：デフォルトの名無しさん：01/11/17 23:32
>>926
自分が極めたと思った瞬間、そいつの成長は止まってしまう。
つまり、彼の成長は１０年前に既に停止してるんだよ(藁
928 ：デフォルトの名無しさん：01/11/17 23:37
クラスライブラリがないと何もできない駄目プログラマが
このスレでＯＯを擁護してそうだな。
おっと、ＯＯを否定しているわけじゃないよ。
929 ：デフォルトの名無しさん：01/11/17 23:39
>>928
そう思ったら、具体的に番号示さないと盛り上がらんよ。
930 ：デフォルトの名無しさん：01/11/17 23:50
>>928
OOはクラスライブラリ無いとだめですか？
931 ：デフォルトの名無しさん：01/11/17 23:51
あるに越したことはない
932 ：デフォルトの名無しさん：01/11/17 23:54
>>931
まったく無かったらどうですか？
933 ：デフォルトの名無しさん：01/11/17 23:56
kernelしかないOSがあっても使う気にならないだろう？
934 ：デフォルトの名無しさん：01/11/18 00:50
>>933
それじゃあ、C言語は無意味だね（ｗ
935 ：デフォルトの名無しさん：01/11/18 00:55
Ｃはライブラリが全く無くても組めるがJavaはライブラリ頼り。
936 ：デフォルトの名無しさん：01/11/18 01:49
>>935
それとOOは多分関係無いとおもう。
937 ：デフォルトの名無しさん：01/11/18 02:04
いまどき文字列処理を自前で書きたくないよ。
そういうことは暇なやつか、それを商売にしてるやつにまかせるべきだ。
938 ：デフォルトの名無しさん：01/11/18 02:13
ライブラリないったって、フルスクラッチはしないだろ。＞Ｃ
仕事ならなおさら。
939 ：デフォルトの名無しさん：01/11/18 08:37
>>937
既に有るライブラリしか連想できないとは、発想の貧しい奴。
940 ：デフォルトの名無しさん：01/11/18 10:24
>>935
I/Oもいらないと・・・
941 ：デフォルトの名無しさん：01/11/18 10:47
>>935
Cってライブラリ無しでなにができる？printf？
942 ：仕様書無しさん：01/11/18 10:51
>>941
ちょっと待った、stdio もライブラリだろ。
943 ：デフォルトの名無しさん：01/11/18 11:26
インラインアセンブラもＣのうちと認めれば不可能ではないが・・・
少なくとも >935 にはその技術は無い。
944 ：デフォルトの名無しさん：01/11/18 13:24
>>939
だからさ、いままでにないライブラリ作るときも、文字列処理みたいな
基本的な部分はガイシュツのライブラリ使うだろ?
そうすれば「いままでにないライブラリ」という問題領域に集中できるじゃん。
そういう基本的なライブラリがそろってるJavaは幸せだつう話だよ。
945 ：デフォルトの名無しさん：01/11/18 13:28
要するにここでたたかれていたのは
タケノコのようにでてきたJava厨ということでよろしいな？
946 ：デフォルトの名無しさん：01/11/18 13:51
>>926
引数減らす為だけの構造体作るのは素人。
947 ：デフォルトの名無しさん：01/11/18 14:00
>>946
だが引数 20 個渡すようなルーチンを組むのも、素人。
948 ：デフォルトの名無しさん：01/11/18 14:02
>>943
馬鹿ですか？
949 ：デフォルトの名無しさん：01/11/18 14:06
こいつらもついでに叩いてくれよ！
http://pc.2ch.net/test/read.cgi/tech/997074601/
950 ：デフォルトの名無しさん：01/11/18 14:06
CWIN::CreateEXは引数１１個
951 ：デフォルトの名無しさん：01/11/18 14:15
>>947 WinAPI作ったＭＳはかなり素人っていうことでいいな？
952 ：デフォルトの名無しさん：01/11/18 14:17
>>950
どうでもいいが、MFC なら

CWin::CreateEx()

ですね。これもウィンドウのサイズを x, y, nWidth, nHeight ではなく const CRect で渡すバージョンが定義
してあり、そちらでは必須の引数は 7、加えてデフォルト引数が 1。

引数の数が 7 程度ならまだ覚えられる範囲だけど、それを超えると俺はダメだ。過去のコードを Copy &
Paste しないと、やってられん。
953 ：デフォルトの名無しさん：01/11/18 14:22
APIにはもっと多いのがあった気がする。
引数の数だけで能力計っている>>926を甘やかしてはいけません。
954 ：デフォルトの名無しさん：01/11/18 14:23
引数いちいち覚えるのか？
俺は作ったら忘れる。
覚えてなきゃ使えないようなルーチンは組まない。
955 ：デフォルトの名無しさん：01/11/18 14:27
javaのGraphics.drawimageも１１個だが何か？
956 ：デフォルトの名無しさん：01/11/18 14:28
>>951
Win32 API だと、たとえば CreateWindowEx() は引数 12 個で、しかも hMenu は場合によってメニューの
ハンドルや子ウィンドウの識別子など、まったく異なる型のデータを受け渡す。お世辞にも、優れた設計と
は言いがたいね。

しかし引数 10 個越える API って、使用頻度が高い API には、さすがにそれほど多くない気がする。
RegisterClassEx() なんかは、ウィンドウクラスの情報を引数で個別に渡さず WNDCLASSEX 使ってるし。

>>953
そうだね。必要なら 20 個引数ある関数も書かざるを得ないし。ただ、そんな関数が大量にあったら設計が
腐ってるとは思うけど。
957 ：デフォルトの名無しさん：01/11/18 17:27
んー、Java死亡に話題が集まって引きがイマイチだな・・・。
958 ：デフォルトの名無しさん：01/11/18 17:47
>>954
> 引数いちいち覚えるのか？
さすがに覚えていられん。ただ引数が 20 個ある場合でも、引数が全部プリミティブ型だと

　nWidht, nHeight を入れ替えてしまった

みたいなバグがコンパイル時に検出できないから、嫌だなぁ。

ぜんぜんオブジェクト指向と関係ないね。ごめん。
959 ：デフォルトの名無しさん：01/11/20 10:43
１の周囲の環境が極端なだけ。
960 ：デフォルトの名無しさん：01/11/20 11:22
カプセル化マンセー！！
interfaceマンセー！！
ポリモルフィズムマンセー！！
Beanマンセー！！
961 ：デフォルトの名無しさん：01/11/20 12:07
>>951
だって80年代末だよ? ＞Win32API デザインパターンもさすがに
なかったし。MFCも90年代初頭からあるし。

ところでMFCやWTL以外の、サードパーティ製の、ウィンドウ操作を
カプセル化したクラスライブラリってあるの?
962 ：デフォルトの名無しさん：01/11/20 12:30
gtkとかQTとか、昔Borlandの作ってたOWLとかJAVAのSwingとか？
963 ：デフォルトの名無しさん：01/11/20 22:17
>引数減らす為だけの構造体作るのは素人。
どういう意味で言ってるのかわからん。
引数が多くなるって事は
関数の引数に，構造体へのポインタを渡す意味が全くわかってない厨房ですな。
許容範囲は、４つくらいまでだな。
２０個ってのはもう、プログラミング以外の範囲も含めてセンスがないんだろうな。

APIが引数多くなるのは仕方の無い事
なぜなら一番低レベルな関数なわけだから
964 ：961：01/11/20 22:48
>>962
いやそういう余計なものがいっぱいついているものではなくてWin32APIの薄い
ラッパみたいなライブラリという意味なんだけど...
965 ：デフォルトの名無しさん：01/11/20 23:37
＞関数の引数に，構造体へのポインタを渡す意味。
＞許容範囲は、４つくらいまでだな。

減ったと思うのは局部しか見てない厨房。
構造体に値を渡すために全体は増える。
可読性が落ち、煩雑さが増える。
まあ、>>964は構造体でスパゲティでも作ってなさいってこった。
966 ：デフォルトの名無しさん：01/11/21 00:12
>>965
引数の群れをオブジェクトとしてまとめて扱うことによって
また別の側面が見えてくることがある。
やってみるのもひとつの手。
967 ：デフォルトの名無しさん：01/11/23 02:06
>可読性が落ち、煩雑さが増える。
リレーショナルデータベース完全否定派ですか？（笑
例えば，占い関数があったとして、引数に名前、年齢，住所、星座、体重，血液型・・・
が必要だったとした時
Humanってクラスを作った方がよくない？
もちろんHumanってクラスには占い関数には関係ない変数も持ってるだろうね
でも
占う（Human)
って書けたら読みやすいでしょ？

>構造体に値を渡すために全体は増える。
間違った知識だ・・・
もしかして４バイト区切りだから、byte,short使うと無駄が出る
みたいな意味でいってるのかな？（コンパイラのオプションで消せます）
とりあえず、関数に渡す時は左から順番にスタックに積んでいくわけだから・・・
ポインタ４つ積むのと、変数２０個積むのは結構違うよね

２０個の独立した変数を処理するなら
２０個関数作った方がいいんじゃない？
でも，引数２０個って
デフォルト引数とかあったら，使うのが脅威的な難しさだね
968 ：デフォルトの名無しさん：01/11/23 04:48
>引数減らす為だけの構造体作るのは素人。
と異なる場合を言われてもねえ・・・・。
969 ：デフォルトの名無しさん：01/11/23 04:51
>>961
ET++とかダメ？
970 ：961：01/11/23 05:39
>>969
http://www.gup.uni-linz.ac.at:8001/research/debugging/distribution/et++.html
これ? Gammaがかんでいるみたいだけどさすがに古いね...というか
Win32版は無いみたいなんだけどひょっとしてネタ?
971 ：961：01/11/23 05:43
念のため補足しておくと、元々の話はWin32APIの稚拙なデザインなので、Win32API
上に実装された物、しかもWin32APIの煩雑な操作をオブジェクト指向化
した物という意味でのウィンドウライブラリはないのか、って話。
だからJavaのAWTのようなものを期待した話じゃありません。
972 ：デフォルトの名無しさん：01/11/23 07:11
ＡＷＴが先進なのかＹＯ！
973 ：デフォルトの名無しさん：01/11/23 11:42
Swingは楽チン～～♪
974 ：デフォルトの名無しさん：01/11/23 13:50
>>961
自分で書いてしまうのがいいと思いますよ
汎用的なライブラリーは使いにくいですからね

ファイルを扱うのであれば
File file=new File(filename)
であとは
file.read()
file.write(byte)
だけで、シーケンシャルアクセス限定みたいな
クラスを作っておけば、たいていそれですみます
file.write()の引数にインターフェースを付けて
バイト列を生成するのが便利ですね
975 ：デフォルトの名無しさん：01/12/10 00:53
age
976 ：ソフト屋に恨みを持つハード屋：01/12/14 03:30
なんかソフト屋って頭固いヤツばっかりだな。
数十年前の手法(？)でまだ議論してんのかよ。
バグ減らす努力でもしてろ。ｳﾞｫｹ
おめーらバグ出しすぎ。
977 ：　　：01/12/30 12:27
良スレあげ
978 ：　　：01/12/30 12:29
>>976
従来の蓄積を無視してヴァカが言語転換やるからだ。
Ｊａｖａ等の言語転換ブームが無ければ今の半分以下になってたはず。
979 ：デフォルトの名無しさん：01/12/30 12:41
ＯＯスレにハード屋さんって珍しい展開だな～～。
980 ：デフォルトの名無しさん ：01/12/30 12:57
ハードのバグはソフト屋諸君が取ってくれないと困るのだよ
わっはっはっは
981 ：デフォルトの名無しさん：01/12/30 13:06
ぢゃあ、COBOLでやればバグ発生率はひくくなるの？
982 ：デフォルトの名無しさん：01/12/30 13:12
>>981
ちゃんと読め。おまえJavaってとこしか見てないだろ。
983 ：デフォルトの名無しさん：
従来の蓄積って事なら歴史がながいぶん、
FortranとかのほうがCよりも多いとおもうが。