K.Maebashi's BBS

>つまり私の言いたいのは、 >オブジェクト指向の >利点は「再利用性が高まる事」＝「変更がしやすい、変更しても壊れにくい」。 >本質は「抽象化」 >だと言う事です。 >利点は「見通しの良さ」 >本質は「マルチプルインスタンス」 >ではないと思います。 本質は抽象化だと仰っているのにSEさんが出してるスタックの例はまったく 抽象化されていないような気がするのですが…。

>まるで3つのオブジェクト指向があるように思えますが、実質的にはオブジェクト指向は2です。 >1はメッセージが焦点になっていますが、本質はオブジェクトで2と同様です。 １の本質はオブジェクトではなくてメッセージだと書いてあるはずですが…。 ＃Smalltalkの文法やクラスやオブジェクトといった概念もおまけでしかない、とアランケイはのたまっています >もし初心者が見たら混乱するだけだと思います。2の説明だけあればいいと思います。 きちんと分類して書いてあるから少なくとも混乱することはないと思いますけどね。

クラスの階層構造のおかげで、モジュール化も適切な階層構造で行いやすくなる、ってことでしょうか。 少なくとも私自身は、そんなメリットを実感したこと、一度もないなぁ。 Cで「単位を合わせて」モジュール化する困難さと、クラスの階層構造を適切に設計する困難さは、 あまり違いがないように思うんですが、人によるのかな。 無地のノートより罫線の引いてあるノートのほうが書きやすい、ぐらいの違いはあるかもしれないけど。 Cで適切な階層構造のモジュール化が行えない人が、オブジェクト指向言語でクラス設計したところで、 （しかも実装継承で組んだりしたら）余計ぐちゃぐちゃになっちゃうような気がするんですが。

>関連する操作やデータをまとめる、というのは普通にモジュール化であって、 >私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った >board.cで達成していることでは? ここが重要です。 構造化プログラミングの「モジュール化」は基本的にモジュール化した所でしか有効ではありません。 1つの関数で考えた場合は分かりにくいかと思いますが、関連する複数の関数での場合を考えてください。 つまり拡張を見越して単位を合わせてモジュール化しておく必要があると言う事です。 オブジェクト指向の場合はクラス単位でモジュール化されているような物であると言う事です。 つまり末端のクラスから上位のクラスまで、全ての単位でモジュール化されているため、 あらゆる単位で変更が可能だと言う事です。 つまり私の言いたいのは、 オブジェクト指向の 利点は「再利用性が高まる事」＝「変更がしやすい、変更しても壊れにくい」。 本質は「抽象化」 だと言う事です。 利点は「見通しの良さ」 本質は「マルチプルインスタンス」 ではないと思います。 >いや、「世間のCプログラマはstaticで実装を隠蔽するような気の効いたことは >していない。だからお前の認識はズレているのだ」ということならそうなのかも >しれませんけど(1ソースファイル1関数、という規約のプロジェクトとかって、 >今でもあるんでしょうか)。 774RRさんの言う通り、「対象読者層が異なる」というだけの話のようです。 つまり「インスタンスが複数あっていい」というあたりを理解していないプログラマ向けの文書で、 私の指摘は「インスタンスが複数あるのは当たり前」と理解しているプログラマの視点という事です。 >うーん、Loggerくらいならstaticでもかまわないとは確かに思いますけれど、 >私ならアプリケーションのインスタンスのフィールドに持ちますね。 >オセロの例なら、Boardクラスで障害発生時とかのログを残すとして、Loggerは >Boardに持たせます。名人戦のBoardだけ障害発生時の対応が違ったりするかも >知れませんし。よって、BoardのコンストラクタかsetLogger()メソッドの >引数でLoggerを渡すことになります。 棋譜をセーブデータとして残すために、コンストラクタかセッターにファイル名を渡すと 言うならボードクラスに入れるのはいいと思いますが、 名人戦の障害発生対応が違うかもしれないので、エラーログクラスを受け渡すと言うのは おかしいと思います。

>>>これもひどい内容ですね。 > >とSEさんがおしゃるのか、さっぱりわからないんですけど。 1.メッセージ指向 2.クラス指向 3.手続き抽象化 のまるで3つのオブジェクト指向があるように思えますが、実質的にはオブジェクト指向は2です。 1はメッセージが焦点になっていますが、本質はオブジェクトで2と同様です。 3は少なくとも私は知りませんし、一般的ではないと思います。HP筆者の独自解釈では？ もし初心者が見たら混乱するだけだと思います。2の説明だけあればいいと思います。

