トップページ⇒tech
1001コメント323KB

オブジェクト指向の弊害

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2012/01/24(火) 23:15:19.23
非OOPでコーディングされたソースを見て発狂するアホを生み出したこと
そのくせOOPを十分に理解してないから痛々しい
0002デフォルトの名無しさん2012/01/24(火) 23:20:49.82
と天才プログラマー「あい」は申しております。
0003デフォルトの名無しさん2012/01/24(火) 23:23:30.39
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所
0004デフォルトの名無しさん2012/01/24(火) 23:40:02.58
高級言語の普及によって、プログラムの自己書き換えが廃れたように、
実際、「オブジェクト指向」という制限が掛かることによって
実装できなくなったプログラミングイディオムってあるよね。

「闇のデザインパターン」とでも言えばよいのだろうか。
誰か、そういうのをまとめてくれないかな。
出版してくれたら、絶対に買うよ。
0005デフォルトの名無しさん2012/01/24(火) 23:42:20.09
>>4
アンチパターンですね。
0006デフォルトの名無しさん2012/01/25(水) 00:05:58.77
>>5
アンチパターンは、元々やるべきではないもの。
これは、役に立つけど、諸般の事情で使えなくなったもの。
0007デフォルトの名無しさん2012/01/25(水) 00:19:01.71
OOPは保守性が高い
0008デフォルトの名無しさん2012/01/25(水) 01:01:13.13
>>6
アンチパターンだから使えなくなったのです。
0009デフォルトの名無しさん2012/01/25(水) 01:31:58.75
>>7 きちんとクラスが設計されていれば・・・な
0010デフォルトの名無しさん2012/01/25(水) 02:31:39.48
Object Prototype Programming Architect Interface
0011デフォルトの名無しさん2012/01/25(水) 02:51:28.43
OOPでよく使われる文法は非OO的機能という現実
0012デフォルトの名無しさん2012/01/25(水) 06:50:39.93
Bjarne Stroustrup インタビュー (?)
ttp://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
0013デフォルトの名無しさん2012/01/25(水) 09:26:03.58
アルゴリズム本のページ数が伸びる。
もしくはCで学ばなくてはならない。
0014デフォルトの名無しさん2012/01/25(水) 15:19:25.01
>>12
外人のネタコピペも結構レベル高くなってきたな
0015デフォルトの名無しさん2012/01/25(水) 15:32:14.01
>更新:1999-08-03
0016デフォルトの名無しさん2012/01/25(水) 18:30:16.27
通知を受けるためクラスがあって、そのクラスのインスタンスが
どっかのオブジェクトのメソッドを実行するための何かとか
もう意味不明w
0017デフォルトの名無しさん2012/01/25(水) 18:36:37.11
弊害を語るならせめてパターンくらいは身につけろや
0018デフォルトの名無しさん2012/01/25(水) 21:23:18.94
OO系のスレは他にもあるのにワザワザ新しいのを立てたんだから
>>1は責任もってネタを出すように

まさかあれで終わりということはあるまいな
0019デフォルトの名無しさん2012/01/27(金) 23:25:59.04
>>16
そうだな
OOになびく奴は昔から頭がちょっと弱めが多い
0020デフォルトの名無しさん2012/01/27(金) 23:29:17.09
さあ、釣りだ!
0021デフォルトの名無しさん2012/01/27(金) 23:39:44.39
>>19
ネタが尽きたら自問自答は定番だよな
0022デフォルトの名無しさん2012/01/27(金) 23:41:30.03
PHPを非オブジェクト指向でプログラミングする
それがあるべき理想の姿だな
0023デフォルトの名無しさん2012/01/28(土) 14:58:58.50
>>17
パターンは糞。まだ分からんのか。
0024デフォルトの名無しさん2012/01/28(土) 15:07:16.05
ほら、これが釣りですよw
0025デフォルトの名無しさん2012/01/28(土) 15:10:47.84
Singletonパターンは百害あって一利なし
0026デフォルトの名無しさん2012/01/28(土) 15:12:38.86
パターンが糞っていうか、パターンを身につけないと
糞コード化しやすいところが駄目だわ。
0027デフォルトの名無しさん2012/01/28(土) 15:15:08.89
>>25
そのように、パターン名に名前がついてるってのは
すごく重要だよな。

もしSingletonパターンという名前が存在しなかったら、
>>25の書き込みを正確に書くことはできるだろうか?
0028デフォルトの名無しさん2012/01/28(土) 15:29:03.47
>>27
洗脳されやすいタイプだなw
パターンなんてのが出てくること自体原始的状態だってことだよ。
たらたらとアドホックに追加するだけだろ。10年たったら全部消えてるよ。
0029デフォルトの名無しさん2012/01/28(土) 15:46:31.36
>>28
じゃあ10年後にまたおいでw
0030デフォルトの名無しさん2012/01/28(土) 19:58:45.59
Singletonパターンの正当な批判・擁護がなされていないのが問題
0031デフォルトの名無しさん2012/01/28(土) 21:07:56.37
システムの大半は、データと操作を分離した従来の構造化プログラミングで十分。
オブジェクト指向は動的なポリモーフィズムが必要な一部に局所化して利用するくらいがちょうどいい。
0032デフォルトの名無しさん2012/01/28(土) 21:10:26.68
馬鹿がパズルを生成するだけ
0033デフォルトの名無しさん2012/01/28(土) 21:15:55.63
馬鹿が作ったパズルくらい解けるようにしとけよ
0034デフォルトの名無しさん2012/01/28(土) 21:21:24.23
>>4
手続き型の範囲ではないんじゃない?手続き型プログラムは、クラスをがひとつだけのプログラムか、
staticメソッドだけのプログラムと同じなはずだから。

もちろんアセンブラ的なことは考慮しない。
0035デフォルトの名無しさん2012/01/28(土) 21:29:13.00
馬鹿のパズルは論理破綻してるから解けるわけがない
0036デフォルトの名無しさん2012/01/28(土) 21:53:14.44
オブジェクト指向プログラミングは間違いだったか?
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

所謂オブジェクト指向言語はオブジェクト指向してないんじゃないかというなにか
http://d.hatena.ne.jp/Flast/20111206/1323152264
0037デフォルトの名無しさん2012/01/28(土) 21:54:18.27
>>34
「・・・ないんじゃない?」って、
「オブジェクト指向言語でも実装できるよ」って意味?
そりゃ当たり前。チューリング等価なんだから。

でもそれは、アンチパターンでいうところの
「抽象化の逆転(Abstraction inversion)」になるね。
0038デフォルトの名無しさん2012/01/28(土) 22:56:57.45
闇のデザインパターン()笑は例えばどんなのがあるの?
0039342012/01/28(土) 23:39:29.20
>>37
うーん、オブジェクト指向の機能を使って(メッセージ送信とか)を使って、
手続き型と同じことをしようとするなら、その「抽象化の逆転」になるだろうけど、
大半のオブジェクト指向言語は、オブジェクト指向の機能を使わなければ
手続き型言語そのものになるからなんとも。

手続き型の範囲に限定したのはそのため。
関数プログラミングだってメソッドひとつのイミュータブルな
オブジェクトを使えば大体同じことができるけど、それはたぶん
「抽象化の逆転」になるんでしょう。
0040デフォルトの名無しさん2012/01/29(日) 00:32:48.82
Delphi好きだよDelphi
0041デフォルトの名無しさん2012/01/29(日) 04:27:46.91
ooどころか構造化されてるかどうかさえ怪しいHSPだって
一応プログラムは作れる、ooに拘泥するアホはHSP厨以下
0042デフォルトの名無しさん2012/01/29(日) 05:16:15.66
などということを本気で言ってるやつを見てニヤニヤするスレです
0043デフォルトの名無しさん2012/01/29(日) 09:53:48.64
昔は大きなものも小さなものも C で書いていたが
オブジェクト指向言語は小さなものを作るのに向かないので
今は大きなものを作る言語と小さなものを作る言語
最低 2 つの言語を使えないとプログラマとして使い物にならなくなった
0044デフォルトの名無しさん2012/01/29(日) 10:39:51.24
C++ でやればいいんじゃね?
0045デフォルトの名無しさん2012/01/29(日) 12:44:08.10
>>38
んー・・・
例を挙げると、lisp や JavaScript の実装で使われている
ポインタへのエンコーディングとか、どう?

あれって、何かそれらしい名前がついていたような気がするのだが、
思い出せない・・・
0046デフォルトの名無しさん2012/01/29(日) 13:40:51.08
オブジェクト指向の体現度って↓であってる?

C#>Java>>C++

他の候補:F#、Python、Ruby、Scala
0047デフォルトの名無しさん2012/01/29(日) 15:08:52.07
>>46
c++は規格のライブラリが貧弱なだけで、抽象度はライブラリによる

vclは優秀だった。。。
最適化でvcに負けたけど。。。
(mfcには負けてない)
0048デフォルトの名無しさん2012/01/29(日) 15:10:28.84
vclはPascalって所が欠点だった。
C++のコードデバッグで辿って行ったら途中でPascalになるんだぜ。
あ、Pascalじゃなかった。Delphiという独自拡張された言語。
気持ち悪いったらありゃしない。
0049デフォルトの名無しさん2012/01/29(日) 15:20:42.01
>>46
多分、体現度はsmalltalkが一番
その分、仮装OS的なものが必須だし、>>36の上のurl通り、全体をデバッグしてるんだが。。。

データと手続きが一緒になってるせいで並列化にも向かないって話もある

かえって構造化言語のFortlanの方が超並列ライブラリと言う資産でスパコンで現役だったり

Erlangの中の人がデータと手続きは別のものだ。一緒にするべきじゃない!と言ってたり
(日経ソフトウェア2009年6月号だったと思うけど、matzと結城さんの対談の記事で書いてた)
0050デフォルトの名無しさん2012/01/29(日) 15:28:56.73
> Erlangの中の人がデータと手続きは別のものだ。一緒にするべきじゃない!

賛成だね。

データの寿命は長いが、手続きの寿命は小さい。
データベースなんか、データ専用じゃないか。
0051デフォルトの名無しさん2012/01/29(日) 15:52:58.31
個人的にはオブジェクト指向言語の生産性はライブラリとジェネリックが肝な気がする
Cでもライブラリ充実させて、ジェネリック(C++ではテンプレート)をサポートすれば、生産性はオブジェクト指向言語と変わらんのじゃ無いか?と言う疑惑は持ってる
(疑惑だけで確証は無いんだが)
0052デフォルトの名無しさん2012/01/29(日) 17:16:31.71
OOPLでも手続きの部分はALGOL流のままだ。
smalltalkのように制御構造までオブジェクトという程まで
徹底されてないから手続き型っぽさが抜けない。
0053デフォルトの名無しさん2012/01/29(日) 18:03:12.69
>>49
fortlan2003ではオブジェクト指向が導入されたらしい
0054デフォルトの名無しさん2012/01/29(日) 18:09:51.73
ずっと気になっているんだが、fortlanじゃなくてfortranじゃね?
0055デフォルトの名無しさん2012/01/29(日) 18:36:34.01
>>54
マ板内検索したら、確かにFortranだなw
フォーミュラ何とかランゲッジって覚えてから、lanだと思ったんだが、違ったw
0056デフォルトの名無しさん2012/01/29(日) 18:38:45.15
あ、マじゃなくてム板だった
0057デフォルトの名無しさん2012/01/29(日) 22:18:10.73
お前ら相変わらず机上の空論ばっかだな
0058デフォルトの名無しさん2012/01/29(日) 23:05:26.30
というか、OOもパターンももう終わるし
0059デフォルトの名無しさん2012/01/29(日) 23:10:15.74
と言い続けてはや10年。

自分のほうが、この業界から去ってしまいましたとさ。
0060デフォルトの名無しさん2012/01/29(日) 23:48:58.28
>>57
オブジェクト指向プログラミングはともかく、オブジェクト指向設計とか、何やねん。って思うよな
クラスベースより、プロトタイプベースの方が再利用できてるじゃねえか。みたいな
クロージャの方が、継承よりも再利用に適してんじゃねぇか。みたいな

どんだけ時間の無駄だったのかと
0061デフォルトの名無しさん2012/01/29(日) 23:49:03.78
アスペクト指向ってどうなったの?
0062デフォルトの名無しさん2012/01/30(月) 00:17:51.62
プロトタイプベースで再利用ってあまり聞かないな
何の話してるの?
0063uy2012/01/30(月) 10:04:21.09
>>1
あるある
んで、決まってOOP以外はソースがダメだダメだみたいな

プログラミングしていくに当たって
設計思考がひとつしかない奴ってどうなの・・・・・・・
確かにOOPは万能で、どんなプログラムもかけるけど、あくまで汎用性が高いだけで
10段階評価で全部7程度なだけ

専門特化した設計思考も選べるなら、そっちでやったほうが効率でるんだよ
そっちは10段階評価でひとつだけ10を取って他を3くらいにするような感じ

そもそも関数型()っていう言葉があるのも、変な話

だって、関数っつったらプログラミングの最小単位だからな・・・?wwwwwwwww

関数のところまで分解して考えられるなら、そこからどんな設計思考だって作れるよ
一々、その設計思考に名前をつける事のほうが変な話、無限のパターンがあるのに
それにも気づけず、OOPしか出来ない奴、思いつかない奴、

かなりマジレスしてみた
0064デフォルトの名無しさん2012/01/30(月) 16:14:16.44
いろいろ残念な人のようだ
0065デフォルトの名無しさん2012/01/30(月) 19:36:14.18
最小単位が関数型?
0066デフォルトの名無しさん2012/01/30(月) 20:15:02.82
>>61
どうもなるはずないよ。
OOP、デザパタ、AOPなどなど、ほんとソフトウェア工学は他で使えない頭の弱い連中が
やりちらかしてきた歴史だな。そろそろ仕分けしろよ。
0067デフォルトの名無しさん2012/01/30(月) 22:04:24.68
ほらみて。これが釣りだよ。
0068デフォルトの名無しさん2012/01/30(月) 23:27:44.89
ほんとだ、>>67 がきっちり釣れてるね。
0069デフォルトの名無しさん2012/01/31(火) 16:50:31.40
oopやデザパタのメリットは低能でも分かった気になる事
関数型ではこうはいかない
0070デフォルトの名無しさん2012/01/31(火) 18:13:34.62
>>69
関数型言語の場合、まんま数学で言う特殊から一般へ。と言う手法が使えるから楽だよな
0071デフォルトの名無しさん2012/01/31(火) 22:21:39.26
>>70
なるほど。特殊から一般だな。分かった気になったぞw
0072デフォルトの名無しさん2012/02/06(月) 13:31:25.77
関数型って要するにSQLみたいなもんだろ、大丈夫、わかるわかる
0073デフォルトの名無しさん2012/02/06(月) 20:32:16.21
副問合せが理解できれば関数型も理解できるって寸法か
これで俺もいつ関数型言語の仕事がきても大丈夫だな
0074デフォルトの名無しさん2012/02/21(火) 10:23:19.08
ポリュモルピスムス(笑)
0075デフォルトの名無しさん2012/02/25(土) 01:42:03.35
モジュラー指向プログラムとオブジェクト指向プログラムの違いがわからん。
とりわけFortranの場合、90でモジュールが導入されて、モジュールの中に
手続きが書けるようになったが、さらに2003で構造体の中にも手続きが
書けるようになった。2通りの手続きを束ねる手段があって、冗長に思える。



0076デフォルトの名無しさん2012/02/25(土) 01:50:22.08
>>75
過去のやり方を無かったことにはできないから互換性のために残してんじゃないの。
0077デフォルトの名無しさん2012/02/25(土) 13:16:13.78
fortranさわったことないけど
演算子オーバーロードできるなら
オブジェクト指向の使い道はあると思う
0078デフォルトの名無しさん2012/02/26(日) 01:10:45.85
>>77
javaは使い道ありませんかそうですか
0079デフォルトの名無しさん2012/02/29(水) 01:40:37.94
>>77
 あるよ。さらに利用者定義中置演算子が定義です。ただし、これは2003の
オブジェクト指向の上に載っているのではない。Fortranには伝統的に
「総称名」という概念があって、cos(x)と書くと、xが単精度であれば、
cos(x)[字面が同じで紛らわしいが別のもの]、倍精度であればdcos(x)に
コンパイル時にディスパッチする。
 95これを利用者定義型できる。具体的には、それぞれの型ごとに
同じ形式を持つ手続きをそれぞれ定義して、これらにひとつの総称名を
割り当てるという形をとる。このとき、総称名の代わりに演算子を
割り当てることができる。
>>78
Javaが演算子再定義を持たないのは、これこれで言語仕様を簡潔に保つ
という上で適切な解だと思う。メソッド名が長いのはいとわず、英文で
説明するように処理を記述することを期待しているようなので、演算子
は削ってもいいだろう。


0080デフォルトの名無しさん2012/02/29(水) 02:20:54.99
Javaはドカタ用言語なので、演算子オーバーローディングまで出来てしまったら
ドカタが混乱する。
出来ないのが正解。
0081デフォルトの名無しさん2012/02/29(水) 08:39:55.22
>>80
演算子オーバーロードをなにか特殊なものだと思ってるの?
0082デフォルトの名無しさん2012/02/29(水) 09:33:31.31
>>81
まともなプログラマなら思わないけど、ドカタは思うだろう

…と言う意味では
0083デフォルトの名無しさん2012/02/29(水) 22:02:39.91
あぁ、自分でドカタ=混乱する人と定義してるのかw
0084デフォルトの名無しさん2012/02/29(水) 22:19:11.94
まあオブジェクト指向は最高ってことですねw

高慢と偏見(1)隣は何をする人ぞ
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html
0085デフォルトの名無しさん2012/03/02(金) 02:43:27.07
ぼくのかんがえたすごいオーバーロードが蔓延るのはよくないと考えたからJavaには無いんだろ
どこかの「ぼくがしんかさせたすごい言語」状態のゴミになるのを避けるために
0086デフォルトの名無しさん2012/03/02(金) 07:55:07.83
ぼくのかんがえたすごいフレームワークが蔓延るのは防げないのであった。
0087デフォルトの名無しさん2012/03/02(金) 08:36:04.62
ぼくのかんがえたすごいメソッドと何が違うのかわかりませんw
0088デフォルトの名無しさん2012/03/04(日) 15:21:03.73
オブジェクト指向の弊害は、バグが生じた理由を設計が悪かったの一言ですますこと。
単に力量不足、柔軟な機動力不足だろうと思ったり。
あと、設計に時間とって、UMLみたいなお絵かきを自慢げに出すようになったこと。
そんなの書くのに時間とるやつより、ちょっぱやな動作デモを即効作ってくるタイプと仕事してる方が楽しいのにな。
0089デフォルトの名無しさん2012/03/04(日) 16:18:59.26
ダクトテーププログラマが役に立つのは同意だが
オブジェクト指向の弊害云々はオブジェクト指向以外にも当てはまるからいまいち
0090デフォルトの名無しさん2012/03/04(日) 16:26:40.16
お絵かきはシステム構造図だとかDFDだとかフローチャートだとか
昔から沢山あるだろ。むしろ昔のほうが多かったぐらい。
0091デフォルトの名無しさん2012/03/04(日) 16:31:24.69
> ちょっぱやな動作デモを即効作ってくるタイプ
「動いてるからいいじゃん」タイプか。
そういう奴に任せると、後で苦労するぞ。
0092デフォルトの名無しさん2012/03/04(日) 16:51:27.83
判断基準が楽しいかどうかだしな
趣味なら別にいいが、仕事では相手にしたくないわ
0093デフォルトの名無しさん2012/03/04(日) 17:04:02.67
デモはデモだろ

「金払ってるからいいじゃん」タイプか
そういう奴に仕事もらうと、後で苦労するぞ。

これが問題なんだ
0094デフォルトの名無しさん2012/03/04(日) 17:14:21.24
再利用できるコードより、部分てきに切り貼りしたり、あるいは一から書き直しても早くできる人が役に立つでしょう。
他とのインターフェースだけオブジェクト指向とかできれいにしてりゃいいよ。
オブジェクト指向じゃないコードをバカにするわりには、面白いコードもかけない人の方が、
なんだかんだ理由をつけて進捗のボトルネックになることが多いよ。
0095デフォルトの名無しさん2012/03/04(日) 17:18:08.24
なんというか、あくまで基礎がある上でのオブジェクト指向だな。
基礎がないのに、オブジェクト指向な人が多いから、混乱するだけど、OOが悪いわけじゃないな。
0096デフォルトの名無しさん2012/03/04(日) 17:44:17.40
>>88
> ちょっぱやな動作デモを即効作ってくる
そが即効なのは「後で変更する人たちに工数を押し付けた」結果だったりするからな。
納期直前とかならそういうやり方もありだけど、普通はOOに限らず影響範囲が小さくて済むよう
それなりに設計するもんだ。
0097デフォルトの名無しさん2012/03/04(日) 17:54:39.82
>>96
その言い方をするなら、即効で仕上げて、あとで変更する人たち余裕を与えたともいえる。
ある設計が変更に耐えられる確率を定量的にいえるなら設計に時間与えてもいいけど、
いえる人っていないでしょ。
設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。
0098デフォルトの名無しさん2012/03/07(水) 10:48:41.04
>>97
> ある設計が変更に耐えられる確率を定量的にいえるなら
結合度とか凝集度がそれにあたるな。

> 設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。
設計が甘かったために、ひとつのバグ修正が2つのバグを産むという例のほうが
よっぽど多いけどなw
0099デフォルトの名無しさん2012/03/07(水) 14:26:00.68
一発で設計が上手くいくようなら、ウォータフォールでいいよね
OOPってアジャイルな開発には向いてないの?
0100デフォルトの名無しさん2012/03/07(水) 14:29:40.20
>>97
どんな開発モデルでも、後工程に行けば行くほど修正コストは飛躍的に増大する。

> 設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。

そのような経験があるからといって、設計に時間を与えなくとも良いということには
ならないのはわかるよな。
0101デフォルトの名無しさん2012/03/08(木) 00:46:55.64
ごくごく自然にに考えよう。

設計とか分析とか工程というのは、
その次の工程を行うためにやる。

つまり、その次の工程の内容を理解していなければ、
使えないものが出来るのは当たり前の話。

たとえば使えない設計書。これができてしまうその原因は
その次の工程を全く知らないからだ。

自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。
0102デフォルトの名無しさん2012/03/08(木) 17:27:07.25
もっとひどいのになると絶対実現できない機能を仕様書に平然と書いてあるとかね。
基本的な素養がね。ないとダメなんだよね。
0103デフォルトの名無しさん2012/03/08(木) 23:16:44.20
いまだにLOC以上の定量的手法ないだろ
0104デフォルトの名無しさん2012/03/08(木) 23:20:04.10
ゲームプログラマーやってるとプログラムできないSEとか理解できない。
ゲームでの企画はあくまで雑用とアイデア出しで設計するのはプログラマー。
0105デフォルトの名無しさん2012/03/09(金) 01:21:53.17
ゲーム業界での企画がSEって呼ばれてると思えばいい。
0106デフォルトの名無しさん2012/03/09(金) 01:54:44.75
普通ぷろぐらまが経験を積んでSEになるんでないの?
0107デフォルトの名無しさん2012/03/09(金) 02:40:23.74
大手は最初から上流設計しかやらせないらしい。金かけてクズを育ててるようなもんだが。
0108デフォルトの名無しさん2012/03/09(金) 05:10:43.27
興味本位で「絶対実現できない機能」の例を聞いてみたい
0109デフォルトの名無しさん2012/03/09(金) 06:17:22.66
2年ぐらいプログラム経験つませることも多いだろ
2年程度なら平均的なプログラマぐらいにはなれる
0110デフォルトの名無しさん2012/03/09(金) 07:08:50.22
http://el.jibun.atmarkit.co.jp/pressenter/2011/06/3-1e5b.html
0111デフォルトの名無しさん2012/03/09(金) 08:18:26.86
>>109
平均的なプログラマは
プログラミングをするべきだ。
0112デフォルトの名無しさん2012/03/09(金) 09:46:43.32
とりあえずワードエクセルが使えて客と会話ができればSEとしての体裁は繕えるしな
0113デフォルトの名無しさん2012/03/09(金) 13:24:09.68
平均的なプログラマってのは
クソな仕様書をつき返して問題箇所を指摘したり直させたりできるレベル?
0114デフォルトの名無しさん2012/03/09(金) 16:46:54.23
>>108
レーザープリンタで感圧紙の複写印刷が出来ますと客先で宣言されたことがある。
0115デフォルトの名無しさん2012/03/09(金) 22:09:47.36
>>84
>高慢と偏見(1)隣は何をする人ぞ
これ見ると反OO派をKOしたとOO派は思うんだろな。
もうそろそろそんなレベルを超えろよ。
OOでもまだシンドイだろ?
0116デフォルトの名無しさん2012/03/09(金) 22:44:15.44
grepが効かない!
0117デフォルトの名無しさん2012/03/10(土) 01:48:29.66
>>114
なにそれこわい

…プリンタのハード設計をしてるワケじゃないんだよな?
まあそれでもォィォィと思うが
0118デフォルトの名無しさん2012/03/10(土) 12:00:37.94
.NETは入れたくない
0119デフォルトの名無しさん2012/03/10(土) 14:05:10.78
>>114
プログラミング出来る出来ないは関係ないなw
そいつが根本的に馬鹿なだけだ
0120デフォルトの名無しさん2012/03/14(水) 08:36:19.83
プログラム初心者なんだけど、Cで構造体にデータ入れてDBに登録みたいなことをOOP型言語でやろうとしたんよ。
データには大きくわけて社員と役員という二つのタイプがあって、社員のメンバ変数は役員ならば全て持っている場合、
アクセッサー含めて役員の方にも同じメンバ変数をコピーするのは保守性下がるからよくないと思ったから継承させたんよ。

class 社員 {
int 社員番号;
String 氏名;
String 年齢;
int 給与額;
}

class 役員 extends 社員 {
String 役職;
int 役員賞与額;
}


こんな風に。
んで、Object型に格納して、社員と役員で手続きを共通化させたら、簡素で分かりやすいコードになるんじゃと期待していたんだけど、
実際は、Object型インスタンス.役職とかObject型インスタンス.役員賞与額とかいうのは、遅延バインディングにあたり、静的型づけできないから駄目だったw

じゃあ継承させずに同じメンバ変数を異なるクラスにコピーさせていかないといけないんか、とがっかりしたわ
何のための継承だったんかと
0121デフォルトの名無しさん2012/03/14(水) 08:46:41.65
だからインターフェースを継承してインターフェースでインスタンスを受けとるんだと思ったんだが違ったっけ?
0122デフォルトの名無しさん2012/03/14(水) 20:46:45.07
Objectに入れちゃったら台無しだろw
0123デフォルトの名無しさん2012/03/14(水) 20:49:14.31
>>120
Object型に格納するのがダメなだけじゃんw

初心者だと自覚しているのなら、
自分が何か見落としているだけだと
最初に考えような。

何かおかしいなら、それは自分が悪いと考える。
99%間違いないから。
0124デフォルトの名無しさん2012/03/14(水) 23:30:51.13
VB系から来た人っぽいな
0125デフォルトの名無しさん2012/03/15(木) 05:47:00.80
オブジェクト指向は、Object型指向ではないってことだな。
0126デフォルトの名無しさん2012/03/15(木) 17:03:41.60
Object型が役職とか役員賞与額とかプロパティを持っていなかったのが敗因
どこの田舎ライブラリだよ
0127デフォルトの名無しさん2012/03/15(木) 20:18:47.43
そもそもなんでObject型に格納しようとしたのか、意味不明。
0128デフォルトの名無しさん2012/03/15(木) 21:29:32.26
void* でやりとりするような感覚じゃね。
0129デフォルトの名無しさん2012/03/19(月) 01:35:47.50
それがどうかしたか?
0130デフォルトの名無しさん2012/03/19(月) 20:39:52.18
voidのような偏屈やろうは使えん
0131デフォルトの名無しさん2012/03/20(火) 11:00:59.08
OOP is shit
0132営利利用に関するLR審議中@詳細は自治スレへ2012/04/02(月) 14:40:30.89
>>125
でも、ドカタ指向なのかもしれない。
0133営利利用に関するLR審議中@詳細は自治スレへ2012/04/07(土) 23:03:04.79
>>51
>Cでもライブラリ充実させて、ジェネリック(C++ではテンプレート)をサポートすれば、生産性はオブジェクト指向言語と変わらんのじゃ無いか?
kwsk!

たとえば
qsort(void *, ....)
の void * のような型チェックなしの危険さを排除できるのでしょうか?
0134営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 01:55:12.07
オブジェクト指向が全然ダメって訳ではなくて
オブジェクト指向を盲信し、拡大解釈したり誤解していい加減なこと吹聴している椰子がウザ医
0135営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 02:12:16.49
筋外すやつが多いのは間違いないよね。
構造化みたいに対応言語使っときゃわかってなくてもある程度矯正されるレベルじゃない。
0136営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 10:23:46.94
>>134
この2行、何も言っていない(例えば、全然ダメではないのは何についても言える事だ)。
盲信している奴が悪いのではなく、OO自体が盲信・誤解を誘うまやかしだったという
事が既に明白になっている。なぜはっきりそう言わぬ。
0137営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 11:37:04.68
A ⊂ B の話しかしていないのに
勝手に A ⊃ B 前提の話をし始める >>136 みたいな香具師って
きっと馬鹿なんだろうな
文系板とかマ板ならそういうのをよく見かけるが
ム板で見かけるとは思わなかった
01381342012/04/08(日) 12:09:28.85
>>136
モジュラレィティーの向上などのために、センスと節操をもって使えばOOは役に立つことがあるから。
センスとか線引きが明確化できないものが基準だと使う人次第になるでしょ
0139営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 12:23:28.37
こうぐしって何?
0140営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 12:38:34.09
>>139
それはヤシと読むんだぜ、と釣られてみるテスト
0141営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 22:34:49.94
香具師(やし)
0142営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 22:35:36.56
香具師(ヤシ)
奴(ヤツ)
0143営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 22:54:11.95
Twitter Facebook Tumblr などを自在に使い分ける時代に、2ch用語なんて時代遅れ。
オブジェクト指向言語なんてカテゴリーで考えようとすることも時代遅れ。
0144営利利用に関するLR審議中@詳細は自治スレへ2012/04/08(日) 23:10:42.00
バカッター、フェイスバカ、手ブラ?
0145営利利用に関するLR審議中@詳細は自治スレへ2012/04/09(月) 17:12:24.86
こんにちは世界
を書くのが大変になった
0146営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 19:13:49.31
昔に書いたソースを、C++をオブジェクト指向を駆使してエレガントに書き直す作業が面白くてしょうがない。
ゲームより面白いから、ゲーム機をしばらくいじってないぐらいだ。
プログラミングって分かってくると面白いし、エレガントに書こうと思うと、いくらやってもきりがないよね。
再帰構造のクラスとか考えるのが凄い面白い。
0147営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 19:18:08.87
トイレ入ってる時とか、布団かぶって寝ようとしてる時まで、
「あ、あそこはこう書けばもっと綺麗になるな」
とか思ったり、夢の中でも考えてたり、プログラミングって面白いよね。
0148営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 19:34:43.91
でもそれってどの程度の工数の削減になるの?
って聞かれると答えられないんだよな

