オブジェクト指向の弊害

非OOPでコーディングされたソースを見て発狂するアホを生み出したこと
そのくせOOPを十分に理解してないから痛々しい

と天才プログラマー「あい」は申しております。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

高級言語の普及によって、プログラムの自己書き換えが廃れたように、
実際、「オブジェクト指向」という制限が掛かることによって
実装できなくなったプログラミングイディオムってあるよね。

「闇のデザインパターン」とでも言えばよいのだろうか。
誰か、そういうのをまとめてくれないかな。
出版してくれたら、絶対に買うよ。

>>4
アンチパターンですね。

>>5
アンチパターンは、元々やるべきではないもの。
これは、役に立つけど、諸般の事情で使えなくなったもの。

OOPは保守性が高い

>>6
アンチパターンだから使えなくなったのです。

>>7 きちんとクラスが設計されていれば・・・な

Object Prototype Programming Architect Interface

OOPでよく使われる文法は非OO的機能という現実

Bjarne Stroustrup インタビュー (？)
ttp://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

アルゴリズム本のページ数が伸びる。
もしくはCで学ばなくてはならない。

>>12
外人のネタコピペも結構レベル高くなってきたな

>更新：1999-08-03

通知を受けるためクラスがあって、そのクラスのインスタンスが
どっかのオブジェクトのメソッドを実行するための何かとか
もう意味不明ｗ

弊害を語るならせめてパターンくらいは身につけろや

OO系のスレは他にもあるのにワザワザ新しいのを立てたんだから
>>1は責任もってネタを出すように

まさかあれで終わりということはあるまいな

>>16
そうだな
ＯＯになびく奴は昔から頭がちょっと弱めが多い

さあ、釣りだ！

>>19
ネタが尽きたら自問自答は定番だよな

PHPを非オブジェクト指向でプログラミングする
それがあるべき理想の姿だな

>>17
パターンは糞。まだ分からんのか。

ほら、これが釣りですよｗ

Singletonパターンは百害あって一利なし

パターンが糞っていうか、パターンを身につけないと
糞コード化しやすいところが駄目だわ。

>>25
そのように、パターン名に名前がついてるってのは
すごく重要だよな。

もしSingletonパターンという名前が存在しなかったら、
>>25の書き込みを正確に書くことはできるだろうか？

>>27
洗脳されやすいタイプだなｗ
パターンなんてのが出てくること自体原始的状態だってことだよ。
たらたらとアドホックに追加するだけだろ。１０年たったら全部消えてるよ。

>>28
じゃあ10年後にまたおいでｗ

Singletonパターンの正当な批判・擁護がなされていないのが問題

システムの大半は、データと操作を分離した従来の構造化プログラミングで十分。
オブジェクト指向は動的なポリモーフィズムが必要な一部に局所化して利用するくらいがちょうどいい。

馬鹿がパズルを生成するだけ

馬鹿が作ったパズルくらい解けるようにしとけよ

>>4
手続き型の範囲ではないんじゃない？手続き型プログラムは、クラスをがひとつだけのプログラムか、
staticメソッドだけのプログラムと同じなはずだから。

もちろんアセンブラ的なことは考慮しない。

馬鹿のパズルは論理破綻してるから解けるわけがない

オブジェクト指向プログラミングは間違いだったか?
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

所謂オブジェクト指向言語はオブジェクト指向してないんじゃないかというなにか
http://d.hatena.ne.jp/Flast/20111206/1323152264

>>34
「・・・ないんじゃない？」って、
「オブジェクト指向言語でも実装できるよ」って意味？
そりゃ当たり前。チューリング等価なんだから。

でもそれは、アンチパターンでいうところの
「抽象化の逆転(Abstraction inversion)」になるね。

闇のデザインパターン()笑は例えばどんなのがあるの？

>>37
うーん、オブジェクト指向の機能を使って(メッセージ送信とか)を使って、
手続き型と同じことをしようとするなら、その「抽象化の逆転」になるだろうけど、
大半のオブジェクト指向言語は、オブジェクト指向の機能を使わなければ
手続き型言語そのものになるからなんとも。

手続き型の範囲に限定したのはそのため。
関数プログラミングだってメソッドひとつのイミュータブルな
オブジェクトを使えば大体同じことができるけど、それはたぶん
「抽象化の逆転」になるんでしょう。

Delphi好きだよDelphi

ooどころか構造化されてるかどうかさえ怪しいHSPだって
一応プログラムは作れる、ooに拘泥するアホはHSP厨以下

などということを本気で言ってるやつを見てニヤニヤするスレです

昔は大きなものも小さなものも C で書いていたが
オブジェクト指向言語は小さなものを作るのに向かないので
今は大きなものを作る言語と小さなものを作る言語
最低 2 つの言語を使えないとプログラマとして使い物にならなくなった

C++ でやればいいんじゃね？

>>38
んー・・・
例を挙げると、lisp や JavaScript の実装で使われている
ポインタへのエンコーディングとか、どう？

あれって、何かそれらしい名前がついていたような気がするのだが、
思い出せない・・・

オブジェクト指向の体現度って↓であってる？

C#＞Java＞＞C++

他の候補：F#、Python、Ruby、Scala

>>46
c++は規格のライブラリが貧弱なだけで、抽象度はライブラリによる

vclは優秀だった。。。
最適化でvcに負けたけど。。。
(mfcには負けてない)

vclはPascalって所が欠点だった。
C++のコードデバッグで辿って行ったら途中でPascalになるんだぜ。
あ、Pascalじゃなかった。Delphiという独自拡張された言語。
気持ち悪いったらありゃしない。

>>46
多分、体現度はsmalltalkが一番
その分、仮装OS的なものが必須だし、>>36の上のurl通り、全体をデバッグしてるんだが。。。

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

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

Erlangの中の人がデータと手続きは別のものだ。一緒にするべきじゃない！と言ってたり
(日経ソフトウェア2009年6月号だったと思うけど、matzと結城さんの対談の記事で書いてた)

> Erlangの中の人がデータと手続きは別のものだ。一緒にするべきじゃない！

賛成だね。

データの寿命は長いが、手続きの寿命は小さい。
データベースなんか、データ専用じゃないか。

個人的にはオブジェクト指向言語の生産性はライブラリとジェネリックが肝な気がする
Cでもライブラリ充実させて、ジェネリック(C++ではテンプレート)をサポートすれば、生産性はオブジェクト指向言語と変わらんのじゃ無いか？と言う疑惑は持ってる
(疑惑だけで確証は無いんだが)

OOPLでも手続きの部分はALGOL流のままだ。
smalltalkのように制御構造までオブジェクトという程まで
徹底されてないから手続き型っぽさが抜けない。

>>49
fortlan2003ではオブジェクト指向が導入されたらしい

ずっと気になっているんだが、fortlanじゃなくてfortranじゃね？

>>54
マ板内検索したら、確かにＦｏｒｔｒａｎだなｗ
フォーミュラ何とかランゲッジって覚えてから、lanだと思ったんだが、違ったｗ

あ、マじゃなくてム板だった

お前ら相変わらず机上の空論ばっかだな

というか、ＯＯもパターンももう終わるし

と言い続けてはや10年。

自分のほうが、この業界から去ってしまいましたとさ。

>>57
オブジェクト指向プログラミングはともかく、オブジェクト指向設計とか、何やねん。って思うよな
クラスベースより、プロトタイプベースの方が再利用できてるじゃねえか。みたいな
クロージャの方が、継承よりも再利用に適してんじゃねぇか。みたいな

どんだけ時間の無駄だったのかと

アスペクト指向ってどうなったの？

プロトタイプベースで再利用ってあまり聞かないな
何の話してるの？

>>1
あるある
んで、決まってOOP以外はソースがダメだダメだみたいな

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

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

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

だって、関数っつったらプログラミングの最小単位だからな･･･？ｗｗｗｗｗｗｗｗｗ

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

かなりマジレスしてみた

いろいろ残念な人のようだ

最小単位が関数型？

>>61
どうもなるはずないよ。
ＯＯＰ、デザパタ、ＡＯＰなどなど、ほんとソフトウェア工学は他で使えない頭の弱い連中が
やりちらかしてきた歴史だな。そろそろ仕分けしろよ。

ほらみて。これが釣りだよ。

ほんとだ、>>67 がきっちり釣れてるね。

oopやデザパタのメリットは低能でも分かった気になる事
関数型ではこうはいかない

>>69
関数型言語の場合、まんま数学で言う特殊から一般へ。と言う手法が使えるから楽だよな

>>70
なるほど。特殊から一般だな。分かった気になったぞｗ

関数型って要するにSQLみたいなもんだろ、大丈夫、わかるわかる

副問合せが理解できれば関数型も理解できるって寸法か
これで俺もいつ関数型言語の仕事がきても大丈夫だな

ポリュモルピスムス（笑）

モジュラー指向プログラムとオブジェクト指向プログラムの違いがわからん。
とりわけFortranの場合、90でモジュールが導入されて、モジュールの中に
手続きが書けるようになったが、さらに2003で構造体の中にも手続きが
書けるようになった。2通りの手続きを束ねる手段があって、冗長に思える。

>>75
過去のやり方を無かったことにはできないから互換性のために残してんじゃないの。

fortranさわったことないけど
演算子オーバーロードできるなら
オブジェクト指向の使い道はあると思う

>>77
javaは使い道ありませんかそうですか

>>77
　あるよ。さらに利用者定義中置演算子が定義です。ただし、これは2003の
オブジェクト指向の上に載っているのではない。Fortranには伝統的に
「総称名」という概念があって、cos(x)と書くと、xが単精度であれば、
cos(x)[字面が同じで紛らわしいが別のもの]、倍精度であればdcos(x)に
コンパイル時にディスパッチする。
　95これを利用者定義型できる。具体的には、それぞれの型ごとに
同じ形式を持つ手続きをそれぞれ定義して、これらにひとつの総称名を
割り当てるという形をとる。このとき、総称名の代わりに演算子を
割り当てることができる。
>>78
Javaが演算子再定義を持たないのは、これこれで言語仕様を簡潔に保つ
という上で適切な解だと思う。メソッド名が長いのはいとわず、英文で
説明するように処理を記述することを期待しているようなので、演算子
は削ってもいいだろう。

Javaはドカタ用言語なので、演算子オーバーローディングまで出来てしまったら
ドカタが混乱する。
出来ないのが正解。

>>80
演算子オーバーロードをなにか特殊なものだと思ってるの？

>>81
まともなプログラマなら思わないけど、ドカタは思うだろう

…と言う意味では

あぁ、自分でドカタ＝混乱する人と定義してるのかｗ

まあオブジェクト指向は最高ってことですねｗ

高慢と偏見（1）隣は何をする人ぞ
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html

ぼくのかんがえたすごいオーバーロードが蔓延るのはよくないと考えたからJavaには無いんだろ
どこかの「ぼくがしんかさせたすごい言語」状態のゴミになるのを避けるために

ぼくのかんがえたすごいフレームワークが蔓延るのは防げないのであった。

ぼくのかんがえたすごいメソッドと何が違うのかわかりませんｗ

オブジェクト指向の弊害は、バグが生じた理由を設計が悪かったの一言ですますこと。
単に力量不足、柔軟な機動力不足だろうと思ったり。
あと、設計に時間とって、ＵＭＬみたいなお絵かきを自慢げに出すようになったこと。
そんなの書くのに時間とるやつより、ちょっぱやな動作デモを即効作ってくるタイプと仕事してる方が楽しいのにな。

ダクトテーププログラマが役に立つのは同意だが
オブジェクト指向の弊害云々はオブジェクト指向以外にも当てはまるからいまいち

お絵かきはシステム構造図だとかDFDだとかフローチャートだとか
昔から沢山あるだろ。むしろ昔のほうが多かったぐらい。

> ちょっぱやな動作デモを即効作ってくるタイプ
「動いてるからいいじゃん」タイプか。
そういう奴に任せると、後で苦労するぞ。

判断基準が楽しいかどうかだしな
趣味なら別にいいが、仕事では相手にしたくないわ

デモはデモだろ

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

これが問題なんだ

再利用できるコードより、部分てきに切り貼りしたり、あるいは一から書き直しても早くできる人が役に立つでしょう。
他とのインターフェースだけオブジェクト指向とかできれいにしてりゃいいよ。
オブジェクト指向じゃないコードをバカにするわりには、面白いコードもかけない人の方が、
なんだかんだ理由をつけて進捗のボトルネックになることが多いよ。

なんというか、あくまで基礎がある上でのオブジェクト指向だな。
基礎がないのに、オブジェクト指向な人が多いから、混乱するだけど、OOが悪いわけじゃないな。

>>88
> ちょっぱやな動作デモを即効作ってくる
そが即効なのは「後で変更する人たちに工数を押し付けた」結果だったりするからな。
納期直前とかならそういうやり方もありだけど、普通はOOに限らず影響範囲が小さくて済むよう
それなりに設計するもんだ。

>>96
その言い方をするなら、即効で仕上げて、あとで変更する人たち余裕を与えたともいえる。
ある設計が変更に耐えられる確率を定量的にいえるなら設計に時間与えてもいいけど、
いえる人っていないでしょ。
設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。

>>97
> ある設計が変更に耐えられる確率を定量的にいえるなら
結合度とか凝集度がそれにあたるな。

> 設計に時間与えたのに、あとでバグが生じて、設計が悪かったとかいうのを何度かみたよ。
設計が甘かったために、ひとつのバグ修正が２つのバグを産むという例のほうが
よっぽど多いけどなｗ

一発で設計が上手くいくようなら、ウォータフォールでいいよね
OOPってアジャイルな開発には向いてないの？

>>97
どんな開発モデルでも、後工程に行けば行くほど修正コストは飛躍的に増大する。

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

そのような経験があるからといって、設計に時間を与えなくとも良いということには
ならないのはわかるよな。

ごくごく自然にに考えよう。

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

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

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

自分の担当工程だけやって、下流の内容は知らないじゃだめなんだよ。
プログラミングができないSEはクズと言うのは正しいということが分かる。

もっとひどいのになると絶対実現できない機能を仕様書に平然と書いてあるとかね。
基本的な素養がね。ないとダメなんだよね。

いまだにLOC以上の定量的手法ないだろ

ゲームプログラマーやってるとプログラムできないSEとか理解できない。
ゲームでの企画はあくまで雑用とアイデア出しで設計するのはプログラマー。

ゲーム業界での企画がSEって呼ばれてると思えばいい。

普通ぷろぐらまが経験を積んでＳＥになるんでないの？

大手は最初から上流設計しかやらせないらしい。金かけてクズを育ててるようなもんだが。

興味本位で「絶対実現できない機能」の例を聞いてみたい

２年ぐらいプログラム経験つませることも多いだろ
２年程度なら平均的なプログラマぐらいにはなれる

http://el.jibun.atmarkit.co.jp/pressenter/2011/06/3-1e5b.html

>>109
平均的なプログラマは
プログラミングをするべきだ。

とりあえずワードエクセルが使えて客と会話ができればSEとしての体裁は繕えるしな

平均的なプログラマってのは
クソな仕様書をつき返して問題箇所を指摘したり直させたりできるレベル？

>>108
レーザープリンタで感圧紙の複写印刷が出来ますと客先で宣言されたことがある。

>>84
>高慢と偏見（1）隣は何をする人ぞ
これ見ると反ＯＯ派をＫＯしたとＯＯ派は思うんだろな。
もうそろそろそんなレベルを超えろよ。
ＯＯでもまだシンドイだろ？

grepが効かない！

>>114
なにそれこわい

…プリンタのハード設計をしてるワケじゃないんだよな？
まあそれでもォィォィと思うが

.NETは入れたくない

>>114
プログラミング出来る出来ないは関係ないなｗ
そいつが根本的に馬鹿なだけだ

プログラム初心者なんだけど、Cで構造体にデータ入れてDBに登録みたいなことをOOP型言語でやろうとしたんよ。
データには大きくわけて社員と役員という二つのタイプがあって、社員のメンバ変数は役員ならば全て持っている場合、
アクセッサー含めて役員の方にも同じメンバ変数をコピーするのは保守性下がるからよくないと思ったから継承させたんよ。

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

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


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

じゃあ継承させずに同じメンバ変数を異なるクラスにコピーさせていかないといけないんか、とがっかりしたわ
何のための継承だったんかと

だからインターフェースを継承してインターフェースでインスタンスを受けとるんだと思ったんだが違ったっけ？

Objectに入れちゃったら台無しだろｗ

>>120
Object型に格納するのがダメなだけじゃんｗ

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