>＃自分も特にSmalltalkに思い入れがあるわけではありません＾＾； ありゃ、そうですか。了解です。 全然完璧に関係ないですが、大昔、fjに高木浩光さんが 「Smalltalk原理主義者を殲滅せよ」なんてことを書いていて(もちろんネタですが)、 今これを探そうとしてGoogleグループを見てみたのですが…Googleグループって、 NewsGroupの検索ができるのだと思っていましたが、いつのまに2ch検索エンジンに?

>こくぼさんには「Smalltalkが不憫で仕方ありません」と言われそうですが、 >職業プログラマである我々が、現状、仕事でSmalltalkを使うことはまあまずないわけで、 >JavaやC++やC#を使うのに「メッセージ」がどうこう言われたら誤解を招く、というのは >わかります。 Smalltalkが不憫っていうのは、SEさんが紹介している説明を見ると まるでSmalltalkが悪いせいでオブジェクト指向が理解されてない みたいな書き方をされてるせいです。 ＃自分も特にSmalltalkに思い入れがあるわけではありません＾＾； >とSEさんがおしゃるのか、さっぱりわからないんですけど。 ですよね。

見ていただきありがとうございます。 >要点は、文字列以外はコンスタントプールを使わずに、直接定数を >バイトコードの中に埋め込むようにした、ということですよね。 はい >効率を考えてバイトコードではなくワードコード)中に埋め込んでいるそうです。 管理面とスピードを考えて、コードに埋め込みましたが問題なさそうでよかった。 >あと、もしシステムグローバル変数がDVM_Valueを保持しているのなら、 コード生成が一応落ち着いたのでVM部分を見ました。計算スタックはDVM_Value なんですね。VMを複数スレッド起動させるので、VMは極力最小にしようと思って います。その為に、省ける分はがさがさ省いていっています。コンスタントプール も、まさに、文字列を詰め込んだ配列とそのアクセスポインタテーブルのみです。 それと、GCは不要なシステムになります。INT用とdouble用の固定長プール、そして 文字列はstringに任せてしまうのでVMとしてのGCは無くなりました。この部分は VM管理システムで一括管理する予定。コード生成もそうでしたが、必要機能のた めに実行部分は最小に、その結果管理部分が大きくなっています。 　新しく組み込んでいる部分をあいまいに表現して申し訳ありません。なにぶん 出来てみないとなんとも言えなくて、絵に描いたもちを説明するのも気が引けて。 その部分はある程度完成するまでお待ちください。構想したものを組み込んで、 自身が確認しないとなんとも^^; 　追記、目的ターゲットでは、細かい文字列操作は多量にあると思いますが、長い 文字列は無いと思われますので、stringの管理でも問題は無いと思っています。 しかし、実際やってみての部分は有ります。その時は専用の文字列だけを管理する 処理を組み込む予定です。その場合も文字列だけなのでGCは不要で出来ます。

> {"push_int_4byte", "i", 1}, // 直接持に変更 > {"push_double_8byte", "d", 1}, // 直接持に変更 要点は、文字列以外はコンスタントプールを使わずに、直接定数を バイトコードの中に埋め込むようにした、ということですよね。 Diksamは、JVMを真似したのと、将来的にバイトコードをファイルに 吐き出すことを考えてコンスタントプールを持ちましたが、 たとえばYARVでは、効率を考えて定数をバイトコード(ていうかこれも 効率を考えてバイトコードではなくワードコード)中に埋め込んでいるそうです。 http://www.atdot.net/yarv/yarvarch.ja.html > {"push_sysval_int", "s", 1}, // システムグローバル変数アクセス用 > {"push_sysval_double", "s", 1}, // > {"push_sysval_str", "s", 1}, // > {"pop_sysval_int", "s", -1}, // > {"pop_sysval_double", "s", -1}, // > {"pop_sysval_str", "s", -1}, // あと、もしシステムグローバル変数がDVM_Valueを保持しているのなら、 実はpush_sysval_intやpush_sysval_doubleのようにインストラクションを 型ごとに分ける必要はありません。 Diksamの場合、スタックはDVM_Valueの配列のくせにこのインストラクションを 分けているのは、将来的にint型ローカル変数は4バイトしか消費しないようにする、 といった改善を入れるときのためです。