んで自分がやってたことが所詮子供のお遊びでしかなかったことを知って愕然とするんだ
ビジネスの場では常にコストを意識して仕事が出来る人間しか相手にされない
こんな数字にできないようなおばあちゃんの知恵袋はなんの価値もない
0149営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 19:40:25.96
わかるひとにはわかる
みてるひとはみてる
0150営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 19:54:12.16
はじめに工数と業務を全部だして
それに対してウィークポイントをはっきりさせて
それから対応しないとどうでもいい部分を削減してたり
問題になってない工数を縮小したり意味不明な行動ばっかりとるもんさ人間って
0151営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 20:03:25.34
リファクタリングがビジネス的に利益にならないこと、かえってバグを生むことぐらいは分かってるさ。
俺は趣味のプログラミングの話をしているんだ。
いくらやってもきりがない美しさへの追求。
0152営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 20:09:11.70
職人だな
0153営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 20:10:00.21
それはそれでいいんじゃないかな。気持ちは、分かる。
スキルは付くし。
0154営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 20:43:27.21
バグが出ちゃってる時点でリファクタリングじゃないけどな
0155営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 20:46:03.32
目的を見定めないで思い込みで行動してる奴なんてプロじゃねぇ!

って日曜PGと学生にえらそうに吠えるのが日課です
0156営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 20:52:44.06
動作を変えずに構造を書き換えるのがリファクタリング

プロ意識の問題では無い
0157営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 21:58:13.00
>>156
それはわかってるけどやってみたらバグっちゃうって話してんだろウンコ
お前の理解力は所詮ウンコ程度だってことだよ
0158営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 22:04:31.31
お前が間抜けというだけの話じゃねえか
0159営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 22:05:38.70
理解力がウンコでもなんとかできるようにするのがオブジェクト指向の真髄。
0160営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 22:06:00.84
>>157
プログラミングもバグるよね?

バグるから何?
0161営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 22:14:12.14
バグじゃねーよ
仕様だって言ってんだろ
0162営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 22:51:05.86
>>160
プログラミングはバグんねーよ
プログラムはバグるけど
0163営利利用に関するLR審議中@詳細は自治スレへ2012/04/10(火) 23:03:47.34
プログラマーはしょっちゅうバグるけどな。
納期すぎて怒られて徹夜させられて、会社来なくなったり。
0164営利利用に関するLR審議中@詳細は自治スレへ2012/04/11(水) 00:54:38.43
業界がバグってる
0165営利利用に関するLR審議中@詳細は自治スレへ2012/04/11(水) 01:18:25.60
>>1-1000
http://monobook.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%BB%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
0166営利利用に関するLR審議中@詳細は自治スレへ2012/04/11(水) 10:50:12.27
>>148
いままでオブジェクト指向なんてやってこなかった人を使って、
いままでと同じようなシステム作るなら、
オブジェクト指向なしでやった方が手っ取り早いもんな。
0167営利利用に関するLR審議中@詳細は自治スレへ2012/04/11(水) 15:13:51.93
【激突】関数型言語 VS オブジェクト指向言語2

上記のスレと内容がかぶってる気がする
0168デフォルトの名無しさん2012/04/11(水) 20:49:42.78
激突する相手が違うんだよ
0169デフォルトの名無しさん2012/04/11(水) 20:56:05.28
>>133
c++でテンプレートとcの文法とライブラリのみで試せば良いじゃん
0170デフォルトの名無しさん2012/04/15(日) 08:12:47.98
>>165
確信つきすぎてスレ止まっちまったじゃねーか
0171デフォルトの名無しさん2012/04/15(日) 09:54:57.14
>>165
最初の書き込みが

2012年4月10日 (火) 15:50? Administrator

これか。お前が書いたんだろうなw
0172デフォルトの名無しさん2012/04/15(日) 09:57:30.68
これのどこに知性があるのだろうか?
理詰めで技術を検証するってことができないと困るぞ

オブジェクト指向orデザインパターンを使った場合とそうでない場合と
比べて何がメリットなのかどうかを検証する作業は一度はやるべき
0173デフォルトの名無しさん2012/04/15(日) 10:03:09.01
>>172
何を今更w

各OSがオブジェクト指向で作られている
(たとえ言語がCだったとしても考え方はオブジェクト指向)

そこからも答えは明らかで、
メリットなんか、勉強すれば分かること。
0174 ◆QZaw55cn4c 2012/04/15(日) 10:27:26.31
>>173
>(たとえ言語がCだったとしても考え方はオブジェクト指向)

え!

それはあなたのオブジェクトオリエンティドの定義がユニークなだけでは?
あなたの定義を記述してください。
0175デフォルトの名無しさん2012/04/15(日) 10:31:10.13
>>174
オブジェクト指向(OO)
オブジェクト指向分析(OOA)
オブジェクト指向設計(OOD)
オブジェクト指向言語(OOPL)

この4つの違いが言えますか?

wikipediaなどでもちゃんと別物として
用意されていますから、勉強してくるように。
0176 ◆QZaw55cn4c 2012/04/15(日) 10:41:33.40
>>175
なんだか、OOと呼ばれるものを集めて列挙しているだけ、という印象をぬぐえないのですが。
列挙すればそれも定義になるというのであれば非常に楽チンではありますが、読む側はなんのことやらさっぱりわかりません。

OO ってなんですか?
いや、範囲を狭めましょう。「C 言語で OO」 という記述が具体的になにを指しているのか、あなたの言葉で説明していただけませんか?
「C 言語で OO」 という記述が具体的になにを指しているのか、例をあげてもらえないでしょうか?
<stdio.h> 中のFILE 構造体と、これのポインタを引数や返り値とする関数群、とか。
0177デフォルトの名無しさん2012/04/15(日) 10:43:22.82
OO信者にとっては何でもOOなんだよ
役立つプログラムとかは全部OO
一方、開発に失敗したらOOを使ってなかった or 理解してなかった
0178デフォルトの名無しさん2012/04/15(日) 10:43:32.30
日本のテレビの特徴:

・上にタイトルと説明が書かれている
・四隅のどこかの枠でスタジオの芸能人の様子
・スタジオに数〜数十人の芸能人が鎮座している、その大半が一言も喋らない
・韓国の人間・情報が頻繁に登場する
・下に字幕がある
・挿入曲は45秒くらい
・ヘェー、エェー、美味しそう〜、スゴーイという声がよく聞こえる
・SE丸出しの笑い声や拍手
・この後衝撃映像が!→CM数回引っ張る→予告映像に毛の生えた程度
・CMの後もまだまだ続きます→小トーク→次回予告→小トーク→終了
・CM明けに同じ映像をリピート再生する
・半端な時間で始まる・終わる
0179デフォルトの名無しさん2012/04/15(日) 10:50:14.27
>>176
> OO ってなんですか?

オブジェクトな指向。

指向
[名](スル)ある方向・目的に向かうこと。また、方向や目的を指示してその方に向かわせること。
志向。「輸出先として―する国」「主力を激戦地に―する」

考え方であって具体的なものじゃない。
具体的なものがOOPLなど。

OOPLではなくてOO(考え方)で作るのは可能。
そもそも、考え方が先にできて、それに適合しやすい言語が後から作られた。
0180デフォルトの名無しさん2012/04/15(日) 10:57:13.26
Object-oriented design patterns in the kernel, part 1
http://lwn.net/Articles/444910/

こんなのあったぞ。

Despite the fact that the Linux Kernel is mostly written in C,
it makes broad use of some techniques from the
field of object-oriented programming.

LinuxカーネルはほとんどC言語で書かれているという事実にもかかわらず、
それはオブジェクト指向プログラミングの分野からいくつかの技術の広範な使用しています。
0181 ◆QZaw55cn4c 2012/04/15(日) 11:08:47.59
>>179
いや、扱う範囲を狭めさせてください。
「C 言語で OO」 という記述が具体的になにを指しているのか、これを記述された方、また記述された方でなくとも、なにか思い当たるところをお持ちであれば是非教えてください。

私見では仮想関数の存在こそがOOで重要な点だと考えているので、仮想関数のない C でも OO ができる、という記述には違和感を感じます。
0182 ◆QZaw55cn4c 2012/04/15(日) 11:10:11.96
>>180
C で OO を標榜するのは無理がある、という立場からすれば、

>オブジェクト指向プログラミングの分野からいくつかの技術
というのが具体的になにを指すのか知りたいです。
0183デフォルトの名無しさん2012/04/15(日) 11:26:19.21
>>181
仮想関数テーブルを構造体とかに持たせる => CでOOできた!

……Smalltalkerに怒られそう
0184デフォルトの名無しさん2012/04/15(日) 11:32:51.27
クラスって関数ポインタ入れた構造体でしょ
0185デフォルトの名無しさん2012/04/15(日) 11:33:35.52
>>181
OOをサポートした言語の方がOOをやりやすいけど他の言語で出来ないわけじゃない。
昔のC++はCのプリプロセッサでC言語を吐いていたし。
0186 ◆QZaw55cn4c 2012/04/15(日) 11:37:36.70
まあ、トランスレータで吐いた C コードも OO できた!というのは認めたとしても、で、
Linux の C コードに仮想関数テーブルが存在するとは、とても信じられない。

一度みてみたい。
0187デフォルトの名無しさん2012/04/15(日) 12:32:14.01
switchでも仮想関数テーブル相当だし関数テーブルなんて普通に有りそうだし
なにをいちゃもんつけてるんだとしか思えない
0188デフォルトの名無しさん2012/04/15(日) 12:43:33.27
>>182
> >オブジェクト指向プログラミングの分野からいくつかの技術
> というのが具体的になにを指すのか知りたいです。

リンク先に書いてあります。
part1と書いてあるようにpart2以降まで有る
長い文章です。
0189 ◆QZaw55cn4c 2012/04/15(日) 12:45:03.48
そりゃ、なんでもかんでも Object Oriented といえばすむ、という風潮にいちゃもんをつけているだけです。
0190デフォルトの名無しさん2012/04/15(日) 14:08:35.33
>>189
キモい。
0191デフォルトの名無しさん2012/04/15(日) 14:19:49.53
>>188
自分の言葉で説明できないならレスなんてつけんなや坊主
0192デフォルトの名無しさん2012/04/15(日) 14:20:36.42
なぜ自分の言葉で説明しないといけないのか?
0193デフォルトの名無しさん2012/04/15(日) 14:22:06.99
>>192
なんでそんなこと説明しなきゃならんのか?
0194デフォルトの名無しさん2012/04/15(日) 14:23:03.00
説明しなくていいよw
0195デフォルトの名無しさん2012/04/15(日) 14:23:26.90
>>193
自分の言葉で説明できないならレスなんてつけんなや坊主
0196デフォルトの名無しさん2012/04/15(日) 14:23:55.24
発している言葉が真である必要があるか?
0197デフォルトの名無しさん2012/04/15(日) 14:25:04.19
使っている技術が役に立つモノである必要があるか?
0198デフォルトの名無しさん2012/04/15(日) 14:25:47.47
>>191
他人の受け売りを消化せずに自分の言葉のように発する輩も多いぞ。
0199デフォルトの名無しさん2012/04/15(日) 14:26:41.90
それの何がまずいのか?
0200デフォルトの名無しさん2012/04/15(日) 14:27:26.13
>>197
営業的に役に立つ技術と実際に役に立つ技術の2つがある。
前者は一時は流行るが直ぐに廃れる。
0201デフォルトの名無しさん2012/04/15(日) 14:27:29.81
すべてをリセットして考えよう
オブジェクト指向は役に立つ技術か?
また役に立つ必要はあるのか?
その議論に意味はあるのか?
0202デフォルトの名無しさん2012/04/15(日) 14:27:50.49
マンコ
0203デフォルトの名無しさん2012/04/15(日) 14:33:10.49
>>202
マンコの方が役に立つのは確かである。
0204デフォルトの名無しさん2012/04/15(日) 14:34:12.43
なにをもって役に立つとするのか?
0205デフォルトの名無しさん2012/04/15(日) 15:09:12.79
ホモやEDの人間からしたらマンコなんて役に立たんな
0206デフォルトの名無しさん2012/04/15(日) 18:09:12.84
>>186
vtableと実装技術は違うけど、構造体に関数テーブル持たせるのは
Linuxカーネルに限らず用いられてるごく普通のテクニック。

ドライバなんかも、論理的なインタフェースとハードに応じた実装
と分けておくことで設計をシンプルに保ってるしな。
0207 ◆QZaw55cn4c 2012/04/15(日) 19:03:19.97
>>206
>インタフェースとハードに応じた実装と分けておくこと
これが単にラッパを一段かませてある、というだけであるのならとてもじゃないが OO 由来技術とはいいがたいと悲憤慷慨すると思います。:-)

>構造体に関数テーブル持たせる
関数へのポインタを並べたテーブルを用いること自体は理解できると思います。
とりあえず、いただいたポインタを読んでいるところです。
0208デフォルトの名無しさん2012/04/15(日) 19:21:39.74
> これが単にラッパを一段かませてある、というだけであるのなら
違うよ。
0209デフォルトの名無しさん2012/04/15(日) 19:23:05.01
あぁでもOO由来ではないかもね。
元々、そういうテクニックは存在してて、それをOOがうまく取り込んだ
というのが正解に近いんじゃないかな。
0210デフォルトの名無しさん2012/04/15(日) 19:44:30.73
どんな言語で書いたものであろうと
最終的にはマシン語に変換可能である
つまりCで書けなくもない
0211デフォルトの名無しさん2012/04/15(日) 20:16:15.70
OO由来じゃないからOOじゃないってのどうか

つーか「OOにしかない」とか「OOが初出」の技術って有るの?
概念とかならあるのかも知れんけど技術は既存の寄せ集めだろ

OOPLの支援がなくてもOOPができるのは当たり前な気がすんだけど
0212デフォルトの名無しさん2012/04/15(日) 21:45:36.39
CでOOPというとGLibやGTKででてくるGObject systemとか?
0213デフォルトの名無しさん2012/04/15(日) 22:50:55.60
Xの方が有名ではないかと
0214デフォルトの名無しさん2012/04/15(日) 23:44:26.93
90年代前半からMotifはそうやっていた
いまではすっかり寂れたwidgetだが
0215デフォルトの名無しさん2012/04/15(日) 23:45:00.06
SimulaはOOPLじゃないんだろこいつのなかでは
0216デフォルトの名無しさん2012/04/15(日) 23:46:56.55
昨今のOOPのブームを見ると、車輪が再発明されるシーンを
10回くらい繰り返し見せられたような既視感に捕らわれる
0217デフォルトの名無しさん2012/04/15(日) 23:48:37.43
あとからあとから騙されやすいシンパが世代交代して湧いてくるって訳よ
0218デフォルトの名無しさん2012/04/15(日) 23:52:36.81
浜の真砂は尽くるとも、世にお間抜けの種は尽きまじ
0219デフォルトの名無しさん2012/04/16(月) 00:12:55.99
OOもそれなりに定着した気はするけどもっと収斂してもいい気もする
0220デフォルトの名無しさん2012/04/16(月) 04:48:29.95
継承、多態、カプセル化がオブジェクト指向の要素だ
と主張するやつもいれば
多態さえあればオブジェクト指向であとは誤差だ
と主張するやつもいるし永遠に収斂しないんじゃないのかな
ちなみにおれは後者の立場
0221デフォルトの名無しさん2012/04/16(月) 07:02:51.38
別に定義なんてどうでもいいや
ただ多態ってメリットあるんか?
0222デフォルトの名無しさん2012/04/16(月) 07:58:00.15
あるよ。
0223デフォルトの名無しさん2012/04/16(月) 08:40:25.90
>>220
俺はその内の一つでもあれば
オブジェクト指向だと思ってるよ。

お前の考えをさらに柔軟にした考えだ。
0224デフォルトの名無しさん2012/04/16(月) 12:24:34.95
多態は同じクラスから継承した別クラスのインスタンスを同じ配列にぶっ込んで、ループ処理させたりするのに良く使う。
頭悪い奴は、クラス定義からして間違ってるから、多態を利用するアイデアも思いつかない。
0225デフォルトの名無しさん2012/04/16(月) 13:21:59.07
実装を一つもみないで分かったつもりで多態のための基底クラスやインターフェースを作ってしまうと
いざ実装を始めたときにインターフェースに足りないものが見えてきて、
他の全ての実装クラスを巻き込んだ仕様変更の嵐に巻き込まれることになる。

多態や基底クラス考えるのはある程度実装が出揃ってからのデファクタリングだと思ってやるべき。
0226デフォルトの名無しさん2012/04/16(月) 13:27:08.71
ちょっと何いってるかわかんない
0227デフォルトの名無しさん2012/04/16(月) 13:54:09.51
高度な釣りと見たw
高度、というのは具が多く仕込まれてるという意味。
0228デフォルトの名無しさん2012/04/16(月) 22:21:35.80
>>224
いや、俺違うもん同じ配列に混ぜるようなへちょいプログラム組んだことねーし
0229デフォルトの名無しさん2012/04/16(月) 22:50:56.93
よくやるけど。てか多態ってそういうやりかたするためにあるんだし
0230デフォルトの名無しさん2012/04/16(月) 22:59:34.53
>>229
なんだ
設計下手糞な奴のためにあるのか
0231デフォルトの名無しさん2012/04/16(月) 23:04:24.39
設計が上手くないから、ひとつの配列に同じ物しか入れられないんでしょ。
0232デフォルトの名無しさん2012/04/16(月) 23:06:17.89
基底クラスの配列にサブクラスのインスタンスを格納するのはごく普通のことだろ
同じ配列に入れるのが目的で継承するとかなら別だけど
0233デフォルトの名無しさん2012/04/16(月) 23:09:58.15
>>231
入れられないじゃなくていれねーんだよ
違うもんなんだから違うように扱えよ
なんでわざわざごった煮にするんだよ
0234デフォルトの名無しさん2012/04/16(月) 23:13:26.59
WindowsAPI位しか非OO系言語のライブラリを使っていないけど、
アレでもオブジェクト指向している気がする。
ハンドルで識別される「何か」に対して操作を行うって設計に。
0235デフォルトの名無しさん2012/04/16(月) 23:25:59.45
>>233
全てはタスカー様のお導きのままに。
0236デフォルトの名無しさん2012/04/16(月) 23:29:31.58
オブジェクト指向だから何でも多態ありきでやろうとするとタスクシステムへ行き着くんですけど
信者とアンチが大暴れするあのタスクシステムに。
オブジェクト指向でも何でもない、関数ポインタの配列ぐるぐる回すだけのタスクシステムに。
0237デフォルトの名無しさん2012/04/16(月) 23:38:05.20
>>233
そもそも違うかどうかも知らんし、知る必要もない。
特定のインタフェースを実装してるかどうかだけわかってればいい。
0238デフォルトの名無しさん2012/04/16(月) 23:39:13.95
>>236
なんだそのタスクシステムって。
0239デフォルトの名無しさん2012/04/16(月) 23:45:48.28
>>238
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html
0240デフォルトの名無しさん2012/04/16(月) 23:59:02.36
>>233
君にはオブジェクト指向が向いてない
DuckTypingなんて10年も前のトピックだ
0241デフォルトの名無しさん2012/04/17(火) 00:08:30.21
>>237
でも生成するときって違いはあるんでしょ?
それをなんの意味もないのにわざわざ一箇所にまとめてるんだよね?
バッカでー
0242デフォルトの名無しさん2012/04/17(火) 00:11:07.86
>>241
一括管理できるものを、わざわざバラバラに管理する意図がわかりません。
0243デフォルトの名無しさん2012/04/17(火) 00:14:39.40
>>242
したらどうして違うクラスにしたの?
ごった煮で入ってるってことはどっかで分けないといけないよね?
0244デフォルトの名無しさん2012/04/17(火) 00:16:22.40
極端な話すべての使用するクラスのインスタンスを1つの配列に突っ込むことも可能っちゃ可能だ
実際、ゲームではそうやっちゃう人もいるしねw

彼らポリモ信者はそこに線引きはできるんだろうか?
0245デフォルトの名無しさん2012/04/17(火) 00:18:57.62
> したらどうして違うクラスにしたの?
あるメッセージを受け取った時の処理が、それぞれ異なるから。

> ごった煮で入ってるってことはどっかで分けないといけないよね?
メッセージを受信したオブジェクトがそれぞれ自分の動作をすればいい。
0246デフォルトの名無しさん2012/04/17(火) 00:20:52.18
>>243
君は怖がっているが、有用な手段であることには変わりない
怖いのならやらないのは仕方ないが、だからといってやる人間がいなくなるわけではないな
0247デフォルトの名無しさん2012/04/17(火) 00:22:38.41
>>245
やっぱ、違うじゃん
違う処理走るんだろ?
違う情報が必要になるし(この時点で引数が違う)
同じ利点がまったくねーじゃん
せいぜいfor文1つで済む程度
2つ書いてもコピペで済むレベルのはずなのに
なぜかこんなところを一生懸命まとめようとしてるのがポリモ信者(=馬鹿)
一度ポリモを使ったときとそうでないときとでコードを比べたほうがいいよ
0248デフォルトの名無しさん2012/04/17(火) 00:23:01.49
タスクシステムの何が嫌いって、ごくローカルな用語でしかないのに
>>236みたいに知ってて当然というような態度の奴がいるのが嫌い。
0249デフォルトの名無しさん2012/04/17(火) 00:24:56.84
>>247
釣りかよ…
0250デフォルトの名無しさん2012/04/17(火) 00:25:14.57
結局、削減可能工数から逆算できる技術以外はみんなカスだな
1Hもけずれねーことに力いれてんじゃねーよカス
ポリモ使ってまとめられるレベルじゃおまんまクエねーよバーカ
理詰めで仕事ができない奴って毎回こんなチンポコレベルの仕事しかできなくてはずかしくねーのか?って毎回思う
0251デフォルトの名無しさん2012/04/17(火) 00:27:20.47
>>247
> 違う情報が必要になるし(この時点で引数が違う)
仮にもオブジェクトなんだから、動作に必要な情報は自分自身が持ってるでしょ。

もし、クラスに応じて違う引数を渡さないといけないようなものをまとめてるのなら
設計が下手としか言いようがないが、下手なものを持ち出されて「ダメじゃん」
って言われてもねぇ。
0252デフォルトの名無しさん2012/04/17(火) 00:29:59.51
>>251
>仮にもオブジェクトなんだから、動作に必要な情報は自分自身が持ってるでしょ。
そうとも限らないよね?
ゲームではよくあるんだけどホーミングミサイルとかはどうしても別オブジェクトの情報が必要になる
0253デフォルトの名無しさん2012/04/17(火) 00:31:46.48
>>252
で、そのホーミングミサイルを同時に数種類動かすときどうすんの?
その種類ごとにループ作るの?
種類が増えたらループ増やすの?
0254デフォルトの名無しさん2012/04/17(火) 00:32:36.46
コピペプログラマの主張なんか聞くに値しないなwwww
0255デフォルトの名無しさん2012/04/17(火) 00:33:54.05
>>252
ホーミングミサイルというやつに、別オブジェクトの情報を持たせればいいんじゃね?
そのときに、どんなオブジェクトを追尾しててもgetLoc()で座標が取れたら便利だと思わないか?
0256デフォルトの名無しさん2012/04/17(火) 00:36:19.23
>>255
そのオブジェクトが消滅したらホーミングミサイルにどうやって通知するんだ?とか考えはじめると頭痛くなる。
0257デフォルトの名無しさん2012/04/17(火) 00:37:38.07
参照が切れるまでは消滅状態で保持する
0258デフォルトの名無しさん2012/04/17(火) 00:39:00.43
>>255
実際に狙われもしない奴のgetLoc()も実装するとかめんどくさすぎる。
0259デフォルトの名無しさん2012/04/17(火) 00:39:42.48
それこそ継承じゃん
0260デフォルトの名無しさん2012/04/17(火) 00:43:37.13
>>220
上はOOでもOOPでもなくOOPLの説明でしょ
OO自体には「オブジェクトを中心とした考え方」以上の意味はないかと
0261デフォルトの名無しさん2012/04/17(火) 00:48:56.22
ごった煮だと当たり判定で組み合わせ爆発したらどうすんのとか。
あらかじめリストを敵、弾、自機とかにわけておけば軽減できるよとか。
え、最近のPCは速いから大丈夫だって?うん、俺もそう思う。
0262デフォルトの名無しさん2012/04/17(火) 01:14:02.96
てかすでにごったの利点は消えてる
ちょっと関連が増えるとすぐにこの状態になるのがポリモ
なんの利点もねーよ
ホーミングミサイル程度も受け入れるキャパがないのがポリモ
なんの検証もしないで導入しちゃうから当然の結果

所詮似非技術者ができることなんてこの程度
農家の生まれが知的作業するなっていういい例
0263デフォルトの名無しさん2012/04/17(火) 01:18:37.31
多種多様な要件に応えるために肥大化する基底クラス。人はそれをゴッドクラス(神クラス)と呼ぶ。
0264デフォルトの名無しさん2012/04/17(火) 01:21:19.59
>>263
神クラスってのはCマガジンの誰かがつけた名前で
グローバルインスタンスホルダー(ネーミングで内容はだいたい予想できるだろw)のことだ
0265デフォルトの名無しさん2012/04/17(火) 02:13:42.40
>>262
うんだから君にオブジェクト指向は無理だから
無理しなくてもいいんだよ
0266デフォルトの名無しさん2012/04/17(火) 06:56:24.99
ゲームの例えしか出せないのはゲーム業界の奴だと思うけど、そういう奴はオブジェクト指向とか無視して
今まで通りC言語でゴリゴリ書いてりゃいいんじゃね?w
ゲームなんて突貫工事みたいに汚いコードでも、とりあえず動けばいいってな感じだし、再利用性も考えてるヒマがない。
汚すぎて常に使い捨てのソースw
バグが出ても誰に迷惑をかけるわけでもなく、単に「糞ゲー」と呼ばれるだけ。
そういう責任感が希薄な現場なので、自分もその雰囲気に染まって仕事するしかないだろう。
0267デフォルトの名無しさん2012/04/17(火) 07:06:44.04
>>265
はぁ?
俺がどうこうって問題じゃなくて
すでに利点が消えてんじゃん
問題の切り分けもできないの?バーカ
0268デフォルトの名無しさん2012/04/17(火) 07:11:51.36
認めて欲しくて必死だな
0269デフォルトの名無しさん2012/04/17(火) 07:14:10.40
>>268
は?
馬鹿なの?
すでに導入した技術の利点が消えてるのに
なんで利用しつづけようとするの?
って聞いてんだよ
0270デフォルトの名無しさん2012/04/17(火) 07:17:16.25
多態なんてミサイルとホーミングミサイル(ターゲットの引数1つ増えただけ)の違いも記述できないチャチな仕組みってことだよな
0271デフォルトの名無しさん2012/04/17(火) 08:15:28.19
弱い奴ほどよく吠える
0272デフォルトの名無しさん2012/04/17(火) 08:26:55.28
わけのわからん奴が
利点欠点入り乱れる中
ゲーム界という狭き立場で利点を欠点に変えようとしてる阿呆がいる
利点もあるし欠点もあるんだよ
0273デフォルトの名無しさん2012/04/17(火) 08:28:07.70
>>267
利点が理解できないんでしょ。だから消えてるように見える。
無理しなくていいんだって。
0274デフォルトの名無しさん2012/04/17(火) 08:30:13.31
ネタかと思ったら天然だったでござる
0275デフォルトの名無しさん2012/04/17(火) 08:36:34.74
ポリモ信者も糞だがアンチも糞ということがよく解った
0276デフォルトの名無しさん2012/04/17(火) 08:39:18.98
>>270
記述できるよw

ゲームとかでもよく使われてる。
0277デフォルトの名無しさん2012/04/17(火) 08:42:46.55
ファイルとフォルダの関係のポルモ(同一視)の利点について、どう欠点に変えてくれますか?
0278デフォルトの名無しさん2012/04/17(火) 08:54:05.22
>>247
>同じ利点がまったくねーじゃん
>せいぜいfor文1つで済む程度

コピペで済ますか済まさないかという大きな違いがある
そこの違いに意味を持たせる事が出来ないなら使いこなせませんよ

0279デフォルトの名無しさん2012/04/17(火) 09:02:47.23
>>273でFA
0280デフォルトの名無しさん2012/04/17(火) 09:08:57.65
すでに導入した技術の利点が消えてるのに
なんで利用しつづけようとするのか?

ポリモの話じゃねえじゃんww
0281デフォルトの名無しさん2012/04/17(火) 10:01:01.96
どっちも必死すぎてくだらん
0282デフォルトの名無しさん2012/04/17(火) 10:16:44.47
痛い所は全てスルー
0283デフォルトの名無しさん2012/04/17(火) 10:21:12.48
ポリモの利点を語れない奴が欠点だけ語ってんだよ