何かおかしいなら、それは自分が悪いと考える。
99％間違いないから。

VB系から来た人っぽいな

オブジェクト指向は、Object型指向ではないってことだな。

Object型が役職とか役員賞与額とかプロパティを持っていなかったのが敗因
どこの田舎ライブラリだよ

そもそもなんでObject型に格納しようとしたのか、意味不明。

void*　でやりとりするような感覚じゃね。

それがどうかしたか？

voidのような偏屈やろうは使えん

OOP is shit

>>125
でも、ドカタ指向なのかもしれない。

>>51
＞Cでもライブラリ充実させて、ジェネリック(C++ではテンプレート)をサポートすれば、生産性はオブジェクト指向言語と変わらんのじゃ無いか？
kwsk!

たとえば
qsort(void *, ....)
の void * のような型チェックなしの危険さを排除できるのでしょうか？

ｵﾌﾞｼﾞｪｸﾄ指向が全然ﾀﾞﾒって訳ではなくて
ｵﾌﾞｼﾞｪｸﾄ指向を盲信し、拡大解釈したり誤解していい加減なこと吹聴している椰子がｳｻﾞ医

筋外すやつが多いのは間違いないよね。
構造化みたいに対応言語使っときゃわかってなくてもある程度矯正されるレベルじゃない。

>>134
この２行、何も言っていない（例えば、全然ダメではないのは何についても言える事だ）。
盲信している奴が悪いのではなく、ＯＯ自体が盲信・誤解を誘うまやかしだったという
事が既に明白になっている。なぜはっきりそう言わぬ。

A ⊂ B の話しかしていないのに
勝手に A ⊃ B 前提の話をし始める >>136 みたいな香具師って
きっと馬鹿なんだろうな
文系板とかマ板ならそういうのをよく見かけるが
ム板で見かけるとは思わなかった

>>136
ﾓｼﾞｭﾗﾚｨﾃｨｰの向上などのために、センスと節操をもって使えばOOは役に立つことがあるから。
センスとか線引きが明確化できないものが基準だと使う人次第になるでしょ

こうぐしって何？

>>139
それはヤシと読むんだぜ、と釣られてみるテスト

香具師（やし）

香具師（ヤシ）
奴（ヤツ）

Twitter Facebook Tumblr などを自在に使い分ける時代に、2ch用語なんて時代遅れ。
オブジェクト指向言語なんてカテゴリーで考えようとすることも時代遅れ。

バカッター、フェイスバカ、手ブラ？

こんにちは世界
を書くのが大変になった

昔に書いたソースを、C++をオブジェクト指向を駆使してエレガントに書き直す作業が面白くてしょうがない。
ゲームより面白いから、ゲーム機をしばらくいじってないぐらいだ。
プログラミングって分かってくると面白いし、エレガントに書こうと思うと、いくらやってもきりがないよね。
再帰構造のクラスとか考えるのが凄い面白い。

トイレ入ってる時とか、布団かぶって寝ようとしてる時まで、
「あ、あそこはこう書けばもっと綺麗になるな」
とか思ったり、夢の中でも考えてたり、プログラミングって面白いよね。

でもそれってどの程度の工数の削減になるの？
って聞かれると答えられないんだよな

んで自分がやってたことが所詮子供のお遊びでしかなかったことを知って愕然とするんだ
ビジネスの場では常にコストを意識して仕事が出来る人間しか相手にされない
こんな数字にできないようなおばあちゃんの知恵袋はなんの価値もない

わかるひとにはわかる
みてるひとはみてる

はじめに工数と業務を全部だして
それに対してウィークポイントをはっきりさせて
それから対応しないとどうでもいい部分を削減してたり
問題になってない工数を縮小したり意味不明な行動ばっかりとるもんさ人間って

リファクタリングがビジネス的に利益にならないこと、かえってバグを生むことぐらいは分かってるさ。
俺は趣味のプログラミングの話をしているんだ。
いくらやってもきりがない美しさへの追求。

職人だな

それはそれでいいんじゃないかな。気持ちは、分かる。
スキルは付くし。

バグが出ちゃってる時点でリファクタリングじゃないけどな

目的を見定めないで思い込みで行動してる奴なんてプロじゃねぇ！

って日曜ＰＧと学生にえらそうに吠えるのが日課です

動作を変えずに構造を書き換えるのがリファクタリング

プロ意識の問題では無い

>>156
それはわかってるけどやってみたらバグっちゃうって話してんだろウンコ
お前の理解力は所詮ウンコ程度だってことだよ

お前が間抜けというだけの話じゃねえか

理解力がウンコでもなんとかできるようにするのがオブジェクト指向の真髄。

>>157
プログラミングもバグるよね？

バグるから何？

バグじゃねーよ
仕様だって言ってんだろ

>>160
プログラミングはバグんねーよ
プログラムはバグるけど

プログラマーはしょっちゅうバグるけどな。
納期すぎて怒られて徹夜させられて、会社来なくなったり。

業界がバグってる

>>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

>>148
いままでオブジェクト指向なんてやってこなかった人を使って、
いままでと同じようなシステム作るなら、
オブジェクト指向なしでやった方が手っ取り早いもんな。

【激突】関数型言語　VS　オブジェクト指向言語2

上記のスレと内容がかぶってる気がする

激突する相手が違うんだよ

>>133
c++でテンプレートとcの文法とライブラリのみで試せば良いじゃん

>>165
確信つきすぎてスレ止まっちまったじゃねーか

>>165
最初の書き込みが

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

これか。お前が書いたんだろうなｗ

これのどこに知性があるのだろうか？
理詰めで技術を検証するってことができないと困るぞ

オブジェクト指向orデザインパターンを使った場合とそうでない場合と
比べて何がメリットなのかどうかを検証する作業は一度はやるべき

>>172
何を今更ｗ

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

そこからも答えは明らかで、
メリットなんか、勉強すれば分かること。

>>173
＞（たとえ言語がCだったとしても考え方はオブジェクト指向）

え！

それはあなたのオブジェクトオリエンティドの定義がユニークなだけでは？
あなたの定義を記述してください。

>>174
オブジェクト指向（OO)
オブジェクト指向分析（OOA)
オブジェクト指向設計（OOD)
オブジェクト指向言語（OOPL)

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

wikipediaなどでもちゃんと別物として
用意されていますから、勉強してくるように。

>>175
なんだか、OOと呼ばれるものを集めて列挙しているだけ、という印象をぬぐえないのですが。
列挙すればそれも定義になるというのであれば非常に楽チンではありますが、読む側はなんのことやらさっぱりわかりません。

OO ってなんですか？
いや、範囲を狭めましょう。「C 言語で OO」 という記述が具体的になにを指しているのか、あなたの言葉で説明していただけませんか？
「C 言語で OO」 という記述が具体的になにを指しているのか、例をあげてもらえないでしょうか？
<stdio.h> 中のFILE 構造体と、これのポインタを引数や返り値とする関数群、とか。

OO信者にとっては何でもOOなんだよ
役立つプログラムとかは全部OO
一方、開発に失敗したらOOを使ってなかった or 理解してなかった

日本のテレビの特徴：

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

>>176
> OO ってなんですか？

オブジェクトな指向。

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

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

OOPLではなくてOO（考え方）で作るのは可能。
そもそも、考え方が先にできて、それに適合しやすい言語が後から作られた。

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言語で書かれているという事実にもかかわらず、
それはオブジェクト指向プログラミングの分野からいくつかの技術の広範な使用しています。

>>179
いや、扱う範囲を狭めさせてください。
「C 言語で OO」 という記述が具体的になにを指しているのか、これを記述された方、また記述された方でなくとも、なにか思い当たるところをお持ちであれば是非教えてください。

私見では仮想関数の存在こそがOOで重要な点だと考えているので、仮想関数のない C でも OO ができる、という記述には違和感を感じます。

>>180
C で OO を標榜するのは無理がある、という立場からすれば、

＞オブジェクト指向プログラミングの分野からいくつかの技術
というのが具体的になにを指すのか知りたいです。

>>181
仮想関数テーブルを構造体とかに持たせる => CでOOできた！

……Smalltalkerに怒られそう

クラスって関数ポインタ入れた構造体でしょ

>>181
OOをサポートした言語の方がOOをやりやすいけど他の言語で出来ないわけじゃない。
昔のC++はCのプリプロセッサでC言語を吐いていたし。

まあ、トランスレータで吐いた C コードも OO できた！というのは認めたとしても、で、
Linux の C コードに仮想関数テーブルが存在するとは、とても信じられない。

一度みてみたい。

switchでも仮想関数テーブル相当だし関数テーブルなんて普通に有りそうだし
なにをいちゃもんつけてるんだとしか思えない

>>182
> ＞オブジェクト指向プログラミングの分野からいくつかの技術
> というのが具体的になにを指すのか知りたいです。

リンク先に書いてあります。
part1と書いてあるようにpart2以降まで有る
長い文章です。

そりゃ、なんでもかんでも Object Oriented といえばすむ、という風潮にいちゃもんをつけているだけです。

>>189
キモい。

>>188
自分の言葉で説明できないならレスなんてつけんなや坊主

なぜ自分の言葉で説明しないといけないのか？

>>192
なんでそんなこと説明しなきゃならんのか？

説明しなくていいよｗ

>>193
自分の言葉で説明できないならレスなんてつけんなや坊主

発している言葉が真である必要があるか？

使っている技術が役に立つモノである必要があるか？

>>191
他人の受け売りを消化せずに自分の言葉のように発する輩も多いぞ。

それの何がまずいのか？

>>197
営業的に役に立つ技術と実際に役に立つ技術の２つがある。
前者は一時は流行るが直ぐに廃れる。

すべてをリセットして考えよう
オブジェクト指向は役に立つ技術か？
また役に立つ必要はあるのか？
その議論に意味はあるのか？

ﾏﾝｺ

>>202
マンコの方が役に立つのは確かである。

なにをもって役に立つとするのか？

ホモやＥＤの人間からしたらマンコなんて役に立たんな

>>186
vtableと実装技術は違うけど、構造体に関数テーブル持たせるのは
Linuxカーネルに限らず用いられてるごく普通のテクニック。

ドライバなんかも、論理的なインタフェースとハードに応じた実装
と分けておくことで設計をシンプルに保ってるしな。

>>206
＞インタフェースとハードに応じた実装と分けておくこと
これが単にラッパを一段かませてある、というだけであるのならとてもじゃないが OO 由来技術とはいいがたいと悲憤慷慨すると思います。:-)

＞構造体に関数テーブル持たせる
関数へのポインタを並べたテーブルを用いること自体は理解できると思います。
とりあえず、いただいたポインタを読んでいるところです。

> これが単にラッパを一段かませてある、というだけであるのなら
違うよ。

あぁでもOO由来ではないかもね。
元々、そういうテクニックは存在してて、それをOOがうまく取り込んだ
というのが正解に近いんじゃないかな。

どんな言語で書いたものであろうと
最終的にはマシン語に変換可能である
つまりCで書けなくもない

OO由来じゃないからOOじゃないってのどうか

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

OOPLの支援がなくてもOOPができるのは当たり前な気がすんだけど

CでOOPというとGLibやGTKででてくるGObject systemとか？

Xの方が有名ではないかと

90年代前半からMotifはそうやっていた
いまではすっかり寂れたwidgetだが

SimulaはOOPLじゃないんだろこいつのなかでは

昨今のOOPのブームを見ると、車輪が再発明されるシーンを
10回くらい繰り返し見せられたような既視感に捕らわれる

あとからあとから騙されやすいシンパが世代交代して湧いてくるって訳よ

浜の真砂は尽くるとも、世にお間抜けの種は尽きまじ

OOもそれなりに定着した気はするけどもっと収斂してもいい気もする

継承、多態、カプセル化がオブジェクト指向の要素だ
と主張するやつもいれば
多態さえあればオブジェクト指向であとは誤差だ
と主張するやつもいるし永遠に収斂しないんじゃないのかな
ちなみにおれは後者の立場

別に定義なんてどうでもいいや
ただ多態ってメリットあるんか？

あるよ。

>>220
俺はその内の一つでもあれば
オブジェクト指向だと思ってるよ。

お前の考えをさらに柔軟にした考えだ。

多態は同じクラスから継承した別クラスのインスタンスを同じ配列にぶっ込んで、ループ処理させたりするのに良く使う。
頭悪い奴は、クラス定義からして間違ってるから、多態を利用するアイデアも思いつかない。

実装を一つもみないで分かったつもりで多態のための基底クラスやインターフェースを作ってしまうと
いざ実装を始めたときにインターフェースに足りないものが見えてきて、
他の全ての実装クラスを巻き込んだ仕様変更の嵐に巻き込まれることになる。

多態や基底クラス考えるのはある程度実装が出揃ってからのデファクタリングだと思ってやるべき。

ちょっと何いってるかわかんない

高度な釣りと見たｗ
高度、というのは具が多く仕込まれてるという意味。

>>224
いや、俺違うもん同じ配列に混ぜるようなへちょいプログラム組んだことねーし

よくやるけど。てか多態ってそういうやりかたするためにあるんだし

>>229
なんだ
設計下手糞な奴のためにあるのか

設計が上手くないから、ひとつの配列に同じ物しか入れられないんでしょ。

基底クラスの配列にサブクラスのインスタンスを格納するのはごく普通のことだろ
同じ配列に入れるのが目的で継承するとかなら別だけど

>>231
入れられないじゃなくていれねーんだよ
違うもんなんだから違うように扱えよ
なんでわざわざごった煮にするんだよ

WindowsAPI位しか非OO系言語のライブラリを使っていないけど、
アレでもオブジェクト指向している気がする。
ハンドルで識別される「何か」に対して操作を行うって設計に。

>>233
全てはタスカー様のお導きのままに。

オブジェクト指向だから何でも多態ありきでやろうとするとタスクシステムへ行き着くんですけど
信者とアンチが大暴れするあのタスクシステムに。
オブジェクト指向でも何でもない、関数ポインタの配列ぐるぐる回すだけのタスクシステムに。

>>233
そもそも違うかどうかも知らんし、知る必要もない。
特定のインタフェースを実装してるかどうかだけわかってればいい。

>>236
なんだそのタスクシステムって。

>>238
http://www5f.biglobe.ne.jp/~kenmo/program/task/task.html

>>233
君にはオブジェクト指向が向いてない
DuckTypingなんて10年も前のトピックだ

>>237
でも生成するときって違いはあるんでしょ？
それをなんの意味もないのにわざわざ一箇所にまとめてるんだよね？
バッカでー

>>241
一括管理できるものを、わざわざバラバラに管理する意図がわかりません。

>>242
したらどうして違うクラスにしたの？
ごった煮で入ってるってことはどっかで分けないといけないよね？

極端な話すべての使用するクラスのインスタンスを１つの配列に突っ込むことも可能っちゃ可能だ
実際、ゲームではそうやっちゃう人もいるしねｗ

彼らポリモ信者はそこに線引きはできるんだろうか？

> したらどうして違うクラスにしたの？
あるメッセージを受け取った時の処理が、それぞれ異なるから。

> ごった煮で入ってるってことはどっかで分けないといけないよね？
メッセージを受信したオブジェクトがそれぞれ自分の動作をすればいい。

>>243
君は怖がっているが、有用な手段であることには変わりない
怖いのならやらないのは仕方ないが、だからといってやる人間がいなくなるわけではないな

>>245
やっぱ、違うじゃん
違う処理走るんだろ？
違う情報が必要になるし（この時点で引数が違う）
同じ利点がまったくねーじゃん
せいぜいfor文１つで済む程度
２つ書いてもコピペで済むレベルのはずなのに
なぜかこんなところを一生懸命まとめようとしてるのがポリモ信者（＝馬鹿）
一度ポリモを使ったときとそうでないときとでコードを比べたほうがいいよ

タスクシステムの何が嫌いって、ごくローカルな用語でしかないのに
>>236みたいに知ってて当然というような態度の奴がいるのが嫌い。

>>247
釣りかよ…

結局、削減可能工数から逆算できる技術以外はみんなカスだな
１Ｈもけずれねーことに力いれてんじゃねーよカス
ポリモ使ってまとめられるレベルじゃおまんまクエねーよバーカ
理詰めで仕事ができない奴って毎回こんなチンポコレベルの仕事しかできなくてはずかしくねーのか？って毎回思う

>>247
> 違う情報が必要になるし（この時点で引数が違う）
仮にもオブジェクトなんだから、動作に必要な情報は自分自身が持ってるでしょ。