　コード生成部分を作っています。基本部以外がほとんど新たなプログラムに なっています。下にバイトコードの変更およびコードのディスアセンブラです。 　もしお時間が有りましたら見て、何か気になる点が有りますでしょうか？ ---　修正したバイトコード　------------ {"push_int_4byte", "i", 1}, // 直接持に変更 {"push_double_8byte", "d", 1}, // 直接持に変更 // 今考えると、リアル値を持つのはまずい？ ---　追加したバイトコード　------------ {"push_sysval_int", "s", 1}, // システムグローバル変数アクセス用 {"push_sysval_double", "s", 1}, // {"push_sysval_str", "s", 1}, // {"pop_sysval_int", "s", -1}, // {"pop_sysval_double", "s", -1}, // {"pop_sysval_str", "s", -1}, // -------------------------------------------------------- int main(int p1,int p2) { string[] msg = { "asd","qwe","zzz"}; int[] i1 = {1,2,65537}; double d1; d1 =3.1; } -------------------------------------------------------- 　　↓ コード生成後のダンプ 　　↓ 　　↓　上のコード修正で、constデータは文字列だけになりました。 -------------------------------------------------------- 1:*** 関数情報ダンプ ****************** 1:--- int main(int p1, int p2) 1:*** ローカル変数の表示 no = 3 *** 1: 0:string [] msg 1: 1:int [] i1 1: 2:double d1 1:*** 文字列定数 数 = 3 *** 1: 0: "asd" 1: 1: "qwe" 1: 2: "zzz" 1:*** 使用予定のスタックサイズ = 10 1:*** 関数コードのディスアセンブラ size = 45 1: 0 push_string_ptr 0 1: 3 push_string_ptr 1 1: 6 push_string_ptr 2 1: 9 new_array_literal_object 3 1: 12 pop_stack_object 2 1: 15 push_int_1byte 1 1: 17 push_int_1byte 2 1: 19 push_int_4byte 65537 1: 24 new_array_literal_int 3 1: 27 pop_stack_int 3 1: 30 push_double_8byte 3.100000e+000 1: 39 pop_stack_double 4 1: 42 push_int_1byte 0 1: 44 return 1:*** 行情報 数 = 5 *** 1: 3: from 0 size 15 1: 4: from 15 size 15 1: 6: from 30 size 12 1: 8: from 42 size 2 1: 7: from 44 size 1 1:*** end of main() -------------- --------------------------------------------------------

>デザインパターンと言うのは、世の中にある数多くのOOで組まれたプログラムの中から、 >共通性のある物を抜き出して分類し、その特徴や利点／欠点を解析する学問的な物です。 >重要なのは解析する能力を付ける事です。 なるほど、「学問的な物です」というのはよくわかりませんが、 おっしゃりたいことはだいたいわかったように思います。 >誰かの分類したパターンと特徴を暗記しても意味はありません。 しかしこれを「意味はありません」と言い切っちゃうのはどうかと。 kitさんが既に書いておられますが、デザインパターンはパターンに名前をつけて プログラマ間のコミュニケーションに使うことに意味があるわけですから。 >ITproのHPの人も言っていますが、「言語」→「実践」→「デザパタ」と進むのが >いいと思います。実践無しでデザパタを見たら、大抵の人は勘違いすると思います。 ここに異論はありません。

SEさんが何をおっしゃりたいのかますますわからなくなっていくのですが、 >ちなみに簡単に変更できた例は、 >メモリ上で頻繁に検索するデータが100件から6万件に変わった時の事でした。 >検索にキャッシュやヒストリー機能などあらゆる機能を組み込み高速化しましたが、 >修正したクラスは1つです。もしCの構造化で組んでいたら、修正箇所と影響範囲を >調べるだけで嫌になっていたと思います。 関連する操作やデータをまとめる、というのは普通にモジュール化であって、 私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った board.cで達成していることでは? http://kmaebashi.com/programmer/object/othello.html 「疑りぶかい～」を書いたときの私の認識は、 「Cなどでプログラムを書いている普通のプログラマは、staticで情報隠蔽するような 　モジュール化は普通に行っているだろう。でもそれは、オブジェクト指向ではない。 　オブジェクト指向(C++流の)といえばカプセル化、継承、ポリモルフィズムと言われるけれど、 　カプセル化は普通のCプログラマも理解していそうだし、継承やポリモルフィズムに 　至る前にマルチプルインスタンスを理解しなければいけないのに、世間にあふれる 　オブジェクト指向の説明からはそこがすっぽり抜けている。 　多くの人がここで引っかかるように思うので、このミッシングリンクは埋めておく 　べきではないか」 というものです。 この認識がズレている、という批判ならお受けしますけれども。 マルチプルインスタンスのさらに手前の事例を持ってきて、オブジェクト指向の 成果だと言われても…… 継承の話はどこにいったんでしょうか。 いや、「世間のCプログラマはstaticで実装を隠蔽するような気の効いたことは していない。だからお前の認識はズレているのだ」ということならそうなのかも しれませんけど(1ソースファイル1関数、という規約のプロジェクトとかって、 今でもあるんでしょうか)。 >普通のLoggerは、staticのフィールド変数として作成して直接使用するため、Logger自体を >メソッドの引数にして使用する事は少ないと思います。 うーん、Loggerくらいならstaticでもかまわないとは確かに思いますけれど、 私ならアプリケーションのインスタンスのフィールドに持ちますね。 オセロの例なら、Boardクラスで障害発生時とかのログを残すとして、Loggerは Boardに持たせます。名人戦のBoardだけ障害発生時の対応が違ったりするかも 知れませんし。よって、BoardのコンストラクタかsetLogger()メソッドの 引数でLoggerを渡すことになります。 >敢えてLoggerを例にするとすると、 >void write(Logger l){} >なら、 >class Logger{ >　　void write(){} >} >にすべきと言う事です。 ええと、write()メソッドがログを吐くメソッドなら、 >class Logger{ >　　void write(){} >} となるのは当たり前だと思うんですが……

