オブジェクト指向・嗜好・試行・至高・歯垢
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
NGNGオブジェクト指向を何度も試行し、
オブジェクト指向は至高のものだと考え、
オブジェクト指向は歯垢のように無駄だと思う人のスレです。
前スレ
貴様ら！オブジェクト指向を教えろ！！
http://pc2.2ch.net/test/read.cgi/tech/1047696495/
誰も立てないので立てました。
重複していましたら、削除依頼をお願いします。
0002前スレのコピペ
NGNG・要件分析→設計までを一貫した成果物のスタイルに落とすことができ
て、他人が後からトレースするのが簡単
・クラスの分割、パッケージ分割などをきれいにしておくと、整理された
戸棚みたいに、特定機能の位置の把握がしやすい
あたりは便利だと思ってるな。
別に開発スタイルの一種だと思えば、それに従ってやるだけでしかな
いよ、折れは。仕事だし。
本読んだだけで分かった気になって、上司の攻撃に利用するマンセー
厨新入社員が大嫌いなのは、俺も同じだ(ﾜﾗ
0003デフォルトの名無しさん
NGNGhttp://hkwr.com/
http://hkwr.com/bbs
0004デフォルトの名無しさん
NGNG＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
○O
＿＿＿＿,,,,,,,,,,,,,,,,､､､
／ ）））
/ ＿＿＿＿＿＿,,,ノ
/ ｌ / ＼＼ヽ|）
| | '''''''''' ''''''''| ﾓﾜﾓﾜｰ
| | ( ･ ) ( ･ )l
| ｌ ｌ |
| （ ~ _) |
| | ,―――. ｌ ／￣￣￣￣￣￣￣
ｌ .|ヽ ー――' / ＜ という夢を見たんだ
ヾ | ＼＿＿＿＿ノ ＼＿＿＿＿＿＿＿
＿＿／ヽ＼ | ｌ＼＿
￣ λ ヽ / .|
0005前スレのコピペ
NGNGわからん・・・。
手続き型言語のサブルーチンじゃだめなの？
どこから呼び出しても使える便利なサブルーチンをたくさん作ってさ、
あとはメインルーチンからどれをどう呼び出すかだけ
プログラムすればいいようにすれコーディングは十分ラクできるじゃん。
オブジェクト指向はさらに何をラクしたくてできた言語なわけ？
よくできたサブルーチン集を作ることとの決定的な違いってなによ？
Answer1
コードの再利用とか不必要な情報の隠蔽とか利点はいろいろあると思う。
まあ特に必要を感じないんだったら従来どおりにやればいいと思うよ。
Answer2
モジュールとして完成度の高いプログラムはアセンブリ言語でも書くことが出来る。
したがって、オブジェクト指向型の言語は必須ではない。
しかし、オブジェクト指向型言語は、モジュールの完成度を高めるための支援を言語レベルで行う。
いわゆる勘違いによる間違いが減る。それだけである。が、これは圧倒的な生産性の向上を意味する。
よく出来たサブルーチンを作れる人ならば、オブジェクト指向の支援を便利に感じるであろう。
まずは良く出来たサブルーチンの条件、モジュール強度と
モジュール結合度などから学びはじめるのが良いだろう。
0006前スレのコピペ
NGNG構造化手法だけではカプセル化という概念を導入できない。
UMLかJavaの勉強をすればオブジェクト指向を素早く理解できる。
構造化手法だけでは各コンポーネント間の結合度を凝集度を下げることは
容易ではない。
各ソフトウェアコンポーネントは互いに低い結合度で結びつきあっていることが望ましい。
一つのコンポーネントは互いに関連のある責務だけから形成されていることが望ましい。
これが構造化手法の研究成果であるという。
0007前スレのコピペ
NGNGブロックに分割して開発できることだ。
だから、分担しての多人数の開発もやりやすいし、改良する場合も
必要なオブジェクトだけ変更すれば良い。
もちろん、オブジェクト指向を使わなくてもルーチン毎、ソース毎
の分割はできるわけだが、オブジェクト指向を使えばもっと見通しが
良くなり、データを不正なアクセスから隠蔽できたりもする。
0008デフォルトの名無しさん
NGNGOO できる環境ならお勧めはしないけど、C の FILE * なんかはカプセル化だね。
FILE 構造体の中身は感知してはいけない暗黙のルールになっている。
言語が禁止できる仕組みを持っていないけれど。
0009前スレのコピペ
NGNG非オブジェクト指向だと、
1. "ファイルを開く関数"を呼ぶ
2. "ファイルからデータを読み込む関数"を呼ぶ
3. "ファイルを閉じる関数"を呼ぶ
オブジェクト指向だと
1. "ファイル"を表現する、オブジェクト(インスタンス)を作る。
2. そのオブジェクトに"開く"というメッセージを送る
3. そのオブジェクトに"読み込み"というメッセージを送る
4. そのオブジェクトに"閉じる"と言うメッセージを送る。
非オブジェクト指向のときは、どの関数の名前にも"ファイルを〜"と付いてる。
オブジェクト指向のときは、どの操作も"そのオブジェクトにメッセージを送る"となってる。
0010デフォルトの名無しさん
NGNGで、引数に FILE * を取る関数群が FILE クラスのメンバ関数、ということになる。
まあ、わざとそんなことするのはとってもとっても不便だから、素直に class 使いませう。
0011デフォルトの名無しさん
NGNGとうちゃん.Getお茶(かあちゃん.Putお茶());
こんな幹事会。
0012デフォルトの名無しさん
NGNGで、OO にすると、FILE 構造体のメンバ変数が File クラスの private メンバ変数になって、
FILE * を引数に取る関数が File クラスの public メンバ関数となる。
0013前スレのコピペ
NGNG構造化分析ってのは、システムを初期化処理、主処理、終了処理という
構造で考えていくことだ。それぞれの部分が、さらに
細分化されて、モジュールという単位になる。
細かく細分化されることで、確かに一つ一つのモジュールの
機能は分かりやすくなったが、解決されない問題もある。
それは結合度の問題。トップから始まるピラミッド形の構造が、
モジュールの結合を強固にしてしまっている。
簡単にいえば、処理する順番が決まっているということだな。
そこで、共通モジュールというのを抽出して、
いろんなところから利用できるようにするというのが
行われる。共通モジュールはいつでも呼び出せるので
結合度が低い。
OOは、結合殿観点からいえば、総共通モジュール化を
狙ったものととらえることができる。時系列に依存する
部分をできるだけ内側に綴じ込め、いつでもどこからでも
処理を呼び出せるようにして、結合度を低く押さえるわけだ。
つまり、OOでは構造化のようなモジュール分割ではなく、
小さなモジュールの見通しの良さを生かしつつ、逆に
オブジェクトの内部に、そのオブジェクトをうまく使うための
初期化処理（これは通常コンストラクタが担う）
終了処理（デストラクタなどが担う）
を内包させ、初期化後は自由に使えるようにしたわけだ。
発想が逆なのがおもしろいね。
0014前スレのコピペ
NGNGその考え方に基づいたプログラム手法がオブジェクト指向プログラミングであり
同様な設計手法がオブジェクト指向設計。同様に分析手法が（略
で、オブジェクト指向という考え方がどういうものかというと、
「オブジェクトを単位に物事を考える」こと。
オブジェクトとは、内部に状態を持ち、その状態により振る舞いが変わる。
その振る舞いの結果、（自分自身も含めて）他のオブジェクトにメッセージを送る。
メッセージを受けたオブジェクトは、そのメッセージに対応した
状態変化を起し、あらたな振る舞いの結果、またメッセージ送信が行われる。
これが基本。
0015前スレのコピペ
NGNGインクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
プログラム上からは全部プリンタとして扱うことができる。
もちろんそれ以外の方式を採用したプリンタがでてもプリンタとしての
インターフェースを持っていれば同様に扱うことができる。
プリンタとして扱って欲しければプリンタのインターフェースを備えればいい。
レーザープリンタはプリンタとして汎用的に使うこともできるし
レーザープリンタとして特有の機能を使っても良い。
0016前スレのコピペ
NGNG犬とかネコとか山田さんとかそういうことは理解できるんだけど
それを実際のアプリ製作に当てはめようとするとどうもいまいちわからない。
作成するアプリを書いたら、どういうクラスが必要かをレスしてくれるスレはないかなあ
(レス）
激しく同意。
俺の場合も、逝く度かの渡来＆エラーを繰り返して、今も試行錯誤してる途中。
学の無い者による独学ほど非効率なものは無いと痛感。人生死ぬまで修行僧（意味不明
例えば経理システムをOOでどう構築しようかと（経理知識ゼロの俺が）思案してるんだけど、
とりあえず、最終出力たる各種帳票ごとに、対応するクラスをまず作ろうかと思ってる。
この各帳票に対応するクラスを「すごろくのアガリ」と考え、経理のネーチャンが端末から
各種データ（おそらくこれもクラス化の対象になるだろう）を入力してから「上がる」までに
どのような処理が必要かを考え、各種クラス・メソッド・DBレイアウト等をぼちぼち追加していく。
粘り強くやっていけば、いつかはパライソにたどり着くという目論見だが、多分この辺の
要件分析からクラス設計までの話は、学術的・体系的に確立されたものがあるような気がする。
２ちゃんねるではあまり見かけない気がするけど。
0017前スレのコピペ(16の追加）
NGNGただし、道筋に沿って最終目標へ近づけていくアプローチ自体は
むしろ構造化手法そのものなんじゃないかと悩み中。
いくつかの道を辿っていくうちに、以前設計したクラスと似た構成の
クラスが必要になったり、あるクラスの一部分の構成を別クラスとして
切り出して、他クラスにも持たせる必要が出てきたりすると思う。
そのときには、共通関数や共通モジュールのような「単なる共通系〜」を
作らないように気をつけてる。「オブジェクトとして表現すべきものか」を考えてる。
言葉にするのが難しいので、「この辺はやってみて、体で覚えて」としか言えない
のが心苦しいんだけど。
0018前スレのコピペ
NGNGOOは大人数、大規模プロジェクトで複数の人がコードを参照し
仕様変更による改良・改変しデバッグをしやすいというのが売りなんだから
リバーシのような個人が数日で作れるようなソフトではプロセスをそのまま
コーディングする非OOの方が慣れてる人が多い分、早くても自然だと思います。
コードの量が増えるにしたがってOOが有利になると思います。
改良・改変・デバッグに費やす時間（ソースの量Nの増加として）
非OO：OO ＝ N：Log N って感じかと。
0019デフォルトの名無しさん
NGNGプロパティとアトリビュートってどう違うの？
0020あぼーん
NGNG! i iﾉﾉﾘ）) 〉
i l l.´ヮ｀ﾉﾘ ＜先生！こんなのがありました！
l く/_只ヽ
|￣￣￣￣￣|
http://saitama.gasuki.com/koufuku/
0021前スレのコピペ
NGNG開発するほうが工数がかかると思う。ただ、ＯＯで最初から開発しておけば
後々の拡張を考えたとき、非ＯＯよりは工数が少なくなると思う。
非ＯＯ、ＯＯとも、まともに設計されていれば、だけど。
ただ両者の差がどれくらいになるかはつまるところ開発要員によるわけで。
あまりどっちがどうのと優劣をつける問題でもないような気がする。人的な
問題のほうが手法的問題よりはるかに大きい。
優劣を論じたり、ＯＯは使えないとか非ＯＯは古いとかっていう二元論に
持ち込もうとする人間が最大のガンなんだろうと思う。
0022前スレのコピペ
NGNGインスタンス変数をpublicで直接いじるのでは
なく、privateにして、setter、getterメソッドで
アクセスさせる方法が定石なのはなぜなのか、
違い（というか、できたらからくりも）
お前ら教えてください。
Answer1
そうしておくと、そのオブジェクトの変数を変更しようとする人は、
必ずメソッドコールしてることになるでしょ。
そうすると、誰がいつ変更しようとしたかが分かるわけさ。
ﾜｹﾜｶﾗﾝとんでもない値入れようとしたら拒否してみたり、変更の履歴
を取ったり、そういう仕事をメソッド内部に追加できるわけさ。
でもって、そういうものを追加しても、(メソッドシグネチャは変わ
らんので)ユーザに迷惑掛けないわけさ。
誰がいつどのように変更して、整合性の取れない状態変数の集合に
なっても全然かまわないクラスなら、全部変数publicでもかまわない
けど、普通クラスに複数の変数を宣言するときって、それぞれの変数
が全部"なんでもいい"って事は、ないことが多いでしょ？
Answer2
publicな変数を１つ使って実現していた機能が、変数２つに変更したいとする。
外部から直接変数を操作していると、操作する個所すべてに修正を入れる
必要がある。１箇所２箇所ならいいが、数百箇所もあったらバグるのは目に
見えている。
setter/getterメソッドを使って実現していると、メソッドの呼び出し形式が変更
されない限り、変数の操作はクラス内部に隠蔽される。よって、変更箇所も
クラス内部だけですみ、修正工数もバグも激減することになる。
0023デフォルトの名無しさん
NGNG> インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
> プログラム上からは全部プリンタとして扱うことができる。
つまり、端末からだろうが、どっかからのパイプからだろうが、
リダイレクトされたファイルだろうが「標準入力」として扱える
UnixってOO指向的なんですか？
0024前スレのコピペ
NGNGOO だと既存の開発プロセスや設計手法が沢山あり、
それに従って開発するのが OO だと思われているので、
不適合なプロセスを選択すると不自由を感じながら開発することになる。
0025前スレのコピペ
NGNG解説書には「物として扱う」などとかかれているが、それは微妙にニュアンスが異なる。
「対象として扱う」と記述したほうがより理解が進むであろう。
漏れはオブジェクト指向は目的思考とでも言ったほうが良かった気がする。
objectとまったく同じニュアンスを持つ日本語が存在しないために
苦肉の策としてオブジェクトというカタカナを使ったのだとは思うが、
物体思考だと勘違いする香具師がいかんせん多すぎはしないか。
0026前スレのコピペ
NGNG配列への操作と大量のスイッチ文でプログラムを実現する、「根性の賜物」ソー
スを追う羽目になりまして、「ああ、ｺﾚ作った奴がOOをちょっとでも知ってたら、
オイラも楽だし、作った奴も楽だっただろうにな〜…何がなんだか分からんよ つд`)」
と思ったのデス。
根性なしのオイラからみると、作者はある意味えらいとおもうんだけど、その根性
をすこしでも情報収集に向けてくれてれば…
0027前スレのコピペ
NGNGせっかくオブジェクトとしてそれぞれ独立させたんだったら、相手の
オブジェクトのことは（必要最低限のこと以外は）知らなくても良いように
したくない？
多態性があると、『このオブジェクト群には、こう命令すれば動いてくれる』
といった感じに何種類かのオブジェクトをひとまとめにして取り扱うことが
できるので、そのオブジェクト群を使うオブジェクトが、そのオブジェクト群を
個別に扱う必要が無くなる->オブジェクトがシンプルになる。という訳。
wigetなんかの設計をするときに多態性がなかったら死んでますな………
＃さらにこの考えを推し進めると、もっと便利になるよ。
＃Rubyだと、そもそも同じ名前のメソッドだったら、継承関係の無い
＃オブジェクトでさえも同じように扱える。
このへんは現実世界でも良くあることで、例えば
・テレビ用のリモコン
・AVコンポ用のリモコン
・エアコン用のリモコン
なんかは、とりあえずpowerボタンを押せば、それぞれの装置のことを
あまり詳しく知らなくてもスイッチを入れることができるよね。
多態性って、そのあたりのメタファーなんじゃない？
0028前スレのコピペ
NGNG次に逆の方向になるけど、次のようなケースも多態性が必要になるケースですな。
すでにできあがっている／作りかけのシステムに機能（仕組み）を追加したくなった。
その機能は全く新しい機能なので、既存のオブジェクトを調整するだけでは
実現できないけど、機能を実現するための仕組みは従来のオブジェクトを
操作する方法を利用できそうだ。
（実際うまく設計できれば、様々な機能を同じ仕組みの上で実現することができる）
そこで、『このオブジェクト群と同じ命令を受け付ける様にする』すなわち多態性を
利用することによって、既存のシステムの仕組みを変更することなく新しい機能を
追加することができる。
こっちのほうがいわゆる『多態性』になるのかな？
このへんも現実世界で良くあることで、タイプライターとコンピュータのキーボード
なんかは良い例ですな。
つまり、多態性によって『機能』と『仕組み／操作方法』を分離することができるつうのが
『多態性』を重要なものにしている要因だと思うんだけど、どう？
0029前スレのコピペ
NGNGＯＯを採用したプロジェクトがなかなか成功しない
と言われる原因は何ですか？
Answer
全体的にプロジェクト自体の規模が大きくなり、予算・納期は縮小する傾向が
あるので、プロジェクトが成功しにくくなっているというのがある。
だから、OOを採用してなければ成功していたかというと、難しい。
また、新技術にはやはりリスクがあるので、OOを採用したからといって
最初からその利点の恩恵にあずかれるものでもない。
ただ言えるのは、最近の開発で成功しているプロジェクトは
OOを採用している割合が高くなっている。
0030前スレのコピペ
NGNG画面フォームの提示様式とボタンの機能を統一するため、
最小限の基本機能（画面の見た目、パネル分け、PFキー、確認ボタン類）をクラス定義して、
各アプリはそのクラスを利用して造り込んでいく、というものです。
この時問題になったのは、クラス内部の（結果的に）冗長的な一機能が、派生先の仕様によっては足枷になる場合が開発末期に生じたという事です。
また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず独自に別個の関数をダラダラ書きやがったという問題もありました。
（俺も書きやがった一人ですが） …まあ、その程度の経験しかないす。
オブジェクト指向って、決して同一ではないが似たような手続きを複数箇所にダラダラ書くのはダサイから、
一つにまとめて能率よく処理できるよう工夫を凝らそうといったものになるんでしょうか。
ある種ゲージツ的センスで意見が分かれそうで集団開発にどこまで向いているのかちと疑問にも思ったりします。
ちゅーか、それこそ"指向"に左右されるのだなぁなんてね。
0031前スレのコピペ(30へレス）
NGNG関連のあるものを近いところに、関連のないものを遠くにおくか、とか
まとめて変更する可能性のあるものをいかにまとめるか、とか。
だから、集団開発、という点でいえば、おおきなプログラムを
集団で作るときに、ある機能を担当している人が作るプログラムが
他の機能を担当している人のプログラムの影響を受けない・影響を与えない
ようにという方向で設計ができる、という点でオブジェクト指向が良い。
コードが似ている・似ていないが判断基準になるのではなく
概念的に似ている・似ていないが判断基準になる。
結果的には、コードが似ている・似ていないでまとめることになる場合が多い
のだけど、それは結果論。
ある時点でコードが似ているからという理由でまとめると、あとで泣く。
0032前スレのコピペ
NGNGまあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。
(レス）
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな？となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。
0033１
NGNG準備不足ですみません。
0034デフォルトの名無しさん
NGNG0035１
NGNGオレもそういう予感がした。。。。
突っ込む余地を与えるのも大事なんだな。。。。。
トホホ。。。。。
0036デフォルトの名無しさん
NGNG0037デフォルトの名無しさん
NGNGUNIX の設計は OO 風だと思う。
process が fork で増えてく仕組みなんかは prototype based OO そのものだし。
0038デフォルトの名無しさん
NGNGObject Saiko!
Object Siko
オブジェクト指向
0039デフォルトの名無しさん
NGNGプロパティとアトリビュートってどう違うの？
0040デフォルトの名無しさん
NGNGprop・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.
00412ch過去スレのコピペ
NGNGOOPしないことのデメリットを教えたほうがわかりやすいと思うんだけどね。
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);
↓ポリモ以下略
004240
NGNG特に分けては考えないけど、あえて分けるとしたら
Property=特性=オブジェクトに影響を与える(影響が大きい)
Attribute=属性=オブジェクトに影響を与えない(影響が小さい)
こんな感じかも？ とおもう。
00432ch過去スレのコピペ
NGNGどんなに巨大なプログラムでも全体から詳細まで把握してプログラムできるなら、
OOで無駄なポインタのやり取りなどせず書いたほうが効率がいいだろう。
でも自分は人間だから、脳内スタックがすぐ足りなくなるので
どうしても OOに頼らざるを得ない。
0044デフォルトの名無しさん
NGNG00452ch過去スレのコピペ
NGNGなら、何がいいのかというとトータルでは扱いやすいってこと。
むしろ既存の手法にあった色々な考え方を
カプセル化や継承なんていう基本語彙で表現しやすくしたのがでかい。
00462ch過去スレのコピペ
NGNG元の対象とする事象 と それを認知した頭の中の model との間、
頭の中の model と それを自然言語で記述したもの との間、
および、自然言語で記述したもの と それを Programming Language で表現したもの
との間 での traceability を指している。
00472ch過去スレのコピペ
NGNG粒度の大きさ（抽象度と言い換えてもいい）を再確認しよう。
依存性が高いか、粒度が小さいならば再利用が難しいのは明らか。
二つの戦略がある。（粒度の使い方が適当でないかも）
・再利用性を高めるためにドメイン依存をなくし、粒度を大きめにとる
・生産性を高めるためにドメインに特化し、粒度も適当に小さくする
はっきり言って前者は相当しんどい。
標準クラスライブラリ並みの作りこみが必要だし、
どうしたってドメインに依存せざるを得ない
（比較的依存しない部分は標準クラスライブラリでほとんど賄われているわけだし）。
だからデザインパターン（作り方・設計）を（再）利用して、
実際に作るのは後者でいいやんというのが現状。
実装の継承による差分プログラミングが有効なのは
もちろん親子直系のクラスツリーを作るときだけだよな。
それって結構範囲が狭い。
00482ch過去スレのコピペ
NGNGGoF本とかじっくり読んで、部分部分はそれなりの設計ができるように
なったので、試しに一本ツールを作ってみたのですが…。
関連を増やすことを恐れるあまり、部分部分を繋ぐ部分がどうしても
MediatorかObserverっぽくなっちゃいます。つまりものすごく多くの
クラスと関連を持つ頭でっかちな中心クラスが一つ出来てしまうんです。
部分の再利用性は抜群ですが、中心クラスはそりゃもーむごいもんです。
この、設計の最終段階を解説してくれてるような良書ってありますか？
GoF本の２章も仕上げの部分が省略されてていまいちでして。
Answer
「中心」なんてものを出来るだけ無くすようにするのが吉。
芝居だって主人公が(あなたが言う意味の)「中心」である
わけじゃないでしょ？
注：OOPの古典的理論に「アクター(俳優?)理論」ってのが有るらしく。
つまり、
>MediatorかObserverっぽくなっちゃいます。つまりものすごく多く
この部分に「つまり」という単語が出るところが敗因。
もしかしてMediatorやObserverを中心に据えようと
していないっすか？
駄目っすよそのスタイルは。VB/Delを厨房がいじるのと
同じなんだから。(ナニも考えずにあの手のRADを使うと
Formに書く処理が爆発的に多くなる)
00492ch過去スレのコピペ
NGNGただ工数が減ったかといわれると微妙。
速く作れるようになったと言うより、
確実性が増したと言うべきか。
例えば、「こりゃ複雑すぎてメンテできん、
手も足も出ない」っていう状況はほぼなくなりました。
ドキュメントが無い状態でも、クラスを見れば、
おおよその働きは理解できます。
危険な操作はできないように隠蔽できるので、
アクセスのエラーが出たら、
何かしてはいけないことをしたのだという目安になります。
00502ch過去スレのコピペ
NGNGいわゆる「open~closeを並べる」タイプだったです。
でもしばらくしてからプログラムしている内容をオブジェクトに切り 分けて、
そのオブジェクト間のメッセージのやりとりという観点から 自前でクラス階層を構築する、
という作業をしてみると以前よりずっと 実際の問題に近いレベルでプログラムを構造化（？）できるなあ、
と 感じるようになりました。
openだとかcloseだとかは自分のつくったクラスのもっと具体的な名前 のメソッドのなかに隠されて
外からはすぐに見えなくなると思うのですが
00512ch過去スレのコピペ
NGNGモジュールは管理している属性が不明瞭だし、操作する対象も不明瞭のままです。
そこを明らかにすることに価値を見出すのがオブジェクト指向かと。
0052デフォルトの名無しさん
NGNG00532ch過去スレのコピペ
NGNG・多態は静的な型チェックと動的なlate bindingを両立させる。
・late bindingによって実装を隠蔽したままオブジェクト間の組合わせを変え
る自由度が得られる。
・late bindingによって「インターフェースのみを決めた」プログラミング、
たとえばさまざまなデザインパターンが可能となる。
…のは確かなんだが、肝心なのは抽象化であって多態やlate bindingはその
手段じゃないかなあ。
(レス）
これらの意見は、一見、OOの利点に聞こえるが（実際、利点だが…）
この中にある『「インターフェースのみを決めた」プログラミング』が問題。
OOの利点を生かすためには、＜インターフェースのみを先に設計する＞という
前提が必要になるのだが、実際にはこの部分の実践が難しい。
00542ch過去スレのコピペ
NGNGこうやってコーディングするのだなあって思った。抽象化された
コアを作り込んで、具象化はなるべく後にする。そうすることで
問題の本質が見えてくるし、コードの再利用も進む。
頭いい人の手法を「再利用」できるようになったことは、OOによ
る恩恵だなあ。構造化プログラミングの時代には、データ構造＋
アルゴリズム＝プログラムだったから、ついついすべてのコード
がそのプログラムで解決したい具体的な問題に「べったり」なも
のになりがちだった。似たような、しかし、ちょっとずつ違うコー
ドを大量に書いた。いつもデバッグばかりしていた。それがOOに
なって、デバッグの済んだコードを再利用するケースが増えてき
た。デザインパターンまで来て、ようやく得られた恩恵だけど。
デザインパターンを知らないでいると、OOなんてちょっと気の利
いた（しかし、けっこう面倒な）モジュール化技術にしか見えな
いだろうな。
00552ch過去スレのコピペ
NGNGすでにシンプルな物をよりシンプルにするのは苦手というか、効果が薄い。
そういうところはアルゴリズムにまかせたほうがいい。
有用な技術だけど、すべてにおいて効果を発揮する万能薬じゃないのだよ。
会社組織にたとえれば、２〜３人の小さな組織で備品購買担当を決める意味があるのか。
こんな小さな組織で下手に担当を決めるとかえって窮屈になる。
だから３目並べやテトリスくらいでは、デメリットばかりが目立っていい例はあげられない。
しかし大きな組織になったら担当が必要になる。
１００人の社員が好き勝手に備品を買ってきたらえらいことになるし、
管理するのは大変だから担当を決めて、決済や稟議というメッセージを仲介し、
購入という操作や、予算という属性を隠蔽する必要が出てくる。
組織を知ればオブジェクト指向は見えてくる。
00562ch過去スレのコピペ
NGNGＯＯ＝オブジェクト指向：思想。ポリシー。対象を特に選ばない。
ＯＯＡ＝オブジェクト指向分析：ＯＯに基づいた問題領域の分析工程。
ＯＯＤ＝オブジェクト指向設計：ＯＯに基づいた(ソフトウェアの)設計工程。
ＯＯＰ＝オブジェクト指向プログラミング：ＯＯに基づいた実装工程。
クラスとかインスタンスという概念はＯＯでよく見られる一つのパターンであって
ＯＯＡやＯＯＤだからクラスでＯＯＰだったらインスタンスというのは変だよ。
プロトタイプベースの言語だったらクラスないし。
クラス間ならぬインスタンス間の関係を設計段階では扱わないかと言えばんなことないし。
00572ch過去スレのコピペ
NGNG「ソフトウェア構造の把握しやすさ」という概念は理解できていないのでは？
共通部分を括り出すだけでは自分用関数ライブラリと変わらない。
デザインパターンは、ソフトウェアを開発していると良く出くわす
*設計上*の問題とその解決法に名前を付けたもの。
名前があるおかげで、
「これはfactoryパターンでやるといいんでない？」「あ、なるほど」
というやりとりができる。
まあ、みんながパターンを知ってないと共通語彙として使えないから
まだまだ浸透するには時間がかかるだろうけどねえ。
00582ch過去スレのコピペ
NGNG俺もOOマンセーなんだけど、引継ぎで
俺「ここの状態遷移はStateパターンそのままで･･･」
相手「ﾊｧ？すていとぱたーん？」
俺「個々の状態を、AbstractStateクラスのサブクラスで定義して･･･」
相手「ﾊｧ？クラス？構造化プログラミングの言葉でいうと何？」
てなことがしょっちゅうなんだけど。
思うにOOの弱点は
・OOへの理解が浅い人間が設計するとどこまでもひどくなりうる。
・もともとの設計がまともでも、OOへの理解の浅い人間がソースを引き継ぐと
理解できない、またはどこまでもひどくなりうる
・上記2点にもかかわらず理解を深めるのが難しい。（このスレの混乱振りを見れば明らか）
つまり、フールプルーフがなってない。
よって、設計・実装・保守を行う者と、利用者が明確に区別できる場合
（たとえば自分用クラスライブラリや、商用クラスライブラリや、長期に渡って
同一人物やチームが保守することができる場合など）のみしか有効でないと
思うんだがどうよ？
#OOへの理解が浅いのはオレモナー
0059デフォルトの名無しさん
NGNG0060前スレのコピペ
NGNGその周辺に用意されたものが、たまたまニーズに
合ってるだけかもしれない。
オブジェクト指向は「狼の皮を被った羊」なんじゃないのか、と。
0061前スレのコピペ
NGNG「オブジェクト指向」と一括りにされて、うやむやにされた技術は、
実はほとんどが「オブジェクト指向」とは全く関係ないものばかりだ。
俺達は「オブジェクト指向」という言葉に踊らされているのさ。
0062前スレのコピペ
NGNGなんかこれ、真理を突いてるっぽい。
初心者がプログラムするときなんか、メッセージなんて概念は
頭に出てこないだろうし。最近の言語の傾向見てると、
純粋な「オブジェクト指向」という意味自体も消えかかってる。
0063前スレのコピペ
NGNGプログラムをあまり勉強しなくても、ある程度部品を組み合わせれば
ある程度のものができるようになっている。
あと、>>60の言うような「周辺に用意されたもの」の多くは
オブジェクト指向を核に研究開発されている。
それは情報処理学会誌なんかを読んだ感想。
0067前スレのコピペ
NGNGとなると、純なオブジェクト指向＝メッセージング程度という>>66の意見と、
オブジェクト指向の周辺技術がニーズにあっているという感覚からすると、
少なくとも俺はオブジェクト指向の派生物を便利便利と言っているわけで、
そうなると俺は何指向だ？オブジェクトデリバティブ指向とかか？
0068前スレのコピペ
NGNG0069前スレのコピペ
NGNGまあ、確かにそうかもしれん。
でもやっぱりプログラムするときはいつもインターフェース
意識するから、しいて言うなら俺はインターフェース指向かな。
オブジェクト指向ではないことは、>>60の発言で確定したし。
0070前スレのコピペ
NGNGあいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。
0071前スレのコピペ
NGNG学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな？となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。
0074前スレのコピペ
NGNG同意。
オブジェクト指向の本はあんなに分厚い必要はない。
なんつーか、うまく分離できないものかね。
とまあ、この辺の話に興味があるので、レス番編集してコピペしときます。
煽りっぽい発言は省いてます。意味通じないかも。
というか今更だけど、
貴様ら！オブジェクト指向を教えろ！！
http://pc2.2ch.net/test/read.cgi/tech/1047696495/957-
とした方が良かったかも。
00751
NGNG切りがないのでここらでコピペは一旦終了です。
>60-74はオレじゃないんで。(分かるだろうけど）
2chもノイズが多いけど、まとめると凄いためになるんだなと実感。
0076デフォルトの名無しさん
NGNGお疲れ様です。
ワタシが勤めてるトコは、メーカーの情報システム部門で、
ＯＰＥＮ系の開発経験が浅いんです。
（ＶＢ、ＡＳＰとかくらい）
で、外部からも、Ｗｅｂ系の受注を取りたいってことで
オブジェクト指向を取り入れる？ってことらしいんですが、
ＳＥの平均年齢は４０代後半、ちゃんと設計できるのかしら？
・・・このスレに堂々と書き込めるほどには、
オブジェクト指向を理解していないのでsage
0077デフォルトの名無しさん
NGNG受注するのはいいが、オブジェクト指向はやめとけ。
0078デフォルトの名無しさん
NGNGPC上で作業する以上少なからずOOの要素は含まれていると思う。
100%完璧なOOも100%非OOも多分実用的じゃない。
0079デフォルトの名無しさん
NGNGオブジェクト指向がいいとか悪いとか、もうどうでもいいんだあああ！！！
クラスの洗い出しがうまくなるコツをご教授してくれえええええ！！！
0080デフォルトの名無しさん
NGNG0081デフォルトの名無しさん
NGNGそのSﾖがASPにはM$のASPと、ビジネス形態としてのASPの2種類があることを
知らずにASPASPっていってるのならあきらめたほうがいいね。
0082デフォルトの名無しさん
NGNG0083デフォルトの名無しさん
NGNG0084デフォルトの名無しさん
NGNGASP = Anal Sex Play
00851
NGNG貴様ら！オブジェクト指向を教えろ！！第2章
http://pc2.2ch.net/test/read.cgi/tech/1049857221/
0086デフォルトの名無しさん
NGNG0087デフォルトの名無しさん
NGNGおつかれ。てかグッジョブ。
>>79
インターフェースだ。インターフェース指向だとわかりやすいだろ？
0088デフォルトの名無しさん
NGNGで、各部品の叩き台みたいなのを作って動作を確認する。
正しく動いてさえいれば完成したつもりになる。
その後、部品をチューンして性能を上げたり、
インターフェースを継承して機能追加したり。
趣味プログラマからみたＯＯの利点は
妙なバグを出さずに改造を長く楽しめること。
気分はWIZとかのキャラ育ての延長なんだな。
0089デフォルトの名無しさん
NGNGプロの文章に見える。
テクニカルライタさんでつか？
00902ch過去スレのコピペ
NGNGこちらの方が、深く根深い問題だな。
継承したら、子クラスは親クラスのインタフェースを必ず
すべてサポートしなければいけないのが、嫌なんだろうな。
階層の下に行くにつれて、インタフェースがどんどん大きくなっていって、
ある時点での子クラスは、その子クラス自身が使われる問題領域では
恐らく使わないであろうインタフェースまでサポートしなければいけないのが納得いかない…と。
これは確かに歯がゆいねぇ。
(1)子クラスが親クラスのインタフェースを全て扱えることを保証
(2)あるクラスが必要最小限のインターフェースをサポート
の2つの要求のどちらが優先か、にかかっている。
普通は、1>2の場合継承を使い、1<2の場合委譲を使う。
実装階層とインタフェース階層を別に用意して、
TPOに合わせて(?)インタフェース階層をいくつも作ったりとか…。
ここら辺が気持ち悪い？
00912ch過去スレのコピペ
NGNG利用する側：クラスは「自分の」プログラムに適したものが欲しい
提供する側：クラスは「利用者すべての」プログラムで使える様にしたい
つうことで，利用者は最適性を，提供者は汎用性を追い求める……と
結局，両方とも追い求めているものが違う訳だからねぇ．
通常だと継承とかしてクラスのカスタマイズをするわけだけど，
隠蔽という概念を尊重するのならばあまり無茶はできないし……
利用する側：
カスタマイズ「したい」部分をカスタマイズすれば最適化を行える
しかもそのカスタマイズは未来永劫利用できることを保証されている
提供する側：
ユーザーがどのように利用していようと，ユーザーに影響を与えずに
クラスのカスタマイズができる．
つうのは理想だなぁ．両者が好き勝手やるとなんにもできないので，
結局契約で縛る必要があるんだけど……
……デザインパターンとかフレームワークとかの話になるのかな？
0092山崎渉
NGNG0093デフォルトの名無しさん
NGNG0094public ◆PmQxVjGtl2
NGNG0095山崎渉
NGNG（ ＾＾ ）＜ ぬるぽ（＾＾）
0096デフォルトの名無しさん
NGNGなんかいい本ありまつか？
C++から入ってしまった俺としては、C++≠OOは遠すぎるけどC++≒OOではないよなぁというぐらいの
認識しかないんでつけど。
0097デフォルトの名無しさん
NGNGSmalltalk だよ。
0098デフォルトの名無しさん
NGNGC++ でも、コンストラクタ以外、つまりデストラクタとメンバ関数をみんな virtual にすれば、
かなり良質な OO になる。
0099デフォルトの名無しさん
NGNG継承あり、委譲(streambufへ)あり、複雑な内部状態あり、と
オブジェクト指向の好例だと思うけど。
文句を付けるとしたら、streamとstreambufの間の結合が
強すぎることだけど、これは仕方無い。
0100デフォルトの名無しさん
NGNGこういう場所でねたはやめれ。
0102デフォルトの名無しさん
NGNGネタじゃねー。あたりまえのことだ。
0103デフォルトの名無しさん
NGNG0104デフォルトの名無しさん
NGNG確かに、Java のメソッドはみんな C++ でいう virtual やな。
0105デフォルトの名無しさん
NGNG0106デフォルトの名無しさん
NGNGでも、それだけで良質なOOになるとは思えないような。
0107デフォルトの名無しさん
NGNGみんな virtual なら、何でもオーバーライドできて便利♪みたいな。
オーバーライドが危険なメソッドとか、クラス丸ごと継承不可の時の効率とか、
どうでもいいんだろうな。
0108デフォルトの名無しさん
NGNGC++ にはオーバーライドを禁止する言語的な指定はできないから、virtual をやめようと
なんだろうとどうにもできない。
virtual じゃなくても、子クラスとして呼び出した場合はオーバーライドした方の
メソッドが呼ばれちゃうし。
効率はリファクタリングのときに考えること。
初めから非 virtual にしたらたぶん効率がいいだろうと仮定してやみくもにする人、いるんだよね。
ちゃんと、プロファイルしてからオーバーヘッドの高い部分だけを絞り込んで、効率が上がる方法で
リファクタすること。エンジニアリングなんだから、気分じゃなくて、
測定して行うこと。
0109デフォルトの名無しさん
NGNGこんな常識もわからんの？
パフォーマンスのチューニングは全然話が違う。
Javaはアホ用の言語だからしかたないが、それが開発の常識だと勘違いするな。
0110デフォルトの名無しさん
NGNGセキュリティの話？
0111デフォルトの名無しさん
NGNG0112デフォルトの名無しさん
NGNG馬鹿だなあ。Java の方が final 指定ができるからメソッドのオーバーライドを
言語レベルで禁止できるんだよ。
0113デフォルトの名無しさん
NGNG0114デフォルトの名無しさん
NGNG何でもオーバーライドできるのが最高ってのはマヌケすぎると。
0115デフォルトの名無しさん
NGNGオーバーライドしちゃいけないメソッドに、バーチャルつける奴は氏ね。
0116デフォルトの名無しさん
NGNG> パフォーマンスのチューニングは全然話が違う。
効率の話はそっちが最初にしてきたと思はれ。
0117デフォルトの名無しさん
NGNG0118デフォルトの名無しさん
NGNG必要になったら final をはずしていくということでつね。
0119デフォルトの名無しさん
NGNG書かなければ final、必要なら virtual と書くが望ましいだろうな。
0120デフォルトの名無しさん
NGNG0121デフォルトの名無しさん
NGNGそれをオーバーライドする段で override をつけて、それが一致しないと
エラーになる。
Java だと、final をつけたのはオーバーライドするとエラーになる。
0122デフォルトの名無しさん
NGNG> それをオーバーライドする段で override をつけて、それが一致しないと
> エラーになる。
理想的だね。
0123デフォルトの名無しさん
NGNGオーバーライドするときは、overrideとかのキーワード
つけるようにしたほうが便利だと思うんだが。
コンパイル時にシグネチャが合ってるかチェックできるし、
オーバーライドしてるんだって一目でわかるし。
0124デフォルトの名無しさん
NGNGJavaが出た頃は
｢C++はvirtualをつけないとオーバーライドできない。
それに比べJavaはデフォルトでオーバーライドできる。
これこそ真のオブジェクト指向言語だ」
みたいな論調があったからね。
最近はオーバーライドに限らず、
継承一般に関して反動的（？）な意見が主流になってる。
時代による認識の変化は面白い。
0125デフォルトの名無しさん
NGNGと思いつつ、望洋先生の本を眺めてみたけど見つからなかった。
かわりに overload 宣言子をみつけた。
overload func;
int func(int);
int func(char*);
などのように使うらしい。
きっと、これを間違って覚えていたんだな。
オブジェクト指向とは何の関係も無いので下げ。
0126デフォルトの名無しさん
NGNGオブジェクト指向は言語ではなくて考え方。
よく言われるけどオブジェクト指向言語はオブジェクト指向的な考え方を
支援するための道具でしかないよ。
＃C++≠OO、C++≒OOという比較は、比較する質が違っているから
＃あんまり意味無いと思う。
ただ、使う道具によってどのようなプログラミングをするのか制限されてしまうから、
オブジェクト指向を学習するときは正しい道具を使って学習するのが非常に重要。
C++って基本的にプロフェッショナルツールだから、学習用として使用させるのは
とても危険だとおもう。
＃山の素人をいきなり冬の日本アルプスに叩き込むようなもんだよね……
0127デフォルトの名無しさん
NGNG本気で学習用にするなら、大学の講義で言えば、
１年間くらい黒板と原書（笑）輪読で勉強して、
それから半年実習やって、というくらいの覚悟
でやらないと駄目だよな。
0128デフォルトの名無しさん
NGNG5年遅すぎたようだな。
いまどきJavaは遅いといっている奴は時代遅れ
0129デフォルトの名無しさん
NGNG色々と参考になりました。ありがとうございます。
一番判りやすかったのは126さんかも(w
0130デフォルトの名無しさん
NGNGそういや、Java 用のネイティブコンパイラが GCC に入ったっけ？
（>>128 は JIT コンパイラのことを言ってると思うのだが、
最初の１回はどうしても遅くなるので速度的には没。
用途的には◎だけど）
0131デフォルトの名無しさん
NGNG起動の遅さとメモリ喰いなのは相変わらずだよね。
やっぱデスクトップアプリケーションには向かないな。
0132デフォルトの名無しさん
NGNGもはや、オブジェクト失効か？
ところで、Lyeeってオブジェクト指向ですか？？？
0133デフォルトの名無しさん
NGNG0134デフォルトの名無しさん
NGNGあれはスカラー波指向
0135デフォルトの名無しさん
NGNG0136山崎渉
NGNGﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
0137名無しさん＠Linuxザウルス
NGNG0138デフォルトの名無しさん
NGNG0139デフォルトの名無しさん
NGNG0140デフォルトの名無しさん
NGNG0141デフォルトの名無しさん
NGNG0142山崎 渉
NGNG__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
0143山崎 渉
NGNG0144デフォルトの名無しさん
NGNGコンポジションってのは確か has-a のことですよね？結局昔からの設計のほうが仕事
はうまくいくってことなのかな？職業プログラマの皆さんどう思いますか？
どこに書いていいのかわからないためage
0145デフォルトの名無しさん
NGNG0146デフォルトの名無しさん
NGNGポリモフィズム=OO
継承を多用しないということはポリモフィズムを行わないということか
つまり沢村は間違ってると
0147沢口靖子
NGNGその程度の継承は許されてると思うよ。
継承の多用＝ポリモーフィズムじゃないので沢村が間違ってるとも言い切れない
ただ何でもかんでも汎化するのはあたしゃすきじゃありません
0148マリーナの夏
NGNG0149デフォルトの名無しさん
NGNGおまいは、早く結婚しろ！
0150山崎 渉
NGNG│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0151デフォルトの名無しさん
NGNG0152デフォルトの名無しさん
NGNGユースケース分析が、OOだというあなたに聞いてみたい。
ユースケース分析では、あるユースケースをどのように
実現するかという観点で、必要ならサブユースケースに
分割していきます。
これって構造化分析じゃないでしょうか。
どこがOOなんでしょう。
0153デフォルトの名無しさん
NGNGいや、ユースケースそのものはオブジェクト指向とは別もんだと思うが。
誰がそんなこと言ってる？
0154デフォルトの名無しさん
NGNG01551
NGNG2chのテキストマイニングは時間がかかりすぎ・・・・
0156デフォルトの名無しさん
NGNGおぶ戦スレでそんなこといわれたからさ。
OOの本にもユースケース分析が載ってたりするし。
はっきりさせたかったのよ。
0157デフォルトの名無しさん
NGNGこのまま落ちてくのはもったいないスレだよね。
をれも考えを整理するのに役立った。
0158デフォルトの名無しさん
NGNG0159名無し＠沢村
NGNG大学でいえば成城大、芝浦工大、電通大以上だ。このレベルではちょっときついが、頑張れは何とかなる。
６１以上になると、手続き型言語を覚えるのと同程度の労力でオブジェクト指向もマスターできる。
日本女子大、学習院、青学以上だ。
５４以下ではまず不可能だろうね。
国際大、金沢工大、熊本学園大などだ。
もちろん偏差値が高いのにランクが低い大学にいってるやつとかは、この限りではないよ。
0160名無し＠沢村
NGNGだから２ちゃんねらーには手続き型言語が合っている。
もちろん頑張れば不可能ではないから、やってみることだ。
0161デフォルトの名無しさん
NGNG巛巛巛巛巛巛巛彡彡
r､r.r ､|::::: |
r |_,|_,|_,||:::::: ⌒ ⌒|
|_,|_,|_,|/⌒ -="- (-=" ぁぁそうなんや・・・・
|_,|_,|_人そ(^i '"" ) ･ ･)""ヽ なるほどね・・・
| ) ヽﾉ |. ┃｀ー-ﾆ-ｲ｀┃
| `".｀´ ﾉ ┃ ⌒ ┃|
人 入＿ノ´ ┃ ┃ﾉ＼
／ ＼＿／＼＼ ┗━━┛/ ＼＼
／ ＼ ト ───ｲ/ ヽヽ
巛彡彡ミミミミミ彡彡
巛巛巛巛巛巛巛彡彡
r､r.r ､|::::: |
r |_,|_,|_,||:::::: ／' '＼ |
|_,|_,|_,|/⌒ (・ ) (・ )|
|_,|_,|_人そ(^i ⌒ ) ･･)'⌒ヽ ・・・で、何が言いたいん？
| ) ヽﾉ |. ┏━━━┓|
| `".｀´ ﾉ ┃ ノ￣i ┃|
人 入＿ノ´ ┃ヽﾆﾆノ┃ﾉ＼
／ ＼＿／＼＼ ┗━━┛/|＼＼
／ ＼ ト ───ｲ/ ヽヽ
0162デフォルトの名無しさん
NGNG「手続き志向言語」と呼ぶのがいいと思うがどうか。
0163デフォルトの名無しさん
NGNG多様性をいきなり説明したほうがありがたみがわかるような気がするんですけど
私だけかな？
0164デフォルトの名無しさん
NGNG0165デフォルトの名無しさん
NGNG釣られてやるよ。
多態性をどう説明すると、ありがみがわかるんだ。
0166デフォルトの名無しさん
NGNG162じゃないが・・・
解凍ソフトを作るときLHAとかZIPを解凍するクラスが同じ抽象クラスを継承していたら
LHAとかZIPを意識することなくコードを書くことができる?とかかな？
0167デフォルトの名無しさん
NGNGいや、多態性をカプセル化や継承よりも先に説明したほうが
わかりやすいのはなぜかということ。
多態性は継承の側面も持ってるから。
0168デフォルトの名無しさん
NGNGってか、もうそろそろカプセル化だの継承だの多態性だのって
だれも出所も背景も妥当性もしらんような要素に無理やり当てはめてooを説明
しようとするのはやめようぜ。oopやooplの機能紹介ならともかく。
オブジェクトを「データや機能性データ（関数）を自らに内包するデータ」
であることを相手のレベルに合わせてしっかり説明してから、データ内包の
しかた（設計）、それへのアクセスや（機能性があるならその）発現方法、
あるいはそのタイミングを、解決したい問題に合うように吟味するのがoo、
ってことでいいじゃん。あとは解決したい問題の範囲、使用するooplを明示的に
して、どんなときに何がウレシイかを具体例を語ればいい。
0169デフォルトの名無しさん
NGNG0170デフォルトの名無しさん
NGNG確かに最初理解するのは大変だったけど 滝汗
0171デフォルトの名無しさん
NGNG身につけば、いわゆる頭の良くない人にとってのほうが、
なおお得でしょう。
0172デフォルトの名無しさん
NGNGオブジェクト＝クロージャな人ですか？
0173デフォルトの名無しさん
NGNG0174デフォルトの名無しさん
NGNGクロージャは「データ（環境）や機能性データを自らに内包する機能性データ」
0175デフォルトの名無しさん
NGNGオブジェクトは「データ」で
クロージャは「機能性データ」
ですか。
立場がなんとなくわかります。
0176デフォルトの名無しさん
NGNGわからんよ。
機能性データって何語よ。
0177デフォルトの名無しさん
NGNG振る舞いを持つデータ かな？
0178デフォルトの名無しさん
NGNGだから関数だって言っているｗ
0179デフォルトの名無しさん
NGNGまあ、どっちが主役かって主観の話だわね。
オブジェクト指向と（方法論としての）抽象データ型の違いと話が似ているかも。
オブジェクトとクロージャもしかりで、
理屈では（ってか仕組みや枠組み的には）まったく同じもの。
0180デフォルトの名無しさん
NGNG以前からの疑問なんですが、本来オブジェクト指向は、
抽象データ型＋「抽象関数型」と呼ばれるべきなんじゃ
ないかと。
0181デフォルトの名無しさん
NGNG関数型って言い回しは語弊があるかも…ｗ
あと、抽象データ型（手法のほうじゃなくて、「ユーザー定義可能な型」
のほう）に“抽象”関数、すなわち仮想関数という考え方や仕組みも
含まれるような気もしなくもありませんが、どんなもんでしょう。
0182デフォルトの名無しさん
NGNG「関数型」はまずかったですね。じゃ「抽象手続き型」とか・・・。
個人的な単純に言葉からくる印象だとC++のテンプレートとかで型をパラメータ化
するほうが「抽象データ型」で、「仮想関数」を使うのは「抽象手続き型」と
いった方がしっくりするんじゃないかという気がしたもので。
一般的な用語の使い方ではないのですけれども。
0183デフォルトの名無しさん
NGNG0184デフォルトの名無しさん
NGNGイメージの世界で理解せよ。
0185デフォルトの名無しさん
NGNG0186デフォルトの名無しさん
NGNG0188デフォルトの名無しさん
NGNGthis=自分 super=基底クラス・親クラス
0189デフォルトの名無しさん
NGNGthisもsuperも自分だと思っていたよ。
0190名無しさん＠Linuxザウルス
NGNG妹クラスを作って１２人の妹を派生させて
呼びかけると
お兄い様
お兄いちゃん
お兄いたま
(ry
と応答させて
おお ポリモーフィズム マンセー！！
という感じで理解しろという事かな
0191最凶VB厨房
NGNG0192名無しさん＠Linuxザウルス
NGNGいや よくいるだろ 数学の公式は覚えられない
のにモーニング娘の名前は全員覚えてるやつ
だから分からんやつは まずは好きなオブジェ
クトを作らせてそれを複雑にしていった方が
覚えられるだろう
それに客観的に見れば あの作品wの"妹達"は
それぞれ違うのに "妹"という共通のくくりに
入っていて"兄を慕う"という共通の属性を持っ
ている
継承とかポリモーフィズムの題材としては
最適じゃないのかｗ
0193デフォルトの名無しさん
NGNGわらた。
0194名無しさん＠Linuxザウルス
NGNGオブジェクトを生成するのだろうが
最初はなかなか難しいだろうからな
0195最凶VB厨房
NGNG好きなオブジェクトが妹というのもキモイだけ。
ポリモーフィズムの題材として
ポリモーフィズムを使うと何がうれしいのかが知りたいのであって
おにいたまなぞ言われてもキモイだけで何もうれしくない。
0196名無しさん＠Linuxザウルス
NGNGその激しい嫌いよう・・・
もしや おぬしリアル妹がいるな
0197最凶VB厨房
NGNG0198デフォルトの名無しさん
NGNG0199デフォルトの名無しさん
NGNG先生！萌え萌えオブジェクト指向の執筆おながいしまつ
0200名無しさん＠Linuxザウルス
NGNGこらほんとにそんな連載をこのスレで
やられたら大変じゃないか
ついでに200Get
0201デフォルトの名無しさん
NGNGttp://www.entis.jp/doc/lolita_programing/lolita1.html
0202デフォルトの名無しさん
NGNG役に立たねぇぇぇぇ
0203デフォルトの名無しさん
NGNG）
（
,, ） ）
ﾞﾐ;;;;;,_ （
ミ;;;;;;;;､;:..,,.,,,,,
i;i;i;i; '',',;^′..ヽ
ﾞゞy､､;:..､） ｝
.¨.､,_,,､_,,r_,ノ′
/;:;":;.:;";i; '',',;;;_~;;;′.ヽ
ﾞ{y､､;:...:,:(´∇｀).:.､;:.,._､｝
".¨ｰ=v ''‐ .:v､,,､_,r_,ノ′
/;i;i; '',',;;;_~⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′..ヽ
ﾞ{y､､;:...:,:.:.､;､;:.:,:.:. ._ .､） ､｝
".¨ｰ=v ''‐ .:v､冫_._ .､,_,,､_,,r_,ノ′
/i;i; '',',;;;_~υ⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′.ｿ.ヽ
ﾞ{y､､;:..ゞ.:,:.:.､;:.ﾐ.:,:.:. ._υﾟo,,'.､） ､｝
ヾ,,..;::;;;::,;,::;):;:;:; .:v､冫_._ .､,_,,､_,,r_,ノ′
0204190
NGNG苦情その他は、原稿を依頼した>>199へおながいします。
萌え萌えオブジェクト指向(1)
まずオブジェクト指向を解説するにあたって一言。この連載では厳密には正しくないけど、分かりやすい例えを使いたいと思います。
これは不完全でも分かった方が、完全さにこだわり、分からなくなるよりも|
何倍もましだからです。
これは、メイド服について理解した時を思い出してもらえればわかるでしょう。
「○○メイドはメイド服じゃないんだよほんとのメイド服というのはね（ry」といったオタのうんちくを聞くよりも
まほろまてぃっくや、ハンドメイドメイというアニメから入り、
メイドコスプレの女の子の写真をとりにイベント参加。
メイドホームページを作ってしまうようになってはじめて
ああ、「○○メイドは、ほんとのメイド服じゃないんだ」という事が分かるのと同じです。
それではまず、オブジェクト指向が生まれた経緯から説明しましょう。
以前、コンピュータという物は高価でしかも今よりも遙かに低性能でした。
そこで、人間がコンピュータ様の都合に合わせて、コンピュータ様が
分かりやすいようにプログラムをしていました。
このコンピュータ様が女の子型の匡体で、「ちぃ」とかわいく鳴いたりするなら、そりゃいたれりつくせりして
やりたくなりますが、実際にはただの無愛想な箱にすぎません。
その後コンピュータが高性能で安価になるにつれ、なんで人間様がコンピュータごときの都合に合わせなあかんねん。
もっと人間様の都合に合わせて、そう現実の世界を、そのままメモリ内につくって、それがプログラムとして動いたらいいのに。
という考えが出てきてオブジェクト指向が生まれました。
ですから、コンピュータの事を考えなければ、オブジェクト指向はごく単純な事なのです。
単純で当たり前すぎるがゆえに、分からなくなってしまうのです。
さて、今回はここまでにしましょう。
それでは次回までごきげんよう。
0205190
NGNG苦情その他は、原稿を依頼した>>199へおながいします。
萌え萌えオブジェクト指向(2)
それではまず「オブジェクト」について
これは辞書にでてくる「もの」という
意味と同じです。
例えば、ちよちゃん、おおさかさん、可憐、白鳥、四葉、あなたの持っている初回版CD、限定版DVDボックス。
それから、限定版DVDボックスの"予約"、ちょびっツCD-ROMの"注文"といった実体がない"もの"も"オブジェクト"です。
次にクラスについて。
ひとつの"もの"はいろんな表現ができます。
例えば"可憐ちゃん"は、女の子ですし、妹、学生、人間という表現ができます。
つまり"もの"はいろんなくくりでくくれます。
そして学生というくくりの中では可憐ちゃんも、四葉ちゃんも、おおさかさんも皆勉強します。
人間というくくりでは可憐ちゃんも、ちよちゃんも、あなたも、食べたり寝たりします。
つまり同じ性質をもつものをまとめてクラスと呼ぶのです。
さて、今回はここまでにしましょう。
それでは次回までごきげんよう。
0206デフォルトの名無しさん
NGNG0207デフォルトの名無しさん
NGNGいや、出てくる言葉が謎が多いからか、、
0209デフォルトの名無しさん
NGNG0210デフォルトの名無しさん
NGNG0211190
NGNG苦情その他は、原稿を依頼した>>199へおながいします。
萌え萌えオブジェクト指向(3)
さて今回はまず"継承"から
前回、ものはさまざまなくくり方が出来て
これをクラスと呼びました。
ここでシス〇リの"可憐ちゃん"について見て見ましょう
まず妹なので「お兄にちゃん」と呼んでくれます
おおきなくくりでは学生なので、学校に行きます
さらに大きなくくりでは人間なので、食べたり
寝たりします。人間の持っている性質は学生も
持っているし、学生の持っている性質は"可憐ちゃん"
も持っています。
但しその逆を考えると、人間は必ずしも学校に行くわけでは
この様におおきなくくりの性質を小さなくくりが
受け継ぐ亊を"継承"と呼んでるだけです。
つまり"可憐ちゃん"も人間だから食たり寝たり
するし学生だから学校に行くって亊です。
さて、そろそろ「改行が多すぎますエラー」で
書けなくなるかもしれないので
今回はここまでにしましょう。
それでは次回までごきげんよう。
0212190
NGNG苦情その他は、原稿を依頼した>>199へ。
萌え萌えオブジェクト指向(4)
ここでよく解説書に「オブジェクト同士で通信して、メッセージのやりとりをして」と書かれている事について説明します。
ここであるシーンを思い浮かべてみましょう
あなたは「もとすわ ひでき」という青年になっています、外観が人間のかわいい女の子そっくり
のパソコンが抱き着いてきました
あなたの顔を見て「ちぃ」と鳴いてほほ笑んでいます。
あなたはかわいさのあまり抱きしめてしまいます。
今度は「もとすわ ひでき」君のバイト先のかわいい女の子が抱き着いてきました、あなたの顔を見て「もとすわさん」とささやいてほほ笑んでいます。
あなたはかわいさのあまり抱きしめてしまいます。
この時「もとすわ」君という"もの"と女の子パソコンという"もの"の間では何がおきていますか？
関数呼び出しですか？
「もとすわ」君には肌から体温という情報が、目から光という形でかわいい顔が伝わってきています
女の子パソコンにも肌から体温という情報が、目から光という形で大好きな人の顔が伝わってきています
このように"もの"と"もの"との間では自然とやりとりが生まれ 結果としてほほ笑んだり、抱きしめたりという動作につながります。
実際には熱とかいろいろなものが伝わります、ですがコンピュータは情報機器なのでメモリ上の"もの"の間では情報だけが流れます。
情報の流れ、これはまさに通信といえるのではないでしようか。
このように流れる情報はメッセージと呼ぶ方が自然ではないでしょうか。
"ほほ笑む"というメッセージを受けて、"抱きしめる"という動作をしたと表現した方が自然ではないでしょうか。
つまり一見、変ですが"もの"をベースに考えるとむしろ自然な表現なのです。
さて、「本文が長すぎますエラー」をくらったので
今回はここまでにしましょう。それでは次回までごきげんよう。
0213デフォルトの名無しさん
NGNG○あなたはもう萌え萌えでむぎゅっとしてしまいます。
0214デフォルトの名無しさん
NGNG0215デフォルトの名無しさん
NGNG俄然興味が出てきて、今 @IT のUMLの連載を読んでるとこ。
あの本よく出きてるなーと思った。すんなり記事の内容を理解できたけど
たぶんあの本を読んでなかったら、チンプンカンプンだったと思う。とり
あえず色んな書籍を読んで OO の大海原に漕ぎ出したい気分になりました。
0216デフォルトの名無しさん
NGNGオブ脳はとりあえず4章まで読めばOK。
その後は、UMLでも、デザパタでも、EJBでもすきなところ行ってくれ！
0217190
NGNG苦情その他は、原稿を依頼した>>199へおながいします。
萌え萌えオブジェクト指向(5)
それでは、前回出てきたシーンを思い出してみましょう
この場合、はじめに出てきたのは、女の子形とはいえあくまでも中身はパソコンです
次は生身の人間の女の子です。
全く別の内部構造をしています。
ですが、同じメッセージを発していたので同じ様に"抱きしめる"という扱いが出来たのです。
別の表現をすれば、外部からみてかわいい女の子なら、中身が何でも、萌えられる、という事です。
その女の子に「暗殺する」（メソッド）を追加しても、萌えられるという事です。
これはとても便利な性質です。
さて、今回はここまでにしましょう。
それでは次回までごきげんよう。
0218デフォルトの名無しさん
NGNG0219デフォルトの名無しさん
NGNG期待あげ
0220デフォルトの名無しさん
NGNG仕事がてんぱってるんだろーか
0221デフォルトの名無しさん
NGNG0222名無しさん
NGNGまさかふりよの事故で他界？
(((；ﾟДﾟ))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0223デフォルトの名無しさん
NGNGインプリメントって調べてもよくわからないです
0224デフォルトの名無しさん
NGNG継承は関係ない。
0225デフォルトの名無しさん
NGNGクラスを実装するというか
抽象データ型を実装したのがクラスな訳で
0227デフォルトの名無しさん
NGNG0228デフォルトの名無しさん
NGNGまあそうなんだろうけど、普通にnewで宣言してして使うのとどう違うんだよ？
0229デフォルトの名無しさん
NGNG何か違う話になってないか？
0230デフォルトの名無しさん
NGNGとりあえず理念と実装の区別をつけろ。
あとインターフェースの意味も覚えとけ。
老婆心ながら付け加えるが、Javaのinterfaceという言語要素の事とは限らないぞ。
0231デフォルトの名無しさん
NGNGﾊｧ( Д)ﾟ ﾟ？
0232デフォルトの名無しさん
NGNG>>231 クラスのインスタンスを生成して
0233デフォルトの名無しさん
NGNGﾊｧ( Д)ﾟ ﾟ？
実装するって言うのは、
定義済の機能を実現(コーディング)することなんだが。
0234デフォルトの名無しさん
NGNG実現するってなに？
アホにでも分かるように教えてくれよ（ﾊｰﾄ
0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNGimplementsで・実装する（って言っていいのかな？・だけではだめなの？
カスにでも分かるように（ry
0237デフォルトの名無しさん
NGNGメンバ関数(メソッド)の中身を書く
ということ
じゃ、あかんか?
0238デフォルトの名無しさん
NGNGフィールド(属性)は?
0239デフォルトの名無しさん
NGNGそれなら分かるんだけど
じゃあVBのimplementsって何のためにあるんだろって思う
ボケに（ry
0240デフォルトの名無しさん
NGNGフィールド -> メンバ変数
VBは知らん。
0241デフォルトの名無しさん
NGNGフィールドはJava用語かな
OMG的にいうなら属性だが
0242デフォルトの名無しさん
NGNG１９０連載期待あげ
ちょっと分かりづらい言葉も多いのは気に（ｒｙ
0243デフォルトの名無しさん
NGNG0244デフォルトの名無しさん
NGNG話が実際的でかなりいい本だと思いながら読んで
いたんだが、「プログラマのたしなみ以前の常識」と
して紹介しているスタックを、なんとFIFOと解説。
（しかも図解付き。図ではちゃんとLIFO。）
この時点で著者への信用がガラガラと・・・。
0245デフォルトの名無しさん
NGNG0246デフォルトの名無しさん
NGNG「オブジェクト指向でなぜつくるのか」だろ
0247デフォルトの名無しさん
NGNGただの誤植だろ？
0248デフォルトの名無しさん
NGNG正解。
>>247
１箇所だったらそう思えるけれど・・・。しかも
「FIFO(First In First Out)」って丁寧に説明
してるし。
ま今では直ってるみたいなのでこの話は
終了で。それよりこの本を読んだ人の感想
を聞きたい。
0249デフォルトの名無しさん
NGNGだいたい意味は分かった。
これでオブジェクト指向、理解したことになる？
0250デフォルトの名無しさん
NGNG0251デフォルトの名無しさん
NGNG0252249
NGNG次、何読めばいい？
0253デフォルトの名無しさん
NGNG0254デフォルトの名無しさん
NGNGオブジェクト指向とオブジェクト志向は違う概念やぞ
0255デフォルトの名無しさん
NGNG0256デフォルトの名無しさん
NGNG「オブジェクト志向」の表記ミス。
表記ミスの方が一般には広まってしまった。
0257デフォルトの名無しさん
NGNGなわけないだろ
指向はorientedの訳
0258デフォルトの名無しさん
NGNGゴキブリのパロディだろ。
0259デフォルトの名無しさん
NGNGゴキカブリ
0260デフォルトの名無しさん
NGNG0261デフォルトの名無しさん
NGNG0262デフォルトの名無しさん
NGNGC++またはC#からはじめては、、、いけない。
脳みそ腐りますがな。
0263デフォルトの名無しさん
NGNGC++とC#を同列に扱ってどうする。
0264デフォルトの名無しさん
NGNGできれば理由も教えてください
0265デフォルトの名無しさん
NGNG文法がでかすぎる。
プログラミング言語にとってはこれは致命的。
なくてもよいお便利機能がてんこもり。
C++は歴史的な経緯から仕方ない側面があるけど、
C#は真の糞。
0266デフォルトの名無しさん
NGNG何故ですか？
0267デフォルトの名無しさん
NGNG漏れは仕事だから毎日使ってるけどいやになるね。
0268デフォルトの名無しさん
NGNG俺も言語によっちゃそういうのあるな
0269デフォルトの名無しさん
NGNGだけどC#はMSの最新言語ってこと考えると、
文法の練り込みが甘すぎると思うんだな。
0270デフォルトの名無しさん
NGNG0271デフォルトの名無しさん
NGNGC#触ったこともないが
0272デフォルトの名無しさん
NGNGこれも否定されたら、メジャーなのがほとんど残らない気がするぞ
0273デフォルトの名無しさん
NGNG0274デフォルトの名無しさん
NGNG原点である「メッセージ指向」からならSmalltalkか、せめてRuby。
現在主流の「抽象データ型のスーパーセット」（いわゆる、カプセル化、継承、多態性【註】）からなら
オリジナルのSIMULAか、Cからの派生でメジャーどこならC++やJava、C#。
これらにこだわらない、もっとプリミティブなオブジェクト指向に興味があって、
「インスタンスベースのオブジェクト指向」からならSELFか、メジャーどこならPythonやJavaScript系。
もっと枠をとっぱらったところからで、かつ疑似関数プログラミングとかにも興味があれば、CLOS。
一般に、新しい言語ほど、いろいろなコンセプトのいいとこ取り（悪いときは単にひそみにならって
いるだけ）なので、純粋なところは学びにくくなるように思います。
【註】この文脈では、ストラウストラップの言う、「抽象データ型」、「継承」、「仮想関数」、と
言い換えたほうが無難かも…。
0275デフォルトの名無しさん
NGNG参考資料も多いし。
0276デフォルトの名無しさん
NGNGこの中で一番簡単そうなのはどれですか？
0277デフォルトの名無しさん
NGNGJavaScript
0278デフォルトの名無しさん
NGNGGUI はそれこそ classify しやすい分野だと思うから、Squeak とかで
遊んでみるのが良いと思う。
そういう意味では Java でも Delphi でも C# でもいいのだが。
それなりに楽しんだら、デザインパターンか分析／設計の方へ。
0279デフォルトの名無しさん
NGNG・良い点
クラスもオブジェクト（メタ・メタ・メタ！）
強力なリフレクション機能（基底クラスのメソッド数が膨大）
制御構文も（疑似）メッセージ送信（if 文もメソッド呼び出し風に書ける）
クラスやメソッドの定義もメッセージ送信（動的にクラス定義出来るよん）
実行時型決定（クラスのすげ替えとかが簡単に出来ちゃう）
オブジェクト指向的ライブラリの豊富さ（クラス数、メソッド数が半端じゃない）
充実したブラウザ、インスペクタ（凄ぇぜ）
キーワードメッセージ式は S 式 + マクロに匹敵すると思う
・悪い点
リテラル配列中でクロージャが作れない（ダメじゃん）
Squeak のクロージャはレキシカルじゃない（再帰出来ないよん -- ANSI はｵｹ）
メタは取っ付きにくい（最初だけだけど）
環境一式をイメージに抱え込む方式（外世界とのやり取りが面倒）
チャンク式が汚い（スクリプティングには向いてない）
使い易い処理系が無い（日本語使い辛いとか、ライセンスとか、配布とか）
GUI がイケてない（見た目が古いとか、他との整合性とか）
まぁ、オブジェクト指向を語る上で必修言語であるのは間違いないでしょう。
0280デフォルトの名無しさん
NGNG定説です
0281278
NGNG>SmalltalkをSmallTalkとか書く奴に、ロクな奴は居ない
む、何度もこのような文面を見たことがあるのにやってしまった・・・
俺がろくでなしなのと無関係に、 Smalltalk は初学者が
手始めとして触ってみるのに向いた環境だと思うよ
0282デフォルトの名無しさん
NGNG他の言語もオブジェクト指向言語としての良い点／悪い点聞いてみたい。
0283273
NGNG意思の疎通を図る上で何の問題もないのは明らかだが、
馬鹿に「SmalltalkをSmallTalkとか書く奴に、ロクな奴は居ない」とか言われて
むかつくリスクを考えたらSmalltalkと書いた方がいい。
俺は自信がなかったらから調べた。
0284デフォルトの名無しさん
NGNGそんな事書いてもこのスレ的には何のメリットも無い訳で。
まぁ >>280 の気持ちも分からないでもないけど。
各オブジェクトシステムモデル間の差異ってこれくらいかな。
... メソッドがクラスに属しているか
... オブジェクトがクラスに属しているか／クラスベースか、オブジェクトベースか
... メソッドはオブジェクトか（データとして渡す事が可能か）
... 単一継承か、多重継承か、ミックスインがあるか
... インターフェイスを持っているか
... リフレクション機能を持っているか／メタオブジェクト的な機能があるか
... 動的なクラス、メソッドの再定義を許しているか（ユーザが拡張可能か）
... メソッド呼び出しの記法（ドットで繋ぐ／メッセージ送信）
... 内部に関数呼び出しの層を持っているか
... オブジェクトではないデータ型があるか／Boxing を行うか
... オブジェクト内データへのアクセス制限が可能か（隠蔽）
0285デフォルトの名無しさん
NGNG... メソッドがクラスに属しているか
- 属している。クラスに属さないメソッドは定義出来ない。
... オブジェクトがクラスに属しているか／クラスベースか、オブジェクトベースか
- クラスベース。クラスをテンプレートとしてインスタンスを生成
... メソッドはオブジェクトか（データとして渡す事が可能か）
- メソッドはオブジェクトとして取り出せる。
... 単一継承か、多重継承か、ミックスインがあるか
- 単一継承。ミックスインは標準では無い？
... インターフェイスを持っているか
- ある。大きな特徴の一つ。
... リフレクション機能を持っているか／メタオブジェクト的な機能があるか
- java.lang.reflect にある。get 系だけで、set は出来ない。
... 動的なクラス、メソッドの再定義を許しているか（ユーザが拡張可能か）
- 出来ない？ クラス、メソッドはソースコードで定義され、コンパイルされる必要がある。
... メソッド呼び出しの記法（ドットで繋ぐ／メッセージ送信）
- ドットで繋ぐ。インスタンス生成は特別なキーワード new を使用する。
... 内部に関数呼び出しの層を持っているか
- 無い？
... オブジェクトではないデータ型があるか／Boxing を行うか
- プリミティブ型あり。Boxing は 1.5 で予定。
... オブジェクト内データへのアクセス制限が可能か（隠蔽）
- 出来る。アクセス修飾子を使用する。
0286デフォルトの名無しさん
NGNGSmalltalkに近いんだよね？
0287デフォルトの名無しさん
NGNG0288デフォルトの名無しさん
NGNGruby を使ってみて Smalltalk に近いと感じるぶんにはいいけど、
Smalltalk に近いからと聞いて ruby を使うのはどうなのかなぁ…（反語的に）。
今は昔と違って、処理系もロハだし、マシンパワーもほぼ十分だから
即実践…と先を急がないなら Smalltalk をじかにいじってほしいかな、と。
Smalltalk(Squeak/VisualWorks/etc.)総合スレ
http://pc5.2ch.net/test/read.cgi/tech/1039017724/l50
ただ、繰り返しになりますが「クラス指向」と言うべき、抽象データ型の
スーパーセットとしてオブジェクト指向を学びたいなら、SIMULA や
C++ の流れを汲む言語のほうが個人的にはいいと思います。
簡単とかで選ぶんじゃなくて、学びたいことに合った処理系を選ぶのが一番です。
0290デフォルトの名無しさん
NGNG「メッセージ指向」のオブジェクト指向は、それこそ子供でも直感的に理解できるように
考え出されたものなので、とても簡単です。ようは、コンピューティングに関わるもの
すべてを「オブジェクト」とそれへの「メッセージ送信」に置き換えることで表現しよう、
というものです。これを実践するために考え出されたコンピュータシステムと言語が
Smalltalk システムと Smalltalk 言語ですから、逆にメッセージ指向を学ぶのに、これ
以上のものはありません。
一方で「クラス指向」と呼ぶべき現在主流のオブジェクト指向は、ずっと複雑です。これは
「抽象データ型」、つまり、ユーザーが自由にデータ型を定義できるしくみに加えて、定義
した型から「派生」させて別の型作成を容易にするしくみ、さらに、関数を動的に呼び出す
「仮想関数」というしくみを知って活用することを目指すものです。従来、言語仕様に
組み込まれて自由にはできなかった“データ型”とその振る舞いを、「クラス」として
ユーザーの手で定義できるメリットは大きいのですが、そのぶん、学ばなければ
ならないことも多くなります。なので、こちらを会得しようと思ったら、片手間では
ちょっと難しいかもしれませんね。
0291デフォルトの名無しさん
NGNGJavaは多重継承を制限付きでサポートする (実装の多重継承はできない)
バートランド・メイヤーいわく、GenericityやガベッジコレクションもOOには必須らしい
あと個人的にはクロージャがファーストクラスかどうか、とか
0292デフォルトの名無しさん
NGNGJavaはオブジェクト指向の糞を集めた言語
0293デフォルトの名無しさん
NGNG0294286
NGNG丁寧なレス、サンクス。
趣味程度だと、Smalltalkが良さそうだね。
本屋に行ったけど、Smalltalkの本があまりない。
Squeakってのでもいいのでしょうか？
0295デフォルトの名無しさん
NGNG＞Smalltalkの本があまりない
つーか、どーでもいいくだらん本が多いだけだと思う。
0297デフォルトの名無しさん
NGNGいい本1冊買えば足りると思うけど。
Smalltalk の本？ 待っても増えないと思うけど。
しかも日本語のを期待しても、
0298デフォルトの名無しさん
NGNGそのいい本って何ですか？
0299デフォルトの名無しさん
NGNGEiffel
0300デフォルトの名無しさん
NGNGお〜、また新しい言語ですか・・・
0301デフォルトの名無しさん
NGNG0302デフォルトの名無しさん
NGNG0303デフォルトの名無しさん
NGNG本人本
ttp://www.ascii.co.jp/books/detail/4-7561/4-7561-3254-5.html
0304デフォルトの名無しさん
NGNG本屋で見たら難しそうでした・・・
偶然、このスレ↓が新しくたったので、見つけたのですが、D言語ってどうなのでしょうか？
今、これのHP読んでるのですが、評価するのは私には難しいっす。
D言語 Part.4
http://pc5.2ch.net/test/read.cgi/tech/1091185216/
0305304
NGNG＞最初に学ぶプログラミング言語として。 Basic か Java が初心者には向いています。
＞D は、中級〜上級者プログラマが二番目に修得する言語として優れています。
0306デフォルトの名無しさん
NGNG書籍にこだわらなければ、ウェブの資料で十分。
0307デフォルトの名無しさん
NGNGC言語でオブジェクト指向風なコーディングをしてみるのはどうすかね。
gtkのソースとか眺めてみたりしてさ。
rubyとかはその後に勉強してもいいでしょ。
そしたらオブジェクト指向言語ってすっきりかけるなぁとかしみじみしてみたり。
0308デフォルトの名無しさん
NGNGそうですか。
とりあえずそれでゆっくりやっていきます。
>>307
Cは以前、少し使ったことがあるので、文法は知ってるんですよね。
最近の言語って（見た目の記述が）Cライクなのが多くて、C知ってて
良かったな〜と思ってます。
gtk ｸﾞｸﾞってみます。
0309デフォルトの名無しさん
NGNGよさげだな。。。
0310デフォルトの名無しさん
NGNG0311デフォルトの名無しさん
NGNGホントか(w
0312デフォルトの名無しさん
NGNG0314デフォルトの名無しさん
NGNG0316デフォルトの名無しさん
NGNG0317デフォルトの名無しさん
NGNG英語→日本語の訳という意味ではなく
Object Orientの本質と「指向」が一致しているのかと。。。
このスレをみて思う俺様であった。
0318デフォルトの名無しさん
NGNG東方見物禄でどうだ
0319デフォルトの名無しさん
NGNGつーか、オブジェクト指向ってよりは、オブジェクト適用プログラミング
ってほうがしっくりくるかな？
0320デフォルトの名無しさん
NGNGしかし、この世界、先に訳した人のものだな。
石田の『関数』とか。
0321デフォルトの名無しさん
NGNG0322デフォルトの名無しさん
NGNG今まで、
save( "fname",resize( 100,200,image));
って述語→目的語って英語の語順みたいに並んでたのが、急に
image.resize(100,200).save("fname");
って目的語→述語って、日本語風になっちまった。混在してて読みにくいんだよ！
save("fname")^resize(100,200)^image;
みたいに書くようにできんもんかね？
0323デフォルトの名無しさん
NGNGsyntaxの問題だけだもん。
0324デフォルトの名無しさん
NGNG目的語じゃない。主語だ。
image が saveするんだ。 image を save するんじゃない。
手続指向から早く脱しろよ。
0325デフォルトの名無しさん
NGNG命令文の主語は、二人称
そして、imageは三人称
そういうわけで、俺も違和感ある
自分で作るときは、関数記法を使えるようにしてしまうことが多いな
class foo {
public:
virtual int bar(int hoge);
};
inline int bar(foo& f, int hoge)
{
return f.bar(hoge);
}
こんな感じで
0326デフォルトの名無しさん
NGNGかわいそうな人のスレはここですか?
0327デフォルトの名無しさん
NGNGx.foo()が多態して、foo(x)が多態しないというのは、
c++とかの特定の言語の文法に限った話
しかもc++は、上記のように、多態させることも可能
foo(x)と書いて、普通にxの動的な型に応じて多態する言語もあるAdaとかな
さらに、foo(x,y)とかx.foo(y)と書いた時に
xとyの両方の動的な型に応じて多態して欲しかったら
(More Effective C++の項目31のような場合）
x.foo(y)という書式は非常に違和感がある
0328デフォルトの名無しさん
NGNGSmalltalk、C++、Javaのように obj foo: とするのか、
CLOSみたいに (foo obj) にするのか、
どっちだっていいし、どっちでも理解できた方がいい
obj.foo() にしないと理解できない>>322みたいな連中の事を言ってるだけなのに
そんなに必死に弁護せんでも
0329デフォルトの名無しさん
NGNGオブジェクト指向とオブジェクト指向プログラミングを
混同しているわけだが。。。
0330デフォルトの名無しさん
NGNGあたまにオブジェクトを持ってくるのは SIMULA からそうで、
単に関数の動的結合の際の名前空間の特定のためだから、主語とか
暗黙の第一引数とか、もっと言えばオブジェクト指向とか、そんなのとは
全然関係ないよ。 SIMULA の当時はオブジェクト指向なんて言葉すら
なかったからね。あったのはクラスとオブジェクトだけ。
もうちょっと勉強しようね。＞オブ厨
0331デフォルトの名無しさん
NGNG0332329
NGNG『オブジェクト指向』と
『オブジェクト指向プログラミング』と
『オブジェクト指向プログラミング言語』だ。
0333デフォルトの名無しさん
NGNGそれぞれの定義も出典も提示できん奴にフィーリングで分類される
オブジェクト指向もずいぶん不幸なパラダイムだなぁ…。
0334デフォルトの名無しさん
NGNGんじゃあ、お前が示せ。
0335デフォルトの名無しさん
NGNG0336デフォルトの名無しさん
NGNG0337デフォルトの名無しさん
NGNGいやいや。そもそもそんな区別はご都合主義の後付けだっていう反語だよ。
そんなことも分からんとは、ほんと駄目だな。オブ（理解できてると勘違いしてる）厨は…
0338デフォルトの名無しさん
NGNGたとえば、「構造化プログラミングとは？」との問いなら
「ダイクストラの本を読め」で終わる。
構造化プログラミングをあみ出したのはダイクストラだし
権威以前に、それが定義だ。
それがオブジェクト指向については聞いたこともない。
(知っている人いたら教えて)
0339デフォルトの名無しさん
NGNGで、俺が捕らえているオブジェクト指向は、
オブジェクト指向って哲学なんだよね数学じゃなくて。
(似ている領域ではあるが)
物や事象を人がどう認識するのかというところからモデリングする。
(そうすると現実の世界と将来を含めてモデルのズレが少なくなる。
人が認識できる範囲なんだから)
もっと手っ取り早い言い方すると、「それは何か？」っていうことを
とことんモデリングする。
ってところがオブジェクト指向なんだろうか？
具体的な作業レベルにまで落ちていないんでわからんが。
0340デフォルトの名無しさん
NGNGで、物や事象の認識は、種類で囲う方法や構造(どういう部品からできているか)
などがあってそれが継承や包含にあたる。ってとこかな。
だけどプログラミングの話で出てくる継承は
モデリングで出てくる継承以外に、プログラム的な都合による継承
(機能の追加や、ポリモフィズム。あ、ポリモは微妙だな)もあるので
その辺は別に考えないとごっちゃになるなっと。
これがオブジェクト指向の正解かどうかわからんが。変なら指摘してちょ。
むしろ議論は(前向きなら）ウエルカム。
0341デフォルトの名無しさん
NGNG誰が作った言葉かも知らないというなら、まず、coined-the-term-object-oriented
とかでぐぐれ。話はそれからだ。
0342デフォルトの名無しさん
NGNGみたいな勘違いを招きやすいから
オブジェクト指向は難しいと
おもわれるんだろうな。
0343３４０
NGNG>>341
んーで、答えはなんなの。なんでこう答えをズバット言えんの？
>>342
で勘違いを具体的に指摘してちょ。精進するから。
0344デフォルトの名無しさん
NGNGプログラムコードに乗せられると思っているところ
0346３４０
NGNGとりあえず、ぐぐってみたがアラン・ケイというキーワードがでる。
彼のことを言っていますか？
彼の編み出したオブジェクト指向というのは、「メッセージ指向」な予感。
今現在で言われているオブジェクト指向は、もうそれ以上のような。
0347デフォルトの名無しさん
NGNGそういったことをオブジェクト指向プログラミングが
目指しているわけではない。
0349デフォルトの名無しさん
NGNG抽象概念の導出だと思うんだけど、どうよ？
0350デフォルトの名無しさん
NGNGほんっとにお前はどーしようもないな。
メッセージ指向の何を知ってそれを言う？
お前の言う現実世界を云々は、まさにそれの受け売りだというのに。
そもそも当初の意味を失ったオブジェクト指向には
メッセージメタファ同様、もはや無用のコンセプトなんだよ。
では、誰がいつどんな定義で乗っ取ったのか？ ここからが本題だってえのに……
0353デフォルトの名無しさん
NGNG0354デフォルトの名無しさん
NGNG何か？を説明できないくせに
何かを説明するとバカにする
概念なんだな。このスレをみて、それだけはわかった。
0355デフォルトの名無しさん
NGNG0356デフォルトの名無しさん
NGNGooよりもポインタのほうが理解しずらかったんだけど。。
よっぽど教材が悪かったんか？
0357最凶VB厨房
NGNG0358デフォルトの名無しさん
NGNG教材によってOOの説明が違う。
昔の教材：継承による差分プログラミング
少し前の教材：クラスによるカプセル化
GoF後：抽象化の手段
初心者のころ一番悩んだのは
ワンとかニャーとかOOPLの機能自体はわかっても
その使い方がわからなかった
ポインタ型を覚えてもその使い道がわからなったのと同じ経験
0359デフォルトの名無しさん
NGNG同じooというシンボルに異なる意味があるから難しいだろうなと思う。
0360デフォルトの名無しさん
NGNG>ワンとかニャーとかOOPLの機能自体はわかっても
>その使い方がわからなかった
ワンとかニャーの話はオブジェクト指向言語の説明としては全く正しいけど、
オブジェクト指向設計の説明としては、だからなんなのとしか言いようがないね。
言語と設計を区別して説明しないといかんのだと思う。
0361デフォルトの名無しさん
NGNG0362デフォルトの名無しさん
NGNGお前はほんっとに駄目だなぁ…。ものには段階ってものがあるし、
それ以前に、つまらん知ったかで応酬したり、他人にものを要求する前に
自分のやるべきことがいくらでもあるだろう。たとえば、ぐぐって出てきた
最初のページくらい、ざっとでもいいから目を通してみたのか？ そこに
次のステップへのヒントがあるとは思い付かないのか？
0363デフォルトの名無しさん
NGNG今どきメイヤーなんか勧めるヤツの気が知れん。
ありゃ、理解を確認するための本で、学ぶための本じゃない。
書いてあることがぜーんぶ知っていることならセーフってなだけ。
知らないことが書いてあっても、それが何かをあれから学ぶことはできんよ。
0364デフォルトの名無しさん
NGNG0365デフォルトの名無しさん
NGNG言ったら同じように、突っ込みのマトにされるのがわかっていて、それが怖いだけ。
0366デフォルトの名無しさん
NGNG0367デフォルトの名無しさん
NGNGまあ、それは一理ある。
0368デフォルトの名無しさん
NGNGだけど、メイヤーは頭いいと思うよ。例外の定義のところで、
「事前条件が満たされているのに事後条件を満たせない状態が『例外』だ」って
書いてたけど、こんなすっきりした定義、なかなか、考えつかないと思う。
0369デフォルトの名無しさん
NGNG>>363 は読んでも分からんのが怖くて読まずに批判だけしている厨房
0370デフォルトの名無しさん
NGNGだからって何でもかんでもExceptionを投げるのは馬鹿だよな。
0371デフォルトの名無しさん
NGNG>>368の意味理解してないだろ
0372デフォルトの名無しさん
NGNG0373デフォルトの名無しさん
NGNGつまり理解してない馬鹿がJAVAを作ったという事か？
0374デフォルトの名無しさん
NGNG>>370とか>>373には、意味論の入門書（特に公理論的意味論）の
目次とかindexだけでも見てほしかとです。
ヒロシです…
ヒロシです…
こうして今日また、まんまと釣られてしまったとです。
ヒロシです…
0375デフォルトの名無しさん
NGNGその通り。いまごろ気付いたの？
0376デフォルトの名無しさん
NGNG簡単な掲示板を作ろうと思ったんですが
いきなり躓いています。
0377デフォルトの名無しさん
NGNGそれだけ言われてもどうしようもないんだが。
0378376
NGNGクエリを何十回も発行しなきゃいけなくなるんですがこれでいいんでしょうか
パフォーマンスがすごい落ちそう。
0379376
NGNG別々のクラスを作ればいいのか
でもそれもなんか変な気がする。あｆｄさｆｄｓｋｆｊさｆｌうぇあｑｗせｄｒｆｔｇｙふじこｌ
0380376
NGNGいちいちオブジェクトのプロパティにオブジェクトの参照を代入しなければならないのが面倒。
だいたい参照を持たせるのなら
その時点で結合度が高くなって一つの変更が局所化できなくなる。
オブジェクト指向プログラミングに何の利益があるのか。
0381376
NGNG0382デフォルトの名無しさん
NGNG最近にぎやかに議論されておる所になると思います。
DIについてはSpringやseasarというフレームワークについて
調べてみると良いかも知れません。
特に380の疑問点には、DIの考え方は
ほほーとなると思います。俺もなんかすっきりしました。
まだ実案件で使った事ないんですけどね。
私は国産なのでseasarが良いなーと思ってます。
tp://www.seasar.org/
つか、あまりにもスマートな疑問の湧き方なので
ネタかとも思いましたが、一応。
0383デフォルトの名無しさん
NGNGhttp://www.amazon.co.jp/exec/obidos/ASIN/4797323361
分厚くて高いですが、すいすい読めてお勧めです。
私はあまりOO大好き人間ではないのですけれど、
interfaceを中心に設計して、実装と切り離して疎結合を実現する
オブジェクト設計の原則は大変為になりました。
DIはそのinterfaceに対する実装を実行時に行うイメージですかね。
0384376
NGNGぐぐりつつ勉強します。
とりあえず
message
messagelist
controller
db_message
のクラスを作った。
messsageに新たな項目を増やそうとすると
controller message db_message
クラスを変更する必要がある。
メッセージのソート方法を追加しようとすると
controller db_message
クラスを変更する必要がある。
一つの変更が全体に影響するよい例を作ってしまった。
何これ(´A`)
0385376
NGNGdbのフィールド名とmessageクラスのプロパティの変数名を
関係づけるためのクラス。
値しか持っていない。
0386デフォルトの名無しさん
NGNG流れていくものだから、入力項目追加の影響が
全体に波及するのはしょむない事だと思いますよ。
mapperクラスかあ。俺はすぐあるもの使う奴だけど
一度自分でやってみてからO/Rマッピングとか触れたら
面白さとか全然違うんだろうなあ。
頑張って下さい。
0387376
NGNGありがとうございます。
db_messageクラスは
messageの項目の増減に影響されないように
コーディングできました。
ただし、トリッキーなコードになってしまった。
0388376
NGNGこのページで依存性注入読みました。
これはおもしろいですね。
逆に、実装側のオブジェクトを引数として与えるんですね。
なるほどって感じです。
おもしろい。
使ってみよう。
0389デフォルトの名無しさん
NGNGseasarの記事がありますんでオススメ。
DIのよさがかなり判りやすく書いてありました。
tp://www.gihyo.co.jp/magazines/wdpress/archive/Vol22
この号は他にも逆引きデザインパターンとか
なかなか面白かった。
あとseasarはスレもあります。
国産DIコンテナSeasarとくーす その３
http://pc5.2ch.net/test/read.cgi/tech/1102862221/l50
0390376
NGNG飼いましたイイです！
>>389
ヨドバシいってみます。
ところで、DBのフィールド名と、それに対応するModel層のオブジェクトのプロパティの
変数名を一致させるという拘束は
一般的に許容できる程度の拘束なんでしょうか？
0391デフォルトの名無しさん
NGNG一般的なO/Rマッピングフレームワークだと（EJBもそうだけど）
DBフィールドとオブジェクトの変数名は
一致させなくてもいい作りになってますね。
XMLファイルなどでマッピングの情報を持ったりします。
DBとオブジェクトのマッピングを自前でやる場合は
もうそれこそ俺ルールで構わないと思います。
奥義、いっすよねー。分厚くて高いけど、
すいすい読めるし元は取ったなあ。
0392=! 340
NGNGSmalltalkのメッセージ指向から
Simulaのシュミレーション処理と複雑さの管理へと辿る訳ですか？
もし、そうだと仮定し早漏気味に考えると
オブジェクト指向という言葉群が取扱う対象は、モデル対象自体の複雑性であって
データという、それ自体の難しさを解決する物では無い。
つまり別に現実であるリアルだろうが、仮想であるシステムだろうが、
存在箇所がどっちでも構わない「情報」を、扱う事が目的である業務システムでは
オブジェクト指向という言葉群の概念だけでは事を成し得ないと
考えられているのでしょうか？
この結論で今までの霧が晴れた様に感じているのは幻想なのか？
0393デフォルトの名無しさん
NGNG0394392
NGNG簡単に且つ間違いを恐れずに言えば、構造化分析や構造化設計の勉強を抜きで
オブジェクト指向分析やオブジェクト指向設計でシステム開発が出来ると思っていた。
つまり、オブジェクト指向分析やオブジェクト指向設計だけでは
最後まで到達出来ない領域があって、そこの解決手段に悩んでいた。
って言って通じるかな？
0395デフォルトの名無しさん
NGNG相対性理論や量子力学を理解できるはずもない
0396デフォルトの名無しさん
NGNGそれは理解力の話ではなく前提知識という意味で？
0397デフォルトの名無しさん
NGNG話ばかりで…orz状態です。
大抵の先生は、若くて綺麗なねーちゃんなので、それはそれで楽しい
のですが…、
みんな、あんな講座受けて理解しているのだろうか？
それとも、洩れ見たいに、いつまでも理解できんのだろうか？
0398デフォルトの名無しさん
NGNGどこがわからないの？
0399デフォルトの名無しさん
NGNGまず手続き型言語（Ｃなど）をやってから、それとの違いを意識しながら
勉強すると効率いいと思うんだけど。遠回りだが。
0400デフォルトの名無しさん
NGNGまあ、今のオブジェクト指向は手続き型言語をベースにしているからね。
オブジェクト指向言語を駆動しているツールを知るのも悪くないかも。
ただ、オブジェクト指向と手続き指向は、それぞれ目指している
理想像が結構違ったりするところもある。んで、そのあたりが
ごっちゃにならないようにしないとね。
0401376
NGNG0402400
NGNG結構違うと思うよ。
一番違うのが、
手続き指向：シングルスケール
オブジェクト指向：マルチスケール
な点じゃないかな。
手続き指向は細部まで作り込みできるから最適化しやすいけど、
規模が大きくなると大変……
0403デフォルトの名無しさん
NGNG（どうしても各モジュールの依存関係が強い)
オブジェクト指向やり初めて、デザパタ勉強したあたりから
自然と独立度の高いモジュール化ができるようになったなぁ。
多分今なら手続き型でも独立度の高いモジュールを作れるんだろうけど。
0404397
05/01/19 19:44:43何が分からんと言う答えには、正直つまってしまう。ｗ
説明してることは、（やさしく説明してくれるので）大変良く分かるんですけど、
概念レベルでは、ホニュウ類とハチュウ類とか、そんな例え話ばかりで。
しかも、いざ作業レベルにはいっても
ＧＵＩでツールをペタペタはるだけ。
オブジェクト指向の本質って何？？？っていつも思ってしまう。
ちなみに、ＣやＰＥＲＬは仕事で普通に書いてる非常に経験の長い
（Over 20）ジジイだったりします。
0405デフォルトの名無しさん
05/01/19 20:55:03オブジェクト指向は、その名詞で表せるものを現実世界のように取り扱うって考え方で。「○○をどうする（会議を開く）」とか。
違うかな。
猫とか犬とかの動物が鳴くって考え方よりマシだと思うんだが。
で、実践UMLの内容は正しいって考えて良いんだよね？
オブジェクト指向の本質に入るなら、これが良い入門書になると思うんだ。
間違ってたら指摘きぼん
0406デフォルトの名無しさん
05/01/19 21:06:12オブジェクト指向は流派や流儀が多くて、
一概には定義できま（ry
0407デフォルトの名無しさん
05/01/19 22:25:09はいくつかありますが、そんなに多くはないですよ。根底を流れる
コンセプトを論文を読んで学ぶのではなく、そのインスタンスに過
ぎない言語の使用経験から得た知識や感触から語る人が多く、さら
にそこから又聞きで広めようとする風潮があるから混乱に拍車がか
かるのだと思います。犬猫の類なんかその典型的な例でしょう。
0408デフォルトの名無しさん
05/01/19 23:07:42何か釈然としないものが残るのはなんでだろう。
0409デフォルトの名無しさん
05/01/19 23:41:33しかも、語る人によって解釈も説明も大きく違う。
オブジェクト指向系の人を２人つれてくると、必ず（ry
0410デフォルトの名無しさん
05/01/20 01:15:16業務用アプリケーションじゃ走ったり飛んだりの自発的動作をしてくれそうなオブジェクトは
ユーザーぐらいしか見つからないもんな。
0411デフォルトの名無しさん
05/01/20 02:44:23つまり正解はないけどハズレでもない・・・ってことだよね。
0412398
05/01/20 03:07:00「オブジェクトは小さなプログラムと似ています」だって。
マルチスケール性を言いえて妙だね
>404
>オブジェクト指向の本質って何？？？っていつも思ってしまう。
>406の言う通り、本質はいくつもあるし言う人によっても変わるけど
取りあえず私の私見は、
常に慣れ親しんでいる現実世界のメタファーをうまくプログラムに
取り込むためのもの。そのために、現実世界の「対象」という概念を
表現する枠組みを用意したもの。
じゃないかな、と思います。
で、「対象」という概念を使うと、
・同じような「対象」をグループ化することができる
・同じような「対象」は同じように操作できる／動作・反応する（is-aの関係）
（その他 has-a, imprement-of……）
・「対象」の中の構造を知らなくても、操作に対してどのように反応するかを
知っていれば「対象」を操ることができる（カプセル化、インターフェイス）
とか、色々便利なことが（少ない学習で）活用することができます。
0413デフォルトの名無しさん
05/01/20 22:00:36何でオブジェクト指向の説明って、何の言語かも分からない説明を
使いたがるんだろうねぇ？
例）メタファー
0414デフォルトの名無しさん
05/01/20 22:06:51得られない。
初学者は、ifやwhileを覚える前にまずオブジェクト指向を
徹底的に学習し、その概念をある程度掴んで置く事が大切だと
講師に言われた事がある。
始めは、難しさから反発したのだが、勉強が進むにつれ
確かにその通りだなって思うようになったよ。
0415デフォルトの名無しさん
05/01/20 22:35:22かっこつけている面もあるけど、英語の方が概念をうまく表せることが多いぞ。
0416デフォルトの名無しさん
05/01/20 22:53:180417398
05/01/21 00:50:44日本語で近いのは「隠喩」だけど……「象徴」という概念も含むし、難しいね。
0418デフォルトの名無しさん
05/01/21 05:43:52> 何でオブジェクト指向の説明って、何の言語かも分からない説明を
> 使いたがるんだろうねぇ？
> 例）メタファー
正直言ってあなたの日本語もどうかと思います。
>>415-が苦もなく理解してるのがすごい。それとも俺の読解能力が低いのか？
0419デフォルトの名無しさん
05/01/21 11:39:130420デフォルトの名無しさん
05/01/21 11:59:53だよね。隠喩とか無理して日本語で言われても何のことだかさっぱり。
0421デフォルトの名無しさん
05/01/21 12:05:25こういうのが我が物顔にはびこるから混乱するんだ。
0422デフォルトの名無しさん
05/01/21 22:10:48剥げ同。
フェノメナが、きちんと記述されていない。
0423デフォルトの名無しさん
05/01/21 22:12:28フェラとは違うの？
0424デフォルトの名無しさん
05/01/21 22:19:100425デフォルトの名無しさん
05/01/21 23:32:00お前、いいオブジェクト使いになれそうだなｗ
そのなんとなく分かりそうで分からない単語ｗ
0426デフォルトの名無しさん
05/01/22 10:25:39ついつい「ワンワンスタイルで…」などと想像してしま（ry
0427398
05/01/22 12:40:40GUIと言えば、こんな記事あったよ
ttp://pc.watch.impress.co.jp/docs/2005/0121/config035.htm
>421
それだけじゃなぁ……
・駄目なオブジェクト指向の説明とする根拠
・良いなオブジェクト指向の説明
のどっちかぐらい論理展開してよ。批判にもなってないよ。
>422
フェノメナってなに？
0428最凶VB厨房
05/01/22 13:06:37それ以上の意味はない
0429デフォルトの名無しさん
05/01/22 13:32:090431デフォルトの名無しさん
05/01/22 15:13:43いや、それがオブジェクト指向の文脈だとどういうい意味なのかと……
>428
いや、それは手段であって、そのものじゃないと思うけど。
0433デフォルトの名無しさん
05/01/22 15:32:10コンストラクタも関数？
0434デフォルトの名無しさん
05/01/22 15:53:36違うの？
0435デフォルトの名無しさん
05/01/22 22:12:20ハゲ同なんだが、それ以外の考えってある？
0436431
05/01/22 22:49:06意味ということなら、ちょっと簡単化しすぎかなぁと思う。
確かに状態を表す変数とふるまいを表す関数をセットにしたのが
オブジェクトだけど、あるクラス（分類・凡例）のインスタンス（事例）
としての意味もあるしね
0437デフォルトの名無しさん
05/01/23 00:13:38のアレ？
0438最凶VB厨房
05/01/23 09:33:15当然だ。変数と言うのは必ず初期化しなければ
ならない。そうではなかったかな？
>>435
>>436
のようだ。
俺にはほとんど理解不能だね。
0439デフォルトの名無しさん
05/01/23 12:07:19大事なのは、クラスだ。クラスは我々に“データ型”を定義する自由を
与えてくれる。オブジェクト指向なんて、どうやってうまく完璧で安全で
使える“型”を定義するかってだけのことだ。ワンニャンなんて関係ない。
現実世界云々なんてのはSmalltalkローカルな考え方に意味も分からず
翻弄されているだけ。
0440デフォルトの名無しさん
05/01/23 15:10:25静的チェックは大好きだけどプロトタイプベースの訳わかんない動的さもイカス。
0441デフォルトの名無しさん
05/01/23 18:21:25ユーザー型定義でいいんだったら別にクラスである必要も無いけどね。
オブジェクト指向だとユースケースとかアクターとかでモデル化されることが
多いけど、これはクラスという概念に納まっていないんじゃない？
0442デフォルトの名無しさん
05/01/23 19:31:42（SIMULA発祥の）クラスなんだよ。他にあるからなんだってえの。
モデル化云々いったって、結局最後はどう型に落とし込むかだし。
0443デフォルトの名無しさん
05/01/23 19:32:440444デフォルトの名無しさん
05/01/23 19:39:280445デフォルトの名無しさん
05/01/23 20:21:29型のある言語ならな
0446デフォルトの名無しさん
05/01/23 23:10:28勉強になった。（例：Ruby）
0447デフォルトの名無しさん
05/01/24 00:31:46クラスは、つまりSimulaのクラスは、オブジェクト指向のために作られた
ものではないという但し書きは入れておいたほうがよいでしょう。混乱
する人もいるかもしれませんが、オブジェクトすら、オブジェクト指向の
ために作られたものではないのです。これはオブジェクト指向が何かを
語る前に是非知っておきたいことのひとつだと思います。
ユーザー定義の型という考え方はSimula以前にもなかったわけではありませんが、
注目を集めたり、実装して試されるようになったのは、Simula以降です。
したがって、ユーザー型定義の手法がいくつかあったとしても、その多く
は、Simulaのクラスをヒントに考案されたものがほとんどです。なので、
オブジェクト指向の本質を型定義とするなら、これら（抽象データ型）との
差別化についても言及する必要はあるのでは？
0448デフォルトの名無しさん
05/01/24 00:46:160449デフォルトの名無しさん
05/01/24 21:46:080450デフォルトの名無しさん
05/01/24 23:10:44まあ、抽象データ型に分類される言語もオブジェクト指向言語だと
信じて疑わない人も多いから明確な区別はできないんでね？
オブジェクト指向設計を言い出したBoochタソはいってもAdaな人だし。
0451デフォルトの名無しさん
05/01/25 11:07:28オブジェクト指向の本質は
オブジェクト（インスタンス）と
その振る舞いの定義であって
クラスや型といったものは本来その実装手段に過ぎない。
つーか何人か指摘してるけど
プロトタイプベースのオブジェクト指向言語は
仲間はずれっすか？
http://sumim.no-ip.com:8080/wiki/493
0452デフォルトの名無しさん
05/01/25 11:39:43動的→遅い。
静的→速い。
速ければ速いほど良い。
0453デフォルトの名無しさん
05/01/25 12:41:24だから、それは安全で使用に耐える型の定義と同義だろ。
メモリ上のデータに「振る舞い」とか言うな。気色悪い。
プロチはSmalltalkのエッセンスを抽出しただけのモノだから
Smalltalkと同じ穴のムジナ（振る舞いとか言い出すクチだ…）だし、
現在主流のオブジェクト指向とはそもそも関係ない代物だよ。
お情けでオブジェクト指向を名乗らせてあげてるだけで。
型安全性もクソもないじゃん。あんないい加減な言語。
じゃあ逆に聞くけど、プロチな言語処理系のほとんどすべてに
クラスが実装されているのはナゼさ？
0454デフォルトの名無しさん
05/01/25 13:35:32速くて動的ならいい？ そんなわきゃあない。
0455デフォルトの名無しさん
05/01/26 02:41:22>型安全性もクソもないじゃん。あんないい加減な言語。
なんか……設計の柔軟性と引き換えに型安全性が
弱くなっていることを解っていないのかなぁ。
>じゃあ逆に聞くけど、プロチな言語処理系のほとんどすべてに
>クラスが実装されているのはナゼさ？
設計が固まった後に（クラス指定による振る舞いの固定化で）
予定外の状態になることを防いでいるんじゃない？
0456デフォルトの名無しさん
05/01/26 02:46:310457455
05/01/26 02:58:01読んどけ。な
設計とは、制約を課す作業のことです。従って、
設計指向のライブラリは、 *設計済みの制約*
ではなく、*ユーザの考え出した設計自身の制約*
を強制するように支援しなくてはなりません。
至極名言だな。強い静的型付けだと*設計済みの制約*て
やつに縛られやすく、プログラマがそこから逃れるのが
とても大変なんだよねぇ
＃Modern C++ DesignではTemplateによるシンタックス指向と
＃オブジェクト指向を組み合わせたマルチパラダイムによる
＃解が紹介されていますな。
0458デフォルトの名無しさん
05/01/26 03:57:16残った気がする。このスレは。
0459デフォルトの名無しさん
05/01/26 13:37:13オブジェクトとオブジェクト指向プログラミング（言語）について考えてればそれで満足なのれすよ
0460デフォルトの名無しさん
05/01/26 23:33:250461デフォルトの名無しさん
05/01/26 23:37:290462デフォルトの名無しさん
05/01/27 19:19:220463デフォルトの名無しさん
05/01/27 20:29:00>現在主流のオブジェクト指向とはそもそも関係ない代物だよ。
主流でないからといって無視してよい理由にはならない。
異動車両のほとんどに車輪が使われているからといって
キャタピラやソリその他がまったく不必要なわけじゃない。
0464デフォルトの名無しさん
05/01/27 23:28:04装軌戦車なんか時代遅れ。
これからは装輪ですよ。
0465デフォルトの名無しさん
05/01/28 13:47:53無視できない存在だからといって、
節操なく取り入れてよいということにはならない。
移動車両における車輪の使い方もよく分かっていない状態で、
キャタピラやソリが便利だからといって取り入れたところで混乱を招くだけ。
0466デフォルトの名無しさん
05/01/28 14:42:060467デフォルトの名無しさん
05/01/28 23:01:02主流かどうか「のみ」でものごとを判断するのはちょっと……
「小人は同じて和せず」と論語にもあるしね。
>移動車両における車輪の使い方もよく分かっていない状態で、
>キャタピラやソリが便利だからといって取り入れたところで混乱を招くだけ。
どういう時に使うべきでどういう時に使うべきでないかを理解していない
うちは、使い方が解ったなんて恥ずかしくてとても言えないねぇ
車輪が不便だと解っているのに、ソリの代わりに車輪を氷上で使うのは
ちょっとなぁ……
車輪の性能が上がっているので強引に押し通すこともできるけど、
マルチパラダイムで適材適所で使えばいいじゃん。
0468デフォルトの名無しさん
05/01/28 23:39:280469デフォルトの名無しさん
05/01/31 14:14:150470デフォルトの名無しさん
05/02/01 01:15:53どっか別の所で見たぞそのネタ。
ここだっけ？
ハンニバルっていったら人食いじゃなくて
こっちだよなー。
0471デフォルトの名無しさん
05/02/01 14:36:41スゲー感動した！！
インタフェースとコンポジションとの組み合わせ最高！！
0472デフォルトの名無しさん
05/02/04 00:50:16こんなのもあったぞ
設計というものは、・・・できることとできないことを実行前に
決定する規則を完備したものなのではないでしょうか？
0473デフォルトの名無しさん
05/02/04 01:16:420474デフォルトの名無しさん
05/02/08 22:14:42決定する規則を完備したものなのではないでしょうか？
ポリシーというものは、できることとできないことを実行前に
決定する規則を完備したものなのではないでしょうか？
・・・何にでも当てはまるな
0475デフォルトの名無しさん
05/02/22 02:58:48汎用性があるとか普遍的だとか言ってやれ。
0476デフォルトの名無しさん
2005/03/29(火) 00:59:54設定ファイルのようなものを作りたいのですが、
今までの非OOPのようなCで言うところのdefine定義を羅列した
ファイルを設定ファイルとしてインクルードする方法はどうかと思い、
コンストラクタでデータを定義したゲッターのみのクラスを作ろうかと
考えたのですが、一般的なオブジェクト指向プログラミングにおいて
設定ファイルのようなものはどのような形にするべきなのでしょうか？
オブジェクト指向プログラミング初心者なので変な質問かもしれませんが
指揮者のご意見をお聞かせいただければと思います。
0477デフォルトの名無しさん
2005/03/29(火) 01:03:05stdafx.h
0478デフォルトの名無しさん
2005/03/29(火) 01:53:20Object Persistency
または
Persistent Object
0479デフォルトの名無しさん
2005/03/29(火) 03:29:13pear/Config :-p
0480デフォルトの名無しさん
2005/04/30(土) 16:58:06ところで、状態を持たないオブジェクトを扱える言語ってある？
0481デフォルトの名無しさん
2005/05/01(日) 13:45:310482480
2005/05/01(日) 20:33:40状態を持たないオブジェクトしか扱えない言語ってある？
0483480
2005/05/01(日) 20:34:25初期状態から変化しないとか、そういう意味で。
0484デフォルトの名無しさん
2005/05/01(日) 21:29:470485デフォルトの名無しさん
2005/05/01(日) 21:34:050486デフォルトの名無しさん
2005/05/01(日) 21:35:57>>480
オブジェクト＝データ構造＋処理
として、状態を持たない/状態変換のないオブジェクト
って具体的にどういう事なの？
0487デフォルトの名無しさん
2005/05/01(日) 21:36:30○状態変化
0488480
2005/05/01(日) 21:55:23え〜っと、インスタンス変数が全部 readonly な奴です
ローカル変数はどうだって良いや
あるメソッドに渡したオブジェクトが意図しない改変されてたら迷惑だな〜って思ったんですが、
んじゃ状態変化が無いオブジェクトを扱う言語ってあったかな？ って、ふと思いまして
0489デフォルトの名無しさん
2005/05/01(日) 22:23:50Immutableパターン？
単純な不変オブジェクトが欲しいなら、セッターメソッドを提供しない
だけで済むと思うが・・・・・・
FactoryやDIと組み合わせるパターンは・・・・・・まっ、いいかｗ
0490480
2005/05/01(日) 22:32:45Immutable パターンって言うのか。結城本しか持ってなかったから知らんかったよ。ﾄﾝｸｽ
とりあえず、不変性を確保できる言語はあるけど、変更できない言語はあったかな〜って思っただけなんで、
チラシの裏的発言と思ってもらえれば ^-^;
0491デフォルトの名無しさん
2005/05/01(日) 22:33:29大きな誤解があると思う。
Java以降のやり方としては、
Immutableなインタフェースを作ってメソッドに渡せば、
オブジェクトの内部状態へのアクセスを制限できるのだが。
0492480
2005/05/01(日) 22:35:44結城本でもこっちは持ってなかったわ。
0493デフォルトの名無しさん
2005/05/01(日) 22:45:29そのパターンに当てはめた質問をすると、
なにか楽しい事があるのですか？
あなたの質問には、その質問をするに至った思考過程や、
シチュエーションというものが欠けている。
それが、「問題定義をきちんとせずに、答えを出してきて、周りが付いて来ない」
という現象なんですが。
0494デフォルトの名無しさん
2005/05/01(日) 22:48:28・そこら辺の問題意識や背景情報を、素人向きにネグっちゃってる点
・素人がそのパターンを丸暗記して、無理に現実に適用しようとする点
が、結城本の大きな問題点だと認識している。
0495デフォルトの名無しさん
2005/05/01(日) 22:56:07＞そのパターンに当てはめた質問をすると、
＞なにか楽しい事があるのですか？
パターンがあるとは知らなかった。許してくれ
＞その質問をするに至った思考過程
あとだしじゃんけんみたいで済まないが、理由は >>490 ということで
0496デフォルトの名無しさん
2005/05/01(日) 22:56:58彼はこのスレで結城さんのThreadパターン本や、
その他のデザイン・パターンの話題をしたいのだろうって。
付き合ってあげたら？
0497デフォルトの名無しさん
2005/05/01(日) 22:59:58んなわけあるかい
たまたま出てきただけじゃ
まぁ、そう熱くなるなって
0498デフォルトの名無しさん
2005/05/01(日) 23:02:040499デフォルトの名無しさん
2005/05/01(日) 23:04:04っていわれてやった事あるんだけど、
あのサンプル・プログラムは、初心者の独習用であって、
わざわざ時間かけてこっちが説明するにはキツイ(シンプル過ぎて実践的でない)
と思う。
例えば「Observerパターン」。
彼のサンプルは、Window Frameに一つのEventListenerを置き、
そこから各GUIパーツにイベントを振り分ける、というコードなんだが、
これって古いAWTのモデルとも、SWINGのモデルとも合致しない、
説明のための説明みたいな非現実的なコードなんだよな。
で俺はプロだから、結城さんのやり方、AWTのやり方、SWINGのやり方と、
三通りを説明する必要に迫られる。
実際アプリで使うのは、JBuilderが吐くSWING流のやり方だからね。
すると、説明が非常に難解で、初心者諸君にわかりにくいものになる。
0500デフォルトの名無しさん
2005/05/01(日) 23:04:20て言うか、結城本てぶっちゃけカタログだから、あれでは何も学べない。
それは辞書だけで英語を学ぶ様なもんだ。
プログラムデザインやJAVAの格言なんかでは、SingletonやImmutable
の様な、それ自体は単純だけどその先が意外と深いものについてもき
ちんと説明されてる。
結城本を買うくらいなら自分の単価分ググった方がマシ。
0501デフォルトの名無しさん
2005/05/01(日) 23:06:28独習したいなら結城本も結構でしょう。
俺が教えるなら、GoFなり"Pattern Language of Programming Design"1〜4から選んで、
サンプルプログラムを適切なものに修正して、説明する。
それだけの話だ。
0502499=501
2005/05/01(日) 23:08:14GoFから表面掬い取った似非入門書に過ぎない、と思う。
0503デフォルトの名無しさん
2005/05/01(日) 23:09:48深い所を求めるなら、
・結城本
・Javaの格言
などというゾッキ本だけでなく、
ちゃんと原典に手を伸ばして、
わかんなくなったらゾッキ本でカンニングするのが良い
0504デフォルトの名無しさん
2005/05/01(日) 23:11:26カタログ本というのは、
・Design Language of Program Desing
・Architecture Pattern
のようなのを指す。
0505489
2005/05/01(日) 23:13:58自分で使っといてなんだが、Immutableはそれ自体が意味を持ってるから
別にパターンじゃないし、結城本に出てくるImmutableパターンと今回の回
答にはあまり関連がないぞ。
>>480
>>491をスルーするな。君の疑問に対しては彼の回答こそが正しい。
0506デフォルトの名無しさん
2005/05/01(日) 23:14:33充分一般的な問題定義などする能力もなく、
あらかじめ回答を決めて質問してくるようなのが、
２ちゃんの煽りなんだよ。
ほっとけって
0507デフォルトの名無しさん
2005/05/01(日) 23:16:37読みにくいだろ？それ見栄とかカッコ付け抜きに本気で思ってる？
0508デフォルトの名無しさん
2005/05/01(日) 23:18:01なんでこんなに必死なの？
0509デフォルトの名無しさん
2005/05/01(日) 23:40:31読みにくい？じゃぁ水で薄めた読み易い本を読んどけばええやん。
俺は、わざわざセンスが悪い本を読んで、苦労したいとは思わない。
>>508
まぁええやん。
>>499訂正
・結城本のEventHandlerは、GUIと無関係なアプリ側に実装。
アプリがイベントを解釈し、GUI部品の拡張メソッドを操作。
0510デフォルトの名無しさん
2005/05/01(日) 23:45:49すごい薄っぺらい理解でデザパタ騙るのが多いのは、
やっぱゾッキ本のせいなのか
0511デフォルトの名無しさん
2005/05/02(月) 00:25:11GoF自体、C++とSmalltalkを扱った古い本だからなぁ〜
ここ数年の間にこの分野に入ってきた若手には、キッツイんだろうよ。
さりとて、JavaやC#に焼きなおしただけでは通用しないパターンも多いし。
いい加減、新しい世代のデザイン・パターン本が欲しいな。
あと、PoEAAとかドメイン・パターンとか、もっと高レベルで実用になるパターンの普及も必要だ。
0512デフォルトの名無しさん
2005/05/02(月) 00:38:40知ってる単語と書籍名を並べて何か語った気になりたい奴は
今がチャンスだ。
0513デフォルトの名無しさん
2005/05/02(月) 00:40:53２ちゃん常駐コーダー様が、ありがたいお言葉を語るそうです。
ところでオマエ高校出てたっけ？ｗ
0514デフォルトの名無しさん
2005/05/02(月) 00:42:39チンパンジーくんのワンマンショーの開始です
物を投げたりせず、生暖かく見守ってあげましょう
====================================================
0515デフォルトの名無しさん
2005/05/02(月) 00:48:090516デフォルトの名無しさん
2005/05/02(月) 00:51:31http://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/
同じ展開ワラタ。
以後この展開をチンパンジーパターンと命名する。
0517デフォルトの名無しさん
2005/05/02(月) 00:56:34オマエは低能な質問しかできねぇ屑だから、
チンパン扱いされてるんだろｗ
さっさと動物園に帰れって。目が真っ赤だぞ(ｹﾞﾗｹﾞﾗ
0518デフォルトの名無しさん
2005/05/02(月) 01:06:320519【(ｹﾞﾗ】の検索
2005/05/02(月) 01:16:50517
ＰＣ等 [プログラム] ■暗号技術【ROUND2】■
200
ＰＣ等 [プログラム] 【初心者】プログラム初心者に最適の言語ってなに？
100
ＰＣ等 [プログラム] プログラミングなんか興味ねぇんだよ！！
32
ＰＣ等 [プログラム] NetBeans / Sun One Studio
19 74
ＰＣ等 [プログラム] 【Java】次世代Java・J2SE1.6の動向【Mustang】
96 313
0520デフォルトの名無しさん
2005/05/02(月) 01:17:09202 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 件見つかりました】
0521デフォルトの名無しさん
2005/05/02(月) 21:27:20http://www.aw-bc.com/catalog/academic/product/0,1144,0201607344,00.html
0522デフォルトの名無しさん
2005/05/02(月) 22:16:59>>501
ソフトウェア・パターン http://www.amazon.co.jp/exec/obidos/ASIN/4320120159/
0523こっち
2005/05/02(月) 22:52:01>>501＝PLoPD
プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集
http://www.amazon.co.jp/exec/obidos/ASIN/4797314397/
0524デフォルトの名無しさん
2005/05/16(月) 21:31:07書き込ませていただきます。
C♯を使用していますが、不特定多数のオブジェクト (仮に Objects とする) を一括で管理する必要が
あり、コレクションを使って管理しようと考えました。管理を行うコレクションのクラスを static 宣言するという
手段は一般的に相応しいものなのでしょうか。
よろしくお願い致します。
0525デフォルトの名無しさん
2005/05/17(火) 12:47:10すべきではないので染んでください
0526デフォルトの名無しさん
2005/05/17(火) 13:04:09これにはそうやってますと書いてあったからいいんじゃないの
http://www.amazon.co.jp/exec/obidos/ASIN/4822221180
0528デフォルトの名無しさん
2005/05/30(月) 16:52:07そのコレクションが複数のスレッドからアクセスされるなら、同期の問題が発生しますよ。
また、コレクションに追加されたオブジェクトをいつ誰が廃棄するのか、という点もあります。
本当に必要でなければ、避けた方がよいのでは？
0529デフォルトの名無しさん
2005/05/30(月) 17:38:22ステートレスに設計する必要がありますなー確かに。
キャッシュみたく考えてるんだったら
ステートレスにしておけば、廃棄されてたらまた生成、みたく出来る。
デザインパターンで名前付いてたな。こういうの。
0530デフォルトの名無しさん
2005/05/30(月) 20:49:57一括管理と書いてあるだけで、
複数スレッドで共有して使いまわすなんて
ひとっことも書いてねぇ〜だろ（ぷ
0531デフォルトの名無しさん
2005/05/30(月) 20:52:320532デフォルトの名無しさん
2005/05/31(火) 10:31:29アドバイスとしちゃ言っといた方がいいと思うよ
もしwebアプリだったらなおさら。
0536528
2005/05/31(火) 13:09:310537デフォルトの名無しさん
2005/05/31(火) 17:24:44ヒアリングはスムーズに行ったのに
実装時にどでかい仕変が待っていた
なんてトラブルは大概こういう人がリーダーなんだよ。
って釣られたのかなー。
0538デフォルトの名無しさん
2005/05/31(火) 18:18:170539デフォルトの名無しさん
2005/05/31(火) 23:27:16書くための道具だね。
オブジェクトを使うと、読みやすいプログラムは出来るけど、出来上がった
コードは、必要以上に膨らんで、重いし、めちゃくちゃ効率が悪い。
立ち上げに一分以上かかるような、＞GBの巨大なプログラムを書いて
喜んでるオブジェクト厨のお陰で半導体業界は儲かってるようなもんだな。
窓一つ出すだけでも、スーパーコンピューター並みのCPUが必要だし（藁
0540デフォルトの名無しさん
2005/06/01(水) 13:01:16＞オブジェクトって、結局、必要以上にでっかくて重たい重たいプログラムを書くための道具だね。
これは当たっていると思うけど、その後の文、なんか変じゃないか？
0541デフォルトの名無しさん
2005/06/01(水) 13:34:570542デフォルトの名無しさん
2005/06/01(水) 19:44:120543デフォルトの名無しさん
2005/06/01(水) 20:15:200544デフォルトの名無しさん
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
0545デフォルトの名無しさん
2005/08/03(水) 16:04:230546デフォルトの名無しさん
2005/08/12(金) 01:28:01どっちにメソッドをつければいいのかが良く分からない。
例えば、画用紙に、クレヨンで、四角を書く場合、とか、
将棋で将棋盤上の飛車があるマス目に移動できるかを判定する場合とかが
解りません。
画用紙の場合だと
画用紙
クレヨン
四角 extends Shape
って感じにクラスを抽出するとおもうんだけど。
書くというメソッドはどこにつけるのだろう？
Shapeにつけて置いて、
四角でオーバーライドすればポリモーフィズムっぽい感じもするし、
実際、多くの解説本とかだとそういう説明がなされているけれど、
Java2Dとかだと、画用紙#draw(Shape)って感じになってる。
将棋の例だと将棋盤でも駒でもなくて審判クラスを作れなんて書いてある本も多いけど、
だったら画用紙は画家クラスでも作るのか？とか悩んでしまう。
なにか、良い判断基準ってないのでしょうか？
0547デフォルトの名無しさん
2005/08/12(金) 13:29:420548546
2005/08/12(金) 19:29:40そうなんですか？
でもそうするとほとんどメソッドは人間クラスが持つことになっちゃう上に、
人間に持たすべきメンバ変数がないんで。
単に、構造体と関数で組んでる構造化プログラムを変わらないじゃあないのかなあ？
とか思ってしまうんです。
オブジェクトの状態をメッセージで変化させるなら確かに画用紙につけるべきなのかなあ
とか思うし、今後追加機能が予想されそうなのは楕円とか三角とかの形だから、
ポリモーフィズムを使いやすいように四角につけるべきかなあとかも思うし、
書くのはクレヨンだろとかいや人間（画家）だとかも思っていつも悩むんです。
0549デフォルトの名無しさん
2005/08/13(土) 05:58:19画用紙には抽象的な紙として、点の描画指示を受け付けるメソッドを持たせる。
クレヨンには抽象的な筆として、点や線の描画指示を受け付けて、紙に描画を指示するメソッドを持たせる。
人間には抽象的な描画メソッドを持たせて、図形や紙や筆に問い合わせながら、筆に描画指示を出させる。
こんな感じでやれば、人間に描画メソッドを持たせても、ただの構造化っぽくはならないと思う。
0550デフォルトの名無しさん
2005/08/13(土) 13:26:27画用紙：描く（クレヨン、四角）
で良いはず。あとは変則で
クレヨン：描く（画用紙、四角）
とか
四角：描く（クレヨン、画用紙）
とか。
好きな物を使えば良い。
0551デフォルトの名無しさん
2005/08/19(金) 12:25:51画家がいてくれると、undo&redoや繰り返し定義(OpenGLのdisplay listみたいなの)が
直感的にわかりやすくなるよね。
0552デフォルトの名無しさん
2005/08/21(日) 03:31:49猫とか犬とか哺乳類とか書いてある入門書なんか捨てちまえ。
0553デフォルトの名無しさん
2005/08/23(火) 14:42:58そもそもオブジェクト指向は「実世界のモデル化」を目的に Simula に導入されましたから
しかし、オブジェクト指向は『実世界の事象説明』以上のことも出来るから、
哺乳類云々しか書いてない入門書は捨てるべきだとは思うが
0554デフォルトの名無しさん
2005/08/23(火) 15:53:22>>553
そういう抽象論でなく、具体的な目標（ゲームとか電卓とか）があって、それをオブジェクト指向で
作り上げていくという書籍はないですかね？
0555デフォルトの名無しさん
2005/08/23(火) 16:58:56出自がどうであろうと現在のOOPはそこから遥か遠くに離れてる。
寧ろそういう視点から始めると、大概動くものは何一つ作れない。
0556デフォルトの名無しさん
2005/08/23(火) 17:20:05モデル化から完全に離れたオブジェクト指向ってどんなのよ
マジで想像付かない
0557デフォルトの名無しさん
2005/08/23(火) 21:30:53> そもそもオブジェクト指向は「実世界のモデル化」を目的に Simula に導入
おいおい。Simulaの頃にはまだオブジェクト指向なんて言葉すら存在しとらんぞ。
あえていうなら「クラスとオブジェクトは」だろ。オブジェクト指向なんて少なくとも
'70年代に入ってSimulaをヒントにCluとSmalltalkが作られはじめてからの話だ。
「実世界のモデル化」なんてのはSmalltalkローカル、もとい、Alan Kayの頭ん中
ローカルな夢想を真に受けてどつぼっているだけ。クラスごときににそんなポテン
シャルはないって。。。
0558デフォルトの名無しさん
2005/08/23(火) 22:18:11つ http://www.amazon.co.jp/exec/obidos/ASIN/477412222X/qid=1124803029/sr=1-9/ref=sr_1_26_9/250-0244807-4748240
結構いい本だとおもう。
0559デフォルトの名無しさん
2005/08/23(火) 22:23:42> クラスごときににそんなポテン
> シャルはないって。。。
クラスはともかく、オブジェクト指向にはあると思うけどな。
0560デフォルトの名無しさん
2005/08/23(火) 22:29:38サンクス。
オブジェクト指向の本、2冊読んで、概念としては分かったんだけど、具体的な作り方が
分からなくて悶々としてました。
0561デフォルトの名無しさん
2005/08/23(火) 22:30:51モデル化＝現実世界のシミュレート
を必要以上に考えすぎてると思う。
オブジェクト指向原理主義者たちの布教をモロに信じ込んで、
なんだが森羅万象がオブジェクト指向なら
簡単にプログラムできるような錯覚をしてるんじゃないかと。
0562デフォルトの名無しさん
2005/08/24(水) 02:40:09知ったか乙。
SimulaはSimula67で大きく言語仕様が変わり、
最初のオブジェクト指向言語と呼ばれるものになった。
あと、LiskovのCLUはClusterを中心に据えたObject言語であって、
Object指向言語と呼ぶには違和感がある。
0563デフォルトの名無しさん
2005/08/24(水) 02:52:46つ[実践UML]
0564デフォルトの名無しさん
2005/08/24(水) 09:21:22これ↓でしょうか？
自分にはまだ敷居が高いような感じが・・・
ちょっと本屋で立ち読みしてから判断してみます。
紹介、サンクス。
実践UML―パターンによる統一プロセスガイド
http://www.amazon.co.jp/exec/obidos/ASIN/4894713861/
0565デフォルトの名無しさん
2005/08/24(水) 12:05:06とは言うものの、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
0566553
2005/08/24(水) 20:26:15◇言いたいことその１
なんとなく 557 は、
「1 + 2 を“加算”と呼ぶのは間違ってるだろ。
1 + 2 が考案された時には加算なんて呼び方はしてなかったわけだし」
って主張しているように思えてしょうがなくて。
◇言いたいことその２
微妙に揚げ足取りのような気はするんだけど、OO には様々な流派があるから
「C++ の OO が主流だ」とか一概に言ってはいけない希ガス
確かに C++ のは良く使われているが
◇言いたいことその３
http://ja.wikipedia.org/wiki/Simula
もし 565 が本当なら、誰か↑を訂正してやってくれ
0567デフォルトの名無しさん
2005/08/24(水) 21:13:41立ち読みで1/3ぐらい読んだ。
やっとOOPの片鱗が見えた。
すごいパラダイムシフトであることがやっと実感できた。
OOPで書くと多分、従来のスタイルで書くのがアホらしくなりそう。
でも設計はまだ全然できないけど。
>>563
やっぱり俺にはまだ、内容が難しそうだった。
今回はパスしました。
0568デフォルトの名無しさん
2005/08/24(水) 22:24:59貴方の意見には同意できません。
例えば：
> 現在主流のオブジェクト指向の考え方は C++ のストラウストラップの
> もの、つまり抽象データ型のスーパーセット（抽象データ型 ＋ 派
> 生・仮想関数。今風に言うと、カプセル化・継承・多相性）
貴方は何故、C++をOOのリファレンスと捉えているのか、
なかなか興味深い所ですね。
え？私の意見？
10年位前に、某MLのエライ人の居た基礎研に潜り込もうとして失敗してから、
あまり進歩してませんから。OOってのは所詮、
・型理論とか
・圏論とか
・あるいは80年代AI文化のフレーム理論?とか(ﾜﾗ
そのあたりを、抽象データ型の言葉で語ったものに過ぎないんじゃないかなぁ、
なんて変な物の見方してます。つかOOってルーズで一貫性がなくて、理系向きじゃねぇよな
0569568
2005/08/24(水) 22:27:04学生時代の専門は物性基礎論だったりします（ﾜﾗ
物性基礎論で、情報系の基礎研受けるなよ（ﾜﾗ
0570553
2005/08/24(水) 22:37:36ん〜 …… 565 は C++/Java 系の OO が最も使用頻度が高いって事を言いたいんじゃないか？
C++/Java 系は言語として良く使われているし
ちなみに、個人的に OO を最も簡潔に表現しているのは Self 系のプロトタイプベースだと思ってる
あまり使用されていないが
0571デフォルトの名無しさん
2005/08/24(水) 22:43:30>>569
型理論も圏論もフレーム理論も、OO とは直接的な関係は無い筈
フレーム理論だけ、何で OO と結びつくのか分からんが
0572デフォルトの名無しさん
2005/08/24(水) 23:07:430573デフォルトの名無しさん
2005/08/24(水) 23:18:41JavaのOOは、Smalltalk流のMetaclassを、C++ ＋ Reflection機構で実現している点で既にC++とは別物、
ついでに JDK1.5 TigerのAnnotationsは、Javaを宣言型言語に読み替え可能にしちまった点で、
もはや別次元に逝っちまってると思う。
あとSelfは俺も好きだが、それをOOと等価と見なすのは、単なる思い入れ(思い込み)でしょ？
>>571はもうどうでもいいです。有益な議論ができる相手とは思えん（わら萎え
0574デフォルトの名無しさん
2005/08/24(水) 23:21:29○ JavaのOOは、Smalltalk流Metaclassを、C++にReflection機構を加えた形で表現している点で、Smalltalkや純粋なC++とは別物、
0575デフォルトの名無しさん
2005/08/25(木) 01:15:10Self も OOPL と呼ぶのが普通だと思ってたけど、違うの？
0576デフォルトの名無しさん
2005/08/25(木) 01:21:55Javaでの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じゃないとばっさり切って
捨てるのも大人げないってもんですぜ。
0577デフォルトの名無しさん
2005/08/25(木) 19:50:00>でも設計はまだ全然できないけど。
本気で設計やりたいと思ったら>563を思い出してね。
Cのポインタ理解できるレベルで読める本だと思うから。
0578デフォルトの名無しさん
2005/08/25(木) 20:42:59了解。
次に読んでみます。
0579570=553
2005/08/28(日) 18:51:43>>573
メタクラスとリフレクションは、仮に目的と結果が同じでも概念が異なるし
アノテーションは只のメタデータっていうか属性でしょ
>>576
568 に対し、「今自分が捉えている OO とは何か」を教えたかったから Self を出した
(俺は Self はやったこと無くて、実際にやったのは Io だけど)
なんつーか、幾つかの OOPL を自称している言語を見ていくと OO の捉え方に大きな差があるんだけど、
そいつらから逆算して OO の最小公倍数を考えた結果、
・手続きとデータをまとめたものがオブジェクト
・オブジェクトに対して操作を行う
の２つの要素を「最低限の OO」として俺は認識した
(CLOS は危うい。Io はこれに等しい。C++ や Java は付属品が豪華すぎる)
0582デフォルトの名無しさん
2005/08/30(火) 01:35:010583デフォルトの名無しさん
2005/08/30(火) 12:41:46わかりやすいバカ印たな
0584570=553
2005/08/30(火) 19:31:430585570=553
2005/08/30(火) 19:40:49付け加えておくけど、579 の「なんつーか」以降は個人的見解だから注意な
0586デフォルトの名無しさん
2005/09/01(木) 15:24:33>オブジェクト指向は，英語では "object oriented" であり，「もの指向」「もの中心」といった意味を持ちます。
http://software.nikkeibp.co.jp/software/backno/2005/0506t1.pdf
0587デフォルトの名無しさん
2005/09/01(木) 20:32:560588デフォルトの名無しさん
2005/09/02(金) 02:01:48とかいっちゃだめ？
0589デフォルトの名無しさん
2005/09/02(金) 03:48:33「実世界のモデル化」だの「もの指向」だのとかは攪乱が目的としか思えん。
メッセージがどーたら言う奴はアランケイの脳内砂場で遊んでろっての。
0590デフォルトの名無しさん
2005/09/02(金) 04:34:32何ですか？
0591デフォルトの名無しさん
2005/09/02(金) 08:06:03これに異論を唱える奴はOO教信者
0592デフォルトの名無しさん
2005/09/02(金) 09:21:470593デフォルトの名無しさん
2005/09/02(金) 14:05:50実装方法はこの際どうでも良いかと思う
『〜を〜する』という考えが出来るようになった程度の認識で十分
クラス信者からは異論が来るだろうが
0594デフォルトの名無しさん
2005/09/02(金) 16:24:47データ(フィールド・メンバー変数)があってもなくても、オブジェクトだと思うけれども
0595579
2005/09/02(金) 16:42:03「０個以上の手続きとデータをまとめたものがオブジェクト」という意味です
０個でも別に構わないし、むしろまとめる事が出来るという事自体が肝心
というか、オブジェクトそのものがデータだから、
データ(構造体)に手続き(関数)をくっつけるという見方も出来ると思う
そういう意味では >>591 に同意
0596579
2005/09/02(金) 16:51:07関連付けの仕方には「クラス」「スロット」「総称関数」やら色々な流派があるけど、
この定義は OOPL を名乗る言語のほとんどに適用できそうな気がする
0597デフォルトの名無しさん
2005/09/02(金) 17:15:47OOは最先端の構造化技法 なのか？
0598デフォルトの名無しさん
2005/09/02(金) 19:48:260599デフォルトの名無しさん
2005/09/02(金) 21:09:05んでもってキーポイントも同じ。データ構造をうまく分析・設計
できるか否かが鍵。これができないとと豚に真珠だね。
0600デフォルトの名無しさん
2005/09/02(金) 23:02:330601デフォルトの名無しさん
2005/09/03(土) 05:53:010602デフォルトの名無しさん
2005/09/03(土) 05:58:30ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
0603デフォルトの名無しさん
2005/09/03(土) 08:46:58読んでオブジェクト指向が理解できない奴は旧人類。
0604デフォルトの名無しさん
2005/09/03(土) 09:54:13ひとくくりにしている現状に気づかないで最大公約数的なものを探そうとすると
とんでもないことになるんだって。
オブ脳はどちらかといえばケイの妄想寄り。
憂鬱とか平澤とかはストラウストラップの流れ。
両者はもともと別物なんだから相容れないのは当たり前。ある程度いいとこ
どりはできなくもないけど、けっきょく混乱と難解さしか生じさせない。なにより
両者の本質の所在があいまいになる。
あと、オブジェクトやクラスはなにもオブジェクト指向のために作られたもの
じゃない（それぞれが思いついたオブジェクト指向を具現化するのに便利だから、
ケイやストラウストラップがSimulaから拝借したにすぎない）から、その実装や定義を
整理してもオブジェクト指向の本質には到達できにくいよ！
たとえばクラスは、オブジェクト指向するには欠陥があることがクックに指摘されて、
今はインターフェイスによるてこ入れが行なわれている。
0605デフォルトの名無しさん
2005/09/03(土) 10:22:17＞だから、もともと違う前提にもとずく考え方を同じ「オブジェクト指向」と称して
VHS と β の違いみたいなもんか。無駄な混乱を招くっていう点では。
む〜、最大公約数で考えた 596 は間違っていたのか……
0606デフォルトの名無しさん
2005/09/03(土) 13:31:09相容れないどころか、両方包含できるでしょうに。
0607デフォルトの名無しさん
2005/09/03(土) 13:33:37概念モデルは>>604の言うケイの妄想寄りなんだけど。
0608デフォルトの名無しさん
2005/09/03(土) 13:38:50つーか、君の言うオブジェクト指向ならAdaで十分なわけだが。
0609デフォルトの名無しさん
2005/09/03(土) 14:06:23もしかして「継承がないとオブジェクト指向とは言えない」ってクチか？
そういや Ada95 では継承ができるようになってたんだな。知らんかった
0610デフォルトの名無しさん
2005/09/03(土) 16:39:20・モデリング方面
主にデータモデリングの延長線上で進化してきたもの。
元になっているデータモデリングの考え方に継承を加えて
「主キー」という考え方を「オブジェクトリファレンス」に変化させたもの。
けれど、メッセージパッシングの考え方を含めるのはなぜか稀。
モデラーが重視していないだけだろうけど。
・実装テクニック系
主にオブジェクト指向言語とGUIの発展に伴って磨かれてきたもの。
もともとモデリングの世界と同一の出発点からオブジェクト指向言語
が形成されたが、MacやWindows、X Window SystemなどでGUIをうまく
簡単に作れるようにするために実装テクニックが磨かれ続けた。
デザパタを代表とするオブジェクト指向テクニックにGUI系のものが多かったのは
そのため。今は手法が確立したからGUIの話をすることは無くなり、
もっと広いさまざまな局面における実装テクニックが考えられている。
この２つ、どちらもオブジェクト指向。出発点は同じだけど、内容は分岐している。
でも、どちらも重要。
0611デフォルトの名無しさん
2005/09/04(日) 01:20:51> もしかして「継承がないとオブジェクト指向とは言えない」ってクチか？
聞こえちゃいけない声が聞こえちゃう人ですか？
0612デフォルトの名無しさん
2005/09/04(日) 07:48:46ちなみにそれの邦題は「ドメイン貧血症」という事になっているが、
俺は「ドメイン欠乏症」もしくはもう意訳に徹して「ドメイン不足症候群」くらいのニュアンスにした方がいいとオモタ。
センスねぇよな、そこの邦訳作ってる奴。
0613デフォルトの名無しさん
2005/09/04(日) 07:50:36はげわろす。
0614デフォルトの名無しさん
2005/09/04(日) 21:19:24貧血って直訳だし、無難な所だと思うけどなあ。
俺センスでゆるロックとかやられるよりはいいよ。
0615デフォルトの名無しさん
2005/09/06(火) 00:40:12テーブル設計をするって書いてあったんだけど・・
これってモデルを先に決めながら、後（もしくは同時？）にテーブル設計をする。
テーブルはあくまでそれを永続化するためのものでしかないって事かな。
それって従来型のようなテーブルの論理設計や正規化やらをしなくても
いいって事？あーバカにも分かりやすく説明してちょ。
0616デフォルトの名無しさん
2005/10/10(月) 02:51:50なにが出来ればオブジェクト指向を習得したって言えるの？
0617デフォルトの名無しさん
2005/10/10(月) 09:15:32・現実世界のモデリング(概念モデリング)
・GoFのデザインパターンなどのオブジェクト指向的実装テクニック
・オブジェクト指向的な実装テクニックを用いたフレームワーク構築
だいたいこの３点でしょう。最後のはいらないかも？
1番上と2番目のやつは全く違う方向性を持つので別物に見えるだろうけど、
この2つ、どちらもオブジェクト指向。
0618デフォルトの名無しさん
2005/10/10(月) 09:21:41オブジェクト指向における概念モデリングは、もともとデータモデル作成から
派生してきたものなので、実際には出発点や考え方は同じものだよ。
これを「全く別だから注意ね！」とか言う人が居るけど、歴史上同じ出発点から
分岐して来ているものだから、信じないこと。
オブジェクト指向設計ではテーブル定義は概念モデルから導きます。概念モデル
の作成方法は以前からやられているデータモデリングと同じように論理設計とか
正規化と似たような考えで作られます。流派が違うから少し違うように見えるだけで、
本質的にやろうとしている事は同じ。きちんとした概念モデルが作れた後に、それを
あまり崩さない形でテーブル設計します。
0619伝説の新人
2005/10/10(月) 09:33:19まずは、コーディングから。コードの再利用性。迂闊に変数や関数を
さわれない安全性。オブジェクト指向で提供される関数などの利用。
そこからだな。ちなみに、Visual Basic.netの
.netはオブジェクト指向型で提供される.Net Framework。
0620デフォルトの名無しさん
2005/10/10(月) 09:43:250621デフォルトの名無しさん
2005/10/10(月) 10:25:38大事なのは、メンテのしやすさを念頭に置けるかどうか。
安全性。データ型とは何か、それを定義する意義や方法を知ること。
カプセル化とか言われるのはコレ。通常、オブジェクト指向言語では、
データ型の定義にクラスを使う。
言語によって、情報隠蔽（アクセスコントロール）という概念も入る。
それと安全性については、もうひとつ。型安全性についての知識も大切。
サブタイプとサブクラスの違いとか（通常は同一視して構わないけれど、
局面によっては区別せなあかん。だからインターフェイスが必要…とか）。
静的型チェック機構を持つ言語では、（コンパイルを通すためにするのではなく）
ちゃんと仕組みや意味を分かって、この機構を役立てること。
総じて、オブジェクト指向とはクラスという言語機能を使って必要なデータ型を
設計して運用することだから、繰り返しになるけど、データ型が何かを知っていて
常に意識できていないと、いろんなモヤモヤがでてきて、うまく対処したり、
他人に自分がなにをしているのかを説明できないと思う。
余談。
よく出てくるメッセージ送信うんぬんは、Smalltalkから強い影響を受けた言語を
使うのでなければ、とりあえず無視していい。単なる関数呼び出しのことだから。
0622デフォルトの名無しさん
2005/10/10(月) 15:20:57それを言ってしまったら「OOする本質的な利点」が消失してしまわないか？
0623デフォルトの名無しさん
2005/10/10(月) 17:07:420624デフォルトの名無しさん
2005/10/10(月) 19:06:34うおっと・・・610=617です。1ヶ月前に書いているのを見つけられて
かなり恥ずい・・。
0625デフォルトの名無しさん
2005/10/10(月) 20:00:13デザインパターンはオブジェクト指向とは何の関係もないから、
「オブジェクト指向的実装〜」とか言われると違和感ありまくり。
勉強が足りないな。
オブジェクト指向って言葉に踊らされてる馬鹿って感じ。
0626デフォルトの名無しさん
2005/10/10(月) 20:09:34GoF に限れば OO を使用しているものが多く、これらを自然に使いこなせていれば OO も理解しているのでは
という事じゃないの？
0627デフォルトの名無しさん
2005/10/10(月) 20:42:26これ以上言うまい。
0628デフォルトの名無しさん
2005/10/10(月) 21:53:110629デフォルトの名無しさん
2005/10/11(火) 00:01:08>オブジェクト指向ってなに？
現実世界のメタファー（あるいは人間が環境を認識・処理する方法）を利用した
プログラミングテクニック、つうのがオレ的解釈
それを実現するための基礎概念として、カプセル化や継承・包含・委譲といった
ようなのがある……と。ここから先は参考書嫁
>なにが出来ればオブジェクト指向を習得したって言えるの？
こいつは難しいよ。免許制度があるわけじゃないしね……
極端な例えだけど「オレは算数を習得した」と言い切れる人間は少ないよね？
それと一緒で、「オブジェクト指向を習得した」と言い切れる人間は少ないと思う。
0630デフォルトの名無しさん
2005/10/11(火) 00:39:18なんかもうオブジェクト指向が云々て言うの面倒だなって思えた瞬間
0631デフォルトの名無しさん
2005/10/11(火) 00:42:220632デフォルトの名無しさん
2005/10/11(火) 12:12:35こういうのがいちばんよく見かける、けど、いちばんたちのわるい例だ。
ＮＧワードは「現実世界」「メタファー」「オレ的」「詳しくは参考書
（で、何を読めばいいのかすら書いていない…が、まあ、薦めてもらっても
同じ穴のムジナが書いた駄目本がずらずら出てくるだけだろうが……）」
ちゃんと理解できていないなら、書かなければいいのに…。
616 よ、よく覚えておいて、この手合いはいっさい無視して良い。
0633デフォルトの名無しさん
2005/10/11(火) 17:31:58じゃあ，あんたが具体的に解説してくれ
0634629
2005/10/12(水) 02:49:08>何を読めばいいのかすら書いていない…
そういやそうだな、と思ったけど、よくよく考えるとオブジェクト指向の入門書持ってないや……
歴史も含めた概略としては
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
が良いような気もするけど……
0635デフォルトの名無しさん
2005/10/12(水) 09:25:57はあ？ こんなのサイアクじゃん。混乱を招くだけだよ。因果関係めちゃくちゃだし。
とにかくSmalltalkローカルな考え方を説明する以外でメッセージとか書いている
時点でダウト。はっきり言って書いている奴はわかっていない。ほぼ断言できる。
まずはメイヤーの「オブジェクト指向入門」でも読んで出直してこいと言いたい。
0636デフォルトの名無しさん
2005/10/12(水) 10:21:580637デフォルトの名無しさん
2005/10/12(水) 12:31:31OOつうのはプログラミング方法論ではなくてパラダイムなんじゃないの？。
OOPだけに話を限ればそれもある意味正しいかもしれないけれど
0638デフォルトの名無しさん
2005/10/12(水) 12:55:53ハイブリッドとか往っている時点でもうアウトだぜ。おとといこいってんだってかんじ。
とりあえずSmalltalkの毒電波をあたかまら排除して考えるクセをつけてみることを勧める。
実際、なんにも困ることはないから。
ttp://www.tcp-ip.or.jp/~ikken/cpp/abst.txt
0639デフォルトの名無しさん
2005/10/12(水) 16:25:310640デフォルトの名無しさん
2005/10/12(水) 19:33:55釣り言葉は多いけれど、結局言っていることがよくわからない（あいまいな）ので、
具体的に自分の言葉で指摘してみて。
0641デフォルトの名無しさん
2005/10/13(木) 00:04:550642629
2005/10/13(木) 01:54:06どう考えても入門者向けじゃないような……Eiffelだし。
>Smalltalkローカルな考え方を説明する以外でメッセージとか書いている時点でダウト
メッセージは普通につかうと思うけど。
Io, Ruby, Selfとか、オブジェクト指向の強い（らしい）言語はメッセージの概念で
説明している……と思う。Objective-C もそうか。
>638
いや、それC++前提だし。
C++はマルチパラダイム言語だよね……オブジェクト指向のサポートも強くないし。
＃代わりに関数型プログラミングのサポートがあるわけだけど。
「オブジェクト指向なんて堅苦しく考えないで、適当にプログラムすりゃいいじゃん」
つうこと？コーディングするときはそれでいいけど、ここはオブジェクト指向のスレだし……
0643639
2005/10/13(木) 02:16:25・C++ 系の言語では、"メッセージ送信" は "関数起動" として実装される。
つまり、OO の "メッセージ送信" は、C++ の OOP 的に言うと "関数起動" になると俺は思った。
けど、もしかしたら "メッセージ送信" は Smalltalk の OOP 的表現かも。こまった。
0644デフォルトの名無しさん
2005/10/13(木) 02:20:320645デフォルトの名無しさん
2005/10/13(木) 02:22:00そのサイトの文章の内容最悪。
仮想関数のところひどすぎ。
0646デフォルトの名無しさん
2005/10/13(木) 02:46:14Smalltalkとその強い影響下にある言語以外でメッセージという表現を
使うことに抵抗を感じれない人間は、OOとOOPの区別以前に、OOPが
演ｽかすらあたまｂ�ﾅ整理が付ｂ｢ていないようｂﾈ希ガス。そう＝Bお前のことだ＝B
0647629
2005/10/13(木) 02:57:01まあ、C++のメンバ関数なんかだとやっぱり不便だもんな……メッセージじゃなくて
ソースの記述に縛られるわけだし。
ただ、メンバ関数はメッセージ駆動のような挙動をエミュレートするから、メッセージの
代用品と呼ぶのは悪くないんじゃない？
0649デフォルトの名無しさん
2005/10/13(木) 10:00:39C++しか眼中ねぇ！のにそれを全てのOOPの話のように書いてしまって
Smalltalkerやらその他の皆様からここぞとばかり叩かれてたご仁を思い出してしまたよ、漏れも（w
0650デフォルトの名無しさん
2005/10/19(水) 22:28:28ttp://pc8.2ch.net/test/read.cgi/tech/1127198808/556
こいつを誘導しました。
面倒見てやってください。
0651デフォルトの名無しさん
2005/10/19(水) 22:29:55オブジェクト指向と関係なくてごめん。
0652デフォルトの名無しさん
2005/10/19(水) 22:50:38> プログラムを組んでく以上の意味は無いでしょうよ。」であること。
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
じゃあ、それ以外に何があるの？
きっちり全部いって。
後で、これもあったは無しね。
0653デフォルトの名無しさん
2005/10/19(水) 22:57:20とりあえずこのスレを>>1からじっくり読むといいよ
0654デフォルトの名無しさん
2005/10/19(水) 22:59:52そもそも君のいう「オブジェクト単位でクラスこさえて、プログラムを組んでく」こと
そのものに意味が存在するのか？
その結果として型安全性や再生産性が高まるといった価値に対する「意味」なら存在するけどね。
手法の結果に得られた利益にこそ意味は存在する。
> 後で、これもあったは無しね。
子供の喧嘩か？
君は人が作って、しかも今も変わりつつあるパラダイムについてすべてを知りつしているのか？
そのレベルに合わせて議論するなら、オブジェクト指向からポリホーフィズムを
取っ払った時の利点と欠点をすべて論って比較することが君に可能だというのなら
俺も試してやるよ。
0655デフォルトの名無しさん
2005/10/19(水) 23:10:42>そもそも君のいう「オブジェクト単位でクラスこさえて、プログラムを組んでく」こと
>そのものに意味が存在するのか？
するじゃん。
これこれこういう具合に組んでみました。
っていうコミュニケーションの道具になら役に立つんじゃね？
そうやって説明できれば、他の人からみて「そういう風に組んだなら、これはまずいんじゃない？」とか
指摘できるようになるでしょ？
>オブジェクト指向からポリホーフィズムを取っ払った時の利点と欠点をすべて論って
さっさと書けよｗ
とりあえず書いてもらわなきゃ。
俺がそのレベルの話を理解できるかどうかわからんでしょ？
ただ、他からのリンクを貼るだけってのは勘弁してくれ。
あくまでも君の言葉で語ることが前提。
まあ、そんな何十行も続くような理論なんてありえない。続いたらどっかがおかしい。
0656デフォルトの名無しさん
2005/10/19(水) 23:13:220657デフォルトの名無しさん
2005/10/19(水) 23:18:51考えるな。感じろ。
0658デフォルトの名無しさん
2005/10/19(水) 23:24:24書いてるし。節穴？
> これこれこういう具合に組んでみました。
> っていうコミュニケーションの道具になら役に立つんじゃね？
それは「組んでく」ことの意味じゃない
パラダイムを共有することが協約を可能にすることの意味であって
プログラミングとは直接は関係ない。
> 俺がそのレベルの話を理解できるかどうかわからんでしょ？
明確な自己認識もない奴と議論するのは時間の無駄。
さっさと再認識してくるか一刻も早くうせろ。
前者を選択してくれることを切に祈るよ。
>>656
652=655
0659デフォルトの名無しさん
2005/10/19(水) 23:26:11反論に反論を返してるから、主張したい点が全く見えない。
0660デフォルトの名無しさん
2005/10/19(水) 23:34:56簡潔にいうと俺が
「ポリモーフィズムなんて百害あって一利なし」
って言ったら、特に理由も言わずに俺を馬鹿扱いしたんよ。
0661デフォルトの名無しさん
2005/10/19(水) 23:36:20オブジェクト指向なんて嫌いだー
0662デフォルトの名無しさん
2005/10/19(水) 23:38:09こんな↓感じではじまったｗ
556 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 12:35:52
>>555
>非配列は、処理の速さというより、オブジェクト指向でいう所のポリモーフィズムというか、
>インターフェイスと実装を分離する感じが好きなのよ。もちろん処理も速いけど。
実際、そういうところでバグり易いのに、わざわざ処理の分岐をわかりにくくするのは、
あまりよくないんじゃないか？
俺はぶっちゃけ、ポリモーフィズムなんてこれっぽっちもよくないと思ってる。
よーく考えると利点の無いオブジェクト指向言語の改悪機能の一つだと思ってる。
560 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 21:07:08
>>556
オブジェクト指向を何も理解してないんだな。
0663デフォルトの名無しさん
2005/10/19(水) 23:39:17さらに
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
具体的にいってよ。意味ねーじゃん。
あと、君がオブジェクト指向に変な意味を付加してるのがわかるよ。
オブジェクト指向っつーのはオブジェクト単位でクラスこさえて、
プログラムを組んでく以上の意味は無いでしょうよ。
後にあるのは設計が下手糞か上手かどうかの話でオブジェクト指向云々じゃない。
ポリモーフィズムはあくまでもオブジェクト指向言語の機能だ。
オブジェクト指向じゃない。
0664デフォルトの名無しさん
2005/10/19(水) 23:41:39と書くのは簡単だけど勿論もっと書くよ？
・ポリモーフィズムはオブジェクト指向の一機能であると同時に不可欠。
・ポリモーフィズムはコードの一元化をスマートに行う機能である。
・ポリモーフィズムがもたらす利益は多々存在する。
・俺の問に問で返さずに答えて欲しい
・意図的に「以上の意味は無いでしょうよ。」の部分を削った理由を聞かせて欲しい。
・>>556に対して否定的意見を述べる理由を挙げているのに無視している理由を聞かせて欲しい。
0665デフォルトの名無しさん
2005/10/19(水) 23:42:09わかった？
つまり、
俺：ポリモーフィズムなんてウンコじゃん。死ねよ。
奴：お前なにもわかってねぇよ。死ねよ。
っていう会話なんだよ。掻い摘んで言うと。
だから、何が分かってないのかとりあえず書いてもらわなね。
0666デフォルトの名無しさん
2005/10/19(水) 23:43:03じゃあ、まず、
>・ポリモーフィズムはオブジェクト指向の一機能であると同時に不可欠。
これはどうして？
0667デフォルトの名無しさん
2005/10/19(水) 23:45:29564 名前：デフォルトの名無しさん 投稿日：2005/10/19(水) 22:01:58
>>563
>処理が変われば
たぶんそこの考えが違うんだろうな。
処理が主体なんじゃなくて、オブジェクトが主体なんだよ。
手続き型のパラダイムのままじゃ理解できない。
570 名前：デフォルトの名無しさん 投稿日：2005/10/19(水) 22:23:38
>569
> 具体的にいってよ。意味ねーじゃん。
君が具体論を持ち出した形跡が見当たらないわけだが。
論点逸らすのやめたほうがいいぞ。
> あと、君がオブジェクト指向に変な意味を付加してるのがわかるよ。
わかったからといってどうなるの？
> オブジェクト指向っつーのはオブジェクト単位でクラスこさえて、
> プログラムを組んでく以上の意味は無いでしょうよ。
その過程にポリモーフィズムの活用があるのもわからんのか。
> 後にあるのは設計が下手糞か上手かどうかの話でオブジェクト指向云々じゃない。
何の後だよ。
> ポリモーフィズムはあくまでもオブジェクト指向言語の機能だ。
> オブジェクト指向じゃない。
だれがんなこといったんだ？エスパー？
0668デフォルトの名無しさん
2005/10/19(水) 23:47:29その下の2つがそれを説明している。
利益の具体例は>>654で挙げた。
0669６５９
2005/10/19(水) 23:48:16>>660
inclusions polymorphism は "処理を入れ替えられる" っていうと害が多いような気がするけど、
オブジェクト指向の重要な機能 "情報隠蔽" に深く関わってくる概念だと俺は思うんだ。
つまり 『名前』 と 『処理』 を分離し、プログラミング時に "詳細な処理内容" を意識しなくてすむようになってるんだな。
ただ、分離しているものをランタイムに結合するから処理を動的に入れ替えることも可能で、
これを技巧的に扱うと色々なことが出来るかもしれないけど、多用は混乱の元だと考えてる。
0670デフォルトの名無しさん
2005/10/19(水) 23:49:43意味がわかんない。
つまり、君は俺に何がわかって無いっていいたいの？
ポリモーフィズムがオブジェクト指向に必要な理由を言ってみて、
俺が納得すればそれで終わりじゃないの？
0671デフォルトの名無しさん
2005/10/19(水) 23:51:06いやいや、途中で入ってきて話をややこしくするな。
オブジェクト指向と結びつけつつ話してくれよ。
その文じゃちょっと便利だよ程度だろ？
0672デフォルトの名無しさん
2005/10/19(水) 23:55:09「意味がわからない」のか「俺が納得すればそれで終わり」であることを
認識しているのかどちらかにしてくれ。
一言
「納得した」
といってくれれば、>>664の下の三点は答えたくないなら答えないでいい。
こちらが意図的なものを感じたから問うただけだ。
0673デフォルトの名無しさん
2005/10/19(水) 23:57:350674６５９
2005/10/19(水) 23:58:05そうか？それは済まない。
けど俺は、これがオブジェクト駆動の全てなんじゃないかと思ってる。
関数起動の形で、object に message という何らかのアクションを起こしたことを通達する。
object は message を受けて、指定の処理を行う。
何をするかは object が全部知っているから、関数を起動した側は object が何をやってるか気にしなくて良い。
ただ、期待した動作が行われることだけを信じて待っていれば良い。
これが inclusions polymorphism だと俺は捉えている。
微妙に違うけど。
0675デフォルトの名無しさん
2005/10/19(水) 23:59:42どうしても文章の一部が見えなくなる人がいるらしい。
2chのバグならいいのだが。
0676デフォルトの名無しさん
2005/10/20(木) 00:02:47ストラウストラップがオブジェクト指向プログラミングやそれをサポートする
言語に必須と言ってから、広まって定着した。他に、カプセル化、継承も
出自は同じ。（だが、その出典を知って使っている人は意外と少ない。）
ttp://www.research.att.com/~bs/whatis.pdf
なお、前のほうのやりとりにあるとおり、メッセージングというのは、この
ストラウストラップの「オブジェクト指向」には関係ない。メッセージを言い
出したのは Smalltalk の設計者のケイで、逆にこの人の「オブジェクト指向」
にはカプセル化や継承は関係ない。
ttp://www.purl.org/stefan_ram/pub/doc_kay_oop_en
0677デフォルトの名無しさん
2005/10/20(木) 00:06:550678デフォルトの名無しさん
2005/10/20(木) 00:08:320679デフォルトの名無しさん
2005/10/20(木) 00:09:12どっちにしても必須じゃねーじゃんな。
だからポリモーフィズムなんて後付けだっつったのに＞all
0680デフォルトの名無しさん
2005/10/20(木) 00:11:000681６５９
2005/10/20(木) 00:13:17お、ついでだから >>674 で 「微妙に違う」 って言った理由も書いておこう。
polymorphism つまり多態は２つの異なるオブジェクトを同一のものとして認識する必要があって、
この "同一のものとして認識する" ための指針として使われるのがストラウストラップの継承を使った型検査。
ケイの OO だけだと、わざわざ polymorphism と言わなければならない必要性が無いんだな。
どうでも良いんだけど、Smalltalk には継承はあった筈。
また、オブジェクトにデータと手続きをまとめるという立場から言えば、カプセル化は自然に行われていると見なせる筈。
0682デフォルトの名無しさん
2005/10/20(木) 00:13:24お前の主張は「ポリモーフィズムが改悪であること」だろ。
いい加減にしろ。
0683デフォルトの名無しさん
2005/10/20(木) 00:21:24必須ではないことはわかったわけだ。
ここまではいいよね。
ここまでは確定しておいてくれないと、「オブジェクト指向にポリモーフィズムは必須」とか、
わけのわからんこといって逃げられるから。「んなわけ。ねーだろボケ」で確定でいいよな。
じゃあ、次は、「ポリモーフィズムなんてウンコじゃん」って俺の主張だね。
これは俺の主張だからどこにも定義なんてされてないよ。
そんなこと無いって言い返すなら、キチンと俺のレスを汲み取って返さなきゃならない。
受け側としては、ちょっと苦痛な作業だ。
(続く）（ちょっとレス止めろｗもちつけおまいらｗ会話はキャッチボールだｗ今、ボールは俺が保有しているｗ）
0684デフォルトの名無しさん
2005/10/20(木) 00:25:13いつ俺が必須じゃないと認めたのかレス番で教えてくれ。
それにこれは会話じゃない。掲示板への書き込みだ。
いいよね？などと確認を求めておきながら返事も聞かずに
先に進めるための欺瞞としか思えない。
0685デフォルトの名無しさん
2005/10/20(木) 00:31:29で、俺の主張ってのはこれ↓だね。（３行目からだぞ）
＞>非配列は、処理の速さというより、オブジェクト指向でいう所のポリモーフィズムというか、
＞>インターフェイスと実装を分離する感じが好きなのよ。もちろん処理も速いけど。
＞実際、そういうところでバグり易いのに、わざわざ処理の分岐をわかりにくくするのは、
＞あまりよくないんじゃないか？
＞〜略〜
＞処理が変われば引数も変わるんだ。
＞無理やり同じようにまとめるべきじゃない。
＞
っていうちょっと実装寄りの単純な理由なわけよ。
「〜だから駄目」っていうキチンとした１本スジな理由があるわけじゃなくて、
「欠点だったら、いくつでもあがるぞ！」みたいなもん。
いままで騒いできたところじゃこんなもんしか書いてない。
で、よく考えてほしいわけよ。
・ポリモーフィズムを実現するにあたってやらなきゃならんこと。と
・実際にポリモーフィズムを実装したときのクラスのメソッドの動作。
この２つがよろしくない。どうよろしくないんだよ？つーか、よろしくないｗ
俺がいいたいことはこんだけｗ
後は反論で滅多切りにされるのをまつだけｗ
0686デフォルトの名無しさん
2005/10/20(木) 00:33:05いいじゃねーかｗ
どうせ必須じゃねんだからｗ
その点で責める気は無いよ。
0687デフォルトの名無しさん
2005/10/20(木) 00:35:22563 名前： デフォルトの名無しさん 投稿日： 2005/10/19(水) 21:52:57
>>560
ポリモーフィズムなんて、所詮は後付け機能。
ダレが公認したのか知らんけど入れるべきじゃないね。
処理が変われば引数も変わるんだ。
無理やり同じようにまとめるべきじゃない。
強引にポリモーフィズムを突き通したことでグローバル変数を使うような糞設計なんてしてりゃ世話無いよなｗ低脳君ｗ
0688デフォルトの名無しさん
2005/10/20(木) 00:38:30ああ、それは小さい理由だよ。
強引にポリモーフィズムやるために引数をなくしてグローバル変数かシングルトン使う奴いるでしょ？
もしくはvoid*かそれに相当するもの。型誤魔化し。
それを脳内で結びつけて勝手に俺が煽り口調でレスしただけだから、
自分はそんなことやってないと思ったらスルーでかまわない。
0689デフォルトの名無しさん
2005/10/20(木) 00:38:59＞Smalltalk には継承はあった筈。
初期の Smalltalk にはなかったし、それがケイの「オブジェクト指向」
に必須というわけでもない。どうでもいいけど。
ttp://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
0691デフォルトの名無しさん
2005/10/20(木) 00:42:33それは設計した奴が糞なんであってポリモーフィズムが糞ということにはならないような…。
0692６５９
2005/10/20(木) 00:44:30確かにケイの OO には継承は必要ないわ。
0693デフォルトの名無しさん
2005/10/20(木) 00:45:21ＯＯＰの事なにも理解してない（理解できない）んだね。
0694デフォルトの名無しさん
2005/10/20(木) 00:45:21はいはい、見つけられなかったのね。
>>676を読んで必須じゃないと判断した理由が俺にはわからないが。
是非聞かせてもらいたいものだ。
これも勿論答えたくないなら答えなくていい。
それだけ君に対する判断が変わるというだけの話だ。
> ＞処理が変われば引数も変わるんだ。
まさにそんな実装で使う必然性などない。
それを理解していないから
>> 強引にポリモーフィズムを突き通したことでグローバル変数を使うような糞設計なんてしてりゃ世話無いよなｗ低脳君ｗ？
等というレスをする羽目になる。
この発言を無視しろなどというのはごまかしだ。
これでオブジェクト指向を理解しているといえるか？
ある程度理解しているならば強引な実装など設計段階で排除されている。
> ・ポリモーフィズムを実現するにあたってやらなきゃならんこと。と
既に定着しているものを有害というのならソフトハウスにでもいって開発の陣頭指揮でも執ってこい。
> ・実際にポリモーフィズムを実装したときのクラスのメソッドの動作。
言語が明確に規定していると思うが。
0695デフォルトの名無しさん
2005/10/20(木) 00:50:40まさにオブジェクト指向の理解が間違っているための悲劇と思われ。
0696デフォルトの名無しさん
2005/10/20(木) 00:54:08＞・実際にポリモーフィズムを実装したときのクラスのメソッドの動作。
これって言語の実装の話なのか、それとも多態を利用する側の話なのかどっち？
たぶん後者だろうけど、多態を利用するために必要な事なんてvirtualを
宣言することぐらいでないの？
0697デフォルトの名無しさん
2005/10/20(木) 00:56:22>まさにそんな実装で使う必然性などない。
だから、使う必要ないだろｗ
世の中にあるもんのほとんどが引数変えずに処理できるもんって無いってｗ
使う場面が無い。絶対無い。
無理やり使ってる場面のが多い。
そして、そのやり方のほとんどがグローバル変数の使用による実現ってのがほとんどじゃん。
例えばさぁ。ゲーム関連スレから来たからこんな例を挙げちゃうけど。
普通のミサイルとホーミングミサイルってさぁ。
まとまりそうだけど、やっぱ、まとめらんねぇじゃん。
だけどできそうじゃん。オブジェクト指向がこういうもんでポリモーフィズムとか知ってたら是非ともまとめたいもんじゃん。
でも、どうしても、ホーミングミサイルの方の動作にはターゲットのセットがいるじゃん。
そのセットが無いと動けないじゃん。ホーミングミサイルだし。
これ回避してポリモーフィズムちっくにする意味ないじゃん。
でも、こんなのができねぇなら、一体なんの為にあるのか疑問にならねぇ？
0698デフォルトの名無しさん
2005/10/20(木) 00:59:06＞ホーミングミサイルの方の動作にはターゲットのセットがいるじゃん
すればよくないか？
グローバル変数じゃなくてインスタンス変数で。
……っていうか、もしかして "クラス内のグローバル変数" って意味で使ってる？
0699デフォルトの名無しさん
2005/10/20(木) 00:59:33簡潔に言おう。
君に「分類」の能力がないから平気でそういう台詞が出てくるのよ。
つまりお馬鹿って事だわな。
0700デフォルトの名無しさん
2005/10/20(木) 01:00:070701デフォルトの名無しさん
2005/10/20(木) 01:03:120702デフォルトの名無しさん
2005/10/20(木) 01:03:53> 使う場面が無い。絶対無い。
それに絶対無いと言い切るその自信がわからない。
使う必要性とオブジェクト指向にポリモーフィズムが不可欠ということを混同するな。
まさかとある機能があるからどんなプログラムでもそれを使わなきゃならないと思ってないだろうな。
CからC++に移ったばかりの奴が無駄にクラスを使ってめちゃくちゃにするのと同じだぞ。
設計能力の欠如に対する無自覚がお前のレスを破綻させていることに気付け。
0703デフォルトの名無しさん
2005/10/20(木) 01:07:46どうでもいいけど、Bookmarkから消え去ってGoogle様にすがるのも面倒とおもってた論文だ（w
ありがと（笑）
0704デフォルトの名無しさん
2005/10/20(木) 01:08:01class Missile { ... }
class HomingMissile extends Missile {
void setTarget( Target t ) { ... }
}
な、そういう場合はな、こうやるんだ。
0705デフォルトの名無しさん
2005/10/20(木) 01:09:37下らん。いい加減寝る。
0706デフォルトの名無しさん
2005/10/20(木) 01:18:39くだんのは OCR ミスで意味不明なところが多いので、汚くて読みにくいけど
こちらのほうがお薦め。たぶんブックマークしていたのはこっちでは？
ttp://www.metaobject.com/papers/Smallhistory.pdf
どうでもいいけど。ｗ
0707デフォルトの名無しさん
2005/10/20(木) 01:19:02６５９氏に感謝します。
スマートな解説がとても読みやすかったですよ。
0708デフォルトの名無しさん
2005/10/20(木) 01:26:00はぁ〜やると思ったよ。
そこでポインタ保持しちゃうの？
ポインタ保持しなくても、まあ、インデックス保持だとしても、
すでに綺麗な組み方じゃないのはわかるよね？
まず、そこで保持する理由がない。
次のフレームではそれは使えないor必要ないからだ。
ターゲットが切り替わる可能性があるから、
一度捕捉したらロックオンするという仕様でなければ、
ターゲットの再検索をかけなければいけないはずだ。
ポリモーフィズムを実装するという目的さえなければ、
直接、動かす関数に引数をつけるはずだ。
そもそもここがすでに自然じゃない。
設計をまげている。
0709デフォルトの名無しさん
2005/10/20(木) 01:26:280710デフォルトの名無しさん
2005/10/20(木) 01:27:18void Missile.Move(Environment env) としておけば良いんじゃないか？
0711デフォルトの名無しさん
2005/10/20(木) 01:29:43悪いけどそれって究極まで突き詰めるとvoid*のがよっぽど楽ってことにならない？ｗ
0712デフォルトの名無しさん
2005/10/20(木) 01:31:49誰がホーミングなんだか、まとまった集団の中から探しださなきゃいけねぇから、
ポリモの恩恵あまりないんじゃねぇの？
0713デフォルトの名無しさん
2005/10/20(木) 01:32:23ならないなぁ。そうならないうちに割り切って、それで出来ないことは諦めるのも１つの手。
というより、void * だと受け取っても何が入ってるのか分からなくて怖いです。
0714デフォルトの名無しさん
2005/10/20(木) 01:32:27認めないモノである。
0715デフォルトの名無しさん
2005/10/20(木) 01:34:58ある分類における共通動作概念を抜き出して個々に実装すべきもの。
よって、あるオブジェクト固有の機能をポリモフィズムで実装する
必要なんて元からないんだがね。
0716デフォルトの名無しさん
2005/10/20(木) 01:34:59だったら
class Missile {
int direction; // ミサイルの進行方向
int speed; // ミサイルのスピード
...
}
class HomingMissile : public Missile {
void SearchTarget(); // 進行方向の一定の範囲ににいるターゲットを検索する。
// ターゲットが存在すれば進行方向を調整し、存在しなければそのままロストとみなし直進する
}
とすればいいだけでは？
0718６５９
2005/10/20(木) 01:37:35『(例外を除いた) 殆どのものを１つにまとめる』 ことが出来るだけで万々歳のような気がする。
>>707
ありがとん。そう言ってもらえたの初めて｡･ﾟ･(ﾉД`)･ﾟ･｡
0719デフォルトの名無しさん
2005/10/20(木) 01:38:290720デフォルトの名無しさん
2005/10/20(木) 01:39:57Strategyにすれば自然に多態を使うことになる。
で、この場合、Missileに対してじゃなくStrategyに
ゲーム中の敵機の集合をContextとして渡してやれば
いいんじゃまいか？
0721デフォルトの名無しさん
2005/10/20(木) 01:41:02いやいやＩＤ付き。一応バグりはしないっぽいっしょ。
前に開発したときはそうやってポリモちっくでつくっててさ、
で、動作の前の準備として、setXXData関数っての作ってすべてのオブジェクトの動作実行前で
bool setXXData(void* data)を実行した。
で、すべてのオブジェクトが必ず１つのクラスから派生してて、そのクラスにＩＤを取得する関数がついてっから、
それを継承してどのクラスか判断するような設計だった。
で、おもったんよ。
「これってよ。もしかしてキタネェプログラムなんじゃねーの？」
疑問もたない？
なんで言語に型があるのか、激しく疑問に思ったよ。
で、都合のいいときだけ無視するように組んでたけど、
本当に綺麗なプログラムの組み方って型を誤魔化すような設計にはならねぇんじゃねーの？
って思ったわけよ。
Environment envもやったけどさ。
これって無駄に設定する手間が増える分バグが増えると思ったし、
結局、オブジェクトに必要なもん敷き詰めるのは変わらないべ。
0722デフォルトの名無しさん
2005/10/20(木) 01:41:20数多のプロジェクトが破綻する訳だぜ。
0723デフォルトの名無しさん
2005/10/20(木) 01:43:53馬鹿な私共に是非とも貴方様の素晴らしい意見をお聞かせください。
0724デフォルトの名無しさん
2005/10/20(木) 01:44:29ポリモいらんいうてるやつは
java.lang.Objectのメソッドは今後一切使うなよ。
0725デフォルトの名無しさん
2005/10/20(木) 01:47:04>というよりふと思ったんだけど、polymorphism で 『全部を１つにまとめる』 必要は無いんじゃないか？
>『(例外を除いた) 殆どのものを１つにまとめる』 ことが出来るだけで万々歳のような気がする。
それだよ！
長々と説明したけど、俺が思ったのはよ。
でさ、例外っていうけど、
誰が何をどうやってこれは「例外」だと認識できるん？
俺はミサイルとホーミングミサイル程度は綺麗にまとまらなきゃつかいもんになんねぇだろ。現実。
って勝手に決め付けて、最初に偶然ポリモをやってみたとき、「うまくいかねぇ！」ってなったけど、
他の人は実際どうだったん？
ミサイルとホーミングミサイルの違いはターゲットそれだけだで。（実装の都合で言えば）
他にこんなの何に使えるって言うの？
でさ、現場の誰もこれとこれはポリモであってて、これとこれは間違いだよ。
っていえねーじゃん。
つか、時間かかるじゃん。その判別に。
0726デフォルトの名無しさん
2005/10/20(木) 01:49:19あほらし、寝るわ
0727デフォルトの名無しさん
2005/10/20(木) 01:50:150728デフォルトの名無しさん
2005/10/20(木) 01:52:07Strategyにcontextを渡す仕様にすれば、
setDataをすべてのオブジェクトの移動前に
セットする必要はないっしょ。
しかもホーミングミサイルのサーチアルゴリズムは
共通なのでStrategyはsingletonで良い。
と言うことはcontextのセットは、すべてのオブジェクトの
移動の始まりに一回セットすれば良いだけじゃね？
間違ってる？自然な設計だと思うが。
新しいアルゴリズムが必要なら新しいstrategyクラスを
派生するだけでしょ。
0729デフォルトの名無しさん
2005/10/20(木) 01:56:28＞でさ、例外っていうけど、
＞誰が何をどうやってこれは「例外」だと認識できるん？
そりゃ設計者が分析してだろ
0730６５９
2005/10/20(木) 01:59:09＞誰が何をどうやってこれは「例外」だと認識できるん？
ちゃんとした答えは無いんじゃないかなぁ。
自分が綺麗じゃないと思ったら、その時点で例外としちゃって良いと思うよ。それが設計って奴なんだと思う。
自然にまとめられる物は、類似点の多いオブジェクトになってるから、polymorphism も自然に行えるでしょ？
「これは１つにまとめられないなー」 って思ったら、そのオブジェクトは、その時点で他のオブジェクトとは類似点が少ないことになるし。
0731デフォルトの名無しさん
2005/10/20(木) 02:01:06>共通なのでStrategyはsingletonで良い
だから、そうやってグローバル使うしｗ
駄目だって、目的を見失っちゃ。
煽るつもりでいうわけじゃないけど、
ポリモーフィズムを強引に実装しようとしなければそんなことする必要ないでしょ？
これは明らかっしょ。
ホーミング単体でみれば動作関数の引数にターゲットがついてる形が一番綺麗でしょ。
まず、原点に戻ろうよ。
って、俺もそれを考えたときに脳内で自問自答したｗ
つーか、これ以上は平行線でしょ。
俺のいいたいことはだいたい言ったし、これで納得いかない人はずっとこのままっしょ。
俺もしばらく、どうやんだ？これは間違ってるのか？あーでもキタネェし・・・って考えてたからｗ
っちゅーわけで、今夜はとりあえずお開きな。
つーか、俺は、もう寝るｗ
0732デフォルトの名無しさん
2005/10/20(木) 02:02:51いい解決方法があれば、聞いてみたいってのも本音なのよ。
ただ、その解決方法はホーミングクラスをいじることでは無い気がするんだよね。
ってのが俺の考え。
0733デフォルトの名無しさん
2005/10/20(木) 02:05:02ほんとストレス溜まるな。あーあ、胸糞悪りぃ。
0734デフォルトの名無しさん
2005/10/20(木) 02:06:14Strategyのsingletonはアルゴリズムを動的に取り替えられる
柔軟さがもたらされるので、かえってプログラムの保守が
容易になる。
いわゆるグローバル変数の保守しにくさとは次元が違う。
0735デフォルトの名無しさん
2005/10/20(木) 02:09:44でもこれってホーミングミサイルとふつうのミサイルの区別はIDによるswitch
でしょう？
汚いし、アルゴリズムが増えるたびに条件分岐を増やさなきゃならない。
保守がしにくい。
0736デフォルトの名無しさん
2005/10/20(木) 02:12:33そもそもアルゴリズムは共通じゃないかもしれないよ？
>>735
ホーミングミサイルを、ボスとして扱うのはどうだろうか。
自分の思ったとおりに設計すれば良いと思う。
ただ、選択肢は多く考えておいた方が良いと思うけどね。
0737デフォルトの名無しさん
2005/10/20(木) 02:13:280738デフォルトの名無しさん
2005/10/20(木) 02:16:27共通じゃないからStrategyにしてるんだが。
アルゴリズム一つに対して一つのStrategyインスタンスが
対応するわけで。
＞ホーミングミサイルを、ボスとして扱うのはどうだろうか。
いみがわかんね。
それこそ、汚い設計じゃないの？
0739デフォルトの名無しさん
2005/10/20(木) 02:18:37ごめん。ザコ敵の方が分かりやすかったか。
0740デフォルトの名無しさん
2005/10/20(木) 02:19:45グローバル変数が保守しにくいのは、どこかでグローバル変数の中身が
書き換えられるという副作用がプログラムに影響をあたえるからだよ。
Strategyのインスタンスは生成されてから中身のアルゴリズムが書き換
えられる事はない。（別のStrategyインスタンスに置き換えるだけだから）
0741デフォルトの名無しさん
2005/10/20(木) 02:20:170742デフォルトの名無しさん
2005/10/20(木) 02:21:43Strategyを推し進めると敵味方のオブジェクトも一括して
扱えるかも。
0743デフォルトの名無しさん
2005/10/20(木) 02:23:00＞共通じゃないからStrategyにしてるんだが
ん〜。strategy にしろ、polymorphism で実装する以上、アルゴリズムに何らかの共通点は有るでしょ？
最低でも関数の引数と戻り値は同じじゃなきゃいけない。
んで、もしこれらが異なるものだったら、strategy は使えないよね？ って話です。
0744デフォルトの名無しさん
2005/10/20(木) 02:26:07最終的には、画面上のオブジェクトは全て ScreenObject(仮) としてまとめることが出来る。
自機、ボス、ザコ、数種類の弾から背景まで全部。
果たして、そこまで１つにまとめる必要があるのか？ って話だよ。
できる事は分かってるんだけど、それによって問題が複雑になっちゃったら本末転倒だよ。
0745デフォルトの名無しさん
2005/10/20(木) 02:26:50さっきからストラテジーの話をしている人は引数も戻り値も変更しないことを前提にしている気がするのだが。
0746デフォルトの名無しさん
2005/10/20(木) 02:27:00そのオブジェクトの次の座標を取得するメソッドのインタフェースは
同じになると思いますが？
contextはコンストラクタで一回与えればOKかもね。
0747デフォルトの名無しさん
2005/10/20(木) 02:28:43そです。
少なくともゲーム中のオブジェクトの移動メソッドは
共通のインターフェースで済むはずだけど。
0748デフォルトの名無しさん
2005/10/20(木) 02:31:42『名前』つうと解りづらいけど、具体的な例は「ソースコードの記述」な。
>708
>直接、動かす関数に引数をつけるはずだ。
とすると、そこの記述は
1. HomingMissile専用のソースコードになる
2. Missileの関数を実行するときに、余計な引数を指定する必要がある
のどっちかになって、動かす関数を呼び出すソースコードの記述が
HomingMissileやMissileの定義に依存しちまうわけですな。
1. だと、似たようなコードをHomingMissileとMissile用にそれぞれ用意する
必要が出て来て面倒だし、2. だとMissileを動かすときにわざわざ要らない
引数を指定する必要があって面倒ですな。
多態性があれば簡単に処理できるけど、わざわざこんなことするの？
0749デフォルトの名無しさん
2005/10/20(木) 02:32:39ん〜。ScreenObject(仮) なら、getPoint() は共通化できるね。
んじゃ、Move 系のメソッドはどうだろうか。今回のゴタゴタはこのあたりを問題にしていると思うんだけど。
自機・ボス・弾・背景は、Move 系のメソッドを共通化する意味はあるのかな。
0750748
2005/10/20(木) 02:33:520751デフォルトの名無しさん
2005/10/20(木) 02:37:08だからmove系メソッドのアルゴリズムを取り替えるためにstrategyを
使うって話をしてるんだってば。
たとえばDemo画面でプレイヤー機が勝手に動いてるような場面も、
通常のゲームのルーチンと全く同じプログラムでプレイヤー機の
移動strategyを取り替えるだけになるじゃん。
0752デフォルトの名無しさん
2005/10/20(木) 02:37:16『特化』 は完全に無視なの？
0753デフォルトの名無しさん
2005/10/20(木) 02:40:12オブジェクト指向は「特化」部分を切り離したり置き換えたりを
容易にする技術でしょ。
ハードコーディングを「特化」という訳ではない。
0754デフォルトの名無しさん
2005/10/20(木) 02:41:32自機には、パッド等からの入力が伝わるよ。
ボスには、現在の自機座標が伝わるよ。
自機とボスの Move を共通化すると、両方のオブジェクトに両方の情報が伝わるね。
これは無駄じゃないのかな？ って話。
構造化手法的に言うと、情報とオブジェクトの結合度が強くならないかな？ って話。
0755デフォルトの名無しさん
2005/10/20(木) 02:45:00頭真っ白になってんだよ。
ＯＯＰ＝何が何でもぽりもーふぃずむで実装って思考に陥ってんだろうな。
0756754
2005/10/20(木) 02:45:060757デフォルトの名無しさん
2005/10/20(木) 02:46:19パッドからの情報はstrategyの中にカプセル化できるでしょ。
ボス、自機に限らず、他のオブジェクトの位置情報が参照で
きないと当たり判定ができないでしょ。
で、その情報はオブジェクトのインスタンス変数に保持される
んでしょうから、オブジェクトを介して情報を取得するのは
結合を密にするとはいえないでしょ。
というか座標の取得自体が多態使うでしょ。
0758754
2005/10/20(木) 02:55:17自機と自機の当たり判定なんて、まったく意味無いですし。
弾を生成する段階で自機への参照を保持するのも良いかもしれないけど、
それだと自機の 「自機への当たり判定を求める」 処理が無駄になる予感。
あるいは、これも OnFrame() の中に入れた方が良いのかなぁ……。
共通化しないほうが簡単になる部分は、共通化しないほうが良いんじゃないのかなぁと思う。
さっきから言ってるけど。
0759デフォルトの名無しさん
2005/10/20(木) 02:57:330760デフォルトの名無しさん
2005/10/20(木) 03:00:00まあ当たり判定はよけいな話だったかも知れないが、
言いたいのはstrategyにゲーム中のcontextを与えれば
実際のゲーム中のオブジェクトごとに引数変えたり
しなくても済む。
どこまで共通化するかは設計者の考え方次第だが、
デモ画面の話のように柔軟さは保守や拡張の容易さ
を生むと思うけどね。
そろそろ寝るよ。
0761デフォルトの名無しさん
2005/10/20(木) 03:02:04巨大化はしないと思うが。
strategyに共通の部分はstrategyの基底クラスに置いて、
特化された部分は派生クラスに書けばよいだけ。
あとは多態がうまくしてくれる。ww
0762デフォルトの名無しさん
2005/10/20(木) 03:03:49まさかグローバルな配列に置いてる
訳じゃないよね？
0763デフォルトの名無しさん
2005/10/20(木) 03:05:110764デフォルトの名無しさん
2005/10/20(木) 03:07:02ググる様をお使いになって。寝る。
0765デフォルトの名無しさん
2005/10/20(木) 03:08:35singleton
0766デフォルトの名無しさん
2005/10/20(木) 03:11:08それすごく意味不明。まさにグローバル変数の代わりにsingleton
使ってるだけの意味不明な設計じゃん。
本来座標とかはオブジェクトが持つ属性でね？
0767デフォルトの名無しさん
2005/10/20(木) 03:12:18＞馬鹿な私共に是非とも貴方様の素晴らしい意見をお聞かせください。
722じゃないが、変わりに言わせてもらうと
本当に素晴らしい人、できる人ってのは「ゴチャゴチャ言わず
すぐさま実践、そして実現している」ってこった。
持っている技術を説明したり、ひけらかしたり
逆に説明を受ける気も無いわけ。
それだと掲示板には無用な存在 ってことになってしまうけどなｗ
0768763
2005/10/20(木) 03:13:27何かスレ見に来たらあまり見覚えのない単語が飛び交って荒れてたから
ぐぐってみた結果の質問が>>763です(´･ω･)
0769デフォルトの名無しさん
2005/10/20(木) 03:13:540770デフォルトの名無しさん
2005/10/20(木) 03:28:360771デフォルトの名無しさん
2005/10/20(木) 09:25:04俺はいいたいこと言ったから、とりあえずはＯＫだよ。
後は、自分でやりたいように考えてもらうしかないっしょ。
その中でいい設計があるっていうなら出してもらえばいいし。
とりあえず、出てる中で俺が納得いくのは無いな（まあ、これも俺の独断だけど）。
ポリモに対してなんの疑いももたないで作ってた人は疑問持った人もいるでしょ？
つかえねーんだよ。これ。引数１個増えただけで破綻。
それを回避するのにまた破綻。
破綻の連鎖爆弾をプロジェクトに設置することになるから下手糞な人は使わないほうがいいよ。
また、プロジェクト進行中に設計に疑問なんか感じたら、かなりやばいしね。
小突いただけで簡単に揺らいじゃうような人やキッチリ納得できる
位置まで自分の中で完結してない人は使わないほうがいいよ。
ちなみに俺は>>732からこのレスの前まではレスつけてないからね。
案外、俺もただのキチガイじゃないっしょ？（笑）
0772デフォルトの名無しさん
2005/10/20(木) 10:02:570773デフォルトの名無しさん
2005/10/20(木) 10:31:55解決する方法はいくらでもあるけど、君のレベルじゃ微妙ってだけ。
下手糞な人は使わないほうがいいよってのは同意で、
C++でC++らしいコード書こうとすると慣れてない人はすぐ破綻する。ってのは
昔から言われ続けてるしな。
無理だと思うならCっぽく書いてけばいいんじゃない？
型変換保障されてるだけでもCよりマシだから。
言いたい事わからんでも無いがね。
型情報のデシリアライズが出来ないと、データドリブンと特化は相性悪いしな。
0774デフォルトの名無しさん
2005/10/20(木) 11:17:35つまり、「そんなの解決できないのは、あんたのレベルが低いからだよ」っていいたいわけ？
ここまで議論進んでるんだから、ちょっとはましな設計出してからいいなよｗ
この解決方法を聞きたいと思ってるのはたぶん俺だけじゃないぜ。
0775デフォルトの名無しさん
2005/10/20(木) 11:33:54もう結論でてるよ。
理解できないおまえがバカだって。
0776デフォルトの名無しさん
2005/10/20(木) 11:55:54グローバル変数使ったようなのとかシングルトンの変なのしかでてないけど？ｗ
0777デフォルトの名無しさん
2005/10/20(木) 12:20:35Enemy はさらにボスと弾、Background は背景とスコア表示とかを扱う。
つまり全体を階層構造にするんだな。
弾どうしは strategy を使うけど、弾と自機を1つにまとめたりはしないかな。
これが、俺の中では一番簡単だと思う。
0778デフォルトの名無しさん
2005/10/20(木) 12:52:41「目」など外部との通信手段があるかないかと言う決定的な違いがあるわけで。
ならばこの能力（たとえば視覚）をインターフェイスとして切り出せば、
他の、この能力を持つもの（自機を狙って弾を撃つ敵など）と共通化ができて、
処理をまとめることができる。
0779デフォルトの名無しさん
2005/10/20(木) 13:42:16それはわかりづらいよー
直感的な設計にしようぜｗ
>>778
なんかそれ、ホーミングミサイルの中にミサイルと目が内包されてる設計しか見えてこねぇよ。
なんか別にしちまうのってチガクネ？
そろそろ会議なんので離脱。
0780デフォルトの名無しさん
2005/10/20(木) 13:56:170781デフォルトの名無しさん
2005/10/20(木) 14:00:51で、振る舞いとかｱｸｼｮﾝなどのﾛｼﾞｯｸはｺﾏﾝﾄﾞで実装し、必要な情報はｵﾌﾞｻﾞﾊﾞから間接的にとる
ﾓｯｸてすとも簡単
0782デフォルトの名無しさん
2005/10/20(木) 14:05:020783デフォルトの名無しさん
2005/10/20(木) 14:28:410784777
2005/10/20(木) 16:21:08え〜。自機の当たり判定を rect とすると、当たり判定は enemies.hittest(rect); で出せるじゃん。
オブジェクトグループにそれぞれマネージャクラスを作るのが、直感的に見えないのか？
0785デフォルトの名無しさん
2005/10/20(木) 18:15:57いや、わかりづれーのはここ↓だよ。
>Enemy はさらにボスと弾、Background は背景とスコア表示とかを扱う。
ぶっちゃけセンスわりぃよ。
まとめる必要ないんじゃない？
0786777
2005/10/20(木) 18:18:23悪い。自機でも敵でもない、ゲームに直接の影響の無い (無いってことは無いんだが) オブジェクト群をまとめたつもりだった。
まとめる必要がなくても良いっス。
まとめられなかったら Background と Score とかに分けるから。
0787778
2005/10/21(金) 00:29:34>なんかそれ、ホーミングミサイルの中にミサイルと目が内包されてる設計しか見えてこねぇよ。
>なんか別にしちまうのってチガクネ？
具体的に何がご不満なのですか？
0788デフォルトの名無しさん
2005/10/21(金) 00:45:51別にわけたところでなんの解決にもなってないよ。
0789デフォルトの名無しさん
2005/10/21(金) 00:47:42＞つまり、「そんなの解決できないのは、あんたのレベルが低いからだよ」っていいたいわけ？
まさにその通り。
自分でも解ってるみたいじゃん。
スカスカの脳みそで訳の解らん分類して勝手に自爆してるだけ。
ＯＯＰの大事な要素の一つは分類をする為の分析能力なんだよ。
小学生の頃やった知能指数テストにあったでしょ？
複数の図柄見せられてチーム分けしたり仲間はずれ探したりするやつ。
あれだよ。あれ。お前にはその能力が生まれながらに欠如してんだよ。
0790デフォルトの名無しさん
2005/10/21(金) 00:53:03奇抜な発想が盛り沢山でオジサン着いていけないよ。ヽ(´ー｀)ノ
0791デフォルトの名無しさん
2005/10/21(金) 00:58:09ttp://pc8.2ch.net/test/read.cgi/prog/1122318533/l50
の 「リスコフの置換原則」 あたりと似た雰囲気を感じる。
0792デフォルトの名無しさん
2005/10/21(金) 01:05:20>つかえねーんだよ。これ。引数１個増えただけで破綻。
「引数１個増えただけ」とかいうセンスがわからん……引数の数が違えば扱う情報量が
変わるんだけどね……
まあ、「明示的なメソッド群による引数の置き換え」「オブジェクトそのものの受け渡し」
「引数オブジェクトの導入」ぐらいは調べといたら？重宝するよ
0793デフォルトの名無しさん
2005/10/21(金) 01:09:02救いがたい基地外だということはわかった。
0794773
2005/10/21(金) 01:18:54君以外の人は多分自己解決出来ると思うよ。
試しにSTGでも作ってみるといい。
C++等、不満が出てくるのは悪い事じゃないが、
やっても無駄だと思った時点で終了だな。
OOPというより、設計そのものに向いてない。
OOPは設計を縛るものではなくて、手助けするものという事を理解していない。
問題点が出るのは当たり前。より良いものにすれば良いだけ。
それが駄目だと言うなら、ずっと使い捨てコード書き続ければいい。
本人だけはそれが分かり易いと思ってるんだろう。
シンプルで判り易い、汎用性があるってのと、ハードコードの使い捨てコードだらけ、何もシステム化出来てない。
は似てるようで全く別物。
0795デフォルトの名無しさん
2005/10/21(金) 01:25:45叩かれている方もおられますが一人では勉強しにくい分野と思われますので謙虚に知識を共有しあえたら有意義ですよね
0796デフォルトの名無しさん
2005/10/21(金) 01:26:360797デフォルトの名無しさん
2005/10/21(金) 02:06:01これでも煽ってる方々は
はじめポリモーフィズムはオブジェクト指向に必須。以上。
みたいな煽り方してたんですよｗ
人と話はしてみるもんですよね。
結局、なんの解決策も示せないまま、ここまで無意味に煽ってこられたわけです。
ポリモーフィズムを使った時点でグローバル変数と
似たような構造のものが必要になるのはわからないんですかねぇ・・・ｗ
この構造で引数が増えるってでかいっしょ？
でも、ポリモーフィズムってのは、この程度の変更で大きな変更が必要となる組み方でもあるわけですよ。
正直、俺は自分のオブジェクト指向に絶対の自信をもってるよ。
君等程度の実力じゃ絶対に俺の域には到達できない。
理由聞いてみたい？
0798デフォルトの名無しさん
2005/10/21(金) 02:09:40いや、別に聞きたくない。
つーか、糞して寝てくれ。
0799デフォルトの名無しさん
2005/10/21(金) 02:20:29俺の通勤途中、道端でこの世の終わりみたいな顔して
腕時計見ながらギギギギ・・と喚いているスーツの若い
あんちゃんをよく見かけるんだが、こいつじゃないの？
0800792
2005/10/21(金) 02:31:21>この構造で引数が増えるってでかいっしょ？
だから、（多くの言語では）引数の数が変わればメソッドの意味も変わるんだって。
受け取る情報量（次数？）が変わるんだから。
まあ、引数の数が違っても同じメソッドとして処理できる言語もあったと思うけどね。
あと、C++なんかだと「引数オブジェクトの導入」を行えば引数の数の問題は
回避できるよ。
0801デフォルトの名無しさん
2005/10/21(金) 03:12:49＞正直、俺は自分のオブジェクト指向に絶対の自信をもってるよ。
はたで見ていて思うのは、そもそもの問題はこれかな、と。
797 の絶対だと考えている「オブジェクト指向」は、普通の人の考える
オブジェクト指向とは違うんだよ。たぶんそれは（手法としての）抽象
データ型だ。で、普通の人はそれに継承とポリモを足したものを（797
的には不要なものだから“引いた”？）ものをオブジェクト指向と呼んで
いるわけ。少なくともストラウストラップはそう定義して、多くの教科書は
これを暗黙の了解としている。それなのに、オブジェクト指向にポリモは
無用とか言うから、おかしな反発を招いとるんじゃないかと。
0802デフォルトの名無しさん
2005/10/21(金) 03:50:20引数の追加とかみんな過去に通ってきた道。とっくに解決出来てるし。
タスクを敵、さらにボス、弾等に分けて管理する事で、便利に判りやすくなる事はあっても、
デメリットなどないし。（基本的なタスク管理は当然大元がする）
これらで不満が出る事自体、「自分はまだまだ未熟です。」と言い回ってる事にしかならん。
こいつがどんなものを設計したかは興味あるな。どうせろくなもんじゃないだろうが。
0803デフォルトの名無しさん
2005/10/21(金) 15:10:40どうしても singleton が嫌なら、しなくてもすむ実装も出来るし。
0804デフォルトの名無しさん
2005/10/21(金) 16:33:49まともな実装としては引数で渡すぐらいしか残って無いな。
メンバ変数に保持しておくってのはやらんほうが賢明だよね。
0805デフォルトの名無しさん
2005/10/21(金) 16:44:29不自然な設計と思ってるのがそもそも勘違い。
（それならsingletonパターンなんてそもそもない）
グローバル変数がなぜダメなのか考えずに、
「グローバル変数は悪、よってsingletonも悪」
という思いこみを発揮しているだけだな。やれやれ。
それにstrategyを使う場合にsingletonにするのは
必須じゃない。（使わなくても同じ事ができる）
無駄なオブジェクトの生成を抑えるためにsingletonに
するのであってその辺がわかってない。
mutableとかimmutableとかたぶん意識したことが
ないんだろう。
つまり何にもわかってないど素人。
0806デフォルトの名無しさん
2005/10/21(金) 16:46:17理解してないみたいだな。はぁ。
0807デフォルトの名無しさん
2005/10/21(金) 16:48:15引数で渡してるのか？
何のためにオブジェクト指向を使ってるんだ？
0808デフォルトの名無しさん
2005/10/21(金) 16:53:56全然的外れなこといってるねｗ
0809デフォルトの名無しさん
2005/10/21(金) 16:54:560810デフォルトの名無しさん
2005/10/21(金) 17:19:49シングルトンなんて確実にグローバル変数or関数だし。
で、結局ポリモーフィズムなんて引数の数でもう使えなくなっちゃうでしょ？
こんな実装依存の糞概念いらねぇじゃん。
これがあやしいと思えない奴ってのは感性腐ってんだよ。
まずね。こういう奴等と俺と合わない理由ってのは根本にあるんだよ。
お前等はオブジェクト指向を理解してない。
そもそも、俺と話す前はオブジェクト指向にポリモーフィズムは必須とか
理由も説明できないくせに言ってたじゃん。
ここでもう自分の知識を疑えよ。俺の言うことを強引に否定できるほど頭よく無いでしょｗ
で、結局、ポリモーフィズムは後からできたものだってわかってから静かになったけど。
馬鹿なんだから、人の話よくきけよｗ
0811デフォルトの名無しさん
2005/10/21(金) 17:26:23> そもそも、俺と話す前はオブジェクト指向にポリモーフィズムは必須とか
> 理由も説明できないくせに言ってたじゃん。
どこら辺だ？レス番で示してくれ。
0812デフォルトの名無しさん
2005/10/21(金) 17:28:56途中から入ってきた人は過去ログ読んでね。
0813デフォルトの名無しさん
2005/10/21(金) 17:30:04グローバル変数とグローバル関数は同じモノなのか？
アホすぎ。
「副作用」が悪なんだよ。
副作用の起こらないグローバル変数は「定数」だし、
副作用のないグローバル関数はいつでも安全に使えるんだよ。w
自機と敵機のオブジェクトから座標やID、残HPなどの情報を
取得するために多態は使わないの？
バカじゃない？www
0814デフォルトの名無しさん
2005/10/21(金) 17:31:20最初からいたわけだが。
要するに、具体的に示すと自分の嘘がばれるから答えられないのね。
0815デフォルトの名無しさん
2005/10/21(金) 17:32:43オブジェクトの構造体からIDを取得してswitch caseで
分岐するモノだった！
そんな気がする。www
0816デフォルトの名無しさん
2005/10/21(金) 17:40:07というよりお前のオブジェクト指向とその他の人間のオブジェクト指向が別物なのだから、
そういう結論になるのは至極当然のこと。
0817デフォルトの名無しさん
2005/10/21(金) 17:41:50グローバル変数や関数なんて使ってる馬鹿はこんなとここなくていいんだよｗ
一体、いつから言われてることかわかってるのか、
いまだにグローバル変数や関数を使わない組み方すら知らないで恥ずかしくないのか？
ポリモーフィズムやるためにグローバル云々が出てきてしまうような設計なら、
まず、設計を見直すのが先だろ。
素で頭おかしいだろｗ
0818デフォルトの名無しさん
2005/10/21(金) 17:43:15そういう彼が推す「オブジェクト指向の本質」はきっと
「マルチプルインスタンス」
前橋のページの誤読者でないことを祈る。
0819デフォルトの名無しさん
2005/10/21(金) 17:44:36中身を理解してから書き込もうね。ボク。
なぜグローバル変数はつかっちゃいけないのかな？
しゅくだいをきちんとすませようね？www
0820デフォルトの名無しさん
2005/10/21(金) 17:45:45お前面白いからｺﾃﾊﾝにしなよ。
0821デフォルトの名無しさん
2005/10/21(金) 17:47:33つかっちゃいけないってかいてあるんだ。
だからしんぐるとんもつかっちゃいけないんだ。
じょうたいはぜんぶひきすうでわたすんだ。
それがいちばんきれいなんだ！
0822デフォルトの名無しさん
2005/10/21(金) 17:48:33さすがにそんな石器時代にまで戻って議論なんてしないよ（笑）
１人で悩んでろよｗカス野郎ｗ
0823デフォルトの名無しさん
2005/10/21(金) 17:49:350824デフォルトの名無しさん
2005/10/21(金) 17:50:15また中身なしレス。
ユー、コテハンにしちゃいなよ。
0825デフォルトの名無しさん
2005/10/21(金) 17:50:56俺のレス無視すんなって。
何番から何番なの？
0826デフォルトの名無しさん
2005/10/21(金) 17:54:19だいたい、グローバル変数とか関数とか使ってもＯＫ的な発言しちゃうし。
お前の設計の基準はなんなんだよｗ
回避しようと思わないのか？
どうして、グローバル変数や関数の使用回避がポリモーフィズムの実現より、
優先度が下になっちゃうんだ？
おかしいと思えよｗ
設計がどうあるべきかってわかってないだろｗ
俺の言ってること間違ってるか？
0827デフォルトの名無しさん
2005/10/21(金) 17:56:30設計の基準が教条主義的だ。
中身を理解してない。
仏作って魂入れず。
だからデザパタも理解できない。
0828デフォルトの名無しさん
2005/10/21(金) 18:01:49じゃあ、この↓辺とかどう？
>どうして、グローバル変数や関数の使用回避がポリモーフィズムの実現より、
>優先度が下になっちゃうんだ？
明らかにおかしいでしょ？
こういう状況になっちゃうのって。
こういうのなんで駄目なの？って聞くまでもなく駄目でしょ。
こういうのさ、いちいち説明して、２ちゃんで会話できないよ。
で、説明しないと説明できないとかどうとか騒ぎ出す始末だし。
さすがにまともな思考回路もってない人とそんなに議論なんて続ける気ないってｗ
だって明らかにおかしいでしょ？
自分がやってることってどうよ？
0829デフォルトの名無しさん
2005/10/21(金) 18:06:09どうでもいいから早くレス番を教えろ。
0830デフォルトの名無しさん
2005/10/21(金) 18:07:54>>813をしっかり読めよ。
strategyはアルゴリズムをインスタンス化したもので、
副作用がない設計にするんだよ。（当然）
これはアルゴリズムに対応した関数を作るのと本質は変わらない。
副作用を利用するグローバル変数を使うのとは違うんだよ。w
0831デフォルトの名無しさん
2005/10/21(金) 18:11:470832デフォルトの名無しさん
2005/10/21(金) 18:13:02だから、お前は自分が馬鹿なのを直してこいよｗ
0833デフォルトの名無しさん
2005/10/21(金) 18:14:25ていうか、いじるの飽きてきた。ww
0834デフォルトの名無しさん
2005/10/21(金) 18:20:01こんな↓意味不明で恥ずかしいこと言ってた仲間なのに飽きてきたも無いでしょう？
664 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/19(水) 23:41:39
>>556はオブジェクト指向を少しも理解していない。以上。
と書くのは簡単だけど勿論もっと書くよ？
・ポリモーフィズムはオブジェクト指向の一機能であると同時に不可欠。
・ポリモーフィズムはコードの一元化をスマートに行う機能である。
・ポリモーフィズムがもたらす利益は多々存在する。
・俺の問に問で返さずに答えて欲しい
・意図的に「以上の意味は無いでしょうよ。」の部分を削った理由を聞かせて欲しい。
・>>556に対して否定的意見を述べる理由を挙げているのに無視している理由を聞かせて欲しい。
ポリモーフィズムなんてオブジェクト指向を理解していない人間が
後付けでくっつけた糞機能だって理解できたの？
なにがどう、不可欠なのか教えてほしいよ＞ホラ吹き君達ｗ
始めにオブジェクト指向があって、その後に出来たものがオブジェクト指向に不可欠なわけないだろ。死ねよｗ
頭使ってよく考えてから、自信持てよｗ
全然レベル低くて話にならないｗ
0835デフォルトの名無しさん
2005/10/21(金) 18:20:02＞strategyはアルゴリズムをインスタンス化したもので、副作用がない設計にするんだよ。（当然）
そうでもない。strategy でまとめたメソッドから属性を変更するのは良くやること。
0836デフォルトの名無しさん
2005/10/21(金) 18:20:410837デフォルトの名無しさん
2005/10/21(金) 18:21:53改良とか改善とか推敲って言葉もしかして知らない？
0838デフォルトの名無しさん
2005/10/21(金) 18:23:09その説明で逃げるのは苦しくない？ｗ
0839デフォルトの名無しさん
2005/10/21(金) 18:24:01君の中ではあのStroustrup氏がオブジェクト指向を理解していないほら吹きなわけだ。
で、レス番は？
0840デフォルトの名無しさん
2005/10/21(金) 18:25:28ああ、もちろんそういう設計もある。
strategyをsingletonにする場合に、
複数のオブジェクトで使い回しても
副作用のない設計ということが言い
たかった。
0841デフォルトの名無しさん
2005/10/21(金) 18:25:43今来たところで話の流れ自体はよくわからないのだが
とりあえず>837は>>834を読んだ感想
0842デフォルトの名無しさん
2005/10/21(金) 18:28:29元のスレの流れがどうなのかは、
まるっきり知りません。
STGの設計の話じゃなかったの？
0843デフォルトの名無しさん
2005/10/21(金) 18:29:59「オブジェクト指向のポリモーフィズムは悪か？」 という話になって、
ついでに STG の設計の話が出てきた。
0844デフォルトの名無しさん
2005/10/21(金) 18:33:05実はそう考えてる。
彼は実は理解できてなかっただろ。
名声に騙されガチだけど。
誰か疑問をもってもいいんじゃない？
ポリモにしたってこんな機能なんで付けたのか全く理解できないほどの駄目っぷりだし。
いままで、制限を付ける形で発展してきたのに、急にこの分野になってから、
お便利機能程度のくっだらない内容を声高々に叫ぶようになったし。
食いつなぐ＝名声を保つのに必死だったんじゃねーの？
ま、人間だしね。
0845デフォルトの名無しさん
2005/10/21(金) 18:35:02最初のオブジェクト指向言語Simulaには
動的束縛があったみたいだな。
動的束縛があれば多態できるだろ。違う？
0846デフォルトの名無しさん
2005/10/21(金) 18:35:23申し訳ないが同感。
ストラウストラップ氏を責めるわけじゃないが、少なくとも氏はケイ氏の OO とは別の道を行ってるしな。
0847デフォルトの名無しさん
2005/10/21(金) 18:38:44あるよーな。C++は動的束縛なくてもプログラム
かけるけど、動的束縛できるし。
最初のオブジェクト指向に多態がないってのは、
どっからきてるんだ？
0848デフォルトの名無しさん
2005/10/21(金) 18:40:43おお、このスレきて以来はじめての同意。ｸｿｳﾚｼｽ
0849６５９
2005/10/21(金) 18:41:15ごめん。それ俺が >>681 で書いた。
そもそも、静的型付けの言語じゃないと多態が無いのよ。(多分)
多態はもともと型理論の用語だった気がする。
0850デフォルトの名無しさん
2005/10/21(金) 18:45:28それには同意できないなぁ。
俺は動的束縛で呼び出されるモノはすべて多態だとおもうけど。
つまりオブジェクト指向とSimulaの関係のように、多態という概念は
あと広まっただけで、オブジェクト指向の最初から含まれていたように
考えるけど。
0852デフォルトの名無しさん
2005/10/21(金) 18:53:34理解できなくもないけど、本来、多態と呼ばれるべきだった
モノをC++が「多態とは継承が必須な何か」に意味を狭めて
しまった希ガス。
メッセージングは本質的に多態を含んでいるというのは同意。
0853デフォルトの名無しさん
2005/10/21(金) 18:59:03inclusion, parametric, overload, cast の４つの多態は、どれも型付けに関しての用語のような希ガス。
0854デフォルトの名無しさん
2005/10/21(金) 19:03:07Sumulaに多態はなかったの？
0855６５９
2005/10/21(金) 19:04:290856デフォルトの名無しさん
2005/10/21(金) 19:11:290857デフォルトの名無しさん
2005/10/21(金) 19:15:14（この場合inclusion polymorphism）を持ってた事に
ならない？
0858デフォルトの名無しさん
2005/10/21(金) 19:18:57多態を持っていたって言うのは間違いないと思う。
ただ Simula の時点ではそういう用語は無かった可能性がある。
Simula の OO は、実は良く知らない。
継承とか、今ある OO に似ているものなんかな。
0859デフォルトの名無しさん
2005/10/21(金) 19:20:43｢多態を使うべきでないときに多態を使うべきでない｣ではなく｢いかなる場合も多態は不要｣と言ってるように聞こえるんだが、
この人はいったいどういった設計をしているんだろう。
俺の頭が固いのかもしれないけど、多態なしにOOPするなんてちょっと考えられない。
0860デフォルトの名無しさん
2005/10/21(金) 19:20:55なかったしねぇ。
Simulaの詳細は俺も知らん。
Algol系という噂しか知らない。
0861デフォルトの名無しさん
2005/10/21(金) 19:23:49＞多態なしにインタフェースの概念は実現できるのですか？
interface が java や C# のそれを指しているのなら、多態が無ければ意味が無い。
というか、動的型付け言語だと、そもそも interface が要らない。
interface は type system に必要だから作られた？
0862デフォルトの名無しさん
2005/10/21(金) 19:39:33あ、なるほど。静的言語しか考えてなかった。やっぱり頭固いな漏れ。
しかし、静的言語で多態なしOOPってどうする気だ？そもそも可能なのか？
それとも多態不要の人は最初から動的言語を念頭に置いててC++なんか眼中にないのか？
だとしたらこのディスコミュニケーションの説明もつくかもしれないが。
0863デフォルトの名無しさん
2005/10/21(金) 19:40:15彼の（そして現在主流の）オブジェクト指向は、その設計の過程で
整理されたもの。
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
0864デフォルトの名無しさん
2005/10/21(金) 19:45:17（メッセージング）と Smalltalk を作った。
SIMULA のクラスをヒントにリスコフは、彼女のオブジェクト指向
（あるいは、抽象データ型とも）と CLU を作った。
同様に、SIMULA のクラスをヒントにストラウストラップは、
彼のオブジェクト指向（カプセル化（抽象データ型）＋ 継承と多態性）と
C++ を作った。
0865デフォルトの名無しさん
2005/10/21(金) 19:47:14Smalltalkもinclusion polymorphismできる。
いずれにしてもオブジェクト指向の最初から
inclusion polymorphism（いわゆる多態）は
あった。
・・・・・が結論？
0866デフォルトの名無しさん
2005/10/21(金) 19:48:540867デフォルトの名無しさん
2005/10/21(金) 19:50:03多態はあった。用語が無かった。
0868デフォルトの名無しさん
2005/10/21(金) 19:50:43OK。すっきりした。
0869デフォルトの名無しさん
2005/10/21(金) 19:53:51どうも多態は型検査の用語のような気がしてしっくりこない。
動的型付けでも多態になってるのは分かるけど、動的型付けで多態という言葉を聞いたことが無い
……のは俺だけ？
0870デフォルトの名無しさん
2005/10/21(金) 19:55:260871デフォルトの名無しさん
2005/10/21(金) 19:58:05ttp://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=Ruby%CD%D1%B8%EC%BD%B8
＞ポリモルフィズム
＞多態, Polymorphism
＞対象になるオブジェクトによって実際の操作が決定されること。
＞Rubyではレシーバのオブジェクトに応じ てメソッドが選択される
＞ことによって実現されている。
動的型付き言語でも使ってるぞ。
0872デフォルトの名無しさん
2005/10/21(金) 19:58:540873デフォルトの名無しさん
2005/10/21(金) 20:11:450874デフォルトの名無しさん
2005/10/21(金) 20:34:040875デフォルトの名無しさん
2005/10/21(金) 21:11:38はじめは多態なんて無かっただろ。
オブジェクト指向をちゃんと理解したけりゃ、継承と多態の解説を抜いた本を探せ。
あまりにも糞な本が増えすぎた。
オブジェクト指向入門といいつつ、継承や多態の話から始めるような糞本を回避しろ。
多態なしにOOPするなんてちょっと考えられないなんて、
私、オブジェクト指向理解できてませんでしたってことだろ？
簡単な話だｗ
0876デフォルトの名無しさん
2005/10/21(金) 21:17:370877デフォルトの名無しさん
2005/10/21(金) 21:20:190878デフォルトの名無しさん
2005/10/21(金) 21:22:270879デフォルトの名無しさん
2005/10/21(金) 21:26:11Cで構造体に関数ポインタ入れただけのようなもんじゃん。
0880859
2005/10/21(金) 21:29:16すいません、ちょっと確認させていただきたいんですが、
・静的言語について話しているんですよね？
・使いどころによらず、ポリモーフィズムという概念そのものが糞であり不必要だ、という主張ですよね？
0881デフォルトの名無しさん
2005/10/21(金) 21:37:00継承と多態性のないオブジェクト指向というのもある。言語で言えば
CLU の流れを汲んでいるもの。Ada とか。ちなみにオブジェクト指向
設計で有名なブーチは、Ada での経験から、その考え方を育んだ。
世の中には、クラスによって型を定義できて（カプセル化）、継承と
多態性があってはじめてオブジェクト指向…という人（これが主流）と、
クラス（か、それに準ずる言語機構）で型を定義できれば、それで
オブジェクト指向…という人と、
カプセル化とか継承とかは関係ない（邪魔しなければあってもいい）。
メッセージングができれば、それでオブジェクト指向…という人がいる。
0882デフォルトの名無しさん
2005/10/21(金) 21:43:07あったんじゃねーの？
0883デフォルトの名無しさん
2005/10/21(金) 21:46:32あってもオブジェクト指向に関する機能はCでもあんまり苦労せずに
実現できるようなものばっかりになるよ。
0884デフォルトの名無しさん
2005/10/21(金) 21:54:330885デフォルトの名無しさん
2005/10/21(金) 21:58:49OOPの本質とか言い出したらアタマがおかしい人になる。
0886デフォルトの名無しさん
2005/10/21(金) 22:16:500887デフォルトの名無しさん
2005/10/21(金) 22:24:02>>881 の一番下に当てはまる人にとっては、非OOPL でも OO の実現は (それほど) 難しくないと思うんだが。
0888デフォルトの名無しさん
2005/10/21(金) 22:31:150889デフォルトの名無しさん
2005/10/21(金) 22:32:32ハッシュがあれば簡単だな。
配列のリニアサーチでも良いが。
継承が絡むと少し面倒だがそんなに難しいわけじゃない。
でも多態に類する機能がないのは話にならん。
0890デフォルトの名無しさん
2005/10/21(金) 22:34:58何らかの形で多態を実現する方法を持っていた。
OK？皆の衆。
0891デフォルトの名無しさん
2005/10/21(金) 22:35:51OK 兄者。
0892デフォルトの名無しさん
2005/10/21(金) 22:46:45脳を開けても胸を開けても心がみつからないのと同じ。
OOとか、確かにそこに存在しているという人の思いに
よって意味が与えられてるだけ。
0893デフォルトの名無しさん
2005/10/21(金) 23:29:33パラメトリック多相は C++ のテンプレートみたいなもので、
それこそオブジェクト指向とは関係ないだろ。多相とつけば
なんでもいいのか？
0894デフォルトの名無しさん
2005/10/21(金) 23:47:09対象になるオブジェクトによって実際の操作が決定されること。
Parametric PolymorphismもInclusion Polymorphismも
「対象になるオブジェクトによって実際の操作が決定」される
Polymorphism。
0895デフォルトの名無しさん
2005/10/21(金) 23:50:530896デフォルトの名無しさん
2005/10/21(金) 23:51:260897デフォルトの名無しさん
2005/10/22(土) 00:00:05非 OOPL で実現可能かもしれないけれど、けっして“容易”ということは
ないと思うよ。
抽象データ型（もちろん、そのスーパセットである君らの OOP 。すなわち、
カプセル化（＝抽象データ型）＋継承と多態性…な OOP ）で大事なのは、
ユーザーが定義した型が、基本型と同じように便利かつ安全に運用できる
ことなわけで、これを C などの非 OOPL で容易に実現できるとは思えない。
0898デフォルトの名無しさん
2005/10/22(土) 00:01:54なんでもない。
0899デフォルトの名無しさん
2005/10/22(土) 00:10:00上にも出てたけど、>>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) { /* ... */ }
0900デフォルトの名無しさん
2005/10/22(土) 00:12:29だから、多態ならなんでもいいのかって。
そもそもはオーバーライド（継承）によって実現される多態性が不要か
どうかってはなしなんじゃないの？
で、世の中には継承や多態性はいらないっていう、手法があって
それも「オブジェクト指向」と呼ばれることがあるってんでいいじゃん。
0901デフォルトの名無しさん
2005/10/22(土) 00:15:28でも、それをもって「CはOOPLだ！」とか言い出したらアタマ
おかしい人になる。
さらに「多態は本質じゃない」とか言い出すのはもっとおかしい。
0902デフォルトの名無しさん
2005/10/22(土) 00:15:460904デフォルトの名無しさん
2005/10/22(土) 00:18:47だから、そうして披露自慢したくなる程度には OOP 向けの言語機能や環境の
サポートなしでは“困難な”コトだったのでは？ 可能か否かなら、よほどタコな
言語でもない限り、たいていは“可能”だよ。
0905デフォルトの名無しさん
2005/10/22(土) 00:18:47いずれにしても型なりクラスなりでアルゴリズムを
共有する手段として多態なり多相なりが必要とされて
いるんじゃないの？切り口は違うけど。
逆に現在普及してるOOPL言語で、多態がない言語は
あるの？
0906875
2005/10/22(土) 00:27:56ポリモーフィズムなんて必須じゃねぇし、いらないってわかったらもういいだろｗ
結局、ポリモ使ったら、グローバルみたいなモン必須なことには変わりねぇだろ。
んでそれは駄目な組み方なんだからよｗ
いい加減、目を覚ませってｗ
ここでいくらレスつけたって過去は変わらねぇぞｗ
0907デフォルトの名無しさん
2005/10/22(土) 00:31:13いや。クラスと多態／多相性（パラメトリックは除く）は直接は関係ないよ。
クラスは型を定義するために（多くの OOPL ）で使われているだけ。
（クラスもオブジェクトも、もともとは OOP のためのものではないからね）
継承機構があるとき、共有云々のための（オーバーライドによる）多態性が
からんでくる。
ttp://www.research.att.com/~bs/hopl2.pdf
ttp://www.research.att.com/~bs/whatis.pdf
0908デフォルトの名無しさん
2005/10/22(土) 00:32:36居なかったなら読み返してくれ。
むしろ polymorphism が要らないのだったら OO は要らないんじゃないかとか思ったんだが。
0909デフォルトの名無しさん
2005/10/22(土) 01:12:21腹切れｗ
0910デフォルトの名無しさん
2005/10/22(土) 01:13:290911デフォルトの名無しさん
2005/10/22(土) 01:28:52http://pc8.2ch.net/test/read.cgi/tech/1128354256/l50
0912859
2005/10/22(土) 01:48:04とりあえず、>>880の認識であってるんですよね？
で、質問なんですが、多態を使用しないOOPの実際ってどんなかんじなんでしょうか？
たとえば、Compositeパターンを多態を使用せずに実現するとしたらどうすればいいんでしょう。
0913デフォルトの名無しさん
2005/10/22(土) 02:07:27ＳＴＧのような実用的な例を挙げてみろよ。教えてばっかじゃなくてさ。
要するに、C++,Java,C#で多態使わずにタスク等を一元管理する設計。とやらを。
出来るもんならなｗ
>>912
シーングラフにComposite使ってる例も多いな。
0914デフォルトの名無しさん
2005/10/22(土) 02:22:12>タスク等を一元管理する設計
こんなことする必要無いって気づけｗ
0915デフォルトの名無しさん
2005/10/22(土) 02:40:51キチガイはコテハンにしろ。
＞こんなことする必要無い
話にならんな。
ギャラクシアンの頃から利用されてるシステムを否定するか。
つーかゲームエンジンそのものの否定だな。
ようは毎回全部書き直せと？ｗ
キャラの種類が一つ増える度に、色んなコードを修正しなきゃいかんなｗ
そんな糞設計のプロジェクト組まされたらキレる奴続出だな。
否定するならまず、代案を出せ。出せるもんならな。
0916デフォルトの名無しさん
2005/10/22(土) 02:52:36前にこの手のキチガイを見たのは、たしかGOFスレ。
0917デフォルトの名無しさん
2005/10/22(土) 03:01:10ﾃﾗﾅﾂｶｼｽ
0918デフォルトの名無しさん
2005/10/22(土) 09:20:37いや、お前のような馬鹿は一度だって普通に組んだことが無い。
口ばっかり達者で実は糞タスク以外の組み方を知らないただのアホ。
代案を出せとか言ってるけど、そもそもお前はタスクを使わないで組んであるソースすら見たことないだけだろ。
結局、知らないだけ。
まあ、あんまり馬鹿で可哀想だから教えてやろう。
継承を一切使わずに組んでみろ。
0919デフォルトの名無しさん
2005/10/22(土) 10:49:00結局出せないのねｗｗｗ口だけはお前て事だな。
これだけ具体例出てるのに何１つ具体的に反論出来てないしねｗ
タスク使わないコード＞俺も学生の頃はそうだったよ。門外不出だし、今みたいにネットなかったし。
糞みたいなコード書くところから始めたね。
＞継承を一切使わずに組んでみろ。
継承も駄目？ギャグだろ？ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
お前、.NETやJavaでは組む事すら出来ないじゃんｗｗｗｗｗ
非効率的な組み方を極めるつもりか？ｗｗｗｗｗ
Cで組んであるＳＴＧの移植で似たような糞コードなら見たことあるよ。
タスクは使ってるんだが、それ以外のレイヤー層（ハード、ゲーム仕様）がごちゃ混ぜｗ
仕様変更の際、苦労したねー。読むのも苦痛だったし。
似たようなコードそこらじゅうにあるし。
お前みたいなキチガイが組むとこうなる。って感じの例だよ。
それ書いたやつには言っといたけど、「組むのが一番早いから」とか言い訳してたなｗ
組んで終わりじゃねーんだよｗ仕事は。
保守、仕様変更に強くして普通。
0921デフォルトの名無しさん
2005/10/22(土) 11:24:25もしかしてそれも駄目なのかな？ｗ
抽象化出来ないから、管理部分など作れない。だから、全部ベタ書きｗ
キャラＡの処理
キャラＡの処理
キャラＢの処理
キャラＣの処理
：
：
、、で、キャラが追加される度に書き直しｗ汎用性ゼロｗ
キャラが多数、目まぐるしく入れ替わるＳＴＧをどうやって再現するつもりだろうねｗ
ぶっちゃけ、落ちこぼれ学生か何かか？ＰＧだと思いたくないｗ
0922デフォルトの名無しさん
2005/10/22(土) 11:27:29STGのようにステージ上にある沢山の種類のオブジェクトを取り扱うのに多態性が無いなんてあり得ない。
多態性をサポートする言語機能を使わなくたって、概念上多態性を持つだろうよ。
0923デフォルトの名無しさん
2005/10/22(土) 11:33:57bullet[1].texture = (青弾のテクスチャ);
OO の多態ではないけど、こういうのも多態に通じるところがあると思った。
0924デフォルトの名無しさん
2005/10/22(土) 12:56:23>継承を一切使わずに組んでみろ。
ΩΩ＜それは ひょっとしてギャグで言っているのか!?
継承前提のライブラリはいくらだってあるのに……
0925デフォルトの名無しさん
2005/10/22(土) 13:05:12ところでコテハンつけてなくても呼称がキチガイで統一され始めてたりする？ｗ
0926デフォルトの名無しさん
2005/10/22(土) 13:08:280927デフォルトの名無しさん
2005/10/22(土) 13:12:150928デフォルトの名無しさん
2005/10/22(土) 13:17:50これか？
0929デフォルトの名無しさん
2005/10/22(土) 14:06:17全ての要素が不要になってしまう。
0930デフォルトの名無しさん
2005/10/22(土) 17:27:51ttp://sourceforge.jp/projects/aioec/
とりあえず入れてみた。猫プラグインとか、使い勝手向上させるプラグインも
最初から入ってるといいなぁ。。。
0931デフォルトの名無しさん
2005/10/22(土) 18:10:31それ使うとインストールがどうこうよりもダウンロードが楽ｗ
0932デフォルトの名無しさん
2005/10/22(土) 19:02:03継承使わないで組んだことないでしょ？
よく考えてみ？
そういう風にならないから。
0933デフォルトの名無しさん
2005/10/22(土) 19:05:240934デフォルトの名無しさん
2005/10/22(土) 19:07:37ソースファイルの肥大化を押さえて、どこまで安全に組めるかが勝負。
大抵は委譲を使うけど。
0935デフォルトの名無しさん
2005/10/22(土) 19:18:49まあ、追加でいっとくけど、
そういう方向で増えたとしても、
君のＳＴＧはいったい何種類の特徴をもった敵がいるんだい？
例えば、等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。
あとは自機の動きに反応して次の動きを選択するプログラムが入るだけだろ。
これだけでも結構できのいいＳＴＧが作れるのに、キャラＡ、キャラＢ、キャラＣ・・・なんてそもそもありえるのか？
こんなの１０種類もいきゃかなりの超大作だと思われるが、それでも１０種類程度ならソースに並べても大したことないじゃないか。
＃アインハンダーだっておそらくそんなにねーぞｗ
まあ、頭のいい奴は俺のいいたいことがわかりそうなもんだが。
この方向で、ソースが増大することはほとんど無いんだよ。
0936デフォルトの名無しさん
2005/10/22(土) 19:27:370937デフォルトの名無しさん
2005/10/22(土) 19:50:57神レベル
0938デフォルトの名無しさん
2005/10/22(土) 19:59:03句読点の使い方とか全角アルファベットとか文の特徴が似通ってる気が。
いい加減疲れてきてボロが出たのかな？
0939デフォルトの名無しさん
2005/10/22(土) 20:01:200940デフォルトの名無しさん
2005/10/22(土) 20:02:160941デフォルトの名無しさん
2005/10/22(土) 20:02:38本人がageまくってて意味ないが
0942デフォルトの名無しさん
2005/10/22(土) 20:36:18すごいオブジェクト指向だなｗ
問題は組めるかどうかじゃないと何度言ったら分かるんだ？
0943デフォルトの名無しさん
2005/10/22(土) 20:38:03レスの主旨を酌みとってよｗ
0944デフォルトの名無しさん
2005/10/22(土) 20:56:02甘えるな。
0945デフォルトの名無しさん
2005/10/22(土) 21:34:11俺は頭が良くないから君の言いたいことわかんない。
0946デフォルトの名無しさん
2005/10/22(土) 21:44:26だったらどこがどうわからんのか聞けばいいじゃない。
0947デフォルトの名無しさん
2005/10/22(土) 22:22:550948デフォルトの名無しさん
2005/10/22(土) 23:00:17>>等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。
て・・・
0949デフォルトの名無しさん
2005/10/22(土) 23:30:36別におかしいところはないように見えるが・・・
0950デフォルトの名無しさん
2005/10/22(土) 23:33:330951デフォルトの名無しさん
2005/10/22(土) 23:35:52どうして同じに聞こえるのか、そっちのが聞きたいよ・・・
0952デフォルトの名無しさん
2005/10/22(土) 23:41:21それに>>935の話の主旨はそこじゃあないぞ。
>>935の大事な部分は
「お前等が汎用性をもたせようとしてる部分は全部書き出したって大した量にはならないぞ」
ってところだ。
0953デフォルトの名無しさん
2005/10/22(土) 23:58:55思いこみだな。
大した量になるかどうかはSTGというだけじゃ判断出来ないだろう。
極端な話、RoboCodeみたいにみんなで動きをカスタマイズして遊びたいのかも知れない。
0954デフォルトの名無しさん
2005/10/23(日) 00:09:57わからないのに汎用性をつける部分の検証をしないっしょ？
思い込みはどっちなのよ？
0955953
2005/10/23(日) 00:38:09> わからないのに汎用性をつける部分の検証をしないっしょ？
もちろん。分からないのに、
>「お前等が汎用性をもたせようとしてる部分は全部書き出したって大した量にはならないぞ」
なんて事は言いませんな。
0956デフォルトの名無しさん
2005/10/23(日) 00:41:25はぁ？何言ってんの？
俺はわかるよ。
お前等はわからないんだろ？
必要の無い汎用性つけて悦にいってるようなアホなんだからｗ
しかも、それでグローバル変数＆関数作っちゃうしｗ
0957デフォルトの名無しさん
2005/10/23(日) 00:44:50てか、設計云々語ろうとする割にはグローバル変数とか関数使っちゃうし、
型誤魔化すし、処理をわけることを考えないで無理やりまとめることばっかり考えてるな。
お前等って。
なんでまとめるかな。
大きく複雑なモンは、小さく単純なモンに分けないとどの道管理は行き詰るぞ。
0958デフォルトの名無しさん
2005/10/23(日) 01:02:17何故その二つが並んで出てくるのかが分からん。
自分のまわりではポリモーフィズムを使いたがる人はグローバル変数に無頓着な人が多かった、という私怨^H^H経験則か何か？
0959デフォルトの名無しさん
2005/10/23(日) 01:13:13だから途中から入ってきたならまず過去ログ読めよ。
おめーはDirectX初心者スレのアホと同じレベルかｗ
0960デフォルトの名無しさん
2005/10/23(日) 01:29:04結局の実装に落とされる世界なのに、難しく考えすぎ。
0961921
2005/10/23(日) 03:26:42＞例えば、等速、等加速の敵の処理なんて全部一括してシステムを組めると思うんだ。
具体的には？君の嫌いなグローバル関数で纏めるのか？ｗ
それなら継承使った方がマシだなｗ
もっと具体的に言えよ。抽象化は嫌いなくせにな。
それともデータドリブンなんで敵の種類少なくていいんだよｗってオチか？
0963921
2005/10/23(日) 03:38:04馬鹿でかい汎用クラスをデータ駆動させる事なのかな？ｗ
確か、ダンジョンシージがそういう組み方してると聞いた事はあるが。
>>958
グローバル変数をクラス化するだけでも、問題となる副作用の殆どを抑制出来るよね？
まあ、シングルトンがどういったものかすら理解出来てないようだからねｗ
0964デフォルトの名無しさん
2005/10/23(日) 04:44:51Aho aho = new Aho();
これが解らない。
Aho baka = new baka();
0965958じゃないよ
2005/10/23(日) 05:18:38>>959
一通り読んだが、さっぱし解らん
DirectXを、上手く「カプセル化」出来ないのを恨んでるって事？
>>963
そう言う意味じゃないと思う
シングルトンとポリモーフィズムは殆ど関係が無い
0966デフォルトの名無しさん
2005/10/23(日) 07:12:57前者はただのアホ、後者は馬鹿を含んだアホってことじゃない？
0968デフォルトの名無しさん
2005/10/23(日) 09:15:00ん〜。むしろバカをアホとして扱うってことじゃないのかな。
0969デフォルトの名無しさん
2005/10/23(日) 10:35:17抑制できるできないの問題じゃなくて、
グローバルにした変数や関数を使った時点でそのクラス（ソース？）との関連ができちゃうでしょ？
引数から呼ばれてるわけでもなければ、メンバ変数でも無い。
こういうのをソース中に散りばめるとバグが増えるよ。
単体動作のできないクラスをたくさん作ることになるし、はっきりいってただの無駄。
正直、いちから勉強し直せってレベルだから、君の発言スルーしてたんだよねｗ
0970デフォルトの名無しさん
2005/10/23(日) 12:10:320971デフォルトの名無しさん
2005/10/23(日) 12:21:13スレ違い。
それとポリモーフィズムの有効性と何が関係あるんだよ。
0972デフォルトの名無しさん
2005/10/23(日) 13:01:01それは921に言ってやれ
0973デフォルトの名無しさん
2005/10/23(日) 13:16:40スレの流れとしては>968か
0974792
2005/10/23(日) 13:58:08ホント、いいかげんID導入してほしいな……
>969
>グローバルにした変数や関数を使った時点でそのクラス（ソース？）との関連ができちゃうでしょ？
>引数から呼ばれてるわけでもなければ、メンバ変数でも無い。
引数／メンバ変数にしても依存は回避できませんから〜〜
グローバル変数の問題点はそこじゃなくて、
・変更を管理できないので、想定外の挙動の対応が困難。（時にマルチスレッド）
・アクセス可能な範囲を制限できないので、凝縮度が低くなる
といったところかね。
C++だと、その他に初期化／終了タイミングの管理とかあるけど。
また、グローバル関数は、副作用を持たないかぎりあまり問題にならないよ。
問題は名前空間の汚染ぐらいかね。
0975デフォルトの名無しさん
2005/10/23(日) 14:51:28ことははっきりしたな。
彼が振り回してるのは古の構造化手法でのタブーで
オブジェクト指向そのものを理解してない。
0976デフォルトの名無しさん
2005/10/23(日) 14:59:22グローバル変数擁護君はまちがってもデザパタわかってるとか言って欲しく無い。
0977デフォルトの名無しさん
2005/10/23(日) 15:03:50もしかしてsingletonオブジェクトは
グローバル変数に保持すると思ってるんだろうか？
アホすぎ。
0978デフォルトの名無しさん
2005/10/23(日) 15:13:48>引数から呼ばれてるわけでもなければ、メンバ変数でも無い。
この文章が決定的に「ポリモいらない君」が何にも理解してないことを
如実に物語っているわけだ。(・∀・)ﾆﾔﾆﾔ
0979デフォルトの名無しさん
2005/10/23(日) 16:21:29そこはあってる。
ポリモいらない君が駄目なのはそこじゃない。
0980デフォルトの名無しさん
2005/10/23(日) 16:29:55彼が思ってるつうのはsingletonを理解してないからだと思うよ。
0981デフォルトの名無しさん
2005/10/23(日) 16:42:32そもそもポリモとsingletonは関係無い。
0982デフォルトの名無しさん
2005/10/23(日) 17:45:50>>688
> 強引にポリモーフィズムやるために引数をなくしてグローバル変数かシングルトン使う奴いるでしょ？
> もしくはvoid*かそれに相当するもの。型誤魔化し。
> それを脳内で結びつけて勝手に俺が煽り口調でレスしただけだから、
> 自分はそんなことやってないと思ったらスルーでかまわない。
つまり勝手に妄想して関係のない話を持ち出しただけ。
0983デフォルトの名無しさん
2005/10/23(日) 17:46:46理解してないのは確かだな。
0984デフォルトの名無しさん
2005/10/23(日) 17:54:52それと、「void*かそれに相当するもの、型誤魔化し」が並べて書い
てあるのもワケわからん。
0985デフォルトの名無しさん
2005/10/23(日) 18:19:19どう考えてもポリモーフィズムとは結びつかない。
そこで話は終わりなのに、グローバル変数を擁護する人間とか、
ポリモーフィズムの正しい使い方を挙げられない人間ばっかりで、
反論している奴のレベルも著しく低い。
0986デフォルトの名無しさん
2005/10/23(日) 18:24:10その相互作用というものを考えていくと多態性というものが自然と出てくる。
今日、この多態性を利用せずにプログラムを作る事は事実上不可能だ。
OSがアプリケーションを統一的なしくみで起動できる時点で多態性を利用していると言える。
実装よりな視点で使えない！ バグり易い！ 処理が変われば引数も変わる！
などと言ったところで、現実にみんな既に使っているものなのだ。
結局このポリモいらない君の不味いところは、自らの狭い経験から「ポリモつかえね」
と言い切って書いていることにある。
「使いどころをわきまえよう」程度にしておけば問題ないものを。
09871/2
2005/10/23(日) 18:29:12strategy パターン一筋の人に警告してみる。strategy が悪いとは言わないけど、今一度考え直して欲しい。
◆ 前提
STG を作ることを考えて、画面上に配置できる全オブジェクトの親クラスを ScreenObject としてみる。
そして、strategy を使ってまとめることを考えてみる。
09882/2
2005/10/23(日) 18:29:57例えば、画面描画に使う DrawScreen(Screen) メソッドは ScreenObject に入れるべきだろう。
そのほかにも当たり判定を調べる HitTest(RECT) や、
スコアを更新する SetScore(int) 等も ScreenObject に入れると “strategy でまとめる” ことができる。
この場合の問題点は、ScreenObject に大量のメソッドが入ること。
おそらく、その中には何も行わないメソッドも沢山あるだろう。
無駄な処理を行うことと引き換えに、オブジェクトを strategy で１つにまとめることが、果たして良いことなのだろうか。
◆ パターン２: ScreenObject に入れるメソッドの粒度を荒くする。
例えば、ScreenObject には最低限 『描画前に行う処理 (移動など)』 『描画処理』 『描画の後処理』 の３つのメソッドがあれば良い。
それ以外の情報は、全ての ScreenObject に共有されるオブジェクトによって仲介される。
粒度を荒くすることで、ScreenObject は “strategy でまとめる” ことができる。
この場合の問題点は、仲介用のオブジェクトが巨大になること。
自機座標から敵機座標、自弾の当たり判定にアイテムの位置、現在のスコアまでが全部１つにまとまる事になる。
そしてもう１つ。
『前処理』 『主処理』 『後処理』 だけのメソッドを持つオブジェクトを作ることが、果たして本来のオブジェクト指向なのだろうか。
ココまで粒度を荒くすると、どんなオブジェクトも strategy でまとまる。ちょっと考えて欲しい。
0989デフォルトの名無しさん
2005/10/23(日) 18:31:14話のすべてに根拠が無い。
にわかデザパタ君、レスつけないでおいてくれたほうがいいんだけど。
0990デフォルトの名無しさん
2005/10/23(日) 18:31:33スレを読み返してみたが、そんな人間になかったぞ？
ここはsingletonにできる、とか言ってた奴はいたが。
それよりもsingletonイコールグローバル変数として
煽ってたレベル低い奴はいたな。ポリモいらない君。
0991デフォルトの名無しさん
2005/10/23(日) 18:34:37そもそもstrategyで全部まとめろ的主張じゃないんだが。
元々strategyを使えば？と言ってたのは、ミサイルの移動
アルゴリズムの問題だけだし。
0992987-988
2005/10/23(日) 18:38:22だから 『ミサイルは strategy でまとめれば全て解決』 って言われたからそれに対する警告。
上からずっと流れを追ってたんだけど、strategy が大好きな人が居るっぽいので。
まとめないことも重要だろうに。
思考停止してパターン化された解を求めてはいけない。
0993デフォルトの名無しさん
2005/10/23(日) 18:40:54「ポリモいらねー」って人は使えない。
strategy的なことをポリモなしで実現しようとすると、IDによってswitch case
とかでしょう？それってポリモ手作業でやってるのとあまり変わらない。
引数が異なる場合について「ポリモいらない君」は文句を付けてるわけだけど、
strategy側に参照をあらかじめ持たせるとか回避する方法はいくらでもあるよな。
0994デフォルトの名無しさん
2005/10/23(日) 18:42:33それこそ設計側の詳細であってここで議論するような問題じゃない。
でもホーミングミサイル程度の問題strategyで十分にまとめられる
問題だよね。
0995デフォルトの名無しさん
2005/10/23(日) 18:44:46>strategy側に参照をあらかじめ持たせるとか
なんで一番反論が来そうな例をわざわざ挙げるかな。
0996986
2005/10/23(日) 18:46:00俺はここでデザインパターンに関する事を一つも書いた事はないよ。
ずいぶん妄想癖があるようだけど、妄想でレスを返さないで理解したくないなら素直にそう書けば？
0997987-988
2005/10/23(日) 18:46:06一行目には同意。言ってみただけだ。
二行目以降には突っ込んでみる。
ホーミングミサイルは弾ではなくむしろボスと認識するべきではないのか、とか。
まとめても良い。まとめる場合には、何とまとめるか考えなくてはいけない。
まとめなくても良い。まとめない場合には、煩雑するオブジェクトをどうやって管理するか考えなくてはいけない。
つまり何が言いたいかというと、『次スレよろしく』
0998デフォルトの名無しさん
2005/10/23(日) 18:47:19大量のメソッドが一つのクラスに集中するような
書きぶりだが、strategyパターンはそもそもアル
ゴリズムごとにクラスを分割するパターンなんだが。
0999デフォルトの名無しさん
2005/10/23(日) 18:48:581000デフォルトの名無しさん
2005/10/23(日) 18:49:051001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。