もし、クラスに応じて違う引数を渡さないといけないようなものをまとめてるのなら
設計が下手としか言いようがないが、下手なものを持ち出されて「ダメじゃん」
って言われてもねぇ。

>>251
>仮にもオブジェクトなんだから、動作に必要な情報は自分自身が持ってるでしょ。
そうとも限らないよね？
ゲームではよくあるんだけどホーミングミサイルとかはどうしても別オブジェクトの情報が必要になる

>>252
で、そのホーミングミサイルを同時に数種類動かすときどうすんの？
その種類ごとにループ作るの？
種類が増えたらループ増やすの？

コピペプログラマの主張なんか聞くに値しないなwwww

>>252
ホーミングミサイルというやつに、別オブジェクトの情報を持たせればいいんじゃね？
そのときに、どんなオブジェクトを追尾しててもgetLoc()で座標が取れたら便利だと思わないか？

>>255
そのオブジェクトが消滅したらホーミングミサイルにどうやって通知するんだ？とか考えはじめると頭痛くなる。

参照が切れるまでは消滅状態で保持する

>>255
実際に狙われもしない奴のgetLoc()も実装するとかめんどくさすぎる。

それこそ継承じゃん

>>220
上はOOでもOOPでもなくOOPLの説明でしょ
OO自体には「オブジェクトを中心とした考え方」以上の意味はないかと

ごった煮だと当たり判定で組み合わせ爆発したらどうすんのとか。
あらかじめリストを敵、弾、自機とかにわけておけば軽減できるよとか。
え、最近のPCは速いから大丈夫だって？うん、俺もそう思う。

てかすでにごったの利点は消えてる
ちょっと関連が増えるとすぐにこの状態になるのがポリモ
なんの利点もねーよ
ホーミングミサイル程度も受け入れるキャパがないのがポリモ
なんの検証もしないで導入しちゃうから当然の結果

所詮似非技術者ができることなんてこの程度
農家の生まれが知的作業するなっていういい例

多種多様な要件に応えるために肥大化する基底クラス。人はそれをゴッドクラス（神クラス）と呼ぶ。

>>263
神クラスってのはＣマガジンの誰かがつけた名前で
グローバルインスタンスホルダー（ネーミングで内容はだいたい予想できるだろｗ）のことだ

>>262
うんだから君にオブジェクト指向は無理だから
無理しなくてもいいんだよ

ゲームの例えしか出せないのはゲーム業界の奴だと思うけど、そういう奴はオブジェクト指向とか無視して
今まで通りC言語でゴリゴリ書いてりゃいいんじゃね？ｗ
ゲームなんて突貫工事みたいに汚いコードでも、とりあえず動けばいいってな感じだし、再利用性も考えてるヒマがない。
汚すぎて常に使い捨てのソースｗ
バグが出ても誰に迷惑をかけるわけでもなく、単に「糞ゲー」と呼ばれるだけ。
そういう責任感が希薄な現場なので、自分もその雰囲気に染まって仕事するしかないだろう。

>>265
はぁ？
俺がどうこうって問題じゃなくて
すでに利点が消えてんじゃん
問題の切り分けもできないの？バーカ

認めて欲しくて必死だな

>>268
は？
馬鹿なの？
すでに導入した技術の利点が消えてるのに
なんで利用しつづけようとするの？
って聞いてんだよ

多態なんてミサイルとホーミングミサイル（ターゲットの引数１つ増えただけ）の違いも記述できないチャチな仕組みってことだよな

弱い奴ほどよく吠える

わけのわからん奴が
利点欠点入り乱れる中
ゲーム界という狭き立場で利点を欠点に変えようとしてる阿呆がいる
利点もあるし欠点もあるんだよ

>>267
利点が理解できないんでしょ。だから消えてるように見える。
無理しなくていいんだって。

ネタかと思ったら天然だったでござる

ポリモ信者も糞だがアンチも糞ということがよく解った

>>270
記述できるよｗ

ゲームとかでもよく使われてる。

ファイルとフォルダの関係のポルモ(同一視)の利点について、どう欠点に変えてくれますか？

>>247
＞同じ利点がまったくねーじゃん
＞せいぜいfor文１つで済む程度

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

>>273でFA

すでに導入した技術の利点が消えてるのに
なんで利用しつづけようとするのか？

ポリモの話じゃねえじゃんww

どっちも必死すぎてくだらん

痛い所は全てスルー

ポリモの利点を語れない奴が欠点だけ語ってんだよ

底の浅い奴だな

ただのインターフェースの共通化、抽象化をOOPの成果みたいに言うのもどうかと思うがな。

ゲーム業界という、質より物量を優先する所では使えないだろうな

物量の無いところでポリモの出番無いんじゃ。

階層型データ、例えばフォルダ/ファイルとか、ブラウザのブックマークとか、アプリのメニューバーとか、XMLパーサーとか、
そういうのを全部、再帰構造のクラスで表現するように書き直す作業をやってる。
それが凄い面白い。
クラスの中に自分のクラスのインスタンスのポインタ配列を持たせて、入れ子状態を表現する。
そうやってクラスを書くと、コード行数がもの凄い減ったし、個々の処理がシンプルで見やすくなった。
これは勉強になったわ。
オブジェクト指向は最強だ。

いや、最強と言っちゃうと変な人が騒ぎ出すから…

ゲームみたいに速度重要なとこじゃ使えんだろう。
オブジェクト指向厨がいくら設計がんばっても、速度でなけりゃ物量もだせないし、
全然ダメだろ。設計で速度もみつもれりゃいいんだろうけど。

>>279
少なくともミサイルとホーミングミサイルでは役に立たないみたいだねｗ

もっと建設的な言い方しろよ
全然ダメとか何様だよww

笑っちゃうだろ

一連のレスを読んで、日本のゲームデベロッパがいかに低レベルか思い知らされたよ。。
もうちょっとレベルが高いものと思ってたけど、これじゃぁ欧米に勝てる見込みはなさそうだね。。

>>291
本当の建設的っていうのは
役に立たないものを役に立たないと受け入れらることだろう

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

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

これが見えなくなったら技術者なんて辞めちまえ
給料少ないしホントにやってる意味ないと思う

>>292
>もうちょっとレベルが高いものと思ってたけど、これじゃぁ欧米に勝てる見込みはなさそうだね。。
このオブジェクト指向だのポリモだののゴミは

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

まあ、向こうの文化とかもよく知るべきだよね
セミナーとか金集めの道具にこういう意味不明な技術はもってこいなんだろ？

頭のいい人は気がつくんだろうけどね
http://tabesugi.net/memo/2009/1a.html#152154

>>295
多くの平均以下のプログラマがC＋＋を使わなくなれば改善するよw
まぁJavaみたいに平均以下のプログラマを大量に投入するのに特化するのもありだと思うけど。

理詰めでモノを考えられない似非技術者が多いのが嫌いなんだろ？
多分その人もメリットを数字であげてみろって絶対いうと思うけどね
製造業でこれがないっておかしくないか？

自我強い奴に関わると疲れるだけだろ

だから利点もあるし欠点もあるんだって・・

なんで欠点だけしか語れないの?

>>299
利点って？
正直、引数１つ増えたごときでもう使えないんじゃ利点も糞もないと思うんだけど？
仮に引数として増やさなかったときはそのつじつまあわせは別のどっかでやるんでしょ？
これをやっちまったときの余波が正直ハンパねぇ痛さだと思う
担当者があきらめてこの時点で多態をやめてくれれば傷は浅くて済むが・・・

引数たった１こですよ
いつ必要になるかわからないレベルじゃん
これでもうこの構造ダメ
冷静に考えて使い物にならない
メリットあるとかないとかの話じゃないだろこれ

そもそも引数が増えたら多態じゃねえじゃん。
馬鹿だから区別ついてないんだな。

arityの概念さえしらんのか。まあこの程度のやつだったらそれも仕方ないな。

ファイルとフォルダの関係のポリモ(同一視)の利点について、どう欠点に変えてくれますか？

大抵の奴はこの時点でもう手段と目的が逆転しちゃってて人の話なんて聞く耳もたなくなっちゃってるけどね
意地でも多態を実現するために引数を増やさずにグローバル変数・インスタンスを使ってでもやっちゃう・・・
これがもうね・・・技術者として最悪

>>303
しつこいな
糞じゃん

ごったにしなくても
普通に
フォルダに対してgetFileListでファイル一覧取得できて
フォルダに対してgetFolderListでフォルダ一覧取得できたら
みんな幸せになれんじゃねーの？
ごった煮じゃないとダメなことあるのか？

あんたも十分聞く耳持ってないよ
安心しろ同類だ

>>306
そのレスに技術的な指摘が入ることはこの先もないんだよなｗ

つっこむなら全レスに突っ込んでけよww
301と302が抜けてるぞ

>>305
＞普通に
＞フォルダに対してgetFileListでファイル一覧取得できて
＞フォルダに対してgetFolderListでフォルダ一覧取得できたら
＞みんな幸せになれんじゃねーの

それをしたくないから合わせるんだけど・・

>>290
> 少なくともミサイルとホーミングミサイルでは役に立たないみたいだねｗ

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

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

あとはその座標にレンダリングするだけ。

>>305
＞しつこいな
＞糞じゃん
＞
＞ごったにしなくても
＞普通に
＞フォルダに対してgetFileListでファイル一覧取得できて
＞フォルダに対してgetFolderListでフォルダ一覧取得できたら
＞みんな幸せになれんじゃねーの？
＞ごった煮じゃないとダメなことあるのか？

すげーうけるww
ごちゃまぜの利点理解出来ないんだなwww

ゲームと言えばC++だね。
速度も速いししオブジェクト指向

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

最近ゲーム関連の良書が増えたけど
ことごとくC++ばかりだし。

ホーミング先の選定なんて引数で渡す必要すら薄いのだが…
そのミサイルオブジェクトのオーナーに尋ねればいいだろ

>>305
強引に否定してるだけだろ、それwww
利点を消してんじゃん、なにやってんのww

ホーミングミサイルの仕様から考えると、
ミサイルの周りの状況を認識する機能が必要。

周りの状況を認識するってのは
ホーミングミサイルだけに必要な物じゃないだろうから。
すべてのオブジェクトに周りのオブジェクトの状態を認識するための
インターフェースを基底クラスにつけることになるだろうね。

>>303
自分もファイルクラスを継承してフォルダクラスを作ったわ。
そうすると、フォルダクラスが持つ子供リストはファイルクラスの（ポインタ）配列だけで済む。
ファイルの配列とフォルダの配列を別々に持つと、ものすごい気持ち悪い処理になるので、すぐにダメだと分かった。

>>305
再帰的に作った方が楽ですよ？

気持ち悪い処理っていうのは、名前とか日時とかいう属性でソートしたりするときの話ね。

>>317
楽じゃないですよ？

理由ぐらい言ってから、「楽ですよ」と言いなさい。

www
まだいたのかよ
随分ツッコミが飛んでるぞ

>>320が今から突っ込むので期待して寝ろ！

クラスそのものが再帰構造（入れ子）になっている場合、「再帰関数」というものを使う必要がない。
常に自分の子供のことだけを考えて処理を書けばいい。
それだけで、rootから簡単にツリー上の全体の数を調べることができる。

ごちゃまぜの利点なんて
共通メインルーチンを作る仕組み
それだけだが、それが狙いなのに

共通メインルーチン否定して何がしたいの？

基底クラスの肥大化を防ぎ、設計をシンプルにします。

馬脚を表すのが怖くて>>301-302にはレスできない模様ですwwww
もう馬脚を表してるんだから怖がる必要ないのにwwwww

オブジェクト思考にこだわる奴は糞だが、否定する奴も糞すぎるwww

何を今更・・
次元の低い言い争いですね

>>326
お前はビルの屋上から道行く人を眺めて王様気分に浸ってるのがお似合いだよ

>>326
満足したなら帰れよｗ
どうせ他に何も言えることがないんだろう？

>>309
え？なんで？
ちょっとコード書いてみ？
ファイルとフォルダで別のが楽だろ？

そもそも多態なんてオブジェクト指向特有の概念ではなくて
ただ扱いやすいように整備されてるだけの話なんだけどな

unixのファイルシステムなんて多態の最たるものじゃないか

>>331
デバイスドライバもそうだな。

>>330
ウザすぎ

>>333
人格否定が出るってことは技術的な指摘ができなくなったってことだよな
弱いｗ

いやだから何回も指摘してんじゃん
>>330
について語ってやれよ

>>331

>>330
利点が見えない時点で終わってる

痛い所は全てスルー
技術的なスレにツッコミいれていけよ
>>301,302,309,331
の解答が無いよ

>>330
うけるww

>>330
宗教の勧誘だなww

>>338
なんか答えてもまったく実りがなさそうなんだけどｗ

>>303
多分、この特別頭悪いの君だよね？
何が利点だったの？
数字をあげてメリットを教えてくれる？
コード量でもコーディング時間でも君の好きな数字でいいよ

>>338
多態でないものを多態と思いこんで「多態使えねー」とか、
多態を効果的に使っている例を無視とか何だかなというかんじ。
ちょっと前までは釣りかと思ってたけど、ほぼ天然で確定だと思うわ。

>>342
ミサイルとホーミングミサイルの例では多態はダメだって結論が出た話しただけだよね？
君がどのレスをしたのか俺はよく知らないけど
なにか有効なレス出たっけ？ｗごめん本当にわからなかったわｗ

>>343
じゃあファイルシステムの例でいこうか。
WindowsではNTFSやFATやSMBがファイルシステムとして実装されてる。
これはファイルシステムの外から見ると全く同じように使える(=多態である)
それぞれのファイルシステムごとに
ntfs_openやらfat_openやらsmb_openやらの関数を用意して
アプリケーションから使い分ける実装ももちろん可能だが、
ただひとつopenという関数でどのファイルシステムでも使えた方がずっと労力がかからないし、
別のファイルシステムが実装されたとしてもプログラムに変更を加える必要はない。

これを利点と言わずしてなんと言おうか。

>>344
え？
それってさっきのファイルとフォルダがごったになってる話とリンクしてんの？
んでもって仮にそうだとしてなんの処理やること想定してんの？

>>345
どこをどう読んだらファイルとフォルダがごったになった話とリンクしてるように読めるんだ。

>>346
え？
急になんの話はじめたの？

>>347
>>311の話を引き継いでいるんだけど。
まあ理解できないなら別にいいです。

ごめん、>>311じゃなくて>>331だったわ。
お詫びして訂正いたします。

>>348
あ、やっぱリンクしてたの？
レスもごった煮なんだ？

さっそくアドレスミスって例外エラーとかおめでてーな

まあでもファイルシステムの具体例を見て利点がおぼろげなりとも想像もできないようだったら、
プログラマは向いてないと思うよ

スルースキルが大切なスレだな

>>352
ファイルシステムって多態が使われてるの？
どうみても組み込み分野なんだけど

後、利点に見えないんだよね
switch caseでわけても同じことできるっしょ？
単に多態つかって表現してみました程度にしか見えない

これで工数はいくつ削減できるの？
別に工数じゃなくてもいいけど数字で説明してみ？（強制ではないけど）

>>354
組み込み分野なら多態が使われないと言いたいのなら、それは思い込み。

>>355
> switch caseでわけても同じことできるっしょ？
ドライバ増えるごとに、カーネル側のコードをいちいち書き換えるの？

>>354
多態は別にオブジェクト指向特有の概念ではない。
抽象化の手法に過ぎない。
ただしオブジェクト指向言語においては多態が使いやすくなるように仕掛けが用意されている。
なので組み込み分野だろうがなんだろうが関係なく使える手法だ。

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

これで理解できないのだったら、もう諦めるよ。

>>355
動的にロードしたいドライバなんかは、
新しいドライバモジュールロードする度にカーネルコードの書き変えと
コンパイルが必要になるよ？

>>356
え？実際に使われてるの？
それとも例としてあげただけ？

WindowsAPIの涙ぐましい努力の跡を見るに、最初に作った共通インターフェースは未来永劫足かせになる。
そして16bitから32bitへ、そして64bitへ移行するにつれて○○Exとかいう拡張関数が次から次へと追加され
基底クラスは過去との互換性のためにぐちゃぐちゃになっていく。

>>359
構造体＋関数ポインタという素朴な形から、Strategyパターンのようなものまで
ありとあらゆる形で出てくる。

>>360
そしてWindows RTで仕切りなおしというわけだよ。
互換性を保ちながら仕切りなおしが出来る
この体力がWindowsの強さである。

見事な平行線だな

問題を解決するより
不満を解決する方向に行ってる

共通インタフェースを
この通りに作れば良いのか楽だなと取るか
テンプレあんのかよ、足かせだなと取るか