件名変えました。 >アランケイの「メッセージ指向」は、C++の登場した当たりから軽視されるようになっていて、 >現在のオブジェクト指向の実装や環境から考えると、誤解しやすい物になっているからです。 >（ぱ）さんも「ただの関数呼び出し」と言っていますが、私もそう思います。 こくぼさんには「Smalltalkが不憫で仕方ありません」と言われそうですが、 職業プログラマである我々が、現状、仕事でSmalltalkを使うことはまあまずないわけで、 JavaやC++やC#を使うのに「メッセージ」がどうこう言われたら誤解を招く、というのは わかります。 で、当のsumimさんのページにはまさにそういうことが書いてあるわけで、 >なお、この文脈の「オブジェクト指向」において、メッセージングはぜんぜん関係ない >無用のもの and/or 動的性実現のための（仮想関数より効率の悪い）実装のひとつに >過ぎない…ということを強く意識する必要があります。ケイの影響で「オブジェクト >指向＝メッセージ」と脳に染みついている人には酷かもしれませんが、いっそ排除して >考えたほうがすっきりしますし、可能な限りそうすべきです。 >しがらみのない初学者へのレクチャーに際しては、ぜひとも「オブジェクトにメッセー >ジを送って…」とか「世の中のあらゆるものを(ry」なんて説明は後々無用な混乱を >招くだけなので、やめて欲しいと思います。 なぜこのページについて >これもひどい内容ですね。 とSEさんがおしゃるのか、さっぱりわからないんですけど。

デザインパターンと言うのは、世の中にある数多くのOOで組まれたプログラムの中から、 共通性のある物を抜き出して分類し、その特徴や利点／欠点を解析する学問的な物です。 重要なのは解析する能力を付ける事です。 誰かの分類したパターンと特徴を暗記しても意味はありません。 ただ私もGoFのパターンは見ました。学者的で実務に使えるのは2割程度だと思いましたが。 ITproのHPの人も言っていますが、「言語」→「実践」→「デザパタ」と進むのが いいと思います。実践無しでデザパタを見たら、大抵の人は勘違いすると思います。

>アランケイの「メッセージ指向」は、C++の登場した当たりから軽視されるようになっていて、 >現在のオブジェクト指向の実装や環境から考えると、誤解しやすい物になっているからです。 >（ぱ）さんも「ただの関数呼び出し」と言っていますが、私もそう思います。 >歴史に関してはウィキペディアに詳しく記載されています。 あぁ…。抽象データ型のオブジェクト指向が現代のオブジェクト指向だと解釈されているのですね。 そこらへんの各人のオブジェクト指向への認識の違いを理解していただくことも含めて sumimさんの説明ページへとリンクしたつもりでしたが伝わってないみたいで…。 ＃Wikipediaの説明も見ましたがあれではSmalltalkが不憫で仕方ありません >オブジェクト指向自体の話ではありませんが、オブジェクト指向の間違いやすい所に関しては、 >以下の記載がかなりいい所をついていると思います。（全て賛成できる訳ではありませんが） >http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/?ST=develop&P=1 ザッと見ました。 このページを見る限りではSEさんが例示しておられる 実装継承を使ったオブジェクト指向プログラミングを推奨しているわけではなさそうですね。

