2 ：
逝って良しの１：02/07/30 08:09
＠カレー
必要。
OOﾏﾝｾｰ
>>1 つか、ちゃんとラジオ体操には行って来たか?
宿題は涼しい午前中にやっとけよ。
ソフトウェア開発方法論がここ十年でこれほど進歩したにも関わらず
ラジオ体操は数十年前から全く進化しないのはいかがなものか？
封印された幻のラジオ体操第3はどうですか？
8 ：
逝って良しの１：02/07/30 09:12
ラジオ体操はあれで完成されているのです。
下手にいじると故障や病気になる人が出てきます。
9 ：
逝って良しの１：02/07/30 09:14
再利用可能モジュールってのはそれなりのセンスと経験を持った人でないと
創れない。
素人がＯＯＰＬ使えたからと言って出来るようになるものではない。
手間をかけて再利用可能になるように設計したモジュールを、
自分の手でゼロから書き直すはめになった経験がなんどもある。
>>9 再利用と OO とは関係ないだろ
Delphiでコンポーネントとか自作して当然再利用してるが、
自分ではオブジェクト指向してるとは思わない。
あくまでもOO言語を便利に使っているだけ
OO言語の機能は便利で使うが、オブジェクト指向はキライ
12 ：
デフォルトの名無しさん：02/07/30 15:56
オブジェクト指向が理解出来ずに「必要なし」なんて逝ってる
バカがプロジェクトを戦場にしてるんだ。
それどころか凝集度・結合度すら理解していない奴ら。
ローカル変数や関数すら分からない奴ら。
ろくな設計をしなかったために、テスト段階になって火が噴いて
挙げ句の果てに「やっぱり設計に時間をかけられない」なんて逝ってる奴ら。
>>12 そういう奴は は OOがどうとか設計前の打ち合わせで言ってる奴に多いな
本スレはスパイラル開発されております。
約 200 レスごとに 1 イテレーションです。
もしかして「逝って良しの１」ドリブンですか？
16 ：
デフォルトの名無しさん：02/07/30 21:10
違うと思うけど。
クラス作ったほうが、時流に乗ってるって感じ？
それがいいんだよねー。
で、みようみまねでBuilderパターン適用して作っちゃうとか。
こんなカスなことができるオブジェクト指向が大好き！
可哀想な人がたくさんいるね。
オブジェクト指向も罪なもんだ。
19 ：
デフォルトの名無しさん：02/07/30 22:44
ネタニマジレスで申し訳ない無いんだけど、
>私の独自の調査においては、OOで開発すると効率が悪く
>バグコードが侵入しやすい傾向があるという調査結果が出ています。
この調査の詳細が知りたい。
仕事でオブジェクト指向やC++なんて何のメリットもない、って人はかなりいるんだけど、
そういう人ってその理由を論理的に説明してくれない（できない？）から、
OOマンセーな僕としては、是非その詳細を知りたいのです。
20 ：
逝って良しの１：02/07/30 22:46
11 名前：デフォルトの名無しさん ：02/07/30 09:30
>>9 再利用と OO とは関係ないだろ
ヽ(｀Д´)ﾉ ｻﾗｼｱｹﾞﾀﾞﾞｺﾞﾙｱ
糞PGは OO で開発してなくとも糞コード書くから糞PGなわけで
オブジェクト指向が戦場で必要ないかどうかよりも
糞PGをまず先に何とかして
22 ：
逝って良しの１：02/07/30 23:14
そうです。
Ｃでダメダメだった奴は時流に乗ってＯＯで１発スターダムにのし上がろうと
しても無駄という事です。
ＢＡＳＩＣでダメダメだった奴はＣでもダメダメだったし、
Ｃでダメダメだった奴はＯＯＰＬでもダメダメ。
「そうか！俺がダメなんじゃなくてＧＯＴＯが悪かったんだ！」
なんて言語のせいにしてる時点でだめ。
>>19 >仕事でオブジェクト指向やC++なんて何のメリットもない、って人はかなりいるんだけど
>そういう人ってその理由を論理的に説明してくれない（できない？）から、
「悪魔の証明」だもの。あたりまえだろ。
>>19 > 仕事でオブジェクト指向やC++なんて何のメリットもない、って人はかなりいるんだけど、
> そういう人ってその理由を論理的に説明してくれない（できない？）から、
> OOマンセーな僕としては、是非その詳細を知りたいのです。
例えば、サイクリングや山登りをチームで行ったとしましょう。
その場合、チームの速度はチームの中で一番遅い人の速度になります。
プログラミングもチームで開発を行う場合はチームの中で
一番スキルの低い人にあわせる必要があります。
そして、他の方法よりもオブジェクト指向やC++はスキルが必要です。
もし、そのチームが全員オブジェクト指向やC++を理解していない場合、
メリットよりもデメリットの方が高いです。
25 ：
デフォルトの名無しさん：02/07/31 11:10
>>24 そういう時の正解は、ヘタレを切ること。プロジェクト管理の鉄則だな。
>>24 そんな必要はないよ。
俺は技能が低い奴が混じっていたら スクリプト作ってスクリプト触らせてる。
OOが好きとかいう奴にはOO風スクリプトにして満足させてやってる
>>25 技能に応じた仕事をさせて責任と報酬をバランスするのがプロジェクト管理の鉄則だよ
>>26 大抵の場合、報酬はプロジェクト管理の埒外で決められているという罠。
>>25 > そういう時の正解は、ヘタレを切ること。プロジェクト管理の鉄則だな。
君のプロジェクト管理は楽そうでいいね。
で、人数が不足した場合、どうするの？
ようするに、プロジェクトで一斉に同じ山を登らせるのは馬鹿のやる事で
それぞれに山を設定して、それぞれの山に同じ時期に到着出来るように
配分してやれって事だな
>>28 まあ、オチケツ。
「人月の神話」を持ち出すまでもなく、ヘタレがいるとマトモな奴等の負担になるんよ。
ヘタレを外して結果として人数が足りなくなるのなら、ヘタレがいたらもっと人数が足りなくなる罠。
そんぐらいなら少数精鋭でやったほうが傷が少なくてすみぞ。
>>30 > そんぐらいなら少数精鋭でやったほうが傷が少なくてすみぞ。
それはチーム人数に対し、ヘタレの人数が十分に少ない場合、
例えばチームのほとんど全員がヘタレだった場合、どうするんだい？
尻尾をまいて逃げるが君の正解かい？
32 ：
デフォルトの名無しさん：02/07/31 13:11
>>31 チームのほとんど全員がヘタレなのに爆進し続けてデスマーチにするのが得意な人ですか？
33 ：
デフォルトの名無しさん：02/07/31 13:16
>一番スキルの低い人にあわせる必要があります。
ありませんよ。
だって切ればいいだけのことですもの。
>>32 マトモなプログラマは一人いればいい。 残りはそのサポートに回る体制を作れ
>>33 > だって切ればいいだけのことですもの
そして誰もいなくなった．．．
>>35 それで誰もいなくなるような所なら、なくなってしまったほうがマシ。
>>34 サポート役をサポートするためにそのマトモなプログラマの労力が割かれてしまう罠
>>36 > それで誰もいなくなるような所なら、なくなってしまったほうがマシ。
チームが存在すれば各人のスキルには差があるのは当然。
スキルが一番低い奴を切っても、次に低かった奴が１番低い奴になるだけ、
スキルが低い奴を切ってもやはりチームにはスキルが低い奴がいる。
そんなこともわからんの？最近の学生って
39 ：
デフォルトの名無しさん：02/07/31 13:48
＞実際は世の中にどれだけの糞SEや糞PGがいることか。。。
能力ないのに、気張るＤＱＮＰＧはあかんが、
正直な話し、マトモＰＧが沢山いたら、日本はサブイよ。
ＰＧ職人に傾向すればするほど、精神面が働かなくなるのだ。人間味が無くなる。
現実は、スキルが低いから駄目なのではく、やっぱり適性があわないのだと思うよ
オブジェクト指向は「一つの方法」であって、「全て」であったりメインではない。
それが判らずに、先にオブジェクト指向ありきな人はやっぱり普通のチーム開発の適性がない。
単にオブジェクト指向なプロジェクトのチーム開発で歯車として巧く動けた
というスキルがあったとしても、やっぱりプログラマとしては適性が無いのだと思うよ
もちろん、全員が同じツールを使う方法としてはオブジェクト指向に見るべき面がある。
しかし、能力差がある現実を埋める方法としては
VC+VBとか、onVBAとか、
>>26のいうonスクリプトとかがやっぱり優れているよ
>>38 君は相対評価でしか人の技量を測れないのか？
まあ学生のうちはそれでもいいのかもしれんが、
社会人になったら使える人間と使えない人間をちゃんと区別できるようにならないとね。
>>41 > 社会人になったら使える人間と使えない人間をちゃんと区別できるようにならないとね。
取りあえず、読解力の無い人間は使えない人間に区別した方がいいね。
>>42 そうだね、
>>38の読解力の低さは目に余る。おそらく真っ先に切られる人間だろうな。
まあ、
>>38にもきっと自分にあった職種がみつかるでしょ。ソープの呼び込みとか(藁
まあもし切るとしたら 仕事出来ない奴より 人間性に問題ある方だな
人間がまともなら、出来る仕事させればいいんだからさ
>>42 > そうだね、
>>38の読解力の低さは目に余る。おそらく真っ先に切られる人間だろうな。
> まあ、
>>38にもきっと自分にあった職種がみつかるでしょ。ソープの呼び込みとか(藁
ちなみに社会性の低い人間は使える人間だと思いますか？
>>44 俺なら仕事出来ない奴をいつまでもプロジェクトに入れておくぐらいなら
人間性に問題があってもちゃんと仕事できる奴を残すな。
情実に流されて編成すると、全員不幸になるよ。
それぐらいなら人間性があるけど仕事できない奴は早目に見切りをつけてあげるのがお互いのため。
切られた奴も、人間性はあるんならいつか自分にあった職種がみつかるだろ。
ちゃんと仕事できる奴の人間性は問題になどしないよ
ただし、こんな所で簡単にフレーム起こすような奴は、ちゃんと仕事出来る筈がない。
そういう奴は、条件によって仕事出来るだけの奴
48 ：
デフォルトの名無しさん：02/07/31 16:35
a
49 ：
デストラクター：02/07/31 20:25
オブジェクト指向についてべらべらしゃべる日本人（SE、講師）
で実際の開発経験があるやつなんているの？
>>49 そりゃなかにはいるでしょ
全く使えない手法ではないんだし、ただペラペラしゃべるうちに、万能的に昇格してしまうだけで
51 ：
デフォルトの名無しさん：02/07/31 20:51
>49
あれは、肩書き大卒が生活する手段なんだから、あまりつっこんじゃダメ！
戦場（戦術）＝実装・デバッグ
とした場合クラス設計までが戦略にはいるかいな。
戦略が間違っていたら戦術が修羅場になるのは当たりまえで、
別にＯＯ自体の問題ではない罠。
クラス設計を戦場で見なおさないとしたら、戦略ミスということかな。
53 ：
デフォルトの名無しさん：02/07/31 21:17
OO設計で作って便利なのは自分だけという罠。
クビになる奴には漏れが後にメンテナンスする羽目になる
ためぜひフラットに作っていただきたい。
速度の遅い奴は仕事量を減らせば良いような気が。
もちろん報酬もね。募集かければすぐ人材が来るような環境
がうらやましいね。
55 ：
デフォルトの名無しさん：02/07/31 21:51
>>54 札幌か？
Javaマスターとかやってる割には
まともにできるやつがいねーよ。
OO＝再利用可能っていう幻想はまだあるの？
再利用可能なのはコンテナ・GUI部品とか抽象度の高い物だけ。
現実のコーディングで抽象度が高い部分はほんの一部。
まー漏れはライブラリ->00, 実際のコード->構造化って使い分けてるけどね。
57 ：
デフォルトの名無しさん：02/07/31 22:20
札幌？
58 ：
デフォルトの名無しさん：02/07/31 22:34
>>49 開発できないからオブジェクト指向やっていんだから
あまりつっこんじゃだめ
おまえらやかましい。
とりあえず俺は継承がしたいのだ。
>>47 はあ？2ちゃんで何いってんだか…
煽りにもなってないよりは、ちゃんと煽りになってるほうが遥かにマシだろ(藁
おまえらやかましい。
デザインパターンはまだまだ先の話じゃ馬鹿
63 ：
逝って良しの１：02/08/01 09:33
64 ：
デフォルトの名無しさん：02/08/01 10:23
オブジェクト指向はあまりモノにならず腐り落ちるに100万オブジェ
俺はオブジェクト指向は読みやすいコードが出来ると思う。
だから今後俺しかさわらないと思われるコード（趣味）はclass使わないでやって、
ソース出す時にはclass使ってる。
とりあえず、必要な時だけ使えばいい物なのに
常に使えって言う奴も全く使えないっていう奴もバカじゃねーか？
66 ：
デフォルトの名無しさん：02/08/01 12:02
>>65 まあね、それはいえてるな。
dirty hackで済ませたい所はわざわざclassにする必要はないし、
きちんと形を整えておきたい部分はclassにしたほうがいい。
まあ、俺っちの場合は趣味のコードもclassにするけどね。
もっともこれはそれこそ個人の趣味の問題だから、どうでもいいけど。
67 ：
デフォルトの名無しさん：02/08/01 12:14
実際の開発経験なんかしないのにオブジェクト指向のわだいつくるなボケ！
ここで必要なしと言ってるオブジェクト指向は
オブジェクト指向言語を使う事ではなく、 オブジェクト指向設計の事
俺も class 使うけど、それはあくまでも 便利な機能として使うのであって
オブジェクトを志向などしてるつもりは全くない。
69 ：
デフォルトの名無しさん：02/08/01 12:34
>>68 オブジェクト指向言語のどんな所が便利？
その便利さを生かすためにはどんな設計(脳内設計も可)がいいと思う？
>>68 禿同。指向してしまうと宗教入ってくるし。
あまり拘ると生産性逆に落ちるのに。
>>69 クラスは構造体より少し便利だね。コンストラクタが書けるのが特にね
継承も便利だね。
隠蔽は特に便利と思わないな。
設計は普通に構造化で設計してるよ。 トップダウン＋ボトムアップでね
72 ：
デフォルトの名無しさん：02/08/01 14:05
>>71 クラスは構造体よりもどんな所が便利？
コンストラクタも単体では構造体の初期化関数と一緒でしょ？
メソッドは書かないの？
まあコンストラクタだけじゃ確かに意味ないね。
構造体ポインタを返す関数と一緒といえば一緒だから。
例外とペアで初めて便利になったって事だな
そりゃクラスを使うんだからメソッドも書くし、virtual にもするよ。
構造体で関数ポインタのメンバ持つよりは楽だからさ
74 ：
デフォルトの名無しさん：02/08/01 14:30
>>73 まあ、構造体に関数ポインタ持つと、その構造体の実体ごとにポインタ分のメモリ消費されるからね。
でも、それだけなら構造体とは別にその構造体を操作するための関数書いても同じだよね。
丁度、CのFILE構造体をfopen(), fread(), fclose()等で操作するみたいにさ。
でも、わざわざvirtualにすると何が嬉しいの？
単純な関数呼び出しよりもvtable参照する分だけ遅いよね、virtualにすると。
ひょっとしてpolymorphismなんていうOO臭い事してるわけ？
あと、例外とペアでというけど、普通に関数内で例外を受けるのと何が違うの？
それがオブジェクトのメンバ関数だと何が嬉しいの？
ひょっとして状態をオブジェクト毎に設計してるなんていうOO臭い事してる？
>>74 そうOO臭い事してる。
でもそれだけじゃオブジェクト指向設計じゃないよ
Cのfopen/freadやqsortと同じレベルの構造化設計をOO言語でやってるだけ
だってオブジェクト分析してないもの
「オブジェクト指向型ソフトウェア開発のメリットとデメリットについて」
今レポートを書いてます。
皆様意見をお寄せください！
78 ：
デフォルトの名無しさん：02/08/01 15:02
>>75 でも継承と多態は使ってるわけでしょ？わざわざvirtualにしてまで。
その時点で構造化設計の埒外に出てると思うけど。
つまり、少なくとも脳内ではオブジェクト分析の少なくとも一部はやっていると思うよ。
それが本に書いてある方法論の通りでなくてもね。
逆に本に書いてある通りに分析・設計をやってる人って、本当にわかってるとは思えないんだよね。
方法論ってのはプロジェクト毎に改良したり作り直したりするもんだと思うよ。
たぶん君はそれを脳内でやっていると思われ。
79 ：
デフォルトの名無しさん：02/08/01 15:58
あと10年後にはオブジェクト指向は開発者の思い出となるでしょう。
良質なプログラミングは、99%の汗と1%のコーヒーで成り立っている
>>78 なんか新手の勧誘で、ちょっと気持ちE・・・あわわ その手は桑名の焼きハマグリ
大丈夫、「キミのコードはオブジェクト指向じゃない」って言われてるから間違いなくそうじゃない
まず、継承と多態を使えば構造化設計の埒外ってのはどうかと思う。
オブジェクト＝機能＋データ を主眼に設計するのがオブジェクト指向だろ？
継承も多態も機能の表現方法にすぎない
＞オブジェクト＝機能＋データ
ふりだしに戻ってるし・・・
たとえば
ttp://www.s34.co.jp/cpptechdoc/article/oo/ >これまでのプログラミング言語では、あるシステムを記述していく場合、
>いわば何もない状態から始めなければなりませんでした
とか
>たとえばデータベースの場合、最初にデータのフォーマットを決めてし
>まったとします。そのデータ構造にアクセスするような仕組みを今まで
>のソフトウェア・システムで書いたとすると、そのカラム数を変えたくなっ
>たときに、その部分を変更すると、そのデータをアクセスしているソフト
>ウェアをすべて書き換えなければならなくなりました。
とか
あまりにもお馬鹿な・・・こんなのが蔓延してるからイヤンだよ
構造化分析や構造化設計をしている奴なんて本当にいるのか？
分析/設計結果が本当に構造化になっているのかよく考えてみろ。
構造化分析はやってられないだろうけど
構造化設計は
簡単に言うとトップダウンやボトムアップを使って小さな構造の集合として大きなプログラムを作りましょうという事
だから普通に使ってるのでは？
88 ：
デフォルトの名無しさん：02/08/01 18:06
>>81 ちぇ、しくじったか(藁
ところで、継承や多態も機能の実現形態だというのは、まあそれならそれでいいけど、
構造化分析/設計では継承や多態をどう表現するの？
とりあえず表現できないことには分析も設計もやりようがないよね。
>>88 多態であっても手続きにすぎないよ
単に機能を分解して小さくした機能のうちの一つにすぎない
それが表現出来ないなんていえば、関数ポインタさえ表現出来ない事になってしまう
差分コーデングは構造化設計手法での表現は難しいけどね
90 ：
デフォルトの名無しさん：02/08/01 18:35
>>89 いや、だから多態ということは、扱うデータによって実際に使われる手続きがかわるでしょ？
で、その使われる手続きの候補は関数内で閉じる構造化と違って、その関数の外に後からどんどん足していけるわけよ。
classを継承したらoverrideするかもしれないし、そのまま使い回されるかもしれない。
これを構造化設計で的確に表現できる？
多態だって所詮は場合分け。
ＯＯだろうがそうじゃなかろうが、操作の対象の種類によって動作が違う
場合は、それぞれの動作を定義しなくちゃいけないのは同じ。
ただ、ＯＯの場合は、デフォルトの動作を定義出来るのがらくちんだし、
間違いが少ない、ってことだろ？
ＯＯをマメにやっていると自分のコーディングの履歴がクラス単位で系統化される。
のもメリットの一つだと思うんだけど。ただ昔の設計は今見ると赤面ものだったりする罠。
可読性が高く使えるクラスなら喜んで使わせてくださいな。という感じ。
93 ：
デフォルトの名無しさん：02/08/01 19:11
>>91 いや、構造化設計では手続きの中で分岐しているのが根本でしょ。
だからこそ多重ネストして構造化するわけで。
ところが多態の場合は、その手続きの外で分岐している。
しかもその分岐先は不定で、いつでも追加できる。
よって、いつまでたってもその「分岐」は定義できないわけよ。
もしその「確定できない分岐」を仮想的な手続きで囲んでしまうと、
その手続きはいつまでも定義できない。
これは構造化設計では致命的な問題でしょ。
>>93 なんで？ 構造化設計で 関数ポインタ使うのと同じで全然問題ないよ
トップダウン設計の時には「ここにこんな処理する」って書いておいて
その部分の実装は後で考える事にする。 そこは仮想というか非常に大まかなイメージね
そして、ボトムアップで必要そうなそれぞれの手続きを組んでみて、
ああ、この部分の詳細は関数ポインタか多態でいいな って間に入れてゆくだけ
なんで致命的とか思うわけ？
95 ：
デフォルトの名無しさん：02/08/01 20:11
>>94 ええ？それじゃあトップダウンの時とボトムアップの時で手続きの実体が別々になっちゃうでしょ。
別々どころか1対他対応だよ、それじゃ。粒度も違うし。
トレーサビリティが低すぎないか、それ？
そもそも、それではどの機能がどの機能を利用して実装するのか全然明かにならないじゃん。
>>93 メソッド探索のアルゴリズムはフローチャートでかける。
それで十分だろ？
おまえらやかましい。いまいち継承したときの動作の
細かい部分がわからん。
98 ：
デフォルトの名無しさん：02/08/01 20:17
>>95の続き
というわけで、やっぱり君は構造化設計とOO言語の間の溝を
脳内設計で埋めているんだよ、きっと。
さっさと改宗しなされや (藁
ﾎﾟｶｰﾝ、っと。
100 ：
デフォルトの名無しさん：02/08/01 20:19
>>96 その勢いでOO言語処理系の設計をしてしまいなさい。
きっと幸せになれます。(藁
「 」、John、81=逝って（略 の後継登場？
継承するとスーパクラスのプライベート変数はどうなるの？
というか、なんていえばよいのだか！
ya!
なんだかわかってきたぁ。
protectedで解決できたが、それで良かったのだか・・・。
ﾑﾌﾑﾌ
104 ：
逝って良しの１：02/08/02 01:31
全部publicで問題ないだろ？
ドロボーに取られる訳じゃ無し。
105 ：
デフォルトの名無しさん：02/08/02 02:49
>>104 いや、時々ドロボーみたいな糞PGが勝手に代入して壊したり、
一時データを勝手に取っていって本物を参照するのを怠けたりして、
困ったことになります。
「くそっ！やられた。」
「どうした？」
「publicメンバだよ！ドロボーに盗られた！」
「バカだなー。ちゃんと変数にはアクセス関数つけろっていつも言ってるだろ。」
「しかしよー。パンダの名前なんか欲しがる奴なんていないと思ったんだよ。」
「・・・お前、何作ってたんだ？」
public変数ふたつ作って、片方に嘘いれとくってのはどうかな・・
だから 耐火金庫じゃだめだっていったろ！ 防盗金庫くらい買えよ！
変数全部publicにして、
privateな自分と同じ型の変数を一つ持っておく。
で、public変数は全部ダミーで、privateなオブジェクトに本当の値を入れておく。
publicな値はいくら盗まれても書き換えられても平気！
>>109先生
その程度じゃ火を噴いたプロジェクトで延焼せずにすむだけ
Cでvoid 型で渡して実体を触り難くしてるのと同じ程度じゃないかい？
防盗にするには、それだけじゃ駄目 最低暗号化しないとさ
>>110 暗号化しても代入で上書きされてあぼーんの罠。
とりあえずROMにでも焼いとけや。
public class A {
public String 重要な変数;
public String 人に知られてはマズイ変数;
public int 書き換えちゃダメ;
private A バカめこっちが本物だ = new A();
public static void main(String[] args) { new A(); }
}
>>112 すみません、その「バカめこっちが本物だ」はどうやって利用するのでしょう？
見たところアクセサどころか、その変数への参照が全くないようですが…
心の目で見るのじゃ
ヨーダ：ポインタじゃ、ポインタを使うのじゃ。
プライバシーなど幻想でしかない
プライバシーは暴露されるためにある。
118 ：
デフォルトの名無しさん：02/08/02 16:02
visitorパターン
再起か・・・。
121 ：
逝って良しの１：02/08/02 21:57
なあ、なんで一つのクラスを大勢で突つき回すような設計にするんだ？
Chain of Responsibilityパターンなんだけど、
これってどんなときにも使える物じゃないよな
forを除去してこれを使えって言われるんだけど、
ネストが数万回になってスタックを喰いまくるので、
やっぱりforで回しちゃうんだけど。
スタックを喰わないうまい方法ってあるの？
ちなみに、C++(gcc/vc)です
123 ：
逝って良しの１：02/08/02 22:23
124 ：
デフォルトの名無しさん：02/08/02 23:02
（;´Д｀）ﾊｧﾊｧ・・・
（;´Д｀）ﾊｧﾊｧ ﾊｧﾊｧ ﾊｧﾊｧ・・・
また戦車不要論ですか？
>>63 >>65 なぜすべてをクラスにする必要があるか分からなければ
オブジェクト指向もデザパタも永遠に謎のまま(藁
131 ：
逝って良しの１：02/08/03 01:33
132 ：
逝って良しの１：02/08/03 01:34
アプリケーションのメインのクラス（なんて言うのか知らんが）
をクラスにする理由なんてあるのか？
アプリケーションに関する情報をまとめられるとか。
感情論全開の電波コテハンスレ認定
別にクラスでなくても何とかなるけど(例えばC++)、
・クラスにしても困らない
・ルールは少ないほうが良いので、世の中すべからくオブジェクト（＝クラスがある）にしたほうがよい
>>135 だから、そうしたとしてもさ、
それ使うだけではオブジェクト指向してる事にならないんだよ
・・・とＯＯマンセー厨はのたまうんだよ。
137 ：
デフォルトの名無しさん：02/08/03 13:23
>>136 もし
>>135が言うようなOO言語で実装したら、それだけで十分OOしてると思うがな。
もちろん、OO的にいい造りをしてるかどうかは別として。
おまえらやかましい。
VB.NETのデザパタサイト教えろ。
>>130 > なぜすべてをクラスにする必要があるか分からなければ
先生！
Javaのmathクラスをクラスにする必要がわからないです。
これってどう見てもオブジェクトじゃないですよね。
C++で同様の処理を行う関数群はクラスを使って無いですよね？
全ての概念をクラスやオブジェクトで無理に表現しようとすると
その本質を見失ってしまいませんか？
namespace
141 ：
デフォルトの名無しさん：02/08/03 13:48
>>139 ちなみにSmalltalkでは整数も浮動小数点数も分数もオブジェクトです。
ちなみにRubyでは制御構造もオブジェクトらしい。ﾁｮﾄﾋﾞﾋﾞｯﾀ
名前欄に停止&rf&rusi&ran&ras&ran
>>142 Smalltalkでも制御構造はオブジェクト
Lispの場合、制御構造は式で表現する
C/COBOLなど手続き型の場合、制御構造は文で表現する。
で、JavaやC++は結局、手続き型の土台の上にオブジェクト指向
を乗せているだけなのでJava/C++などの言語で「完全な」OO指向は無理
また、現実世界は全ての概念をOOでは表現できない。
OO信者はその現実を知ろうとしない。
すべてをOOで表現しても別に不都合はない、って事じゃないの？
OOってかObjectな。
それじゃあさ
1辺の長さ x , y の長方形に接して収まる楕円の周長を求めよ
てな問題をＯＯで表現してみろよ。
判で押したように
「そういう問題をＯＯで解こうとするのが馬鹿って」答えるぞ
そんな奴いるの？
public class Mondai {
final String text;
public Mondai(String text) {
this.text = text;
}
}
Mondai mondai = new Mondai("1辺の長さ x , y の長方形に接して収まる楕円の周長を求めよ");
(´ー`)y-~~
150 ：
デフォルトの名無しさん：02/08/03 14:41
>>147 とりあえず近似式はあるわけだから、
楕円オブジェクトのメソッドに引数として必要な精度を渡してやって、
あとは近似式に精度に応じて適用していくだけだろ。
>>147 クラス抽出の格好の例題になりそうに思うが。
>>147 あ、そうそう、楕円のインスタンス生成クラスメソッドで
「この長方形に内接する楕円」なんてのがあってもいいね。
もちろん、xとyから生成してやってもいいんだけど。(中心のデフォルト値は原点にして)
あと、OO信者ってデザインパターンを崇拝しているけど、滑稽だね。
良くある概念を簡潔に表現できないから
ある定石で冗長に表現したのがデザインパターン。
要するにOOが使いにくい証拠品。
例えばTemplate Method
C++の場合、このデザインパターンを用いなくとも言語仕様でTemplate
を表現することができ、
C++のTemplateの方が余計なクラスを定義しなくともよい。
OOPLでは無い言語で多態を表現する場合、冗長になることはいやがるのに、
OOでデザインパターンのような冗長な表現を嫌がらないのは何故？
構造化設計なら
○任意精度の楕円の周長は定積分で求めるのが一番効率がいい という情報から
楕円の周長を求める
円と対比させる
円を分割してゆく
外接多角形と内接多角形の周長を求める
その差が希望する精度以下ならＯＫ
というような手続きに落とす分析がすぐに出来るぞ！
ＯＯでどうするんだ？
155 ：
デフォルトの名無しさん：02/08/03 14:58
楕円の前に形オブジェクトを考えて、ああしてこうして(^^;
>>155 いや欲しいのは楕円の周長だけなんだけど？
>>154で考えるとして、この一連の手続きを一つのメソッドにするのではダメなの？
単に分析が下手なだけとは違う？
よくもまぁ、飽きずに繰り返すもんだ…
判をおしたように、って、それが正解だからでしょ。
ＯＯじゃなくちゃできない解決方法を要求してＯＯを否定しるのは
反ＯＯ厨のヤリクチだろ。
ま、ムキになってＯＯ的解決方法を探そうとするやつは、それ以下だけどな。
あ、おれ？素直にみとめるよ。
「ＯＯじゃなくちゃ出来ないやりかた」なんて、無いよ。
結局 OOは構造化設計では対処出来ない程大きなプロジェクトで威力を発揮するって建前で
だからこういう構造化設計の範疇は苦手という逃げ口なんだよね
円 円a = new 円(半径);
for(n = 3; ; n++) {
多角形 内接n角形 = 多角形.内接多角形of円(円a, n);
多角形 外接n角形 = 多角形.外接多角形of円(円a, n);
double 周長の差 = 外接n角形.周長() - 内接n角形.周長();
if (周長の差 < 希望する精度) {
return (外接n角形.周長() + 内接n角形.周長()) / 2;
}
}
かな？
こんな狭い範囲のコーディングでOOだ手続き型だなんて言っても意味ないと思うんだが・・・
つまりは、構造化設計とOO設計は背反する概念じゃないのに
構造化設計は古いとかさ
>>83 のサイトみたいに 訳の判らん事言う奴がいるから駄目なんだよ
実際、クラスライブラリは使う。しかし、設計は構造化設計でホントに十分
に効率的に仕事は出来る。
そして、その仕事の成果をコンポーネント化してゆくという単純なやり方の
方が 最初からOO分析、OO設計を持ち出すより、効率がいい
おい、円の円周の長さを構造化設計でやってみろよ。
円周を求めるのに構造化設計なんかいらないから
構造化設計なんてする必要ないぞ。
と言っているように思える。
>>163 構造化設計なら、円周の長さを求める手続きやブロックを作るだろう？
それは例えば
L=2*π*r;
というブロックだったり double CircleLen(double r){ return 2*M_PI*r;};
という関数だったりするわけだ
もちろんOO設計でも、それは同じだ。 つまり、OO設計はある時点からは
構造化設計に移行しなければいけない。
それなのに、それが判ってないOO厨が多すぎるという事が問題なのよ
ブロックをオブジェクトと考える。
147はつまり大して内容の無いことを声高に叫んでいるのか。
>それなのに、それが判ってないOO厨が多すぎるという事が問題なのよ
お前の勘違い
或いは確信犯に釣られてるとかな。
ありゃ。愉快犯？
>>167 OO厨が多いのかは不明ですが、
少なくとも
>>130の発言
> なぜすべてをクラスにする必要があるか分からなければ
> オブジェクト指向もデザパタも永遠に謎のまま(藁
は「OO厨」だと思いませんか？
＋－－オブジェクト指向－－＋
｜ ｜
｜ ＋－－構造化－－＋ ｜
｜ ｜ ｜ ｜
｜ ＋－－－－－－－＋ ｜
｜ ｜
＋－－－－－－－－－－－＋
>>173 含有は必ずしもしていない。 いちおう独立概念だから
175 ：
デフォルトの名無しさん：02/08/03 15:49
>>164 だから、それのどこが構造化設計だっての。算数でしょ。アフォらし。
176 ：
デフォルトの名無しさん：02/08/03 15:50
>>174 含有してるだろ。
含有してないというのなら、構造化設計にあってOO設計にはないものを挙げてみそ。
>>175 算数というリテラルを貼ったら、算数だけの視点になってしまうようじゃまだまだ
世の中には一つの現象に複数の概念が含まれている場合も多い
俺は人間だ。 が、同時に動物でもあるし、日本人でもあるのだろう。
>>176 例： ボトムアップ ・ ウォータフォール
アドインの仕組みを作るときにはOO設計が必要だろ。
必要ない
必要なデータの流れを分析して
トップダウン＆ボトムアップで
>>181 >>178 OO設計はスパイラル型なものが多いが、
スパイラル型はウォータフォール型が多重に重なり合っていると看倣すとができる。
つまりスパイラルの各ステップはそれぞれウォータフォール的な開発の繰り返しとなる。
また、OO設計でもボトムアップなものは多い。
例えばAgileに代表されるlight weight methodsでは詳細はボトムアップで詰めていく。
184 ：
デフォルトの名無しさん：02/08/03 16:08
>>178 では、楕円の周長を求める近似式を構造化設計で導き出してみてください。
いくらなんでもデザパタが必要ないと思っている奴はいないよね
俺に言わせれば分析や詳細でない設計に構造化やらOOやらをつけるのがおかしい。
>>185 >>153 からの引用。反論できるならばやってみろ。
あと、OO信者ってデザインパターンを崇拝しているけど、滑稽だね。
良くある概念を簡潔に表現できないから
ある定石で冗長に表現したのがデザインパターン。
要するにOOが使いにくい証拠品。
例えばTemplate Method
C++の場合、このデザインパターンを用いなくとも言語仕様でTemplate
を表現することができ、
C++のTemplateの方が余計なクラスを定義しなくともよい。
OOPLでは無い言語で多態を表現する場合、冗長になることはいやがるのに、
OOでデザインパターンのような冗長な表現を嫌がらないのは何故？
言語レベルでtemplateあるならそれでいいじゃん。
なんでそれがデザパタを否定することになるのかがﾜｶﾗﾝ。
>>188 良くある概念を簡潔に表現できない場合、デザインパターンを使わないで
冗長にしないで表現できるの？ 代替案を出せ。
Templateの使い方が間違ってないか？
多態を表現するという目的があったとき、冗長にならないのは
どっちだと思う。
191 ：
デフォルトの名無しさん：02/08/03 16:23
>>188 テンプレートで抽象できるものがクラス階層とマッチしていたらTemplateMethodパターンを使えばいいし、
どうにもクラス階層とマッチしなければクラス階層を見直すか、あるいは別の手段を講じればいい。
その場合、C++のテンプレート機能はその候補の1つになるだろうな。
それだけの話。
192 ：
デフォルトの名無しさん：02/08/03 16:25
>>186 とりあえず、パラメータとして渡されるものとしてくださいな。
アンチOOって痛いな(ﾌﾟ
>>192 なるほど、
パラーメータとして渡された 精度から、
楕円の周長を求める近似式を導き出す という課題ですね？
構造化設計で 設計フローとしてはこうなるでしょうね。
１、調査 -> 結果
1-1 数値計算では定積分が最も効率のよい算出方法
1-2 既知の近似式
ttp://www.infoeddy.ne.jp/~tensyo/prog/ALGO.HTM (2-π)(1-x^1.55)^1.08+π
２、必要な精度の近似式を得る為に
1-2を参考に (2-π)(1-x^1.55)^1.08+π + Σan*x^n
として、数値積分し、必要な重み an を求めるものとする
あとは 数値積分と、重み an を求める詳細設計に入る
では、OO設計ではどうなるのですか？
195 ：
デフォルトの名無しさん：02/08/03 16:38
>>194 それは構造化設計によって楕円の周長を求める近似式を導き出しているのではなく、
構造化設計的な表現によって利用する近似式を選択する方法を示しているにすぎない。
全然ダメダメですね。
>>195 ワクワク ますますOO設計に期待が膨らみます
え？ だって
>>195 さんは 構造化設計では出来なかった楕円の周長の近似式を
OO設計なら簡単に出せるのをこれから見せてくれるんでしょ？ そりゃワクワクしますって
OO設計ってのはこういう場合
既存クラスで 解決出来そうなものを探す
・見つかった-------> ラッキー
・見つからなかった--> 無ければ出来ませんと答える
って意味だろ？
201 ：
デフォルトの名無しさん：02/08/03 16:47
>>198 この問題で構造化設計を使う必要がないのは同意したわけだよね。
だからといって構造化設計が必要がないとは思わないよね。
これと同じように
ある簡単な問題でOO設計を使う必要がなくても、だからといって
OO設計が必要がないということにならないってこと。
>>202 え？ 構造化設計では解けなかったんでしょ？
だからOO設計で解いてくださいよ
OO厨の行動パターン
既存レスで 煽れそうなものを探す
・見つかった-------> ラッキー
・見つからなかった--> １行煽りレスを返す
決して具体的なOO設計をしません。というかできません。
何でこのスレに粘着しているのかも不思議です。
206 ：
デフォルトの名無しさん：02/08/03 16:53
ｳﾞｧｶが勝手な思い込みで語りだすと迷惑。
>>203 もう少し日本語を勉強しろ。まずはそれからだ。
>>202 なんで？ ちゃんと構造化設計の手法である
トップダウン とボトムアップ
を使った問題解決手法を書いていますが？
既存の方法（既知の公式）にボトムアップして任意精度の公式を作る方法を
述べてからトップダウンで、詳細設計に入る方法を書いてるつもりで
>>206 激しく同意
特にOO設計ができないのに１行煽りを繰り返すｳﾞｧｶは逝って欲しい。
>>208 ＯＯ設計でも同じ。ＯＯで解く場合も同じ手法を用いるが
それは構造化設計がＯＯ設計に取り込まれているから。
だからさっき言っただろ。
俺に言わせれば分析や詳細でない設計に構造化やらOOやらをつけるのがおかしい。
どちらも手法は同じ。
212 ：
デフォルトの名無しさん：02/08/03 17:02
>>208 問題を解決する道筋を構造化設計手法的に記述しても、
それは構造化設計によって楕円の周長を求める公式を導き出したことにはならない。
実際に用いられているのは数学の公式/定理/手法である。
213 ：
デフォルトの名無しさん：02/08/03 17:03
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
どちらも手法は同じ。
214 ：
デフォルトの名無しさん：02/08/03 17:06
>>212の続き
つまり、君がやった事はUMLを使ってRUPを記述したようなものだ。
UMLが構造化設計での記法に置きかわり、
RUPが「近似式を応用する方法」に置きかわったにすぎない。
つまり、方法を記述しただけで、
その方法を実践するのに用いたのは数学的手法だ。
数学的手法をどこで使っているのか自分にはわかりませんが、
目的を具体化する作業が設計であり、
実現までの必要な方法を記述してゆく事が構造化設計の手法だと思っていますよ
あ！忘れていました。
>>212 代数的な解として楕円の周長を求める公式は作れない事がどうとかいうサイトがありましたから
公式を導き出すという表現は、問題をねじ曲げてしまうだけだと思いますよ
217 ：
デフォルトの名無しさん：02/08/03 17:18
>>216 では「計算機での有限精度での実用に適した近似式を導き出す」と言い替えましょうか？
よく判らないけど、
ようするに、オブジェクト指向設計が構造化設計を含んでて
難しい問題は構造化設計で解けるんなら
構造化設計だけで十分じゃないの？
>>218 ちょっと違うな。
すべての問題が構造化設計で最適に解けるんなら
構造化設計だけで十分じゃないの？
とするべきだ。答えは否だろう。
>>217 たぶん、公式を作るという事なら数学的な問題なのでしょうが、これは必要な精度の近似式の
一つを得るまでの 解法なのですから
プログラム設計手法の応用範囲だと思いますが・
>>219 たとえばどんな問題が構造化設計では解けなくて、どんな問題がオブジェクト指向なら簡単に解けるの？
222 ：
デフォルトの名無しさん：02/08/03 17:24
>>220 いや、メタレベルが1つ違うんだって。
「開発プロセス」を示しても開発した事にはならないでしょ？
マシン語以外は戦場では必要なし！
224 ：
デフォルトの名無しさん：02/08/03 17:25
>>221 構造化設計でも解けないことはないよ。
OO設計の方がふさわしいこともあるってだけで。
その逆も真なり。
今年は暑いから仕方ないな。
そっとしといてやれ
>>224 227 ：
デフォルトの名無しさん：02/08/03 17:29
>>222の補足
つまり、例えば開発スケジュールをPERT図で記述しても、
PERT図でシステム設計をしたことにはなりませんよね？
同様に、
構造化設計の記法で近似式を導き出す過程を記述しても、
構造化設計で近似式を導き出したことにはならないわけです。
(´,_ゝ`)ﾌﾟｯ
すげえバカ発見。
>>だからOO設計の方がふさわしいことって何？
GUIクラスライブラリ以外にOO設計がふさわしいものって何がある？
クラスライブラリ使うのはOOじゃないでしょ
>>227 そうだそうだ。
OO設計の記法で近似式を導き出す過程を記述しても、
OO設計で近似式を導き出したことにはならないわけなのだ。
･･･なにか？>>ALL
XX設計の記法でYYを記述しても、 XX設計でYYを記述した事にはならないのだ！
そういやOO言語でプログラムを書いても OOした事にはならないよと言ってるから
これはOO厨の常套句？
もういいよ。 原則論にはウンザリ
だから 戦場では必要ないなんて言われるのさ。
つーかね。設計の意味することがみんなばらばらだから話がかみ合ってないんだよ。
>>194 あなたの周りの人間は、コミュニケーションに苦労していることでしょう。
>>233 > 設計の意味することがみんなばらばらだから
じゃあ、「設計」って何？
>>235 君の思っている設計を書いてみ。いろいろ反論されるから。
>>236 ん、了解。まずは口火を切ってみようか。
設計とはシステムをある方法で表現したものである。
構造化設計の場合、主にDFDなどでシステムを表現する。
OO設計の場合、主にUMLなどでシステムを表現する。
ここまでで反論どうぞ。
あ、ちなみに反論するときは理由も付けてね。
できれば自分で思っている設計の定義を書いてくれると建設的になる。
じゃ自分のソフトウエア設計の定義：
,要求される性能,機能に基づいて機構や構造を定める
これに必要な ツールやライブラリ、そしてスタイルの選定
人員、工程、などの計画を立てることも含む。
設計内容は文章や図で示す事もある、口頭で伝える事もある
＞構造化設計の場合、主にDFDなどでシステムを表現する。
について、
DFD:データフロダイアグラムは 分析の時に使う
構造化設計時には機能面に絞って設計する為に、
分析時にはデータフローで分析する事がより重要となる為
>>238 UMLつってもいろんな図があるよね。全部設計用と思っていいの？
243 ：
逝って良しの１：02/08/03 20:16
設計つうのは、モノを作る前にやるというタテマエがあって、
でも実際にはモノを作ったあとにやるヤシだろ。
>>243 やれやれ、皮肉いや格好イイとでも思ってるのかねえ
OOが駄目とか言ってる奴はいっぺんxUnit使って開発やってみろ。
目から鱗落ちるぞ。
OO出来ないと駄目とか言ってる奴は「リファクタリング」読んでから自分のソース見直してみろ。
恥ずかしくて穴に入りたくなるぞ。
247 ：
逝って良しの１：02/08/04 01:32
なんだか知らんが俺が天然でとっくの昔に発明してるに決まっている。
とっくに煮詰まってんじゃねえか
sageろやハゲ
250 ：
デフォルトの名無しさん：02/08/04 02:17
>>242 UMLは記法の総集編みたいなもの。
多くは分析に「も」使うし、設計に「も」使う。
具体的にどの記法を用いるかは、開発方法論によって異なる。
251 ：
デフォルトの名無しさん：02/08/04 02:24
>>237 ユースケースを洗い出してクラス図を描く(改良する)ところはボトムアップ的だし、
クラス図からコラボレーション図で詳細を詰めていくところはトップダウン的なわけで、
OO分析でもOO設計でも、トップダウンとボトムアップを何度も繰り返すのが普通だ。
252 ：
デフォルトの名無しさん：02/08/04 03:25
>>251 で、コーディングに入ってると、不幸を招くプロジェクトに様変わりだ。
>>252 なんか最近分かってきたよ。今までみたいに「天才が設計して莫迦が
コード書く」やり方だと、確かに
>>251 までやって「じゃ、あとお前の
仕事ね」でいつまでたっても完成しない & 実装漏れ、仕様誤解だらけ。
UML とか OO とかってのは設計～開発～テストまで一人でやる職人プロ
グラマが使うものであって、COBOLER みたいなリーマンプログラマが
使うもんじゃない。
254 ：
デフォルトの名無しさん：02/08/04 04:07
>>253 「設計が天才でコード書きがバカ」なんていうプロジェクトより、
「設計がなにも出来ない能無しで、コード書きはコードしかかけ
ない」プロジェクトの方が圧倒的に多いな。
下の場合、コード書きは自分の責任を全うしているが、設計者
連中は首にすべきゴミ。
>>253 そう、スキル格差のある開発に導入したところで失敗する。結局、設計の
最初から話に参加していないと、読めない書けない作れないで終わって
しまう。だからコーディングフェーズにだけ派遣を大量確保して力技で
進める様な銀行開発では使えない。
逆に、完全なブラックボックスを一人で作りきれるだけのスキルを持った
連中の間で使うには非常に便利なものだ。自社内開発などは結構こっち
のケースも多いだろう。
257 ：
デフォルトの名無しさん：02/08/04 05:19
258 ：
デフォルトの名無しさん：02/08/04 05:23
>>256 つーか、だからこそUMLのUはUnifiedのUなんだよな。
「誰でも」統一された記法を使うことも大事だが、
「どのフェーズでも」統一された記法を使うことはもっと大事。
クラス図作成は分析？設計？
構造化設計でそれに対応するものはなに？
260 ：
デフォルトの名無しさん：02/08/04 07:57
>>259 通常は分析段階からクラス図を描いていって、
シーケンス図やユースケース等といっしょに練っていきます。
ある程度それが練れてきたら、設計にはいります。
設計でもクラス図を改良/詳細化していきますが、
分析段階と違って、コンポーネントやパッケージを意識し、
コラボレーション図などによってクラス図の構造や振舞いを検証し、改良していきます。
もちろん、主に使う図の種類や描く順番や評価方法など、
それぞれの方法論によって異なります。
UMLはあくまで記法にすぎないので。
261 ：
デフォルトの名無しさん：02/08/04 08:00
ところで、
>>252は
>>251のどこを見て「不幸を招くプロジェクト」になると思ったのだろうか？
OOや構造化手法に限らず、設計の方法論の大抵はトップダウンとボトムアップをすると思うのだが。
>完全なブラックボックスを一人で作りきれるだけのスキルを持った連中
は、 C++ より Cが好き そしてアセンブラが好き
>>262 俺は丁度逆だ。
システム依存なんていやんな感じだもん。
265 ：
逝って良しの１：02/08/04 12:34
Ｃ，アセンブラだってシステム依存無しに書けるよ。
つうか非依存で書けやｺﾞﾙｱ。
>>265 ども、素人です。
アセンブラでもそんなことできるの？
>>266 アフォの相手はアフォの片棒をかつぐことになります
>>266 マクロアセンブラを使って、ニーモニックの違いを吸収させるとかね
>>269 8080とSPARCに同じアセンブリソースからアセンブルできるのかよ。
ついでに68030と8086の場合はどうだ？
>>270 その例だと C でも可搬性のあるコードは一部しか書けない
それでも C程度には可能だよ
>>271 アセンブリ言語である以上、機械語と1対1対応してないとアセンブリとは呼べないと思いますが、
それでも可搬性のあるコードが書けるのですか？例えば、8080と8086ではどうでしょう？
エンディアンが同じなので、可搬性のあるC処理系を実装することは可能ですが、
可搬性のあるアセンブラは存在可能ですか？
>>272 だからマクロASM なら可能
それから機械語と1対１対応してないアセンブラなんて沢山あるよ
論理左シフトと算術左シフトは同じバイナリになるとかさ
274 ：
逝って良しの１：02/08/04 16:19
>>270 Ｚ80→68000
Z80→286
ならやった。
>>272 仮想マシンコードでやるのだ。
だから Cの出始めはマクロアセンブラのライブラリを抱え込んでた所は
Cよりこっちが可搬性もある上、記述の柔軟性は高く、しかも効率もいい のに何でC? と思ってたんだよ
>>265 C はともかく、アセンブラで書くところは
普通システム依存するところだとおもうが・・・
>>273 8080と8086でか？そりゃすげーな。
それでちゃんと8086のセグメントレジスタとか使えるのか？(藁
>>273 まあ、そういう例外的なニーモニックがあるものも結構ありますね。
でも原則的にはアセンブリと機械語は1対1の関係ですよね。
というか、アセンブリ言語は機械語の別記法として定義されるものですよね。
>>274 誰が移植の話をしたんだよ。
同一ソースコードからそれぞれの機械語を生成するアセンブラおよび共通アセンブリ言語を定義できるかって話なんだよ。
279 ：
デフォルトの名無しさん：02/08/04 18:57
な ん だ か ん だ 言 っ て も
O O は 消 え る 運 命 に あ り ま す 。
>>279 いや、ただの煽りでは説得力がないんですが。
>>280 雑誌の海運財布のCMみたいなもんな。マジレスすんな。
Brew ってどうよ? 誰か使ってる?
283 ：
デフォルトの名無しさん：02/08/04 20:32
俺OOバリバリに使って開発してるけど、
OOのおかげですごく開発が楽にﾅﾀｰﾖ。
OOは仕様変更にも強いし、
開発期間も短縮できたよ。
これからはOOで開発が一番だね。
>>283 お前は本当にOOが一番だと思っているのか
それともアンチが餌まいてるのか？
後者なら氏ね。前者でも氏ね。
>>284 取りあえずBASIC程度は書けるようになってから物言ってくれ。
287 ：
デフォルトの名無しさん：02/08/04 20:54
OOはやっぱ開発効率一番だね！
>>287 正気か？
あるものを再利用するなら効果的だが
無いものを作るのは面倒だ。
>>288 必ずともそうとはいえない。
インスタンスが複数あるものはOOの方が便利。
290 ：
デフォルトの名無しさん：02/08/04 21:09
結局OOの利点ってなんだ？
実際に開発効率いいのか？
習得しやすいのか？
後のPGの引継ぎがスムースにできるのか？
仕様変更に柔軟なのか？
複数人での共同開発がしやすいか？
コストが抑えられるのか？
>>290 OOもそうだが構造化についても同じ疑問があるな。
実際に開発効率いいのか？
習得しやすいのか？
後のPGの引継ぎがスムースにできるのか？
仕様変更に柔軟なのか？
複数人での共同開発がしやすいか？
コストが抑えられるのか？
>>290 まず、非OOでそれらが達成できていると言うことを証明してくれ。
293 ：
デフォルトの名無しさん：02/08/04 21:13
>>293 「いやいや、後手の方が有利だからさ。」
仕掛けてくると言うことはよっぽど自信があるんだろう。
それくらいハンデくださいよ。畑山さん。
そう言うファイトクラブ生達。
たとえどっちでも大差ないって結論になっても、
どっちでもいいなら構造化でいいじゃんって結論はやめてね。
どっちでもいい かつ 構造化が自分の周りで普及しているから構造化がいい ならいいけど。
結論から書くとOOでも
たいしたことないっすね。
>>295 その場合の結論は好きな方を使え。が正常だろう。
298 ：
デフォルトの名無しさん：02/08/04 21:22
>たとえどっちでも大差ないって結論になっても、
>どっちでもいいなら構造化でいいじゃんって結論はやめてね。
じゃあ構造化に比べてOOを導入する利点ってなんだよ。
PGオタの最後の砦ってか？（ｗ
インスタンスを複数作る場合には 構造化でも クラス的なものを作る事になってしまう
他の方法は別のプロセスを作るくらいしかないんだけど、それはコストが大きすごるから
すべてをクラスにするというのは設計のこと。
C++のようなハイブリッド言語ならすべてをクラスにする必要はないし
GtkのようにC言語でオブジェクト指向設計をすることもできる。
オブジェクト指向設計とはオブジェクトそのものをイメージし
それを（クラスベースの言語であれば）クラスとして定義することをいう。
よくあるおかしな設計は
構造体を定義して関数を構造体の中に入れるというもの。
この方法はソース上ではデータと機能がカプセル化されているかもしれないが
頭の中ではデータと機能がバラバラになっている。
OOマンセーは頭の中でオブジェクトそのものをイメージできる。
>>153 デザバタ・レベルの抽象化を非OOPLでやるともっと冗長になる。
あと、どうでもいいことだけど
C++のTemplateとデザパタのTemplate Methodは関係ない。
301 ：
デフォルトの名無しさん：02/08/04 23:11
OO 構造化
理解しやすさ × ○
設計の大切さ ◎ ○
わかっている人が作ったときの
開発効率 ○ ◎
仕様変更への強さ ◎ ○
わかっていない人が作ったときの
開発効率 × ◎
仕様変更への強さ × ◎
結論、
わかっている人が作ると OO の方が効率がよく、
わかっていない人が作ると構造化の方が効率がよい。
しかも、理解のしやすさは 構造化の方が容易なのでへたれプログラマーには
構造化がお似合い。
OOは構造化を含んでるってのは正しいの？
>>304 クラスを構造と言ってしまえば正しいでしょう。
>>304 >OOは構造化を含んでるってのは正しいの？
正しい。
構造化で脳みそが硬直してる奴にJAVAなんかをやらせると一つのクラスの中に
全てを押し込んで作りやがる。
「こうしないとグローバル変数作れなかったんですよ。」
「氏ね。」
>>306 その設計は構造化してないような・・・
OO言語を使っていてもOOしてないのと同じく
構造化言語を使っていても構造化してない奴は大勢いる
>>307 構造化プログラミングと構造化分析/設計は別物だと思ふ。
オブジェクト指向プログラミングと オブジェクト指向設計も別物で
後者は不要
>>309 いや、オブジェクト指向分析/設計のオブジェクトは、
オブジェクト指向プログラミングでのオブジェクトと概念的には同じもの。
一方、構造化分析/設計のいう「構造化」と
構造化プログラミングのいう「構造化」は別物。
>>310 どう別物なのか説明しなくちゃ
構造化プログラミングの構造化はダイクストラの 全てのプログラムは以下の構造に分類出来る の構造の事
構造化設計の構造は、その構造化プログラミングにどう落とすか それはトップダウンとボトムアップだ という事で
「構造化プログラミングに適した設計」 を略したもの
じゃこう言い換えよう
オブジェクト指向プログラミング言語は有用だが オブジェクト指向プログラミングは不要
312 ：
デフォルトの名無しさん：02/08/05 10:00
「オブジェクト指向プログラミング言語は有用だが オブジェクト指向プログラミングは不要 」
やっと結論が出てきたという感じだな
OOを一生懸命勉強した人、お気の毒に。
オブジェクト指向言語の持っている機能は 便利だし、使いこなせるようになると非常に有用
教養として知っていて、手法の一つとして利用すれば十分に役立つのも確かだ。
しかし、設計の場にオブジェクト指向を持ち出す輩は、「指向」しようとする
それは、イランのよ テンプレート覚えて自作の文字列クラス作って使わせようとする輩と同じくらい迷惑なのよ
>>314 ／＊
しかし、設計の場にオブジェクト指向を持ち出す輩は、「指向」しようとする
それは、イランのよ テンプレート覚えて自作の文字列クラス作って使わせようとする輩と同じくらい迷惑なのよ
クソ自作文字列クラス－＞仕様知らない－＞理解しなければいけない－＞面倒くさい－＞しんどい－＞イラン
OO－＞理解できない－＞理解しなければいけない－＞面倒くさい－＞しんどい－＞イラン
他人－＞理解できない－＞理解しなければいけない－＞面倒くさい－＞しんどい－＞イラン
ボトムアップとかトップダウンってどういうことよ。
って知ってるけど教えてくれ。それが構造化設計とどのように関係するのか。
319 ：
デフォルトの名無しさん：02/08/05 10:36
そっかOOってダメなんだ・・・(´･ω･｀)
>>318 ボトムアップ：
関数なりクラスなり作りまくってそれを組み合わせて完成。
トップダウン：
おおざっぱにmainを書いてそれにどんどん肉を付けていく。
そっか人間ってダメなんだ・・・(´･ω･｀)
>>318 ボトムアップ：
よりシステムに密着した実装をしやすいが、設計物自体が無駄になることも
トップダウン：
いるものを必要になってから作るから無駄はでないが、鬼のような性能はのぞめないかも
323 ：
デフォルトの名無しさん：02/08/05 10:44
OO導入してSE／PGが糞の場合コストが高くなりそう。
また仕様変更があるといくら優れたPGでも
最初からクラス設計しなおさないとあかんしな。
324 ：
デフォルトの名無しさん：02/08/05 10:48
>>311 構造化プロラミングはその通りだが、構造化設計に関しては全然違うだろ。
構造化分析/設計における構造化は構造化プログラミング言語で実装しやすくするためのものではなく、
あくまでシステムの要件から機能を分解していき、また、機能の合成をすることでシステムの機能や構成をモジュール化していくもの。
実装をどのような言語でやるかとは全然関係ない。
>>323 仕様変更があるといつでもクラス設計しなおさなければならないって言い方だな。
クラス設計しなおさなければならないくらい仕様が変更されても
構造化なら設計しなおさなくてもいいと？
>>324 それは結果論で
歴史的には、 プログラミングについては構造化プログラミングが出て改善された、しかし設計手法をどうしようと
という事で生まれたもの。
そうじゃないというなら、 その構造化設計の 「構造化」 の由来を説明してみてよ
327 ：
デフォルトの名無しさん：02/08/05 10:54
>>323 なぜ最初からやりなおし？普通に見直すだけだろ？
ちょっと
>>324の言葉を借りて。
システムの要件からオブジェクトを分解していき、また、オブジェクトの合成をすることでシステムのオブジェクトや構成をモジュール化していくもの。
こうすると、構造化分析/設計のことオブジェクト指向分析/設計のこと、それとも意味不明な文章？
モジュール化じゃなくてコンポーネント化とした方がいいかな。
オブジェクト指向設計も同じだな OOが先に出来て、後から追いかけてきた
331 ：
デフォルトの名無しさん：02/08/05 11:05
>>326 プログラミング言語の構造化は、制御構造を構成的に定義したもの。
分析/設計の構造化は機能分解と機能合成であり、それは機能を中心にした還元主義といってもいい。
別の言い方をしよう。
プログラミング言語の構造化は、構造化がゴールではない。あくまで安全な制御構造の構成が目的。
一方、構造化分析/設計の構造化は、機能を構造化し表現することがゴール。
332 ：
デフォルトの名無しさん：02/08/05 11:06
>>330 それを言うのなら、プログラミングが先に出来て、システム分析/設計は後から追いかけてきた。
>>332 じゃまあ その下らない議論は そのせんで軟着陸させましょう
では本題に戻って 結局オブジェクト指向は
指向・志向がイカンのじゃないの？
そんな所に拘るなよってカンジ
構造化分析/設計の機能が、具体的にどのようなものか。
データはどうなるのか、オブジェクト指向だとそれがどのように
変化するのか気になるな。
335 ：
デフォルトの名無しさん：02/08/05 11:11
>>328 違います。
オブジェクトの分解や合成は、あくまでオブジェクトを見直す時に用いる操作であって、
それ自体が設計の中心になるわけではない。
構造化設計では機能の分解や合成が中心的活動なのとは対照的。
構造化分析 --> データとデータの流れに注目
構造化設計 --> 主に機能に注目
>>335 キミってさっきから 「違う」という事は言うけど「こうだ」は言わないね
恐いの？
>>337 1行しか読めない人？
せめて、たった4行の文章ぐらいちゃんと最後まで読もうね。
400ページの英語の本読めってんじゃないんだからさ (藁
340 ：
逝って良しの１：02/08/05 21:17
ＯＯ流行らせても詐欺師が横行するだけなのに・・・
アンチOOへの反論
>>300 からの引用。
> オブジェクト指向設計とはオブジェクトそのものをイメージし
> それを（クラスベースの言語であれば）クラスとして定義することをいう。
>
> よくあるおかしな設計は
> 構造体を定義して関数を構造体の中に入れるというもの。
> この方法はソース上ではデータと機能がカプセル化されているかもしれないが
> 頭の中ではデータと機能がバラバラになっている。
>
> OOマンセーは頭の中でオブジェクトそのものをイメージできる。
342 ：
逝って良しの１：02/08/06 00:42
ＯＯマンセー派のよくあるおかしな設計は
１）脈絡も無くサブルーチン集をクラスにまとめたもの。
２）クラス名が「機能を持ったモノ」を表していない。（たまに動詞）
３）よくバージョンが変わり、上位互換性も下位互換性もなくインターフェース
も毎回変わる
（インターフェースと言うと継承で使うアレしか思い浮かばないので話が通じない）
４）とにかく汎用性の低い部品しか作れない。
（そのプログラムでのみ使用可能なクラスしか作れない）
５）本人は時代の最先端を行っていると勘違いしている（実は二周遅れ）
それ、全然OOじゃないじゃん。
構造化で頭の固まった上級PGが勘違いして設計して、
周りに迷惑かけてる典型。
というか、今の職場のフレームワークそのもの。
オブジェクト指向の本見てみろ。ずらずらと・・・
こんな習得が難しいのならやめとけ。バグの元だ。
オブジェクト指向で考えたほうが自然な考え方？ﾊｧ？
カプセル化だけならまだしも、ポリモーフィズムのどこが
自然な考え方？おまえらは人間捨てたからそう言えるのかもしれないが、
まっとうな人間はプログラム的には自然かもしれんが、
決して自然な考え方などではない。そこんところわかっとけな。
OOは構造化を含むとか言ってる馬鹿へ。
クラス使えばOOしてるってことになるの？禿藁
構造化分析設計の本見てみろ。70年代から80年代までずらずらと・・・
こんな習得が難しいのならやめとけ。バグの元だ。
構造化して考えたほうが自然な考え方？ﾊｧ？
データフローだけならまだしも、モジュール階層のどこが
自然な考え方？おまえらは人間捨てたからそう言えるのかもしれないが、
まっとうな人間はプログラム的には自然かもしれんが、
決して自然な考え方などではない。そこんところわかっとけな。
オブジェクト指向はもともと生産性危機から必要とされたのではない。
GUI時代になってイベント駆動型フレームワークを
合理的に記述するのに必要になったわけ。
オブジェクト指向がいったん定着すると、
サーバサイドプログラミングが復活してきたにもかかわらず、
何でもオブジェクト指向にせねば気が済まぬ傾向があるわけで。
習慣の力というものだね。
GUIや複合ドキュメントが無くならない以上、オブジェクト指向も
無くならないよ。両極端な原理主義はどちらもおかしい。
349 ：
デフォルトの名無しさん：02/08/06 07:29
>>348 は？
イベント駆動のためにOOが必要になったのではなく、
OOを真似するためにイベント駆動が使われるようになったんだよ。
>>349 実際、Cでも割り込みベクタとかシグナルによるイベントドリブンシステムは組める。
>>350 懐かしーな、おい。DOS は INT24h だっけ?
最初使ったときは「実行時に動きが変えられるすごい仕組みだ」と
思ったもんだが、あれも関数ポインタテーブルでポリモーフィズムの
基礎なんだよな。研究室で CAMAC のボードから割り込み信号受け取っ
てたよ。もう忘れたけど。
352 ：
デフォルトの名無しさん ：02/08/06 11:30
>>348 おまえらバカか、
この種の議論が好きなやつらは、
プログラム開発の経験まるでなしのふつ～のSEばかりじゃ。
OOPはプログラム開発する人のためにあるの。
OOPはプログラム開発する人のためにあり、かつ役立つ
OO設計は プログラム作れない奴が金を毟るためにあり、かつ役立たない
354 ：
デフォルトの名無しさん：02/08/06 11:46
>>352-353はプログラミングも設計もできないの一点読み。
OOPするのであれば、少なくとも脳内ではOODをしているはず。
そしてOODに関する方法論は、
まずはその脳内OODを一定の記法でドキュメントとして残す事を要求し、
また、OODする際に陥りやすい罠を避ける方法を提案しているものだ。
355 ：
デフォルトの名無しさん：02/08/06 11:50
言葉で遊ぶなこの糞SE、
OOPっていったらOODも含むの。
356 ：
デフォルトの名無しさん：02/08/06 12:12
くだらない議論続いてるなと思ったけど
PGじゃなくてSﾖなのね。
納得。
いいよべつに 脳内でOODしてるというなら、それでいいから
設計会議で持ち出すのはやめてくれ、
どのクラスが云々言い出したら終らりゃしないからさ
設計している気分に浸りたい万年コーダが吼えとるな
361 ：
デフォルトの名無しさん：02/08/06 15:41
OOはPGオタの最後の砦です。
そっとしておいてあげましょう。
所詮2ちゃんねるでしか吼えられない人間か。
可哀想に。
363 ：
逝って良しの１：02/08/07 01:38
そういえば、明治時代に「文明開化だ！」と叫んで日本間に土足で上がりこんで
得意になってたヤシがいたな。
(ﾟ Д ﾟ)･････
OOは構造化を含むとか言ってる馬鹿へ。
クラス使えばOOしてるってことになるの？禿藁
(ﾟ Д ﾟ)･････
367 ：
デフォルトの名無しさん：02/08/07 03:34
>>365 なるよ。少なくともOOの概念を利用している事には間違いない。
で？
それよりも、なんでOO業界には自己開発セミナーくずれみたいな
衒学的なペテン師が多いのかの方が気になる。
369 ：
デフォルトの名無しさん：02/08/07 08:35
>>368 実際にどれぐらいの人数のペテン師がいるわけ？
そして具体的にどの人がペテン師？
その人は具体的にどんなペテンを働いた？
370 ：
デフォルトの名無しさん：02/08/07 09:10
OOを導入すると再利用に優れているため
開発工数を劇的に減らすことができるのは事実。
またクラスによって共同作業による
バグなどを減らすことができます。
アンチOOの人はなんでOOを批判するのか分からない。
>>370 再利用すべき物がある場合は、な。
再利用できる物を作ろうと思うとどうしてもすぐに必要のないところまで実装しないといけない。
それに、同じような機能が別の親クラスから継承されてたりしたら・・・。
Adapterパターンを使うと必要以上にソースが汚れるし。
まぁ、OO派の意見です。
372 ：
デフォルトの名無しさん：02/08/07 09:38
>>371 なぜすぐに必要のないところまで実装しないといけないの？
あとで必要になった時に実装すればいいんじゃないの？
>>372 継承とかで？
どんどんコードがややこしく・・・
374 ：
デフォルトの名無しさん：02/08/07 09:43
375 ：
デフォルトの名無しさん：02/08/07 09:46
OOむずい・・・
>>374 再利用生を突き詰めるなら既存のコードは変更しないようにしないと
ちょっと改変したコンポーネントが出現する。
そのプログラムの再利用性は落ちると思うんだが。
必要なライブラリとかぐちゃぐちゃになるかと。
どこかのコードから関数取って改造するのと大して変わらん。
デザインパターンを使うって答えを想定せずここまで書いたｗ
377 ：
デフォルトの名無しさん：02/08/07 09:54
378 ：
デフォルトの名無しさん：02/08/07 09:58
それとも下位のクラスで適宣再定義できるように、
てゆうか再定義を前提にテキトーにつくとけってこと？？
>>378 だからはじめからコンポーネントとして作り込めと。
最悪でもしっかりとリファクタリングしろと。
ここはアプリ固有のクラス・クラスライブラリ・フレームワークの区別なしに
再利用性を議論してしまう未経験者の集うスレですか?
381 ：
デフォルトの名無しさん：02/08/07 11:54
>>376 そのクラスを自分達のグループの外に出してしまうかどうかでも状況はかわりますし、
インターフェースをグループの外に出すかどうか、また、
そのインターフェースを実装するクラスを他のグループが作るかどうかによっても
状況は大きくかわります。
クラスに機能を追加したかったらメソッド追加すりゃいいじゃん。
まあクラスにしなくても 関数ポインタ型プロパティで いいとは思うけど
コンポにした方が細かい処理を渡せるだろうし
ただ、ベースクラスの設計は難しくなるだろうね
384 ：
デフォルトの名無しさん：02/08/07 15:43
>>383 クラスにしないのに基底クラスの設計が難しくなるのか？
わけわからん。
鯨クラスは魚類クラスに含めるべきでしょうか？
蕎麦クラスは麺類クラスに含めるべきでしょうか？
バナナクラスはおやつクラスに含めるべきでしょうか？
＞バナナクラスはおやつクラスに含めるべきでしょうか？
言いたかっただけちゃうんかと・・・略
バナナを主食とする文化もある。
>>386 鯨 is a 魚類 でしょうか？
蕎麦 is a 麺類 でしょうか？
バナナ is a おやつ でしょうか？
実務ではこういう微妙なクラスに頭を悩ませる。
ここで鯨 is a 哺乳類 とかしてしまうと
魚類の「泳ぐ」メソッドを利用できなくなる。
>>390 そういう実際を無視したオナニー設計に頭を悩ますヴァカっているよな。
血が出てるときにマッタリ血に凝固メソッド出せるかゴルァ!!
弾に飛んでいってもらうのか？トマホークしかないぞゴルァ!!
誰が包帯巻くんじゃぁぁぁ。
BattleField ww2; //world war II
ww2.tomahawk(_392_);
>>390 魚類に「泳ぐ」メソッドを持たせている時点で設計ミスでは?
「泳ぐ」は魚固有なわけじゃ無し。
それに継承を基本とする設計もなんかだめぽ。
やっぱ型に厳しいOOPLは嫌い。
interface 海の生き物
泳ぐ();
もぐる()；
public interface ISwimable {
public void swim();
}
>>396 INatantの方がふさわしいと思ふ。
わしはswimableのほうが直観的でいいと思うといってみるテスト
海の生き物の功績をもうちょっとたたえて欲しいテスト。
>>392 >誰が包帯巻くんじゃぁぁぁ。
衛生兵。
public interface IAidman{
public void tieUp();
}
extends ISoldierですか…ｗ
>>394 > 魚類に「泳ぐ」メソッドを持たせている時点で設計ミスでは?
>「泳ぐ」は魚固有なわけじゃ無し。
確かに、ペンギンも泳げるね。
>>395 > interface 海の生き物
海の生き物でない生き物（ex淡水魚）の場合は？
interface 泳げる生き物
だと、他に走れる生き物、飛べる生き物、木に登る生き物、
などクラス名が爆発してしまう。
さらに考えると、人間の場合、泳げる人間と泳げない人間がいる
人間をクラスと表現してしまうと人間は泳げる／泳げないのどちらかで
各インスタンス毎に泳げる／泳げないを制御することができない。
ここら辺が現在のOOPLの表現力の限界かなぁとか思っている
俺のボケからなんか凄くためになる話が聞けてしまった。
何でも書いて見るもんだ。
>>430 そんなん言語仕様によりけり。
module Swimable;end
class Human;end
hoge = Human.new
hoge.extend Swimable
2chの夏。
電波の夏。
>>406 おぉ、できる言語もあるんだ。JavaとかC++しか知らなかった。勉強になる。
ところで、なんていう言語？
両生類はどうすんだべ？
410 ：
逝って良しの１：02/08/07 23:30
>>406ってObject Pascalでないの？
414 ：
デフォルトの名無しさん：02/08/08 08:47
まだやってるのかよ。
この世界はいいものはすぐに普及する
ものだが、数年前からあまり普及しないで
くすぶってるようなOO設計は見込みないよ。
いいものだけどすぐに普及しなかったものもたくさんあるよ。
今思い出すだけでも JFS, PGP, Linux, PNG なんか。
これらや OO は根底に「ってか、現状のでなんとかなっちゃ
うし…」があるからかな。
っていうかこういう手法が「何年」レベルで普及すると思う?
416 ：
デフォルトの名無しさん：02/08/08 09:30
>>415 ソフトウェア工学自体が「机上論」で片付けられてる所が多い現状では
あと20年か30年ぐらいはかかるな。
お前らの狭い了見で普及したのしなかったのほざくなヴぉけ
418 ：
デフォルトの名無しさん：02/08/08 10:09
>>417 で、君の狭い了見では普及してるのか？してないのか？
419 ：
デフォルトの名無しさん：02/08/08 10:39
>>415 それらは本当に「いいもの」なの？
「いい部分もあるけど悪い部分もあるもの」ではないの？
>>419 いいこともあるがワルいこともある⊂いいもの
手放しで良いものなんて最近あったっけ?
>>421 つーか、そんなものこの世に存在するのか？
>>426 さっき食ったカレーライスは、手放しで良いものだった。
ごちそうさま。
428 ：
デフォルトの名無しさん：02/08/08 16:33
激しく夏だと感じる今日この頃。
手放しで良いものは直前まで掴んでるものだろうが！
432 ：
逝って良しの１：02/08/08 21:52
オウムはカレーで信者を募った。
ＯＯ教徒は最初は「生産性」の甘い言葉で集められたが、
一度信者になると生産性のことなどどうでも良くなるらしい。
433 ：
逝って良しの１：02/08/08 21:53
追）
空中浮遊と同じだ。
お前の仕事は2ちゃんねるで下らない議論を誘発することか。
>>434 下らないか下らなくないかはお前が判断する問題ではない
じゃ誰が判断すんの？答えてみそ。答えられたらだけど（ｗ
個人個人が心の中で感じることだ。
おまえが勝手に決めるなということだ
はぁ～～（ｗ
440 ：
デフォルトの名無しさん：02/08/08 22:49
>>439 おまえとは濃い話ができそうにない。帰ってくれ。モー板に
>>440 おまえとは恋話ができそうにない。帰ってくれ。
誰が嫌と言ったんだ？？おーいﾀﾞﾚﾀﾞｧ!!
嫌よ嫌よも好きのうち。
>>442 とりあえずおまえは出て行け。そして氏ね
自分が(省略)
自分が自分が。
周りの見えてない親父に多い台詞よね・・・ﾄﾎﾎ
そんな必死にならないくていいんだよ（ｗ
>>450 書いた後は一度見直そうな。
必死なのがばれちゃうぞ♪
452 ：
OO初学生：02/08/08 23:22
あのー。
まだデザインパターンとかエレガントなことは学んでないけど
OOって有効なモデル・設計方法ですよね？
ここは技術についていけない年寄りが愚痴をたれるスレッドですか？
ここは学生が集まるスレですか？（ｗ
454 ：
デフォルトの名無しさん：02/08/08 23:26
>>452 そのようです。業界標準から漏れた人達の言い訳らしいです。
OOとは、コｍプテｒの中に世界を構築することじゃ
オブジェクト指向もわかってないような学生さんが
暴れておられます。。。
スキルの無い奴は来るなって。ﾏｼﾞﾃﾞ
新しい秩序の確立が難しいのは当たり前だな。
いろんな邪魔なものが転がってる。
まずはこれを綺麗に掃除してから････
>>456 多分、学生じゃないよ。高校生以下だと思う。
高校生も中学生も学生だよ。
460 ：
デフォルトの名無しさん：02/08/08 23:58
どっちでもいいよ
462 ：
デフォルトの名無しさん：02/08/09 00:01
>>461 プログラムの知識だけじゃなく
日本語の知識もない
でも負け惜しみだけは一人前
さっきから煽ってるやつ氏ね。
煽りは半人前。
466 ：
デフォルトの名無しさん：02/08/09 00:10
夏厨のための日本語講座
小学生 = 児童
中学生 = 生徒
高･大学生 = 学生
ついに日本語ヲタが出てきますた（ｗ
高校生は生徒じゃないのか（ｗ
あげて書くなよ。恥ずかしいだけだぞ？おい？
高校生は狭義では非学生でしょ。
日本語知らなくても、威張ってるな夏厨。
恥知らずって特だなぁ（ｗ
女子高生と女子校生はどう違いますか？
473 ：
デフォルトの名無しさん：02/08/09 00:16
特だなぁとか書く奴が
夏厨であろうと相手を日本語知らない呼ばわりすんな。
恥ずかしいから。
ＡＶに出れるのが女子校生
じどう【児童】
心身ともまだ十分に発達していない者。こども。わらべ。童児。現在は、特に小学校に学んでいる子どもをいう。
せいと【生徒】
学校などで教えを受ける人。現在はふつう、大学の学生や小学校の児童に対し、高等学校・中学校で教育を受ける者をいう。
がくせい【学生】
学問をしている人。現在は普通、高校以上、特に大学に通って学ぶ者をいう。
>>473 工房のころは生徒手帳なるものを持っていたのですが
それでも学生とおっしゃりたいのですか？(-_-;)
阿呆ばっかでんなぁ～
>>478 それぐらいならどんな阿呆でも言えますよ。ﾆﾔﾆﾔ
「特に」「ふつう」が付いてる（制限されてる）でしょ
「児童≡小学生」「生徒≡中高生」とはどこにも書いてない
おまえらみたいな中身も外見も同じようなカスは
俺がcompositeパターンで設計してやる！
>>481 おまえ、中学生を学生だとかぬかして、指摘されて逆切れした真性馬鹿だろ。
486 ：
デフォルトの名無しさん：02/08/09 00:27
学生とつけば学生なのだろう
きっと小学生も学生なんだよ
日本語も知らない奴がOOを知ったかぶりするｽﾚはここですか?
厨大活躍（藁
491 ：
デフォルトの名無しさん：02/08/09 00:30
>>487 俺がじゃないよ
中学生を学生だと言い張る夏厨
夏厨流だと子女とか?
OOが浸透しない理由がわかりました。
早まってるつもりもないけど次のＸＸ指向が出てきてもおんなじだと思う。
所詮は自然淘汰だよ。
いくら広めようとしても悪い物は広まらない。
いくら否定しても良い物は広まっていく。
OOは後者だな。
Windowsは最高ってことで終了？
じゃぁ終了します。みなさんありがとうございましたぁ
新しい終わり方ですね。さようなら
いえーいWindowサイコー(-Д-)。
また明日～
ﾓｳ1時か。今日はﾁﾄ頑張って煽り過ぎたかな。
反省。
しかしまぁ、これだけ引っかかる奴がいるとやめられねぇよな。ｸﾞﾋﾋﾋ
おめーらまた明日煽りに来てやるよ。あっだめだ。
明日女の子引っ掛けに行くからな。ｽﾏﾝ
まぁ成功したらこのスレに報告してやんよ。
楽しみに待ってろよ。厨房諸君。
おやすみ
危険人物が来ているか良く見極めて煽らないと、自分が傷を負うということですな。
なんだったんだ、この厨の群れは…
508 ：
デフォルトの名無しさん：02/08/09 04:41
>>507 平和な事はいいことですが、ダイクストラ先生が亡くなられました。
構造化プログラミング無しにはオブジェクト指向もなかったでしょう。
合掌。
510 ：
逝って良しの１：02/08/09 07:03
寝ている間に煽り屋どうしの煽りしかなかったのかYO!
正しいか正しくないかの判定基準も「生産性」だ。
これが判らない奴は社会人やる資格なし。
>>510 > 正しいか正しくないかの判定基準も「生産性」だ。
？？？
じゃあ生産性が高いと言われているVBって正しいの？
512 ：
デフォルトの名無しさん：02/08/09 10:47
>>510 その生産性を測定する基準は何？
具体的なメトリクスを提示してよ。
あと、生産性はどこまでを生産性と呼ぶ？
信頼性とか頑健性とか拡張性とか再利用性とか移植性とか可読性とか再現性とかも含める？
>>511 Perl で CGI や PHP ゴリゴリ書くのも生産性高いぞ。
ってか、いつもの微弱電波。
514 ：
デフォルトの名無しさん：02/08/09 13:13
515 ：
デフォルトの名無しさん：02/08/09 14:23
Ooを体得するのは簡単ではないと思う。
ゆえに単純にコストに響いてきます。
ホントのプログラミングを体得する事そのものが簡単ではないと思う。
プログラミングを深く理解するには10年かかる。
片足突っ込むだけなら猿でもできる。
519 ：
デフォルトの名無しさん：02/08/09 14:36
520 ：
デフォルトの名無しさん：02/08/09 16:19
>>519 一般的に言って、ホントのプログラミングを体得する事そのものが簡単ではないと思います。
521 ：
デフォルトの名無しさん：02/08/09 16:35
>>520 その上、OOの場合さらに体得するのが困難なため
普及しないでしょう
522 ：
デフォルトの名無しさん：02/08/09 16:49
>>521 プログラミングを半端に体得している人が片手間でOOを体得するのは、確かに困難ですね。
体得より習得の方が良いんじゃないの？
必殺技とかですか？
529 ：
デフォルトの名無しさん：02/08/09 21:12
OOって何？
>>527 くっくっく、士官学校でのひよっこか。
この、ソロモンの悪夢と呼ばれた私にはかなうまい！
こんな感じ。
どれが好き？
【体得】 完全に会得(えとく)して身につけること
【修得】 習いおさめて会得すること
【習得】 習って覚え込むこと
辞書房ウザイ
ハイハイ 余計なお邪魔、申し訳ござらん。
じゃ また不毛なファイトにお戻り下さい。 出番ですよ >>逝って良しの１
消えろ
>>531 おまえとは濃い話ができそうにない。去れ
自作自演大変ね。
536 ：
デフォルトの名無しさん：02/08/09 22:51
ＯＯが何なのか教えないと絶交だぞ！
なんてセンスのないレスだ･･･
ｏ
/ ￣￣￣￣￣￣￣￣￣￣ /
/ このスレは無事に /
/ 終了いたしました /
/ ありがとうございました /
/ /
/ モララーより /
/￣￣￣￣￣￣￣￣￣￣￣/
∧＿∧ / /∧＿∧
（ ･∀･） / /（･∀･ ）
（ ）つ ⊂（ ）
｜ ｜ ｜ ｜ ｜ ｜
（_＿）＿） （＿（＿_）
逝って良しの１の手によってまたスレが荒れるだろう。
もし逝って良しの１がこのスレに書きこまなかったらオレの負け。
541 ：
逝って良しの１：02/08/09 23:19
>>511 「生産性が高いと言われている」かどうか知らんが、高いなら正しい。
>>512 前半：
正確には「同じソフトを作らせて完成までの時間を計る」方法でいける。
現実的には「同じようなソフト」や「数多くのプロジェクトのサンプリング」だな。
後半：
再利用性を含めない生産性を「単発の開発効率」
含めたのを「継続開発効率」
保守費用は「保守効率」とする。
>>513 氏ね
よし、オレの勝ち。俺って天才？
うん。
544 ：
デフォルトの名無しさん：02/08/09 23:56
>>541 前半：
「完成」ってのは、何をもって「完成」とみなすんですか？
自己申告？それともバグが完全にゼロになるまで？
後半：
君の定義によると、正しいか正しくないかの判定基準には
信頼性や頑健性や可読性や可追跡性や安全性は関係ないって事なのか？
545 ：
逝って良しの１：02/08/10 00:01
前半
一連の定められた検査を通った後。
後半
関係有ります。分類が細かくなり、それぞれの測定方法になるだけ。
つうか、これぐらい常識だと思うが？
議論になると「正確な定義」を持ち出し、決して納得しないのは厨房の証し
なので止めておいた方が良い。
>>545 あまり読んでないが、たぶん同意。
ただ、「逝って良しの１」ってのがなぁ。
「狼がきたぞー」って何回もウソついて本当に来たとき信用されなかった少年の話知ってる？
こいつ、たまにいいこと言う（今までに３回くらい）んだけど、
いかんせん、それ以外の微電波の数が多くてなぁ…
548 ：
逝って良しの１：02/08/10 00:13
何回も嘘ついた？
なにそれ？
多分本人は真面目に言ってるんだと思うけど・・・・
時々車輪が側溝に落ちるんだよね
>>546-547 お前らのレベルの低さの方が驚く。
カラスは黒い程度のことしか言ってないだろが。
553 ：
逝って良しの１：02/08/10 00:19
生産性の定義に文句があるならＯＯ教徒に言えや。
最初に言い出したのは奴らなんだから。
ﾎﾟｶ-ﾝ っと。
>>552 俺が反論したとでも因縁つけたいのか？
デザパタ最高が馬鹿丸出しなのと同じで、
テストの基本の基本で「いい事言う」とか
いってんじゃねーよって事。
558 ：
逝って良しの１：02/08/10 00:26
ｳﾞｧｶを例にあげれば誰だってｳﾞｧｶだと思うさ。
562 ：
逝って良しの１：02/08/10 00:33
>>559 トップページ見たらi-mode用じゃないです。
５６歳くらいの人だったり・・・
逝って良しの１の行動
ＯＯ関連のサイトを検索する
見つかったサイトがまともなら見なかったことにする。
見つかったサイトがまともじゃないならＯＯ信者はこんな奴と思い込む。
結婚式に呼ばれたら、絶対に「３つのふくろ」とかスピーチするな、
>>558のページのひと。
566 ：
逝って良しの１：02/08/10 00:41
おふくろ、こぶくろ、きゃんた(略)
えぴすてーめーってどういう意味？
>>569 結構有名だよな。でも変な文字の人って言われてそう。
えぴす == 2ちゃんえら？
(;´Д`)ﾊｧﾊｧ
572 ：
デフォルトの名無しさん：02/08/10 07:16
>>545 そういう君が、信頼性や頑健性や可読性や可追跡性や安全性をさしおいて
>>510 > 正しいか正しくないかの判定基準も「生産性」だ。
といってるから、
君の言う「生産性」ってのは信頼性や頑健性や可読性や可追跡性や安全性を含むのかどうかを訊いてるんだけど？
アクワイアのゲーム「侍」は C++ で OO してるそーだ。ウチも C++ 主流だけど。
574 ：
逝って良しの１：02/08/10 09:33
>>572 へーそういうのは生産性に入らないと思ってるんだ
ヴァカ？
575 ：
逝って良しの１：02/08/10 09:38
「さしおいて～いっている」つうのはアンタ先入観のもたらした妄想。
こっちは「関係有る」つってるのに。
コイツ論理的思考力無いヴァカ。
BASE64な関数を求めて三日間探し続けました♪
生産性悪いと思うが。
577 ：
逝って良しの１：02/08/10 09:55
578 ：
逝って良しの１：02/08/10 10:10
本題に戻るが
>>568 ＞プログラムの部品化
＞これまでのプログラミング言語では、あるシステムを記述していく場合、
＞いわば何もない状態から始めなければなりませんでした。
＞プログラムを作るたびに、同じような目的のサブルーチンを作らなければ
＞ならなかったのです。
典型的なＯＯ詐欺の手口じゃん。
つうか、俺は典型的なＯＯ詐欺のＨＰを探していたのだがＴＨＸ。
>>578 今更だな。
誰もが感じたことがあるはずだよ。
クラス書くのめんどくせー！
って。
クラス使うのは楽。作るのはしんどい。
夏休みの宿題、先にやってればいっぱい遊べる。
子供の時に学んだはずだ。
そんな当たり前のことを詐欺と言われても困ると思うぞ。みんな。
580 ：
逝って良しの１：02/08/10 10:27
>>579 書いてあることの意味が良く判らないが、
従来言語でも部品化は行われていた。
同じようなサブルーチンを汎用化して二度と書かないようにする事も行われて
いた。
だから
>>568のＨＰに書いてある事は初心者を騙して洗脳する為の
ＯＯ派の典型的な嘘。
>>578 >>83 で既出
ところでさ、電波って回ってるんだよ 電界と磁界が回転してやってるんだ、ぐるぐるって
>>580 はいな、ライブラリね。
でも、ポリモルフィズムで同一手順で異なるアルゴリズムを選択できる。
とかメリットもいくつかあると思うけどね。
単純に、機能ごとにクラス名という名前空間を与えられることはライブラリを
組み合わせなければいけない局面で便利だと思われ。
>>582 それは、関数ポインタを使って構造化プログラミングの範囲で実現出来るよ
たとえばさ、qsortって関数は比較関数という手続きを引数に渡してるでしょ？
それと同じく qsortという手続きを呼び出してる場所でアルゴリズムを変えたければ
関数ポインタによる間接呼び出しに変更しればいいだけ
>>583 うむ、割と納得。
で、下の方はどう思う？
>>584 それは名前空間で解決出来る
ModulaとかObjectPascalは 早くからユニット・モジュール単位の名前空間を提供していた
名前が喧嘩する事は Cの欠点だけど、
Cの場合も、ソースがあるなら喧嘩した時に #define マクロを使って名前を変換してしまう
事が出来る
>>585 ところで、そこまでOOライクなことを非OO言語でやるメリットって挙げられますか。
逆に言えば関数ポインタ駆使でできることをクラスでやっても何ら問題ないわけで。
今までので全部できるから新しいのは要らない。
間違ってはい無いと思いますが歯ブラシがあるからと電動歯ブラシを否定しているようにも聞こえます。
そこまで非OOにこだわる理由はなんでしょうか。
>>586 オブジェクトライクならいいけど、オブジェクトを指向するのが嫌なんだよ
電動歯ブラシをたまに使うのはいいよ。 でも電動歯ブラシだけ使えって言われた嫌なんだよ
歯ブラシだけじゃなく必要な時には歯間ブラシやワイヤーも使うし
なけりゃ指で磨く事もあるさ
588 ：
逝って良しの１：02/08/10 10:53
589 ：
逝って良しの１：02/08/10 10:54
はじまるのも 逝って良しの１
おわるのも 逝って良しの１
ああよきかな かなしかな
>>587 いや、割と納得できた。
何でもかんでもオブジェクト指向は俺も疑問。
適材適所。これだね。
まぁ、それがわかってない言語厨とか指向厨がいるから問題なわけで。
古い人間と新しい人間を振るいに掛けているようだ。
593 ：
逝って良しの１：02/08/10 11:26
ＯＯは論理的思考能力の無いヴァカを集めるゴキブリホイホイみたいな
もんだな。
594 ：
デフォルトの名無しさん：02/08/10 11:27
595 ：
デフォルトの名無しさん：02/08/10 11:33
OOってバブルみたいなモノだな。
ま、普及しないで終わるでしょう。
596 ：
デフォルトの名無しさん：02/08/10 12:27
>>574 普通ははいらんだろ(藁
相互に関連があるけど、それぞれ独立した概念だ。
そんな事も知らんのか？本当に逝ってよしだな。
で、「生産性」だけを取り上げて、それのみで「正しいかどうか」など決めようというのは
アフォ以前の問題だぞ。
いってみれば、「車の設計手法が正しいかどうかは最高速度で決まる！」と言ってるようなもんだ。
597 ：
逝って良しの１：02/08/10 12:33
>>596 だからその「単純な生産効率」だけ取り上げてるのはアンタ。
598 ：
逝って良しの１：02/08/10 12:36
まあ、どんな測定方法でも純ＯＯは非純ＯＯに劣るので定義など問題にならないが。
>>598 同意。
何でも純粋には無駄があるものだ。
600 ：
デフォルトの名無しさん：02/08/10 12:40
>>597 それらの概念は相互に関連はあるが、一方が他方を含むことはない。
この程度の事も理解できないほど論理的思考に欠けてるんだね。
OOどころかプログラミング自体ちゃんと理解できてるのか怪しいもんだ。
601 ：
デフォルトの名無しさん：02/08/10 12:42
エスペラントっていう医者が世界中の共通言語を
作ったんだけど結局普及しないで終わった。
結局、実用的でなく必要なかったからだ。
OOもその道をたどることになるでしょう。
結局クラスライブラリ止まりじゃん。
>>600 sleep-interrupt でスレッド間通知やってるような奴だからな。
604 ：
逝って良しの１：02/08/10 12:46
605 ：
デフォルトの名無しさん：02/08/10 12:54
>>604 ポカーン…
こいつ、マジで生産性が安全性や頑健性を含む概念だと思ってるのか…
606 ：
逝って良しの１：02/08/10 12:55
607 ：
デフォルトの名無しさん：02/08/10 12:55
結局マイクロソフトがNTでC++を採用しなけりゃ
C++もOOもし萎んでいたのに。
>>600 あんたのやってること、そうとう非生産的だね。
>>607 バカにしようと思ったがObjective-Cのことがあるからなぁ。
610 ：
逝って良しの１：02/08/10 12:58
>>605 会計を少しでもかじった人（かつ論理的思考力のある）なら当然含まれると
考える。
生産性は確かに安全性などを含む概念ではない。
だが、生産性が高いということはやはり安全性などをある程度
含んでいないと生産性高いと言うｌｅｖｅｌには到達できない
>>611 同意。５分でできても同時起動するとデータファイルぶっ壊すソフトはな。
会計をかじらないとプログラミングできないんですか？
かじるとおいしいですか？
生産性を辞書で引いてくれよ
↓
615 ：
逝って良しの１：02/08/10 13:21
マトモな社会人なら関係無くてもかじるくらいはする。
もう忘れたが。
616 ：
逝って良しの１：02/08/10 13:22
大体、俺の問題提起における定義なんだから俺定義で良いのだ。
生産性言いたいだけちゃうんかと・・・
619 ：
逝って良しの１：02/08/10 13:37
>>617 >>544は論理的に検討する為に「俺のいうところの定義」を逆に聞いて来た
純粋に論理的に考えるなら、あとはその定義にしたがって検討するのが
論理的思考能力を持つ者の自然に取る態度。
明らかに定義そのものが矛盾しているならともかく、
人の定義にごちゃごちゃインネンつけるのは頭が論理的でない証拠。
定義の話はおしまい。
620 ：
逝って良しの１：02/08/10 13:40
正しいか正しくないかの判定基準も「生産性」だ。
これが判らない奴は社会人やる資格なし。
論理的思考能力を持つ者＝都合の良い馬鹿
622 ：
逝って良しの１：02/08/10 13:45
およそ全ての企業は利益を出すことを第１目的にしている。
会社で働く人間の第１原理は「単位時間あたりの利益を最大にする」
これだけだ。
従って、言語選定の判定基準は「生産性」以外にありえない。
これが判らない奴は社会人の資格がない。
>>622 それは基本的に間違っているよ
およそ全ての企業は社会への貢献とか奉仕を第一目的にしてるよ
嘘だと思ったら登記簿とってみてごらん
>>619 いや、君の
>>510の記述がどうにも変なんで、
これは用語を変な意味で使っているからじゃないかと思ったんだ。
それで、どういう意味で使っているのか訊いてみたんだけど、
案の定、変な意味で使ってたわけだ。
625 ：
逝って良しの１：02/08/10 13:58
>>623 んじゃ来月から給料返上して社会の為に使ってもらいなさい。
>>622 ゲスだねえ
そういうのは真摯に生きてる奴がタマに言うから許されるんだよ
ポンチ絵しか書けない奴はイカレポイチって呼ぶのさ
ゲスなセリフにしらけてみても、世の中みわたしゃゲスばかり
思い出すのはこのセリフ
宇崎 竜童：金が仇の世の中で 夢を追う奴あ莫迦なのか
628 ：
デフォルトの名無しさん：02/08/10 14:19
>>625 まずは、糞コードを書き散らすばかりで全然役に立っていないクセに
「 正しいか正しくないかの判定基準も生産性だ。」
などとプププな事を言う
>>625が給料を返上するべきだと思います。
629 ：
逝って良しの１：02/08/10 14:23
>>626-628 を翻訳すると
「そんなことされたら詐欺師の俺は商売あがったりだ。」
だな。
人生真っ直ぐに生きられる奴ばっかじゃあない 斜めに生きるしかない奴もいるさ
正面向いて生きてりゃ、譲る事もあるし遠回りもあって当然
でもさ、斜めにしか見られないのは それは違うんじゃない？
631 ：
逝って良しの１：02/08/10 14:29
まっすぐ正しくＣ言語
>>631 まっすぐ正しいのは、むしろModula-3だな。
まっすぐ正しく完全武装なC++。
ｹﾃｰｲ。
635 ：
逝って良しの１：02/08/10 14:43
昨日、近所のFreeBSD.org行ったんです。FreeBSD.org。
そしたらなんかマイナー言語マニアがめちゃくちゃいっぱいで重いんです。
で、よく見たらなんか垂れ幕下がってて、Delphi最高！、とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、Pascal如きで普段来てないFreeBSD.orgに来てんじゃねーよ、ボケが。
Pascalだよ、Pascal。
なんか親子連れとかもいるし。一家４人でFreeBSD.orgか。おめでてーな。
よーしパパマシン語で組んじゃうぞー、とか言ってるの。もう見てらんない。
お前らな、「よくわかるDelphi」やるからその席空けろと。
FreeBSD.orgってのはな、もっと殺伐としてるべきなんだよ。
JAVAマニアやC言語使いといつ喧嘩が始まってもおかしくない、
ハックするかされるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっとアクセスできたかと思ったら、隣の奴が、やっぱ Modula-3でしょ、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、Modula-3なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、Modula-3でしょ、だ。
お前は本当にModula-3で組みたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、Modula-3って言いたいだけちゃうんかと。
FreeBSD.org通の俺から言わせてもらえば今、FreeBSD.org通の間での最新流行はやっぱり、
C、これだね。
C++でなくC。これが通の組み方。
Cってのは関数が多めに入ってる。そん代わりオブジェクトが少なめ。これ。
で、それにハイスペックマシン。これ最強。
しかしこれで組むと次からメモリ破壊が容易という危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、BASICでも組んでなさいってこった
http://www.geofront.magisystem.net/misc/others/yoshi-comp.txt 636 ：
逝って良しの１：02/08/10 14:45
良く判らんが、Modula-3つうのは「つゆだく」みたいなものらしい。
良く判らんが、ハジカシイの？ それハジライ表現？ 結構可愛いとこあんじゃん
>>635 君、Modula-3使った事ないんじゃない？
あれはいい言語だよ。
型システムの綺麗さを筆頭に安全性を確保しながらも、unsafeなコードを許容する幅もある。
GCもあるが、unsafeなモジュールで自前でメモリ管理することもできる。
モジュールの仕様も、実装とインターフェースの分離がしっかりしている上に、再コンパイルを最小限にしてくれる。
最適化の研究なんかでも、時々題材として使われてるね。
639 ：
逝って良しの１：02/08/10 14:55
俺が良く判らんもの＝世界が必要としていないもの
>>635 Cが関数多めでオブジェクト少なめ？
そんな事ないだろ？int型のauto変数のメモリ領域だってオブジェクトだぞ。
結論： かなり出来の悪い吉牛コピペと言わざるをえない。
641 ：
逝って良しの１：02/08/10 15:01
コピペにマジレスされても・・・
642 ：
逝って良しの１：02/08/10 15:02
俺がマジレスすると電波扱いされ、
電波飛ばすとマジレスがかえってくるのは２ＣＨの仕様ですか？
>>642 普段から電波を飛ばすことがなければ、そのような扱いはうけぬかと。
というか、キミの属性
>>641 そのコピペの出来が悪いと指摘されている事に気付かないのか？
>>642 > 俺がマジレスすると電波扱いされ、
つまり君は電波だということですね。
>>243 設計つうのは、モノを作る前にやるというタテマエがあって、
でも実際にはモノを作ったあとにやるヤシだろ。
>>622 およそ全ての企業は利益を出すことを第１目的にしている。
会社で働く人間の第１原理は「単位時間あたりの利益を最大にする」
これだけだ。
従って、言語選定の判定基準は「生産性」以外にありえない。
これが判らない奴は社会人の資格がない。
647 ：
デフォルトの名無しさん：02/08/10 15:21
昨日、2chのOO撲滅スレ行ったんです。OO撲滅スレ。
そしたらなんか電波飛ばしてるヤツがめちゃくちゃいっぱいで話に入っていけないんです。
で、よく見たらなんか垂れ幕下がってて、「逝って良しの、木村よしの」とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、女如きで普段来てないOO撲滅スレに来てんじゃねーよ、ボケが。
木村だよ、木村。
なんか親子連れとかもいるし。一家４人で2ちゃんねるか。おめでてーな。
よーしパパおっぱい揉んじゃうぞ～、とか言ってるの。もう見てらんない。
お前らな、俺の秘蔵のCD-Rやるからその席空けろと。
OOスレってのはな、もっと殺伐としてるべきなんだよ。
使えない新人や口先SEといつ喧嘩が始まってもおかしくない、
AA荒らしになるかならないか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっとアクセスできたかと思ったら、隣の奴が、やっぱ 生産性 でしょ、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、生産性なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、言語選択は生産性、だ。
お前は本当に言語選択してるのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、生産性って言いたいだけちゃうんかと。
OO通の俺から言わせてもらえば今、OO通の間での最新流行はやっぱり、
多相性、これだね。
生産性でなく多相性。これが通の組み方。
多相性ってのは色んな顔を持ってる。そん代わりオーバヘッドが多め。これ。
で、それにC++。これ最強。
しかしこれで組むと次から先輩PGにマークされるという、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、インターフェースの継承で組んでなさいってこった
なんだこの馴れ合いスレは
649 ：
デフォルトの名無しさん：02/08/10 16:15
>>1の言う通り、OOは使えないということで
結論が出そうですね。
ｱﾌｫには使えないことくらい見てたら分かります。
おいしい所だけ頂いて、日々の仕事が少し楽になれば、それでええよ。
勤労青年なら
私がオブジェクト指向する事で、世の中の
皆様の為に少しでもお役にたてるのでした
ら喜んで オブジェクト指向に身を捧げさ
せて頂きます
653 ：
逝って良しの１：02/08/10 18:35
>>650 アフォは「自分はＯＯ使える」
と勘違いしてる奴が圧倒的に多いのを知らないのか？
>>650 アフォは「自分はヒョデーイを使える」
と勘違いしてる奴が圧倒的に多いのを知らないのか？
655 ：
デフォルトの名無しさん：02/08/10 18:56
オブジェクト指向の理解の仕方も十人十色だね。
結論は言わないでくだしい。
アフォが釣れなくなりまふ。
おまいら全員Averages
>>646 製品として出すなら生産性より品質の方が優先されるのでは？
個人でソフト作るなら生産性の方が大事。
高いほど凄いソフトが簡単にかける。
660 ：
逝って良しの１：02/08/10 20:55
んー、例えば経済学で言うところの労働生産性だと、
「単位時間当たりに生み出した価値」
だから品質も入る。
市場原理が働いていれば低品質＝低価格：価格∝消費者にとっての価値だからね。
価値の低いものを生産しても低い生産性にしかならない。
>>660 なるほど。経済学も教養で取らなきゃ(w;
ということは企業では作りやすさと品質のバランスが大事ってことかな。
>>661 この業界を志望してるんなら妙な先入観持たずに飛び込んだ方がいいよ。
大学ってのは「社会人になってから役に立つ知識」を求める場所じゃない。
卒業可能な単位を確保したら自分の興味の赴くままに好きなこと勉強しなさい。
10年後にはそれが思わぬところで人生の肥やしになっていた事に気づくはず。
>>660 経済学とソフトウェア工学では扱う対象が違うんだから、生産性の定義も違うにきまってるだろ。
とりあえず
>>661は、
>>662が言うように自分の興味の赴くままに勉強すればいいけど、
ちゃんと異なる分野の間ではしっかりとどの分野のどの概念が他の分野の何に相当するのか
ちゃんと理解できるように意識して勉強してね。
そっちのほうが単一の学問だけを学ぶよりよほど大事だ。
もっとも、逝って良しの1は何も学んでいないみたいだけど。
664 ：
逝って良しの１：02/08/11 00:54
＞んー、例えば経済学で言うところの
という文字が読めない御方がなにかほざいております。
逝って良しの１にここまで言われた奴も珍しいな（ｗ
というか、逝って良しの１はなんでこんなにムキになるんだ？
OO使いに会社でバカにされた？
いや、女を寝取られたとか？
そりゃねーか。
667 ：
逝って良しの１：02/08/11 01:58
獣の数の人に言われたくないです。
もともと女なんてできっこないんだからそれは無いだろう.
大方OOが理解できずにリストラにでもあったんじゃないか?
あんまり問い詰めると泣いちゃうかもしれないよ（ｗ
>>669 そうだね, 可哀想だからやめとこうか.
671 ：
デフォルトの名無しさん：02/08/11 02:07
>>664 だからさ、
> 経済学とソフトウェア工学では扱う対象が違うんだから、生産性の定義も違うにきまってるだろ。
という文字が読めない白痴が何かほざいててもねぇ…
>>669 いや、どのみち言葉を理解してないんだから、泣き出したりしないだろ。
つーか、泣きだすんなら、このスレの前半でとっくに泣きだしてると思われ。
>>671 逝ってよしの１が可哀想だからやめてやれってw
674 ：
逝って良しの１：02/08/11 02:12
そうとう悔しいらしいなｗ
675 ：
逝って良しの１：02/08/11 02:14
じゃあ、その「ソフトウエア工学における生産性の定義」とやらを示して
もらおう。
どう定義しても純ＯＯは非純ＯＯに劣るとすでに述べた。
>>674 誰が悔しがってんだよ, 日本語読めってw
このスレの中で一番悔しがってるのはお前だよw
みんな、逝って良しの1のことが好きなんだね。
We love Itteyosi_no1
679 ：
デフォルトの名無しさん：02/08/11 02:32
>>675 生産性はソフトウェア生成プロセスの実行効率を表わす概念だよ。
大別して、組織的生産性と個人的生産性があるね。
その差は再利用がおこなわれた時に、特に顕著になる。
680 ：
逝って良しの１：02/08/11 02:39
細かい話してもしょうがないが、
１）明らかに違う人との話を同じ文脈で捉えるほうが脳が腐っています。
２）さらに話の区切りをつけるために「んー例えば経済学でいうところの」
と断りを入れました。
>獣の数の人に言われたくないです。
まさか番号にケチ付けるとは、OO叩けるんなら理由は何でもいいってこったな。
ご苦労さん。
>>666 あ, そういう意味だったのね.
666の番号の意味は知ってたけど.
なんで獣なの？
684 ：
逝って良しの１：02/08/11 02:54
685 ：
逝って良しの１：02/08/11 02:56
聖書にそう書いてあるから＞獣の数
「サタンは獣の数を持ちそれは６６６である」とかなんとか
学があるなぁ
おおかた後藤勉の本でも読んだんだろ。
688 ：
逝って良しの１：02/08/11 03:02
将来人類を滅ぼす為に現れる悪魔の使いを予言した章で
「人々を惑わすもの」が６６６の数を持っているとかだった。たしか。
689 ：
デフォルトの名無しさん：02/08/11 03:08
691 ：
逝って良しの１：02/08/11 03:17
Ｃの方が再利用単位を小さくできる。
単位が大きくなれば再利用できる可能性が低くなる。
なぜならば、より基本的で単純なモジュールほど全く異なるプログラムでも
使用できる可能性が高いからだ。
ＯＯＰＬだとクラス以下の単位は再利用できず、
クラスを小さくするのに限界がある。
よってＣの方が再利用性が高いモジュールが作れる。
>>961 サイズよりも、独立の度合いが重要だと思う
694 ：
デフォルトの名無しさん：02/08/11 03:29
>>691 正しい。ただし、再利用性が高いことは、必ずしも使い勝手の良さや
開発効率の高さを意味しない。
695 ：
デフォルトの名無しさん：02/08/11 03:30
>>691 あのー、君の言う、純粋OO言語であるSmalltalkでは、クラス以下の単位でも
バンバン再利用するのが流儀なのよ。それこそ変数名まで再利用する。
SmalltalkはXEROX PARCで育った言語だが、
まさに「ゼロックスのコピー文化そのものだ」と揶揄されてきたんだよ。
Workspaceで書き溜めていったコードからいくつかの部分を切り出して
くっつけてメソッドを書く、みたいな事がよく行われていたんだ。
C プ ロ グ ラ マ が や る よ り も ず っ と 遥 か に 頻 繁 に ね 。
俺はCの方が再利用単位を小さくできるって意見に不同意なんだが….
誰か例をあげて説明してくれないか?
697 ：
デフォルトの名無しさん：02/08/11 03:39
>>691 Cにおいて関数を再利用できるのと同程度に、
OOPLでもメソッドを再利用できる。
よって
>>691はマチガイ。
698 ：
逝って良しの１：02/08/11 03:47
>>698 サブルーチンやマクロね.
>>697が言うように, OOPLでもメソッド単位の再利用が可能なので
利点とは言えない.
>そのメソッドの使い方はOOではない
OOでプログラムを書いていてメソッド単位の再利用をすることは
往々にしてあるが.
700 ：
デフォルトの名無しさん：02/08/11 03:51
>>698 > その言語知らないのでなんとも。
Smalltalk知らずに純粋OOの生産性うんぬんを語っていた！？
>そのメソッドの使い方はＯＯではない。
はあ？
何故それがOOではないのか根拠を示してよ。
メソッド単位での再利用とOOとの矛盾点とかさ。
>>700 何げにキリ番ゲットだね, おめでとう.
俺はSmalltalkを知っていて(実際に実務に使用したことがないとしても),
それを前提に語っていると思っていたんだが. > 逝ってよしの１
702 ：
デフォルトの名無しさん：02/08/11 07:49
かわいそうな逝って良しの1たん...
ネタキャラにしても叩きすぎじゃない？ > 1以外all
え？ 少なくとも３人くらいで演じてるんだろ？
>>703 なるほど。鋭い指摘だね。たしかにそんな気がしてきた。
もしそうじゃないんだとしたら、ちょっと俺、叩きすぎたかも・・・・
706 ：
デフォルトの名無しさん：02/08/11 11:27
707 ：
デフォルトの名無しさん：02/08/11 13:26
このスレのせいでOO厨が精神的に不安定
になってきております。
708 ：
逝って良しの１：02/08/11 15:52
>>701 Smalltalkなんて言語ヲタしか使ってないようなのは除外。
>>707 ホント。ＯＯ厨の叩きレスばっかだね。
余裕の感じられない。
閑話休題――
710 ：
デフォルトの名無しさん：02/08/11 16:29
>>708 じゃ、具体的にどの言語を指して純粋OO言語の生産性を語っていたんだ？
711 ：
逝って良しの１：02/08/11 16:33
純粋OO言語の生産性など話題にした覚えはありません。
713 ：
逝って良しの１：02/08/11 16:54
「言語」という余計な文字が追加されて意味が変わっているんだが
714 ：
デフォルトの名無しさん：02/08/11 16:57
OOは10万行程度の小規模開発には必要ありません。
つまり通常の開発にはOOは必要ないと思います。
OO使わないってのは、JavaもC++も使わないで、今時Cで開発？
ご苦労さんですなあ。
C でも OOP は（以下略
C++よりコード量が増えて複雑になって面倒くさくてバグを埋め込みやすいが出来ないことも無い。
だから、OOP言語はgood OOは糞だって話なんだろ ？
>>715 つーかOOって使い方するな。話がごちゃごちゃなる。
これからはOOA、OOD、OOPと書き、すべてを表すOOはちゃんと
OOA/OOD/OOPと書くこと。日本語でも可。
そのご提案は却下します
721 ：
デフォルトの名無しさん：02/08/11 18:08
>>711 じゃ、君の言う「純ＯＯ」ってのは具体的に何を指しているんだ？
純一郎
>>719 スレタイにオブジェクト指向って書いてあるんだから
別にＯＯでいいじゃん。特に区別したいときは
ＯＯＡ/ＯＯＤ/ＯＯＰって書くだろうよ。日本語のできない
香具師はすっこんでろ。
＞日本語のできない香具師
おまえだろ
OO を否定する文脈では区別しないで書かれることが多いんだよね。
実例も比較対照も挙げずに 「効率が悪い」 「生産性が劣る」 とばかり。
726 ：
逝って良しの１：02/08/11 18:42
純ＯＯ＝全てのモジュールがオブジェクト
非純ＯＯ＝オブジェクトでないのも含む
やっぱり下らない話合いですね。
匿名で自分の好きなことしか発言してないのに結論なんて出るわけ無い。
728 ：
デフォルトの名無しさん：02/08/11 19:07
729 ：
デフォルトの名無しさん：02/08/11 19:11
>>726 そこでいうOOはOOA？それともOOD？それともOOP？それとも全部？
>>727 結論はOOは有効とでてる。その状態でアンチOOが否定し続けてるだけ。
731 ：
逝って良しの１：02/08/11 19:20
ＯＯ厨は茶化すことしか出来なくなった模様。
逝って良しの１は茶化してばっかりだがな
733 ：
逝って良しの１：02/08/11 19:29
中間報告１
ＯＯは戦場では役に立たない。
まともにＯＯで設計できるのは１０人に一人も居ない。
純ＯＯで組もうとすると破綻する。
中間報告２
ＯＯは戦場であろうがなかろうが基本的に詐欺である。
純ＯＯではなく混在モデルが最も効率が良い。
中間報告３
ＯＯジャンキーという厨が存在する。
効率が落ちているのに 幸福感に浸り、「効率が上がった」などと
事実と異なる報告をする 現象が観測された。
734 ：
名無しさん＠Ｅｍａｃｓ：02/08/11 19:32
中間報告１
逝ってよしの１は戦場では役に立たない。
逝ってよしの１はろくに設計もできない。
純逝ってよしの１はOOで組もうとすると破綻する。
中間報告２
逝ってよしの１は戦場であろうがなかろうが基本的に詐欺である。
純逝ってよしの１ではなく混在モデルが最も効率が良い。
中間報告３
逝ってよしの１ジャンキーという厨が存在する。
効率が落ちているのに 幸福感に浸り、「効率が上がった」などと
事実と異なる報告をする 現象が観測された。
>>733 そこでいうOOはOOA？それともOOD？それともOOP？それとも全部？
>>735 必要ないのはOO全部 使えるのは OOP言語だって何度言えば判るんだ？
OOPじゃなくてOOP言語ね！
>>733 そもそも, こんな書き方しかできない時点でダメな奴だろ.
自分の理論に自信・確信があるならキチンと議論で論破(漢字あやすぃ)
できるはず. それを返す
>>734もどうかと思うが.
738 ：
デフォルトの名無しさん：02/08/11 20:14
つーかこのスレ伸びがいいなぁ。
>>738 なんだかんだ言ってみんなOOが好きなのさ…(違.
わけはなげ(違
>>736 > OOPじゃなくてOOP言語ね！
なにゆえにOOPLじゃないのかと小一時間（略
742 ：
デフォルトの名無しさん：02/08/11 23:15
全てのモジュールをオブジェクトにすべし。
これがオブジェクト指向の基本。
逝ってよしの１はクラスを構造体だと思い込んでるバカ。
>>742 > 逝ってよしの１はクラスを構造体だと思い込んでるバカ。
VC++だとデフォルトのアクセス指定子を除けば、それであってるけど。
VC++だと
>>743 そう意味じゃなくて
クラスという概念を(C言語の)構造体の拡張だと思い込んでるってこと。
>>743 ついでに言うと、vcだけじゃなくてc++の定義でそうなってる。
ちなみに、c++では構造体（というか、struct）もクラスだよ。
ここは実装と概念の違いもわからねぇバカがいるスレだね。
>>743 おまえのことだけど。
ね。
>>746 クラスとの違いはデフォルトがpublicであること。
クラスとの違いがある時点でそれはクラスなのか？と揚げ足。
と、人のふんどしで人をけなすだけの
>>747さんでした。
僕たち、なんにも理解してないね。
誰か、理想的なOO設計をするお勉強の出来るWebSite教えてください。
>>750 ＞僕たち、なんにも理解してないね。
僕、つまり君だけだと思われ。
>クラスとの違いがある時点でそれはクラスなのか？と揚げ足。
C++定義のクラスとは違うかも知れないけど、
OOP定義のクラスと同義だと思うんだが、どうか。
publicデフォルトを採用してる言語だってあるんだし。
>>749 「と、人のふんどしで人をけなすだけの>>xxxさんでした。」
xxxは何番に置き換えてもよい文章だな。
お前の書き込みがもっとも無用だということさ。
>751
そーゆーことにしたいのですね。＆＆ 2行目にこたえてください。
>>755 そーゆーことにしたいのですね
は激しくfalseなので&&以降は評価されません。
そうでしたか。trueのひといませんかね。
うわっ、は、恥ずかしいスレ…。
誰ががんばってんのか知らないけど
ム板って、こんなところだったのか…。
多分そうだよ。
761 ：
逝って良しの１：02/08/12 01:18
>>759 本に書いてある事を絶対の真実と思いこんでるアフォにはそう思えるだろうね。
逝って良しの１が書いている事を絶対の真実と思いこんでる奴はアフォだね。
なんでそんな自信たっぷりに他人が便利に使ってる手法を
否定できるんかね？
まあ、否定するにも根拠なんて何も示してなくて、
俺が駄目だと思うから駄目、ばっかなんだけどな、
逝って良しの１よ。
逝って良しな人物だから当然
765 ：
逝って良しの１：02/08/12 01:50
ＯＯ厨は権威主義に毒されていて現実を見ていない。
（権威とは本や雑誌や偉い人の発言など）
ただひたすら、そのような権威からの情報を有り難がり、暗記するだけで
現実との照合を全く行わない、言わば老化した脳の持ち主ばかりである。
また、ＯＯ普及を機会に詐欺師の活動も活発化した。
仕事の出来ないＰＧがハッタリとＯＯ用語連発で上層部が騙される
例のなんと多いことか。
>>765 「権威主義」とやらを持ち出して批判するのは典型的な電波の言い種だね。
逝って良しの１の論理は良くOOに関わる人間の方を向いているが、
関わる人間にダメなやつがいるからその技術が駄目と言っているのは論理の
摺り替えそのもの。
何か問題が出たらその解決策を考えるのが賢い人だね。
臭いものに蓋をするって考えじゃだめだね。
769 ：
デフォルトの名無しさん：02/08/12 08:44
770 ：
デフォルトの名無しさん：02/08/12 09:12
そもそも個人レベルの1万行とかのプログラムで
オブジェクト指向設計が必要あるのか？
>>770 必要あるかどうかなんて聞かれたら、必要無いに決まってんじゃねぇか。
何が聞きたいんだ？
つまりさ、 ソフトウエア危機ってのは
馬鹿も利口も世の中いて当然、馬鹿に仕事させるにはどうすればいいかって問題をどう解決するかって事さ
で、一つの言語・ツールで解決する方法が オブジェクト指向 馬鹿はオブジェクト使っとけって事さ
他の有名な方法は、言語・ツールを別けてしまう事。 これはVBで大成功
で、困った事に、馬鹿は自分が馬鹿だと判らない。
VBだとVBから外に出ないからいいのだが オブジェクト指向だと、
この馬鹿が上流もやろうとしてしまうんだ
で、馬鹿だから何でもオブジェクトにしようとしたりもう無茶苦茶
こんなことになるんなら、
OOPLは使おう（既存のクラスライブラリも使おう)ぜ、でもさ
オブジェクト指向はやらんでおこうね ってのが大人の智恵って事さ
>>773 典型的なOO勘違いしてるやつの意見そのものじゃん。
Cで「おぶじぇくと指向」できても、OOPLでは『おぶじぇくと指向』
出来ないって主張ですか？＞逝ってヨシの１
馬鹿にはさわらせずに、自分で設計したらどうですか？
>>773 頭、イイんでしょ？
>>774 チームでやるとそういう訳にはいかないんだよ
モチベーションも維持させないといけないからね
>>775 結局「おぶじぇくと指向」の技術的な問題とかじゃなくて、
日本には教育の足りない馬鹿プログラマが多いってことだろ？
長くCで開発してきて、「おぶじぇくと指向」に拒否反応を示す
プログラマを腐るほど見たけど、そいつらの問題なだけ。
インド人プログラマにでも職場を追われて下さい。
おながいします。
>>776 そうだよ それが悲しい事に現実
でもさ、開発の現場の多くはアウトソーシング。
社内で蓄積しようなんて奇特な会社は極少
それに見合っといえば見合った現実なんだろね
778 ：
デフォルトの名無しさん：02/08/12 09:50
>>772 いや、ヴァカと本物をちゃんと峻別して
本物の方の作業効率をあげて全体の生産性を上げましょうってのも
ソフトウェア危機への対処法の一つなんだけどね。
まあそういう事だな 再利用性ってのは 馬鹿のコードじゃなく 本物のコードを再利用しろって事だな
>>778 ところが、日本じゃそれが出来ない。 だって給料同じ
781 ：
デフォルトの名無しさん：02/08/12 11:14
OO厨の机上の空論には呆れるね。ﾌﾟ
空気の読めない煽りは無視で。
>>778 > いや、ヴァカと本物をちゃんと峻別して
で、峻別する奴がヴァカだと目も当てられないことに．．．
>>783 いや、そうすると残ったのは峻別した奴も含めてヴァカばっかということになる。
ヴァカばっかのチームが目も当てられない状況になってアボーンしてくれたら
業界全体の質の向上に役立つのでは？
文系の方がOOはできると思うよ。ということは誰でもできるってこと。
787 ：
デフォルトの名無しさん：02/08/12 14:17
（´ﾟ∀ﾟ｀） OOが普及するっていってから何年経ってるんだ？
（´ﾟ∀ﾟ｀） 構造化分析設計が普及するっていってから何十年経ってるんだ？
そんだけｱﾌｫなﾔｼﾗが多いのよ。
構造化設計までは許せたけど 構造化分析はなあ・・・あれは金儲けの手段だろ・・・というか
今のオブジェクト指向屋に金儲け方法を指南したって意味じゃしっかり意味はあったんだろが
逝って良しの１まだ～？
792 ：
デフォルトの名無しさん：02/08/12 23:01
>>765 > ＯＯ厨は権威主義に毒されていて現実を見ていない。
> （権威とは本や雑誌や偉い人の発言など）
> ただひたすら、そのような権威からの情報を有り難がり、暗記するだけで
> 現実との照合を全く行わない、言わば老化した脳の持ち主ばかりである。
暗記するだけでプログラミングできると思ってるなら本当のバカ。
793 ：
逝って良しの１：02/08/12 23:20
「汝偶像を作るなかれ」
偶像とはオブジェクトのことなり。
>>792 暗記というより
本に書いてあることが理解できた = プログラミングできる
って香具師が多いのは事実
ドライブシュートの蹴り方を理解しても
ドライブシュートができるワケじゃないのと同じ
やっぱり実際に何度も蹴らないとね
>>793 クラスならともかくオブジェクト（＝インスタンス）は実態だと思われ。
日本人の大半は仏教徒で偶像崇拝が許されています。
キリスト教徒でも許されています。
神が人間を創ったのならOO信仰は神のご意志さ。
>>795 逝って良しの１ の話にもついていけない 逝って良しの１ 以下の可哀想なお人
799 ：
デフォルトの名無しさん：02/08/13 00:51
逝って良しの１まだ～？
800
801 ：
デフォルトの名無しさん：02/08/13 02:17
OOっつーものはクライアントに対する見せかけには
役に立つな。けど実際会社でOOの技術者を育てるのも
養うのもコストがかかるので避けたいとは思う。
>>801 養うコストは他と変わらないよ。
だって、OOなんて既に当たり前の技術だもん。
使えない香具師をクビにして、外から人を探してくればいいよ
(内部の人間を育てるのは難しい、なぜなら社内教育なんて嘘っぱちだからさ)
803 ：
デフォルトの名無しさん：02/08/13 05:22
OO厨の机上の空論には呆れるね。ﾌﾟ
OO使ってない職場とかあるの？
OO使うと同僚がコードを理解してくれないとか？
なんかそういう職場って嫌だな。
OOが構造化を含むんだったら、
どんなプログラマもOOしてるんですね？（嘲笑禿藁
807 ：
デフォルトの名無しさん：02/08/13 07:34
>>806 頼むからもう少し頭の悪くなさそうなことを書き込んでくれんか?
>>806 「頭のいい人」がきちんと構造化すると、OOPと実質同じになるよ。
ファイルスコープで隠蔽とか、関数ポインタの構造体で多態モドキ
なこと（いや、Cが先なんでもどき呼ばわりは失礼だが）とか、やる
でしょ？
>>808 > ファイルスコープで隠蔽とか、関数ポインタの構造体で多態モドキ
> なこと（いや、Cが先なんでもどき呼ばわりは失礼だが）とか、やる
> でしょ？
どうでしょ？Simula-67とか、現在のように洗練されていなくても
継承による多態は存在はしていました。
Cでも DLL作って処理する時には 相手には データ構造は教えずに
void *のポインタを用意させて
void *hoge=OpenHoge(引数);
HogeHage(hoge,引数)
みたいなのは、普通だしな
これをオブジェクト指向だななんて 呼ばないでくれ
だって FOpenから学んだんだから
ありゃ 大文字 FOpenは格好悪かった・鬱
>>810 つーか、多態だからといってオブジェクト指向なわけではないでしょ。
parametric polymorphismなんかはむしろ(非OOな)関数型言語だし、
operator overloadingやimplicit type conversionによるad-hoc polymorphismなんかはFORTRANからあるし。
>>810のCでの例はinclusion polymorphismの一種だね。
ただ、言語仕様でそれを積極的にサポートされてるかどうかは大きな違いだけど。
うぐ。訂正すまそ。
> parametric polymorphismなんかはむしろ(非OOな)関数型言語だし、
は、
> parametric polymorphismなんかはむしろ(非OOな)関数型言語のほうが主流だし、
に読み替えてちょ。
>>812 判ってくれたか。 Cでやってたように、オブジェクト指向もどきの事を C++ や Delphiでやってるだけで
オブジェクト指向をやってる訳じゃない。
それは似てるけど、俺たちはオブジェクトを指向などしたくないんだ
815 ：
デフォルトの名無しさん：02/08/13 08:58
> 787 名前：デフォルトの名無しさん 投稿日：02/08/12 14:17
> （´ﾟ∀ﾟ｀） OOが普及するっていってから何年経ってるんだ？
>
>
> 788 名前：デフォルトの名無しさん 投稿日：02/08/12 14:20
> （´ﾟ∀ﾟ｀） 構造化分析設計が普及するっていってから何十年経ってるんだ？
>
OOも30年以上の歴史があるんだけど・・・ね。
まあ方法としては確立されてはいるけど、
結局はイマイチなんだろうね。
816 ：
デフォルトの名無しさん：02/08/13 09:00
>>815 だからOOなんてバブルみたいなもんなんだよ。
>>814 つーかさ、君がやっていた(いる)事は
「オブジェクト指向もどき」じゃなくて「自作多態」って事なんじゃないの？
818 ：
デフォルトの名無しさん：02/08/13 09:09
>>816 （´ﾟ∀ﾟ｀） OO一生懸命勉強したのにね。お気の毒に。
あのさ
>>810 は これは多態じゃなくて いわゆるデータの隠蔽って奴だ
多態もどきにするなら、Hogeの中で関数ポインタを持たせて
void HogeHage( hoge , 引数){
hoge->MyFunc(hoge,引数);
}
とやるわけだけど、それは外からは見えない
>>819 いや、void *型に宣言した変数にいくつかの種類の構造型へのポインタを入れて、
それを関数に渡してやるんだろ？
つまり、
struct foo {
int sort;
int x, y, z;
....
};
struct bar {
int sort;
int x, y;
...
}
とかあって、
void * OpenHoge(引数)が引数に応じてstruct foo *を返すかstruct bar *を返すかが決まるとするよ。
void *polymorphic_var;
polymorphic_var = OpenHoge(何か適当は変数);
とすると、polymorphic_varの参照先にはパラメータに応じてstruct fooの値か
あるいはstruct barの値が入ってるわけでしょ。
これって、十分にポリモーフィズムだよ。
さらに、
HogeHage(polymorphic_var, ...);
とかすれば、この関数への第一引数がstruct foo *の場合もあるし struct bar *の場合もある。
これもやはりpolymorphismになる。
ここで、このpolymorphismを何polymorphismと呼ぶべきかだけど、
変数polymorphic_varの参照先が先頭のint sort;の内容で型を判定するとすると、
これは一種のstructural type equivalenceによるinclusion polymorphismと捉えることができる。
だから、「
>>810のCでの例はinclusion polymorphismの一種だね。 」と言ったわけ。
まあ、
>>810では複数の構造体を定義していないから
>>820は曲解の可能性もあるけど、
OpenHoge()の返り値の型をvoid *にしたのはそういう意味があったんじゃないかと思ったんだけど。
あと、HogeHageへの第一引数もvoid *の変数で渡してるし。
スマン、 そんな事より
>>820 を見ると foo/barの識別は sortでやるのか？
それなら enumにしてくれとか
それより関数ポインタ持たせてとか
そんなレベルの問題が気になってしょうがない
そのポリモーフィズムの話は、なんか俺が齧ったのとは違うようだが
あんまり興味ない
>>822 > スマン、 そんな事より
>>820 を見ると foo/barの識別は sortでやるのか？
> それなら enumにしてくれとか
> それより関数ポインタ持たせてとか
すまん。enumにしてくれってのはその通り。
関数ポインタについては、続きを見てくれ。
>>823の続き
>>822 >そのポリモーフィズムの話は、なんか俺が齧ったのとは違うようだが
実は同じだったりする。どっちもsubtypeによるinclusion polymorphismだよ。
たとえば
>>822が聞いたというポリモーフィズムは
t a;
a.message();
があったとすると、
・変数aには複数の型(型tのsubtype)の値が代入されている可能性があり、
・その値の実際の型に応じて実際に実行されるmessage()の実体が異なる
という話だと思う。
このうち1番目のほうは
>>820で書いた例と同じだということがわかると思う。
実はこれこそがsubtypeによるinclusion polymorphismだったりする。
それが(クラスベースの静的型付)オブジェクト指向言語では副次的に
・型tのsubtypeはメッセージmessage()を受け付けることができ、
・対応するメソッドはaの実際のクラスによって定義される
ということが自然な拡張というか、当然の結果というか、まあ、そういうことになる。
オブジェクト指向では、こちらの副次的な部分のほうが強調される事がままあるけれども、
型理論的には、本来ポリモーフィズムが意味するのは上のほうの1番目の機能だったりする。
関数ポインタを構造体に持たせるのはinclusion polymorphismなしで
その副次効果を実現させているわけだが、実はその究極の形を考えれば
関数ポインタ型の変数そのものだったりする。
実際の値によって実際に呼び出される関数がかわるっていう意味ではね。
というわけで、興味ないと言われながらの長文すまそ。
おまけに「だったりする」ばかりで本当に駄文だな。
重ねてすまそ。欝だ。
まあ、enjoy programmingということで。
826 ：
デフォルトの名無しさん：02/08/13 12:20
社内のオブジェクト指向設計で開発している
自己満足PGをクビにしたい。
コメントもドキュメントもないからなぁ。使えネーヨ。
827 ：
デフォルトの名無しさん：02/08/13 12:24
やはりオブジェクト指向という試みは失敗に
終わったということでいいんじゃないでしょうか？
>>826 クビにしてみたらいいと思います。
そのPGもまともな同僚に恵まれた環境を得て
いい仕事ができるようになるかもしれませんから。
またfopenバカがかきこんでるな。
「Cでもオブジェクト指向できるから、オブジェクト指向なんていらねぇよ」
この論理っておかしくねぇ？
結局、自分の今までのやり方が通らないから嫌なだけ。
それを必死で言い繕っても端から見てると哀れなだけ。
おまえらくだらねぇ
>>829 このすぐ上で言ってる事はそういう事じゃないように思うんだが？
832 ：
デフォルトの名無しさん：02/08/13 15:18
確かにここ最近OOが下火になってきて、
OOでも非OOでもこだわらない効率のよい環境や言語が
人気がでてきているのは確か。
＞OOでも非OOでもこだわらない効率のよい環境や言語
ってなあに？HSP？
C使いは帰っていいよ。
>>832 そうかい? 俺はそうは思わないよ.
OOが下火になってきたってのは分かるけど.
>>832 それってC++位しか該当言語が思い当たらないんだが、
全然C++の仕事無いぞ
>>836 うちはJavaが増えてC++が減った.
あと急増するPHP…w 俺の中では飽きたから惰性で書いてるなぁ….
個人的にはC++とJavaがもっと来てくれるとうれすぃ.
838 ：
逝って良しの１：02/08/13 21:30
うーん、サイクルがずれている会社があるな。
Ｊａｖａが増えてって・・・まだ・・・地獄を見ていない・・・かんじ。
クライアントがとにかくＪａｖａが良いと、どっかの雑誌なんかで洗脳されて、
で、発注して出来あがったモノ見てその遅さにクレームつけてくるパターンね。
「Ｊａｖａは遅いんです」つっても信じてもらえるまで地獄を見るか、
あるいは発注した馬鹿が責任をひた隠しにした結果その会社との取引ききられたとか
まあご苦労さんね。
>>838 > 「Ｊａｖａは遅いんです」
そうか？
VMの起動が遅いだけでJava自体はそんなに重いとは思わないけど。
マシン起動時にVMも同時に起動させれば特に問題はない。
遅いんだからしょうがない。
実際遅いのは認めるよ. 少なくとも今の速度のままならクライアントサイドの
アプリケーションは使いたくない. でもサーバサイドなら気にならないけど?
Javaはうちの開発部では2番目にクレームが少ない言語だし.
出来上がったものの遅さにクレーム付けられることは今までない. 発注かかる時に
パフォーマンスのデータは出すし(いや, 俺がやってるわけじゃないけど営業が).
出来上がったモノにクレーム付けられるなんて(Javaに限らず)営業がキチンと
仕事してないか, 開発の実力不足だろ. そんな会社辞めたほうがいいぞ.
で, ここまで話しといて何だけど, OOと遅さは関係ない.
843 ：
デフォルトの名無しさん：02/08/13 23:08
逝って良しの１さんへ
純粋OOPLがキライならそれでいいと思います。
ただ、Smalltalkerに代表されるような
すべてをオブジェクトとして考えるのが自然だと感じる人も
いるということを分かって欲しいと思います。
そういう人にとって純粋OOPLは使いやすい言語です。
>>843 > すべてをオブジェクトとして考えるのが自然だと感じる人も
> いるということを分かって欲しいと思います。
人間、清濁合わせ持つってのは大事だぞ。
所詮世の中グレーなんだ。
白か黒かなんてのは子供の自己満足。
両極端を選択するのは単純明快だが、
妥当な落としどころを模索するのがプロの仕事。
845 ：
デフォルトの名無しさん：02/08/13 23:58
SmallTalkと聞いて思い出す。
九州・・・（以下略）
846 ：
逝って良しの１：02/08/14 00:00
すべてオブジェクトは無理。
つうか、屁理屈みたいなクラスができる。
847 ：
デフォルトの名無しさん：02/08/14 00:03
>>846 激しく同感。
クラスの中でクラスを呼んだクラスがクラスを呼んで、
一度ループした事がありました。
・・・俺だけ？？
848 ：
デフォルトの名無しさん：02/08/14 00:04
そもそもOOでの設計は非OOよりも
トリッキーになりがちじゃない？
それをごまかすためのデザインパターン
850 ：
デフォルトの名無しさん：02/08/14 00:09
851 ：
逝って良しの１：02/08/14 00:10
>>847 今ナウいヤングなプログラマーの間で人気の「再帰」ということに。
853 ：
逝って良しの１：02/08/14 00:21
釣りって・・・
前にも誰か書いてたけど、javaのmathクラスなんか屁理屈だし
Systemクラスもオブジェクトとは言えないじゃん。
それからアプリケーションのメインのクラスもオブジェクトとは言えないし。
Javaはクラスを名前空間代わりに使ってるだけじゃん
そんなにシビアになるなよ。
C言語病 (C++病かも？)
オブジェクト イコール 構造体の中に関数を入れたもの
>>854 すべてをオブジェクトにという足枷が
本来のOOの概念を崩しているね
矛盾した事をいってるように聞こえるかな？
>>857 オブジェクトを構造体と結び付けるからおかしくなる。
オブジェクトという概念が構造体から生まれたわけじゃない。
構造体とデータ抽象型も関係ないし。
>>859 > オブジェクトを構造体と結び付けるからおかしくなる。
勝手な妄想されても困る。
mathクラスは本来のOOの概念でオブジェクトか？
オブジェクトです。
なにも問題はありません。
>mathクラスは本来のOOの概念でオブジェクトか？
デザパタ勉強してからOOの否定しろよ….
864 ：
逝って良しの１：02/08/14 00:56
>>863 > デザパタ勉強してからOOの否定しろよ….
また勝手な妄想････
OO自体は肯定してるだろ。
もういやだ夏厨は（泣
このスレはコンプレックスに悩む逝って良しの１を慰めるスレになりますた。
>>861 関数型OOPには代入という概念がないので
クラスの中にはメソッドしかありません。
データ + メソッド という定義は手続き型的なものです。
オブジェクト指向とは関係ありません。
>>861 普通に immutable なオブジェクトでいいんじゃない。
> オブジェクトを構造体と結び付けるからおかしくなる。
これ、同意。
>>868 オブジェクト指向のオブジェクトとは何かいってみなさい
そこに答えがある
夏厨の相手はもうあきました
872 ：
デフォルトの名無しさん：02/08/14 01:05
逆にOOが生かせるプロジェクトってどんなのよ？
OOPLの機能がOOだと、勘違いしてるバカが居るな。
このスレ全部読み返して思ったんだけどさー、ここでOO否定してる奴らって
何の概念持ってきてもアレコレ文句つけて否定するんじゃないの？
875 ：
デフォルトの名無しさん：02/08/14 01:06
>>872 OOで苦労して作ったプロジェクトの次のプロジェクトでは？
877 ：
デフォルトの名無しさん：02/08/14 01:07
>>874 正解。ここで難癖をつけていい気分になりたいだけなんだよ。
現実が悲惨だから。
>>878 得意の自己レスが連発しています
見ているこちらが恥ずかしいです
881 ：
デフォルトの名無しさん：02/08/14 01:13
デザパタなんてＯＯでもなんでもねーじゃん。
つーかオブジェクト指向ってよ、シューティングゲームを例に取ると
自機、敵、弾、敵弾、爆発、カメラ等って感じで、これがそのままクラス
になる（その後の継承とかはまあすきにしろよ。）。
とりあえずだれがみてもみんながおおよそ納得してくれるように
わかりやすいものでなきゃならんと俺は思うよ。
デザパタってみんな読まないだろ？
そうだよな、これ会社の基準なんかにしちゃうと５００ページを超える
プログラム社内規約になっちゃうだけだよ。
で、内容は誰も考えつかないようなトリッキーなクラス設計？
これが間違ってんだよ。
どうしてみんながはじめに認識できる形でそのままクラスに
落とし込めないのか疑問でしょうがない。
882 ：
デフォルトの名無しさん：02/08/14 01:13
晒しage
すみません・・・
バイオとかNECとかのキーボードの上についてるボタンはキーコードを吐き出しますか？
どうも読み取れません。
>>880 あの…
>>878は俺じゃないんだけど…(汗). トリップ付けようか?
とりあえずさ, OOのどこが悪いのかキチンと理論付けて否定してほしい.
で, 何が至上なのか. 正直, このスレ全部読んでも何がダメなんか
分からん.
自分を基準にしちゃいけないよ。
887 ：
デフォルトの名無しさん：02/08/14 01:15
888 ：
デフォルトの名無しさん：02/08/14 01:15
あ
なんか荒れてきたけどオブジェクトとは何かから
もう一度勉強した方が良いよ
自分の好きな言語の仕様を正当化する
気持ちははわかるけどね
>>881 ちょっと待てやー！
とは言ったものの中途半端な意見しか言えそうにないんで
理解のある人に助けを求めてみる。
>で、内容は誰も考えつかないようなトリッキーなクラス設計？
>これが間違ってんだよ。
これが間違ってんだよ。
>>868のような都合の悪いレスはアンチOOに無視される。
893 ：
逝って良しの１：02/08/14 01:32
868は妄想君じゃん
>>893 妄想だって (ぷぷぷ
もっとまともな反論できないの？
896 ：
デフォルトの名無しさん：02/08/14 01:40
まあ結論としてOOは青春のいい思い出だったということでいいんじゃない？
>>893 みんなだって悩んでるんだ。君だけじゃないよ。
がんばって！
なぜアンチOOは誤ったオブジェクト指向の定義に固執するの？
>900
それがわからないから
おまえらハッスルしすぎ
904 ：
逝って良しの１：02/08/14 01:53
このスレ読み返して見ろ。
だれもそんな定義なぞしとらん。
だから妄想だといってんの。
そろそろ次スレを立てた方が良くないか?
950で
次スレが必要なら、逝って良しの1氏が立てるんじゃないの？
>>904 こんな所でオブジェクト指向を批判するより
情報工学を勉強した方がいいよ。
910 ：
デフォルトの名無しさん：02/08/14 02:26
>>868 え？関数型言語には破壊的代入はあるけど、環境による変数の束縛はあるから
関数型ベースのOOPLではオブジェクトにはメソッドしかないって事にはならないでしょ。
状態変化がないだけで、データというか束縛情報は保持するよ。
>>910 そっちの方が正確。
状態がないオブジェクト指向という考え方もあるってことを言いたかっただけ。
912 ：
逝って良しの１：02/08/14 04:08
>>911 誰も状態が必要とはいっとらん。
仮想人格をでっち上げたのが敗因ですな。
STLは使ってると凄く便利に感じるけど、
あれってOO使ってるよね？
OOの有効性の証明なんて俺にはそれで十分だよ。STLみたいに
超便利なものが出来る。それがOOってことさ。
つーか、「破壊的代入はあるけど」には誰もツッコまないのね...
正しくは「破壊的代入はないけど」だな。 let state == #down in eval die
>>914 STLはオブジェクトを指向してないでしょ
>>916 コンテナもイテレータもオブジェクトとして捉えられてるし、コンテナは
テンプレートを使ってオブジェクトが格納されるようになってるし。
どこからどう見てもオブジェクト指向にしか見えんが？
>>915 オブジェクト指向派にはそう見えて、否定派にはそう見えない そういうもんじゃないの？
>>918 917へ言ってるんだろうけど。
否定派はオブジェクト指向の有効性を何が何でも認めたくないから、
STLはオブジェクト指向じゃないと強弁するわけだ。（ﾜﾗ
920 ：
デフォルトの名無しさん：02/08/14 09:00
STLの特徴はオブジェクト指向というよりも、ジェネリック
プログラミングでは？
オブジェクト指向も融合していると思いますが。
921 ：
デフォルトの名無しさん：02/08/14 09:07
>>920 そりゃまあ両方が特徴なんだけど、
じゃあSTL自体の実装からオブジェクト指向的な部分を切り取っていくと何が残るのかな、って事になる。
プログラミング言語の技術要素ってのは単純に切り離せないものだし
組合せの妙ってのが言語設計の華だよね。
だから、もしSTLが有用だということであれば、
オブジェクト指向もゲネリックプログラミングも有用だということになると思われ。
物（オブジェクト）の見方はそりゃ多種多様というのが否定派の考えだよ
オブジェクト指向派はなんでもオブジェクトを指向しようとする
テンプレートでオブジェクを扱ってる部分もそりゃあるだろうよ
しかしSTLはオブジェクトを指向はしていない それは
道具であって、オブジェクトを指向させるかどうかはプログラマによるんじゃないの？
どうにもプログラミング言語自体の話みたくなっちゃったけど
汎用ライブラリの設計でも同じことだよね。
つーわけで補足でした。
typeじゃなくてtypoね。欝だ。
>>922 では手続き型プログラミング言語では全てが手続きなのかというと、そういうわけではない。
ほかにも色々な技術要素があってプログラミング言語が成立している。
オブジェクト指向プログラミング言語も同じで、ほかにも色々な技術要素があって
はじめてプログラミング言語として成立する。
STLなんかも同じように、STLを構築する多くの技術要素のうち
より大きな存在がオブジェクト指向とジェネリックプロラミングだというだけの話。
で、どっちが欠けてもSTLは今のSTLとは別物になる。
>オブジェクト指向派はなんでもオブジェクトを指向しようとする
まず「オブジェクトを指向する」ってどういう意味で使ってるんだ？
STLが指向してないのはなぜ？
オブジェクト指向派がなんでもオブジェクトを指向しようとしてるって
どういう意味？
Smalltalkのような動的なオブジェクト指向言語は、ジェネリックと
オブジェクト指向が融合した例だと思う。
929 ：
デフォルトの名無しさん：02/08/14 10:14
長い沈黙の後、ついにあの
>>922が重い口を開いた…
↓さあ、どうぞ！
ぁる遺伝子研究の結果、最強の兵器となるべく生まれた。
通称(ジェネリック)と呼ばれている。
あるとき、12人のぁぁぁっ、 ぐふっ･･･
簡単な話だ たとえばアレイのコンテナを使って格納し、ソートアルゴリズムをかけて
出力するだけの利用をしているのをみて、これをオブジェクト指向と呼ぶのかい？
それならそれでいいが、それは
【オブジェクト指向派がなんでもオブジェクトを指向】の例証になる
それが違うというのなら、上の例証になる
>>931 その例はライブラリユーザーのコードだろ。
STLのライブラリとしての構想は、オブジェクトを指向していると思ったほうがいいはず。
イテレータによってアルゴリズムを抽象化して提供しているとか。
>>932 もちろんそうだ。 MFCがオブジェクト指向とは思えないから VCLを例にして
VCLがオブジェクト指向で作られていたとしても、 VCLユーザがオブジェクト
指向する必要はないのと同じだ。
では、そういう使い方をするユーザにとって VCLはオブジェクト指向なのか？
単なる便利なライブラリでしかない
さて、一般のクラスと違って テンプレートは 必ずしもオブジェクトを生成する訳じゃない
イテレータはクラスを作成し、その実体を作ればオブジェクトを作成するのかもしれないが
多くのアルゴリズムは、オブジェクトを引数とする関数を生成する
それをオブジェクト指向として捉えずに使う事は VCLよりたやすい。
934 ：
デフォルトの名無しさん：02/08/14 11:02
Smalltalkでさえ使うだけならオブジェクト指向である必要はない。
しかし、Smalltalkライブラリを最大限有効に利用しようとしたら
ライブラリユーザのコードもオブジェクト指向的にしたほうがよい。
STLも程度の違いはあれ、それと同じだと思うが。
つまりSTLを使うだけであればオブジェクト指向する必要はない。
しかしSTLをより有効に利用しようとしたら
少しずつでもオブジェクト指向的にしていったほうがよい。
935 ：
コギャルとHな出会い：02/08/14 11:03
http://kado7.ug.to/net/ 朝までから騒ぎ！！
小中高生
コギャル～熟女まで
メル友
i/j/PC/対応
女性の子もたくさん来てね
小中高生大歓迎です
全国デ－トスポット情報も有ります。
全国エステ＆ネイル情報あります。
激安携帯情報あります。
結論：オブジェクト指向は（クラスライブラリを使うだけの）戦場では必要なし
結論：プログラミングは(プログラムを書くだけの)戦場では必要なし。ヤッター！
>>934 オブジェクトという捉え方は場合によって有効なのは確かだよ
そしてオブジェクト指向を習得することが必要なのも確か
しかし習得中の状態で、オブジェクト【指向】してしまうのはどうだろうか？
それは
>>1 のようになってしまうだろうという事
つまりは習得は必要な事。しかし習得中はオブジェクト使うだけにしといたら？ って事
なんか 剣を抜かなくなって初めて達人 って言葉に似てるな
OOはOOしなくなって初めて達人？
「カプセル化」「継承」「多態」を道具として使うのが達人
なんでも適用しようとするのが廚
ってことかな？
ホントの達人は、「カプセル化」「継承」「多態」なんて自然にやってしまって
そういう用語を逆に使わなくなるんじゃないかな
943 ：
デフォルトの名無しさん：02/08/14 11:59
944 ：
デフォルトの名無しさん：02/08/14 12:20
実際のプログラミングじゃ使わないけど、仕様決定段階で
考え方だけ借りるのはよくある。
まとめるのに便利なんだよね、オブジェクト指向って。
945 ：
デフォルトの名無しさん：02/08/14 12:42
>>944 そうなのか…
俺的には、OOA/OOD/OOPでは、一番オブジェクト指向的要素が小さいのがOOAだと思うのだが。
>>933 MFCがオブジェクト指向していると思えないのはなんで？
糞ライブラリだから？
VCLがオブジェクト指向していると思うのはなんで？
某エピ氏によると、オブジェクト指向フレームワークとしてみた場合、
MFCは最低限DocViewとしてフレームワークが組まれているけど、
VCLはそれすらもしてない、最悪なフレームワークであると言うことなんだけど。
俺はVCLは知らないから、何ともいえん。
ただ、MFCはAPIの薄いラッパーに過ぎない糞ライブラリであることには同意だけど、
オブジェクト指向をしてないと言う意見には疑問を抱く。
>>946 MVCのCが無い感じだね。MFC。
それに対してVCLはライブラリ集。
個人的にはのびのび書ける後者が好きだけどね。
>>947 Cがないんじゃなくて、ウインドウという表示操作を同一のオブジェクトで
行う環境だから、CをVに吸収しただけでしょ。
もっとも、今だとtraitsとして分離するのが良いのかも知れないけど。
VCLはたしかに使いやすそうではあるんだけど、
モデルとビューが分離されてないから、人のソースのメンテが大変になりそう。
勿論、切り分て書くようにしていればいいんだけど、
強制されないと横着しちゃうこともあるし。
Viewだけ用意されているのがVCLじゃないの？
Modelやコントローラの枠組みを用意しないのも一つの主張だと思うよ
VCLだけだと、確かに人のソースのメインテナンスは難しいと思う
でも
コンポーネントを使う事で、フォーム上からイベントを視覚的に追いかける
事ができるため、比較的読みやすく、機能の変更は楽になっている
そうか？ VCLでも
データベースコントロールについては、MVCが揃ってるように思うのだが？
951 ：
デフォルトの名無しさん：02/08/14 14:02
>>948 ウィンドウシステムでのGUIであっても、VとCを分離したほうがいい場合も結構あるよ。
たとえばテキストエリアでどんなキーバインドにするかを
コントローラで直接とっかえられたら楽な場合なんかもあるし、
あと、マウスで使ったりタッチパネルで使ったりする場合があるとか。
>データベースコントロールについては
結局これだけじゃん。
VCLは基本設計にMVCを採用してないでしょ。
VCLが劣っているって言いたいんじゃなくて、OOフレームワークではないって言っているの。
コンポーネント集としては優れているかもしれないけど、使ってるわけじゃないんで
俺に優劣の評価は下せない。
>>951 まぁ、そらそうだろうけど、MFCではVにCを吸収したってこと。
だから分離するのが良いのかも知れないけどって書いた。
>>951 それならちゃんとActionという仕掛けがあるよ
よくは知らないけど VCLでも Web関係では MVCが採用されてるみたいだけど？
採用っていうより、それ以外に手がないだけじゃん。
というか、web周りはIEコンポだから当然。
？ IEコンポって何の関係が？
TWebBrowserでしょ？
あれってIEのIDL取り込んでるだけじゃん。
それとも、ソケットコントロールのこと？
ビューなんかあるの？
WebSnap/WebBroker とかの事じゃないの？
なんだかよく判らないや
具体的にはどんな感じ？ Actionって
-------------------------------------------------------
アクションリストがなければ、開発者はすべてのコマンド項目とアプリケーション
オブジェクトの間のすべてのリンクを追跡しなければなりません。ユーザーインター
フェース要素は、特定のアプリケーションオブジェクトの状態に基づいて無効にし
たり、再度有効にしたりする（たとえば [貼り付け] コマンド）必要があります。
その結果がスパッゲッティユーザーインターフェースデザインです。アクションリ
ストがあれば、開発者に必要なのはユーザーインターフェースとアプリケーション
ロジックの間のリンクを 1 つ、アクション項目を使って管理することだけです。1
つのアクションをメンテナンスするだけで、開発者は真にオブジェクト指向の方式
でアプリケーションロジックとソースコードの間の相互作用を管理できます。Delphi
4 では、[切り取り]、[コピー]、[貼り付け] といった開発者が再利用できる共通ア
クションを多数備えています。アクションリストは、ユーザーインターフェースデ
ザインのブレークスルーを備えています。ユーザーインターフェース要素が初めて
アプリケーションロジックから分離され、その結果、再利用性とアプリケーション
の安定性を増しながらコードの複雑性と行数が削減されています
>>960 commandパターンって奴じゃないの？
つまりは、
【ビジュアルコントロール】<->【アクション】<->【ボタン・メニュ類】
となっていて、
ボタン・メニュのショートカットを操作しなくても、アクションを通じて
自動的にキーバインドを変更出来るし、入力コントロールや
フォーカスの状態に応じて自動的に選ばれるし、さらにイネーブル
もされたりする
それから実際の動作も アクションのイベントとして変更出来る
ボタンやメニューはビジュアルコントロール（TControlから派生？）じゃないの？
>>963 ありがと、
D6パーソナルのヘルプ読んでもやっぱりよく判らないや
アクション＝コントローラ？
アクションのターゲット＝ドキュメント？
アクションのクライアント＝操作側
みたいに別けてるのかなあ
>>965 最初の【ビジュアルコントロール】は間違いで ああ 確かに説明が難しいな
>>963 キーバインドの話はショートカットとかじゃなくて、
たとえばviみたいな操作体系とemacsっぽい体系を実行時に切り替えたり、
あるいは実行時にユーザ定義したいという話で、
それはコントローラを直接入れ替えたり、キーバインドを1つのオブジェクトにまとめて
コントローラにそれを保持・管理させればすっきり簡単になるわけよ。
タッチパネルの例では、例えばマウスを使った操作では普通の操作体系だけど、
タッチパネルではジェスチャーが使えるようにしたりとか、
通常にあがってくるイベントより細かい所で変更したくなるわけよ。
そういうのって、アクションを使えば同様な事ができるの？
VCLも今ではバージョンが６なんだから、 そりゃ細かく色々と機能が加えられているさ
Ver1の頃は そりゃViewだけだったかもしれない。そして互換性持たせてるから
今でもViewだけ使って十分にアプリが作れるけどさ
>>913 俺は関数型OOP厨房。
関数型OOP覚えたてだから何か書いてみたかったんだよ～
> オブジェクトと構造体を結び付けるからおかしくなる
ってのはホントのこと。
純粋OOPL万歳！