両者の言い争いは泥沼化していく

まとめる事が嫌いな奴が
ごり押ししてるだけ

ファイルとフォルダの関係っつう極簡単な物まで分けて考えろとか、言ってる事めちゃくちゃ

>>366
え？真面目な話なんかメリットあったの？

ミサイルとホーミングミサイルだとまったくメリットなかったみたいだけどね
似てるけど

この人の中でシンボリックリンクはどうなるんだろ
ディレクトリの一覧、通常ファイルの一覧を得る関数のどちらかで取得？
それとも、シンボリックリンクの一覧を得る関数が別に用意されるのだろうか

>>368
んじゃ、微妙に目標へ曲がるレーザーとか
普通のレーザーとかも
「微妙に曲がるレーザー配列」や「普通のレーザー配列」とかに別々に詰めるの？
「こんな新しいタイプの攻撃も考えたから実装よろ」って言われたら
その都度配列増やしてループ増やしていくの？

複雑にしたら害悪だが、まとめる事は良い事だ
その二つがポリモ化してるのが原因

>>370
なんか神クラスとかいう言葉が出てきてたけど、神関数や神ループが必要になる予感。
神switch-case文も。

オブジェクト思考のポリモなんてなんの意味もない
↓
単純なファイルとフォルダの関係についてまとめて扱える事が利点だ
↓
別けて作った方が楽だろ
↓
え？真面目な話なんかメリットあったの？

単純にポリモ使って、複雑化して蛇足になってるって話なら良かったのに、
ファイルとフォルダシステムという簡単な仕分けにまで糞認定したのが哀れだよ

キチガイに踊らされすぎたな
クリティカルシンキングが足りなかったと思う

>>373
微妙に違う

オブジェクト思考のポリモなんてなんの意味もない
↓
単純なファイルとフォルダの関係が利点だ
↓
別けて作った方が楽だろ
↓
まとめた方が楽だろ
↓
え？真面目な話なんかメリットあったの？

そしてなぜかファイルシステムの話には沈黙するのであった

一旦ごった煮にしておいてあとから区別するのだけが糞。
*区別しなくて良いものを* ひとくくりで扱うのがポリモのメリット。

上の方で散々ポリモを使って段々カオスになっていく。設計もまともに出来ない奴が使って阿呆すぎ。
とか散々言ってんのに
設計の見通しが楽で、簡単にまとめる事が出来るファイルシステムの話なのに、別けて考えた方が楽だろ発言。

途中で誰かと入れ替わったんだろ
それか本物の阿呆だったか

自分が理解できない概念は否定したくなる「酸っぱい葡萄の論理」だよ、分かってやれ。

ポリモとか下級戦士じゃ殆ど活躍の機会がないから、糞認定するのはわかるけど
比較的わかりやすい、唯一の良心となっているcompositeパターンにまで噛み付くとはな

compositeのキモは多態よりも再帰だろ常考。

再帰も否定してたじゃんw

ファイルとフォルダの関係がcompositeじゃん・・

ツリーの要素がディレクトリとファイルしかないんだったら
一通り愚直にコーディングしてみて、さあcompositeでスマートにまとめてみようかなと思ったときには
必要な機能は大体完成していて、それ以上手を入れる旨味が無い。

頭の中でまとめれないんだな・・

>>385
設計の工程全否定だなww

状態がディレクトリとファイルの2パターンしか無くて、
設計の段階でそれ以上追加も無いってわかってるんだったらifで分けても楽勝じゃん。

>>385
>>388
あらかじめcompositeパターンというまとめた物が頭の中にあるのに、なんでごり押しでプログラム作ったの？

まとめたくないんだなww

>>388
なにかやるたびにいちいちifで場合分けするよりポリモでコードを分離しておいた方がはるかに見通しがよくて楽

>>385
フリーダムなコーディングだな

>>388
これだけの話なら全然いいけど、385が前提となるとなんとも言えんな

ファイルとフォルダってのがまた絶妙だな。
実際、共通にする意味はないだろうな。
ファイルとフォルダでインターフェースがずいぶん違うだろうし。
共通になりそうな部分を括り出しても、
意味のないインターフェースが一つ増えるだけだろう。
そもそも、GetFile()でIFileBaseが返されるとして、
それがフォルダかファイルか調べたりキャストしたり等々、
実は余り便利ではないしな。

しかしWindowsでもunixでもディレクトリはファイルの一種として実装されている事実

これは個人的な見解だけど、
迷ったら使わない、必要がなければ使わない、だとおもう。
ほら、買い物の名言に、迷ったら買わないってあるじゃん。
インターフェースと制御構造とデータ構造、
同じところでスパっと切り取れりゃ良いんだが、
実際にはそれなりの粒度で無いとなかなか。

>>394
でもね、今欲しいのは低レベルIOなのかって言う。
その理論なら、intもfloatも4バイトのビット列なんです、になるだろ？

あと、オレなら仮にファイルとフォルダを纏めるにしても、
普通にis_directoryフラグを設けて switch なり if なりするぜ。
この二つしか種類がないって分かりきってるからな。

パイプかもしれない。

中々笑えるスレだな

>>396
intとfloatとはいい例を挙げてくれた。多分Cだと思うんだけど+演算子も多態だよ。
intとintの和もintとfloatの和も実際のコードは異なるのに同じ+で表現できる。
もちろんintとfloatの内部表現は異なる。なので

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

とはならない。内部表現に関わらず同じような操作は同じような名前で呼び出せるのが多態だ。
こんな初歩的なところも理解せずに君は批判してるのかい？

>>397
そんなことはないよ。デバイスファイルはどうするんだい？

>>400
でもいっしょにされるとなにかと困っちゃうよね
四則演算のどれも注意が必要
全部いっしょにしてよなんてのはよほどの馬鹿しかいない
同じ＋でなんて

　余　計　な　こ　と　す　る　な　！

と叫びたくなるな

あ、ちなみにごった煮の場合ね
俺はintとfloatはちゃんと別にもつからね

>>400
文字列の足し算と数値の足し算はまるで違うし、オブジェクトの足し算もありうる。
また数値は数値でもビッグなインテジャーもあれば文字列表現されている数値もある。
結局は各組み合わせごとに加算方法を定義する必要があるわけで多態なんかお呼びじゃないよ。
プリミティブな変数に限ってコンパイラが頑張って暗黙的なキャストしてるけど、
どの型にキャストするのかについてどの型が上位かという序列を内部でもってるわけだし。

>>404
>結局は各組み合わせごとに加算方法を定義する必要があるわけで多態なんかお呼びじゃないよ。

多態はまさに各組み合わせごとに加算方法を定義するわけなんだが。
多態のキモはそこではなくて「同じ名前で呼び出せる」ことにあるんだけど、
まだそこは理解できないのかい？

別に余計なことするなとかそんなことはどうでもよくて多態の一例というだけのこと。
ポインタと整数の加算も余計なことかい？

>>406
うん
エラー出して止まってほしいね

gotoさえあれば関数なんて必要ないだろ、って言い張ってるやつを一所懸命説得してるようなもんだなwwwww
無駄だからやめとけよwwwwww

>>405
演算子や関数のオーバーロードは多態じゃないよ。

いたい！

>>409
君は多態とオーバーロードの区別もつかないのか…

>> 368
> ミサイルとホーミングミサイルだとまったくメリットなかったみたいだけどね
> 似てるけど

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

で見なかったことにするようなレスをするとｗ

どうでもいいから
ミサイルとホーミングミサイルを多態で表現してみろよ
レーザーとホーミングレーザーでもいいぞ

>>411
おまえは変態だろう。

>>413
ミサイル　発射
ホーミングミサイル　発射

糞スレ化してんぞ
頭冷やして書き込めよ

>>415
ホーミングミサイルくんはターゲットがわからないと追尾できないのだ・・・

「オブジェクト」と呼べるようなものが
あるアプリには多態は必須だろうね。

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

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

こういう"物”がたくさんあってそのバリエーションが
多かったり、カスタマイズして増えたりするのは
多態を使わないと工数がかかってしょうがなくなる。

>>417
当たり前だろ何言ってんだあんた

>>417
生成するときに相手を指定したらいいんじゃないの

>>417
え？ その答えも上に書いてあったじゃん？
ターゲットが分かるようにすればいいだけ。

そのレスを引用してくれる？
そしたら話し続けようね。

>>420
多態を使う時newの引数を変えていいの？

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

こんなのやったらだめだよね？

>>422
良いに決まってるだろｗ

はたして、できるからといって
やっていいものだろうか？

とんでもないもんが出てきたなww
ウケルww

そもそもホーミングミサイルだってターゲットが必要っていうけど
途中消失や相手を見失ったときの索敵も実際は必要になるんだからね！
発射したばかりはターゲットもいないだろうよ
ただ、撃った方向に飛ぶだけだ
索敵して敵を見つけてはじめてホーミングミサイルとしての役目に移るのだよ！
そして、敵を見失ったらまた敵を探すのだよ！
一般的なゲームでそこまでやってるかどうか知らんが俺が組んだときはそうしたのだよ
目視では当然わからんが・・・ｗ

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

↓これが多態
m.発射()

>>427
索敵機能もないホーミングとかゴミなもん作りやがって

笑わせんなよww

>>426
じゃあ相手を探す機能をつければいいだけでは？

ホーミングミサイルはロックオンしてから飛ばすってお母さん教えたわよねぇ？

>>430
関連は敵リスト全部っすか？
第三者クラスが必要な規模

>>426
ゲームであれば、少なくとも
レンダリング時など一定時間ごとに
呼び出されるメソッドがある。

そのメソッドで、相手を探せばいいだけではないのか？

>>432
敵リスト全部つーか敵リストをひとつ持ってりゃいーじゃん

>>432
> 関連は敵リスト全部っすか？
関連？

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

ゲームシステムオブジェクトは
すべてのミサイル等をレンダリングなどの機能を持っており
すべてのオブジェクトを管理しているもの

俺のホーミングミサイルは障害物も壊せる
敵のホーミングミサイルからすれば自機をもってないとね
んなわけで自機ホーミングと敵ホーミングなんてできたりしてｗ

は？デコイ？なんだデコイって？
とかつくと余計ややこしい

> 俺のホーミングミサイルは障害（ｒｙ

話も聞かずに略すけどｗ

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

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

で、話は？ｗ

ああ、それとシールドで跳ね返ったホーミングミサイルは
敵ホーミング→自機ホーミングになるから（ｂｙ企画）

へーい（糞が、だれも気がつかねぇよそんなの）

プログラマ「仕方ないな。じゃあ自機ホーミングと敵ホーミングなんて区別やめて、
シールド衝突時に敵限定でターゲットを再検索するか」

デコイがあるときは自機はターゲットにしないっていっただろ！
そんなこともできないのかよ！

↑俺が企画様（５つ下）から承った言葉
ＳＴＧじゃないけどねｗ

>>440
そんなことも出来ないのかよｗ

ターゲット取得時に、デコイを返すだけだろｗ

>>440
多態を使わないと、どんどん複雑になって
管理できなくなるような話をしてるなｗ

多態を使わなければIFの嵐だろうね。

>>441
敵ホーミングの目標消失時チェックで自機がいなかったら〜的なプログラム組んでたから
デコイが考慮されてなかっただけでぶっちぎれなされた模様

知らんよ。キレたとか個人的な話はどうでもいい。

企画様を多態で黙らせてくださいよ！

企画様をバッドで黙らせればいい。

>>442
多態で吸収しきれないだろこんなの

じゃあ何で吸収します？

>>448
超必殺switch caseですべてのケースを書き出す
判定が重複したときも１つのケースとしてすべて書き出す
でないと複雑すぎてやってられん・・・

なんだ、釣りだったかｗ
わざと反対の事を言うってやつだな。

仕込みがなげえな

複合要素を複合要素のままほっとくと修正できないぞ
保守とかそういう次元じゃなくて１つのプロジェクト期間内で修正が効かなくなる
これはマジで

デコイはヤフオクで買える

敵リスト作るとか、
そのうち敵弾リストとか自弾リストとかできていって
何のために多態してるのかわからなくなるな。

>>454
まあ、普通にリストは共通オブジェクトのリストですよね。
ゲーム内に登場するすべてのオブジェクトの上位クラス

そこから、敵のみをリストでフィルタして抽出してとか
あるでしょうが。

自機or敵デコイリストはあったほうが便利だ
どっちにしろデコイ有効範囲はその都度チェックいるけど

LINQ(やっと俺の出番が来たようだな・・・)

↑ないって、お前無駄多いし

>>456
そうやっていろんなリストを作るのが
オブジェクト指向に反してるっていうのｗ

ミサイルとホーミングミサイルよりは
自機リストと敵リストのがいくらか多態しやすそうじゃね？

「ゲーム会社に居るんですが、オブジェクト指向がまったく分かりません。
多態でやれと上司から言われてるんですが、どんなメリットがあって、どんな風に実装するか教えてください。」

って最初っから言えよ。

グローバルインスタンスホルダーがある限り
なにをどう組んでもどうにでもなるだろ

リストごとに専用のインターフェースが必要になります。

>>400
亀レスで申し訳無いが、流れが速くてな。
intとfloatは多態は多態でもオーバーロードの方で、基底クラスは持ってないだろ？
ファイルとディレクトリーでダックタイピングしたけりゃそりゃ結構だが、
基底クラスはいらんだろうと。

void*でいく

あ、あと、ホーミングの話はもう止めた方が良いと思う。
その話とも絡むんだが、さっきの続きで、
(int)+(int)や(float)+(float)の「+」は多態するんだが、
これってマルチメソッドだろ？しかも基底クラス無しでな。
一方でC++やJavaの仮想関数はシングルディスパッチだろ？
しかも基底クラスが必要だ。その辺どう思ってんだってはなしな。
で、ホーミングの話だが、要するに、
foreach(ホーミング弾リスト)
{ ホーミング処理(ホーミング弾, プレイヤー機) }
↑こう書くのが本来の姿で、他は奇形だって話だろ。
古来よりのplus(2, 3)のスタイル。
そんで、このとき動的な多態が出来なくなるのは言語側の問題でしかない訳で。

まだまだミサイルの例えは続くよｗ

ミサイルとホーミングミサイルの違いも吸収できなくて何が多態か！

foreach(ホーミング弾リスト)
{ ホーミング処理(ホーミング弾, プレイヤー機) }
デコイ追えないじゃん。

デコイなんかに騙されてるミサイルは糞

動的な多態したけりゃ、オーバーライドすれば良いっしょ、んでダブルディスパッチにすればいい・・強引にwww

Javaでダブルディスパッチなんか使おうとすると受け入れるメソッド作らなければいけないじゃん・・多態じゃないよね？めんどくせーww

Visitorパターンだ受けいれてやれ

ダブルディスパッチなんて
継承したオブジェクト(静的)な物を引数で渡す(動的)に扱いたい場合にしか使い道思いつかないんだが
これのどこに多態が入るんだ？

>>468
こうすればいいだろ。

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

ここでも多態が生きてくるな。
ターゲットは、プレイヤーかもしれないし、デコイかもしれない。

Visitorパターンなんか、手直ししなければならなくなった時、逃げ出す準備をし始める

物中心で考えるようになったから、出来た思考の負の遺産の最たる物だと思ってる
複雑に絡まったら抜け出せない

>>474
だっせ
ホーミング処理の中にプレイヤーとデコイのコード入れることになんじゃん
カプセル化を欠片も理解してないな

デコイやプレイヤーがないとコンパイルも通らないホーミングミサイル作ってなにが楽しいのか？

もの作りながら考えろ。ぐだぐだ言い訳ばかり。

オーバーロードってコンパイル言語(java)中心の俺には、引数を自在に扱えるようになって便利なんだけど、静的にしか表現出来ないから不便、他言語だと動的に扱えますか？

そこまで解ってんだったら調べろよww
Perlやphpみたいな曖昧な型言語だとオーバーロード自体出来ないよ

引数の数が同じで型が異なるオーバーロードされたメソッドの定義は混乱の元

たくさんメソッド名考えなくて済むから素敵

多態とは

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

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

だと思うんだが・・

カオスだな、誰かまとめてよ

みんなちゃんとまとまてるよ

>>397
ださいっつうか面白みも考える余地もないな
正に機械語

機械に近くなるか、人間に近くなるか

ダサいと思うか、合理的と思うか、人それぞれ。
得てして シンプル イズ ベスト だと思う。

インタフェースを実装する時点でメソッドをオーバーライドしてる。つまり多態だろ