>関数等に切り出されて一箇所にまとめられていれば修正するのは一箇所です。 >ここまではオブジェクト指向は関係ありません。 ここがミソです。1つの関数を考えた場合はそうですが、関数群で考えると違います。 例えばファイル操作を考えてみましょう。 クラスなら以下のようになるとします。 class File{ 　　public void open(){} 　　public void read(){} 　　public void write(){} 　　public void close(){} } これなら明確です。ファイルからメモりに変わっても簡単に変更できるでしょう。 しかしCの構造化なら関数同士の関連はありません。 そのため、もしかしたらread()は業務ロジックに組み込まれ関数化されていないかもしれませんし、 write()は3つに分割されているかもしれません。例がファイルなのでそんな簡単な間違いは しないと言うかもしれませんが、もしこれが業務ロジックなら簡単に判断出来ないかもしれません。 これが関数化（プロセス中心アプローチ（POA）または、データ中心アプローチ（DOA））と、 クラス化（オブジェクト中心アプローチ（OOA））の違いです。 POA、DOA、OOAの特徴と違いについては、以下のサイトがよく分かります。 （分かりにくい表現もありますが） http://itpro.nikkeibp.co.jp/article/COLUMN/20061019/251255/ ちなみに簡単に変更できた例は、 メモリ上で頻繁に検索するデータが100件から6万件に変わった時の事でした。 検索にキャッシュやヒストリー機能などあらゆる機能を組み込み高速化しましたが、 修正したクラスは1つです。もしCの構造化で組んでいたら、修正箇所と影響範囲を 調べるだけで嫌になっていたと思います。 Loggerのようないわゆる「横断的関心事」はOOに適さないので例としては良くないと思いますが、 普通のLoggerは、staticのフィールド変数として作成して直接使用するため、Logger自体を メソッドの引数にして使用する事は少ないと思います。 敢えてLoggerを例にするとすると、 void write(Logger l){} なら、 class Logger{ 　　void write(){} } にすべきと言う事です。 >

>どこがひどいと思われるのでしょうか？ >「この当たりの話は知っています」と書かれていることから類似のWebページなどをご存知なのでしょうか。 >できればその情報のソースを教えていただきたいです。 >(自分的にこの手の情報はsumimさんの日記くらいしか知らないので) アランケイの「メッセージ指向」は、C++の登場した当たりから軽視されるようになっていて、 現在のオブジェクト指向の実装や環境から考えると、誤解しやすい物になっているからです。 （ぱ）さんも「ただの関数呼び出し」と言っていますが、私もそう思います。 歴史に関してはウィキペディアに詳しく記載されています。 >＃できれば他にもSEさんが比較的マシだと思ってる本やWebページを >＃いろいろ教えていただきたいところですが オブジェクト指向自体の話ではありませんが、オブジェクト指向の間違いやすい所に関しては、 以下の記載がかなりいい所をついていると思います。（全て賛成できる訳ではありませんが） http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/?ST=develop&P=1

懐かしいお名前がいっぱいでうれしくなりました。 kitさんも >でも、そもそもデザインパターンの多くは、それなりのプログラマーだったら、 >自分で似たようなものを必要に応じて考えて既に使っているものですよね。 と書かれていますが、SEさんのご意見が、 「天下りに与えられたパターンを憶える（＝学習する？）んじゃなくて、 自分で同じものを作ってみるなりしてきちんと理解する（＝解析する？）べきだ」、 ということならば、賛成ですけどね。 議論の行く末が気になるので、SEさんにはまた登場していただきたいです。

>ちょっと穿って解釈すると、 > >　ちなみにデザインパターンは学習(に値)する(ような)物ではなく、 >　(こんなものを調子こいて使ってしまうとソースが読みにくくなって >　必死に)解析する(ハメになるような)物です。 > >という意味なんでしょうか。 > >そういう趣旨ならわからなくはないし、部分的には賛同しないでもないのですが、 なるほど。 勉強したばかりで調子にのって *必要ないのに* 使いすぎると、問題は問題ですね。 でも、そもそもデザインパターンの多くは、それなりのプログラマーだったら、 自分で似たようなものを必要に応じて考えて既に使っているものですよね。 各種パターン本の意義は、そういうものにきちんと名前をつけて、いちいち説明 しなくても意思の疎通を可能にするという側面が大きいわけです。これにはソース 中の名前づけを標準化して、可読性を高めることを含みます。 したがって、経験のあるプログラマーにとって、デザインパターンの学習という のは、既知の設計手法について、規範となる名前を学習するという意味になります。 また、デザインパターンとして標準化された名前を使うことによって、ソース等を 解析することなく (すなわち、名前を見ただけで) モジュールの役割を理解する ことが可能になります。 また、もちろん初学者にとっては、設計パターンを自分で一から考える手間を省く という学習の意義があります。 というわけで、もしそういう意味だったとしても、やっぱり賛成できませんねえ。