底の浅い奴だな
0284デフォルトの名無しさん2012/04/17(火) 12:34:19.04
ただのインターフェースの共通化、抽象化をOOPの成果みたいに言うのもどうかと思うがな。
0285デフォルトの名無しさん2012/04/17(火) 12:59:06.01
ゲーム業界という、質より物量を優先する所では使えないだろうな
0286デフォルトの名無しさん2012/04/17(火) 13:08:23.02
物量の無いところでポリモの出番無いんじゃ。
0287デフォルトの名無しさん2012/04/17(火) 17:39:52.15
階層型データ、例えばフォルダ/ファイルとか、ブラウザのブックマークとか、アプリのメニューバーとか、XMLパーサーとか、
そういうのを全部、再帰構造のクラスで表現するように書き直す作業をやってる。
それが凄い面白い。
クラスの中に自分のクラスのインスタンスのポインタ配列を持たせて、入れ子状態を表現する。
そうやってクラスを書くと、コード行数がもの凄い減ったし、個々の処理がシンプルで見やすくなった。
これは勉強になったわ。
オブジェクト指向は最強だ。
0288デフォルトの名無しさん2012/04/17(火) 17:43:09.63
いや、最強と言っちゃうと変な人が騒ぎ出すから…
0289デフォルトの名無しさん2012/04/17(火) 18:33:36.36
ゲームみたいに速度重要なとこじゃ使えんだろう。
オブジェクト指向厨がいくら設計がんばっても、速度でなけりゃ物量もだせないし、
全然ダメだろ。設計で速度もみつもれりゃいいんだろうけど。
0290デフォルトの名無しさん2012/04/17(火) 19:20:54.66
>>279
少なくともミサイルとホーミングミサイルでは役に立たないみたいだねw
0291デフォルトの名無しさん2012/04/17(火) 19:21:41.28
もっと建設的な言い方しろよ
全然ダメとか何様だよww

笑っちゃうだろ
0292デフォルトの名無しさん2012/04/17(火) 19:32:24.47
一連のレスを読んで、日本のゲームデベロッパがいかに低レベルか思い知らされたよ。。
もうちょっとレベルが高いものと思ってたけど、これじゃぁ欧米に勝てる見込みはなさそうだね。。
0293デフォルトの名無しさん2012/04/17(火) 19:36:10.24
>>291
本当の建設的っていうのは
役に立たないものを役に立たないと受け入れらることだろう

そもそもお前等似非技術者はなんでこんな効果のわからんもんを簡単にYesと言ってしまうのか?
お前等じゃわからないんだろ
検証の仕方も判断の記述も自分で定義できんから?
した覚えあるのか?ないだろ?

馬鹿じゃないのか?
ちゃんと検証してみろ嫌なことから目をそらすな
数字で追えば必ず答えは見える

これが見えなくなったら技術者なんて辞めちまえ
給料少ないしホントにやってる意味ないと思う
0294デフォルトの名無しさん2012/04/17(火) 19:37:51.88
>>292
>もうちょっとレベルが高いものと思ってたけど、これじゃぁ欧米に勝てる見込みはなさそうだね。。
このオブジェクト指向だのポリモだののゴミは

 向 こ う か ら き た も の だ か ら !

まあ、向こうの文化とかもよく知るべきだよね
セミナーとか金集めの道具にこういう意味不明な技術はもってこいなんだろ?
0295デフォルトの名無しさん2012/04/17(火) 19:47:25.44
頭のいい人は気がつくんだろうけどね
http://tabesugi.net/memo/2009/1a.html#152154
0296デフォルトの名無しさん2012/04/17(火) 20:00:46.27
>>295
多くの平均以下のプログラマがC++を使わなくなれば改善するよw
まぁJavaみたいに平均以下のプログラマを大量に投入するのに特化するのもありだと思うけど。
0297デフォルトの名無しさん2012/04/17(火) 20:02:54.73
理詰めでモノを考えられない似非技術者が多いのが嫌いなんだろ?
多分その人もメリットを数字であげてみろって絶対いうと思うけどね
製造業でこれがないっておかしくないか?
0298デフォルトの名無しさん2012/04/17(火) 20:07:29.53
自我強い奴に関わると疲れるだけだろ
0299デフォルトの名無しさん2012/04/17(火) 20:13:09.92
だから利点もあるし欠点もあるんだって・・

なんで欠点だけしか語れないの?
0300デフォルトの名無しさん2012/04/17(火) 20:44:23.91
>>299
利点って?
正直、引数1つ増えたごときでもう使えないんじゃ利点も糞もないと思うんだけど?
仮に引数として増やさなかったときはそのつじつまあわせは別のどっかでやるんでしょ?
これをやっちまったときの余波が正直ハンパねぇ痛さだと思う
担当者があきらめてこの時点で多態をやめてくれれば傷は浅くて済むが・・・

引数たった1こですよ
いつ必要になるかわからないレベルじゃん
これでもうこの構造ダメ
冷静に考えて使い物にならない
メリットあるとかないとかの話じゃないだろこれ
0301デフォルトの名無しさん2012/04/17(火) 20:45:39.83
そもそも引数が増えたら多態じゃねえじゃん。
馬鹿だから区別ついてないんだな。
0302デフォルトの名無しさん2012/04/17(火) 20:46:56.30
arityの概念さえしらんのか。まあこの程度のやつだったらそれも仕方ないな。
0303デフォルトの名無しさん2012/04/17(火) 20:47:16.31
ファイルとフォルダの関係のポリモ(同一視)の利点について、どう欠点に変えてくれますか?
0304デフォルトの名無しさん2012/04/17(火) 20:47:37.47
大抵の奴はこの時点でもう手段と目的が逆転しちゃってて人の話なんて聞く耳もたなくなっちゃってるけどね
意地でも多態を実現するために引数を増やさずにグローバル変数・インスタンスを使ってでもやっちゃう・・・
これがもうね・・・技術者として最悪
0305デフォルトの名無しさん2012/04/17(火) 20:50:40.02
>>303
しつこいな
糞じゃん

ごったにしなくても
普通に
フォルダに対してgetFileListでファイル一覧取得できて
フォルダに対してgetFolderListでフォルダ一覧取得できたら
みんな幸せになれんじゃねーの?
ごった煮じゃないとダメなことあるのか?
0306デフォルトの名無しさん2012/04/17(火) 20:51:30.06
あんたも十分聞く耳持ってないよ
安心しろ同類だ
0307デフォルトの名無しさん2012/04/17(火) 20:53:49.61
>>306
そのレスに技術的な指摘が入ることはこの先もないんだよなw
0308デフォルトの名無しさん2012/04/17(火) 20:58:05.32
つっこむなら全レスに突っ込んでけよww
301と302が抜けてるぞ
0309デフォルトの名無しさん2012/04/17(火) 21:07:11.83
>>305
>普通に
>フォルダに対してgetFileListでファイル一覧取得できて
>フォルダに対してgetFolderListでフォルダ一覧取得できたら
>みんな幸せになれんじゃねーの

それをしたくないから合わせるんだけど・・
0310デフォルトの名無しさん2012/04/17(火) 21:08:41.51
>>290
> 少なくともミサイルとホーミングミサイルでは役に立たないみたいだねw

成り立つだろw
なんで成り立たないと思うわけ?

片方はミサイルらしい動きで座標を決める
もう片方は、ホーミングミサイルらしい動きで座標を決める。

あとはその座標にレンダリングするだけ。
0311デフォルトの名無しさん2012/04/17(火) 21:13:17.10
>>305
>しつこいな
>糞じゃん
>
>ごったにしなくても
>普通に
>フォルダに対してgetFileListでファイル一覧取得できて
>フォルダに対してgetFolderListでフォルダ一覧取得できたら
>みんな幸せになれんじゃねーの?
>ごった煮じゃないとダメなことあるのか?

すげーうけるww
ごちゃまぜの利点理解出来ないんだなwww
0312デフォルトの名無しさん2012/04/17(火) 21:20:26.28
ゲームと言えばC++だね。
速度も速いししオブジェクト指向

ゲームプログラマになる前に覚えておきたい技術
ゲーム開発者のためのAI入門
実例で学ぶゲーム3D数学
ゲームコーディング・コンプリート 一流になるためのゲームプログラミング
ゲームプログラミングのための3Dグラフィックス数学
ゲームエンジン・アーキテクチャ

最近ゲーム関連の良書が増えたけど
ことごとくC++ばかりだし。
0313デフォルトの名無しさん2012/04/17(火) 21:21:19.70
ホーミング先の選定なんて引数で渡す必要すら薄いのだが…
そのミサイルオブジェクトのオーナーに尋ねればいいだろ
0314デフォルトの名無しさん2012/04/17(火) 21:24:57.01
>>305
強引に否定してるだけだろ、それwww
利点を消してんじゃん、なにやってんのww
0315デフォルトの名無しさん2012/04/17(火) 21:26:32.58
ホーミングミサイルの仕様から考えると、
ミサイルの周りの状況を認識する機能が必要。

周りの状況を認識するってのは
ホーミングミサイルだけに必要な物じゃないだろうから。
すべてのオブジェクトに周りのオブジェクトの状態を認識するための
インターフェースを基底クラスにつけることになるだろうね。
03162872012/04/17(火) 21:28:53.21
>>303
自分もファイルクラスを継承してフォルダクラスを作ったわ。
そうすると、フォルダクラスが持つ子供リストはファイルクラスの(ポインタ)配列だけで済む。
ファイルの配列とフォルダの配列を別々に持つと、ものすごい気持ち悪い処理になるので、すぐにダメだと分かった。
0317デフォルトの名無しさん2012/04/17(火) 21:32:13.14
>>305
再帰的に作った方が楽ですよ?
0318デフォルトの名無しさん2012/04/17(火) 21:32:19.38
気持ち悪い処理っていうのは、名前とか日時とかいう属性でソートしたりするときの話ね。
0319デフォルトの名無しさん2012/04/17(火) 21:38:19.81
>>317
楽じゃないですよ?

理由ぐらい言ってから、「楽ですよ」と言いなさい。
0320デフォルトの名無しさん2012/04/17(火) 21:40:27.34
www
まだいたのかよ
随分ツッコミが飛んでるぞ
0321デフォルトの名無しさん2012/04/17(火) 21:40:56.79
>>320が今から突っ込むので期待して寝ろ!
0322デフォルトの名無しさん2012/04/17(火) 21:42:58.98
クラスそのものが再帰構造(入れ子)になっている場合、「再帰関数」というものを使う必要がない。
常に自分の子供のことだけを考えて処理を書けばいい。
それだけで、rootから簡単にツリー上の全体の数を調べることができる。
0323デフォルトの名無しさん2012/04/17(火) 21:48:23.61
ごちゃまぜの利点なんて
共通メインルーチンを作る仕組み
それだけだが、それが狙いなのに

共通メインルーチン否定して何がしたいの?
0324デフォルトの名無しさん2012/04/17(火) 21:50:06.14
基底クラスの肥大化を防ぎ、設計をシンプルにします。
0325デフォルトの名無しさん2012/04/17(火) 21:51:12.20
馬脚を表すのが怖くて>>301-302にはレスできない模様ですwwww
もう馬脚を表してるんだから怖がる必要ないのにwwwww
0326デフォルトの名無しさん2012/04/17(火) 22:01:33.62
オブジェクト思考にこだわる奴は糞だが、否定する奴も糞すぎるwww
0327デフォルトの名無しさん2012/04/17(火) 22:03:49.09
何を今更・・
次元の低い言い争いですね
0328デフォルトの名無しさん2012/04/17(火) 22:04:42.86
>>326
お前はビルの屋上から道行く人を眺めて王様気分に浸ってるのがお似合いだよ
0329デフォルトの名無しさん2012/04/17(火) 22:05:22.40
>>326
満足したなら帰れよw
どうせ他に何も言えることがないんだろう?
0330デフォルトの名無しさん2012/04/17(火) 22:14:52.76
>>309
え?なんで?
ちょっとコード書いてみ?
ファイルとフォルダで別のが楽だろ?
0331デフォルトの名無しさん2012/04/17(火) 22:18:37.40
そもそも多態なんてオブジェクト指向特有の概念ではなくて
ただ扱いやすいように整備されてるだけの話なんだけどな

unixのファイルシステムなんて多態の最たるものじゃないか
0332デフォルトの名無しさん2012/04/17(火) 22:19:18.78
>>331
デバイスドライバもそうだな。
0333デフォルトの名無しさん2012/04/17(火) 23:05:32.54
>>330
ウザすぎ
0334デフォルトの名無しさん2012/04/17(火) 23:07:55.54
>>333
人格否定が出るってことは技術的な指摘ができなくなったってことだよな
弱いw
0335デフォルトの名無しさん2012/04/17(火) 23:09:23.35
いやだから何回も指摘してんじゃん
>>330
について語ってやれよ
0336デフォルトの名無しさん2012/04/17(火) 23:09:52.84
>>331
0337デフォルトの名無しさん2012/04/17(火) 23:11:15.91
>>330
利点が見えない時点で終わってる
0338デフォルトの名無しさん2012/04/17(火) 23:25:24.18
痛い所は全てスルー
技術的なスレにツッコミいれていけよ
>>301,302,309,331
の解答が無いよ
0339デフォルトの名無しさん2012/04/17(火) 23:32:48.50
>>330
うけるww
0340デフォルトの名無しさん2012/04/17(火) 23:40:04.42
>>330
宗教の勧誘だなww
0341デフォルトの名無しさん2012/04/17(火) 23:42:13.85
>>338
なんか答えてもまったく実りがなさそうなんだけどw

>>303
多分、この特別頭悪いの君だよね?
何が利点だったの?
数字をあげてメリットを教えてくれる?
コード量でもコーディング時間でも君の好きな数字でいいよ
0342デフォルトの名無しさん2012/04/17(火) 23:43:21.21
>>338
多態でないものを多態と思いこんで「多態使えねー」とか、
多態を効果的に使っている例を無視とか何だかなというかんじ。
ちょっと前までは釣りかと思ってたけど、ほぼ天然で確定だと思うわ。
0343デフォルトの名無しさん2012/04/17(火) 23:45:16.70
>>342
ミサイルとホーミングミサイルの例では多態はダメだって結論が出た話しただけだよね?
君がどのレスをしたのか俺はよく知らないけど
なにか有効なレス出たっけ?wごめん本当にわからなかったわw
0344デフォルトの名無しさん2012/04/17(火) 23:50:28.82
>>343
じゃあファイルシステムの例でいこうか。
WindowsではNTFSやFATやSMBがファイルシステムとして実装されてる。
これはファイルシステムの外から見ると全く同じように使える(=多態である)
それぞれのファイルシステムごとに
ntfs_openやらfat_openやらsmb_openやらの関数を用意して
アプリケーションから使い分ける実装ももちろん可能だが、
ただひとつopenという関数でどのファイルシステムでも使えた方がずっと労力がかからないし、
別のファイルシステムが実装されたとしてもプログラムに変更を加える必要はない。

これを利点と言わずしてなんと言おうか。
0345デフォルトの名無しさん2012/04/17(火) 23:59:25.11
>>344
え?
それってさっきのファイルとフォルダがごったになってる話とリンクしてんの?
んでもって仮にそうだとしてなんの処理やること想定してんの?
0346デフォルトの名無しさん2012/04/18(水) 00:00:44.11
>>345
どこをどう読んだらファイルとフォルダがごったになった話とリンクしてるように読めるんだ。
0347デフォルトの名無しさん2012/04/18(水) 00:01:53.61
>>346
え?
急になんの話はじめたの?
0348デフォルトの名無しさん2012/04/18(水) 00:03:24.49
>>347
>>311の話を引き継いでいるんだけど。
まあ理解できないなら別にいいです。
0349デフォルトの名無しさん2012/04/18(水) 00:04:30.04
ごめん、>>311じゃなくて>>331だったわ。
お詫びして訂正いたします。
0350デフォルトの名無しさん2012/04/18(水) 00:04:51.99
>>348
あ、やっぱリンクしてたの?
レスもごった煮なんだ?
0351デフォルトの名無しさん2012/04/18(水) 00:06:02.90
さっそくアドレスミスって例外エラーとかおめでてーな
0352デフォルトの名無しさん2012/04/18(水) 00:07:29.17
まあでもファイルシステムの具体例を見て利点がおぼろげなりとも想像もできないようだったら、
プログラマは向いてないと思うよ
0353デフォルトの名無しさん2012/04/18(水) 00:19:59.38
スルースキルが大切なスレだな
0354デフォルトの名無しさん2012/04/18(水) 00:46:20.79
>>352
ファイルシステムって多態が使われてるの?
どうみても組み込み分野なんだけど
0355デフォルトの名無しさん2012/04/18(水) 00:49:19.16
後、利点に見えないんだよね
switch caseでわけても同じことできるっしょ?
単に多態つかって表現してみました程度にしか見えない

これで工数はいくつ削減できるの?
別に工数じゃなくてもいいけど数字で説明してみ?(強制ではないけど)
0356デフォルトの名無しさん2012/04/18(水) 00:56:06.00
>>354
組み込み分野なら多態が使われないと言いたいのなら、それは思い込み。

>>355
> switch caseでわけても同じことできるっしょ?
ドライバ増えるごとに、カーネル側のコードをいちいち書き換えるの?
0357デフォルトの名無しさん2012/04/18(水) 00:58:57.85
>>354
多態は別にオブジェクト指向特有の概念ではない。
抽象化の手法に過ぎない。
ただしオブジェクト指向言語においては多態が使いやすくなるように仕掛けが用意されている。
なので組み込み分野だろうがなんだろうが関係なく使える手法だ。

>>355
世の中にごまんとあるファイルを扱うアプリケーションを想像してみよう。
新しいファイルシステムが実装されるたびにこれらアプリ全てでcaseの場合分けを増やしてリコンパイル、テスト、公開をやるのかい?
実際にここ10年でWindowsにはftpファイルシステムやwebdavファイルシステムが増えてるし、
リリースはされなかったがWINFSという新しいファイルシステムがvistaで登場する予定だった。
こういったファイルシステムが登場したときにアプリケーションの修正を一切せずとも正常に動作するのは多大な利点だ。

これで理解できないのだったら、もう諦めるよ。
0358デフォルトの名無しさん2012/04/18(水) 00:59:27.61
>>355
動的にロードしたいドライバなんかは、
新しいドライバモジュールロードする度にカーネルコードの書き変えと
コンパイルが必要になるよ?
0359デフォルトの名無しさん2012/04/18(水) 01:15:06.10
>>356
え?実際に使われてるの?
それとも例としてあげただけ?
0360デフォルトの名無しさん2012/04/18(水) 01:15:22.75
WindowsAPIの涙ぐましい努力の跡を見るに、最初に作った共通インターフェースは未来永劫足かせになる。
そして16bitから32bitへ、そして64bitへ移行するにつれて○○Exとかいう拡張関数が次から次へと追加され
基底クラスは過去との互換性のためにぐちゃぐちゃになっていく。
0361デフォルトの名無しさん2012/04/18(水) 01:25:00.99
>>359
構造体+関数ポインタという素朴な形から、Strategyパターンのようなものまで
ありとあらゆる形で出てくる。
0362デフォルトの名無しさん2012/04/18(水) 04:38:53.64
>>360
そしてWindows RTで仕切りなおしというわけだよ。
互換性を保ちながら仕切りなおしが出来る
この体力がWindowsの強さである。
0363デフォルトの名無しさん2012/04/18(水) 05:56:39.12
見事な平行線だな
0364デフォルトの名無しさん2012/04/18(水) 06:13:31.67
問題を解決するより
不満を解決する方向に行ってる
0365デフォルトの名無しさん2012/04/18(水) 06:53:47.21
共通インタフェースを
この通りに作れば良いのか楽だなと取るか
テンプレあんのかよ、足かせだなと取るか

両者の言い争いは泥沼化していく
0366デフォルトの名無しさん2012/04/18(水) 07:18:47.41
まとめる事が嫌いな奴が
ごり押ししてるだけ

ファイルとフォルダの関係っつう極簡単な物まで分けて考えろとか、言ってる事めちゃくちゃ
0367デフォルトの名無しさん2012/04/18(水) 07:20:02.98
>>366
え?真面目な話なんかメリットあったの?
0368デフォルトの名無しさん2012/04/18(水) 07:21:07.65
ミサイルとホーミングミサイルだとまったくメリットなかったみたいだけどね
似てるけど
0369デフォルトの名無しさん2012/04/18(水) 07:28:10.98
この人の中でシンボリックリンクはどうなるんだろ
ディレクトリの一覧、通常ファイルの一覧を得る関数のどちらかで取得?
それとも、シンボリックリンクの一覧を得る関数が別に用意されるのだろうか
0370デフォルトの名無しさん2012/04/18(水) 07:32:45.13
>>368
んじゃ、微妙に目標へ曲がるレーザーとか
普通のレーザーとかも
「微妙に曲がるレーザー配列」や「普通のレーザー配列」とかに別々に詰めるの?
「こんな新しいタイプの攻撃も考えたから実装よろ」って言われたら
その都度配列増やしてループ増やしていくの?
0371デフォルトの名無しさん2012/04/18(水) 08:03:19.14
複雑にしたら害悪だが、まとめる事は良い事だ
その二つがポリモ化してるのが原因
0372デフォルトの名無しさん2012/04/18(水) 09:32:44.90
>>370
なんか神クラスとかいう言葉が出てきてたけど、神関数や神ループが必要になる予感。
神switch-case文も。
0373デフォルトの名無しさん2012/04/18(水) 09:36:30.21
オブジェクト思考のポリモなんてなんの意味もない
↓
単純なファイルとフォルダの関係についてまとめて扱える事が利点だ
↓
別けて作った方が楽だろ
↓
え?真面目な話なんかメリットあったの?
0374デフォルトの名無しさん2012/04/18(水) 09:47:38.14
単純にポリモ使って、複雑化して蛇足になってるって話なら良かったのに、
ファイルとフォルダシステムという簡単な仕分けにまで糞認定したのが哀れだよ
0375デフォルトの名無しさん2012/04/18(水) 10:04:26.35
キチガイに踊らされすぎたな
クリティカルシンキングが足りなかったと思う
0376デフォルトの名無しさん2012/04/18(水) 10:16:30.04
>>373
微妙に違う

オブジェクト思考のポリモなんてなんの意味もない
↓
単純なファイルとフォルダの関係が利点だ
↓
別けて作った方が楽だろ
↓
まとめた方が楽だろ
↓
え?真面目な話なんかメリットあったの?
0377デフォルトの名無しさん2012/04/18(水) 12:08:51.49
そしてなぜかファイルシステムの話には沈黙するのであった
0378デフォルトの名無しさん2012/04/18(水) 12:18:54.65
一旦ごった煮にしておいてあとから区別するのだけが糞。
*区別しなくて良いものを* ひとくくりで扱うのがポリモのメリット。
0379デフォルトの名無しさん2012/04/18(水) 13:06:38.47
上の方で散々ポリモを使って段々カオスになっていく。設計もまともに出来ない奴が使って阿呆すぎ。
とか散々言ってんのに
設計の見通しが楽で、簡単にまとめる事が出来るファイルシステムの話なのに、別けて考えた方が楽だろ発言。

途中で誰かと入れ替わったんだろ
それか本物の阿呆だったか
0380デフォルトの名無しさん2012/04/18(水) 13:32:40.14
自分が理解できない概念は否定したくなる「酸っぱい葡萄の論理」だよ、分かってやれ。
0381デフォルトの名無しさん2012/04/18(水) 14:16:04.08
ポリモとか下級戦士じゃ殆ど活躍の機会がないから、糞認定するのはわかるけど
比較的わかりやすい、唯一の良心となっているcompositeパターンにまで噛み付くとはな
0382デフォルトの名無しさん2012/04/18(水) 14:16:44.18
compositeのキモは多態よりも再帰だろ常考。
0383デフォルトの名無しさん2012/04/18(水) 14:20:33.38
再帰も否定してたじゃんw
0384デフォルトの名無しさん2012/04/18(水) 14:32:06.19
ファイルとフォルダの関係がcompositeじゃん・・
0385デフォルトの名無しさん2012/04/18(水) 14:33:06.52
ツリーの要素がディレクトリとファイルしかないんだったら
一通り愚直にコーディングしてみて、さあcompositeでスマートにまとめてみようかなと思ったときには
必要な機能は大体完成していて、それ以上手を入れる旨味が無い。
0386デフォルトの名無しさん2012/04/18(水) 14:52:34.90
頭の中でまとめれないんだな・・
0387デフォルトの名無しさん2012/04/18(水) 14:57:39.45
>>385
設計の工程全否定だなww
0388デフォルトの名無しさん2012/04/18(水) 15:00:05.14
状態がディレクトリとファイルの2パターンしか無くて、
設計の段階でそれ以上追加も無いってわかってるんだったらifで分けても楽勝じゃん。
0389デフォルトの名無しさん2012/04/18(水) 15:05:42.05
>>385
>>388
あらかじめcompositeパターンというまとめた物が頭の中にあるのに、なんでごり押しでプログラム作ったの?
0390デフォルトの名無しさん2012/04/18(水) 15:09:07.38
まとめたくないんだなww
0391デフォルトの名無しさん2012/04/18(水) 15:10:47.32
>>388
なにかやるたびにいちいちifで場合分けするよりポリモでコードを分離しておいた方がはるかに見通しがよくて楽
0392デフォルトの名無しさん2012/04/18(水) 16:54:28.17
>>385
フリーダムなコーディングだな

>>388
これだけの話なら全然いいけど、385が前提となるとなんとも言えんな
0393デフォルトの名無しさん2012/04/18(水) 18:33:46.01
ファイルとフォルダってのがまた絶妙だな。
実際、共通にする意味はないだろうな。
ファイルとフォルダでインターフェースがずいぶん違うだろうし。
共通になりそうな部分を括り出しても、
意味のないインターフェースが一つ増えるだけだろう。
そもそも、GetFile()でIFileBaseが返されるとして、
それがフォルダかファイルか調べたりキャストしたり等々、
実は余り便利ではないしな。
0394デフォルトの名無しさん2012/04/18(水) 18:49:14.26
しかしWindowsでもunixでもディレクトリはファイルの一種として実装されている事実
0395デフォルトの名無しさん2012/04/18(水) 18:49:50.98
これは個人的な見解だけど、
迷ったら使わない、必要がなければ使わない、だとおもう。
ほら、買い物の名言に、迷ったら買わないってあるじゃん。
インターフェースと制御構造とデータ構造、
同じところでスパっと切り取れりゃ良いんだが、
実際にはそれなりの粒度で無いとなかなか。
0396デフォルトの名無しさん2012/04/18(水) 18:54:15.59
>>394
でもね、今欲しいのは低レベルIOなのかって言う。
その理論なら、intもfloatも4バイトのビット列なんです、になるだろ?
0397デフォルトの名無しさん2012/04/18(水) 19:00:49.22
あと、オレなら仮にファイルとフォルダを纏めるにしても、
普通にis_directoryフラグを設けて switch なり if なりするぜ。
この二つしか種類がないって分かりきってるからな。
0398デフォルトの名無しさん2012/04/18(水) 19:24:43.83
パイプかもしれない。
0399デフォルトの名無しさん2012/04/18(水) 19:46:26.90
中々笑えるスレだな
0400デフォルトの名無しさん2012/04/18(水) 21:15:35.05
>>396
intとfloatとはいい例を挙げてくれた。多分Cだと思うんだけど+演算子も多態だよ。
intとintの和もintとfloatの和も実際のコードは異なるのに同じ+で表現できる。
もちろんintとfloatの内部表現は異なる。なので

> その理論なら、intもfloatも4バイトのビット列なんです、になるだろ?

とはならない。内部表現に関わらず同じような操作は同じような名前で呼び出せるのが多態だ。
こんな初歩的なところも理解せずに君は批判してるのかい?
0401デフォルトの名無しさん2012/04/18(水) 21:26:38.50
>>397
そんなことはないよ。デバイスファイルはどうするんだい?
0402デフォルトの名無しさん2012/04/18(水) 21:29:54.16
>>400
でもいっしょにされるとなにかと困っちゃうよね
四則演算のどれも注意が必要
全部いっしょにしてよなんてのはよほどの馬鹿しかいない
同じ+でなんて

 余 計 な こ と す る な !

と叫びたくなるな
0403デフォルトの名無しさん2012/04/18(水) 21:31:09.06
あ、ちなみにごった煮の場合ね
俺はintとfloatはちゃんと別にもつからね
0404デフォルトの名無しさん2012/04/18(水) 21:32:10.97
>>400
文字列の足し算と数値の足し算はまるで違うし、オブジェクトの足し算もありうる。
また数値は数値でもビッグなインテジャーもあれば文字列表現されている数値もある。
結局は各組み合わせごとに加算方法を定義する必要があるわけで多態なんかお呼びじゃないよ。
プリミティブな変数に限ってコンパイラが頑張って暗黙的なキャストしてるけど、
どの型にキャストするのかについてどの型が上位かという序列を内部でもってるわけだし。
0405デフォルトの名無しさん2012/04/18(水) 21:34:29.01
>>404
>結局は各組み合わせごとに加算方法を定義する必要があるわけで多態なんかお呼びじゃないよ。

多態はまさに各組み合わせごとに加算方法を定義するわけなんだが。
多態のキモはそこではなくて「同じ名前で呼び出せる」ことにあるんだけど、
まだそこは理解できないのかい?
0406デフォルトの名無しさん2012/04/18(水) 21:36:01.38
別に余計なことするなとかそんなことはどうでもよくて多態の一例というだけのこと。
ポインタと整数の加算も余計なことかい?
0407デフォルトの名無しさん2012/04/18(水) 21:36:47.91
>>406
うん
エラー出して止まってほしいね
0408デフォルトの名無しさん2012/04/18(水) 21:40:41.02
gotoさえあれば関数なんて必要ないだろ、って言い張ってるやつを一所懸命説得してるようなもんだなwwwww
無駄だからやめとけよwwwwww
0409デフォルトの名無しさん2012/04/18(水) 21:46:44.09
>>405
演算子や関数のオーバーロードは多態じゃないよ。
0410デフォルトの名無しさん2012/04/18(水) 21:47:53.46
いたい!
0411デフォルトの名無しさん2012/04/18(水) 21:48:55.72
>>409
君は多態とオーバーロードの区別もつかないのか…
0412デフォルトの名無しさん2012/04/18(水) 21:53:21.37
>> 368
> ミサイルとホーミングミサイルだとまったくメリットなかったみたいだけどね
> 似てるけど

わざとかな?
メリット有るって結論がでて、
それに対する反論ないよね?