多態が使えないと言った奴は何の言語で書いてんのか気になるんだけど

単にOO厨って言っても流派がいくつかあるから
こういった場での話し合いは混乱するんだよな。ここIDもないし。
多態といっても、
タイミング：　リンク時/実行時
レシーバ：　多重/単一
型制限：　ダックタイピング/インターフェース
と、千差万別。組み合わせの数はとても多いし、加えてテンプレートまで絡んでくる。
だから、OO厨の間でも、
インターフェースが悪だと言う者、逆にそういった型制限こそ必要だと言う者、
単一ディスパッチが古いと言う者、逆に節度だと言う者、等々色々な立場を持ってたりする。
そんで、インターフェースの話が単一ディスパッチに突然飛び火したりして収集が付かなく・・・。
ただ、昔みたいに1+2を「1」に"+2"ってメッセージを云々って解釈は、もう合わなくなってると思う。
C++にすら、テンプレートで良く使うように、オーバーロードによる多重ディスパッチの静的多態が有ったりするので、
多態のことは、引数に基づいて関数の呼び出し先が切り替わる、ぐらいに考えるしかないね。

あ、一応書いておくけど、
俺は、OOPLと言うのなら、多重ディスパッチは言語機能として持ってるべきだが、
言語使用者は、それが有っても使うな、gotoやグローバル変数と同じようにな、って考え。
使わない機能が有ってどうするんだ？って感じだが、
既にC++やJavaに静的多重ディスパッチが実装されてるし、しかも普及しているから、
いまさらOOの定義を単一ディスパッチに制限する意味も無いわけで。でも使うな、と。

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

あれだな、vtableや継承や単一ディスパッチは、
多態の現実的な手抜き実装の手段でしかなかったのに、
それをコンセプトとして前面に押し出したのが失敗だったな。
犬や猫が動物クラスから派生するのは、コンパイラ実装上の都合だからな。
OO設計なんて、コンパイラの都合に合わせて設計しているだけなのに、
何か素晴らしい物のように言われてるのがなんとも。洗脳おそろし。

昨日、出たうんこみたいに長いレスだったな
で？なに？

つまりポインタは使うなってことでしょ

静的多重ディスパッチってなんだよ・・

オーバーロードのことだろうけど、ちゃんとオーバーロードと言ってほしい
もしくはアドホック多相

>>C++にすら、テンプレートで良く使うように、オーバーロードによる多重ディスパッチの静的多態

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

>>多態の結論が引数に基づいて関数の呼び出し先が切り替わる
引数？インスタンスに基づいて変わるって言わない？
上の言い方だとオーバーロードが思い浮かぶんだけど

>>417
ホーミングミサイル　発射　標的：>>417

失敗公表、正恩氏が指示＝演説原稿は自ら執筆−訪朝の米教授
http://www.jiji.com/jc/c?g=int_30&k=2012041900884
　【ソウル時事】１５日の故金日成主席生誕１００周年に合わせ、約１週間にわたり北朝鮮の
平壌を訪れた米ジョージア大の朴漢植教授は１９日、ソウルで取材に応じ、北朝鮮当局者の話
として、金正恩労働党第１書記が、ミサイル発射失敗を隠すべきだとの周囲の助言を振り切り
「そのまま発表しろ」と指示したことを明らかにした。また、正恩氏は閲兵式での演説原稿を
自ら執筆したという。
　ミサイル発射失敗後、側近らが「人民の士気もあるので、隠しましょう」と述べたのに対し、
正恩氏は、外国記者らを招待したのは透明性を担保するためであり、最後までその方向で行か
なければならないとの趣旨を強調し、発表するよう指示した。
　北朝鮮側関係者はミサイルの失敗について「科学というものは、失敗なしに成功はない」と
正当化しつつも、「首領様（金主席）の生誕１００周年は今しかない」と無念な様子だった
という。（2012/04/19-19:14）

>>476
> ホーミング処理の中にプレイヤーとデコイのコード入れることになんじゃん
> カプセル化を欠片も理解してないな
入れることになると思っているお前の頭がダサい。
それしか思いつかんのか馬鹿は？

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

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

もちろんインターフェースを作らなくても、プレイヤーとデコイの両方の祖先クラスを使う方法もあるけど。

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

違うよ。

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

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

多態とオーバーロードの両方を組み合わせることも出来るけど
両方組み合わせれば、両方組み合わせた結果になるだけ。

>>499
それはお前の勝手な脳内定義だろ。

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

仮に、その定義だったとしても、オーバーロードでそれは出来る。
テンプレートを使えばな。

幼年期の終わり

多態の定義ってなんかソースとかあるのかな。

ソースっつーか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)　→　継承

>>503
へえ、多態って結構幅広いのな。

なんでこんなに人によって言い回しが違うのか・・
全部英語の方が誤解ないのにな

え？

>>500
あぁ、それはテンプレートを使うことで
オーバーロードを多態として使うテクニックってだけだ。

>>503
それはただのHaskell用語だ

多重ディスパッチを見ていたらアタマが痛くなった

多重ディスパッチはコードはごちゃごちゃしてるけど、
結局何がしたいのか？ に焦点をあてれば簡単。

実行時型情報があればスマートの実装できる問題を
実行時型情報を使わないで書くやり方だから。

>>508
http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
↑URLを見る限りそうは見えませんが。

>>511
Ruud Kootとかいうやつが
それまでの内容を全部自分の都合のいいように書き換えてる。

これだからwikipediaはあてにならないのだ。

そろそろ頭良い人がまとめてくれるのかな

>>512
少なくともHaskell用語じゃない証拠として
論文を出してみる
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf

次は論文もあてにならないと言い出す予感
正しいのは俺の脳内定義だー

それぞれの派生クラスで処理メソッドを変えてこそのポリモーフィズムだと思っていたんだが、幅広いな

実際殆どの基本書ではポリモというとこれしか書いてないよな

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限定ってことかな

広義のpolymorphismで話してる奴と
OOPLの狭義のpolymorphismで話してる奴が言い争ってた感じか
話が噛み合わんわけだな

OOPだった

でもそうすると、プロトタイプベースやダックタイピングはどうするんだ？
Javascriptはどういう位置づけになるんだ？

馬鹿には無理

概念はなんとなくわかったど
実際に便利に使おうとすると中々思いつかんな
納得する使い道ある？

日常生活においてデータさえありゃ満足で、処理する価値少ないなとつくづく思う

>>498
そしたらもう多態はあきらめるほかないよね？

どんな32bit整数もintで扱えるっていうのはポリモだよね。
特定の数値を表現するのに3bitあれば十分という場合でも32bit確保してるんだから。
実は変数も構造体もポリモだった。

どんな32bit整数値を計算するときも、
数値の大きさによらずCPUのロジックは一定だから、
多態ではない。

> 数値の大きさによらずCPUのロジックは一定
それはどんな内容に対しても呼び出すメソッドは同じと同義。

その広義でポリモと言うとすげー違和感だな
ポリモが一人歩きしてる感じ
厨2のように

あたりまえだが、
処理のロジックが同一なことと、呼び出しが同一な事は、同義ではない。

>>524
全然違うよ。
符号なしで考えると7+1の結果は
32bits整数型: 8
3bits整数型: 0

ふむふむなるほど、キャリアは等しくとも別の代数構造になるのですな

>>529
>>524の説にも全く同意できないが、それ、3bitで十分じゃない時の話じゃん

>>520
構造的部分型（同じシグネチャのメソッド持ってたら多態可能）は
subtype polymorphism の一種

subtype の定義が nominal か structural かの違いだけ
（だけっていうには大きい違いだが...）

変数がROMだのバスだのポートだのに直結してる場合もあるわけで、
変数＝RAMとは限らない。
変数もまた抽象化されたインターフェースの一つ。

何が言いたい

馬鹿には無理

変数が多態でもいいけど、抽象化されたインターフェースってのは言い過ぎなのよ
コンピュータサイエンスでの多態は、仮に今扱うのが
store( a, b );
という関数の呼び出し文だとしたら、
上記の呼び出し文全体で、その振る舞いが多態、ってこと。
変数や引数が共通のインターフェースを提供している、というふうに、
オブジェクト中心に考え直すかどうかは、多態とは関係ない。

本質的に異なるものを同じと言い張るのは良くないぬ

のようなもの

なんとゆるふわな科学

ゆるふわな定義なんだから仕方ない

まさかオブジェクト指向が癒し系だったとかありえんw

いやいや多態の定義がゆるふわってだけで、
オブジェクト指向の定義は・・・・もっとゆるふわだぜ？
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
「〜考え方である。」
だってさ。これ、科学なんですかね。

>>542
情報隠蔽さえあればオブジェクト指向ってことだな

パンツはオブジェクト指向

オブジェクトそのものじゃね

民主党はオブジェクト

オブイェクト

クラスでカプセル化さえできていれば、そのインスタンスがグローバル変数であったとしても、なんら問題ない。
意味のあるまとまりでカプセル化されていることがオブジェクト指向のキモだと思う。

隠蔽はオブジェクト指向以前から確立されてたし。
OOならではってのが欲しいね。

OOはweb2.0レベルのバズワード

>>546
いつガベージコレクトされますか？

>>551
参照されなくならない限り残ります

世界中のえらいひとたちが考え出して使ってるもんなんだから
凡人が理解できなくてもなんら恥じることはない
むしろ理解していると思っていることを恥じるべき

>>523
お前（＝馬鹿）は諦めて下さい。

この業界を諦めて下さい。

Simulaがオブジェクト指向の定義でいいよ

オブジェクト指向で傑作なアイデアは継承だね
こんな密結合を生む馬鹿な機能は他では見ない

そして、継承の他にオブジェクト指向固有の特徴は無い

継承のメリットのほとんどは
delegateとinterfaceで事切れる

委譲と言ったりデリゲートと言ったり、しまいにはコンポジションとか言ったりする

日本語最悪ww

じゃあお前は日本語しゃべるな

事切れるのか

OOPは死んだ

パソコンが欧米で作られたのがいたいな
日本初なら全部日本語で頑張っただろうにww

日本の文字単位がなぁ・・
この文字で頑張ろうとすると死にそう

ホーミングレーザーの話が良かったな。
ターゲットインターフェースを持っていれば
相手がなんでも同じものとして扱える。
多態の便利さが実感できた。

あれはダメな例でしょ。
だって、本来ホーミングミサイルクラスが
ターゲットインターフェースに依存する必要はないもの。
ホーミング処理( ホーミング弾, x, y );
もしくはどうしてもOOPスタイルが好きな人は、
ホーミング弾 . ホーミング処理( x, y )
これで良いだろ。

「ターゲットインターフェースには現在地があればいいな」
↓
「ターゲットには敵味方識別がないとダメだろ常識的に考えて」
↓
「移動予測しないとミサイルなんてあたらねぇよ速度加速度も入れろ」
↓
インターフェースの仕様変更のたびに全部書き換えることに
↓
「最初からターゲットクラスの派生にしとけばよかったんや！」

そんでこれ重要だと思うんだけど、
あるホーミングミサイルが、
今現在どのターゲットを狙っているか、
の紐付け情報の置き場所は、
ホーミングミサイル自身の内部ではなくて、
ゲームクラス、もしくは幾分細分化して、
ホーミング管理クラスだ。

>>565
> だって、本来ホーミングミサイルクラスが
> ターゲットインターフェースに依存する必要はないもの。

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

え、言ってみろｗ

クラスに依存しなければ良い。
以上。

>>566

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

>>498
> もちろんインターフェースを作らなくても、プレイヤーとデコイの両方の祖先クラスを使う方法もあるけど。

>>566
そういう時は、

ターゲットインターフェースを実装した
ターゲットクラスの派生にするんだよ。

オブジェクト思考すぎるな

>>567
> 今現在どのターゲットを狙っているか、
> の紐付け情報の置き場所は、
> ホーミングミサイル自身の内部ではなくて、
> ゲームクラス、もしくは幾分細分化して、
> ホーミング管理クラスだ。

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

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

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

お前の言うとおり、最初から、ホーミングミサイル自身には紐付け情報はない。
ホーミングミサイルはホーミング管理クラスが紐付けた相手を
教えてもらってるに過ぎない。

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;
　}
}

よし

>>568
>インターフェースに依存しないで、どうやって他のオブジェクトを操作するんだ？
ホーミングミサイルが直接管理下にない他のオブジェクトを操作する必要ないんだよ。
つーか、しない方が良い。

>>574
他のオブジェクトを操作しなくても、
他のオブジェクトの情報を取得する必要はあるだろ。

しないとターゲット追えないでしょww

水かけ論になってるよ、出発地点のどこかがおかしいww

>>572
ホーミングミサイルが、ターゲットをホールドするなと言ってるんだ。
紐付け情報の置き場所をホーミングミサイルの中にするな、と
>>567でちゃんとかいてるだろ。

>>575
情報は引数でもらえば良い。
ホーミング処理( ホーミングミサイル, x, y );

ホーミング管理クラスがある。
そのホーミング管理クラスが
ホーミングミサイルにいろいろ指示を出す。

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

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

これも多態の便利さ。

ホーミングミサイルの話から、ホーミング管理クラスの話にすり替えようとしても
無駄だぜ、こっちはこっちで多態の素晴らしさを語ることが可能だからな。

>>579
その使い型は否定してないんだけど。
ただ、例として出てたホーミングミサイルの実装案がお粗末だったから、
例として不適切だと指摘したまで。

>>577
だから、ターゲットをホールドするのは
管理クラスの仕事だとしても、
そのホールドするターゲットに向かっていく処理は
ホーミングミサイルの仕事でしょうがｗ

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

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

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

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

> ホーミング処理( ホーミングミサイル, x, y );
↑変更大変そうだなｗ

>>580
ここはホーミングミサイルを作ろうという話をしてるんじゃなくて
ホーミングミサイルを例にしてオブジェクト指向の話をしてるんだから
的外れだ。

意味が通じてるのなら何の問題もない。

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

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

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

>>581
>それ、引数が変わっただけ。
引数が変わったことで結合度が下がったんだ。
もはやホーミングミサイルがターゲットインターフェースを知る必要はない。

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

その話をしていたのは俺ではない。
俺は無駄な依存関係が嫌いなだけ。

>>583
ターゲットインターフェースをx,yに展開するのは、
ゲームクラスやホーミングクラスだから、
ホーミングミサイルクラスはターゲットインターフェースを知る必要がない。
ホーミングミサイルの結合度が下がる。

>>580
落ち着いて聞いてね。
ホーミングミサイルの実装には二通りあるってだけ

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

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

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

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

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

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

ホーミングミサイルはどう有るべきかなんて的外れもいいとこだ。

曲線弾道と自動追尾がごっちゃになっとるわ

固定座標目標で発射したら追尾できないだろ。常識的に考えて。
敵弾はそれでいいけど自弾は最後まで追尾しないと意味ないぞ

出てきたクラス、インタフェースだけでも列挙した方が良いだろ、わけわからんww

まとめるとこんな感じ。

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

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

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

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

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

簡単なユースケースもお願い

>>585
えと、関数の引数もインターフェースの一つだから。
プリミティブ型もオブジェクトな考え方を知っていれば、

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

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

に見えるよね？

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

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

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

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

全ての始まり、ミサイルインタフェースがなくなってるww

ミサイル管理クラスがミサイルインタフェースだろ

>>585は

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

それは違う。

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

依存してるのがインターフェースであれば、
そのインターフェースを実装したクラスであれば
何にでも置き換えだから、これは結合していることにならない。

>>592
このスレにミサイルインタフェースなんて
言葉は出てきてないよｗ

ミサイルとホーミングミサイルの共通点なんてミサイルって名前ぐらいなもんだな
大抵のゲームであったときの爆発も同じものってことないしな
ミサイルとわざわざ多態でむすんでおくメリットはほぼないな

と思うんだけど
ここまで頑張って多態を使うメリットあるかね？

>>595
お前のレスの中に答えが出てる。

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

これこそ多態。呼び出される爆発メソッドは同じだが
その表現を変えたいってところで使える多態のメリットだ。

もう多態しすぎだろww
自重しなさいwww

>>597
まーたテキトーなレスして
爆発もどう爆発すっかわかんねーぞ
その場で爆発するだけならなげっぱでいいけど
爆発するターゲットが必要だったりするとまたミサイルとホーミングミサイルの関係といっしょだろ？

アイテムで自機ショットをTypeAからTypeBに換装っていうなら
括る意味はあるでしょ

昔作ったゲームで小爆発が短時間に５発以上重なったときは
キャンセルして中爆発に切り替えてほしいってのもあったな
フィルレートおっせから