横から口を出しますけど、 >>そもそも OO (というか継承－派生というシステム) のおいしいところは >>・「基底クラスを使う人」と「派生クラスを作る人」が分離できる >>・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい >>・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 >>　自動的に正しく使ってもらえる、と判断してよい >これが利点ですか？ちょっと他人に説明するのが難しいです。 前回私が例に出したLoggerクラスで考えると、 >>・「基底クラスを使う人」と「派生クラスを作る人」が分離できる 「Loggerクラスを使う人」は、logger.write()のようなメソッドを単に呼べばよく、 「ログをファイルに出力するFileLoggerクラスを作る人」と分離できる。 >>・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい 「Loggerクラスを使う人」は、logger.write()のようなメソッドを単に呼べばよく、 FileLoggerクラスについては知らなくていい。 >>・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 >>　自動的に正しく使ってもらえる、と判断してよい 「FileLoggerクラスを作る人」は、基底クラス側で期待している動作(=契約)に 反しない限り、自動的に正しく使ってもらえる、と判断してよい わけで、私から見れば、774RRさんはごく普通にオブジェクト指向の利点を 挙げていると思うんですけど。 もちろん、何にでも利点と欠点はあるものですし、その重み付けは用途によって 変わります。SEさんの過去の業務で実装継承がすごく役に立ったのなら、 それはそれで興味深いことです。 だからこそ、実際に役に立ちそうな現実的な例を挙げていただきたいと思いますし、 上記774RRさんが挙げられたような利点をあまり重視しておられないように見える割に、 [1260]のUpperStackにおいて、getUpper()のようなメソッドを作らずにget()を オーバーライドしていたり、 [1270]で >>「要素をgetする側は、大文字が欲しいとき、そのことを意識しないで済む」 >>ということにしたいのでしょうか? という問いに対して >そうです。 と答えていたり、 同じく[1270]で new LinkedHashMap<String, String>()の戻り値を Map<String, String>型の変数に代入したりしている 意図がさっぱりわからないわけです。

kitさん、おひさしぶりです。 >>>ちなみにデザインパターンは学習する物ではなく、解析する物です。 >> >>？？ >>すみません、仰っておられる意味がわかりません…。 > >素直に解釈すると、SEさんは GoF本や PofEAA あたりも読んだことがないって >ことになります (こういった本を読むこと == デザインパターンを学習すること >ですから)。 私にもSEさんのおっしゃる意味はよくわからないのですが、ちょっと穿って解釈すると、 　ちなみにデザインパターンは学習(に値)する(ような)物ではなく、 　(こんなものを調子こいて使ってしまうとソースが読みにくくなって 　必死に)解析する(ハメになるような)物です。 という意味なんでしょうか。 そういう趣旨ならわからなくはないし、部分的には賛同しないでもないのですが、 もしそういう意図なら、もっとわかりやすく書いていただきたいです……

>こちらの返信が遅くなってしまいました。 いえいえ、お返事いただけるだけで嬉しいので、気にしないでゆっくりして下さい。 >(私の感覚では)かなり実用的な問題でして。 了解しました >また、ヘッダファイルの依存関係が漏洩するという問題もあるでしょう。 >あるライブラリがウインドウに絵を描いたりするのでprivateメンバで >windows.hで定義されている型などを使っていたりすると、それを使う人にまで >もれなくwindows.hがプレゼントされ名前空間が汚染されてしまったりとか。 賛同です。これは問題ですね。OOP以前C言語の時は、それはキッチリとヘッダーが きれいに分割され必要な所だけが#includeされていたのですが。OOPになって、 必要も無いようなヘッダーが次から次へと#includeされているのを見るのは、 正直止めてほしいと思っています。特にVCはひどい、プリコンパイルヘッダーを 作ったのは苦肉の策ではないかと疑ってしまうほどです。 　しかし、現実に自身が作っている内容でも、結局多くのヘッダーが#include してしまっているのを見るにつけ、何かの対策がほしいと思います。 >これを問題と思わない人が多かったようなので、私のような心配をするのは >少数派なのかもしれませんけれども。 私もそうですが、目をつぶっているだけなのかも知れません。 　ちょっと真剣に考えて見ます。軽はずみな返事をしたくないと思っているので ちょっと期間をくださ。今は、作っている言語仕様に頭がいっぱいなんです。 いま佳境に入ってて、最近はプログラムではなく仕様書の書き込み書き直しばか りしています。楽しくもあり苦しくもある時間です。 　いやほんと、こんな仕様を発表したら、けちょんけちょんにけなされっるので はないかとか、本当に良いんだろうかとか、でも当面第1弾はこれしかないよな～ とか、悩んだりしています。 　　今作っている言語そしてシステムの最大の目的は。 　　「簡単なルールを持った言語で、いかに複雑な処理を簡単に書けるか」 なので、熟練のプログラマーのほうが抵抗が大きいのではないかと… 　プログラミング言語というものは論理的に整然と矛盾が無く、どんな形でも 記述可能であり。その中においてさえ、書きやすくセーフティーな環境を提供し 見やすさを追求している、と私は思っています。でも、私が目指しているのは。 記述目的を限定することで、自由が無くなる分、普通では考えられないような 記述で複雑なものを簡単に記述すシステムを出してみたい。 　大風呂敷はこのへんで終わって、早く実物が出来るようにがんばります。

