OOとゲームプログラミング
952 ：名前は開発中のものです。：03/10/25 02:08 ID:gxGaLgtV
953 ：名前は開発中のものです。：03/10/25 02:20 ID:J6bPJp+i
954 ：名前は開発中のものです。：03/10/25 08:55 ID:dCj6IHyK
厳密にOOにしたがっているかどうかはともかく、
ゲーム作ってると自然にプログラムがOO的になってくよね。
(というか、OO的にしか作りようが無いというか…)
ゲーム作ってると自然にプログラムがOO的になってくよね。
(というか、OO的にしか作りようが無いというか…)
955 ：名前は開発中のものです。：03/10/25 09:33 ID:tFQvBzvJ
>>954
それは世界を知らないｗ。（驚くぞー）
それは世界を知らないｗ。（驚くぞー）
956 ：名前は開発中のものです。：03/10/25 09:42 ID:ACQoSRpG
（ソースが読みづらくて）驚くぞー
957 ：名前は開発中のものです。：03/10/25 13:53 ID:nbb61oD4
まとめると、C++は仕様固まってないし複雑極まりないしそんなもんのコンパイラなんて作りようが無い。
そんなのを技術基盤にすると土台からソフトが壊れる。ってなことですな。
そんなのを技術基盤にすると土台からソフトが壊れる。ってなことですな。
まぁ、OOだからってC++で作らなければいけないわけではないsage
959 ：とむ ◆0MTMwDpCZo ：03/10/25 18:47 ID:BUT7ZVYF
>>952-953
OOの「考え方」を簡潔に言葉にすれば、そんなとこに落ち着くだろうね。
そのへんの考え方自体に異論がある人はそんなにはいないと思うよ。
ただ、抽象的に言うとそうなんだけど、じゃあ実際にゲームをプログラムするにあたって、
その考え方をどう当てはめるかというところで、色んな考え方が出てきてしまって紛糾
するんだと思う。
それと、ただその言葉だけを教条的に受け止めてしまうと、「じゃあOOでない組み方の
処理単位は人やモノ単位ではないの？」という話も出てきてしまう。
そのへんの細かい捉え方のズレが、混乱を生んでる気がするよ。
OOの「考え方」を簡潔に言葉にすれば、そんなとこに落ち着くだろうね。
そのへんの考え方自体に異論がある人はそんなにはいないと思うよ。
ただ、抽象的に言うとそうなんだけど、じゃあ実際にゲームをプログラムするにあたって、
その考え方をどう当てはめるかというところで、色んな考え方が出てきてしまって紛糾
するんだと思う。
それと、ただその言葉だけを教条的に受け止めてしまうと、「じゃあOOでない組み方の
処理単位は人やモノ単位ではないの？」という話も出てきてしまう。
そのへんの細かい捉え方のズレが、混乱を生んでる気がするよ。
960 ：名前は開発中のものです。：03/10/25 21:06 ID:dCj6IHyK
>>959
＞それと、ただその言葉だけを教条的に受け止めてしまうと、「じゃあOOでない組み方の
＞処理単位は人やモノ単位ではないの？」という話も出てきてしまう。
普通にプログラムを組んでれば、OO的な技法も自然に使えるようになるはずだし、普通に使ってる
はずだ。たとえOOをまったく知らなかったとしてもね(ゲームはそうなりやすい分野だな)。
その行為に「名前を付け」、それにかかわる技法(抽象化、カプセル化、継承、多態性など)をある程度
「形式化」したのがオブジェクト指向。
混乱してるのは、OOを仰々しく考えてる人だけだと思うな。
(OO=C++orJavaとかいうアホもいるしな。)
ソフトウェア「開発技法」全般にいえることだけど、それらは特別なことを言ってるわけじゃなくて、
分かってる人には分かってることを明示的に定義したもの。明示的にすることの利点は分かるよな？
＞それと、ただその言葉だけを教条的に受け止めてしまうと、「じゃあOOでない組み方の
＞処理単位は人やモノ単位ではないの？」という話も出てきてしまう。
普通にプログラムを組んでれば、OO的な技法も自然に使えるようになるはずだし、普通に使ってる
はずだ。たとえOOをまったく知らなかったとしてもね(ゲームはそうなりやすい分野だな)。
その行為に「名前を付け」、それにかかわる技法(抽象化、カプセル化、継承、多態性など)をある程度
「形式化」したのがオブジェクト指向。
混乱してるのは、OOを仰々しく考えてる人だけだと思うな。
(OO=C++orJavaとかいうアホもいるしな。)
ソフトウェア「開発技法」全般にいえることだけど、それらは特別なことを言ってるわけじゃなくて、
分かってる人には分かってることを明示的に定義したもの。明示的にすることの利点は分かるよな？
961 ：名前は開発中のものです。：03/10/25 21:23 ID:tiQvbl+8
>>960
でもまあ、>>952の説明でわからない人に何をいっても無駄だけどね。
明示的にしてあっても、技法を覚えても（色々苦労してる人がいるけどこれは無駄かな〜）
まず、>>952に書いてあることを理解してはじめて役に立つもんだからね。
技術っていう視点でみると意外と珍しい分野だと思うよ。
でもまあ、>>952の説明でわからない人に何をいっても無駄だけどね。
明示的にしてあっても、技法を覚えても（色々苦労してる人がいるけどこれは無駄かな〜）
まず、>>952に書いてあることを理解してはじめて役に立つもんだからね。
技術っていう視点でみると意外と珍しい分野だと思うよ。
962 ：名前は開発中のものです。：03/10/25 21:46 ID:fKPDVu0L
＞まず、>>952に書いてあることを理解してはじめて役に立つもんだからね。
＞技術っていう視点でみると意外と珍しい分野だと思うよ。
いや、少しプログラミングしてれば>>952みたいなことは、明示的ではないにせよわかってこないかなぁ？
データ指向(カプセル化(と抽象化)のみ、つまり>>952)をプログラムの一部で利用するくらいは普通だよね？
fopen(), fread(), fwrite(), fclose()シリーズはOOなんだよって言われて、あぁ！と言えないひとは適性ないかも。
＞技術っていう視点でみると意外と珍しい分野だと思うよ。
いや、少しプログラミングしてれば>>952みたいなことは、明示的ではないにせよわかってこないかなぁ？
データ指向(カプセル化(と抽象化)のみ、つまり>>952)をプログラムの一部で利用するくらいは普通だよね？
fopen(), fread(), fwrite(), fclose()シリーズはOOなんだよって言われて、あぁ！と言えないひとは適性ないかも。
963 ：名前は開発中のものです。：03/10/26 11:31 ID:u8Gb4htY
964 ：名前は開発中のものです。：03/10/26 17:57 ID:B+12Xvtr
965 ：sage：03/10/26 19:28 ID:kUfEcyYU
>962
fopen(), fread(), fwrite(), fclose()では、何（オブジェクト）に対して言っているのか
不明だから、関数では？、こそまでOOを省略するのもどうかと。
aaa.fopen()ならいいんだけど、関数の集合とOOを同じく考えるのは、行き過ぎかと。
fopen(), fread(), fwrite(), fclose()では、何（オブジェクト）に対して言っているのか
不明だから、関数では？、こそまでOOを省略するのもどうかと。
aaa.fopen()ならいいんだけど、関数の集合とOOを同じく考えるのは、行き過ぎかと。
966 ：名前は開発中のものです。：03/10/26 20:44 ID:H2YLwGPx
FILE* を引数で必ず指定するでしょ。
967 ：名前は開発中のものです。：03/10/26 21:05 ID:7LT0mx4j
FILE*関係はオブジェクト指向の概念のほとんどを含んでいるよ。
ユーザーには直接見えないけど、カンのいい奴はすぐわかるはず。
＞その先があるのよ。
そしてライブラリの構成に注意を払うだけの力があるなら、
オブジェクト指向を本格的にやる前に「その先」に気づくはずなんだ。
だから、そういう面に関しては、OOを採用するか否かは、OO開発において
UMLを採用するか否かという議論に似てる。
ユーザーには直接見えないけど、カンのいい奴はすぐわかるはず。
＞その先があるのよ。
そしてライブラリの構成に注意を払うだけの力があるなら、
オブジェクト指向を本格的にやる前に「その先」に気づくはずなんだ。
だから、そういう面に関しては、OOを採用するか否かは、OO開発において
UMLを採用するか否かという議論に似てる。
968 ：名前は開発中のものです。：03/10/26 21:06 ID:7LT0mx4j
969 ：名前は開発中のものです。：03/10/26 21:08 ID:8EahqbN9
>967
>カンのいい奴はすぐわかるはず。
カンがいくないから悩んでるのでは？
>カンのいい奴はすぐわかるはず。
カンがいくないから悩んでるのでは？
970 ：名前は開発中のものです。：03/10/26 21:15 ID:7LT0mx4j
そういう奴は適性が無いんだよ。
あきらめるか、必死に勉強するなり、経験をつむなりしれ。
あきらめるか、必死に勉強するなり、経験をつむなりしれ。
971 ：とむ ◆0MTMwDpCZo ：03/10/26 21:53 ID:BiK1R2UA
>>960
そうそう、例えばＣ言語＋古いやり方、という感じでプログラムを組んでいる人も、
細かく見ればどこかしらはOOのやり方を取り込んでいるんだよね。下で、FILE構造体
の話をしている人がいるけど、そういう標準ライブラリ自体が提供しているのものもあれば、
組み方としてそうなってしまうところもある。
ただ、そういう細かい話をしはじめると、結局何も言えなくなっちゃうんだよね。
だから、オブジェクト志向の話をする時、「どんなスタイルでもオブジェクトはある」なんて
のは当たり前の話であって、もっと大きな範囲の見方でのOOについて話をしないと、
結局元の位置に戻っちゃう気がするな。
そうそう、例えばＣ言語＋古いやり方、という感じでプログラムを組んでいる人も、
細かく見ればどこかしらはOOのやり方を取り込んでいるんだよね。下で、FILE構造体
の話をしている人がいるけど、そういう標準ライブラリ自体が提供しているのものもあれば、
組み方としてそうなってしまうところもある。
ただ、そういう細かい話をしはじめると、結局何も言えなくなっちゃうんだよね。
だから、オブジェクト志向の話をする時、「どんなスタイルでもオブジェクトはある」なんて
のは当たり前の話であって、もっと大きな範囲の見方でのOOについて話をしないと、
結局元の位置に戻っちゃう気がするな。
972 ：名前は開発中のものです。：03/10/26 22:01 ID:tz4JL+20
＞ただ、そういう細かい話をしはじめると、結局何も言えなくなっちゃうんだよね。
なにが言いたいのかしらんが、いえないんなら言う必要が無いんじゃない？
なにが言いたいのかしらんが、いえないんなら言う必要が無いんじゃない？
973 ：sage：03/10/26 23:32 ID:kUfEcyYU
>>966-968
前にあるか、後ろにあるかだけで、同じOOだと、論ずるのは乱暴でしょう
OOを表現するためには、納得できる書式がいると思います。
私にはfopen()の括弧の中にあるのはパラメータです。
Func(a,b,c,d）、の場合a-dのどれが対象のオブジェクトだと言えますか?
仮に、Func(a#b,c,d)でaがオブジェクトで＃が識別子ならOKです。
前にあるか、後ろにあるかだけで、同じOOだと、論ずるのは乱暴でしょう
OOを表現するためには、納得できる書式がいると思います。
私にはfopen()の括弧の中にあるのはパラメータです。
Func(a,b,c,d）、の場合a-dのどれが対象のオブジェクトだと言えますか?
仮に、Func(a#b,c,d)でaがオブジェクトで＃が識別子ならOKです。
974 ：名前は開発中のものです。：03/10/26 23:43 ID:kUfEcyYU
うお、sageが間違ってる・・・ オブジェクトとパラメータの谷間に落ちて（逝ってくる
975 ：名前は開発中のものです。：03/10/27 00:27 ID:H1m2iQt7
>973
私の理解では
OOは（プログラムに限らず）考え方の話。(OO=Object Oriented)
OOPはプログラムを書くときの手法の話。(OOP=Object Oriented Programing)
OOPLはプログラミング言語の中のOOしやすいもの。(OOPL=Object Oriented Programing Language)
CでのFunc(a,b,c,d）とC++でのa.func(b,c,d)とが等価になるような規約の下では
非OOPLでもOOPが出来そうだと思いませんか？
（まあ、私は実践したことがなかったりするのだけど）
私の理解では
OOは（プログラムに限らず）考え方の話。(OO=Object Oriented)
OOPはプログラムを書くときの手法の話。(OOP=Object Oriented Programing)
OOPLはプログラミング言語の中のOOしやすいもの。(OOPL=Object Oriented Programing Language)
CでのFunc(a,b,c,d）とC++でのa.func(b,c,d)とが等価になるような規約の下では
非OOPLでもOOPが出来そうだと思いませんか？
（まあ、私は実践したことがなかったりするのだけど）
976 ：名前は開発中のものです。：03/10/27 00:36 ID:xto1M/gG
977 ：名前は開発中のものです。：03/10/27 00:38 ID:xto1M/gG
あぁ、実装に関してもCommon Lispのオブジェクト指向拡張であるCLOSみたいな
書き方も有るので、調べてみると良い。
書き方も有るので、調べてみると良い。
978 ：名前は開発中のものです。：03/10/28 19:56 ID:3FYAC515
オブジェクト指向を表記法かなんかだと勘違いしている痛い>>973がいるのは
このﾇﾚですか？
このﾇﾚですか？
979 ：名前は開発中のものです。：03/10/28 21:42 ID:oyZapmnU
OOA、OODを知っている人
OOP、OOPLしか知らない人
両者の溝は大きいということが分かりましたか？
OOP、OOPLしか知らない人
両者の溝は大きいということが分かりましたか？
980 ：名前は開発中のものです。：03/10/28 23:14 ID:3FYAC515
OOA、OOD、OOP、OOPLって分けるのもどうかなと思うぞ。
そしたらXPとかのAgileな方法論って何ぞや？ってことになるし。
まぁ最近はやりのAgileなんちゃらは、基礎がちゃんとできた人間が
実践するもんだと激しく実感ｼﾏｽﾀ まる
そしたらXPとかのAgileな方法論って何ぞや？ってことになるし。
まぁ最近はやりのAgileなんちゃらは、基礎がちゃんとできた人間が
実践するもんだと激しく実感ｼﾏｽﾀ まる
981 ：名前は開発中のものです。：03/10/29 00:05 ID:14EcwHsf
でも、OOP、OOPLしか知らない人(そこから入って止まっている人)が、いきなりAgileいくのはまずいだろう。
TestingFrameworkだけ取り入れましたとか言うならともかく。
TestingFrameworkだけ取り入れましたとか言うならともかく。
982 ：951：03/10/29 02:11 ID:xRwANdUo
見事にスルーされてしまった。悲しい。後段はともかく、前段にはツッコミほしかったんだけどな。
誰かかまってかまって
誰かかまってかまって
983 ：名前は開発中のものです。：03/10/29 04:56 ID:eTAa161v
そろそろ次スレの用意をしたほうがよいかもね。
よろしく >>990
>>982 >>951
ゲームで「分析過程の出る幕があまり無い」のは、単に事前に
分析できないだけでしょう。
特定の業務に特化したソフト（伝票処理とか）ですら、良い物に
しようと思ったら分析過程は困難だというのに、ゲームはそもそも
何が良い物なのか指針（速度とか定量化できるもの）がまったくない。
なもんだから、迅速なプロトタイピングのために、柔軟なフレームワークを
作り上げることに注力すべきで、そのためにはＯＯは非常に有効かと。
ってここまで書いて自分が951とまったく同じことを言っていることに気が付いた。
柔軟なフレームワーク、つまり良く出来たGameObjectとかEntityとか呼ばれる
仕組みは「すでに十分抽象化されて」いて、分析も何も、って感じな訳だけど、
このことを言っていたのかな？
よろしく >>990
>>982 >>951
ゲームで「分析過程の出る幕があまり無い」のは、単に事前に
分析できないだけでしょう。
特定の業務に特化したソフト（伝票処理とか）ですら、良い物に
しようと思ったら分析過程は困難だというのに、ゲームはそもそも
何が良い物なのか指針（速度とか定量化できるもの）がまったくない。
なもんだから、迅速なプロトタイピングのために、柔軟なフレームワークを
作り上げることに注力すべきで、そのためにはＯＯは非常に有効かと。
ってここまで書いて自分が951とまったく同じことを言っていることに気が付いた。
柔軟なフレームワーク、つまり良く出来たGameObjectとかEntityとか呼ばれる
仕組みは「すでに十分抽象化されて」いて、分析も何も、って感じな訳だけど、
このことを言っていたのかな？
984 ：名前は開発中のものです。：03/10/29 06:46 ID:14EcwHsf
要するに
「ゲーム(のプログラム)の分析過程」 ＝ 「ゲーム(という商品)のデザインを行う過程」
だね。視点を変えれば、工程の呼び方も変わるということで。
OOでやるかやらないか、というのは有るけど、さぁ作ろうとなったときには、
分析が済んでいるという考え方は、まぁ、普通か。
んで、フレームワークのほうは、プログラムの設計(デザイン)の段階だと
思うんだが？設計はフレームワークを作る/作らないに関わらず、常に
出る幕は有るんじゃないかな。
「ゲーム(のプログラム)の分析過程」 ＝ 「ゲーム(という商品)のデザインを行う過程」
だね。視点を変えれば、工程の呼び方も変わるということで。
OOでやるかやらないか、というのは有るけど、さぁ作ろうとなったときには、
分析が済んでいるという考え方は、まぁ、普通か。
んで、フレームワークのほうは、プログラムの設計(デザイン)の段階だと
思うんだが？設計はフレームワークを作る/作らないに関わらず、常に
出る幕は有るんじゃないかな。
985 ：名前は開発中のものです。：03/10/29 07:32 ID:eTAa161v
986 ：名前は開発中のものです。：03/10/29 14:59 ID:xRwANdUo
>>983-985 サンクス！
> 「ゲーム(のプログラム)の分析過程」 ＝ 「ゲーム(という商品)のデザインを行う過程」
> フレームワークのほうは、プログラムの設計(デザイン)の段階
> 分析＝用件分析、だと思ってた。
私は「分析」という工程を、「要求仕様からオブジェクトを導出する作業」と想定して
話してたんだけど、それは「設計」と言うべきだった。申し訳ない。
> 設計はフレームワークを作る/作らないに関わらず、常に出る幕は有るんじゃないかな。
> もちろん設計は必要だと思いまつ
設計のうち、「要求仕様からオブジェクトを導出する作業」に関しては、あまり必要が
無いんじゃないかなって思って書いたのが>>951の前段。
だって「駒」にせよ「盤面」にせよ、すでに十分抽象的なんだもんそのままモデリングすりゃ
ええやんってオモタんだけど、この点についての是非が聞きたかったのね。
＃「駒と盤面」というレベルじゃ済まないような複雑なゲームでは、設計にもそれなりの工数が
＃必要になると思うけど、そこで>>983のような「柔軟なフレームワーク」を作っておくと良いかも、
＃と思って書いたのが>>951の後段の部分。表現は違うかもしれないけど、コンセプトは>>983と同じ。
> 「ゲーム(のプログラム)の分析過程」 ＝ 「ゲーム(という商品)のデザインを行う過程」
> フレームワークのほうは、プログラムの設計(デザイン)の段階
> 分析＝用件分析、だと思ってた。
私は「分析」という工程を、「要求仕様からオブジェクトを導出する作業」と想定して
話してたんだけど、それは「設計」と言うべきだった。申し訳ない。
> 設計はフレームワークを作る/作らないに関わらず、常に出る幕は有るんじゃないかな。
> もちろん設計は必要だと思いまつ
設計のうち、「要求仕様からオブジェクトを導出する作業」に関しては、あまり必要が
無いんじゃないかなって思って書いたのが>>951の前段。
だって「駒」にせよ「盤面」にせよ、すでに十分抽象的なんだもんそのままモデリングすりゃ
ええやんってオモタんだけど、この点についての是非が聞きたかったのね。
＃「駒と盤面」というレベルじゃ済まないような複雑なゲームでは、設計にもそれなりの工数が
＃必要になると思うけど、そこで>>983のような「柔軟なフレームワーク」を作っておくと良いかも、
＃と思って書いたのが>>951の後段の部分。表現は違うかもしれないけど、コンセプトは>>983と同じ。
987 ：名前は開発中のものです。：03/10/29 15:32 ID:14EcwHsf
>ままモデリングすりゃ
>ええやんってオモタ
いや、それが設計なんでは？
(古典的なウォータフォールモデルでは基本設計と詳細設計に分かれるみたいだけど。)
>ええやんってオモタ
いや、それが設計なんでは？
(古典的なウォータフォールモデルでは基本設計と詳細設計に分かれるみたいだけど。)
988 ：名前は開発中のものです。：03/10/29 18:10 ID:xRwANdUo
>>987
> いや、それが設計なんでは？
うん。そこがゲームをプログラムコードに落とし込んでいく上で肝になる部分だから、
> あまり必要が無いんじゃないか
というのは思いっきり語弊があった。
ゲームにおいては現実のモデルをOOに適応させるための「技巧的な」モデリングを
する場面は少なくて、比較的素直にモデリングできるんじゃないか、さほど高度な概念や
技術を駆使しなくても必要十分なモデリングが可能なんじゃないか、と言いたかった。
つまり、ゲームとOOは親和性が高いんじゃないかということが言いたかったんよ。
とまあ、>>948の
> 本質的な話というか、「OOとは何か」というところの議論
に対して、ゲームと絡めてネタフリしたのが>>951だったわけです。
＃にしてはお粗末だった（というか無知をさらけ出す結果になった）。スマン。
> いや、それが設計なんでは？
うん。そこがゲームをプログラムコードに落とし込んでいく上で肝になる部分だから、
> あまり必要が無いんじゃないか
というのは思いっきり語弊があった。
ゲームにおいては現実のモデルをOOに適応させるための「技巧的な」モデリングを
する場面は少なくて、比較的素直にモデリングできるんじゃないか、さほど高度な概念や
技術を駆使しなくても必要十分なモデリングが可能なんじゃないか、と言いたかった。
つまり、ゲームとOOは親和性が高いんじゃないかということが言いたかったんよ。
とまあ、>>948の
> 本質的な話というか、「OOとは何か」というところの議論
に対して、ゲームと絡めてネタフリしたのが>>951だったわけです。
＃にしてはお粗末だった（というか無知をさらけ出す結果になった）。スマン。
989 ：名前は開発中のものです。：03/10/29 22:14 ID:9dxR22/7
>962
FILE* はカプセル化と情報隠蔽のサンプルとしては良いかもしれないが
継承や多態性のサンプルにはならないから、OOの例としては不適格では？
>971
家ゲーRPG板に「あの」スレの後継が出来てるので覗きに来てくれると嬉しい。
（叩きがウザイので名無し推奨）
>951
ではｗ
前段は、ゲームルールとして単純でも例えば思考ルーチンを作る事を考えると分析にも
意味はあると思うっす。検証の意味でも分析が不要ってことは無い、かな。
後段は同意。
↓次スレよろ
FILE* はカプセル化と情報隠蔽のサンプルとしては良いかもしれないが
継承や多態性のサンプルにはならないから、OOの例としては不適格では？
>971
家ゲーRPG板に「あの」スレの後継が出来てるので覗きに来てくれると嬉しい。
（叩きがウザイので名無し推奨）
>951
ではｗ
前段は、ゲームルールとして単純でも例えば思考ルーチンを作る事を考えると分析にも
意味はあると思うっす。検証の意味でも分析が不要ってことは無い、かな。
後段は同意。
↓次スレよろ
990 ：名前は開発中のものです。：03/10/29 22:48 ID:JAh2lgHM
FILE*は多態性の格好のサンプルだろ。
992 ：名前は開発中のものです。：03/10/30 00:08 ID:tONNfDVU
用意しました
タイトル
OOとゲームプログラミングNo.2 : 自由に変更してください
本文
OOをどのように用いれば美しいゲームプログラミングを
行うことが出来るか語り合うスレです。
・正直、素人にはお勧めできない
・煽り・荒らしは放置。名無し推奨。
タイトル
OOとゲームプログラミングNo.2 : 自由に変更してください
本文
OOをどのように用いれば美しいゲームプログラミングを
行うことが出来るか語り合うスレです。
・正直、素人にはお勧めできない
・煽り・荒らしは放置。名無し推奨。
993 ：名前は開発中のものです。：03/10/30 00:13 ID:geh2FZdf
これも付けといてん。
前スレ:
OOとゲームプログラミング
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/
参考スレ:
オブジェクト指向の説明について 2ループ目
http://pc2.2ch.net/test/read.cgi/tech/1064295567/
【OO?】オブジェクトオリエンテッド総合【非OO？】
http://pc2.2ch.net/test/read.cgi/tech/1041658161/
OOPの次はAOPだそうですね？
http://pc2.2ch.net/test/read.cgi/tech/1004962559/
【XP】 Agile Process 【UP】
http://pc2.2ch.net/test/read.cgi/tech/1032882847/
前スレ:
OOとゲームプログラミング
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/
参考スレ:
オブジェクト指向の説明について 2ループ目
http://pc2.2ch.net/test/read.cgi/tech/1064295567/
【OO?】オブジェクトオリエンテッド総合【非OO？】
http://pc2.2ch.net/test/read.cgi/tech/1041658161/
OOPの次はAOPだそうですね？
http://pc2.2ch.net/test/read.cgi/tech/1004962559/
【XP】 Agile Process 【UP】
http://pc2.2ch.net/test/read.cgi/tech/1032882847/
994 ：とむ ◆0MTMwDpCZo ：03/10/30 00:20 ID:WzMaSpz4
FILE関係は、最初にＣライブラリから使うようになった時は、「この関数シリーズはちょっと
異質だな」という違和感があったんだけど、こうしてC++等を使うようになって「OOだ」と
指摘されると、なるほどという感じがしますね。
異質だな」という違和感があったんだけど、こうしてC++等を使うようになって「OOだ」と
指摘されると、なるほどという感じがしますね。
995 ：名前は開発中のものです。：03/10/30 05:15 ID:C9mKyhbZ
次スレ立てた
OOとゲームプログラミング Role2
http://pc2.2ch.net/test/read.cgi/gamedev/1067458051/
>>990
カプセル化の非OOPLによる好例、だとは思うけど、
多態性なんてあるか？
OOとゲームプログラミング Role2
http://pc2.2ch.net/test/read.cgi/gamedev/1067458051/
>>990
カプセル化の非OOPLによる好例、だとは思うけど、
多態性なんてあるか？
996 ：名前は開発中のものです。：03/10/30 09:06 ID:rduyZy7M
997 ：名前は開発中のものです。：03/10/30 12:43 ID:gx/g9R6B
fopen の戻り値と stdin,stdout,stderr が同じに扱えるのは多態性と言えないのですか？
998 ：名前は開発中のものです。：03/10/30 13:28 ID:geh2FZdf
stdin,stdout,stderrはFILE*なグローバル変数じゃない？
そのうえ、それらの多態性は、ファイルデスクリプタ(OSのファイルシステム)の
多態性によるところが大きくて、どう多態してるのかはOSのソースを読まないと
分からないという罠
そのうえ、それらの多態性は、ファイルデスクリプタ(OSのファイルシステム)の
多態性によるところが大きくて、どう多態してるのかはOSのソースを読まないと
分からないという罠
999 ：名前は開発中のものです。：03/10/30 13:44 ID:gx/g9R6B
>>998
実装とインターフェースをごっちゃにしちゃだめですよ。
実装とインターフェースをごっちゃにしちゃだめですよ。
1000 ：名前は開発中のものです。：03/10/30 14:24 ID:8gxfHKMc
delete this;
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。