>>586
抜けてるね。
元々はゲーム中の全オブジェクトの更新を、gameobj->update()
一発で済まそうって人への反論として、ホーミングミサイルの話が出ている。
つまり、updateメソッドに、どうやってターゲットの座標を渡すかが焦点だ。
updateの仮引数が基底クラスで固定されているから、
追加の情報は、グローバル変数か、メンバ変数を経由して渡さなきゃならない。
生成時にパラメータとして渡してあげるのが一般的だが、
通常のミサイルのように普遍な目標値を渡すのなら値のコピーで問題ないが、
ホーミングのような動的に変化して、常に新鮮な値が必要な場合は、さて、どう渡すかって話。
OOPの人たちはすぐにターゲットインターフェースなる物を使って渡すと言うが、
それでは結合度が上がるし、元々update時に新鮮な座標が欲しいってだけなわけだから、
都度都度引数で渡してあげればよいだろう。
ホールドしないからインターフェースも必要なく、結合度も下がる。
つまり、元締めupdate一発方式は、クラス結合度も、オブジェクト参照数も上がるから、良くないね。
そういう話だったはずだが。

「新鮮な位置座標」はゲームオブジェクトそのものじゃないか
すべてのオブジェクトから位置情報を引き出すためにインターフェースが必要だ
遅くてもいいならダックタイピングしてもいいけど

ゲームオブジェクトごとに「移動したら自分の位置情報を
グローバルな位置情報リストに登録しなおすこと」なんて
テストしきれねぇよ

update一発方式を改めろよ雑魚

>ホーミングミサイルはどう有るべきかなんて的外れもいいとこだ。

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

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

彼まだ見てるのかな。

僕はもうunityで作ることにしました

もしかして

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

みたいな管理しろと？
意味ねぇ
ミサイル種別ごとに別々にUpdate呼ぶのかよ
実行時にも余計コストかかってるよ

>>607
この場合においてはそのほうが楽だろうな
だいたいその記述方法でupdate一発方式の場合のやり方を記述できるか？
余計面倒くさいことになると思うぞ

グローバル変数使えば楽は楽だけど
それだと今度はカプセル化っていうかオブジェクト指向っていうか設計思想自体まったく意味ないと思うし

やべぇ意味ない事になっちゃうぞ・・

物体管理オブジェクトが画面上のバルカン弾もミサイルも自機も敵機も保持する
各物体のインスタンス化の際は必ず物体管理オブジェクトへの参照を渡す
ミサイルの推進メソッド内では、そのオーナーである物体管理クラスのインスタンスに対し
「敵陣営機体の位置情報リストをくれ」と尋ねる
ミサイルはその位置情報を元に、最適なターゲットを選定する

これじゃダメなの？

オブジェクト思考の鉄板、「覆う」が機能し始めたぞ

おおぅ

>>610
そのお便利クラスがないとミサイルのクラスはコンパイルもできなくなるんじゃないの？
どうせそんなんなるんだったら素直にグローバル変数でも使ったほうがいいと思うけど？

こうなってしまうから意味がない
間にそんな潤滑油入れたところでなんの意味もない「ヌメェ〜ヌチャ〜」ってするだけ

オブジェクト管理　「お問い合わせのシリアル番号に対応するオブジェクトは
　爆散もしくはゲーム画面外へ消失しました」

って返すのかね
自分で直接オブジェクトを見て爆散判定するよりはスマートだね

>>614
シリアル番号なんて使わないぞ？？？

>>613
ネームスペースを細かく作れるのも多くのOOPLの強みだと思うよ

ここらでプロの実力を魅せて欲しいな

>>617
プロは説明不可能なことしないの
似非プロはなんでもかんでも手を出すけど

ちゃんと工数＝お金に変えられないことははじかないとね

プロの仕事の姿勢がみたいんじゃなくて実力がみたいんですがw

>>615
ガベージコレクションがないから参照使いたくないんじゃないの？

>>620
…そんな前提だったの？
それでも別に生成と消滅を管理オブジェクトでやればよくね？
シリアルも参照もそこからは出ようがないと思うが…

>>619
君には見えないんじゃない？
オブジェクト指向なんてお金にならないもん信仰してる限りは

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

具体的にいうと
非オブジェクト指向で組んだときと比べてどのくらい短縮できる？
という質問に答えられない

オブジェクト指向なんてなかったころにシューティングゲーム作った経験があるなら
そんなえらそうな物言いは絶対できないだろう
そもそもゲームなんて作ったことないんじゃないか

テストコード書くことを考えてもオブジェクト指向なしはありえない

>>622
>>619

> テストコード書くことを考えてもオブジェクト指向なしはありえない

???

まとめ

オブジェクト指向便利。
コードを自然な感じで構成することができる
工数も短くなる

随分くだらない話になっちゃったな
ミサイルの阿呆話の方が面白かったよ

ミサイルをオブジェクト指向で作ると
あんなにもスマートに表現できるとはね。

現実世界におけるミサイル が
そのまま、ミサイルクラスになるところが
素晴らしいよね。

強引すぎるよなww

結局、ミサイルとホーミングミサイルを多態で結びつけるメリットはほぼ無しってことでいいだろ？
ミサイル＋ターゲットってだけに見えるのにな

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

そんなにうまくいかねぇんだって
だから俺等が必要な理由でもあるんだしよ

> 結局、ミサイルとホーミングミサイルを多態で結びつけるメリットはほぼ無しってことでいいだろ？

あれほど、多態のメリットが出てただろ
それに反論したレスあったか？

多態のメリットはすごかった
身震いするほどに。

発射ってメソッドを呼ぶだけで、
どんなタイプのミサイルでもハッシュするんだぜ

すごいよ多態

えー、そこで頑張るのー？
いい加減認めて次のステップへいこうぜ

理解できない馬鹿は、こっちでやれよｗ

ｵﾌﾞｼﾞｪｸﾄ指向は無駄なもの。俺が理解出来ないからね
http://kohada.2ch.net/test/read.cgi/prog/1332351520/

オブジェクト指向を批判する意味がなくなったので
次のステップもないなｗ

>>636
えー、あくまでそういうことにしたいのー？
もうあんま役立たないってわかっただろ？

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

そもそもオブジェクト指向ってこれねー実はねーセミナー向け技術なんだよー
いい加減セミナー商法だったって気づけよー

このおっさんがすごすぎる
ttp://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html

すげー笑えるww

そういや C のポインタの間違った解釈で散々に叩かれていたライターさんがいましたね。エピさん大活躍のやつ。
ポインタを間違えると職業的死亡も同然なんだがそれに比べると、OO を叩いても許されるような気が。

ポインタって参照でしょって感じ？

>>638
負け犬の遠吠えにしか見えないｗｗｗ

>>642
でも、ミサイルとホーミングミサイルの多態のメリットはあげることできなかったよな？

if文地獄から抜け出せる

抜け出した先にはクラス名を考える仕事が待っていた

非OOでも関数名は考えるだろ
変わらんよ

一人で自演してるようなコメばっか
そんなに多態性でもめるかよ

>>643
わざとらしすぎだろ。

ホーミングミサイルと多態のメリットはたくさん出てる。
それをお前は否定することは出来ないはずだぞ。

>>648
でてねーじゃんｗ
何をいってるんだ

ていうか、メリットねーだろ
もう、必要なもんも全然違うし
ちょこっとなんか拡張したら総崩れになるって今回の例でわかっただろ？

>>649
上のほう見ればメリットが出てるのは明らか。
それに対して反論するレスがあるというのなら
それを教えてくれよ。

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

ああ恐ろしい

>>651
多態を使わないからそうなるんだよなｗ

>>651
これは多態を使ったら改善できる
典型的な例だな。

俺は多胎を使ってるつもりなんだが？
馬鹿には見えないのか？

>>651のどこに多態があるんだ？

まあ、C#は全クラスがobjectの派生だけどさ

あ、レスが途中で切れた

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();
}

そこはforeach objectじゃなくてforeach IGameObjectやろ
ひと騙るならもっとうまくやってくれよ

間違った

foreach (GameObject gameObject in GameObjectList){
　　gameObject.Update();
}

これが多態のメリットってやつか！！
すごい！

多態のメリットだすと
あいつが来るぞ。

反論できない奴が！

来るだろうけど、今は来ないよ。

いつもどおり別の話題になって
忘れた頃に来るだろｗ

>>657
え？それ、なにがいいの？
っていうかホーミングのターゲットや索敵機能の話しはどこに反映されてるの？

>>663
> っていうかホーミングのターゲットや索敵機能の話しはどこに反映されてるの？
それはupdate()の中だよ

>>664
なんだよそれ
カプセル化死んでんじゃん
ターゲットリストないとコンパイルできねークラスになってるじゃん

設計なんてドブに捨ててグローバル変数使えよ

IGameObject.Update(GameManager ゲームオブジェクト管理)
よし

>>665
カプセル化は死んでないし、テストドライバを使うことの何がおかしい？

>>667
Updateの中でどうやってやんの？
ホーミングミサイルは敵の熱源ユニット設定値をみてターゲットにするかどうか決めてくださいって
仕様が入ったらコードに敵クラス必要になるで
あくまで上記仕様はシーンに書く処理だと思うな

>>668
まさか、Updateだけで全てを完結させようとしてるの？

ifで書くのとポリモで書くのはどっちもメリットデメリットある
そこのトレードオフができるかできないかが問題

１）ミサイルはコンストラクタで目標オブジェクトを入力するのさ
２）目標オブジェクトの所有者は敵機なり自機なり。自分で更新してくれ
３）ミサイルのUpdateがきたら目標オブジェクトにむかってちょっとだけ動け
４）まあ目標消失したときのことを考えてオブジェクト管理クラスが仲介したほうがいいかもな

わかったな

>>663
だからお前が聞きたいのは多態のメリットだろ？

これが多態のメリットだよ。

>>671
目標をコンストラクタで決めるのはまずくない？
Update内で決めたほうが良いような気がするけど

ふつう撃った後に目標は変わらんだろ。それならコンストラクタ一択じゃん
途中で変えたいならChangeTargetで
チャフなんかで目標変更したいときは管理クラスにおまかせで

最初にターゲットを決めるホーミングミサイルとは別に
途中でターゲットを変えられるホーミングミサイルができたら
どうすんの？

更にその他の機能がついたいろんなミサイルができたらどうするの？
両方をどうやって管理するの？

foreach(ホーミングミサイル ミサイル in GameObjectList)
　ミサイル.目標変更(ゲームオブジェクト管理.AimNear(自機, AimTo.敵機));

こんなもんか
なにか追加処理が来るときはトリガーがあるんだから
そのときに拾い上げればいいだろ？

>>676
AimNearの引数は座標型かな俺なら

>>671
どこにメリットあんだよｗ

結局オブジェクト指向で作る話になってるしｗ

>>676
>668に対応できないじゃん

>>689
オブジェクト指向を使わないと対応できなくても当たり前。

対応させる方法がない。

ゲームオブジェクトのような末端に、末端同士で参照を握り合って
勝手気ままにコミュニケートされちゃ困るよね。

あれは駄目これも駄目とは言うけど何故駄目なのか具体的な説明が欲しい

俺だったら、引数のオブジェクトではなく
オブジェクトのIDをもらうようにして、
で必要なときにゲームシステムから
オブジェクトを取得するようにするな。

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

これもまたオブジェクト指向である。

サポートしたいインターフェースのメソッドの仮引数が、
そのクラスが満たすべき処理をするのに足りてないからといって、
不足分をメンバ変数経由で渡すのなら、
元々そのクラスは、そのインターフェースにふさわしくない。
そうは思わんか？

皆が多態をしたがる。インターフェースを統一したがる。
メソッドの仮引数を統一したがる。無理にでも統一したがる。
処理に足りない情報は、メンバ変数経由でこっそり受け渡し。
インターフェース統一の代償。
あれもこれもホルダーだらけ。裏で何しているか分かりません。
OOの負の一面。

>>685
それは単にお前の設計が下手なだけだよ。

そんな設計にするのは馬鹿といってもいい。

少なくともミサイルに引数なんていらないのに
なんでホーミングミサイルのために引数もたなきゃいけないの？
多態が役に立たないことの証明になるんとちゃいますか？

>>685
それで、仮引数が違う時
オブジェクト指向以外だと
どうするんだい？

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

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

なぜなら仮引数はオブジェクト一つ。
そのオブジェクトから必要なデータを引き出せばいいからだ。
いくらでも拡張可能。

お前ら議論のための議論しかできないのな
それも体をなしてないが

>>687
> 少なくともミサイルに引数なんていらないのに
> なんでホーミングミサイルのために引数もたなきゃいけないの？

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

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

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

これが多態を使わないと、破綻することの証明になってる。

>>687
引数が違うのは、仕様だからどうしようもない。

引数が違っても同じものとして扱わないといけない。
多態だとそれが可能ということ。

俺だったらオブジェクトが能動的に
他のオブジェクトを取得しに行くプログラムは書かないね。
updateの呼び出し元が処理に必要な情報を明示的に渡せば良いし、
そうするのが筋ってもんだ。
でもそうすると、関数の仮引数リストが処理内容によってマチマチになって、
インターフェースの統一は出来ない。多態も出来ない。
でも、仮引数のリストが違うってことは、本質的に違う種類の処理なのだろう。
仮引数リストの違いが縁の切れ目。無理に纏めずに諦めよう。

え？多態を使うから
ミサイルとホーミングミサイルで引数が違うんでしょ？

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

だから、ゲームに出てくるすべてのオブジェクトが
関係ない引数をたくさんもらって、
func(a, b, c, d, e, f, g, h, i, j, k, l, m, n）みたいに
酷いことになるが、それが正義だ。何が悪い。ばーかばーか

というか生成時に画面上の全オブジェクトを参照できるようにするんじゃ駄目なのか
衝突判定とかにも要るだろうし

>>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 が △△ミサイル） {
　略
} 略

>>695

あ、見たこと有るわｗｗｗｗ

>>692
そもそもさ、
仮引数の数が違うのはなぜかというと
オブジェクト指向じゃないからだよ。

オブジェクト指向なら、どんなオブジェクトであっても
仮引数は同じに出来る。

>>694
ゲームクラスは全てのゲームオブジェクトを知ってる必要があるね。
でも、衝突判定をゲームオブジェクト自身が行う必要はなし、
間違ってもゲームオブジェクトがゲームクラスにゲームオブジェクトのリスト頂戴〜、
なんてのはナンセンスだよね。
例えば君が部長で、部下が「うちの部の前メンバーのリスト頂戴〜」
なんて言ってきたら、一体何をおっぱじめる気だ？ってなるよね。

>>698
そうだね。
オブジェクト指向だと
そういうことが可能だよね。

>>695
ターゲットはインターフェースで纏めても良いだろう。
今言ってるのは、
ホーミングミサイルとミサイルのインターフェースを、
updateに関して纏める必要はないねって話で。
だって、ミサイルのupdateにはターゲット座標は要らないけど、
ホーミングミサイルのupdateにはターゲット座標が必要でしょ？
つまり、本質的に別の処理だ。無理に纏める必要はないね。

> 例えば君が部長で、部下が「うちの部の前メンバーのリスト頂戴〜」
> なんて言ってきたら、一体何をおっぱじめる気だ？ってなるよね。

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

何か問題でも？

問題があるのなら、何が問題なのかを
教えてください。

>>700
何を言ってるかさっぱりわからん。

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

つまり何が言いたいのかというと。
updateの時にifがたくさんできるのが正しいのだ
俺が正義だ。

ミサイルのupdateにも
ホーミングミサイルのupdateにも
ターゲットはいらないだろ。

なんでホーミングミサイルのupdateから
ターゲットを取り除いて
同じ引数にする方法がわからないんだ？

オブジェクト指向ができてないと、
オブジェクトごとに引数を変える方法しか思いつかんのだよ。

壁ってやつさ。

>オブジェクト指向なら、どんなオブジェクトであっても
>仮引数は同じに出来る。

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

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

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

なんちゃって。

> 本当に言っている意味が分からない。
うん。馬鹿だからだね。

>>701
部長がgetしてsetするから、本人同士は合う必要なし。
この方がパーツ同士の依存度が低くて良いだろ。

バカには見えないっていうやつはたいていバカ

>>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); ←このメソッドは全てのオブジェクトでバラバラ
}

>>703
メンバ変数経由にするぐらいなら、分けたほうがマシ。
ゲームクラスに問い合わせるのはもっと最悪。

>>707
> 部長がgetしてsetするから、本人同士は合う必要なし。

