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

1 ：デフォルトの名無しさん：03/04/08 14:02

オブジェクト指向を激しく嗜好し、
オブジェクト指向を何度も試行し、
オブジェクト指向は至高のものだと考え、
オブジェクト指向は歯垢のように無駄だと思う人のスレです。

前スレ
貴様ら！オブジェクト指向を教えろ！！
http://pc2.2ch.net/test/read.cgi/tech/1047696495/

誰も立てないので立てました。
重複していましたら、削除依頼をお願いします。

2 ：前スレのコピペ：03/04/08 14:06

おれもOOがカンペキでスバラシイなどとは一つも思ってないが、

・要件分析→設計までを一貫した成果物のスタイルに落とすことができ
て、他人が後からトレースするのが簡単
・クラスの分割、パッケージ分割などをきれいにしておくと、整理された
戸棚みたいに、特定機能の位置の把握がしやすい

あたりは便利だと思ってるな。
別に開発スタイルの一種だと思えば、それに従ってやるだけでしかな
いよ、折れは。仕事だし。

本読んだだけで分かった気になって、上司の攻撃に利用するマンセー
厨新入社員が大嫌いなのは、俺も同じだ(ﾜﾗ

3 ：デフォルトの名無しさん：03/04/08 14:08

ｵﾛｵﾛ(ﾟﾛﾟ;))((;ﾟﾛﾟ)ｵﾛｵﾛ
http://hkwr.com/
http://hkwr.com/bbs

4 ：デフォルトの名無しさん：03/04/08 14:08

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　○O
　　　　　＿＿＿＿,,,,,,,,,,,,,,,,､､､
　　　／　　　　　　　　　　　　）））
　　　/　　　　＿＿＿＿＿＿,,,ノ
　　　/　　　ｌ　/　　　＼＼ヽ|）
　　　| 　　　|　''''''''''　　　''''''''|　　ﾓﾜﾓﾜｰ
　　　| 　　　| ( 　･ )　　　( ･ )l
　　　| 　　ｌ　　　　　　ｌ　　|
　　　| 　（ ~　　　　　　 _)　 |
　　　 | 　 |　　　 ,―――.　ｌ　　　／￣￣￣￣￣￣￣
　　　　ｌ　.|ヽ　　　ー――' / 　　＜　という夢を見たんだ
　　　　ヾ |　＼＿＿＿＿ノ　　　　＼＿＿＿＿＿＿＿
　＿＿／ヽ＼　　　　　　| ｌ＼＿
￣　　　　　λ ヽ　　　　 / .|

5 ：前スレのコピペ：03/04/08 14:16

Question
わからん・・・。
手続き型言語のサブルーチンじゃだめなの？
どこから呼び出しても使える便利なサブルーチンをたくさん作ってさ、
あとはメインルーチンからどれをどう呼び出すかだけ
プログラムすればいいようにすれコーディングは十分ラクできるじゃん。
オブジェクト指向はさらに何をラクしたくてできた言語なわけ？
よくできたサブルーチン集を作ることとの決定的な違いってなによ？

Answer1
コードの再利用とか不必要な情報の隠蔽とか利点はいろいろあると思う。
まあ特に必要を感じないんだったら従来どおりにやればいいと思うよ。

Answer2
モジュールとして完成度の高いプログラムはアセンブリ言語でも書くことが出来る。
したがって、オブジェクト指向型の言語は必須ではない。
しかし、オブジェクト指向型言語は、モジュールの完成度を高めるための支援を言語レベルで行う。
いわゆる勘違いによる間違いが減る。それだけである。が、これは圧倒的な生産性の向上を意味する。
よく出来たサブルーチンを作れる人ならば、オブジェクト指向の支援を便利に感じるであろう。
まずは良く出来たサブルーチンの条件、モジュール強度と
モジュール結合度などから学びはじめるのが良いだろう。

6 ：前スレのコピペ：03/04/08 14:19

Answer3
構造化手法だけではカプセル化という概念を導入できない。

UMLかJavaの勉強をすればオブジェクト指向を素早く理解できる。

構造化手法だけでは各コンポーネント間の結合度を凝集度を下げることは
容易ではない。

各ソフトウェアコンポーネントは互いに低い結合度で結びつきあっていることが望ましい。
一つのコンポーネントは互いに関連のある責務だけから形成されていることが望ましい。

これが構造化手法の研究成果であるという。

7 ：前スレのコピペ：03/04/08 14:22

オブジェクト指向の利点は、プログラムをオブジェクトと呼ばれる
ブロックに分割して開発できることだ。
だから、分担しての多人数の開発もやりやすいし、改良する場合も
必要なオブジェクトだけ変更すれば良い。

もちろん、オブジェクト指向を使わなくてもルーチン毎、ソース毎
の分割はできるわけだが、オブジェクト指向を使えばもっと見通しが
良くなり、データを不正なアクセスから隠蔽できたりもする。

8 ：デフォルトの名無しさん：03/04/08 14:23

>>6
OO できる環境ならお勧めはしないけど、C の FILE * なんかはカプセル化だね。
FILE 構造体の中身は感知してはいけない暗黙のルールになっている。
言語が禁止できる仕組みを持っていないけれど。

9 ：前スレのコピペ：03/04/08 14:24

例えばファイル読み込みについて書くと、
非オブジェクト指向だと、
1. "ファイルを開く関数"を呼ぶ
2. "ファイルからデータを読み込む関数"を呼ぶ
3. "ファイルを閉じる関数"を呼ぶ

オブジェクト指向だと
1. "ファイル"を表現する、オブジェクト(インスタンス)を作る。
2. そのオブジェクトに"開く"というメッセージを送る
3. そのオブジェクトに"読み込み"というメッセージを送る
4. そのオブジェクトに"閉じる"と言うメッセージを送る。

非オブジェクト指向のときは、どの関数の名前にも"ファイルを～"と付いてる。
オブジェクト指向のときは、どの操作も"そのオブジェクトにメッセージを送る"となってる。

10 ：デフォルトの名無しさん：03/04/08 14:25

>>8
で、引数に FILE * を取る関数群が FILE クラスのメンバ関数、ということになる。
まあ、わざとそんなことするのはとってもとっても不便だから、素直に class 使いませう。

11 ：デフォルトの名無しさん：03/04/08 14:26

かあちゃん.おーいお茶();
とうちゃん.Getお茶(かあちゃん.Putお茶());
こんな幹事会。

12 ：デフォルトの名無しさん：03/04/08 14:29

>>10
で、OO にすると、FILE 構造体のメンバ変数が File クラスの private メンバ変数になって、
FILE * を引数に取る関数が File クラスの public メンバ関数となる。

13 ：前スレのコピペ：03/04/08 14:31

構造化とオブジェクト指向について結合度の観点から考えてみるよ。

構造化分析ってのは、システムを初期化処理、主処理、終了処理という
構造で考えていくことだ。それぞれの部分が、さらに
細分化されて、モジュールという単位になる。
細かく細分化されることで、確かに一つ一つのモジュールの
機能は分かりやすくなったが、解決されない問題もある。
それは結合度の問題。トップから始まるピラミッド形の構造が、
モジュールの結合を強固にしてしまっている。
簡単にいえば、処理する順番が決まっているということだな。
そこで、共通モジュールというのを抽出して、
いろんなところから利用できるようにするというのが
行われる。共通モジュールはいつでも呼び出せるので
結合度が低い。

OOは、結合殿観点からいえば、総共通モジュール化を
狙ったものととらえることができる。時系列に依存する
部分をできるだけ内側に綴じ込め、いつでもどこからでも
処理を呼び出せるようにして、結合度を低く押さえるわけだ。
つまり、OOでは構造化のようなモジュール分割ではなく、
小さなモジュールの見通しの良さを生かしつつ、逆に
オブジェクトの内部に、そのオブジェクトをうまく使うための
初期化処理（これは通常コンストラクタが担う）
終了処理（デストラクタなどが担う）
を内包させ、初期化後は自由に使えるようにしたわけだ。
発想が逆なのがおもしろいね。

14 ：前スレのコピペ：03/04/08 14:35

「オブジェクト指向」とは、あくまで考え方。
その考え方に基づいたプログラム手法がオブジェクト指向プログラミングであり
同様な設計手法がオブジェクト指向設計。同様に分析手法が（略

で、オブジェクト指向という考え方がどういうものかというと、
「オブジェクトを単位に物事を考える」こと。

オブジェクトとは、内部に状態を持ち、その状態により振る舞いが変わる。
その振る舞いの結果、（自分自身も含めて）他のオブジェクトにメッセージを送る。
メッセージを受けたオブジェクトは、そのメッセージに対応した
状態変化を起し、あらたな振る舞いの結果、またメッセージ送信が行われる。

これが基本。

15 ：前スレのコピペ：03/04/08 14:37

レーザープリンタでもドットインパクトプリンタでもサーマルプリンタでも
インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
プログラム上からは全部プリンタとして扱うことができる。

もちろんそれ以外の方式を採用したプリンタがでてもプリンタとしての
インターフェースを持っていれば同様に扱うことができる。
プリンタとして扱って欲しければプリンタのインターフェースを備えればいい。

レーザープリンタはプリンタとして汎用的に使うこともできるし
レーザープリンタとして特有の機能を使っても良い。

16 ：前スレのコピペ：03/04/08 14:40

(問いかけ）
犬とかネコとか山田さんとかそういうことは理解できるんだけど
それを実際のアプリ製作に当てはめようとするとどうもいまいちわからない。

作成するアプリを書いたら、どういうクラスが必要かをレスしてくれるスレはないかなあ

(レス）
激しく同意。

俺の場合も、逝く度かの渡来＆エラーを繰り返して、今も試行錯誤してる途中。
学の無い者による独学ほど非効率なものは無いと痛感。人生死ぬまで修行僧（意味不明

例えば経理システムをOOでどう構築しようかと（経理知識ゼロの俺が）思案してるんだけど、
とりあえず、最終出力たる各種帳票ごとに、対応するクラスをまず作ろうかと思ってる。
この各帳票に対応するクラスを「すごろくのアガリ」と考え、経理のネーチャンが端末から
各種データ（おそらくこれもクラス化の対象になるだろう）を入力してから「上がる」までに
どのような処理が必要かを考え、各種クラス・メソッド・DBレイアウト等をぼちぼち追加していく。

粘り強くやっていけば、いつかはパライソにたどり着くという目論見だが、多分この辺の
要件分析からクラス設計までの話は、学術的・体系的に確立されたものがあるような気がする。
２ちゃんねるではあまり見かけない気がするけど。

17 ：前スレのコピペ(16の追加）：03/04/08 14:42

(レス）
ただし、道筋に沿って最終目標へ近づけていくアプローチ自体は
むしろ構造化手法そのものなんじゃないかと悩み中。

いくつかの道を辿っていくうちに、以前設計したクラスと似た構成の
クラスが必要になったり、あるクラスの一部分の構成を別クラスとして
切り出して、他クラスにも持たせる必要が出てきたりすると思う。

そのときには、共通関数や共通モジュールのような「単なる共通系～」を
作らないように気をつけてる。「オブジェクトとして表現すべきものか」を考えてる。
言葉にするのが難しいので、「この辺はやってみて、体で覚えて」としか言えない
のが心苦しいんだけど。

18 ：前スレのコピペ：03/04/08 14:44

業務だからOOなんでは？
OOは大人数、大規模プロジェクトで複数の人がコードを参照し
仕様変更による改良・改変しデバッグをしやすいというのが売りなんだから
リバーシのような個人が数日で作れるようなソフトではプロセスをそのまま
コーディングする非OOの方が慣れてる人が多い分、早くても自然だと思います。
コードの量が増えるにしたがってOOが有利になると思います。

改良・改変・デバッグに費やす時間（ソースの量Nの増加として）
非OO：OO　＝　N：Log N　って感じかと。

19 ：デフォルトの名無しさん：03/04/08 14:46

かなり抽象的な質問で申し訳ないが、
プロパティとアトリビュートってどう違うの？

20 ：あぼーん：03/04/08 14:48

　　 ,.´ / Vヽヽ
　　　 ! i iﾉﾉﾘ）) 〉
　　　 i l l.´ヮ｀ﾉﾘ　＜先生！こんなのがありました！
　　　 l く/_只ヽ　　　
　　|￣￣￣￣￣|
http://saitama.gasuki.com/koufuku/

21 ：前スレのコピペ：03/04/08 14:53

非ＯＯで新規開発するのと、ＯＯで新規開発するのは、若干ながらＯＯで
開発するほうが工数がかかると思う。ただ、ＯＯで最初から開発しておけば
後々の拡張を考えたとき、非ＯＯよりは工数が少なくなると思う。

非ＯＯ、ＯＯとも、まともに設計されていれば、だけど。
ただ両者の差がどれくらいになるかはつまるところ開発要員によるわけで。
あまりどっちがどうのと優劣をつける問題でもないような気がする。人的な
問題のほうが手法的問題よりはるかに大きい。

優劣を論じたり、ＯＯは使えないとか非ＯＯは古いとかっていう二元論に
持ち込もうとする人間が最大のガンなんだろうと思う。

22 ：前スレのコピペ：03/04/08 14:57

Question
インスタンス変数をpublicで直接いじるのでは
なく、privateにして、setter、getterメソッドで
アクセスさせる方法が定石なのはなぜなのか、
違い（というか、できたらからくりも）
お前ら教えてください。

Answer1
そうしておくと、そのオブジェクトの変数を変更しようとする人は、
必ずメソッドコールしてることになるでしょ。

そうすると、誰がいつ変更しようとしたかが分かるわけさ。
ﾜｹﾜｶﾗﾝとんでもない値入れようとしたら拒否してみたり、変更の履歴
を取ったり、そういう仕事をメソッド内部に追加できるわけさ。
でもって、そういうものを追加しても、(メソッドシグネチャは変わ
らんので)ユーザに迷惑掛けないわけさ。

誰がいつどのように変更して、整合性の取れない状態変数の集合に
なっても全然かまわないクラスなら、全部変数publicでもかまわない
けど、普通クラスに複数の変数を宣言するときって、それぞれの変数
が全部"なんでもいい"って事は、ないことが多いでしょ？

Answer2
publicな変数を１つ使って実現していた機能が、変数２つに変更したいとする。
外部から直接変数を操作していると、操作する個所すべてに修正を入れる
必要がある。１箇所２箇所ならいいが、数百箇所もあったらバグるのは目に
見えている。

setter/getterメソッドを使って実現していると、メソッドの呼び出し形式が変更
されない限り、変数の操作はクラス内部に隠蔽される。よって、変更箇所も
クラス内部だけですみ、修正工数もバグも激減することになる。

23 ：デフォルトの名無しさん：03/04/08 14:57

> レーザープリンタでもドットインパクトプリンタでもサーマルプリンタでも
> インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
> プログラム上からは全部プリンタとして扱うことができる。
つまり、端末からだろうが、どっかからのパイプからだろうが、
リダイレクトされたファイルだろうが「標準入力」として扱える
UnixってOO指向的なんですか？

24 ：前スレのコピペ：03/04/08 15:03

オレルールで開発するのが楽なのは当たり前。
OO だと既存の開発プロセスや設計手法が沢山あり、
それに従って開発するのが OO だと思われているので、
不適合なプロセスを選択すると不自由を感じながら開発することになる。

25 ：前スレのコピペ：03/04/08 15:04

オブジェクト指向のオブジェクトとは物体ではなく、対象・目的という意味合いが強い。
解説書には「物として扱う」などとかかれているが、それは微妙にニュアンスが異なる。
「対象として扱う」と記述したほうがより理解が進むであろう。

漏れはオブジェクト指向は目的思考とでも言ったほうが良かった気がする。
objectとまったく同じニュアンスを持つ日本語が存在しないために
苦肉の策としてオブジェクトというカタカナを使ったのだとは思うが、
物体思考だと勘違いする香具師がいかんせん多すぎはしないか。

26 ：前スレのコピペ：03/04/08 15:05

いや～、今日、死ぬほどたくさんのプリミティブ値の配列を準備して、全てその
配列への操作と大量のスイッチ文でプログラムを実現する、「根性の賜物」ソー
スを追う羽目になりまして、「ああ、ｺﾚ作った奴がOOをちょっとでも知ってたら、
オイラも楽だし、作った奴も楽だっただろうにな～…何がなんだか分からんよ　つд`)」
と思ったのデス。

根性なしのオイラからみると、作者はある意味えらいとおもうんだけど、その根性
をすこしでも情報収集に向けてくれてれば…

27 ：前スレのコピペ：03/04/08 15:14

多態性というよりも、グルーピングといったほうがピンと来そうだけど……

せっかくオブジェクトとしてそれぞれ独立させたんだったら、相手の
オブジェクトのことは（必要最低限のこと以外は）知らなくても良いように
したくない？

多態性があると、『このオブジェクト群には、こう命令すれば動いてくれる』
といった感じに何種類かのオブジェクトをひとまとめにして取り扱うことが
できるので、そのオブジェクト群を使うオブジェクトが、そのオブジェクト群を
個別に扱う必要が無くなる->オブジェクトがシンプルになる。という訳。
wigetなんかの設計をするときに多態性がなかったら死んでますな………

＃さらにこの考えを推し進めると、もっと便利になるよ。
＃Rubyだと、そもそも同じ名前のメソッドだったら、継承関係の無い
＃オブジェクトでさえも同じように扱える。

このへんは現実世界でも良くあることで、例えば
・テレビ用のリモコン
・AVコンポ用のリモコン
・エアコン用のリモコン
なんかは、とりあえずpowerボタンを押せば、それぞれの装置のことを
あまり詳しく知らなくてもスイッチを入れることができるよね。
多態性って、そのあたりのメタファーなんじゃない？

28 ：前スレのコピペ：03/04/08 15:14

つづき
次に逆の方向になるけど、次のようなケースも多態性が必要になるケースですな。
すでにできあがっている／作りかけのシステムに機能（仕組み）を追加したくなった。
その機能は全く新しい機能なので、既存のオブジェクトを調整するだけでは
実現できないけど、機能を実現するための仕組みは従来のオブジェクトを
操作する方法を利用できそうだ。
（実際うまく設計できれば、様々な機能を同じ仕組みの上で実現することができる）

そこで、『このオブジェクト群と同じ命令を受け付ける様にする』すなわち多態性を
利用することによって、既存のシステムの仕組みを変更することなく新しい機能を
追加することができる。
こっちのほうがいわゆる『多態性』になるのかな？

このへんも現実世界で良くあることで、タイプライターとコンピュータのキーボード
なんかは良い例ですな。

つまり、多態性によって『機能』と『仕組み／操作方法』を分離することができるつうのが
『多態性』を重要なものにしている要因だと思うんだけど、どう？

29 ：前スレのコピペ：03/04/08 15:19

Question
ＯＯを採用したプロジェクトがなかなか成功しない
と言われる原因は何ですか？

Answer
全体的にプロジェクト自体の規模が大きくなり、予算・納期は縮小する傾向が
あるので、プロジェクトが成功しにくくなっているというのがある。
だから、OOを採用してなければ成功していたかというと、難しい。

また、新技術にはやはりリスクがあるので、OOを採用したからといって
最初からその利点の恩恵にあずかれるものでもない。

ただ言えるのは、最近の開発で成功しているプロジェクトは
OOを採用している割合が高くなっている。

30 ：前スレのコピペ：03/04/08 15:20

ちなみにDelphiでやってた"継承"というのは、
画面フォームの提示様式とボタンの機能を統一するため、
最小限の基本機能（画面の見た目、パネル分け、PFキー、確認ボタン類）をクラス定義して、
各アプリはそのクラスを利用して造り込んでいく、というものです。

この時問題になったのは、クラス内部の（結果的に）冗長的な一機能が、派生先の仕様によっては足枷になる場合が開発末期に生じたという事です。
また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず独自に別個の関数をダラダラ書きやがったという問題もありました。
（俺も書きやがった一人ですが）　…まあ、その程度の経験しかないす。

オブジェクト指向って、決して同一ではないが似たような手続きを複数箇所にダラダラ書くのはダサイから、
一つにまとめて能率よく処理できるよう工夫を凝らそうといったものになるんでしょうか。
ある種ゲージツ的センスで意見が分かれそうで集団開発にどこまで向いているのかちと疑問にも思ったりします。
ちゅーか、それこそ"指向"に左右されるのだなぁなんてね。

31 ：前スレのコピペ(30へレス）：03/04/08 15:20

そういう観点で言うなら、いかにプログラムを分割して
関連のあるものを近いところに、関連のないものを遠くにおくか、とか
まとめて変更する可能性のあるものをいかにまとめるか、とか。

だから、集団開発、という点でいえば、おおきなプログラムを
集団で作るときに、ある機能を担当している人が作るプログラムが
他の機能を担当している人のプログラムの影響を受けない・影響を与えない
ようにという方向で設計ができる、という点でオブジェクト指向が良い。

コードが似ている・似ていないが判断基準になるのではなく
概念的に似ている・似ていないが判断基準になる。
結果的には、コードが似ている・似ていないでまとめることになる場合が多い
のだけど、それは結果論。

ある時点でコードが似ているからという理由でまとめると、あとで泣く。

32 ：前スレのコピペ：03/04/08 15:24

(問いかけ）
まあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。

(レス）
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな？となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。

33 ：１：03/04/08 15:27

とりあえずコピペまとめは終了です。
準備不足ですみません。

34 ：デフォルトの名無しさん：03/04/08 15:34

まとまりすぎてこのまま終了の予感

35 ：１：03/04/08 15:37

＞34
オレもそういう予感がした。。。。
突っ込む余地を与えるのも大事なんだな。。。。。
トホホ。。。。。

36 ：デフォルトの名無しさん：03/04/08 15:37

乙＞ｺﾋﾟﾍﾟ

37 ：デフォルトの名無しさん：03/04/08 15:47

>>23
UNIX の設計は OO 風だと思う。
process が fork で増えてく仕組みなんかは prototype based OO そのものだし。

38 ：デフォルトの名無しさん：03/04/08 17:04

オブジェクト最高！
Object Saiko!
Object Siko
オブジェクト指向

39 ：デフォルトの名無しさん：03/04/08 17:05

なぁ、教えておくれよ。
プロパティとアトリビュートってどう違うの？

40 ：デフォルトの名無しさん：03/04/08 17:18

>>39
prop・er・ty
━━ n. ((集合的)) 財産, 不動産（物件）; 所有物; 所有地; 所有（権）, 著作権; 特性; 【劇】小道具.
man of property　資産家.
prop・er・tied　━━ a. 財産のある.
property dividend　【金融】現物配当, 物品配当.
property insurance　【保険】財産保険, 財物保険, 損害保険.
property man　【劇】小道具方.
property tax　財産税.
real [personal] property　不動産［動産］.

at・trib・ute
━━ vt. …に帰する, …のせいにする; 作者を…であるとする.
━━ n. 属性, 特質; 象徴; 標識; 【文法】限定詞.
at・trib・ut・a・ble
　━━ a. …に帰せられる, に起因する ((to)).
attributable profit　帰属利益.
at・tri・bu・tion　━━ n. 帰属, 帰因; 属性; 職権.
at・trib・u・tive
　━━ a., n. 属性の; 【文法】限定的な; 限定詞.
at・trib・u・tive・ly　ad.

41 ：2ch過去スレのコピペ：03/04/08 17:19

OOP教えるなら抽象論から入らないで型進化論的アプローチで
OOPしないことのデメリットを教えたほうがわかりやすいと思うんだけどね。

int x, y;
x += 1; y += -2; PutPixel(x,y);

　↓構造体導入
typedef struct{
　int x, y;
} Pos;
Pos p;
p.x += 1; p.y += -2; PutPixel(p.x, p.y);

　↓データ抽象化
typedef struct{
　int x, y;
} Pos;
PosMove(&p, 1, -2); PosShow(&p);

　↓カプセル化
typedef struct{
　int x, y;
　void Move(int dx, int dy){
　　x += dx; y += dy; Show();
　}
　void Show();
} Pos;
Pos p; p.Move(1,-2);
　↓ポリモ以下略

42 ：40：03/04/08 17:20

特性と属性で良いんじゃないかな？
特に分けては考えないけど、あえて分けるとしたら
　Property=特性=オブジェクトに影響を与える(影響が大きい)
　Attribute=属性=オブジェクトに影響を与えない(影響が小さい)
こんな感じかも？　とおもう。

43 ：2ch過去スレのコピペ：03/04/08 17:27

もし神がプログラミングするなら、OOは使わないだろうな。
どんなに巨大なプログラムでも全体から詳細まで把握してプログラムできるなら、
OOで無駄なポインタのやり取りなどせず書いたほうが効率がいいだろう。
でも自分は人間だから、脳内スタックがすぐ足りなくなるので
どうしても OOに頼らざるを得ない。

44 ：デフォルトの名無しさん：03/04/08 17:27

はげしく勉強になるのでもっと書き込んでください。

45 ：2ch過去スレのコピペ：03/04/08 17:37

(オブジェクト指向に）既存の手法に対する全く新規なアドバンテージもないと思う。
なら、何がいいのかというとトータルでは扱いやすいってこと。
むしろ既存の手法にあった色々な考え方を
カプセル化や継承なんていう基本語彙で表現しやすくしたのがでかい。

46 ：2ch過去スレのコピペ：03/04/08 17:43

(オブジェクトとは）
元の対象とする事象とそれを認知した頭の中の model との間、
頭の中の model とそれを自然言語で記述したものとの間、
および、自然言語で記述したものとそれを Programming Language で表現したもの
との間での traceability を指している。

47 ：2ch過去スレのコピペ：03/04/08 18:13

ライブラリのドメイン依存性（ある特定の問題領域の解決にどの程度特化しているか）や
粒度の大きさ（抽象度と言い換えてもいい）を再確認しよう。
依存性が高いか、粒度が小さいならば再利用が難しいのは明らか。

二つの戦略がある。（粒度の使い方が適当でないかも）

・再利用性を高めるためにドメイン依存をなくし、粒度を大きめにとる
・生産性を高めるためにドメインに特化し、粒度も適当に小さくする

はっきり言って前者は相当しんどい。
標準クラスライブラリ並みの作りこみが必要だし、
どうしたってドメインに依存せざるを得ない
（比較的依存しない部分は標準クラスライブラリでほとんど賄われているわけだし）。

だからデザインパターン（作り方・設計）を（再）利用して、
実際に作るのは後者でいいやんというのが現状。
実装の継承による差分プログラミングが有効なのは
もちろん親子直系のクラスツリーを作るときだけだよな。
それって結構範囲が狭い。

48 ：2ch過去スレのコピペ：03/04/08 18:21

Question
GoF本とかじっくり読んで、部分部分はそれなりの設計ができるように
なったので、試しに一本ツールを作ってみたのですが…。

関連を増やすことを恐れるあまり、部分部分を繋ぐ部分がどうしても
MediatorかObserverっぽくなっちゃいます。つまりものすごく多くの
クラスと関連を持つ頭でっかちな中心クラスが一つ出来てしまうんです。

部分の再利用性は抜群ですが、中心クラスはそりゃもーむごいもんです。
この、設計の最終段階を解説してくれてるような良書ってありますか？
GoF本の２章も仕上げの部分が省略されてていまいちでして。

Answer
「中心」なんてものを出来るだけ無くすようにするのが吉。
芝居だって主人公が(あなたが言う意味の)「中心」である
わけじゃないでしょ？

注：OOPの古典的理論に「アクター(俳優?)理論」ってのが有るらしく。

つまり、
>MediatorかObserverっぽくなっちゃいます。つまりものすごく多く

この部分に「つまり」という単語が出るところが敗因。
もしかしてMediatorやObserverを中心に据えようと
していないっすか？
駄目っすよそのスタイルは。VB/Delを厨房がいじるのと
同じなんだから。(ナニも考えずにあの手のRADを使うと
Formに書く処理が爆発的に多くなる)

49 ：2ch過去スレのコピペ：03/04/08 18:25

オブジェクト指向を使うと、凄く楽になったという実感があるよ。
ただ工数が減ったかといわれると微妙。
速く作れるようになったと言うより、
確実性が増したと言うべきか。

例えば、「こりゃ複雑すぎてメンテできん、
手も足も出ない」っていう状況はほぼなくなりました。
ドキュメントが無い状態でも、クラスを見れば、
おおよその働きは理解できます。
危険な操作はできないように隠蔽できるので、
アクセスのエラーが出たら、
何かしてはいけないことをしたのだという目安になります。

50 ：2ch過去スレのコピペ：03/04/08 18:51

自分もOOPL覚えたての頃はクラスライブラリをべたべたと利用するだけで、
いわゆる「open~closeを並べる」タイプだったです。
でもしばらくしてからプログラムしている内容をオブジェクトに切り分けて、
そのオブジェクト間のメッセージのやりとりという観点から自前でクラス階層を構築する、
という作業をしてみると以前よりずっと実際の問題に近いレベルでプログラムを構造化（？）できるなあ、
と感じるようになりました。
openだとかcloseだとかは自分のつくったクラスのもっと具体的な名前のメソッドのなかに隠されて
外からはすぐに見えなくなると思うのですが

51 ：2ch過去スレのコピペ：03/04/08 18:54

オブジェクト（役割単位での分割）とモジュール（機能単位での分割）は区別して考えないと。
モジュールは管理している属性が不明瞭だし、操作する対象も不明瞭のままです。
そこを明らかにすることに価値を見出すのがオブジェクト指向かと。

52 ：デフォルトの名無しさん：03/04/08 19:45

2chでも書くやつは書くね。

53 ：2ch過去スレのコピペ：03/04/08 19:46

・多態が強力な一般化・抽象化の手段である。
・多態は静的な型チェックと動的なlate bindingを両立させる。
・late bindingによって実装を隠蔽したままオブジェクト間の組合わせを変え
　る自由度が得られる。
・late bindingによって「インターフェースのみを決めた」プログラミング、
　たとえばさまざまなデザインパターンが可能となる。

…のは確かなんだが、肝心なのは抽象化であって多態やlate bindingはその
手段じゃないかなあ。

(レス）
これらの意見は、一見、OOの利点に聞こえるが（実際、利点だが…）
この中にある『「インターフェースのみを決めた」プログラミング』が問題。
OOの利点を生かすためには、＜インターフェースのみを先に設計する＞という
前提が必要になるのだが、実際にはこの部分の実践が難しい。

54 ：2ch過去スレのコピペ：03/04/08 19:58

OOになって、デザインパターンが出てきて、なるほど頭いい人は
こうやってコーディングするのだなあって思った。抽象化された
コアを作り込んで、具象化はなるべく後にする。そうすることで
問題の本質が見えてくるし、コードの再利用も進む。

頭いい人の手法を「再利用」できるようになったことは、OOによ
る恩恵だなあ。構造化プログラミングの時代には、データ構造＋
アルゴリズム＝プログラムだったから、ついついすべてのコード
がそのプログラムで解決したい具体的な問題に「べったり」なも
のになりがちだった。似たような、しかし、ちょっとずつ違うコー
ドを大量に書いた。いつもデバッグばかりしていた。それがOOに
なって、デバッグの済んだコードを再利用するケースが増えてき
た。デザインパターンまで来て、ようやく得られた恩恵だけど。

デザインパターンを知らないでいると、OOなんてちょっと気の利
いた（しかし、けっこう面倒な）モジュール化技術にしか見えな
いだろうな。

55 ：2ch過去スレのコピペ：03/04/08 20:04

オブジェクト指向は複雑な物をシンプルにするのが得意。
すでにシンプルな物をよりシンプルにするのは苦手というか、効果が薄い。
そういうところはアルゴリズムにまかせたほうがいい。
有用な技術だけど、すべてにおいて効果を発揮する万能薬じゃないのだよ。

会社組織にたとえれば、２～３人の小さな組織で備品購買担当を決める意味があるのか。
こんな小さな組織で下手に担当を決めるとかえって窮屈になる。
だから３目並べやテトリスくらいでは、デメリットばかりが目立っていい例はあげられない。
しかし大きな組織になったら担当が必要になる。
１００人の社員が好き勝手に備品を買ってきたらえらいことになるし、
管理するのは大変だから担当を決めて、決済や稟議というメッセージを仲介し、
購入という操作や、予算という属性を隠蔽する必要が出てくる。
組織を知ればオブジェクト指向は見えてくる。

56 ：2ch過去スレのコピペ：03/04/08 20:06

あまり一般的な分類だとは思えないなぁ。255 さんとかぶるけど、

ＯＯ＝オブジェクト指向：思想。ポリシー。対象を特に選ばない。
ＯＯＡ＝オブジェクト指向分析：ＯＯに基づいた問題領域の分析工程。
ＯＯＤ＝オブジェクト指向設計：ＯＯに基づいた(ソフトウェアの)設計工程。
ＯＯＰ＝オブジェクト指向プログラミング：ＯＯに基づいた実装工程。

クラスとかインスタンスという概念はＯＯでよく見られる一つのパターンであって
ＯＯＡやＯＯＤだからクラスでＯＯＰだったらインスタンスというのは変だよ。
プロトタイプベースの言語だったらクラスないし。
クラス間ならぬインスタンス間の関係を設計段階では扱わないかと言えばんなことないし。

57 ：2ch過去スレのコピペ：03/04/08 20:20

おそらくあなたは、「コードの把握しやすさ」は理解できても
「ソフトウェア構造の把握しやすさ」という概念は理解できていないのでは？

共通部分を括り出すだけでは自分用関数ライブラリと変わらない。
デザインパターンは、ソフトウェアを開発していると良く出くわす
*設計上*の問題とその解決法に名前を付けたもの。
名前があるおかげで、
「これはfactoryパターンでやるといいんでない？」「あ、なるほど」
というやりとりができる。
まあ、みんながパターンを知ってないと共通語彙として使えないから
まだまだ浸透するには時間がかかるだろうけどねえ。

58 ：2ch過去スレのコピペ：03/04/08 20:22

ここにいるOOマンセーな皆の会社ではOO、デザパタなんぞ常識レベルなの？
俺もOOマンセーなんだけど、引継ぎで

俺「ここの状態遷移はStateパターンそのままで･･･」
相手「ﾊｧ？すていとぱたーん？」
俺「個々の状態を、AbstractStateクラスのサブクラスで定義して･･･」
相手「ﾊｧ？クラス？構造化プログラミングの言葉でいうと何？」

てなことがしょっちゅうなんだけど。

思うにOOの弱点は
・OOへの理解が浅い人間が設計するとどこまでもひどくなりうる。
・もともとの設計がまともでも、OOへの理解の浅い人間がソースを引き継ぐと
理解できない、またはどこまでもひどくなりうる
・上記2点にもかかわらず理解を深めるのが難しい。（このスレの混乱振りを見れば明らか）

つまり、フールプルーフがなってない。
よって、設計・実装・保守を行う者と、利用者が明確に区別できる場合
（たとえば自分用クラスライブラリや、商用クラスライブラリや、長期に渡って
同一人物やチームが保守することができる場合など）のみしか有効でないと
思うんだがどうよ？

#OOへの理解が浅いのはオレモナー

59 ：デフォルトの名無しさん：03/04/08 20:26

クラスってアクションゲームとかだとどういった使い方をしますか？敵キャラのオブジェクトとかマップのブロックとか？とかですか？っていうかクラスってなんですか？

60 ：前スレのコピペ：03/04/08 20:34

オブジェクト指向が特に便利というわけじゃなく、
その周辺に用意されたものが、たまたまニーズに
合ってるだけかもしれない。
オブジェクト指向は「狼の皮を被った羊」なんじゃないのか、と。

61 ：前スレのコピペ：03/04/08 20:34

おまえら「オブジェクト指向」に騙されてるぞ。
「オブジェクト指向」と一括りにされて、うやむやにされた技術は、
実はほとんどが「オブジェクト指向」とは全く関係ないものばかりだ。
俺達は「オブジェクト指向」という言葉に踊らされているのさ。

62 ：前スレのコピペ：03/04/08 20:35

>>61
なんかこれ、真理を突いてるっぽい。
初心者がプログラムするときなんか、メッセージなんて概念は
頭に出てこないだろうし。最近の言語の傾向見てると、
純粋な「オブジェクト指向」という意味自体も消えかかってる。

63 ：前スレのコピペ：03/04/08 20:36

へんなちゃちゃが入ってるようだけど、オブジェクト指向のおかげで
プログラムをあまり勉強しなくても、ある程度部品を組み合わせれば
ある程度のものができるようになっている。

あと、>>60の言うような「周辺に用意されたもの」の多くは
オブジェクト指向を核に研究開発されている。
それは情報処理学会誌なんかを読んだ感想。

64 ：前スレのコピペ：03/04/08 20:36

>>63
>オブジェクト指向のおかげで
オブジェクト指向のおかげじゃない。
オブジェクト指向の周辺技術のおかげだ。

65 ：前スレのコピペ：03/04/08 20:37

>>63
>部品を組み合わせればある程度のものができる
これはオブジェクト指向とは何の関係も無いな。

66 ：前スレのコピペ：03/04/08 20:41

>>60
なるほど。
多態や継承とかは、別にオブジェクト指向でなくてもできるよな。
純なオブジェクト指向つーと、メッセージ受け渡し程度だから、
まあ無くてもいいわな。

67 ：前スレのコピペ：03/04/08 20:42

>>61
となると、純なオブジェクト指向＝メッセージング程度という>>66の意見と、
オブジェクト指向の周辺技術がニーズにあっているという感覚からすると、
少なくとも俺はオブジェクト指向の派生物を便利便利と言っているわけで、
そうなると俺は何指向だ？オブジェクトデリバティブ指向とかか？

68 ：前スレのコピペ：03/04/08 20:42

庶民はとくに指向でなくてよい。

69 ：前スレのコピペ：03/04/08 20:43

>>68
まあ、確かにそうかもしれん。
でもやっぱりプログラムするときはいつもインターフェース
意識するから、しいて言うなら俺はインターフェース指向かな。
オブジェクト指向ではないことは、>>60の発言で確定したし。

70 ：前スレのコピペ：03/04/08 20:43

まあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。

71 ：前スレのコピペ：03/04/08 20:44

>>70
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな？となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。

72 ：前スレのコピペ：03/04/08 20:46

>>71
そんなとこだと思う。
オブジェクト指向だけが全面に出てくる今の状況はおかしい。
理系の考え方じゃない。

73 ：前スレのコピペ：03/04/08 20:46

>>72
エンジニアリングは理系じゃないからね。

74 ：前スレのコピペ：03/04/08 20:49

>>82
同意。
オブジェクト指向の本はあんなに分厚い必要はない。
なんつーか、うまく分離できないものかね。

とまあ、この辺の話に興味があるので、レス番編集してコピペしときます。
煽りっぽい発言は省いてます。意味通じないかも。
というか今更だけど、

貴様ら！オブジェクト指向を教えろ！！
http://pc2.2ch.net/test/read.cgi/tech/1047696495/957-

とした方が良かったかも。

75 ：1：03/04/08 21:01

まだ過去スレからコピペしたいものが一杯あるんだけど。。。
切りがないのでここらでコピペは一旦終了です。

>60-74はオレじゃないんで。(分かるだろうけど）

2chもノイズが多いけど、まとめると凄いためになるんだなと実感。

76 ：デフォルトの名無しさん：03/04/08 23:42

>>1
お疲れ様です。
ワタシが勤めてるトコは、メーカーの情報システム部門で、
ＯＰＥＮ系の開発経験が浅いんです。
（ＶＢ、ＡＳＰとかくらい）
で、外部からも、Ｗｅｂ系の受注を取りたいってことで
オブジェクト指向を取り入れる？ってことらしいんですが、
ＳＥの平均年齢は４０代後半、ちゃんと設計できるのかしら？

・・・このスレに堂々と書き込めるほどには、
オブジェクト指向を理解していないのでsage

77 ：デフォルトの名無しさん：03/04/09 00:13

>>76
受注するのはいいが、オブジェクト指向はやめとけ。

78 ：デフォルトの名無しさん：03/04/09 09:13

OOと非OOって1か0かじゃないよね。
PC上で作業する以上少なからずOOの要素は含まれていると思う。
100%完璧なOOも100%非OOも多分実用的じゃない。

79 ：デフォルトの名無しさん：03/04/09 14:48

オブジェクト指向がいいとか悪いとか、もうどうでもいいんだあああ！！！

クラスの洗い出しがうまくなるコツをご教授してくれえええええ！！！

80 ：デフォルトの名無しさん：03/04/09 15:12

思い切って1モジュール1クラスにしてみては？

81 ：デフォルトの名無しさん：03/04/09 15:35

>>76
そのSﾖがASPにはM$のASPと、ビジネス形態としてのASPの2種類があることを
知らずにASPASPっていってるのならあきらめたほうがいいね。

82 ：デフォルトの名無しさん：03/04/09 15:38

83 ：デフォルトの名無しさん：03/04/09 16:23

ASP = Advanced HSP

84 ：デフォルトの名無しさん：03/04/09 16:30

どこにもHが見当たらないんですが。
ASP = Anal Sex Play

85 ：1：03/04/09 16:41

ネタはこちらでお願いします。

貴様ら！オブジェクト指向を教えろ！！第2章
http://pc2.2ch.net/test/read.cgi/tech/1049857221/

86 ：デフォルトの名無しさん：03/04/09 20:25

ここがネタスレ？

87 ：デフォルトの名無しさん：03/04/09 21:39

>>1
おつかれ。てかグッジョブ。
>>79
インターフェースだ。インターフェース指向だとわかりやすいだろ？

88 ：デフォルトの名無しさん：03/04/11 20:34

Javaで何か作るときは大体、インターフェースだけで先に骨格を組む。
で、各部品の叩き台みたいなのを作って動作を確認する。
正しく動いてさえいれば完成したつもりになる。
その後、部品をチューンして性能を上げたり、
インターフェースを継承して機能追加したり。

趣味プログラマからみたＯＯの利点は
妙なバグを出さずに改造を長く楽しめること。
気分はWIZとかのキャラ育ての延長なんだな。

89 ：デフォルトの名無しさん：03/04/12 07:33

最初の方(5～20あたり)、少しだけ読んだんだけど、説明（言い回し）が洗練されていて、
プロの文章に見える。
テクニカルライタさんでつか？

90 ：2ch過去スレのコピペ：03/04/12 11:10

今度の論点は、継承の事か。
こちらの方が、深く根深い問題だな。
継承したら、子クラスは親クラスのインタフェースを必ず
すべてサポートしなければいけないのが、嫌なんだろうな。
階層の下に行くにつれて、インタフェースがどんどん大きくなっていって、
ある時点での子クラスは、その子クラス自身が使われる問題領域では
恐らく使わないであろうインタフェースまでサポートしなければいけないのが納得いかない…と。

これは確かに歯がゆいねぇ。
(1)子クラスが親クラスのインタフェースを全て扱えることを保証
(2)あるクラスが必要最小限のインターフェースをサポート
の2つの要求のどちらが優先か、にかかっている。
普通は、1>2の場合継承を使い、1<2の場合委譲を使う。
実装階層とインタフェース階層を別に用意して、
TPOに合わせて(?)インタフェース階層をいくつも作ったりとか…。
ここら辺が気持ち悪い？

91 ：2ch過去スレのコピペ：03/04/12 11:13

クラスを「利用する側」と「提供する側」の永遠のジレンマですな．
利用する側：クラスは「自分の」プログラムに適したものが欲しい
提供する側：クラスは「利用者すべての」プログラムで使える様にしたい
つうことで，利用者は最適性を，提供者は汎用性を追い求める……と
結局，両方とも追い求めているものが違う訳だからねぇ．

通常だと継承とかしてクラスのカスタマイズをするわけだけど，
隠蔽という概念を尊重するのならばあまり無茶はできないし……

利用する側：
　カスタマイズ「したい」部分をカスタマイズすれば最適化を行える
　しかもそのカスタマイズは未来永劫利用できることを保証されている

提供する側：
　ユーザーがどのように利用していようと，ユーザーに影響を与えずに
　クラスのカスタマイズができる．

つうのは理想だなぁ．両者が好き勝手やるとなんにもできないので，
結局契約で縛る必要があるんだけど……

……デザインパターンとかフレームワークとかの話になるのかな？

92 ：山崎渉：03/04/17 15:30

（＾＾）

93 ：デフォルトの名無しさん：03/04/17 19:02

age

94 ：public ◆PmQxVjGtl2 ：03/04/17 19:11

Javaのデザインパターン！

95 ：山崎渉：03/04/20 03:14

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

96 ：デフォルトの名無しさん：03/04/21 00:47

そもそも、本当のオブジェクト指向ってなんなんですかね？
なんかいい本ありまつか？
C++から入ってしまった俺としては、C++≠OOは遠すぎるけどC++≒OOではないよなぁというぐらいの
認識しかないんでつけど。

97 ：デフォルトの名無しさん：03/04/21 01:03

>>96
Smalltalk だよ。

98 ：デフォルトの名無しさん：03/04/21 01:04

>>96
C++ でも、コンストラクタ以外、つまりデストラクタとメンバ関数をみんな virtual にすれば、
かなり良質な OO になる。

99 ：デフォルトの名無しさん：03/04/21 01:12

iostreamは、多重継承あり、実装継承あり、インターフェース
継承あり、委譲(streambufへ)あり、複雑な内部状態あり、と
オブジェクト指向の好例だと思うけど。
文句を付けるとしたら、streamとstreambufの間の結合が
強すぎることだけど、これは仕方無い。

100 ：デフォルトの名無しさん：03/04/21 01:12

>>98
こういう場所でねたはやめれ。

101 ：とりあえずつっこみ：03/04/21 01:25

>>32 >>71　学術用途で抽象度の高かったオブジェクト指向
っていうレトリックは、何を指しているのかいなー？
アクター？

102 ：デフォルトの名無しさん：03/04/21 01:46

>>100
ネタじゃねー。あたりまえのことだ。

103 ：デフォルトの名無しさん：03/04/21 02:08

>>98,>>100 漏れ的にも、このスレ全体、特に>>98は不思議な違和感を覚える。最近のオブジェクト指向業界って、こんなに違和感のある意見が頻出する場所なの？

104 ：デフォルトの名無しさん：03/04/21 02:14

>>103
確かに、Java のメソッドはみんな C++ でいう virtual やな。

105 ：デフォルトの名無しさん：03/04/21 02:17

Java厨をまともに相手にするなよ･･･

106 ：デフォルトの名無しさん：03/04/21 02:18

virtual ＝動的ってなニュアンスなのかなー。
でも、それだけで良質なOOになるとは思えないような。

107 ：デフォルトの名無しさん：03/04/21 03:27

馬鹿だから、virtual にするかどうか、考えたくないんだろ。
みんな virtual なら、何でもオーバーライドできて便利♪みたいな。
オーバーライドが危険なメソッドとか、クラス丸ごと継承不可の時の効率とか、
どうでもいいんだろうな。

108 ：デフォルトの名無しさん：03/04/21 06:52

>>107
C++ にはオーバーライドを禁止する言語的な指定はできないから、virtual をやめようと
なんだろうとどうにもできない。
virtual じゃなくても、子クラスとして呼び出した場合はオーバーライドした方の
メソッドが呼ばれちゃうし。

効率はリファクタリングのときに考えること。
初めから非 virtual にしたらたぶん効率がいいだろうと仮定してやみくもにする人、いるんだよね。
ちゃんと、プロファイルしてからオーバーヘッドの高い部分だけを絞り込んで、効率が上がる方法で
リファクタすること。エンジニアリングなんだから、気分じゃなくて、
測定して行うこと。

109 ：デフォルトの名無しさん：03/04/21 07:01

普通は安全にしておいて、必要なところだけ穴を開けるんだよ。
こんな常識もわからんの？
パフォーマンスのチューニングは全然話が違う。
Javaはアホ用の言語だからしかたないが、それが開発の常識だと勘違いするな。

110 ：デフォルトの名無しさん：03/04/21 07:04

>>109
セキュリティの話？

111 ：デフォルトの名無しさん：03/04/21 07:05

ふつうはポートを塞いでおいて必要なところだけあける。

112 ：デフォルトの名無しさん：03/04/21 07:06

>>109
馬鹿だなあ。Java の方が final 指定ができるからメソッドのオーバーライドを
言語レベルで禁止できるんだよ。

113 ：デフォルトの名無しさん：03/04/21 07:07

>>109 は馬鹿だから、セキュリティの話で煙に巻こうとしていまつ。

114 ：デフォルトの名無しさん：03/04/21 07:08

final デフォルトにしろって話でしょ。
何でもオーバーライドできるのが最高ってのはマヌケすぎると。

115 ：デフォルトの名無しさん：03/04/21 07:08

ちなみにC++で、virtual じゃないメソッドをオーバーライドする奴は氏ね。
オーバーライドしちゃいけないメソッドに、バーチャルつける奴は氏ね。

116 ：デフォルトの名無しさん：03/04/21 07:09

>>109
> パフォーマンスのチューニングは全然話が違う。

効率の話はそっちが最初にしてきたと思はれ。

117 ：デフォルトの名無しさん：03/04/21 07:11

やっぱりJava真理教だな

118 ：デフォルトの名無しさん：03/04/21 07:11

そうか。Java でやる場合は、なんでもかんでも final にしておいて、
必要になったら final をはずしていくということでつね。

119 ：デフォルトの名無しさん：03/04/21 07:13

>>118
書かなければ final、必要なら virtual と書くが望ましいだろうな。

120 ：デフォルトの名無しさん：03/04/21 07:22

C++ で、オーバーライドするとエラーにできるような書き方ってないかな？

121 ：デフォルトの名無しさん：03/04/21 07:24

Delphi だと、オーバーライドしてもいい関数は virtual をつけて、
それをオーバーライドする段で override をつけて、それが一致しないと
エラーになる。
Java だと、final をつけたのはオーバーライドするとエラーになる。

122 ：デフォルトの名無しさん：03/04/21 07:26

> Delphi だと、オーバーライドしてもいい関数は virtual をつけて、
> それをオーバーライドする段で override をつけて、それが一致しないと
> エラーになる。
理想的だね。

123 ：デフォルトの名無しさん：03/04/21 16:36

finalの話とは微妙にずれるが、JavaもC#みたく
オーバーライドするときは、overrideとかのキーワード
つけるようにしたほうが便利だと思うんだが。
コンパイル時にシグネチャが合ってるかチェックできるし、
オーバーライドしてるんだって一目でわかるし。

124 ：デフォルトの名無しさん：03/04/21 17:39

オーバーライドに関する認識が随分様変わりしたね。
Javaが出た頃は
｢C++はvirtualをつけないとオーバーライドできない。
それに比べJavaはデフォルトでオーバーライドできる。
これこそ真のオブジェクト指向言語だ」
みたいな論調があったからね。
最近はオーバーライドに限らず、
継承一般に関して反動的（？）な意見が主流になってる。
時代による認識の変化は面白い。

125 ：デフォルトの名無しさん：03/04/21 22:32

昔はC++にもoverride指定子があったよなぁ...
と思いつつ、望洋先生の本を眺めてみたけど見つからなかった。

かわりに overload 宣言子をみつけた。
overload func;
int func(int);
int func(char*);
などのように使うらしい。
きっと、これを間違って覚えていたんだな。

オブジェクト指向とは何の関係も無いので下げ。

126 ：デフォルトの名無しさん：03/04/22 00:53

>96
オブジェクト指向は言語ではなくて考え方。
よく言われるけどオブジェクト指向言語はオブジェクト指向的な考え方を
支援するための道具でしかないよ。
＃C++≠OO、C++≒OOという比較は、比較する質が違っているから
＃あんまり意味無いと思う。

ただ、使う道具によってどのようなプログラミングをするのか制限されてしまうから、
オブジェクト指向を学習するときは正しい道具を使って学習するのが非常に重要。

C++って基本的にプロフェッショナルツールだから、学習用として使用させるのは
とても危険だとおもう。
＃山の素人をいきなり冬の日本アルプスに叩き込むようなもんだよね……

127 ：デフォルトの名無しさん：03/04/22 01:20

>>126
本気で学習用にするなら、大学の講義で言えば、
１年間くらい黒板と原書（笑）輪読で勉強して、
それから半年実習やって、というくらいの覚悟
でやらないと駄目だよな。

128 ：デフォルトの名無しさん：03/04/22 01:29

C++厨は懲りずに必死になってJavaを馬鹿にしようとしているようだが
5年遅すぎたようだな。

いまどきJavaは遅いといっている奴は時代遅れ

129 ：デフォルトの名無しさん：03/04/22 22:06

96です。思ったより話が膨らんでびっくりしてまつ。
色々と参考になりました。ありがとうございます。
一番判りやすかったのは126さんかも(w

130 ：デフォルトの名無しさん：03/04/23 03:49

>>128
そういや、Java 用のネイティブコンパイラが GCC に入ったっけ？
（>>128 は JIT コンパイラのことを言ってると思うのだが、
　最初の１回はどうしても遅くなるので速度的には没。
　用途的には◎だけど）

131 ：デフォルトの名無しさん：03/04/24 00:38

JavaはJITのおかげでだいぶ早くなったのは認めるけど、
起動の遅さとメモリ喰いなのは相変わらずだよね。
やっぱデスクトップアプリケーションには向かないな。

132 ：デフォルトの名無しさん：03/05/01 23:51

歯のシコウには、ワロタ！

もはや、オブジェクト失効か？

ところで、Lyeeってオブジェクト指向ですか？？？

133 ：デフォルトの名無しさん：03/05/02 14:40

20倍の奴ですか？

134 ：デフォルトの名無しさん：03/05/02 22:56

>>132
あれはスカラー波指向

135 ：デフォルトの名無しさん：03/05/21 19:00

♥

136 ：山崎渉：03/05/28 12:54

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

137 ：名無しさん＠Linuxザウルス：03/06/26 23:58

げ

138 ：デフォルトの名無しさん：03/06/27 01:08

hosgu

139 ：デフォルトの名無しさん：03/06/27 01:27

GeHosyu

140 ：デフォルトの名無しさん：03/06/29 00:41

フーン

141 ：デフォルトの名無しさん：03/06/29 07:24

Javaがアホ用の言語だと思っている香具師は、プログラミング言語Javaの第3版でも読みなされ。

142 ：山崎渉：03/07/15 10:26

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

143 ：山崎渉：03/08/02 02:53

（＾＾）

144 ：デフォルトの名無しさん：03/08/11 20:03

成功する設計では継承よりもコンポジションが多用されるようなことを聞いたんですけど
コンポジションってのは確か has-a のことですよね？結局昔からの設計のほうが仕事
はうまくいくってことなのかな？職業プログラマの皆さんどう思いますか？

どこに書いていいのかわからないためage

145 ：デフォルトの名無しさん：03/08/11 20:11

MFCやOWLが失敗したのも継承を多用するからだろうね。

146 ：デフォルトの名無しさん：03/08/11 20:16

沢村いわく
ポリモフィズム=OO
継承を多用しないということはポリモフィズムを行わないということか

つまり沢村は間違ってると

147 ：沢口靖子：03/08/14 08:06

ヌヒよ、ポリモーフィズムが生きるのはインターフェイスや抽象クラスだな
その程度の継承は許されてると思うよ。
継承の多用＝ポリモーフィズムじゃないので沢村が間違ってるとも言い切れない

ただ何でもかんでも汎化するのはあたしゃすきじゃありません

148 ：マリーナの夏：03/08/14 10:03

http://life.fam.cx/a011/

149 ：デフォルトの名無しさん：03/08/14 17:19

>>147
おまいは、早く結婚しろ！

150 ：山崎渉：03/08/15 15:25

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

151 ：デフォルトの名無しさん：03/08/24 19:44

名スレの予感

152 ：デフォルトの名無しさん：03/09/23 13:32

おぶ戦スレから引っ越してきました。

ユースケース分析が、OOだというあなたに聞いてみたい。

ユースケース分析では、あるユースケースをどのように
実現するかという観点で、必要ならサブユースケースに
分割していきます。
これって構造化分析じゃないでしょうか。
どこがOOなんでしょう。

153 ：デフォルトの名無しさん：03/09/23 15:00

>>152
いや、ユースケースそのものはオブジェクト指向とは別もんだと思うが。
誰がそんなこと言ってる？

154 ：デフォルトの名無しさん：03/09/23 15:18

ユースケ・サンｔ (ﾄﾞｷｭｿ!) うわっやられたぁヽ(´ー｀)ノ

155 ：1：03/09/23 15:36

このスレどうしようかなー・・・・
2chのテキストマイニングは時間がかかりすぎ・・・・

156 ：デフォルトの名無しさん：03/09/24 07:31

>>153
おぶ戦スレでそんなこといわれたからさ。
OOの本にもユースケース分析が載ってたりするし。
はっきりさせたかったのよ。

157 ：デフォルトの名無しさん：03/09/24 07:35

>>155
このまま落ちてくのはもったいないスレだよね。
をれも考えを整理するのに役立った。

158 ：デフォルトの名無しさん：03/09/24 16:34

読みであるなあ　このすれ　

159 ：名無し＠沢村：03/09/30 17:10

オブジェクト指向を理解して使いこなすためには、最低でも５８程度の偏差値が必要だろうね。
大学でいえば成城大、芝浦工大、電通大以上だ。このレベルではちょっときついが、頑張れは何とかなる。
６１以上になると、手続き型言語を覚えるのと同程度の労力でオブジェクト指向もマスターできる。
日本女子大、学習院、青学以上だ。
５４以下ではまず不可能だろうね。
国際大、金沢工大、熊本学園大などだ。
もちろん偏差値が高いのにランクが低い大学にいってるやつとかは、この限りではないよ。

160 ：名無し＠沢村：03/09/30 17:11

２ちゃんねらーの平均偏差値は５４～５６の間とおれは見てるから、オブジェクト指向を理解して使いこなすためには、ちょっと足りないものがあるね。
だから２ちゃんねらーには手続き型言語が合っている。
もちろん頑張れば不可能ではないから、やってみることだ。

161 ：デフォルトの名無しさん：03/09/30 17:56

　　　　　　　　　　　　　　巛彡彡ミミミミミ彡彡
　　　　　　　　　　　　　巛巛巛巛巛巛巛彡彡
　　　　　　　　　　r､r.r ､|:::::　　　　　　　　　　|
　　　　　　　　　r |_,|_,|_,||::::::　　　　 ⌒　　　⌒|
　　　　　　　　　|_,|_,|_,|/⌒　　　　 -="- 　(-="　　　　ぁぁそうなんや・・・・
　　　　　　　　　|_,|_,|_人そ(^i　　　 '"" ) ･･)""ヽ　　　なるほどね・・・
　　　　　　　　　|　)　　ヽﾉ　|.　　┃｀ー-ﾆ-ｲ｀┃
　　　　　　　　　|　　`".｀´ 　ﾉ　　 ┃　　⌒ 　┃|
　　　　　　　　人　　入＿ノ´　　　┃　　　　┃ﾉ＼
　　　　　　　／　　＼＿／＼＼　　 ┗━━┛/ ＼＼
　　　　　　　　　　　　／　　＼　ト ───ｲ/　　ヽヽ

　　　　　　　　　　　　　　巛彡彡ミミミミミ彡彡
　　　　　　　　　　　　　巛巛巛巛巛巛巛彡彡
　　　　　　　　　　r､r.r ､|:::::　　　　　　　　　　|
　　　　　　　　　r |_,|_,|_,||::::::　　　　／'　　'＼ |
　　　　　　　　　|_,|_,|_,|/⌒　　　　 (・ )　　(・ )|
　　　　　　　　　|_,|_,|_人そ(^i　　　　⌒ ) ･･)'⌒ヽ　　　・・・で、何が言いたいん？
　　　　　　　　　|　)　　ヽﾉ　|.　　　┏━━━┓|
　　　　　　　　　|　　`".｀´ 　ﾉ　　 ┃　ノ￣i　┃|
　　　　　　　　人　　入＿ノ´　　　┃ヽﾆﾆノ┃ﾉ＼
　　　　　　　／　　＼＿／＼＼　　 ┗━━┛/|＼＼
　　　　　　　　　　　　／　　＼　ト ───ｲ/　　ヽヽ

162 ：デフォルトの名無しさん：03/09/30 20:16

関数型言語との対比で用いられる「手続き型言語」と区別するために
「手続き志向言語」と呼ぶのがいいと思うがどうか。

163 ：デフォルトの名無しさん：03/10/04 10:41

OOの説明するとき、オブジェクトとは物　みたいなとこから説明から始めるよりも
多様性をいきなり説明したほうがありがたみがわかるような気がするんですけど

私だけかな？

164 ：デフォルトの名無しさん：03/10/04 11:54

diversity?

165 ：デフォルトの名無しさん：03/10/04 13:49

>>163
釣られてやるよ。
多態性をどう説明すると、ありがみがわかるんだ。

166 ：デフォルトの名無しさん：03/10/05 21:17

>>165
162じゃないが・・・
解凍ソフトを作るときLHAとかZIPを解凍するクラスが同じ抽象クラスを継承していたら
LHAとかZIPを意識することなくコードを書くことができる?とかかな？

167 ：デフォルトの名無しさん：03/10/06 07:22

>>166
いや、多態性をカプセル化や継承よりも先に説明したほうが
わかりやすいのはなぜかということ。
多態性は継承の側面も持ってるから。

168 ：デフォルトの名無しさん：03/10/06 11:36

>>167
ってか、もうそろそろカプセル化だの継承だの多態性だのって
だれも出所も背景も妥当性もしらんような要素に無理やり当てはめてooを説明
しようとするのはやめようぜ。oopやooplの機能紹介ならともかく。

オブジェクトを「データや機能性データ（関数）を自らに内包するデータ」
であることを相手のレベルに合わせてしっかり説明してから、データ内包の
しかた（設計）、それへのアクセスや（機能性があるならその）発現方法、
あるいはそのタイミングを、解決したい問題に合うように吟味するのがoo、
ってことでいいじゃん。あとは解決したい問題の範囲、使用するooplを明示的に
して、どんなときに何がウレシイかを具体例を語ればいい。

169 ：デフォルトの名無しさん：03/10/06 22:38

>>168が、いいこといった

170 ：デフォルトの名無しさん：03/10/07 02:31

偏差値40で普通にOO設計やってますが・・
確かに最初理解するのは大変だったけど　滝汗

171 ：デフォルトの名無しさん：03/10/07 02:33

抽象化ってのは、考えるのを楽にする手段だからね。
身につけば、いわゆる頭の良くない人にとってのほうが、
なおお得でしょう。

172 ：デフォルトの名無しさん：03/10/07 02:52

>>168
オブジェクト＝クロージャな人ですか？

173 ：デフォルトの名無しさん：03/10/07 10:17

APIはOO？

174 ：デフォルトの名無しさん：03/10/07 21:56

>>172
クロージャは「データ（環境）や機能性データを自らに内包する機能性データ」

175 ：デフォルトの名無しさん：03/10/07 23:06

>>174
オブジェクトは「データ」で
クロージャは「機能性データ」
ですか。
立場がなんとなくわかります。

176 ：デフォルトの名無しさん：03/10/07 23:30

>>175
わからんよ。
機能性データって何語よ。

177 ：デフォルトの名無しさん：03/10/07 23:53

振る舞いを持つデータ　かな？

178 ：デフォルトの名無しさん：03/10/08 00:14

>>176
だから関数だって言っているｗ

179 ：デフォルトの名無しさん：03/10/08 00:18

>>175
まあ、どっちが主役かって主観の話だわね。
オブジェクト指向と（方法論としての）抽象データ型の違いと話が似ているかも。
オブジェクトとクロージャもしかりで、
理屈では（ってか仕組みや枠組み的には）まったく同じもの。

180 ：デフォルトの名無しさん：03/10/08 00:40

>>179
以前からの疑問なんですが、本来オブジェクト指向は、
抽象データ型＋「抽象関数型」と呼ばれるべきなんじゃ
ないかと。

181 ：デフォルトの名無しさん：03/10/08 01:47

>>180
関数型って言い回しは語弊があるかも…ｗ

あと、抽象データ型（手法のほうじゃなくて、「ユーザー定義可能な型」
のほう）に“抽象”関数、すなわち仮想関数という考え方や仕組みも
含まれるような気もしなくもありませんが、どんなもんでしょう。

182 ：デフォルトの名無しさん：03/10/09 00:00

>>181
「関数型」はまずかったですね。じゃ「抽象手続き型」とか・・・。
個人的な単純に言葉からくる印象だとC++のテンプレートとかで型をパラメータ化
するほうが「抽象データ型」で、「仮想関数」を使うのは「抽象手続き型」と
いった方がしっくりするんじゃないかという気がしたもので。
一般的な用語の使い方ではないのですけれども。

183 ：デフォルトの名無しさん：03/11/05 00:53

age

184 ：デフォルトの名無しさん：03/11/05 14:00

言語レベルで無理やり理解するのではなく、
イメージの世界で理解せよ。

185 ：デフォルトの名無しさん：03/11/12 13:27

this,superについて説明せよ

186 ：デフォルトの名無しさん：03/11/12 17:58

この板のオブジェクト指向の説明についてを見ればいいんじゃないの？

187 ： ◆qQ4COMPILE ：03/11/13 09:54

勉強になるスレだな。

188 ：デフォルトの名無しさん：03/11/15 08:00

>>185
this=自分　super=基底クラス・親クラス

189 ：デフォルトの名無しさん：03/11/16 03:52

>>188
thisもsuperも自分だと思っていたよ。

190 ：名無しさん＠Linuxザウルス：04/02/16 21:49

>>184
妹クラスを作って１２人の妹を派生させて

呼びかけると
お兄い様
お兄いちゃん
お兄いたま
(ry

と応答させて
おお　ポリモーフィズム　マンセー！！

という感じで理解しろという事かな

191 ：最凶VB厨房：04/02/16 22:01

よくそんなキモイ発想ができるな。

192 ：名無しさん＠Linuxザウルス：04/02/16 22:29

>>191
いや　よくいるだろ　数学の公式は覚えられない
のにモーニング娘の名前は全員覚えてるやつ

だから分からんやつは　まずは好きなオブジェ
クトを作らせてそれを複雑にしていった方が
覚えられるだろう

それに客観的に見れば　あの作品wの"妹達"は
それぞれ違うのに　"妹"という共通のくくりに
入っていて"兄を慕う"という共通の属性を持っ
ている

継承とかポリモーフィズムの題材としては
最適じゃないのかｗ

193 ：デフォルトの名無しさん：04/02/16 22:38

>>192
わらた。

194 ：名無しさん＠Linuxザウルス：04/02/16 22:39

まあ本当は構成を考えて必要なclassを作り
オブジェクトを生成するのだろうが

最初はなかなか難しいだろうからな

195 ：最凶VB厨房：04/02/16 22:45

あの作品が何を指しているのかさっぱりわからんし、
好きなオブジェクトが妹というのもキモイだけ。

ポリモーフィズムの題材として
ポリモーフィズムを使うと何がうれしいのかが知りたいのであって
おにいたまなぞ言われてもキモイだけで何もうれしくない。

196 ：名無しさん＠Linuxザウルス：04/02/16 23:09

>>195
その激しい嫌いよう・・・
もしや　おぬしリアル妹がいるな

197 ：最凶VB厨房：04/02/16 23:21

おらん。

198 ：デフォルトの名無しさん：04/02/17 07:44

ほかの板でやってくれ。きもちわるい。

199 ：デフォルトの名無しさん：04/02/17 10:44

>>190
先生！萌え萌えオブジェクト指向の執筆おながいしまつ

200 ：名無しさん＠Linuxザウルス：04/02/17 17:22

>>199
こらほんとにそんな連載をこのスレで
やられたら大変じゃないか

ついでに200Get

201 ：デフォルトの名無しさん：04/02/21 03:09

藻前らここでも見ておけ
ttp://www.entis.jp/doc/lolita_programing/lolita1.html

202 ：デフォルトの名無しさん：04/02/21 10:01

>>201
役に立たねぇぇぇぇ

203 ：デフォルトの名無しさん：04/02/22 13:57

　　　　　　　　　　　　↓ヒゲポソ
　　　　　　　　　　　　　　）
　　　　　　　　　　　　　（
　　　　　　　　,,　　　　　　　　）　　　　　　）
　　　　　　　　ﾞﾐ;;;;;,_　　　　　　　　　　　（
　　　　　　　　　ミ;;;;;;;;､;:..,,.,,,,,
　　　　　　　　　　i;i;i;i; '',',;^′..ヽ
　　　　　　　　　　ﾞゞy､､;:..､）　　｝
　　　　　　　　　　　.¨.､,_,,､_,,r_,ノ′
　　　　　　　　/;:;":;.:;";i; '',',;;;_~;;;′.ヽ
　　　　　　　　ﾞ{y､､;:...:,:(´∇｀).:.､;:.,._､｝
　　　　　　　　".¨ｰ=v ''‐ .:v､,,､_,r_,ノ′
　　　　　　　/;i;i; '',',;;;_~⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′..ヽ　
　　　　　　ﾞ{y､､;:...:,:.:.､;､;:.:,:.:.　._　　.､）　　､｝
　　　　　　　".¨ｰ=v ''‐ .:v､冫_._ .､,_,,､_,,r_,ノ′
　　　　　　/i;i; '',',;;;_~υ⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′.ｿ.ヽ
　　　　　　ﾞ{y､､;:..ゞ.:,:.:.､;:.ﾐ.:,:.:.　._υﾟo,,'.､）　　､｝
　　　　　　ヾ,,..;::;;;::,;,::;):;:;:; .:v､冫_._ .､,_,,､_,,r_,ノ′　　　

204 ：190：04/02/24 12:50

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

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

まずオブジェクト指向を解説するにあたって一言。この連載では厳密には正しくないけど、分かりやすい例えを使いたいと思います。
これは不完全でも分かった方が、完全さにこだわり、分からなくなるよりも|
何倍もましだからです。

これは、メイド服について理解した時を思い出してもらえればわかるでしょう。
「○○メイドはメイド服じゃないんだよほんとのメイド服というのはね（ry」といったオタのうんちくを聞くよりも
まほろまてぃっくや、ハンドメイドメイというアニメから入り、
メイドコスプレの女の子の写真をとりにイベント参加。
メイドホームページを作ってしまうようになってはじめて
ああ、「○○メイドは、ほんとのメイド服じゃないんだ」という事が分かるのと同じです。

それではまず、オブジェクト指向が生まれた経緯から説明しましょう。
以前、コンピュータという物は高価でしかも今よりも遙かに低性能でした。
そこで、人間がコンピュータ様の都合に合わせて、コンピュータ様が
分かりやすいようにプログラムをしていました。
このコンピュータ様が女の子型の匡体で、「ちぃ」とかわいく鳴いたりするなら、そりゃいたれりつくせりして
やりたくなりますが、実際にはただの無愛想な箱にすぎません。
その後コンピュータが高性能で安価になるにつれ、なんで人間様がコンピュータごときの都合に合わせなあかんねん。
もっと人間様の都合に合わせて、そう現実の世界を、そのままメモリ内につくって、それがプログラムとして動いたらいいのに。
という考えが出てきてオブジェクト指向が生まれました。

ですから、コンピュータの事を考えなければ、オブジェクト指向はごく単純な事なのです。
単純で当たり前すぎるがゆえに、分からなくなってしまうのです。

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

205 ：190：04/02/24 12:56

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

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

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

206 ：デフォルトの名無しさん：04/02/24 14:29

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

207 ：デフォルトの名無しさん：04/02/24 22:26

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

208 ：デフォルトの名無しさん：04/02/24 22:54

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

209 ：デフォルトの名無しさん：04/02/25 00:15

「オブ脳」読め！

210 ：デフォルトの名無しさん：04/02/25 02:21

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

211 ：190：04/02/25 06:59

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

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

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

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

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

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

212 ：190：04/02/26 08:55

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

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

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

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

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

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

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

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

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

213 ：デフォルトの名無しさん：04/02/26 23:31

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

214 ：デフォルトの名無しさん：04/02/28 03:48

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

215 ：デフォルトの名無しさん：04/02/28 04:04

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

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

216 ：デフォルトの名無しさん：04/02/28 12:59

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

217 ：190：04/02/28 18:43

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

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

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

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

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

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

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

218 ：デフォルトの名無しさん：04/03/01 00:52

連載期待あげ

219 ：デフォルトの名無しさん：04/03/03 13:52

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

期待あげ

220 ：デフォルトの名無しさん：04/03/08 22:41

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

221 ：デフォルトの名無しさん：04/03/09 01:26

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

222 ：名無しさん：04/03/10 08:37

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

223 ：デフォルトの名無しさん：04/03/31 17:23

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

224 ：デフォルトの名無しさん：04/03/31 17:26

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

225 ：デフォルトの名無しさん：04/03/31 21:39

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

226 ：デフォルトの名無しさん：04/04/01 00:46

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

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

227 ：デフォルトの名無しさん：04/04/01 23:00

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

228 ：デフォルトの名無しさん：04/04/01 23:13

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

229 ：デフォルトの名無しさん：04/04/01 23:44

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

230 ：デフォルトの名無しさん：04/04/02 00:11

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

231 ：デフォルトの名無しさん：04/04/02 00:38

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

ﾊｧ( Д)ﾟﾟ？

232 ：デフォルトの名無しさん：04/04/02 06:20

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

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

233 ：デフォルトの名無しさん：04/04/02 14:07

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

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

234 ：デフォルトの名無しさん：04/04/02 18:14

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

　　実現するってなに？

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

235 ：デフォルトの名無しさん：04/04/02 18:37

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

236 ：デフォルトの名無しさん：04/04/02 20:21

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

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

237 ：デフォルトの名無しさん：04/04/02 21:13

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

じゃ、あかんか?

238 ：デフォルトの名無しさん：04/04/02 23:09

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

239 ：デフォルトの名無しさん：04/04/03 00:26

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

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

ボケに（ry

240 ：デフォルトの名無しさん：04/04/04 11:10

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

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

VBは知らん。

241 ：デフォルトの名無しさん：04/04/04 13:43

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

OMG的にいうなら属性だが

242 ：デフォルトの名無しさん：04/05/10 21:50

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

243 ：デフォルトの名無しさん：04/06/06 16:45

244 ：デフォルトの名無しさん：04/06/10 02:30

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

245 ：デフォルトの名無しさん：04/06/30 01:04

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

246 ：デフォルトの名無しさん：04/07/04 09:44

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

247 ：デフォルトの名無しさん：04/07/09 20:51

>>244
ただの誤植だろ？

248 ：デフォルトの名無しさん：04/07/10 02:17

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

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

249 ：デフォルトの名無しさん：04/07/21 18:50

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

250 ：デフォルトの名無しさん：04/07/21 19:19

ならねえよ。

251 ：デフォルトの名無しさん：04/07/23 00:02

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

252 ：249：04/07/23 08:55

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

253 ：デフォルトの名無しさん：04/07/23 11:01

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

254 ：デフォルトの名無しさん：04/07/23 11:54

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

255 ：デフォルトの名無しさん：04/07/23 12:21

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

256 ：デフォルトの名無しさん：04/07/23 14:04

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

257 ：デフォルトの名無しさん：04/07/23 22:39

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

258 ：デフォルトの名無しさん：04/07/23 23:13

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

259 ：デフォルトの名無しさん：04/07/24 08:54

>>258
ゴキカブリ

260 ：デフォルトの名無しさん：04/07/24 09:18

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

261 ：デフォルトの名無しさん：04/07/24 10:25

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

262 ：デフォルトの名無しさん：04/07/24 11:10

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

263 ：デフォルトの名無しさん：04/07/24 11:11

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

264 ：デフォルトの名無しさん：04/07/24 11:22

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

265 ：デフォルトの名無しさん：04/07/24 11:52

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

266 ：デフォルトの名無しさん：04/07/24 11:55

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

267 ：デフォルトの名無しさん：04/07/24 11:59

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

268 ：デフォルトの名無しさん：04/07/24 12:06

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

269 ：デフォルトの名無しさん：04/07/24 12:17

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

270 ：デフォルトの名無しさん：04/07/24 19:02

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

271 ：デフォルトの名無しさん：04/07/24 19:24

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

272 ：デフォルトの名無しさん：04/07/24 19:26

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

273 ：デフォルトの名無しさん：04/07/24 19:39

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

274 ：デフォルトの名無しさん：04/07/24 21:54

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

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

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

275 ：デフォルトの名無しさん：04/07/24 22:09

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

276 ：デフォルトの名無しさん：04/07/24 23:49

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

277 ：デフォルトの名無しさん：04/07/24 23:51

>>276
JavaScript

278 ：デフォルトの名無しさん：04/07/25 05:06

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

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

279 ：デフォルトの名無しさん：04/07/25 09:17

Smalltalk ね。

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

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

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

280 ：デフォルトの名無しさん：04/07/25 17:04

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

281 ：278：04/07/25 20:28

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

282 ：デフォルトの名無しさん：04/07/25 21:01

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

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

283 ：273：04/07/25 21:39

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

284 ：デフォルトの名無しさん：04/07/25 22:07

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

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

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

285 ：デフォルトの名無しさん：04/07/25 22:37

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

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

286 ：デフォルトの名無しさん：04/07/26 09:33

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

287 ：デフォルトの名無しさん：04/07/26 10:16

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

288 ：デフォルトの名無しさん：04/07/26 17:48

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

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

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

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

289 ：286：04/07/26 23:13

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

290 ：デフォルトの名無しさん：04/07/27 00:58

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

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

291 ：デフォルトの名無しさん：04/07/27 01:29

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

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

292 ：デフォルトの名無しさん：04/07/27 04:12

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

293 ：デフォルトの名無しさん：04/07/27 16:05

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

294 ：286：04/07/27 18:05

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

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

295 ：デフォルトの名無しさん：04/07/27 18:44

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

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

296 ：286：04/07/27 18:51

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

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

297 ：デフォルトの名無しさん：04/07/28 11:27

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

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

298 ：デフォルトの名無しさん：04/07/28 23:00

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

299 ：デフォルトの名無しさん：04/07/29 01:07

>>298
Eiffel

300 ：デフォルトの名無しさん：04/07/29 08:59

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

301 ：デフォルトの名無しさん：04/07/29 10:55

いい本、まだぁ？

302 ：デフォルトの名無しさん：04/07/29 17:11

Agile

303 ：デフォルトの名無しさん：04/07/30 09:34

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

304 ：デフォルトの名無しさん：04/07/30 22:26

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

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

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

305 ：304：04/07/30 22:46

こんな記述があったわ。

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

306 ：デフォルトの名無しさん：04/07/31 01:03

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

307 ：デフォルトの名無しさん：04/07/31 01:15

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

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

308 ：デフォルトの名無しさん：04/07/31 09:11

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

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

gtk ｸﾞｸﾞってみます。

309 ：デフォルトの名無しさん：04/07/31 09:26

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

よさげだな。。。

310 ：デフォルトの名無しさん：04/07/31 17:39

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

311 ：デフォルトの名無しさん：04/08/02 15:40

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

ホントか(w

312 ：デフォルトの名無しさん：04/08/31 23:58

保守していいの？

313 ：308：04/09/01 21:52

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

314 ：デフォルトの名無しさん：04/09/02 09:47

釣り？

315 ：308：04/09/02 10:03

>>314
本物です。

316 ：デフォルトの名無しさん：04/11/16 09:43:02

317 ：デフォルトの名無しさん：04/12/02 06:26:23

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

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

318 ：デフォルトの名無しさん：04/12/02 12:13:24

そうだな…Object Oriented Programmingか

東方見物禄でどうだ

319 ：デフォルトの名無しさん：04/12/02 12:49:20

Objective Oriental Programming

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

320 ：デフォルトの名無しさん：04/12/02 21:26:31

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

321 ：デフォルトの名無しさん：04/12/03 02:53:04

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

322 ：デフォルトの名無しさん：04/12/12 03:30:20

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

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

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

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

323 ：デフォルトの名無しさん：04/12/12 04:01:41

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

324 ：デフォルトの名無しさん：04/12/12 13:44:24

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

325 ：デフォルトの名無しさん：04/12/12 14:56:29

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

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

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

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

こんな感じで

326 ：デフォルトの名無しさん：04/12/12 17:15:09

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

327 ：デフォルトの名無しさん：04/12/12 18:04:13

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

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)という書式は非常に違和感がある

328 ：デフォルトの名無しさん：04/12/12 22:26:13

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

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

329 ：デフォルトの名無しさん：04/12/13 00:18:11

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

330 ：デフォルトの名無しさん：04/12/13 17:42:56

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

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

331 ：デフォルトの名無しさん：04/12/13 19:22:06

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

332 ：329：04/12/13 20:58:22

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

333 ：デフォルトの名無しさん：04/12/13 21:33:23

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

334 ：デフォルトの名無しさん：04/12/13 21:37:09

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

335 ：デフォルトの名無しさん：04/12/13 21:55:30

子供の喧嘩だな

336 ：デフォルトの名無しさん：04/12/13 22:03:22

パラダイム銀河

337 ：デフォルトの名無しさん：04/12/13 22:31:42

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

338 ：デフォルトの名無しさん：04/12/14 00:28:49

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

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

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

339 ：デフォルトの名無しさん：04/12/14 00:29:39

（つづき)

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

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

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

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

340 ：デフォルトの名無しさん：04/12/14 00:30:59

(つづき)

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

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

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

341 ：デフォルトの名無しさん：04/12/14 00:55:38

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

342 ：デフォルトの名無しさん：04/12/14 01:00:42

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

343 ：３４０：04/12/14 01:08:38

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

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

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

344 ：デフォルトの名無しさん：04/12/14 01:11:20

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

345 ：３４０：04/12/14 01:15:39

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

じゃあどうすれば？

346 ：３４０：04/12/14 01:21:29

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

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

347 ：デフォルトの名無しさん：04/12/14 01:25:25

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

348 ：３４０：04/12/14 01:30:16

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

349 ：デフォルトの名無しさん：04/12/14 01:32:26

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

350 ：デフォルトの名無しさん：04/12/14 01:41:31

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

351 ：３４０：04/12/14 01:45:51

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

352 ：３４０：04/12/14 01:57:26

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

353 ：デフォルトの名無しさん：04/12/14 03:12:32

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

354 ：デフォルトの名無しさん：04/12/14 06:28:33

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

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

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

355 ：デフォルトの名無しさん：04/12/14 06:32:56

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

356 ：デフォルトの名無しさん：04/12/14 07:53:34

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

357 ：最凶VB厨房：04/12/14 07:55:33

説明の仕方

358 ：デフォルトの名無しさん：04/12/14 08:05:24

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

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

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

359 ：デフォルトの名無しさん：04/12/14 08:37:37

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

360 ：デフォルトの名無しさん：04/12/14 08:58:47

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

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

361 ：デフォルトの名無しさん：04/12/14 10:37:13

MayerのEiffel本読むといいよ

362 ：デフォルトの名無しさん：04/12/14 11:24:10

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

363 ：デフォルトの名無しさん：04/12/14 11:28:54

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

364 ：デフォルトの名無しさん：04/12/14 12:15:28

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

365 ：デフォルトの名無しさん：04/12/14 12:43:19

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

366 ：デフォルトの名無しさん：04/12/14 12:44:47

362もな

367 ：デフォルトの名無しさん：04/12/14 18:51:09

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

368 ：デフォルトの名無しさん：04/12/14 22:13:54

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

369 ：デフォルトの名無しさん：04/12/14 23:34:53

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

370 ：デフォルトの名無しさん：04/12/17 11:40:19

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

371 ：デフォルトの名無しさん：04/12/17 16:22:01

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

372 ：デフォルトの名無しさん：04/12/17 21:10:07

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

373 ：デフォルトの名無しさん：04/12/17 22:06:24

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

374 ：デフォルトの名無しさん：04/12/17 22:19:29

ヒロシです…

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

ヒロシです…

ヒロシです…

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

ヒロシです…

375 ：デフォルトの名無しさん：04/12/17 23:34:13

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

376 ：デフォルトの名無しさん：04/12/20 00:42:00

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

377 ：デフォルトの名無しさん：04/12/20 00:48:55

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

378 ：376：04/12/20 00:58:03

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

379 ：376：04/12/20 01:15:15

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

380 ：376：04/12/20 01:23:20

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

381 ：376：04/12/20 01:24:43

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

382 ：デフォルトの名無しさん：04/12/20 01:56:52

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

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

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

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

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

383 ：デフォルトの名無しさん：04/12/20 02:02:39

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

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

384 ：376：04/12/20 12:10:48

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

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

何これ(´A`)

385 ：376：04/12/20 12:12:02

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

386 ：デフォルトの名無しさん：04/12/20 12:22:07

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

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

387 ：376：04/12/21 01:46:51

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

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

388 ：376：04/12/22 02:11:18

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

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

389 ：デフォルトの名無しさん：04/12/22 10:08:24

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

390 ：376：04/12/26 17:35:50

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

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

391 ：デフォルトの名無しさん：04/12/26 22:41:28

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

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

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

392 ：=! 340：04/12/26 23:45:13

>>362

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

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

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

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

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

393 ：デフォルトの名無しさん：04/12/27 04:05:26

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

394 ：392：04/12/27 21:49:36

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

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

って言って通じるかな？

395 ：デフォルトの名無しさん：04/12/28 22:59:16

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

396 ：デフォルトの名無しさん：04/12/29 00:01:10

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

397 ：デフォルトの名無しさん：05/01/16 00:29:51

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

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

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

398 ：デフォルトの名無しさん：05/01/16 00:59:30

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

399 ：デフォルトの名無しさん：05/01/16 01:08:58

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

400 ：デフォルトの名無しさん：05/01/16 01:30:32

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

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

401 ：376：05/01/16 01:41:25

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

402 ：400：05/01/16 02:08:32

>401
結構違うと思うよ。

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

403 ：デフォルトの名無しさん：05/01/16 11:17:42

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

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

404 ：397：05/01/19 19:44:43

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

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

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

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

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

405 ：デフォルトの名無しさん：05/01/19 20:55:03

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

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

間違ってたら指摘きぼん

406 ：デフォルトの名無しさん：05/01/19 21:06:12

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

407 ：デフォルトの名無しさん：05/01/19 22:25:09

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

408 ：デフォルトの名無しさん：05/01/19 23:07:42

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

409 ：デフォルトの名無しさん：05/01/19 23:41:33

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

410 ：デフォルトの名無しさん：05/01/20 01:15:16

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

411 ：デフォルトの名無しさん：05/01/20 02:44:23

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

412 ：398 ：05/01/20 03:07:00

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

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

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

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

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

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

413 ：デフォルトの名無しさん：05/01/20 22:00:36

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

例）メタファー

414 ：デフォルトの名無しさん：05/01/20 22:06:51

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

415 ：デフォルトの名無しさん：05/01/20 22:35:22

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

416 ：デフォルトの名無しさん：05/01/20 22:53:18

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

417 ：398：05/01/21 00:50:44

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

418 ：デフォルトの名無しさん：05/01/21 05:43:52

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

419 ：デフォルトの名無しさん：05/01/21 11:39:13

普通に分かると思われ

420 ：デフォルトの名無しさん：05/01/21 11:59:53

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

421 ：デフォルトの名無しさん：05/01/21 12:05:25

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

422 ：デフォルトの名無しさん：05/01/21 22:10:48

>>421
剥げ同。

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

423 ：デフォルトの名無しさん：05/01/21 22:12:28

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

424 ：デフォルトの名無しさん：05/01/21 22:19:10

同じだよ　ちょっとえっち

425 ：デフォルトの名無しさん：05/01/21 23:32:00

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

426 ：デフォルトの名無しさん：05/01/22 10:25:39

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

427 ：398：05/01/22 12:40:40

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

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

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

428 ：最凶VB厨房：05/01/22 13:06:37

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

429 ：デフォルトの名無しさん：05/01/22 13:32:09

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

430 ：デフォルトの名無しさん：05/01/22 14:08:56

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

431 ：デフォルトの名無しさん：05/01/22 15:13:43

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

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

432 ：最凶VB厨房：05/01/22 15:26:46

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

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

433 ：デフォルトの名無しさん：05/01/22 15:32:10

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

434 ：デフォルトの名無しさん：05/01/22 15:53:36

>>433
違うの？

435 ：デフォルトの名無しさん：05/01/22 22:12:20

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

436 ：431：05/01/22 22:49:06

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

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

437 ：デフォルトの名無しさん：05/01/23 00:13:38

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

438 ：最凶VB厨房：05/01/23 09:33:15

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

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

439 ：デフォルトの名無しさん：05/01/23 12:07:19

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

440 ：デフォルトの名無しさん：05/01/23 15:10:25

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

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

441 ：デフォルトの名無しさん：05/01/23 18:21:25

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

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

442 ：デフォルトの名無しさん：05/01/23 19:31:42

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

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

443 ：デフォルトの名無しさん：05/01/23 19:32:44

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

444 ：デフォルトの名無しさん：05/01/23 19:39:28

志村うしろー(棒読み)

445 ：デフォルトの名無しさん：05/01/23 20:21:29

>442
型のある言語ならな

446 ：デフォルトの名無しさん：05/01/23 23:10:28

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

447 ：デフォルトの名無しさん：05/01/24 00:31:46

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

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

448 ：デフォルトの名無しさん：05/01/24 00:46:16

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

449 ：デフォルトの名無しさん：05/01/24 21:46:08

志村？

450 ：デフォルトの名無しさん：05/01/24 23:10:44

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

451 ：デフォルトの名無しさん：05/01/25 11:07:28

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

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

452 ：デフォルトの名無しさん：05/01/25 11:39:43

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

453 ：デフォルトの名無しさん：05/01/25 12:41:24

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

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

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

454 ：デフォルトの名無しさん：05/01/25 13:35:32

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

455 ：デフォルトの名無しさん：05/01/26 02:41:22

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

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

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

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

456 ：デフォルトの名無しさん：05/01/26 02:46:31

fortranﾏﾝｾｰ

457 ：455 ：05/01/26 02:58:01

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

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

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

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

458 ：デフォルトの名無しさん：05/01/26 03:57:16

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

459 ：デフォルトの名無しさん：05/01/26 13:37:13

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

460 ：デフォルトの名無しさん：05/01/26 23:33:25

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

461 ：デフォルトの名無しさん：05/01/26 23:37:29

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

462 ：デフォルトの名無しさん：05/01/27 19:19:22

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

463 ：デフォルトの名無しさん：05/01/27 20:29:00

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

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

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

464 ：デフォルトの名無しさん：05/01/27 23:28:04

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

465 ：デフォルトの名無しさん：05/01/28 13:47:53

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

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

466 ：デフォルトの名無しさん：05/01/28 14:42:06

鎖キャタピラ

467 ：デフォルトの名無しさん：05/01/28 23:01:02

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

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

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

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

468 ：デフォルトの名無しさん：05/01/28 23:39:28

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

469 ：デフォルトの名無しさん：05/01/31 14:14:15

飛行機だけはカンベンな

470 ：デフォルトの名無しさん：05/02/01 01:15:53

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

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

471 ：デフォルトの名無しさん：05/02/01 14:36:41

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

472 ：デフォルトの名無しさん：05/02/04 00:50:16

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

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

473 ：デフォルトの名無しさん：05/02/04 01:16:42

分析

474 ：デフォルトの名無しさん：05/02/08 22:14:42

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

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

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

475 ：デフォルトの名無しさん：05/02/22 02:58:48

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

476 ：デフォルトの名無しさん：2005/03/29(火) 00:59:54

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

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

477 ：デフォルトの名無しさん：2005/03/29(火) 01:03:05

>>476
stdafx.h

478 ：デフォルトの名無しさん：2005/03/29(火) 01:53:20

>>476
Object Persistency
または
Persistent Object

479 ：デフォルトの名無しさん：2005/03/29(火) 03:29:13

>>476
pear/Config :-p

480 ：デフォルトの名無しさん：2005/04/30(土) 16:58:06

(・∀・)ﾊｲｰｷｮ

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

481 ：デフォルトの名無しさん：2005/05/01(日) 13:45:31

キチガイ晒し上げ

482 ：480：2005/05/01(日) 20:33:40

間違えてたｽﾏﾇ

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

483 ：480：2005/05/01(日) 20:34:25

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

484 ：デフォルトの名無しさん：2005/05/01(日) 21:29:47

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

485 ：デフォルトの名無しさん：2005/05/01(日) 21:34:05

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

486 ：デフォルトの名無しさん：2005/05/01(日) 21:35:57

そう急かすなって。

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

487 ：デフォルトの名無しさん：2005/05/01(日) 21:36:30

×状態変換
○状態変化

488 ：480：2005/05/01(日) 21:55:23

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

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

489 ：デフォルトの名無しさん：2005/05/01(日) 22:23:50

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

490 ：480：2005/05/01(日) 22:32:45

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

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

491 ：デフォルトの名無しさん：2005/05/01(日) 22:33:29

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

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

492 ：480：2005/05/01(日) 22:35:44

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

493 ：デフォルトの名無しさん：2005/05/01(日) 22:45:29

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

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

494 ：デフォルトの名無しさん：2005/05/01(日) 22:48:28

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

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

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

495 ：デフォルトの名無しさん：2005/05/01(日) 22:56:07

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

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

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

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

496 ：デフォルトの名無しさん：2005/05/01(日) 22:56:58

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

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

497 ：デフォルトの名無しさん：2005/05/01(日) 22:59:58

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

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

498 ：デフォルトの名無しさん：2005/05/01(日) 23:02:04

アンチデザパタ必死杉

499 ：デフォルトの名無しさん：2005/05/01(日) 23:04:04

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

例えば「Observerパターン」。

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

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

500 ：デフォルトの名無しさん：2005/05/01(日) 23:04:20

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

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

501 ：デフォルトの名無しさん：2005/05/01(日) 23:06:28

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

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

502 ：499=501：2005/05/01(日) 23:08:14

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

503 ：デフォルトの名無しさん：2005/05/01(日) 23:09:48

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

504 ：デフォルトの名無しさん：2005/05/01(日) 23:11:26

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

505 ：489：2005/05/01(日) 23:13:58

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

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

506 ：デフォルトの名無しさん：2005/05/01(日) 23:14:33

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

ほっとけって

507 ：デフォルトの名無しさん：2005/05/01(日) 23:16:37

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

508 ：デフォルトの名無しさん：2005/05/01(日) 23:18:01

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

509 ：デフォルトの名無しさん：2005/05/01(日) 23:40:31

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

>>508
まぁええやん。

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

510 ：デフォルトの名無しさん：2005/05/01(日) 23:45:49

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

511 ：デフォルトの名無しさん：2005/05/02(月) 00:25:11

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

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

512 ：デフォルトの名無しさん：2005/05/02(月) 00:38:40

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

513 ：デフォルトの名無しさん：2005/05/02(月) 00:40:53

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

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

514 ：デフォルトの名無しさん：2005/05/02(月) 00:42:39

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

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

515 ：デフォルトの名無しさん：2005/05/02(月) 00:48:09

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

516 ：デフォルトの名無しさん：2005/05/02(月) 00:51:31

推薦図書/必読書のためのスレッド 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 ：デフォルトの名無しさん：2005/05/02(月) 00:56:34

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

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

518 ：デフォルトの名無しさん：2005/05/02(月) 01:06:32

バカがバカを煽る展開

519 ：【(ｹﾞﾗ】の検索：2005/05/02(月) 01:16:50

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

520 ：デフォルトの名無しさん：2005/05/02(月) 01:17:09

ＰＣ等 [プログラム] ミ,,ﾟДﾟ彡フサギコのﾌｻﾌｻ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 件見つかりました】

521 ：デフォルトの名無しさん：2005/05/02(月) 21:27:20

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

522 ：デフォルトの名無しさん：2005/05/02(月) 22:16:59

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

523 ：こっち：2005/05/02(月) 22:52:01

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

524 ：デフォルトの名無しさん：2005/05/16(月) 21:31:07

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

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

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

525 ：デフォルトの名無しさん：2005/05/17(火) 12:47:10

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

526 ：デフォルトの名無しさん：2005/05/17(火) 13:04:09

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

527 ：524：2005/05/17(火) 15:31:26

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

528 ：デフォルトの名無しさん：2005/05/30(月) 16:52:07

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

529 ：デフォルトの名無しさん：2005/05/30(月) 17:38:22

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

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

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

530 ：デフォルトの名無しさん：2005/05/30(月) 20:49:57

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

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

531 ：デフォルトの名無しさん：2005/05/30(月) 20:52:32

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

532 ：デフォルトの名無しさん：2005/05/31(火) 10:31:29

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

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

533 ：528：2005/05/31(火) 13:05:11

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

534 ：528：2005/05/31(火) 13:05:17

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

535 ：528：2005/05/31(火) 13:06:47

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

536 ：528：2005/05/31(火) 13:09:31

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

537 ：デフォルトの名無しさん：2005/05/31(火) 17:24:44

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

って釣られたのかなー。

538 ：デフォルトの名無しさん：2005/05/31(火) 18:18:17

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

539 ：デフォルトの名無しさん：2005/05/31(火) 23:27:16

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

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

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

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

540 ：デフォルトの名無しさん：2005/06/01(水) 13:01:16

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

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

541 ：デフォルトの名無しさん：2005/06/01(水) 13:34:57

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

542 ：デフォルトの名無しさん：2005/06/01(水) 19:44:12

またお前か

543 ：デフォルトの名無しさん：2005/06/01(水) 20:15:20

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

544 ：デフォルトの名無しさん：2005/06/01(水) 21:31:44

とっくに出てるが何か。

"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

　

545 ：デフォルトの名無しさん：2005/08/03(水) 16:04:23

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

546 ：デフォルトの名無しさん：2005/08/12(金) 01:28:01

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

画用紙の場合だと

画用紙
クレヨン
四角　extends Shape

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

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

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

547 ：デフォルトの名無しさん：2005/08/12(金) 13:29:42

書くのは人間だから人間

548 ：546：2005/08/12(金) 19:29:40

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

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

549 ：デフォルトの名無しさん：2005/08/13(土) 05:58:19

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

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

550 ：デフォルトの名無しさん：2005/08/13(土) 13:26:27

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

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

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

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

とか

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

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

551 ：デフォルトの名無しさん：2005/08/19(金) 12:25:51

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

552 ：デフォルトの名無しさん：2005/08/21(日) 03:31:49

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

553 ：デフォルトの名無しさん：2005/08/23(火) 14:42:58

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

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

554 ：デフォルトの名無しさん：2005/08/23(火) 15:53:22

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

555 ：デフォルトの名無しさん：2005/08/23(火) 16:58:56

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

556 ：デフォルトの名無しさん：2005/08/23(火) 17:20:05

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

557 ：デフォルトの名無しさん：2005/08/23(火) 21:30:53

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

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

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

558 ：デフォルトの名無しさん：2005/08/23(火) 22:18:11

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

559 ：デフォルトの名無しさん：2005/08/23(火) 22:23:42

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

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

560 ：デフォルトの名無しさん：2005/08/23(火) 22:29:38

>>558
サンクス。

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

561 ：デフォルトの名無しさん：2005/08/23(火) 22:30:51

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

562 ：デフォルトの名無しさん：2005/08/24(水) 02:40:09

>>557
知ったか乙。

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

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

563 ：デフォルトの名無しさん：2005/08/24(水) 02:52:46

>>560
つ[実践UML]

564 ：デフォルトの名無しさん：2005/08/24(水) 09:21:22

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

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

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

565 ：デフォルトの名無しさん：2005/08/24(水) 12:05:06

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

566 ：553：2005/08/24(水) 20:26:15

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

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

◇言いたいことその２

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

◇言いたいことその３

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

567 ：デフォルトの名無しさん：2005/08/24(水) 21:13:41

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

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

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

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

568 ：デフォルトの名無しさん：2005/08/24(水) 22:24:59

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

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

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

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

569 ：568：2005/08/24(水) 22:27:04

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

570 ：553：2005/08/24(水) 22:37:36

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

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

571 ：デフォルトの名無しさん：2005/08/24(水) 22:43:30

ついでにもう１つ

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

572 ：デフォルトの名無しさん：2005/08/24(水) 23:07:43

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

573 ：デフォルトの名無しさん：2005/08/24(水) 23:18:41

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

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

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

574 ：デフォルトの名無しさん：2005/08/24(水) 23:21:29

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

575 ：デフォルトの名無しさん：2005/08/25(木) 01:15:10

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

576 ：デフォルトの名無しさん：2005/08/25(木) 01:21:55

>>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じゃないとばっさり切って
捨てるのも大人げないってもんですぜ。

577 ：デフォルトの名無しさん：2005/08/25(木) 19:50:00

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

578 ：デフォルトの名無しさん：2005/08/25(木) 20:42:59

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

579 ：570=553：2005/08/28(日) 18:51:43

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

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

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

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

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

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

580 ：デフォルトの名無しさん：2005/08/29(月) 23:28:42

>> >>573
ちがう。

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

581 ：580：2005/08/29(月) 23:57:14

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

582 ：デフォルトの名無しさん：2005/08/30(火) 01:35:01

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

583 ：デフォルトの名無しさん：2005/08/30(火) 12:41:46

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

わかりやすいバカ印たな

584 ：570=553：2005/08/30(火) 19:31:43

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

585 ：570=553：2005/08/30(火) 19:40:49

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

586 ：デフォルトの名無しさん：2005/09/01(木) 15:24:33

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

587 ：デフォルトの名無しさん：2005/09/01(木) 20:32:56

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

588 ：デフォルトの名無しさん：2005/09/02(金) 02:01:48

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

589 ：デフォルトの名無しさん：2005/09/02(金) 03:48:33

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

590 ：デフォルトの名無しさん：2005/09/02(金) 04:34:32

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

591 ：デフォルトの名無しさん：2005/09/02(金) 08:06:03

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

592 ：デフォルトの名無しさん：2005/09/02(金) 09:21:47

(ﾟДﾟ )ﾎﾟｶｰﾝ

593 ：デフォルトの名無しさん：2005/09/02(金) 14:05:50

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

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

594 ：デフォルトの名無しさん：2005/09/02(金) 16:24:47

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

595 ：579：2005/09/02(金) 16:42:03

俺へのレスか

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

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

596 ：579：2005/09/02(金) 16:51:07

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

597 ：デフォルトの名無しさん：2005/09/02(金) 17:15:47

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

598 ：デフォルトの名無しさん：2005/09/02(金) 19:48:26

そうじゃないの？

599 ：デフォルトの名無しさん：2005/09/02(金) 21:09:05

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

600 ：デフォルトの名無しさん：2005/09/02(金) 23:02:33

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

601 ：デフォルトの名無しさん：2005/09/03(土) 05:53:01

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

602 ：デフォルトの名無しさん：2005/09/03(土) 05:58:30

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

603 ：デフォルトの名無しさん：2005/09/03(土) 08:46:58

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

604 ：デフォルトの名無しさん：2005/09/03(土) 09:54:13

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

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

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

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

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

605 ：デフォルトの名無しさん：2005/09/03(土) 10:22:17

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

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

606 ：デフォルトの名無しさん：2005/09/03(土) 13:31:09

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

607 ：デフォルトの名無しさん：2005/09/03(土) 13:33:37

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

608 ：デフォルトの名無しさん：2005/09/03(土) 13:38:50

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

609 ：デフォルトの名無しさん：2005/09/03(土) 14:06:23

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

610 ：デフォルトの名無しさん：2005/09/03(土) 16:39:20

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

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

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

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

611 ：デフォルトの名無しさん：2005/09/04(日) 01:20:51

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

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

612 ：デフォルトの名無しさん：2005/09/04(日) 07:48:46

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

613 ：デフォルトの名無しさん：2005/09/04(日) 07:50:36

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

はげわろす。

614 ：デフォルトの名無しさん：2005/09/04(日) 21:19:24

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

615 ：デフォルトの名無しさん：2005/09/06(火) 00:40:12

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

616 ：デフォルトの名無しさん：2005/10/10(月) 02:51:50

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

617 ：デフォルトの名無しさん：2005/10/10(月) 09:15:32

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

618 ：デフォルトの名無しさん：2005/10/10(月) 09:21:41

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

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

619 ：伝説の新人：2005/10/10(月) 09:33:19

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

620 ：デフォルトの名無しさん：2005/10/10(月) 09:43:25

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

621 ：デフォルトの名無しさん：2005/10/10(月) 10:25:38

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

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

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

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

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

622 ：デフォルトの名無しさん：2005/10/10(月) 15:20:57

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

623 ：デフォルトの名無しさん：2005/10/10(月) 17:07:42

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

624 ：デフォルトの名無しさん：2005/10/10(月) 19:06:34

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

625 ：デフォルトの名無しさん：2005/10/10(月) 20:00:13

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

626 ：デフォルトの名無しさん：2005/10/10(月) 20:09:34

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

627 ：デフォルトの名無しさん：2005/10/10(月) 20:42:26

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

628 ：デフォルトの名無しさん：2005/10/10(月) 21:53:11

何こいつ？エラそーに。

629 ：デフォルトの名無しさん：2005/10/11(火) 00:01:08

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

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

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

630 ：デフォルトの名無しさん：2005/10/11(火) 00:39:18

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

631 ：デフォルトの名無しさん：2005/10/11(火) 00:42:22

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

632 ：デフォルトの名無しさん：2005/10/11(火) 12:12:35

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

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

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

633 ：デフォルトの名無しさん：2005/10/11(火) 17:31:58

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

634 ：629：2005/10/12(水) 02:49:08

>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
が良いような気もするけど……

635 ：デフォルトの名無しさん：2005/10/12(水) 09:25:57

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

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

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

636 ：デフォルトの名無しさん：2005/10/12(水) 10:21:58

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

637 ：デフォルトの名無しさん：2005/10/12(水) 12:31:31

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

638 ：デフォルトの名無しさん：2005/10/12(水) 12:55:53

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

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

639 ：デフォルトの名無しさん：2005/10/12(水) 16:25:31

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

640 ：デフォルトの名無しさん：2005/10/12(水) 19:33:55

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

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

641 ：デフォルトの名無しさん：2005/10/13(木) 00:04:55

あたかまら

642 ：629：2005/10/13(木) 01:54:06

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

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

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

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

643 ：639：2005/10/13(木) 02:16:25

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

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

644 ：デフォルトの名無しさん：2005/10/13(木) 02:20:32

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

645 ：デフォルトの名無しさん：2005/10/13(木) 02:22:00

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

646 ：デフォルトの名無しさん：2005/10/13(木) 02:46:14

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

647 ：629：2005/10/13(木) 02:57:01

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

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

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

648 ：639：2005/10/13(木) 07:46:42

>>646
kwsk

649 ：デフォルトの名無しさん：2005/10/13(木) 10:00:39

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

650 ：デフォルトの名無しさん：2005/10/19(水) 22:28:28

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

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

651 ：デフォルトの名無しさん：2005/10/19(水) 22:29:55

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

652 ：デフォルトの名無しさん：2005/10/19(水) 22:50:38

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

653 ：デフォルトの名無しさん：2005/10/19(水) 22:57:20

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

654 ：デフォルトの名無しさん：2005/10/19(水) 22:59:52

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

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

655 ：デフォルトの名無しさん：2005/10/19(水) 23:10:42

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

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

656 ：デフォルトの名無しさん：2005/10/19(水) 23:13:22

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

657 ：デフォルトの名無しさん：2005/10/19(水) 23:18:51

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

658 ：デフォルトの名無しさん：2005/10/19(水) 23:24:24

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

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

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

>>656
652=655

659 ：デフォルトの名無しさん：2005/10/19(水) 23:26:11

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

660 ：デフォルトの名無しさん：2005/10/19(水) 23:34:56

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

661 ：デフォルトの名無しさん：2005/10/19(水) 23:36:20

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

662 ：デフォルトの名無しさん：2005/10/19(水) 23:38:09

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

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

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

663 ：デフォルトの名無しさん：2005/10/19(水) 23:39:17

>>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
具体的にいってよ。意味ねーじゃん。

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

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

664 ：デフォルトの名無しさん：2005/10/19(水) 23:41:39

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

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

665 ：デフォルトの名無しさん：2005/10/19(水) 23:42:09

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

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

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

666 ：デフォルトの名無しさん：2005/10/19(水) 23:43:03

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

667 ：デフォルトの名無しさん：2005/10/19(水) 23:45:29

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

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

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

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

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

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

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

668 ：デフォルトの名無しさん：2005/10/19(水) 23:47:29

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

669 ：６５９：2005/10/19(水) 23:48:16

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

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

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

670 ：デフォルトの名無しさん：2005/10/19(水) 23:49:43

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

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

671 ：デフォルトの名無しさん：2005/10/19(水) 23:51:06

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

672 ：デフォルトの名無しさん：2005/10/19(水) 23:55:09

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

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

673 ：デフォルトの名無しさん：2005/10/19(水) 23:57:35

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

674 ：６５９：2005/10/19(水) 23:58:05

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

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

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

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

675 ：デフォルトの名無しさん：2005/10/19(水) 23:59:42

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

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

676 ：デフォルトの名無しさん：2005/10/20(木) 00:02:47

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

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

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

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

677 ：デフォルトの名無しさん：2005/10/20(木) 00:06:55

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

678 ：デフォルトの名無しさん：2005/10/20(木) 00:08:32

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

679 ：デフォルトの名無しさん：2005/10/20(木) 00:09:12

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

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

680 ：デフォルトの名無しさん：2005/10/20(木) 00:11:00

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

681 ：６５９：2005/10/20(木) 00:13:17

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

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

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

682 ：デフォルトの名無しさん：2005/10/20(木) 00:13:24

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

683 ：デフォルトの名無しさん：2005/10/20(木) 00:21:24

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

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

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

684 ：デフォルトの名無しさん：2005/10/20(木) 00:25:13

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

685 ：デフォルトの名無しさん：2005/10/20(木) 00:31:29

（続き）

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

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

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

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

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

686 ：デフォルトの名無しさん：2005/10/20(木) 00:33:05

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

687 ：デフォルトの名無しさん：2005/10/20(木) 00:35:22

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

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

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

688 ：デフォルトの名無しさん：2005/10/20(木) 00:38:30

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

689 ：デフォルトの名無しさん：2005/10/20(木) 00:38:59

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

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

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

690 ：６５９：2005/10/20(木) 00:42:29

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

691 ：デフォルトの名無しさん：2005/10/20(木) 00:42:33

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

692 ：６５９：2005/10/20(木) 00:44:30

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

693 ：デフォルトの名無しさん：2005/10/20(木) 00:45:21

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

694 ：デフォルトの名無しさん：2005/10/20(木) 00:45:21

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

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

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

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

695 ：デフォルトの名無しさん：2005/10/20(木) 00:50:40

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

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

696 ：デフォルトの名無しさん：2005/10/20(木) 00:54:08

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

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

697 ：デフォルトの名無しさん：2005/10/20(木) 00:56:22

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

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

698 ：デフォルトの名無しさん：2005/10/20(木) 00:59:06

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

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

699 ：デフォルトの名無しさん：2005/10/20(木) 00:59:33

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

700 ：デフォルトの名無しさん：2005/10/20(木) 01:00:07

志村、Strategyパターン。

701 ：デフォルトの名無しさん：2005/10/20(木) 01:03:12

わろたｗ

702 ：デフォルトの名無しさん：2005/10/20(木) 01:03:53

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

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

703 ：デフォルトの名無しさん：2005/10/20(木) 01:07:46

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

704 ：デフォルトの名無しさん：2005/10/20(木) 01:08:01

>>697

class Missile { ... }

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

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

705 ：デフォルトの名無しさん：2005/10/20(木) 01:09:37

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

706 ：デフォルトの名無しさん：2005/10/20(木) 01:18:39

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

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

どうでもいいけど。ｗ

707 ：デフォルトの名無しさん：2005/10/20(木) 01:19:02

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

708 ：デフォルトの名無しさん：2005/10/20(木) 01:26:00

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

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

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

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

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

709 ：デフォルトの名無しさん：2005/10/20(木) 01:26:28

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

710 ：デフォルトの名無しさん：2005/10/20(木) 01:27:18

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

711 ：デフォルトの名無しさん：2005/10/20(木) 01:29:43

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

712 ：デフォルトの名無しさん：2005/10/20(木) 01:31:49

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

713 ：デフォルトの名無しさん：2005/10/20(木) 01:32:23

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

714 ：デフォルトの名無しさん：2005/10/20(木) 01:32:27

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

715 ：デフォルトの名無しさん：2005/10/20(木) 01:34:58

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

716 ：デフォルトの名無しさん：2005/10/20(木) 01:34:59

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

717 ：704：2005/10/20(木) 01:36:28

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

718 ：６５９：2005/10/20(木) 01:37:35

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

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

719 ：デフォルトの名無しさん：2005/10/20(木) 01:38:29

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

720 ：デフォルトの名無しさん：2005/10/20(木) 01:39:57

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

721 ：デフォルトの名無しさん：2005/10/20(木) 01:41:02

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

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

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

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

722 ：デフォルトの名無しさん：2005/10/20(木) 01:41:20

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

723 ：デフォルトの名無しさん：2005/10/20(木) 01:43:53

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

724 ：デフォルトの名無しさん：2005/10/20(木) 01:44:29

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

725 ：デフォルトの名無しさん：2005/10/20(木) 01:47:04

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

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

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

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

726 ：デフォルトの名無しさん：2005/10/20(木) 01:49:19

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

727 ：デフォルトの名無しさん：2005/10/20(木) 01:50:15

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

728 ：デフォルトの名無しさん：2005/10/20(木) 01:52:07

なんか全然理解してもらえてない気がするけど、
Strategyにcontextを渡す仕様にすれば、
setDataをすべてのオブジェクトの移動前に
セットする必要はないっしょ。
しかもホーミングミサイルのサーチアルゴリズムは
共通なのでStrategyはsingletonで良い。
と言うことはcontextのセットは、すべてのオブジェクトの
移動の始まりに一回セットすれば良いだけじゃね？
間違ってる？自然な設計だと思うが。
新しいアルゴリズムが必要なら新しいstrategyクラスを
派生するだけでしょ。

729 ：デフォルトの名無しさん：2005/10/20(木) 01:56:28

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

そりゃ設計者が分析してだろ

730 ：６５９：2005/10/20(木) 01:59:09

>>725
＞誰が何をどうやってこれは「例外」だと認識できるん？

ちゃんとした答えは無いんじゃないかなぁ。
自分が綺麗じゃないと思ったら、その時点で例外としちゃって良いと思うよ。それが設計って奴なんだと思う。

自然にまとめられる物は、類似点の多いオブジェクトになってるから、polymorphism も自然に行えるでしょ？
「これは１つにまとめられないなー」って思ったら、そのオブジェクトは、その時点で他のオブジェクトとは類似点が少ないことになるし。

731 ：デフォルトの名無しさん：2005/10/20(木) 02:01:06

>>728
>共通なのでStrategyはsingletonで良い
だから、そうやってグローバル使うしｗ
駄目だって、目的を見失っちゃ。

煽るつもりでいうわけじゃないけど、
ポリモーフィズムを強引に実装しようとしなければそんなことする必要ないでしょ？
これは明らかっしょ。
ホーミング単体でみれば動作関数の引数にターゲットがついてる形が一番綺麗でしょ。
まず、原点に戻ろうよ。

って、俺もそれを考えたときに脳内で自問自答したｗ

つーか、これ以上は平行線でしょ。
俺のいいたいことはだいたい言ったし、これで納得いかない人はずっとこのままっしょ。
俺もしばらく、どうやんだ？これは間違ってるのか？あーでもキタネェし・・・って考えてたからｗ

っちゅーわけで、今夜はとりあえずお開きな。
つーか、俺は、もう寝るｗ

732 ：デフォルトの名無しさん：2005/10/20(木) 02:02:51

つかね。
いい解決方法があれば、聞いてみたいってのも本音なのよ。
ただ、その解決方法はホーミングクラスをいじることでは無い気がするんだよね。
ってのが俺の考え。

733 ：デフォルトの名無しさん：2005/10/20(木) 02:05:02

自分の知能の低さに気付かないで講釈垂れる奴を見かけると
ほんとストレス溜まるな。あーあ、胸糞悪りぃ。

734 ：デフォルトの名無しさん：2005/10/20(木) 02:06:14

アルゴリズムは共通なんだからSingletonで良いんだよ。
Strategyのsingletonはアルゴリズムを動的に取り替えられる
柔軟さがもたらされるので、かえってプログラムの保守が
容易になる。
いわゆるグローバル変数の保守しにくさとは次元が違う。

735 ：デフォルトの名無しさん：2005/10/20(木) 02:09:44

＞ホーミング単体でみれば動作関数の引数にターゲットがついてる形が一番綺麗
でもこれってホーミングミサイルとふつうのミサイルの区別はIDによるswitch
でしょう？
汚いし、アルゴリズムが増えるたびに条件分岐を増やさなきゃならない。
保守がしにくい。

736 ：デフォルトの名無しさん：2005/10/20(木) 02:12:33

>>734
そもそもアルゴリズムは共通じゃないかもしれないよ？

>>735
ホーミングミサイルを、ボスとして扱うのはどうだろうか。

自分の思ったとおりに設計すれば良いと思う。
ただ、選択肢は多く考えておいた方が良いと思うけどね。

737 ：デフォルトの名無しさん：2005/10/20(木) 02:13:28

グローバル変数ってそこまで毛嫌いするほど使っちゃいけないものなの？

738 ：デフォルトの名無しさん：2005/10/20(木) 02:16:27

>>736
共通じゃないからStrategyにしてるんだが。
アルゴリズム一つに対して一つのStrategyインスタンスが
対応するわけで。

＞ホーミングミサイルを、ボスとして扱うのはどうだろうか。
いみがわかんね。
それこそ、汚い設計じゃないの？

739 ：デフォルトの名無しさん：2005/10/20(木) 02:18:37

>>738
ごめん。ザコ敵の方が分かりやすかったか。

740 ：デフォルトの名無しさん：2005/10/20(木) 02:19:45

>>737
グローバル変数が保守しにくいのは、どこかでグローバル変数の中身が
書き換えられるという副作用がプログラムに影響をあたえるからだよ。
Strategyのインスタンスは生成されてから中身のアルゴリズムが書き換
えられる事はない。（別のStrategyインスタンスに置き換えるだけだから）

741 ：デフォルトの名無しさん：2005/10/20(木) 02:20:17

小学生が意味も解らず適当に用語使って喋ってる感じのスレだな。

742 ：デフォルトの名無しさん：2005/10/20(木) 02:21:43

>>739
Strategyを推し進めると敵味方のオブジェクトも一括して
扱えるかも。

743 ：デフォルトの名無しさん：2005/10/20(木) 02:23:00

>>738
＞共通じゃないからStrategyにしてるんだが
ん～。strategy にしろ、polymorphism で実装する以上、アルゴリズムに何らかの共通点は有るでしょ？
最低でも関数の引数と戻り値は同じじゃなきゃいけない。

んで、もしこれらが異なるものだったら、strategy は使えないよね？って話です。

744 ：デフォルトの名無しさん：2005/10/20(木) 02:26:07

>>742
最終的には、画面上のオブジェクトは全て ScreenObject(仮) としてまとめることが出来る。
自機、ボス、ザコ、数種類の弾から背景まで全部。

果たして、そこまで１つにまとめる必要があるのか？って話だよ。
できる事は分かってるんだけど、それによって問題が複雑になっちゃったら本末転倒だよ。

745 ：デフォルトの名無しさん：2005/10/20(木) 02:26:50

>>743
さっきからストラテジーの話をしている人は引数も戻り値も変更しないことを前提にしている気がするのだが。

746 ：デフォルトの名無しさん：2005/10/20(木) 02:27:00

>>743
そのオブジェクトの次の座標を取得するメソッドのインタフェースは
同じになると思いますが？
contextはコンストラクタで一回与えればOKかもね。

747 ：デフォルトの名無しさん：2005/10/20(木) 02:28:43

>>745
そです。
少なくともゲーム中のオブジェクトの移動メソッドは
共通のインターフェースで済むはずだけど。

748 ：デフォルトの名無しさん：2005/10/20(木) 02:31:42

>660の答は 659が >669 >681あたりでまとめている内容かと思うけど……
『名前』つうと解りづらいけど、具体的な例は「ソースコードの記述」な。

>708
>直接、動かす関数に引数をつけるはずだ。
とすると、そこの記述は
1. HomingMissile専用のソースコードになる
2. Missileの関数を実行するときに、余計な引数を指定する必要がある
のどっちかになって、動かす関数を呼び出すソースコードの記述が
HomingMissileやMissileの定義に依存しちまうわけですな。

1. だと、似たようなコードをHomingMissileとMissile用にそれぞれ用意する
必要が出て来て面倒だし、2. だとMissileを動かすときにわざわざ要らない
引数を指定する必要があって面倒ですな。
多態性があれば簡単に処理できるけど、わざわざこんなことするの？

749 ：デフォルトの名無しさん：2005/10/20(木) 02:32:39

>>746
ん～。ScreenObject(仮) なら、getPoint() は共通化できるね。
んじゃ、Move 系のメソッドはどうだろうか。今回のゴタゴタはこのあたりを問題にしていると思うんだけど。

自機・ボス・弾・背景は、Move 系のメソッドを共通化する意味はあるのかな。

750 ：748：2005/10/20(木) 02:33:52

……おっと、2.だと多態性使用する前提ですな……無視してくだされ

751 ：デフォルトの名無しさん：2005/10/20(木) 02:37:08

>>749
だからmove系メソッドのアルゴリズムを取り替えるためにstrategyを
使うって話をしてるんだってば。
たとえばDemo画面でプレイヤー機が勝手に動いてるような場面も、
通常のゲームのルーチンと全く同じプログラムでプレイヤー機の
移動strategyを取り替えるだけになるじゃん。

752 ：デフォルトの名無しさん：2005/10/20(木) 02:37:16

１つだけ思ったんだけど、何でみんな『汎化』の方にだけ進もうとするのかなぁ。
『特化』は完全に無視なの？

753 ：デフォルトの名無しさん：2005/10/20(木) 02:40:12

>>752
オブジェクト指向は「特化」部分を切り離したり置き換えたりを
容易にする技術でしょ。
ハードコーディングを「特化」という訳ではない。

754 ：デフォルトの名無しさん：2005/10/20(木) 02:41:32

>>751
自機には、パッド等からの入力が伝わるよ。
ボスには、現在の自機座標が伝わるよ。

自機とボスの Move を共通化すると、両方のオブジェクトに両方の情報が伝わるね。
これは無駄じゃないのかな？って話。
構造化手法的に言うと、情報とオブジェクトの結合度が強くならないかな？って話。

755 ：デフォルトの名無しさん：2005/10/20(木) 02:45:00

>>752
頭真っ白になってんだよ。
ＯＯＰ＝何が何でもぽりもーふぃずむで実装って思考に陥ってんだろうな。

756 ：754：2005/10/20(木) 02:45:06

そういうことか。分かった分かった。いわゆる object.OnFrame() で移動させたいのな。納得。

757 ：デフォルトの名無しさん：2005/10/20(木) 02:46:19

>>754
パッドからの情報はstrategyの中にカプセル化できるでしょ。
ボス、自機に限らず、他のオブジェクトの位置情報が参照で
きないと当たり判定ができないでしょ。
で、その情報はオブジェクトのインスタンス変数に保持される
んでしょうから、オブジェクトを介して情報を取得するのは
結合を密にするとはいえないでしょ。
というか座標の取得自体が多態使うでしょ。

758 ：754：2005/10/20(木) 02:55:17

でも自機・ボス・弾・背景を共通化すると、自機との当たり判定に無駄が出るような気がします。
自機と自機の当たり判定なんて、まったく意味無いですし。

弾を生成する段階で自機への参照を保持するのも良いかもしれないけど、
それだと自機の「自機への当たり判定を求める」処理が無駄になる予感。
あるいは、これも OnFrame() の中に入れた方が良いのかなぁ……。

共通化しないほうが簡単になる部分は、共通化しないほうが良いんじゃないのかなぁと思う。
さっきから言ってるけど。

759 ：デフォルトの名無しさん：2005/10/20(木) 02:57:33

っていうかどんどん OnFrame() が巨大化していくｗ　助けてｗ

760 ：デフォルトの名無しさん：2005/10/20(木) 03:00:00

>>758
まあ当たり判定はよけいな話だったかも知れないが、
言いたいのはstrategyにゲーム中のcontextを与えれば
実際のゲーム中のオブジェクトごとに引数変えたり
しなくても済む。
どこまで共通化するかは設計者の考え方次第だが、
デモ画面の話のように柔軟さは保守や拡張の容易さ
を生むと思うけどね。
そろそろ寝るよ。

761 ：デフォルトの名無しさん：2005/10/20(木) 03:02:04

>>759
巨大化はしないと思うが。
strategyに共通の部分はstrategyの基底クラスに置いて、
特化された部分は派生クラスに書けばよいだけ。
あとは多態がうまくしてくれる。ww

762 ：デフォルトの名無しさん：2005/10/20(木) 03:03:49

あと座標の取得に多態は使わないの？
まさかグローバルな配列に置いてる
訳じゃないよね？

763 ：デフォルトの名無しさん：2005/10/20(木) 03:05:11

strategyとポリモフィズムって何が違うの？

764 ：デフォルトの名無しさん：2005/10/20(木) 03:07:02

もうお手上げ。
ググる様をお使いになって。寝る。

765 ：デフォルトの名無しさん：2005/10/20(木) 03:08:35

>>762
singleton

766 ：デフォルトの名無しさん：2005/10/20(木) 03:11:08

>>765
それすごく意味不明。まさにグローバル変数の代わりにsingleton
使ってるだけの意味不明な設計じゃん。
本来座標とかはオブジェクトが持つ属性でね？

767 ：デフォルトの名無しさん：2005/10/20(木) 03:12:18

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

722じゃないが、変わりに言わせてもらうと
本当に素晴らしい人、できる人ってのは「ゴチャゴチャ言わず
すぐさま実践、そして実現している」ってこった。
持っている技術を説明したり、ひけらかしたり
逆に説明を受ける気も無いわけ。
それだと掲示板には無用な存在　ってことになってしまうけどなｗ

768 ：763：2005/10/20(木) 03:13:27

聞いたタイミングが悪かったか。すんません。
何かスレ見に来たらあまり見覚えのない単語が飛び交って荒れてたから
ぐぐってみた結果の質問が>>763です(´･ω･)

769 ：デフォルトの名無しさん：2005/10/20(木) 03:13:54

変わりに→代わりに　だ。

770 ：デフォルトの名無しさん：2005/10/20(木) 03:28:36

もう最初と最後で同じ話題を議論してるのかもわからないのだけどとりあえず終わったの？

771 ：デフォルトの名無しさん：2005/10/20(木) 09:25:04

>>770
俺はいいたいこと言ったから、とりあえずはＯＫだよ。
後は、自分でやりたいように考えてもらうしかないっしょ。
その中でいい設計があるっていうなら出してもらえばいいし。
とりあえず、出てる中で俺が納得いくのは無いな（まあ、これも俺の独断だけど）。

ポリモに対してなんの疑いももたないで作ってた人は疑問持った人もいるでしょ？
つかえねーんだよ。これ。引数１個増えただけで破綻。
それを回避するのにまた破綻。
破綻の連鎖爆弾をプロジェクトに設置することになるから下手糞な人は使わないほうがいいよ。
また、プロジェクト進行中に設計に疑問なんか感じたら、かなりやばいしね。
小突いただけで簡単に揺らいじゃうような人やキッチリ納得できる
位置まで自分の中で完結してない人は使わないほうがいいよ。

ちなみに俺は>>732からこのレスの前まではレスつけてないからね。
案外、俺もただのキチガイじゃないっしょ？（笑）

772 ：デフォルトの名無しさん：2005/10/20(木) 10:02:57

ホーミングがどうこう言ってるから、次の対象を指定するObserverを用意するのはどうかと思った。

773 ：デフォルトの名無しさん：2005/10/20(木) 10:31:55

>>771
解決する方法はいくらでもあるけど、君のレベルじゃ微妙ってだけ。

下手糞な人は使わないほうがいいよってのは同意で、
C++でC++らしいコード書こうとすると慣れてない人はすぐ破綻する。ってのは
昔から言われ続けてるしな。

無理だと思うならCっぽく書いてけばいいんじゃない？
型変換保障されてるだけでもCよりマシだから。

言いたい事わからんでも無いがね。
型情報のデシリアライズが出来ないと、データドリブンと特化は相性悪いしな。

774 ：デフォルトの名無しさん：2005/10/20(木) 11:17:35

>>773
つまり、「そんなの解決できないのは、あんたのレベルが低いからだよ」っていいたいわけ？
ここまで議論進んでるんだから、ちょっとはましな設計出してからいいなよｗ
この解決方法を聞きたいと思ってるのはたぶん俺だけじゃないぜ。

775 ：デフォルトの名無しさん：2005/10/20(木) 11:33:54

>>774
もう結論でてるよ。
理解できないおまえがバカだって。

776 ：デフォルトの名無しさん：2005/10/20(木) 11:55:54

>>775
グローバル変数使ったようなのとかシングルトンの変なのしかでてないけど？ｗ

777 ：デフォルトの名無しさん：2005/10/20(木) 12:20:35

俺だったら、自機を扱う Player、敵全般を扱う Enemy、背景等を扱う Background の３つの Facade を作るよ。
Enemy はさらにボスと弾、Background は背景とスコア表示とかを扱う。
つまり全体を階層構造にするんだな。

弾どうしは strategy を使うけど、弾と自機を1つにまとめたりはしないかな。
これが、俺の中では一番簡単だと思う。

778 ：デフォルトの名無しさん：2005/10/20(木) 12:52:41

普通のミサイルとホーミングミサイルには、
「目」など外部との通信手段があるかないかと言う決定的な違いがあるわけで。

ならばこの能力（たとえば視覚）をインターフェイスとして切り出せば、
他の、この能力を持つもの（自機を狙って弾を撃つ敵など）と共通化ができて、
処理をまとめることができる。

779 ：デフォルトの名無しさん：2005/10/20(木) 13:42:16

>>777
それはわかりづらいよー
直感的な設計にしようぜｗ

>>778
なんかそれ、ホーミングミサイルの中にミサイルと目が内包されてる設計しか見えてこねぇよ。
なんか別にしちまうのってチガクネ？

そろそろ会議なんので離脱。

780 ：デフォルトの名無しさん：2005/10/20(木) 13:56:17

実機と敵はｵﾌﾞｻﾞｰﾊﾞで管理して各々が更新した時関連付けされたﾘｽﾅに自動通知されるようにしたいな

781 ：デフォルトの名無しさん：2005/10/20(木) 14:00:51

780続き
で、振る舞いとかｱｸｼｮﾝなどのﾛｼﾞｯｸはｺﾏﾝﾄﾞで実装し、必要な情報はｵﾌﾞｻﾞﾊﾞから間接的にとる
ﾓｯｸてすとも簡単

782 ：デフォルトの名無しさん：2005/10/20(木) 14:05:02

シューティングゲーム製作技術議論スレはここですか？

783 ：デフォルトの名無しさん：2005/10/20(木) 14:28:41

おまいらオブジェクト指向で縦シューつくろうぜpart1

784 ：777：2005/10/20(木) 16:21:08

>>779
え～。自機の当たり判定を rect とすると、当たり判定は enemies.hittest(rect); で出せるじゃん。
オブジェクトグループにそれぞれマネージャクラスを作るのが、直感的に見えないのか？

785 ：デフォルトの名無しさん：2005/10/20(木) 18:15:57

>>784
いや、わかりづれーのはここ↓だよ。
>Enemy はさらにボスと弾、Background は背景とスコア表示とかを扱う。
ぶっちゃけセンスわりぃよ。
まとめる必要ないんじゃない？

786 ：777：2005/10/20(木) 18:18:23

>>785
悪い。自機でも敵でもない、ゲームに直接の影響の無い (無いってことは無いんだが) オブジェクト群をまとめたつもりだった。

まとめる必要がなくても良いっス。
まとめられなかったら Background と Score とかに分けるから。

787 ：778：2005/10/21(金) 00:29:34

>779
>なんかそれ、ホーミングミサイルの中にミサイルと目が内包されてる設計しか見えてこねぇよ。
>なんか別にしちまうのってチガクネ？
具体的に何がご不満なのですか？

788 ：デフォルトの名無しさん：2005/10/21(金) 00:45:51

>>787
別にわけたところでなんの解決にもなってないよ。

789 ：デフォルトの名無しさん：2005/10/21(金) 00:47:42

>>774
＞つまり、「そんなの解決できないのは、あんたのレベルが低いからだよ」っていいたいわけ？

まさにその通り。
自分でも解ってるみたいじゃん。
スカスカの脳みそで訳の解らん分類して勝手に自爆してるだけ。
ＯＯＰの大事な要素の一つは分類をする為の分析能力なんだよ。
小学生の頃やった知能指数テストにあったでしょ？
複数の図柄見せられてチーム分けしたり仲間はずれ探したりするやつ。
あれだよ。あれ。お前にはその能力が生まれながらに欠如してんだよ。

790 ：デフォルトの名無しさん：2005/10/21(金) 00:53:03

近頃の若いもんは、背景画像に当たり判定だとか、スコア表示が弾を発射するとか、
奇抜な発想が盛り沢山でオジサン着いていけないよ。ヽ(´ー｀)ノ

791 ：デフォルトの名無しさん：2005/10/21(金) 00:58:09

っていうか、どこかで見た流れだと思ったら……
ttp://pc8.2ch.net/test/read.cgi/prog/1122318533/l50
の「リスコフの置換原則」あたりと似た雰囲気を感じる。

792 ：デフォルトの名無しさん：2005/10/21(金) 01:05:20

>771
>つかえねーんだよ。これ。引数１個増えただけで破綻。

「引数１個増えただけ」とかいうセンスがわからん……引数の数が違えば扱う情報量が
変わるんだけどね……

まあ、「明示的なメソッド群による引数の置き換え」「オブジェクトそのものの受け渡し」
「引数オブジェクトの導入」ぐらいは調べといたら？重宝するよ

793 ：デフォルトの名無しさん：2005/10/21(金) 01:09:02

＞案外、俺もただのキチガイじゃないっしょ？（笑）
救いがたい基地外だということはわかった。

794 ：773：2005/10/21(金) 01:18:54

>>774
君以外の人は多分自己解決出来ると思うよ。
試しにSTGでも作ってみるといい。

C++等、不満が出てくるのは悪い事じゃないが、
やっても無駄だと思った時点で終了だな。

OOPというより、設計そのものに向いてない。
OOPは設計を縛るものではなくて、手助けするものという事を理解していない。
問題点が出るのは当たり前。より良いものにすれば良いだけ。

それが駄目だと言うなら、ずっと使い捨てコード書き続ければいい。
本人だけはそれが分かり易いと思ってるんだろう。

シンプルで判り易い、汎用性があるってのと、ハードコードの使い捨てコードだらけ、何もシステム化出来てない。
は似てるようで全く別物。

795 ：デフォルトの名無しさん：2005/10/21(金) 01:25:45

便利だから都合が良いからな視点で発想する事が多々見られますが理にかなった設計をしたいですよね
叩かれている方もおられますが一人では勉強しにくい分野と思われますので謙虚に知識を共有しあえたら有意義ですよね

796 ：デフォルトの名無しさん：2005/10/21(金) 01:26:36

( ´_ゝ｀)フーン

797 ：デフォルトの名無しさん：2005/10/21(金) 02:06:01

不思議でしょ？
これでも煽ってる方々は
はじめポリモーフィズムはオブジェクト指向に必須。以上。
みたいな煽り方してたんですよｗ
人と話はしてみるもんですよね。
結局、なんの解決策も示せないまま、ここまで無意味に煽ってこられたわけです。

ポリモーフィズムを使った時点でグローバル変数と
似たような構造のものが必要になるのはわからないんですかねぇ・・・ｗ
この構造で引数が増えるってでかいっしょ？
でも、ポリモーフィズムってのは、この程度の変更で大きな変更が必要となる組み方でもあるわけですよ。

正直、俺は自分のオブジェクト指向に絶対の自信をもってるよ。
君等程度の実力じゃ絶対に俺の域には到達できない。
理由聞いてみたい？

798 ：デフォルトの名無しさん：2005/10/21(金) 02:09:40

>>797
いや、別に聞きたくない。
つーか、糞して寝てくれ。

799 ：デフォルトの名無しさん：2005/10/21(金) 02:20:29

どうも精神やられてるっぽいな。
俺の通勤途中、道端でこの世の終わりみたいな顔して
腕時計見ながらギギギギ・・と喚いているスーツの若い
あんちゃんをよく見かけるんだが、こいつじゃないの？

800 ：792：2005/10/21(金) 02:31:21

>797
>この構造で引数が増えるってでかいっしょ？

だから、（多くの言語では）引数の数が変わればメソッドの意味も変わるんだって。
受け取る情報量（次数？）が変わるんだから。

まあ、引数の数が違っても同じメソッドとして処理できる言語もあったと思うけどね。

あと、C++なんかだと「引数オブジェクトの導入」を行えば引数の数の問題は
回避できるよ。

801 ：デフォルトの名無しさん：2005/10/21(金) 03:12:49

>>797
＞正直、俺は自分のオブジェクト指向に絶対の自信をもってるよ。

はたで見ていて思うのは、そもそもの問題はこれかな、と。

797 の絶対だと考えている「オブジェクト指向」は、普通の人の考える
オブジェクト指向とは違うんだよ。たぶんそれは（手法としての）抽象
データ型だ。で、普通の人はそれに継承とポリモを足したものを（797
的には不要なものだから“引いた”？）ものをオブジェクト指向と呼んで
いるわけ。少なくともストラウストラップはそう定義して、多くの教科書は
これを暗黙の了解としている。それなのに、オブジェクト指向にポリモは
無用とか言うから、おかしな反発を招いとるんじゃないかと。

802 ：デフォルトの名無しさん：2005/10/21(金) 03:50:20

グローバル変数とシングルトンじゃ雲泥の差があるし、
引数の追加とかみんな過去に通ってきた道。とっくに解決出来てるし。

タスクを敵、さらにボス、弾等に分けて管理する事で、便利に判りやすくなる事はあっても、
デメリットなどないし。（基本的なタスク管理は当然大元がする）

これらで不満が出る事自体、「自分はまだまだ未熟です。」と言い回ってる事にしかならん。
こいつがどんなものを設計したかは興味あるな。どうせろくなもんじゃないだろうが。

803 ：デフォルトの名無しさん：2005/10/21(金) 15:10:40

strategy と singleton の組み合わせは、グローバル変数というよりはグローバル関数だろう。
どうしても singleton が嫌なら、しなくてもすむ実装も出来るし。

804 ：デフォルトの名無しさん：2005/10/21(金) 16:33:49

>>803
まともな実装としては引数で渡すぐらいしか残って無いな。
メンバ変数に保持しておくってのはやらんほうが賢明だよね。

805 ：デフォルトの名無しさん：2005/10/21(金) 16:44:29

singletonをグローバル変数と同じで使っちゃいけない
不自然な設計と思ってるのがそもそも勘違い。
（それならsingletonパターンなんてそもそもない）
グローバル変数がなぜダメなのか考えずに、
「グローバル変数は悪、よってsingletonも悪」
という思いこみを発揮しているだけだな。やれやれ。
それにstrategyを使う場合にsingletonにするのは
必須じゃない。（使わなくても同じ事ができる）
無駄なオブジェクトの生成を抑えるためにsingletonに
するのであってその辺がわかってない。
mutableとかimmutableとかたぶん意識したことが
ないんだろう。
つまり何にもわかってないど素人。

806 ：デフォルトの名無しさん：2005/10/21(金) 16:46:17

>>804をみるとそもそもstrategyパターンを
理解してないみたいだな。はぁ。

807 ：デフォルトの名無しさん：2005/10/21(金) 16:48:15

自機や敵機の座標もメンバ変数じゃなくて
引数で渡してるのか？
何のためにオブジェクト指向を使ってるんだ？

808 ：デフォルトの名無しさん：2005/10/21(金) 16:53:56

>>805-807
全然的外れなこといってるねｗ

809 ：デフォルトの名無しさん：2005/10/21(金) 16:54:56

うは。反論できずそれだけか。w

810 ：デフォルトの名無しさん：2005/10/21(金) 17:19:49

>>809
シングルトンなんて確実にグローバル変数or関数だし。
で、結局ポリモーフィズムなんて引数の数でもう使えなくなっちゃうでしょ？

こんな実装依存の糞概念いらねぇじゃん。
これがあやしいと思えない奴ってのは感性腐ってんだよ。

まずね。こういう奴等と俺と合わない理由ってのは根本にあるんだよ。
お前等はオブジェクト指向を理解してない。

そもそも、俺と話す前はオブジェクト指向にポリモーフィズムは必須とか
理由も説明できないくせに言ってたじゃん。
ここでもう自分の知識を疑えよ。俺の言うことを強引に否定できるほど頭よく無いでしょｗ
で、結局、ポリモーフィズムは後からできたものだってわかってから静かになったけど。
馬鹿なんだから、人の話よくきけよｗ

811 ：デフォルトの名無しさん：2005/10/21(金) 17:26:23

>>810
> そもそも、俺と話す前はオブジェクト指向にポリモーフィズムは必須とか
> 理由も説明できないくせに言ってたじゃん。
どこら辺だ？レス番で示してくれ。

812 ：デフォルトの名無しさん：2005/10/21(金) 17:28:56

>>811
途中から入ってきた人は過去ログ読んでね。

813 ：デフォルトの名無しさん：2005/10/21(金) 17:30:04

うはwww
グローバル変数とグローバル関数は同じモノなのか？
アホすぎ。
「副作用」が悪なんだよ。
副作用の起こらないグローバル変数は「定数」だし、
副作用のないグローバル関数はいつでも安全に使えるんだよ。w
自機と敵機のオブジェクトから座標やID、残HPなどの情報を
取得するために多態は使わないの？
バカじゃない？www

814 ：デフォルトの名無しさん：2005/10/21(金) 17:31:20

>>812
最初からいたわけだが。
要するに、具体的に示すと自分の嘘がばれるから答えられないのね。

815 ：デフォルトの名無しさん：2005/10/21(金) 17:32:43

オブジェクト指向がわかってると豪語する810の設計は
オブジェクトの構造体からIDを取得してswitch caseで
分岐するモノだった！

そんな気がする。www

816 ：デフォルトの名無しさん：2005/10/21(金) 17:40:07

>>810
というよりお前のオブジェクト指向とその他の人間のオブジェクト指向が別物なのだから、
そういう結論になるのは至極当然のこと。

817 ：デフォルトの名無しさん：2005/10/21(金) 17:41:50

>>813
グローバル変数や関数なんて使ってる馬鹿はこんなとここなくていいんだよｗ
一体、いつから言われてることかわかってるのか、
いまだにグローバル変数や関数を使わない組み方すら知らないで恥ずかしくないのか？
ポリモーフィズムやるためにグローバル云々が出てきてしまうような設計なら、
まず、設計を見直すのが先だろ。
素で頭おかしいだろｗ

818 ：デフォルトの名無しさん：2005/10/21(金) 17:43:15

「感性が腐ってる」
そういう彼が推す「オブジェクト指向の本質」はきっと

「マルチプルインスタンス」

前橋のページの誤読者でないことを祈る。

819 ：デフォルトの名無しさん：2005/10/21(金) 17:44:36

>>817
中身を理解してから書き込もうね。ボク。
なぜグローバル変数はつかっちゃいけないのかな？
しゅくだいをきちんとすませようね？www

820 ：デフォルトの名無しさん：2005/10/21(金) 17:45:45

>>817
お前面白いからｺﾃﾊﾝにしなよ。

821 ：デフォルトの名無しさん：2005/10/21(金) 17:47:33

ボクのつかったきょうかしょにはぐろーばるへんすうは
つかっちゃいけないってかいてあるんだ。
だからしんぐるとんもつかっちゃいけないんだ。
じょうたいはぜんぶひきすうでわたすんだ。
それがいちばんきれいなんだ！

822 ：デフォルトの名無しさん：2005/10/21(金) 17:48:33

>>819
さすがにそんな石器時代にまで戻って議論なんてしないよ（笑）
１人で悩んでろよｗカス野郎ｗ

823 ：デフォルトの名無しさん：2005/10/21(金) 17:49:35

どうでもいいから早くシューティングゲーム作ってくれよ

824 ：デフォルトの名無しさん：2005/10/21(金) 17:50:15

うはww
また中身なしレス。
ユー、コテハンにしちゃいなよ。

825 ：デフォルトの名無しさん：2005/10/21(金) 17:50:56

>>822
俺のレス無視すんなって。
何番から何番なの？

826 ：デフォルトの名無しさん：2005/10/21(金) 17:54:19

アホでしょ？
だいたい、グローバル変数とか関数とか使ってもＯＫ的な発言しちゃうし。
お前の設計の基準はなんなんだよｗ
回避しようと思わないのか？
どうして、グローバル変数や関数の使用回避がポリモーフィズムの実現より、
優先度が下になっちゃうんだ？

おかしいと思えよｗ
設計がどうあるべきかってわかってないだろｗ
俺の言ってること間違ってるか？

827 ：デフォルトの名無しさん：2005/10/21(金) 17:56:30

間違ってる。
設計の基準が教条主義的だ。
中身を理解してない。
仏作って魂入れず。
だからデザパタも理解できない。

828 ：デフォルトの名無しさん：2005/10/21(金) 18:01:49

>>827
じゃあ、この↓辺とかどう？
>どうして、グローバル変数や関数の使用回避がポリモーフィズムの実現より、
>優先度が下になっちゃうんだ？
明らかにおかしいでしょ？
こういう状況になっちゃうのって。
こういうのなんで駄目なの？って聞くまでもなく駄目でしょ。
こういうのさ、いちいち説明して、２ちゃんで会話できないよ。
で、説明しないと説明できないとかどうとか騒ぎ出す始末だし。

さすがにまともな思考回路もってない人とそんなに議論なんて続ける気ないってｗ
だって明らかにおかしいでしょ？
自分がやってることってどうよ？

829 ：デフォルトの名無しさん：2005/10/21(金) 18:06:09

>>828
どうでもいいから早くレス番を教えろ。

830 ：デフォルトの名無しさん：2005/10/21(金) 18:07:54

>>828
>>813をしっかり読めよ。
strategyはアルゴリズムをインスタンス化したもので、
副作用がない設計にするんだよ。（当然）
これはアルゴリズムに対応した関数を作るのと本質は変わらない。
副作用を利用するグローバル変数を使うのとは違うんだよ。w

831 ：デフォルトの名無しさん：2005/10/21(金) 18:11:47

DirectXスレから彼を誘導したものです。変なの連れて来てごめんなさい。

832 ：デフォルトの名無しさん：2005/10/21(金) 18:13:02

>>830
だから、お前は自分が馬鹿なのを直してこいよｗ

833 ：デフォルトの名無しさん：2005/10/21(金) 18:14:25

また中身無しか。コテハンにすれば？
ていうか、いじるの飽きてきた。ww

834 ：デフォルトの名無しさん：2005/10/21(金) 18:20:01

>>833
こんな↓意味不明で恥ずかしいこと言ってた仲間なのに飽きてきたも無いでしょう？

664 名前：デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 23:41:39
>>556はオブジェクト指向を少しも理解していない。以上。

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

ポリモーフィズムなんてオブジェクト指向を理解していない人間が
後付けでくっつけた糞機能だって理解できたの？

なにがどう、不可欠なのか教えてほしいよ＞ホラ吹き君達ｗ
始めにオブジェクト指向があって、その後に出来たものがオブジェクト指向に不可欠なわけないだろ。死ねよｗ
頭使ってよく考えてから、自信持てよｗ
全然レベル低くて話にならないｗ

835 ：デフォルトの名無しさん：2005/10/21(金) 18:20:02

>>830
＞strategyはアルゴリズムをインスタンス化したもので、副作用がない設計にするんだよ。（当然）
そうでもない。strategy でまとめたメソッドから属性を変更するのは良くやること。

836 ：デフォルトの名無しさん：2005/10/21(金) 18:20:41

実はもう途中から全然違う人が成りすまして煽ってるだけだったりして。

837 ：デフォルトの名無しさん：2005/10/21(金) 18:21:53

>>834
改良とか改善とか推敲って言葉もしかして知らない？

838 ：デフォルトの名無しさん：2005/10/21(金) 18:23:09

>>837
その説明で逃げるのは苦しくない？ｗ

839 ：デフォルトの名無しさん：2005/10/21(金) 18:24:01

>>834
君の中ではあのStroustrup氏がオブジェクト指向を理解していないほら吹きなわけだ。

で、レス番は？

840 ：デフォルトの名無しさん：2005/10/21(金) 18:25:28

>>835
ああ、もちろんそういう設計もある。
strategyをsingletonにする場合に、
複数のオブジェクトで使い回しても
副作用のない設計ということが言い
たかった。

841 ：デフォルトの名無しさん：2005/10/21(金) 18:25:43

>>838
今来たところで話の流れ自体はよくわからないのだが
とりあえず>837は>>834を読んだ感想

842 ：デフォルトの名無しさん：2005/10/21(金) 18:28:29

ちなみにww付きで煽ってたオイラは、
元のスレの流れがどうなのかは、
まるっきり知りません。
STGの設計の話じゃなかったの？

843 ：デフォルトの名無しさん：2005/10/21(金) 18:29:59

>>842
「オブジェクト指向のポリモーフィズムは悪か？」という話になって、
ついでに STG の設計の話が出てきた。

844 ：デフォルトの名無しさん：2005/10/21(金) 18:33:05

>>839
実はそう考えてる。
彼は実は理解できてなかっただろ。
名声に騙されガチだけど。

誰か疑問をもってもいいんじゃない？
ポリモにしたってこんな機能なんで付けたのか全く理解できないほどの駄目っぷりだし。
いままで、制限を付ける形で発展してきたのに、急にこの分野になってから、
お便利機能程度のくっだらない内容を声高々に叫ぶようになったし。
食いつなぐ＝名声を保つのに必死だったんじゃねーの？
ま、人間だしね。

845 ：デフォルトの名無しさん：2005/10/21(金) 18:35:02

http://ja.wikipedia.org/wiki/Simula

最初のオブジェクト指向言語Simulaには
動的束縛があったみたいだな。
動的束縛があれば多態できるだろ。違う？

846 ：デフォルトの名無しさん：2005/10/21(金) 18:35:23

>>844
申し訳ないが同感。
ストラウストラップ氏を責めるわけじゃないが、少なくとも氏はケイ氏の OO とは別の道を行ってるしな。

847 ：デフォルトの名無しさん：2005/10/21(金) 18:38:44

うーん。SimulaにもSmalltalkにも動的束縛は
あるよーな。C++は動的束縛なくてもプログラム
かけるけど、動的束縛できるし。
最初のオブジェクト指向に多態がないってのは、
どっからきてるんだ？

848 ：デフォルトの名無しさん：2005/10/21(金) 18:40:43

>>846
おお、このスレきて以来はじめての同意。ｸｿｳﾚｼｽ

849 ：６５９：2005/10/21(金) 18:41:15

>>847
ごめん。それ俺が >>681 で書いた。

そもそも、静的型付けの言語じゃないと多態が無いのよ。(多分)
多態はもともと型理論の用語だった気がする。

850 ：デフォルトの名無しさん：2005/10/21(金) 18:45:28

＞そもそも、静的型付けの言語じゃないと多態が無いのよ。(多分)
それには同意できないなぁ。
俺は動的束縛で呼び出されるモノはすべて多態だとおもうけど。
つまりオブジェクト指向とSimulaの関係のように、多態という概念は
あと広まっただけで、オブジェクト指向の最初から含まれていたように
考えるけど。

851 ：６５９：2005/10/21(金) 18:50:34

>>850
＞俺は動的束縛で呼び出されるモノはすべて多態だとおもうけど
ん～いやいや。『わざわざ多態と呼ぶ必要が無い』ってことです。

852 ：デフォルトの名無しさん：2005/10/21(金) 18:53:34

>>851
理解できなくもないけど、本来、多態と呼ばれるべきだった
モノをC++が「多態とは継承が必須な何か」に意味を狭めて
しまった希ガス。
メッセージングは本質的に多態を含んでいるというのは同意。

853 ：デフォルトの名無しさん：2005/10/21(金) 18:59:03

ん～。多態っていうか、この場合は inclusion polymorphism だよなぁ。
inclusion, parametric, overload, cast の４つの多態は、どれも型付けに関しての用語のような希ガス。

854 ：デフォルトの名無しさん：2005/10/21(金) 19:03:07

ていうかそもそもSimulaって型付きじゃないの？
Sumulaに多態はなかったの？

855 ：６５９：2005/10/21(金) 19:04:29

あれ？ Simula って型付きだったっけ？良く知らん。

856 ：デフォルトの名無しさん：2005/10/21(金) 19:11:29

あーごめん。Simula は静的型付けみたいだ。

857 ：デフォルトの名無しさん：2005/10/21(金) 19:15:14

それじゃ、やっぱりオブジェクト指向は最初から多態
（この場合inclusion polymorphism）を持ってた事に
ならない？

858 ：デフォルトの名無しさん：2005/10/21(金) 19:18:57

>>857
多態を持っていたって言うのは間違いないと思う。
ただ Simula の時点ではそういう用語は無かった可能性がある。

Simula の OO は、実は良く知らない。
継承とか、今ある OO に似ているものなんかな。

859 ：デフォルトの名無しさん：2005/10/21(金) 19:20:43

低レベルな質問で恐縮なんですが、多態なしにインタフェースの概念は実現できるのですか？
｢多態を使うべきでないときに多態を使うべきでない｣ではなく｢いかなる場合も多態は不要｣と言ってるように聞こえるんだが、
この人はいったいどういった設計をしているんだろう。
俺の頭が固いのかもしれないけど、多態なしにOOPするなんてちょっと考えられない。

860 ：デフォルトの名無しさん：2005/10/21(金) 19:20:55

Simulaの時点ではオブジェクト指向という言葉も
なかったしねぇ。
Simulaの詳細は俺も知らん。
Algol系という噂しか知らない。

861 ：デフォルトの名無しさん：2005/10/21(金) 19:23:49

>>859
＞多態なしにインタフェースの概念は実現できるのですか？

interface が java や C# のそれを指しているのなら、多態が無ければ意味が無い。
というか、動的型付け言語だと、そもそも interface が要らない。

interface は type system に必要だから作られた？

862 ：デフォルトの名無しさん：2005/10/21(金) 19:39:33

>>861
あ、なるほど。静的言語しか考えてなかった。やっぱり頭固いな漏れ。

しかし、静的言語で多態なしOOPってどうする気だ？そもそも可能なのか？
それとも多態不要の人は最初から動的言語を念頭に置いててC++なんか眼中にないのか？
だとしたらこのディスコミュニケーションの説明もつくかもしれないが。

863 ：デフォルトの名無しさん：2005/10/21(金) 19:40:15

ストラウストラップは 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

864 ：デフォルトの名無しさん：2005/10/21(金) 19:45:17

SIMULA のオブジェクトをヒントにケイが彼のオブジェクト指向
（メッセージング）と Smalltalk を作った。

SIMULA のクラスをヒントにリスコフは、彼女のオブジェクト指向
（あるいは、抽象データ型とも）と CLU を作った。

同様に、SIMULA のクラスをヒントにストラウストラップは、
彼のオブジェクト指向（カプセル化（抽象データ型）＋　継承と多態性）と
C++ を作った。

865 ：デフォルトの名無しさん：2005/10/21(金) 19:47:14

Simulaはinclusion polymorphismがあった。
Smalltalkもinclusion polymorphismできる。
いずれにしてもオブジェクト指向の最初から
inclusion polymorphism（いわゆる多態）は
あった。

・・・・・が結論？

866 ：デフォルトの名無しさん：2005/10/21(金) 19:48:54

以上の点について多態なんてオブジェクト指向にはいらねーと言っていた方、コメントをどうぞｗｗｗｗ

867 ：デフォルトの名無しさん：2005/10/21(金) 19:50:03

>>865
多態はあった。用語が無かった。

868 ：デフォルトの名無しさん：2005/10/21(金) 19:50:43

>>866
OK。すっきりした。

869 ：デフォルトの名無しさん：2005/10/21(金) 19:53:51

う～ん。確かにオブジェクト指向は多態が出来るのは分かるんだが……。
どうも多態は型検査の用語のような気がしてしっくりこない。

動的型付けでも多態になってるのは分かるけど、動的型付けで多態という言葉を聞いたことが無い
……のは俺だけ？

870 ：デフォルトの名無しさん：2005/10/21(金) 19:55:26

おまえだけだ。

871 ：デフォルトの名無しさん：2005/10/21(金) 19:58:05

>>869
ttp://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=Ruby%CD%D1%B8%EC%BD%B8
＞ポリモルフィズム
＞多態, Polymorphism
＞対象になるオブジェクトによって実際の操作が決定されること。
＞Rubyではレシーバのオブジェクトに応じてメソッドが選択される
＞ことによって実現されている。

動的型付き言語でも使ってるぞ。

872 ：デフォルトの名無しさん：2005/10/21(金) 19:58:54

ほー。じゃ俺だけか。すまんかった。

873 ：デフォルトの名無しさん：2005/10/21(金) 20:11:45

おまいらは本当に頭がよさそうですが一向にシューティングゲームを作ってくれません

874 ：デフォルトの名無しさん：2005/10/21(金) 20:34:04

そして「ポリモいらない君」がいなくなった

875 ：デフォルトの名無しさん：2005/10/21(金) 21:11:38

何をでっちあげてんだか。
はじめは多態なんて無かっただろ。
オブジェクト指向をちゃんと理解したけりゃ、継承と多態の解説を抜いた本を探せ。
あまりにも糞な本が増えすぎた。
オブジェクト指向入門といいつつ、継承や多態の話から始めるような糞本を回避しろ。

多態なしにOOPするなんてちょっと考えられないなんて、
私、オブジェクト指向理解できてませんでしたってことだろ？
簡単な話だｗ

876 ：デフォルトの名無しさん：2005/10/21(金) 21:17:37

前橋、乙。

877 ：デフォルトの名無しさん：2005/10/21(金) 21:20:19

前半と後半で分裂症な予感がする

878 ：デフォルトの名無しさん：2005/10/21(金) 21:22:27

今となっては多態と継承についての解説のない本の方が糞じゃねーかと思うのは俺だけでしょうか…。

879 ：デフォルトの名無しさん：2005/10/21(金) 21:26:11

多態と継承のないオブジェクト指向って・・・
Cで構造体に関数ポインタ入れただけのようなもんじゃん。

880 ：859：2005/10/21(金) 21:29:16

>>875
すいません、ちょっと確認させていただきたいんですが、
・静的言語について話しているんですよね？
・使いどころによらず、ポリモーフィズムという概念そのものが糞であり不必要だ、という主張ですよね？

881 ：デフォルトの名無しさん：2005/10/21(金) 21:37:00

それはちょっと頭、堅杉。

継承と多態性のないオブジェクト指向というのもある。言語で言えば
CLU の流れを汲んでいるもの。Ada とか。ちなみにオブジェクト指向
設計で有名なブーチは、Ada での経験から、その考え方を育んだ。

世の中には、クラスによって型を定義できて（カプセル化）、継承と
多態性があってはじめてオブジェクト指向…という人（これが主流）と、

クラス（か、それに準ずる言語機構）で型を定義できれば、それで
オブジェクト指向…という人と、

カプセル化とか継承とかは関係ない（邪魔しなければあってもいい）。
メッセージングができれば、それでオブジェクト指向…という人がいる。

882 ：デフォルトの名無しさん：2005/10/21(金) 21:43:07

ちょっとまった。CLUにはParametric Polymorphism が
あったんじゃねーの？

883 ：デフォルトの名無しさん：2005/10/21(金) 21:46:32

>>881
あってもオブジェクト指向に関する機能はCでもあんまり苦労せずに
実現できるようなものばっかりになるよ。

884 ：デフォルトの名無しさん：2005/10/21(金) 21:54:33

OOPL使わないとOOPではないのですか？

885 ：デフォルトの名無しさん：2005/10/21(金) 21:58:49

非OOPLでもOOPできるが非OOPLで実現容易な物こそが
OOPの本質とか言い出したらアタマがおかしい人になる。

886 ：デフォルトの名無しさん：2005/10/21(金) 22:16:50

そしてまた「ポリモいらない君」がいなくなった

887 ：デフォルトの名無しさん：2005/10/21(金) 22:24:02

>>885
>>881 の一番下に当てはまる人にとっては、非OOPL でも OO の実現は (それほど) 難しくないと思うんだが。

888 ：デフォルトの名無しさん：2005/10/21(金) 22:31:15

仮想関数とそのオーバーライドによって実現されるポリモの可否、についての話だったとしかヘタレの俺には解釈できんかったorz

889 ：デフォルトの名無しさん：2005/10/21(金) 22:32:32

>>887
ハッシュがあれば簡単だな。
配列のリニアサーチでも良いが。
継承が絡むと少し面倒だがそんなに難しいわけじゃない。
でも多態に類する機能がないのは話にならん。

890 ：デフォルトの名無しさん：2005/10/21(金) 22:34:58

最初のオブジェクト指向言語と目される言語は
何らかの形で多態を実現する方法を持っていた。
OK？皆の衆。

891 ：デフォルトの名無しさん：2005/10/21(金) 22:35:51

>>890
OK 兄者。

892 ：デフォルトの名無しさん：2005/10/21(金) 22:46:45

OOに実体はないよ。
脳を開けても胸を開けても心がみつからないのと同じ。
OOとか、確かにそこに存在しているという人の思いに
よって意味が与えられてるだけ。

893 ：デフォルトの名無しさん：2005/10/21(金) 23:29:33

>>882
パラメトリック多相は C++ のテンプレートみたいなもので、
それこそオブジェクト指向とは関係ないだろ。多相とつけば
なんでもいいのか？

894 ：デフォルトの名無しさん：2005/10/21(金) 23:47:09

多態, Polymorphism
対象になるオブジェクトによって実際の操作が決定されること。

Parametric PolymorphismもInclusion Polymorphismも
「対象になるオブジェクトによって実際の操作が決定」される
Polymorphism。

895 ：デフォルトの名無しさん：2005/10/21(金) 23:50:53

parametric polymorphism って多相型じゃなかったっけ？

896 ：デフォルトの名無しさん：2005/10/21(金) 23:51:26

あれはオブジェクト指向じゃなくてゼネリックプログラミングかな。

897 ：デフォルトの名無しさん：2005/10/22(土) 00:00:05

>>885
非 OOPL で実現可能かもしれないけれど、けっして“容易”ということは
ないと思うよ。

抽象データ型（もちろん、そのスーパセットである君らの OOP 。すなわち、
カプセル化（＝抽象データ型）＋継承と多態性…な OOP ）で大事なのは、
ユーザーが定義した型が、基本型と同じように便利かつ安全に運用できる
ことなわけで、これを C などの非 OOPL で容易に実現できるとは思えない。

898 ：デフォルトの名無しさん：2005/10/22(土) 00:01:54

シューティ(ry
なんでもない。

899 ：デフォルトの名無しさん：2005/10/22(土) 00:10:00

>>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) { /* ... */ }

900 ：デフォルトの名無しさん：2005/10/22(土) 00:12:29

>>894
だから、多態ならなんでもいいのかって。

そもそもはオーバーライド（継承）によって実現される多態性が不要か
どうかってはなしなんじゃないの？

で、世の中には継承や多態性はいらないっていう、手法があって
それも「オブジェクト指向」と呼ばれることがあるってんでいいじゃん。

901 ：デフォルトの名無しさん：2005/10/22(土) 00:15:28

ていうかCで情報隠蔽とかは、当たり前のイディオムの希ガス。
でも、それをもって「CはOOPLだ！」とか言い出したらアタマ
おかしい人になる。
さらに「多態は本質じゃない」とか言い出すのはもっとおかしい。

902 ：デフォルトの名無しさん：2005/10/22(土) 00:15:46

(･∀･)ﾐﾄﾒﾀｸﾅｲ！

903 ：899：2005/10/22(土) 00:17:44

>>901
＞Cで情報隠蔽とかは、当たり前のイディオムの希ガス
いやまあ、確かにそうなんだけどな。同意。

904 ：デフォルトの名無しさん：2005/10/22(土) 00:18:47

>>899
だから、そうして披露自慢したくなる程度には OOP 向けの言語機能や環境の
サポートなしでは“困難な”コトだったのでは？　可能か否かなら、よほどタコな
言語でもない限り、たいていは“可能”だよ。

905 ：デフォルトの名無しさん：2005/10/22(土) 00:18:47

>>900
いずれにしても型なりクラスなりでアルゴリズムを
共有する手段として多態なり多相なりが必要とされて
いるんじゃないの？切り口は違うけど。
逆に現在普及してるOOPL言語で、多態がない言語は
あるの？

906 ：875：2005/10/22(土) 00:27:56

俺のいないところでレスが増えてるなｗ
ポリモーフィズムなんて必須じゃねぇし、いらないってわかったらもういいだろｗ
結局、ポリモ使ったら、グローバルみたいなモン必須なことには変わりねぇだろ。
んでそれは駄目な組み方なんだからよｗ
いい加減、目を覚ませってｗ

ここでいくらレスつけたって過去は変わらねぇぞｗ

907 ：デフォルトの名無しさん：2005/10/22(土) 00:31:13

>>905
いや。クラスと多態／多相性（パラメトリックは除く）は直接は関係ないよ。
クラスは型を定義するために（多くの OOPL ）で使われているだけ。
（クラスもオブジェクトも、もともとは OOP のためのものではないからね）
継承機構があるとき、共有云々のための（オーバーライドによる）多態性が
からんでくる。

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

908 ：デフォルトの名無しさん：2005/10/22(土) 00:32:36

>>906
居なかったなら読み返してくれ。
むしろ polymorphism が要らないのだったら OO は要らないんじゃないかとか思ったんだが。

909 ：デフォルトの名無しさん：2005/10/22(土) 01:12:21

>>908
腹切れｗ

910 ：デフォルトの名無しさん：2005/10/22(土) 01:13:29

基地外が帰ってきたようです

911 ：デフォルトの名無しさん：2005/10/22(土) 01:28:52

お前らスレ違いだぞ？

http://pc8.2ch.net/test/read.cgi/tech/1128354256/l50

912 ：859：2005/10/22(土) 01:48:04

>>906
とりあえず、>>880の認識であってるんですよね？

で、質問なんですが、多態を使用しないOOPの実際ってどんなかんじなんでしょうか？
たとえば、Compositeパターンを多態を使用せずに実現するとしたらどうすればいいんでしょう。

913 ：デフォルトの名無しさん：2005/10/22(土) 02:07:27

キチガイの言ってる事は理想論だろ。

ＳＴＧのような実用的な例を挙げてみろよ。教えてばっかじゃなくてさ。
要するに、C++,Java,C#で多態使わずにタスク等を一元管理する設計。とやらを。

出来るもんならなｗ

>>912
シーングラフにComposite使ってる例も多いな。

914 ：デフォルトの名無しさん：2005/10/22(土) 02:22:12

>>913
>タスク等を一元管理する設計
こんなことする必要無いって気づけｗ

915 ：デフォルトの名無しさん：2005/10/22(土) 02:40:51

>>914
キチガイはコテハンにしろ。

＞こんなことする必要無い

話にならんな。
ギャラクシアンの頃から利用されてるシステムを否定するか。
つーかゲームエンジンそのものの否定だな。

ようは毎回全部書き直せと？ｗ
キャラの種類が一つ増える度に、色んなコードを修正しなきゃいかんなｗ
そんな糞設計のプロジェクト組まされたらキレる奴続出だな。

否定するならまず、代案を出せ。出せるもんならな。

916 ：デフォルトの名無しさん：2005/10/22(土) 02:52:36

なあ、この流れ、どっかで見覚えないか？
前にこの手のキチガイを見たのは、たしかGOFスレ。

917 ：デフォルトの名無しさん：2005/10/22(土) 03:01:10

さらにその前は「オブ戦」スレにいたキチガイに似てる。
ﾃﾗﾅﾂｶｼｽ

918 ：デフォルトの名無しさん：2005/10/22(土) 09:20:37

>>915
いや、お前のような馬鹿は一度だって普通に組んだことが無い。
口ばっかり達者で実は糞タスク以外の組み方を知らないただのアホ。
代案を出せとか言ってるけど、そもそもお前はタスクを使わないで組んであるソースすら見たことないだけだろ。
結局、知らないだけ。

まあ、あんまり馬鹿で可哀想だから教えてやろう。
継承を一切使わずに組んでみろ。

919 ：デフォルトの名無しさん：2005/10/22(土) 10:49:00

>>918
結局出せないのねｗｗｗ口だけはお前て事だな。
これだけ具体例出てるのに何１つ具体的に反論出来てないしねｗ

タスク使わないコード＞俺も学生の頃はそうだったよ。門外不出だし、今みたいにネットなかったし。
糞みたいなコード書くところから始めたね。

＞継承を一切使わずに組んでみろ。

継承も駄目？ギャグだろ？ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前、.NETやJavaでは組む事すら出来ないじゃんｗｗｗｗｗ
非効率的な組み方を極めるつもりか？ｗｗｗｗｗ

Cで組んであるＳＴＧの移植で似たような糞コードなら見たことあるよ。
タスクは使ってるんだが、それ以外のレイヤー層（ハード、ゲーム仕様）がごちゃ混ぜｗ
仕様変更の際、苦労したねー。読むのも苦痛だったし。
似たようなコードそこらじゅうにあるし。
お前みたいなキチガイが組むとこうなる。って感じの例だよ。

それ書いたやつには言っといたけど、「組むのが一番早いから」とか言い訳してたなｗ
組んで終わりじゃねーんだよｗ仕事は。
保守、仕様変更に強くして普通。

920 ：912：2005/10/22(土) 11:13:09

>>918
このパターンはGOFスレそのままですね(^^;
とにかく、具体例を要求されても絶対出さない。ひたすら｢お前がバカだ｣のみ。

921 ：デフォルトの名無しさん：2005/10/22(土) 11:24:25

>>918は抽象化そのものが駄目と言ってるから、グローバル関数で無理矢理処理を纏めるしかないね。
もしかしてそれも駄目なのかな？ｗ

抽象化出来ないから、管理部分など作れない。だから、全部ベタ書きｗ
キャラＡの処理
キャラＡの処理
キャラＢの処理
キャラＣの処理
：
：

、、で、キャラが追加される度に書き直しｗ汎用性ゼロｗ
キャラが多数、目まぐるしく入れ替わるＳＴＧをどうやって再現するつもりだろうねｗ

ぶっちゃけ、落ちこぼれ学生か何かか？ＰＧだと思いたくないｗ

922 ：デフォルトの名無しさん：2005/10/22(土) 11:27:29

小さなプログラムなら多態性が登場しないプログラムもあり得るだろうが、
STGのようにステージ上にある沢山の種類のオブジェクトを取り扱うのに多態性が無いなんてあり得ない。
多態性をサポートする言語機能を使わなくたって、概念上多態性を持つだろうよ。

923 ：デフォルトの名無しさん：2005/10/22(土) 11:33:57

bullet[0].texture = (赤弾のテクスチャ);
bullet[1].texture = (青弾のテクスチャ);

OO の多態ではないけど、こういうのも多態に通じるところがあると思った。

924 ：デフォルトの名無しさん：2005/10/22(土) 12:56:23

>918
>継承を一切使わずに組んでみろ。

ΩΩ＜それは　ひょっとしてギャグで言っているのか!?

継承前提のライブラリはいくらだってあるのに……

925 ：デフォルトの名無しさん：2005/10/22(土) 13:05:12

きっとそういうのは一切使わず全部自作してるんだよ
ところでコテハンつけてなくても呼称がキチガイで統一され始めてたりする？ｗ

926 ：デフォルトの名無しさん：2005/10/22(土) 13:08:28

このキチガイ自作自演じゃないかと思えてきた。

927 ：デフォルトの名無しさん：2005/10/22(土) 13:12:15

伝説のプロ名無しだ！

928 ：デフォルトの名無しさん：2005/10/22(土) 13:17:50

すべてのオブジェクトは世界に一つだけのオブジェクト。
これか？

929 ：デフォルトの名無しさん：2005/10/22(土) 14:06:17

無くても出来るからいらない、と言い出したら
全ての要素が不要になってしまう。

930 ：デフォルトの名無しさん：2005/10/22(土) 17:27:51

All-In-One Eclipseってどう？
ttp://sourceforge.jp/projects/aioec/

とりあえず入れてみた。猫プラグインとか、使い勝手向上させるプラグインも
最初から入ってるといいなぁ。。。

931 ：デフォルトの名無しさん：2005/10/22(土) 18:10:31

>>930
それ使うとインストールがどうこうよりもダウンロードが楽ｗ

932 ：デフォルトの名無しさん：2005/10/22(土) 19:02:03

>>921,922
継承使わないで組んだことないでしょ？
よく考えてみ？
そういう風にならないから。

933 ：デフォルトの名無しさん：2005/10/22(土) 19:05:24

継承使わないってソースファイルが肥大化するだけじゃないのか？

934 ：デフォルトの名無しさん：2005/10/22(土) 19:07:37

継承使うとカプセル化壊れることもあるよ。
ソースファイルの肥大化を押さえて、どこまで安全に組めるかが勝負。

大抵は委譲を使うけど。

935 ：デフォルトの名無しさん：2005/10/22(土) 19:18:49

>>921
まあ、追加でいっとくけど、
そういう方向で増えたとしても、
君のＳＴＧはいったい何種類の特徴をもった敵がいるんだい？
例えば、等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。
あとは自機の動きに反応して次の動きを選択するプログラムが入るだけだろ。
これだけでも結構できのいいＳＴＧが作れるのに、キャラＡ、キャラＢ、キャラＣ・・・なんてそもそもありえるのか？
こんなの１０種類もいきゃかなりの超大作だと思われるが、それでも１０種類程度ならソースに並べても大したことないじゃないか。
＃アインハンダーだっておそらくそんなにねーぞｗ

まあ、頭のいい奴は俺のいいたいことがわかりそうなもんだが。
この方向で、ソースが増大することはほとんど無いんだよ。

936 ：デフォルトの名無しさん：2005/10/22(土) 19:27:37

確信した。こいつ自作自演だ。

937 ：デフォルトの名無しさん：2005/10/22(土) 19:50:57

>>935
神レベル

938 ：デフォルトの名無しさん：2005/10/22(土) 19:59:03

>>921と>>935は同一人物に見えるな…。
句読点の使い方とか全角アルファベットとか文の特徴が似通ってる気が。
いい加減疲れてきてボロが出たのかな？

939 ：デフォルトの名無しさん：2005/10/22(土) 20:01:20

「まあ、追加でいっとくけど」なんて言ってるから、921 への付け足しのつもりでアンカー張ったのではないかと推測

940 ：デフォルトの名無しさん：2005/10/22(土) 20:02:16

ごめん。935 と 921 の話って正反対だわな。長文全然読んでなかった orz

941 ：デフォルトの名無しさん：2005/10/22(土) 20:02:38

晒しage

本人がageまくってて意味ないが

942 ：デフォルトの名無しさん：2005/10/22(土) 20:36:18

>>935
すごいオブジェクト指向だなｗ
問題は組めるかどうかじゃないと何度言ったら分かるんだ？

943 ：デフォルトの名無しさん：2005/10/22(土) 20:38:03

>>942
レスの主旨を酌みとってよｗ

944 ：デフォルトの名無しさん：2005/10/22(土) 20:56:02

>>943
甘えるな。

945 ：デフォルトの名無しさん：2005/10/22(土) 21:34:11

>>935
俺は頭が良くないから君の言いたいことわかんない。

946 ：デフォルトの名無しさん：2005/10/22(土) 21:44:26

>>945
だったらどこがどうわからんのか聞けばいいじゃない。

947 ：デフォルトの名無しさん：2005/10/22(土) 22:22:55

>>935がどうしてそんなに自信満々なのかがわからない。

948 ：デフォルトの名無しさん：2005/10/22(土) 23:00:17

タスクを一元管理なんてする必要がないとか言った後に、

>>等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。

て・・・

949 ：デフォルトの名無しさん：2005/10/22(土) 23:30:36

>>948
別におかしいところはないように見えるが・・・

950 ：デフォルトの名無しさん：2005/10/22(土) 23:33:33

タスクを一元管理することと処理を全部一括してシステムを組むことの違いが聞きたいのでは？

951 ：デフォルトの名無しさん：2005/10/22(土) 23:35:52

>>950
どうして同じに聞こえるのか、そっちのが聞きたいよ・・・

952 ：デフォルトの名無しさん：2005/10/22(土) 23:41:21

>>950
それに>>935の話の主旨はそこじゃあないぞ。
>>935の大事な部分は

「お前等が汎用性をもたせようとしてる部分は全部書き出したって大した量にはならないぞ」

ってところだ。

953 ：デフォルトの名無しさん：2005/10/22(土) 23:58:55

>>952
思いこみだな。
大した量になるかどうかはSTGというだけじゃ判断出来ないだろう。
極端な話、RoboCodeみたいにみんなで動きをカスタマイズして遊びたいのかも知れない。

954 ：デフォルトの名無しさん：2005/10/23(日) 00:09:57

>>953
わからないのに汎用性をつける部分の検証をしないっしょ？
思い込みはどっちなのよ？

955 ：953：2005/10/23(日) 00:38:09

>>954
> わからないのに汎用性をつける部分の検証をしないっしょ？

もちろん。分からないのに、

>「お前等が汎用性をもたせようとしてる部分は全部書き出したって大した量にはならないぞ」

なんて事は言いませんな。

956 ：デフォルトの名無しさん：2005/10/23(日) 00:41:25

>>955
はぁ？何言ってんの？
俺はわかるよ。
お前等はわからないんだろ？
必要の無い汎用性つけて悦にいってるようなアホなんだからｗ
しかも、それでグローバル変数＆関数作っちゃうしｗ

957 ：デフォルトの名無しさん：2005/10/23(日) 00:44:50

>>955
てか、設計云々語ろうとする割にはグローバル変数とか関数使っちゃうし、
型誤魔化すし、処理をわけることを考えないで無理やりまとめることばっかり考えてるな。
お前等って。
なんでまとめるかな。

大きく複雑なモンは、小さく単純なモンに分けないとどの道管理は行き詰るぞ。

958 ：デフォルトの名無しさん：2005/10/23(日) 01:02:17

ポリモーフィズムの使用とグローバル変数の使用との関係を教えて欲しいのだが。
何故その二つが並んで出てくるのかが分からん。
自分のまわりではポリモーフィズムを使いたがる人はグローバル変数に無頓着な人が多かった、という私怨^H^H経験則か何か？

959 ：デフォルトの名無しさん：2005/10/23(日) 01:13:13

>>958
だから途中から入ってきたならまず過去ログ読めよ。
おめーはDirectX初心者スレのアホと同じレベルかｗ

960 ：デフォルトの名無しさん：2005/10/23(日) 01:29:04

@ITのオブジェクト指向の世界とかいう連載はなんであんなに衒学的なんだ？
結局の実装に落とされる世界なのに、難しく考えすぎ。

961 ：921：2005/10/23(日) 03:26:42

>>935
＞例えば、等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。

具体的には？君の嫌いなグローバル関数で纏めるのか？ｗ
それなら継承使った方がマシだなｗ
もっと具体的に言えよ。抽象化は嫌いなくせにな。

それともデータドリブンなんで敵の種類少なくていいんだよｗってオチか？

962 ：921：2005/10/23(日) 03:30:08

>>938
残念ながら違います、、、そう思いたい気持ちはわかるが、、、。

現実にいる。と。真性キチガイがｗ

963 ：921：2005/10/23(日) 03:38:04

キチガイのいうオブジェクト指向とは、
馬鹿でかい汎用クラスをデータ駆動させる事なのかな？ｗ
確か、ダンジョンシージがそういう組み方してると聞いた事はあるが。

>>958
グローバル変数をクラス化するだけでも、問題となる副作用の殆どを抑制出来るよね？
まあ、シングルトンがどういったものかすら理解出来てないようだからねｗ

964 ：デフォルトの名無しさん：2005/10/23(日) 04:44:51

これは解るけど。
Aho aho = new Aho();

これが解らない。
Aho baka = new baka();

965 ：958じゃないよ：2005/10/23(日) 05:18:38

＞ポリモーフィズムの使用とグローバル変数の使用との関係を教えて欲しいのだが。
>>959
一通り読んだが、さっぱし解らん
DirectXを、上手く「カプセル化」出来ないのを恨んでるって事？

>>963
そう言う意味じゃないと思う
シングルトンとポリモーフィズムは殆ど関係が無い

966 ：デフォルトの名無しさん：2005/10/23(日) 07:12:57

>>964
前者はただのアホ、後者は馬鹿を含んだアホってことじゃない？