で見なかったことにするようなレスをするとw
0413デフォルトの名無しさん2012/04/18(水) 21:54:04.54
どうでもいいから
ミサイルとホーミングミサイルを多態で表現してみろよ
レーザーとホーミングレーザーでもいいぞ
0414デフォルトの名無しさん2012/04/18(水) 21:54:38.99
>>411
おまえは変態だろう。
0415デフォルトの名無しさん2012/04/18(水) 21:57:06.67
>>413
ミサイル 発射
ホーミングミサイル 発射
0416デフォルトの名無しさん2012/04/18(水) 21:58:12.79
糞スレ化してんぞ
頭冷やして書き込めよ
0417デフォルトの名無しさん2012/04/18(水) 21:59:53.25
>>415
ホーミングミサイルくんはターゲットがわからないと追尾できないのだ・・・
0418デフォルトの名無しさん2012/04/18(水) 22:01:14.00
「オブジェクト」と呼べるようなものが
あるアプリには多態は必須だろうね。

ここでいうオブジェクトというのはオブジェクト指向用語の
オブジェクトではなく、言葉通りの意味の”物”
パーツとか言ってもいい。

例えばシューティングゲームだと、敵キャラとか自機とか。
モデリングツールだと円とかシェイプとか。
ブラウザだと各エレメントとか

こういう"物”がたくさんあってそのバリエーションが
多かったり、カスタマイズして増えたりするのは
多態を使わないと工数がかかってしょうがなくなる。
0419デフォルトの名無しさん2012/04/18(水) 22:01:46.30
>>417
当たり前だろ何言ってんだあんた
0420デフォルトの名無しさん2012/04/18(水) 22:02:13.59
>>417
生成するときに相手を指定したらいいんじゃないの
0421デフォルトの名無しさん2012/04/18(水) 22:02:26.05
>>417
え? その答えも上に書いてあったじゃん?
ターゲットが分かるようにすればいいだけ。

そのレスを引用してくれる?
そしたら話し続けようね。
0422デフォルトの名無しさん2012/04/18(水) 22:04:03.62
>>420
多態を使う時newの引数を変えていいの?

たとえば
Missile m = new NormalMissaile();
Missile m = new HormingMissaile(target);

こんなのやったらだめだよね?
0423デフォルトの名無しさん2012/04/18(水) 22:04:29.98
>>422
良いに決まってるだろw
0424デフォルトの名無しさん2012/04/18(水) 22:04:55.29
はたして、できるからといって
やっていいものだろうか?
0425デフォルトの名無しさん2012/04/18(水) 22:09:14.92
とんでもないもんが出てきたなww
ウケルww
0426デフォルトの名無しさん2012/04/18(水) 22:12:56.22
そもそもホーミングミサイルだってターゲットが必要っていうけど
途中消失や相手を見失ったときの索敵も実際は必要になるんだからね!
発射したばかりはターゲットもいないだろうよ
ただ、撃った方向に飛ぶだけだ
索敵して敵を見つけてはじめてホーミングミサイルとしての役目に移るのだよ!
そして、敵を見失ったらまた敵を探すのだよ!
一般的なゲームでそこまでやってるかどうか知らんが俺が組んだときはそうしたのだよ
目視では当然わからんが・・・w
0427デフォルトの名無しさん2012/04/18(水) 22:14:00.42
Missile m = new NormalMissaile();
Missile m = new HormingMissaile(target);

↓これが多態
m.発射()
0428デフォルトの名無しさん2012/04/18(水) 22:14:56.66
>>427
索敵機能もないホーミングとかゴミなもん作りやがって
0429デフォルトの名無しさん2012/04/18(水) 22:16:13.23
笑わせんなよww
0430デフォルトの名無しさん2012/04/18(水) 22:17:15.12
>>426
じゃあ相手を探す機能をつければいいだけでは?
0431デフォルトの名無しさん2012/04/18(水) 22:17:28.88
ホーミングミサイルはロックオンしてから飛ばすってお母さん教えたわよねぇ?
0432デフォルトの名無しさん2012/04/18(水) 22:18:43.47
>>430
関連は敵リスト全部っすか?
第三者クラスが必要な規模
0433デフォルトの名無しさん2012/04/18(水) 22:19:25.33
>>426
ゲームであれば、少なくとも
レンダリング時など一定時間ごとに
呼び出されるメソッドがある。

そのメソッドで、相手を探せばいいだけではないのか?
0434デフォルトの名無しさん2012/04/18(水) 22:21:07.97
>>432
敵リスト全部つーか敵リストをひとつ持ってりゃいーじゃん
0435デフォルトの名無しさん2012/04/18(水) 22:22:33.50
>>432
> 関連は敵リスト全部っすか?
関連?

ホーミングミサイルの仕様によるが
ミサイルに一番近い位置にいる敵を、
ゲームシステムオブジェクト(仮)に
問い合わせればいいだけ。

ゲームシステムオブジェクトは
すべてのミサイル等をレンダリングなどの機能を持っており
すべてのオブジェクトを管理しているもの
0436デフォルトの名無しさん2012/04/18(水) 22:23:25.02
俺のホーミングミサイルは障害物も壊せる
敵のホーミングミサイルからすれば自機をもってないとね
んなわけで自機ホーミングと敵ホーミングなんてできたりしてw

