OOとゲームプログラミング

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

**名無しさん＠お腹いっぱい。** · 01/11/16 18:20

>>268
VC++使ってると全然気にならないんだけどな。

**名無しさん＠お腹いっぱい。** · 01/11/16 23:37

Delphi使ってると再コンパイルの手間すら気にならんけどな。

**名無しさん＠お腹いっぱい。** · 01/11/17 00:32

仕様がしっかりしている場合に限るけれど、
こーゆー書き方なら、たまぁにする。
class CMain;
class CSub
{
public:
CSub(){}
virtual ~CSub(){}
virtual void FunkA(CMain*pMain) = 0;
virtual void FunkB(CMain*pMain) = 0;
};
class CSubNull : public CSub
{
public:
void FunkA(CMain*){}
void FunkB(CMain*){}
};
class CMain
{
CSub*m_pSub;
static CSubNull m_SubNull;
public:
CMain(){ m_pSub = &m_SubNull; }
virtual ~CMain(){}
void FunkA(){ m_pSub -> FunkA(this); }
void FunkB(){ m_pSub -> FunkB(this); }
void SetSub(CSub*pSub)
{
if(pSub == NULL)pSub = &m_SubNull;
m_pSub = pSub;
}
CSub*GetSub(){ return m_pSub; }
};

**名無しさん＠お腹いっぱい。** · 01/11/17 00:51

それは立派なStateパターンでんな。

**名無しさん＠お腹いっぱい。** · 01/11/17 13:55

C使いでC++がダメ!って言う人は、実装継承とか深い継承とかを試してみてダメって言ってる気がする。
デザインパターン勉強すれば便利に使えるんだけど、使えるかどうか試してみるだけの人にデザパタ勉強しろとは言えないからなぁ。

**名無しさん＠お腹いっぱい。** · 01/11/17 18:20

OOの真髄はデザインパターンによるコーディングのパターン、及びテンプレート化だからなぁ･･･
ボトルネックとか、無駄な継承等を最適化していったら、どっかで既に使われていたパタｰンの
亜流だったなんての事は、実際かなりあったよ･･･

**名無しさん＠お腹いっぱい。** · 01/11/17 19:25

>>273
意味不明

**名無しさん＠お腹いっぱい。** · 01/11/18 02:39

>>275
デザパタの学習をやり出せば解る｡
デザパタはOOを十分理解してる事が前提で話を進めてるので｡

ラム · 01/11/18 09:59

ageるっちゃ。

**名無しさん＠お腹いっぱい。** · 01/11/18 10:48

>>276
違う、そういう意味じゃない。デザインパターンまで実務に使ってる。
キミの言ってることのつながりが全然わからないと言っている。

**名無しさん＠お腹いっぱい。** · 01/11/18 20:54

ゲ技版にもデザパタ馬鹿が出るのか・・・・。

**名無しさん＠お腹いっぱい。** · 01/11/18 21:18

別になあ、今更デザパタでもなかろうに。
つかっててあたりまえだといいたいんだろう？ >>279

**名無しさん＠お腹いっぱい。** · 01/11/18 22:29

Design Pattern for Computer Games
http://www.totempole.net/patterns/gamepatterns.html
こんな試みもあるがね。

**名無しさん＠お腹いっぱい。** · 01/11/19 22:42

とてもヨワヨワな質問でスマソ。
カードゲームを作ろうとしたときカード１枚１枚をクラスとして扱う？
カードの枚数だけクラスが出来るんかな…

**名無しさん＠お腹いっぱい。** · 01/11/19 23:38

>>282
MT:G 系のカードごとにルールがあるカードゲーム？
カードクラスとルールクラスで構成するか、それぞれをクラスにするかだね。
Prototype や Flyweight パターンを参照してみて。
↓だけじゃ分からないと思うけど、参考までに。
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/prototype.html
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/flyweight.html

**名無しさん＠お腹いっぱい。** · 01/11/20 00:08

さっそくのお答えありがとです。
Flyweight パターンが近そうなので
もうちょっと勉強してみます。

**名無しさん＠お腹いっぱい。** · 01/11/20 20:34

