オブジェクト指向・嗜好・試行・至高・歯垢

リクエストにお答えして連載開始しました。
苦情その他は、原稿を依頼した>>199へおながいします。

萌え萌えオブジェクト指向(2)

それではまず「オブジェクト」について
これは辞書にでてくる「もの」という
意味と同じです。
例えば、ちよちゃん、おおさかさん、可憐、白鳥、四葉、あなたの持っている初回版CD、限定版DVDボックス。
それから、限定版DVDボックスの"予約"、ちょびっツCD-ROMの"注文"といった実体がない"もの"も"オブジェクト"です。
　
次にクラスについて。
ひとつの"もの"はいろんな表現ができます。
例えば"可憐ちゃん"は、女の子ですし、妹、学生、人間という表現ができます。
つまり"もの"はいろんなくくりでくくれます。
そして学生というくくりの中では可憐ちゃんも、四葉ちゃんも、おおさかさんも皆勉強します。
人間というくくりでは可憐ちゃんも、ちよちゃんも、あなたも、食べたり寝たりします。
つまり同じ性質をもつものをまとめてクラスと呼ぶのです。
　　
さて、今回はここまでにしましょう。
それでは次回までごきげんよう。

この連載ってほんとに分かりやすいのか？

始まったばかりでまだ内容は無いから判断しづらい
いや、出てくる言葉が謎が多いからか、、

>>199 でてこい！
あと>>201にも容疑がかかるな。

「オブ脳」読め！

固有名詞がさっぱりわからんが、もう少し待ってみよう。

リクエストにお答えして連載開始しました。
苦情その他は、原稿を依頼した>>199へおながいします。

萌え萌えオブジェクト指向(3)

さて今回はまず"継承"から
前回、ものはさまざまなくくり方が出来て
これをクラスと呼びました。
ここでシス〇リの"可憐ちゃん"について見て見ましょう
まず妹なので「お兄にちゃん」と呼んでくれます
おおきなくくりでは学生なので、学校に行きます
さらに大きなくくりでは人間なので、食べたり
寝たりします。人間の持っている性質は学生も
持っているし、学生の持っている性質は"可憐ちゃん"
も持っています。
但しその逆を考えると、人間は必ずしも学校に行くわけでは

この様におおきなくくりの性質を小さなくくりが
受け継ぐ亊を"継承"と呼んでるだけです。

つまり"可憐ちゃん"も人間だから食たり寝たり
するし学生だから学校に行くって亊です。

さて、そろそろ「改行が多すぎますエラー」で
書けなくなるかもしれないので
今回はここまでにしましょう。
それでは次回までごきげんよう。

リクエストにお答えして連載。
苦情その他は、原稿を依頼した>>199へ。

萌え萌えオブジェクト指向(4)

ここでよく解説書に「オブジェクト同士で通信して、メッセージのやりとりをして」と書かれている事について説明します。
ここであるシーンを思い浮かべてみましょう
あなたは「もとすわ　ひでき」という青年になっています、外観が人間のかわいい女の子そっくり
のパソコンが抱き着いてきました
あなたの顔を見て「ちぃ」と鳴いてほほ笑んでいます。
あなたはかわいさのあまり抱きしめてしまいます。
今度は「もとすわ　ひでき」君のバイト先のかわいい女の子が抱き着いてきました、あなたの顔を見て「もとすわさん」とささやいてほほ笑んでいます。
あなたはかわいさのあまり抱きしめてしまいます。

この時「もとすわ」君という"もの"と女の子パソコンという"もの"の間では何がおきていますか？
関数呼び出しですか？

「もとすわ」君には肌から体温という情報が、目から光という形でかわいい顔が伝わってきています
女の子パソコンにも肌から体温という情報が、目から光という形で大好きな人の顔が伝わってきています

このように"もの"と"もの"との間では自然とやりとりが生まれ　結果としてほほ笑んだり、抱きしめたりという動作につながります。

実際には熱とかいろいろなものが伝わります、ですがコンピュータは情報機器なのでメモリ上の"もの"の間では情報だけが流れます。
情報の流れ、これはまさに通信といえるのではないでしようか。
このように流れる情報はメッセージと呼ぶ方が自然ではないでしょうか。

"ほほ笑む"というメッセージを受けて、"抱きしめる"という動作をしたと表現した方が自然ではないでしょうか。
つまり一見、変ですが"もの"をベースに考えるとむしろ自然な表現なのです。

さて、「本文が長すぎますエラー」をくらったので
今回はここまでにしましょう。それでは次回までごきげんよう。

×あなたはかわいさのあまり抱きしめてしまいます。
○あなたはもう萌え萌えでむぎゅっとしてしまいます。

なんか某D言語研究家の文体に似てなくてもないが・・。

オブジェクト指向が何なのかも知らずに興味本位でオブ脳買ったんだけど
俄然興味が出てきて、今 @IT のUMLの連載を読んでるとこ。

あの本よく出きてるなーと思った。すんなり記事の内容を理解できたけど
たぶんあの本を読んでなかったら、チンプンカンプンだったと思う。とり
あえず色んな書籍を読んで OO の大海原に漕ぎ出したい気分になりました。

>>215
オブ脳はとりあえず4章まで読めばOK。
その後は、UMLでも、デザパタでも、EJBでもすきなところ行ってくれ！

リクエストにお答えして連載開始しました。
苦情その他は、原稿を依頼した>>199へおながいします。

萌え萌えオブジェクト指向(5)

それでは、前回出てきたシーンを思い出してみましょう

この場合、はじめに出てきたのは、女の子形とはいえあくまでも中身はパソコンです
次は生身の人間の女の子です。
全く別の内部構造をしています。

ですが、同じメッセージを発していたので同じ様に"抱きしめる"という扱いが出来たのです。

別の表現をすれば、外部からみてかわいい女の子なら、中身が何でも、萌えられる、という事です。
その女の子に「暗殺する」（メソッド）を追加しても、萌えられるという事です。
これはとても便利な性質です。

さて、今回はここまでにしましょう。
それでは次回までごきげんよう。

連載期待あげ

たぶん出版したらそれなりに売れぞｗ

期待あげ