は?デコイ?なんだデコイって?
とかつくと余計ややこしい
0437デフォルトの名無しさん2012/04/18(水) 22:25:02.27
> 俺のホーミングミサイルは障害(ry

話も聞かずに略すけどw

ミサイルを含めた各オブジェクトは
衝突時にイベントハンドラが呼ばれ
衝突相手を取得できる。

その相手に従って、自分の状態を変えるように作ればいいだけ

で、話は?w
0438デフォルトの名無しさん2012/04/18(水) 22:25:30.28
ああ、それとシールドで跳ね返ったホーミングミサイルは
敵ホーミング→自機ホーミングになるから(by企画)

へーい(糞が、だれも気がつかねぇよそんなの)
0439デフォルトの名無しさん2012/04/18(水) 22:27:31.49
プログラマ「仕方ないな。じゃあ自機ホーミングと敵ホーミングなんて区別やめて、
シールド衝突時に敵限定でターゲットを再検索するか」
0440デフォルトの名無しさん2012/04/18(水) 22:27:43.41
デコイがあるときは自機はターゲットにしないっていっただろ!
そんなこともできないのかよ!

↑俺が企画様(5つ下)から承った言葉
STGじゃないけどねw
0441デフォルトの名無しさん2012/04/18(水) 22:29:04.94
>>440
そんなことも出来ないのかよw

ターゲット取得時に、デコイを返すだけだろw
0442デフォルトの名無しさん2012/04/18(水) 22:30:18.74
>>440
多態を使わないと、どんどん複雑になって
管理できなくなるような話をしてるなw

多態を使わなければIFの嵐だろうね。
0443デフォルトの名無しさん2012/04/18(水) 22:33:16.88
>>441
敵ホーミングの目標消失時チェックで自機がいなかったら〜的なプログラム組んでたから
デコイが考慮されてなかっただけでぶっちぎれなされた模様
0444デフォルトの名無しさん2012/04/18(水) 22:39:08.29
知らんよ。キレたとか個人的な話はどうでもいい。
0445デフォルトの名無しさん2012/04/18(水) 22:41:52.42
企画様を多態で黙らせてくださいよ!
0446デフォルトの名無しさん2012/04/18(水) 22:43:09.26
企画様をバッドで黙らせればいい。
0447デフォルトの名無しさん2012/04/18(水) 22:55:45.92
>>442
多態で吸収しきれないだろこんなの
0448デフォルトの名無しさん2012/04/18(水) 22:56:46.89
じゃあ何で吸収します?
0449デフォルトの名無しさん2012/04/18(水) 22:59:59.50
>>448
超必殺switch caseですべてのケースを書き出す
判定が重複したときも1つのケースとしてすべて書き出す
でないと複雑すぎてやってられん・・・
0450デフォルトの名無しさん2012/04/18(水) 23:01:58.04
なんだ、釣りだったかw
わざと反対の事を言うってやつだな。
0451デフォルトの名無しさん2012/04/18(水) 23:03:09.77
仕込みがなげえな
0452デフォルトの名無しさん2012/04/18(水) 23:03:10.88
複合要素を複合要素のままほっとくと修正できないぞ
保守とかそういう次元じゃなくて1つのプロジェクト期間内で修正が効かなくなる
これはマジで
0453デフォルトの名無しさん2012/04/18(水) 23:04:34.69
デコイはヤフオクで買える
0454デフォルトの名無しさん2012/04/18(水) 23:04:59.95
敵リスト作るとか、
そのうち敵弾リストとか自弾リストとかできていって
何のために多態してるのかわからなくなるな。
0455デフォルトの名無しさん2012/04/18(水) 23:08:15.87
>>454
まあ、普通にリストは共通オブジェクトのリストですよね。
ゲーム内に登場するすべてのオブジェクトの上位クラス

そこから、敵のみをリストでフィルタして抽出してとか
あるでしょうが。
0456デフォルトの名無しさん2012/04/18(水) 23:08:27.40
自機or敵デコイリストはあったほうが便利だ
どっちにしろデコイ有効範囲はその都度チェックいるけど
0457デフォルトの名無しさん2012/04/18(水) 23:09:54.27
LINQ(やっと俺の出番が来たようだな・・・)

↑ないって、お前無駄多いし
0458デフォルトの名無しさん2012/04/18(水) 23:12:22.33
>>456
そうやっていろんなリストを作るのが
オブジェクト指向に反してるっていうのw
0459デフォルトの名無しさん2012/04/18(水) 23:52:56.03
ミサイルとホーミングミサイルよりは
自機リストと敵リストのがいくらか多態しやすそうじゃね?
0460デフォルトの名無しさん2012/04/18(水) 23:53:51.91
「ゲーム会社に居るんですが、オブジェクト指向がまったく分かりません。
多態でやれと上司から言われてるんですが、どんなメリットがあって、どんな風に実装するか教えてください。」

って最初っから言えよ。
0461デフォルトの名無しさん2012/04/18(水) 23:57:24.90
グローバルインスタンスホルダーがある限り
なにをどう組んでもどうにでもなるだろ
0462デフォルトの名無しさん2012/04/18(水) 23:57:50.00
リストごとに専用のインターフェースが必要になります。
04633962012/04/18(水) 23:58:25.05
>>400
亀レスで申し訳無いが、流れが速くてな。
intとfloatは多態は多態でもオーバーロードの方で、基底クラスは持ってないだろ?
ファイルとディレクトリーでダックタイピングしたけりゃそりゃ結構だが、
基底クラスはいらんだろうと。
0464デフォルトの名無しさん2012/04/18(水) 23:58:28.18
void*でいく
04653962012/04/19(木) 00:13:37.38
あ、あと、ホーミングの話はもう止めた方が良いと思う。
その話とも絡むんだが、さっきの続きで、
(int)+(int)や(float)+(float)の「+」は多態するんだが、
これってマルチメソッドだろ?しかも基底クラス無しでな。
一方でC++やJavaの仮想関数はシングルディスパッチだろ?
しかも基底クラスが必要だ。その辺どう思ってんだってはなしな。
で、ホーミングの話だが、要するに、
foreach(ホーミング弾リスト)
{ ホーミング処理(ホーミング弾, プレイヤー機) }
↑こう書くのが本来の姿で、他は奇形だって話だろ。
古来よりのplus(2, 3)のスタイル。
そんで、このとき動的な多態が出来なくなるのは言語側の問題でしかない訳で。
0466デフォルトの名無しさん2012/04/19(木) 02:31:33.49
まだまだミサイルの例えは続くよw
0467デフォルトの名無しさん2012/04/19(木) 07:11:41.34
ミサイルとホーミングミサイルの違いも吸収できなくて何が多態か!
0468デフォルトの名無しさん2012/04/19(木) 07:14:52.42
foreach(ホーミング弾リスト)
{ ホーミング処理(ホーミング弾, プレイヤー機) }
デコイ追えないじゃん。
0469デフォルトの名無しさん2012/04/19(木) 07:22:29.66
デコイなんかに騙されてるミサイルは糞
0470デフォルトの名無しさん2012/04/19(木) 07:36:33.42
動的な多態したけりゃ、オーバーライドすれば良いっしょ、んでダブルディスパッチにすればいい・・強引にwww

0471デフォルトの名無しさん2012/04/19(木) 07:56:28.09
Javaでダブルディスパッチなんか使おうとすると受け入れるメソッド作らなければいけないじゃん・・多態じゃないよね?めんどくせーww
0472デフォルトの名無しさん2012/04/19(木) 08:04:07.48
Visitorパターンだ受けいれてやれ
0473デフォルトの名無しさん2012/04/19(木) 08:32:36.33
ダブルディスパッチなんて
継承したオブジェクト(静的)な物を引数で渡す(動的)に扱いたい場合にしか使い道思いつかないんだが
これのどこに多態が入るんだ?
0474デフォルトの名無しさん2012/04/19(木) 08:39:32.81
>>468
こうすればいいだろ。

foreach(ホーミング弾リスト)
{ ホーミング処理(ホーミング弾, ターゲット) }

ここでも多態が生きてくるな。
ターゲットは、プレイヤーかもしれないし、デコイかもしれない。
0475デフォルトの名無しさん2012/04/19(木) 08:50:21.03
Visitorパターンなんか、手直ししなければならなくなった時、逃げ出す準備をし始める

物中心で考えるようになったから、出来た思考の負の遺産の最たる物だと思ってる
複雑に絡まったら抜け出せない
0476デフォルトの名無しさん2012/04/19(木) 08:56:53.87
>>474
だっせ
ホーミング処理の中にプレイヤーとデコイのコード入れることになんじゃん
カプセル化を欠片も理解してないな

デコイやプレイヤーがないとコンパイルも通らないホーミングミサイル作ってなにが楽しいのか?
0477デフォルトの名無しさん2012/04/19(木) 08:58:38.38
もの作りながら考えろ。ぐだぐだ言い訳ばかり。
0478デフォルトの名無しさん2012/04/19(木) 09:22:30.56
オーバーロードってコンパイル言語(java)中心の俺には、引数を自在に扱えるようになって便利なんだけど、静的にしか表現出来ないから不便、他言語だと動的に扱えますか?
0479デフォルトの名無しさん2012/04/19(木) 09:31:43.84
そこまで解ってんだったら調べろよww
Perlやphpみたいな曖昧な型言語だとオーバーロード自体出来ないよ
0480デフォルトの名無しさん2012/04/19(木) 09:35:38.80
引数の数が同じで型が異なるオーバーロードされたメソッドの定義は混乱の元
0481デフォルトの名無しさん2012/04/19(木) 09:56:24.70
たくさんメソッド名考えなくて済むから素敵
0482デフォルトの名無しさん2012/04/19(木) 10:02:49.63
多態とは

同じ名前のメソッドを呼び出しで、異なる振る舞いをすること。

インスタンスの動的な型に応じて異なる振る舞いをする、動的多態性
に対して、メソッドのオーバーロードも多態性の一種、静的多態性

だと思うんだが・・
0483デフォルトの名無しさん2012/04/19(木) 10:47:24.39
カオスだな、誰かまとめてよ
0484デフォルトの名無しさん2012/04/19(木) 11:14:15.95
みんなちゃんとまとまてるよ
0485デフォルトの名無しさん2012/04/19(木) 11:43:38.01
>>397
ださいっつうか面白みも考える余地もないな
正に機械語
0486デフォルトの名無しさん2012/04/19(木) 12:33:39.76
機械に近くなるか、人間に近くなるか
0487デフォルトの名無しさん2012/04/19(木) 13:04:25.17
ダサいと思うか、合理的と思うか、人それぞれ。
得てして シンプル イズ ベスト だと思う。
0488デフォルトの名無しさん2012/04/19(木) 14:12:02.10
インタフェースを実装する時点でメソッドをオーバーライドしてる。つまり多態だろ

多態が使えないと言った奴は何の言語で書いてんのか気になるんだけど
0489デフォルトの名無しさん2012/04/19(木) 14:12:22.62
単にOO厨って言っても流派がいくつかあるから
こういった場での話し合いは混乱するんだよな。ここIDもないし。
多態といっても、
タイミング: リンク時/実行時
レシーバ: 多重/単一
型制限: ダックタイピング/インターフェース
と、千差万別。組み合わせの数はとても多いし、加えてテンプレートまで絡んでくる。
だから、OO厨の間でも、
インターフェースが悪だと言う者、逆にそういった型制限こそ必要だと言う者、
単一ディスパッチが古いと言う者、逆に節度だと言う者、等々色々な立場を持ってたりする。
そんで、インターフェースの話が単一ディスパッチに突然飛び火したりして収集が付かなく・・・。
ただ、昔みたいに1+2を「1」に"+2"ってメッセージを云々って解釈は、もう合わなくなってると思う。
C++にすら、テンプレートで良く使うように、オーバーロードによる多重ディスパッチの静的多態が有ったりするので、
多態のことは、引数に基づいて関数の呼び出し先が切り替わる、ぐらいに考えるしかないね。
0490デフォルトの名無しさん2012/04/19(木) 15:11:55.46
あ、一応書いておくけど、
俺は、OOPLと言うのなら、多重ディスパッチは言語機能として持ってるべきだが、
言語使用者は、それが有っても使うな、gotoやグローバル変数と同じようにな、って考え。
使わない機能が有ってどうするんだ?って感じだが、
既にC++やJavaに静的多重ディスパッチが実装されてるし、しかも普及しているから、
いまさらOOの定義を単一ディスパッチに制限する意味も無いわけで。でも使うな、と。

ただ、「犬と猫は動物から派生して〜」と、分かった気にさせて洗脳しにかかるよりは、
「引数に基づいて関数の呼び出し先が切り替わる」の方が分かりやすいし、ウソが無くて良心的だろ。

あれだな、vtableや継承や単一ディスパッチは、
多態の現実的な手抜き実装の手段でしかなかったのに、
それをコンセプトとして前面に押し出したのが失敗だったな。
犬や猫が動物クラスから派生するのは、コンパイラ実装上の都合だからな。
OO設計なんて、コンパイラの都合に合わせて設計しているだけなのに、
何か素晴らしい物のように言われてるのがなんとも。洗脳おそろし。
0491デフォルトの名無しさん2012/04/19(木) 15:49:29.75
昨日、出たうんこみたいに長いレスだったな
で?なに?
0492デフォルトの名無しさん2012/04/19(木) 15:52:24.93
つまりポインタは使うなってことでしょ
0493デフォルトの名無しさん2012/04/19(木) 16:20:14.49
静的多重ディスパッチってなんだよ・・
0494デフォルトの名無しさん2012/04/19(木) 16:47:52.51
オーバーロードのことだろうけど、ちゃんとオーバーロードと言ってほしい
もしくはアドホック多相
0495デフォルトの名無しさん2012/04/19(木) 17:01:39.74
>>C++にすら、テンプレートで良く使うように、オーバーロードによる多重ディスパッチの静的多態

頭の弱い俺には理解出来ない

>>多態の結論が引数に基づいて関数の呼び出し先が切り替わる
引数?インスタンスに基づいて変わるって言わない?
上の言い方だとオーバーロードが思い浮かぶんだけど
0496デフォルトの名無しさん2012/04/19(木) 20:10:44.96
>>417
ホーミングミサイル 発射 標的:>>417
0497デフォルトの名無しさん2012/04/19(木) 20:24:52.14
失敗公表、正恩氏が指示=演説原稿は自ら執筆−訪朝の米教授
http://www.jiji.com/jc/c?g=int_30&k=2012041900884
 【ソウル時事】15日の故金日成主席生誕100周年に合わせ、約1週間にわたり北朝鮮の
平壌を訪れた米ジョージア大の朴漢植教授は19日、ソウルで取材に応じ、北朝鮮当局者の話
として、金正恩労働党第1書記が、ミサイル発射失敗を隠すべきだとの周囲の助言を振り切り
「そのまま発表しろ」と指示したことを明らかにした。また、正恩氏は閲兵式での演説原稿を
自ら執筆したという。
 ミサイル発射失敗後、側近らが「人民の士気もあるので、隠しましょう」と述べたのに対し、
正恩氏は、外国記者らを招待したのは透明性を担保するためであり、最後までその方向で行か
なければならないとの趣旨を強調し、発表するよう指示した。
 北朝鮮側関係者はミサイルの失敗について「科学というものは、失敗なしに成功はない」と
正当化しつつも、「首領様(金主席)の生誕100周年は今しかない」と無念な様子だった
という。(2012/04/19-19:14)
0498デフォルトの名無しさん2012/04/19(木) 22:21:20.36
>>476
> ホーミング処理の中にプレイヤーとデコイのコード入れることになんじゃん
> カプセル化を欠片も理解してないな
入れることになると思っているお前の頭がダサい。
それしか思いつかんのか馬鹿は?

> デコイやプレイヤーがないとコンパイルも通らないホーミングミサイル作ってなにが楽しいのか?
基本的な考え方の話でインターフェースに対するプログラミングって知ってる?
ホーミングミサイルを作るのにデコイもプレイヤもいらない。
ホーミングミサイルを作るのに必要なのは「ターゲットインターフェース」だけ。

ターゲットインターフェースからは現在位置と敵味方情報を取得できる。
プレイヤーとデコイは当然その他でもターゲットインターフェースさえ持っていれば
ホーミングミサイルのターゲットにすることができる

もちろんインターフェースを作らなくても、プレイヤーとデコイの両方の祖先クラスを使う方法もあるけど。
0499デフォルトの名無しさん2012/04/19(木) 22:29:47.67
>>482
> インスタンスの動的な型に応じて異なる振る舞いをする、動的多態性
> に対して、メソッドのオーバーロードも多態性の一種、静的多態性

違うよ。

話をわかりやすくするために、
「呼び出し側」と「呼び出され側」に分けよう

「呼び出し側」のコードを変えてないのに「呼び出され側」(の実体)よって動作が変わるのが多態
「呼び出し側」のコード(引数)を変えることで「呼び出され側」の動作が変わるのがオーバーロード

多態とオーバーロードの両方を組み合わせることも出来るけど
両方組み合わせれば、両方組み合わせた結果になるだけ。
0500デフォルトの名無しさん2012/04/19(木) 22:52:15.97
>>499
それはお前の勝手な脳内定義だろ。

>「呼び出し側」のコードを変えてないのに「呼び出され側」(の実体)よって動作が変わるのが多態

仮に、その定義だったとしても、オーバーロードでそれは出来る。
テンプレートを使えばな。
0501デフォルトの名無しさん2012/04/19(木) 23:26:06.59
幼年期の終わり
0502デフォルトの名無しさん2012/04/19(木) 23:33:32.76
多態の定義ってなんかソースとかあるのかな。
0503デフォルトの名無しさん2012/04/19(木) 23:47:23.54
ソースっつーかWikiだけど。
http://en.wikipedia.org/wiki/Polymorphism_(computer_science)

英語が嫌って人向けにどうぞ
http://www.nslabs.jp/haskell-poly.rhtml

C++用語で平たく言うと、
Ad-hoc polymorphism → オーバーロード
Parametric polymorphism → テンプレート
Subtype polymorphism (or inclusion polymorphism) → 継承
0504デフォルトの名無しさん2012/04/19(木) 23:53:19.68
>>503
へえ、多態って結構幅広いのな。
0505デフォルトの名無しさん2012/04/19(木) 23:57:35.34
なんでこんなに人によって言い回しが違うのか・・
全部英語の方が誤解ないのにな
0506デフォルトの名無しさん2012/04/20(金) 01:07:37.21
え?
0507デフォルトの名無しさん2012/04/20(金) 01:43:09.96
>>500
あぁ、それはテンプレートを使うことで
オーバーロードを多態として使うテクニックってだけだ。
0508デフォルトの名無しさん2012/04/20(金) 01:45:32.17
>>503
それはただのHaskell用語だ
0509デフォルトの名無しさん2012/04/20(金) 01:48:33.84
多重ディスパッチを見ていたらアタマが痛くなった
0510デフォルトの名無しさん2012/04/20(金) 02:06:25.73
多重ディスパッチはコードはごちゃごちゃしてるけど、
結局何がしたいのか? に焦点をあてれば簡単。

実行時型情報があればスマートの実装できる問題を
実行時型情報を使わないで書くやり方だから。
0511デフォルトの名無しさん2012/04/20(金) 02:43:28.37
>>508
http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
↑URLを見る限りそうは見えませんが。
0512デフォルトの名無しさん2012/04/20(金) 03:07:45.23
>>511
Ruud Kootとかいうやつが
それまでの内容を全部自分の都合のいいように書き換えてる。

これだからwikipediaはあてにならないのだ。
0513デフォルトの名無しさん2012/04/20(金) 06:42:08.52
そろそろ頭良い人がまとめてくれるのかな
0514デフォルトの名無しさん2012/04/20(金) 06:46:14.58
>>512
少なくともHaskell用語じゃない証拠として
論文を出してみる
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
0515デフォルトの名無しさん2012/04/20(金) 07:19:30.99
次は論文もあてにならないと言い出す予感
正しいのは俺の脳内定義だー
0516デフォルトの名無しさん2012/04/20(金) 09:44:31.15
それぞれの派生クラスで処理メソッドを変えてこそのポリモーフィズムだと思っていたんだが、幅広いな

実際殆どの基本書ではポリモというとこれしか書いてないよな
0517デフォルトの名無しさん2012/04/20(金) 09:47:51.65
http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming
wikipediaだけどこっちでは
>Subtype polymorphism, almost universally called polymorphism in the context of object-oriented programming
ってあるね
オブジェクト指向プログラミングでの狭義のpolymorphismはSubtype polymorphism限定ってことかな
0518デフォルトの名無しさん2012/04/20(金) 10:04:26.66
広義のpolymorphismで話してる奴と
OOPLの狭義のpolymorphismで話してる奴が言い争ってた感じか
話が噛み合わんわけだな
05195182012/04/20(金) 10:08:57.72
OOPだった
0520デフォルトの名無しさん2012/04/20(金) 11:07:06.00
でもそうすると、プロトタイプベースやダックタイピングはどうするんだ?
Javascriptはどういう位置づけになるんだ?
0521デフォルトの名無しさん2012/04/20(金) 11:24:04.58
馬鹿には無理
0522デフォルトの名無しさん2012/04/20(金) 12:20:39.74
概念はなんとなくわかったど
実際に便利に使おうとすると中々思いつかんな
納得する使い道ある?

日常生活においてデータさえありゃ満足で、処理する価値少ないなとつくづく思う
0523デフォルトの名無しさん2012/04/20(金) 12:42:06.63
>>498
そしたらもう多態はあきらめるほかないよね?
0524デフォルトの名無しさん2012/04/20(金) 12:45:36.25
どんな32bit整数もintで扱えるっていうのはポリモだよね。
特定の数値を表現するのに3bitあれば十分という場合でも32bit確保してるんだから。
実は変数も構造体もポリモだった。
0525デフォルトの名無しさん2012/04/20(金) 12:51:05.84
どんな32bit整数値を計算するときも、
数値の大きさによらずCPUのロジックは一定だから、
多態ではない。
0526デフォルトの名無しさん2012/04/20(金) 13:10:03.50
> 数値の大きさによらずCPUのロジックは一定
それはどんな内容に対しても呼び出すメソッドは同じと同義。
0527デフォルトの名無しさん2012/04/20(金) 13:28:48.96
その広義でポリモと言うとすげー違和感だな
ポリモが一人歩きしてる感じ
厨2のように
0528デフォルトの名無しさん2012/04/20(金) 13:36:26.18
あたりまえだが、
処理のロジックが同一なことと、呼び出しが同一な事は、同義ではない。
0529デフォルトの名無しさん2012/04/20(金) 14:09:17.09
>>524
全然違うよ。
符号なしで考えると7+1の結果は
32bits整数型: 8
3bits整数型: 0
0530デフォルトの名無しさん2012/04/20(金) 14:22:38.10
ふむふむなるほど、キャリアは等しくとも別の代数構造になるのですな
0531デフォルトの名無しさん2012/04/20(金) 14:50:58.13
>>529
>>524の説にも全く同意できないが、それ、3bitで十分じゃない時の話じゃん
0532デフォルトの名無しさん2012/04/20(金) 15:01:22.08
>>520
構造的部分型(同じシグネチャのメソッド持ってたら多態可能)は
subtype polymorphism の一種

subtype の定義が nominal か structural かの違いだけ
(だけっていうには大きい違いだが...)
0533デフォルトの名無しさん2012/04/20(金) 15:13:20.08
変数がROMだのバスだのポートだのに直結してる場合もあるわけで、
変数=RAMとは限らない。
変数もまた抽象化されたインターフェースの一つ。
0534デフォルトの名無しさん2012/04/20(金) 15:39:09.63
何が言いたい
0535デフォルトの名無しさん2012/04/20(金) 15:48:03.97
馬鹿には無理
0536デフォルトの名無しさん2012/04/20(金) 15:49:10.96
変数が多態でもいいけど、抽象化されたインターフェースってのは言い過ぎなのよ
コンピュータサイエンスでの多態は、仮に今扱うのが
store( a, b );
という関数の呼び出し文だとしたら、
上記の呼び出し文全体で、その振る舞いが多態、ってこと。
変数や引数が共通のインターフェースを提供している、というふうに、
オブジェクト中心に考え直すかどうかは、多態とは関係ない。
0537デフォルトの名無しさん2012/04/20(金) 16:05:56.67
本質的に異なるものを同じと言い張るのは良くないぬ
0538デフォルトの名無しさん2012/04/20(金) 16:06:32.01
のようなもの
0539デフォルトの名無しさん2012/04/20(金) 16:12:00.84
なんとゆるふわな科学
0540デフォルトの名無しさん2012/04/20(金) 16:22:18.90
ゆるふわな定義なんだから仕方ない
0541デフォルトの名無しさん2012/04/20(金) 16:47:30.10
まさかオブジェクト指向が癒し系だったとかありえんw
0542デフォルトの名無しさん2012/04/20(金) 17:05:12.47
いやいや多態の定義がゆるふわってだけで、
オブジェクト指向の定義は・・・・もっとゆるふわだぜ?
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91
「〜考え方である。」
だってさ。これ、科学なんですかね。
0543デフォルトの名無しさん2012/04/20(金) 17:22:42.72
>>542
情報隠蔽さえあればオブジェクト指向ってことだな
0544デフォルトの名無しさん2012/04/20(金) 17:39:05.88
パンツはオブジェクト指向
0545デフォルトの名無しさん2012/04/20(金) 17:41:18.73
オブジェクトそのものじゃね
0546デフォルトの名無しさん2012/04/20(金) 18:16:35.22
民主党はオブジェクト
0547デフォルトの名無しさん2012/04/20(金) 18:25:25.60
オブイェクト
0548デフォルトの名無しさん2012/04/20(金) 19:32:46.16
クラスでカプセル化さえできていれば、そのインスタンスがグローバル変数であったとしても、なんら問題ない。
意味のあるまとまりでカプセル化されていることがオブジェクト指向のキモだと思う。
0549デフォルトの名無しさん2012/04/20(金) 20:03:57.95
隠蔽はオブジェクト指向以前から確立されてたし。
OOならではってのが欲しいね。
0550デフォルトの名無しさん2012/04/20(金) 20:56:08.00
OOはweb2.0レベルのバズワード
0551デフォルトの名無しさん2012/04/20(金) 21:01:42.16
>>546
いつガベージコレクトされますか?
0552デフォルトの名無しさん2012/04/20(金) 22:06:51.38
>>551
参照されなくならない限り残ります
0553デフォルトの名無しさん2012/04/20(金) 23:33:46.78
世界中のえらいひとたちが考え出して使ってるもんなんだから
凡人が理解できなくてもなんら恥じることはない
むしろ理解していると思っていることを恥じるべき
0554デフォルトの名無しさん2012/04/20(金) 23:52:57.50
>>523
お前(=馬鹿)は諦めて下さい。

この業界を諦めて下さい。
0555デフォルトの名無しさん2012/04/21(土) 01:01:46.59
Simulaがオブジェクト指向の定義でいいよ
0556デフォルトの名無しさん2012/04/21(土) 07:29:38.74
オブジェクト指向で傑作なアイデアは継承だね
こんな密結合を生む馬鹿な機能は他では見ない

そして、継承の他にオブジェクト指向固有の特徴は無い
0557デフォルトの名無しさん2012/04/21(土) 09:21:09.07
継承のメリットのほとんどは
delegateとinterfaceで事切れる
0558デフォルトの名無しさん2012/04/21(土) 09:38:35.45
委譲と言ったりデリゲートと言ったり、しまいにはコンポジションとか言ったりする

日本語最悪ww
0559デフォルトの名無しさん2012/04/21(土) 10:45:43.56
じゃあお前は日本語しゃべるな
0560デフォルトの名無しさん2012/04/21(土) 11:17:48.17
事切れるのか
0561デフォルトの名無しさん2012/04/21(土) 11:20:18.92
OOPは死んだ
0562デフォルトの名無しさん2012/04/21(土) 12:08:57.03
パソコンが欧米で作られたのがいたいな
日本初なら全部日本語で頑張っただろうにww
0563デフォルトの名無しさん2012/04/21(土) 12:16:32.99
日本の文字単位がなぁ・・
この文字で頑張ろうとすると死にそう
0564デフォルトの名無しさん2012/04/21(土) 12:35:37.28
ホーミングレーザーの話が良かったな。
ターゲットインターフェースを持っていれば
相手がなんでも同じものとして扱える。
多態の便利さが実感できた。
0565デフォルトの名無しさん2012/04/21(土) 12:51:16.21
あれはダメな例でしょ。
だって、本来ホーミングミサイルクラスが
ターゲットインターフェースに依存する必要はないもの。
ホーミング処理( ホーミング弾, x, y );
もしくはどうしてもOOPスタイルが好きな人は、
ホーミング弾 . ホーミング処理( x, y )
これで良いだろ。
0566デフォルトの名無しさん2012/04/21(土) 12:53:13.10
「ターゲットインターフェースには現在地があればいいな」
↓
「ターゲットには敵味方識別がないとダメだろ常識的に考えて」
↓
「移動予測しないとミサイルなんてあたらねぇよ速度加速度も入れろ」
↓
インターフェースの仕様変更のたびに全部書き換えることに
↓
「最初からターゲットクラスの派生にしとけばよかったんや!」
0567デフォルトの名無しさん2012/04/21(土) 13:10:16.89
そんでこれ重要だと思うんだけど、
あるホーミングミサイルが、
今現在どのターゲットを狙っているか、
の紐付け情報の置き場所は、
ホーミングミサイル自身の内部ではなくて、
ゲームクラス、もしくは幾分細分化して、
ホーミング管理クラスだ。
0568デフォルトの名無しさん2012/04/21(土) 13:12:34.78
>>565
> だって、本来ホーミングミサイルクラスが
> ターゲットインターフェースに依存する必要はないもの。

インターフェースに依存しないで、どうやって他のオブジェクトを操作するんだ?

え、言ってみろw

クラスに依存しなければ良い。
以上。
0569デフォルトの名無しさん2012/04/21(土) 13:15:04.06
>>566

↓これよんだ? お前ごときが考えることはすでに出てる。

>>498
> もちろんインターフェースを作らなくても、プレイヤーとデコイの両方の祖先クラスを使う方法もあるけど。
0570デフォルトの名無しさん2012/04/21(土) 13:17:51.99
>>566
そういう時は、

ターゲットインターフェースを実装した
ターゲットクラスの派生にするんだよ。
0571デフォルトの名無しさん2012/04/21(土) 13:20:16.98
オブジェクト思考すぎるな
0572デフォルトの名無しさん2012/04/21(土) 13:23:38.60
>>567
> 今現在どのターゲットを狙っているか、
> の紐付け情報の置き場所は、
> ホーミングミサイル自身の内部ではなくて、
> ゲームクラス、もしくは幾分細分化して、
> ホーミング管理クラスだ。

つまり、ホーミング管理クラスが、ホーミングミサイルに対して
どれがターゲットか教えるってことだろ?

> Missile m = new NormalMissaile();
> Missile m = new HormingMissaile(target);

つまりホーミングミサイルをnewしているコード。
それがホーミング管理クラスだよ。

お前の言うとおり、最初から、ホーミングミサイル自身には紐付け情報はない。
ホーミングミサイルはホーミング管理クラスが紐付けた相手を
教えてもらってるに過ぎない。
0573デフォルトの名無しさん2012/04/21(土) 13:23:52.22
class Target{
 public Point Position {get;set;}
}

interface IGameObject{
 Target Target {get;set;}
}

class 敵1: IGameObject{
 public void チャフ散布(){
  GameManager.GameObjectCollection.Add(new チャフ(this.Target));
  this.Target=this.Target.Clone();
 }
}

class チャフ:IGameObject{
 public チャフ(Target target){
  this.Target=target;
 }
}

よし
0574デフォルトの名無しさん2012/04/21(土) 13:28:13.40
>>568
>インターフェースに依存しないで、どうやって他のオブジェクトを操作するんだ?
ホーミングミサイルが直接管理下にない他のオブジェクトを操作する必要ないんだよ。
つーか、しない方が良い。
0575デフォルトの名無しさん2012/04/21(土) 13:29:36.10
>>574
他のオブジェクトを操作しなくても、
他のオブジェクトの情報を取得する必要はあるだろ。
0576デフォルトの名無しさん2012/04/21(土) 13:30:40.38
しないとターゲット追えないでしょww

水かけ論になってるよ、出発地点のどこかがおかしいww
0577デフォルトの名無しさん2012/04/21(土) 13:31:13.62
>>572
ホーミングミサイルが、ターゲットをホールドするなと言ってるんだ。
紐付け情報の置き場所をホーミングミサイルの中にするな、と
>>567でちゃんとかいてるだろ。
0578デフォルトの名無しさん2012/04/21(土) 13:32:18.10
>>575
情報は引数でもらえば良い。
ホーミング処理( ホーミングミサイル, x, y );
0579デフォルトの名無しさん2012/04/21(土) 13:33:57.64
ホーミング管理クラスがある。
そのホーミング管理クラスが
ホーミングミサイルにいろいろ指示を出す。

さて、ホーミングミサイルといってもいろんな型番がある。
それらすべてに対してホーミング管理クラスが指令を出す時、
いちいちA-001なら○○B-001なら△△、C-001なら□□
なんてif文で切り分けるとかアホすぎる。

そこで出てくるのがホーミングミサイルインターフェース。
すべてのホーミングミサイルは同じインターフェースを採用しているので
ホーミング管理クラスは同じ処理で、すべてのホーミングミサイルを扱うことが出来る。

これも多態の便利さ。

ホーミングミサイルの話から、ホーミング管理クラスの話にすり替えようとしても
無駄だぜ、こっちはこっちで多態の素晴らしさを語ることが可能だからな。
0580デフォルトの名無しさん2012/04/21(土) 13:35:56.01
>>579
その使い型は否定してないんだけど。
ただ、例として出てたホーミングミサイルの実装案がお粗末だったから、
例として不適切だと指摘したまで。
0581デフォルトの名無しさん2012/04/21(土) 13:37:53.39
>>577
だから、ターゲットをホールドするのは
管理クラスの仕事だとしても、
そのホールドするターゲットに向かっていく処理は
ホーミングミサイルの仕事でしょうがw

>>578
それ、引数が変わっただけ。

ホーミング処理( ホーミングミサイル, x, y );
ホーミング処理( ホーミングミサイル, ターゲット);

※ターゲットからはxとyの値を取得できる。

所でターゲットからxとyの他に敵情報を取得した時に
変更する点が多いという話じゃなかったか?

> ホーミング処理( ホーミングミサイル, x, y );
↑変更大変そうだなw
0582デフォルトの名無しさん2012/04/21(土) 13:39:07.98
>>580
ここはホーミングミサイルを作ろうという話をしてるんじゃなくて
ホーミングミサイルを例にしてオブジェクト指向の話をしてるんだから
的外れだ。

意味が通じてるのなら何の問題もない。
0583デフォルトの名無しさん2012/04/21(土) 13:40:58.63
ホーミング処理( ホーミングミサイル, x, y );

x、yってのはもともとターゲットなんだからこう書かないといけないよ。

x = ターゲット.x;
y = ターゲット.y
ホーミング処理( ホーミングミサイル, x, y );

0584デフォルトの名無しさん2012/04/21(土) 13:42:32.54
>>581
>それ、引数が変わっただけ。
引数が変わったことで結合度が下がったんだ。
もはやホーミングミサイルがターゲットインターフェースを知る必要はない。

>所でターゲットからxとyの他に敵情報を取得した時に
>変更する点が多いという話じゃなかったか?

その話をしていたのは俺ではない。
俺は無駄な依存関係が嫌いなだけ。
0585デフォルトの名無しさん2012/04/21(土) 13:46:01.32
>>583
ターゲットインターフェースをx,yに展開するのは、
ゲームクラスやホーミングクラスだから、
ホーミングミサイルクラスはターゲットインターフェースを知る必要がない。
ホーミングミサイルの結合度が下がる。
0586デフォルトの名無しさん2012/04/21(土) 13:48:38.97
>>580
落ち着いて聞いてね。
ホーミングミサイルの実装には二通りあるってだけ

管制塔(ホーミングミサイル管理クラス)が
すべてのホーミングミサイルを遠隔管理するか、

ホーミングミサイル自身が敵を発見し、
自律的にホーミング処理を行うか。

前者だと、追跡アルゴリズムは、管制塔が全て管理するが
後者だと、追跡アルゴリズムは、ミサイルごとに変えることが可能になる。

元々話は、ただのミサイルとホーミングミサイルをどう実装するかの話。
ターゲットはnewする時点で与えるって話なのだから敵発見アルゴリズムはどちらも一緒。

違うのは追跡アルゴリズム。
ミサイルは追跡アルゴリズムは、最初に与えられたターゲットの位置に一直線に進む
ホーミングミサイルは、移動した後の位置に進む。

こういう話から、ターゲットインターフェースの話になったんだよ。

ホーミングミサイルはどう有るべきかなんて的外れもいいとこだ。
0587デフォルトの名無しさん2012/04/21(土) 13:49:54.11
曲線弾道と自動追尾がごっちゃになっとるわ

固定座標目標で発射したら追尾できないだろ。常識的に考えて。
敵弾はそれでいいけど自弾は最後まで追尾しないと意味ないぞ
0588デフォルトの名無しさん2012/04/21(土) 13:51:00.38
出てきたクラス、インタフェースだけでも列挙した方が良いだろ、わけわからんww
0589デフォルトの名無しさん2012/04/21(土) 13:57:35.35
まとめるとこんな感じ。

ミサイル管理クラス・・・どんな機能のミサイルでも全て管理しているクラス
ホーミングミサイル管理クラス・・・ホーミングミサイル専用の管理クラス

ミサイル・・・まっすぐ飛んでいくミサイル
ホーミングミサイル・・・追尾するミサイル

ターゲットインターフェース・・・ターゲットになりうるものが全て持ってるインターフェース

敵ターゲットクラス・・・敵ターゲットのベースクラス。ターゲットインターフェースを実装
敵Aクラス・・・いろんな敵の一つ。敵ターゲットクラスを継承
敵Bクラス・・・〃

自機ターゲットクラス・・・自機のベースクラス。ターゲットインターフェースを実装
自機Aクラス・・・いろんな機体の一つ。自機ターゲットクラスを継承
0590デフォルトの名無しさん2012/04/21(土) 14:01:29.57
簡単なユースケースもお願い
0591デフォルトの名無しさん2012/04/21(土) 14:01:29.93
>>585
えと、関数の引数もインターフェースの一つだから。
プリミティブ型もオブジェクトな考え方を知っていれば、

> ホーミング処理( ホーミングミサイル, x, y );
コレは

  ホーミング処理( ホーミングミサイル, X座標オブジェクト, Y座標オブジェクト );

に見えるよね?

リファクタリングの一つとして、関連する値をまとめるというものがある。

  ホーミング処理( ホーミングミサイル, 座標オブジェクト);

やってることはこれと一緒。

お前の言う所の、座標オブジェクトに結合している状態になってる。
そもそもお前の”結合度”の解釈が間違ってるんだがね。

0592デフォルトの名無しさん2012/04/21(土) 14:02:04.87
全ての始まり、ミサイルインタフェースがなくなってるww
0593デフォルトの名無しさん2012/04/21(土) 14:04:23.99
ミサイル管理クラスがミサイルインタフェースだろ
0594デフォルトの名無しさん2012/04/21(土) 14:05:50.65
>>585は

Javaのimport=結合と単純に考えているだけで
プリミティブ型ならimportしなければ結合していないと
そういう解釈をしてる。

それは違う。

本来の結合というのは実装を使うということ。
つまりクラスを直接使うこと。処理がクラスに結合してしまって
別のクラスに置き換えることが来ない。この話。

依存してるのがインターフェースであれば、
そのインターフェースを実装したクラスであれば
何にでも置き換えだから、これは結合していることにならない。
0595デフォルトの名無しさん2012/04/21(土) 14:06:25.81
>>592
このスレにミサイルインタフェースなんて
言葉は出てきてないよw
0596デフォルトの名無しさん2012/04/21(土) 14:06:37.77
ミサイルとホーミングミサイルの共通点なんてミサイルって名前ぐらいなもんだな
大抵のゲームであったときの爆発も同じものってことないしな
ミサイルとわざわざ多態でむすんでおくメリットはほぼないな

と思うんだけど
ここまで頑張って多態を使うメリットあるかね?
0597デフォルトの名無しさん2012/04/21(土) 14:08:55.52
>>595
お前のレスの中に答えが出てる。

ミサイルとホーミングミサイルに共通で存在する
「爆発」という処理をミサイルとホーミングミサイルで
違う爆発の仕方をする。

これこそ多態。呼び出される爆発メソッドは同じだが
その表現を変えたいってところで使える多態のメリットだ。
0598デフォルトの名無しさん2012/04/21(土) 14:10:30.72
もう多態しすぎだろww
自重しなさいwww
0599デフォルトの名無しさん2012/04/21(土) 14:11:20.97
>>597
まーたテキトーなレスして
爆発もどう爆発すっかわかんねーぞ
その場で爆発するだけならなげっぱでいいけど
爆発するターゲットが必要だったりするとまたミサイルとホーミングミサイルの関係といっしょだろ?
0600デフォルトの名無しさん2012/04/21(土) 14:12:04.40
アイテムで自機ショットをTypeAからTypeBに換装っていうなら
括る意味はあるでしょ
0601デフォルトの名無しさん2012/04/21(土) 14:13:29.78
昔作ったゲームで小爆発が短時間に5発以上重なったときは
キャンセルして中爆発に切り替えてほしいってのもあったな
フィルレートおっせから
0602デフォルトの名無しさん2012/04/21(土) 14:19:39.75
>>586
抜けてるね。
元々はゲーム中の全オブジェクトの更新を、gameobj->update()
一発で済まそうって人への反論として、ホーミングミサイルの話が出ている。
つまり、updateメソッドに、どうやってターゲットの座標を渡すかが焦点だ。
updateの仮引数が基底クラスで固定されているから、
追加の情報は、グローバル変数か、メンバ変数を経由して渡さなきゃならない。
生成時にパラメータとして渡してあげるのが一般的だが、
通常のミサイルのように普遍な目標値を渡すのなら値のコピーで問題ないが、
ホーミングのような動的に変化して、常に新鮮な値が必要な場合は、さて、どう渡すかって話。
OOPの人たちはすぐにターゲットインターフェースなる物を使って渡すと言うが、
それでは結合度が上がるし、元々update時に新鮮な座標が欲しいってだけなわけだから、
都度都度引数で渡してあげればよいだろう。
ホールドしないからインターフェースも必要なく、結合度も下がる。
つまり、元締めupdate一発方式は、クラス結合度も、オブジェクト参照数も上がるから、良くないね。
そういう話だったはずだが。
0603デフォルトの名無しさん2012/04/21(土) 14:35:54.20
「新鮮な位置座標」はゲームオブジェクトそのものじゃないか
すべてのオブジェクトから位置情報を引き出すためにインターフェースが必要だ
遅くてもいいならダックタイピングしてもいいけど

ゲームオブジェクトごとに「移動したら自分の位置情報を
グローバルな位置情報リストに登録しなおすこと」なんて
テストしきれねぇよ
0604デフォルトの名無しさん2012/04/21(土) 14:37:47.59
update一発方式を改めろよ雑魚
0605デフォルトの名無しさん2012/04/21(土) 14:39:02.05
>ホーミングミサイルはどう有るべきかなんて的外れもいいとこだ。

じつは元ともそういう"有り方"の話だったんだ。
元締めgameobj->update()一発方式は止めて、
オブジェクト間に跨る処理は、オブジェクト外でしましょう。
直接管理下にないオブジェクトをホールドするのは止めましょう。
処理に必要な新鮮な値は、常に引数で都度都度渡しましょう。
っていう。

もともとの彼の主張はたったこれだけだったんだけど、
彼の文章力がなかったのもあって・・・

彼まだ見てるのかな。
0606デフォルトの名無しさん2012/04/21(土) 14:41:52.36
僕はもうunityで作ることにしました
0607デフォルトの名無しさん2012/04/21(土) 14:46:34.52
もしかして

class ホーミング管理{
 public ホーミングミサイルbase ミサイル{get;set;}
 public ゲームオブジェクト 目標{get;set;}
 public void Update(){
  ミサイル.追尾(目標.座標);
 }
}
List<ホーミング管理> ホーミングミサイルリスト;

みたいな管理しろと?
意味ねぇ
ミサイル種別ごとに別々にUpdate呼ぶのかよ
実行時にも余計コストかかってるよ
0608デフォルトの名無しさん2012/04/21(土) 15:23:18.46
>>607
この場合においてはそのほうが楽だろうな
だいたいその記述方法でupdate一発方式の場合のやり方を記述できるか?
余計面倒くさいことになると思うぞ

グローバル変数使えば楽は楽だけど
それだと今度はカプセル化っていうかオブジェクト指向っていうか設計思想自体まったく意味ないと思うし
0609デフォルトの名無しさん2012/04/21(土) 15:42:46.44
やべぇ意味ない事になっちゃうぞ・・
0610デフォルトの名無しさん2012/04/21(土) 15:46:51.70
物体管理オブジェクトが画面上のバルカン弾もミサイルも自機も敵機も保持する
各物体のインスタンス化の際は必ず物体管理オブジェクトへの参照を渡す
ミサイルの推進メソッド内では、そのオーナーである物体管理クラスのインスタンスに対し
「敵陣営機体の位置情報リストをくれ」と尋ねる
ミサイルはその位置情報を元に、最適なターゲットを選定する

これじゃダメなの?
0611デフォルトの名無しさん2012/04/21(土) 15:54:41.51
オブジェクト思考の鉄板、「覆う」が機能し始めたぞ
0612デフォルトの名無しさん2012/04/21(土) 16:13:14.11
おおぅ
0613デフォルトの名無しさん2012/04/21(土) 17:02:52.74
>>610
そのお便利クラスがないとミサイルのクラスはコンパイルもできなくなるんじゃないの?
どうせそんなんなるんだったら素直にグローバル変数でも使ったほうがいいと思うけど?

こうなってしまうから意味がない
間にそんな潤滑油入れたところでなんの意味もない「ヌメェ〜ヌチャ〜」ってするだけ
0614デフォルトの名無しさん2012/04/21(土) 17:06:21.39
オブジェクト管理 「お問い合わせのシリアル番号に対応するオブジェクトは
 爆散もしくはゲーム画面外へ消失しました」

って返すのかね
自分で直接オブジェクトを見て爆散判定するよりはスマートだね
0615デフォルトの名無しさん2012/04/21(土) 19:06:48.98
>>614
シリアル番号なんて使わないぞ???
0616デフォルトの名無しさん2012/04/21(土) 19:08:11.10
>>613
ネームスペースを細かく作れるのも多くのOOPLの強みだと思うよ
0617デフォルトの名無しさん2012/04/21(土) 19:13:38.81
ここらでプロの実力を魅せて欲しいな
0618デフォルトの名無しさん2012/04/21(土) 19:28:31.83
>>617
プロは説明不可能なことしないの
似非プロはなんでもかんでも手を出すけど

ちゃんと工数=お金に変えられないことははじかないとね
0619デフォルトの名無しさん2012/04/21(土) 19:41:47.11
プロの仕事の姿勢がみたいんじゃなくて実力がみたいんですがw
0620デフォルトの名無しさん2012/04/21(土) 19:45:58.50
>>615
ガベージコレクションがないから参照使いたくないんじゃないの?
0621デフォルトの名無しさん2012/04/21(土) 19:55:04.69
>>620
…そんな前提だったの?
それでも別に生成と消滅を管理オブジェクトでやればよくね?
シリアルも参照もそこからは出ようがないと思うが…
0622デフォルトの名無しさん2012/04/21(土) 21:50:18.59
>>619
君には見えないんじゃない?
オブジェクト指向なんてお金にならないもん信仰してる限りは

こんなの仕組みだけなら馬鹿だってわかるよ
でも工数と結びつけて話すときのアドバンテージがまったくないんだよ

具体的にいうと
非オブジェクト指向で組んだときと比べてどのくらい短縮できる?
という質問に答えられない
0623デフォルトの名無しさん2012/04/21(土) 21:57:05.91
オブジェクト指向なんてなかったころにシューティングゲーム作った経験があるなら
そんなえらそうな物言いは絶対できないだろう
そもそもゲームなんて作ったことないんじゃないか

テストコード書くことを考えてもオブジェクト指向なしはありえない
0624デフォルトの名無しさん2012/04/21(土) 21:58:09.99
>>622
>>619
0625デフォルトの名無しさん2012/04/21(土) 22:01:05.73
> テストコード書くことを考えてもオブジェクト指向なしはありえない

???
0626デフォルトの名無しさん2012/04/21(土) 22:03:24.15
まとめ

オブジェクト指向便利。
コードを自然な感じで構成することができる
工数も短くなる
0627デフォルトの名無しさん2012/04/21(土) 22:03:41.05
随分くだらない話になっちゃったな
ミサイルの阿呆話の方が面白かったよ
0628デフォルトの名無しさん2012/04/21(土) 22:04:23.71
ミサイルをオブジェクト指向で作ると
あんなにもスマートに表現できるとはね。
0629デフォルトの名無しさん2012/04/21(土) 22:05:49.73
現実世界におけるミサイル が
そのまま、ミサイルクラスになるところが
素晴らしいよね。
0630デフォルトの名無しさん2012/04/21(土) 22:06:23.87
強引すぎるよなww
0631デフォルトの名無しさん2012/04/21(土) 22:08:35.56
結局、ミサイルとホーミングミサイルを多態で結びつけるメリットはほぼ無しってことでいいだろ?
ミサイル+ターゲットってだけに見えるのにな

でも現実こういうもん多いんだぜ
なんでもかんでも馬鹿みたいに適用しちゃうのはもうやめような?

そんなにうまくいかねぇんだって
だから俺等が必要な理由でもあるんだしよ
0632デフォルトの名無しさん2012/04/21(土) 22:10:04.29
> 結局、ミサイルとホーミングミサイルを多態で結びつけるメリットはほぼ無しってことでいいだろ?

あれほど、多態のメリットが出てただろ
それに反論したレスあったか?
0633デフォルトの名無しさん2012/04/21(土) 22:10:29.09
多態のメリットはすごかった
身震いするほどに。
0634デフォルトの名無しさん2012/04/21(土) 22:11:15.45
発射ってメソッドを呼ぶだけで、
どんなタイプのミサイルでもハッシュするんだぜ

すごいよ多態
0635デフォルトの名無しさん2012/04/21(土) 22:13:43.00
えー、そこで頑張るのー?
いい加減認めて次のステップへいこうぜ
0636デフォルトの名無しさん2012/04/21(土) 22:14:27.31
理解できない馬鹿は、こっちでやれよw

オブジェクト指向は無駄なもの。俺が理解出来ないからね
http://kohada.2ch.net/test/read.cgi/prog/1332351520/
0637デフォルトの名無しさん2012/04/21(土) 22:15:17.28
オブジェクト指向を批判する意味がなくなったので
次のステップもないなw
0638デフォルトの名無しさん2012/04/21(土) 22:19:29.48
>>636
えー、あくまでそういうことにしたいのー?
もうあんま役立たないってわかっただろ?

ミサイルとホーミングミサイルなんていかにもなもんでも多態は役に立たないんだよって
って頭ではわかっても認めることができない的な?

そもそもオブジェクト指向ってこれねー実はねーセミナー向け技術なんだよー
いい加減セミナー商法だったって気づけよー
0639デフォルトの名無しさん2012/04/21(土) 22:20:18.44
このおっさんがすごすぎる
ttp://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html

すげー笑えるww
0640 ◆QZaw55cn4c 2012/04/21(土) 22:24:22.71
そういや C のポインタの間違った解釈で散々に叩かれていたライターさんがいましたね。エピさん大活躍のやつ。
ポインタを間違えると職業的死亡も同然なんだがそれに比べると、OO を叩いても許されるような気が。
0641デフォルトの名無しさん2012/04/21(土) 22:32:58.45
ポインタって参照でしょって感じ?
0642デフォルトの名無しさん2012/04/21(土) 23:14:01.50
>>638
負け犬の遠吠えにしか見えないwww
0643デフォルトの名無しさん2012/04/21(土) 23:19:58.73
>>642
でも、ミサイルとホーミングミサイルの多態のメリットはあげることできなかったよな?
0644デフォルトの名無しさん2012/04/21(土) 23:23:14.18
if文地獄から抜け出せる
0645デフォルトの名無しさん2012/04/21(土) 23:27:03.05
抜け出した先にはクラス名を考える仕事が待っていた
0646デフォルトの名無しさん2012/04/21(土) 23:30:41.27
非OOでも関数名は考えるだろ
変わらんよ
0647デフォルトの名無しさん2012/04/21(土) 23:33:53.39
一人で自演してるようなコメばっか
そんなに多態性でもめるかよ
0648デフォルトの名無しさん2012/04/21(土) 23:35:41.38
>>643
わざとらしすぎだろ。

ホーミングミサイルと多態のメリットはたくさん出てる。
それをお前は否定することは出来ないはずだぞ。
0649デフォルトの名無しさん2012/04/22(日) 00:14:51.87
>>648
でてねーじゃんw
何をいってるんだ

ていうか、メリットねーだろ
もう、必要なもんも全然違うし
ちょこっとなんか拡張したら総崩れになるって今回の例でわかっただろ?
0650デフォルトの名無しさん2012/04/22(日) 00:16:35.06
>>649
上のほう見ればメリットが出てるのは明らか。
それに対して反論するレスがあるというのなら
それを教えてくれよ。
0651デフォルトの名無しさん2012/04/22(日) 00:29:20.66
foreach (object gameObject in GameObjectList){
 if (gameObject is ホーミングミサイルTypeA)
  ((ホーミングミサイルTypeA)gameObject).Update();
 if (gameObject is 自機ショットNormal)
  ((自機ショットNormal)gameObject).Update();
}

ああ恐ろしい
0652デフォルトの名無しさん2012/04/22(日) 00:32:33.67
>>651
多態を使わないからそうなるんだよなw
0653デフォルトの名無しさん2012/04/22(日) 00:33:00.88
>>651
これは多態を使ったら改善できる
典型的な例だな。
06546512012/04/22(日) 00:34:09.51
俺は多胎を使ってるつもりなんだが?
馬鹿には見えないのか?
0655デフォルトの名無しさん2012/04/22(日) 00:34:51.10
>>651のどこに多態があるんだ?
0656デフォルトの名無しさん2012/04/22(日) 00:35:41.68
まあ、C#は全クラスがobjectの派生だけどさ
06576512012/04/22(日) 00:36:31.61
あ、レスが途中で切れた

foreach (object gameObject in GameObjectList){
 if (gameObject is ホーミングミサイルTypeA)
  ((ホーミングミサイルTypeA)gameObject).Update();
 if (gameObject is 自機ショットNormal)
  ((自機ショットNormal)gameObject).Update();
}

↓ 多態を使うと こうなる。

foreach (object gameObject in GameObjectList){
  gameObject.Update();
}
0658デフォルトの名無しさん2012/04/22(日) 00:38:22.83
そこはforeach objectじゃなくてforeach IGameObjectやろ
ひと騙るならもっとうまくやってくれよ
06596512012/04/22(日) 00:38:29.58
間違った

foreach (GameObject gameObject in GameObjectList){
  gameObject.Update();
}
0660デフォルトの名無しさん2012/04/22(日) 00:39:32.88
これが多態のメリットってやつか!!
すごい!
0661デフォルトの名無しさん2012/04/22(日) 00:40:36.44
多態のメリットだすと
あいつが来るぞ。

反論できない奴が!
0662デフォルトの名無しさん2012/04/22(日) 00:43:24.14
来るだろうけど、今は来ないよ。

いつもどおり別の話題になって
忘れた頃に来るだろw
0663デフォルトの名無しさん2012/04/22(日) 00:44:58.35
>>657
え?それ、なにがいいの?
っていうかホーミングのターゲットや索敵機能の話しはどこに反映されてるの?
0664デフォルトの名無しさん2012/04/22(日) 00:47:52.51
>>663
> っていうかホーミングのターゲットや索敵機能の話しはどこに反映されてるの?
それはupdate()の中だよ
0665デフォルトの名無しさん2012/04/22(日) 00:53:56.87
>>664
なんだよそれ
カプセル化死んでんじゃん
ターゲットリストないとコンパイルできねークラスになってるじゃん

設計なんてドブに捨ててグローバル変数使えよ
0666デフォルトの名無しさん2012/04/22(日) 00:54:44.63
IGameObject.Update(GameManager ゲームオブジェクト管理)
よし
0667デフォルトの名無しさん2012/04/22(日) 01:15:25.18
>>665
カプセル化は死んでないし、テストドライバを使うことの何がおかしい?
0668デフォルトの名無しさん2012/04/22(日) 01:19:28.07
>>667
Updateの中でどうやってやんの?
ホーミングミサイルは敵の熱源ユニット設定値をみてターゲットにするかどうか決めてくださいって
仕様が入ったらコードに敵クラス必要になるで
あくまで上記仕様はシーンに書く処理だと思うな
0669デフォルトの名無しさん2012/04/22(日) 01:26:09.50
>>668
まさか、Updateだけで全てを完結させようとしてるの?
0670デフォルトの名無しさん2012/04/22(日) 01:27:15.33
ifで書くのとポリモで書くのはどっちもメリットデメリットある
そこのトレードオフができるかできないかが問題
0671デフォルトの名無しさん2012/04/22(日) 01:31:13.48
1)ミサイルはコンストラクタで目標オブジェクトを入力するのさ
2)目標オブジェクトの所有者は敵機なり自機なり。自分で更新してくれ
3)ミサイルのUpdateがきたら目標オブジェクトにむかってちょっとだけ動け
4)まあ目標消失したときのことを考えてオブジェクト管理クラスが仲介したほうがいいかもな

