-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590720デフォルトの名無しさん
2011/09/12(月) 23:58:24.90>ありがとうございます
いいぇ、私は何もしていません。自分自身で解決していると思います。
>data_d:array[0..10000000,0..30] of double
Integerの場合は、「data_d:array[0..10000000,0..60] of Integer」と定義しても大丈夫なんでしょうか？
>>312
>静的配列と動的配列はメモリ確保の方法が全く違うんだが
すみません、"全く違う"とはどう違うんでしょうか？教えて下さい。
>>313
>ローカル変数として確保しようとしてスタックオーバーフロー起こしただけだったりして
すみません、ローカル変数の確保がなぜ”スタック”オーバーフローになるのか、教えて下さい。
0721デフォルトの名無しさん
2011/09/13(火) 11:01:06.03スタック消費するならオーバーフローするのは当たり前な気がするが・・・？
0722デフォルトの名無しさん
2011/09/15(木) 00:28:47.64実体を持つstaticフィールドを1個だけもち、全てのインスタンスが、そのフィールドに問い合わせ
するようにしても同じじゃん。
classs Logger
{
private static LoggerCore core;
public Logger()
{
if( null == core ) core = new LoggerCore();
}
}
0723デフォルトの名無しさん
2011/09/18(日) 12:37:17.44何が便利なんだか、わからん。
ただ、LoggerでLoggerCoreの全てのメソッドを、いちいち委譲しなきゃならなくなった
だけなのでは？
0724デフォルトの名無しさん
2011/09/18(日) 13:30:35.43Core自体は処理をもたなくてもいいんだよ。
言語によっては構造体でいい。
あと、シングルトンで継承しない場合はともかく、
したほうが良い場合でも、staticメソッドを使う場合は
上手く継承できない。
更に言えば、コンストラクタでオブジェクトを生成するのを
前提としたインターフェースに対し、staticメソッドでオブジェクトを返す
シングルトンオブジェクトだけは特別扱いしなきゃならない。
object.exampleNew(Logger.class); //Singletonも他のクラスと同様に生成できるべき。
0725デフォルトの名無しさん
2011/09/18(日) 17:37:53.97new LoggerCore(); でインスタンスを生成されると困るから
Singletonにするのでは？
0726デフォルトの名無しさん
2011/09/18(日) 17:48:03.390727デフォルトの名無しさん
2011/09/18(日) 19:10:47.820728デフォルトの名無しさん
2011/09/18(日) 19:21:34.270729デフォルトの名無しさん
2011/09/18(日) 21:31:28.690730デフォルトの名無しさん
2011/09/18(日) 22:25:49.47「Coreが処理を持たない」って、データだけ持つの？それで隠蔽化できてるの？
あと、シングルトンであるべきか否かはクラスの責務で決まるはずだから、継承したら変わるのでは？
まぁ「コンストラクタでオブジェクトを生成〜」は分からんでもない。シングルトンオブジェクトを
ラップするクラスを作る必要があるので、確かにこれに似た状態になるな。
0731デフォルトの名無しさん
2011/09/18(日) 22:31:28.55>>726が実現できるのは、内部クラスを作れる言語だけだ。
0732デフォルトの名無しさん
2011/09/18(日) 22:31:59.86class Logger
{
private static class LogField
{
int data1;
int data2;
}
private static LogFiled core;
public Logger()
{
if( Logger.core == null )
{
Logger.core = new LogField();
//必要なら初期化
}
}
//他coreを操作するメンバー
}
0733デフォルトの名無しさん
2011/09/19(月) 03:18:31.74例となるクラス図が載ってるサイトありますか？
0734デフォルトの名無しさん
2011/09/19(月) 22:01:52.57確かにそれでもシングルトンにはなるけど、
new Logger()だと中身が共有されてるってことを想像しづらいから、staticメソッドを使うんだと思う。
0735デフォルトの名無しさん
2011/09/19(月) 23:23:58.980736デフォルトの名無しさん
2011/09/20(火) 11:49:03.57むしろシングルトンと通常のオブジェクトを
インターフェース的に区別する必用がある？
0737デフォルトの名無しさん
2011/09/22(木) 01:05:30.38すべてのクラスは引数なしのコンストラクタを持つべきって主張してるわけじゃないよね。
シングルトンなんて使わずにモノステートを使おうよって話？
例にあるLogger自体はシングルトンじゃないから、シングルトンの説明に使おうとするなら根本的に間違ってると思うけど。
0738デフォルトの名無しさん
2011/09/22(木) 09:47:13.61引数があるかどうかはどうでもいいんだけど、
他のオブジェクトとインターフェースは同一にすべきとは考えてる。
リフレクションとか使う既存のリソースを再利用できるからね。
シングルトンと違うってのは、staticメソッドを使わないから違うって事言ってるの?
それとも空のインスタンスが生成されるから機能面で違うといってるの?
0739デフォルトの名無しさん
2011/09/22(木) 09:57:37.36モノステートとはちょと違うね。
例では分かりづらいけど、全てインスタンスメソッドだから。
0740デフォルトの名無しさん
2011/09/22(木) 21:07:57.85>>733
PACパターン で画像検索
0741デフォルトの名無しさん
2011/09/22(木) 22:10:00.87なるほどねー。ググったらstaticメソッドだらけのクラスを
モノステートと呼んでる所があったから違うと思ったけど、
ググり直したら全部インスタンスメソッドのものを
モノステートと呼んでる所があった。
これからはモノステートを
調べる事にするわ。
0742デフォルトの名無しさん
2011/09/23(金) 00:15:41.36完全に monostate が singleton の上位みたいな感じだな
よっぽど継承を封じ込めたくてfinalも無いような環境か
アドレスレベルで比較して同一と判断しなきゃならない場合を除いて
基本的に monostate を使っとけばいい感じだな。
0743デフォルトの名無しさん
2011/09/24(土) 22:41:09.72state/strategyとFactoryMethod使うと
OOっぽさが6割増し位になるよね
0744デフォルトの名無しさん
2011/10/21(金) 10:34:03.120745デフォルトの名無しさん
2011/10/22(土) 19:39:25.14自販機とかの架空の例や、顧客どうのこうのといった大きな例じゃなく、
小さなアプリを UML の記述から始めて OOP で作って完成させる例がほしいです
解説する言語も、プログラミング言語も問いません
数独ソルバ程度の小さなアプリであれば数独ソルバでなくてもいいんですが、
数独ソルバの例だとありがたいです
0746デフォルトの名無しさん
2011/10/22(土) 23:05:57.480747デフォルトの名無しさん
2011/10/22(土) 23:37:24.78いや、宿題じゃなくて・・・
関数型言語スレで、関数型言語だとUMLは書かないのかという質問があって、
OOP と FP でアプリの作り方（完成までの道のり）にどれくらい違いがあるのか興味が沸いて、
比較してみようと思いました
それで、既に UML を使った OOP での例があるなら、
OOP の方はそれを拝借した方が手っ取り早いと思っただけです
無いのでしたら、自分で両方の言語で試してみます
0748デフォルトの名無しさん
2011/10/23(日) 01:28:31.63一般的なUMLベースのOOP入門という題材なら「いくらでも」ころがってる
目的と手段をはき違えているように見える
もしどうしても数独ソルバにこだわりたいのなら、宿題スレへ逝ケ
0749デフォルトの名無しさん
2011/10/23(日) 02:12:11.39「数独ソルバでなくてもいい」 >>745 で言いました
> 一般的なUMLベースのOOP入門という題材なら「いくらでも」ころがってる
UML を使ってゼロから設計してアプリケーションとして完成させている例が無いです
「いくらでも」と言うのなら 10 例くらいWebページを挙げてほしいです
UMLで図を描いて終わってるページや、ソースコードだけのページはありますが
数独ソルバなら、パラダイム間で設計手法を比較する例としては
登場すると思われるクラスの数も多すぎず少なすぎず、
またデータが入力されたら解の出力まで処理が一直線なので、
クラス全体の関係を比較的見通し安いと思ったからです
今のところ他にいい例が思い浮かびません
また、FP の方では数独ソルバを既にゼロから設計して完成させているので、
OOP の方でも同じ例の方が楽です（別の例なら FP の方でも新規に作る必要がある）
べつに拘っては無いので、何度も言いますが、数独ソルバでなくてもいいです
> 目的と手段をはき違えているように見える
目的は >>747 のとおり設計手法の比較で、手段は（今のところ）数独ソルバですけど
履き違えてるように見えたのですか？
0750デフォルトの名無しさん
2011/10/24(月) 18:00:43.900751デフォルトの名無しさん
2011/10/24(月) 19:13:45.03無理かどうかはどうでも良くて、そういうWebページがないかどうかです
いくらでもあるそうですけど・・・
0752デフォルトの名無しさん
2011/10/25(火) 08:10:57.02そういう題材でサンプルを作ろうという話がそもそもない、というのはあるかもよ。
調べてないから想像だけど。
試しに、軽く自分で設計してみたらどうか。
0753デフォルトの名無しさん
2011/10/25(火) 08:14:31.30http://twitter.com/asami224/statuses/128609304684134401
http://twitter.com/asami224/statuses/128609800404746240
0754デフォルトの名無しさん
2011/10/25(火) 18:35:52.68その軽く設計ってのを省けるなら省きたいって質問なんだと思う。
すでに数独ソルバで片方やっちまってるからOOP版があれば欲しい、
ないなら数独ソルバには拘らないからOOPで設計実装してるの何かない？ ってことだと思うんだが。
あとどうでもいいけどFPって聞くと見積りの方が先に出てきて変な感じだ。
0755デフォルトの名無しさん
2011/10/25(火) 19:22:22.53その数独ソルバってのがよく分からないんだけど、多分アルゴリズム系だよね？
題材自体が、責務でインタフェース切ってオブジェクトに分割して、という方法論と
合わない気がするなぁ。
それ以外でもいいということなら、なんか著名な書籍を一冊買ってくるとかの方が早いかも。
0756デフォルトの名無しさん
2011/10/25(火) 19:46:20.70もの凄く分かりやすい代弁ありがとうございます
私も３行で自分の発言をまとめられる人間になりたい
>>755
私にとってはアルゴリズム系という意味の方がよく分からないのですが・・・
トイブログラムとか実験プログラム、検証プログラムとかの類じゃなくて、
ユーザーが数独の初期配置を画面に入力し、解答ボタンを押すと、
その数独の解答が表示されるというアプリです
当然、問題自体が間違っていて解答が複数存在すれば複数表示されますし、
解無しなら解無しと表示されます
すいません、その「著名な書籍」を一冊教えていただきたいです
今まで買ったオブジェクト指向の入門書や方法論的な本、UMLの本などは、
使えるアプリケーションとして完成させるまでに至っていませんでした
コアの部分をサンプルや例題として使ってオブジェクト指向的に考えたり、
アプリの全体的な設計図をUMLで表す道筋を何かのサンプルで示す、
というものばかりで、どちらも解説は丁寧ですが、「ゼロから完成」が無いんです
Webページも上記のパターンのどちらかのしか私は見つけられませんでした
いくらでも転がっているそうですけど
自分で作ってもいいんですが、私のようなオブジェクト指向未熟者じゃなく
お手本となるようなページを探してましたが、無さそうなので、とりあえず諦め、
拙いなりに自分でゼロから作る事にします
ありがとうございました
0757デフォルトの名無しさん
2011/10/25(火) 19:48:48.01正しい意味を始めて知りました
0758デフォルトの名無しさん
2011/10/25(火) 19:50:58.75すいません、意味合ってました
これだから電子辞書は ヽ(｀Д´#)ﾉ ﾑｷｰ
0759デフォルトの名無しさん
2011/10/25(火) 21:33:15.74ああなるほど、そういう「アプリケーション」レベルの設計の話か。
残念ながら、俺も「あるなら教えて欲しい」という感じなので力にはなれそうもない。
ただ、どんな手法でもウェブ上で「アプリケーションを一から設計して〜」というサイトは見たことが無い。
「ウェブは暇人によって支えられている」とは誰かの言葉だが、そういうメディアじゃないんだろうな、ウェブは。
なので本で探した方が確率は高いとは思う。
0760デフォルトの名無しさん
2011/11/05(土) 22:40:44.92TDDやプロトタイピング等で、ソースコードを設計書代わりにしちまうしなあ
0761デフォルトの名無しさん
2011/11/17(木) 13:21:21.981マス１マスをオブジェクトにするとかあるな。
マスに当てはまる候補を格納したり、
マスに所属するグループ持たせたり、
グループをオブジェクトで表現したり、
枠の判定を多態で表したり。
0762デフォルトの名無しさん
2011/11/28(月) 11:52:55.15・ネコ亜目 Feliformia
・ネコ科 Felidae : ネコ類、18属37種
・イヌ亜目 Caniformia
・イヌ下目 Cynoidea
・イヌ科 Canidae : イヌとその類縁、10属35種
この分類納得行かないよなｗ
イヌ科の元がネコ目だなんてｗ
0763デフォルトの名無しさん
2011/11/28(月) 18:13:25.550764デフォルトの名無しさん
2012/01/12(木) 23:56:38.89オブジェクト指向的な考えからするとdynamic_cast同様あまり良い設計とは言えないものなのかな？
0765デフォルトの名無しさん
2012/01/13(金) 00:24:26.78プロセス超えるからわざわざ書いてるだけで
面倒なだけだと思うけど。
0766デフォルトの名無しさん
2012/01/13(金) 00:39:51.73dynamic_castだとインターフェース以外にも正常にキャストできるけどQueryInterfaceはそれを制限できる、とか
直接的な継承関係がなくてもインターフェースを継承しているメンバのアドレスを返すことで代替できる、とか
0767デフォルトの名無しさん
2012/01/13(金) 20:27:05.48どいうこと!?
0768デフォルトの名無しさん
2012/01/13(金) 20:40:14.840769デフォルトの名無しさん
2012/01/13(金) 21:11:09.620770デフォルトの名無しさん
2012/01/13(金) 23:52:31.100771デフォルトの名無しさん
2012/01/14(土) 16:53:08.130772デフォルトの名無しさん
2012/01/14(土) 16:58:17.320773デフォルトの名無しさん
2012/01/14(土) 18:33:03.340774デフォルトの名無しさん
2012/01/14(土) 18:40:03.430775デフォルトの名無しさん
2012/01/14(土) 20:05:31.28この4つぐらいしか判定要素に使わんからワザワザ型判定する必要もない。
衝突判定対象要素の全に対し、この要素を取得できるようにしとけば済む。
0776デフォルトの名無しさん
2012/01/14(土) 20:39:43.40衝突するかどうかの処理じゃなくて
衝突した後どうなるかの処理だろハンドリングって書いてあるし
0777デフォルトの名無しさん
2012/01/14(土) 21:24:03.890778デフォルトの名無しさん
2012/01/15(日) 00:52:32.82ハンドラなんかいらない
0779デフォルトの名無しさん
2012/01/15(日) 01:02:23.53例えばタンクと下半身の壊れたガンダムが良い感じの角度と速度で衝突した時は特定のモーションを経て合体してガンタンクになる
というような処理は全オブジェクトに共通する通常の衝突処理フローでは実現できない
0780デフォルトの名無しさん
2012/01/15(日) 01:19:04.87オブジェクトを生成した際に特定オブジェクトのセットへの参照を
持たせておいて、衝突判定が降りた際、その衝突した
対象のID(もしくはポインタ)がセットの中に存在するかチェックすればいい。
そのほうが処理が早いし柔軟性も効く
0781デフォルトの名無しさん
2012/01/15(日) 01:42:58.29特殊処理が必要な型が増えるたびに冗長なコレクションを増やして、
しかも衝突するたびにそのコレクションから検索する、だなんてどうみても安くはつかないぞ
0782デフォルトの名無しさん
2012/01/15(日) 01:51:38.90> そのやり方はとても現実的とは思えない
なるだろうけど、らしく振る舞うだけなら省略できる部分がたくさんあるわな
つか、 計算しなくても済むところまで計算してるだろ？
0783デフォルトの名無しさん
2012/01/15(日) 12:19:27.31現実には0〜5程度。現実にはdynamic_castなんかより
setの方がコストは低いよ。とくにHash setにしてしまえば歴然。
あと、setであれば、その型が何かで限定する必然性は無くなる。
set<Tank*>, set<Gundom*> なんて分ける必要なく、set<Unit*>ひとつでいい。
入れられるオブジェクトを制限したい場合は別だろうけど。
コレにより、人間の見たキャラでクラス分けしなくて済むようになる。
機能でクラス分けすればよくなる。
0784デフォルトの名無しさん
2012/01/15(日) 13:04:50.24あるオブジェクトがその機能を持っているかどうかの問い合わせはそのレジストリから検索してあたりがあるかどうかで調べる
オブジェクトが死んだらレジストリから削除しなければならない
拡張によって特殊な機能が増えと新しいレジストリを作らなければならない
・ある機能を持っているオブジェクトかどうかそのオブジェクト本人に問い合わせる
拡張によって特殊な機能が増えてもその追加された機能を継承するクラスだけQueryInterfaceメソッドに1行追加するだけで良い
どっちが目的を明確に表していて、シンプルで理解しやすく、効率がいいのか、一目瞭然だろう
0785デフォルトの名無しさん
2012/01/15(日) 13:14:59.610786785
2012/01/15(日) 13:15:35.280787デフォルトの名無しさん
2012/01/15(日) 13:22:55.67パターン1個追加するたびに、関係するクラス全部変更ってのは不便。
人間始点ベースで組むと得てして拡張性は下がる。
たとえば、画面上のキャラ座標(固有ステータスも含む)と、
キャラクラス(形状データ、アクションデータ)はオブジェクトとして
一緒にしないでしょ。キャラ座標に、キャラクラスへの参照を持たせる。
拡張性を考えるなら見た目と、データ構造は一致し無いのが普通。
0788デフォルトの名無しさん
2012/01/15(日) 13:27:47.57>拡張によって特殊な機能が増えてもその追加された機能を継承するクラスだけQueryInterfaceメソッドに1行追加するだけで良い
無理
0789デフォルトの名無しさん
2012/01/15(日) 13:28:23.84>明確かどうかより拡張性さがるのが問題
>パターン1個追加するたびに、関係するクラス全部変更ってのは不便。
QueryInterfaceは拡張性ぜんぜん下がらないよ
むしろレジストリに登録する方がクラス間の参照関係、依存関係が増えて拡張性が下がる
0790デフォルトの名無しさん
2012/01/15(日) 13:33:06.07駒となるオブジェクトに持たせる必要が無いんだよ。
散々トポロジーの分野で使い古されてるネタだけど、
ある駒から、ある駒へのノードそのものをオブジェクトにして
そこにアクションを持たせておけばいい。
もちろんフルコネクトで繋ぎあわせると組み合わせが莫大になるから
その辺は、論理上のクラス(OOのクラスじゃない)で分けるんだけどね。
0791デフォルトの名無しさん
2012/01/15(日) 13:36:45.29そもそもQueryInterfaceをどうやって使う気なんだい？
クラスとオブジェクトのデータ構造が見えないから、
先入観で悪い使い方してるようにしか見えない。
0792デフォルトの名無しさん
2012/01/15(日) 13:45:24.19登録方式ならクラス間の依存性は増えないよ
他のクラスの事なんて全く知らないからね
0793デフォルトの名無しさん
2012/01/15(日) 13:48:01.12いまの流れで言ってるのは能力照会だよ
すごい適当に擬似コード書くならこんな感じの
衝突後処理(a, b)
合体可能インターフェース * p = 0; a->QueryInterface(合体可能インターフェースID, &p);
合体可能インターフェース * q = 0; b->QueryInterface(合体可能インターフェースID, &q);
if(p && q) { 合体処理(p, q) ; } // 両方共合体能力を持ってるなら合体
else { 通常処理(a, b); } // そうでないなら普通に衝突
>>792
クラス同士がお互いのレジストリクラスのこと知らないとだめじゃん
0794デフォルトの名無しさん
2012/01/15(日) 13:55:58.31const Kind gundom;
NodeSet set;
set.Register( new NodeActionA(), &tank, &gundom );
Unit unit_a( &gundom ), unit_b( &tank );
set.Conflict( unit_a, unit_b ).ActionDriven();
ノード制御ならこの3つを増やすだけだから楽だぞ
>const Kind xxxx;
>set.Register( new NodeActionA(), &tank, &gundom );
>new NodeActionA()
0795デフォルトの名無しさん
2012/01/15(日) 14:00:39.40それだったらQueryInterfaceやdynamic_castの類を使う必要はないよね。
単にIDを持ってるかどうか判定できればいいだけじゃん。
合体可能インターフェースなんて、クラスの依存性が増えるような物も必要ないじゃん。
0796794
2012/01/15(日) 14:08:48.56衝突情報を渡すの忘れてた。まぁいいか。
0797デフォルトの名無しさん
2012/01/15(日) 14:19:25.04あぁなるほど
RTTIオブジェクトのペアから衝突処理へのテーブルを用意するのか
ちょっとためしてみるわ
0798デフォルトの名無しさん
2012/01/15(日) 14:22:05.84もしかしたら誤解されてるかもしれんから
補足するけど、RTTIじゃなくアドレスをキーにしてるだけよ。
KindがRTTIの役割をするってのはそうだけど。
0799デフォルトの名無しさん
2012/01/17(火) 17:44:25.61昨年、俺らハードグループに配属（左遷）された癖の強いプログラマーがやってきて、
Ｃでさらさらとテストプログラムを完成させていくのを見るにつけ異人種だな！
あちきは、ＰＩＣマイコングループだが、あんなメモリ量しかないのにようやるわ。
ソース見てもコメントのステートとかストラテジーとかブリッジとかちんぷんかんぷん。
わしらの今まで書いていたテストプログラムはいったいなんだったんだ？
0800デフォルトの名無しさん
2012/01/22(日) 22:42:45.850801デフォルトの名無しさん
2012/01/30(月) 19:45:17.93仕様
・条件分岐やループ関連のコマンドはなし
・変数も使えない
・区切り文字はスペース、先頭の単語はコマンドを表し、それ以降はコマンド子固有のパラメーター
とりあえず、ファクトリーパターンでコマンドごとにIOperanインターフェイスを継承したオブジェクトを精製し、それに処理させるという形を考えてみた
これより拡張がしやすい設計の仕方があったら教えてほしい
0802デフォルトの名無しさん
2012/01/30(月) 23:38:18.110803デフォルトの名無しさん
2012/02/04(土) 23:54:00.53という意味でした。
0804デフォルトの名無しさん
2012/02/12(日) 17:23:42.97誰か教えてもらえないっすかねぇ。
http://ja.wikipedia.org/wiki/Model_View_Controller
の「MVCのシナリオ」のフロー通りに見ていくと
1&2で、まずWM_LBUTTONDOWN辺りのメッセージが、コールバック関数に送られてきますよね。
このコールバック関数があるスコープを仮にMainと呼んだとして、これをControllerと解釈していいんですかね？
3で、左クリックのイベントに対し、先のコールバック関数から、ModelクラスのHogeを読んで数値を+1したとします。
そしてHogeはObserverとして持っていた、Viewクラスに変更を通知します。
4で、Viewクラスが、例えばオフスクリーンサーフェスを更新して、InvalidateRect()します。
するとWM_PAINTを受け取ったMainがフリップします。Controllerが画面描画しちゃいますが。
こんな感じでいいんですかねぇ。なんかあまりすっきりしないというか、素人目には当たり前に見えてしまうというか。
0805デフォルトの名無しさん
2012/02/12(日) 17:25:27.580806デフォルトの名無しさん
2012/02/15(水) 03:10:14.230807デフォルトの名無しさん
2012/02/15(水) 14:09:38.750808デフォルトの名無しさん
2012/02/21(火) 23:56:46.63HWND window = CreateWindowEx(・・・);
Binder binder( window ); // CallbackをフックしてObserverに委譲するバインダー
CloseController control( window ); // 引数で受け取ったWindowを閉じるコントローラー
binder[WM_LBUTTONDOWN] += &control; // WM_LBUTONDOWNイベントにコントローラーを登録
0809デフォルトの名無しさん
2012/06/24(日) 18:50:30.45>staticメソッドを使う場合は 上手く継承できない。
SingletonとMonostateの比較でよく言われるけど、これってどういう現象を指してるんだ？
0810デフォルトの名無しさん
2012/06/24(日) 18:59:22.93いったいそれのどこがOOPなんだ
0811デフォルトの名無しさん
2012/06/24(日) 23:23:53.51オブジェクトで振る舞いを定義してるところ。
どうでもいいが、WindowsのWindowClassってのは、
Windowsの中じゃ唯一まともにOOPを実現できてるところよ。
CreateWindowでオブジェクトを作り、SendMessage,
PostMessageで、Smalltalkや、Objective-Cと同じ
メッセージパッシング機構を実現した。
どんくさい環境での妥協案ではあったが、なんとか
そこだけはパロアルトの意志を継いでる。
0812デフォルトの名無しさん
2012/06/24(日) 23:29:41.95継承も出来るし
0813デフォルトの名無しさん
2012/06/24(日) 23:30:19.65ポインタや参照をハンドルって形にしてるだけで
全然別種のオブジェクトを同じAPIで使用や解放する辺りも多態っぽい
0814デフォルトの名無しさん
2012/06/24(日) 23:31:14.63COMの方だろ。
0815デフォルトの名無しさん
2012/06/24(日) 23:31:44.91>メッセージパッシング機構を実現した。
全然違うｗｗｗ
0816デフォルトの名無しさん
2012/06/25(月) 00:39:40.40object x:10 y;10. 形式じゃないとメッセージ文に非ずと？
重要なのは、メッセージをメソッドと独立したデータとして扱える点だろ。
0817デフォルトの名無しさん
2012/06/25(月) 00:41:41.10COMはC++風OOPで、Smalltalk系統とは違うからなぁ
0818デフォルトの名無しさん
2012/06/25(月) 00:49:21.57WindowsというかWinAPIね。
0819デフォルトの名無しさん
2012/06/25(月) 01:03:23.54Windowと違ってユーザーが拡張できんからねぇ。
WindowClassなら、他のOOと同じく、移譲・集約・継承による
拡張ができるじゃん。当然、既存のウィンドウの子ウィンドウを
差し替えられて、ブリッジパターンの様な事すら可能だ。
しかもプロセス間においてもメッセージ送信が可能でSmalltalkや
Objecitive-Cのメッセージパッシングに非常に近い。
0820デフォルトの名無しさん
2012/06/25(月) 20:38:03.60メッセージの遅延送信ができてキューイングも出来るんだよな
よく似てる
■ このスレッドは過去ログ倉庫に格納されています