太閤立志伝Iは、オールアセンブラと思われる古いゲームだが
オブジェクト志向してたんじゃないだろうか。
基底クラス武将を継承するプレイヤー武将クラス、大名武将クラス、一般武将クラス。
それらのオブジェクトが家臣団ツリー構造で管理され、
マルチスレッド処理で並列で動いてる。
当時これをつくったひとは本当に天才だとおもう。
ずっと後に出た、これと似たシステムのガンパレードマーチはさんざん自慢しまくってたが。

**名無しさん＠お腹いっぱい。** · 01/11/20 21:25

大抵のゲームプログラマーはとっくの昔に自分でＯＯＰやデザパタ発見してるよ。
本に出てるのは他人に教えても良いゴミテクと知れや。

**名無しさん＠お腹いっぱい。** · 01/11/20 23:36

>>99

例えば、ゲームボーイとか、タイトなパフォーマンスが要求されるとことか、
まぁあったでしょうけど、やっぱ今後は開発効率の向上が必須項目。

例えば、全部組み込みJavaでゲームが書かれるようなことにも数年後にはなり
かねないしさ。

>101
モジュールやデータ構想の勉強っって何ですか？

**名無しさん＠お腹いっぱい。** · 01/11/20 23:43

タイトなパフォーマンスが要求されないゲームってＰＣぐらいしかないんじゃ？
アマですか＞287

**名無しさん＠お腹いっぱい。** · 01/11/21 07:35

>>286
こういうやつよくいるわ。

**名無しさん＠お腹いっぱい。** · 01/11/21 11:44

ま、とりあえず>>286がデザインパターンの存在意義を
理解してないのは分かるわねー。

**名無しさん＠お腹いっぱい。** · 01/11/21 12:33

個人的にはパフォーマンスよりも
開発効率のほうが今後のネックだと思うが。
納期に追われたこと無いの？>288

**名無しさん＠お腹いっぱい。** · 01/11/21 17:02

＋→描画デバイス
＋→シーン＋→キャラクタ→モーション
　　　　　＋→キャラクタ→モーション
なんて風にオブジェクトを階層構造にしてるとき
キャラクタの描画メッセージは、どいつがどのように送りますか？
それとも、こんな構造にはしませんか。

**名無しさん＠お腹いっぱい。** · 01/11/21 20:28

>>286
確かにデザパタ厨房は、
今は物理シミュレーションの時代だとか言ってるゲーハー厨並に痛いけど
（そんなのファミコン時代からやってるって…）

デザインパターン自体には、
昔からの手法に共通の名前を与えるという意義はあると思う。

**名無しさん＠お腹いっぱい。** · 01/11/21 20:52

>>271-272みたいな感じでんな。
プログラマ間の意思疎通がシャア並みに速くなる。

**286** · 01/11/21 23:12

>>293
逆に名前がついてないと頑なに認めないのが一杯居て困る事多し。
１）マルチスレッド的プログラム構造の実際。
２）外部からの通信でどのような状態にも自由に遷移できる構造
３）どのような状態でもメッセージを受け取れる構造
４）正規の処理以外のエラー処理への随時対応可能構造
といった事を教えても「スタイルの違い」と理解せず変更せず、
挙句の果てに人のバグだと言い始める逐次プログラマーの多いこと
多いこと。

**名無しさん＠お腹いっぱい。** · 01/11/21 23:16

それは、貴殿が新しいパターンを作って文書化すればいいのでわ。
GoFとかに載ってるのだけがすべてじゃないよ。

HN · 01/11/21 23:22

> http://www1.linkclub.or.jp/~zhidao/zlab/
> オブジェクト指向を用いてぷよぷよを作る記事がある。

ウェブページだけ見ていて、ソースはそんなに真剣には見てはいなんだけど・・・。

これはこれで、イイっていえばイイのかもしれないんですけども。
オブジェクト指向の例題とするには納得しかねるなぁ～。

1)
連鎖発生時の「ファイヤ～」「ばよえ～ん」とか、ここはキャラクター
が変わることによってメッセージが変わるわけだから、ここでこそ、
Character クラスでも作るのがイイのでは。

2)
Puyo クラスの中に座標を持っているんですけど、これは
明らかに無意味なような気が。

まぁもし、ぷよ一つ一つが、特別な性質を持っていて（例えば、
赤ぷよだけ５つ繋がらないと消えないとか、黄色ぷよを消すと
回りのぷよも変色するとか）そういうことなら、Puyo クラス
でも作って、自分が存在する座標とゲームフィールドの参照を
持って設計するのが、正しいと思うんですけど・・・、うーん、
ぷよぷよっていうゲームの場合、ルールは完全にゲームフィー
ルド毎に決められてるんだから、べつにint型の二次元配列
でやっても、一向にかまわないと思いますよ。

