消えてなくなれよ >オブジェクト指向 part.2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/03/22(日) 06:57:59http://pc11.2ch.net/test/read.cgi/tech/1198822420/
0679デフォルトの名無しさん
2009/05/28(木) 00:52:35> ＯＯって単なる実現手段で工数決める場に出てこないし
そりゃそうだ。
> ってことは使っても使わなくてもなんもお金に影響ないってことだよね
同じお金もらえるんなら、工数少なくてすむ実現方法の方がいいよね。
0680デフォルトの名無しさん
2009/05/28(木) 00:55:20設計に失敗して、火を吹いてるプロジェクトは結構見かけるが。
0681680
2009/05/28(木) 01:01:58設計するのならOOは有効な設計ガイドラインだと思うよ。
0682デフォルトの名無しさん
2009/05/28(木) 01:12:13人類の負の遺産だわ。不良債権処理しなきゃ。
0683神と言われたヲトコ ◆vBOFA0jTOg
2009/05/28(木) 01:28:510684デフォルトの名無しさん
2009/05/28(木) 01:37:441億ステップのスパゲッティコードにバグ一つ入らん
0685デフォルトの名無しさん
2009/05/28(木) 01:50:52人力車が現れたときの駕籠かき、タクシーが現れたときの車夫。
酸っぱい葡萄だよ。
0686デフォルトの名無しさん
2009/05/28(木) 03:10:32お前はOOなんて使わなくても今まで業界でやってきて見積り精度にも
自信があるんだろうが、お前の下についた若いプログラマは
「プロジェクト仕切ってる上司が時代遅れすぎてありえねぇ。無駄な作業多すぎて鬱」
って２ちゃんねるで愚痴ってるかもしれないぞ。
0687デフォルトの名無しさん
2009/05/28(木) 03:53:50おれ無職だから説得力あるよね
0688デフォルトの名無しさん
2009/05/28(木) 04:29:43設計することと理解することは全く別。
今時OOで書かれたプログラムを読んで理解出来ない奴を雇っていることこそが
非効率の元凶であってOOが問題ではない。
0689デフォルトの名無しさん
2009/05/28(木) 07:47:18> ＯＯ使って組んだら理解できる人間が少なくなるならそれは単に非効率なだけだろ
逆だ。クズPGを排除することで効率化が実現される。
プロジェクト管理の肝は、できないPGが足を引っ張るのに対してどう対処するかにある。
できないマネージャーはできないPGを教育しようとしたり、できないなりの仕事をさせる。
一方で、できるマネージャーはチーム内からできないPGを排除する。
すると、マネージャーもできるPGも快適に作業を進めることができる。
0690デフォルトの名無しさん
2009/05/28(木) 09:22:33>クズPGを排除することで
そして誰もいなくなった、的な。
0691デフォルトの名無しさん
2009/05/28(木) 09:28:28> ソースにまでクラスって形でもっていけるのが唯一の利点だと思ってるから
このパターンだよな。この手の人が気軽にOO批判する。
0692デフォルトの名無しさん
2009/05/28(木) 09:47:42まずオブジェクト指向が何なのか説明汁 ボケ！
0693デフォルトの名無しさん
2009/05/28(木) 09:51:31（ ﾟωﾟ ) >>692お断りします
＿(__つ/￣￣￣/＿
＼/ /
0694デフォルトの名無しさん
2009/05/28(木) 10:36:15ググレカス
0695デフォルトの名無しさん
2009/05/28(木) 10:40:41いるいる。チームから気に入らないＰＧを排除して自分勝手に進めるやつ
プロジェクトが成功すればいいけど、失敗したら何も残らない…
0696デフォルトの名無しさん
2009/05/28(木) 11:27:51どんな言語使ってる？
0697デフォルトの名無しさん
2009/05/28(木) 11:33:25単価の安いＰＧなんて、そんなのばっかりだろ。
出来る人にベースを作らせて、クズＰＧにはｏｏとか意識させずに「この手順でやってください」
手順を明示しても出来ないクズは流石に切った方がいい
0698デフォルトの名無しさん
2009/05/28(木) 12:18:07というような変な分業体制作っちゃったから日本の技術力が落ちたんだけどね。
0699デフォルトの名無しさん
2009/05/28(木) 12:39:50何でだ？
0700デフォルトの名無しさん
2009/05/28(木) 13:03:35コーディングしやすさを考えて設計したら駄目
と思ってんじゃねーの
0701デフォルトの名無しさん
2009/05/28(木) 15:04:13プログラミングにおいて設計変更は日常茶飯事だからな。
一部金融系なんかの仕様書ガチガチな業務システムを除いては
設計しながらコーディングというのがあるべき姿であって、
分離する事自体が間違い。
つーか日本のブルーカラーの勤勉さは世界一と言っても過言じゃないぞ。
その代わり給料もそれなりにもらってるがな。
0702デフォルトの名無しさん
2009/05/28(木) 15:06:190703デフォルトの名無しさん
2009/05/28(木) 15:24:250704デフォルトの名無しさん
2009/05/28(木) 15:27:310705デフォルトの名無しさん
2009/05/28(木) 17:52:17お前ら本当に"オブジェクト指向"をちゃんと定義できるの？
俺が今まで見た中で一番マトモなオブジェクト指向の定義はこれだが
ttp://practical-scheme.net/trans/reesoo-j.html
はっきり言ってこんなの未定義と不定と実装依存を足して３で割ったようなもんだと思う
もっと見事な定義ができるとか、ググればマトモな定義が見つかるっていうなら
是非見せてもらいたい。
0706デフォルトの名無しさん
2009/05/28(木) 18:00:58それよりよほどましな定義
http://e-words.jp/w/E382AAE38396E382B8E382A7E382AFE38388E68C87E59091.html
0707デフォルトの名無しさん
2009/05/28(木) 18:01:23／ ＼ ＿＿＿
／ﾉし u; ＼ ;／(＞)＾ ヽ＼;
| ⌒ ) ;／ (＿ （＜） ＼;
| 、 );/ /rｪヾ__）⌒::: ヾ; はっきり言ってこんなの
| ＾ | i ｀⌒´-'´ u; ﾉ;; 未定義と不定と実装依存を足して
| | ＼ヽ 、 , ／; ３で割ったようなもんだと思うお
| ;j |／ ＼-^^ｎ ∠ ヾ、
＼ ／ ! 、 /￣~ﾉ ＿＿/ i;
／ ⌒ヽ ヽ二) /（⌒ ノ
/ r、 ＼ / ./ ￣￣￣/
0708デフォルトの名無しさん
2009/05/28(木) 18:09:28その定義はC++やJavaなどに毒されているんじゃないか
オブジェクトに対するメッソッドじゃなくて
オブジェクト間のメッセージが本流だろ
0709デフォルトの名無しさん
2009/05/28(木) 18:19:33http://d.hatena.ne.jp/sumim/20040525/p1
0710デフォルトの名無しさん
2009/05/28(木) 18:28:37毒されているのが良く分かるな。
0711デフォルトの名無しさん
2009/05/28(木) 18:35:370712デフォルトの名無しさん
2009/05/28(木) 18:52:15逆だろw >>642がイメージしているのはKay的OOとは正反対だ。
0713デフォルトの名無しさん
2009/05/28(木) 19:05:10オブジェクト指向：ツリー型
0714デフォルトの名無しさん
2009/05/28(木) 19:12:34それはまったく違うぞ。
>>642の脳内での「オブジェクト指向」の定義はKay的OOだが、
オブジェクト指向「プログラミング」はC++的なものだと思ってるってことだ。
0715デフォルトの名無しさん
2009/05/28(木) 20:31:550716デフォルトの名無しさん
2009/05/28(木) 20:37:050717デフォルトの名無しさん
2009/05/28(木) 21:09:35> "メッセージ"とかご大層なもののように言うけど、単に遅延束縛だろ。
うんにゃ、メッセージってのは、「ノイズも含めて」ただの信号だ
信号処理系をどうデザインするかは、手法によって変わるんだろうけど
少なくともOOAとかOODって言ってる奴等は
「ノイズも信号のうち」
って、当たり前の事実が分かってない
0718デフォルトの名無しさん
2009/05/28(木) 21:11:260719デフォルトの名無しさん
2009/05/28(木) 21:14:03単なる関数呼び出し。Objective Cのコードとか見てみろって。
0720デフォルトの名無しさん
2009/05/28(木) 21:14:27うけねらい？それともOO信者お得意のメタファー？
ネタなら、ごめん。意味分からん。
たとえ話なら、そんなのいいからプログラミングの機能の話がしたい。
0721デフォルトの名無しさん
2009/05/28(木) 21:22:30OO信者というより、通信理論や信号処理をかじった奴が能書き垂れてるだけだろ。
とんだお笑いものだがな。
0722717
2009/05/28(木) 21:24:39いや、厳然たる事実
OOA とか OOD とかやってる連中って、やたら例外を作る
「ノイズも信号のうち」と考えてデザインすると
物事はもっと簡単になったりする
# もとハード屋のつぶやきだ
0723デフォルトの名無しさん
2009/05/28(木) 21:36:16じゃあどう簡単になるのか設計の具体例を挙げてみてよ
0724デフォルトの名無しさん
2009/05/28(木) 21:57:14nullで例外出さないでNullableで演算を最後まで通してしまうとかかな
0725717
2009/05/28(木) 22:38:47ソフト的に考えたらそうなんだろうけど
ノイズそのものも評価対象にいれるってゆうか…
ハードつくる場合って例外事象への対応はとってもコストが
かかるんで、伝達関数書くときに外乱を意味する変数を作って、
それも一緒に処理の中に含めるってゆうか…
外乱とかノイズとかも最初から入力の一つの要素として扱う
ってのが、賢いハード屋
0726デフォルトの名無しさん
2009/05/28(木) 22:52:03だからソフトウェア開発でお前の言った方法論が適用出来る具体例を挙げろよ
0727717
2009/05/28(木) 22:54:55例外扱いしなきゃいいって
0728デフォルトの名無しさん
2009/05/28(木) 22:57:51具体的に何を例外扱いせずにどう処理するんだよ
0729717
2009/05/28(木) 23:08:14例外事象も入力のうちって捕らえたら
out = f (in, exception-case)
の関数だよな. 内部の状態は適当に隠蔽するとして…
後はカリー化して1入力-1出力の関数になるだろ？
0730デフォルトの名無しさん
2009/05/28(木) 23:09:03製造業や建設業における設計が、ソフトウェアでは設計＋実装に当たるから。
ソフトウェア産業での「製造工程」ってのは、ビルドフェーズになる。
つまり、既に自動化されている。
0731デフォルトの名無しさん
2009/05/28(木) 23:10:420732デフォルトの名無しさん
2009/05/28(木) 23:30:300733デフォルトの名無しさん
2009/05/28(木) 23:37:200734デフォルトの名無しさん
2009/05/28(木) 23:53:16だから入力がfで処理できないようなものだったらどうするのか、ってことなんだが。
0735デフォルトの名無しさん
2009/05/29(金) 00:06:34C#だとNullableがあってもRoundなどNullable用のメソッドがないから
自分で作っていたが
もしかしてMaybeモナドってそんなことしなくてすむようになるんかな
だとしたらHaskellすごい
0736デフォルトの名無しさん
2009/05/29(金) 00:06:38で、それがオブジェクト指向とどう関わりがあるんだ？
0737デフォルトの名無しさん
2009/05/29(金) 00:11:44カプセル化？データ構造や内部関数の隠蔽ならMLのモジュールでもできるよ。
逆にデータ構造と手続きを分離できないから、visitorパターンなんていうばかばかしい
テクニックを使わなきゃいけなくなる。
データと手続きを一緒にする意義ってあるの？正直ナンセンスだよ。
0738デフォルトの名無しさん
2009/05/29(金) 00:20:18サブルーチンのカタマリにしてくってことですか？
0739デフォルトの名無しさん
2009/05/29(金) 00:23:32カプセル化だけがOOだと思ってるなら勉強不足にも程がある
0740デフォルトの名無しさん
2009/05/29(金) 00:25:13おっと、こんな時間にだれかk(ry
0741デフォルトの名無しさん
2009/05/29(金) 00:25:57データと手続きを分離した場合、無制限に操作を許すと
「システムとして有り得ない状態」を作り出しやすいんだよね。
もしくは、状態を多数つくって管理が破綻するとか。
敢えて制限をかけることで制御のし易さを得ることができるというわけ。
0742デフォルトの名無しさん
2009/05/29(金) 00:26:33OOの方がいいと思うけど。OOから入った人は、OOが当たり前に有るから。
その欠点しか見えないかもしれないね。これもゆとりの･･･
0743デフォルトの名無しさん
2009/05/29(金) 00:26:47OO信者最強の武器「勉強不足」www
0744デフォルトの名無しさん
2009/05/29(金) 00:27:47ジェネリックプログラミングは型の型による制約で分離しつつもそれを防いでいる
0745デフォルトの名無しさん
2009/05/29(金) 00:30:13アホか？信者じゃねーぞ
批判するならOOを知った上でないと>>737みたいな勘違い批判になるってことだ
0746デフォルトの名無しさん
2009/05/29(金) 00:34:040747デフォルトの名無しさん
2009/05/29(金) 00:37:59737は勘違いなのか？データと手続きは分離したままで、「システムとして有り得ない状態」
が出ないように隠蔽できるというMLの型システム(モジュール)を知っての上での批判だと思うが。
0748デフォルトの名無しさん
2009/05/29(金) 00:38:22ジェネリックプログラミングとOOは排他的な概念じゃなかろうもん。
0749デフォルトの名無しさん
2009/05/29(金) 00:43:41その意味ではコンストラクタとデストラクタ間で制約を設けられるような類のOO言語の方が有利な場合もある
0750デフォルトの名無しさん
2009/05/29(金) 00:45:50そんなことは言っていないぞ。
MLのモジュールシステムは基本的に関数やデータタイプを個別の名前空間に閉じ込める
だけだから、「システムとして有り得ない状態」を防げるわけではない。
> データと手続きを一緒にする意義ってあるの？正直ナンセンスだよ。
なんて言う時点で勘違い。
0751デフォルトの名無しさん
2009/05/29(金) 00:48:52力不足というのは同位
>コンストラクタとデストラクタ間で制約を設けられるような類のOO言語の方が有利
ここ、もちょっとkwsk
0752デフォルトの名無しさん
2009/05/29(金) 00:52:39>MLのモジュールシステムは基本的に関数やデータタイプを個別の名前空間に閉じ込める
>だけだから、「システムとして有り得ない状態」を防げるわけではない。
そこまで知ってるなら、なぜシグネチャーを知らない？
0753デフォルトの名無しさん
2009/05/29(金) 01:15:35当然知ってるが。シグネチャは結局モジュールの受け付ける型を制限するだけで
あって、静的型チェックはC++やJavaでもやってること。
0754デフォルトの名無しさん
2009/05/29(金) 01:29:43http://www.geocities.jp/m_hiroi/func/ocaml09.html
「シグネチャとデータ抽象」あたりを読むべし。
0755デフォルトの名無しさん
2009/05/29(金) 01:40:41何が言いたいんだ？3行で説明してみろよ。
0756デフォルトの名無しさん
2009/05/29(金) 01:53:37せめて引用したい部分だけでも貼れって思う
仮に
>>754
http://www.ntv.co.jp/sekaju/student/20050115/03_0201.html
とかやったら俺のいうことを理解できるまで上記リンクを最後まで読むんだろか？ｗ
0757デフォルトの名無しさん
2009/05/29(金) 04:46:280758デフォルトの名無しさん
2009/05/29(金) 05:04:48違いを具体的に説明出来ないのなら、それは理解していないのと何ら変わりない。
0759デフォルトの名無しさん
2009/05/29(金) 05:13:29違いはinclusion polymorphismだ。あとは自分で調べろカス
0760デフォルトの名無しさん
2009/05/29(金) 05:25:46結局説明できないんだな。知ったかのクズが
0761デフォルトの名無しさん
2009/05/29(金) 07:18:410762デフォルトの名無しさん
2009/05/29(金) 07:32:24曖昧さのないように３行で説明してみろやボケが
0763デフォルトの名無しさん
2009/05/29(金) 08:35:29人にモノを訊くときにはまず自分で調べてからにしろ。クズ。
0764デフォルトの名無しさん
2009/05/29(金) 08:59:42ここまで渋るとは、お前は本当に説明出来ないんだな。
だったら最初から偉そうな物言いをするなよ。
人の名前や述語を挙げて後は調べろで煙に巻くような輩に碌な人間はいないな。
0765デフォルトの名無しさん
2009/05/29(金) 09:02:34最低限の知識を踏まえていない人間が議論で相手にされるとでも？
0766デフォルトの名無しさん
2009/05/29(金) 09:17:07するのならその根拠を説明するのは当然だろうが。そんなことも理解できないのか？
0767デフォルトの名無しさん
2009/05/29(金) 09:23:03もう>>757は嘘ということで終わりな
0768デフォルトの名無しさん
2009/05/29(金) 09:23:400769デフォルトの名無しさん
2009/05/29(金) 09:45:54称される機構は、ちょっと回りくどい関数呼び出しに過ぎないですよ。それは Smalltalk も同じ。
Smalltalkはあくまで暫定的な仕様のシステムだったのだけれども、いろいろあって途中で変化を
やめてしまった。にも関わらず、それを完成された形と勘違いした多くの言語作者が
この関数のことをメソッドだとかその呼び出しをメッセージ送信だとか、ひそみに倣い
はじめたからおかしな事になったわけです。
ただやっかいなことに、しくみは古いままでも、それをメッセージングだと見なしてプログラミングしたり
そうした思考や行為をサポートする主にメタな機構・ツール・環境を充実させてみると、（領域によっては）
目を見張る生産性を発揮することも分かった。暫定ダイナブックOSとしてのSmalltalkはその実証でもあるわけです。
20年以上再起動することなしに動き、拡張され続けているシステムって、メッセージングのアイデアの
源でもあるインターネットシステムを除けば、Smalltalkの他にないのではないでしょうか。
そんなケイが「メッセージング」を介して本来目指したものや、Smalltalkによって得られた成果についての
ケイ自身の総括みたいなものはここで読めます。
http://metatoys.org/oxymoron/oxymoron.html
以上、長くなりましたがケイの「メッセージングのＯＯ」の参考まで。
0770デフォルトの名無しさん
2009/05/29(金) 10:06:100771デフォルトの名無しさん
2009/05/29(金) 10:14:06リンク先にもきちんと書いてあるだろ？
元々 well-defined じゃない。
0772デフォルトの名無しさん
2009/05/29(金) 13:46:010773デフォルトの名無しさん
2009/05/29(金) 17:53:530774デフォルトの名無しさん
2009/05/29(金) 18:44:54メッセージングの違いとかinclusion polymorphismの話題を含むやつを具体的に
0775デフォルトの名無しさん
2009/05/29(金) 18:52:360776デフォルトの名無しさん
2009/05/29(金) 19:29:22『作った後で要求がガンガン変わる』という事例にまで頭が回っていないように見える。
0777デフォルトの名無しさん
2009/05/29(金) 20:35:28http://www.ntv.co.jp/sekaju/student/20050115/03_0201.html
0778デフォルトの名無しさん
2009/05/29(金) 20:52:40■ このスレッドは過去ログ倉庫に格納されています