わかったな
0672デフォルトの名無しさん2012/04/22(日) 01:39:43.50
>>663
だからお前が聞きたいのは多態のメリットだろ?

これが多態のメリットだよ。
0673デフォルトの名無しさん2012/04/22(日) 01:40:36.53
>>671
目標をコンストラクタで決めるのはまずくない?
Update内で決めたほうが良いような気がするけど
0674デフォルトの名無しさん2012/04/22(日) 01:43:35.42
ふつう撃った後に目標は変わらんだろ。それならコンストラクタ一択じゃん
途中で変えたいならChangeTargetで
チャフなんかで目標変更したいときは管理クラスにおまかせで
0675デフォルトの名無しさん2012/04/22(日) 01:49:18.64
最初にターゲットを決めるホーミングミサイルとは別に
途中でターゲットを変えられるホーミングミサイルができたら
どうすんの?

更にその他の機能がついたいろんなミサイルができたらどうするの?
両方をどうやって管理するの?
0676デフォルトの名無しさん2012/04/22(日) 01:52:58.96
foreach(ホーミングミサイル ミサイル in GameObjectList)
 ミサイル.目標変更(ゲームオブジェクト管理.AimNear(自機, AimTo.敵機));

こんなもんか
なにか追加処理が来るときはトリガーがあるんだから
そのときに拾い上げればいいだろ?
0677デフォルトの名無しさん2012/04/22(日) 01:58:36.89
>>676
AimNearの引数は座標型かな俺なら
0678デフォルトの名無しさん2012/04/22(日) 02:07:00.04
>>671
どこにメリットあんだよw
0679デフォルトの名無しさん2012/04/22(日) 02:24:08.33
結局オブジェクト指向で作る話になってるしw
0680デフォルトの名無しさん2012/04/22(日) 02:27:56.38
>>676
>668に対応できないじゃん
0681デフォルトの名無しさん2012/04/22(日) 02:29:08.64
>>689
オブジェクト指向を使わないと対応できなくても当たり前。

対応させる方法がない。
0682デフォルトの名無しさん2012/04/22(日) 02:51:28.32
ゲームオブジェクトのような末端に、末端同士で参照を握り合って
勝手気ままにコミュニケートされちゃ困るよね。
0683デフォルトの名無しさん2012/04/22(日) 03:03:36.42
あれは駄目これも駄目とは言うけど何故駄目なのか具体的な説明が欲しい
0684デフォルトの名無しさん2012/04/22(日) 03:06:06.89
俺だったら、引数のオブジェクトではなく
オブジェクトのIDをもらうようにして、
で必要なときにゲームシステムから
オブジェクトを取得するようにするな。

オブジェクトを取得した後は
そのオブジェクトが持ってるインターフェースから
いろいろ値を取得する。

これもまたオブジェクト指向である。
0685デフォルトの名無しさん2012/04/22(日) 03:07:52.14
サポートしたいインターフェースのメソッドの仮引数が、
そのクラスが満たすべき処理をするのに足りてないからといって、
不足分をメンバ変数経由で渡すのなら、
元々そのクラスは、そのインターフェースにふさわしくない。
そうは思わんか?

皆が多態をしたがる。インターフェースを統一したがる。
メソッドの仮引数を統一したがる。無理にでも統一したがる。
処理に足りない情報は、メンバ変数経由でこっそり受け渡し。
インターフェース統一の代償。
あれもこれもホルダーだらけ。裏で何しているか分かりません。
OOの負の一面。
0686デフォルトの名無しさん2012/04/22(日) 03:08:40.61
>>685
それは単にお前の設計が下手なだけだよ。

そんな設計にするのは馬鹿といってもいい。
0687デフォルトの名無しさん2012/04/22(日) 03:10:37.26
少なくともミサイルに引数なんていらないのに
なんでホーミングミサイルのために引数もたなきゃいけないの?
多態が役に立たないことの証明になるんとちゃいますか?
0688デフォルトの名無しさん2012/04/22(日) 03:10:44.10
>>685
それで、仮引数が違う時
オブジェクト指向以外だと
どうするんだい?

そこが重要なとこだよね。

ちなみにオブジェクト指向なら
仮引数が違うとか全然怖くない。

なぜなら仮引数はオブジェクト一つ。
そのオブジェクトから必要なデータを引き出せばいいからだ。
いくらでも拡張可能。
0689デフォルトの名無しさん2012/04/22(日) 03:12:02.26
お前ら議論のための議論しかできないのな
それも体をなしてないが
0690デフォルトの名無しさん2012/04/22(日) 03:12:44.29
>>687
> 少なくともミサイルに引数なんていらないのに
> なんでホーミングミサイルのために引数もたなきゃいけないの?

え? ターゲットという引数が増えたからでしょw
ホーミングミサイルにターゲットという引数が増えるというのは
オブジェクト指向とは全く関係ない。

> 多態が役に立たないことの証明になるんとちゃいますか?
真逆。

引数が増えたにも関わらず、生成したオブジェクトを
ミサイルと同じように扱えることが可能。

これが多態を使わないと、破綻することの証明になってる。
0691デフォルトの名無しさん2012/04/22(日) 03:16:01.33
>>687
引数が違うのは、仕様だからどうしようもない。

引数が違っても同じものとして扱わないといけない。
多態だとそれが可能ということ。
0692デフォルトの名無しさん2012/04/22(日) 03:16:27.68
俺だったらオブジェクトが能動的に
他のオブジェクトを取得しに行くプログラムは書かないね。
updateの呼び出し元が処理に必要な情報を明示的に渡せば良いし、
そうするのが筋ってもんだ。
でもそうすると、関数の仮引数リストが処理内容によってマチマチになって、
インターフェースの統一は出来ない。多態も出来ない。
でも、仮引数のリストが違うってことは、本質的に違う種類の処理なのだろう。
仮引数リストの違いが縁の切れ目。無理に纏めずに諦めよう。
0693デフォルトの名無しさん2012/04/22(日) 03:18:51.66
え?多態を使うから
ミサイルとホーミングミサイルで引数が違うんでしょ?

多態を使わない場合は、
ミサイルもホーミングミサイルも引数は全くおなじになる。
ミサイルが必要ない引数は無視すればいいだけのこと。

だから、ゲームに出てくるすべてのオブジェクトが
関係ない引数をたくさんもらって、
func(a, b, c, d, e, f, g, h, i, j, k, l, m, n)みたいに
酷いことになるが、それが正義だ。何が悪い。ばーかばーか
0694デフォルトの名無しさん2012/04/22(日) 03:20:00.20
というか生成時に画面上の全オブジェクトを参照できるようにするんじゃ駄目なのか
衝突判定とかにも要るだろうし
0695デフォルトの名無しさん2012/04/22(日) 03:22:25.82
>>692
> updateの呼び出し元が処理に必要な情報を明示的に渡せば良いし、
> そうするのが筋ってもんだ。

たとえば、こういうことだよね。

if(object が ミサイル) {
 ミサイル.update();
} else if(object が ホーミングミサイル) {
 if(ターゲット が 敵A) {
  x = 敵A.x;
  y = 敵A.Y;
 } else if(ターゲットが敵B) {
  x = 敵A.x;
  y = 敵A.Y;
 } else if(ターゲットが略) {
 }
 ホーミング.update(x, y);
} else if(object が ○○ミサイル) {
 if(ターゲット が 敵A) {
  x = 敵A.x;
  y = 敵A.Y;
 略 }
 ○○ミサイル.update(x, y);
} else if(object が △△ミサイル) {
 略
} 略
0696デフォルトの名無しさん2012/04/22(日) 03:24:00.18
>>695

あ、見たこと有るわwwww
0697デフォルトの名無しさん2012/04/22(日) 03:26:51.28
>>692
そもそもさ、
仮引数の数が違うのはなぜかというと
オブジェクト指向じゃないからだよ。

オブジェクト指向なら、どんなオブジェクトであっても
仮引数は同じに出来る。
0698デフォルトの名無しさん2012/04/22(日) 03:27:59.01
>>694
ゲームクラスは全てのゲームオブジェクトを知ってる必要があるね。
でも、衝突判定をゲームオブジェクト自身が行う必要はなし、
間違ってもゲームオブジェクトがゲームクラスにゲームオブジェクトのリスト頂戴〜、
なんてのはナンセンスだよね。
例えば君が部長で、部下が「うちの部の前メンバーのリスト頂戴〜」
なんて言ってきたら、一体何をおっぱじめる気だ?ってなるよね。
0699デフォルトの名無しさん2012/04/22(日) 03:29:15.04
>>698
そうだね。
オブジェクト指向だと
そういうことが可能だよね。
0700デフォルトの名無しさん2012/04/22(日) 03:31:38.26
>>695
ターゲットはインターフェースで纏めても良いだろう。
今言ってるのは、
ホーミングミサイルとミサイルのインターフェースを、
updateに関して纏める必要はないねって話で。
だって、ミサイルのupdateにはターゲット座標は要らないけど、
ホーミングミサイルのupdateにはターゲット座標が必要でしょ?
つまり、本質的に別の処理だ。無理に纏める必要はないね。
0701デフォルトの名無しさん2012/04/22(日) 03:32:17.48
> 例えば君が部長で、部下が「うちの部の前メンバーのリスト頂戴〜」
> なんて言ってきたら、一体何をおっぱじめる気だ?ってなるよね。

作業の引き継ぎのために前の部のメンバーに連絡がとりたいんです。

何か問題でも?

問題があるのなら、何が問題なのかを
教えてください。
0702デフォルトの名無しさん2012/04/22(日) 03:33:33.58
>>700
何を言ってるかさっぱりわからん。

updateのとき、オブジェクトがミサイルなら、
引数いらないし、オブジェクトがホーミングミサイルなら
ターゲット引数がいるだろ。

つまり何が言いたいのかというと。
updateの時にifがたくさんできるのが正しいのだ
俺が正義だ。
0703デフォルトの名無しさん2012/04/22(日) 03:35:45.08
ミサイルのupdateにも
ホーミングミサイルのupdateにも
ターゲットはいらないだろ。

なんでホーミングミサイルのupdateから
ターゲットを取り除いて
同じ引数にする方法がわからないんだ?
0704デフォルトの名無しさん2012/04/22(日) 03:37:08.38
オブジェクト指向ができてないと、
オブジェクトごとに引数を変える方法しか思いつかんのだよ。

壁ってやつさ。
0705デフォルトの名無しさん2012/04/22(日) 03:38:51.11
>オブジェクト指向なら、どんなオブジェクトであっても
>仮引数は同じに出来る。

ただ、これは本当に 迷言 だと思う。
本当に言っている意味が分からない。

もしくは状態マシン風に無理に纏めることは出来るが、
止めろと言ってる訳で。

obj->set_param( 〜〜 );
obj->execute(); ←このメソッドは全てのオブジェクトで共通。

なんちゃって。
0706デフォルトの名無しさん2012/04/22(日) 03:39:43.93
> 本当に言っている意味が分からない。
うん。馬鹿だからだね。
0707デフォルトの名無しさん2012/04/22(日) 03:41:39.60
>>701
部長がgetしてsetするから、本人同士は合う必要なし。
この方がパーツ同士の依存度が低くて良いだろ。
0708デフォルトの名無しさん2012/04/22(日) 03:42:48.63
バカには見えないっていうやつはたいていバカ
0709デフォルトの名無しさん2012/04/22(日) 03:43:22.40
>>705の書くコード

if(obj == A) {
 obj->execute(a); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == B) {
 obj->execute(a,b); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == C) {
 obj->execute(a,b,c); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == D) {
 obj->execute(a,b,c, d); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == E) {
 obj->execute(a,b,c,d,e ); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == F) {
 obj->execute(a,b,c,d,e,f ); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == G) {
 obj->execute(a,b,c,d,e,f,g); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == H) {
 obj->execute(a,b,c,d,e,f,g,h); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == I) {
 obj->execute(a,b,c,d,e,f,g,h,i); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == J) {
 obj->execute(a,b,c,d,e,f,g,h,i,j); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == K) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == L) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k,l); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == M) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k,l,m); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == N) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k,l,m,n); ←このメソッドは全てのオブジェクトでバラバラ
}
0710デフォルトの名無しさん2012/04/22(日) 03:44:14.65
>>703
メンバ変数経由にするぐらいなら、分けたほうがマシ。
ゲームクラスに問い合わせるのはもっと最悪。
0711デフォルトの名無しさん2012/04/22(日) 03:44:59.64
>>707
> 部長がgetしてsetするから、本人同士は合う必要なし。

部下「うちの部の前メンバーのリスト頂戴〜
部長「え?俺がやるの?」
部下「当然ですよ。メンバーのリストを作成するのは部長のお仕事ですよねwww」
0712デフォルトの名無しさん2012/04/22(日) 03:45:37.98
>>710
じゃあ、最善の方法を使えばいいのでは?

すなわち多態だけど。
0713デフォルトの名無しさん2012/04/22(日) 03:47:32.88
>>710
> メンバ変数経由にするぐらいなら、分けたほうがマシ。
分けるってことは、ローカル変数経由にするってこと?
0714デフォルトの名無しさん2012/04/22(日) 03:47:35.21
>>709
違うね。
obj_a->execute( a );
obj_b->execute( a, b );
obj_c->execute( a, b, c );
obj_d->execute( a, b, c, d );
だ。
型ごとにコレクションするからね。
0715デフォルトの名無しさん2012/04/22(日) 03:49:05.90
>>711
メンバーリストを作るのは部長の仕事だが、
それを部下に教える必要はないし、部下も知る必要はない。
それが身のため。
0716デフォルトの名無しさん2012/04/22(日) 03:50:21.91
> 型ごとにコレクションするからね。
つまり、こういうことかいハニー?w

if(obj == A) {
 obj_a_collection.add(obj);
} else if(obj == B) {
 obj_b_collection.add(obj);
} else if(obj == C) {
 obj_c_collection.add(obj);
} else if(obj == D) {
 obj_d_collection.add(obj);
} else if(obj == E) {
 obj_e_collection.add(obj);
} else if(obj == F) {
 obj_f_collection.add(obj);
} else if(obj == G) {
 obj_g_collection.add(obj);
} else if(obj == H) {
 obj_h_collection.add(obj);
} else if(obj == I) {
 obj_i_collection.add(obj);
} else if(obj == J) {
 obj_j_collection.add(obj);
} else if(obj == K) {
 obj_k_collection.add(obj);
} else if(obj == L) {
 obj_l_collection.add(obj);
} else if(obj == M) {
 obj_m_collection.add(obj);
} else if(obj == N) {
 obj_n_collection.add(obj);
}
0717デフォルトの名無しさん2012/04/22(日) 03:53:03.67
foreach(obj_a : obj_a_collection) {
  obj_a->execute( a );
}
foreach(obj_b : obj_b_collection) {
  obj_b->execute( a, b );
}
foreach(obj_c : obj_c_collection) {
  obj_c->execute( a, b, c );
}
foreach(obj_d : obj_d_collection) {
  obj_d->execute( a, b, c, d );
}
0718デフォルトの名無しさん2012/04/22(日) 03:54:17.48
オブジェクト指向を使わないと
ここまで醜くなるんだな。

逆に勉強になったわ。逆に。
0719デフォルトの名無しさん2012/04/22(日) 03:55:13.50
>>718
逆にじゃなくてそれが目的だろw
反面教師。
0720デフォルトの名無しさん2012/04/22(日) 03:56:17.31
>>713
呼び出し元を分けるってこと。
ミサイル->update(); と ホーミングミサイル->update( x, y ); で。
処理に必要なパラメータが違うのだから、違う処理なんだよ。
それでもどうしてもプラグインにでもする必要があるなら纏めるがな。
もっと大きな粒度での話だが。
0721デフォルトの名無しさん2012/04/22(日) 03:56:19.83
オブジェクト指向で設計できない人が書くと
>>716みたいになるんだろうな。