>>ちなみにデザインパターンは学習する物ではなく、解析する物です。 > >？？ >すみません、仰っておられる意味がわかりません…。 素直に解釈すると、SEさんは GoF本や PofEAA あたりも読んだことがないって ことになります (こういった本を読むこと == デザインパターンを学習すること ですから)。 そう解釈していいんですかね?

SEさんとの議論がアツいので、こちらの返信が遅くなってしまいました。 >　カプセル化という言葉に対して、きっちりとした完全な意味を求めてるのだ >ろうと思いますが、私はそこまでのことを意識してこの言葉を使っていません。 ええと、用語定義の問題と言うよりは、(私の感覚では)かなり実用的な問題でして。 >　必要なこと意外一切情報を出さないほうがいいのか。内部がある程度想像 >できるほうがいいのか？Cはたとえ使えなくともクラスのデータやメソッドが見 >える。これが良いか悪いかでしょう。私は後者のほうが気分的には良いです。 チームで開発するとき、ライブラリとそれを使うアプリケーションがあったとして、 これらを平行して開発することがあります。そういう場合、ライブラリの ヘッダファイルだけ先に作ってしまえばアプリケーション側のコンパイルが通せますが、 その時、空実装のメソッドを暫定で書いて後で差し替えるような作業は バージョン管理が面倒になるので避けたい。また、ヘッダファイルはドキュメント的な 性格も大きいですから、ここに実装やprivateメンバを書いてごちゃごちゃして しまうのも避けたい。 また、ヘッダファイルの依存関係が漏洩するという問題もあるでしょう。 あるライブラリがウインドウに絵を描いたりするのでprivateメンバで windows.hで定義されている型などを使っていたりすると、それを使う人にまで もれなくwindows.hがプレゼントされ名前空間が汚染されてしまったりとか。 ……という話題が昔JavaHouseであったとき、 http://java-house.jp/ml/archive/j-h-b/048357.html#body http://java-house.jp/ml/archive/j-h-b/048360.html#body これを問題と思わない人が多かったようなので、私のような心配をするのは 少数派なのかもしれませんけれども。 >　言語の設計において、理想的なものを作っていくのもあります。私の場合は >目的が実現できれば簡単なものでいいと思って設計しています。その代表が >#defineです。古い仕様で問題点も内包しますが、実に使いやすく融通が利きます。 >今では#defineはあまり良くないとされていますが、私は利点を選びました。 これは同意です。「わかって使う」分には、#defineは便利ですよね。

>大文字小文字の例が悪かったのか、話がそこから進まないようです。 では、よい例を出してもらえませんか。具体的な例なしでこの手の話をしても 意味がありません。 774RRさんへの返信に >例えば総合試験で性能目標に達しなかった場合、従来の方法では普通は大変更に >なりますが、オブジェクト指向の場合、一部のクラスの取得処理を変更しただけで >修正できた例もあります。 とありますが、これも具体的にどういうケースだったのかわかりません。 普通に考えて、どこかの処理がボトルネックになっていたのなら、そこだけ 書き直せば速くなるでしょう。もちろん、その処理がプログラムのあっちこっちに コピペされていれば大変更になるでしょうが、関数等に切り出されて一箇所に まとめられていれば修正するのは一箇所です。ここまではオブジェクト指向は 関係ありません。 オブジェクト指向であったがゆえにうまくいった、とのことなので、 関数化ではうまくいかないケースだったのでしょう。どういう理由で、関数化では うまくいかず、オブジェクト指向(実装継承?)でうまくいったのでしょうか。 仕事のソースをここに貼ることができないのはわかっていますが、概要だけでも 教えてもらえませんか。興味深いので。 >遠くの所でnewした特有の処理の入ったクラスを、引数で使い回すのは、 >構造化のスタンプ結合的で、オブジェクト指向的には良くない設計です。 オブジェクト指向の最大の特徴のひとつであるポリモルフィズムは、遠いところで newしたオブジェクトのメソッドを呼ぶと、呼ぶ側が意識しなくても、 そのオブジェクトに応じたメソッドが呼び出される、というものですよね? デザインパターンなどでは生成に関するパターンだけでいくつもあって、 うちいくつかは、具体的なクラスが何であるかを意識させないようにするための ものですし、DI(Dependency Injection)なんかも考え方はそっち方面です。 まあ、この手のことは、当面用途もないのに調子に乗って柔軟性を求めると ソースが追えなくなってしまうので、私はあまり好きではないのですけれど。 ありがちな例では、たとえばログを出力するLoggerクラスをabstractクラスもしくは interfaceとして作って、それを継承またはimplementsしてファイルに吐くLoggerや syslogに吐くLoggerを作ったりしますが、これは、遠く離れたところでnewした Loggerを引数等で持って回ることになると思うんですが。 >オブジェクト指向の場合は処理は関連するデータと共にクラスに >まとめられるため、その引数を必要とするメソッドを、引数のクラス内 >に実装できるか検討すべきです。 意味がわかりません。 さっきのLoggerの例で言えば、Loggerクラスを引数として受け取るメソッドは Loggerを使うアプリケーションですが、アプリケーションのメソッドを Loggerクラスの中に作れ、という主張……ではないですよね。 >>ひとつ伺いたいのですが、SEさんはどんな本でオブジェクト指向の勉強をされたの >>でしょうか。 こくぼさんからも質問が出ていますが、私もSEさんが「比較的マシ」だと思ってる 本やWebページを教えていただきたいです。