部下「うちの部の前メンバーのリスト頂戴〜
部長「え？俺がやるの？」
部下「当然ですよ。メンバーのリストを作成するのは部長のお仕事ですよねｗｗｗ」

>>710
じゃあ、最善の方法を使えばいいのでは？

すなわち多態だけど。

>>710
> メンバ変数経由にするぐらいなら、分けたほうがマシ。
分けるってことは、ローカル変数経由にするってこと？

>>709
違うね。
obj_a->execute( a );
obj_b->execute( a, b );
obj_c->execute( a, b, c );
obj_d->execute( a, b, c, d );
だ。
型ごとにコレクションするからね。

>>711
メンバーリストを作るのは部長の仕事だが、
それを部下に教える必要はないし、部下も知る必要はない。
それが身のため。

> 型ごとにコレクションするからね。
つまり、こういうことかいハニー？ｗ

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);
}

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 );
}

オブジェクト指向を使わないと
ここまで醜くなるんだな。

逆に勉強になったわ。逆に。

>>718
逆にじゃなくてそれが目的だろｗ
反面教師。

>>713
呼び出し元を分けるってこと。
ミサイル->update();　と　ホーミングミサイル->update( x, y );　で。
処理に必要なパラメータが違うのだから、違う処理なんだよ。
それでもどうしてもプラグインにでもする必要があるなら纏めるがな。
もっと大きな粒度での話だが。

オブジェクト指向で設計できない人が書くと
>>716みたいになるんだろうな。

ゲームとか、キャラクターの数
何中何百ってなるわけだが
型ごとにコレクションしたら酷いことになるな。

呼び出し元を分けるってこと。
ミサイル->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); ←このメソッドは全てのオブジェクトでバラバラ

>>716
なんでいったんobjにアップキャストする必要があるんだ？
obj_a_collection.add( new obj_a );
でよいだろ。よーわからん。

>>717
あ、これ最高。何が最高って、処理の順番が明確だから。

>>720
> 処理に必要なパラメータが違うのだから、違う処理なんだよ。

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

違う処理でも同じように呼び出せるのが
多態のメリットなわけで。

>>722
だから、何度もいうが、どうしていつもobjにアップキャストするんだ？
アップキャストするとダウンキャストしなきゃならなくなるだろ。

>>723
まさかこんなキモい設計なのか？

class グローバルコレクションクラス {
　　public ミサイル用コレクション
　　public ホーミングミサイル用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
　　public ○用コレクション
}

>>727
それのどこが悪い？

実際のゲームだとそんなもんじゃないぞ。
それの100倍はある。

実際のゲームのフレームワークを見てみようよ。

オブジェクトごとにコレクション作ってるのないから。

>>725
呼び出しが纏まることより、非明示なデータの流れが出来る方が害がある。

>>730
それは真逆だ。

すべての仕事は上司が一人でやる方式

VS

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


お前の会社はどっち？

>>698
なんか感覚で語ってない？
リアルタイムでオブジェクトが動くようなゲーム作ったこと無いから頓珍漢な事言ってるかもしらんが
オブジェクトが自身の動作に必要なものを参照するのは普通じゃね？

>>707
なんか部下の仕事のほとんどを部長がやるハメになりそうな気がするんだが大丈夫か
部下の仕事が増えるたびに部長の仕様も拡張する必要が出てきそうに見える

>>732
部下同士でコミュニケーションとってたらダメだろ。

誰々と話したい時は上司経由で
連絡を取るもんだ。

>>727
これが最高なんだよ。何が最高って、ダウンキャストが発生しない。
仮にオブジェクトが複数のインターフェースを実装している場合は、
それぞれのインターフェースごとのコレクションにも追加されるのな。
で、コレクションごとにfor_each回して処理してく。超シンプル。

>>735
だから、真逆

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

わかってないなら馬鹿。
わかってやってるならアホ

>>735
多態にはアップキャストしか必要ないんだが？

>>733
問題ない問題ない。課長を作れば良い。
ゲーム部ホーミング課長とかな。
ゲームオブジェクトは派遣だね。
ゆえに何も知る必要はない。

>>738
どうした？ 意味不明になってるぞｗ
馬鹿にされ過ぎて
本当に馬鹿になったのか？

>>737
ダウンキャストが必要になるよ。
なぜならオブジェクトごとにメソッドの引数が違うだろ？


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

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

そして馬鹿な設計で、ダメにしているのを
オブジェクト指向のせいにしている。

やあ、これでupdateのメソッドを
共通にする理由が明らかになったじゃないか。

ダウンキャストを無くすためだ。

>そもそもの話、オブジェクトごとにメソッドの引数が
>違うってことがおかしいんだが

だったら今ここで世界共通の唯一の仮引数リストとやらを発表してくれ。

>>741
なんでそんな上流で締め上げちまうんだよ。
オブジェクト間を跨る処理をスマートに処理できるのは上流だけなんだぜ？
後は勝手にやってくれってか？もったいない。

だからメリットねぇだろｗ
ミサイルとホーミングミサイル程度の違いでも多態は吸収不可なんだよ
いつまでやってんだ？お前等
文系ＰＧ邪魔すぎだろ

じゃあ理系プログラマらしくコードで説明してくれ
非OOでミサイルとホーミングミサイルを実装したコード見せて

>>745
やだよ
面倒臭ぇもん

それに、いま、多態によるメリットが見えてなければプログラム組んでも無意味なもんができるだけじゃない？

OOより非OOが勝るところをコードで説明できないの？

>>746
口だけ、いらね

>>748
自己紹介乙

醜い罵り合いになっちゃったな
雑魚ばかり

下級戦士程よ吠えるんだよ。しょうがない

メリットが見えないというより、もう見ないようにしてるだけだろ
ソースも出さないで騙るなよ

シンプルって言葉だけでオブジェクト指向否定してる阿呆もいるし

>>744
専門卒乙

粒度がバラバラ

ソフトウェア開発はカオスという事が解った
オブジェクト指向の利点は、処理なんて何も無いのにあたかも処理してるぜって感じる事じゃねwww

ttp://d.hatena.ne.jp/ryoasai/touch/20110317/1300380540

阿呆にも解りやすくアナロジーで騙ってるのか

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

これが出来てる奴がいかに少ないか
俺も出来ないけどww

>>755
web開発の場合、処理よりデータの扱いの方が大きいからオブジェクト指向が流行ったんだろ

処理が無いとは言いすぎだが、処理より物をとったんだから自然とそうなるのは仕方ない

>>711
違うよ、メンバーリストは既に作成済み(適宜更新されてる)で部長が持ってて
部下はそのリストを部長の許可なしには見れないだけ
真っ当でそ、何かおかしいかな？

カプセル化がまだいたのか
委譲したいって事でしょ。特に問題ないが、先に言い出した時は、インスタンスをまるごと渡すって言い方だったぞ

>>759
え？なんの話？

オブジェクト指向は例えんのが大好きだなって話かな

>>756
つまり「タイムを縮める」ためには「速く走ればいい」ってことだろ
うん、わかるわかる

>758
> 部下はそのリストを部長の許可なしには見れないだけ
> 真っ当でそ、何かおかしいかな？

おかしいだろ。

理由は、>>698を読め

> 例えば君が部長で、部下が「うちの部の前メンバーのリスト頂戴〜」
> なんて言ってきたら、一体何をおっぱじめる気だ？ってなるよね。

オブジェクト指向で処理が見えにく物まで処理すようになった、で良いんじゃないかなww

多態はすごいな。
ミサイルとホーミングミサイルを
綺麗に表現してしまった。

>>765
いや、まったくできてないどころか喧嘩になっとるやんけ

>>766
いや、一人オブジェクト指向がわかってない奴が
オレオレオブジェクト指向して、出来ないと言ってるだけで
他の人はわかってる。

見れる事自体が問題だと言ってるのに、上司経由でなら見て良いでしょ？って言ってるから問題なんだろ
以下にもオブジェクト指向らしい問題だな

>>763
素直に部長に説明するだけでしょ、正当な理由があれば通るしそうでなければ通らないだけだと思うが

じゃあ>>698は馬鹿ということか！

アナロジーは、議論をこじれさせる天才だな
つまり、オブジェクト指向をアナロジーする時に問題は生まれる

>>698に関して言えば、
衝突判定だけをゲームを管理しているオブジェクトが行い、
衝突したらどうなるかは、各オブジェクトに委譲する。

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

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

ゲームオブジェクトのリストが必要な場面はある。
その時、ゲームオブジェクトがゲーム管理オブジェクトに
問い合わせることに何の問題もない。

オブジェクト指向自体がアナロジーの産物

衝突といってもオブジェクトによって引数は違う

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

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


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

根本的に引数を変える方法しか知らないから
このような結論になる。

ミサイルとホーミングミサイルにそれぞれ
衝突メソッド、collision()インターフェースを実装して

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

もしくは各オブジェクト生成時に親オブジェクト
（ゲーム管理オブジェクト）を渡して、そこから取得する方法もある。

オブジェクト指向を批判するＡ君（仮名）が一貫して主張してるのは
オブジェクトには一切の情報を持たせないということ
※現実のミサイルは自分に内蔵するコンピュータで目標捉えて姿勢制御するけどね

たぶん「ミサイル」はオブジェクトじゃなくユニークキーにしたいんだろう
RDBMSの概念でゲームを作ろうとは実務ＳＥらしい考え方

>>769
個人情報集めるのに正当な理由なんて有るわけ無いだろ。
つまり、上司にリストを聞くのはNGってことだ。

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

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

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

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

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

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

オブジェクト指向そのものの問題です。

>>776
> オブジェクト指向を批判するＡ君（仮名）が一貫して主張してるのは
> オブジェクトには一切の情報を持たせないということ

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

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

上司はどんな部下がいるかをすべて把握している
なんでもできるスーパーマン。だからこそ上司になったんだ。

あー、馬鹿のまねをするのは楽しいｗｗ

>>778
部下は情報を持たなくても、
上司が誰か知っていれば（普通知ってる）

必要なときに、上司に問い合わせればいい。
上司から引数リストで貰う必要はない。

つまり、ミサイルもホーミングミサイルも
update()でよくて、

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

コレで引数が共通に出来ます。
多態できます。
すごくスマートですね。

衝突したか否かの判定が
ミサイルとターゲットの両方の型に依存する場合に
どうしてる？

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)
...

> 衝突したか否かの判定が
> ミサイルとターゲットの両方の型に依存する場合に
> どうしてる？

ダブルディスパッチ

一言で終了しちゃったｗ

常識でんがなｗ
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

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

""適応的衝突判定アルゴリズム"" では、通例物体により異なる方法で衝突を判定する必要がある。
典型的な例では、ゲーム開発環境で、宇宙船と小惑星の衝突と、宇宙船と宇宙ステーションの衝突とは異なる方法で計算される。

これもオブジェクト指向の
すごさってやつか！

ダブルディスパッチは全然シンプルなコードにならないけどね
マルチメソッドなら良いのに

オブジェクト指向批判している奴は蚊帳の外
涙目ｗｗｗ

マルチメソッドもOOの範疇だけどな
マルチメソッドできない言語？うんこでしょ

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)

ダブルディスパッチと多重ディスパッチ(マルチメソッド)の違いを教えてくれませんか？

そもそも多態厨は想像力がたりない
引数がちょっと増えたなんてのはあくまで１例であって
そもそも型特有の情報で判定して型特有の情報でないと判定できないチェックが走るかもしれない可能性を
はじめから排除して当たり判定やらターゲット処理を共通化できると勝手に思い込んでいる

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

そもそも判定にしたって込み入ったゲームになるとオブジェクト１対１で済むほうが稀

マルチメソッドを使いたかったら
>>789のどれかを使ってれば良いんじゃね？

MultiJavaとか古過ぎてJava5にすら対応してないけど
そこは気合いで乗り切るってことでさ。

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();
}

書いてみればええねん。もちろん動くで
実際のクラスのコードはいらんやろ

>>791
今更なに必死になってんのさｗ

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

頭固いね。多態それだけしか使っちゃいけない機能じゃない。
多態は既存の機能に＋して使える機能だ。
お前が持ってる全ての技術＋多態（＋その他たくさん）である
俺らのほうが勝ってるのさ

要件は後出し
非OOのコードを示せといっても出さない
多態にはメリットが無いという根拠もださない

これで納得できるほうがおかしい

>>794
実際、ミサイルとホーミングミサイル程度のもんにも使えない現実があるんだけどねｗ

勝ち負けは勝手に出すなよ

>>796
根拠を書いてね
あと非OOならうまく書けるってんならコードもな

>>796

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

反論できない奴が！


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

いつもどおり別の話題になって
忘れた頃に来るだろｗ

マルチメソッドできる => 神
マルチメソッドできない => ゴミ（非OOに毛が生えたようなもん）

同じOOで語るな

>>798
俺は多態にメリットがないって言ってるだけだよ
やめりゃいいじゃん
メリットないんだから
ターゲット程度の要素の増減で設計思想丸つぶれになるんだから
こんなの意味ないんだよバーカ
そんなこともわからないの？

これまで勉強してきたことが全部無駄になっちゃう！
ほら、多態が使えるって頑張って説明しなきゃ！ｗ

変態のどこが悪いんじゃ

>>801
君がメリットを感じないのはもうわかったからわざわざ宣言してくれなくてもいいけど

今まで散々メリットについて説明されてるよね
それについて反論するならちゃんと根拠をかいてくれなきゃ
ただ無いと言い張るだけじゃだれも説得できないよ

interface IGameObject
{
GameObjectInfo GameObjectInfo { get; set; }
void Update();
bool Collision(GameObjectType someone);
}

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

もっとも何百というオブジェクトがリアルタイムで飛び交うんだから
１対１ではチェックしないけどな

> もっとも何百というオブジェクトがリアルタイムで飛び交うんだから
> １対１ではチェックしないけどな
どんだけボロいPC想定してんだと。10年前のPCでも余裕だぞそれ。

？

誰もＰＣで動かすなんて想定してないじゃないか
ゲーム機だったらどうするだ？

１００個が１０００個になって１万個になったときにハングするようなコードは
書きたくないなぁ

>>801

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

理由はコレかい？

ｵﾌﾞｼﾞｪｸﾄ指向は無駄なもの。俺が理解出来ないからね
http://kohada.2ch.net/test/read.cgi/prog/1332351520/

多態したいがために仕様を複雑にしようとしてる奴がいるな。
オブジェクト指向以前に仕様をシンプルにまとめる努力しろと思う。

そもそも仕様が示されてない

仕様はミサイルとホーミングミサイルだよ。

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

実装してしまったので、なかったことにしたいんだろうなｗ

仕様が無い物までプログラミングするのが、オブジェクト指向の強みだろ

手続き型で表せる筈が無い

>>813
それくらい手続き型でも出来る。
ナメんな馬鹿野郎

Q. ○○とか××とかにも対応できるように汎用性を持たせるべきだ。
A. ○○することなんて一生ねーよバカ野郎。

多態には高度な先見の明が要求されます。
ただの妄想厨は設計を複雑にするだけなので嫌われます。

> 多態には高度な先見の明が要求されます。

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

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

xとかyとか、あるオブジェクトに依存した
引数を渡す。なんてことをするから拡張性がなくなるんだよ。

そんなコードを見てみたいな

プログラマに必要な、抽象化って能力の話だよね。
実力がない人は、抽象化能力がないため
つい具体的な例になってしまう。

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

抽象化ができる人なら逆に具体的なクラスから
抽象的なクラスを導くことが出来る。
そのため設計がシンプルになる。

馬鹿 → 全てに対応しようとして破綻
プログラマ → 全てに対応可能な設計にしておき、必要なった時に後から追加する。シンプル

class ゲーム管理 implements
                ゲームオブジェクトA問い合わせインターフェース,
                ゲームオブジェクトB問い合わせインターフェース,
                ゲームオブジェクトC問い合わせインターフェース,
                ゲームオブジェクトD問い合わせインターフェース,
                                ...
                ゲームオブジェクトZ問い合わせインターフェース
{
}

馬鹿 → 全てに対応しようとして破綻
天才→全てに対応する

馬鹿と天才は紙一重

>>821
全てに対応することは不可能だよ。
だから、全てに対応可能な設計にする。

後から機能を追加できるようにしておけば
必要になった時に考えればいいから、
先見の明が必要なくなる。

>>820
オブジェクト指向的には0点だね。

それはオブジェクト指向ではないよ。

>>820って型ごとにコレクション持つとか
言っていた馬鹿と同じやつじゃね？
同じ事やってるしｗ