ゲームとか、キャラクターの数
何中何百ってなるわけだが
型ごとにコレクションしたら酷いことになるな。
0722デフォルトの名無しさん2012/04/22(日) 03:57:10.11
呼び出し元を分けるってこと。
ミサイル->update(); と ホーミングミサイル->update( x, y ); で。
↓つまりこういうこと
if(obj == ミサイル) {
 obj->execute(); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == ホーミングミサイル) {
 obj->execute(x,y); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == C) {
 obj->execute(a,b,c); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == D) {
 obj->execute(a,b,c, d); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == E) {
 obj->execute(a,b,c,d,e ); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == F) {
 obj->execute(a,b,c,d,e,f ); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == G) {
 obj->execute(a,b,c,d,e,f,g); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == H) {
 obj->execute(a,b,c,d,e,f,g,h); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == I) {
 obj->execute(a,b,c,d,e,f,g,h,i); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == J) {
 obj->execute(a,b,c,d,e,f,g,h,i,j); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == K) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == L) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k,l); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == M) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k,l,m); ←このメソッドは全てのオブジェクトでバラバラ
} else if(obj == N) {
 obj->execute(a,b,c,d,e,f,g,h,i,j,k,l,m,n); ←このメソッドは全てのオブジェクトでバラバラ
0723デフォルトの名無しさん2012/04/22(日) 03:58:40.45
>>716
なんでいったんobjにアップキャストする必要があるんだ?
obj_a_collection.add( new obj_a );
でよいだろ。よーわからん。
0724デフォルトの名無しさん2012/04/22(日) 03:59:38.75
>>717
あ、これ最高。何が最高って、処理の順番が明確だから。
0725デフォルトの名無しさん2012/04/22(日) 03:59:40.80
>>720
> 処理に必要なパラメータが違うのだから、違う処理なんだよ。

だからパラメータが一緒でも違っても、
クラスが違うなら、違う処理なの当たり前だろ・・・

違う処理でも同じように呼び出せるのが
多態のメリットなわけで。
0726デフォルトの名無しさん2012/04/22(日) 04:01:04.70
>>722
だから、何度もいうが、どうしていつもobjにアップキャストするんだ?
アップキャストするとダウンキャストしなきゃならなくなるだろ。
0727デフォルトの名無しさん2012/04/22(日) 04:01:30.61
>>723
まさかこんなキモい設計なのか?

class グローバルコレクションクラス {
  public ミサイル用コレクション
  public ホーミングミサイル用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
  public ○用コレクション
}
0728デフォルトの名無しさん2012/04/22(日) 04:04:47.01
>>727
それのどこが悪い?

実際のゲームだとそんなもんじゃないぞ。
それの100倍はある。
0729デフォルトの名無しさん2012/04/22(日) 04:05:35.31
実際のゲームのフレームワークを見てみようよ。

オブジェクトごとにコレクション作ってるのないから。
0730デフォルトの名無しさん2012/04/22(日) 04:06:13.79
>>725
呼び出しが纏まることより、非明示なデータの流れが出来る方が害がある。
0731デフォルトの名無しさん2012/04/22(日) 04:06:46.91
>>730
それは真逆だ。
0732デフォルトの名無しさん2012/04/22(日) 04:08:55.82
すべての仕事は上司が一人でやる方式

VS

仕事は部下が分担してやる方式


お前の会社はどっち?
0733デフォルトの名無しさん2012/04/22(日) 04:09:25.67
>>698
なんか感覚で語ってない?
リアルタイムでオブジェクトが動くようなゲーム作ったこと無いから頓珍漢な事言ってるかもしらんが
オブジェクトが自身の動作に必要なものを参照するのは普通じゃね?

>>707
なんか部下の仕事のほとんどを部長がやるハメになりそうな気がするんだが大丈夫か
部下の仕事が増えるたびに部長の仕様も拡張する必要が出てきそうに見える
0734デフォルトの名無しさん2012/04/22(日) 04:10:34.19
>>732
部下同士でコミュニケーションとってたらダメだろ。

誰々と話したい時は上司経由で
連絡を取るもんだ。
0735デフォルトの名無しさん2012/04/22(日) 04:11:15.62
>>727
これが最高なんだよ。何が最高って、ダウンキャストが発生しない。
仮にオブジェクトが複数のインターフェースを実装している場合は、
それぞれのインターフェースごとのコレクションにも追加されるのな。
で、コレクションごとにfor_each回して処理してく。超シンプル。
0736デフォルトの名無しさん2012/04/22(日) 04:12:22.61
>>735
だから、真逆

わかっててやってるだろ?

わかってないなら馬鹿。
わかってやってるならアホ
0737デフォルトの名無しさん2012/04/22(日) 04:14:03.66
>>735
多態にはアップキャストしか必要ないんだが?
0738デフォルトの名無しさん2012/04/22(日) 04:15:07.47
>>733
問題ない問題ない。課長を作れば良い。
ゲーム部ホーミング課長とかな。
ゲームオブジェクトは派遣だね。
ゆえに何も知る必要はない。
0739デフォルトの名無しさん2012/04/22(日) 04:16:05.72
>>738
どうした? 意味不明になってるぞw
馬鹿にされ過ぎて
本当に馬鹿になったのか?
0740デフォルトの名無しさん2012/04/22(日) 04:18:37.74
>>737
ダウンキャストが必要になるよ。
なぜならオブジェクトごとにメソッドの引数が違うだろ?


そもそもの話、オブジェクトごとにメソッドの引数が
違うってことがおかしいんだが、
馬鹿にはそれがわからない。

つまりだ、ダウンキャストが出てきた時点で
奴は馬鹿。

そして馬鹿な設計で、ダメにしているのを
オブジェクト指向のせいにしている。
0741デフォルトの名無しさん2012/04/22(日) 04:19:36.99
やあ、これでupdateのメソッドを
共通にする理由が明らかになったじゃないか。

ダウンキャストを無くすためだ。
0742デフォルトの名無しさん2012/04/22(日) 04:21:52.30
>そもそもの話、オブジェクトごとにメソッドの引数が
>違うってことがおかしいんだが

だったら今ここで世界共通の唯一の仮引数リストとやらを発表してくれ。
0743デフォルトの名無しさん2012/04/22(日) 04:25:48.74
>>741
なんでそんな上流で締め上げちまうんだよ。
オブジェクト間を跨る処理をスマートに処理できるのは上流だけなんだぜ?
後は勝手にやってくれってか?もったいない。
0744デフォルトの名無しさん2012/04/22(日) 09:09:57.40
だからメリットねぇだろw
ミサイルとホーミングミサイル程度の違いでも多態は吸収不可なんだよ
いつまでやってんだ?お前等
文系PG邪魔すぎだろ
0745デフォルトの名無しさん2012/04/22(日) 09:36:26.08
じゃあ理系プログラマらしくコードで説明してくれ
非OOでミサイルとホーミングミサイルを実装したコード見せて
0746デフォルトの名無しさん2012/04/22(日) 09:40:04.61
>>745
やだよ
面倒臭ぇもん

それに、いま、多態によるメリットが見えてなければプログラム組んでも無意味なもんができるだけじゃない?
0747デフォルトの名無しさん2012/04/22(日) 09:43:42.71
OOより非OOが勝るところをコードで説明できないの?
0748デフォルトの名無しさん2012/04/22(日) 09:48:44.29
>>746
口だけ、いらね
0749デフォルトの名無しさん2012/04/22(日) 09:49:21.59
>>748
自己紹介乙
0750デフォルトの名無しさん2012/04/22(日) 09:58:21.73
醜い罵り合いになっちゃったな
雑魚ばかり
0751デフォルトの名無しさん2012/04/22(日) 10:01:26.27
下級戦士程よ吠えるんだよ。しょうがない
0752デフォルトの名無しさん2012/04/22(日) 10:10:45.78
メリットが見えないというより、もう見ないようにしてるだけだろ
ソースも出さないで騙るなよ

シンプルって言葉だけでオブジェクト指向否定してる阿呆もいるし
0753デフォルトの名無しさん2012/04/22(日) 10:10:59.07
>>744
専門卒乙
0754デフォルトの名無しさん2012/04/22(日) 10:18:37.65
粒度がバラバラ
0755デフォルトの名無しさん2012/04/22(日) 10:30:29.33
ソフトウェア開発はカオスという事が解った
オブジェクト指向の利点は、処理なんて何も無いのにあたかも処理してるぜって感じる事じゃねwww

ttp://d.hatena.ne.jp/ryoasai/touch/20110317/1300380540
0756デフォルトの名無しさん2012/04/22(日) 10:45:43.47
阿呆にも解りやすくアナロジーで騙ってるのか

「問題領域の概念を抽象的に表現する為のクラスを正しく抽出する必要がある」

これが出来てる奴がいかに少ないか
俺も出来ないけどww
0757デフォルトの名無しさん2012/04/22(日) 10:58:13.24
>>755
web開発の場合、処理よりデータの扱いの方が大きいからオブジェクト指向が流行ったんだろ

処理が無いとは言いすぎだが、処理より物をとったんだから自然とそうなるのは仕方ない
0758デフォルトの名無しさん2012/04/22(日) 11:10:34.87
>>711
違うよ、メンバーリストは既に作成済み(適宜更新されてる)で部長が持ってて
部下はそのリストを部長の許可なしには見れないだけ
真っ当でそ、何かおかしいかな?
0759デフォルトの名無しさん2012/04/22(日) 11:18:09.19
カプセル化がまだいたのか
委譲したいって事でしょ。特に問題ないが、先に言い出した時は、インスタンスをまるごと渡すって言い方だったぞ
0760デフォルトの名無しさん2012/04/22(日) 11:30:00.51
>>759
え?なんの話?
0761デフォルトの名無しさん2012/04/22(日) 11:40:12.62
オブジェクト指向は例えんのが大好きだなって話かな
0762デフォルトの名無しさん2012/04/22(日) 11:41:19.48
>>756
つまり「タイムを縮める」ためには「速く走ればいい」ってことだろ
うん、わかるわかる
0763デフォルトの名無しさん2012/04/22(日) 11:49:14.17
>758
> 部下はそのリストを部長の許可なしには見れないだけ
> 真っ当でそ、何かおかしいかな?

おかしいだろ。

理由は、>>698を読め

> 例えば君が部長で、部下が「うちの部の前メンバーのリスト頂戴〜」
> なんて言ってきたら、一体何をおっぱじめる気だ?ってなるよね。
0764デフォルトの名無しさん2012/04/22(日) 11:52:09.84
オブジェクト指向で処理が見えにく物まで処理すようになった、で良いんじゃないかなww
0765デフォルトの名無しさん2012/04/22(日) 11:54:35.84
多態はすごいな。
ミサイルとホーミングミサイルを
綺麗に表現してしまった。
0766デフォルトの名無しさん2012/04/22(日) 12:12:10.64
>>765
いや、まったくできてないどころか喧嘩になっとるやんけ
0767デフォルトの名無しさん2012/04/22(日) 12:13:34.13
>>766
いや、一人オブジェクト指向がわかってない奴が
オレオレオブジェクト指向して、出来ないと言ってるだけで
他の人はわかってる。
0768デフォルトの名無しさん2012/04/22(日) 12:17:59.17
見れる事自体が問題だと言ってるのに、上司経由でなら見て良いでしょ?って言ってるから問題なんだろ
以下にもオブジェクト指向らしい問題だな
0769デフォルトの名無しさん2012/04/22(日) 12:30:17.80
>>763
素直に部長に説明するだけでしょ、正当な理由があれば通るしそうでなければ通らないだけだと思うが
0770デフォルトの名無しさん2012/04/22(日) 12:31:06.35
じゃあ>>698は馬鹿ということか!
0771デフォルトの名無しさん2012/04/22(日) 12:34:34.61
アナロジーは、議論をこじれさせる天才だな
つまり、オブジェクト指向をアナロジーする時に問題は生まれる
0772デフォルトの名無しさん2012/04/22(日) 12:37:01.00
>>698に関して言えば、
衝突判定だけをゲームを管理しているオブジェクトが行い、
衝突したらどうなるかは、各オブジェクトに委譲する。

そのとき各オブジェクトはそれぞれ違うクラスだが
ゲーム管理オブジェクトは、それらすべてに同じ引数で
呼び出すことが可能で、それぞれに応じた動作をする
つまり各オブジェクトは多態になってる。

>>698が馬鹿なのは、衝突判定にゲームオブジェクトのリストが
必要なというだけで、どんな場合でも必要ないかのように言ったこと。

ゲームオブジェクトのリストが必要な場面はある。
その時、ゲームオブジェクトがゲーム管理オブジェクトに
問い合わせることに何の問題もない。
0773デフォルトの名無しさん2012/04/22(日) 12:37:45.29
オブジェクト指向自体がアナロジーの産物
0774デフォルトの名無しさん2012/04/22(日) 12:41:12.65
衝突といってもオブジェクトによって引数は違う

あるオブジェクトは、2つ衝突したら爆発するかもしれないし
他のオブジェクトは、3つ同時に衝突したら爆発するかもしれない。

その時、前者は引数2つ。後者は引数3つになる。
これを同じにすることなんか出来ない!


↑これがオブジェクト指向をわかってない例の馬鹿の主張。

根本的に引数を変える方法しか知らないから
このような結論になる。
0775デフォルトの名無しさん2012/04/22(日) 12:48:19.13
ミサイルとホーミングミサイルにそれぞれ
衝突メソッド、collision()インターフェースを実装して

collision()を呼び出すときに、衝突情報オブジェクトを渡せば
あとは2つ衝突したか、3つ衝突したかは
衝突情報オブジェクトから取得できるな。

もしくは各オブジェクト生成時に親オブジェクト
(ゲーム管理オブジェクト)を渡して、そこから取得する方法もある。
0776デフォルトの名無しさん2012/04/22(日) 12:59:45.44
オブジェクト指向を批判するA君(仮名)が一貫して主張してるのは
オブジェクトには一切の情報を持たせないということ
※現実のミサイルは自分に内蔵するコンピュータで目標捉えて姿勢制御するけどね

たぶん「ミサイル」はオブジェクトじゃなくユニークキーにしたいんだろう
RDBMSの概念でゲームを作ろうとは実務SEらしい考え方
0777デフォルトの名無しさん2012/04/22(日) 13:00:33.77
>>769
個人情報集めるのに正当な理由なんて有るわけ無いだろ。
つまり、上司にリストを聞くのはNGってことだ。

ここから容易に部下は上司から情報を提供する方法しか
存在しないという結論が成り立ちます。

しかし、部下によって必要な情報はまちまち。
だから上司は、部下を呼び出すときに、情報を変えて渡す必要があります。

引数が違うので多態は使えません。

そしてダウンキャストを無くすために、部下の種類ごとに
コレクションを作ります。

これは俺が馬鹿でオブジェクト指向を知らないからこんな
クソ設計になったのではありません。

そもそも上司にリストを聞くのがNGという最初の答えが間違っていたから
そのあと全てが壊れたのではありません。

オブジェクト指向そのものの問題です。
0778デフォルトの名無しさん2012/04/22(日) 13:05:04.26
>>776
> オブジェクト指向を批判するA君(仮名)が一貫して主張してるのは
> オブジェクトには一切の情報を持たせないということ

当たり前だろ。部下に情報を渡したらそれをどう使うのかわからん。
他社に売りつけるかもしれないだろ。

部下はいっさい情報を持たず、上司がその部下ごとに
必要な情報を、引数リストで渡す。

上司はどんな部下がいるかをすべて把握している
なんでもできるスーパーマン。だからこそ上司になったんだ。
0779デフォルトの名無しさん2012/04/22(日) 13:07:58.94
あー、馬鹿のまねをするのは楽しいww
0780デフォルトの名無しさん2012/04/22(日) 13:09:52.56
>>778
部下は情報を持たなくても、
上司が誰か知っていれば(普通知ってる)

必要なときに、上司に問い合わせればいい。
上司から引数リストで貰う必要はない。
0781デフォルトの名無しさん2012/04/22(日) 13:12:35.72
つまり、ミサイルもホーミングミサイルも
update()でよくて、

ミサイルやホーミングミサイルで何かの
情報が必要になった時は
ゲーム管理オブジェクトに問い合わせればいいわけですね。

コレで引数が共通に出来ます。
多態できます。
すごくスマートですね。
0782デフォルトの名無しさん2012/04/22(日) 13:15:10.80
衝突したか否かの判定が
ミサイルとターゲットの両方の型に依存する場合に
どうしてる?

collision_AA(ミサイルA, ターゲットA)
collision_AB(ミサイルA, ターゲットB)
collision_BA(ミサイルB, ターゲットA)
collision_BB(ミサイルB, ターゲットB)

それぞれで処理が違う場合、どうやって一つのcollisionにまとめてる?



さらに地形等、多数に依存する場合はどうしてる?

collision_AAA(ミサイルA, ターゲットA, 地形A)
collision_AAB(ミサイルA, ターゲットA, 地形B)
...
0783デフォルトの名無しさん2012/04/22(日) 13:15:59.18
> 衝突したか否かの判定が
> ミサイルとターゲットの両方の型に依存する場合に
> どうしてる?

ダブルディスパッチ

一言で終了しちゃったw
0784デフォルトの名無しさん2012/04/22(日) 13:17:25.07
常識でんがなw
wikipediaにすら書いてあるぐらい。

http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%96%E3%83%AB%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81

ダブルディスパッチは計算結果が引数の動的な型に依存する場合に有用である。
たとえば、以下のような状況でダブルディスパッチを活用することができる。

""適応的衝突判定アルゴリズム"" では、通例物体により異なる方法で衝突を判定する必要がある。
典型的な例では、ゲーム開発環境で、宇宙船と小惑星の衝突と、宇宙船と宇宙ステーションの衝突とは異なる方法で計算される。
0785デフォルトの名無しさん2012/04/22(日) 13:18:22.42
これもオブジェクト指向の
すごさってやつか!
0786デフォルトの名無しさん2012/04/22(日) 13:19:03.37
ダブルディスパッチは全然シンプルなコードにならないけどね
マルチメソッドなら良いのに
0787デフォルトの名無しさん2012/04/22(日) 13:20:01.67
オブジェクト指向批判している奴は蚊帳の外
涙目www
0788デフォルトの名無しさん2012/04/22(日) 13:20:29.22
マルチメソッドもOOの範疇だけどな
マルチメソッドできない言語?うんこでしょ
0789デフォルトの名無しさん2012/04/22(日) 13:22:20.70
http://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81

プログラミング言語におけるサポート

汎用のマルチメソッド機能をサポートするプログラミング言語は次のとおりである。
Common Lisp (Common Lisp Object System)
Dylan
Nice
Slate
Cecil
Perl6
何らかの拡張でマルチメソッドをサポートする言語として、次のものがある。
Scheme (TinyCLOS)
Python (gnosis.magic.multimethods)
Perl (Class:Multimethods)
Java (MultiJava)
Ruby (The Multiple Dispatch Library, Multimethod Package)
0790デフォルトの名無しさん2012/04/22(日) 13:27:13.48
ダブルディスパッチと多重ディスパッチ(マルチメソッド)の違いを教えてくれませんか?
0791デフォルトの名無しさん2012/04/22(日) 13:27:56.68
そもそも多態厨は想像力がたりない
引数がちょっと増えたなんてのはあくまで1例であって
そもそも型特有の情報で判定して型特有の情報でないと判定できないチェックが走るかもしれない可能性を
はじめから排除して当たり判定やらターゲット処理を共通化できると勝手に思い込んでいる

ほとんどのゲームでそんなことできねぇし
できるもんならわざわざ作らないんだよ

そもそも判定にしたって込み入ったゲームになるとオブジェクト1対1で済むほうが稀
0792デフォルトの名無しさん2012/04/22(日) 13:30:15.85
マルチメソッドを使いたかったら
>>789のどれかを使ってれば良いんじゃね?

MultiJavaとか古過ぎてJava5にすら対応してないけど
そこは気合いで乗り切るってことでさ。
0793デフォルトの名無しさん2012/04/22(日) 13:38:17.41
static void Main(string[] args)
{
 List<IGameObject> gameObjectList = new List<IGameObject>();

 int 発射座標 = 10;
 int ただのミサイルの進行方向 = 1;
 int 標的座標 = -100;
 標的 迎撃実験目標 = new 標的(標的座標);
 gameObjectList.Add(迎撃実験目標);
 gameObjectList.Add(new ただのミサイル(発射座標, ただのミサイルの進行方向));
 gameObjectList.Add(new ホーミングミサイル(発射座標, 迎撃実験目標.GameObjectInfo));

 int ループ上限 = 5;
 for (int i = 0; i < ループ上限; i++)
 {
  foreach (IGameObject gameObject in gameObjectList)
  {
   gameObject.Update();
   Console.WriteLine("{0}: {1} 位置 {2}", i, gameObject, gameObject.GameObjectInfo.Position);
  }
 }
 Console.ReadKey();
}

書いてみればええねん。もちろん動くで
実際のクラスのコードはいらんやろ
0794デフォルトの名無しさん2012/04/22(日) 13:39:08.62
>>791
今更なに必死になってんのさw

周回遅れだぞ。
答えが出た後に問題出しても恥ずかしいだけだ。

頭固いね。多態それだけしか使っちゃいけない機能じゃない。
多態は既存の機能に+して使える機能だ。
お前が持ってる全ての技術+多態(+その他たくさん)である
俺らのほうが勝ってるのさ
0795デフォルトの名無しさん2012/04/22(日) 13:50:05.92
要件は後出し
非OOのコードを示せといっても出さない
多態にはメリットが無いという根拠もださない

これで納得できるほうがおかしい
0796デフォルトの名無しさん2012/04/22(日) 14:01:26.42
>>794
実際、ミサイルとホーミングミサイル程度のもんにも使えない現実があるんだけどねw
0797デフォルトの名無しさん2012/04/22(日) 14:05:32.80
勝ち負けは勝手に出すなよ
0798デフォルトの名無しさん2012/04/22(日) 14:05:45.34
>>796
根拠を書いてね
あと非OOならうまく書けるってんならコードもな
0799デフォルトの名無しさん2012/04/22(日) 14:14:56.81
>>796

661 名前:デフォルトの名無しさん[sage] 投稿日:2012/04/22(日) 00:40:36.44
多態のメリットだすと
あいつが来るぞ。

反論できない奴が!


662 名前:デフォルトの名無しさん[sage] 投稿日:2012/04/22(日) 00:43:24.14
来るだろうけど、今は来ないよ。

いつもどおり別の話題になって
忘れた頃に来るだろw
0800デフォルトの名無しさん2012/04/22(日) 14:16:16.76
マルチメソッドできる => 神
マルチメソッドできない => ゴミ(非OOに毛が生えたようなもん)

同じOOで語るな
0801デフォルトの名無しさん2012/04/22(日) 14:26:16.65
>>798
俺は多態にメリットがないって言ってるだけだよ
やめりゃいいじゃん
メリットないんだから
ターゲット程度の要素の増減で設計思想丸つぶれになるんだから
こんなの意味ないんだよバーカ
そんなこともわからないの?
0802デフォルトの名無しさん2012/04/22(日) 14:27:20.21
これまで勉強してきたことが全部無駄になっちゃう!
ほら、多態が使えるって頑張って説明しなきゃ!w
0803デフォルトの名無しさん2012/04/22(日) 14:30:56.62
変態のどこが悪いんじゃ
0804デフォルトの名無しさん2012/04/22(日) 14:31:41.49
>>801
君がメリットを感じないのはもうわかったからわざわざ宣言してくれなくてもいいけど

今まで散々メリットについて説明されてるよね
それについて反論するならちゃんと根拠をかいてくれなきゃ
ただ無いと言い張るだけじゃだれも説得できないよ
0805デフォルトの名無しさん2012/04/22(日) 14:35:37.47
interface IGameObject
{
GameObjectInfo GameObjectInfo { get; set; }
void Update();
bool Collision(GameObjectType someone);
}

別になんも考える必要ないしね
こんな簡単なことも思いつかない演技をしなきゃならないA君の方がかわいそうだよ

もっとも何百というオブジェクトがリアルタイムで飛び交うんだから
1対1ではチェックしないけどな
0806デフォルトの名無しさん2012/04/22(日) 14:41:18.45
> もっとも何百というオブジェクトがリアルタイムで飛び交うんだから
> 1対1ではチェックしないけどな
どんだけボロいPC想定してんだと。10年前のPCでも余裕だぞそれ。
0807デフォルトの名無しさん2012/04/22(日) 14:43:18.63
?
0808デフォルトの名無しさん2012/04/22(日) 14:49:27.65
誰もPCで動かすなんて想定してないじゃないか
ゲーム機だったらどうするだ?

100個が1000個になって1万個になったときにハングするようなコードは
書きたくないなぁ
0809デフォルトの名無しさん2012/04/22(日) 14:50:13.41
>>801

俺は多態にメリットがないって言ってるだけだよ

理由はコレかい?

オブジェクト指向は無駄なもの。俺が理解出来ないからね
http://kohada.2ch.net/test/read.cgi/prog/1332351520/
0810デフォルトの名無しさん2012/04/22(日) 14:57:20.93
多態したいがために仕様を複雑にしようとしてる奴がいるな。
オブジェクト指向以前に仕様をシンプルにまとめる努力しろと思う。
0811デフォルトの名無しさん2012/04/22(日) 14:59:13.33
そもそも仕様が示されてない
0812デフォルトの名無しさん2012/04/22(日) 15:01:10.02
仕様はミサイルとホーミングミサイルだよ。

これをどうやって多態を使って
綺麗に実装するか。

実装してしまったので、なかったことにしたいんだろうなw
0813デフォルトの名無しさん2012/04/22(日) 15:02:03.92
仕様が無い物までプログラミングするのが、オブジェクト指向の強みだろ

手続き型で表せる筈が無い
0814デフォルトの名無しさん2012/04/22(日) 15:03:32.15
>>813
それくらい手続き型でも出来る。
ナメんな馬鹿野郎
0815デフォルトの名無しさん2012/04/22(日) 15:04:51.57
Q. ○○とか××とかにも対応できるように汎用性を持たせるべきだ。
A. ○○することなんて一生ねーよバカ野郎。

多態には高度な先見の明が要求されます。
ただの妄想厨は設計を複雑にするだけなので嫌われます。
0816デフォルトの名無しさん2012/04/22(日) 15:07:42.95
> 多態には高度な先見の明が要求されます。

そんなものいらんよ。
シンプルに作れば、拡張性をもたせられる。

オブジェクトからはどんな情報でも引き出せる。
こうしておけば、あとはオブジェクトを与えるだけ。

xとかyとか、あるオブジェクトに依存した
引数を渡す。なんてことをするから拡張性がなくなるんだよ。
0817デフォルトの名無しさん2012/04/22(日) 15:10:17.27
そんなコードを見てみたいな
0818デフォルトの名無しさん2012/04/22(日) 15:11:48.98
プログラマに必要な、抽象化って能力の話だよね。
実力がない人は、抽象化能力がないため
つい具体的な例になってしまう。

つまり、ミサイルとかホーミングミサイルみたいなもの。
んで、ホーミングミサイルならターゲット情報が必要だ。
○○ミサイルなら○○情報が必要みたいに、
クラスごとにいろんな例を考え、全てに対応しようとして破綻する。

抽象化ができる人なら逆に具体的なクラスから
抽象的なクラスを導くことが出来る。
そのため設計がシンプルになる。
0819デフォルトの名無しさん2012/04/22(日) 15:13:08.74
馬鹿 → 全てに対応しようとして破綻
プログラマ → 全てに対応可能な設計にしておき、必要なった時に後から追加する。シンプル
0820デフォルトの名無しさん2012/04/22(日) 15:16:02.72
class ゲーム管理 implements
                ゲームオブジェクトA問い合わせインターフェース,
                ゲームオブジェクトB問い合わせインターフェース,
                ゲームオブジェクトC問い合わせインターフェース,
                ゲームオブジェクトD問い合わせインターフェース,
                                ...
                ゲームオブジェクトZ問い合わせインターフェース
{
}
0821デフォルトの名無しさん2012/04/22(日) 15:16:23.57
馬鹿 → 全てに対応しようとして破綻
天才→全てに対応する

馬鹿と天才は紙一重
0822デフォルトの名無しさん2012/04/22(日) 15:18:57.18
>>821
全てに対応することは不可能だよ。
だから、全てに対応可能な設計にする。

後から機能を追加できるようにしておけば
必要になった時に考えればいいから、
先見の明が必要なくなる。
0823デフォルトの名無しさん2012/04/22(日) 15:19:45.29
>>820
オブジェクト指向的には0点だね。

それはオブジェクト指向ではないよ。
0824デフォルトの名無しさん2012/04/22(日) 15:22:56.58
>>820って型ごとにコレクション持つとか
言っていた馬鹿と同じやつじゃね?
同じ事やってるしw
0825デフォルトの名無しさん2012/04/22(日) 15:32:10.89
俺はホーミングミサイルの例でいくなら、毎ターン、ホーミングミサイル側で好き勝手やらせるんじゃなくて、
ホーミングオブジェクト作って、対象が移動したぞっていうイベントを通知するような感じでやるかな。
0826デフォルトの名無しさん2012/04/22(日) 15:41:07.88
型ごとにコレクションって当たり前だと思うんだけど。
どう考えても、ゲームクラスなどの管理クラスは、
アップキャスト発生前の一番情報量の多い状態で、
インスタンスを握っておきたいだろ。
オブジェクトがインターフェースを公開するなら、
そのインターフェースも毎々にコレクションだ。
それに加えて、用途ごとに分けたコレクションもする。
その方が検索が早かったり、そもそも実行のタイミングが異なってて、
同一リストで管理する意味がなかったりする場合などな。
でもそれ以前に型やインターフェースごとのコレクション無しでは、
多態すらおぼつかない。
仮に全ゲームオブジェクトを全てGameObjClassでコレクトして、
とりあえず毎フレームupdate呼ぶんで、あとは各自よろしく、では、
全ての変数がグローバル変数なのと変わらない。
だから、型やインターフェースごとのコレクションは最低限の常識では。
0827デフォルトの名無しさん2012/04/22(日) 15:44:14.41
> 型ごとにコレクションって当たり前だと思うんだけど。

そんな事すると、型が100個になれば
100のコレクションが出来る。

ムダでしかない。
メリットもない。
0828デフォルトの名無しさん2012/04/22(日) 15:45:10.96
>>826
どのゲーム本にそんな、常識が乗ってましたか?

素人が口出すなよ。
0829デフォルトの名無しさん2012/04/22(日) 15:49:49.28
> どう考えても、ゲームクラスなどの管理クラスは、
> アップキャスト発生前の一番情報量の多い状態で、
> インスタンスを握っておきたいだろ。
無い無いw

お前の設計がおかしいだけ。
ゲームの管理クラスは、すべてのオブジェクト
ベースクラスしか知る必要はない。

それ以外の情報を見たいってことは、
ゲームの管理クラスがすべてのオブジェクトのクラスに
依存しているということ。結合度が高くなってる。

型ごとのコレクションを持つということからも
結合度が高いと簡単に導き出せが。

これはオブジェクト指向というよりプログラム開発全般で
やってはならない事の一つ。
0830デフォルトの名無しさん2012/04/22(日) 15:54:50.11
> どう考えても、ゲームクラスなどの管理クラスは、
> アップキャスト発生前の一番情報量の多い状態で、
> インスタンスを握っておきたいだろ。

なぜそんなことをお前が思ったのかの答えもわかってる。

それはオブジェクト指向としてやってならないことを
お前がやってるから。
間違った使い方をした結果、間違った答えにたどり着いてる。

で何が間違っているかというと、お前がゲームクラスなどの管理クラスで
各オブジェクトのメソッドをそれぞれ違う引数で呼ぼうとしているから。

お前のゲームクラスは、アンチパターン(やってはいけないこと)で言う
神オブジェクトになってる。一つのクラスになんでも処理が詰め込まれてる。

最悪の最悪な設計。
0831デフォルトの名無しさん2012/04/22(日) 16:06:17.92
foreach (objA : objA_collection) {
    objA.update(x, y)
}
foreach (objB : objB_collection) {
    objB.update(x, y, z)
}


---------------------------------------
foreach (obj : obj_collection) {
    obj.update()
}

GameObjA::update() {
    (x, y) = gameMaster.get2dVector()
    ...
}
GameObjB::update() {
    (x, y, z) = gameMaster.get3dVector()
    ...
}

class GameMaster implements 2dVector, 3dVector, ... {
    ...
}
0832デフォルトの名無しさん2012/04/22(日) 16:07:42.43
結合度を下げることからもゲーム管理クラスは、
各クラスの詳細を知ってはいけないことは明らかだよな。
0833デフォルトの名無しさん2012/04/22(日) 16:12:54.71
生成だけして更新のタイミング等でupdateを呼び出すだけ
ぐらいまでいったらかなり簡単にできるんだろうな
と思いつつ毎回神クラス作ってる
0834デフォルトの名無しさん2012/04/22(日) 16:17:22.73
>>829
>ゲームの管理クラスは、すべてのオブジェクト
>ベースクラスしか知る必要はない。
ゲームオブジェ据え置きの固定的なupdateでの更新方式?
とりあえず、処理の実行順が問題にならない程度には、
型やインターフェースや用途ごとにコレクションを分けたほうが良いのでは?
引数固定で追加の情報は各自勝手に現地調達してねってのも、
むしろ逆行しててBASIC臭い。ゲームPGにはお似合いか。
でも、ゲームクラスはもうちょっと仕事した方が良いんじゃない?
定期的にキックするだけでは、あまりにも無能なのでは。

>ゲームの管理クラスがすべてのオブジェクトのクラスに
>依存しているということ
アプリケーションが個々のパーツに依存するのは当たり前だと思うがね。
パーツを集めてきて、機能するようにしたのが、アプリケーションなんだから。
プラグインのような形式なら別だが。ゲームはそういう類じゃないし。
0835デフォルトの名無しさん2012/04/22(日) 16:27:59.71
>>830
>神オブジェクト
神オブジェクトを分割すれば良い。例えばゲームなら、
・描画エンジン
・サウンドエンジン
・当たり判定エンジン
などなど。
纏まった機能ごとに分けるのがポイントだな。
というのも、機能はオブジェクト同士の相互作用によって齎されるけど、
相互作用や関わり合いってのは非常に危険な要素なわけだ。
だから、機能単位で纏め上げる訳だ。
オブジェクトがどうこう、ってよりは、相互作用を管理したいんだよ。
0836デフォルトの名無しさん2012/04/22(日) 17:03:44.01
>>834
なんでもあらわすベースクラスだから逆になんにもできないベースクラスでもある
つまり意味ないんだよw
タスクシステムといっしょ
なんにもできない管理クラスw
0837デフォルトの名無しさん2012/04/22(日) 18:02:57.43
オブジェクト指向の一番の弊害は
お前らのようなオレオレ・オブジェクト恥垢厨が涌くことだな。

オレオレオブジェクト指向は後のメンテで苦労する。
0838デフォルトの名無しさん2012/04/22(日) 18:21:41.47
メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください。

ワロタwww
0839デフォルトの名無しさん2012/04/22(日) 19:53:46.91
やっぱりミサイルとホーミングミサイルを
綺麗に実装したオブジェクト指向と多態はすごいと思うよ。
0840デフォルトの名無しさん2012/04/22(日) 19:56:46.97
>>836
なにいってんのお前?
何も出来ないんじゃなくて、
管理だけをする管理オブジェクトなんだよ。

そりゃ管理以外のことは何も出来ないよ。
当たり前だろ、結合度を下げてるんだから
これが正しい
0841デフォルトの名無しさん2012/04/22(日) 19:57:24.65
>>834
> アプリケーションが個々のパーツに依存するのは当たり前だと思うがね。

あたりまえじゃないよ。
素人かよ。
0842デフォルトの名無しさん2012/04/22(日) 19:59:48.17
>>840
役に立つと思ってるのはお前だけってねw
0843デフォルトの名無しさん2012/04/22(日) 20:02:38.16
>>842
役に立たないと思ってるのはお前だけという意味か?w
0844デフォルトの名無しさん2012/04/22(日) 20:03:30.64
馬鹿は一つのクラスに
いろんな機能ものを詰め込むからなw

そしてこれがオブジェクト指向だ!
なんていう。

幼稚園児かw
0845デフォルトの名無しさん2012/04/22(日) 20:06:50.16
COM打ち麻雀ゲームがあったとして
プレイヤークラスがあって
派生したCOMプレイヤークラスがあって
そこにいるAIは

他家の捨て牌や点数みるのに
雀卓オブジェクトを参照するよ
0846デフォルトの名無しさん2012/04/22(日) 20:09:41.06
>>845
それで?

シューティングゲームじゃかなわないと思って
麻雀ゲームに話をすり替えようとしているのかい?

哀れだね。
0847デフォルトの名無しさん2012/04/22(日) 20:12:26.46
ミサイルとホーミングミサイルの多態は結局できなかったわけだな
オブジェクト指向厨はセミナー商法に騙されてしまった哀れな子羊だったのだ
0848デフォルトの名無しさん2012/04/22(日) 20:12:59.74
COMプレイヤーといっても、
いろんなAIがいる。

ここでも多態が使えますね。

AIによっては見る情報が違っているでしょう。
完全にランダムでゲームを進める。
なぜか知ることがい情報をする(ずるをする)
しかし、その違いを吸収することが可能。

さすが多態だ。
0849デフォルトの名無しさん2012/04/22(日) 20:13:29.31
>>847
必死すぎだろw
一体お前度のレスのことを言ってるんだ?
言えないだろ?それが答えだよ。
0850デフォルトの名無しさん2012/04/22(日) 20:14:25.48
>>849
なになに?
ミサイルとホーミングミサイルの多態はうまくできたの?
0851デフォルトの名無しさん2012/04/22(日) 20:15:43.12
何度目のループだよ
めんどくせーな
0852デフォルトの名無しさん2012/04/22(日) 20:17:04.21
特にスレも変わってないんだからアンカー書くだけだけど
そんなレスないからいいわけ考えるのが大変なんだよな
0853デフォルトの名無しさん2012/04/22(日) 20:18:07.37
>>850
うん。できた。

出来ないといっている奴の話を聞くと
単にそいつがオブジェクト指向わかってないだけじゃん
って結論になった。

その馬鹿は自分の意見を無理やり通そうと、
行き当たりばったりの案をだして、しまいには結合度を
高くしてソフトウェア開発の原則と正反対の
事を言って自滅したよ。

いわく。すべての型に依存した神オブジェクトを作れ!だとさw
0854デフォルトの名無しさん2012/04/22(日) 20:19:00.80
>>850
>>793
0855デフォルトの名無しさん2012/04/22(日) 20:21:25.58
索敵機能とデコイも入った?
なんか多態でやると簡単だって途中のレスで出てたけど?
0856デフォルトの名無しさん2012/04/22(日) 20:23:26.24
>>855
とっくに対応してる。

あ、あの馬鹿は間違った
やり方をして、デコイを引数に入れるとか
めちゃくちゃな事言っていたけどw
0857デフォルトの名無しさん2012/04/22(日) 20:24:05.10
素敵機能もデコイも
きちんと抽象化ができていれば
簡単に対応できた。
0858デフォルトの名無しさん2012/04/22(日) 20:33:29.75
人間魚雷はデコイに騙されないとか
ステルス機能付きの敵は索敵されないとか
でも新型レーダー搭載ミサイルならステルス機能付きの敵を発見できる
しかし新型ステルスな敵は索敵されない
でもしかし最新型レーダーv2搭載ミサイルはそんな敵も索敵できるが
やっぱり超ステルス搭載な敵は索敵されない

以下無限に仕様が拡大していきますが、貴方の多態は大丈夫ですか?
0859デフォルトの名無しさん2012/04/22(日) 20:34:52.51
>>858
はい。

そんなのをいちいち考える必要を無くすのが
多態です。

逆に言えばそんなものに対応するのは
難しいと考えてる時点で、
あ、わかってないこいつwって言われる原因です。
0860デフォルトの名無しさん2012/04/22(日) 20:38:06.44
>>858のような仕様全てに対応した
神オブジェクトを作ろうとするから破綻するんだよねw
0861デフォルトの名無しさん2012/04/22(日) 20:38:48.01
これをすべてupdate()で実現するってすごいなぁ(馬鹿じゃねw)
0862デフォルトの名無しさん2012/04/22(日) 20:41:06.80
>>861
じゃあお前は何で実現するんだい(ほら、答えてみろwっw)
0863デフォルトの名無しさん2012/04/22(日) 20:42:51.14
>>861
updateといっても神オブジェクトではなく
各クラスのそれぞれのupdateなのだから
何の問題もない。

コードはあるべき場所に正しく置くことができる。

もちろんupdateから、ゲーム管理システムを
読み出すことも可能なので、
お前が考えるような、変なことは起きない。
0864デフォルトの名無しさん2012/04/22(日) 20:45:04.59
複数のミサイルがフォーメーションを組むだの、
隊長ミサイルが破壊されたらすぐに別のミサイルが隊長になって先導するだの
敵の迎撃や障害物を回避する機能があるだの、敵の弱点を分析してそこを狙うだの
ミサイルが一つ迎撃されるたびにHDDのエロ画像が一つ消去されるだの。

そんな多彩な可能性を可能なままにするために、
どれだけの機能と権限が末端のオブジェクトからリクエスト可能な状態にされるというのか。
0865デフォルトの名無しさん2012/04/22(日) 20:49:45.08
> 複数のミサイルがフォーメーションを組むだの、

複数のミサイルを集約した
フォーメーションオブジェクトを作ればいいだけ。

この場合、ミサイルがゲーム管理クラスに直接登録されるのではなく
ミサイルはフォーメーションオブジェクトに登録され、
そのフォーメーションオブジェクトがゲーム管理クラスに登録される。

こんなこともすぐに思いつかない? 本当に素人だなw
0866デフォルトの名無しさん2012/04/22(日) 20:50:52.99
そりゃ、いつも神オブジェクトしている奴には
難しいだろうさw
0867デフォルトの名無しさん2012/04/22(日) 20:54:01.50
なんで作っちゃうんですかね?>神クラス
多態を実現するために一箇所にまとめたグローバルインスタンスホルダーがどうしてもほしくなっちゃうんですかね?
引数同一にしたいから?(もう設計歪んでるだろw)
0868デフォルトの名無しさん2012/04/22(日) 20:55:42.28
>>865
あるミサイルが複数のフォーメーションに所属していた場合はどうすんだとか。
0869デフォルトの名無しさん2012/04/22(日) 21:02:06.06
>>848
例えば、10種類のAIがあって、それぞれ処理に必要としている情報が違うのなら、
呼び出し時にゲームクラスから明示的に処理に必要な情報だけを渡してあげたほうが、より安全だ。
無理にインターフェースを統一したために、処理に必要な情報が引数で渡らず、追加情報を得るために、
ぞれぞれのAIが勝手気ままに雀卓にアクセスするのなら、
それは、グローバル変数全盛期のBASICまで逆戻りだ。
そもそも、AI処理に必要な情報を、ゲームクラスが集めて渡すか、AIが各自で集めるか、の差でしかない。
前者と後者でコードの量は同等。処理に必要な情報が違った時点で、
多態でコードの量は減らない。なぜならAIが自力で情報を得るためのコードが追加されるから。
なら、前者の方が、情報の受け渡し箇所が集約されていて、管理のしやすさで分がある。

>しかし、その違いを吸収することが可能。
多態は引数リストが同じ場合のみしか吸収する力はない。
麻雀の例では、多態の為に引数リストを揃えたつけを、
雀卓参照というグローバル変数的発想で補っているに過ぎない。
だから、君の主張していることは、多態は便利、ではなくて、グローバル変数は便利、だ。
0870デフォルトの名無しさん2012/04/22(日) 21:06:22.36
フォーメーション機能語りたいならアクションゲームの敵想定のがいいな

個別のオブジェクトのAIとチームのAIと
起こした行動に対する結果or現在の状況からチームAIの次の行動の方針決定
→個別のオブジェクトのAIの行動決定までの流れがうまく動けばうれしいね
0871デフォルトの名無しさん2012/04/22(日) 21:09:02.34
>>868
OO以外ではどうやって解決してんの?
自分がどうやって解決してるのか書いてくれなきゃフェアじゃないよ

多態よりマシな解決法があるんでしょ?
0872デフォルトの名無しさん2012/04/22(日) 21:10:25.40
>>871
簡単だよ。
そんなクソめんどくさい仕様思いついた奴を蹴飛ばして
仕様を撤回させるんだ。
0873デフォルトの名無しさん2012/04/22(日) 21:12:07.87
じゃあ俺もお前を蹴飛ばして仕様を撤回させるわw
0874デフォルトの名無しさん2012/04/22(日) 21:14:57.72
OOならもしやと思って期待していたんだが、がっかりだな。
0875デフォルトの名無しさん2012/04/22(日) 21:19:08.94
OOだって銀の弾丸じゃないんだからひたすら後付されたら
いつかは対応できなくなるに決まってんじゃん
0876デフォルトの名無しさん2012/04/22(日) 21:20:18.91
いいや、ミサイルとホーミングミサイル(ミサイル+ターゲット)の時点でもう無理が出てたよ
0877デフォルトの名無しさん2012/04/22(日) 21:22:30.06
どこに無理が出てるのか具体的に説明してね
0878デフォルトの名無しさん2012/04/22(日) 21:23:36.82
commandパターン見習えよ・・

なんでもかんでも引数しようとすんなよ
0879デフォルトの名無しさん2012/04/22(日) 21:24:02.83
グローバルに追い出したり神クラスを作ってその場凌ぎを繰り返しているうちにカオスになっていくのさ
かといって1から書き直すというのも碌な結果にならないという・・・
0880デフォルトの名無しさん2012/04/22(日) 21:28:28.66
そういう設計になってるレスがどこにあるの?
同じスレだしアンカー書くだけだよね?
0881デフォルトの名無しさん2012/04/22(日) 21:33:34.53
たぶん、この流れ
例のオブジェクト指向否定野郎には
苦しい流れだろうw
0882デフォルトの名無しさん2012/04/22(日) 22:10:38.77
結局、多態なんて役たってなくてグローバル変数使ってただけってことでしょ?
満足した?
0883デフォルトの名無しさん2012/04/22(日) 22:11:22.21
C/C++のvoid*のがいくらかましだったな
0884デフォルトの名無しさん2012/04/22(日) 22:22:32.71
>>882
そういう設計になってるレスがどこにあるの?
同じスレだしアンカー書くだけだよね?
0885デフォルトの名無しさん2012/04/22(日) 22:27:15.45
>>869
グローバル変数の問題点とは何か、が全く解ってないな
0886デフォルトの名無しさん2012/04/22(日) 22:44:05.99
オブジェクト指向はグローバル変数に
Singletonパターンなんて別名を与えるくらい
グローバル変数大好き
0887デフォルトの名無しさん2012/04/22(日) 22:49:04.72
意外と流れが速いから今のうちに言っとくけど
似たようなスレがあるから次スレは立てずにこっちに移動してね

オブジェクト指向は本当に正しいのか?
http://toro.2ch.net/test/read.cgi/tech/1331443855/
0888デフォルトの名無しさん2012/04/22(日) 22:59:14.35
>>886
いや、だからぁw

お前はオブジェクト指向知らないのよね。
だからお前が叩いているのはオブジェクト指向じゃないわけよ。

お前が考えてる変なものを
お前が勝手にごちゃごちゃいってるだけ。
0889デフォルトの名無しさん2012/04/22(日) 23:27:14.34
>>886
その発言は、流石にあきれるぞww

つうか釣られすぎだな
0890デフォルトの名無しさん2012/04/23(月) 00:15:00.95
>>889
そーゆー発言はミサイルとホーミングミサイルを多態でうまくまとめてみせてからしてよ
だっせ
0891デフォルトの名無しさん2012/04/23(月) 00:17:53.01
引数ボーイの暴れっぷりはすごいな。
0892デフォルトの名無しさん2012/04/23(月) 00:23:11.10
ヌルいレベルで返すと強めな反撃を受ける辺りが話し相手として調度いいんだろうと予想
0893デフォルトの名無しさん2012/04/23(月) 00:24:50.46
関数引数の狭いスコープじゃ僕ちんプログラム組めないから
神オブジェクトの参照をメンバ変数に持っておいて
任意の情報に自由にアクセスするよ
0894デフォルトの名無しさん2012/04/23(月) 01:23:26.94
「そもそも」で検索すると、このスレは20レス検出される。
0895デフォルトの名無しさん2012/04/23(月) 01:30:55.24
チーム機残数3と4でフォーメーションが違うっていうなら
フォーメーション指示クラスが必要だな
チーム内番号に応じてリーダー機に対する相対位置を返す
ゲームじゃ味方同士にはコリジョンないから楽なもんだな

誰がリーダーで誰が何番かはチーム情報全部渡して
フォーメーション指示クラスに決めてもらおうか

指示クラスは誰が持つべきか、
どうやってチーム機がアクセスするか
爆散したときのnotify、

まあお金払ってくれるなら考えてもいいよ
0896デフォルトの名無しさん2012/04/23(月) 01:38:58.03
もし地形情報その他移送の際にワールド情報を参照したいなら
Updateのときにまるっと渡してやればいい

ゲームオブジェクトが参照もたなくていいのかって? グローバルが必要じゃないかって?
だって、ゲームオブジェクトはUpdate以外呼び出さないじゃん

ありもしない状況のときを考えてシステムをめちゃくちゃにする
こんな人間が居たら毎日デスマーチだろうな
0897デフォルトの名無しさん2012/04/23(月) 01:43:29.06
解読求む
0898デフォルトの名無しさん2012/04/23(月) 07:30:51.60
初期の設計段階では考慮されてない要件が後になって降ってくる
というあるあるネタ
0899デフォルトの名無しさん2012/04/23(月) 09:47:40.65
>>869
プレイヤーが作ったAI同士の対戦させたいときには、
プレイヤーにゲームコードを書き換えさせるの?
0900デフォルトの名無しさん2012/04/23(月) 09:57:13.01
PG○ま
0901デフォルトの名無しさん2012/04/23(月) 10:18:32.35
なんで自分だけ天才ってことにしたいんだろうな
0902デフォルトの名無しさん2012/04/23(月) 10:23:38.28
負けを認める勇気
0903デフォルトの名無しさん2012/04/23(月) 11:44:02.79
インターフェース変えると呼び出し側も変更が必要になること、変更すればするほどバグ発生の可能性が増えることにいつになったら気付くんだ?
0904デフォルトの名無しさん2012/04/23(月) 16:17:25.06
>>1を一部引用

OOPを十分に理解してないから痛々しい
0905デフォルトの名無しさん2012/04/23(月) 20:46:44.61
>>898
たしかにそれはあるが、それにしても基本的なところで困り過ぎ。
コードを抽象化してないせいだね。

たとえばゲーム管理クラスにミサイル専用のコードが含まれている。
つまりミサイルオブジェクトにミサイルオブジェクト専用の
引数を渡して呼び出すなんてコードを書くから困るんだよ。

新しいオブジェクトができたら、ゲーム管理クラスが新しいオブジェクトに対応した
コードを書く必要がある。こんなのやってたら破綻するのは目に見えてる。

呼び出し方を逆にして、新しいオブジェクトを作ったら、そのオブジェクトから
ゲーム管理クラスが持っている情報を引き出すようにすれば、大幅に拡張性が上がる。

ゲーム管理クラスは何もせずに、新しいオブジェクトに対応したということは、
無限のオブジェクトに対応してるということ。あとは追加したいオブジェクトだけを作ればいい。
0906デフォルトの名無しさん2012/04/23(月) 20:48:24.13
まあようするに、抽象化、継承、多態、カプセル化
これらが重要ってこと。当たり前か。
0907デフォルトの名無しさん2012/04/23(月) 20:50:53.16
純粋オブジェクト指向論者や定義厨が出てくると話がややこしくなるけど

実用的には
>抽象化、継承、多態、カプセル化
これで十分だよね
0908デフォルトの名無しさん2012/04/23(月) 20:52:13.45
下手の考え休むに似たり

あの場合はどうするんだ? この場合はどうするんだ?って
言っている奴ほど馬鹿ってことかな。

そんなのを考える必要がある設計がそもそもおかしい。
0909デフォルトの名無しさん2012/04/23(月) 21:07:48.71
何も考えて無いと仕様変更した奴を蹴飛ばして撤回させるタイミングを外します。
0910デフォルトの名無しさん2012/04/23(月) 21:11:03.42
解読求む
0911デフォルトの名無しさん2012/04/23(月) 21:16:24.74
安易に思いつきで仕様変更提案してくる奴を
その場で蹴飛ばして「んなもんやってられっかボケェっ!!」ってやるためには
あらかじめ出来ることとめんどくさいことを整理しておく必要があると思うのです。
0912デフォルトの名無しさん2012/04/23(月) 21:16:52.73
荒らしたいだけ
0913デフォルトの名無しさん2012/04/23(月) 21:17:45.21
何にでも対応できる設計をしてる気になってると、
上司や同僚やクライアントの安易な思いつきに安易に「OK」出してしまいがちですが、
いざやってみて消耗して「やっぱりダメでした」ってやるのはもうイヤダ。
0914デフォルトの名無しさん2012/04/23(月) 21:19:23.95
単にコミュニケーション能力不足なだけじゃないかw

何にでも対応できる設計にしておくのは当たり前で
その上で答えを出すのはちゃんと検証してからだろ。
0915デフォルトの名無しさん2012/04/23(月) 21:19:54.81
なんでも出来ませんって言ってれば
仕事なくなる。
0916デフォルトの名無しさん2012/04/23(月) 21:36:29.11
つか、普通はできなっていうのはNGで
それをするためにはどれだけ時間がかかるとか
いうのが正解なんだが。


ま、デスマしてるとこには
無理な話だなw
0917デフォルトの名無しさん2012/04/23(月) 21:37:37.43
デスマしてんのは仕様変更してくる奴が悪い
俺の技術力に問題はない。
0918デフォルトの名無しさん2012/04/23(月) 21:41:13.63
自分が無いものねだりしてるだけってことに気付けないと悲惨
0919デフォルトの名無しさん2012/04/23(月) 21:43:21.73
仕様変更に愚痴言ってるのは
オブジェクト指向否定してたやつだったな。

まあ、そりゃそうだろうなw
0920デフォルトの名無しさん2012/04/23(月) 21:49:43.30
ここのスレ名見てみ、弊害だぜ
持ち上げてどうすんのよ
0921デフォルトの名無しさん2012/04/23(月) 22:44:58.13
>新しいオブジェクトができたら、ゲーム管理クラスが新しいオブジェクトに対応した
>コードを書く必要がある。こんなのやってたら破綻するのは目に見えてる。
メインプログラマを経由しないと、あたらしい事は出来ない。スバラシイ。

>呼び出し方を逆にして、新しいオブジェクトを作ったら、そのオブジェクトから
>ゲーム管理クラスが持っている情報を引き出すようにすれば、大幅に拡張性が上がる。
誰が何処で何を参照し更新しているか分かったもんじゃない。ゲロゲロ。
しかもその手のゲームって、実行順序がプライオリティー管理になってたりするから、よけいカオス。

>ゲーム管理クラスは何もせずに、新しいオブジェクトに対応したということは、
>無限のオブジェクトに対応してるということ。あとは追加したいオブジェクトだけを作ればいい。
バグの可能性も無限大www
制限こそ真の武器。OO/非OO関係なくね。
何でもできる は 何でも起きる。
本人は一生懸命カプセル化を進めたはずなのに、
実は何でも有りのアクセス不法地帯になってるって、かなり笑えるよね。
0922デフォルトの名無しさん2012/04/23(月) 23:33:59.91
ゲームは処理メインだから手続きの方が良いんじゃない
ぐらいの言い方なら可愛げがあるが、なぜそう嘲笑うように騙るのかねww
0923デフォルトの名無しさん2012/04/23(月) 23:49:48.03
>>921
>制限こそ真の武器
つまりその制限をどうやって管理するかって事じゃね?
>誰が何処で何を参照し
抽象化がしっかりしてないから誰がどこで何を参照し更新してるかビクビくしなきゃならない。
>メインプログラマを経由しないと
カプセル化はメインプログラマの生命をも守る様だなw
0924デフォルトの名無しさん2012/04/23(月) 23:51:30.96
ゲロゲロとかカオスとかいう単語使うから低く見られるのが解ってないんだろうな

頭悪い奴ほど、説得する時、感情が出る
0925デフォルトの名無しさん2012/04/24(火) 00:06:53.48
両者の主張が極論すぎてツッコミずらいよ
0926デフォルトの名無しさん2012/04/24(火) 00:19:52.40
各オブジェクトに余計な情報を開示しないとなると、
・通常のミサイルは敵情報を参照できない
・ホーミングミサイルは敵情報の一部を参照できる
こんな要件が出てくる。
多態を使ってミサイルを抽象化する場合、どうやって上の要件を満たすかを考えてみる。
・……

めんどくさいから敵の情報くらい通常のミサイルに渡してもいいやと思った。
0927デフォルトの名無しさん2012/04/24(火) 01:10:54.35
>>921 >>926
OOPを十分に理解してないから痛々しい
0928デフォルトの名無しさん2012/04/24(火) 01:44:58.42
各オブジェクトに余計な情報を開示しないとなると、
・通常のミサイルは敵情報を参照できない
・ホーミングミサイルは敵情報の一部を参照できる
こんな要件が出てくる。
多態を使ってミサイルを抽象化する場合、どうやって上の要件を満たすかを考えてみる。

・通常のミサイルは敵情報を参照できない
→敵情報を知っているオブジェクトに問い合わせない

・ホーミングミサイルは敵情報の一部を参照できる
→敵情報を知っているオブジェクトに問い合わせる

あ、できちゃったw
0929デフォルトの名無しさん2012/04/24(火) 01:47:17.31
>>928
> →敵情報を知っているオブジェクトに問い合わせない
可能だけどしない、は要件を満たしてない。不可能でなければ意味がない。
0930デフォルトの名無しさん2012/04/24(火) 01:52:41.43
>>929
この要件の理由は何ですか?
0931デフォルトの名無しさん2012/04/24(火) 01:55:43.89
何のためにそんなことがやりたいのかさっぱり。
工数使って拡張性を落とすだけだけど、
もしそんなことがやりたいのなら、
単にクラスに応じて、渡すオブジェクトを変えればいいだけ。

簡単w
0932デフォルトの名無しさん2012/04/24(火) 01:59:17.72
>>930
君はグローバル変数を使っていればよいよ。
0933デフォルトの名無しさん2012/04/24(火) 02:00:50.33
>>932
え? 今までの話の流れのどこにグローバル変数が出てくるの?
もしかしてグローバル変数の意味もわかってない?
0934デフォルトの名無しさん2012/04/24(火) 02:08:26.34
相手しない。
>>928 を皆に読んでもらえばよい。
0935デフォルトの名無しさん2012/04/24(火) 02:14:37.85
>>930
オブジェクトメソッドの影響範囲とオブジェクト間の関連を極力少なくすることで
オブジェクトを疎結合に保ち、テスト、デバッグ、調整を容易にすることを目指します。
0936デフォルトの名無しさん2012/04/24(火) 02:34:42.33
なら十分目的を達成していますね。
0937デフォルトの名無しさん2012/04/24(火) 02:40:15.66
>>935
相手するのやめたほうがよいよ。
0938デフォルトの名無しさん2012/04/24(火) 02:48:36.48
>>937
なぜ? オブジェクト指向理解してないからといって
それは失礼ではないかw
0939デフォルトの名無しさん2012/04/24(火) 02:48:57.24
多態も理解できない馬鹿は相手する価値ないw
0940デフォルトの名無しさん2012/04/24(火) 02:49:24.34
ですよねーw
0941デフォルトの名無しさん2012/04/24(火) 02:54:14.04
な、相手しなくて良かったろ。
0942デフォルトの名無しさん2012/04/24(火) 03:49:27.02
実際の所、オブジェクト指向の基礎なわけだ、
抽象化、継承、多態、カプセル化なんてのは。

その時点で躓いているやつは
素人と切り捨ててもいいレベル。

まあ、からかって遊んでやるよ。
ホーミングミサイルがスマートに実装できた。
素晴らしいねw
0943デフォルトの名無しさん2012/04/24(火) 03:57:21.52
ホーミングミサイルの話をすると
すぐに釣れるから面白いw
前から何度も釣ってそのたびにボコボコにしてる
0944デフォルトの名無しさん2012/04/24(火) 15:46:57.75
今日もお花畑は幸せそうだ
0945デフォルトの名無しさん2012/04/24(火) 19:58:56.41
Minecraftのmod作ってみたときは
>>905の「呼び出し方を逆に」という点の重要さを実感したな
そういう風に作られてる部分と、そうでない部分でmodの作り易さが違った
0946デフォルトの名無しさん2012/04/24(火) 21:01:54.09
Modやプラグインは後から拡張するものだからそういう作りになってる。
他にもウィンドウズのウィンドウ関数やWinMainなどなど。
これらの手法は呼び出し元コードの変更が不可能な場合にとられる。
逆に言えば・・・
0947デフォルトの名無しさん2012/04/24(火) 22:04:54.38
たいていのソフトウェアは、
「後から拡張するもの」だ。
0948デフォルトの名無しさん2012/04/24(火) 22:12:18.26
思い込み
0949デフォルトの名無しさん2012/04/24(火) 22:14:33.21
修正しないソフトウェアはないだろw
0950デフォルトの名無しさん2012/04/24(火) 22:23:42.86
946の「後から」ってのは、ビルド後、リリース後、再ビルドせずに、って意味だぞ。
0951デフォルトの名無しさん2012/04/24(火) 23:04:14.35
ていうか、関数引数って何であるの?

引数使わなかったら関数のシグニチャを一切変えなくても
幾らでも仕様変更できるし拡張もできる

使わなければ使わない程変更に強くなるじゃん
0952デフォルトの名無しさん2012/04/24(火) 23:17:46.23
>>951
巨大関数でなければ、全部main()よりは格段に変更に強いよ
誰かさんみたいに、仕様拡張に合わせて引数増やす…みたいなことやると
目も当てられない状態になるけど
0953デフォルトの名無しさん2012/04/25(水) 00:00:23.86
>>950
再ビルドしなくても使えるテクニックを
ビルドした場合に使わない理由はないですね。

追加分を除いてソースコードを修正しないですむということは
それだけテスト工数もバグも減らせるということです。
0954デフォルトの名無しさん2012/04/25(水) 00:01:17.53
ばかばっか
0955デフォルトの名無しさん2012/04/25(水) 00:03:09.04
デバッグの話がない議論はただの煽り合い
0956デフォルトの名無しさん2012/04/25(水) 00:12:29.85
スタックの深さとか抽象化による状態把握の困難さとか
0957デフォルトの名無しさん2012/04/25(水) 00:15:00.36
「抽象化による状態把握の困難さ」とは?
0958デフォルトの名無しさん2012/04/25(水) 00:20:23.50
カプセル化の話では?
0959デフォルトの名無しさん2012/04/25(水) 01:10:16.97
追加分を除いてソースコードを修正しないのが
そんなに素晴らしいことなら
グローバル変数も素晴らしいことになるんじゃないの?
修正いらないよグローバル変数使えば。
0960デフォルトの名無しさん2012/04/25(水) 01:15:24.98
>>959
ソースコードの修正と
グローバル変数には何の関連性もない。

とりあえずだ。お前は馬鹿。
0961デフォルトの名無しさん2012/04/25(水) 01:19:15.48
>>960
むしろお前が馬鹿なんじゃない?
自分が何言われてるか理解してない

OOP=正義、グローバル変数=悪って頭から信じてるだけ
理解できてない
0962デフォルトの名無しさん2012/04/25(水) 01:20:50.04
>>961
え? ほんとにわかってないの?

グローバル変数というのは、いわばバグに近い。
ソースコードの問題点は修正するのは当たり前の話。
0963デフォルトの名無しさん2012/04/25(水) 01:21:46.97
誰が問題点を放置しろといったよw

ソースコードを修正しないというのは、
機能追加する際の話しだろ。
0964デフォルトの名無しさん2012/04/25(水) 01:23:06.33
問題点なら修正するのは当たり前の話だし、
問題がないなら既存部分を修正しないで機能追加できるのが良い。
0965デフォルトの名無しさん2012/04/25(水) 01:24:21.87
> グローバル変数というのは、いわばバグに近い。

理由が無くいきなり結論になってますね
理解してないと、こういう発言になります
注意しましょう
0966デフォルトの名無しさん2012/04/25(水) 01:24:36.42
>>961
誰がグローバル変数=悪と言ったんですか?

あなたがそう思っているのですよね?
わかってるじゃないですかw
0967デフォルトの名無しさん2012/04/25(水) 01:26:22.81
>>965
理由があればいいんだよねw
0968デフォルトの名無しさん2012/04/25(水) 01:26:44.74
少なくともホーミングミサイルの例は
グローバル変数「でも」コードを変更しないで
追加するようにすることは出来る

だからってグローバル変数マンセーじゃねーぞ
0969デフォルトの名無しさん2012/04/25(水) 01:27:27.36
グローバル変数とスタティックおじさん
http://d.hatena.ne.jp/rabbit2go/20110703/1309692441
0970デフォルトの名無しさん2012/04/25(水) 01:28:15.25
>>968
ホーミングミサイルの話って、多態の話だよね?

グローバル変数がなんででてくるの?
0971デフォルトの名無しさん2012/04/25(水) 01:30:13.07
CでOOできない奴はC++でもできない
0972デフォルトの名無しさん2012/04/25(水) 01:33:08.96
>>970
メソッドのシグニチャを変更しないで
メソッドに情報を渡す方法のひとつだから
(ただし最も邪悪な)
0973デフォルトの名無しさん2012/04/25(水) 06:46:28.21
>>960,970
↑こういう直近の話もわからない馬鹿ってなんでPGに増えたの?
職場で「はぁ?それいちから説明しないとだめぇ?面倒臭ぇ」って奴多いんだけど?
0974デフォルトの名無しさん2012/04/25(水) 07:21:46.41
井の中の蛙大海を知らず
0975デフォルトの名無しさん2012/04/25(水) 07:23:05.20
文系PG増えたからなー
0976デフォルトの名無しさん2012/04/25(水) 07:32:35.10
オブジェクト指向の弊害
0977デフォルトの名無しさん2012/04/25(水) 07:34:18.27
>>959 >>973
近視眼的な極論言い出すお前の方がバカだと思いました
0978デフォルトの名無しさん2012/04/25(水) 07:58:57.31
>>973
もともと適正の無い人間をPGにしようとするから

この手の馬鹿は理屈抜きで教えられた事信じるから
適当に教育してどーでも良い単純作業をさせるに限る
0979デフォルトの名無しさん2012/04/25(水) 09:04:02.81
>>973
読んでほしければ、3行でまとめろ。
0980デフォルトの名無しさん2012/04/25(水) 10:14:50.12
弊害? ちょっとOOをかじり出すとオタク気取りになる事か?
今時、弊害はあってもやらざるを得ないだろ。
0981デフォルトの名無しさん2012/04/25(水) 10:25:33.56
俺はOOP大好きだと思ってたし、OOPLにも敬意を払う。
OOPL無しにOOP出来る、なんて気安く言う輩にはOOPの目的は楽をすることだと言いたい。
非OOPLでOOPしようとすることで、ちゃんと手間に見合う結果を得られるのかと問い詰めたい。

話が逸れたが、今となってはOOPピンとこない。
OOPがどうの、という以前に、構造化であったり、
モジュール性であったりという古くからある観点、
それの偉大さのほうがウェイト大きいと思ってる。
0982デフォルトの名無しさん2012/04/25(水) 10:39:09.47
怠惰の為の勤勉
0983デフォルトの名無しさん2012/04/25(水) 10:47:18.88
所詮0と1しか理解出来ないコンピュータ
コンピュータ相手に人間世界を構築しようとしてオブジェクト指向が出てきた

当たり前の話、現実世界は複雑
複雑なものを表現しようとしてんだから複雑になるのは当たり前だが

何を問題にしてコンピュータに仕事させるのかを考えたら普通にオブジェクト指向と構造化の使い訳は出来ると思うけど
0984デフォルトの名無しさん2012/04/25(水) 18:10:35.38
コンピュータに変わる物が出てこないのか
コンピュータブームだから
俺が生きてる頃には無理そうだが

0と1でよくもまあこんなに発展させられたなと、人間の頭脳にひれ伏すよ
0985デフォルトの名無しさん2012/04/25(水) 20:31:53.77
適当ばっかり言うよね。
0や1のビット列に意味を持たせてるのは、演算なのに。
0986デフォルトの名無しさん2012/04/25(水) 20:41:20.80
ゲートです
0987デフォルトの名無しさん2012/04/25(水) 21:05:57.36
>>972
> メソッドのシグニチャを変更しないで
> メソッドに情報を渡す方法のひとつだから
> (ただし最も邪悪な)

そうだよね。邪悪だよね。
その時点でグローバル変数は切り捨てで終わる話なのにね。

0988デフォルトの名無しさん2012/04/25(水) 21:13:21.28
替わりにシングルトンですね、分かります。
0989デフォルトの名無しさん2012/04/25(水) 21:15:59.01
>>988
シングルトンをグローバル変数の代わりに使おうという発想は、
オブジェクト指向を理解してない証拠ですよ。
0990デフォルトの名無しさん2012/04/25(水) 21:31:02.46
>>987
でも>>960みたいなバカは
なんで邪悪なのか理解できてないけどね
0991デフォルトの名無しさん2012/04/25(水) 21:36:03.17
>>990
よっぽど悔しかったんですか?w
0992デフォルトの名無しさん2012/04/25(水) 21:45:02.15
平たく言えばオブジェクト指向は多態を手軽にするぐらいしか能が無いから、
実際には、>>981 が正しいね。
0993デフォルトの名無しさん2012/04/25(水) 21:55:31.14
>>992
はい、オブジェクト指向を理解してない人は
あなたのような発言をよくします。

ぶっちゃけありきたりの感想ですね。
0994デフォルトの名無しさん2012/04/25(水) 21:56:53.90
>>993
間違いなくお前がこのスレで一番アホなのに
なんで上から目線なの?
0995デフォルトの名無しさん2012/04/25(水) 22:02:31.50
念のため

>>887
0996デフォルトの名無しさん2012/04/25(水) 22:02:32.62
>>994
あなたの発言は、下から目線ですねw
0997デフォルトの名無しさん2012/04/25(水) 22:30:25.81
見積もりを工数でしっかりと出さなければならない仕事をやってはじめて
オブジェクト指向なんて無意味なものだと理解する

単純に、オブジェクト指向を適用したプロジェクトとそうでないプロジェクト
まったく同じ仕様を満たすものを作成するとしたらいくつ工数は変わるの?

って気軽に「〜ぐらいじゃないっすかねぇ・・・」なんて答えられる現場と
ちゃんと1Hまで根拠を求められる現場とでぬるさが違う

ヌルイ現場にいる奴に考えてほしいが
いま、てめぇがやってる仕事は非オブジェクト指向でやったときに
どのくらいの工数が増えるのか?それがちゃんと上司に報告できる形で仕事をしているか?

1つ1つきちんと積み上げていかんとなんも作れないPGになってしまうで
趣味でアプリを完成させられない人間とかじつは1人でプログラムを完成させる実力がなかった・・・って場合あるぜ
まず、なにやるにも見積もり・・・これが出せるPGとそうでないPGだんだん差が開いていくで
0998デフォルトの名無しさん2012/04/25(水) 22:33:10.11
なーーーんでもおもいこみで
てーーーきとうに組んでるだけじゃ
いつまでたっても答えにたどり着けない

その思考回路のまま何年もPGを続けていってしまうと
過ぎてった年数分の実力を穴埋めするのは不可能になるぜ

その第一歩としてオブジェクト指向の否定があると思う
こいつをおかしいと思わないと・・・
0999デフォルトの名無しさん2012/04/25(水) 22:34:44.91
何年PGをやってても1人でなんにも作れない
そんな奴実は多いんだよね
1000デフォルトの名無しさん2012/04/25(水) 22:37:37.60
以上、自己紹介でした
10011001Over 1000Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。