後は、MVC の分離をきっちりやるといいのかなぁ～。でもこれも
単純なゲームにおいてはほとんど無意味だからやらなくていいか。

まぁ、ぷよぷよというゲームの本質とＯＯＰはあまり関係ないやね。

HN · 01/11/21 23:27

Model（ゲームデザインの部分）のコト書いたんですけども、

View（表示する部分）の話でしたら、Puyo クラス書く意味は
大いにありますよね。消すときのエフェクトは、ぷよの色ごと
に違ったりしますから、その Puyo クラスごとに絵画方法を
定義すればラクチン。

HN · 01/11/21 23:28

ごめん、↑の２つ、ミス

**マルチポストは止めよう** · 01/11/21 23:36

どうでもいいけど語尾の『なぁ～。』って口癖？

**名前は開発中のものです。** · 01/11/25 17:49

age

**きえさっぱ** · 01/11/26 01:21

んー、ぷよぷよをＯＯ学習のサンプル題材として議論しているのは
分かるんだけど、ベーシックでもできるものなので、題材として
適切かどうかはちょっと疑問だと思うー

「再帰呼び出し学習材料」としてなら、ぷよぷよは好材料だと思うけど。

＿ · 01/12/01 02:43

age
結局、タスクマネージャC++版は、デキなんですかね？

**名前は開発中のものです。** · 01/12/02 13:44

＞デキなんですかね？

どう言う意味ですか？

**名前は開発中のものです。** · 01/12/12 13:09

salvAGE

**名前は開発中のものです。** · 01/12/17 16:26

OOやるならレミングスとかが良いんじゃないかなー。
正直ぷよぷよはOO向きではないよね。

**名前は開発中のものです。** · 01/12/31 23:56

下がってる…。

やっぱり RPG 系こそOOの真価が発揮されると思うんだけど。

**名前は開発中のものです。** · 02/01/01 12:43

というか日常的に考えてシナリオとかプロジェクトというものをOO的に変換して
うまくいかないんだから
プログラムを全部OOでやろうってのがどだい間違いでは？

**名前は開発中のものです。** · 02/01/01 14:59

>>308
じゃあ何ならうまくできるの？
構造化言語？アセンブラ？

速度的な問題点っていうのは別として、
組み方としてうまくいかないって言う人は絶対 OO 解っていない人だよ。

**名前は開発中のものです。** · 02/01/01 15:56

全部OOでやろうってのは非効率的（になることが多い）。

**名前は開発中のものです。** · 02/01/01 16:03

デザイナが書くためのスクリプトがオブジェクト指向だった日には
そりゃもう大変。

**名前は開発中のものです。** · 02/01/01 16:47

>>309
もうアフォかヴァカかと。

**名前は開発中のものです。** · 02/01/01 17:03

とにかく、ゲームプログラミングには適してない。

**名前は開発中のものです。** · 02/01/01 18:36

で、OO否定派で、ゲーム以外の物はOOで作ってるって人はいないの？
そういう人のゲームにOOは(どういう理由で)向いてないっていう意見キボーン。

そうじゃないやつはOO理解できてないだけでしょ？
つまり銀行でCOBOL書いてるやつらと一緒。
やつらでさえ最近はJavaにお熱みたいだから、あと数年でCOBOLer以下になるね、君ら。

**名前は開発中のものです。** · 02/01/01 18:43

>>314
Ｃ言語はそこまでダメじゃないと思うよ。
単純に乗り換えるコストが見合わないってだけだろうね。
その人にとって。ボクにとって。（ぉ

そのうちやるさｗ

**314** · 02/01/01 19:02

>>315
(私以外の)OO派もきっとCとかアセンブラが駄目とは思っていないと思う。実際今までCでたくさんの名作が作られてきているから。

でも、そこには血もにじむような努力があったわけでしょう？
それこそ場合によっては発狂する人が出るくらいの。

そういうの、終わりにしませんか？っていう事です。
OOが解決策になりませんか？って言いたいんです。

みんなが幸せになる技術だと思うから、気づいて欲しい。
一番幸せになるのはプログラマーなのに、そのプログラマーに
「OO使えねぇ」とか、本当に使っても無いのに言われるのは悲しいんです。