俺はホーミングミサイルの例でいくなら、毎ターン、ホーミングミサイル側で好き勝手やらせるんじゃなくて、
ホーミングオブジェクト作って、対象が移動したぞっていうイベントを通知するような感じでやるかな。

型ごとにコレクションって当たり前だと思うんだけど。
どう考えても、ゲームクラスなどの管理クラスは、
アップキャスト発生前の一番情報量の多い状態で、
インスタンスを握っておきたいだろ。
オブジェクトがインターフェースを公開するなら、
そのインターフェースも毎々にコレクションだ。
それに加えて、用途ごとに分けたコレクションもする。
その方が検索が早かったり、そもそも実行のタイミングが異なってて、
同一リストで管理する意味がなかったりする場合などな。
でもそれ以前に型やインターフェースごとのコレクション無しでは、
多態すらおぼつかない。
仮に全ゲームオブジェクトを全てGameObjClassでコレクトして、
とりあえず毎フレームupdate呼ぶんで、あとは各自よろしく、では、
全ての変数がグローバル変数なのと変わらない。
だから、型やインターフェースごとのコレクションは最低限の常識では。

> 型ごとにコレクションって当たり前だと思うんだけど。

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

ムダでしかない。
メリットもない。

>>826
どのゲーム本にそんな、常識が乗ってましたか？

素人が口出すなよ。

> どう考えても、ゲームクラスなどの管理クラスは、
> アップキャスト発生前の一番情報量の多い状態で、
> インスタンスを握っておきたいだろ。
無い無いｗ

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

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

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

これはオブジェクト指向というよりプログラム開発全般で
やってはならない事の一つ。

> どう考えても、ゲームクラスなどの管理クラスは、
> アップキャスト発生前の一番情報量の多い状態で、
> インスタンスを握っておきたいだろ。

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

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

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

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

最悪の最悪な設計。

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, ... {
    ...
}

結合度を下げることからもゲーム管理クラスは、
各クラスの詳細を知ってはいけないことは明らかだよな。

生成だけして更新のタイミング等でupdateを呼び出すだけ
ぐらいまでいったらかなり簡単にできるんだろうな
と思いつつ毎回神クラス作ってる

>>829
>ゲームの管理クラスは、すべてのオブジェクト
>ベースクラスしか知る必要はない。
ゲームオブジェ据え置きの固定的なupdateでの更新方式？
とりあえず、処理の実行順が問題にならない程度には、
型やインターフェースや用途ごとにコレクションを分けたほうが良いのでは？
引数固定で追加の情報は各自勝手に現地調達してねってのも、
むしろ逆行しててBASIC臭い。ゲームPGにはお似合いか。
でも、ゲームクラスはもうちょっと仕事した方が良いんじゃない？
定期的にキックするだけでは、あまりにも無能なのでは。

>ゲームの管理クラスがすべてのオブジェクトのクラスに
>依存しているということ
アプリケーションが個々のパーツに依存するのは当たり前だと思うがね。
パーツを集めてきて、機能するようにしたのが、アプリケーションなんだから。
プラグインのような形式なら別だが。ゲームはそういう類じゃないし。

>>830
>神オブジェクト
神オブジェクトを分割すれば良い。例えばゲームなら、
・描画エンジン
・サウンドエンジン
・当たり判定エンジン
などなど。
纏まった機能ごとに分けるのがポイントだな。
というのも、機能はオブジェクト同士の相互作用によって齎されるけど、
相互作用や関わり合いってのは非常に危険な要素なわけだ。
だから、機能単位で纏め上げる訳だ。
オブジェクトがどうこう、ってよりは、相互作用を管理したいんだよ。

>>834
なんでもあらわすベースクラスだから逆になんにもできないベースクラスでもある
つまり意味ないんだよｗ
タスクシステムといっしょ
なんにもできない管理クラスｗ

オブジェクト指向の一番の弊害は
お前らのようなオレオレ・オブジェクト恥垢厨が涌くことだな。

オレオレオブジェクト指向は後のメンテで苦労する。

メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください。

ワロタwww

やっぱりミサイルとホーミングミサイルを
綺麗に実装したオブジェクト指向と多態はすごいと思うよ。

>>836
なにいってんのお前？
何も出来ないんじゃなくて、
管理だけをする管理オブジェクトなんだよ。

そりゃ管理以外のことは何も出来ないよ。
当たり前だろ、結合度を下げてるんだから
これが正しい

>>834
> アプリケーションが個々のパーツに依存するのは当たり前だと思うがね。

あたりまえじゃないよ。
素人かよ。

>>840
役に立つと思ってるのはお前だけってねｗ

>>842
役に立たないと思ってるのはお前だけという意味か？ｗ

馬鹿は一つのクラスに
いろんな機能ものを詰め込むからなｗ

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

幼稚園児かｗ

ＣＯＭ打ち麻雀ゲームがあったとして
プレイヤークラスがあって
派生したＣＯＭプレイヤークラスがあって
そこにいるＡＩは

他家の捨て牌や点数みるのに
雀卓オブジェクトを参照するよ

>>845
それで？

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

哀れだね。

ミサイルとホーミングミサイルの多態は結局できなかったわけだな
オブジェクト指向厨はセミナー商法に騙されてしまった哀れな子羊だったのだ

COMプレイヤーといっても、
いろんなAIがいる。

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

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

さすが多態だ。

>>847
必死すぎだろｗ
一体お前度のレスのことを言ってるんだ？
言えないだろ？それが答えだよ。

>>849
なになに？
ミサイルとホーミングミサイルの多態はうまくできたの？

何度目のループだよ
めんどくせーな

特にスレも変わってないんだからアンカー書くだけだけど
そんなレスないからいいわけ考えるのが大変なんだよな

>>850
うん。できた。

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

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

いわく。すべての型に依存した神オブジェクトを作れ！だとさｗ

>>850
>>793

索敵機能とデコイも入った？
なんか多態でやると簡単だって途中のレスで出てたけど？

>>855
とっくに対応してる。

あ、あの馬鹿は間違った
やり方をして、デコイを引数に入れるとか
めちゃくちゃな事言っていたけどｗ

素敵機能もデコイも
きちんと抽象化ができていれば
簡単に対応できた。

人間魚雷はデコイに騙されないとか
ステルス機能付きの敵は索敵されないとか
でも新型レーダー搭載ミサイルならステルス機能付きの敵を発見できる
しかし新型ステルスな敵は索敵されない
でもしかし最新型レーダーv2搭載ミサイルはそんな敵も索敵できるが
やっぱり超ステルス搭載な敵は索敵されない

以下無限に仕様が拡大していきますが、貴方の多態は大丈夫ですか？

>>858
はい。

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

逆に言えばそんなものに対応するのは
難しいと考えてる時点で、
あ、わかってないこいつｗって言われる原因です。

>>858のような仕様全てに対応した
神オブジェクトを作ろうとするから破綻するんだよねｗ

これをすべてupdate()で実現するってすごいなぁ（馬鹿じゃねｗ）

>>861
じゃあお前は何で実現するんだい（ほら、答えてみろｗっｗ）

>>861
updateといっても神オブジェクトではなく
各クラスのそれぞれのupdateなのだから
何の問題もない。

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

もちろんupdateから、ゲーム管理システムを
読み出すことも可能なので、
お前が考えるような、変なことは起きない。

複数のミサイルがフォーメーションを組むだの、
隊長ミサイルが破壊されたらすぐに別のミサイルが隊長になって先導するだの
敵の迎撃や障害物を回避する機能があるだの、敵の弱点を分析してそこを狙うだの
ミサイルが一つ迎撃されるたびにHDDのエロ画像が一つ消去されるだの。

そんな多彩な可能性を可能なままにするために、
どれだけの機能と権限が末端のオブジェクトからリクエスト可能な状態にされるというのか。

> 複数のミサイルがフォーメーションを組むだの、

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

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

こんなこともすぐに思いつかない？　本当に素人だなｗ

そりゃ、いつも神オブジェクトしている奴には
難しいだろうさｗ

なんで作っちゃうんですかね？＞神クラス
多態を実現するために一箇所にまとめたグローバルインスタンスホルダーがどうしてもほしくなっちゃうんですかね？
引数同一にしたいから？（もう設計歪んでるだろｗ）

>>865
あるミサイルが複数のフォーメーションに所属していた場合はどうすんだとか。

>>848
例えば、10種類のAIがあって、それぞれ処理に必要としている情報が違うのなら、
呼び出し時にゲームクラスから明示的に処理に必要な情報だけを渡してあげたほうが、より安全だ。
無理にインターフェースを統一したために、処理に必要な情報が引数で渡らず、追加情報を得るために、
ぞれぞれのAIが勝手気ままに雀卓にアクセスするのなら、
それは、グローバル変数全盛期のBASICまで逆戻りだ。
そもそも、AI処理に必要な情報を、ゲームクラスが集めて渡すか、AIが各自で集めるか、の差でしかない。
前者と後者でコードの量は同等。処理に必要な情報が違った時点で、
多態でコードの量は減らない。なぜならAIが自力で情報を得るためのコードが追加されるから。
なら、前者の方が、情報の受け渡し箇所が集約されていて、管理のしやすさで分がある。

>しかし、その違いを吸収することが可能。
多態は引数リストが同じ場合のみしか吸収する力はない。
麻雀の例では、多態の為に引数リストを揃えたつけを、
雀卓参照というグローバル変数的発想で補っているに過ぎない。
だから、君の主張していることは、多態は便利、ではなくて、グローバル変数は便利、だ。

フォーメーション機能語りたいならアクションゲームの敵想定のがいいな

個別のオブジェクトのＡＩとチームのＡＩと
起こした行動に対する結果or現在の状況からチームＡＩの次の行動の方針決定
→個別のオブジェクトのＡＩの行動決定までの流れがうまく動けばうれしいね

>>868
OO以外ではどうやって解決してんの？
自分がどうやって解決してるのか書いてくれなきゃフェアじゃないよ

多態よりマシな解決法があるんでしょ？

>>871
簡単だよ。
そんなクソめんどくさい仕様思いついた奴を蹴飛ばして
仕様を撤回させるんだ。

じゃあ俺もお前を蹴飛ばして仕様を撤回させるわｗ

OOならもしやと思って期待していたんだが、がっかりだな。

OOだって銀の弾丸じゃないんだからひたすら後付されたら
いつかは対応できなくなるに決まってんじゃん

いいや、ミサイルとホーミングミサイル（ミサイル＋ターゲット）の時点でもう無理が出てたよ

どこに無理が出てるのか具体的に説明してね

commandパターン見習えよ・・

なんでもかんでも引数しようとすんなよ

グローバルに追い出したり神クラスを作ってその場凌ぎを繰り返しているうちにカオスになっていくのさ
かといって1から書き直すというのも碌な結果にならないという・・・

そういう設計になってるレスがどこにあるの？
同じスレだしアンカー書くだけだよね？

たぶん、この流れ
例のオブジェクト指向否定野郎には
苦しい流れだろうｗ

結局、多態なんて役たってなくてグローバル変数使ってただけってことでしょ？
満足した？

C/C++のvoid*のがいくらかましだったな

>>882
そういう設計になってるレスがどこにあるの？
同じスレだしアンカー書くだけだよね？

>>869
グローバル変数の問題点とは何か、が全く解ってないな

オブジェクト指向はグローバル変数に
Singletonパターンなんて別名を与えるくらい
グローバル変数大好き

意外と流れが速いから今のうちに言っとくけど
似たようなスレがあるから次スレは立てずにこっちに移動してね

オブジェクト指向は本当に正しいのか？
http://toro.2ch.net/test/read.cgi/tech/1331443855/

>>886
いや、だからぁｗ

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

お前が考えてる変なものを
お前が勝手にごちゃごちゃいってるだけ。

>>886
その発言は、流石にあきれるぞｗｗ

つうか釣られすぎだな

>>889
そーゆー発言はミサイルとホーミングミサイルを多態でうまくまとめてみせてからしてよ
だっせ

引数ボーイの暴れっぷりはすごいな。

ヌルいレベルで返すと強めな反撃を受ける辺りが話し相手として調度いいんだろうと予想

関数引数の狭いスコープじゃ僕ちんプログラム組めないから
神オブジェクトの参照をメンバ変数に持っておいて
任意の情報に自由にアクセスするよ

「そもそも」で検索すると、このｽﾚは20ﾚｽ検出される。

チーム機残数３と４でフォーメーションが違うっていうなら
フォーメーション指示クラスが必要だな
チーム内番号に応じてリーダー機に対する相対位置を返す
ゲームじゃ味方同士にはコリジョンないから楽なもんだな

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

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

まあお金払ってくれるなら考えてもいいよ

もし地形情報その他移送の際にワールド情報を参照したいなら
Updateのときにまるっと渡してやればいい

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

ありもしない状況のときを考えてシステムをめちゃくちゃにする
こんな人間が居たら毎日デスマーチだろうな

解読求む

初期の設計段階では考慮されてない要件が後になって降ってくる
というあるあるネタ

>>869
プレイヤーが作ったAI同士の対戦させたいときには、
プレイヤーにゲームコードを書き換えさせるの？

PG○ま

なんで自分だけ天才ってことにしたいんだろうな

負けを認める勇気

インターフェース変えると呼び出し側も変更が必要になること、変更すればするほどバグ発生の可能性が増えることにいつになったら気付くんだ？

>>1を一部引用

OOPを十分に理解してないから痛々しい

>>898
たしかにそれはあるが、それにしても基本的なところで困り過ぎ。
コードを抽象化してないせいだね。

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

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

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

ゲーム管理クラスは何もせずに、新しいオブジェクトに対応したということは、
無限のオブジェクトに対応してるということ。あとは追加したいオブジェクトだけを作ればいい。

まあようするに、抽象化、継承、多態、カプセル化
これらが重要ってこと。当たり前か。

純粋オブジェクト指向論者や定義厨が出てくると話がややこしくなるけど

実用的には
>抽象化、継承、多態、カプセル化
これで十分だよね

下手の考え休むに似たり

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

そんなのを考える必要がある設計がそもそもおかしい。

何も考えて無いと仕様変更した奴を蹴飛ばして撤回させるタイミングを外します。

解読求む

安易に思いつきで仕様変更提案してくる奴を
その場で蹴飛ばして「んなもんやってられっかボケェっ！！」ってやるためには
あらかじめ出来ることとめんどくさいことを整理しておく必要があると思うのです。

荒らしたいだけ

何にでも対応できる設計をしてる気になってると、
上司や同僚やクライアントの安易な思いつきに安易に「ＯＫ」出してしまいがちですが、
いざやってみて消耗して「やっぱりダメでした」ってやるのはもうイヤダ。

単にコミュニケーション能力不足なだけじゃないかｗ

何にでも対応できる設計にしておくのは当たり前で
その上で答えを出すのはちゃんと検証してからだろ。

なんでも出来ませんって言ってれば
仕事なくなる。

つか、普通はできなっていうのはNGで
それをするためにはどれだけ時間がかかるとか
いうのが正解なんだが。


ま、デスマしてるとこには
無理な話だなｗ

デスマしてんのは仕様変更してくる奴が悪い
俺の技術力に問題はない。

自分が無いものねだりしてるだけってことに気付けないと悲惨

仕様変更に愚痴言ってるのは
オブジェクト指向否定してたやつだったな。

まあ、そりゃそうだろうなｗ

ここのスレ名見てみ、弊害だぜ
持ち上げてどうすんのよ

>新しいオブジェクトができたら、ゲーム管理クラスが新しいオブジェクトに対応した
>コードを書く必要がある。こんなのやってたら破綻するのは目に見えてる。
メインプログラマを経由しないと、あたらしい事は出来ない。スバラシイ。

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

>ゲーム管理クラスは何もせずに、新しいオブジェクトに対応したということは、
>無限のオブジェクトに対応してるということ。あとは追加したいオブジェクトだけを作ればいい。
バグの可能性も無限大www
制限こそ真の武器。OO/非OO関係なくね。
何でもできる は 何でも起きる。
本人は一生懸命カプセル化を進めたはずなのに、
実は何でも有りのアクセス不法地帯になってるって、かなり笑えるよね。

ゲームは処理メインだから手続きの方が良いんじゃない
ぐらいの言い方なら可愛げがあるが、なぜそう嘲笑うように騙るのかねww

>>921
>制限こそ真の武器
つまりその制限をどうやって管理するかって事じゃね？
>誰が何処で何を参照し
抽象化がしっかりしてないから誰がどこで何を参照し更新してるかビクビくしなきゃならない。
>メインプログラマを経由しないと
カプセル化はメインプログラマの生命をも守る様だなw