>ちなみにデザインパターンは学習する物ではなく、解析する物です。 ？？ すみません、仰っておられる意味がわかりません…。 >これもひどい内容ですね。 詳しく教えていただきたいのですが、 どこがひどいと思われるのでしょうか？ 「この当たりの話は知っています」と書かれていることから類似のWebページなどをご存知なのでしょうか。 できればその情報のソースを教えていただきたいです。 (自分的にこの手の情報はsumimさんの日記くらいしか知らないので) >これならまだ「ウィキペディア」の「オブジェクト指向プログラミング」の >方がマシです。 >一度読んでみてはいかがですか？ ありがとうございます。 読んでみます。 ＃できれば他にもSEさんが比較的マシだと思ってる本やWebページを ＃いろいろ教えていただきたいところですが

>デザインパターンを学習されているなら継承を使う機会は減ると思うんですけど。 >＃減るというか注意深くなるというか デザインパターンは知っています。 ちなみにデザインパターンは学習する物ではなく、解析する物です。 >ちなみにこのページはオブジェクト指向を学ぶうえにおいてとても参考になります。 >一読してみてください。 >http://d.hatena.ne.jp/sumim/20040525/p1 これもひどい内容ですね。 この当たりの話は知っていますが、参考にするのはまずいでしょう。 これならまだ「ウィキペディア」の「オブジェクト指向プログラミング」の 方がマシです。 一度読んでみてはいかがですか？

>俺も (ぱ) 氏ももっとマクロな＝大規模プログラムでの応用の話をしているわけです。 >そういうレベルでは、提示のコードのような派生はうまくいきません。 なぜ大規模プログラムでうまくいかないのかが分かりません。 実際、大規模プログラムで使用していますが、効果が出ています。 例えば総合試験で性能目標に達しなかった場合、従来の方法では普通は大変更に なりますが、オブジェクト指向の場合、一部のクラスの取得処理を変更しただけで 修正できた例もあります。 オブジェクト指向ではオブジェクト単位であるため、大きいレベルから小さいレベル まで対応できるのが特徴です。 >そもそも OO (というか継承－派生というシステム) のおいしいところは >・「基底クラスを使う人」と「派生クラスを作る人」が分離できる >・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい >・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 >　自動的に正しく使ってもらえる、と判断してよい これが利点ですか？ちょっと他人に説明するのが難しいです。 私の例では、処理に大修正が入った場合（例えばDB変更や、ローカルファイルから 通信を使ったリモートファイルへの変更）、これだけの修正で済みますなどと 言えますが、上記の場合はどう説明しますか？ >んで、マルチプルインスタンスの件のほうはもういいのでしょうか？ >俺としては既に書いたとおり「対象読者層が異なる」というだけの話だと思っております。 了解しました。

スタックの例とかあんまり細かく見ずにコメントしますが…。 >それぞれ用途が違いますが、オブジェクト指向特有で強力なのが2,3です。 >別に全て2でやれと言っているわけではなく、2の使い方が出来るのが >利点だと言っている訳です。 >... >つまり、分かりやすいとか間違えやすいとか言う話は別として、 >4種類の変更方法を選択できるため、再利用性が高いと言っている訳です。 そもそも継承というメカニズムを使うのが間違いのもとになっちゃうような。 デザインパターンを学習されているなら継承を使う機会は減ると思うんですけど。 ＃減るというか注意深くなるというか >本は色々読みましたが、全てが同意できる物はありません。 となると、ここで力説されていらっしゃる実装継承を使ったOOP をどこから学ばれたのか興味深いですね。 ちなみにこのページはオブジェクト指向を学ぶうえにおいてとても参考になります。 一読してみてください。 http://d.hatena.ne.jp/sumim/20040525/p1