でも、たしかに色々な意味で初期コストは高くつきますね…。

**名前は開発中のものです。** · 02/01/01 19:06

OO使いたい奴は使えばいいし、使いたくない奴は使わなければ良いじゃん

**312** · 02/01/01 19:11

ＯＯはプログラム構造の一部しか記述できないんだよ。
＞絶対 OO 解っていない人だよ。
なんて書いてる君こそ判っていない。

**315** · 02/01/01 19:13

Ｃ言語にかけたコストは伊達じゃないので、そんなにＣ＋＋にすぐに
移行したいとは思わない。必要な規模の仕事もあんまりないし・・・。
ウチでは使ってるヤツと使ってないやつが混在してるよ。

**名前は開発中のものです。** · 02/01/01 19:17

根本的に設計が間違っている場合、OOで記述できない構造もあるわな　(藁

02/01/01 19:55

プログラム板追い出されたからってこんなとこで吼えるなや。

**316** · 02/01/01 21:09

>>318
煽り…ですか？マジで言ってるの？
OO向きじゃない部分があるのは認めるけど…。

＞ＯＯはプログラム構造の一部しか記述できないんだよ。
これOOをC言語に置き換えて、アセンブラマンセーな人の発言だと思って読んでみるといいですよ。

**名前は開発中のものです。** · 02/01/02 09:54

>>318
そうそうアセンブラじゃないと記述できない部分があるよね。
フルアセンブラまんせー。

**312** · 02/01/02 10:44

そういう意味じゃない。
アセンブラでもＯＯは出来るし。

**312** · 02/01/02 10:47

ああ、言うの忘れてたけど>>316はＯＯ対Ｃみたいに書いてるけど
判ってない証拠だね。
ＯＯは言語によらず使える。
戦略ゲームなんかはＣでＯＯ使ったけど？１０年くらい前か　藁
あと、スプライトはＯＯだな。
でも全部をＯＯ化するのはアフォです。

**名前は開発中のものです。** · 02/01/02 11:55

OO に対する認識が個々違いすぎる

OO 言語派: C++ など OO をサポートした言語を使えば OO である
OO 戦術派: オブジェクト（敵データ）管理などに OO の考えを使う
一般的 OO 派: OO サポート言語を使用。設計はどうあれ全面的にクラス/継承を使う
OOD 派: UML、デザパタ、RUP や XP の使用が前提

俺は OO をサポートしてない言語でわざわざ OOP する気にはならない。
けど速度がクリティカルじゃなきゃ VC++ で全部 OOP するよ。
その方が楽だからね。

02/01/02 12:33

俺は純ＯＯＰＬよりＣ＋＋でファイル分けする方が好きだな。
クラス化するかグローバルで行くかは使い勝手しだい。

＞全部ＯＯＰするよ。

無理。全部クラス化なら可能かもしれないが。

**名前は開発中のものです。** · 02/01/02 16:54

OO 反対派はゲームクリエイターズバイブル読んだ？
ちなみにゲームクリエイターズバイブルは
Game Architecture and Desing の日本語訳本ね。

ようするに漏れのいいたいことは…
・monostate の化け物みたいなクラスしか書いたことないのに「 OO 駄目」とか言わないように。
・80:20 の法則に基づいて、速度にクリティカルな所以外では関数呼び出しのコストを気にしすぎない。
って事かな？

まぁ、一番惜しいのは >> 326 の分類でいう「 OO 戦術派」の人達。
OO のよさが少しはわかっているのに OOPL による強力なサポートをパフォーマンスを理由に拒んでいる気がする。
反対に早く目を覚ませっ！って言いたいのは「 OO 言語派」だね、
漏れも始めはこのグループだったので、あんまり偉そうな事言えないけど、
OOPL 使うのと OOP するのは違うからね。

OOP のよさが始めに解ってくるのは「インターフェイスに対するプログラミング」が理解できた所あたりかな？
このあたりからポリモーフィズムとか、有用な所が一気に身についてくると思うから。
そこらへんまでたどり着く前に OO 否定に回っちゃ駄目だと思うなぁ。

**名前は開発中のものです。** · 02/01/02 17:02

もうちょっと一派的な方で用語の統一を…

OO　… オブジェクト指向
OOP … オブジェクト指向プログラミング
OOPL… オブジェクト指向プログラミング言語

単にOOするのとOOPLでOOPするのとは格段に違うぞ。と言いたい。

02/01/02 17:22

とうとうageちゃったか・・・。
>>328
現場の人間はそんな素人向けの本なぞ読まない。
それ以下の文章は意味不明だ。病院行け。

**328** · 02/01/02 18:49

>>330
あなた >>327 ？
>>327 の発言のがよっぽど意味不明なんだけど。

あなたは素人向けの本だと思ったのかもしれないけど、
本当はあなたみたいな頭の固い人の為の本だと思うよ。

と思ったけど、あんたはまずはじめに「達人プログラマー」から読みなさい。

つーかそれ以前に読んでもない本を初心者向けと言い切るあたりが
やってもない「本当の OOP 」を否定してるって態度をあらわしてるね。

**315** · 02/01/02 20:11

初期コストが問題なだけですよ。コストってお金だけじゃないからね。
最終的にはお金になるんだけどもｗ

02/01/02 20:32

やれやれ、ヲタク本列挙して何のつもりなのやら。

**名前は開発中のものです。** · 02/01/02 20:46

諸君、ソフトウエア業界は危機に瀕している。
業界は頭の固い旧世代プログラマーに占拠され、発展の可能性を
失っている。
これら旧世代を駆逐し、ＯＯＰＬを世に広めなければソフトウエア業界
に未来は無い。
立て。若者達よ。
立って諸君らの力でこれら旧世代を駆逐し、明るい未来を切り開くのだ。
日本の未来は諸君の双肩に掛かっている。

みたいなー。
まあ、判りやすくデフォルメするとこんな煽動が
ＯＯＰＬやＯＯの解説で行われているわけだ。
んでもってアフォが飛びついて洗脳される。と。

**名前は開発中のものです。** · 02/01/02 21:05

ＯＯＰＬ登場の理由はたった一つ、旧世代ＰＧの排除であるってことは
みんな分かってるよね？ね？なら若い奴は必至こいて勉強しろって事だよ。
ただそれだけの事にこんなに議論しちゃって・・・。恥ずかしくない？

**名前は開発中のものです。** · 02/01/02 21:22

>>335 さんの発言を見て、なんでゲームプログラマが
OOを嫌うのかわかったよ。

簡単になったら低脳なやつらはクビ切られるからね。
OOが普及するのが怖いんでしょ？

**名前は開発中のものです。** · 02/01/02 21:37

結局ＯＯはインネンつける手段かい！

**名前は開発中のものです。** · 02/01/02 21:38

>>336
低脳かどうかはどうやって判断するの？

**名前は開発中のものです。** · 02/01/02 21:38

ＯＯの理解度で判断します！

**名前は開発中のものです。** · 02/01/02 21:44

自己完結哲学というか、オウムそっくりというべきか・・・。
救いようがないですな。

**名前は開発中のものです。** · 02/01/02 22:03

単純に C より C++ の方が組みやすいじゃん。

**名前は開発中のものです。** · 02/01/02 22:18

　　　　　　ﾋﾞﾋﾞﾋﾞﾋﾞ
　 ∧＿∧　　。））））））））　　∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　`∀´）／　　　　　　　　（　@∀@）＜　ＯＯマンセー
　（Ｓつ二/)　　　　　　　　　(　　　　）　｜　旧世代を打倒せよ
　｜｜　| 　　　　　　　　　　｜｜　|　　＼＿＿＿＿＿＿＿＿＿
　（_＿）＿）　　　　　　　　　〈＿フ__フ

**名前は開発中のものです。** · 02/01/02 22:29

こうしてアンチOO派は論理的反論ができなくなったので
コピペ荒らしに転向しましたとさ。

　　　　　　　　　　　　　　　めでたし、めでたし。

**名前は開発中のものです。** · 02/01/02 22:30

めでたしめでたし

＊＊＊＊＊＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊＊＊＊＊＊＊

**名前は開発中のものです。** · 02/01/03 23:00

レースゲーとかだったら、ＯＯ不要なんだけど。

02/01/04 00:50

そうだね。
ゲームを完全ＯＯで組めるとか言ってる人は実際に組んでみればいいじゃんか。
さらに、それで効率上がるなら自分だけ効率上げて待遇良くなればいいじゃんか。
（やったら自滅するけど）
なんで布教活動するのかなあ。

**名前は開発中のものです。** · 02/01/04 02:23

バカのためにわざわざ非OOで組まなければならない
苦労を察してください。

**名前は開発中のものです。** · 02/01/04 02:40

>>345
ＯＯが絶対必要だっていう事は(レースゲーに限らず)多分ないよ。
でもレースゲーだってＯＯならもっと簡単になる可能性がある。

>>346
いいかげんウザすぎる。
本当に頼むから理解してないくせに批判するのやめて欲しい。
というか、逆にきくけどＯＯの何が不満さ？
「ぼくがりかいできないからです」以外の理由をちゃんと言ってよ。

_ · 02/01/04 02:53

何が効率よくて、何が良くないかが、理解出来てない。俺は。
上手く比較デキンというか、理想系がわからんというか。

メンバアクセス関数を用意するのは、面倒かな？
記述量も増えるし。
設計で余計に悩まされるとも思う。

どのぐらいの納期かで使い分けるのがいいのかな。

**名前は開発中のものです。** · 02/01/04 04:15

>>349
ＯＯの良さって、なかなか文章にするのは難しいです。
肌で感じてもらうのが一番いいと思うんですけど…。
もしあなたがすごく頭がいい人なら、もしかしたらＯＯの良さを
肌で感じてもらうには、途方も無く難しい(複雑な)問題に対面して
もらわなければいけないかも知れません。
私はあんまり頭が良くないので、ＯＯを知ってよかった。と日々痛感していますけど。

うーんアクセッサを書くのが面倒っていう心情はわからなくはないけど、カプセル化は必要だから、これは慣れてもらうしかないです。

設計についてはＯＯが解っていれば逆に簡単になると思います。
ただし一番酷い状態はＯＯがわかっていない人がＯＯの設計をしたときかな？
記述量は…たしかに増えているかもしれませんけど、何度も書き直すのに比べれば確実に生産性はいいはずです。
それに本来混みあって見難くなる部分が逆にすっきりしたりする場合が多いので、単純にキーボードを叩く数では決められない生産性があると思います(まともなプログラマーなら多少鍵打数が増えるくらいはたいした負担ではないでしょう？)。

納期での使い分け…、というのはちょっと違うかな…。
もし納期の単位が一週間から一ヶ月とかいうのでもない限りは。
そんなに納期が短いスパンの仕事なら、わざわざＯＯしなくても
(むしろしない方が)いいでしょう。
すごく小さいプログラム(複雑度が低い)ならばＯＯはそれほど必要じゃありません。
私の心情的には「本当に速度にクリティカルな部分」はＯＯの冗長性が邪魔なので、そういう部分は非ＯＯでもかまわないけれど、
それ以外の全てのコードはＯＯでやって欲しい。と思います。

**名前は開発中のものです。** · 02/01/04 04:23

>>350
禿同
アクセッサを書くのは確かに面倒かもしれないけど、カプセル化の恩恵は
それ以上の物がある。

_ · 02/01/04 05:03

>>350
そうスか。
ゲームって、そんなに複雑なものでもないと思ってるけどね。
（後、規模的にも）

＞もし納期の単位が一週間から一ヶ月とかいうのでもない限りは。

因みに今やってるのは２日です。（１つの目標に割ける時間）
全体で３週間かな？で、C++で書いてる。

そもそもC++ぐらいしか、現状で実用的な環境にない。てのが
問題なのかもね。

>>351
重要なものに関してはCの頃からやってた。
（「マクロ定義関数用意してるから、それ使え」とコメント付けてるだけだが）
テンプレートもマクロ定義のようなものだよね？
コンパイラが型チェックしてくれるようになった。と。

**名前は開発中のものです。** · 02/01/04 12:03

ＯＯＰは、コピペＰＧの天敵かもしれんな。
漏れの場合、似たようなコードを何度も書きたくない
という理由でコードを共通化してる部分が山ほどあるケド、
そのために、継承をさかのぼって読まないと、
どんな作業をしているかが分かりづらい所があるんよ。

だから、自分に理解できても、他人には理解出来んコードが
少なくないかもしれん。

**名前は開発中のものです。** · 02/01/04 12:45

関数呼び出しを遡っていくのと大して変わらないと思ったり。

**名前は開発中のものです。** · 02/01/04 14:01

ライブラリが複数ファイルにまたがっている事に対して、
文句を言ってる厨房がいたような・・・・

**名前は開発中のものです。** · 02/01/04 18:29

>>343
泣ける…
モナジェクトXとかにして。

OOで効率が悪くなるとか全部組めないとか言ってる人は、どういう部分が出来ないと思ってるんだろう？
>>355は、だしかにそう思う。
ユースケースごとくらいにシーケンス図があったりすると嬉しいんだけどね。
あと、JavaDocみたいなドキュメントをちょこっと書いておくのも重要だ。
C++はDoxygenだっけ？

**名前は開発中のものです。** · 02/01/04 18:31

なお、継承は悪(ただし必要悪)だという事に決まりましたので、
あんまり継承に頼らないようにしましょう。
Template Method とかは別として。

ライブラリ的な部分と利用者部分を分けて考えるのが良いと思います。
ライブラリの中身が実は OO じゃなくても、外っツラがちゃんとした OO っぽく
なっていれば結構ハッピーです。でも意味不明な static 変数やめてね。
(クラスのメンバって意味じゃなくて、関数の中とかのね)

それじゃ！グッドモーニング!!

**名前は開発中のものです。** · 02/01/04 19:00

ポリモーフィズムがOOのキモなのに…

**初愚痴** · 02/01/04 19:26

必要悪だから頼り過ぎないように、という話だろう。
経験的にインターフェースと実装の分離の為の継承では
ほとんど問題起きないね。

**357** · 02/01/04 19:32

>>358
あぁ、言葉が足りなかった！
Java 用語で言う interface を継承するのはちっとも悪くないよ。
実装継承を繰り返すのが悪なの。

むしろインターフェイスだけの継承はバリバリ行うべし。
まさしくポリモーフィズムは OO の華。

まぁ漏れはアクセッサくらいはベースクラスに含めてもいいと思ってるけど。
(まともなロジックは入れない)

共通の基本の振る舞いが欲しければアグリゲートする方向で。

02/01/04 20:49

まあ、コーダーレベルのＰＧには全てＯＯで行けると思えるだろうね。

**名前は開発中のものです。** · 02/01/04 22:10

じゃぁ、どこが行けないの？

02/01/04 22:31

実際に作ってみれば？
ＯＯは
１）処理とオブジェクトをごちゃ混ぜにしている
２）規模が大きくなり、オブジェクト間の処理が多くなってくると
　　クラスが邪魔になる。（ＯＯＰＬ）
３）オブジェクトの無い処理に不向き
４）メモリ上のインスタンス以外をオブジェクトにしようとすると
　たちまち非効率になる。
５）処理だけでオブジェクトが無い場合は無意味。

02/01/04 22:34

あ、３）と５）被ってるｗ
５）境界のあいまいな処理に不向き。

02/01/04 22:35

例：
Stringクラスは何故Charクラスを継承してないか？

**名前は開発中のものです。** · 02/01/04 23:24

はぁ…。
別にすべてクラス(のメソッド)にしなくても、OOはOOだと思うんだけど…。
(「処理」もオブジェクトであるという見方をしてもいいし)
「全て」の定義を聞きたいところ。
全てのコードをクラス内に入れること？
OOPの話だよね？

あと、>>365はネタですか？
文字と文字列は(国際化とか考え出すと)深すぎるのであまり足を突っ込みたくないけど、
それは違うでしょ。
あぁ、でも、言いたい事はだいたい分かった。曖昧なのはあなたの頭です。

**名前は開発中のものです。** · 02/01/04 23:45

１）処理はメッセージパッシングの流れであらわすのが基本。できなそうなら、全体を制御するオブジェクトを作るのが普通かな？
２）異なる種類の複数のオブジェクトを処理する場合は、STLばりに「処理をする」オブジェクトを作ろう。
３）意味不明。整数オブジェクトは使いませんか？
４）VRAM上のメモリとかに直接アクセスできない場合とかの事を言っている？非効率なのは単純に設計が悪いだけでしょう。
５）曖昧でなくなるまで設計を見直しましょう。

**名前は開発中のものです。** · 02/01/04 23:47

>>361での発言を見ると、チーフか何かなのかも知れないが、
そうだとしたら、こいつの下の人は本当にかわいそうだ。

つーか何だ>>363は？
意味不明。
＞実際に作ってみれば？
これはそっくりそのまま返したい。