(´-`).｡oO(190はどうしたんだろー
仕事がてんぱってるんだろーか

多重分類と動的分類について説明してくれ。

(´-`).｡oO(190はどうしたんだろー
まさかふりよの事故で他界？
(((；ﾟДﾟ))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

あの、クラスをインプリメントするって継承するって事と同じ意味ですか？
インプリメントって調べてもよくわからないです

単に「実装する」ってだけ。
継承は関係ない。

>224
クラスを実装するというか
抽象データ型を実装したのがクラスな訳で

>>224>>225
どもです
なんで実装ってかかないんだろ
インプリメントなんてわかりにくいよ

でも実装って言われても分かりにくいけど・・・

>226 implementも実装も全然わかりにくくない。おまいが阿呆なだけ。

>>227
まあそうなんだろうけど、普通にnewで宣言してして使うのとどう違うんだよ？

>>228
何か違う話になってないか？

>228
とりあえず理念と実装の区別をつけろ。
あとインターフェースの意味も覚えとけ。
老婆心ながら付け加えるが、Javaのinterfaceという言語要素の事とは限らないぞ。

>普通にnewで宣言してして使う

ﾊｧ( Д)ﾟ ﾟ？

インターフェースって外部に公開する仕様の事じゃなかった？と思う・・

>>231　クラスのインスタンスを生成して

> >>231　クラスのインスタンスを生成して

ﾊｧ( Д)ﾟ ﾟ？
実装するって言うのは、
定義済の機能を実現(コーディング)することなんだが。

定義済の機能を実現(コーディング)する

　　実現するってなに？

　　アホにでも分かるように教えてくれよ（ﾊｰﾄ

ぷろぐらむをかくということです。

定義済みの機能を実装するためのコードってことでＯＫ？
implementsで・実装する（って言っていいのかな？・だけではだめなの？

カスにでも分かるように（ry

インプリメント
メンバ関数(メソッド)の中身を書く
ということ

じゃ、あかんか?

>237
フィールド(属性)は?

>>237
それなら分かるんだけど

じゃあVBのimplementsって何のためにあるんだろって思う

ボケに（ry

漏れの中の人は以下のように脳内変換しているそうです。

フィールド -> メンバ変数

VBは知らん。

VBはプロパティじゃないか
フィールドはJava用語かな

OMG的にいうなら属性だが

久しぶりにためになるスレッド読んだ。
１９０連載期待あげ
ちょっと分かりづらい言葉も多いのは気に（ｒｙ

最近出た「なぜオブジェクト指向でつくるのか」。
話が実際的でかなりいい本だと思いながら読んで
いたんだが、「プログラマのたしなみ以前の常識」と
して紹介しているスタックを、なんとFIFOと解説。
（しかも図解付き。図ではちゃんとLIFO。）
この時点で著者への信用がガラガラと・・・。

昨日買ったけど、LIFOに直ってるみたい……

>>244
「オブジェクト指向でなぜつくるのか」だろ

>>244
ただの誤植だろ？

>>246
正解。
>>247
１箇所だったらそう思えるけれど・・・。しかも
「FIFO(First In First Out)」って丁寧に説明
してるし。

ま今では直ってるみたいなのでこの話は
終了で。それよりこの本を読んだ人の感想
を聞きたい。

オブ脳3章まで立ち読みした。
だいたい意味は分かった。
これでオブジェクト指向、理解したことになる？

ならねえよ。

オブ脳よんでもオブジェクト指向はわからんよ

>>251
次、何読めばいい？

普通オブジェクト志向って言わない？

>>253
オブジェクト指向とオブジェクト志向は違う概念やぞ

指向 志向 思考 試行 嗜好 歯垢　ﾆﾎﾝｺﾞﾑｽﾞｶｼﾈ

「オブジェクト指向」は、
「オブジェクト志向」の表記ミス。
表記ミスの方が一般には広まってしまった。

>>256
なわけないだろ
指向はorientedの訳

>>257
ゴキブリのパロディだろ。

>>258
ゴキカブリ

オブジェクト指向＝頭はいいが基本的な部分の幼稚な奴が飛びつく指向。

オブジェクト指向を学ぼうと思ったら、どのプログラミング言語が最適ですか？

>>261
C++またはC#からはじめては、、、いけない。
脳みそ腐りますがな。

>>262
C++とC#を同列に扱ってどうする。

>>262
できれば理由も教えてください

>>264
文法がでかすぎる。
プログラミング言語にとってはこれは致命的。
なくてもよいお便利機能がてんこもり。
C++は歴史的な経緯から仕方ない側面があるけど、
C#は真の糞。

C++と比べるとC#はかなり単純明快に見えますが真の糞なのは
何故ですか？

最新言語なのに寄せ鍋だから。
漏れは仕事だから毎日使ってるけどいやになるね。

それって好き嫌いの部類と違うのかね？
俺も言語によっちゃそういうのあるな

まあたしかに好き嫌いってのもあるけどな。
だけどC#はMSの最新言語ってこと考えると、
文法の練り込みが甘すぎると思うんだな。

C++/C#を外して、オブジェクト指向言語……具体的には何をお勧めなのよ？

C#を仕事で使えるってのは羨ましいななんか
C#触ったこともないが

C# に似通った Java はどうよ
これも否定されたら、メジャーなのがほとんど残らない気がするぞ

Smalltalk原理主義者なんだろう。

「オブジェクト指向」をどういう切り口から会得したいかによるかと。
原点である「メッセージ指向」からならSmalltalkか、せめてRuby。
現在主流の「抽象データ型のスーパーセット」（いわゆる、カプセル化、継承、多態性【註】）からなら
オリジナルのSIMULAか、Cからの派生でメジャーどこならC++やJava、C#。
これらにこだわらない、もっとプリミティブなオブジェクト指向に興味があって、
「インスタンスベースのオブジェクト指向」からならSELFか、メジャーどこならPythonやJavaScript系。
もっと枠をとっぱらったところからで、かつ疑似関数プログラミングとかにも興味があれば、CLOS。

一般に、新しい言語ほど、いろいろなコンセプトのいいとこ取り（悪いときは単にひそみにならって
いるだけ）なので、純粋なところは学びにくくなるように思います。

【註】この文脈では、ストラウストラップの言う、「抽象データ型」、「継承」、「仮想関数」、と
言い換えたほうが無難かも…。

とはいえ、初心者用のオモチャとしてはJavaが楽じゃね？
参考資料も多いし。

>>274
この中で一番簡単そうなのはどれですか？

>>276
JavaScript

プログラミング自体も初心者なら SmallTalk が良いと思うけど。
GUI はそれこそ classify しやすい分野だと思うから、Squeak とかで
遊んでみるのが良いと思う。
そういう意味では Java でも Delphi でも C# でもいいのだが。

それなりに楽しんだら、デザインパターンか分析／設計の方へ。

Smalltalk ね。

・良い点
クラスもオブジェクト（メタ・メタ・メタ！）
強力なリフレクション機能（基底クラスのメソッド数が膨大）
制御構文も（疑似）メッセージ送信（if 文もメソッド呼び出し風に書ける）
クラスやメソッドの定義もメッセージ送信（動的にクラス定義出来るよん）
実行時型決定（クラスのすげ替えとかが簡単に出来ちゃう）
オブジェクト指向的ライブラリの豊富さ（クラス数、メソッド数が半端じゃない）
充実したブラウザ、インスペクタ（凄ぇぜ）
キーワードメッセージ式は S 式 + マクロに匹敵すると思う

・悪い点
リテラル配列中でクロージャが作れない（ダメじゃん）
Squeak のクロージャはレキシカルじゃない（再帰出来ないよん -- ANSI はｵｹ）
メタは取っ付きにくい（最初だけだけど）
環境一式をイメージに抱え込む方式（外世界とのやり取りが面倒）
チャンク式が汚い（スクリプティングには向いてない）
使い易い処理系が無い（日本語使い辛いとか、ライセンスとか、配布とか）
GUI がイケてない（見た目が古いとか、他との整合性とか）

まぁ、オブジェクト指向を語る上で必修言語であるのは間違いないでしょう。

SmalltalkをSmallTalkとか書く奴に、ロクな奴は居ない
定説です

>>280
>SmalltalkをSmallTalkとか書く奴に、ロクな奴は居ない
む、何度もこのような文面を見たことがあるのにやってしまった・・・
俺がろくでなしなのと無関係に、 Smalltalk は初学者が
手始めとして触ってみるのに向いた環境だと思うよ

アラン・ケイもどっちでも良いって言ってるから、良いんでない？

他の言語もオブジェクト指向言語としての良い点／悪い点聞いてみたい。

>>282
意思の疎通を図る上で何の問題もないのは明らかだが、
馬鹿に「SmalltalkをSmallTalkとか書く奴に、ロクな奴は居ない」とか言われて
むかつくリスクを考えたらSmalltalkと書いた方がいい。
俺は自信がなかったらから調べた。

>>283
そんな事書いてもこのスレ的には何のメリットも無い訳で。
まぁ >>280 の気持ちも分からないでもないけど。

各オブジェクトシステムモデル間の差異ってこれくらいかな。

... メソッドがクラスに属しているか
... オブジェクトがクラスに属しているか／クラスベースか、オブジェクトベースか
... メソッドはオブジェクトか（データとして渡す事が可能か）
... 単一継承か、多重継承か、ミックスインがあるか
... インターフェイスを持っているか
... リフレクション機能を持っているか／メタオブジェクト的な機能があるか
... 動的なクラス、メソッドの再定義を許しているか（ユーザが拡張可能か）
... メソッド呼び出しの記法（ドットで繋ぐ／メッセージ送信）
... 内部に関数呼び出しの層を持っているか
... オブジェクトではないデータ型があるか／Boxing を行うか
... オブジェクト内データへのアクセス制限が可能か（隠蔽）

例えば Java の場合：（正直 Java 分かってないんで訂正して下さい）

... メソッドがクラスに属しているか
- 属している。クラスに属さないメソッドは定義出来ない。
... オブジェクトがクラスに属しているか／クラスベースか、オブジェクトベースか
- クラスベース。クラスをテンプレートとしてインスタンスを生成
... メソッドはオブジェクトか（データとして渡す事が可能か）
- メソッドはオブジェクトとして取り出せる。
... 単一継承か、多重継承か、ミックスインがあるか
- 単一継承。ミックスインは標準では無い？
... インターフェイスを持っているか
- ある。大きな特徴の一つ。
... リフレクション機能を持っているか／メタオブジェクト的な機能があるか
- java.lang.reflect にある。get 系だけで、set は出来ない。
... 動的なクラス、メソッドの再定義を許しているか（ユーザが拡張可能か）
- 出来ない？　クラス、メソッドはソースコードで定義され、コンパイルされる必要がある。
... メソッド呼び出しの記法（ドットで繋ぐ／メッセージ送信）
- ドットで繋ぐ。インスタンス生成は特別なキーワード new を使用する。
... 内部に関数呼び出しの層を持っているか
- 無い？
... オブジェクトではないデータ型があるか／Boxing を行うか
- プリミティブ型あり。Boxing は 1.5 で予定。
... オブジェクト内データへのアクセス制限が可能か（隠蔽）
- 出来る。アクセス修飾子を使用する。

何となくRubyがいいのかな〜。
Smalltalkに近いんだよね？

Ruby 興味あるならとりあえず使ってみてください

>>286
ruby を使ってみて Smalltalk に近いと感じるぶんにはいいけど、
Smalltalk に近いからと聞いて ruby を使うのはどうなのかなぁ…（反語的に）。
今は昔と違って、処理系もロハだし、マシンパワーもほぼ十分だから
即実践…と先を急がないなら Smalltalk をじかにいじってほしいかな、と。

Smalltalk(Squeak/VisualWorks/etc.)総合スレ
http://pc5.2ch.net/test/read.cgi/tech/1039017724/l50

ただ、繰り返しになりますが「クラス指向」と言うべき、抽象データ型の
スーパーセットとしてオブジェクト指向を学びたいなら、SIMULA や
C++ の流れを汲む言語のほうが個人的にはいいと思います。

簡単とかで選ぶんじゃなくて、学びたいことに合った処理系を選ぶのが一番です。

>>288
やっぱりOOPは難しそうだ。。。
まぁ、趣味でやるんだから必然性はないんだけどね。

>>289
「メッセージ指向」のオブジェクト指向は、それこそ子供でも直感的に理解できるように
考え出されたものなので、とても簡単です。ようは、コンピューティングに関わるもの
すべてを「オブジェクト」とそれへの「メッセージ送信」に置き換えることで表現しよう、
というものです。これを実践するために考え出されたコンピュータシステムと言語が
Smalltalk システムと Smalltalk 言語ですから、逆にメッセージ指向を学ぶのに、これ
以上のものはありません。

一方で「クラス指向」と呼ぶべき現在主流のオブジェクト指向は、ずっと複雑です。これは
「抽象データ型」、つまり、ユーザーが自由にデータ型を定義できるしくみに加えて、定義
した型から「派生」させて別の型作成を容易にするしくみ、さらに、関数を動的に呼び出す
「仮想関数」というしくみを知って活用することを目指すものです。従来、言語仕様に
組み込まれて自由にはできなかった“データ型”とその振る舞いを、「クラス」として
ユーザーの手で定義できるメリットは大きいのですが、そのぶん、学ばなければ
ならないことも多くなります。なので、こちらを会得しようと思ったら、片手間では
ちょっと難しいかもしれませんね。

>285
Javaは多重継承を制限付きでサポートする (実装の多重継承はできない)


バートランド・メイヤーいわく、GenericityやガベッジコレクションもOOには必須らしい
あと個人的にはクロージャがファーストクラスかどうか、とか

Javaなんて参考にならん
Javaはオブジェクト指向の糞を集めた言語

Ruby は副手続きの定義順に悩む罠

>>290
丁寧なレス、サンクス。
趣味程度だと、Smalltalkが良さそうだね。

本屋に行ったけど、Smalltalkの本があまりない。
Squeakってのでもいいのでしょうか？

>>294
＞Smalltalkの本があまりない

つーか、どーでもいいくだらん本が多いだけだと思う。

>>295
そうなんだ。
やっぱRubyの方がいいのかな〜。

というか、もっといい本が出るまで待つか。
急ぐ理由なんてないし。

待つ？ Ruby の本を？
いい本1冊買えば足りると思うけど。

Smalltalk の本？　待っても増えないと思うけど。
しかも日本語のを期待しても、

>>297
そのいい本って何ですか？

>>298
Eiffel

>>299
お〜、また新しい言語ですか・・・

いい本、まだぁ？

Agile

>>298
本人本
ttp://www.ascii.co.jp/books/detail/4-7561/4-7561-3254-5.html

>>303
本屋で見たら難しそうでした・・・

偶然、このスレ↓が新しくたったので、見つけたのですが、D言語ってどうなのでしょうか？
今、これのHP読んでるのですが、評価するのは私には難しいっす。

D言語 Part.4
http://pc5.2ch.net/test/read.cgi/tech/1091185216/

こんな記述があったわ。

＞最初に学ぶプログラミング言語として。 Basic か Java が初心者には向いています。
＞D は、中級〜上級者プログラマが二番目に修得する言語として優れています。

>>304
書籍にこだわらなければ、ウェブの資料で十分。

D言語って、まだβ版じゃなかったっけか。違ったらごめんだけど。

C言語でオブジェクト指向風なコーディングをしてみるのはどうすかね。
gtkのソースとか眺めてみたりしてさ。
rubyとかはその後に勉強してもいいでしょ。
そしたらオブジェクト指向言語ってすっきりかけるなぁとかしみじみしてみたり。

>>306
そうですか。
とりあえずそれでゆっくりやっていきます。

>>307
Cは以前、少し使ったことがあるので、文法は知ってるんですよね。
最近の言語って（見た目の記述が）Cライクなのが多くて、C知ってて
良かったな〜と思ってます。

gtk ｸﾞｸﾞってみます。

http://www.kmonos.net/alang/d/comparison.html

よさげだな。。。

でもまだバグだらけでとても使えたもんじゃないよ

＞Cは以前、少し使ったことがあるので、文法は知ってるんですよね。

ホントか(w

保守していいの？

>>311
うん、for文とか。
意表をついてperlにしました。

釣り？

>>314
本物です。

しかし、この「指向」っていう日本語は適切なのかね？
英語→日本語の訳という意味ではなく
Object Orientの本質と「指向」が一致しているのかと。。。

このスレをみて思う俺様であった。

そうだな…Object Oriented Programmingか

東方見物禄でどうだ

Objective Oriental Programming

つーか、オブジェクト指向ってよりは、オブジェクト適用プログラミング
ってほうがしっくりくるかな？

『オブジェクト着目』だとおもう。
しかし、この世界、先に訳した人のものだな。
石田の『関数』とか。

キーボードを鍵盤と訳された日にゃ

オブジェクト指向は、語順の並びが変でわかりにくい。

今まで、
save( "fname",resize( 100,200,image));
って述語→目的語って英語の語順みたいに並んでたのが、急に

image.resize(100,200).save("fname");
って目的語→述語って、日本語風になっちまった。混在してて読みにくいんだよ！

save("fname")^resize(100,200)^image;
みたいに書くようにできんもんかね？

もちろんできるんじゃない？
syntaxの問題だけだもん。

>322
目的語じゃない。主語だ。
image が saveするんだ。 image を save するんじゃない。
手続指向から早く脱しろよ。

アルゴル系のプログラムってのは、文は原則命令文なわけで
命令文の主語は、二人称
そして、imageは三人称

そういうわけで、俺も違和感ある
自分で作るときは、関数記法を使えるようにしてしまうことが多いな

class foo {
　public:
　　virtual int bar(int hoge);
};

inline int bar(foo& f, int hoge)
{
　return f.bar(hoge);
}

こんな感じで

オブジェクト指向に脳がついていけない
かわいそうな人のスレはここですか?

ついてってないのは、むしろあんただろ

x.foo()が多態して、foo(x)が多態しないというのは、
c++とかの特定の言語の文法に限った話
しかもc++は、上記のように、多態させることも可能

foo(x)と書いて、普通にxの動的な型に応じて多態する言語もあるAdaとかな

さらに、foo(x,y)とかx.foo(y)と書いた時に
xとyの両方の動的な型に応じて多態して欲しかったら
(More Effective C++の項目31のような場合）
x.foo(y)という書式は非常に違和感がある

>>327
Smalltalk、C++、Javaのように obj foo: とするのか、
CLOSみたいに (foo obj) にするのか、
どっちだっていいし、どっちでも理解できた方がいい

obj.foo() にしないと理解できない>>322みたいな連中の事を言ってるだけなのに
そんなに必死に弁護せんでも

あいもかわらず、
オブジェクト指向とオブジェクト指向プログラミングを
混同しているわけだが。。。

>>328
あたまにオブジェクトを持ってくるのは SIMULA からそうで、
単に関数の動的結合の際の名前空間の特定のためだから、主語とか
暗黙の第一引数とか、もっと言えばオブジェクト指向とか、そんなのとは
全然関係ないよ。 SIMULA の当時はオブジェクト指向なんて言葉すら
なかったからね。あったのはクラスとオブジェクトだけ。

もうちょっと勉強しようね。＞オブ厨

とんでもねぇ、あたしゃ神様だよ

すまん、それだけじゃ足らんかったね。
『オブジェクト指向』と
『オブジェクト指向プログラミング』と
『オブジェクト指向プログラミング言語』だ。

>>332
それぞれの定義も出典も提示できん奴にフィーリングで分類される
オブジェクト指向もずいぶん不幸なパラダイムだなぁ…。

>>333
んじゃあ、お前が示せ。

子供の喧嘩だな

パラダイム銀河

>>334
いやいや。そもそもそんな区別はご都合主義の後付けだっていう反語だよ。
そんなことも分からんとは、ほんと駄目だな。オブ（理解できてると勘違いしてる）厨は…

実際、オブジェクト指向ってフィーリングでしか捉えられていない気もする。

たとえば、「構造化プログラミングとは？」との問いなら
「ダイクストラの本を読め」で終わる。
構造化プログラミングをあみ出したのはダイクストラだし
権威以前に、それが定義だ。

それがオブジェクト指向については聞いたこともない。
(知っている人いたら教えて)

（つづき)

で、俺が捕らえているオブジェクト指向は、
オブジェクト指向って哲学なんだよね数学じゃなくて。
(似ている領域ではあるが)

物や事象を人がどう認識するのかというところからモデリングする。
(そうすると現実の世界と将来を含めてモデルのズレが少なくなる。
人が認識できる範囲なんだから)

もっと手っ取り早い言い方すると、「それは何か？」っていうことを
とことんモデリングする。

ってところがオブジェクト指向なんだろうか？
具体的な作業レベルにまで落ちていないんでわからんが。

(つづき)

で、物や事象の認識は、種類で囲う方法や構造(どういう部品からできているか)
などがあってそれが継承や包含にあたる。ってとこかな。

だけどプログラミングの話で出てくる継承は
モデリングで出てくる継承以外に、プログラム的な都合による継承
(機能の追加や、ポリモフィズム。あ、ポリモは微妙だな)もあるので
その辺は別に考えないとごっちゃになるなっと。

これがオブジェクト指向の正解かどうかわからんが。変なら指摘してちょ。
むしろ議論は(前向きなら）ウエルカム。

>>338
誰が作った言葉かも知らないというなら、まず、coined-the-term-object-oriented
とかでぐぐれ。話はそれからだ。

>>340
みたいな勘違いを招きやすいから
オブジェクト指向は難しいと
おもわれるんだろうな。

わかったわかった。俺はバカだよ。勘違い厨房だよ。

>>341
んーで、答えはなんなの。なんでこう答えをズバット言えんの？

>>342
で勘違いを具体的に指摘してちょ。精進するから。

現実の物事をそのままモデリングして
プログラムコードに乗せられると思っているところ

>>344
あー、その辺は難しいよなーとは感じていた。
だから具体的な作業レベルに落ちれないと(言い訳気味)

じゃあどうすれば？

>>341
とりあえず、ぐぐってみたがアラン・ケイというキーワードがでる。
彼のことを言っていますか？

彼の編み出したオブジェクト指向というのは、「メッセージ指向」な予感。
今現在で言われているオブジェクト指向は、もうそれ以上のような。

そういうことはそもそも不可能だってことに気づいてください。
そういったことをオブジェクト指向プログラミングが
目指しているわけではない。

>>347
何を目指しているんでしょう？
(有能な人を捕まえるチャンスってめったに無いんで、質問厨になるのはお許しを)

オブジェクト指向で何が難しいかって言われたら、
抽象概念の導出だと思うんだけど、どうよ？

>>346
ほんっとにお前はどーしようもないな。
メッセージ指向の何を知ってそれを言う？
お前の言う現実世界を云々は、まさにそれの受け売りだというのに。
そもそも当初の意味を失ったオブジェクト指向には
メッセージメタファ同様、もはや無用のコンセプトなんだよ。
では、誰がいつどんな定義で乗っ取ったのか？　ここからが本題だってえのに……

>>350
その本題を語って…

>>350
歴史的な流れを言うと、アランケイな気もするのですが
なんとなく、卵の前に鶏が出てしまった感もあるのは俺の勘違いなんでしょうね。

ttp://pc5.2ch.net/test/read.cgi/tech/1101931660/

つまり、オブジェクト指向とは

何か？を説明できないくせに
何かを説明するとバカにする

概念なんだな。このスレをみて、それだけはわかった。

2chのような知ったかぶりの巣窟でそれを言っても始まらん

C++を勉強中の俺が言うのもなんだけど、解らないってやつは、ooの何が解らないわけ？
ooよりもポインタのほうが理解しずらかったんだけど。。
よっぽど教材が悪かったんか？

説明の仕方

>>356
教材によってOOの説明が違う。

昔の教材：継承による差分プログラミング
少し前の教材：クラスによるカプセル化
GoF後：抽象化の手段


初心者のころ一番悩んだのは
ワンとかニャーとかOOPLの機能自体はわかっても
その使い方がわからなかった
ポインタ型を覚えてもその使い道がわからなったのと同じ経験

C+から入った人が思うooと、設計論から入った人のooで違うんだと思う。
同じooというシンボルに異なる意味があるから難しいだろうなと思う。

>初心者のころ一番悩んだのは
>ワンとかニャーとかOOPLの機能自体はわかっても
>その使い方がわからなかった

ワンとかニャーの話はオブジェクト指向言語の説明としては全く正しいけど、
オブジェクト指向設計の説明としては、だからなんなのとしか言いようがないね。
言語と設計を区別して説明しないといかんのだと思う。

MayerのEiffel本読むといいよ

>>351
お前はほんっとに駄目だなぁ…。ものには段階ってものがあるし、
それ以前に、つまらん知ったかで応酬したり、他人にものを要求する前に
自分のやるべきことがいくらでもあるだろう。たとえば、ぐぐって出てきた
最初のページくらい、ざっとでもいいから目を通してみたのか？　そこに
次のステップへのヒントがあるとは思い付かないのか？

>>361
今どきメイヤーなんか勧めるヤツの気が知れん。
ありゃ、理解を確認するための本で、学ぶための本じゃない。
書いてあることがぜーんぶ知っていることならセーフってなだけ。
知らないことが書いてあっても、それが何かをあれから学ぶことはできんよ。

知らないことがあるということを学べればいいんだよ。

363は自分で説明出来ないから勝手に調べろって言ってるだけだから無視していいよ。
言ったら同じように、突っ込みのマトにされるのがわかっていて、それが怖いだけ。

362もな

>>364
まあ、それは一理ある。

>>363
だけど、メイヤーは頭いいと思うよ。例外の定義のところで、
「事前条件が満たされているのに事後条件を満たせない状態が『例外』だ」って
書いてたけど、こんなすっきりした定義、なかなか、考えつかないと思う。

>>368
>>363 は読んでも分からんのが怖くて読まずに批判だけしている厨房

>>368
だからって何でもかんでもExceptionを投げるのは馬鹿だよな。

>>370
>>368の意味理解してないだろ

事前条件が明確になっている場面に遭遇したことがないんだが。

>>371
つまり理解してない馬鹿がJAVAを作ったという事か？

ヒロシです…

>>370とか>>373には、意味論の入門書（特に公理論的意味論）の
目次とかindexだけでも見てほしかとです。

ヒロシです…



ヒロシです…

こうして今日また、まんまと釣られてしまったとです。

ヒロシです…

>>373
その通り。いまごろ気付いたの？

オブジェクト指向プログラミングの練習として
簡単な掲示板を作ろうと思ったんですが
いきなり躓いています。

>>376
それだけ言われてもどうしようもないんだが。

データベースの一つの行を１つのオブジェクトに対応させようとすると
クエリを何十回も発行しなきゃいけなくなるんですがこれでいいんでしょうか
パフォーマンスがすごい落ちそう。

それとも行を挿入するときと取得するときで
別々のクラスを作ればいいのか
でもそれもなんか変な気がする。あｆｄさｆｄｓｋｆｊさｆｌうぇあｑｗせｄｒｆｔｇｙふじこｌ

オブジェクト同士でデータをやりとりするときに
いちいちオブジェクトのプロパティにオブジェクトの参照を代入しなければならないのが面倒。
だいたい参照を持たせるのなら
その時点で結合度が高くなって一つの変更が局所化できなくなる。
オブジェクト指向プログラミングに何の利益があるのか。

参照と書いたけど、実体である場合が多い。

それはO/Rマッピングや依存性注入（DI）などなど
最近にぎやかに議論されておる所になると思います。

DIについてはSpringやseasarというフレームワークについて
調べてみると良いかも知れません。

特に380の疑問点には、DIの考え方は
ほほーとなると思います。俺もなんかすっきりしました。
まだ実案件で使った事ないんですけどね。

私は国産なのでseasarが良いなーと思ってます。
tp://www.seasar.org/

つか、あまりにもスマートな疑問の湧き方なので
ネタかとも思いましたが、一応。

あと、アジャイルソフトウェア開発の奥義って本
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361
分厚くて高いですが、すいすい読めてお勧めです。
私はあまりOO大好き人間ではないのですけれど、
interfaceを中心に設計して、実装と切り離して疎結合を実現する
オブジェクト設計の原則は大変為になりました。

DIはそのinterfaceに対する実装を実行時に行うイメージですかね。

ありがとうございます
ぐぐりつつ勉強します。

とりあえず
message
messagelist
controller
db_message
のクラスを作った。
messsageに新たな項目を増やそうとすると
controller message db_message
クラスを変更する必要がある。
メッセージのソート方法を追加しようとすると
controller db_message
クラスを変更する必要がある。
一つの変更が全体に影響するよい例を作ってしまった。

何これ(´A`)

あとmapperクラスも作った
dbのフィールド名とmessageクラスのプロパティの変数名を
関係づけるためのクラス。
値しか持っていない。

入力データはプレゼンテーション層から永続層まで
流れていくものだから、入力項目追加の影響が
全体に波及するのはしょむない事だと思いますよ。

mapperクラスかあ。俺はすぐあるもの使う奴だけど
一度自分でやってみてからO/Rマッピングとか触れたら
面白さとか全然違うんだろうなあ。
頑張って下さい。

どうにかがんばります。
ありがとうございます。

db_messageクラスは
messageの項目の増減に影響されないように
コーディングできました。
ただし、トリッキーなコードになってしまった。

http://kakutani.com/trans/fowler/injection.html

このページで依存性注入読みました。
これはおもしろいですね。
逆に、実装側のオブジェクトを引数として与えるんですね。
なるほどって感じです。
おもしろい。
使ってみよう。

WEB+DB pressの前の前の号かな、
seasarの記事がありますんでオススメ。
DIのよさがかなり判りやすく書いてありました。

tp://www.gihyo.co.jp/magazines/wdpress/archive/Vol22

この号は他にも逆引きデザインパターンとか
なかなか面白かった。

あとseasarはスレもあります。

国産DIコンテナSeasarとくーす その３
http://pc5.2ch.net/test/read.cgi/tech/1102862221/l50

アジャイルソフトウェア開発の奥義
飼いましたイイです！
>>389
ヨドバシいってみます。

ところで、DBのフィールド名と、それに対応するModel層のオブジェクトのプロパティの
変数名を一致させるという拘束は
一般的に許容できる程度の拘束なんでしょうか？

>>390
一般的なO/Rマッピングフレームワークだと（EJBもそうだけど）
DBフィールドとオブジェクトの変数名は
一致させなくてもいい作りになってますね。
XMLファイルなどでマッピングの情報を持ったりします。

DBとオブジェクトのマッピングを自前でやる場合は
もうそれこそ俺ルールで構わないと思います。

奥義、いっすよねー。分厚くて高いけど、
すいすい読めるし元は取ったなあ。

>>362

Smalltalkのメッセージ指向から
Simulaのシュミレーション処理と複雑さの管理へと辿る訳ですか？

もし、そうだと仮定し早漏気味に考えると

オブジェクト指向という言葉群が取扱う対象は、モデル対象自体の複雑性であって
データという、それ自体の難しさを解決する物では無い。

つまり別に現実であるリアルだろうが、仮想であるシステムだろうが、
存在箇所がどっちでも構わない「情報」を、扱う事が目的である業務システムでは
オブジェクト指向という言葉群の概念だけでは事を成し得ないと
考えられているのでしょうか？

この結論で今までの霧が晴れた様に感じているのは幻想なのか？

具体的にはどういう霧がかかっていたんですか？

>>393
簡単に且つ間違いを恐れずに言えば、構造化分析や構造化設計の勉強を抜きで
オブジェクト指向分析やオブジェクト指向設計でシステム開発が出来ると思っていた。

つまり、オブジェクト指向分析やオブジェクト指向設計だけでは
最後まで到達出来ない領域があって、そこの解決手段に悩んでいた。

って言って通じるかな？

ニュートン力学を理解しないで、
相対性理論や量子力学を理解できるはずもない

>>395
それは理解力の話ではなく前提知識という意味で？

オブジェクト指向を学習しても、いつも幼稚園児に言葉を教えるような
話ばかりで…orz状態です。

大抵の先生は、若くて綺麗なねーちゃんなので、それはそれで楽しい
のですが…、

みんな、あんな講座受けて理解しているのだろうか？
それとも、洩れ見たいに、いつまでも理解できんのだろうか？

>397
どこがわからないの？

オブジェクト指向っていきなり理解するより、
まず手続き型言語（Ｃなど）をやってから、それとの違いを意識しながら
勉強すると効率いいと思うんだけど。遠回りだが。

>399
まあ、今のオブジェクト指向は手続き型言語をベースにしているからね。
オブジェクト指向言語を駆動しているツールを知るのも悪くないかも。

ただ、オブジェクト指向と手続き指向は、それぞれ目指している
理想像が結構違ったりするところもある。んで、そのあたりが
ごっちゃにならないようにしないとね。

理想像は同じで方法が違うだけだと俺は思う。（OOPの方が優れている）

>401
結構違うと思うよ。

一番違うのが、
　手続き指向：シングルスケール
　オブジェクト指向：マルチスケール
な点じゃないかな。
手続き指向は細部まで作り込みできるから最適化しやすいけど、
規模が大きくなると大変……

手続き型やってるころはモジュールを作るのが苦手だったけど
（どうしても各モジュールの依存関係が強い)

オブジェクト指向やり初めて、デザパタ勉強したあたりから
自然と独立度の高いモジュール化ができるようになったなぁ。
多分今なら手続き型でも独立度の高いモジュールを作れるんだろうけど。

>>398
何が分からんと言う答えには、正直つまってしまう。ｗ

説明してることは、（やさしく説明してくれるので）大変良く分かるんですけど、
概念レベルでは、ホニュウ類とハチュウ類とか、そんな例え話ばかりで。

しかも、いざ作業レベルにはいっても
ＧＵＩでツールをペタペタはるだけ。

オブジェクト指向の本質って何？？？っていつも思ってしまう。

ちなみに、ＣやＰＥＲＬは仕事で普通に書いてる非常に経験の長い
（Over 20）ジジイだったりします。

オブジェクトって名詞で表現できるものだろ？
オブジェクト指向は、その名詞で表せるものを現実世界のように取り扱うって考え方で。「○○をどうする（会議を開く）」とか。
違うかな。
猫とか犬とかの動物が鳴くって考え方よりマシだと思うんだが。

で、実践UMLの内容は正しいって考えて良いんだよね？
オブジェクト指向の本質に入るなら、これが良い入門書になると思うんだ。

間違ってたら指摘きぼん

>>405
オブジェクト指向は流派や流儀が多くて、
一概には定義できま（ry

たしかに「オブジェクト指向」というタームを共有するパラダイム
はいくつかありますが、そんなに多くはないですよ。根底を流れる
コンセプトを論文を読んで学ぶのではなく、そのインスタンスに過
ぎない言語の使用経験から得た知識や感触から語る人が多く、さら
にそこから又聞きで広めようとする風潮があるから混乱に拍車がか
かるのだと思います。犬猫の類なんかその典型的な例でしょう。

ほ乳類とかの例が出てくる本読むと、
何か釈然としないものが残るのはなんでだろう。

>>407
しかも、語る人によって解釈も説明も大きく違う。
オブジェクト指向系の人を２人つれてくると、必ず（ry

>>408
業務用アプリケーションじゃ走ったり飛んだりの自発的動作をしてくれそうなオブジェクトは
ユーザーぐらいしか見つからないもんな。

>>406
つまり正解はないけどハズレでもない・・・ってことだよね。

今月のCマガで、結城のとっつぁんがいいこと言っていたよ。
「オブジェクトは小さなプログラムと似ています」だって。
マルチスケール性を言いえて妙だね


>404
>オブジェクト指向の本質って何？？？っていつも思ってしまう。

>406の言う通り、本質はいくつもあるし言う人によっても変わるけど
取りあえず私の私見は、
　常に慣れ親しんでいる現実世界のメタファーをうまくプログラムに
　取り込むためのもの。そのために、現実世界の「対象」という概念を
　表現する枠組みを用意したもの。
じゃないかな、と思います。

で、「対象」という概念を使うと、

・同じような「対象」をグループ化することができる
・同じような「対象」は同じように操作できる／動作・反応する（is-aの関係）
　（その他 has-a, imprement-of……）
・「対象」の中の構造を知らなくても、操作に対してどのように反応するかを
　知っていれば「対象」を操ることができる（カプセル化、インターフェイス）

とか、色々便利なことが（少ない学習で）活用することができます。

上の方、煽るつもりは無いんだけど、
何でオブジェクト指向の説明って、何の言語かも分からない説明を
使いたがるんだろうねぇ？

例）メタファー

オブジェクト指向の理解なくしてプログラミングの理解は
得られない。
初学者は、ifやwhileを覚える前にまずオブジェクト指向を
徹底的に学習し、その概念をある程度掴んで置く事が大切だと
講師に言われた事がある。
始めは、難しさから反発したのだが、勉強が進むにつれ
確かにその通りだなって思うようになったよ。

>>413
かっこつけている面もあるけど、英語の方が概念をうまく表せることが多いぞ。

オブジェクト指向は言葉遊び

>413
日本語で近いのは「隠喩」だけど……「象徴」という概念も含むし、難しいね。

>>413
> 何でオブジェクト指向の説明って、何の言語かも分からない説明を
> 使いたがるんだろうねぇ？
> 例）メタファー
正直言ってあなたの日本語もどうかと思います。
>>415-が苦もなく理解してるのがすごい。それとも俺の読解能力が低いのか？

普通に分かると思われ

メタファーに限って言えば、英語（カタカナ語）のほうが一般的
だよね。隠喩とか無理して日本語で言われても何のことだかさっぱり。

それはともかく>>412は典型的に駄目なオブジェクト指向の説明だよね。
こういうのが我が物顔にはびこるから混乱するんだ。

>>421
剥げ同。

フェノメナが、きちんと記述されていない。

フェノメナってなあに？
フェラとは違うの？

同じだよ　ちょっとえっち

>>422
お前、いいオブジェクト使いになれそうだなｗ
そのなんとなく分かりそうで分からない単語ｗ

可愛い美人講師が、犬→ワンワンとかいってると、
ついつい「ワンワンスタイルで…」などと想像してしま（ry

>404
GUIと言えば、こんな記事あったよ
ttp://pc.watch.impress.co.jp/docs/2005/0121/config035.htm

>421
それだけじゃなぁ……
・駄目なオブジェクト指向の説明とする根拠
・良いなオブジェクト指向の説明
のどっちかぐらい論理展開してよ。批判にもなってないよ。

>422
フェノメナってなに？

オブジェクト指向とは関数付き変数であって
それ以上の意味はない

そりゃオブジェクト指向プログラミングの説明じゃ

>>427
Phenomenon のことと思われ。
>>428-429
それが全てでしょ。

>430
いや、それがオブジェクト指向の文脈だとどういうい意味なのかと……

>428
いや、それは手段であって、そのものじゃないと思うけど。

オブジェクトとは関数付き変数であって
それ以上の意味はない

>>431
どう思ってるんだね？

>>432
コンストラクタも関数？

>>433
違うの？

>>432
ハゲ同なんだが、それ以外の考えってある？

>432
意味ということなら、ちょっと簡単化しすぎかなぁと思う。

確かに状態を表す変数とふるまいを表す関数をセットにしたのが
オブジェクトだけど、あるクラス（分類・凡例）のインスタンス（事例）
としての意味もあるしね

つまり、犬→ワンワン
のアレ？

>>433
当然だ。変数と言うのは必ず初期化しなければ
ならない。そうではなかったかな？

>>435
>>436
のようだ。
俺にはほとんど理解不能だね。

オブジェクトなんて何者でもないよ。定義しようとするだけ時間の無駄。
大事なのは、クラスだ。クラスは我々に“データ型”を定義する自由を
与えてくれる。オブジェクト指向なんて、どうやってうまく完璧で安全で
使える“型”を定義するかってだけのことだ。ワンニャンなんて関係ない。
現実世界云々なんてのはSmalltalkローカルな考え方に意味も分からず
翻弄されているだけ。

>>439 クラスベース万歳の人か。

静的チェックは大好きだけどプロトタイプベースの訳わかんない動的さもイカス。

>439
ユーザー型定義でいいんだったら別にクラスである必要も無いけどね。

オブジェクト指向だとユースケースとかアクターとかでモデル化されることが
多いけど、これはクラスという概念に納まっていないんじゃない？

逆だろ。ユーザー型定義のためにオブジェクト指向が選んだのが
（SIMULA発祥の）クラスなんだよ。他にあるからなんだってえの。

モデル化云々いったって、結局最後はどう型に落とし込むかだし。

Pythonの書き方ってクラスだっけ？

志村うしろー(棒読み)

>442
型のある言語ならな

文の定義も最新の言語では変わって来てるんだね。
勉強になった。（例：Ruby）

>>442
クラスは、つまりSimulaのクラスは、オブジェクト指向のために作られた
ものではないという但し書きは入れておいたほうがよいでしょう。混乱
する人もいるかもしれませんが、オブジェクトすら、オブジェクト指向の
ために作られたものではないのです。これはオブジェクト指向が何かを
語る前に是非知っておきたいことのひとつだと思います。

ユーザー定義の型という考え方はSimula以前にもなかったわけではありませんが、
注目を集めたり、実装して試されるようになったのは、Simula以降です。
したがって、ユーザー型定義の手法がいくつかあったとしても、その多く
は、Simulaのクラスをヒントに考案されたものがほとんどです。なので、
オブジェクト指向の本質を型定義とするなら、これら（抽象データ型）との
差別化についても言及する必要はあるのでは？

全ての実装はオブジェクト指向というイデアの影なのれすよ。

志村？

>>447
まあ、抽象データ型に分類される言語もオブジェクト指向言語だと
信じて疑わない人も多いから明確な区別はできないんでね？
オブジェクト指向設計を言い出したBoochタソはいってもAdaな人だし。

>>439
オブジェクト指向の本質は
オブジェクト（インスタンス）と
その振る舞いの定義であって
クラスや型といったものは本来その実装手段に過ぎない。

つーか何人か指摘してるけど
プロトタイプベースのオブジェクト指向言語は
仲間はずれっすか？
http://sumim.no-ip.com:8080/wiki/493

使う側が気になるのは結局どの程度まで動的なのかだと思う。
動的→遅い。
静的→速い。
速ければ速いほど良い。

>>451
だから、それは安全で使用に耐える型の定義と同義だろ。
メモリ上のデータに「振る舞い」とか言うな。気色悪い。

プロチはSmalltalkのエッセンスを抽出しただけのモノだから
Smalltalkと同じ穴のムジナ（振る舞いとか言い出すクチだ…）だし、
現在主流のオブジェクト指向とはそもそも関係ない代物だよ。
お情けでオブジェクト指向を名乗らせてあげてるだけで。
型安全性もクソもないじゃん。あんないい加減な言語。

じゃあ逆に聞くけど、プロチな言語処理系のほとんどすべてに
クラスが実装されているのはナゼさ？

>>452
速くて動的ならいい？　そんなわきゃあない。

>453
>型安全性もクソもないじゃん。あんないい加減な言語。

なんか……設計の柔軟性と引き換えに型安全性が
弱くなっていることを解っていないのかなぁ。

>じゃあ逆に聞くけど、プロチな言語処理系のほとんどすべてに
>クラスが実装されているのはナゼさ？

設計が固まった後に（クラス指定による振る舞いの固定化で）
予定外の状態になることを防いでいるんじゃない？

fortranﾏﾝｾｰ

とりあえず、Modern C++ Designの第一章だけでも良いから
読んどけ。な

　設計とは、制約を課す作業のことです。従って、
　設計指向のライブラリは、 *設計済みの制約*
　ではなく、*ユーザの考え出した設計自身の制約*
　を強制するように支援しなくてはなりません。

至極名言だな。強い静的型付けだと*設計済みの制約*て
やつに縛られやすく、プログラマがそこから逃れるのが
とても大変なんだよねぇ

＃Modern C++ DesignではTemplateによるシンタックス指向と
＃オブジェクト指向を組み合わせたマルチパラダイムによる
＃解が紹介されていますな。

オブジェクト指向の本を読んでわかったような気になっている香具師ばかり
残った気がする。このスレは。

オブジェクト指向なんて考えず
オブジェクトとオブジェクト指向プログラミング（言語）について考えてればそれで満足なのれすよ

わかった気にさせてくれる本を紹介しておくれ。　c++かperl。

「オブジェクト指向でなぜ作るのか」

ふむ。こんど見てみる。thx

>>453
>現在主流のオブジェクト指向とはそもそも関係ない代物だよ。

主流でないからといって無視してよい理由にはならない。

異動車両のほとんどに車輪が使われているからといって
キャタピラやソリその他がまったく不必要なわけじゃない。

>>463
装軌戦車なんか時代遅れ。
これからは装輪ですよ。

>>463
無視できない存在だからといって、
節操なく取り入れてよいということにはならない。

移動車両における車輪の使い方もよく分かっていない状態で、
キャタピラやソリが便利だからといって取り入れたところで混乱を招くだけ。

鎖キャタピラ

>465
主流かどうか「のみ」でものごとを判断するのはちょっと……
「小人は同じて和せず」と論語にもあるしね。

>移動車両における車輪の使い方もよく分かっていない状態で、
>キャタピラやソリが便利だからといって取り入れたところで混乱を招くだけ。

どういう時に使うべきでどういう時に使うべきでないかを理解していない
うちは、使い方が解ったなんて恥ずかしくてとても言えないねぇ
車輪が不便だと解っているのに、ソリの代わりに車輪を氷上で使うのは
ちょっとなぁ……

車輪の性能が上がっているので強引に押し通すこともできるけど、
マルチパラダイムで適材適所で使えばいいじゃん。

いえ、私はやはり航空機が好みです

飛行機だけはカンベンな

>>469
どっか別の所で見たぞそのネタ。
ここだっけ？

ハンニバルっていったら人食いじゃなくて
こっちだよなー。

オブジェクト指向がわかった！
スゲー感動した！！
インタフェースとコンポジションとの組み合わせ最高！！

>>457
こんなのもあったぞ

設計というものは、・・・できることとできないことを実行前に
決定する規則を完備したものなのではないでしょうか？

分析

型というものは、できることとできないことを実行前に
決定する規則を完備したものなのではないでしょうか？

ポリシーというものは、できることとできないことを実行前に
決定する規則を完備したものなのではないでしょうか？

・・・何にでも当てはまるな

>>475
汎用性があるとか普遍的だとか言ってやれ。

オブジェクト指向プログラミングにおいて
設定ファイルのようなものを作りたいのですが、
今までの非OOPのようなCで言うところのdefine定義を羅列した
ファイルを設定ファイルとしてインクルードする方法はどうかと思い、
コンストラクタでデータを定義したゲッターのみのクラスを作ろうかと
考えたのですが、一般的なオブジェクト指向プログラミングにおいて
設定ファイルのようなものはどのような形にするべきなのでしょうか？

オブジェクト指向プログラミング初心者なので変な質問かもしれませんが
指揮者のご意見をお聞かせいただければと思います。

>>476
stdafx.h

>>476
Object Persistency
または
Persistent Object

>>476
pear/Config :-p

(・∀・)ﾊｲｰｷｮ


ところで、状態を持たないオブジェクトを扱える言語ってある？

キチガイ晒し上げ

間違えてたｽﾏﾇ

状態を持たないオブジェクトしか扱えない言語ってある？

……ちょっと変だな。
初期状態から変化しないとか、そういう意味で。

えぇ〜と、キミは変数への破壊的代入がない関数型言語やった方がいいと思うよ。

もしかして、BPMNじゃなくUMLのクラス図で、HIPOチャート書く派の人？

そう急かすなって。

>>480
オブジェクト＝データ構造＋処理
として、状態を持たない/状態変換のないオブジェクト
って具体的にどういう事なの？

×状態変換
○状態変化

>>486
え〜っと、インスタンス変数が全部 readonly な奴です
ローカル変数はどうだって良いや


あるメソッドに渡したオブジェクトが意図しない改変されてたら迷惑だな〜って思ったんですが、
んじゃ状態変化が無いオブジェクトを扱う言語ってあったかな？　って、ふと思いまして

>>488
Immutableパターン？
単純な不変オブジェクトが欲しいなら、セッターメソッドを提供しない
だけで済むと思うが・・・・・・
FactoryやDIと組み合わせるパターンは・・・・・・まっ、いいかｗ

>>489
Immutable パターンって言うのか。結城本しか持ってなかったから知らんかったよ。ﾄﾝｸｽ

とりあえず、不変性を確保できる言語はあるけど、変更できない言語はあったかな〜って思っただけなんで、
チラシの裏的発言と思ってもらえれば ^-^;

カプセル化設計 (データ隠蔽)について、
大きな誤解があると思う。

Java以降のやり方としては、
Immutableなインタフェースを作ってメソッドに渡せば、
オブジェクトの内部状態へのアクセスを制限できるのだが。

あ、Immutable はクラス構造じゃなくてスレッド構造の方でしたか。
結城本でもこっちは持ってなかったわ。

えぇ〜とぉ、結城本を金科玉条のようにして、
そのパターンに当てはめた質問をすると、
なにか楽しい事があるのですか？

あなたの質問には、その質問をするに至った思考過程や、
シチュエーションというものが欠けている。
それが、「問題定義をきちんとせずに、答えを出してきて、周りが付いて来ない」
という現象なんですが。

・そこら辺の問題意識や背景情報を、素人向きにネグっちゃってる点

・素人がそのパターンを丸暗記して、無理に現実に適用しようとする点

が、結城本の大きな問題点だと認識している。

>>493
＞そのパターンに当てはめた質問をすると、 
＞なにか楽しい事があるのですか？ 

パターンがあるとは知らなかった。許してくれ

＞その質問をするに至った思考過程

あとだしじゃんけんみたいで済まないが、理由は >>490 ということで

まぁそう熱くなるなって。

彼はこのスレで結城さんのThreadパターン本や、
その他のデザイン・パターンの話題をしたいのだろうって。
付き合ってあげたら？

>>496
んなわけあるかい
たまたま出てきただけじゃ

まぁ、そう熱くなるなって

アンチデザパタ必死杉

結城さんの教科書使ってデザイン・パターンの説明しる！
っていわれてやった事あるんだけど、
あのサンプル・プログラムは、初心者の独習用であって、
わざわざ時間かけてこっちが説明するにはキツイ(シンプル過ぎて実践的でない)
と思う。

例えば「Observerパターン」。

彼のサンプルは、Window Frameに一つのEventListenerを置き、
そこから各GUIパーツにイベントを振り分ける、というコードなんだが、
これって古いAWTのモデルとも、SWINGのモデルとも合致しない、
説明のための説明みたいな非現実的なコードなんだよな。

で俺はプロだから、結城さんのやり方、AWTのやり方、SWINGのやり方と、
三通りを説明する必要に迫られる。
実際アプリで使うのは、JBuilderが吐くSWING流のやり方だからね。
すると、説明が非常に難解で、初心者諸君にわかりにくいものになる。

>>494
て言うか、結城本てぶっちゃけカタログだから、あれでは何も学べない。
それは辞書だけで英語を学ぶ様なもんだ。
プログラムデザインやJAVAの格言なんかでは、SingletonやImmutable
の様な、それ自体は単純だけどその先が意外と深いものについてもき
ちんと説明されてる。

結城本を買うくらいなら自分の単価分ググった方がマシ。

といったような意味で、
独習したいなら結城本も結構でしょう。

俺が教えるなら、GoFなり"Pattern Language of Programming Design"1〜4から選んで、
サンプルプログラムを適切なものに修正して、説明する。
それだけの話だ。

まぁ、俺的には結城本はカタログ本などではなく、
GoFから表面掬い取った似非入門書に過ぎない、と思う。

>>500
深い所を求めるなら、
・結城本
・Javaの格言
などというゾッキ本だけでなく、
ちゃんと原典に手を伸ばして、
わかんなくなったらゾッキ本でカンニングするのが良い

>>500
カタログ本というのは、
・Design Language of Program Desing
・Architecture Pattern
のようなのを指す。

俺がパターンて単語を使ったから荒れたのか？
自分で使っといてなんだが、Immutableはそれ自体が意味を持ってるから
別にパターンじゃないし、結城本に出てくるImmutableパターンと今回の回
答にはあまり関連がないぞ。

>>480
>>491をスルーするな。君の疑問に対しては彼の回答こそが正しい。

充分一般的な問題定義などする能力もなく、
あらかじめ回答を決めて質問してくるようなのが、
２ちゃんの煽りなんだよ。

ほっとけって

>>503
読みにくいだろ？それ見栄とかカッコ付け抜きに本気で思ってる？

493=496=506
なんでこんなに必死なの？

>>507
読みにくい？じゃぁ水で薄めた読み易い本を読んどけばええやん。
俺は、わざわざセンスが悪い本を読んで、苦労したいとは思わない。

>>508
まぁええやん。

>>499訂正
・結城本のEventHandlerは、GUIと無関係なアプリ側に実装。
　アプリがイベントを解釈し、GUI部品の拡張メソッドを操作。

ＧｏＦ本、マジで素人衆の受け悪いのね。
すごい薄っぺらい理解でデザパタ騙るのが多いのは、
やっぱゾッキ本のせいなのか

>>510
GoF自体、C++とSmalltalkを扱った古い本だからなぁ〜
ここ数年の間にこの分野に入ってきた若手には、キッツイんだろうよ。
さりとて、JavaやC#に焼きなおしただけでは通用しないパターンも多いし。

いい加減、新しい世代のデザイン・パターン本が欲しいな。
あと、PoEAAとかドメイン・パターンとか、もっと高レベルで実用になるパターンの普及も必要だ。

具体性のなさが加速していく。
知ってる単語と書籍名を並べて何か語った気になりたい奴は
今がチャンスだ。

Javaの格言と結城本が座右の書である、
２ちゃん常駐コーダー様が、ありがたいお言葉を語るそうです。

ところでオマエ高校出てたっけ？ｗ

====================================================
　　チンパンジーくんのワンマンショーの開始です

　　物を投げたりせず、生暖かく見守ってあげましょう
====================================================

薄々思ってはいたが、必死な人はやっぱり同一人物だったな。

推薦図書/必読書のためのスレッド PART24
http://pc8.2ch.net/test/read.cgi/tech/1114902703/

【GoF】デザインパターン 3
http://pc8.2ch.net/test/read.cgi/tech/1095388499/

最高に頭悪そうな発言してください in ム板 (IV)
http://pc8.2ch.net/test/read.cgi/tech/1108989422/

国産DIコンテナSeasarとくーす その３
http://pc8.2ch.net/test/read.cgi/tech/1102862221/

同じ展開ワラタ。
以後この展開をチンパンジーパターンと命名する。

くだらねぇ煽りだなぁおい。

オマエは低能な質問しかできねぇ屑だから、
チンパン扱いされてるんだろｗ
さっさと動物園に帰れって。目が真っ赤だぞ(ｹﾞﾗｹﾞﾗ

バカがバカを煽る展開

ＰＣ等 [プログラム] オブジェクト指向・嗜好・試行・至高・歯垢
517
ＰＣ等 [プログラム] ■暗号技術【ROUND2】■
200
ＰＣ等 [プログラム] 【初心者】プログラム初心者に最適の言語ってなに？
100
ＰＣ等 [プログラム] プログラミングなんか興味ねぇんだよ！！
32
ＰＣ等 [プログラム] NetBeans / Sun One Studio
19 74
ＰＣ等 [プログラム] 【Java】次世代Java・J2SE1.6の動向【Mustang】
96 313

ＰＣ等 [プログラム] ミ,,ﾟДﾟ彡フサギコのﾌｻﾌｻDelphi談話室その22
202 297
ＰＣ等 [プログラム] 【Ver.4.0】ActiveBasic 2【開発中】
200
ＰＣ等 [プログラム] C＃って死滅する理由がないよね！ Part4
103 105 142-143 341 534
ＰＣ等 [プログラム] Java 高速GUI SWT　２
52
ＰＣ等 [プログラム] SDL=Simple DirectMedia Layerでゲームだ
28
ＰＣ等 [プログラム] JSF(JavaServer Faces)【.NET死亡？！！！】
59 91 98
ＰＣ等 [プログラム] 【必須?】XML技術【使ってる?】
23
ＰＣ等 [プログラム] WinFX を語るスレ Part4
312 398 404 430 492
ＰＣ等 [プログラム] COMにはやられた...
765
ＰＣ等 [プログラム] EJBは終わってる
360
ＰＣ等 [プログラム] ミ,,ﾟДﾟ彡フサギコのﾌｻﾌｻ.NET談話室
663
ＰＣ等 [プログラム] 【完全初心者】何をやったらいいですか？
142
ＰＣ等 [プログラム] J2EEを語ろう
257
ＰＣ等 [プログラム] .net と J2ee
196 207 352

【20 件見つかりました】

これなんかどうよ？
http://www.aw-bc.com/catalog/academic/product/0,1144,0201607344,00.html

>>521
　>>501　
　ソフトウェア・パターン　http://www.amazon.co.jp/exec/obidos/ASIN/4320120159/

>>521
　>>501＝PLoPD
　プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集
　http://www.amazon.co.jp/exec/obidos/ASIN/4797314397/

ここでこのような質問をすべきではないのかもしれませんが、ここしか思いつきませんでしたので
書き込ませていただきます。

C♯を使用していますが、不特定多数のオブジェクト (仮に Objects とする) を一括で管理する必要が
あり、コレクションを使って管理しようと考えました。管理を行うコレクションのクラスを static 宣言するという
手段は一般的に相応しいものなのでしょうか。

よろしくお願い致します。

>>524
すべきではないので染んでください

>>524
これにはそうやってますと書いてあったからいいんじゃないの
http://www.amazon.co.jp/exec/obidos/ASIN/4822221180

>>526
「（ここでこのような質問を）すべきでない」のつもりだった
言葉足らずでスマン

>>524
そのコレクションが複数のスレッドからアクセスされるなら、同期の問題が発生しますよ。
また、コレクションに追加されたオブジェクトをいつ誰が廃棄するのか、という点もあります。
本当に必要でなければ、避けた方がよいのでは？

格納するオブジェクトをすべからく
ステートレスに設計する必要がありますなー確かに。

キャッシュみたく考えてるんだったら
ステートレスにしておけば、廃棄されてたらまた生成、みたく出来る。

デザインパターンで名前付いてたな。こういうの。

判った風なレスつけてんじゃねぇ〜よｗ

一括管理と書いてあるだけで、
複数スレッドで共有して使いまわすなんて
ひとっことも書いてねぇ〜だろ（ぷ

さてはサーバアプリのインスタンス・プールとか、インスタンスのスレッド間共有で嵌ったクチだなｗ

複数スレッドでは共有しませんとも書いてないからな、
アドバイスとしちゃ言っといた方がいいと思うよ

もしwebアプリだったらなおさら。

>>532
ですよね。static 変数とするなら、
意図しなくても複数スレッドで共有されてしまう可能性が
ありますもんね。

>>532
ですよね。static 変数とするなら、
意図しなくても複数スレッドで共有されてしまう可能性が
ありますもんね。

>>532
ですよね。static 変数とするなら、
意図しなくても複数スレッドで共有されてしまう可能性が
ありますもんね。

なぜか、複数回、書き込まれました。失礼しました。

>>530も本当の事は言ってますが、
ヒアリングはスムーズに行ったのに
実装時にどでかい仕変が待っていた
なんてトラブルは大概こういう人がリーダーなんだよ。

って釣られたのかなー。

ここにもスレッドプログラミング程度でヒィヒィ逝っちゃう馬鹿が粘着中か。

オブジェクトって、結局、必要以上にでっかくて重たい重たいプログラムを
書くための道具だね。

オブジェクトを使うと、読みやすいプログラムは出来るけど、出来上がった
コードは、必要以上に膨らんで、重いし、めちゃくちゃ効率が悪い。

立ち上げに一分以上かかるような、＞GBの巨大なプログラムを書いて
喜んでるオブジェクト厨のお陰で半導体業界は儲かってるようなもんだな。

窓一つ出すだけでも、スーパーコンピューター並みのCPUが必要だし（藁

>>539
＞オブジェクトって、結局、必要以上にでっかくて重たい重たいプログラムを書くための道具だね。

これは当たっていると思うけど、その後の文、なんか変じゃないか？

オブジェクトを高級言語に置き換えてもオッケーだ

またお前か

Java の CPU ができたとすれば処理が速くなるかもな

とっくに出てるが何か。

"Java Chip" の検索結果 約 9,080 件中 1 - 10 件目 (0.27 秒)
http://www.google.com/search?num=50&hl=ja&c2coff=1&q=%22Java+Chip%22&lr=

　CPUプールをアプライアンスに，Azulが日本でのビジネスを本格化　(日経BP 2005/4/25)
　http://blog.nikkeibp.co.jp/itpro/java/archives/2005/04/cpuazul.html

　製品コンセプト > マイコン > Java Chip Solution - FUJITSU Japan
　http://edevice.fujitsu.com/jp/concept/product/micom/java/

　Sun makes Java chip deals | CNET News.com
　http://news.com.com/Sun+makes+Java+chip+deals/2100-1001_3-278485.html

　ARM, Sun broaden Java-chip effort | CNET News.com
　htto://news.com.com/ ARM,+Sun+broaden+Java-chip+effort/2100-1001_3-268935.html

　

萌え萌えオブジェクト指向の続きまだ〜？

２つ以上のオブジェクトの関連しあう場合に
どっちにメソッドをつければいいのかが良く分からない。
例えば、画用紙に、クレヨンで、四角を書く場合、とか、
将棋で将棋盤上の飛車があるマス目に移動できるかを判定する場合とかが
解りません。

画用紙の場合だと

画用紙
クレヨン
四角　extends Shape

って感じにクラスを抽出するとおもうんだけど。
書くというメソッドはどこにつけるのだろう？
Shapeにつけて置いて、
四角でオーバーライドすればポリモーフィズムっぽい感じもするし、
実際、多くの解説本とかだとそういう説明がなされているけれど、
Java2Dとかだと、画用紙#draw(Shape)って感じになってる。

将棋の例だと将棋盤でも駒でもなくて審判クラスを作れなんて書いてある本も多いけど、
だったら画用紙は画家クラスでも作るのか？とか悩んでしまう。

なにか、良い判断基準ってないのでしょうか？

書くのは人間だから人間

>>547
そうなんですか？
でもそうするとほとんどメソッドは人間クラスが持つことになっちゃう上に、
人間に持たすべきメンバ変数がないんで。
単に、構造体と関数で組んでる構造化プログラムを変わらないじゃあないのかなあ？
とか思ってしまうんです。

オブジェクトの状態をメッセージで変化させるなら確かに画用紙につけるべきなのかなあ
とか思うし、今後追加機能が予想されそうなのは楕円とか三角とかの形だから、
ポリモーフィズムを使いやすいように四角につけるべきかなあとかも思うし、
書くのはクレヨンだろとかいや人間（画家）だとかも思っていつも悩むんです。

四角には書きかたのヒントとか、図形の特性とかを伝えるメソッドを持たせる。
画用紙には抽象的な紙として、点の描画指示を受け付けるメソッドを持たせる。
クレヨンには抽象的な筆として、点や線の描画指示を受け付けて、紙に描画を指示するメソッドを持たせる。
人間には抽象的な描画メソッドを持たせて、図形や紙や筆に問い合わせながら、筆に描画指示を出させる。

こんな感じでやれば、人間に描画メソッドを持たせても、ただの構造化っぽくはならないと思う。

画家クラスは作らなくても良いでしょ。書くのは主体なんだから、

　画用紙：描く（クレヨン、四角）

で良いはず。あとは変則で

　クレヨン：描く（画用紙、四角）

とか

　四角：描く（クレヨン、画用紙）

とか。
好きな物を使えば良い。

>>550
画家がいてくれると、undo&redoや繰り返し定義(OpenGLのdisplay listみたいなの)が
直感的にわかりやすくなるよね。

なんで「オブジェクト指向＝実世界のシミュレート」って考える初心者が後を絶たないんだろうか。
猫とか犬とか哺乳類とか書いてある入門書なんか捨てちまえ。

＞なんで「オブジェクト指向＝実世界のシミュレート」って考える初心者が後を絶たないんだろうか。
そもそもオブジェクト指向は「実世界のモデル化」を目的に Simula に導入されましたから

しかし、オブジェクト指向は『実世界の事象説明』以上のことも出来るから、
哺乳類云々しか書いてない入門書は捨てるべきだとは思うが

>>552
>>553
そういう抽象論でなく、具体的な目標（ゲームとか電卓とか）があって、それをオブジェクト指向で
作り上げていくという書籍はないですかね？

>>553
出自がどうであろうと現在のOOPはそこから遥か遠くに離れてる。
寧ろそういう視点から始めると、大概動くものは何一つ作れない。

>>555
モデル化から完全に離れたオブジェクト指向ってどんなのよ
マジで想像付かない

>>553
> そもそもオブジェクト指向は「実世界のモデル化」を目的に Simula に導入

おいおい。Simulaの頃にはまだオブジェクト指向なんて言葉すら存在しとらんぞ。
あえていうなら「クラスとオブジェクトは」だろ。オブジェクト指向なんて少なくとも
'70年代に入ってSimulaをヒントにCluとSmalltalkが作られはじめてからの話だ。

「実世界のモデル化」なんてのはSmalltalkローカル、もとい、Alan Kayの頭ん中
ローカルな夢想を真に受けてどつぼっているだけ。クラスごときににそんなポテン
シャルはないって。。。

>>554
つ http://www.amazon.co.jp/exec/obidos/ASIN/477412222X/qid=1124803029/sr=1-9/ref=sr_1_26_9/250-0244807-4748240
結構いい本だとおもう。

>>557
> クラスごときににそんなポテン
> シャルはないって。。。

クラスはともかく、オブジェクト指向にはあると思うけどな。

>>558
サンクス。

オブジェクト指向の本、2冊読んで、概念としては分かったんだけど、具体的な作り方が
分からなくて悶々としてました。

オブジェクト指向で混乱してる人は
モデル化＝現実世界のシミュレート
を必要以上に考えすぎてると思う。
オブジェクト指向原理主義者たちの布教をモロに信じ込んで、
なんだが森羅万象がオブジェクト指向なら
簡単にプログラムできるような錯覚をしてるんじゃないかと。

>>557
知ったか乙。

SimulaはSimula67で大きく言語仕様が変わり、
最初のオブジェクト指向言語と呼ばれるものになった。

あと、LiskovのCLUはClusterを中心に据えたObject言語であって、
Object指向言語と呼ぶには違和感がある。

>>560
つ[実践UML]

>>563
これ↓でしょうか？
自分にはまだ敷居が高いような感じが・・・

ちょっと本屋で立ち読みしてから判断してみます。
紹介、サンクス。

実践UML―パターンによる統一プロセスガイド
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/

>>562
とは言うものの、SIMULA 68 の論文に object-oriented を示唆する
記述を見つけることは、実際にかないません。それもそのはず、現
在主流のオブジェクト指向の考え方は C++ のストラウストラップの
もの、つまり抽象データ型のスーパーセット（抽象データ型 ＋ 派
生・仮想関数。今風に言うと、カプセル化・継承・多相性）ですか
ら、SIMULA のクラスに影響を受けて「抽象データ型」を提唱したリ
スコフの CLU が現われたのちに形成されたかなりのちの（少なくと
も 15 年は後）の考え方だと思った方が無難だと思うので…。

そもそも、SIMULA が初のOOPL だと言い出したのはストラウスト
ラップですが、これもパクリ元への敬意のあわられって感じもしな
くもないですし。

参考：（全文の閲覧には ACM の会員である必要があります）
ttp://portal.acm.org/citation.cfm?id=805258
ttp://portal.acm.org/citation.cfm?id=1057826
ttp://portal.acm.org/citation.cfm?id=624721

>>565
◇言いたいことその１

なんとなく 557 は、
「1 + 2 を“加算”と呼ぶのは間違ってるだろ。
　1 + 2 が考案された時には加算なんて呼び方はしてなかったわけだし」
って主張しているように思えてしょうがなくて。

◇言いたいことその２

微妙に揚げ足取りのような気はするんだけど、OO には様々な流派があるから
「C++ の OO が主流だ」とか一概に言ってはいけない希ガス
確かに C++ のは良く使われているが

◇言いたいことその３

http://ja.wikipedia.org/wiki/Simula
もし 565 が本当なら、誰か↑を訂正してやってくれ

>>558
立ち読みで1/3ぐらい読んだ。
やっとOOPの片鱗が見えた。

すごいパラダイムシフトであることがやっと実感できた。
OOPで書くと多分、従来のスタイルで書くのがアホらしくなりそう。

でも設計はまだ全然できないけど。

>>563
やっぱり俺にはまだ、内容が難しそうだった。
今回はパスしました。

>>565
貴方の意見には同意できません。

例えば：
> 現在主流のオブジェクト指向の考え方は C++ のストラウストラップの
> もの、つまり抽象データ型のスーパーセット（抽象データ型 ＋ 派
> 生・仮想関数。今風に言うと、カプセル化・継承・多相性）

貴方は何故、C++をOOのリファレンスと捉えているのか、
なかなか興味深い所ですね。

え？私の意見？
10年位前に、某MLのエライ人の居た基礎研に潜り込もうとして失敗してから、
あまり進歩してませんから。OOってのは所詮、
・型理論とか
・圏論とか
・あるいは80年代AI文化のフレーム理論?とか(ﾜﾗ
そのあたりを、抽象データ型の言葉で語ったものに過ぎないんじゃないかなぁ、
なんて変な物の見方してます。つかOOってルーズで一貫性がなくて、理系向きじゃねぇよな

一応名誉のために。
学生時代の専門は物性基礎論だったりします（ﾜﾗ
物性基礎論で、情報系の基礎研受けるなよ（ﾜﾗ

>>568
ん〜 …… 565 は C++/Java 系の OO が最も使用頻度が高いって事を言いたいんじゃないか？
C++/Java 系は言語として良く使われているし

ちなみに、個人的に OO を最も簡潔に表現しているのは Self 系のプロトタイプベースだと思ってる
あまり使用されていないが

ついでにもう１つ

>>569
型理論も圏論もフレーム理論も、OO とは直接的な関係は無い筈
フレーム理論だけ、何で OO と結びつくのか分からんが

盛り上がってまいりました

C++/Java系って一緒くたにしてるあたりに痛さを感じる。
JavaのOOは、Smalltalk流のMetaclassを、C++　＋ Reflection機構で実現している点で既にC++とは別物、
ついでに JDK1.5 TigerのAnnotationsは、Javaを宣言型言語に読み替え可能にしちまった点で、
もはや別次元に逝っちまってると思う。

あとSelfは俺も好きだが、それをOOと等価と見なすのは、単なる思い入れ(思い込み)でしょ？

>>571はもうどうでもいいです。有益な議論ができる相手とは思えん（わら萎え

×　JavaのOOは、Smalltalk流のMetaclassを、C++　＋ Reflection機構で実現している点で既にC++とは別物
○　JavaのOOは、Smalltalk流Metaclassを、C++にReflection機構を加えた形で表現している点で、Smalltalkや純粋なC++とは別物、

>>573
Self も OOPL と呼ぶのが普通だと思ってたけど、違うの？

>>573
JavaでのOOが、ストラウストラップの言うOO
ttp://www.research.att.com/~bs/whatis.pdf

から大きく離れているとは思えないのだが…。

まあ、ストラウストラップよりはメイヤーのOO
ttp://www.amazon.co.jp/exec/obidos/ASIN/4756100503

寄りかな。でも、メイヤーのOOは、契約によるプログラミング
を除けば、ほとんどストラスストラップの言っていることと一緒なんだよね。

あと、Self、つまりアンガーとスミスのOO
ttp://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/self/self.html

は、ある種ケイのOO
ttp://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

に忠実で、しかしそれを極端に単純化したものだからね。ここで言うリスコフ
から発するストラウストラップのOOの潮流（現在主流のOO）とはまったく
異質で無関係のもの。

この流れでSelfを出す570もナンだけど、そんなのOOじゃないとばっさり切って
捨てるのも大人げないってもんですぜ。

>>567
>でも設計はまだ全然できないけど。
本気で設計やりたいと思ったら>563を思い出してね。
Cのポインタ理解できるレベルで読める本だと思うから。

>>577
了解。
次に読んでみます。

わるい。寝てたらレスが遅くなった

>>573
メタクラスとリフレクションは、仮に目的と結果が同じでも概念が異なるし
アノテーションは只のメタデータっていうか属性でしょ

>>576
568 に対し、「今自分が捉えている OO とは何か」を教えたかったから Self を出した
(俺は Self はやったこと無くて、実際にやったのは Io だけど)


なんつーか、幾つかの OOPL を自称している言語を見ていくと OO の捉え方に大きな差があるんだけど、
そいつらから逆算して OO の最小公倍数を考えた結果、

・手続きとデータをまとめたものがオブジェクト
・オブジェクトに対して操作を行う

の２つの要素を「最低限の OO」として俺は認識した
(CLOS は危うい。Io はこれに等しい。C++ や Java は付属品が豪華すぎる)

>> >>573
ちがう。

>> >>576
それは単なる貴方の個人的見解というやつですね。
あまり意味ない情報だ。

↑は>>579が、>>573および>>576に対して行ったレスへのレスね

理由や根拠も示さずに言い放しにしている>>580のほうがよほど意味のない情報と思われ。

捨てｾﾞﾘﾌはいつも「俺じゃなくてｵﾏｴｶﾞﾅｰ」

わかりやすいバカ印たな

ごめん。俺 580 が何をしたいのかわかんない

あ、なんだ。579 に対して横レスしただけか。すまぬ。
付け加えておくけど、579 の「なんつーか」以降は個人的見解だから注意な

>オブジェクト指向を正しく理解する　―混乱を招く落とし穴に注意しよう―
>オブジェクト指向は，英語では "object oriented" であり，「もの指向」「もの中心」といった意味を持ちます。
http://software.nikkeibp.co.jp/software/backno/2005/0506t1.pdf

それこそ混乱を招くような表現だな

object oriented: 対象志向、客体志向
とかいっちゃだめ？

オブジェクト指向を「データ型とは何か」から始めない解説はことごとくダウト。
「実世界のモデル化」だの「もの指向」だのとかは攪乱が目的としか思えん。
メッセージがどーたら言う奴はアランケイの脳内砂場で遊んでろっての。

＞データ型とは何か
何ですか？

構造体に関数を入れられるようになったもので十分
これに異論を唱える奴はOO教信者

(ﾟДﾟ )ﾎﾟｶｰﾝ

>>591
実装方法はこの際どうでも良いかと思う

『〜を〜する』という考えが出来るようになった程度の認識で十分
クラス信者からは異論が来るだろうが

>・手続きとデータをまとめたものがオブジェクト
データ(フィールド・メンバー変数)があってもなくても、オブジェクトだと思うけれども

俺へのレスか

「０個以上の手続きとデータをまとめたものがオブジェクト」という意味です
０個でも別に構わないし、むしろまとめる事が出来るという事自体が肝心

というか、オブジェクトそのものがデータだから、
データ(構造体)に手続き(関数)をくっつけるという見方も出来ると思う
そういう意味では >>591 に同意

『データに手続きを関連付ける』が OO の定義ってのは正しいかもしれない
関連付けの仕方には「クラス」「スロット」「総称関数」やら色々な流派があるけど、
この定義は OOPL を名乗る言語のほとんどに適用できそうな気がする

それだと「データとロジックの統合された構造化」にしかならない。
OOは最先端の構造化技法　なのか？

そうじゃないの？

そうだね。構造化手法の延長上にある。
んでもってキーポイントも同じ。データ構造をうまく分析・設計
できるか否かが鍵。これができないとと豚に真珠だね。

それは昔のオブジェクト指向だね

えー、たんに取り上げられているのが偏っているだけだよ

ついでに思い出したから貼っとく。ファウラーの書いた奴で、そうだよなーと共感したやつ。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

「オブジェクト脳のつくり方」と「オブジェクト指向で何故作るのか」を
読んでオブジェクト指向が理解できない奴は旧人類。

だから、もともと違う前提にもとずく考え方を同じ「オブジェクト指向」と称して
ひとくくりにしている現状に気づかないで最大公約数的なものを探そうとすると
とんでもないことになるんだって。

オブ脳はどちらかといえばケイの妄想寄り。
憂鬱とか平澤とかはストラウストラップの流れ。

両者はもともと別物なんだから相容れないのは当たり前。ある程度いいとこ
どりはできなくもないけど、けっきょく混乱と難解さしか生じさせない。なにより
両者の本質の所在があいまいになる。

あと、オブジェクトやクラスはなにもオブジェクト指向のために作られたもの
じゃない（それぞれが思いついたオブジェクト指向を具現化するのに便利だから、
ケイやストラウストラップがSimulaから拝借したにすぎない）から、その実装や定義を
整理してもオブジェクト指向の本質には到達できにくいよ！

たとえばクラスは、オブジェクト指向するには欠陥があることがクックに指摘されて、
今はインターフェイスによるてこ入れが行なわれている。

>>604
＞だから、もともと違う前提にもとずく考え方を同じ「オブジェクト指向」と称して
VHS と β の違いみたいなもんか。無駄な混乱を招くっていう点では。

む〜、最大公約数で考えた 596 は間違っていたのか……

>>604
相容れないどころか、両方包含できるでしょうに。

>>604が概念モデルに関してどう考えているのか知りたい。
概念モデルは>>604の言うケイの妄想寄りなんだけど。

>>599
つーか、君の言うオブジェクト指向ならAdaで十分なわけだが。

>>608
もしかして「継承がないとオブジェクト指向とは言えない」ってクチか？
そういや Ada95 では継承ができるようになってたんだな。知らんかった

オレが今一般的だと思っているオブジェクト指向は方向性は２つ。

・モデリング方面
　主にデータモデリングの延長線上で進化してきたもの。
　元になっているデータモデリングの考え方に継承を加えて
　「主キー」という考え方を「オブジェクトリファレンス」に変化させたもの。
　けれど、メッセージパッシングの考え方を含めるのはなぜか稀。
　モデラーが重視していないだけだろうけど。

・実装テクニック系
　主にオブジェクト指向言語とGUIの発展に伴って磨かれてきたもの。
　もともとモデリングの世界と同一の出発点からオブジェクト指向言語
　が形成されたが、MacやWindows、X Window SystemなどでGUIをうまく
　簡単に作れるようにするために実装テクニックが磨かれ続けた。
　デザパタを代表とするオブジェクト指向テクニックにGUI系のものが多かったのは
　そのため。今は手法が確立したからGUIの話をすることは無くなり、
　もっと広いさまざまな局面における実装テクニックが考えられている。

この２つ、どちらもオブジェクト指向。出発点は同じだけど、内容は分岐している。
でも、どちらも重要。

>>609
> もしかして「継承がないとオブジェクト指向とは言えない」ってクチか？

聞こえちゃいけない声が聞こえちゃう人ですか？

>>602
ちなみにそれの邦題は「ドメイン貧血症」という事になっているが、
俺は「ドメイン欠乏症」もしくはもう意訳に徹して「ドメイン不足症候群」くらいのニュアンスにした方がいいとオモタ。
センスねぇよな、そこの邦訳作ってる奴。

相変わらずレベル低いのが自作自演で議論もどきやってるな〜

はげわろす。

>>612
貧血って直訳だし、無難な所だと思うけどなあ。
俺センスでゆるロックとかやられるよりはいいよ。

オブ脳で、オブジェクト指向ではオブジェクト指向向けに
テーブル設計をするって書いてあったんだけど・・
これってモデルを先に決めながら、後（もしくは同時？）にテーブル設計をする。
テーブルはあくまでそれを永続化するためのものでしかないって事かな。
それって従来型のようなテーブルの論理設計や正規化やらをしなくても
いいって事？あーバカにも分かりやすく説明してちょ。

オブジェクト指向ってなに？
なにが出来ればオブジェクト指向を習得したって言えるの？

>>616
・現実世界のモデリング(概念モデリング)
・GoFのデザインパターンなどのオブジェクト指向的実装テクニック
・オブジェクト指向的な実装テクニックを用いたフレームワーク構築
だいたいこの３点でしょう。最後のはいらないかも？
1番上と2番目のやつは全く違う方向性を持つので別物に見えるだろうけど、
この2つ、どちらもオブジェクト指向。

>>615
オブジェクト指向における概念モデリングは、もともとデータモデル作成から
派生してきたものなので、実際には出発点や考え方は同じものだよ。
これを「全く別だから注意ね！」とか言う人が居るけど、歴史上同じ出発点から
分岐して来ているものだから、信じないこと。

オブジェクト指向設計ではテーブル定義は概念モデルから導きます。概念モデル
の作成方法は以前からやられているデータモデリングと同じように論理設計とか
正規化と似たような考えで作られます。流派が違うから少し違うように見えるだけで、
本質的にやろうとしている事は同じ。きちんとした概念モデルが作れた後に、それを
あまり崩さない形でテーブル設計します。

610＝617かな。その説明ではわからんでしょ。実践レベルだし。
まずは、コーディングから。コードの再利用性。迂闊に変数や関数を
さわれない安全性。オブジェクト指向で提供される関数などの利用。
そこからだな。ちなみに、Visual Basic.netの
.netはオブジェクト指向型で提供される.Net Framework。

>>616 はオブジェクト指向プログラミングについて訊きたいと思われ。

再利用性は（意識しちゃいけないってことはないけれど）本質じゃないよ。
大事なのは、メンテのしやすさを念頭に置けるかどうか。

安全性。データ型とは何か、それを定義する意義や方法を知ること。
カプセル化とか言われるのはコレ。通常、オブジェクト指向言語では、
データ型の定義にクラスを使う。
言語によって、情報隠蔽（アクセスコントロール）という概念も入る。

それと安全性については、もうひとつ。型安全性についての知識も大切。
サブタイプとサブクラスの違いとか（通常は同一視して構わないけれど、
局面によっては区別せなあかん。だからインターフェイスが必要…とか）。
静的型チェック機構を持つ言語では、（コンパイルを通すためにするのではなく）
ちゃんと仕組みや意味を分かって、この機構を役立てること。

総じて、オブジェクト指向とはクラスという言語機能を使って必要なデータ型を
設計して運用することだから、繰り返しになるけど、データ型が何かを知っていて
常に意識できていないと、いろんなモヤモヤがでてきて、うまく対処したり、
他人に自分がなにをしているのかを説明できないと思う。


余談。
よく出てくるメッセージ送信うんぬんは、Smalltalkから強い影響を受けた言語を
使うのでなければ、とりあえず無視していい。単なる関数呼び出しのことだから。

再利用性がたとえ本質的でないとしても
それを言ってしまったら「OOする本質的な利点」が消失してしまわないか？

再利用性なんかオブジェクト指向とは何の関係もない

>>619
うおっと・・・610=617です。1ヶ月前に書いているのを見つけられて
かなり恥ずい・・。

>>617
デザインパターンはオブジェクト指向とは何の関係もないから、
「オブジェクト指向的実装〜」とか言われると違和感ありまくり。
勉強が足りないな。
オブジェクト指向って言葉に踊らされてる馬鹿って感じ。

>>625
GoF に限れば OO を使用しているものが多く、これらを自然に使いこなせていれば OO も理解しているのでは
という事じゃないの？

自然に使いこなすには経験が必要なわけで・・・
これ以上言うまい。

何こいつ？エラそーに。

>616
>オブジェクト指向ってなに？
現実世界のメタファー（あるいは人間が環境を認識・処理する方法）を利用した
プログラミングテクニック、つうのがオレ的解釈

それを実現するための基礎概念として、カプセル化や継承・包含・委譲といった
ようなのがある……と。ここから先は参考書嫁

>なにが出来ればオブジェクト指向を習得したって言えるの？
こいつは難しいよ。免許制度があるわけじゃないしね……
極端な例えだけど「オレは算数を習得した」と言い切れる人間は少ないよね？
それと一緒で、「オブジェクト指向を習得した」と言い切れる人間は少ないと思う。

>なにが出来ればオブジェクト指向を習得したって言えるの？
なんかもうオブジェクト指向が云々て言うの面倒だなって思えた瞬間

オブジェクト指向って学習の一分野ぐらいに考えてたほうがいいのかな

>>629
こういうのがいちばんよく見かける、けど、いちばんたちのわるい例だ。
ＮＧワードは「現実世界」「メタファー」「オレ的」「詳しくは参考書
（で、何を読めばいいのかすら書いていない…が、まあ、薦めてもらっても
同じ穴のムジナが書いた駄目本がずらずら出てくるだけだろうが……）」

ちゃんと理解できていないなら、書かなければいいのに…。

616 よ、よく覚えておいて、この手合いはいっさい無視して良い。

>>632
じゃあ，あんたが具体的に解説してくれ

>632
>何を読めばいいのかすら書いていない…
そういやそうだな、と思ったけど、よくよく考えるとオブジェクト指向の入門書持ってないや……
歴史も含めた概略としては
ttp://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%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
が良いような気もするけど……

>>634
はあ？　こんなのサイアクじゃん。混乱を招くだけだよ。因果関係めちゃくちゃだし。

とにかくSmalltalkローカルな考え方を説明する以外でメッセージとか書いている
時点でダウト。はっきり言って書いている奴はわかっていない。ほぼ断言できる。

まずはメイヤーの「オブジェクト指向入門」でも読んで出直してこいと言いたい。

今思えばSmalltalkは邪魔なだけだったな。あれの影響を受けたわんにゃんみたいなワケワカの説明のせいでオブジェクト指向の普及は十年は遅れた…。orz

そうかなぁ。ハイブリッドなOOPLが主流であるが故にSmalltalkへの風当りは強いけど、
OOつうのはプログラミング方法論ではなくてパラダイムなんじゃないの？。
OOPだけに話を限ればそれもある意味正しいかもしれないけれど

>>637
ハイブリッドとか往っている時点でもうアウトだぜ。おとといこいってんだってかんじ。
とりあえずSmalltalkの毒電波をあたかまら排除して考えるクセをつけてみることを勧める。
実際、なんにも困ることはないから。

ttp://www.tcp-ip.or.jp/~ikken/cpp/abst.txt

Smalltalk 以外でメッセージを使うことに抵抗感を覚える人は、OO と OOP を区別できていないような気がする。

>はあ？　こんなのサイアクじゃん。混乱を招くだけだよ。因果関係めちゃくちゃだし。

釣り言葉は多いけれど、結局言っていることがよくわからない（あいまいな）ので、
具体的に自分の言葉で指摘してみて。

あたかまら

>635 「オブジェクト指向入門」
どう考えても入門者向けじゃないような……Eiffelだし。

>Smalltalkローカルな考え方を説明する以外でメッセージとか書いている時点でダウト
メッセージは普通につかうと思うけど。
Io, Ruby, Selfとか、オブジェクト指向の強い（らしい）言語はメッセージの概念で
説明している……と思う。Objective-C もそうか。

>638
いや、それC++前提だし。
C++はマルチパラダイム言語だよね……オブジェクト指向のサポートも強くないし。
＃代わりに関数型プログラミングのサポートがあるわけだけど。

「オブジェクト指向なんて堅苦しく考えないで、適当にプログラムすりゃいいじゃん」
つうこと？コーディングするときはそれでいいけど、ここはオブジェクト指向のスレだし……

・オブジェクト駆動モデルでは、オブジェクトに対して "メッセージ" という起爆剤を送ることで反応を起こす。
・C++ 系の言語では、"メッセージ送信" は "関数起動" として実装される。

つまり、OO の "メッセージ送信" は、C++ の OOP 的に言うと "関数起動" になると俺は思った。
けど、もしかしたら "メッセージ送信" は Smalltalk の OOP 的表現かも。こまった。

Smalltalk では Message 送信と Method 起動は分けて考えてるみたいだよ。

>>638
そのサイトの文章の内容最悪。
仮想関数のところひどすぎ。

>>639
Smalltalkとその強い影響下にある言語以外でメッセージという表現を
使うことに抵抗を感じれない人間は、OOとOOPの区別以前に、OOPが
何かすらあたまん中で整理が付いていないような希ガス。そう。お前のことだ。

>使うことに抵抗を感じれない人間

まあ、C++のメンバ関数なんかだとやっぱり不便だもんな……メッセージじゃなくて
ソースの記述に縛られるわけだし。

ただ、メンバ関数はメッセージ駆動のような挙動をエミュレートするから、メッセージの
代用品と呼ぶのは悪くないんじゃない？

>>646
kwsk

なんとなくそれを思い出したなぁ（笑）
C++しか眼中ねぇ！のにそれを全てのOOPの話のように書いてしまって
Smalltalkerやらその他の皆様からここぞとばかり叩かれてたご仁を思い出してしまたよ、漏れも（w

【C++】 DirectX初心者質問スレ Part6 【C++】
ttp://pc8.2ch.net/test/read.cgi/tech/1127198808/556

こいつを誘導しました。
面倒見てやってください。

ら抜き言葉気持ち悪い。それともふいんきみたいな2ch独特の用語なの？感じれないって。
オブジェクト指向と関係なくてごめん。

>2．君の文は「オブジェクト指向っつーのはオブジェクト単位でクラスこさえて、
>　　プログラムを組んでく以上の意味は無いでしょうよ。」であること。
>　　　　　　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~
じゃあ、それ以外に何があるの？
きっちり全部いって。
後で、これもあったは無しね。

>>652
とりあえずこのスレを>>1からじっくり読むといいよ

>>652
そもそも君のいう「オブジェクト単位でクラスこさえて、プログラムを組んでく」こと
そのものに意味が存在するのか？
その結果として型安全性や再生産性が高まるといった価値に対する「意味」なら存在するけどね。
手法の結果に得られた利益にこそ意味は存在する。

> 後で、これもあったは無しね。
子供の喧嘩か？
君は人が作って、しかも今も変わりつつあるパラダイムについてすべてを知りつしているのか？
そのレベルに合わせて議論するなら、オブジェクト指向からポリホーフィズムを
取っ払った時の利点と欠点をすべて論って比較することが君に可能だというのなら
俺も試してやるよ。

>>654
>そもそも君のいう「オブジェクト単位でクラスこさえて、プログラムを組んでく」こと
>そのものに意味が存在するのか？
するじゃん。
これこれこういう具合に組んでみました。
っていうコミュニケーションの道具になら役に立つんじゃね？
そうやって説明できれば、他の人からみて「そういう風に組んだなら、これはまずいんじゃない？」とか
指摘できるようになるでしょ？

>オブジェクト指向からポリホーフィズムを取っ払った時の利点と欠点をすべて論って
さっさと書けよｗ
とりあえず書いてもらわなきゃ。
俺がそのレベルの話を理解できるかどうかわからんでしょ？
ただ、他からのリンクを貼るだけってのは勘弁してくれ。
あくまでも君の言葉で語ることが前提。
まあ、そんな何十行も続くような理論なんてありえない。続いたらどっかがおかしい。

で、どっちが>>650のスレの>>556なんだ？

>>656
考えるな。感じろ。

>>655
書いてるし。節穴？

> これこれこういう具合に組んでみました。
> っていうコミュニケーションの道具になら役に立つんじゃね？
それは「組んでく」ことの意味じゃない
パラダイムを共有することが協約を可能にすることの意味であって
プログラミングとは直接は関係ない。

> 俺がそのレベルの話を理解できるかどうかわからんでしょ？
明確な自己認識もない奴と議論するのは時間の無駄。
さっさと再認識してくるか一刻も早くうせろ。
前者を選択してくれることを切に祈るよ。

>>656
652=655

はい提案。とりあえず各自、各々の主張を簡潔にまとめて提示してくださいな。
反論に反論を返してるから、主張したい点が全く見えない。

>>659
簡潔にいうと俺が
「ポリモーフィズムなんて百害あって一利なし」
って言ったら、特に理由も言わずに俺を馬鹿扱いしたんよ。

>>659
オブジェクト指向なんて嫌いだー

>>659
こんな↓感じではじまったｗ

556 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 12:35:52
>>555
>非配列は、処理の速さというより、オブジェクト指向でいう所のポリモーフィズムというか、
>インターフェイスと実装を分離する感じが好きなのよ。もちろん処理も速いけど。
実際、そういうところでバグり易いのに、わざわざ処理の分岐をわかりにくくするのは、
あまりよくないんじゃないか？
俺はぶっちゃけ、ポリモーフィズムなんてこれっぽっちもよくないと思ってる。
よーく考えると利点の無いオブジェクト指向言語の改悪機能の一つだと思ってる。

560 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 21:07:08
>>556
オブジェクト指向を何も理解してないんだな。

>>659
さらに

563 名前： デフォルトの名無しさん 投稿日： 2005/10/19(水) 21:52:57
>>560
ポリモーフィズムなんて、所詮は後付け機能。
ダレが公認したのか知らんけど入れるべきじゃないね。

処理が変われば引数も変わるんだ。
無理やり同じようにまとめるべきじゃない。
強引にポリモーフィズムを突き通したことでグローバル変数を使うような糞設計なんてしてりゃ世話無いよなｗ低脳君ｗ

568 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 22:07:04
>>563
> 強引にポリモーフィズムを突き通したことでグローバル変数を使うような糞設計
そりゃ単にオブジェクト指向を正しく使っていないだけ。

ポリモーフィズムを上手に活用するのがオブジェクト指向。
569 名前： デフォルトの名無しさん 投稿日： 2005/10/19(水) 22:15:39
>>568
具体的にいってよ。意味ねーじゃん。

あと、君がオブジェクト指向に変な意味を付加してるのがわかるよ。
オブジェクト指向っつーのはオブジェクト単位でクラスこさえて、
プログラムを組んでく以上の意味は無いでしょうよ。

後にあるのは設計が下手糞か上手かどうかの話でオブジェクト指向云々じゃない。
ポリモーフィズムはあくまでもオブジェクト指向言語の機能だ。
オブジェクト指向じゃない。

>>556はオブジェクト指向を少しも理解していない。以上。

と書くのは簡単だけど勿論もっと書くよ？
・ポリモーフィズムはオブジェクト指向の一機能であると同時に不可欠。
・ポリモーフィズムはコードの一元化をスマートに行う機能である。
・ポリモーフィズムがもたらす利益は多々存在する。
・俺の問に問で返さずに答えて欲しい
・意図的に「以上の意味は無いでしょうよ。」の部分を削った理由を聞かせて欲しい。
・>>556に対して否定的意見を述べる理由を挙げているのに無視している理由を聞かせて欲しい。

>>659
わかった？
つまり、

俺：ポリモーフィズムなんてウンコじゃん。死ねよ。
奴：お前なにもわかってねぇよ。死ねよ。

っていう会話なんだよ。掻い摘んで言うと。
だから、何が分かってないのかとりあえず書いてもらわなね。

>>664
じゃあ、まず、
>・ポリモーフィズムはオブジェクト指向の一機能であると同時に不可欠。
これはどうして？

ちなみに俺(ここの654=658=664)のレスは次の2つのみ。

564 名前：デフォルトの名無しさん 投稿日：2005/10/19(水) 22:01:58
>>563
>処理が変われば
たぶんそこの考えが違うんだろうな。
処理が主体なんじゃなくて、オブジェクトが主体なんだよ。
手続き型のパラダイムのままじゃ理解できない。

570 名前：デフォルトの名無しさん 投稿日：2005/10/19(水) 22:23:38
>569
> 具体的にいってよ。意味ねーじゃん。
君が具体論を持ち出した形跡が見当たらないわけだが。
論点逸らすのやめたほうがいいぞ。

> あと、君がオブジェクト指向に変な意味を付加してるのがわかるよ。
わかったからといってどうなるの？

> オブジェクト指向っつーのはオブジェクト単位でクラスこさえて、
> プログラムを組んでく以上の意味は無いでしょうよ。
その過程にポリモーフィズムの活用があるのもわからんのか。

> 後にあるのは設計が下手糞か上手かどうかの話でオブジェクト指向云々じゃない。
何の後だよ。

> ポリモーフィズムはあくまでもオブジェクト指向言語の機能だ。
> オブジェクト指向じゃない。
だれがんなこといったんだ？エスパー？

>>665
その下の2つがそれを説明している。
利益の具体例は>>654で挙げた。

ふむふむ。みんなサンクス。

>>660
inclusions polymorphism は "処理を入れ替えられる" っていうと害が多いような気がするけど、
オブジェクト指向の重要な機能 "情報隠蔽" に深く関わってくる概念だと俺は思うんだ。
つまり 『名前』 と 『処理』 を分離し、プログラミング時に "詳細な処理内容" を意識しなくてすむようになってるんだな。

ただ、分離しているものをランタイムに結合するから処理を動的に入れ替えることも可能で、
これを技巧的に扱うと色々なことが出来るかもしれないけど、多用は混乱の元だと考えてる。

>>668
意味がわかんない。
つまり、君は俺に何がわかって無いっていいたいの？

ポリモーフィズムがオブジェクト指向に必要な理由を言ってみて、
俺が納得すればそれで終わりじゃないの？

>>669
いやいや、途中で入ってきて話をややこしくするな。
オブジェクト指向と結びつけつつ話してくれよ。
その文じゃちょっと便利だよ程度だろ？

>>670
「意味がわからない」のか「俺が納得すればそれで終わり」であることを
認識しているのかどちらかにしてくれ。

一言
「納得した」
といってくれれば、>>664の下の三点は答えたくないなら答えないでいい。
こちらが意図的なものを感じたから問うただけだ。

>>669はちゃんとオブジェクト指向に結びついてるように見えるんだが…

>>671
そうか？それは済まない。
けど俺は、これがオブジェクト駆動の全てなんじゃないかと思ってる。


関数起動の形で、object に message という何らかのアクションを起こしたことを通達する。
object は message を受けて、指定の処理を行う。

何をするかは object が全部知っているから、関数を起動した側は object が何をやってるか気にしなくて良い。
ただ、期待した動作が行われることだけを信じて待っていれば良い。

これが inclusions polymorphism だと俺は捉えている。
微妙に違うけど。

> オブジェクト指向の重要な機能 "情報隠蔽" に深く関わってくる概念だと俺は思うんだ。

どうしても文章の一部が見えなくなる人がいるらしい。
2chのバグならいいのだが。

多態性（ポリモーフィズム）は、80 年代半ばに C++ の設計者である
ストラウストラップがオブジェクト指向プログラミングやそれをサポートする
言語に必須と言ってから、広まって定着した。他に、カプセル化、継承も
出自は同じ。（だが、その出典を知って使っている人は意外と少ない。）

ttp://www.research.att.com/~bs/whatis.pdf

なお、前のほうのやりとりにあるとおり、メッセージングというのは、この
ストラウストラップの「オブジェクト指向」には関係ない。メッセージを言い
出したのは Smalltalk の設計者のケイで、逆にこの人の「オブジェクト指向」
にはカプセル化や継承は関係ない。

ttp://www.purl.org/stefan_ram/pub/doc_kay_oop_en

思うにオブジェクト指向プログラミングと構造化プログラミングの区別がついていないような

あ、ごめん。区別がついてないのは俺だったorz

>>676
どっちにしても必須じゃねーじゃんな。

だからポリモーフィズムなんて後付けだっつったのに＞all

後付けで必須じゃないとしてもそれを改悪と言い切る根拠にはならないと思います。

>>676
お、ついでだから >>674 で 「微妙に違う」 って言った理由も書いておこう。

polymorphism つまり多態は２つの異なるオブジェクトを同一のものとして認識する必要があって、
この "同一のものとして認識する" ための指針として使われるのがストラウストラップの継承を使った型検査。
ケイの OO だけだと、わざわざ polymorphism と言わなければならない必要性が無いんだな。

どうでも良いんだけど、Smalltalk には継承はあった筈。
また、オブジェクトにデータと手続きをまとめるという立場から言えば、カプセル化は自然に行われていると見なせる筈。

>>679
お前の主張は「ポリモーフィズムが改悪であること」だろ。
いい加減にしろ。

>>682
必須ではないことはわかったわけだ。
ここまではいいよね。
ここまでは確定しておいてくれないと、「オブジェクト指向にポリモーフィズムは必須」とか、
わけのわからんこといって逃げられるから。「んなわけ。ねーだろボケ」で確定でいいよな。

じゃあ、次は、「ポリモーフィズムなんてウンコじゃん」って俺の主張だね。
これは俺の主張だからどこにも定義なんてされてないよ。
そんなこと無いって言い返すなら、キチンと俺のレスを汲み取って返さなきゃならない。
受け側としては、ちょっと苦痛な作業だ。

(続く）（ちょっとレス止めろｗもちつけおまいらｗ会話はキャッチボールだｗ今、ボールは俺が保有しているｗ）

>>683
いつ俺が必須じゃないと認めたのかレス番で教えてくれ。
それにこれは会話じゃない。掲示板への書き込みだ。
いいよね？などと確認を求めておきながら返事も聞かずに
先に進めるための欺瞞としか思えない。

（続き）

で、俺の主張ってのはこれ↓だね。（３行目からだぞ）

＞>非配列は、処理の速さというより、オブジェクト指向でいう所のポリモーフィズムというか、
＞>インターフェイスと実装を分離する感じが好きなのよ。もちろん処理も速いけど。
＞実際、そういうところでバグり易いのに、わざわざ処理の分岐をわかりにくくするのは、
＞あまりよくないんじゃないか？
＞〜略〜
＞処理が変われば引数も変わるんだ。
＞無理やり同じようにまとめるべきじゃない。
＞

っていうちょっと実装寄りの単純な理由なわけよ。
「〜だから駄目」っていうキチンとした１本スジな理由があるわけじゃなくて、
「欠点だったら、いくつでもあがるぞ！」みたいなもん。
いままで騒いできたところじゃこんなもんしか書いてない。

で、よく考えてほしいわけよ。
・ポリモーフィズムを実現するにあたってやらなきゃならんこと。と
・実際にポリモーフィズムを実装したときのクラスのメソッドの動作。
この２つがよろしくない。どうよろしくないんだよ？つーか、よろしくないｗ

俺がいいたいことはこんだけｗ
後は反論で滅多切りにされるのをまつだけｗ

>>684
いいじゃねーかｗ
どうせ必須じゃねんだからｗ
その点で責める気は無いよ。

で、それがどう↓に繋がるの？グローバル変数全然関係ない気がするんだけど。

563 名前： デフォルトの名無しさん 投稿日： 2005/10/19(水) 21:52:57
>>560
ポリモーフィズムなんて、所詮は後付け機能。
ダレが公認したのか知らんけど入れるべきじゃないね。

処理が変われば引数も変わるんだ。
無理やり同じようにまとめるべきじゃない。
強引にポリモーフィズムを突き通したことでグローバル変数を使うような糞設計なんてしてりゃ世話無いよなｗ低脳君ｗ

>>687
ああ、それは小さい理由だよ。
強引にポリモーフィズムやるために引数をなくしてグローバル変数かシングルトン使う奴いるでしょ？
もしくはvoid*かそれに相当するもの。型誤魔化し。
それを脳内で結びつけて勝手に俺が煽り口調でレスしただけだから、
自分はそんなことやってないと思ったらスルーでかまわない。

>>681
＞Smalltalk には継承はあった筈。

初期の Smalltalk にはなかったし、それがケイの「オブジェクト指向」
に必須というわけでもない。どうでもいいけど。

ttp://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

>>689
Smalltalk80 には既にあったはず。それ以前は知りません。ごめんなさいｗ

>>688
それは設計した奴が糞なんであってポリモーフィズムが糞ということにはならないような…。

あー失礼。>>676 を 「Smalltalk にはカプセル化や継承の概念は無い」 と読み間違えて反論してた orz
確かにケイの OO には継承は必要ないわ。

ポリモーフィズムがいらないて、、、
ＯＯＰの事なにも理解してない（理解できない）んだね。

>>686
はいはい、見つけられなかったのね。
>>676を読んで必須じゃないと判断した理由が俺にはわからないが。
是非聞かせてもらいたいものだ。
これも勿論答えたくないなら答えなくていい。
それだけ君に対する判断が変わるというだけの話だ。

> ＞処理が変われば引数も変わるんだ。
まさにそんな実装で使う必然性などない。
それを理解していないから
>> 強引にポリモーフィズムを突き通したことでグローバル変数を使うような糞設計なんてしてりゃ世話無いよなｗ低脳君ｗ？
等というレスをする羽目になる。
この発言を無視しろなどというのはごまかしだ。
これでオブジェクト指向を理解しているといえるか？
ある程度理解しているならば強引な実装など設計段階で排除されている。

> ・ポリモーフィズムを実現するにあたってやらなきゃならんこと。と
既に定着しているものを有害というのならソフトハウスにでもいって開発の陣頭指揮でも執ってこい。

> ・実際にポリモーフィズムを実装したときのクラスのメソッドの動作。
言語が明確に規定していると思うが。

＞ポリモーフィズムを突き通したことでグローバル変数を使う

まさにオブジェクト指向の理解が間違っているための悲劇と思われ。

＞・ポリモーフィズムを実現するにあたってやらなきゃならんこと。と
＞・実際にポリモーフィズムを実装したときのクラスのメソッドの動作。

これって言語の実装の話なのか、それとも多態を利用する側の話なのかどっち？
たぶん後者だろうけど、多態を利用するために必要な事なんてvirtualを
宣言することぐらいでないの？

>>694
>まさにそんな実装で使う必然性などない。
だから、使う必要ないだろｗ
世の中にあるもんのほとんどが引数変えずに処理できるもんって無いってｗ
使う場面が無い。絶対無い。
無理やり使ってる場面のが多い。
そして、そのやり方のほとんどがグローバル変数の使用による実現ってのがほとんどじゃん。

例えばさぁ。ゲーム関連スレから来たからこんな例を挙げちゃうけど。
普通のミサイルとホーミングミサイルってさぁ。
まとまりそうだけど、やっぱ、まとめらんねぇじゃん。
だけどできそうじゃん。オブジェクト指向がこういうもんでポリモーフィズムとか知ってたら是非ともまとめたいもんじゃん。
でも、どうしても、ホーミングミサイルの方の動作にはターゲットのセットがいるじゃん。
そのセットが無いと動けないじゃん。ホーミングミサイルだし。
これ回避してポリモーフィズムちっくにする意味ないじゃん。
でも、こんなのができねぇなら、一体なんの為にあるのか疑問にならねぇ？

>>697
＞ホーミングミサイルの方の動作にはターゲットのセットがいるじゃん
すればよくないか？
グローバル変数じゃなくてインスタンス変数で。

……っていうか、もしかして "クラス内のグローバル変数" って意味で使ってる？

>>697
簡潔に言おう。
君に「分類」の能力がないから平気でそういう台詞が出てくるのよ。
つまりお馬鹿って事だわな。

志村、Strategyパターン。

わろたｗ

>>697
> 使う場面が無い。絶対無い。
それに絶対無いと言い切るその自信がわからない。

使う必要性とオブジェクト指向にポリモーフィズムが不可欠ということを混同するな。
まさかとある機能があるからどんなプログラムでもそれを使わなきゃならないと思ってないだろうな。
CからC++に移ったばかりの奴が無駄にクラスを使ってめちゃくちゃにするのと同じだぞ。
設計能力の欠如に対する無自覚がお前のレスを破綻させていることに気付け。

>689
どうでもいいけど、Bookmarkから消え去ってGoogle様にすがるのも面倒とおもってた論文だ（w
ありがと（笑）

>>697

class Missile { ... }

class HomingMissile extends Missile {
void setTarget( Target t ) { ... }
}

な、そういう場合はな、こうやるんだ。

繰り返すが明確な自己認識もない奴と議論するのは時間の無駄。
下らん。いい加減寝る。

>>703
くだんのは OCR ミスで意味不明なところが多いので、汚くて読みにくいけど
こちらのほうがお薦め。たぶんブックマークしていたのはこっちでは？

ttp://www.metaobject.com/papers/Smallhistory.pdf

どうでもいいけど。ｗ

言い忘れた。
６５９氏に感謝します。
スマートな解説がとても読みやすかったですよ。

>>704
はぁ〜やると思ったよ。
そこでポインタ保持しちゃうの？

ポインタ保持しなくても、まあ、インデックス保持だとしても、
すでに綺麗な組み方じゃないのはわかるよね？

まず、そこで保持する理由がない。
次のフレームではそれは使えないor必要ないからだ。
ターゲットが切り替わる可能性があるから、
一度捕捉したらロックオンするという仕様でなければ、
ターゲットの再検索をかけなければいけないはずだ。

ポリモーフィズムを実装するという目的さえなければ、
直接、動かす関数に引数をつけるはずだ。

そもそもここがすでに自然じゃない。
設計をまげている。

俺がやりたいことが出来ない機能は糞とでも言いたいのかな

>>708
void Missile.Move(Environment env) としておけば良いんじゃないか？

>>710
悪いけどそれって究極まで突き詰めるとvoid*のがよっぽど楽ってことにならない？ｗ

あと、setTarget関数でやるにしてもさぁ。
誰がホーミングなんだか、まとまった集団の中から探しださなきゃいけねぇから、
ポリモの恩恵あまりないんじゃねぇの？

>>711
ならないなぁ。そうならないうちに割り切って、それで出来ないことは諦めるのも１つの手。
というより、void * だと受け取っても何が入ってるのか分からなくて怖いです。

人間は自分に理解できることしか「自然」であると
認めないモノである。

そもそもポリモフィズムってのは多態性であって
ある分類における共通動作概念を抜き出して個々に実装すべきもの。
よって、あるオブジェクト固有の機能をポリモフィズムで実装する
必要なんて元からないんだがね。

>>708
だったら
class Missile {
int direction; // ミサイルの進行方向
int speed; // ミサイルのスピード
...
}
class HomingMissile : public Missile {
void SearchTarget(); // 進行方向の一定の範囲ににいるターゲットを検索する。
// ターゲットが存在すれば進行方向を調整し、存在しなければそのままロストとみなし直進する
}
とすればいいだけでは？

>>708
ポインタ保持って何？
意味が解りませんｗ

というよりふと思ったんだけど、polymorphism で 『全部を１つにまとめる』 必要は無いんじゃないか？
『(例外を除いた) 殆どのものを１つにまとめる』 ことが出来るだけで万々歳のような気がする。

>>707
ありがとん。そう言ってもらえたの初めて｡･ﾟ･(ﾉД`)･ﾟ･｡

きっと彼は銀の弾を求めているのだよ

いや、ミサイルの移動アルゴリズムの切り替えだから
Strategyにすれば自然に多態を使うことになる。
で、この場合、Missileに対してじゃなくStrategyに
ゲーム中の敵機の集合をContextとして渡してやれば
いいんじゃまいか？

>>713
いやいやＩＤ付き。一応バグりはしないっぽいっしょ。
前に開発したときはそうやってポリモちっくでつくっててさ、
で、動作の前の準備として、setXXData関数っての作ってすべてのオブジェクトの動作実行前で
bool setXXData(void* data)を実行した。
で、すべてのオブジェクトが必ず１つのクラスから派生してて、そのクラスにＩＤを取得する関数がついてっから、
それを継承してどのクラスか判断するような設計だった。
で、おもったんよ。

「これってよ。もしかしてキタネェプログラムなんじゃねーの？」

疑問もたない？
なんで言語に型があるのか、激しく疑問に思ったよ。
で、都合のいいときだけ無視するように組んでたけど、
本当に綺麗なプログラムの組み方って型を誤魔化すような設計にはならねぇんじゃねーの？
って思ったわけよ。

Environment envもやったけどさ。
これって無駄に設定する手間が増える分バグが増えると思ったし、
結局、オブジェクトに必要なもん敷き詰めるのは変わらないべ。

つーか、馬鹿ばかりだな。
数多のプロジェクトが破綻する訳だぜ。

>>722
馬鹿な私共に是非とも貴方様の素晴らしい意見をお聞かせください。

まーjava知らんと思うけど
ポリモいらんいうてるやつは
java.lang.Objectのメソッドは今後一切使うなよ。

>>718
>というよりふと思ったんだけど、polymorphism で 『全部を１つにまとめる』 必要は無いんじゃないか？
>『(例外を除いた) 殆どのものを１つにまとめる』 ことが出来るだけで万々歳のような気がする。
それだよ！
長々と説明したけど、俺が思ったのはよ。

でさ、例外っていうけど、
誰が何をどうやってこれは「例外」だと認識できるん？

俺はミサイルとホーミングミサイル程度は綺麗にまとまらなきゃつかいもんになんねぇだろ。現実。
って勝手に決め付けて、最初に偶然ポリモをやってみたとき、「うまくいかねぇ！」ってなったけど、
他の人は実際どうだったん？
ミサイルとホーミングミサイルの違いはターゲットそれだけだで。（実装の都合で言えば）
他にこんなの何に使えるって言うの？

でさ、現場の誰もこれとこれはポリモであってて、これとこれは間違いだよ。
っていえねーじゃん。
つか、時間かかるじゃん。その判別に。

つか、こいつ基地外やないけｗ
あほらし、寝るわ

何だその謎設計？setXXData()を実行しないとどのクラスか判断できないって…PGが？

なんか全然理解してもらえてない気がするけど、
Strategyにcontextを渡す仕様にすれば、
setDataをすべてのオブジェクトの移動前に
セットする必要はないっしょ。
しかもホーミングミサイルのサーチアルゴリズムは
共通なのでStrategyはsingletonで良い。
と言うことはcontextのセットは、すべてのオブジェクトの
移動の始まりに一回セットすれば良いだけじゃね？
間違ってる？自然な設計だと思うが。
新しいアルゴリズムが必要なら新しいstrategyクラスを
派生するだけでしょ。

>>725
＞でさ、例外っていうけど、
＞誰が何をどうやってこれは「例外」だと認識できるん？

そりゃ設計者が分析してだろ

>>725
＞誰が何をどうやってこれは「例外」だと認識できるん？ 

ちゃんとした答えは無いんじゃないかなぁ。
自分が綺麗じゃないと思ったら、その時点で例外としちゃって良いと思うよ。それが設計って奴なんだと思う。

自然にまとめられる物は、類似点の多いオブジェクトになってるから、polymorphism も自然に行えるでしょ？
「これは１つにまとめられないなー」 って思ったら、そのオブジェクトは、その時点で他のオブジェクトとは類似点が少ないことになるし。

>>728
>共通なのでStrategyはsingletonで良い
だから、そうやってグローバル使うしｗ
駄目だって、目的を見失っちゃ。

煽るつもりでいうわけじゃないけど、
ポリモーフィズムを強引に実装しようとしなければそんなことする必要ないでしょ？
これは明らかっしょ。
ホーミング単体でみれば動作関数の引数にターゲットがついてる形が一番綺麗でしょ。
まず、原点に戻ろうよ。

って、俺もそれを考えたときに脳内で自問自答したｗ

つーか、これ以上は平行線でしょ。
俺のいいたいことはだいたい言ったし、これで納得いかない人はずっとこのままっしょ。
俺もしばらく、どうやんだ？これは間違ってるのか？あーでもキタネェし・・・って考えてたからｗ

っちゅーわけで、今夜はとりあえずお開きな。
つーか、俺は、もう寝るｗ

つかね。
いい解決方法があれば、聞いてみたいってのも本音なのよ。
ただ、その解決方法はホーミングクラスをいじることでは無い気がするんだよね。
ってのが俺の考え。

自分の知能の低さに気付かないで講釈垂れる奴を見かけると
ほんとストレス溜まるな。あーあ、胸糞悪りぃ。

アルゴリズムは共通なんだからSingletonで良いんだよ。
Strategyのsingletonはアルゴリズムを動的に取り替えられる
柔軟さがもたらされるので、かえってプログラムの保守が
容易になる。
いわゆるグローバル変数の保守しにくさとは次元が違う。

＞ホーミング単体でみれば動作関数の引数にターゲットがついてる形が一番綺麗
でもこれってホーミングミサイルとふつうのミサイルの区別はIDによるswitch
でしょう？
汚いし、アルゴリズムが増えるたびに条件分岐を増やさなきゃならない。
保守がしにくい。

>>734
そもそもアルゴリズムは共通じゃないかもしれないよ？

>>735
ホーミングミサイルを、ボスとして扱うのはどうだろうか。


自分の思ったとおりに設計すれば良いと思う。
ただ、選択肢は多く考えておいた方が良いと思うけどね。

グローバル変数ってそこまで毛嫌いするほど使っちゃいけないものなの？

>>736
共通じゃないからStrategyにしてるんだが。
アルゴリズム一つに対して一つのStrategyインスタンスが
対応するわけで。

＞ホーミングミサイルを、ボスとして扱うのはどうだろうか。
いみがわかんね。
それこそ、汚い設計じゃないの？

>>738
ごめん。ザコ敵の方が分かりやすかったか。

>>737
グローバル変数が保守しにくいのは、どこかでグローバル変数の中身が
書き換えられるという副作用がプログラムに影響をあたえるからだよ。
Strategyのインスタンスは生成されてから中身のアルゴリズムが書き換
えられる事はない。（別のStrategyインスタンスに置き換えるだけだから）

小学生が意味も解らず適当に用語使って喋ってる感じのスレだな。

>>739
Strategyを推し進めると敵味方のオブジェクトも一括して
扱えるかも。

>>738
＞共通じゃないからStrategyにしてるんだが
ん〜。strategy にしろ、polymorphism で実装する以上、アルゴリズムに何らかの共通点は有るでしょ？
最低でも関数の引数と戻り値は同じじゃなきゃいけない。

んで、もしこれらが異なるものだったら、strategy は使えないよね？ って話です。

>>742
最終的には、画面上のオブジェクトは全て ScreenObject(仮) としてまとめることが出来る。
自機、ボス、ザコ、数種類の弾から背景まで全部。

果たして、そこまで１つにまとめる必要があるのか？ って話だよ。
できる事は分かってるんだけど、それによって問題が複雑になっちゃったら本末転倒だよ。

>>743
さっきからストラテジーの話をしている人は引数も戻り値も変更しないことを前提にしている気がするのだが。

>>743
そのオブジェクトの次の座標を取得するメソッドのインタフェースは
同じになると思いますが？
contextはコンストラクタで一回与えればOKかもね。

>>745
そです。
少なくともゲーム中のオブジェクトの移動メソッドは
共通のインターフェースで済むはずだけど。

>660の答は 659が >669 >681あたりでまとめている内容かと思うけど……
『名前』つうと解りづらいけど、具体的な例は「ソースコードの記述」な。

>708
>直接、動かす関数に引数をつけるはずだ。
とすると、そこの記述は
1. HomingMissile専用のソースコードになる
2. Missileの関数を実行するときに、余計な引数を指定する必要がある
のどっちかになって、動かす関数を呼び出すソースコードの記述が
HomingMissileやMissileの定義に依存しちまうわけですな。

1. だと、似たようなコードをHomingMissileとMissile用にそれぞれ用意する
必要が出て来て面倒だし、2. だとMissileを動かすときにわざわざ要らない
引数を指定する必要があって面倒ですな。
多態性があれば簡単に処理できるけど、わざわざこんなことするの？

>>746
ん〜。ScreenObject(仮) なら、getPoint() は共通化できるね。
んじゃ、Move 系のメソッドはどうだろうか。今回のゴタゴタはこのあたりを問題にしていると思うんだけど。

自機・ボス・弾・背景は、Move 系のメソッドを共通化する意味はあるのかな。

……おっと、2.だと多態性使用する前提ですな……無視してくだされ

>>749
だからmove系メソッドのアルゴリズムを取り替えるためにstrategyを
使うって話をしてるんだってば。
たとえばDemo画面でプレイヤー機が勝手に動いてるような場面も、
通常のゲームのルーチンと全く同じプログラムでプレイヤー機の
移動strategyを取り替えるだけになるじゃん。

１つだけ思ったんだけど、何でみんな 『汎化』 の方にだけ進もうとするのかなぁ。
『特化』 は完全に無視なの？

>>752
オブジェクト指向は「特化」部分を切り離したり置き換えたりを
容易にする技術でしょ。
ハードコーディングを「特化」という訳ではない。

>>751
自機には、パッド等からの入力が伝わるよ。
ボスには、現在の自機座標が伝わるよ。

自機とボスの Move を共通化すると、両方のオブジェクトに両方の情報が伝わるね。
これは無駄じゃないのかな？ って話。
構造化手法的に言うと、情報とオブジェクトの結合度が強くならないかな？ って話。

>>752
頭真っ白になってんだよ。
ＯＯＰ＝何が何でもぽりもーふぃずむで実装って思考に陥ってんだろうな。

そういうことか。分かった分かった。いわゆる object.OnFrame() で移動させたいのな。納得。

>>754
パッドからの情報はstrategyの中にカプセル化できるでしょ。
ボス、自機に限らず、他のオブジェクトの位置情報が参照で
きないと当たり判定ができないでしょ。
で、その情報はオブジェクトのインスタンス変数に保持される
んでしょうから、オブジェクトを介して情報を取得するのは
結合を密にするとはいえないでしょ。
というか座標の取得自体が多態使うでしょ。

でも自機・ボス・弾・背景を共通化すると、自機との当たり判定に無駄が出るような気がします。
自機と自機の当たり判定なんて、まったく意味無いですし。

弾を生成する段階で自機への参照を保持するのも良いかもしれないけど、
それだと自機の 「自機への当たり判定を求める」 処理が無駄になる予感。
あるいは、これも OnFrame() の中に入れた方が良いのかなぁ……。


共通化しないほうが簡単になる部分は、共通化しないほうが良いんじゃないのかなぁと思う。
さっきから言ってるけど。

っていうかどんどん OnFrame() が巨大化していくｗ　助けてｗ

>>758
まあ当たり判定はよけいな話だったかも知れないが、
言いたいのはstrategyにゲーム中のcontextを与えれば
実際のゲーム中のオブジェクトごとに引数変えたり
しなくても済む。
どこまで共通化するかは設計者の考え方次第だが、
デモ画面の話のように柔軟さは保守や拡張の容易さ
を生むと思うけどね。
そろそろ寝るよ。

>>759
巨大化はしないと思うが。
strategyに共通の部分はstrategyの基底クラスに置いて、
特化された部分は派生クラスに書けばよいだけ。
あとは多態がうまくしてくれる。ww

あと座標の取得に多態は使わないの？
まさかグローバルな配列に置いてる
訳じゃないよね？

strategyとポリモフィズムって何が違うの？

もうお手上げ。
ググる様をお使いになって。寝る。

>>762
singleton

>>765
それすごく意味不明。まさにグローバル変数の代わりにsingleton
使ってるだけの意味不明な設計じゃん。
本来座標とかはオブジェクトが持つ属性でね？

＞>>722
＞馬鹿な私共に是非とも貴方様の素晴らしい意見をお聞かせください。

722じゃないが、変わりに言わせてもらうと
本当に素晴らしい人、できる人ってのは「ゴチャゴチャ言わず
すぐさま実践、そして実現している」ってこった。
持っている技術を説明したり、ひけらかしたり
逆に説明を受ける気も無いわけ。
それだと掲示板には無用な存在　ってことになってしまうけどなｗ

聞いたタイミングが悪かったか。すんません。
何かスレ見に来たらあまり見覚えのない単語が飛び交って荒れてたから
ぐぐってみた結果の質問が>>763です(´･ω･)

変わりに→代わりに　だ。

もう最初と最後で同じ話題を議論してるのかもわからないのだけどとりあえず終わったの？

>>770
俺はいいたいこと言ったから、とりあえずはＯＫだよ。
後は、自分でやりたいように考えてもらうしかないっしょ。
その中でいい設計があるっていうなら出してもらえばいいし。
とりあえず、出てる中で俺が納得いくのは無いな（まあ、これも俺の独断だけど）。

ポリモに対してなんの疑いももたないで作ってた人は疑問持った人もいるでしょ？
つかえねーんだよ。これ。引数１個増えただけで破綻。
それを回避するのにまた破綻。
破綻の連鎖爆弾をプロジェクトに設置することになるから下手糞な人は使わないほうがいいよ。
また、プロジェクト進行中に設計に疑問なんか感じたら、かなりやばいしね。
小突いただけで簡単に揺らいじゃうような人やキッチリ納得できる
位置まで自分の中で完結してない人は使わないほうがいいよ。

ちなみに俺は>>732からこのレスの前まではレスつけてないからね。
案外、俺もただのキチガイじゃないっしょ？（笑）

ホーミングがどうこう言ってるから、次の対象を指定するObserverを用意するのはどうかと思った。

>>771
解決する方法はいくらでもあるけど、君のレベルじゃ微妙ってだけ。

下手糞な人は使わないほうがいいよってのは同意で、
C++でC++らしいコード書こうとすると慣れてない人はすぐ破綻する。ってのは
昔から言われ続けてるしな。

無理だと思うならCっぽく書いてけばいいんじゃない？
型変換保障されてるだけでもCよりマシだから。

言いたい事わからんでも無いがね。
型情報のデシリアライズが出来ないと、データドリブンと特化は相性悪いしな。

>>773
つまり、「そんなの解決できないのは、あんたのレベルが低いからだよ」っていいたいわけ？
ここまで議論進んでるんだから、ちょっとはましな設計出してからいいなよｗ
この解決方法を聞きたいと思ってるのはたぶん俺だけじゃないぜ。

>>774
もう結論でてるよ。
理解できないおまえがバカだって。

>>775
グローバル変数使ったようなのとかシングルトンの変なのしかでてないけど？ｗ

俺だったら、自機を扱う Player、敵全般を扱う Enemy、背景等を扱う Background の３つの Facade を作るよ。
Enemy はさらにボスと弾、Background は背景とスコア表示とかを扱う。
つまり全体を階層構造にするんだな。

弾どうしは strategy を使うけど、弾と自機を1つにまとめたりはしないかな。
これが、俺の中では一番簡単だと思う。

普通のミサイルとホーミングミサイルには、
「目」など外部との通信手段があるかないかと言う決定的な違いがあるわけで。

ならばこの能力（たとえば視覚）をインターフェイスとして切り出せば、
他の、この能力を持つもの（自機を狙って弾を撃つ敵など）と共通化ができて、
処理をまとめることができる。

>>777
それはわかりづらいよー
直感的な設計にしようぜｗ

>>778
なんかそれ、ホーミングミサイルの中にミサイルと目が内包されてる設計しか見えてこねぇよ。
なんか別にしちまうのってチガクネ？

そろそろ会議なんので離脱。

実機と敵はｵﾌﾞｻﾞｰﾊﾞで管理して各々が更新した時関連付けされたﾘｽﾅに自動通知されるようにしたいな

780続き
で、振る舞いとかｱｸｼｮﾝなどのﾛｼﾞｯｸはｺﾏﾝﾄﾞで実装し、必要な情報はｵﾌﾞｻﾞﾊﾞから間接的にとる
ﾓｯｸてすとも簡単

シューティングゲーム製作技術議論スレはここですか？

おまいらオブジェクト指向で縦シューつくろうぜpart1

>>779
え〜。自機の当たり判定を rect とすると、当たり判定は enemies.hittest(rect); で出せるじゃん。
オブジェクトグループにそれぞれマネージャクラスを作るのが、直感的に見えないのか？

>>784
いや、わかりづれーのはここ↓だよ。
>Enemy はさらにボスと弾、Background は背景とスコア表示とかを扱う。
ぶっちゃけセンスわりぃよ。
まとめる必要ないんじゃない？

>>785
悪い。自機でも敵でもない、ゲームに直接の影響の無い (無いってことは無いんだが) オブジェクト群をまとめたつもりだった。

まとめる必要がなくても良いっス。
まとめられなかったら Background と Score とかに分けるから。

>779
>なんかそれ、ホーミングミサイルの中にミサイルと目が内包されてる設計しか見えてこねぇよ。
>なんか別にしちまうのってチガクネ？
具体的に何がご不満なのですか？

>>787
別にわけたところでなんの解決にもなってないよ。

>>774
＞つまり、「そんなの解決できないのは、あんたのレベルが低いからだよ」っていいたいわけ？

まさにその通り。
自分でも解ってるみたいじゃん。
スカスカの脳みそで訳の解らん分類して勝手に自爆してるだけ。
ＯＯＰの大事な要素の一つは分類をする為の分析能力なんだよ。
小学生の頃やった知能指数テストにあったでしょ？
複数の図柄見せられてチーム分けしたり仲間はずれ探したりするやつ。
あれだよ。あれ。お前にはその能力が生まれながらに欠如してんだよ。

近頃の若いもんは、背景画像に当たり判定だとか、スコア表示が弾を発射するとか、
奇抜な発想が盛り沢山でオジサン着いていけないよ。ヽ(´ー｀)ノ

っていうか、どこかで見た流れだと思ったら……
ttp://pc8.2ch.net/test/read.cgi/prog/1122318533/l50
の 「リスコフの置換原則」 あたりと似た雰囲気を感じる。

>771
>つかえねーんだよ。これ。引数１個増えただけで破綻。

「引数１個増えただけ」とかいうセンスがわからん……引数の数が違えば扱う情報量が
変わるんだけどね……

まあ、「明示的なメソッド群による引数の置き換え」「オブジェクトそのものの受け渡し」
「引数オブジェクトの導入」ぐらいは調べといたら？重宝するよ

＞案外、俺もただのキチガイじゃないっしょ？（笑）
救いがたい基地外だということはわかった。

>>774
君以外の人は多分自己解決出来ると思うよ。
試しにSTGでも作ってみるといい。

C++等、不満が出てくるのは悪い事じゃないが、
やっても無駄だと思った時点で終了だな。

OOPというより、設計そのものに向いてない。
OOPは設計を縛るものではなくて、手助けするものという事を理解していない。
問題点が出るのは当たり前。より良いものにすれば良いだけ。

それが駄目だと言うなら、ずっと使い捨てコード書き続ければいい。
本人だけはそれが分かり易いと思ってるんだろう。

シンプルで判り易い、汎用性があるってのと、ハードコードの使い捨てコードだらけ、何もシステム化出来てない。
は似てるようで全く別物。

便利だから都合が良いからな視点で発想する事が多々見られますが理にかなった設計をしたいですよね
叩かれている方もおられますが一人では勉強しにくい分野と思われますので謙虚に知識を共有しあえたら有意義ですよね

( ´_ゝ｀)フーン

不思議でしょ？
これでも煽ってる方々は
はじめポリモーフィズムはオブジェクト指向に必須。以上。
みたいな煽り方してたんですよｗ
人と話はしてみるもんですよね。
結局、なんの解決策も示せないまま、ここまで無意味に煽ってこられたわけです。

ポリモーフィズムを使った時点でグローバル変数と
似たような構造のものが必要になるのはわからないんですかねぇ・・・ｗ
この構造で引数が増えるってでかいっしょ？
でも、ポリモーフィズムってのは、この程度の変更で大きな変更が必要となる組み方でもあるわけですよ。

正直、俺は自分のオブジェクト指向に絶対の自信をもってるよ。
君等程度の実力じゃ絶対に俺の域には到達できない。
理由聞いてみたい？

>>797
いや、別に聞きたくない。
つーか、糞して寝てくれ。

どうも精神やられてるっぽいな。
俺の通勤途中、道端でこの世の終わりみたいな顔して
腕時計見ながらギギギギ・・と喚いているスーツの若い
あんちゃんをよく見かけるんだが、こいつじゃないの？

>797
>この構造で引数が増えるってでかいっしょ？

だから、（多くの言語では）引数の数が変わればメソッドの意味も変わるんだって。
受け取る情報量（次数？）が変わるんだから。

まあ、引数の数が違っても同じメソッドとして処理できる言語もあったと思うけどね。

あと、C++なんかだと「引数オブジェクトの導入」を行えば引数の数の問題は
回避できるよ。

>>797
＞正直、俺は自分のオブジェクト指向に絶対の自信をもってるよ。

はたで見ていて思うのは、そもそもの問題はこれかな、と。

797 の絶対だと考えている「オブジェクト指向」は、普通の人の考える
オブジェクト指向とは違うんだよ。たぶんそれは（手法としての）抽象
データ型だ。で、普通の人はそれに継承とポリモを足したものを（797
的には不要なものだから“引いた”？）ものをオブジェクト指向と呼んで
いるわけ。少なくともストラウストラップはそう定義して、多くの教科書は
これを暗黙の了解としている。それなのに、オブジェクト指向にポリモは
無用とか言うから、おかしな反発を招いとるんじゃないかと。

グローバル変数とシングルトンじゃ雲泥の差があるし、
引数の追加とかみんな過去に通ってきた道。とっくに解決出来てるし。

タスクを敵、さらにボス、弾等に分けて管理する事で、便利に判りやすくなる事はあっても、
デメリットなどないし。（基本的なタスク管理は当然大元がする）

これらで不満が出る事自体、「自分はまだまだ未熟です。」と言い回ってる事にしかならん。
こいつがどんなものを設計したかは興味あるな。どうせろくなもんじゃないだろうが。

strategy と singleton の組み合わせは、グローバル変数というよりはグローバル関数だろう。
どうしても singleton が嫌なら、しなくてもすむ実装も出来るし。

>>803
まともな実装としては引数で渡すぐらいしか残って無いな。
メンバ変数に保持しておくってのはやらんほうが賢明だよね。

singletonをグローバル変数と同じで使っちゃいけない
不自然な設計と思ってるのがそもそも勘違い。
（それならsingletonパターンなんてそもそもない）
グローバル変数がなぜダメなのか考えずに、
「グローバル変数は悪、よってsingletonも悪」
という思いこみを発揮しているだけだな。やれやれ。
それにstrategyを使う場合にsingletonにするのは
必須じゃない。（使わなくても同じ事ができる）
無駄なオブジェクトの生成を抑えるためにsingletonに
するのであってその辺がわかってない。
mutableとかimmutableとかたぶん意識したことが
ないんだろう。
つまり何にもわかってないど素人。

>>804をみるとそもそもstrategyパターンを
理解してないみたいだな。はぁ。

自機や敵機の座標もメンバ変数じゃなくて
引数で渡してるのか？
何のためにオブジェクト指向を使ってるんだ？

>>805-807
全然的外れなこといってるねｗ

うは。反論できずそれだけか。w

>>809
シングルトンなんて確実にグローバル変数or関数だし。
で、結局ポリモーフィズムなんて引数の数でもう使えなくなっちゃうでしょ？

こんな実装依存の糞概念いらねぇじゃん。
これがあやしいと思えない奴ってのは感性腐ってんだよ。

まずね。こういう奴等と俺と合わない理由ってのは根本にあるんだよ。
お前等はオブジェクト指向を理解してない。

そもそも、俺と話す前はオブジェクト指向にポリモーフィズムは必須とか
理由も説明できないくせに言ってたじゃん。
ここでもう自分の知識を疑えよ。俺の言うことを強引に否定できるほど頭よく無いでしょｗ
で、結局、ポリモーフィズムは後からできたものだってわかってから静かになったけど。
馬鹿なんだから、人の話よくきけよｗ

>>810
> そもそも、俺と話す前はオブジェクト指向にポリモーフィズムは必須とか
> 理由も説明できないくせに言ってたじゃん。
どこら辺だ？レス番で示してくれ。

>>811
途中から入ってきた人は過去ログ読んでね。

うはwww
グローバル変数とグローバル関数は同じモノなのか？
アホすぎ。
「副作用」が悪なんだよ。
副作用の起こらないグローバル変数は「定数」だし、
副作用のないグローバル関数はいつでも安全に使えるんだよ。w
自機と敵機のオブジェクトから座標やID、残HPなどの情報を
取得するために多態は使わないの？
バカじゃない？www

>>812
最初からいたわけだが。
要するに、具体的に示すと自分の嘘がばれるから答えられないのね。

オブジェクト指向がわかってると豪語する810の設計は
オブジェクトの構造体からIDを取得してswitch caseで
分岐するモノだった！


そんな気がする。www

>>810
というよりお前のオブジェクト指向とその他の人間のオブジェクト指向が別物なのだから、
そういう結論になるのは至極当然のこと。

>>813
グローバル変数や関数なんて使ってる馬鹿はこんなとここなくていいんだよｗ
一体、いつから言われてることかわかってるのか、
いまだにグローバル変数や関数を使わない組み方すら知らないで恥ずかしくないのか？
ポリモーフィズムやるためにグローバル云々が出てきてしまうような設計なら、
まず、設計を見直すのが先だろ。
素で頭おかしいだろｗ

「感性が腐ってる」
そういう彼が推す「オブジェクト指向の本質」はきっと


「マルチプルインスタンス」


前橋のページの誤読者でないことを祈る。

>>817
中身を理解してから書き込もうね。ボク。
なぜグローバル変数はつかっちゃいけないのかな？
しゅくだいをきちんとすませようね？www

>>817
お前面白いからｺﾃﾊﾝにしなよ。

ボクのつかったきょうかしょにはぐろーばるへんすうは
つかっちゃいけないってかいてあるんだ。
だからしんぐるとんもつかっちゃいけないんだ。
じょうたいはぜんぶひきすうでわたすんだ。
それがいちばんきれいなんだ！

>>819
さすがにそんな石器時代にまで戻って議論なんてしないよ（笑）
１人で悩んでろよｗカス野郎ｗ

どうでもいいから早くシューティングゲーム作ってくれよ

うはww
また中身なしレス。
ユー、コテハンにしちゃいなよ。

>>822
俺のレス無視すんなって。
何番から何番なの？

アホでしょ？
だいたい、グローバル変数とか関数とか使ってもＯＫ的な発言しちゃうし。
お前の設計の基準はなんなんだよｗ
回避しようと思わないのか？
どうして、グローバル変数や関数の使用回避がポリモーフィズムの実現より、
優先度が下になっちゃうんだ？

おかしいと思えよｗ
設計がどうあるべきかってわかってないだろｗ
俺の言ってること間違ってるか？

間違ってる。
設計の基準が教条主義的だ。
中身を理解してない。
仏作って魂入れず。
だからデザパタも理解できない。

>>827
じゃあ、この↓辺とかどう？
>どうして、グローバル変数や関数の使用回避がポリモーフィズムの実現より、
>優先度が下になっちゃうんだ？
明らかにおかしいでしょ？
こういう状況になっちゃうのって。
こういうのなんで駄目なの？って聞くまでもなく駄目でしょ。
こういうのさ、いちいち説明して、２ちゃんで会話できないよ。
で、説明しないと説明できないとかどうとか騒ぎ出す始末だし。

さすがにまともな思考回路もってない人とそんなに議論なんて続ける気ないってｗ
だって明らかにおかしいでしょ？
自分がやってることってどうよ？

>>828
どうでもいいから早くレス番を教えろ。

>>828
>>813をしっかり読めよ。
strategyはアルゴリズムをインスタンス化したもので、
副作用がない設計にするんだよ。（当然）
これはアルゴリズムに対応した関数を作るのと本質は変わらない。
副作用を利用するグローバル変数を使うのとは違うんだよ。w

DirectXスレから彼を誘導したものです。変なの連れて来てごめんなさい。

>>830
だから、お前は自分が馬鹿なのを直してこいよｗ

また中身無しか。コテハンにすれば？
ていうか、いじるの飽きてきた。ww

>>833
こんな↓意味不明で恥ずかしいこと言ってた仲間なのに飽きてきたも無いでしょう？

664 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 23:41:39
>>556はオブジェクト指向を少しも理解していない。以上。

と書くのは簡単だけど勿論もっと書くよ？
・ポリモーフィズムはオブジェクト指向の一機能であると同時に不可欠。
・ポリモーフィズムはコードの一元化をスマートに行う機能である。
・ポリモーフィズムがもたらす利益は多々存在する。
・俺の問に問で返さずに答えて欲しい
・意図的に「以上の意味は無いでしょうよ。」の部分を削った理由を聞かせて欲しい。
・>>556に対して否定的意見を述べる理由を挙げているのに無視している理由を聞かせて欲しい。

ポリモーフィズムなんてオブジェクト指向を理解していない人間が
後付けでくっつけた糞機能だって理解できたの？

なにがどう、不可欠なのか教えてほしいよ＞ホラ吹き君達ｗ
始めにオブジェクト指向があって、その後に出来たものがオブジェクト指向に不可欠なわけないだろ。死ねよｗ
頭使ってよく考えてから、自信持てよｗ
全然レベル低くて話にならないｗ

>>830
＞strategyはアルゴリズムをインスタンス化したもので、副作用がない設計にするんだよ。（当然）
そうでもない。strategy でまとめたメソッドから属性を変更するのは良くやること。

実はもう途中から全然違う人が成りすまして煽ってるだけだったりして。

>>834
改良とか改善とか推敲って言葉もしかして知らない？

>>837
その説明で逃げるのは苦しくない？ｗ

>>834
君の中ではあのStroustrup氏がオブジェクト指向を理解していないほら吹きなわけだ。

で、レス番は？

>>835
ああ、もちろんそういう設計もある。
strategyをsingletonにする場合に、
複数のオブジェクトで使い回しても
副作用のない設計ということが言い
たかった。

>>838
今来たところで話の流れ自体はよくわからないのだが
とりあえず>837は>>834を読んだ感想

ちなみにww付きで煽ってたオイラは、
元のスレの流れがどうなのかは、
まるっきり知りません。
STGの設計の話じゃなかったの？

>>842
「オブジェクト指向のポリモーフィズムは悪か？」 という話になって、
ついでに STG の設計の話が出てきた。

>>839
実はそう考えてる。
彼は実は理解できてなかっただろ。
名声に騙されガチだけど。

誰か疑問をもってもいいんじゃない？
ポリモにしたってこんな機能なんで付けたのか全く理解できないほどの駄目っぷりだし。
いままで、制限を付ける形で発展してきたのに、急にこの分野になってから、
お便利機能程度のくっだらない内容を声高々に叫ぶようになったし。
食いつなぐ＝名声を保つのに必死だったんじゃねーの？
ま、人間だしね。

http://ja.wikipedia.org/wiki/Simula

最初のオブジェクト指向言語Simulaには
動的束縛があったみたいだな。
動的束縛があれば多態できるだろ。違う？

>>844
申し訳ないが同感。
ストラウストラップ氏を責めるわけじゃないが、少なくとも氏はケイ氏の OO とは別の道を行ってるしな。

うーん。SimulaにもSmalltalkにも動的束縛は
あるよーな。C++は動的束縛なくてもプログラム
かけるけど、動的束縛できるし。
最初のオブジェクト指向に多態がないってのは、
どっからきてるんだ？

>>846
おお、このスレきて以来はじめての同意。ｸｿｳﾚｼｽ

>>847
ごめん。それ俺が >>681 で書いた。

そもそも、静的型付けの言語じゃないと多態が無いのよ。(多分)
多態はもともと型理論の用語だった気がする。

＞そもそも、静的型付けの言語じゃないと多態が無いのよ。(多分)
それには同意できないなぁ。
俺は動的束縛で呼び出されるモノはすべて多態だとおもうけど。
つまりオブジェクト指向とSimulaの関係のように、多態という概念は
あと広まっただけで、オブジェクト指向の最初から含まれていたように
考えるけど。

>>850
＞俺は動的束縛で呼び出されるモノはすべて多態だとおもうけど
ん〜いやいや。『わざわざ多態と呼ぶ必要が無い』 ってことです。

>>851
理解できなくもないけど、本来、多態と呼ばれるべきだった
モノをC++が「多態とは継承が必須な何か」に意味を狭めて
しまった希ガス。
メッセージングは本質的に多態を含んでいるというのは同意。

ん〜。多態っていうか、この場合は inclusion polymorphism だよなぁ。
inclusion, parametric, overload, cast の４つの多態は、どれも型付けに関しての用語のような希ガス。

ていうかそもそもSimulaって型付きじゃないの？
Sumulaに多態はなかったの？

あれ？ Simula って型付きだったっけ？ 良く知らん。

あーごめん。Simula は静的型付けみたいだ。

それじゃ、やっぱりオブジェクト指向は最初から多態
（この場合inclusion polymorphism）を持ってた事に
ならない？

>>857
多態を持っていたって言うのは間違いないと思う。
ただ Simula の時点ではそういう用語は無かった可能性がある。

Simula の OO は、実は良く知らない。
継承とか、今ある OO に似ているものなんかな。

低レベルな質問で恐縮なんですが、多態なしにインタフェースの概念は実現できるのですか？
｢多態を使うべきでないときに多態を使うべきでない｣ではなく｢いかなる場合も多態は不要｣と言ってるように聞こえるんだが、
この人はいったいどういった設計をしているんだろう。
俺の頭が固いのかもしれないけど、多態なしにOOPするなんてちょっと考えられない。

Simulaの時点ではオブジェクト指向という言葉も
なかったしねぇ。
Simulaの詳細は俺も知らん。
Algol系という噂しか知らない。

>>859
＞多態なしにインタフェースの概念は実現できるのですか？

interface が java や C# のそれを指しているのなら、多態が無ければ意味が無い。
というか、動的型付け言語だと、そもそも interface が要らない。

interface は type system に必要だから作られた？

>>861
あ、なるほど。静的言語しか考えてなかった。やっぱり頭固いな漏れ。

しかし、静的言語で多態なしOOPってどうする気だ？そもそも可能なのか？
それとも多態不要の人は最初から動的言語を念頭に置いててC++なんか眼中にないのか？
だとしたらこのディスコミュニケーションの説明もつくかもしれないが。

ストラウストラップは SIMULA のクラスを使って C++ を作った。
彼の（そして現在主流の）オブジェクト指向は、その設計の過程で
整理されたもの。

ttp://www.amazon.co.jp/exec/obidos/ASIN/4797328541/
ttp://www.research.att.com/~bs/hopl2.pdf

SIMULA が初のオブジェクト指向言語というのは、彼が言い出した、
パクり元に対するリスペクトの現われにすぎない。ニガードらは、
そんなこと（オブジェクト指向なんてもの）を想定して SIMULA を
作ったわけではない。（彼らは疑似並列処理をやりたかった）

ttp://portal.acm.org/citation.cfm?id=808391

インターフェイスは、ストラウストラップ（正確には、それを受けた
メイヤー）のオブジェクト指向、つまりクラスを使って型を定義し、
継承を使ってサブタイプを宣言する…という手法には型安全性に制約が
あることをクックが指摘し、その改善策として提唱された。

ttp://www.cs.utexas.edu/users/wcook/papers/CookEiffel89/CookEiffel89.pdf
ttp://portal.acm.org/citation.cfm?id=96721

SIMULA のオブジェクトをヒントにケイが彼のオブジェクト指向
（メッセージング）と Smalltalk を作った。

SIMULA のクラスをヒントにリスコフは、彼女のオブジェクト指向
（あるいは、抽象データ型とも）と CLU を作った。

同様に、SIMULA のクラスをヒントにストラウストラップは、
彼のオブジェクト指向（カプセル化（抽象データ型）＋　継承と多態性）と
C++ を作った。

Simulaはinclusion polymorphismがあった。
Smalltalkもinclusion polymorphismできる。
いずれにしてもオブジェクト指向の最初から
inclusion polymorphism（いわゆる多態）は
あった。


・・・・・が結論？

以上の点について多態なんてオブジェクト指向にはいらねーと言っていた方、コメントをどうぞｗｗｗｗ

>>865
多態はあった。用語が無かった。

>>866
OK。すっきりした。

う〜ん。確かにオブジェクト指向は多態が出来るのは分かるんだが……。
どうも多態は型検査の用語のような気がしてしっくりこない。

動的型付けでも多態になってるのは分かるけど、動的型付けで多態という言葉を聞いたことが無い
……のは俺だけ？

おまえだけだ。

>>869
ttp://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=Ruby%CD%D1%B8%EC%BD%B8
＞ポリモルフィズム
＞多態, Polymorphism
＞対象になるオブジェクトによって実際の操作が決定されること。
＞Rubyではレシーバのオブジェクトに応じ てメソッドが選択される
＞ことによって実現されている。

動的型付き言語でも使ってるぞ。

ほー。じゃ俺だけか。すまんかった。

おまいらは本当に頭がよさそうですが一向にシューティングゲームを作ってくれません

そして「ポリモいらない君」がいなくなった

何をでっちあげてんだか。
はじめは多態なんて無かっただろ。
オブジェクト指向をちゃんと理解したけりゃ、継承と多態の解説を抜いた本を探せ。
あまりにも糞な本が増えすぎた。
オブジェクト指向入門といいつつ、継承や多態の話から始めるような糞本を回避しろ。

多態なしにOOPするなんてちょっと考えられないなんて、
私、オブジェクト指向理解できてませんでしたってことだろ？
簡単な話だｗ

前橋、乙。

前半と後半で分裂症な予感がする

今となっては多態と継承についての解説のない本の方が糞じゃねーかと思うのは俺だけでしょうか…。

多態と継承のないオブジェクト指向って・・・
Cで構造体に関数ポインタ入れただけのようなもんじゃん。

>>875
すいません、ちょっと確認させていただきたいんですが、
・静的言語について話しているんですよね？
・使いどころによらず、ポリモーフィズムという概念そのものが糞であり不必要だ、という主張ですよね？

それはちょっと頭、堅杉。

継承と多態性のないオブジェクト指向というのもある。言語で言えば
CLU の流れを汲んでいるもの。Ada とか。ちなみにオブジェクト指向
設計で有名なブーチは、Ada での経験から、その考え方を育んだ。

世の中には、クラスによって型を定義できて（カプセル化）、継承と
多態性があってはじめてオブジェクト指向…という人（これが主流）と、

クラス（か、それに準ずる言語機構）で型を定義できれば、それで
オブジェクト指向…という人と、

カプセル化とか継承とかは関係ない（邪魔しなければあってもいい）。
メッセージングができれば、それでオブジェクト指向…という人がいる。

ちょっとまった。CLUにはParametric Polymorphism が
あったんじゃねーの？

>>881
あってもオブジェクト指向に関する機能はCでもあんまり苦労せずに
実現できるようなものばっかりになるよ。

OOPL使わないとOOPではないのですか？

非OOPLでもOOPできるが非OOPLで実現容易な物こそが
OOPの本質とか言い出したらアタマがおかしい人になる。

そしてまた「ポリモいらない君」がいなくなった

>>885
>>881 の一番下に当てはまる人にとっては、非OOPL でも OO の実現は (それほど) 難しくないと思うんだが。

仮想関数とそのオーバーライドによって実現されるポリモの可否、についての話だったとしかヘタレの俺には解釈できんかったorz

>>887
ハッシュがあれば簡単だな。
配列のリニアサーチでも良いが。
継承が絡むと少し面倒だがそんなに難しいわけじゃない。
でも多態に類する機能がないのは話にならん。

最初のオブジェクト指向言語と目される言語は
何らかの形で多態を実現する方法を持っていた。
OK？皆の衆。

>>890
OK 兄者。

OOに実体はないよ。
脳を開けても胸を開けても心がみつからないのと同じ。
OOとか、確かにそこに存在しているという人の思いに
よって意味が与えられてるだけ。

>>882
パラメトリック多相は C++ のテンプレートみたいなもので、
それこそオブジェクト指向とは関係ないだろ。多相とつけば
なんでもいいのか？

多態, Polymorphism
対象になるオブジェクトによって実際の操作が決定されること。

Parametric PolymorphismもInclusion Polymorphismも
「対象になるオブジェクトによって実際の操作が決定」される
Polymorphism。

parametric polymorphism って多相型じゃなかったっけ？

あれはオブジェクト指向じゃなくてゼネリックプログラミングかな。

>>885
非 OOPL で実現可能かもしれないけれど、けっして“容易”ということは
ないと思うよ。

抽象データ型（もちろん、そのスーパセットである君らの OOP 。すなわち、
カプセル化（＝抽象データ型）＋継承と多態性…な OOP ）で大事なのは、
ユーザーが定義した型が、基本型と同じように便利かつ安全に運用できる
ことなわけで、これを C などの非 OOPL で容易に実現できるとは思えない。

シューティ(ry
なんでもない。

>>897
上にも出てたけど、>>881 みたいに OO には色んな解釈があるんだから、一概に ”難しい” とは言えないよ。


どうでもいいけど俺は、以前に C で限定的な情報隠蔽したことはある。
ヘッダに何を書くか上手く制御できれば、ある程度は隠蔽できるでス。

<ヘッダ>

typedef struct tagSample *LPSAMPLE;
LPSAMPLE Sample_New();
void Sample_Delete(LPSAMPLE self);

<ソース>

struct tagSample { /* 内容 */ };
LPSAMPLE Sample_New() { /* ... */ }
void Sample_Delete(LPSAMPLE self) { /* ... */ }
void Sample_PrivateFunction(LPSAMPLE self) { /* ... */ }

>>894
だから、多態ならなんでもいいのかって。

そもそもはオーバーライド（継承）によって実現される多態性が不要か
どうかってはなしなんじゃないの？

で、世の中には継承や多態性はいらないっていう、手法があって
それも「オブジェクト指向」と呼ばれることがあるってんでいいじゃん。

ていうかCで情報隠蔽とかは、当たり前のイディオムの希ガス。
でも、それをもって「CはOOPLだ！」とか言い出したらアタマ
おかしい人になる。
さらに「多態は本質じゃない」とか言い出すのはもっとおかしい。

(･∀･)ﾐﾄﾒﾀｸﾅｲ！

>>901
＞Cで情報隠蔽とかは、当たり前のイディオムの希ガス
いやまあ、確かにそうなんだけどな。同意。

>>899
だから、そうして披露自慢したくなる程度には OOP 向けの言語機能や環境の
サポートなしでは“困難な”コトだったのでは？　可能か否かなら、よほどタコな
言語でもない限り、たいていは“可能”だよ。

>>900
いずれにしても型なりクラスなりでアルゴリズムを
共有する手段として多態なり多相なりが必要とされて
いるんじゃないの？切り口は違うけど。
逆に現在普及してるOOPL言語で、多態がない言語は
あるの？

俺のいないところでレスが増えてるなｗ
ポリモーフィズムなんて必須じゃねぇし、いらないってわかったらもういいだろｗ
結局、ポリモ使ったら、グローバルみたいなモン必須なことには変わりねぇだろ。
んでそれは駄目な組み方なんだからよｗ
いい加減、目を覚ませってｗ

ここでいくらレスつけたって過去は変わらねぇぞｗ

>>905
いや。クラスと多態／多相性（パラメトリックは除く）は直接は関係ないよ。
クラスは型を定義するために（多くの OOPL ）で使われているだけ。
（クラスもオブジェクトも、もともとは OOP のためのものではないからね）
継承機構があるとき、共有云々のための（オーバーライドによる）多態性が
からんでくる。


ttp://www.research.att.com/~bs/hopl2.pdf
ttp://www.research.att.com/~bs/whatis.pdf

>>906
居なかったなら読み返してくれ。
むしろ polymorphism が要らないのだったら OO は要らないんじゃないかとか思ったんだが。

>>908
腹切れｗ

基地外が帰ってきたようです

お前らスレ違いだぞ？

http://pc8.2ch.net/test/read.cgi/tech/1128354256/l50

>>906
とりあえず、>>880の認識であってるんですよね？

で、質問なんですが、多態を使用しないOOPの実際ってどんなかんじなんでしょうか？
たとえば、Compositeパターンを多態を使用せずに実現するとしたらどうすればいいんでしょう。

キチガイの言ってる事は理想論だろ。

ＳＴＧのような実用的な例を挙げてみろよ。教えてばっかじゃなくてさ。
要するに、C++,Java,C#で多態使わずにタスク等を一元管理する設計。とやらを。

出来るもんならなｗ

>>912
シーングラフにComposite使ってる例も多いな。

>>913
>タスク等を一元管理する設計
こんなことする必要無いって気づけｗ

>>914
キチガイはコテハンにしろ。

＞こんなことする必要無い

話にならんな。
ギャラクシアンの頃から利用されてるシステムを否定するか。
つーかゲームエンジンそのものの否定だな。

ようは毎回全部書き直せと？ｗ
キャラの種類が一つ増える度に、色んなコードを修正しなきゃいかんなｗ
そんな糞設計のプロジェクト組まされたらキレる奴続出だな。

否定するならまず、代案を出せ。出せるもんならな。

なあ、この流れ、どっかで見覚えないか？
前にこの手のキチガイを見たのは、たしかGOFスレ。

さらにその前は「オブ戦」スレにいたキチガイに似てる。
ﾃﾗﾅﾂｶｼｽ

>>915
いや、お前のような馬鹿は一度だって普通に組んだことが無い。
口ばっかり達者で実は糞タスク以外の組み方を知らないただのアホ。
代案を出せとか言ってるけど、そもそもお前はタスクを使わないで組んであるソースすら見たことないだけだろ。
結局、知らないだけ。

まあ、あんまり馬鹿で可哀想だから教えてやろう。
継承を一切使わずに組んでみろ。

>>918
結局出せないのねｗｗｗ口だけはお前て事だな。
これだけ具体例出てるのに何１つ具体的に反論出来てないしねｗ

タスク使わないコード＞俺も学生の頃はそうだったよ。門外不出だし、今みたいにネットなかったし。
糞みたいなコード書くところから始めたね。

＞継承を一切使わずに組んでみろ。

継承も駄目？ギャグだろ？ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前、.NETやJavaでは組む事すら出来ないじゃんｗｗｗｗｗ
非効率的な組み方を極めるつもりか？ｗｗｗｗｗ

Cで組んであるＳＴＧの移植で似たような糞コードなら見たことあるよ。
タスクは使ってるんだが、それ以外のレイヤー層（ハード、ゲーム仕様）がごちゃ混ぜｗ
仕様変更の際、苦労したねー。読むのも苦痛だったし。
似たようなコードそこらじゅうにあるし。
お前みたいなキチガイが組むとこうなる。って感じの例だよ。

それ書いたやつには言っといたけど、「組むのが一番早いから」とか言い訳してたなｗ
組んで終わりじゃねーんだよｗ仕事は。
保守、仕様変更に強くして普通。

>>918
このパターンはGOFスレそのままですね(^^;
とにかく、具体例を要求されても絶対出さない。ひたすら｢お前がバカだ｣のみ。

>>918は抽象化そのものが駄目と言ってるから、グローバル関数で無理矢理処理を纏めるしかないね。
もしかしてそれも駄目なのかな？ｗ

抽象化出来ないから、管理部分など作れない。だから、全部ベタ書きｗ
キャラＡの処理
キャラＡの処理
キャラＢの処理
キャラＣの処理
：
：

、、で、キャラが追加される度に書き直しｗ汎用性ゼロｗ
キャラが多数、目まぐるしく入れ替わるＳＴＧをどうやって再現するつもりだろうねｗ

ぶっちゃけ、落ちこぼれ学生か何かか？ＰＧだと思いたくないｗ

小さなプログラムなら多態性が登場しないプログラムもあり得るだろうが、
STGのようにステージ上にある沢山の種類のオブジェクトを取り扱うのに多態性が無いなんてあり得ない。
多態性をサポートする言語機能を使わなくたって、概念上多態性を持つだろうよ。

bullet[0].texture = (赤弾のテクスチャ);
bullet[1].texture = (青弾のテクスチャ);

OO の多態ではないけど、こういうのも多態に通じるところがあると思った。

>918
>継承を一切使わずに組んでみろ。

ΩΩ＜それは　ひょっとしてギャグで言っているのか!?

継承前提のライブラリはいくらだってあるのに……

きっとそういうのは一切使わず全部自作してるんだよ
ところでコテハンつけてなくても呼称がキチガイで統一され始めてたりする？ｗ

このキチガイ自作自演じゃないかと思えてきた。

伝説のプロ名無しだ！

すべてのオブジェクトは世界に一つだけのオブジェクト。
これか？

無くても出来るからいらない、と言い出したら
全ての要素が不要になってしまう。

All-In-One Eclipseってどう？
ttp://sourceforge.jp/projects/aioec/

とりあえず入れてみた。猫プラグインとか、使い勝手向上させるプラグインも
最初から入ってるといいなぁ。。。

>>930
それ使うとインストールがどうこうよりもダウンロードが楽ｗ

>>921,922
継承使わないで組んだことないでしょ？
よく考えてみ？
そういう風にならないから。

継承使わないってソースファイルが肥大化するだけじゃないのか？

継承使うとカプセル化壊れることもあるよ。
ソースファイルの肥大化を押さえて、どこまで安全に組めるかが勝負。

大抵は委譲を使うけど。

>>921
まあ、追加でいっとくけど、
そういう方向で増えたとしても、
君のＳＴＧはいったい何種類の特徴をもった敵がいるんだい？
例えば、等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。
あとは自機の動きに反応して次の動きを選択するプログラムが入るだけだろ。
これだけでも結構できのいいＳＴＧが作れるのに、キャラＡ、キャラＢ、キャラＣ・・・なんてそもそもありえるのか？
こんなの１０種類もいきゃかなりの超大作だと思われるが、それでも１０種類程度ならソースに並べても大したことないじゃないか。
＃アインハンダーだっておそらくそんなにねーぞｗ

まあ、頭のいい奴は俺のいいたいことがわかりそうなもんだが。
この方向で、ソースが増大することはほとんど無いんだよ。

確信した。こいつ自作自演だ。

>>935
神レベル

>>921と>>935は同一人物に見えるな…。
句読点の使い方とか全角アルファベットとか文の特徴が似通ってる気が。
いい加減疲れてきてボロが出たのかな？

「まあ、追加でいっとくけど」 なんて言ってるから、921 への付け足しのつもりでアンカー張ったのではないかと推測

ごめん。935 と 921 の話って正反対だわな。長文全然読んでなかった orz

晒しage

本人がageまくってて意味ないが

>>935
すごいオブジェクト指向だなｗ
問題は組めるかどうかじゃないと何度言ったら分かるんだ？

>>942
レスの主旨を酌みとってよｗ

>>943
甘えるな。

>>935
俺は頭が良くないから君の言いたいことわかんない。

>>945
だったらどこがどうわからんのか聞けばいいじゃない。

>>935がどうしてそんなに自信満々なのかがわからない。

タスクを一元管理なんてする必要がないとか言った後に、

>>等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。

て・・・

>>948
別におかしいところはないように見えるが・・・

タスクを一元管理することと処理を全部一括してシステムを組むことの違いが聞きたいのでは？

>>950
どうして同じに聞こえるのか、そっちのが聞きたいよ・・・

>>950
それに>>935の話の主旨はそこじゃあないぞ。
>>935の大事な部分は

「お前等が汎用性をもたせようとしてる部分は全部書き出したって大した量にはならないぞ」

ってところだ。

>>952
思いこみだな。
大した量になるかどうかはSTGというだけじゃ判断出来ないだろう。
極端な話、RoboCodeみたいにみんなで動きをカスタマイズして遊びたいのかも知れない。

>>953
わからないのに汎用性をつける部分の検証をしないっしょ？
思い込みはどっちなのよ？

>>954
> わからないのに汎用性をつける部分の検証をしないっしょ？

もちろん。分からないのに、

>「お前等が汎用性をもたせようとしてる部分は全部書き出したって大した量にはならないぞ」

なんて事は言いませんな。

>>955
はぁ？何言ってんの？
俺はわかるよ。
お前等はわからないんだろ？
必要の無い汎用性つけて悦にいってるようなアホなんだからｗ
しかも、それでグローバル変数＆関数作っちゃうしｗ

>>955
てか、設計云々語ろうとする割にはグローバル変数とか関数使っちゃうし、
型誤魔化すし、処理をわけることを考えないで無理やりまとめることばっかり考えてるな。
お前等って。
なんでまとめるかな。

大きく複雑なモンは、小さく単純なモンに分けないとどの道管理は行き詰るぞ。

ポリモーフィズムの使用とグローバル変数の使用との関係を教えて欲しいのだが。
何故その二つが並んで出てくるのかが分からん。
自分のまわりではポリモーフィズムを使いたがる人はグローバル変数に無頓着な人が多かった、という私怨^H^H経験則か何か？

>>958
だから途中から入ってきたならまず過去ログ読めよ。
おめーはDirectX初心者スレのアホと同じレベルかｗ

@ITのオブジェクト指向の世界とかいう連載はなんであんなに衒学的なんだ？
結局の実装に落とされる世界なのに、難しく考えすぎ。

>>935
＞例えば、等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。

具体的には？君の嫌いなグローバル関数で纏めるのか？ｗ
それなら継承使った方がマシだなｗ
もっと具体的に言えよ。抽象化は嫌いなくせにな。

それともデータドリブンなんで敵の種類少なくていいんだよｗってオチか？

>>938
残念ながら違います、、、そう思いたい気持ちはわかるが、、、。

現実にいる。と。真性キチガイがｗ

キチガイのいうオブジェクト指向とは、
馬鹿でかい汎用クラスをデータ駆動させる事なのかな？ｗ
確か、ダンジョンシージがそういう組み方してると聞いた事はあるが。

>>958
グローバル変数をクラス化するだけでも、問題となる副作用の殆どを抑制出来るよね？
まあ、シングルトンがどういったものかすら理解出来てないようだからねｗ

これは解るけど。
Aho aho = new Aho();

これが解らない。
Aho baka = new baka();

＞ポリモーフィズムの使用とグローバル変数の使用との関係を教えて欲しいのだが。
>>959
一通り読んだが、さっぱし解らん
DirectXを、上手く「カプセル化」出来ないのを恨んでるって事？

>>963
そう言う意味じゃないと思う
シングルトンとポリモーフィズムは殆ど関係が無い

>>964
前者はただのアホ、後者は馬鹿を含んだアホってことじゃない？